OAuth 2.0 Rich Authorization Requests for AS-Attested User Certificates

1. Introduction With the rise of autonomous AI Agents acting on behalf of users, traditional OAuth 2.0 scopes often fail to provide the fine-grained, user-signed intent verification required for high-stakes operations. A robust solution involves the Resource Owner (RO) issuing a Verifiable Credential (VC) to the Client. To exercise these delegated rights, the Client generates and presents a Verifiable Presentation (VP)-derived from the original VC-to the Resource Server (RS) to prove specific, user-signed delegation boundaries. However, a trust gap exists: while the RO uses its private key to sign the VC, the RS lacks a standard mechanism to verify if the corresponding public key genuinely belongs to the RO. This specification bridges that gap by leveraging Rich Authorization Requests (RAR) . It allows a Client to request an AS-attested certificate of the RO's public key. The RS can then extract this certificate from the Access Token to verify the signature of the RO-issued evidence contained within the VP.

2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119.

3. Protocol Overview The protocol consists of two phases: Initial Bootstrapping and Autonomous Execution.

3.1. Phase 1: Initial Bootstrapping and Registration The RO registers their public key and authorizes the Client to act on their behalf.

| | | RO | (2) Acknowledge & Store PK | Authorization | | |<-----------------------------------------------| Server (AS) | +------+ | | | | | | (3) Interactive Authz Request (via Client) | | +--------------------------------------------------->| | | | | | (4) Explicit Consent for Refresh Token (RT) | | |<---------------------------------------------------| | | | | | (5) Issue Refresh Token (RT) | | | +------------------------------------------------| | | | +---------------+ v v +----------+ +---------------+ | | (6) Delegate Intent (e.g., via VC) | | | Client |<-------------------------------------------| RO | | (Agent) | (Signed with Private Key) | | +----------+ +---------------+ ]]> Public Key Registration: The RO registers their public key (PK) with the AS. Storage: The AS stores the PK and binds it to the RO's identity. Authorization Request: The Client initiates an interactive OAuth 2.0 flow. Consent: The AS authenticates the RO and obtains consent for a Refresh Token (RT). Token Issuance: The AS issues an RT to the Client. Intent Delegation: The RO provides the Client with signed evidence (e.g., a VC) out-of-band.

3.2. Phase 2: Autonomous Execution The Client uses the Refresh Token to request an Access Token containing the RO's certificate.

| | | Client | | Authorization | | (Agent) | (B) Access Token (includes AS-signed Cert) | Server (AS) | | |<---------------------------------------------------| | +----------+ +---------------+ | | (C) API Request + AT + RO-signed VC v +----------+ (D) [Optional] Introspect AT +---------------+ | Resource |--------------------------------------------------->| Authorization | | Server | (E) Return Certificate Data | Server (AS) | | (RS) |<---------------------------------------------------| | | | +---------------+ | |-- (F) Extract Cert & Verify AS Signature | |-- (G) Verify VC Signature using User PK from Cert | |-- (H) Execute Authorized Operation +----------+ ]]> (A) Token Request: The Client calls the AS /token endpoint with grant_type=refresh_token and RAR authorization_details. (B) AT Issuance: The AS validates the RT and issues an Access Token (AT) containing the RO's certificate. (C) Resource Request: The Client presents the AT and the RO-signed VC to the RS. (D-E) Introspection: The RS may retrieve certificate data via introspection if the AT is opaque. (F-G) Verification: The RS verifies the certificate and then uses the RO's PK to verify the VC.

4. Authorization Details Type This section defines the new RAR authorization_details type urn:ietf:params:oauth:as-attested-user-cert. This type enables the Client to explicitly request the RO's public key attestation.

4.1. The authorization_details Object The following fields are defined for this RAR type: type (REQUIRED): MUST be set to urn:ietf:params:oauth:as-attested-user-cert. cert_format (OPTIONAL): A string indicating the preferred format for the attestation. Supported values include x509 (for [RFC5280] certificates) and jwk (for [RFC7517] JSON Web Keys). If omitted, the AS MAY return a format based on its local policy. intended_rs (OPTIONAL): An array of strings containing the identifiers (e.g., URIs) of the Resource Servers. This allows the AS to restrict the audience of the issued certificate.

4.2. Example Token Request ```http POST /token HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded grant_type=refresh_token &refresh_token=tGzv3JOkF0XG5Qx2TlKWIA &client_id=ai-agent-client-123 &authorization_details=[ { "type": "urn:ietf:params:oauth:as-attested-user-cert", "cert_format": "x509", "intended_rs": ["https://rs.example.com/api/v1"] } ] ```

5. Authorization Server Processing When the AS receives a token request with the urn:ietf:params:oauth:as-attested-user-cert type, it MUST perform the following processing steps: Grant Validation: Validate the refresh_token or other provided grant according to . RO Identification: Identify the RO associated with the authenticated session or grant. Public Key Retrieval: Retrieve the RO's registered public key from the AS's secure storage. If no public key is registered for this RO, the AS MUST return an invalid_request error. Certificate Generation: Generate a digital attestation (e.g., an X.509 certificate) that binds the RO's identity (the sub value) to the retrieved public key. The AS MUST sign this attestation using its own private key. Issuance: Include the attestation data in the authorization_details claim of the issued Access Token.

6. Access Token and Introspection The AS MUST provide the RO's certificate data to the RS, either by embedding it directly in a structured token (e.g., JWT) or by returning it via an introspection response.

6.1. JWT Access Token Payload For JWT-formatted Access Tokens [RFC9068], the AS MUST include the certificate in the authorization_details array:

..." } ] } ]]>

6.2. Token Introspection Response If the Access Token is opaque, the RS MUST use Token Introspection . The AS response MUST include the same authorization_details object as defined above:

7. Resource Server Processing The RS MUST follow these steps to verify the AI Agent's request: AT Validation: Validate the Access Token (signature, expiration, and audience). Certificate Extraction: Extract the certificate_data from the authorization_details claim. AS Signature Verification: Verify the AS's signature on the certificate using the AS's well-known public key. This confirms that the RO's public key has not been tampered with. Application Evidence Verification: Extract the RO's public key from the verified certificate and use it to verify the signature of the application-layer evidence (e.g., the VP/VC provided by the AI Agent). Execution: Proceed with the requested operation only if all cryptographic signatures are valid.

8. Security Considerations

8.1. Integrity and Authenticity of the Resource Owner's Public Key The AS-attested certificate is the primary defense against key substitution attacks. The RS MUST NOT use any RO public key that is not accompanied by a valid AS signature. Any discrepancy in the AS signature MUST result in the immediate rejection of the request.

8.2. Proof-of-Possession (PoP) To prevent token/credential leakage risks, it is RECOMMENDED that the Client's request to the RS be protected by a Proof-of-Possession mechanism (e.g., DPoP or mTLS), ensuring the AT and the RO-signed evidence are bound to the current Client.

8.3. Validation of Delegated Intent Boundaries The RS MUST strictly parse and validate the claims within the presented VP to ensure the requested action falls within the explicit boundaries signed by the RO.

9. IANA Considerations

9.1. OAuth Authorization Details Types Registry This document requests the registration of the following type in the "OAuth Authorization Details Types" registry: Type Value Description Change Controller Reference urn:ietf:params:oauth:as-attested-user-cert Request an AS-attested RO public key certificate IETF [[This Document]]