Adoption records

OAuth 2.1 and its profiles

Version pinned

Versions and statuses were read from the RFC Editor's metadata and the IETF datatracker on 4 October 2026; the texts of RFC 7523, RFC 9700, OpenID Connect Core 1.0 and both Internet-Drafts, with the earlier revisions the MCP record compares, were read from those sources on 8 October 2026. The two Internet-Drafts are moving targets; a later revision is taken only through a change entry.

What is taken

• Authorisation code with PKCE S256 only, exact redirect matching with the RFC 8252 loopback exception, single-use codes and rotating refresh tokens, with a reused code or refresh token ending the grant, as RFC 9700 sections 4.2.4 and 4.14 recommend (A6.3).
• RFC 9728 protected-resource metadata, one path-specific document for each protected resource, RFC 8414 server metadata with RFC 9728's protected_resources, and the RFC 9207 iss parameter (A6.1).
• Client ID Metadata Documents as the primary registration for unknown clients, static registration for first-party clients and RFC 7591 for any client, with client metadata limited to the members A6.1 lists (A6.1).
• private_key_jwt client authentication, which OpenID Connect Core 1.0 section 9 defines on RFC 7523 section 2.2, with the client's inline ES256 keys (A6.1).
• RFC 8707 resource to name the one audience of a grant, and RFC 9126 pushed authorisation requests, with RFC 9101's invalid_request_uri for a pushed request that cannot be used (A6.2, A6.3, B1.9).
• RFC 9396 authorization_details as the envelope for structured requests, which is also PDPP Core v0.1.0's envelope (see the PDPP record, pinned at commit 8f79a48), and for the contribution request (A6.2).
• RFC 9449 DPoP for every access token, RFC 9068 for access token claims, RFC 7009 for refresh-token revocation and RFC 8693 token exchange for delegated grant offers (A6.3 to A6.5).
• RFC 6750's invalid_token error code for a refused token, not its Bearer scheme (A6.3).
• RFC 7662's response shape for the introspection result a provider projects for the PDPP binding (B1.6); no public introspection endpoint is required.
• The error codes these documents define, kept in their own error form on OAuth endpoints and listed in the error registry.

Why

These are the primitives recipients and assistants already implement, with maintained libraries, so Open Personal Context profiles them rather than defining its own authorisation protocol.

What is extended

• The authorization_details content is profiled for domains and disclosure levels through the PDPP binding (B1), and for contribution grants by the type urn:autonym:authorization-details:contribute (A6.2).
• RFC 7591 client metadata gains autonym_purge_uri, where purge instructions are delivered (A6.1).
• The access token gains autonym_grant_id and autonym_purpose (A6.3).
• The grant-offer exchange in A6.4 uses RFC 8693 with an Open Personal Context token type, urn:autonym:params:oauth:token-type:grant-offer. A6.4 states that this is an Open Personal Context choice, not something RFC 8693 defines.
• The client lifecycle token in A6.6 is an Open Personal Context profile of the client credentials grant.
• A grant offer's recipient is a confidential client that authenticates with private_key_jwt, so holding an offer is never enough to redeem it (A6.1, A6.4).
• RFC 7009 asks a public client for no credential at the revocation endpoint. A public client's refresh token is bound to its DPoP key (RFC 9449 section 5), so its revocation also carries a DPoP proof by that key, and a refresh token bound to another key is not revoked (A6.5).

What is replaced or not used

• The implicit grant and the resource owner password grant are not used; OAuth 2.1 removes them.
• PKCE plain is rejected (A6.3).
• Bearer tokens are neither issued nor accepted for any client: every access token is DPoP-bound (A6.3).
• Client secrets, client_secret_basic, client_secret_post and client_secret_jwt are not used; a confidential client authenticates with private_key_jwt (A6.1).
• jwks_uri, sector_identifier_uri and software statements are not accepted in client metadata (A6.1).
• OpenID Connect's application_type client metadata member is not accepted: whether the RFC 8252 loopback-port exception applies is decided from the client's redirect URIs, and only a client whose redirect URIs are all http loopback URIs uses it (A6.1, A6.3).
• A public RFC 7662 introspection endpoint is not required: a provider's resource servers introspect locally (B1.6).
• OpenID Connect sign-in is not used: no ID token, openid scope or userinfo endpoint. A provider's authorisation-server metadata may still carry OpenID Connect's subject_types_supported; it describes the provider's own internal subject identifier, never the pairwise handle every access token carries as sub (A3.2, A6.3).

Deviations

• OAuth 2.1 is still an Internet-Draft. Open Personal Context cites revision 16 and the RFCs it consolidates, and does not claim conformance to an unpublished RFC.
• RFC 9068 section 2.1 requires an authorisation server to support RS256 for access tokens. Open Personal Context signs and accepts access tokens with ES256 only (A6.3), as the JOSE record does for signed objects; no client has to verify one.
• RFC 7591 section 2 has an authorisation server ignore client metadata it does not understand. Open Personal Context refuses a registration or a metadata document with any member A6.1 does not list, so a client is never registered with part of what it asked for silently dropped. It also refuses a software statement, which RFC 7591 lets a server ignore, because a provider trusts no statement issuer.
• RFC 7591 section 2 defaults token_endpoint_auth_method to client_secret_basic. Open Personal Context accepts no client secret, so registration metadata always states the method.
• Mandatory DPoP departs from the Bearer usage MCP specifies for its clients; see the MCP record.

Conformance checks

CORE-01, CONSENT-01, OAUTH-01, FETCH-01, DELEGATE-01, TRANSPORT-01 and the SCOPE family in the conformance manifest, with runtime evidence pending.

References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.