#### [Abblix\.Oidc\.Server](https://www.abblix.com/en/docs/api/abblix-oidc-server 'index')

## Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation Namespace

| Classes | |
| :--- | :--- |
| [AuthorizationDetailsTypesValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.AuthorizationDetailsTypesValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.AuthorizationDetailsTypesValidator') | Rejects client registration when the requested `authorization_details_types` per\-client allowlist \(RFC 9396 §5\.1\) names any `type` value the server does not understand, returning `invalid_client_metadata` per OIDC DCR §3\.2\. Without this gate the registration would succeed and every RAR\-bearing request from this client would fail at the authorize/PAR endpoint with `invalid_authorization_details` — a worse error surface for the deployer who registered with a typo\. |
| [BackChannelAuthenticationValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.BackChannelAuthenticationValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.BackChannelAuthenticationValidator') | Validates CIBA\-related metadata \(OpenID Connect Client\-Initiated Backchannel Authentication 1\.0 §4\): the consistency between `backchannel_token_delivery_mode` and `backchannel_client_notification_endpoint`, and that `backchannel_authentication_request_signing_alg` is on the server's supported list\. |
| [BackChannelLogoutUriValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.BackChannelLogoutUriValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.BackChannelLogoutUriValidator') | Validates the OIDC Back\-Channel Logout 1\.0 `backchannel_logout_uri`: when supplied it must be an absolute URI that the server is permitted to fetch under the active SSRF policy \([SecureHttpFetchOptions](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Features.SecureHttpFetch.SecureHttpFetchOptions 'Abblix\.Oidc\.Server\.Features\.SecureHttpFetch\.SecureHttpFetchOptions')\)\. Because the OP itself POSTs the logout token to this endpoint, rejecting an internal/loopback or disallowed\-scheme target at registration stops a registered client from becoming a \(blind\) SSRF vector and surfaces the problem to the caller up front rather than as a silent delivery failure at logout time\. The outbound handler still re\-validates at request time\. |
| [ClientIdValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.ClientIdValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.ClientIdValidator') | Cross\-checks the supplied `client_id` against the operation type: for [Update](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.DynamicClientOperation#Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.DynamicClientOperation.Update 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.DynamicClientOperation\.Update') \(RFC 7592 §2\.2\) the client must already exist, for [Register](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.DynamicClientOperation#Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.DynamicClientOperation.Register 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.DynamicClientOperation\.Register') \(RFC 7591 §3\) it must not\. A missing `client_id` is treated as new\-registration with server\-assigned id\. |
| [ClientRegistrationContextValidatorComposite](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.ClientRegistrationContextValidatorComposite 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.ClientRegistrationContextValidatorComposite') | Composite that runs the configured chain of [IClientRegistrationContextValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.IClientRegistrationContextValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.IClientRegistrationContextValidator') steps in order and short\-circuits on the first failure, mirroring RFC 7591 §3\.2\.2 which requires the server to reject a registration on the first invalid metadata field\. |
| [ClientRegistrationValidationContext](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.ClientRegistrationValidationContext 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.ClientRegistrationValidationContext') | Mutable state shared by the validation pipeline\. Carries the original [ClientRegistrationRequest](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Model.ClientRegistrationRequest 'Abblix\.Oidc\.Server\.Model\.ClientRegistrationRequest') alongside derived values that earlier steps compute and later steps \(or the processor\) consume\. |
| [CredentialsValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.CredentialsValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.CredentialsValidator') | Validates that client authentication methods are consistent with the credentials provided during registration\. Ensures clients using JWT\-based or TLS authentication have the required credentials \(JWKS for JWT methods, TLS metadata for TLS methods\)\. JWKS may be provided by any client for encryption or request object signing\. |
| [EncryptedResponseAlgorithmsValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.EncryptedResponseAlgorithmsValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.EncryptedResponseAlgorithmsValidator') | Validates the JWE algorithms a client requests for the JWTs this server encrypts or decrypts: `id_token_encrypted_response_alg`/`enc` and `userinfo_encrypted_response_alg`/`enc` \(OIDC Core\), `request_object_encryption_alg`/`enc` \(RFC 9101\) and `authorization_encrypted_response_alg`/`enc` \(JARM §3\)\. Each key\-management \(`alg`\) value must appear in the server's supported key\-management algorithms and each content\-encryption \(`enc`\) value in its supported content\-encryption algorithms\. |
| [ErrorFactory](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.ErrorFactory 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.ErrorFactory') | Builds [OidcError](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.OidcError 'Abblix\.Oidc\.Server\.Common\.OidcError') instances using the error codes RFC 7591 §3\.2\.2 reserves for dynamic client registration: `invalid_redirect_uri`, `invalid_client_metadata`, `invalid_software_statement`, and `unapproved_software_statement`\. |
| [GrantTypeValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.GrantTypeValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.GrantTypeValidator') | Enforces the consistency rule from OIDC DCR 1\.0 §2 between `response_types` and `grant_types`: a client requesting `code` must register the `authorization_code` grant, and one requesting `token` or `id_token` must register the `implicit` grant\. |
| [InitialAccessTokenValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.InitialAccessTokenValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.InitialAccessTokenValidator') | Validates the initial access token on client registration requests per RFC 7591 Section 3 and RFC 6750 Bearer Token Usage\. When [RequireInitialAccessToken](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.OidcOptions#Abblix.Oidc.Server.Common.Configuration.OidcOptions.RequireInitialAccessToken 'Abblix\.Oidc\.Server\.Common\.Configuration\.OidcOptions\.RequireInitialAccessToken') is enabled, checks JWT signature, expiration, type, and revocation status\. Skipped for update operations and when the feature is disabled\. |
| [InitiateLoginUriValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.InitiateLoginUriValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.InitiateLoginUriValidator') | Validates the OIDC DCR 1\.0 §2 `initiate_login_uri`: when supplied it must be an absolute URI using the `https` scheme\. |
| [PostLogoutRedirectUrisValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.PostLogoutRedirectUrisValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.PostLogoutRedirectUrisValidator') | Validates the OpenID Connect RP\-Initiated Logout 1\.0 `post_logout_redirect_uris`: each URI must be absolute, fragment\-free, and consistent with the OIDC DCR 1\.0 §2 scheme rules for the declared `application_type` \(Web = `https`, non\-localhost; Native = custom scheme or `http://localhost`\)\. |
| [ScopeValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.ScopeValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.ScopeValidator') | Validates the scope values in a client registration request per RFC 7591 Section 2\. Each requested scope must be recognized by the server\. |
| [SecurityProfileValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.SecurityProfileValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.SecurityProfileValidator') | Fail\-loud companion to the request\-time profile enforcement: rejects a registration whose declared response types can never satisfy the security profile the client falls under, so the contradiction surfaces at registration with a clear `invalid_client_metadata` diagnostic instead of as a per\-request rejection the client has to reverse\-engineer later\. Whether a client is held to a profile is a server\-side policy decision: a dynamically registered client cannot declare one, so it inherits the server\-wide [DefaultSecurityProfile](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.Configuration.OidcOptions#Abblix.Oidc.Server.Common.Configuration.OidcOptions.DefaultSecurityProfile 'Abblix\.Oidc\.Server\.Common\.Configuration\.OidcOptions\.DefaultSecurityProfile')\. |
| [SignedResponseAlgorithmsValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.SignedResponseAlgorithmsValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.SignedResponseAlgorithmsValidator') | Validates the algorithms a client requests for tokens this server signs: `id_token_signed_response_alg` and `userinfo_signed_response_alg` \(OIDC DCR 1\.0 §2\), and `authorization_signed_response_alg` \(JARM §3\)\. Each must appear in the server's set of supported signing algorithms; in addition, JARM §3 forbids `none` for the authorization response\. |
| [SigningAlgorithmsValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.SigningAlgorithmsValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.SigningAlgorithmsValidator') | Validates the algorithms a client commits to using on inbound JWTs the server will verify: `request_object_signing_alg` \(OIDC Core §6\.1\), `backchannel_authentication_request_signing_alg` \(CIBA §7\.1\.1\), and `token_endpoint_auth_signing_alg` \(RFC 7591 §2 / RFC 8414 §2\)\. Each must appear in the matching set the server advertises in discovery: `request_object_signing_alg` may be `none`, but `token_endpoint_auth_signing_alg` excludes `none` and `backchannel_authentication_request_signing_alg` excludes both `none` and the symmetric HS\* algorithms\. The same provider feeds the discovery document, so DCR accepts exactly what the server advertises\. |
| [SoftwareStatementValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.SoftwareStatementValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.SoftwareStatementValidator') | Validates the software\_statement parameter in a client registration request per RFC 7591 Section 2\.3\. Software statements are signed JWTs issued by a third\-party authority asserting metadata about client software\. |
| [SubjectTypeValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.SubjectTypeValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.SubjectTypeValidator') | Validates the OIDC Core §8 `subject_type` metadata and computes the pairwise sector identifier per OIDC Core §8\.1: when `pairwise` is requested, either a supplied `sector_identifier_uri` \(HTTPS, JSON document of redirect URIs\) is dereferenced and cross\-checked against the registered `redirect_uris`, or all redirect URIs must share a single host\. The resolved host is stored on the context for later persistence\. |
| [SupportedGrantTypeValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.SupportedGrantTypeValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.SupportedGrantTypeValidator') | Rejects client registration when any value in `grant_types` is not advertised as supported by this server, returning `invalid_client_metadata` per OIDC DCR §3\.2\. Without this gate the registration would succeed and the client would only fail later at the token endpoint with `unsupported_grant_type`, or at the authorization endpoint for the `implicit` grant\. Companion to [SupportedResponseTypeValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.SupportedResponseTypeValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.SupportedResponseTypeValidator'), which applies the same rule to `response_types`\. |
| [SupportedResponseTypeValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.SupportedResponseTypeValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.SupportedResponseTypeValidator') | Server\-level support gate for the `response_types` registration parameter \(OIDC DCR §3\.2\): every part of every requested combination must have a registered [IAuthorizationResponseBuilder](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.Authorization.Interfaces.IAuthorizationResponseBuilder 'Abblix\.Oidc\.Server\.Endpoints\.Authorization\.Interfaces\.IAuthorizationResponseBuilder')\. Without `EnableImplicitFlow()` the `token` / `id_token` processors are absent — registration must reject those values with `invalid_client_metadata` at registration time, instead of letting the client succeed at registration and fail with `unsupported_response_type` on its first authorization request\. |
| [SyncClientRegistrationContextValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.SyncClientRegistrationContextValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.SyncClientRegistrationContextValidator') | Convenience base for validation steps whose checks are purely in\-memory: implements the async contract by wrapping the synchronous [Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.SyncClientRegistrationContextValidator\.Validate\(Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.ClientRegistrationValidationContext\)](https://learn.microsoft.com/en-us/dotnet/api/abblix.oidc.server.endpoints.dynamicclientmanagement.validation.syncclientregistrationcontextvalidator.validate#abblix-oidc-server-endpoints-dynamicclientmanagement-validation-syncclientregistrationcontextvalidator-validate(abblix-oidc-server-endpoints-dynamicclientmanagement-validation-clientregistrationvalidationcontext) 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.SyncClientRegistrationContextValidator\.Validate\(Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.ClientRegistrationValidationContext\)') result in a completed task\. |
| [TlsClientAuthValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.TlsClientAuthValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.TlsClientAuthValidator') | Validates tls\_client\_auth metadata fields for RFC 8705 mutual TLS client authentication\. Ensures that required metadata is present and properly formatted when tls\_client\_auth method is selected\. |
| [TokenEndpointAuthMethodValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.TokenEndpointAuthMethodValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.TokenEndpointAuthMethodValidator') | Validates that the requested `token_endpoint_auth_method` \(RFC 7591 §2\) is one this server announces in `token_endpoint_auth_methods_supported` on its discovery document\. |

| Interfaces | |
| :--- | :--- |
| [IClientRegistrationContextValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.IClientRegistrationContextValidator 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.IClientRegistrationContextValidator') | One step in the client\-registration validation pipeline \(RFC 7591 §2 / OIDC DCR 1\.0\)\. Implementations check a specific aspect of the supplied metadata \(redirect URIs, grant types, signing algorithms, sector identifier, software statement, etc\.\) and either clear it or surface an [OidcError](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Common.OidcError 'Abblix\.Oidc\.Server\.Common\.OidcError') for the response\. Aggregated by [ClientRegistrationContextValidatorComposite](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.ClientRegistrationContextValidatorComposite 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.ClientRegistrationContextValidatorComposite')\. |

| Enums | |
| :--- | :--- |
| [DynamicClientOperation](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.DynamicClientOperation 'Abblix\.Oidc\.Server\.Endpoints\.DynamicClientManagement\.Validation\.DynamicClientOperation') | Defines the type of dynamic client management operation being performed\. |