The Authorization Type Attestation (ATA) Protocol

Internet-Draft	ATA Protocol	June 2026
Anokhin	Expires 20 December 2026	[Page]

Abstract

This document describes a session-layer mechanism addressing a requirement independently exhibited by emerging agentic communication systems: the need for recipients to determine the authorization type of the communicating party (a human-controlled credential or an AI provider instance) before or during interaction.¶

The Authorization Type Attestation (ATA) protocol defines a transport-layer extension that carries this authorization type using existing hardware roots of trust (Secure Enclaves, FIDO2, TPM, Confidential Computing) and PKI infrastructure.¶

ATA does not replace existing identity systems (mTLS, SPIFFE, OAuth 2.1, FIDO2). ATA does not verify content authorship or model behavior. ATA provides a mechanism to carry authorization type at the session layer, composably with TLS, QUIC, MLS, MCP, and A2A.¶

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 20 December 2026.¶

Copyright Notice

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.¶

1. Introduction

Modern communication protocols (TLS, DTLS, QUIC [RFC9000], MLS [RFC9420]) verify that data reached the correct endpoint securely. They do not indicate the authorization type of the communicating party at the session layer.¶

This produces four communication states lacking session-layer authorization type encoding:¶

Table 1: Communication states lacking session-layer authorization type encoding
State	Direction	Current gap
H2H	human to human	No mutual authorization attestation
H2AI	human to AI	Human side: FIDO2; AI side: unattested
AI2H	AI to human	No session-layer standard exists
AI2AI	AI to AI	No attestation standard

Existing authentication mechanisms (mTLS, OAuth 2.1, SPIFFE/SPIRE, signed agent cards) establish workload identity and permission scope. They do not indicate whether the authorizing party is a human principal or an AI provider instance. Current MCP and A2A authorization mechanisms do not specify hardware-level AI provider attestation.¶

We observe that emerging agentic systems across independent implementations require this signal. This document specifies a mechanism to address this class of problems.¶

This problem was previously theoretical. It becomes practical with the emergence of agentic systems capable of autonomously initiating real-time interactions at scale. MCP and A2A are early instances of a broader class of protocols that expose this gap operationally. This motivates documenting a transport-layer mechanism before incompatible deployments emerge.¶

Absence of ATA data indicates an unattested session and is not, by itself, evidence of fraud.¶

2. Terminology

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.¶

Authorizing Party:: The human principal or AI provider instance that cryptographically authorized a communication session.¶
Authorization Type:: The semantic classification of the authorizing party: SIGNED_HUMAN, SIGNED_AI, or UNSIGNED. Distinct from workload identity as provided by mTLS or SPIFFE.¶
Authorization Handshake:: The ATA Phase 1 process establishing mutual session authorization type and deriving a session key.¶
Attestation:: A cryptographically signed claim about the hardware and credential state of the authorizing party at session time, expressed in EAT format [RFC9711].¶
Provider Endpoint:: The attestable unit for AI participants: the AI provider's service endpoint on verified hardware infrastructure. The underlying model implementation is outside attestation scope.¶
Certificate Issuer Mismatch:: A condition in which the certificate presented by a party is issued to an organization other than the expected authorizing party. Detectable without content analysis.¶
Agentic Protocol:: A communication protocol designed for autonomous AI agent interactions, typically operating over HTTPS. MCP and A2A are current instances of this class.¶

3. Non-Goals

ATA explicitly does not address the following:¶

