Struct ApprovalRequest 

#[non_exhaustive]
pub struct ApprovalRequest<'a> {
    pub headers: &'a HeaderMap,
    pub subject: &'a str,
    pub client_id: &'a ClientId,
    pub scope: &'a ScopeSet,
    pub redirect_uri: &'a str,
    pub state: Option<&'a str>,
    pub resource: &'a [String],
    pub authorization_details: &'a AuthorizationDetails,
    pub uri: &'a Uri,
    pub remembered: Option<&'a ConsentRecord>,
}

Available on crate feature http only.

What the host’s approval resolver is told about the request it is being asked to approve.

Everything borrows: the resolver is called inside the request path and nothing here outlives it. The request has already passed RFC 6749 s4.1.1 validation, so client_id, redirect_uri and scope are the VALIDATED values (the redirect URI is a registered one, the scope is inside the client’s registration), not raw query text. #[non_exhaustive]: this type’s shape already varies with the cargo features a host enables, so an exhaustive match on it was never portable between builds of this crate.

Fields (Non-exhaustive)

Non-exhaustive structs could have additional fields added in future. Therefore, non-exhaustive structs cannot be constructed in external crates using the traditional Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.

headers: &'a HeaderMap

The request’s headers, so the host can find its own session.

subject: &'a str

The authenticated resource owner, as named by the subject resolver.

client_id: &'a ClientId

The client asking.

scope: &'a ScopeSet

The scope that will be granted if this is approved.

redirect_uri: &'a str

The registered redirect URI this request resolved to.

state: Option<&'a str>

The client’s state, if it sent one.

resource: &'a [String]

The RFC 8707 resource indicators this request asked for, already validated against the server’s allowed_resources. Empty when the client named none.

It is here because the audience a token will carry is part of what the user is being asked to approve: “read your calendar” means something different at one resource server than at another, and the host cannot recover this from the query. For a PAR request the query holds only client_id and the request URI, and the pushed record has already been consumed by the time this resolver runs; for a JAR request the values are inside the signed object.

authorization_details: &'a AuthorizationDetails

Available on crate feature rar only.

The RFC 9396 authorization_details this request asked for, already parsed and already checked against the server’s supported types (section 5).

THE TYPE CHECK IS NOT AN APPROVAL. AuthorizationDetails::require_supported_types inspects the type string alone, so the amount, the identifier, the creditor account and every other type-specific member of an element reach the issued token unexamined unless this resolver looks at them. RFC 9396 section 2 makes the elements the thing being authorized, and this crate never renders a screen, so the decision belongs here: a host that shows only ApprovalRequest::scope is asking the user to approve a payment they were never shown. Like ApprovalRequest::resource, it cannot be recovered from the query on the PAR or JAR paths.

uri: &'a Uri

The full request URI, so a host that renders a consent screen can round-trip the user back to exactly this request after they answer.

remembered: Option<&'a ConsentRecord>

Available on crate feature consent only.

What this user has already granted this client, if anything.

This is the library REPORTING and the host DECIDING, and that split is the whole design. crate::consent::ConsentRecord::covers answers whether the remembered grant already covers what is being asked for now; whether that is a good enough reason to skip the prompt depends on how long ago it was, what the scope means in this deployment, and whether the user is on a device the host trusts, none of which this crate knows. So it is handed over, and nothing here ever approves on the strength of it.

covers takes all three of what is being asked for, and the third is ApprovalRequest::authorization_details, wrapped by crate::consent::RequestedDetails::of. It answers false for any request that carries one, so a resolver that skips its prompt on a true still asks about every RFC 9396 element: a remembered consent records a scope and a resource list, and an element it never recorded is not something it can be said to cover. That method’s docs give the argument in full, including why the answer would barely change if it did record them.