IAuthorizationDetailsPolicy Interface

Single request-time entry point for the RFC 9396 authorization_details policy: per-client allowlist (§10) plus per-type composite dispatch (§5). Endpoint-side adapters delegate here so /authorize, /par, CIBA and device-flow share one policy source.

public interface IAuthorizationDetailsPolicy

Remarks

Registered unconditionally by AddRichAuthorizationRequests(this IServiceCollection) so the server boots cleanly with zero IAuthorizationDetailValidator implementations registered. Per RFC 9396 §5 (the AS MUST refuse unknown types), an empty registry rejects every RAR-bearing request - this is conformance-mandatory, not a configurable policy.

Methods

IAuthorizationDetailsPolicy.ApplyAsync(JsonArray, ClientInfo, CancellationToken) Method

Full RFC 9396 §5 + §10 request-time validation entry point. Takes the raw authorization_details array as it landed on the wire, applies the per-client allowlist, dispatches each typed entry to its keyed IAuthorizationDetailValidator, and returns the validated raw array for the pipeline to forward.

System.Threading.Tasks.Task<Abblix.Utils.Result<System.Text.Json.Nodes.JsonArray?,Abblix.Oidc.Server.Common.OidcError>> ApplyAsync(System.Text.Json.Nodes.JsonArray? raw, Abblix.Oidc.Server.Features.ClientInformation.ClientInfo client, System.Threading.CancellationToken token);

Parameters

raw System.Text.Json.Nodes.JsonArray

The raw authorization_details array off the wire, or null / empty when the request did not carry one.

client ClientInfo

The authenticated client; AuthorizationDetailsTypes drives the allowlist branch.

token System.Threading.CancellationToken

Cancellation token forwarded to per-type validators.

Returns

System.Threading.Tasks.Task<Abblix.Utils.Result<System.Text.Json.Nodes.JsonArray,OidcError>>
On success - the raw System.Text.Json.Nodes.JsonArray that survived validation (or null when the input was null / empty / contained no typed entries - there is nothing to forward in that case). On failure - a fully-formed OidcError with error = invalid_authorization_details (RFC 9396 §5) and the rejection description; the endpoint adapter forwards it as-is when its error type is OidcError, or re-wraps the description otherwise.

Remarks

The returned System.Text.Json.Nodes.JsonArray reflects the post-validation set: when per-type validators leave their inputs untouched it is byte-equivalent to the input, but when a validator narrows / extends per RFC 9396 §7.1 (e.g. a consent-UI slider, an AS-policy cap, or canonicalisation), the mutation surfaces here and the pipeline forwards the post-validation shape into AuthorizationContext - token emission reflects what was actually granted, not the original request.

IAuthorizationDetailsPolicy.ApplyGrantedAsync(JsonArray, ClientInfo, CancellationToken) Method

The same validation applied to a set the consent decision produced rather than one a client sent, dispatching each entry to ValidateGrantedAsync(AuthorizationDetail, ClientInfo, CancellationToken). Defaults to ApplyAsync(JsonArray, ClientInfo, CancellationToken).

System.Threading.Tasks.Task<Abblix.Utils.Result<System.Text.Json.Nodes.JsonArray?,Abblix.Oidc.Server.Common.OidcError>> ApplyGrantedAsync(System.Text.Json.Nodes.JsonArray? granted, Abblix.Oidc.Server.Features.ClientInformation.ClientInfo client, System.Threading.CancellationToken token);

Parameters

granted System.Text.Json.Nodes.JsonArray

The authorization_details the consent decision granted.

client ClientInfo

The client the grant is being issued to.

token System.Threading.CancellationToken

Cancellation token forwarded to per-type validators.

Returns

System.Threading.Tasks.Task<Abblix.Utils.Result<System.Text.Json.Nodes.JsonArray,OidcError>>
The same shape as ApplyAsync(JsonArray, ClientInfo, CancellationToken): the post-validation array on success, or an OidcError naming the entry that was refused.

Remarks

Everything outside the per-type question is phase-independent and still applies: the entries must be JSON objects, their types must be known, and the per-client allowlist still binds. Only the question put to the per-type validator differs, because RFC 9396 §7.1 lets the server add values during consent that §5 obliges it to refuse from a client.

A decorator around this interface MUST forward this member too. The default sends it to ApplyAsync(JsonArray, ClientInfo, CancellationToken), so a decorator that implements only that one turns the granted phase back into the request phase for everything it wraps - silently, since the call still succeeds and the pipeline still runs. The same holds for a mock: a strict one refuses the call, and a loose one answers with a null task result the caller then dereferences.