@techreport{kasselman-oauth-dcr-trusted-issuer-token-01,
    number =    {draft-kasselman-oauth-dcr-trusted-issuer-token-01},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-kasselman-oauth-dcr-trusted-issuer-token/01/},
    author =    {Pieter Kasselman and Ismael},
    title =     {{OAuth 2.0 Dynamic Client Registration with Trusted Issuer Credentials}},
    pagetotal = 11,
    year =      2025,
    month =     jun,
    day =       24,
    abstract =  {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{]}},
}