Independent Submission L. D. Chapman Internet-Draft Qwixl Intended status: Experimental 28 July 2026 Expires: 29 January 2027 End-to-End Encryption and Purpose-Bound Governance for Agent-to-Agent Messaging draft-chapman-a2a-mls-00 Abstract Agent-to-agent protocols increasingly carry messages between autonomous software agents acting on behalf of distinct principals, including across organisational boundaries. Existing protocols in this space secure the transport hop and authenticate the calling party, but do not provide message-level confidentiality, do not provide non-repudiable evidence of what a counterparty asserted, and do not carry machine-enforceable constraints on how a recipient may use the data conveyed. This document specifies a profile that addresses those three gaps. It defines a Governed Object: a signed, purpose-bound, expiring message envelope identified by a decentralised identifier. It specifies how such objects are exchanged inside end-to-end encrypted sessions established using the Messaging Layer Security (MLS) protocol [RFC9420], and how the MLS credential is cryptographically bound to the sending agent's identity. It defines the encapsulation of these constructs as an extension to an agent-to-agent transport, using the Agent2Agent (A2A) protocol [A2A] as the reference binding, and specifies mandatory receiver-side processing rules including replay rejection and purpose enforcement. 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." Chapman Expires 29 January 2027 [Page 1] Internet-Draft Confidential Agent Messaging July 2026 This Internet-Draft will expire on 29 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Relationship to Existing Work . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 6 4. Agent Identity . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Identifier Construction . . . . . . . . . . . . . . . . . 7 4.2. MLS Ciphersuite . . . . . . . . . . . . . . . . . . . . . 7 4.3. Credential Binding . . . . . . . . . . . . . . . . . . . 7 5. The Governed Object . . . . . . . . . . . . . . . . . . . . . 8 5.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Governance . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Canonical Serialisation . . . . . . . . . . . . . . . . . 10 5.4. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.5. Verification . . . . . . . . . . . . . . . . . . . . . . 11 6. Session Establishment . . . . . . . . . . . . . . . . . . . . 11 6.1. KeyPackage Publication . . . . . . . . . . . . . . . . . 11 6.2. Establishing a Pair Session . . . . . . . . . . . . . . . 12 6.3. Group Sessions . . . . . . . . . . . . . . . . . . . . . 12 6.4. Session Persistence . . . . . . . . . . . . . . . . . . . 12 7. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Protocol Version . . . . . . . . . . . . . . . . . . . . 12 7.2. Extension Declaration . . . . . . . . . . . . . . . . . . 13 7.3. Media Type Placement . . . . . . . . . . . . . . . . . . 13 7.4. Governed Object Part . . . . . . . . . . . . . . . . . . 14 7.5. MLS Wire Part . . . . . . . . . . . . . . . . . . . . . . 14 7.6. Handshake Part . . . . . . . . . . . . . . . . . . . . . 15 7.7. Agent Card . . . . . . . . . . . . . . . . . . . . . . . 15 7.8. Version Compatibility . . . . . . . . . . . . . . . . . . 15 7.9. Transport Authentication . . . . . . . . . . . . . . . . 16 8. Receiver Processing Rules . . . . . . . . . . . . . . . . . . 16 Chapman Expires 29 January 2027 [Page 2] Internet-Draft Confidential Agent Messaging July 2026 8.1. Mandatory Ordered Checks . . . . . . . . . . . . . . . . 16 8.2. Replay Rejection . . . . . . . . . . . . . . . . . . . . 17 8.3. Purpose Enforcement . . . . . . . . . . . . . . . . . . . 17 8.4. Rejection Behaviour . . . . . . . . . . . . . . . . . . . 18 9. Regulatory Alignment . . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10.1. What This Specification Provides . . . . . . . . . . . . 18 10.2. What It Does Not Provide . . . . . . . . . . . . . . . . 19 10.3. Availability . . . . . . . . . . . . . . . . . . . . . . 19 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11.1. Media Types . . . . . . . . . . . . . . . . . . . . . . 19 11.2. Purpose Value Registry . . . . . . . . . . . . . . . . . 20 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 13.1. Normative References . . . . . . . . . . . . . . . . . . 22 13.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 23 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction 1.1. Problem Statement Deployments of agent-to-agent messaging are moving from single- organisation orchestration towards interactions between agents that represent different principals: a person and a business, two businesses, or a citizen and a public body. Three properties that are routinely required in such interactions are not provided by the agent-to-agent protocols currently in use. Confidentiality against intermediaries. Current practice secures the transport hop, typically with TLS, and authenticates the caller, typically with OAuth 2.0, OpenID Connect, or mutual TLS. Any intermediary that terminates TLS -- a gateway, a broker, a hosting provider, or the platform operating either agent -- can read the full message content. Where the two principals are mutually independent and the message content is confidential, commercially sensitive, or personal data, transport security is insufficient. Non-repudiable assertion. A recipient frequently needs durable evidence of what the counterparty's agent asserted, and needs it to remain verifiable after the session has ended, after key rotation, and independently of any log held by an intermediary. Transport-level authentication does not produce such evidence, because it authenticates a connection rather than a statement. Machine-enforceable use constraints. When an agent discloses data to Chapman Expires 29 January 2027 [Page 3] Internet-Draft Confidential Agent Messaging July 2026 a counterparty, the disclosing principal frequently intends the disclosure to be limited: to a stated purpose, and for a bounded period. Today that intent, if expressed at all, is expressed in prose outside the protocol and is therefore not available to the receiving implementation at the moment of processing. These are not hypothetical requirements. In several jurisdictions the second and third are closely related to statutory obligations; see Section 9. 1.2. Scope This document specifies: * a signed message envelope, the Governed Object, carrying a semantic type, a payload, a declared purpose, and an expiry (Section 5); * an agent identity scheme based on Ed25519 [RFC8032] decentralised identifiers, and a mandatory cryptographic binding between that identity and the agent's MLS credential (Section 4); * establishment of MLS [RFC9420] sessions between agents, including publication and retrieval of MLS KeyPackages (Section 6); * encapsulation of MLS wire messages and Governed Objects as an extension to an agent-to-agent transport, with A2A [A2A] as the reference binding (Section 7); * mandatory receiver-side processing rules, including signature verification, expiry rejection, replay rejection, and purpose enforcement (Section 8). 1.3. Non-Goals This document does not: * define a new agent-to-agent transport, discovery mechanism, or capability description format; it layers on an existing one; * define agent tool invocation or local resource access, for which the Model Context Protocol [MCP] and comparable mechanisms are used; Chapman Expires 29 January 2027 [Page 4] Internet-Draft Confidential Agent Messaging July 2026 * provide cryptographic enforcement of purpose limitation. The purpose field is signed, tamper-evident, and mandatory to enforce at the receiver, but a non-conforming receiver that has decrypted a message can disregard it. This is a deliberate limitation, discussed in Section 10; * specify authorisation policy, business semantics, or user interface behaviour; * specify how a decentralised identifier is bound to a legal or natural identity. That binding, where required, is provided by credential presentation layered above this specification and is out of scope. 1.4. Relationship to Existing Work MLS [RFC9420] provides the group key establishment and message protection used here. This document does not modify MLS. It specifies a ciphersuite constraint, a credential-binding requirement, and a transport encapsulation. A2A [A2A] provides agent discovery, capability description, and message transport. A2A version 1.0 supports declared protocol extensions, and this document is specified as such an extension; Section 7.1 states the version this binding targets. Nothing here requires changes to A2A itself. The mechanism is transport-agnostic in principle. A2A is used as the reference binding because it is widely deployed and because its extension mechanism makes the binding expressible without protocol changes. 2. Conventions and 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. Agent: A software process that sends and receives messages on behalf of a principal. Principal: The natural person, legal person, or organisation on whose behalf an agent acts. Agent Identity: A did:key identifier [DIDKEY] encoding an Ed25519 Chapman Expires 29 January 2027 [Page 5] Internet-Draft Confidential Agent Messaging July 2026 public key, used to identify an agent and to verify its signatures. Governed Object: The signed message envelope specified in Section 5. Purpose: A short string in a Governed Object declaring the use for which the payload is disclosed. Relying Receiver: An implementation that accepts a Governed Object and acts upon its payload. 3. Architecture Overview Two agents, each holding an Ed25519 key pair, establish an MLS group containing exactly two members (a pair session) or more than two members (a group session). Application messages within that group carry Governed Objects serialised as JSON [RFC8259]. The MLS wire bytes are carried inside the agent-to-agent transport as opaque data. The transport therefore learns the identity of the endpoints and the size and timing of messages, but not the content. Principal A Principal B | | +---v-----------+ +-------v-------+ | Agent A | | Agent B | | | | | | Ed25519 key | | Ed25519 key | | did:key:zA.. | | did:key:zB.. | +---+-----------+ +-----------+---+ | | | (1) retrieve KeyPackage | |---------------------------------------------------->| | (2) MLS Welcome + ratchet tree | |---------------------------------------------------->| | | | (3) MLS application message | | = AEAD( JSON( GovernedObject ) ) | |<--------------------------------------------------->| | | +--+-----------------------------------------------------+--+ | agent-to-agent transport (e.g. A2A over HTTPS) | | sees: endpoints, size, timing. not: content | +----------------------------------------------------------+ Figure 1: Confidential agent messaging Chapman Expires 29 January 2027 [Page 6] Internet-Draft Confidential Agent Messaging July 2026 4. Agent Identity 4.1. Identifier Construction An Agent Identity is a did:key identifier [DIDKEY] encoding an Ed25519 public key. The identifier is the string did:key: followed by the multibase base58btc encoding (prefix z) of the multicodec ed25519-pub header (0xed 0x01) concatenated with the 32-byte public key. Verifiers MUST derive the public key from the identifier itself. Conforming implementations MUST NOT require network resolution of the identifier in order to verify a signature. This property is required so that a Governed Object remains verifiable offline and after the issuer's service has ceased to operate. Implementations MAY support additional DID methods. Implementations MUST support did:key. 4.2. MLS Ciphersuite Implementations MUST support MLS ciphersuite MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519 (value 0x0001 in the MLS Ciphersuites registry established by [RFC9420]). This ciphersuite is mandatory because its signature scheme is Ed25519, matching the Agent Identity key type and enabling the binding specified in Section 4.3. Implementations MAY negotiate other ciphersuites, subject to that section. 4.3. Credential Binding An agent's MLS credential MUST be a basic credential whose identity is the UTF-8 encoding of the agent's Agent Identity. Furthermore, the MLS signature_key in the agent's LeafNode MUST be the same Ed25519 public key that is encoded in that Agent Identity. This requirement is the load-bearing element of this section. Without it, an attacker who can publish a KeyPackage may assert an arbitrary DID string in the credential, and a receiver has no cryptographic basis for concluding that messages from that MLS member originate from the holder of the corresponding DID. With it, MLS membership and Governed Object authorship are bound to a single key. Chapman Expires 29 January 2027 [Page 7] Internet-Draft Confidential Agent Messaging July 2026 On receiving a KeyPackage or LeafNode, an implementation MUST verify that the credential identity parses as a did:key Ed25519 identifier and that the public key so derived is octet-for-octet equal to the LeafNode signature_key. If the check fails, the implementation MUST reject the KeyPackage and MUST NOT add the member to a group. Where a ciphersuite whose signature scheme is not Ed25519 is negotiated, the binding of Section 4.3 cannot be expressed by key equality. In that case implementations MUST instead require the credential identity to be accompanied by a proof of possession: a signature, made with the Agent Identity key, over the MLS signature_key. Definition of that proof's encoding is deferred to a future revision of this document; until it is specified, implementations that require the binding MUST use ciphersuite 0x0001. 5. The Governed Object 5.1. Structure A Governed Object is a JSON object [RFC8259] with the following members. All listed members are mandatory unless stated otherwise. Chapman Expires 29 January 2027 [Page 8] Internet-Draft Confidential Agent Messaging July 2026 +====================+========+============================+ | Member | Type | Description | +====================+========+============================+ | version | number | Format version. MUST be 1 | | | | for this specification. | +--------------------+--------+----------------------------+ | id | string | Unique object identifier. | | | | MUST be unique per issuer. | +--------------------+--------+----------------------------+ | issuerDid | string | Agent Identity of the | | | | signer. | +--------------------+--------+----------------------------+ | issuedAt | string | Issuance time, RFC 3339 | | | | date-time in UTC. | +--------------------+--------+----------------------------+ | semantic | object | Type descriptor; see | | | | below. | +--------------------+--------+----------------------------+ | payload | object | Application data. | +--------------------+--------+----------------------------+ | governance | object | Use constraints; see | | | | Section 5.2. | +--------------------+--------+----------------------------+ | signatureAlgorithm | string | MUST be "ed25519". | +--------------------+--------+----------------------------+ | signature | string | Base64 [RFC4648] Ed25519 | | | | signature. | +--------------------+--------+----------------------------+ Table 1 The semantic member has a mandatory schema member containing an absolute URI identifying the payload type, and OPTIONAL version and embeddingHint members. The id member MUST be unique per issuer and SHOULD be a UUID or other value with negligible collision probability. Receivers rely on this for replay rejection (Section 8.2). 5.2. Governance The governance member carries: Chapman Expires 29 January 2027 [Page 9] Internet-Draft Confidential Agent Messaging July 2026 +============+========+===========================================+ | Member | Type | Description | +============+========+===========================================+ | purpose | string | Mandatory. Declared use for the payload. | +------------+--------+-------------------------------------------+ | ttlSeconds | number | OPTIONAL. Lifetime in seconds from | | | | issuedAt. | +------------+--------+-------------------------------------------+ | expiresAt | string | OPTIONAL. Absolute expiry, RFC 3339 | | | | date-time. | +------------+--------+-------------------------------------------+ Table 2 If both ttlSeconds and expiresAt are present, the earlier resulting instant is the effective expiry. If neither is present, the object does not expire, and receivers SHOULD apply a locally configured maximum lifetime. Purpose strings are lowercase, colon-delimited, and hierarchical, for example comms:message or coordination:proposal. Purpose values are application domain vocabulary; this document does not define a registry, but see Section 11 for a discussion of whether one is warranted. 5.3. Canonical Serialisation The signature is computed over a canonical serialisation of the object's content, excluding signatureAlgorithm and signature. The canonical form is produced by serialising the JSON object consisting of exactly the members version, id, issuerDid, issuedAt, semantic, payload, and governance, such that: 1. object members are ordered lexicographically by their UTF-16 code unit sequence; 2. members whose value is undefined or absent are omitted; 3. array element order is preserved; 4. no insignificant whitespace is emitted; 5. strings and numbers are serialised as specified by [RFC8259]. Implementations SHOULD use JSON Canonicalization Scheme [RFC8785] where available; it satisfies the requirements above for the value space used by this specification. Chapman Expires 29 January 2027 [Page 10] Internet-Draft Confidential Agent Messaging July 2026 Nested objects within semantic, payload, and governance are canonicalised recursively by the same rules. Payload authors SHOULD avoid floating-point numbers, because canonical serialisation of floating-point values is a known source of cross-language interoperability failure. Where numeric precision matters, payloads SHOULD encode values as strings or as integers in a stated minor unit. 5.4. Signing The signature is Ed25519(privateKey, UTF8(canonicalForm)) as specified in [RFC8032], encoded per [RFC4648] Section 4 (base64 with padding). 5.5. Verification A verifier MUST: 1. confirm version equals 1; 2. confirm signatureAlgorithm equals "ed25519"; 3. derive the Ed25519 public key from issuerDid per Section 4; 4. recompute the canonical form per Section 5.3; 5. verify the signature. Verification failure MUST cause the object to be rejected. 6. Session Establishment 6.1. KeyPackage Publication An agent that accepts incoming sessions publishes MLS KeyPackages. Where the A2A binding of Section 7 is used, the agent SHOULD expose them at the path /mls/key-package relative to its A2A service endpoint, returning a JSON object with members did (the Agent Identity) and wire (the base64-encoded MLS KeyPackage). Publishing endpoints MUST rate-limit KeyPackage retrieval. KeyPackages are single-use in MLS; unbounded retrieval permits exhaustion of an agent's pre-published supply. Retrievers MUST perform the credential binding check of Section 4.3 on the retrieved KeyPackage before use. Chapman Expires 29 January 2027 [Page 11] Internet-Draft Confidential Agent Messaging July 2026 6.2. Establishing a Pair Session The initiating agent creates an MLS group containing itself, then commits an Add proposal for the responding agent using the retrieved KeyPackage, and delivers the resulting Welcome message and ratchet tree to the responder using the handshake encapsulation of Section 7.6. Where the responder's identity was learned from an out-of-band invitation that asserted a specific Agent Identity, the initiator MUST verify that the retrieved KeyPackage's credential identity equals the asserted identity, and MUST abort establishment on mismatch. Absent this check, an attacker who controls the endpoint named in an invitation can substitute their own identity. 6.3. Group Sessions Sessions with more than two members follow MLS group semantics unchanged. Any member with commit rights, as determined by local policy, MAY add or remove members. This document places no additional requirements on group membership policy, but implementations MUST apply the credential binding check of Section 4.3 to every joining member. 6.4. Session Persistence Implementations that persist MLS group state across process restarts MUST protect that state at rest with confidentiality and integrity equivalent to the protection afforded to long-term private keys. Group state contains the secrets necessary to decrypt past and future epochs. 7. Encapsulation This section specifies the A2A [A2A] binding. 7.1. Protocol Version This binding is specified against A2A version 1.0. Two properties of that version are relied upon: a message part carries a mediaType member of its own, and a message may enumerate the extensions it depends upon. A2A version 0.3 provided neither. Implementations MAY interoperate with peers speaking version 0.3 by applying Section 7.8, and the reference implementation does so, but a conforming implementation of this document transmits version 1.0. Chapman Expires 29 January 2027 [Page 12] Internet-Draft Confidential Agent Messaging July 2026 Throughout this section, part and message members are named as they appear in the JSON serialisation on the wire. An implementation generated from the A2A protocol buffer schema will present the part content as a language-level tagged union; that representation is an artefact of code generation and is not observable by a peer. 7.2. Extension Declaration An agent supporting this specification MUST declare the extension URI https://atom.qwixl.dev/a2a/data-object/v1 in the capabilities.extensions member of its Agent Card. A message carrying any part specified in this section SHOULD additionally list that URI in the message's extensions member. A receiver MUST NOT require the member to be present, since a peer speaking A2A version 0.3 has no such member to populate, and MUST NOT rely upon it to identify a part: the media type is authoritative. Editor's note: this URI reflects the deployed reference implementation. Should this document be adopted by a standards body, the URI is expected to be reassigned under that body's namespace. Implementations SHOULD treat the URI as an opaque identifier. 7.3. Media Type Placement Each part specified below is identified by one of the media types in Section 11. A sender MUST set the media type in the part's mediaType member, and SHOULD also set a mediaType member within the part's data object with the identical value. A receiver MUST determine the media type from the part's mediaType member when that member is present and non-empty, and MUST fall back to the mediaType member within the data object otherwise. Where both are present and they disagree, the receiver MUST reject the part. The duplication exists because version 0.3 of A2A had no mediaType member on a part, obliging deployments written against A2A version 0.3 to carry the media type inside the payload. A receiver that reads only the inner member therefore continues to interoperate. A sender MAY omit the inner member once no such receiver remains reachable; this document retains it as a SHOULD rather than a MUST for that reason. Chapman Expires 29 January 2027 [Page 13] Internet-Draft Confidential Agent Messaging July 2026 7.4. Governed Object Part A Governed Object MAY be carried unencrypted in an A2A message part whose data member is a JSON object with members mediaType, set to application/vnd.atom.data-object+json;version=1 per Section 7.3, and object, set to the Governed Object. { "data": { "mediaType": "application/vnd.atom.data-object+json;version=1", "object": { ... Governed Object ... } }, "mediaType": "application/vnd.atom.data-object+json;version=1" } Unencrypted carriage provides authenticity and governance metadata but not confidentiality. Implementations MUST NOT use unencrypted carriage for personal data or otherwise confidential payloads where an MLS session can be established. Implementations SHOULD default to encrypted carriage. 7.5. MLS Wire Part MLS wire messages are carried in an A2A message part whose data member is a JSON object with members mediaType, set to application/ vnd.atom.mls-wire+cbor;version=1 per Section 7.3, and wire, set to the base64 encoding [RFC4648] of the MLSMessage as serialised per [RFC9420]. { "data": { "mediaType": "application/vnd.atom.mls-wire+cbor;version=1", "wire": "" }, "mediaType": "application/vnd.atom.mls-wire+cbor;version=1" } The decrypted application message plaintext is the UTF-8 encoding of a JSON object with a member object containing a Governed Object. Implementations MAY define additional members; receivers MUST ignore members they do not recognise. Chapman Expires 29 January 2027 [Page 14] Internet-Draft Confidential Agent Messaging July 2026 7.6. Handshake Part MLS Welcome messages and the accompanying ratchet tree are carried in an A2A message part whose data member is a JSON object with member mediaType set to application/vnd.atom.mls-handshake+json;version=1 per Section 7.3, and members conveying the base64-encoded Welcome and ratchet tree. 7.7. Agent Card An agent's endpoints are declared in the supportedInterfaces member of its Agent Card, an ordered list in which the first entry is the sender's preferred interface and each entry states the A2A protocol version that interface speaks. A2A version 0.3 instead declared a single endpoint in a top-level url member; an implementation reading a card MUST NOT depend on that member. An agent MAY declare more than one interface at the same URL in order to serve more than one protocol version, and the reference implementation does so. An Agent Card MAY carry one or more JWS signatures in its signatures member. Where an agent's identity is a did:key as specified in Section 4, the signature's kid header parameter SHOULD be that identifier, because the verifying key is then recoverable from the identifier itself and card verification requires no key distribution mechanism and no further network retrieval. A relying party that verifies a card signature MUST treat the identifier in kid as the identity that produced the card, and MUST NOT infer from a valid signature that the card's contents are endorsed by any other identity named within it. Transport security establishes control of the origin serving a card; it establishes nothing about the agent the card describes. An unsigned card therefore permits any party controlling an origin to publish a card asserting any agent identity, and a relying party that acts on such an assertion -- for instance, to associate a domain with an agent -- SHOULD require a signature whose kid matches the asserted identity. 7.8. Version Compatibility An implementation MAY accept and originate A2A version 0.3 messages in addition to version 1.0. Where it does: * The version of a received message is determined by the A2A-Version header field. Its absence denotes version 0.3. Chapman Expires 29 January 2027 [Page 15] Internet-Draft Confidential Agent Messaging July 2026 * The version to use towards a given peer is determined by that peer's Agent Card, per Section 7.7. * A part received from a version 0.3 peer carries the media type only within the data object, which Section 7.3 accommodates. Deployment order is not symmetric, and this has operational consequence. A receiver that accepts both versions is compatible with senders of either, but a sender that has begun transmitting version 1.0 is not compatible with a receiver that accepts only version 0.3. In a network upgraded incrementally, every receiver MUST therefore be capable of the newer version before any sender originates it. 7.9. Transport Authentication The transport carrying these parts MUST authenticate the calling party using a mechanism defined by the underlying protocol, such as those enumerated in [A2A]. An unauthenticated transport endpoint permits an unbounded set of parties to consume the receiver's resources, to enqueue messages, and to attempt session establishment. End-to-end encryption does not mitigate this: MLS protects content, not availability. Implementations MUST NOT expose an unauthenticated message-submission endpoint in production. 8. Receiver Processing Rules 8.1. Mandatory Ordered Checks On receiving a Governed Object, whether from a decrypted MLS application message or from unencrypted carriage, a Relying Receiver MUST perform the following checks, and MUST perform them in this order: 1. Structural validation against Section 5. Reject on failure. 2. Signature verification per Section 5. Reject on failure. 3. Where the object arrived inside an MLS session, confirm that issuerDid equals the Agent Identity in the credential of the MLS member that sent the message. Reject on mismatch. 4. Expiry evaluation per Section 5.2. Reject if expired. 5. Replay rejection per Section 8.2. Reject if already seen. Chapman Expires 29 January 2027 [Page 16] Internet-Draft Confidential Agent Messaging July 2026 6. Purpose enforcement per Section 8.3. Reject if not permitted. Only after all six checks succeed may the receiver act upon payload. Check 3 is essential and is easily omitted. Without it, any member of a group can emit an object bearing another member's issuerDid; the signature check alone does not detect this, because the signature is valid -- it is simply not made by the party that sent it. Implementations MUST NOT treat a valid signature as evidence of who transmitted the message. 8.2. Replay Rejection A Relying Receiver MUST reject a Governed Object whose id it has previously accepted from the same issuerDid. Receivers MUST retain accepted (issuerDid, id) pairs for at least the maximum object lifetime they will accept. Where a receiver applies a maximum accepted lifetime, retention for that period is sufficient, because an older object is rejected by check 4 regardless. Absent this requirement, a passive observer of unencrypted carriage, or any member of an MLS group, can re-present a previously valid object. Where objects convey instructions with side effects -- a payment authorisation, a booking confirmation, a consent grant -- replay is directly exploitable. 8.3. Purpose Enforcement A Relying Receiver MUST maintain, per processing context, a set of permitted purpose values, and MUST reject an object whose governance.purpose is not in that set. The set MUST be determined by the receiver's own configuration for the context in which the object is being processed. It MUST NOT be derived from the object itself, nor from any value under the sender's control. Receivers MUST NOT use a payload for a purpose other than the one declared, and MUST NOT retain it beyond its expiry, save where an independent legal obligation requires retention. Chapman Expires 29 January 2027 [Page 17] Internet-Draft Confidential Agent Messaging July 2026 8.4. Rejection Behaviour A receiver rejecting an object SHOULD emit a diagnostic distinguishable by cause, for operator use. A receiver SHOULD NOT return to the sender information that distinguishes between rejection causes beyond what is necessary for interoperability, because fine- grained rejection reasons assist an attacker in probing receiver configuration -- in particular in enumerating the permitted purpose set. 9. Regulatory Alignment This section is informative. The constructs specified here correspond to obligations that exist independently of this document in several jurisdictions. In the European Union, [GDPR] Article 5(1)(b) requires that personal data be collected for specified purposes and not further processed incompatibly with them; Article 5(1)(c) requires data minimisation; and Article 5(1)(e) requires that data be kept no longer than necessary. A Governed Object carries the specified purpose and the retention limit as signed metadata available to the receiving implementation at the moment of processing, rather than as prose in an agreement negotiated out of band. The mandatory receiver-side enforcement of Section 8.3 makes those constraints operative in code. This does not constitute compliance, and this document does not offer legal advice. It observes only that the mechanism places the relevant facts where an implementation can act on them, which is a precondition for compliance being demonstrable rather than merely asserted. 10. Security Considerations 10.1. What This Specification Provides Within an MLS session, message content is confidential from the transport and from any intermediary, with the forward secrecy and post-compromise security properties of [RFC9420]. Governed Objects are authenticated and integrity protected by Ed25519 signatures that remain verifiable independently of the session and after it ends, providing durable evidence of authorship. The credential binding of Section 4.3 ties MLS membership to the same key, so that transmission and authorship cannot be separated. Chapman Expires 29 January 2027 [Page 18] Internet-Draft Confidential Agent Messaging July 2026 10.2. What It Does Not Provide Purpose limitation is not cryptographically enforced. A receiver that has decrypted a message is in possession of the plaintext and can disregard the declared purpose and expiry. The mechanism provides a signed, non-repudiable record of the constraint under which disclosure was made, which converts an undetectable breach into an attributable one. It does not prevent the breach. Constructions that would provide stronger enforcement, such as purpose-bound decryption keys or confidential computing attestation, are out of scope. A DID is not an identity. It denotes control of a key. Binding a DID to a legal or natural person requires a credential presentation layer above this specification. Compromise of an agent's Ed25519 private key compromises both its MLS membership and its ability to sign Governed Objects, precisely because Section 4.3 unifies them. Implementations MUST protect this key accordingly, and SHOULD use non-exportable key storage where the platform provides it. The unification is a deliberate trade: it eliminates a class of impersonation attack at the cost of concentrating key-compromise impact. MLS provides no protection against traffic analysis, and this specification adds none. Endpoints, message sizes, and timing are visible to the transport. 10.3. Availability An unauthenticated message-submission endpoint is a denial-of-service vector regardless of encryption; see Section 7. KeyPackage exhaustion is a related vector; see Section 6. Implementations that queue messages for offline recipients MUST bound queue size and MUST apply the checks of Section 8 on dequeue rather than only on enqueue. Deferring validation to dequeue without bounding the queue permits an attacker to cause unbounded storage consumption with unvalidated input. 11. IANA Considerations 11.1. Media Types This document uses three media types, currently registered in neither the standards nor the vendor tree. The deployed reference implementation uses vendor-tree names. Chapman Expires 29 January 2027 [Page 19] Internet-Draft Confidential Agent Messaging July 2026 If this document advances, the author requests registration of the following in the standards tree, with the vendor-tree names retained as deprecated aliases: +======================+=============================+==============+ | Proposed | Deployed | Purpose | +======================+=============================+==============+ | application/ | application/vnd.atom.data- | Governed | | governed-object+json | object+json | Object | +----------------------+-----------------------------+--------------+ | application/mls- | application/vnd.atom.mls- | MLS wire | | wire+cbor | wire+cbor | message | +----------------------+-----------------------------+--------------+ | application/mls- | application/vnd.atom.mls- | Welcome and | | handshake+json | handshake+json | ratchet | | | | tree | +----------------------+-----------------------------+--------------+ Table 3 Complete registration templates will be supplied in a subsequent revision. 11.2. Purpose Value Registry This document does not establish a registry of purpose values. Purpose vocabulary is application domain specific, and premature centralisation would impede the domain experimentation that ought to inform any eventual registry. The author solicits input on whether a registry of a small number of cross-domain purposes -- for instance a value denoting an authorisation to effect a payment -- would be of sufficient value to warrant the coordination cost, given that such values are the ones for which cross-implementation misinterpretation is most consequential. 12. Implementation Status This section is to be removed before publication as an RFC, per [RFC7942]. An open source implementation exists under the Apache License 2.0 at https://github.com/Qwixl/Atom, and is deployed in a small public network. Implemented and interoperability-tested between two independent processes over HTTP: Chapman Expires 29 January 2027 [Page 20] Internet-Draft Confidential Agent Messaging July 2026 * Governed Object construction, canonical serialisation, Ed25519 signing, and verification, including tamper and expiry rejection. * did:key Ed25519 identity derivation without network resolution. * MLS pair and group sessions using ciphersuite 0x0001 via the ts- mls library, including KeyPackage publication and retrieval, Welcome and ratchet tree delivery, application message encryption and decryption, and group state persistence. * The A2A binding of Section 7 at protocol version 1.0, including extension declaration in the Agent Card and per message, all three part encodings, and media type placement in both positions per Section 7.3. * Version compatibility with A2A version 0.3 per Section 7.8, in both directions, tested against the published version 0.3 implementation rather than against a substitute: a version 1.0 sender delivering to a version 0.3 receiver, and a version 0.3 sender delivering to a version 1.0 receiver. * Agent Card signing and verification per Section 7.7, with kid set to the agent's did:key and the verifying key recovered from that identifier without network retrieval. The relying check described there -- requiring the signing identity to match an asserted identity before associating a domain with an agent -- is applied. * Purpose enforcement by receiver-configured allowlist, and expiry rejection. * Out-of-band invitation with identity assertion, and abort on identity mismatch. Specified here but NOT yet implemented at the time of writing: * The credential binding key-equality check of Section 4.3. The implementation places the DID in the MLS credential but does not verify that the LeafNode signature key matches it. This requirement was identified while preparing this document. * Replay rejection (Section 8.2). No (issuerDid, id) history is retained. * Check 3 of Section 8, confirming issuerDid against the sending MLS member's credential. * Transport authentication on the message-submission endpoint (Section 7), which is presently unauthenticated. Chapman Expires 29 January 2027 [Page 21] Internet-Draft Confidential Agent Messaging July 2026 * Validation on dequeue for messages queued to offline recipients (Section 10), which presently occurs only on enqueue. The author notes that the last five items were each identified by the exercise of writing this specification, having not been apparent from the working implementation. This is offered as evidence for the general proposition that specification and implementation are not redundant activities. A further instance arose in preparing this document. The reference implementation's own documentation described a part using the tagged- union form produced by its code generator, rather than the JSON actually transmitted. The discrepancy was invisible to that implementation, which both produced and consumed the same internal representation, and would have been discovered only by a second implementation in another language attempting to interoperate from the description. The requirement in Section 7.1 that members be named as they appear on the wire, and the encapsulation vectors of Appendix A, exist to prevent a recurrence. 13. References 13.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, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . Chapman Expires 29 January 2027 [Page 22] Internet-Draft Confidential Agent Messaging July 2026 [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, . 13.2. Informative References [A2A] A2A Project (Linux Foundation), "Agent2Agent (A2A) Protocol Specification, Version 1.0", 2026, . [DIDKEY] W3C Credentials Community Group, "The did:key Method", n.d., . [GDPR] European Union, "Regulation (EU) 2016/679 (General Data Protection Regulation)", 2016, . [MCP] Anthropic, "Model Context Protocol", n.d., . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . Appendix A. Test Vectors Machine-readable test vectors accompany this document, comprising: signed Governed Objects with known Ed25519 key pairs and their canonical serialisations; objects with mutated payloads that MUST fail verification; expired objects; objects whose declared purpose is outside a stated permitted set; a replayed object pair; and a KeyPackage whose credential identity does not match its signature key, which MUST be rejected per Section 4.3. Chapman Expires 29 January 2027 [Page 23] Internet-Draft Confidential Agent Messaging July 2026 A second group of vectors covers the encapsulation of Section 7 as serialised JSON, independently of any Governed Object contained within: parts carrying the media type in the part member, in the data member, and in both; a part whose two media type members disagree, which MUST be rejected per Section 7.3; and a part bearing no media type in either position. These vectors exist because the encapsulation is the layer at which two implementations in different languages first fail to interoperate, and it is the layer least well served by reading either implementation's source. Vectors are published at https://github.com/Qwixl/Atom under spec/ vectors/. An implementation claiming conformance to this document SHOULD produce the specified outcome for every vector. The vectors were derived from this document's text rather than generated from the reference implementation, so that the two are capable of disagreeing. On first execution they did: the reference implementation treated governance.expiresAt as authoritative whenever present and never compared it to the interval implied by ttlSeconds, so a sender could extend a short-lived object's lifetime indefinitely by supplying an additional distant absolute expiry. Because the governance block is covered by the signature, the resulting object was valid under every other check. This is the origin of the requirement in Section 5.2 that the earlier instant govern, and it is offered as a concrete instance of why vectors written from specification text are worth the effort of producing. Acknowledgements This work builds directly on the MLS protocol [RFC9420] and on the A2A protocol [A2A]. The author thanks the authors and contributors of both. Author's Address Luke Daniel Chapman Qwixl Email: luke.chapman@qwixl.com Chapman Expires 29 January 2027 [Page 24]