(a): Replacement of existing identity systems. ATA is composable with mTLS, SPIFFE/SPIRE, OAuth 2.1, and FIDO2. It does not supersede or conflict with these mechanisms.¶
(b): Content authorship verification. ATA verifies who authorized the channel. It makes no claim about the origin of individual messages within the channel. Recipients requiring per-message content authorship verification should use C2PA [C2PA] in conjunction with ATA.¶
(c): Model implementation attestation. The attestable unit is the provider's service endpoint. Internal architecture, weights, and model versions are outside scope.¶
(d): Trust scoring or behavioral guarantees. ATA encodes authorization type, not trustworthiness or intent.¶
(e): Biological presence. ATA does not determine biological presence. It verifies that a human principal's device-bound credential authorized the session.¶
(f): Continuous presence guarantee. ATA attests the authorization type at session initiation time. It does not guarantee that the authorizing party remains present or active throughout the session duration.¶
(g): Prevention of relay attacks within authorized sessions. A SIGNED_HUMAN party may relay AI-generated content within an authorized session. ATA records the human as the accountable authorizing party at session initiation. This is an explicit scope boundary: ATA establishes session-layer accountability, not per-message content authorship.¶
(h): Cryptographic proof of provider identity beyond organizational certificate level. SIGNED_AI proves that a session was authorized by a hardware-bound endpoint holding a certificate issued to a verified organization. It does not prevent an adversary from obtaining a certificate for a similarly-named organization. Recipients SHOULD maintain pre-authorized provider certificate lists and treat certificate issuer mismatch as a policy signal, not a cryptographic proof of fraud.¶

ATA cryptographically guarantees:¶

Which attestation class authorized the session (SIGNED_HUMAN, SIGNED_AI, or UNSIGNED).¶
That the session was authorized by a hardware-bound credential at initiation time.¶
The organizational-level identity of the authorizing party.¶

ATA does NOT cryptographically guarantee:¶

Continuous presence of the authorizing party.¶
Per-message content authorship.¶
Provider identity beyond organizational certificate level.¶
Prevention of relay attacks within an authorized session.¶

4. Applicability Criteria

ATA is applicable to a protocol when all three of the following conditions are satisfied simultaneously:¶

(1): Real-time bidirectional channel: the protocol establishes a session in which both parties are present concurrently.¶
(2): Pre-interaction authorization visibility: the recipient can act on authorization type information before or during the interaction, not solely after content delivery.¶
(3): Authorizing party type is material: the type of authorizing party (human principal or AI provider instance) is relevant to the recipient's decision to engage.¶

If any condition is not satisfied, existing standards (C2PA, DKIM, S/MIME, GPG) address the use case more appropriately. See Section 10 for explicit out-of-scope categories.¶

5. Threat Model

ATA is intended to address three threat classes:¶

5.1. AI Impersonation of Human Principal

An AI agent presents itself as a human in a real-time channel without cryptographic disclosure. Recipients cannot distinguish this without content analysis. ATA makes the authorization type available at session initiation, before content is received.¶

5.2. Undisclosed AI Interaction

A human recipient engages with an AI agent without knowledge of its provider identity. No existing transport-layer standard requires cryptographic provider disclosure at session initiation. ATA provides this before content delivery.¶

5.3. Rogue Agent Injection in Pipeline

An unaffiliated AI agent is injected into a multi-agent pipeline (MCP tool chain, A2A task delegation). Certificate issuer mismatch or UNSIGNED state is detectable at the point of injection without content analysis.¶

6. Authorization States

ATA defines three authorization states as a minimal initial classification. This set is designed for extension and policy layering above the protocol level.¶

SIGNED_HUMAN: The channel was authorized by a human-controlled credential, cryptographically bound to a device via biometric attestation (FIDO2 + Secure Enclave). ATA does not prove continuous human presence; it attests that a human-controlled device credential authorized the session. Device certificates may additionally attest organizational affiliation. Authorization type is encoded at the organizational level, not the individual entity level.¶
SIGNED_AI: The channel was authorized by an AI provider instance, cryptographically bound to hardware via TPM or Confidential Computing attestation. The attestable unit is the provider's service endpoint on attested hardware. Provider accountability for model behavior is analogous to server operator accountability for application behavior in TLS deployments.¶
UNSIGNED: No ATA data is present. Legacy fallback. UNSIGNED is a defined state, not an error condition. Recipients determine their own policy for UNSIGNED sessions. ATA does not introduce a negative trust signal. The protocol only introduces positive attestations; UNSIGNED means the absence of proof, not the presence of risk.¶

7. Applicability

7.1. H2H - Mutual Authorization Attestation

