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

## RequestedSubjectValidator Class

Records the end users a `claims` request will accept for `sub`, so the endpoint can honour them
when it chooses a session\.

```csharp
public class RequestedSubjectValidator : Abblix.Oidc.Server.Endpoints.Authorization.Validation.SyncAuthorizationContextValidatorBase
```

Inheritance [System\.Object](https://learn.microsoft.com/en-us/dotnet/api/system.object 'System\.Object') → [SyncAuthorizationContextValidatorBase](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.Authorization.Validation.SyncAuthorizationContextValidatorBase 'Abblix\.Oidc\.Server\.Endpoints\.Authorization\.Validation\.SyncAuthorizationContextValidatorBase') → RequestedSubjectValidator

### Remarks
This is the second way of asking what `id_token_hint` asks, and OpenID Connect Core 1\.0 Section
3\.1\.2\.2 states them as one requirement: "If the `sub` \(subject\) Claim is requested with a specific
value for the ID Token, the Authorization Server MUST only send a positive response if the End\-User
identified by that `sub` value has an active session with the Authorization Server or has been
Authenticated as a result of the request\. The Authorization Server MUST NOT reply with an ID Token or
Access Token for a different user, even if they have an active session with the Authorization Server\. Such
a request can be made either using an `id_token_hint` parameter or by requesting a specific Claim
Value as described in Section 5\.5\.1, if the `claims` parameter is supported by the implementation\."

The condition attached to that MUST is met here rather than left open: the discovery document advertises
`claims_parameter_supported`, so a client is entitled to expect the parameter to decide something.
What makes a request name somebody lives in [RequestedSubjects\(this RequestedClaims\)](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Model.RequestedClaimsExtensions#Abblix.Oidc.Server.Model.RequestedClaimsExtensions.RequestedSubjects(thisAbblix.Oidc.Server.Model.RequestedClaims) 'Abblix\.Oidc\.Server\.Model\.RequestedClaimsExtensions\.RequestedSubjects\(this Abblix\.Oidc\.Server\.Model\.RequestedClaims\)'),
shared with the decoupled endpoint that accepts the same parameter without a browser.

Runs beside [IdTokenHintValidator](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Endpoints.Authorization.Validation.IdTokenHintValidator 'Abblix\.Oidc\.Server\.Endpoints\.Authorization\.Validation\.IdTokenHintValidator') and after the validators that resolve the redirect URI and
the response mode, for the same reason: its refusals are the kind RFC 6749 Section 4.1.2.1 says the client
must be told about by redirection, and before those there is nowhere to tell it.