{
  "dataset": "Agent Identity Attribution Matrix",
  "description": "A clause-level, version-stamped comparison of what five live specifications carry about agent identity, human identity, delegation chains, and attenuation, and what an audit log built on each can therefore prove.",
  "publisher": "Stingrai Inc",
  "canonical_url": "https://www.stingrai.io/blog/web-bot-auth-agent-identity-audit-attribution",
  "data_url": "https://www.stingrai.io/data/agent-identity-attribution-matrix/matrix.json",
  "csv_url": "https://www.stingrai.io/data/agent-identity-attribution-matrix/matrix.csv",
  "license": "CC BY 4.0",
  "license_url": "https://creativecommons.org/licenses/by/4.0/",
  "attribution": "Stingrai, Agent Identity Attribution Matrix, https://www.stingrai.io/blog/web-bot-auth-agent-identity-audit-attribution",
  "accurate_as_of": "2026-07-26",
  "revalidation_cadence": "Quarterly. Next scheduled re-validation 2026-10-26.",
  "method_note": "Every cell was read against the primary specification text, not a summary. Version and revision identifiers below are the exact documents read. Where a specification is silent on a property, the cell says so rather than inferring intent.",
  "value_scale": {
    "Yes": "The specification defines a normative mechanism that carries this property.",
    "Partial": "The specification carries a limited or indirect form of this property, or delegates it to a layer it does not define.",
    "No": "The specification defines no mechanism for this property.",
    "No, normatively excluded": "The specification contains a normative requirement that prevents this property."
  },
  "specifications": [
    {
      "spec_id": "web-bot-auth",
      "spec_name": "HTTP Message Signatures for automated traffic (Web Bot Auth)",
      "spec_version": "draft-meunier-webbotauth-httpsig-protocol-00",
      "spec_date": "2026-06-26",
      "spec_status": "Active Internet-Draft, individual submission, intended status Informational, expires 2026-12-28",
      "spec_url": "https://datatracker.ietf.org/doc/draft-meunier-webbotauth-httpsig-protocol/",
      "predecessor": "draft-meunier-web-bot-auth-architecture-05, 2026-03-02, state Replaced. The clause analysed here appears in that document at Section 5.9 with identical wording.",
      "agent_identity": "Yes",
      "agent_identity_citation": "Section 4 (Architecture): the Agent constructs the request, generates a signature using its signing key, and includes the Signature-Agent header for discovery of its verification key. Section 4.5 defines key discovery. draft-meunier-webbotauth-httpsig-protocol-00.",
      "human_identity": "No, normatively excluded",
      "human_identity_citation": "Section 6.2 (No Human Correlation): the key used for signing MUST NOT be tied to a specific human individual, and keys SHOULD represent a role, company, or automation identity. Stated rationale: avoiding accidental exposure of personally identifiable information and preventing misuse of keys for user tracking or profiling. draft-meunier-webbotauth-httpsig-protocol-00.",
      "delegation_chain": "No",
      "delegation_chain_citation": "Section 3 (Conventions and Definitions) names a User as an entity initiating requests through an agent, which may be a human operator or another system, and Section 4 diagrams User to Agent to Origin. Only the Agent signs. No protocol field carries the User to the Origin. draft-meunier-webbotauth-httpsig-protocol-00.",
      "attenuation": "No",
      "attenuation_citation": "The draft defines identity and message authenticity, not authorization. No scope, permission, or capability field is defined. The created, expires, nonce, and tag signature parameters it inherits from RFC 9421 Section 2.3 bound a signature in time and application context only. draft-meunier-webbotauth-httpsig-protocol-00.",
      "audit_log_can_prove": "That a holder of a named automation key signed this specific set of HTTP components at this time, and that those components were not altered in transit. It cannot prove which human authorised the action, and by design it must not.",
      "known_cve_or_advisory": "None identified. NVD keyword search for web bot auth returned no matching records as of 2026-07-26."
    },
    {
      "spec_id": "rfc9421",
      "spec_name": "HTTP Message Signatures",
      "spec_version": "RFC 9421",
      "spec_date": "2024-02",
      "spec_status": "Standards Track, published February 2024",
      "spec_url": "https://www.rfc-editor.org/rfc/rfc9421.html",
      "predecessor": "None. RFC 9421 is the base signing mechanism that Web Bot Auth references normatively.",
      "agent_identity": "Partial",
      "agent_identity_citation": "Section 2.3 defines keyid as the identifier for the key material as a String value. Section 1.4 requires the application, not the RFC, to define a means of retrieving the key material used to verify the signature, noting the key could also be known from preregistration. Identity binding is an application-layer decision. RFC 9421.",
      "human_identity": "No",
      "human_identity_citation": "No claim, parameter, or derived component defined in RFC 9421 conveys an end-user identity. Section 1.4 delegates all identity semantics to the application profile. RFC 9421.",
      "delegation_chain": "Partial",
      "delegation_chain_citation": "Section 4.3 (Multiple Signatures) permits several signatures on one message, and gives the example of a reverse proxy including a signature over the client's original signature values. That produces a verifiable ordering of signers. It does not carry a statement of who authorised whom. RFC 9421.",
      "attenuation": "No",
      "attenuation_citation": "Section 2.3 signature parameters created, expires, nonce, and tag bound validity in time and application context. Section 1.4 lets an application require a specific tag value. No scope or permission narrowing primitive is defined. RFC 9421.",
      "audit_log_can_prove": "That a holder of a specific key signed a specific set of HTTP components at a specific time, and, where multiple signatures are used, in what order intermediaries countersigned.",
      "known_cve_or_advisory": "Two implementation CVEs, none against the RFC design. CVE-2025-59058, httpsig-rs prior to 0.0.19, non-timing-safe HMAC comparison, CVSS 3.1 base 5.9, published 2025-09-12. CVE-2026-26275, httpsig-hyper prior to 0.0.23, digest verification could incorrectly succeed due to a Rust matches macro misuse, CVSS 3.1 base 7.5, published 2026-02-19."
    },
    {
      "spec_id": "rfc8693",
      "spec_name": "OAuth 2.0 Token Exchange",
      "spec_version": "RFC 8693",
      "spec_date": "2020-01",
      "spec_status": "Standards Track, published January 2020",
      "spec_url": "https://www.rfc-editor.org/rfc/rfc8693.html",
      "predecessor": "None.",
      "agent_identity": "Yes",
      "agent_identity_citation": "Section 4.1: the act claim provides a means within a JWT to express that delegation has occurred and identify the acting party to whom authority has been delegated. Section 2.1 defines the actor_token request parameter as the identity of the party to whom access rights are being delegated. RFC 8693.",
      "human_identity": "Yes",
      "human_identity_citation": "Section 4.1: the token's top-level claims are about the subject, and Figure 5 shows a sub of user@example.com alongside an act naming the current actor. Section 2.1 defines subject_token as the identity of the party on behalf of whom the token is requested. RFC 8693.",
      "delegation_chain": "Yes",
      "delegation_chain_citation": "Section 4.1: a chain of delegation can be expressed by nesting one act claim within another, the outermost act representing the current actor and nested act claims representing prior actors, with the least recent actor most deeply nested, serving as a history trail. Same section, load-bearing caveat: for access control, the consumer MUST only consider top-level claims and the current actor, and prior actors are informational only. RFC 8693.",
      "attenuation": "Yes",
      "attenuation_citation": "Section 2.1 defines optional scope, resource, and audience request parameters that let the client specify the desired scope of the requested token and the target service. Section 2.2.1 makes the response scope REQUIRED whenever the issued scope differs from the requested scope. Section 1.1 describes exchanging a token for one more narrowly scoped for the downstream service. RFC 8693.",
      "audit_log_can_prove": "Which human is the subject, which party currently holds the delegated authority, the ordered history of prior actors, and the scope and audience the issued token was narrowed to. The prior-actor history is evidentiary rather than enforceable, per the Section 4.1 access-control caveat.",
      "known_cve_or_advisory": "None identified against the act claim or the token-exchange grant type. NVD keyword search for OAuth token exchange act claim returned no records as of 2026-07-26."
    },
    {
      "spec_id": "mcp-authorization",
      "spec_name": "Model Context Protocol, Authorization specification",
      "spec_version": "2025-11-25 (current protocol version); 2025-06-18 (prior) also read",
      "spec_date": "2025-11-25",
      "spec_status": "Current protocol revision as published on modelcontextprotocol.io as of 2026-07-26",
      "spec_url": "https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization",
      "predecessor": "2025-06-18. Differences relevant to this matrix are recorded in the citation cells.",
      "agent_identity": "Partial",
      "agent_identity_citation": "Roles section, both revisions: an MCP client acts as an OAuth 2.1 client making protected resource requests on behalf of a resource owner. Identity is therefore the OAuth client identity. The 2025-11-25 revision adds OAuth Client ID Metadata Documents to the Standards Compliance list and to Overview item 2. Neither revision defines a per-agent-instance identifier.",
      "human_identity": "Partial",
      "human_identity_citation": "Roles section, both revisions: the authorization server is responsible for interacting with the user if necessary and issuing access tokens, and the implementation details of the authorization server are beyond the scope of this specification. Whether a user claim appears in the token is an authorization-server decision, not an MCP requirement.",
      "delegation_chain": "No",
      "delegation_chain_citation": "The Standards Compliance list names OAuth 2.1, RFC 8414, RFC 7591, RFC 9728, and, in 2025-11-25, OAuth Client ID Metadata Documents. RFC 8693 is absent from both revisions, and neither contains any reference to token exchange, the act claim, or a delegation chain. Both revisions move in the opposite direction on purpose: servers MUST only accept tokens specifically intended for themselves and MUST reject tokens that do not include them in the audience claim, and the Token Audience Binding section states that token passthrough is explicitly forbidden.",
      "attenuation": "Partial",
      "attenuation_citation": "The 2025-11-25 revision adds a Scope Selection Strategy in which MCP clients SHOULD follow the principle of least privilege, plus a Step-Up Authorization Flow driven by insufficient_scope responses carrying the minimum scopes needed for the operation. The 2025-06-18 revision has neither. Both require audience binding. Neither defines attenuation that survives a hop between agents.",
      "audit_log_can_prove": "Which OAuth client obtained a token for this MCP server, with which scopes, bound to this audience, and under 2025-11-25 which scope escalations were stepped up at runtime. Whether the human behind the call is identifiable depends on what the authorization server puts in the token, which the specification places out of scope.",
      "known_cve_or_advisory": "64 NVD records match Model Context Protocol as of 2026-07-26, all against implementations rather than the authorization specification's delegation model. Representative examples: CVE-2025-66414, MCP TypeScript SDK prior to 1.24.0, DNS rebinding protection not enabled by default, CVSS 3.1 base 8.1, published 2025-12-02; CVE-2026-25536, MCP TypeScript SDK 1.10.0 to 1.25.3, cross-client response data leak on reused transport instances, CVSS 3.1 base 7.1, published 2026-02-04."
    },
    {
      "spec_id": "a2a",
      "spec_name": "Agent2Agent (A2A) Protocol Specification",
      "spec_version": "Protocol version 1.0, specification release v1.0.0",
      "spec_date": "2026-03-12",
      "spec_status": "Latest released specification version 1.0.0, released 2026-03-12. Patch release v1.0.1 on 2026-05-28 does not change the negotiated protocol version, which uses only Major.Minor.",
      "spec_url": "https://a2a-protocol.org/latest/specification/",
      "predecessor": "v0.3.0, released 2025-07-30.",
      "agent_identity": "Partial",
      "agent_identity_citation": "Section 7.2: A2A Clients SHOULD verify the A2A Server's identity by validating its TLS certificate. Section 7.3: the client discovers required schemes via securitySchemes in the AgentCard and acquires credentials out of band. Server identity is well defined; client identity is whatever the chosen scheme happens to carry. A2A v1.0.0.",
      "human_identity": "No",
      "human_identity_citation": "Section 7 opening: A2A treats agents as standard enterprise applications, relying on established web security practices, and identity information is handled at the protocol layer, not within A2A semantics. The companion enterprise guidance states that A2A protocol payloads do not carry user or client identity information directly and that identity is established at the transport or HTTP layer. A2A v1.0.0.",
      "delegation_chain": "No",
      "delegation_chain_citation": "Section 7.6 lets a client that is itself an agent delegate an authorization request onward, enabling forming a chain of Tasks in TASK_STATE_AUTH_REQUIRED. That is a chain of authorization requests, not an attributed chain of delegated authority. Section 7.6.3 warns that in-band credential exchange can allow credentials to be passed across chains of multiple A2A agents, exposing those credentials to each agent participating in the chain, and recommends binding credentials to the originating agent. A2A v1.0.0.",
      "attenuation": "No",
      "attenuation_citation": "Section 7.5: once authenticated, the server authorizes requests based on the authenticated identity and its own policies, and authorization logic is implementation-specific and MAY consider specific skills requested, actions attempted within tasks, data access policies, and OAuth scopes. The protocol itself defines no attenuation primitive. A2A v1.0.0.",
      "audit_log_can_prove": "That an authenticated client called this agent under a declared security scheme, plus the task and context identifiers the protocol assigns. Attribution to a human is placed outside protocol semantics by Section 7.",
      "known_cve_or_advisory": "None identified. NVD keyword search for Agent2Agent returned no records as of 2026-07-26."
    }
  ],
  "gap_closing_work": [
    {
      "draft": "draft-mcguinness-oauth-ai-agent-instance-00",
      "title": "OAuth 2.0 AI Agent Instance Profile",
      "date": "2026-07-04",
      "status": "Active Internet-Draft, individual submission, intended status Standards Track, expires 2027-01-06",
      "relevance": "Defines claims conveying an attested agent instance identifier and agent provenance, plus delegation-chain semantics for agents that spawn sub-agents. References RFC 8693.",
      "url": "https://datatracker.ietf.org/doc/draft-mcguinness-oauth-ai-agent-instance/"
    },
    {
      "draft": "draft-oauth-ai-agents-on-behalf-of-user-02",
      "title": "OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents",
      "date": "2025-08-26",
      "status": "Expired Internet-Draft, individual submission, expired 2026-02-27",
      "relevance": "Introduced requested_actor and actor_token parameters and described access token claims documenting the delegation chain from the user to the agent via a client application. References RFC 8693.",
      "url": "https://datatracker.ietf.org/doc/draft-oauth-ai-agents-on-behalf-of-user/"
    }
  ],
  "revision_log": [
    {
      "version": "1.0",
      "date": "2026-07-26",
      "change": "Initial publication. Five specifications read directly at the revisions stamped above. CVE and advisory sweep run against NVD on 2026-07-26."
    }
  ]
}