Both parties present SIGNED_HUMAN credentials. Certificate issuer identifies organizational affiliation. A party without organizational device infrastructure presents personal SIGNED_HUMAN or UNSIGNED; this distinction is available at session initiation without content analysis.¶

Applicable to: legally and financially significant communications requiring session-layer audit trail.¶

7.2. H2AI - Verified AI Provider Identity

A human initiates a session with a service presenting SIGNED_AI. The human can verify the provider certificate against known issuers. Certificate issuer mismatch is detectable without content analysis.¶

Complements FIDO2 [FIDO-CTAP2]: ATA adds AI-side attestation where FIDO2 provides human-side attestation.¶

Applicable to: client-facing AI services operated by regulated institutions.¶

7.3. AI2H - Disclosed AI Initiation

An AI agent initiates a session. SIGNED_AI provides the recipient with cryptographic evidence of the AI provider before content delivery. No existing transport-layer standard addresses this scenario. This is the primary gap ATA targets.¶

Scope boundary: ATA guarantees that an AI provider authorized the session initiation. It does not prevent a SIGNED_HUMAN party from relaying AI-generated content within an authorized session. Recipients requiring per-message content authorship guarantees should use C2PA [C2PA] in conjunction with ATA.¶

Non-normative regulatory note: EU AI Act Article 52 requires disclosure that content is AI-generated. ATA can provide technical evidence of AI provider authorization at session initiation. Per-message content disclosure requires additional mechanisms (C2PA) beyond ATA scope.¶

Applicable to: AI-operated services where the recipient needs to identify the authorizing party type before engaging. This case has fewer relay-related limitations in fully-automated AI2H scenarios where no human relay is present.¶

7.4. AI2AI - Agent Pipeline Attestation

Multi-agent pipelines (MCP tool chains, A2A task delegation) produce a verifiable authorization chain across each hop. An agent without organizational certificate infrastructure produces certificate issuer mismatch or UNSIGNED at the point of entry, detectable without content analysis.¶

Applicable to: multi-agent workflows requiring accountability logging and forensic auditability.¶

7.5. UNSIGNED - Legacy Compatibility

Existing traffic continues to function. UNSIGNED is a defined state. Recipients determine their own policy.¶

8. Applicability to Agentic Protocols

8.1. Model Context Protocol (MCP)

MCP defines agent-to-tool communication over HTTPS. The MCP security specification documents that OAuth 2.1 and PKCE establish token integrity but do not prove which AI provider instance initiated the request at the hardware level. ATA addresses this as a TLS extension beneath MCP. No MCP protocol changes required. The ATA handshake completes before any MCP messages are exchanged.¶

8.2. Agent2Agent Protocol (A2A)

A2A defines agent-to-agent communication over HTTPS. Signed agent cards (A2A v1.0) establish card content integrity. ATA adds hardware-bound provider attestation at the TLS session layer, complementing signed cards. No A2A protocol changes required.¶

An optional ATA field MAY be included in the A2A agent card to advertise ATA support. The authoritative attestation is the TLS-layer handshake.¶

8.3. Protocol-Agnostic Applicability

MCP and A2A are current instances of a broader class. Any agentic protocol operating over TLS and satisfying Section 4 criteria can adopt ATA without changes to the agentic protocol itself.¶

9. Protocol Operation

ATA follows Control Plane / Data Plane separation:¶

[EDITOR NOTE: Detailed ATA Extension Payload structure, TLS 1.3 ClientHello/ServerHello extension integration, and formal KDF specification (proposed: HKDF-SHA256, consistent with [RFC8446]) to be provided in draft-01.]¶

9.1. Phase 1 - Authorization Handshake (once per session)

Transport: QUIC or TLS 1.3 extension (port 443).¶

Human participant:¶

Device-bound biometric attestation (FIDO2 / Secure Enclave).¶
Generates symmetric session key.¶
Signed by biometric credential and hardware.¶

AI participant:¶

Hardware attestation (TPM / Confidential Computing).¶
Attestation expressed in EAT format [RFC9711].¶
Verified by RATS Verifier service.¶
Generates symmetric session key.¶
Signed by hardware attestation credential.¶

