Web Authorization Protocol                                  P. KasselmanInternet-Draft                                               I. KazzouziIntended status: Informational                                     SPIRLExpires: 26 December 2025                                   24 June 2025 OAuth 2.0 Dynamic Client Registration with Trusted Issuer Credentials           draft-kasselman-oauth-dcr-trusted-issuer-token-01Abstract   An OAuth 2.0 client requires specific information to interact with an   authorization server, including a client identifier registered with   the authorization server.  The OAuth 2.0 Dynamic Client Registration   Protocol [RFC7591] defines a mechansim for dynamic client   registration that removes the need for manual registration.  This   provides a more scalable mechanism that can be used by clients that   do not have a pre-existing relationship with an authorization server,   or where manually configuring such relationships is prohibitive from   a cost and scale perspective.  Examples of deployments that benefit   from dynamic client registration includes modern cloud architectures   where microservices are created on demand to meet scale requirements   or for use with emerging protocols like the Model Context Protocol   (MCP) [MCP] which requires clients to register with an authorization   server even if they do not have a predefined relationship with the   authorization server.  Similar to modern cloud native workloads, MCP   service integrations may be ephemeral in nature.  The OAuth 2.0   Dynamic Client Registration Protocol [RFC7591] defines a software   statement that includes metadata about the client and is signed by a   developer or trusted third party.  This specification describes the   use of specific third party credentials issued to workloads and   applications as software statements.  The specification describes two   types of credentials that may be used as software statements.  The   first is Secure Production Identity Framework For Everyone (SPIFFE)   credentials.  The second is the use of JWT representation of a   Verifiable Credentials [VC-JWT]About This Document   This note is to be removed before publishing as an RFC.   The latest revision of this draft can be found at   https://PieterKas.github.io/OAuth-2.0-DCR-with-Trusted-Issuer-   Credentials/draft-kasselman-oauth-dcr-trusted-issuer-token.html.   Status information for this document may be found at   https://datatracker.ietf.org/doc/draft-kasselman-oauth-dcr-trusted-   issuer-token/.Kasselman & Kazzouzi    Expires 26 December 2025                [Page 1]Internet-Draft     DCR with Trusted Issuer Credentials         June 2025   Discussion of this document takes place on the Web Authorization   Protocol Working Group mailing list (mailto:oauth@ietf.org), which is   archived at https://mailarchive.ietf.org/arch/browse/oauth/.   Subscribe at https://www.ietf.org/mailman/listinfo/oauth/.   Source for this draft and an issue tracker can be found at   https://github.com/PieterKas/OAuth-2.0-DCR-with-Trusted-Issuer-   Credentials.Status of This Memo   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 26 December 2025.Copyright Notice   Copyright (c) 2025 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.Table of Contents   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4     3.1.  SPIFFE Credentials as Software Statements . . . . . . . .   4     3.2.  Verifiable Credentials as Software Statements . . . . . .   5     3.3.  SPIFFE and VC Deployment Models . . . . . . . . . . . . .   5Kasselman & Kazzouzi    Expires 26 December 2025                [Page 2]Internet-Draft     DCR with Trusted Issuer Credentials         June 2025     3.4.  Protocol Flow . . . . . . . . . . . . . . . . . . . . . .   5   4.  Issuer and Client Registration Endpoint Trust Relationship  .   7     4.1.  SPIFFE Issuer and Client Registration Endpoint Trust           Relationship  . . . . . . . . . . . . . . . . . . . . . .   7     4.2.  Verifiable Credentials and Client Registration Endpoint           Trust Relationship  . . . . . . . . . . . . . . . . . . .   7   5.  Client Registration Endpoint Processing . . . . . . . . . . .   7     5.1.  SPIFFE JWT-SVIDs Processing by Client Registration           Endpoint  . . . . . . . . . . . . . . . . . . . . . . . .   8     5.2.  VCs Processing by Client Registration Endpoint  . . . . .   8   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9     6.1.  Client Secrets  . . . . . . . . . . . . . . . . . . . . .   9   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   9   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  10   Appendix B.  Document History . . . . . . . . . . . . . . . . . .  10   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  111.  Introduction   The OAuth framework [RFC6749] is a widely deployed authorization   protocol standard that enables applications to obtain limited access   to user resources.  OAuth clients must be registered with the OAuth   authorization server, which poses significant operational challenges   in dynamically scaling environments.  Manual registration and   subsequent lifecycle management is common, but is costly, difficult   to scale and hard to maintain throughout the lifecycle of a client.   These challenges are exacerbated by the increasingly dynamic nature   of modern cloud native workloads that are instantiated as needed.  In   addition, emerging protocols like Model Context Protocol (MCP) [MCP]   requires clients to register with an authorization server, but these   clients may not always have a predefined relationship with the   authorization server, and similar to modern cloud native workloads,   may be ephemeral in nature.   [RFC7591] defines a mechansim for dynamic client registration that   removes the need for manual registration.  This provides a more   scalable mechanism that can be used by clients that do not have a   pre-existing relationship with an authorization server, or where   manually configuring such relationships is prohibitive from a cost   and scale perspective.  It defines the concept of a software   statement, which is a JSON Web Token (JWT) [RFC7519] that asserts   metadata values about the client that is signed by a developer or   trusted third party.Kasselman & Kazzouzi    Expires 26 December 2025                [Page 3]Internet-Draft     DCR with Trusted Issuer Credentials         June 2025   This specification describes the use of SPIFFE JWT-SVIDs and   Verifiable Credentials as software statements that can be submitted   as software statements when using OAuth 2.0 Dynamic Client   Registration Protocol [RFC7591].2.  Conventions and Definitions   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] when, and only when, they appear in all   capitals, as shown here.3.  Overview   This specification describes the use of two credential types as   software statements, namely Secure Production Identity Framework For   Everyone (SPIFFE) credentials and Verifiable Credentials (VC).3.1.  SPIFFE Credentials as Software Statements   The Secure Production Identity Framework For Everyone (SPIFFE) is a   graduated Cloud Native Compute Foundation project designed to   dynamically attest and verify workload identity (see [SPIFFE].   SPIFFE is commonly deployed to support large scale deployment of   workloads in enterprise and cloud native compute environments.  It   ensures that every workload is attested and issued with X.509-SVID   [SPIFFE_X509] and JWT-SVID [SPIFFE_JWT] credentials.  JWT-SVIDs   contain a minimal set of claims, but may be extended to include   additional claims, including those defined in the Dynamic Client   Registration specification (see Section 2 of [RFC7591]).  A SPIFFE   issuer may attest a workload, add additional metadata based on the   attestation information and issue a JWT-SVID.  Workloads that are   provisioned with JWT-SVIDs present these credentials as software   statements when using Dynamic Client Registration.  The registration   endpoint is configured to trust the SPIFFE issuer and can verify the   JWT-SVID, as well as retrieve additional claims that represents   metadata attested to by the SPIFFE issuer.  Upon succesful validation   of the software statement, the registration endpoint completes the   client registration.  When SPIFFE JWT-SVIDs are used, the   authorization server MUST NOT provision additional client secrets, as   the workload can use its JWT-SVID or X.509 SVID to authenticate when   initiating any OAuth flow.  This removes the risk of additional   secrets proliferation, reduces the overheads of securing and managing   secrets and improves the overall risk posture.Kasselman & Kazzouzi    Expires 26 December 2025                [Page 4]Internet-Draft     DCR with Trusted Issuer Credentials         June 20253.2.  Verifiable Credentials as Software Statements   A Verifiable Credential (VC) is a tamper-evident digital assertion   made by an issuer about a subject, which can be cryptographically   verified by a third party.  VCs follow an issuer–holder–verifier   model where the issuer creates and signs the credential, the holder   stores and presents it, and the verifier checks its authenticity and   validity.  VCs can be represented as a JSON Web Token (JWT) [VC-JWT].   A VC encoded as a JWT can serve as a software statement in dynamic   client registration by including metadata as defined in Section 2 of   [RFC7591] about the client as additional claims in the VC.  Workloads   that are provisioned with VCs present these credentials as software   statements when using Dynamic Client Registration.  The registration   endpoint is configured to trust the VC issuer and can verify the VC   and use the additional metadata claims included by the issuer.  Upon   succesful validation of the software statement, the registration   endpoint completes the client registration.  The use of Verifiable   Credentials for client authentication is currently undefined and it   is up to the authorization server to make a risk based decision on   which authentication methods to use.3.3.  SPIFFE and VC Deployment Models   SPIFFE and VC address different deployment models.  SPIFFE is more   commonly deployed within large enterprise compute environments and   provides high levels of assurance about a workload identity (in this   case an OAuth client) along with a highly robust, low latency   provisioning pipeline with built in credential lifecycle management   to maximise availability.  It is commonly deployed as an alternative   to managing secrets.   VCs provide an option for clients that are deployed outside an   enterprise where SPIFFE is not deployed.  These clients use VC   issuance protocols to obtain VCs.  The use of these protocols or any   attestation that needs to be provided is out of scope for this   specification.3.4.  Protocol FlowKasselman & Kazzouzi    Expires 26 December 2025                [Page 5]Internet-Draft     DCR with Trusted Issuer Credentials         June 2025   +-------------+ (A) Client Registration Endpoint Establishes   |   SPIFFE    |     Trust with SPIFFE or VC Issuer   |     or      |   |     VC      |   |   Issuer    |<------------------------------------------+   +-------------+                                           |          ^                                                  |          |                                                  |          |                                                  |         (B) SPIFFE JWT-SVID or VC provisioned to client     |          |                                                  |          v                                                  V   +-----------+                                      +---------------+   | Client or |--(C)- Client Registration Request -->|    Client     |   | Developer |       with SPIFFE JWT-SVID or VC     |  Registration |   |           |         as software statement        |    Endpoint   |   |           |                                      |               |   |           |<-(D)- Client Information Response ---|               |   |           |        or Client Error Response      +---------------+   +-----------+   Figure 1: Abstracted Dynamic Client Registration Flow with Software   Statement   The OAuth 2.0 Client Dynamic Registration flow illustrated in   Figure 1 describes the interaction between the SPIFFE or VC issuers,   the client and the client registration endpoint defined in [RFC7591].   It includes the following steps:   *  (A) The client registration endpoint establishes a trust      relationship with the SPIFFE or VC Issuer.  Once trust is      established, the client registration endpoint can verify      credentials issued by the SPIFFE or VC Issuer when presented as      software statements.   *  (B) The client is attested and credentialed by the SPIFFE Issuer      [SPIFFE], after which it assigns a SPIFFE ID [SPIFFE_ID], along      with SPIFFE credentials (e.g. JWT-SVID [SPIFFE_JWT] and X.509-SVID      [SPIFFE_X509]).  Alternatively a VC issuer issues and provisions a      VC.  Issuers may include additional claims containing metadata      (e.g the request URI).   *  (C) The client calls the client registration endpoint with the      client's desired registration metadata, and the software statement      (either a SPIFFE JWT-SVID or a VC).Kasselman & Kazzouzi    Expires 26 December 2025                [Page 6]Internet-Draft     DCR with Trusted Issuer Credentials         June 2025   *  (D) The client registration endpoint verifies the SPIFFE JWT-SVID      or VC that was presented as a software statement.  It extracts any      additional claims that should be used as metadata before      registering the client.  It may return additional metadata, client      identifiers and optionally credentials if a VC is used.  Clients      with SPIFFE credentials MUST use the SPIFFE credentials when      authenticating as part of an OAuth flow.4.  Issuer and Client Registration Endpoint Trust Relationship4.1.  SPIFFE Issuer and Client Registration Endpoint Trust Relationship   SPIFFE makes provision for multiple Trust Domains, which are   represented in the workload identifier.  Trust Domains offers   additional segmentation within a SPIFFE deployment and each Trust   Domain has its own keys for signing credentials.  The OAuth   authorization server may choose to trust one or more trust domains as   defined in [SPIFFE-OAUTH-CLIENT-AUTH].4.2.  Verifiable Credentials and Client Registration Endpoint Trust      Relationship   To validate Verifiable Credentials (VCs) during dynamic client   registration, the client registration endpoint MUST be configured to   trust the VC issuer’s public keys or a certificate chain anchored in   a trusted root.  This trust may be established statically or through   a dynamic trust discovery mechanism.  The registration endpoint   SHOULD periodically refresh or revalidate the issuer’s key material   against a trusted source to ensure ongoing integrity.  When a client   presents a VC, the registration endpoint verifies its signature using   the trusted key material.  It MAY also perform additional validation   steps, such as checking the issuer’s identity, validating the   credential’s expiration, and evaluating its revocation status using   mechanisms such as decentralized revocation registries or issuer-   specific status endpoints.5.  Client Registration Endpoint Processing   The client registration endpoint MUST process software statements   (e.g., SPIFFE JWT-SVIDs or Verifiable Credentials) as follows: 1.   Verify Authenticity and Integrity: Validate the software statement's   signature using a trusted issuer key (e.g., SPIFFE Trust Bundle or VC   issuer metadata). 2.  Validate Credential Expiry: Check that the   credential is not expired and is within its valid time window. 3.   Evaluate Revocation Status (if applicable): Optionally verify   revocation status via decentralized registries or issuer-specific   status endpoints (for VCs). 4.  Extract and Validate Metadata Claims:   Parse the credential and validate required claims needed for OAuthKasselman & Kazzouzi    Expires 26 December 2025                [Page 7]Internet-Draft     DCR with Trusted Issuer Credentials         June 2025   client registration (e.g., client_name, redirect_uris, grant_types).   5.  Register the Client: If all validations succeed, proceed with   client registration using the verified metadata. 6.  Return Response:   Send an appropriate OAuth client registration response.5.1.  SPIFFE JWT-SVIDs Processing by Client Registration Endpoint   When a client presents a SPIFFE JWT-SVID as a software statement, the   client registration endpoint MUST:   1.  Verify the Signature: Validate the JWT signature using the       trusted key material from the SPIFFE Trust Bundle corresponding       to the issuer’s trust domain.   2.  Validate Standard Claims: Ensure that the JWT includes and       satisfies the following claims:       *  iss: Must match the expected SPIFFE trust domain.       *  sub: Must be a valid SPIFFE ID URI identifying the client.       *  aud: Must include the registration endpoint’s audience value.       *  exp and iat: Must be present and within acceptable bounds.   3.  Extract and Validate Metadata Claims: Parse and validate any       additional claims used to supply OAuth client metadata (e.g.,       client_name, redirect_uris, scope).   4.  Reject Invalid Credentials: Reject the registration if the JWT is       expired, not correctly signed, or missing required claims.   5.  Register the Client (if all checks succeed): Upon successful       validation, register the client using the extracted metadata and       return a client identifier.  The server MUST NOT issue a client       secret, as the SPIFFE credential is used for subsequent       authentication.5.2.  VCs Processing by Client Registration Endpoint   When a client presents a Verifiable Credential (VC) as a software   statement, the client registration endpoint MUST: 1.  Verify the   Credential Signature: Validate the cryptographic signature of the VC   using the issuer’s trusted public key or certificate chain. 2.  Check   Credential Validity: Ensure the VC has not expired and is not   revoked, using appropriate status mechanisms such as decentralized   revocation registries or issuer-hosted status endpoints. 3.  Extract   and Validate Metadata Claims: Extract required client metadata claimsKasselman & Kazzouzi    Expires 26 December 2025                [Page 8]Internet-Draft     DCR with Trusted Issuer Credentials         June 2025   (e.g., client_name, redirect_uris, scope) embedded in the VC, and   validate their presence and format according to the authorization   server’s policy. 4.  Reject Invalid Credentials: Reject the   registration request if the VC fails any verification step, is   malformed, or lacks required claims.   Optionally, upon successful validation, the registration endpoint MAY   provision additional credentials but SHOULD avoid provisioning   traditional client secrets to minimize risk.6.  Security Considerations6.1.  Client Secrets   Dynamic client registration is designed to increase the ease with   which clients are registered in large scale deployments.  The   increased use of client secrets amplifies the risks of secret theft   and information compromise.  This risk is further amplified if those   secrets are long lived or infrequently rotated.  Clients that are   provisioned with SPIFFE JWT-SVIDs or X.509-SVIDs, and use this   specification MUST use them not only as software statements, but also   when authenticating to the authorization server in subsequent OAuth   flows.   The use of VCs as client authentication mechansims in OAuth is   undefine.  Consequently, when using VCs as software statements, the   authorization server MAY provision additional credentials, but SHOULD   avoid provisioning client secrets to limit the risks of secret   proliferation and the consequences of secret theft.7.  IANA Considerations   This document has no IANA actions.8.  Normative References   [MCP]      "Model Context Protocol", n.d..   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels", BCP 14, RFC 2119,              DOI 10.17487/RFC2119, March 1997,              <https://www.rfc-editor.org/rfc/rfc2119>.   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",              RFC 6749, DOI 10.17487/RFC6749, October 2012,              <https://www.rfc-editor.org/rfc/rfc6749>.Kasselman & Kazzouzi    Expires 26 December 2025                [Page 9]Internet-Draft     DCR with Trusted Issuer Credentials         June 2025   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,              <https://www.rfc-editor.org/rfc/rfc7519>.   [RFC7591]  Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and              P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",              RFC 7591, DOI 10.17487/RFC7591, July 2015,              <https://www.rfc-editor.org/rfc/rfc7591>.   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.   [SPIFFE]   "SPIFFE", n.d.,              <https://github.com/spiffe/spiffe/blob/main/standards/              SPIFFE.md>.   [SPIFFE-OAUTH-CLIENT-AUTH]              "OAuth SPIFFE Client Authentication", n.d., <foo>.   [SPIFFE_ID]              "SPIFFE-ID", n.d.,              <https://github.com/spiffe/spiffe/blob/main/standards/              SPIFFE-ID.md>.   [SPIFFE_JWT]              "JWT-SVID", n.d.,              <https://github.com/spiffe/spiffe/blob/main/standards/JWT-              SVID.md>.   [SPIFFE_X509]              "X509-SVID", n.d.,              <https://github.com/spiffe/spiffe/blob/main/standards/              X509-SVID.md>.   [VC-JWT]   Zundel, B., Steele, O., and K. Yasuda, "Securing              Verifiable Credentials using JSON Web Tokens", 14 June              2023, <https://www.w3.org/TR/vc-jwt/>.Appendix A.  Acknowledgments   TODO acknowledge.Appendix B.  Document History   [[ To be removed from the final specification ]] -latest * Editorial   updates * Corrected markup to show all authorsKasselman & Kazzouzi    Expires 26 December 2025               [Page 10]Internet-Draft     DCR with Trusted Issuer Credentials         June 2025   -00 * Initial draft submitted to DatatrackerAuthors' Addresses   Pieter Kasselman   SPIRL   Email: pieter@spirl.com   Ismael Kazzouzi   SPIRL   Email: ismael@spirl.comKasselman & Kazzouzi    Expires 26 December 2025               [Page 11]