RequestedClaimsExtensions Class
Reading the end users a claims request will accept for sub.
public static class RequestedClaimsExtensionsInheritance System.Object → RequestedClaimsExtensions
Methods
RequestedClaimsExtensions.RequestedSubjects(this RequestedClaims) Method
The end users this request will accept for sub: null when it named none in particular,
an empty array when it named a combination nobody can satisfy, or a failure describing a malformed
qualifier.
public static Abblix.Utils.Result<string[]?,string> RequestedSubjects(this Abblix.Oidc.Server.Model.RequestedClaims? claims);Parameters
claims RequestedClaims
Returns
Abblix.Utils.Result<System.String[],System.String>
Remarks
OpenID Connect Core 1.0 Section 3.1.2.2 names this and id_token_hint as two ways to make one
request, so every endpoint accepting either has to read both the same way. Section 5.5.1 gives the
qualifiers their meaning: value "requests that the Claim be returned with a particular value",
values is "processed equivalently to a value request, except that a choice of acceptable Claim
values is provided", and "if the Claim was sub, a mismatch MUST cause the authentication to
fail".
Section 5.5.1 defines both qualifiers as OPTIONAL and says nothing about carrying them together, so a
request doing so is read as stating both constraints: the subject has to be the one named by
value AND one of those listed in values. Incompatible constraints leave nothing
acceptable, which is the guaranteed mismatch that same section already prescribes an outcome for.
Only the id_token member is read, deliberately. Section 3.1.2.2 scopes the requirement to a
sub "requested with a specific value for the ID Token", and a userinfo.sub entry asks
what the UserInfo response should contain rather than who the request is about - Section 5.5.1's
mismatch rule then governs that response, not the authentication.