Result: Authorization type established; session key derived.¶

9.2. Phase 2 - Data Stream (per packet)

Transport: UDP / QUIC data plane.¶

Encryption: AES-GCM (AES-NI hardware acceleration).¶

Integrity: MAC with session key from Phase 1.¶

No additional per-packet round trip after session establishment.¶

A packet with invalid MAC MUST be silently dropped.¶

11. Attestation Payload Format

ATA attestation_payload uses Entity Attestation Token (EAT) format [RFC9711], consistent with IETF RATS architecture [RFC9334].¶

Hardware-specific attestation evidence (Intel SGX, AMD SEV, ARM TrustZone, TPM) is expressed as EAT claims and verified by RATS Verifier services. Receiving parties verify the EAT token from a RATS Verifier rather than raw hardware evidence directly. This abstracts hardware vendor diversity from the ATA session layer and reuses existing RATS infrastructure.¶

[EDITOR NOTE: Specific EAT claim set and RATS Verifier interaction model to be specified in draft-01.]¶

12. Trust Model

ATA inherits the PKI trust model [RFC5280].¶

The protocol provides cryptographic proof of authorization type at the session layer. Trust in the authorizing party is a reputational and legal concern outside protocol scope, consistent with TLS [RFC8446] and FIDO2 [FIDO-CTAP2].¶

Certificate issuance follows existing CA/Browser Forum requirements. An AI provider endpoint certificate is issued to a verified organization on the same basis as a domain certificate. CA accountability for misissuance applies on the same basis as in existing PKI deployments.¶

Authorization type is encoded at the organizational level. An authorized session produces verifiable session metadata.¶

13. Relation to Existing Standards

TLS 1.3 [RFC8446]: Authenticates server certificate. Does not indicate authorization type. ATA adds this encoding as a TLS extension.¶
mTLS: Mutual certificate authentication establishing workload identity. Does not encode human vs AI authorization type. ATA adds semantic type encoding above the mTLS identity layer.¶
FIDO2 [FIDO-CTAP2]: Human-device binding. Human side only. ATA adds AI-side attestation and session-level type encoding. Composable.¶
SPIFFE/SPIRE: Workload identity for cloud and Kubernetes environments. Establishes infrastructure identity without human/AI semantic distinction. ATA operates as a semantic layer above SPIFFE-class identity.¶
OAuth 2.1: Authorization scope and token integrity. Permission layer. ATA is the attestation layer below. Composable.¶
RATS / EAT [RFC9334] [RFC9711]: Remote attestation architecture and token format. ATA attestation_payload uses EAT format. RATS Verifiers handle hardware-specific verification.¶
HTTP Message Signatures [RFC9421]: HTTP-layer request signing. ATA operates at the TLS session layer. Different layers; composable.¶
MCP Authorization Specification [MCP-AUTH]: OAuth-based MCP client authorization for HTTP transports. Hardware-level AI provider attestation is not specified. ATA addresses this at the TLS layer without MCP changes.¶
A2A Protocol [A2A]: Agent-to-agent communication. Signed agent cards (v1.0) establish card integrity. ATA adds session-layer hardware attestation. Composable.¶
C2PA [C2PA]: Content signing post-creation. Out of ATA scope per Section 10.¶
Certificate Transparency [RFC9162]: Potential audit model for ATA AI provider attestation registries.¶

14. Scope Boundaries

14.1. Content Authorship

ATA verifies who authorized the channel. Content authorship verification is outside scope.¶

14.2. Model Implementation

Internal model architecture, weights, and implementation details are outside attestation scope, consistent with TLS not attesting to server application behavior.¶

14.3. Provider Trustworthiness

SIGNED_AI proves a hardware-bound provider endpoint. Provider trustworthiness is a reputational concern outside protocol scope.¶

14.4. Physical Coercion

Physical security of attesting devices is a precondition for all hardware attestation schemes. Outside protocol scope, consistent with FIDO2.¶

