{
  "version": 1,
  "generatedAt": "2026-10-14T13:29:39.528Z",
  "license": "CC BY 4.0",
  "source": "https://letsauth.eu/atlas/standards/",
  "specs": [
    {
      "id": "rfc6749",
      "name": "The OAuth 2.0 Authorization Framework",
      "body": "ietf-oauth",
      "family": "protocol",
      "maturity": "published",
      "maturityNote": "Proposed Standard; updated by RFC 8252, RFC 8996 and RFC 9700",
      "summary": "Lets a third-party application obtain limited, delegated access to an HTTP resource on behalf of a resource owner, by way of an authorization server that issues access tokens.\n",
      "url": "https://datatracker.ietf.org/doc/rfc6749/",
      "revisions": [
        {
          "id": "rfc",
          "date": "2012-10-13",
          "status": "current",
          "url": "https://www.rfc-editor.org/rfc/rfc6749"
        }
      ]
    },
    {
      "id": "rfc7523",
      "name": "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants",
      "body": "ietf-oauth",
      "family": "protocol",
      "maturity": "published",
      "maturityNote": "Proposed Standard",
      "summary": "Lets a JWT serve as an authorization grant at the token endpoint, or as the client's credential, so an assertion from a trusted issuer can be exchanged for an access token.\n",
      "url": "https://datatracker.ietf.org/doc/rfc7523/",
      "revisions": [
        {
          "id": "rfc",
          "date": "2015-05-19",
          "status": "current",
          "url": "https://www.rfc-editor.org/rfc/rfc7523"
        }
      ]
    },
    {
      "id": "rfc7591",
      "name": "OAuth 2.0 Dynamic Client Registration Protocol",
      "body": "ietf-oauth",
      "family": "protocol",
      "maturity": "published",
      "maturityNote": "Proposed Standard",
      "summary": "Lets a client register itself with an authorization server at run time through an HTTP API and receive a client identifier, instead of being registered by hand.\n",
      "url": "https://datatracker.ietf.org/doc/rfc7591/",
      "revisions": [
        {
          "id": "rfc",
          "date": "2015-07-09",
          "status": "current",
          "url": "https://www.rfc-editor.org/rfc/rfc7591"
        }
      ]
    },
    {
      "id": "rfc7636",
      "name": "Proof Key for Code Exchange by OAuth Public Clients (PKCE)",
      "body": "ietf-oauth",
      "family": "protocol",
      "maturity": "published",
      "maturityNote": "Proposed Standard",
      "summary": "Binds an authorization code to the client that requested it with a one-time verifier, so an intercepted code cannot be redeemed by someone else.\n",
      "url": "https://datatracker.ietf.org/doc/rfc7636/",
      "revisions": [
        {
          "id": "rfc",
          "date": "2015-09-16",
          "status": "current",
          "url": "https://www.rfc-editor.org/rfc/rfc7636"
        }
      ]
    },
    {
      "id": "rfc8414",
      "name": "OAuth 2.0 Authorization Server Metadata",
      "body": "ietf-oauth",
      "family": "discovery",
      "maturity": "published",
      "maturityNote": "Proposed Standard",
      "summary": "A well-known JSON document in which an authorization server publishes its endpoints and supported capabilities, so clients can configure themselves from the issuer alone.\n",
      "url": "https://datatracker.ietf.org/doc/rfc8414/",
      "revisions": [
        {
          "id": "rfc",
          "date": "2018-06-28",
          "status": "current",
          "url": "https://www.rfc-editor.org/rfc/rfc8414"
        }
      ]
    },
    {
      "id": "rfc8693",
      "name": "OAuth 2.0 Token Exchange",
      "body": "ietf-oauth",
      "family": "protocol",
      "maturity": "published",
      "maturityNote": "Proposed Standard",
      "summary": "Lets a client swap one security token for another at the authorization server, with impersonation and delegation semantics, so a downstream call can carry who is acting for whom.\n",
      "url": "https://datatracker.ietf.org/doc/rfc8693/",
      "revisions": [
        {
          "id": "rfc",
          "date": "2020-01-15",
          "status": "current",
          "url": "https://www.rfc-editor.org/rfc/rfc8693"
        }
      ]
    },
    {
      "id": "rfc8707",
      "name": "Resource Indicators for OAuth 2.0",
      "body": "ietf-oauth",
      "family": "protocol",
      "maturity": "published",
      "maturityNote": "Proposed Standard",
      "summary": "Adds a resource parameter with which a client names the protected resource a token is for, so the authorization server can restrict the token's audience.\n",
      "url": "https://datatracker.ietf.org/doc/rfc8707/",
      "revisions": [
        {
          "id": "rfc",
          "date": "2020-02-28",
          "status": "current",
          "url": "https://www.rfc-editor.org/rfc/rfc8707"
        }
      ]
    },
    {
      "id": "oauth-2-1",
      "name": "The OAuth 2.1 Authorization Framework",
      "body": "ietf-oauth",
      "family": "protocol",
      "maturity": "working-group-draft",
      "maturityNote": "Working group document, intended Standards Track; obsoletes RFC 6749 and RFC 6750 when published",
      "summary": "Consolidates OAuth 2.0 with the security best current practice into one document: PKCE is required, the implicit and password grants are removed, and bearer token usage is folded in.\n",
      "url": "https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/",
      "revisions": [
        {
          "id": "draft-00",
          "date": "2020-07-30",
          "status": "superseded",
          "url": "https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-00.html"
        },
        {
          "id": "draft-13",
          "date": "2025-05-28",
          "status": "superseded",
          "url": "https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-13.html",
          "supersedes": "draft-00",
          "changes": "The revision the MCP Authorization specification cites.\n"
        },
        {
          "id": "draft-16",
          "date": "2026-09-02",
          "status": "current",
          "url": "https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-16.html",
          "supersedes": "draft-13"
        }
      ]
    },
    {
      "id": "rfc9068",
      "name": "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens",
      "body": "ietf-oauth",
      "family": "credential-format",
      "maturity": "published",
      "maturityNote": "Proposed Standard",
      "summary": "An interoperable JWT layout for access tokens, including the audience and scope claims a resource server validates.\n",
      "url": "https://datatracker.ietf.org/doc/rfc9068/",
      "revisions": [
        {
          "id": "rfc",
          "date": "2021-10-21",
          "status": "current",
          "url": "https://www.rfc-editor.org/rfc/rfc9068"
        }
      ]
    },
    {
      "id": "rfc9207",
      "name": "OAuth 2.0 Authorization Server Issuer Identification",
      "body": "ietf-oauth",
      "family": "protocol",
      "maturity": "published",
      "maturityNote": "Proposed Standard",
      "summary": "Adds an iss parameter to the authorization response so a client can tell which authorization server answered and defend against mix-up attacks.\n",
      "url": "https://datatracker.ietf.org/doc/rfc9207/",
      "revisions": [
        {
          "id": "rfc",
          "date": "2022-03-18",
          "status": "current",
          "url": "https://www.rfc-editor.org/rfc/rfc9207"
        }
      ]
    },
    {
      "id": "rfc9396",
      "name": "OAuth 2.0 Rich Authorization Requests",
      "body": "ietf-oauth",
      "family": "protocol",
      "maturity": "published",
      "maturityNote": "Proposed Standard",
      "summary": "Adds an authorization_details parameter for fine-grained, structured authorization data in place of flat scope strings.\n",
      "url": "https://datatracker.ietf.org/doc/rfc9396/",
      "revisions": [
        {
          "id": "rfc",
          "date": "2023-05-30",
          "status": "current",
          "url": "https://www.rfc-editor.org/rfc/rfc9396"
        }
      ]
    },
    {
      "id": "sd-jwt-vc",
      "name": "SD-JWT-based Verifiable Digital Credentials (SD-JWT VC)",
      "body": "ietf-oauth",
      "family": "credential-format",
      "maturity": "candidate",
      "maturityNote": "Submitted to the IESG; IETF Last Call ended 2026-09-15; intended Proposed Standard",
      "summary": "The data format and processing rules for verifiable credentials with JSON payloads built on SD-JWT: issuer, type, status and key binding, as used by the EU Digital Identity Wallet.\n",
      "url": "https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/",
      "revisions": [
        {
          "id": "draft-00",
          "date": "2023-08-16",
          "status": "superseded",
          "url": "https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-00.html"
        },
        {
          "id": "draft-19",
          "date": "2026-08-31",
          "status": "current",
          "url": "https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-19.html",
          "supersedes": "draft-00"
        }
      ]
    },
    {
      "id": "rfc9449",
      "name": "OAuth 2.0 Demonstrating Proof of Possession (DPoP)",
      "body": "ietf-oauth",
      "family": "protocol",
      "maturity": "published",
      "maturityNote": "Proposed Standard",
      "summary": "Sender-constrains access and refresh tokens at the application layer with a per-request proof, so a stolen token cannot be replayed by another party.\n",
      "url": "https://datatracker.ietf.org/doc/rfc9449/",
      "revisions": [
        {
          "id": "rfc",
          "date": "2023-09-07",
          "status": "current",
          "url": "https://www.rfc-editor.org/rfc/rfc9449"
        }
      ]
    },
    {
      "id": "transaction-tokens",
      "name": "Transaction Tokens",
      "body": "ietf-oauth",
      "family": "protocol",
      "maturity": "candidate",
      "maturityNote": "Working group last call completed 2026-08-21; awaiting shepherd write-up for the IESG",
      "summary": "Short-lived tokens that carry the user, the workload and the authorization context of one request through a chain of services inside a trust domain, so each hop can verify what it is acting on.\n",
      "url": "https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/",
      "revisions": [
        {
          "id": "draft-00",
          "date": "2023-11-29",
          "status": "superseded",
          "url": "https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-00.html"
        },
        {
          "id": "draft-11",
          "date": "2026-07-30",
          "status": "current",
          "url": "https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-11.html",
          "supersedes": "draft-00"
        }
      ]
    },
    {
      "id": "id-jag",
      "name": "Identity Assertion JWT Authorization Grant",
      "body": "ietf-oauth",
      "family": "protocol",
      "maturity": "working-group-draft",
      "maturityNote": "Working group document, intended Standards Track; known informally as Cross-App Access",
      "summary": "Lets an application present the identity assertion it got from the enterprise identity provider to obtain, through that provider, an access token for a third-party API, so the enterprise stays in control of which apps may talk to which.\n",
      "url": "https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/",
      "revisions": [
        {
          "id": "draft-parecki-00",
          "date": "2024-03-01",
          "status": "superseded",
          "url": "https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-00.html"
        },
        {
          "id": "draft-parecki-05",
          "date": "2025-07-02",
          "status": "superseded",
          "url": "https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-05.html",
          "supersedes": "draft-parecki-00"
        },
        {
          "id": "draft-00",
          "date": "2025-09-08",
          "status": "superseded",
          "url": "https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-grant-00.html",
          "supersedes": "draft-parecki-05",
          "changes": "Adopted by the OAuth working group; replaces the individual draft.\n"
        },
        {
          "id": "draft-04",
          "date": "2026-05-21",
          "status": "current",
          "url": "https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-grant-04.html",
          "supersedes": "draft-00"
        }
      ]
    },
    {
      "id": "cimd",
      "name": "OAuth Client ID Metadata Document",
      "body": "ietf-oauth",
      "family": "discovery",
      "maturity": "working-group-draft",
      "maturityNote": "Working group document, intended Standards Track",
      "summary": "Lets a client use an HTTPS URL as its client_id; the authorization server fetches the metadata document at that URL instead of requiring prior or dynamic registration.\n",
      "url": "https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/",
      "revisions": [
        {
          "id": "draft-parecki-00",
          "date": "2024-07-02",
          "status": "superseded",
          "url": "https://www.ietf.org/archive/id/draft-parecki-oauth-client-id-metadata-document-00.html"
        },
        {
          "id": "draft-parecki-03",
          "date": "2025-07-22",
          "status": "superseded",
          "url": "https://www.ietf.org/archive/id/draft-parecki-oauth-client-id-metadata-document-03.html",
          "supersedes": "draft-parecki-00"
        },
        {
          "id": "draft-00",
          "date": "2025-10-08",
          "status": "superseded",
          "url": "https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-00.html",
          "supersedes": "draft-parecki-03",
          "changes": "Adopted by the OAuth working group; replaces the individual draft.\n"
        },
        {
          "id": "draft-02",
          "date": "2026-07-06",
          "status": "current",
          "url": "https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-02.html",
          "supersedes": "draft-00"
        }
      ]
    },
    {
      "id": "rfc9700",
      "name": "Best Current Practice for OAuth 2.0 Security",
      "body": "ietf-oauth",
      "family": "guidance",
      "maturity": "published",
      "maturityNote": "Best Current Practice (BCP 240); updates RFC 6749, RFC 6750 and RFC 6819",
      "summary": "The updated threat model and security advice for OAuth 2.0 deployments: audience restriction, PKCE everywhere, no token passthrough, deprecated flows.\n",
      "url": "https://datatracker.ietf.org/doc/rfc9700/",
      "revisions": [
        {
          "id": "rfc",
          "date": "2025-01-30",
          "status": "current",
          "url": "https://www.rfc-editor.org/rfc/rfc9700"
        }
      ]
    },
    {
      "id": "rfc9728",
      "name": "OAuth 2.0 Protected Resource Metadata",
      "body": "ietf-oauth",
      "family": "discovery",
      "maturity": "published",
      "maturityNote": "Proposed Standard",
      "summary": "A well-known JSON document in which a protected resource names the authorization servers it trusts and the scopes it understands, so a client can start from the resource alone.\n",
      "url": "https://datatracker.ietf.org/doc/rfc9728/",
      "revisions": [
        {
          "id": "rfc",
          "date": "2025-04-23",
          "status": "current",
          "url": "https://www.rfc-editor.org/rfc/rfc9728"
        }
      ]
    },
    {
      "id": "sd-jwt",
      "name": "Selective Disclosure for JSON Web Tokens (SD-JWT)",
      "body": "ietf-oauth",
      "family": "credential-format",
      "maturity": "published",
      "maturityNote": "Proposed Standard (RFC 9901)",
      "summary": "A JWT whose individual claims can be withheld or disclosed by the holder at presentation time, with optional key binding, so a credential can be shown without revealing everything in it.\n",
      "url": "https://datatracker.ietf.org/doc/rfc9901/",
      "revisions": [
        {
          "id": "draft-22",
          "date": "2025-05-29",
          "status": "superseded",
          "url": "https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-22.html"
        },
        {
          "id": "rfc",
          "date": "2025-11-19",
          "status": "current",
          "url": "https://www.rfc-editor.org/rfc/rfc9901",
          "supersedes": "draft-22",
          "changes": "Published as RFC 9901.\n"
        }
      ]
    },
    {
      "id": "aauth",
      "name": "AAuth Protocol",
      "body": "ietf-oauth",
      "family": "protocol",
      "maturity": "individual-draft",
      "maturityNote": "Individual Internet-Draft; not adopted by a working group",
      "summary": "An agent-first authorization and identity-claim protocol with several access modes, built on HTTP message signatures and published keys rather than on the OAuth authorization code flow.\n",
      "url": "https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/",
      "revisions": [
        {
          "id": "draft-00",
          "date": "2026-04-29",
          "status": "superseded",
          "url": "https://www.ietf.org/archive/id/draft-hardt-oauth-aauth-protocol-00.html"
        },
        {
          "id": "draft-09",
          "date": "2026-07-04",
          "status": "superseded",
          "url": "https://www.ietf.org/archive/id/draft-hardt-oauth-aauth-protocol-09.html",
          "supersedes": "draft-00"
        },
        {
          "id": "draft-11",
          "date": "2026-09-25",
          "status": "current",
          "url": "https://www.ietf.org/archive/id/draft-hardt-oauth-aauth-protocol-11.html",
          "supersedes": "draft-09"
        }
      ]
    },
    {
      "id": "openid-connect-core",
      "name": "OpenID Connect Core 1.0",
      "body": "openid",
      "family": "protocol",
      "maturity": "published",
      "maturityNote": "Final specification, incorporating errata set 2",
      "summary": "The identity layer on OAuth 2.0: an ID Token that states who authenticated, how and when, plus the flows and claims around it.\n",
      "url": "https://openid.net/specs/openid-connect-core-1_0.html",
      "revisions": [
        {
          "id": "final",
          "date": "2014-11-08",
          "status": "superseded",
          "url": "https://openid.net/specs/openid-connect-core-1_0.html"
        },
        {
          "id": "errata-2",
          "date": "2023-12-15",
          "status": "current",
          "url": "https://openid.net/specs/openid-connect-core-1_0.html",
          "supersedes": "final",
          "changes": "Errata set 2: corrections without protocol changes.\n"
        }
      ]
    },
    {
      "id": "openid-connect-discovery",
      "name": "OpenID Connect Discovery 1.0",
      "body": "openid",
      "family": "discovery",
      "maturity": "published",
      "maturityNote": "Final specification, incorporating errata set 2",
      "summary": "How a client finds an OpenID Provider and reads its configuration from the well-known openid- configuration document.\n",
      "url": "https://openid.net/specs/openid-connect-discovery-1_0.html",
      "revisions": [
        {
          "id": "final",
          "date": "2014-11-08",
          "status": "superseded",
          "url": "https://openid.net/specs/openid-connect-discovery-1_0.html"
        },
        {
          "id": "errata-2",
          "date": "2023-12-15",
          "status": "current",
          "url": "https://openid.net/specs/openid-connect-discovery-1_0.html",
          "supersedes": "final",
          "changes": "Errata set 2: corrections without protocol changes.\n"
        }
      ]
    },
    {
      "id": "openid-federation",
      "name": "OpenID Federation 1.0",
      "body": "openid",
      "family": "protocol",
      "maturity": "published",
      "maturityNote": "Final specification approved 2026-02-17",
      "summary": "Multilateral trust: entities publish signed statements about themselves and each other, and a verifier walks the chain to a trust anchor instead of registering every pair by hand.\n",
      "url": "https://openid.net/specs/openid-federation-1_0.html",
      "revisions": [
        {
          "id": "implementers-draft-4",
          "date": "2024-07-24",
          "status": "superseded",
          "url": "https://openid.net/specs/openid-federation-1_0-ID4.html"
        },
        {
          "id": "final",
          "date": "2026-02-17",
          "status": "current",
          "url": "https://openid.net/specs/openid-federation-1_0-final.html",
          "supersedes": "implementers-draft-4"
        }
      ]
    },
    {
      "id": "openid4vp",
      "name": "OpenID for Verifiable Presentations 1.0",
      "body": "openid",
      "family": "protocol",
      "maturity": "published",
      "maturityNote": "Final specification approved 2025-07-10",
      "summary": "An OAuth-based protocol for a verifier to request credentials from a wallet and for the wallet to present them, independent of credential format.\n",
      "url": "https://openid.net/specs/openid-4-verifiable-presentations-1_0.html",
      "revisions": [
        {
          "id": "implementers-draft-3",
          "date": "2024-12-24",
          "status": "superseded",
          "url": "https://openid.net/specs/openid-4-verifiable-presentations-1_0-ID3.html"
        },
        {
          "id": "final",
          "date": "2025-07-09",
          "status": "current",
          "url": "https://openid.net/specs/openid-4-verifiable-presentations-1_0-final.html",
          "supersedes": "implementers-draft-3"
        }
      ]
    },
    {
      "id": "openid4vci",
      "name": "OpenID for Verifiable Credential Issuance 1.0",
      "body": "openid",
      "family": "protocol",
      "maturity": "published",
      "maturityNote": "Final specification approved 2025-09-16",
      "summary": "An OAuth-protected API through which an issuer hands verifiable credentials to a wallet.\n",
      "url": "https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html",
      "revisions": [
        {
          "id": "final",
          "date": "2025-09-16",
          "status": "current",
          "url": "https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html"
        }
      ]
    },
    {
      "id": "authzen-coaz-mcp",
      "name": "AuthZEN COAZ Binding for the Model Context Protocol",
      "body": "openid",
      "family": "profile",
      "maturity": "working-group-draft",
      "maturityNote": "AuthZEN working group draft 1",
      "summary": "Binds the AuthZEN authorization API to MCP so a policy decision point can be asked whether an agent may call a given tool, separate from the OAuth token that got it in the door.\n",
      "url": "https://github.com/openid/authzen/blob/main/profiles/authzen-coaz-mcp-binding-1_0.md",
      "revisions": [
        {
          "id": "draft-1",
          "date": "2026-07-31",
          "status": "current",
          "url": "https://github.com/openid/authzen/blob/main/profiles/authzen-coaz-mcp-binding-1_0.md"
        }
      ]
    },
    {
      "id": "wimse-arch",
      "name": "Workload Identity in a Multi System Environment (WIMSE) Architecture",
      "body": "ietf-wimse",
      "family": "guidance",
      "maturity": "working-group-draft",
      "maturityNote": "Working group document, intended Informational",
      "summary": "Terminology and architecture for giving workloads an identity across heterogeneous systems: trust domains, workload identifiers, credentials and the agents that issue them.\n",
      "url": "https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/",
      "revisions": [
        {
          "id": "draft-00",
          "date": "2024-04-18",
          "status": "superseded",
          "url": "https://www.ietf.org/archive/id/draft-ietf-wimse-arch-00.html"
        },
        {
          "id": "draft-08",
          "date": "2026-07-06",
          "status": "current",
          "url": "https://www.ietf.org/archive/id/draft-ietf-wimse-arch-08.html",
          "supersedes": "draft-00"
        }
      ]
    },
    {
      "id": "wimse-ai-agent-identity",
      "name": "WIMSE Applicability for AI Agents",
      "body": "ietf-wimse",
      "family": "guidance",
      "maturity": "individual-draft",
      "maturityNote": "Individual Internet-Draft; not adopted by a working group",
      "summary": "How WIMSE could give an AI agent an identity of its own and bind it to the user or organisation that is accountable for it.\n",
      "url": "https://datatracker.ietf.org/doc/draft-ni-wimse-ai-agent-identity/",
      "revisions": [
        {
          "id": "draft-00",
          "date": "2025-10-20",
          "status": "superseded",
          "url": "https://www.ietf.org/archive/id/draft-ni-wimse-ai-agent-identity-00.html"
        },
        {
          "id": "draft-03",
          "date": "2026-09-30",
          "status": "current",
          "url": "https://www.ietf.org/archive/id/draft-ni-wimse-ai-agent-identity-03.html",
          "supersedes": "draft-00"
        }
      ]
    },
    {
      "id": "wimse-aims",
      "name": "AI Identity Management System (AIMS)",
      "body": "ietf-wimse",
      "family": "guidance",
      "maturity": "working-group-draft",
      "maturityNote": "Working group document, intended Informational; adopted 2026-09-09 from draft-klrc-aiagent-auth",
      "summary": "Best practices for authenticating and authorizing AI agents with WIMSE and OAuth 2.0, and the gaps those building blocks leave when an agent acts for a user or for itself.\n",
      "url": "https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/",
      "revisions": [
        {
          "id": "draft-klrc-00",
          "date": "2026-03-02",
          "status": "superseded",
          "url": "https://www.ietf.org/archive/id/draft-klrc-aiagent-auth-00.html"
        },
        {
          "id": "draft-klrc-03",
          "date": "2026-07-06",
          "status": "superseded",
          "url": "https://www.ietf.org/archive/id/draft-klrc-aiagent-auth-03.html",
          "supersedes": "draft-klrc-00"
        },
        {
          "id": "draft-00",
          "date": "2026-09-15",
          "status": "current",
          "url": "https://www.ietf.org/archive/id/draft-ietf-wimse-aims-00.html",
          "supersedes": "draft-klrc-03",
          "changes": "Adopted by the WIMSE working group; replaces draft-klrc-aiagent-auth.\n"
        }
      ]
    },
    {
      "id": "wimse-workload-creds",
      "name": "WIMSE Workload Credentials",
      "body": "ietf-wimse",
      "family": "credential-format",
      "maturity": "working-group-draft",
      "maturityNote": "Working group document; one of the drafts that continue the workload-to-workload work",
      "summary": "The credential formats a WIMSE workload presents: workload identity tokens and the certificates that bind a workload identifier to a key.\n",
      "url": "https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/",
      "revisions": [
        {
          "id": "draft-02",
          "date": "2026-07-02",
          "status": "current",
          "url": "https://www.ietf.org/archive/id/draft-ietf-wimse-workload-creds-02.html"
        }
      ]
    },
    {
      "id": "dawn",
      "name": "Discovery of Agents With Names (DAWN)",
      "body": "ietf-other",
      "family": "discovery",
      "maturity": "individual-draft",
      "maturityNote": "Proposed working group: BoF at IETF 126, charter in external review for the IESG telechat of 2026-10-22; every draft is individual",
      "summary": "DNS-based discovery of the public properties of an AI agent or resource (type, reachability, protocol) beneath protocols such as MCP and A2A; it defines no agent identity.\n",
      "url": "https://datatracker.ietf.org/doc/charter-ietf-dawn/",
      "revisions": [
        {
          "id": "draft-farrel-terminology-03",
          "date": "2026-07-05",
          "status": "current",
          "url": "https://www.ietf.org/archive/id/draft-farrel-dawn-terminology-03.html",
          "changes": "Terminology draft presented at the DAWN BoF; the charter itself is not yet approved.\n"
        }
      ]
    },
    {
      "id": "w3c-vc-data-model-2",
      "name": "Verifiable Credentials Data Model 2.0",
      "body": "other",
      "family": "credential-format",
      "maturity": "published",
      "maturityNote": "W3C Recommendation",
      "summary": "An extensible data model for tamper-evident credentials exchanged between issuers, holders and verifiers, the other credential format the EU wallet framework names next to SD-JWT VC.\n",
      "url": "https://www.w3.org/TR/vc-data-model-2.0/",
      "revisions": [
        {
          "id": "rec",
          "date": "2025-05-15",
          "status": "current",
          "url": "https://www.w3.org/TR/2025/REC-vc-data-model-2.0-20250515/"
        }
      ]
    },
    {
      "id": "mcp-authorization",
      "name": "MCP Authorization",
      "body": "mcp",
      "family": "profile",
      "maturity": "published",
      "maturityNote": "Specification revision 2026-07-28",
      "summary": "The OAuth 2.1 profile that MCP clients and servers follow so that a client can obtain and present access tokens to an MCP server over HTTP transports.\n",
      "url": "https://modelcontextprotocol.io/specification/",
      "revisions": [
        {
          "id": "2025-11-25",
          "date": "2025-11-25",
          "status": "superseded",
          "url": "https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization",
          "changes": "Makes OAuth Client ID Metadata Documents the recommended client registration method and adds Enterprise-Managed Authorization (ID-JAG) as an extension.\n"
        },
        {
          "id": "2026-07-28",
          "date": "2026-07-28",
          "status": "current",
          "url": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization",
          "supersedes": "2025-11-25",
          "changes": "Deprecates Dynamic Client Registration in favour of Client ID Metadata Documents, requires RFC 9207 issuer validation on authorization responses, keys stored client credentials by issuer, requires application_type on DCR requests, and removes session identifiers from the transport. Splits the authorization text into separate pages for discovery, client registration and security considerations.\n"
        }
      ]
    },
    {
      "id": "mcp-enterprise-managed-authorization",
      "name": "MCP Enterprise-Managed Authorization",
      "body": "mcp",
      "family": "profile",
      "maturity": "published",
      "maturityNote": "Extension io.modelcontextprotocol/enterprise-managed-authorization, listed as stable",
      "summary": "An MCP extension that lets an enterprise identity provider broker the token an MCP client presents to an MCP server, by way of the Identity Assertion Authorization Grant.\n",
      "url": "https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization",
      "revisions": [
        {
          "id": "stable",
          "date": "2025-11-25",
          "status": "current",
          "url": "https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization",
          "changes": "Announced with specification revision 2025-11-25 and maintained in the ext-auth repository.\n"
        }
      ]
    },
    {
      "id": "a2a-protocol",
      "name": "Agent2Agent (A2A) Protocol",
      "body": "a2a",
      "family": "protocol",
      "maturity": "published",
      "maturityNote": "Version 1.0, a Linux Foundation project",
      "summary": "How agents discover each other through Agent Cards, declare the security schemes they accept, and delegate tasks over JSON-RPC, HTTP or gRPC.\n",
      "url": "https://a2a-protocol.org/latest/specification/",
      "revisions": [
        {
          "id": "0.3.0",
          "date": "2025-07-30",
          "status": "superseded",
          "url": "https://github.com/a2aproject/A2A/releases/tag/v0.3.0",
          "changes": "Adds signatures to Agent Cards so a card can be verified.\n"
        },
        {
          "id": "1.0.0",
          "date": "2026-03-12",
          "status": "current",
          "url": "https://github.com/a2aproject/A2A/releases/tag/v1.0.0",
          "supersedes": "0.3.0",
          "changes": "First major release.\n"
        }
      ]
    },
    {
      "id": "cross-app-access",
      "name": "Cross App Access (XAA)",
      "body": "vendor",
      "family": "profile",
      "maturity": "published",
      "maturityNote": "Okta's implementation of the Identity Assertion JWT Authorization Grant",
      "summary": "Identity-provider-brokered, policy-controlled access from one application or agent to another's API inside an enterprise, without a per-user consent screen.\n",
      "url": "https://developer.okta.com/docs/concepts/xaa",
      "revisions": [
        {
          "id": "2025-06",
          "date": "2025-06-23",
          "status": "current",
          "url": "https://developer.okta.com/docs/concepts/xaa"
        }
      ]
    },
    {
      "id": "auth-md",
      "name": "auth.md",
      "body": "vendor",
      "family": "discovery",
      "maturity": "published",
      "maturityNote": "Open protocol published by WorkOS; not under a standards body",
      "summary": "A Markdown file at /auth.md, plus an agent_auth block in the service's OAuth metadata, that tells an agent how to register with a service on a user's behalf and obtain scoped tokens.\n",
      "url": "https://workos.com/auth-md",
      "revisions": [
        {
          "id": "2026-05",
          "date": "2026-05-21",
          "status": "current",
          "url": "https://github.com/workos/auth.md"
        }
      ]
    },
    {
      "id": "nis2",
      "name": "NIS 2 Directive",
      "body": "eu",
      "family": "regulation",
      "maturity": "in-force",
      "maturityNote": "Directive (EU) 2022/2555",
      "summary": "Cybersecurity risk-management and incident-reporting duties for essential and important entities across the EU, including the identity and access controls they must operate.\n",
      "url": "https://eur-lex.europa.eu/eli/dir/2022/2555/oj",
      "revisions": [
        {
          "id": "oj-2022-2555",
          "date": "2022-12-27",
          "status": "current",
          "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022L2555",
          "changes": "Published in the Official Journal on 2022-12-27; in force since 2023-01-16; transposition deadline 2024-10-17.\n"
        }
      ]
    },
    {
      "id": "eidas-2",
      "name": "European Digital Identity Framework (eIDAS 2.0)",
      "body": "eu",
      "family": "regulation",
      "maturity": "in-force",
      "maturityNote": "Regulation (EU) 2024/1183, amending Regulation (EU) No 910/2014",
      "summary": "Mandates that every Member State offer an EU Digital Identity Wallet and sets the rules for electronic identification, attestations and trust services that an agent acting under a citizen's mandate will depend on.\n",
      "url": "https://eur-lex.europa.eu/eli/reg/2024/1183/oj",
      "revisions": [
        {
          "id": "oj-2024-1183",
          "date": "2024-04-30",
          "status": "current",
          "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1183",
          "changes": "Published in the Official Journal on 2024-04-30; in force since 2024-05-20. Member States must provide at least one wallet within 24 months of the implementing acts, which the Commission reads as the end of 2026.\n"
        }
      ]
    },
    {
      "id": "ai-act",
      "name": "Artificial Intelligence Act",
      "body": "eu",
      "family": "regulation",
      "maturity": "in-force",
      "maturityNote": "Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744",
      "summary": "Risk-based rules for AI systems and general-purpose models, including human oversight, transparency and logging duties that apply to agents acting on people's behalf.\n",
      "url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj",
      "revisions": [
        {
          "id": "oj-2024-1689",
          "date": "2024-07-12",
          "status": "superseded",
          "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689",
          "changes": "Published in the Official Journal on 2024-07-12; in force since 2024-08-01; general application from 2026-08-02.\n"
        },
        {
          "id": "oj-2026-1744",
          "date": "2026-07-24",
          "status": "current",
          "url": "https://eur-lex.europa.eu/eli/reg/2026/1744/oj",
          "supersedes": "oj-2024-1689",
          "changes": "Amended by Regulation (EU) 2026/1744 (the Digital Omnibus on AI), in force since 2026-07-27: Annex III high-risk obligations deferred to 2027-12-02 and Annex I embedded high-risk systems to 2028-08-02; the Article 50 transparency duties still apply from 2026-08-02.\n"
        }
      ]
    },
    {
      "id": "eudi-arf",
      "name": "EUDI Wallet Architecture and Reference Framework",
      "body": "eu",
      "family": "guidance",
      "maturity": "published",
      "maturityNote": "Technical reference by the Commission and the eIDAS expert group; not legislation",
      "summary": "The architecture, requirements and named standards for the EU Digital Identity Wallet ecosystem: credential formats, issuance and presentation protocols, trust and conformance.\n",
      "url": "https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework",
      "revisions": [
        {
          "id": "3.0.0",
          "date": "2026-07-23",
          "status": "current",
          "url": "https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/releases/tag/v3.0.0",
          "changes": "Aligns with the 2026 amending implementing regulations and adds the functional conformance assessment framework.\n"
        }
      ]
    }
  ],
  "relations": [
    {
      "from": "rfc7636",
      "to": "rfc6749",
      "type": "builds-on",
      "note": "Extends the authorization code grant with a code verifier.",
      "source": "https://www.rfc-editor.org/rfc/rfc7636"
    },
    {
      "from": "rfc7591",
      "to": "rfc6749",
      "type": "builds-on",
      "note": "Registers OAuth clients; the client metadata it defines is reused by later documents.",
      "source": "https://www.rfc-editor.org/rfc/rfc7591"
    },
    {
      "from": "rfc7523",
      "to": "rfc6749",
      "type": "builds-on",
      "note": "Defines a JWT assertion grant and JWT client authentication for the token endpoint.",
      "source": "https://www.rfc-editor.org/rfc/rfc7523"
    },
    {
      "from": "rfc8414",
      "to": "rfc6749",
      "type": "builds-on",
      "note": "Publishes the authorization server's endpoints and capabilities.",
      "source": "https://www.rfc-editor.org/rfc/rfc8414"
    },
    {
      "from": "rfc8414",
      "to": "openid-connect-discovery",
      "type": "references",
      "note": "Generalises the OpenID Connect provider metadata to any OAuth authorization server and keeps its field names.",
      "source": "https://www.rfc-editor.org/rfc/rfc8414"
    },
    {
      "from": "rfc8693",
      "to": "rfc6749",
      "type": "builds-on",
      "note": "Adds the token exchange grant type to the token endpoint.",
      "source": "https://www.rfc-editor.org/rfc/rfc8693"
    },
    {
      "from": "rfc8707",
      "to": "rfc6749",
      "type": "builds-on",
      "note": "Adds the resource request parameter to the authorization and token endpoints.",
      "source": "https://www.rfc-editor.org/rfc/rfc8707"
    },
    {
      "from": "rfc9068",
      "to": "rfc6749",
      "type": "builds-on",
      "note": "Profiles the access token the framework leaves opaque as a JWT.",
      "source": "https://www.rfc-editor.org/rfc/rfc9068"
    },
    {
      "from": "rfc9207",
      "to": "rfc6749",
      "type": "builds-on",
      "note": "Adds the iss parameter to the authorization response.",
      "source": "https://www.rfc-editor.org/rfc/rfc9207"
    },
    {
      "from": "rfc9396",
      "to": "rfc6749",
      "type": "builds-on",
      "note": "Adds authorization_details alongside scope.",
      "source": "https://www.rfc-editor.org/rfc/rfc9396"
    },
    {
      "from": "rfc9449",
      "to": "rfc6749",
      "type": "builds-on",
      "note": "Sender-constrains the framework's bearer tokens.",
      "source": "https://www.rfc-editor.org/rfc/rfc9449"
    },
    {
      "from": "rfc9700",
      "to": "rfc6749",
      "type": "builds-on",
      "note": "Updates the framework's security considerations and deprecates the implicit grant and password grant.",
      "source": "https://www.rfc-editor.org/rfc/rfc9700"
    },
    {
      "from": "rfc9728",
      "to": "rfc6749",
      "type": "builds-on",
      "note": "Publishes metadata for the framework's protected resources.",
      "source": "https://www.rfc-editor.org/rfc/rfc9728"
    },
    {
      "from": "rfc9728",
      "to": "rfc8414",
      "type": "references",
      "note": "Mirrors the authorization server metadata conventions for the resource side and names the servers whose metadata a client fetches next.",
      "source": "https://www.rfc-editor.org/rfc/rfc9728"
    },
    {
      "from": "oauth-2-1",
      "to": "rfc6749",
      "type": "replaces",
      "note": "Obsoletes RFC 6749 and RFC 6750 when published.",
      "source": "https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/"
    },
    {
      "from": "oauth-2-1",
      "to": "rfc7636",
      "type": "builds-on",
      "note": "Makes PKCE a requirement of the authorization code grant.",
      "source": "https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/"
    },
    {
      "from": "oauth-2-1",
      "to": "rfc9700",
      "type": "builds-on",
      "note": "Folds the security best current practice into the base specification.",
      "source": "https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/"
    },
    {
      "from": "cimd",
      "to": "rfc6749",
      "type": "builds-on",
      "note": "Defines a client_id syntax and the authorization server behaviour for it.",
      "source": "https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/"
    },
    {
      "from": "cimd",
      "to": "rfc7591",
      "type": "references",
      "note": "The metadata document reuses the client metadata fields of dynamic registration.",
      "source": "https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/"
    },
    {
      "from": "cimd",
      "to": "rfc7591",
      "type": "solves-same-problem-as",
      "note": "Both let a client the authorization server has never seen become usable: dynamic registration by an API call that creates a record, the metadata document by a URL the server fetches on demand. The MCP Authorization specification moved its default from the first to the second in revision 2026-07-28.\n",
      "source": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization"
    },
    {
      "from": "auth-md",
      "to": "rfc9728",
      "type": "builds-on",
      "note": "Places the agent_auth block in the protected resource and authorization server metadata.",
      "source": "https://github.com/workos/auth.md"
    },
    {
      "from": "auth-md",
      "to": "rfc8414",
      "type": "references",
      "note": "The agent_auth block is also carried in the authorization server metadata.",
      "source": "https://github.com/workos/auth.md"
    },
    {
      "from": "auth-md",
      "to": "id-jag",
      "type": "references",
      "note": "Its \"agent verified\" registration path uses the identity assertion grant.",
      "source": "https://github.com/workos/auth.md"
    },
    {
      "from": "auth-md",
      "to": "rfc7591",
      "type": "solves-same-problem-as",
      "note": "Both answer how a client nobody registered gets credentials. Dynamic registration is a generic API; auth.md is a human- and agent-readable file plus metadata aimed at agents signing up for a service on a user's behalf.\n"
    },
    {
      "from": "id-jag",
      "to": "rfc8693",
      "type": "builds-on",
      "note": "The identity assertion is exchanged at the enterprise identity provider using the token exchange grant.",
      "source": "https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/"
    },
    {
      "from": "id-jag",
      "to": "rfc7523",
      "type": "builds-on",
      "note": "The resulting JWT authorization grant is presented to the resource's authorization server as a JWT bearer assertion.",
      "source": "https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/"
    },
    {
      "from": "id-jag",
      "to": "openid-connect-core",
      "type": "references",
      "note": "An ID Token is one of the identity assertions the client can present.",
      "source": "https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/"
    },
    {
      "from": "cross-app-access",
      "to": "id-jag",
      "type": "profiles",
      "note": "Okta's product implements the draft's flow and names its deployment constraints.",
      "source": "https://developer.okta.com/docs/concepts/xaa"
    },
    {
      "from": "mcp-enterprise-managed-authorization",
      "to": "mcp-authorization",
      "type": "builds-on",
      "note": "An extension of the base authorization flow for enterprise-managed MCP clients.",
      "source": "https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization"
    },
    {
      "from": "mcp-enterprise-managed-authorization",
      "to": "id-jag",
      "type": "builds-on",
      "note": "The token the MCP client presents is obtained through the identity assertion grant.",
      "source": "https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization"
    },
    {
      "from": "transaction-tokens",
      "to": "rfc8693",
      "type": "builds-on",
      "note": "A transaction token is minted by a token exchange style request to a transaction token service.",
      "source": "https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/"
    },
    {
      "from": "transaction-tokens",
      "to": "rfc9068",
      "type": "references",
      "note": "Transaction tokens are JWTs and reuse the access token profile's claim conventions.",
      "source": "https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/"
    },
    {
      "from": "mcp-authorization",
      "to": "oauth-2-1",
      "type": "profiles",
      "note": "MCP authorization is a profile of OAuth 2.1 for MCP clients and servers.",
      "source": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization"
    },
    {
      "from": "mcp-authorization",
      "to": "rfc9728",
      "type": "builds-on",
      "note": "An MCP server announces its authorization servers through protected resource metadata.",
      "source": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization"
    },
    {
      "from": "mcp-authorization",
      "to": "rfc8414",
      "type": "builds-on",
      "note": "Clients discover the authorization server's endpoints from its metadata.",
      "source": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization"
    },
    {
      "from": "mcp-authorization",
      "to": "rfc7636",
      "type": "builds-on",
      "note": "PKCE with S256 is required for every authorization request.",
      "source": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization"
    },
    {
      "from": "mcp-authorization",
      "to": "rfc8707",
      "type": "builds-on",
      "note": "Clients name the MCP server with the resource parameter so tokens are audience-bound.",
      "source": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization"
    },
    {
      "from": "mcp-authorization",
      "to": "rfc9207",
      "type": "builds-on",
      "note": "Revision 2026-07-28 requires clients to validate the iss parameter when present.",
      "source": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization"
    },
    {
      "from": "mcp-authorization",
      "to": "cimd",
      "type": "references",
      "note": "Client ID Metadata Documents are the recommended registration method.",
      "source": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization"
    },
    {
      "from": "mcp-authorization",
      "to": "rfc7591",
      "type": "references",
      "note": "Dynamic Client Registration remains an option, deprecated in revision 2026-07-28.",
      "source": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization"
    },
    {
      "from": "mcp-authorization",
      "to": "openid-connect-discovery",
      "type": "references",
      "note": "An authorization server may publish its metadata as an OpenID Provider configuration instead.",
      "source": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization"
    },
    {
      "from": "authzen-coaz-mcp",
      "to": "mcp-authorization",
      "type": "references",
      "note": "Adds a policy decision step for tool calls on top of the token-based authorization MCP defines.",
      "source": "https://github.com/openid/authzen/blob/main/profiles/authzen-coaz-mcp-binding-1_0.md"
    },
    {
      "from": "a2a-protocol",
      "to": "rfc6749",
      "type": "references",
      "note": "Agent Cards can declare an OAuth 2.0 security scheme, including its flows and scopes.",
      "source": "https://a2a-protocol.org/latest/specification/"
    },
    {
      "from": "a2a-protocol",
      "to": "openid-connect-core",
      "type": "references",
      "note": "Agent Cards can declare an OpenID Connect security scheme.",
      "source": "https://a2a-protocol.org/latest/specification/"
    },
    {
      "from": "dawn",
      "to": "a2a-protocol",
      "type": "solves-same-problem-as",
      "note": "Both are about finding an agent and its public properties. A2A does it with an Agent Card the agent serves itself; DAWN proposes DNS-based discovery beneath any agent protocol and leaves identity to others.\n",
      "source": "https://datatracker.ietf.org/doc/bofreq-vyncke-dawn/"
    },
    {
      "from": "aauth",
      "to": "oauth-2-1",
      "type": "competes-with",
      "note": "AAuth proposes a new agent-first protocol built on HTTP message signatures instead of profiling the OAuth authorization code flow; both aim at an agent obtaining authorized access to a resource on a person's behalf.\n",
      "source": "https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/"
    },
    {
      "from": "wimse-s2s",
      "to": "wimse-arch",
      "type": "builds-on",
      "note": "Applied the architecture's workload identity to service-to-service calls.",
      "source": "https://datatracker.ietf.org/doc/draft-ietf-wimse-s2s-protocol/"
    },
    {
      "from": "wimse-workload-creds",
      "to": "wimse-arch",
      "type": "builds-on",
      "note": "Defines the credentials the architecture's workloads carry.",
      "source": "https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/"
    },
    {
      "from": "wimse-workload-creds",
      "to": "wimse-s2s",
      "type": "replaces",
      "note": "Continues the credential part of the dead workload-to-workload draft.",
      "source": "https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/"
    },
    {
      "from": "wimse-aims",
      "to": "wimse-arch",
      "type": "builds-on",
      "note": "Applies WIMSE workload identity to AI agents.",
      "source": "https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/"
    },
    {
      "from": "wimse-aims",
      "to": "rfc6749",
      "type": "references",
      "note": "Reviews how OAuth 2.0 grants apply when an agent acts for a user.",
      "source": "https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/"
    },
    {
      "from": "wimse-aims",
      "to": "rfc8693",
      "type": "references",
      "note": "Token exchange is one of the building blocks it evaluates for agent delegation.",
      "source": "https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/"
    },
    {
      "from": "wimse-ai-agent-identity",
      "to": "wimse-arch",
      "type": "builds-on",
      "note": "Proposes WIMSE identifiers and credentials for AI agents.",
      "source": "https://datatracker.ietf.org/doc/draft-ni-wimse-ai-agent-identity/"
    },
    {
      "from": "wimse-ai-agent-identity",
      "to": "wimse-aims",
      "type": "solves-same-problem-as",
      "note": "Both describe how WIMSE applies to AI agents. AIMS is the working group's adopted document with a best-practices scope; the applicability draft is an individual proposal that also binds the agent to an accountable user or organisation.\n"
    },
    {
      "from": "openid-connect-core",
      "to": "rfc6749",
      "type": "builds-on",
      "note": "Adds the ID Token and authentication semantics to the OAuth 2.0 flows.",
      "source": "https://openid.net/specs/openid-connect-core-1_0.html"
    },
    {
      "from": "openid-connect-discovery",
      "to": "openid-connect-core",
      "type": "builds-on",
      "note": "Discovery of the provider's configuration for Core's flows.",
      "source": "https://openid.net/specs/openid-connect-discovery-1_0.html"
    },
    {
      "from": "openid-federation",
      "to": "openid-connect-core",
      "type": "builds-on",
      "note": "Version 1.0 establishes trust between OpenID Connect relying parties and providers.",
      "source": "https://openid.net/specs/openid-federation-1_0.html"
    },
    {
      "from": "openid4vp",
      "to": "rfc6749",
      "type": "builds-on",
      "note": "Credential presentation is requested with an OAuth 2.0 authorization request.",
      "source": "https://openid.net/specs/openid-4-verifiable-presentations-1_0.html"
    },
    {
      "from": "openid4vp",
      "to": "sd-jwt-vc",
      "type": "references",
      "note": "SD-JWT VC is one of the credential formats it defines presentation rules for.",
      "source": "https://openid.net/specs/openid-4-verifiable-presentations-1_0.html"
    },
    {
      "from": "openid4vp",
      "to": "w3c-vc-data-model-2",
      "type": "references",
      "note": "W3C Verifiable Credentials are another credential format it defines presentation rules for.",
      "source": "https://openid.net/specs/openid-4-verifiable-presentations-1_0.html"
    },
    {
      "from": "openid4vci",
      "to": "rfc6749",
      "type": "builds-on",
      "note": "The credential endpoint is an OAuth 2.0 protected resource.",
      "source": "https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html"
    },
    {
      "from": "openid4vci",
      "to": "rfc9396",
      "type": "references",
      "note": "Uses authorization_details to request the issuance of specific credentials.",
      "source": "https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html"
    },
    {
      "from": "sd-jwt-vc",
      "to": "sd-jwt",
      "type": "builds-on",
      "note": "A credential format on top of the selective disclosure mechanism.",
      "source": "https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/"
    },
    {
      "from": "sd-jwt-vc",
      "to": "w3c-vc-data-model-2",
      "type": "solves-same-problem-as",
      "note": "Both are formats for a credential an issuer signs, a holder keeps and a verifier checks. The EU wallet framework names both; SD-JWT VC is JSON-and-JWT based, the W3C model is a data model with several securing mechanisms.\n"
    },
    {
      "from": "eudi-arf",
      "to": "eidas-2",
      "type": "builds-on",
      "note": "The technical framework that implements the regulation's wallet mandate.",
      "source": "https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework"
    },
    {
      "from": "eudi-arf",
      "to": "openid4vp",
      "type": "references",
      "note": "Named as a presentation protocol for wallet credentials.",
      "source": "https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework"
    },
    {
      "from": "eudi-arf",
      "to": "openid4vci",
      "type": "references",
      "note": "Named as the issuance protocol for wallet credentials.",
      "source": "https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework"
    },
    {
      "from": "eudi-arf",
      "to": "sd-jwt-vc",
      "type": "references",
      "note": "Named as a credential format for wallet attestations.",
      "source": "https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework"
    },
    {
      "from": "eudi-arf",
      "to": "w3c-vc-data-model-2",
      "type": "references",
      "note": "Named as a credential data model for wallet attestations.",
      "source": "https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework"
    }
  ],
  "withdrawn": [
    "wimse-s2s"
  ]
}