| Internet-Draft | OAuth RAR for User Certs | March 2026 |
| Chu, et al. | Expires 3 September 2026 | [Page] |
This document defines an extension to the OAuth 2.0 Rich Authorization Requests (RAR) framework. It introduces a mechanism that allows a Client, such as an autonomous AI Agent, to request an Authorization Server (AS) to include an AS-attested Resource Owner public key certificate within, or bound to, an Access Token.¶
This mechanism enables the Resource Server (RS) to securely obtain the Resource Owner's trusted public key, which can then be used to verify application-layer delegation evidence (e.g., Verifiable Credentials) signed by the Resource Owner.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 September 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
With the rise of autonomous AI Agents acting on behalf of users, traditional OAuth 2.0 [RFC6749] 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) [RFC9396]. 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.¶
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 [RFC8174].¶
The protocol consists of two phases: Initial Bootstrapping and Autonomous Execution.¶
The RO registers their public key and authorizes the Client to act on their behalf.¶
+------+ (1) Register Public Key (PK) +---------------+ | |----------------------------------------------->| | | 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.¶
The Client uses the Refresh Token to request an Access Token containing the RO's certificate.¶
+----------+ (A) Token Request (Refresh Token + RAR) +---------------+
| |--------------------------------------------------->| |
| 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.¶
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.¶
For JWT-formatted Access Tokens [RFC9068], the AS MUST include the certificate in the authorization_details array:¶
{
"iss": "[https://as.example.com](https://as.example.com)",
"sub": "user_12345",
"aud": "[https://rs.example.com/api/v1](https://rs.example.com/api/v1)",
"exp": 1718293600,
"authorization_details": [
{
"type": "urn:ietf:params:oauth:as-attested-user-cert",
"certificate_data": "MIIDdzCCAl+gAwIBAgIE...<Base64_Encoded_Cert>..."
}
]
}
¶
If the Access Token is opaque, the RS MUST use Token Introspection [RFC7662]. The AS response MUST include the same authorization_details object as defined above:¶
{
"active": true,
"scope": "read write",
"authorization_details": [
{
"type": "urn:ietf:params:oauth:as-attested-user-cert",
"certificate_data": "MIIDdzCCAl+gAwIBAgIE..."
}
]
}
¶
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.¶
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.¶
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.¶
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.¶