15. Security Considerations

15.1. Content Relay

A SIGNED_HUMAN party may relay AI-generated content within an authorized session. The protocol records the human as the accountable authorizing party per Section 14. This is an intentional design boundary: the protocol establishes accountability at the session layer, not content authorship at the application layer. Continuous liveness attestation (periodic re-attestation within the data stream) is a proposed optional extension that raises the operational cost of sustained relay by requiring continuous physical presence at the attesting device. Specification deferred to a future draft.¶

15.2. TLS Middlebox Ossification

Corporate firewalls and DPI proxies may drop connections with unknown TLS extension types on port 443. ATA defines three operational modes to address deployment constraints:¶

Mode A (preferred):: TLS ClientHello extension. Full ATA handshake at connection establishment. Optimal latency.¶
Mode B (fallback):: Post-TLS ATA handshake. ATA attestation exchanged as a separate message after TLS establishment. Compatible with middleboxes that drop unknown extensions. Adds one RTT.¶
Mode C (legacy):: UNSIGNED. No ATA attestation. Backward compatible with all existing infrastructure. Recipients apply their own policy.¶

GREASE-style extension probing and automatic fallback negotiation between Mode A and Mode B to be specified in draft-01.¶

15.3. Attestation Payload Size and Privacy

EAT payloads may be several kilobytes when including certificate chains and attestation evidence. Large ClientHello extensions risk MTU fragmentation in QUIC Initial packets and additional RTT in TLS due to Initial Congestion Window constraints.¶

Mitigations under consideration for draft-01:¶

(a): Deferred attestation: ATA handshake as a post-TLS message, avoiding ClientHello size constraints.¶
(b): TLS Encrypted ClientHello (ECH): ATA attestation_payload carried inside ECH, concealing organizational metadata from passive observers and reducing fragmentation risk.¶

EAT payloads additionally reveal organizational affiliation and infrastructure metadata. Depending on deployment mode, these identifiers are visible to the peer and may be visible to passive observers when not protected by ECH or an equivalent confidentiality mechanism. The protocol is intended to provide session accountability metadata, not per-message author identity or continuous presence tracking. Privacy-preserving options (selective disclosure, zero-knowledge proofs) to be explored in future drafts. The IETF Privacy Considerations guidelines [RFC6973] apply.¶

httpsa://: ATA-attested HTTPS. Designator "a" denotes an ATA-attested channel. Follows precedent of https:// over http://.¶
wssa://: ATA-attested WebSocket Secure. Follows precedent of wss:// over ws://. Valid only as an explicit scheme; ATA via HTTP upgrade deferred to a future draft.¶

No known conflicts with the existing IANA URI scheme registry as of the date of this document.¶

17. References

17.1. Normative References

[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/info/rfc2119>.
[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/info/rfc8174>.

17.2. Informative References

[RFC8446]: Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC9711]: Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, <https://www.rfc-editor.org/info/rfc9711>.
[RFC9334]: Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/info/rfc9334>.
[RFC5280]: Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC9162]: Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, <https://www.rfc-editor.org/info/rfc9162>.
[RFC6973]: Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC9000]: Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[RFC9420]: Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, July 2023, <https://www.rfc-editor.org/info/rfc9420>.
[RFC9421]: Backman, A., Richer, J., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, <https://www.rfc-editor.org/info/rfc9421>.
[C2PA]: Coalition for Content Provenance and Authenticity, "C2PA Technical Specification, Version 2.4", 2026, <https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html>.
[FIDO-CTAP2]: FIDO Alliance, "Client to Authenticator Protocol (CTAP), Proposed Standard, Version 2.2", July 2025, <https://fidoalliance.org/specs/fido-v2.2-ps-20250714/fido-client-to-authenticator-protocol-v2.2-ps-20250714.html>.
[MCP-AUTH]: Anthropic, "Model Context Protocol Authorization Specification", 2025, <https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization>.
[A2A]: Linux Foundation, "Agent2Agent (A2A) Protocol Specification, Version 1.0", 2026, <https://a2a-protocol.org/latest/specification/>.