Network Working Group T. Baur Internet-Draft Baur Software Intended status: Informational 20 May 2026 Expires: 21 November 2026 Principal Agent Protocol (PAP) draft-baur-pap-00 Abstract This document specifies the Principal Agent Protocol (PAP), a cryptographic protocol for human-controlled agent-to-agent transactions. PAP establishes a trust model rooted in human principals, defines hierarchical delegation through signed mandates, enforces context minimization through selective disclosure at the protocol level, and provides session ephemerality as a structural guarantee. The protocol uses no novel cryptographic primitives and requires no central registry, token economy, or trusted third party. 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 21 November 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Baur Expires 21 November 2026 [Page 1] Internet-Draft PAP May 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6 1.2. Design Goals . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 7 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 3. Trust Model and Threat Model . . . . . . . . . . . . . . . . 8 3.1. Trust Hierarchy . . . . . . . . . . . . . . . . . . . . . 8 3.2. Trust Assumptions . . . . . . . . . . . . . . . . . . . . 8 3.3. Threat Model . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Explicit Non-Goals . . . . . . . . . . . . . . . . . . . 10 4. Identity Layer . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. DID Method . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. DID Document . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Principal Keypair . . . . . . . . . . . . . . . . . . . . 11 4.4. Session Keypair . . . . . . . . . . . . . . . . . . . . . 11 5. Mandate Structure and Delegation Rules . . . . . . . . . . . 12 5.1. Mandate Object . . . . . . . . . . . . . . . . . . . . . 12 5.2. Mandate Signing . . . . . . . . . . . . . . . . . . . . . 14 5.3. Mandate Hashing . . . . . . . . . . . . . . . . . . . . . 14 5.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4.1. 5.4.1. Scope Object . . . . . . . . . . . . . . . . 14 5.4.2. 5.4.2. ScopeAction Object . . . . . . . . . . . . . 15 5.4.3. 5.4.3. DisclosureSet Object . . . . . . . . . . . . 15 5.4.4. 5.4.4. DisclosureEntry Object . . . . . . . . . . . 16 5.4.5. 5.4.4.1. TEE Requirement for No-Retention Disclosures . . . . . . . . . . . . . . . . . . . . . 17 5.4.6. 5.4.5. Scope Containment . . . . . . . . . . . . . . 18 5.5. Delegation Rules . . . . . . . . . . . . . . . . . . . . 18 5.6. Mandate Chain Verification . . . . . . . . . . . . . . . 18 5.7. Decay State Machine . . . . . . . . . . . . . . . . . . . 19 5.7.1. 5.7.1. State Transitions . . . . . . . . . . . . . . 19 5.7.2. 5.7.2. Decay Computation . . . . . . . . . . . . . . 20 6. Session Lifecycle . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Session State Machine . . . . . . . . . . . . . . . . . . 21 6.2. Capability Token . . . . . . . . . . . . . . . . . . . . 22 6.2.1. 6.2.1. Token Signing . . . . . . . . . . . . . . . . 22 Baur Expires 21 November 2026 [Page 2] Internet-Draft PAP May 2026 6.2.2. 6.2.2. Token Verification . . . . . . . . . . . . . 23 6.3. Six-Phase Handshake . . . . . . . . . . . . . . . . . . . 23 6.3.1. 6.3.1. Phase 1: Token Presentation . . . . . . . . . 24 6.3.2. 6.3.2. Phase 2: Ephemeral DID Exchange . . . . . . . 24 6.3.3. 6.3.3. Phase 3: Disclosure . . . . . . . . . . . . . 25 6.3.4. 6.3.4. Phase 4: Execution . . . . . . . . . . . . . 25 6.3.5. 6.3.5. Phase 5: Receipt Co-Signing . . . . . . . . . 25 6.3.6. 6.3.6. Phase 6: Session Close . . . . . . . . . . . 25 7. SD-JWT Disclosure Protocol . . . . . . . . . . . . . . . . . 25 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 26 7.2. SD-JWT Object . . . . . . . . . . . . . . . . . . . . . . 26 7.3. Disclosure Object . . . . . . . . . . . . . . . . . . . . 26 7.4. Commitment Computation . . . . . . . . . . . . . . . . . 27 7.5. Disclosure Verification . . . . . . . . . . . . . . . . . 27 7.6. Zero-Disclosure Sessions . . . . . . . . . . . . . . . . 28 8. Protocol Messages and Envelope . . . . . . . . . . . . . . . 28 8.1. Protocol Message Types . . . . . . . . . . . . . . . . . 28 8.2. Envelope . . . . . . . . . . . . . . . . . . . . . . . . 29 8.2.1. 8.2.1. Envelope Signing . . . . . . . . . . . . . . 30 8.2.2. 8.2.2. Envelope Verification . . . . . . . . . . . . 31 9. Marketplace Advertisement Schema . . . . . . . . . . . . . . 31 9.1. Agent Advertisement . . . . . . . . . . . . . . . . . . . 31 9.2. Provider Object . . . . . . . . . . . . . . . . . . . . . 33 9.3. Disclosure Filtering . . . . . . . . . . . . . . . . . . 33 9.4. Advertisement Signing . . . . . . . . . . . . . . . . . . 33 9.5. Advertisement Hashing . . . . . . . . . . . . . . . . . . 34 9.6. Operator Metrics . . . . . . . . . . . . . . . . . . . . 34 10. Federation Protocol . . . . . . . . . . . . . . . . . . . . . 36 10.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 36 10.2. Registry Peer . . . . . . . . . . . . . . . . . . . . . 36 10.3. Federation Messages . . . . . . . . . . . . . . . . . . 36 10.4. Federation Endpoints . . . . . . . . . . . . . . . . . . 37 10.5. Content-Hash Deduplication . . . . . . . . . . . . . . . 38 10.6. Peer Discovery . . . . . . . . . . . . . . . . . . . . . 38 10.7. Peer Trust Signals . . . . . . . . . . . . . . . . . . . 38 10.7.1. 10.7.1. Signal Categories . . . . . . . . . . . . . 38 10.7.2. 10.7.2. Peer Vouch . . . . . . . . . . . . . . . . 39 10.7.3. 10.7.3. Vouch Budget . . . . . . . . . . . . . . . 39 11. Receipt Format . . . . . . . . . . . . . . . . . . . . . . . 39 11.1. Transaction Receipt . . . . . . . . . . . . . . . . . . 40 11.2. Receipt Signing . . . . . . . . . . . . . . . . . . . . 41 11.3. Co-Signing Protocol . . . . . . . . . . . . . . . . . . 41 11.4. Receipt Verification . . . . . . . . . . . . . . . . . . 41 11.5. Privacy Properties . . . . . . . . . . . . . . . . . . . 41 11.6. Session Attestation . . . . . . . . . . . . . . . . . . 42 12. Verifiable Credential Envelope . . . . . . . . . . . . . . . 42 12.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 43 12.2. VC Structure . . . . . . . . . . . . . . . . . . . . . . 43 Baur Expires 21 November 2026 [Page 3] Internet-Draft PAP May 2026 12.3. Credential Signing . . . . . . . . . . . . . . . . . . . 43 13. Extension Points . . . . . . . . . . . . . . . . . . . . . . 44 13.1. Payment Proof . . . . . . . . . . . . . . . . . . . . . 44 13.1.1. 13.1.1. Bolt11Hash . . . . . . . . . . . . . . . . 44 13.1.2. 13.1.2. CashuTokenHash . . . . . . . . . . . . . . 45 13.1.3. 13.1.3. Payment Proof Properties . . . . . . . . . 45 13.1.4. 13.1.4. Ecash Blind Signature Protocol . . . . . . 45 13.2. Payment Proof Verification . . . . . . . . . . . . . . . 47 13.2.1. 13.2.1. Receipt Payment Proof Commitment . . . . . 47 13.3. Continuity Tokens . . . . . . . . . . . . . . . . . . . 47 13.3.1. 13.3.1. Continuity Token Lifecycle . . . . . . . . 48 13.3.2. 13.3.2. Continuity Token Properties . . . . . . . . 48 13.4. Auto-Approval Policies . . . . . . . . . . . . . . . . . 49 13.4.1. 13.4.1. Auto-Approval Constraints . . . . . . . . . 49 13.5. M-of-N Social Recovery . . . . . . . . . . . . . . . . . 50 13.5.1. 13.5.1. Recovery Mandate . . . . . . . . . . . . . 50 13.5.2. 13.5.2. Recovery Request . . . . . . . . . . . . . 50 13.5.3. 13.5.3. Partial Recovery Signature (Blind) . . . . 51 13.5.4. 13.5.4. Recovery Proof Assembly . . . . . . . . . . 52 13.5.5. 13.5.5. Revocation Proof and Broadcast . . . . . . 52 13.5.6. 13.5.6. NotarySet Registry . . . . . . . . . . . . 53 13.5.7. 13.5.7. Security Properties . . . . . . . . . . . . 53 13.6. TEE Attestation . . . . . . . . . . . . . . . . . . . . 54 13.6.1. 13.6.1. Attestation Object . . . . . . . . . . . . 54 13.6.2. 13.6.2. Attestation Verification . . . . . . . . . 54 13.6.3. 13.6.3. Trust Boundaries . . . . . . . . . . . . . 55 13.6.4. 13.6.4. Implementation Notes . . . . . . . . . . . 55 13.7. Payment Proof Validation . . . . . . . . . . . . . . . . 55 13.7.1. 13.7.1. Proof Format Registry . . . . . . . . . . . 55 13.7.2. 13.7.2. Validation Requirements . . . . . . . . . . 56 13.7.3. 13.7.3. Privacy Requirements . . . . . . . . . . . 56 13.8. Chat and Real-Time Communication . . . . . . . . . . . . 56 13.8.1. 13.8.1. Overview . . . . . . . . . . . . . . . . . 57 13.8.2. 13.8.2. Capability Grant . . . . . . . . . . . . . 57 13.8.3. 13.8.3. Phase 4 Streaming Mode . . . . . . . . . . 57 13.8.4. 13.8.4. Message Format (DIDComm basicmessage) . . . 58 13.8.5. 13.8.5. Receipt . . . . . . . . . . . . . . . . . . 58 13.8.6. 13.8.6. Group Chat Rooms . . . . . . . . . . . . . 58 13.8.7. 13.8.7. Audio and Video . . . . . . . . . . . . . . 59 13.8.8. 13.8.8. Privacy Properties . . . . . . . . . . . . 59 14. Transport Binding . . . . . . . . . . . . . . . . . . . . . . 59 14.1. HTTP/JSON Transport . . . . . . . . . . . . . . . . . . 59 14.2. Agent Server Endpoints . . . . . . . . . . . . . . . . . 60 14.3. Agent Handler Interface . . . . . . . . . . . . . . . . 60 14.4. Endpoint Resolution . . . . . . . . . . . . . . . . . . 61 14.5. Content Type . . . . . . . . . . . . . . . . . . . . . . 61 14.6. Error Handling . . . . . . . . . . . . . . . . . . . . . 61 14.7. WebSocket Transport . . . . . . . . . . . . . . . . . . 62 Baur Expires 21 November 2026 [Page 4] Internet-Draft PAP May 2026 14.7.1. 14.7.1. Connection Lifecycle . . . . . . . . . . . 62 14.7.2. 14.7.2. Endpoint Format . . . . . . . . . . . . . . 62 14.7.3. 14.7.3. Message Framing . . . . . . . . . . . . . . 62 14.7.4. 14.7.4. Sequence Enforcement . . . . . . . . . . . 62 14.8. Oblivious HTTP (OHTTP) Transport . . . . . . . . . . . . 62 14.8.1. 14.8.1. Architecture . . . . . . . . . . . . . . . 63 14.8.2. 14.8.2. Encapsulation . . . . . . . . . . . . . . . 63 14.8.3. 14.8.3. Key Configuration . . . . . . . . . . . . . 63 14.8.4. 14.8.4. Relay Selection . . . . . . . . . . . . . . 63 14.9. DIDComm Transport . . . . . . . . . . . . . . . . . . . 63 14.9.1. 14.9.1. Message Mapping . . . . . . . . . . . . . . 63 14.9.2. 14.9.2. Encryption . . . . . . . . . . . . . . . . 64 14.9.3. 14.9.3. Service Endpoint . . . . . . . . . . . . . 64 14.10. Transport Negotiation . . . . . . . . . . . . . . . . . 64 14.11. DIDComm v2 Envelope Compatibility . . . . . . . . . . . 65 14.11.1. 14.11.1. Design Principles . . . . . . . . . . . . 65 14.11.2. 14.11.2. Plaintext Messages . . . . . . . . . . . 65 14.11.3. 14.11.3. Signed Messages (Ed25519 JWS) . . . . . . 66 14.11.4. 14.11.4. Encrypted Messages (ECDH-ES + A256GCM JWE) . . . . . . . . . . . . . . . . . . . . . . . . 66 14.11.5. 14.11.5. Ed25519 to X25519 Key Conversion . . . . 67 14.11.6. 14.11.6. Translation Rules . . . . . . . . . . . . 67 15. PAP URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 68 15.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 68 15.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 69 15.3. Resolution . . . . . . . . . . . . . . . . . . . . . . . 70 15.4. Action Type and Query Parameters . . . . . . . . . . . . 71 15.5. Recapture Semantics (pap+https://, pap+wss://) . . . . . 71 15.6. Link Rendering . . . . . . . . . . . . . . . . . . . . . 72 15.7. Special Authorities . . . . . . . . . . . . . . . . . . 72 16. Security Considerations . . . . . . . . . . . . . . . . . . . 73 16.1. Cryptographic Algorithms . . . . . . . . . . . . . . . . 73 16.2. Key Management . . . . . . . . . . . . . . . . . . . . . 73 16.3. Nonce Management . . . . . . . . . . . . . . . . . . . . 74 16.4. Replay Protection . . . . . . . . . . . . . . . . . . . 74 16.5. Denial of Service . . . . . . . . . . . . . . . . . . . 74 16.6. Man-in-the-Middle . . . . . . . . . . . . . . . . . . . 74 16.7. Context Leakage . . . . . . . . . . . . . . . . . . . . 75 16.8. Mandate Chain Depth . . . . . . . . . . . . . . . . . . 75 16.9. Clock Skew . . . . . . . . . . . . . . . . . . . . . . . 75 16.10. Canonical JSON Determinism . . . . . . . . . . . . . . . 75 16.11. Attack Surface Summary . . . . . . . . . . . . . . . . . 75 Appendix A. Example: Zero-Disclosure Search . . . . . . . . . . 76 A.1. A.1. Setup . . . . . . . . . . . . . . . . . . . . . . . 76 A.2. A.2. Root Mandate . . . . . . . . . . . . . . . . . . . 77 A.3. A.3. Marketplace Query . . . . . . . . . . . . . . . . . 77 A.4. A.4. Session Handshake . . . . . . . . . . . . . . . . . 77 A.5. A.5. Receipt . . . . . . . . . . . . . . . . . . . . . . 77 Baur Expires 21 November 2026 [Page 5] Internet-Draft PAP May 2026 Appendix B. Example: Selective Disclosure Flight Booking . . . . 78 B.1. B.1. Disclosure Set . . . . . . . . . . . . . . . . . . 78 B.2. B.2. SD-JWT Claims . . . . . . . . . . . . . . . . . . . 78 B.3. B.3. Marketplace Filtering . . . . . . . . . . . . . . . 78 B.4. B.4. Receipt . . . . . . . . . . . . . . . . . . . . . . 78 Appendix C. Example: 4-Level Delegation Chain . . . . . . . . . 79 Appendix D. Conformance Test Matrix . . . . . . . . . . . . . . 79 D.1. D.1. Core Protocol Tests . . . . . . . . . . . . . . . . 79 D.2. D.2. Transport Tests . . . . . . . . . . . . . . . . . . 83 D.3. D.3. Extension Tests . . . . . . . . . . . . . . . . . . 83 D.4. D.4. Federation Tests . . . . . . . . . . . . . . . . . 85 D.5. D.5. Trust Invariant Summary . . . . . . . . . . . . . . 85 Appendix E. References . . . . . . . . . . . . . . . . . . . . . 86 E.1. Normative References . . . . . . . . . . . . . . . . . . 86 E.2. Informative References . . . . . . . . . . . . . . . . . 87 Appendix F. IANA and Vocabulary References . . . . . . . . . . . 87 F.1. Schema.org Vocabulary . . . . . . . . . . . . . . . . . . 87 F.2. W3C Standards . . . . . . . . . . . . . . . . . . . . . . 88 F.3. IETF Standards . . . . . . . . . . . . . . . . . . . . . 88 F.4. WebAuthn . . . . . . . . . . . . . . . . . . . . . . . . 89 F.5. Multicodec . . . . . . . . . . . . . . . . . . . . . . . 89 F.6. Reserved Namespace Prefixes . . . . . . . . . . . . . . . 89 Appendix G. Changelog . . . . . . . . . . . . . . . . . . . . . 90 G.1. v1.0 (2026-03-24) . . . . . . . . . . . . . . . . . . . . 90 G.2. v0.7 (2026-03-10) . . . . . . . . . . . . . . . . . . . . 90 G.3. v0.6 (2026-02-28) . . . . . . . . . . . . . . . . . . . . 90 G.4. v0.4 (2026-02-01) . . . . . . . . . . . . . . . . . . . . 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 91 1. Introduction 1.1. Problem Statement Existing agent-to-agent protocols authenticate agents as platform entities, not as delegates of human principals. None enforce context minimization at the protocol level. Disclosure is implementation- dependent. Session ephemerality is undefined. Execution isolation is absent—agents run in the same address space as the orchestrator or other services, creating blast radius problems even when disclosure is minimized. Economic models underneath these protocols are compatible with platform capture through cloud compute metering. 1.2. Design Goals PAP is designed to satisfy the following goals: 1. The human principal is the root of trust for every transaction. Baur Expires 21 November 2026 [Page 6] Internet-Draft PAP May 2026 2. Context disclosure is enforced by the protocol at the request boundary (via SD-JWT). 3. Execution is isolated at the process boundary via OS-level capabilities. 4. Sessions are ephemeral by design; no persistent correlation. 5. Delegation is hierarchical with cryptographically enforced bounds. 6. Co-signed receipts prove both disclosure scope and execution constraints. 7. No novel cryptography, no token economy, no central registry. 8. Any compliant implementation MUST be buildable from this document alone, without reference to a specific programming language. 1.3. Protocol Overview A PAP transaction involves: * A *human principal* who holds a device-bound keypair. * An *orchestrator agent* operating under a root mandate. * One or more *downstream agents* operating under delegated mandates, each executing in sandboxed isolation. * A *marketplace* for agent discovery and disclosure filtering. * A *6-phase session handshake* between pairs of agents. * *Request boundary security* via SD-JWT selective disclosure (minimize what the agent sees). * *Execution boundary security* via OS sandboxing (minimize what the agent can do). * *Co-signed receipts* recording property references and enforcement proof, never values. 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 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals, as shown here. 2.1. Definitions *Principal:* A human user who holds the root keypair and is the ultimate authority over all agent actions taken on their behalf. *Orchestrator:* An agent that holds the root mandate from the principal. The orchestrator is the only agent that MAY hold the principal's full context. It delegates scoped mandates to downstream agents. Baur Expires 21 November 2026 [Page 7] Internet-Draft PAP May 2026 *Mandate:* A signed authorization object that specifies what an agent is permitted to do, what context it may disclose, and when the authorization expires. *Mandate Chain:* An ordered sequence of mandates from root to leaf, each cryptographically linked to its parent. *Scope:* The set of actions a mandate permits. Deny-by-default: an empty scope permits nothing. *Disclosure Set:* The set of context classes an agent holds and the conditions under which they may be shared. *Capability Token:* A single-use, signed authorization to open a session with a specific agent for a specific action. *Session DID:* An ephemeral did:key identifier generated for a single session and discarded at session close. *Receipt:* A co-signed record of a transaction that contains property type references but never property values. *Decay State:* The lifecycle state of a mandate as it approaches or passes its TTL without renewal. 3. Trust Model and Threat Model 3.1. Trust Hierarchy The PAP trust hierarchy is: Human Principal (device-bound keypair, root of trust) +-- Orchestrator Agent (root mandate, full principal context) +-- Downstream Agent (task mandate, scoped context) +-- Marketplace Agent (own principal chain) The principal's device-bound keypair is the sole root of trust. Every agent in a transaction MUST carry a cryptographically verifiable mandate chain traceable to this root. 3.2. Trust Assumptions +======================+=======================================+ | Assumption | Verification Method | +======================+=======================================+ | Principal keypair | WebAuthn device binding (Section 4.3) | | not compromised | | +----------------------+---------------------------------------+ Baur Expires 21 November 2026 [Page 8] Internet-Draft PAP May 2026 | Orchestrator | Mandate chain verification | | delegates correctly | (Section 5.6) | +----------------------+---------------------------------------+ | Session keys not | Single-use per session, discarded at | | leaked | close | +----------------------+---------------------------------------+ | Clocks approximately | RFC 3339 timestamps; receivers SHOULD | | synchronized | reject tokens with skew exceeding | | | implementation-defined thresholds | +----------------------+---------------------------------------+ | Ed25519 not broken | Cryptographic library security; | | | algorithm agility reserved for future | | | versions | +----------------------+---------------------------------------+ Table 1 3.3. Threat Model PAP is designed to defend against the following threats: *T1. Context profiling.* An adversary correlates a principal's transactions across sessions to build a behavioral profile. _Mitigation:_ Ephemeral session DIDs (Section 6.3) ensure each session is cryptographically unlinkable. *T2. Over-disclosure.* An agent discloses more principal context than the principal authorized. _Mitigation:_ SD-JWT selective disclosure (Section 7) structurally prevents disclosure of claims not included in the disclosure set. Marketplace filtering (Section 9.3) excludes agents whose requirements exceed the mandate before any session is established. *T3. Delegation bypass.* A downstream agent acts outside its delegated scope. _Mitigation:_ Scope containment (Section 5.4) and TTL bounds (Section 5.5) are verified cryptographically at each level of the mandate chain. *T4. Replay attacks.* An adversary replays a captured capability token to open an unauthorized session. _Mitigation:_ Nonce consumption (Section 6.2) ensures each token is single-use. *T5. Mandate tampering.* An adversary modifies a mandate in the chain. _Mitigation:_ Parent hash binding (Section 5.3) and Ed25519 signatures (Section 5.2) detect any modification. Baur Expires 21 November 2026 [Page 9] Internet-Draft PAP May 2026 *T6. Platform capture.* A platform operator accumulates control over agent transactions through infrastructure dependency. _Mitigation:_ Federated discovery (Section 10), no central registry, no token economy, principal-held keys. Marketplace registries MUST NOT rank query results by operator metrics (Section 9.6) — ranking power is platform capture power. Trust evaluation is the principal's responsibility. *T7. Payment linkability.* A payment is correlated with the principal's identity. _Mitigation:_ Chaumian ecash blind-signed tokens (Section 13.1) provide unlinkable proof of value transfer. 3.4. Explicit Non-Goals The following are explicitly out of scope for PAP: 1. Compatibility with token economy monetization. 2. Enclave-as-equivalent-to-local trust models. 3. Identity recovery through platform operators. 4. Central registries for agent discovery. 5. Runtime scope expansion of mandates. 6. Arbitrary code execution in the orchestrator context. 7. Any extension that trades trust guarantees for adoption ease. 4. Identity Layer 4.1. DID Method PAP uses the did:key method as defined in [DID-KEY]. All identifiers MUST use Ed25519 public keys with the following derivation: did:key:z Where: - 0xed01 is the multicodec prefix for Ed25519 public keys. - public_key_bytes is the 32-byte Ed25519 public key. - base58btc is Bitcoin's base58 encoding. - The z prefix indicates base58btc multibase encoding. Implementations MUST support did:key resolution by extracting the public key bytes from the DID string: 1. Strip the did:key:z prefix. 2. Base58-decode the remainder. 3. Verify the first two bytes are 0xed and 0x01. 4. The remaining 32 bytes are the Ed25519 public key. Baur Expires 21 November 2026 [Page 10] Internet-Draft PAP May 2026 4.2. DID Document A DID document for a PAP identity MUST conform to [DID-CORE] and contain: { "@context": "https://www.w3.org/ns/did/v1", "id": "did:key:z...", "verificationMethod": [{ "id": "did:key:z...#key-1", "type": "Ed25519VerificationKey2020", "controller": "did:key:z...", "publicKeyMultibase": "z" }], "authentication": ["did:key:z...#key-1"] } A DID document MUST NOT contain any personal information. It contains only the public key and verification method reference. 4.3. Principal Keypair The principal keypair is the root of trust. It MUST be an Ed25519 keypair. In production deployments, the private key SHOULD be bound to a hardware authenticator via WebAuthn [WEBAUTHN]. Implementations MUST support the PrincipalSigner interface: * did() -> String -- The did:key identifier. * sign(message: bytes) -> bytes -- Ed25519 signature (64 bytes). * verifying_key() -> Ed25519PublicKey -- The public key. Implementations MAY use software keys for development and testing. Production deployments SHOULD use WebAuthn-backed keys. 4.4. Session Keypair A session keypair is an ephemeral Ed25519 keypair generated fresh for each protocol session. Session keypairs: * MUST be generated using a cryptographically secure random number generator. * MUST NOT be derived from or linked to the principal keypair. * MUST be discarded when the session closes. * MUST NOT be persisted to stable storage. Baur Expires 21 November 2026 [Page 11] Internet-Draft PAP May 2026 The session DID is derived using the same did:key method as the principal DID. An observer MUST NOT be able to determine whether a did:key identifier represents a principal or a session key. 5. Mandate Structure and Delegation Rules 5.1. Mandate Object A mandate is the core delegation primitive. It authorizes an agent to perform specific actions with specific context. A mandate MUST contain the following fields: Baur Expires 21 November 2026 [Page 12] Internet-Draft PAP May 2026 +=====================+=============+========+====================+ | Field |Type |Required| Description | +=====================+=============+========+====================+ | principal_did |String |REQUIRED| DID of the human | | | | | principal (root of | | | | | trust) | +---------------------+-------------+--------+--------------------+ | agent_did |String |REQUIRED| DID of the agent | | | | | receiving this | | | | | mandate | +---------------------+-------------+--------+--------------------+ | issuer_did |String |REQUIRED| DID of the entity | | | | | signing this | | | | | mandate | +---------------------+-------------+--------+--------------------+ | parent_mandate_hash |String or |REQUIRED| SHA-256 hash of | | |null | | the parent | | | | | mandate, or null | | | | | for root mandates | +---------------------+-------------+--------+--------------------+ | scope |Scope |REQUIRED| Permitted actions | | | | | (Section 5.4) | +---------------------+-------------+--------+--------------------+ | disclosure_set |DisclosureSet|REQUIRED| Context classes | | | | | and sharing | | | | | conditions | | | | | (Section 5.4.3) | +---------------------+-------------+--------+--------------------+ | ttl |DateTime |REQUIRED| Expiry timestamp | | | | | (RFC 3339) | +---------------------+-------------+--------+--------------------+ | decay_state |DecayState |REQUIRED| Current lifecycle | | | | | state | | | | | (Section 5.7) | +---------------------+-------------+--------+--------------------+ | issued_at |DateTime |REQUIRED| Issuance timestamp | | | | | (RFC 3339) | +---------------------+-------------+--------+--------------------+ | payment_proof |PaymentProof |OPTIONAL| ZK payment | | |or null | | commitment | | | | | (Section 13.1) | +---------------------+-------------+--------+--------------------+ | signature |String or |OPTIONAL| Ed25519 signature | | |null | | (base64url-no-pad) | +---------------------+-------------+--------+--------------------+ Table 2 Baur Expires 21 November 2026 [Page 13] Internet-Draft PAP May 2026 5.2. Mandate Signing A mandate MUST be signed by the issuer's Ed25519 signing key. The canonical form for signing MUST be computed as follows: 1. Construct a JSON object containing all mandate fields EXCEPT signature. 2. DateTime fields MUST be serialized as RFC 3339 strings. 3. Null fields MUST be included as JSON null. 4. Serialize the JSON object to bytes. 5. Compute the Ed25519 signature over these bytes. 6. Encode the 64-byte signature using base64url without padding (RFC 4648 Section 5, no = padding). The canonical JSON object MUST contain exactly these keys: { "principal_did": "...", "agent_did": "...", "issuer_did": "...", "parent_mandate_hash": null, "scope": { ... }, "disclosure_set": { ... }, "ttl": "2026-03-15T20:00:00+00:00", "issued_at": "2026-03-15T16:00:00+00:00", "payment_proof": null } 5.3. Mandate Hashing The mandate hash is used for parent-child linking in delegation chains. It MUST be computed as: 1. Compute the canonical form (Section 5.2, step 1-4). 2. Apply SHA-256 to the canonical bytes. 3. Encode the 32-byte digest using base64url without padding. The hash MUST be deterministic: the same mandate MUST always produce the same hash. 5.4. Scope 5.4.1. 5.4.1. Scope Object A scope defines the set of permitted actions. It is deny-by-default: an agent with an empty scope MUST NOT perform any action. Baur Expires 21 November 2026 [Page 14] Internet-Draft PAP May 2026 { "actions": [ { "action": "schema:SearchAction", "object": "schema:WebPage", "conditions": {} } ] } +=========+======================+==========+=======================+ | Field | Type | Required | Description | +=========+======================+==========+=======================+ | actions | Array of ScopeAction | REQUIRED | The permitted | | | | | actions | +---------+----------------------+----------+-----------------------+ Table 3 5.4.2. 5.4.2. ScopeAction Object +============+=========+==========+=============================+ | Field | Type | Required | Description | +============+=========+==========+=============================+ | action | String | REQUIRED | Schema.org action type | | | | | (e.g., schema:SearchAction) | +------------+---------+----------+-----------------------------+ | object | String | OPTIONAL | Schema.org object type | | | or null | | constraint (e.g., | | | | | schema:Flight) | +------------+---------+----------+-----------------------------+ | conditions | Object | OPTIONAL | Protocol-level conditions | | | | | (key-value pairs). | | | | | Default: empty object. | +------------+---------+----------+-----------------------------+ Table 4 Action and object type references MUST use the schema: prefix for Schema.org vocabulary. Implementations MAY define additional namespaced prefixes for domain-specific vocabularies. 5.4.3. 5.4.3. DisclosureSet Object The disclosure set defines what context an agent holds and the conditions for sharing it. Baur Expires 21 November 2026 [Page 15] Internet-Draft PAP May 2026 { "entries": [ { "type": "schema:Person", "permitted_properties": ["schema:name", "schema:nationality"], "prohibited_properties": ["schema:email", "schema:telephone"], "session_only": true, "no_retention": true } ] } +=========+==========================+==========+================+ | Field | Type | Required | Description | +=========+==========================+==========+================+ | entries | Array of DisclosureEntry | REQUIRED | The disclosure | | | | | entries | +---------+--------------------------+----------+----------------+ Table 5 5.4.4. 5.4.4. DisclosureEntry Object +=======================+=========+==========+=====================+ | Field | Type | Required | Description | +=======================+=========+==========+=====================+ | type | String | REQUIRED | Schema.org type | | | | | (e.g., | | | | | schema:Person) | +-----------------------+---------+----------+---------------------+ | permitted_properties | Array | REQUIRED | Properties the | | | of | | agent MAY disclose | | | String | | | +-----------------------+---------+----------+---------------------+ | prohibited_properties | Array | REQUIRED | Properties the | | | of | | agent MUST NOT | | | String | | disclose | +-----------------------+---------+----------+---------------------+ | session_only | Boolean | OPTIONAL | If true, disclosed | | | | | data is valid only | | | | | for the session | | | | | duration. Default: | | | | | false. | +-----------------------+---------+----------+---------------------+ | no_retention | Boolean | OPTIONAL | If true, the | | | | | receiving party | | | | | MUST NOT retain | | | | | disclosed data | Baur Expires 21 November 2026 [Page 16] Internet-Draft PAP May 2026 | | | | beyond the session. | | | | | Default: false. | +-----------------------+---------+----------+---------------------+ Table 6 Property references MUST use Schema.org property names with the schema: prefix. *Property Reference Format:* When used in receipts or marketplace advertisements, a fully qualified property reference is formed as {type}.{property}, e.g., schema:Person.schema:name. 5.4.5. 5.4.4.1. TEE Requirement for No-Retention Disclosures When a disclosure entry has no_retention set to true, the receiving agent MUST provide TEE attestation (Section 13.6) during session establishment. If the receiving agent cannot provide valid TEE attestation, the initiating agent MUST NOT disclose properties from that entry. Without TEE attestation, no_retention is a contractual constraint only — the protocol cannot enforce data deletion on an untrusted host. Implementations SHOULD clearly communicate this limitation to principals when TEE attestation is unavailable. An implementation's disclosure validation MUST return one of three states to the caller: +=================+===============================================+ | State | Meaning | +=================+===============================================+ | NotRequired | No no_retention entries in the disclosure set | +-----------------+-----------------------------------------------+ | TeeEnforced | TEE attestation present; retention constraint | | | is cryptographic | +-----------------+-----------------------------------------------+ | ContractualOnly | No TEE available; no_retention is a | | | contractual term only | +-----------------+-----------------------------------------------+ Table 7 Implementations that support the TEE extension (Section 13.6) MUST treat ContractualOnly as an error. Implementations without TEE support MAY proceed with ContractualOnly but MUST expose this state to the caller so the principal can make an informed decision. Baur Expires 21 November 2026 [Page 17] Internet-Draft PAP May 2026 5.4.6. 5.4.5. Scope Containment A child scope S_c is *contained by* a parent scope S_p (written S_c <= S_p) if and only if for every action A_c in S_c, there exists an action A_p in S_p such that: 1. A_c.action == A_p.action 2. If A_p.object is non-null, then A_c.object MUST equal A_p.object. 3. If A_p.object is null, then A_c.object MAY be any value (including null). 4. If A_p.object is non-null and A_c.object is null, the containment check MUST fail. A child MUST NOT broaden an object constraint. 5.5. Delegation Rules When an agent delegates a mandate to a child agent, the following rules MUST be enforced: *R1. Scope Containment:* The child mandate's scope MUST be contained by the parent mandate's scope (Section 5.4.5). If scope containment fails, the delegation MUST be rejected. *R2. TTL Bound:* The child mandate's ttl MUST NOT exceed the parent mandate's ttl. If the child TTL exceeds the parent TTL, the delegation MUST be rejected. *R3. Parent Hash Binding:* The child mandate's parent_mandate_hash MUST equal the hash (Section 5.3) of the parent mandate's canonical form. *R4. Issuer Chain:* The child mandate's issuer_did MUST equal the parent mandate's agent_did. The child mandate MUST be signed by the parent mandate's agent_did key. *R5. Principal Propagation:* The child mandate's principal_did MUST equal the parent mandate's principal_did. *R6. Root Mandate:* A root mandate MUST have parent_mandate_hash set to null. A root mandate's issuer_did MUST equal its principal_did. 5.6. Mandate Chain Verification A mandate chain is an ordered array of mandates [M_0, M_1, ..., M_n] where M_0 is the root mandate. Verification MUST proceed as follows: 1. M_0.parent_mandate_hash MUST be null. 2. M_0.signature MUST verify against the principal's public key. Baur Expires 21 November 2026 [Page 18] Internet-Draft PAP May 2026 3. For each i from 1 to n: a. M_i.parent_mandate_hash MUST equal hash(M_{i-1}). b. M_i.scope MUST satisfy scope containment against M_{i-1}.scope (Section 5.4.5). c. M_i.ttl MUST NOT exceed M_{i-1}.ttl. d. M_i.signature MUST verify against the public key of M_{i-1}.agent_did. If any check fails, the entire chain MUST be rejected. 5.7. Decay State Machine A mandate's decay state tracks its lifecycle as the TTL progresses. The decay state MUST be one of: +===========+===============================+ | State | Description | +===========+===============================+ | Active | Full scope, within TTL | +-----------+-------------------------------+ | Degraded | Reduced scope, TTL within | | | decay window, renewal pending | +-----------+-------------------------------+ | ReadOnly | No execution permitted, | | | observation only, TTL expired | +-----------+-------------------------------+ | Suspended | No activity, awaiting | | | principal review | +-----------+-------------------------------+ Table 8 5.7.1. 5.7.1. State Transitions The following transitions are valid: Active --> Degraded --> ReadOnly --> Suspended ^ | | | | | +-- renewal -+-- renewal -+ Baur Expires 21 November 2026 [Page 19] Internet-Draft PAP May 2026 +===========+===========+=========================================+ | From | To | Condition | +===========+===========+=========================================+ | Active | Degraded | Remaining TTL <= implementation-defined | | | | decay window | +-----------+-----------+-----------------------------------------+ | Degraded | ReadOnly | TTL expired without renewal | +-----------+-----------+-----------------------------------------+ | ReadOnly | Suspended | Implementation-defined timeout without | | | | principal action | +-----------+-----------+-----------------------------------------+ | Degraded | Active | Mandate renewed by issuer | +-----------+-----------+-----------------------------------------+ | ReadOnly | Active | Mandate renewed by issuer | +-----------+-----------+-----------------------------------------+ | Suspended | (none) | Suspended mandates MUST NOT be renewed. | | | | Principal MUST issue a new mandate. | +-----------+-----------+-----------------------------------------+ Table 9 Any transition not listed above MUST be rejected. 5.7.2. 5.7.2. Decay Computation An implementation SHOULD compute the current decay state as: function compute_decay_state(mandate, decay_window_seconds): now = current_utc_time() if now > mandate.ttl: if mandate.decay_state == Suspended: return Suspended else: return ReadOnly else: remaining = mandate.ttl - now (in seconds) if remaining <= decay_window_seconds: return Degraded else: return Active The decay_window_seconds parameter is implementation-defined. Implementations SHOULD document their chosen value. 6. Session Lifecycle Baur Expires 21 November 2026 [Page 20] Internet-Draft PAP May 2026 6.1. Session State Machine A session tracks the state of a transaction between two agents. The session state MUST be one of: +===========+===================================================+ | State | Description | +===========+===================================================+ | Initiated | Capability token presented, awaiting verification | +-----------+---------------------------------------------------+ | Open | Handshake complete, session DIDs exchanged | +-----------+---------------------------------------------------+ | Executed | Transaction executed within session | +-----------+---------------------------------------------------+ | Closed | Session closed, ephemeral keys discarded | +-----------+---------------------------------------------------+ Table 10 Valid transitions: Initiated --> Open --> Executed --> Closed | ^ +----------> Closed (early) ------+ ^ Open -------> Closed (early) -----+ +===========+==========+========================================+ | From | To | Trigger | +===========+==========+========================================+ | Initiated | Open | Session DID exchange completed | +-----------+----------+----------------------------------------+ | Initiated | Closed | Early termination (rejection or error) | +-----------+----------+----------------------------------------+ | Open | Executed | Action executed | +-----------+----------+----------------------------------------+ | Open | Closed | Early termination | +-----------+----------+----------------------------------------+ | Executed | Closed | Session close message sent | +-----------+----------+----------------------------------------+ Table 11 Any transition not listed above MUST be rejected. Baur Expires 21 November 2026 [Page 21] Internet-Draft PAP May 2026 6.2. Capability Token A capability token is a single-use authorization to open a session. It MUST contain the following fields: +============+==========+==========+================================+ | Field | Type | Required | Description | +============+==========+==========+================================+ | id | String | REQUIRED | Unique token identifier | | | | | (UUID v4) | +------------+----------+----------+--------------------------------+ | target_did | String | REQUIRED | DID of the agent this token | | | | | authorizes a session with | +------------+----------+----------+--------------------------------+ | action | String | REQUIRED | Schema.org action type this | | | | | token authorizes | +------------+----------+----------+--------------------------------+ | nonce | String | REQUIRED | Single-use nonce (UUID v4), | | | | | consumed on session | | | | | initiation | +------------+----------+----------+--------------------------------+ | issuer_did | String | REQUIRED | DID of the issuing agent | | | | | (typically the | | | | | orchestrator) | +------------+----------+----------+--------------------------------+ | issued_at | DateTime | REQUIRED | Issuance timestamp (RFC | | | | | 3339) | +------------+----------+----------+--------------------------------+ | expires_at | DateTime | REQUIRED | Expiry timestamp (RFC 3339) | +------------+----------+----------+--------------------------------+ | signature | String | OPTIONAL | Ed25519 signature | | | or null | | (base64url-no-pad) | +------------+----------+----------+--------------------------------+ Table 12 6.2.1. 6.2.1. Token Signing The token canonical form MUST be: Baur Expires 21 November 2026 [Page 22] Internet-Draft PAP May 2026 { "id": "...", "target_did": "...", "action": "...", "nonce": "...", "issuer_did": "...", "issued_at": "...", "expires_at": "..." } Signing follows the same procedure as mandate signing (Section 5.2). 6.2.2. 6.2.2. Token Verification A receiving agent MUST verify a capability token as follows: 1. token.target_did MUST match the receiver's DID. 2. token.nonce MUST NOT appear in the receiver's consumed nonce set. 3. The current time MUST NOT exceed token.expires_at. 4. token.signature MUST verify against the public key of token.issuer_did. If all checks pass, the receiver MUST immediately add token.nonce to its consumed nonce set. A nonce, once consumed, MUST never be accepted again. 6.3. Six-Phase Handshake The session handshake consists of six phases. Each phase involves a message exchange between the initiating agent (I) and the receiving agent (R). Baur Expires 21 November 2026 [Page 23] Internet-Draft PAP May 2026 Phase Direction Message Data ----- --------- ------------------- -------------------------------- 1a I -> R TokenPresentation CapabilityToken 1b R -> I TokenAccepted session_id, receiver_session_did R -> I TokenRejected reason (terminates handshake) 2a I -> R SessionDidExchange initiator_session_did 2b R -> I SessionDidAck (empty) 3a I -> R DisclosureOffer disclosures (may be empty array) 3b R -> I DisclosureAccepted (empty) 4 R -> I ExecutionResult result (Schema.org JSON-LD) 5a I -> R ReceiptForCoSign half-signed TransactionReceipt 5b R -> I ReceiptCoSigned fully co-signed TransactionReceipt 6a I -> R SessionClose session_id 6b R -> I SessionClosed (empty) 6.3.1. 6.3.1. Phase 1: Token Presentation The initiating agent presents a signed capability token. The receiving agent verifies the token (Section 6.2.2). On acceptance, the receiver MUST: 1. Generate a fresh session keypair (Section 4.4). 2. Create a session in the Initiated state. 3. Return a TokenAccepted message containing the session ID and the receiver's ephemeral session DID. On rejection, the receiver MUST return a TokenRejected message with a reason string. The handshake terminates. 6.3.2. 6.3.2. Phase 2: Ephemeral DID Exchange The initiating agent generates its own fresh session keypair and sends a SessionDidExchange message containing its session DID. On receipt, the receiver MUST: 1. Transition the session state from Initiated to Open. 2. Store the initiator's session DID. 3. Return a SessionDidAck message. After Phase 2, both parties have exchanged ephemeral session DIDs. All subsequent envelope signatures (Section 8.2) MUST use session keys. Baur Expires 21 November 2026 [Page 24] Internet-Draft PAP May 2026 6.3.3. 6.3.3. Phase 3: Disclosure The initiating agent sends a DisclosureOffer containing an array of SD-JWT disclosures (Section 7). The array MAY be empty for zero- disclosure sessions. The receiver MUST: 1. Verify each disclosure against the SD-JWT commitment (Section 7.3). 2. Return a DisclosureAccepted message. If disclosure verification fails, the receiver SHOULD return an Error message and close the session. 6.3.4. 6.3.4. Phase 4: Execution The receiver executes the requested action and returns an ExecutionResult message containing a Schema.org JSON-LD result object. The session state MUST transition from Open to Executed. 6.3.5. 6.3.5. Phase 5: Receipt Co-Signing The initiating agent constructs a TransactionReceipt (Section 11), signs it with its session key, and sends it as ReceiptForCoSign. The receiving agent MUST: 1. Verify the initiator's signature on the receipt. 2. Add its own co-signature using its session key. 3. Return the fully co-signed receipt as ReceiptCoSigned. 6.3.6. 6.3.6. Phase 6: Session Close Either party MAY initiate session close by sending a SessionClose message containing the session ID. On receipt of SessionClose, the other party MUST: 1. Return a SessionClosed message. 2. Transition the session state to Closed. 3. Discard all ephemeral session keys. After Phase 6, both parties MUST discard their session keypairs. Session DIDs MUST NOT be reused. 7. SD-JWT Disclosure Protocol Baur Expires 21 November 2026 [Page 25] Internet-Draft PAP May 2026 7.1. Overview PAP uses Selective Disclosure JWT (SD-JWT) as defined in [SD-JWT-08] for context disclosure during the session handshake. SD-JWT allows the principal to hold multiple claims but disclose only those permitted by the mandate. 7.2. SD-JWT Object An SD-JWT MUST contain: +===========+=========+===========+===========================+ | Field | Type | Required | Description | +===========+=========+===========+===========================+ | issuer | String | REQUIRED | DID of the claim issuer | | | | | (typically the principal) | +-----------+---------+-----------+---------------------------+ | claims | Object | REQUIRED | All claims as key-value | | | | (private) | pairs | +-----------+---------+-----------+---------------------------+ | salts | Object | REQUIRED | Per-claim random salts | | | | (private) | (UUID v4) | +-----------+---------+-----------+---------------------------+ | signature | String | OPTIONAL | Ed25519 signature over | | | or null | | commitment bytes | | | | | (base64url-no-pad) | +-----------+---------+-----------+---------------------------+ Table 13 The claims and salts fields are private to the holder and MUST NOT be transmitted in their entirety. Only selected disclosures (Section 7.3) are transmitted. 7.3. Disclosure Object A disclosure reveals a single claim. It MUST contain: Baur Expires 21 November 2026 [Page 26] Internet-Draft PAP May 2026 +=======+==========+==========+================================+ | Field | Type | Required | Description | +=======+==========+==========+================================+ | salt | String | REQUIRED | The claim-specific random salt | +-------+----------+----------+--------------------------------+ | key | String | REQUIRED | The claim key | +-------+----------+----------+--------------------------------+ | value | Any JSON | REQUIRED | The claim value | | | value | | | +-------+----------+----------+--------------------------------+ Table 14 7.4. Commitment Computation The SD-JWT commitment is signed to bind all possible disclosures. 1. For each claim (key, value) with salt s: * Construct: {"salt": s, "key": key, "value": value} * Hash: SHA-256(JSON_bytes(disclosure)) * Encode: base64url-no-pad 2. Collect all hashes and sort lexicographically. 3. Construct commitment bytes: { "issuer": "", "disclosure_hashes": ["", "", ...] } 4. Sign: Ed25519_sign(JSON_bytes(commitment)) 7.5. Disclosure Verification A verifier MUST: 1. Verify the SD-JWT signature over the commitment bytes using the issuer's public key. 2. For each received disclosure: a. Compute hash = base64url(SHA- 256(JSON_bytes(disclosure))). b. Verify that hash is present in the signed disclosure_hashes array. If any disclosure hash is not found in the commitment, the verification MUST fail. Baur Expires 21 November 2026 [Page 27] Internet-Draft PAP May 2026 7.6. Zero-Disclosure Sessions A session MAY proceed with zero disclosures. In this case: * The DisclosureOffer message carries an empty disclosures array. * The SD-JWT signature MUST still verify (the commitment contains hashes for all claims, but none are revealed). * The receiver MUST accept an empty disclosure set without error. 8. Protocol Messages and Envelope 8.1. Protocol Message Types All protocol messages are serialized as JSON objects with a type discriminator field. The following message types are defined: Baur Expires 21 November 2026 [Page 28] Internet-Draft PAP May 2026 +====================+=======+===========+========================+ | Type | Phase | Direction | Fields | +====================+=======+===========+========================+ | TokenPresentation | 1 | I->R | token: CapabilityToken | +--------------------+-------+-----------+------------------------+ | TokenAccepted | 1 | R->I | session_id: String, | | | | | receiver_session_did: | | | | | String | +--------------------+-------+-----------+------------------------+ | TokenRejected | 1 | R->I | reason: String | +--------------------+-------+-----------+------------------------+ | SessionDidExchange | 2 | I->R | initiator_session_did: | | | | | String | +--------------------+-------+-----------+------------------------+ | SessionDidAck | 2 | R->I | (no fields) | +--------------------+-------+-----------+------------------------+ | DisclosureOffer | 3 | I->R | disclosures: Array of | | | | | JSON values | +--------------------+-------+-----------+------------------------+ | DisclosureAccepted | 3 | R->I | (no fields) | +--------------------+-------+-----------+------------------------+ | ExecutionResult | 4 | R->I | result: JSON value | | | | | (Schema.org JSON-LD) | +--------------------+-------+-----------+------------------------+ | ReceiptForCoSign | 5 | I->R | receipt: | | | | | TransactionReceipt | +--------------------+-------+-----------+------------------------+ | ReceiptCoSigned | 5 | R->I | receipt: | | | | | TransactionReceipt | +--------------------+-------+-----------+------------------------+ | SessionClose | 6 | Either | session_id: String | +--------------------+-------+-----------+------------------------+ | SessionClosed | 6 | Either | (no fields) | +--------------------+-------+-----------+------------------------+ | Error | Any | Either | code: String, message: | | | | | String | +--------------------+-------+-----------+------------------------+ Table 15 8.2. Envelope Protocol messages are transmitted inside an envelope that provides routing, sequencing, and integrity. Baur Expires 21 November 2026 [Page 29] Internet-Draft PAP May 2026 +============+=================+==========+====================+ | Field | Type | Required | Description | +============+=================+==========+====================+ | id | String | REQUIRED | Unique envelope | | | | | identifier (UUID | | | | | v4) | +------------+-----------------+----------+--------------------+ | session_id | String | REQUIRED | Session this | | | | | envelope belongs | | | | | to | +------------+-----------------+----------+--------------------+ | sender | String | REQUIRED | DID of the sender | +------------+-----------------+----------+--------------------+ | recipient | String | REQUIRED | DID of the | | | | | intended recipient | +------------+-----------------+----------+--------------------+ | sequence | Integer | REQUIRED | Monotonically | | | | | increasing | | | | | sequence number | | | | | within the session | +------------+-----------------+----------+--------------------+ | payload | ProtocolMessage | REQUIRED | The protocol | | | | | message | +------------+-----------------+----------+--------------------+ | timestamp | DateTime | REQUIRED | ISO 8601 timestamp | +------------+-----------------+----------+--------------------+ | signature | Bytes or null | OPTIONAL | Ed25519 signature | | | | | over signable | | | | | bytes | +------------+-----------------+----------+--------------------+ Table 16 8.2.1. 8.2.1. Envelope Signing The signable bytes for an envelope MUST be computed as: SHA-256(session_id_bytes || sequence_big_endian_8_bytes || payload_json_bytes) Where || denotes concatenation and sequence_big_endian_8_bytes is the sequence number as an 8-byte big-endian integer. Before Phase 2 (DID exchange), the signature field MAY be null because the capability token carries its own signature from the issuer. After Phase 2, all envelopes MUST be signed by the sender's ephemeral session key. Baur Expires 21 November 2026 [Page 30] Internet-Draft PAP May 2026 8.2.2. 8.2.2. Envelope Verification The recipient MUST: 1. Verify recipient matches its own DID. 2. Verify sequence is strictly greater than the last received sequence number for this session. 3. If signature is present, verify it against the sender's session public key. 9. Marketplace Advertisement Schema 9.1. Agent Advertisement An agent advertisement declares an agent's capabilities, disclosure requirements, and return types. Advertisements use Schema.org vocabulary and JSON-LD structure. Baur Expires 21 November 2026 [Page 31] Internet-Draft PAP May 2026 +=====================+==========+==========+======================+ | Field | Type | Required | Description | +=====================+==========+==========+======================+ | @context | String | REQUIRED | MUST be | | | | | "https://schema.org" | +---------------------+----------+----------+----------------------+ | @type | String | REQUIRED | MUST be | | | | | "schema:Service" | +---------------------+----------+----------+----------------------+ | name | String | REQUIRED | Human-readable agent | | | | | name | +---------------------+----------+----------+----------------------+ | provider | Provider | REQUIRED | Provider | | | | | organization | | | | | (Section 9.2) | +---------------------+----------+----------+----------------------+ | capability | Array of | REQUIRED | Schema.org action | | | String | | types the agent can | | | | | perform | +---------------------+----------+----------+----------------------+ | object_types | Array of | REQUIRED | Schema.org object | | | String | | types the agent | | | | | operates on | +---------------------+----------+----------+----------------------+ | requires_disclosure | Array of | REQUIRED | Fully qualified | | | String | | property references | | | | | the agent requires | | | | | (e.g., | | | | | schema:Person.name) | +---------------------+----------+----------+----------------------+ | returns | Array of | REQUIRED | Schema.org types the | | | String | | agent returns | +---------------------+----------+----------+----------------------+ | ttl_min | Integer | OPTIONAL | Minimum session TTL | | | | | in seconds. | | | | | Default: 300. | +---------------------+----------+----------+----------------------+ | signed_by | String | REQUIRED | DID that signed this | | | | | advertisement | +---------------------+----------+----------+----------------------+ | signature | String | OPTIONAL | Ed25519 signature | | | or null | | (base64url-no-pad) | +---------------------+----------+----------+----------------------+ Table 17 Baur Expires 21 November 2026 [Page 32] Internet-Draft PAP May 2026 9.2. Provider Object +=======+========+==========+===============================+ | Field | Type | Required | Description | +=======+========+==========+===============================+ | @type | String | REQUIRED | MUST be "schema:Organization" | +-------+--------+----------+-------------------------------+ | name | String | REQUIRED | Organization name | +-------+--------+----------+-------------------------------+ | did | String | REQUIRED | Operator DID | +-------+--------+----------+-------------------------------+ Table 18 9.3. Disclosure Filtering A marketplace registry MUST support two query modes: *Query by action:* Return all advertisements whose capability array contains the requested action type. *Query by action with disclosure satisfiability:* Return only advertisements where: 1. The capability array contains the requested action type, AND 2. Every entry in requires_disclosure is present in the caller's available properties list. This filtering MUST occur before any mandate is issued or session is established. Agents whose disclosure requirements exceed the principal's authorization MUST be excluded. The principal MUST NOT be asked to over-disclose. 9.4. Advertisement Signing The canonical form for advertisement signing MUST include all fields except signature: { "@context": "https://schema.org", "@type": "schema:Service", "name": "...", "provider": { ... }, "capability": [...], "object_types": [...], "requires_disclosure": [...], "returns": [...], "ttl_min": 300, "signed_by": "did:key:z..." } Baur Expires 21 November 2026 [Page 33] Internet-Draft PAP May 2026 Signing follows the same Ed25519/base64url-no-pad procedure as mandate signing (Section 5.2). A marketplace registry MUST reject unsigned advertisements. 9.5. Advertisement Hashing The content hash of an advertisement MUST be computed as: base64url(SHA-256(canonical_bytes)) This hash is used for deduplication in federated registries (Section 10). 9.6. Operator Metrics An agent advertisement MAY include an operator_metrics field containing self-reported operational statistics. Metrics are informational metadata for principal evaluation and MUST NOT be used by marketplace registries for ranking, sorting, or filtering query results. Baur Expires 21 November 2026 [Page 34] Internet-Draft PAP May 2026 +========================+==========+==========+===================+ | Field | Type | Required | Description | +========================+==========+==========+===================+ | total_receipts | Integer | OPTIONAL | Total co-signed | | | | | transaction | | | | | receipts | +------------------------+----------+----------+-------------------+ | bilateral_attestations | Integer | OPTIONAL | Receipts with | | | | | bilateral session | | | | | attestation | +------------------------+----------+----------+-------------------+ | unique_counterparties | Integer | OPTIONAL | Distinct | | | | | counterparty | | | | | session DIDs | +------------------------+----------+----------+-------------------+ | action_types | Array of | OPTIONAL | Distinct | | | String | | Schema.org action | | | | | types performed | +------------------------+----------+----------+-------------------+ | tee_sessions_pct | Number | OPTIONAL | Fraction of | | | | | sessions with TEE | | | | | attestation (0.0 | | | | | to 1.0) | +------------------------+----------+----------+-------------------+ | first_seen | DateTime | OPTIONAL | RFC 3339 | | | | | timestamp of | | | | | first | | | | | registration | +------------------------+----------+----------+-------------------+ | uptime_days | Integer | OPTIONAL | Days the operator | | | | | has been active | +------------------------+----------+----------+-------------------+ Table 19 The operator_metrics field MUST be excluded from the advertisement content hash (Section 9.5) and signature computation (Section 9.4). Metrics change over time while the advertisement identity remains stable. *Anti-ranking requirement:* Marketplace registries MUST return query results in insertion order. Registries MUST NOT rank, sort, or filter results based on operator metrics. The principal's orchestrator is responsible for evaluating metrics and making selection decisions. This requirement prevents marketplace registries from accumulating ranking power, which would constitute platform capture. Baur Expires 21 November 2026 [Page 35] Internet-Draft PAP May 2026 10. Federation Protocol 10.1. Overview Federation enables independent marketplace registries to discover and share agent advertisements. Federation is peer-to-peer with no central coordinator. 10.2. Registry Peer A federation peer is identified by: +===========+==========+==========+======================+ | Field | Type | Required | Description | +===========+==========+==========+======================+ | did | String | REQUIRED | DID of the peer | | | | | registry operator | +-----------+----------+----------+----------------------+ | endpoint | String | REQUIRED | HTTP(S) endpoint for | | | | | federation API calls | +-----------+----------+----------+----------------------+ | last_sync | DateTime | OPTIONAL | Timestamp of last | | | or null | | successful sync | +-----------+----------+----------+----------------------+ Table 20 10.3. Federation Messages Federation uses the following message types, discriminated by a type field: Baur Expires 21 November 2026 [Page 36] Internet-Draft PAP May 2026 +==================+=========+====================+================+ | Type |Direction| Fields | Description | +==================+=========+====================+================+ | QueryByAction |Request | action: String | Query for | | | | | agents | | | | | supporting an | | | | | action | +------------------+---------+--------------------+----------------+ | QueryResponse |Response | advertisements: | Matching | | | | Array of | advertisements | | | | AgentAdvertisement | | +------------------+---------+--------------------+----------------+ | Announce |Request | advertisement: | Announce a new | | | | AgentAdvertisement | local | | | | | advertisement | +------------------+---------+--------------------+----------------+ | AnnounceAck |Response | hash: String, | Acknowledge | | | | accepted: Boolean | announcement | +------------------+---------+--------------------+----------------+ | PeerList |Request | (none) | Request known | | | | | peer list | +------------------+---------+--------------------+----------------+ | PeerListResponse |Response | peers: Array of | Known peers | | | | RegistryPeer | | +------------------+---------+--------------------+----------------+ Table 21 10.4. Federation Endpoints A federation server MUST expose the following HTTP endpoints: +========+=======================+==============+==================+ | Method | Path | Request Body | Response Body | +========+=======================+==============+==================+ | GET | /federation/ | (none) | QueryResponse | | | query?action={action} | | | +--------+-----------------------+--------------+------------------+ | POST | /federation/announce | Announce | AnnounceAck | +--------+-----------------------+--------------+------------------+ | GET | /federation/peers | (none) | PeerListResponse | +--------+-----------------------+--------------+------------------+ Table 22 Baur Expires 21 November 2026 [Page 37] Internet-Draft PAP May 2026 10.5. Content-Hash Deduplication When merging remote advertisements, a federated registry MUST: 1. Compute the content hash of each advertisement (Section 9.5). 2. If the hash already exists in the local seen-hashes set, skip the advertisement. 3. If the advertisement has no signature, skip it. 4. Otherwise, register the advertisement and add its hash to the seen-hashes set. This ensures idempotent synchronization and prevents duplicate entries. 10.6. Peer Discovery A registry MAY discover new peers transitively: 1. Query a known peer's /federation/peers endpoint. 2. For each peer in the response not already known, add it to the local peer list. Implementations SHOULD implement rate limiting and SHOULD validate that newly discovered peers are reachable before adding them. 10.7. Peer Trust Signals A federation peer MAY present trust signals to establish credibility with other registries. Trust signals are additive — more signals increase confidence but no single signal is sufficient alone. 10.7.1. 10.7.1. Signal Categories +=================+===============+======================+ | Signal | Weight | Description | +=================+===============+======================+ | Social vouching | Primary | Signed vouches from | | | | existing peers | +-----------------+---------------+----------------------+ | TEE attestation | Supplementary | Hardware attestation | | | | of registry software | +-----------------+---------------+----------------------+ | Operational | Supplementary | Observable uptime | | history | | and sync metrics | +-----------------+---------------+----------------------+ | Domain | Supplementary | DNS or TLS proof of | | verification | | domain ownership | +-----------------+---------------+----------------------+ Baur Expires 21 November 2026 [Page 38] Internet-Draft PAP May 2026 Table 23 A registry SHOULD require at least two signal categories before granting a peer full synchronization privileges. 10.7.2. 10.7.2. Peer Vouch A peer vouch is a signed statement by an existing peer that they have evaluated the new peer and believe it operates a conformant registry. +===============+==========+==========+==========================+ | Field | Type | Required | Description | +===============+==========+==========+==========================+ | voucher_did | String | REQUIRED | DID of the vouching peer | +---------------+----------+----------+--------------------------+ | vouchee_did | String | REQUIRED | DID of the peer being | | | | | vouched | +---------------+----------+----------+--------------------------+ | timestamp | DateTime | REQUIRED | RFC 3339 timestamp | +---------------+----------+----------+--------------------------+ | justification | String | REQUIRED | Structured reason for | | | | | vouching | +---------------+----------+----------+--------------------------+ | signature | String | REQUIRED | Ed25519 signature by | | | | | voucher | +---------------+----------+----------+--------------------------+ Table 24 10.7.3. 10.7.3. Vouch Budget To prevent vouch ring attacks (where colluding peers mutually vouch to create Sybil identities), implementations SHOULD enforce: * *Vouch budget:* Each peer MAY issue at most 3 vouches per year. * *Minimum age:* A peer MUST be registered for at least 90 days before it is eligible to vouch for others. * *Probationary period:* Newly registered peers operate in probationary status for 60 days. During probation, a peer MAY receive advertisements but MUST NOT vouch for other peers. * *Diverse trust paths:* The vouchers for a new peer SHOULD NOT all trace their own vouching chains through the same set of peers. 11. Receipt Format Baur Expires 21 November 2026 [Page 39] Internet-Draft PAP May 2026 11.1. Transaction Receipt A transaction receipt is a co-signed record of a completed session. Receipts contain property type references only -- never values. +========================+========+==========+=====================+ | Field |Type | Required | Description | +========================+========+==========+=====================+ | session_id |String | REQUIRED | Ephemeral session | | | | | ID (not linked to | | | | | principal) | +------------------------+--------+----------+---------------------+ | action |String | REQUIRED | Schema.org action | | | | | type executed | +------------------------+--------+----------+---------------------+ | initiating_agent_did |String | REQUIRED | Ephemeral session | | | | | DID of the | | | | | initiator | +------------------------+--------+----------+---------------------+ | receiving_agent_did |String | REQUIRED | Ephemeral session | | | | | DID of the receiver | +------------------------+--------+----------+---------------------+ | disclosed_by_initiator |Array of| REQUIRED | Property references | | |String | | disclosed by the | | | | | initiator | +------------------------+--------+----------+---------------------+ | disclosed_by_receiver |Array of| REQUIRED | Property references | | |String | | or operator | | | | | statements from the | | | | | receiver | +------------------------+--------+----------+---------------------+ | executed |String | REQUIRED | Human-readable | | | | | description of the | | | | | action executed | +------------------------+--------+----------+---------------------+ | returned |String | REQUIRED | Human-readable | | | | | description of the | | | | | result returned | +------------------------+--------+----------+---------------------+ | timestamp |DateTime| REQUIRED | RFC 3339 timestamp | +------------------------+--------+----------+---------------------+ | signatures |Array of| REQUIRED | Co-signatures | | |String | | (base64url-no-pad) | +------------------------+--------+----------+---------------------+ Table 25 Baur Expires 21 November 2026 [Page 40] Internet-Draft PAP May 2026 11.2. Receipt Signing The canonical form for receipt signing MUST include all fields except signatures: { "session_id": "...", "action": "...", "initiating_agent_did": "...", "receiving_agent_did": "...", "disclosed_by_initiator": [...], "disclosed_by_receiver": [...], "executed": "...", "returned": "...", "timestamp": "..." } 11.3. Co-Signing Protocol 1. The initiator constructs a receipt from the completed session. 2. The initiator computes Ed25519_sign(canonical_bytes) using its session key and appends the base64url-no-pad encoded signature to signatures. 3. The initiator sends the half-signed receipt to the receiver. 4. The receiver verifies the initiator's signature against the initiator's session public key. 5. The receiver computes Ed25519_sign(canonical_bytes) using its session key and appends its signature to signatures. 6. The receiver returns the fully co-signed receipt. 11.4. Receipt Verification To verify a co-signed receipt: 1. The signatures array MUST contain exactly 2 entries. 2. signatures[0] MUST verify against the initiator's session public key. 3. signatures[1] MUST verify against the receiver's session public key. 11.5. Privacy Properties Receipts MUST NOT contain: - Personal data values (names, emails, etc.) - SD-JWT claim values - Raw execution inputs or outputs Baur Expires 21 November 2026 [Page 41] Internet-Draft PAP May 2026 Receipts MUST contain only: - Schema.org property type references (e.g., schema:Person.schema:name) - Operator-defined category references (e.g., operator:search_executed) - Human-readable action/ result descriptions This ensures receipts are auditable by both principals without revealing the data exchanged in the transaction. 11.6. Session Attestation A session attestation is a signed statement by a session participant recording their assessment of the session outcome. +==============+==========+==========+===========================+ | Field | Type | Required | Description | +==============+==========+==========+===========================+ | session_id | String | REQUIRED | Session identifier | +--------------+----------+----------+---------------------------+ | attester_did | String | REQUIRED | Ephemeral session DID of | | | | | attester | +--------------+----------+----------+---------------------------+ | outcome | String | REQUIRED | One of: fulfilled, | | | | | partial, failed, disputed | +--------------+----------+----------+---------------------------+ | action_type | String | REQUIRED | Schema.org action type | | | | | executed | +--------------+----------+----------+---------------------------+ | timestamp | DateTime | REQUIRED | RFC 3339 timestamp | +--------------+----------+----------+---------------------------+ | signature | String | REQUIRED | Ed25519 signature by | | | | | attester | +--------------+----------+----------+---------------------------+ Table 26 A receipt with attestations from both the initiating and receiving agents is *bilaterally attested*. Bilaterally attested receipts carry higher evidentiary weight for operator metric computation. Attestations are per-action-type. An operator's reputation in one action domain (e.g., schema:SearchAction) MUST NOT be conflated with reputation in another domain (e.g., schema:ReserveAction). 12. Verifiable Credential Envelope Baur Expires 21 November 2026 [Page 42] Internet-Draft PAP May 2026 12.1. Overview PAP mandates MAY be wrapped in a W3C Verifiable Credential (VC) envelope for interoperability with existing credential ecosystems. The VC envelope is OPTIONAL; implementations MUST support bare mandates and MAY additionally support VC-wrapped mandates. 12.2. VC Structure A PAP Verifiable Credential MUST conform to [VC-DATA-MODEL-2.0]: { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "urn:uuid:", "type": ["VerifiableCredential", "PAPMandateCredential"], "issuer": "", "issuanceDate": "", "expirationDate": "", "credentialSubject": { }, "proof": { "type": "Ed25519Signature2020", "created": "", "verificationMethod": "#key-1", "proofPurpose": "assertionMethod", "proofValue": "" } } The type array MUST include both "VerifiableCredential" and "PAPMandateCredential" for discoverability. 12.3. Credential Signing The canonical form for VC signing MUST include all fields except proof: { "@context": [...], "id": "...", "type": [...], "issuer": "...", "issuanceDate": "...", "expirationDate": "..." or null, "credentialSubject": { ... } } Baur Expires 21 November 2026 [Page 43] Internet-Draft PAP May 2026 The proofValue is base64url(Ed25519_sign(JSON_bytes(canonical))). 13. Extension Points The following extensions are defined for PAP v1.0. Core extensions (Sections 13.1--13.4) were introduced in v0.4. Recovery mandates (Section 13.5), TEE attestation (Section 13.6), and payment proof validation (Section 13.7) were added in v0.7. All extensions are OPTIONAL; a conformant implementation MAY support none, some, or all of them. 13.1. Payment Proof A mandate MAY carry a payment_proof field containing a zero-knowledge payment commitment. PAP does not define the payment protocol; it defines the integration point. Only cryptographic commitments are stored — *never* amounts, destinations, mints, or other identifying payment data. The PaymentProof type is a tagged enum with two variants: +===========+================+======================+ | Variant | Inner Type | Description | +===========+================+======================+ | Lightning | Bolt11Hash | SHA-256 of a BOLT-11 | | | | invoice payment hash | +-----------+----------------+----------------------+ | Ecash | CashuTokenHash | SHA-256 of a Cashu | | | | blind-signed token | +-----------+----------------+----------------------+ Table 27 13.1.1. 13.1.1. Bolt11Hash A commitment to a Lightning Network payment. The hash field contains the base64url-no-pad encoded SHA-256 of the BOLT-11 invoice payment hash. The preimage is never stored. { "type": "Lightning", "hash": "" } Baur Expires 21 November 2026 [Page 44] Internet-Draft PAP May 2026 13.1.2. 13.1.2. CashuTokenHash A commitment to a Cashu ecash token. The hash field contains the base64url-no-pad encoded SHA-256 of the blind-signed token. The token itself is never stored. { "type": "Ecash", "hash": "" } 13.1.3. 13.1.3. Payment Proof Properties * The proof contains *only* a cryptographic commitment hash. * No amounts, destinations, mints, or routing data are stored. * The vendor MUST NOT be able to identify the payer from the proof. * The proof MUST be unlinkable to the principal's identity. * The payment proof is included in the mandate's canonical form for signing. * If a mandate's scope includes schema:PayAction, a payment proof SHOULD be attached. Implementations MAY reject mandates that permit payment actions without a proof. 13.1.4. 13.1.4. Ecash Blind Signature Protocol PAP includes a reference implementation of the Chaumian blind signature scheme in the pap-ecash crate. The scheme uses RFC 9474 RSABSSA-SHA384-PSS (non-augmented variant, randomize = false). *Protocol parameters:* +=============+===================================================+ | Parameter | Value | +=============+===================================================+ | Scheme | RSABSSA-SHA384-PSS (RFC 9474 §4.2, non-augmented) | +-------------+---------------------------------------------------+ | Key size | ≥ 2048 bits (production); 1024 bits (tests only) | +-------------+---------------------------------------------------+ | Commitment | SHA-256(serial ∥ signature), base64url-no-pad | +-------------+---------------------------------------------------+ | Serial size | 32 bytes, randomly chosen by the client | +-------------+---------------------------------------------------+ Table 28 *Protocol steps:* Baur Expires 21 November 2026 [Page 45] Internet-Draft PAP May 2026 1. *Request* — client calls ecash_request(serial, mint_pk). Returns a BlindToken containing a randomly-blinded serial. Only the blinded_message() bytes are transmitted to the mint. 2. *Mint* — mint calls ecash_mint_sign(blinded_msg, keypair). Returns raw blind-signature bytes to the client. 3. *Unblind* — client calls ecash_unblind(blind_token, blind_sig, mint_pk). Returns the spendable EcashToken { serial, signature }. 4. *Attach* — client calls token.to_payment_proof() and includes the result in the mandate's payment_proof field. 5. *Verify* — payee calls ecash_verify(token, mint_pk). Valid tokens have a correct RSA-PSS signature over serial. 6. *Redeem* — payee calls ecash_redeem(token, mint_pk, registry). Atomically verifies and records serial in the spent registry, preventing double-spend. *Unlinkability invariant:* The random blinding factor applied in step 1 means that the blinded_message bytes transmitted to the mint are statistically independent of the final (serial, signature) pair. The mint cannot link a signing operation to a subsequent redemption. *Double-spend invariant:* ecash_redeem MUST return EcashError::DoubleSpend on any second call with the same serial, regardless of signature validity. *Test vectors:* The conformance test suite is in crates/pap-ecash/. Run the following to generate and verify all test vectors: cargo test -p pap-ecash -- --nocapture The ecash_test_vector test uses a freshly-generated 1024-bit test key (test-only size) and serial 0x000…001 (32 bytes). Because blind-rsa- signatures v0.14 uses OsRng internally (no injectable RNG), the blinding factor and PSS salt are non-deterministic. The test therefore validates structural invariants (correct verification, 43-char base64url commitment) rather than pinning an exact byte value. *C FFI:* pap_ecash_mint_keypair_generate, pap_ecash_blind, pap_ecash_blind_message_bytes, pap_ecash_mint_sign, pap_ecash_unblind, pap_ecash_verify, pap_ecash_spent_registry_new, pap_ecash_redeem, pap_ecash_token_payment_proof_commitment. *WASM:* EcashMintKeypair, EcashBlindToken, EcashToken, ecashMintSign, ecashVerify. Baur Expires 21 November 2026 [Page 46] Internet-Draft PAP May 2026 13.2. Payment Proof Verification A receiving agent that requires payment MUST: 1. Extract the payment_proof from the mandate. 2. Validate the proof's structural integrity (valid base64url, 32-byte SHA-256 commitment). 3. Verify the proof against the payment network (out of band): - *Lightning*: verify the BOLT-11 payment hash preimage - *Ecash*: verify the Cashu token with the issuing mint 4. Accept or reject the session based on verification. 13.2.1. 13.2.1. Receipt Payment Proof Commitment When a transaction receipt is created for a schema:PayAction, the receipt MUST include a payment_proof_commitment field containing the commitment hash from the mandate's payment proof. This enables auditing without revealing payment details. A receipt validator MUST check: 1. The payment_proof_commitment is present for payment actions. 2. The commitment matches the mandate's payment proof commitment. 3. The commitment is included in the receipt's canonical form for co-signing. The verification protocol between the receiving agent and the payment network is out of scope for this specification. 13.3. Continuity Tokens A continuity token enables stateful relationships across sessions without requiring the vendor to retain state. Baur Expires 21 November 2026 [Page 47] Internet-Draft PAP May 2026 +===================+==========+==========+=========================+ | Field | Type | Required | Description | +===================+==========+==========+=========================+ | schema_type | String | REQUIRED | Schema.org type | | | | | describing the | | | | | encrypted | | | | | payload shape | +-------------------+----------+----------+-------------------------+ | vendor_did | String | REQUIRED | DID of the | | | | | vendor that | | | | | issued this | | | | | token | +-------------------+----------+----------+-------------------------+ | encrypted_payload | String | REQUIRED | Vendor-encrypted | | | | | state (opaque to | | | | | orchestrator) | +-------------------+----------+----------+-------------------------+ | ttl | DateTime | REQUIRED | Expiry | | | | | timestamp, set | | | | | by the principal | +-------------------+----------+----------+-------------------------+ | issued_at | DateTime | REQUIRED | Issuance | | | | | timestamp | +-------------------+----------+----------+-------------------------+ Table 29 13.3.1. 13.3.1. Continuity Token Lifecycle 1. At session close, the vendor encrypts its internal state and returns it as a continuity token to the orchestrator. 2. The orchestrator stores the token locally. The vendor retains nothing. 3. When the principal returns, the orchestrator presents the token to the vendor. 4. The vendor decrypts the payload and resumes the relationship. 5. The principal controls the TTL. The vendor MUST NOT set or extend the TTL. 6. To sever the relationship, the principal deletes the token. No revocation notice is required. 13.3.2. 13.3.2. Continuity Token Properties * The schema_type MUST be inspectable by the orchestrator without decrypting the payload. * The vendor MUST NOT be able to write to the continuity token without the principal presenting it. Baur Expires 21 November 2026 [Page 48] Internet-Draft PAP May 2026 * The encrypted payload format is vendor-defined and opaque to the protocol. 13.4. Auto-Approval Policies An auto-approval policy allows the principal to pre-authorize certain categories of actions without per-transaction approval. +============================+========+========+===================+ | Field |Type |Required|Description | +============================+========+========+===================+ | name |String |REQUIRED|Human-readable | | | | |policy name | +----------------------------+--------+--------+-------------------+ | scope |Scope |REQUIRED|Subset of the | | | | |mandate scope this | | | | |policy applies to | +----------------------------+--------+--------+-------------------+ | max_value |Number |OPTIONAL|Maximum transaction| | |or null | |value for auto- | | | | |approval (currency-| | | | |agnostic) | +----------------------------+--------+--------+-------------------+ | zero_additional_disclosure |Boolean |REQUIRED|If true, auto- | | | | |approve only when | | | | |zero additional | | | | |disclosure is | | | | |required beyond the| | | | |mandate | +----------------------------+--------+--------+-------------------+ | authored_at |DateTime|REQUIRED|Timestamp when the | | | | |principal authored | | | | |this policy | +----------------------------+--------+--------+-------------------+ Table 30 13.4.1. 13.4.1. Auto-Approval Constraints * The policy scope MUST be contained by the mandate scope (Section 5.4.5). A policy MUST NOT be more permissive than the mandate. * Policies are principal-authored and orchestrator-enforced. An agent MUST NOT trigger a policy change by requesting it. * zero_additional_disclosure defaults to true. When true, the orchestrator MUST auto-approve only when the agent's disclosure requirements are fully covered by the existing mandate. Baur Expires 21 November 2026 [Page 49] Internet-Draft PAP May 2026 * If max_value is set and the transaction value exceeds it, the orchestrator MUST request explicit principal approval. 13.5. M-of-N Social Recovery Principal identity recovery via a designated notary quorum. No central recovery authority. The principal designates N notary DIDs at setup time; any M co-signers from that set can authorize key rotation. 13.5.1. 13.5.1. Recovery Mandate A principal creates a RecoveryMandate while they still control their key, designating the notary set and threshold. +===============+===============+==========+======================+ | Field | Type | Required | Description | +===============+===============+==========+======================+ | principal_did | String | REQUIRED | DID of the principal | | | | | creating the mandate | +---------------+---------------+----------+----------------------+ | threshold | Integer | REQUIRED | M: minimum co- | | | | | signatures required | | | | | (1 ≤ M ≤ N) | +---------------+---------------+----------+----------------------+ | notary_dids | Array | REQUIRED | N designated notary | | | | | DIDs (no duplicates) | +---------------+---------------+----------+----------------------+ | created_at | DateTime | REQUIRED | Mandate creation | | | | | timestamp | +---------------+---------------+----------+----------------------+ | signature | String | REQUIRED | Ed25519 signature by | | | | | the principal | +---------------+---------------+----------+----------------------+ Table 31 Constraints: - threshold MUST be ≥ 1 and ≤ notary_dids.length. - notary_dids MUST NOT contain duplicate entries. - The mandate MUST be signed by the principal's current key. - Only one recovery mandate per principal DID. A new mandate replaces any previous one. 13.5.2. 13.5.2. Recovery Request When recovery is needed, a RecoveryRequest is created identifying the old principal, the new principal keypair, and the authorizing recovery mandate. Baur Expires 21 November 2026 [Page 50] Internet-Draft PAP May 2026 +=======================+==========+==========+=================+ | Field | Type | Required | Description | +=======================+==========+==========+=================+ | old_principal_did | String | REQUIRED | DID of the | | | | | principal being | | | | | recovered | +-----------------------+----------+----------+-----------------+ | new_principal_did | String | REQUIRED | DID of the new | | | | | principal | | | | | keypair | +-----------------------+----------+----------+-----------------+ | recovery_mandate_hash | String | REQUIRED | SHA-256 hash of | | | | | the authorizing | | | | | RecoveryMandate | +-----------------------+----------+----------+-----------------+ | requested_at | DateTime | REQUIRED | Request | | | | | timestamp | +-----------------------+----------+----------+-----------------+ Table 32 The canonical bytes of the recovery request are the message that each notary signs independently. 13.5.3. 13.5.3. Partial Recovery Signature (Blind) Each notary signs the recovery request independently. Notaries MUST NOT communicate with each other during recovery — they learn nothing about which other notaries have been contacted (threshold blind signature scheme). Before signing, a notary MUST verify: 1. The recovery mandate was signed by the old principal. 2. The notary's own DID is in the designated notary set. 3. The request references the correct recovery mandate hash. 4. The request's old_principal_did matches the mandate. Baur Expires 21 November 2026 [Page 51] Internet-Draft PAP May 2026 +============+==========+==========+========================+ | Field | Type | Required | Description | +============+==========+==========+========================+ | notary_did | String | REQUIRED | DID of the signing | | | | | notary | +------------+----------+----------+------------------------+ | signature | String | REQUIRED | Ed25519 signature over | | | | | the RecoveryRequest | | | | | canonical bytes | +------------+----------+----------+------------------------+ | signed_at | DateTime | REQUIRED | Timestamp of the | | | | | notary's signature | +------------+----------+----------+------------------------+ Table 33 13.5.4. 13.5.4. Recovery Proof Assembly A recovery coordinator collects M partial signatures and assembles a RecoveryProof. Verification of the proof MUST check: 1. The recovery mandate was signed by the old principal. 2. At least M partial signatures are present. 3. All signers are in the designated notary set. 4. No duplicate signers. 5. All partial signatures are cryptographically valid. 13.5.5. 13.5.5. Revocation Proof and Broadcast After successful recovery, a RevocationProof is created and broadcast to federation peers. Baur Expires 21 November 2026 [Page 52] Internet-Draft PAP May 2026 +=====================+==========+==========+=======================+ | Field | Type | Required | Description | +=====================+==========+==========+=======================+ | old_principal_did | String | REQUIRED | The revoked DID | +---------------------+----------+----------+-----------------------+ | new_principal_did | String | REQUIRED | The replacement | | | | | DID | +---------------------+----------+----------+-----------------------+ | recovery_proof_hash | String | REQUIRED | SHA-256 hash of | | | | | the RecoveryProof | +---------------------+----------+----------+-----------------------+ | revoked_at | DateTime | REQUIRED | Revocation | | | | | timestamp | +---------------------+----------+----------+-----------------------+ | signature | String | REQUIRED | Ed25519 signature | | | | | by the new | | | | | principal key | +---------------------+----------+----------+-----------------------+ Table 34 The revocation proof MUST be signed by the new principal key (proving possession). Federation peers that receive a valid revocation MUST: - Mark the old principal DID as revoked. - Reject any future operations using the old DID. - Remove the old recovery mandate from their NotarySet. 13.5.6. 13.5.6. NotarySet Registry Each federation node maintains a NotarySet — a registry of recovery mandates queryable by principal DID. The NotarySet: - Stores signed recovery mandates. - Tracks revoked principal DIDs. - Rejects mandate registration for already-revoked DIDs. - Processes revocation broadcasts from federation peers. 13.5.7. 13.5.7. Security Properties * *No central authority.* Recovery requires M independent notaries. * *Blind co-signing.* Notaries do not learn which other notaries participate in a recovery event. * *Old key revocation.* The old principal DID is cryptographically revoked and broadcast to all federation peers. * *Notary set immutability.* The notary set is fixed at mandate creation time by the principal. It cannot be modified without creating a new mandate signed by the principal. * *Threshold enforcement.* Fewer than M signatures MUST be rejected. Duplicate signers MUST be rejected. Baur Expires 21 November 2026 [Page 53] Internet-Draft PAP May 2026 13.6. TEE Attestation A mandate or session MAY carry a Trusted Execution Environment (TEE) attestation to provide evidence that an agent is executing within an isolated enclave. TEE attestation is OPTIONAL and does NOT elevate a TEE to equivalence with local trust (Section 3.4). 13.6.1. 13.6.1. Attestation Object +====================+==========+==========+====================+ | Field | Type | Required | Description | +====================+==========+==========+====================+ | enclave_type | String | REQUIRED | TEE platform | | | | | identifier (e.g., | | | | | "sgx", "sev-snp", | | | | | "trustzone") | +--------------------+----------+----------+--------------------+ | measurement | String | REQUIRED | Enclave | | | | | measurement hash | | | | | (base64url-no-pad) | +--------------------+----------+----------+--------------------+ | attestation_report | String | REQUIRED | Platform-specific | | | | | attestation report | | | | | (base64url-no-pad) | +--------------------+----------+----------+--------------------+ | timestamp | DateTime | REQUIRED | Attestation | | | | | generation | | | | | timestamp (RFC | | | | | 3339) | +--------------------+----------+----------+--------------------+ | nonce | String | REQUIRED | Challenge nonce | | | | | binding this | | | | | attestation to the | | | | | current session | | | | | (UUID v4) | +--------------------+----------+----------+--------------------+ Table 35 13.6.2. 13.6.2. Attestation Verification A verifier MUST: 1. Verify the attestation_report against the TEE platform's root of trust (platform-specific, out of scope). 2. Verify that measurement matches an expected enclave binary hash (implementation-defined allowlist). 3. Verify that nonce matches the session's challenge nonce. Baur Expires 21 November 2026 [Page 54] Internet-Draft PAP May 2026 4. Verify that timestamp is within an acceptable window (implementations SHOULD reject attestations older than 60 seconds). 13.6.3. 13.6.3. Trust Boundaries TEE attestation provides evidence of code integrity, not behavioral correctness. Specifically: * A TEE attestation MUST NOT be treated as equivalent to a mandate. An agent in a TEE still requires a valid mandate chain. * A TEE attestation MUST NOT be used to expand scope beyond what the mandate permits. * The principal MAY use TEE attestation as an input to auto-approval policies (Section 13.4) but MUST NOT be required to accept TEE attestation as a substitute for consent. 13.6.4. 13.6.4. Implementation Notes The reference implementation provides TEE attestation support via the pap-tee crate, which is compiled only when opted into as a dependency. Integration with pap-core is gated behind the tee Cargo feature flag. * *pap-tee crate*: Defines AttestationEvidence, EnclaveType, the AttestationVerifier trait, and a SoftwareSimulator for integration testing without hardware. * *pap-core tee feature*: Adds an optional attestation field to Session and provides open_with_attestation(). * *ProtocolMessage::TokenAccepted*: Carries an optional attestation field as opaque JSON (serde_json::Value). Receivers parse it via AttestationEvidence::from_value(). The SoftwareSimulator uses EnclaveType::Software and signs attestation reports with an Ed25519 key. It is intended for conformance testing (Appendix D, tests E-13 through E-15) and MUST NOT be deployed in production. 13.7. Payment Proof Validation Section 13.1 defines the payment proof integration point. This section specifies the validation requirements that a conformant implementation MUST satisfy when payment proofs are present. 13.7.1. 13.7.1. Proof Format Registry PAP defines the following payment proof format prefixes: Baur Expires 21 November 2026 [Page 55] Internet-Draft PAP May 2026 +=================+================+=======================+ | Prefix | Protocol | Description | +=================+================+=======================+ | ecash:blind:v1: | Chaumian ecash | Blind-signed mint | | | | tokens (Section 13.1) | +-----------------+----------------+-----------------------+ | ln:preimage:v1: | Lightning | Hash preimage proof | | | Network | of payment | +-----------------+----------------+-----------------------+ | zk:receipt:v1: | Zero-knowledge | ZK proof of value | | | proof | transfer | +-----------------+----------------+-----------------------+ Table 36 Implementations MAY support additional formats using the pap:payment: namespace prefix. 13.7.2. 13.7.2. Validation Requirements A receiving agent that requires payment MUST: 1. Parse the payment_proof field and identify the format prefix. 2. If the format is not supported, reject the mandate with a PaymentFormatUnsupported error. 3. Verify the proof against the appropriate payment backend (mint, Lightning node, or ZK verifier). The verification protocol is out of scope for this specification. 4. Verify that the proof amount meets the agent's minimum requirement for the requested action. 5. Verify that the proof has not been previously consumed (double- spend protection). 13.7.3. 13.7.3. Privacy Requirements * Payment proof verification MUST NOT reveal the payer's identity to the payment backend. * The receiving agent MUST NOT store payment proofs beyond the session duration unless required by applicable law. * Payment proofs MUST NOT appear in transaction receipts (Section 11.5). 13.8. Chat and Real-Time Communication Baur Expires 21 November 2026 [Page 56] Internet-Draft PAP May 2026 13.8.1. 13.8.1. Overview PAP provides a natural foundation for zero-trust, privacy-preserving real-time communication between principals. A personal agent MAY advertise schema:CommunicateAction in the federation registry — exactly as a service agent advertises schema:SearchAction. This makes a principal discoverable for chat without requiring a phone number, email address, or centrally-administered identity. Discoverability is opt-in, scoped, and revocable through the standard mandate system. Chat is not a new protocol. It is the *Phase 4 streaming extension* of the standard 6-phase handshake, applied to a schema:CommunicateAction session. 13.8.2. 13.8.2. Capability Grant A CapabilityToken scoped to schema:CommunicateAction MUST be issued by the initiating principal (or a delegated orchestrator) and signed with a principal key. The token: * MUST set action = "schema:CommunicateAction". * MUST set target_did to the receiving principal's agent DID. * MAY set a ttl appropriate for the conversation duration. * MAY carry a scope restricting the permitted communication modes (e.g., text-only, text+audio, text+audio+video). 13.8.3. 13.8.3. Phase 4 Streaming Mode After Phase 3 (disclosure), instead of a single task execution, the session transitions to *streaming mode*: 1. *Phase 4 execute* (client → server, no payload): the receiving agent returns ExecutionResult containing a schema:Conversation JSON-LD object. This signals that the session SHOULD remain open. 2. *StreamingMessage frames* (bidirectional, Phase 4): either party MAY send StreamingMessage frames carrying DIDComm basicmessage protocol payloads (see Section 13.8.5). Each frame MUST include: * id: a UUID for ack correlation. * content: a JSON object conforming to the DIDComm basicmessage body schema. 3. *StreamingAck* (responding side): upon receiving a StreamingMessage, the server MUST reply with either a StreamingAck (delivery confirmed) or a StreamingMessage (reply). Baur Expires 21 November 2026 [Page 57] Internet-Draft PAP May 2026 4. The session MUST remain open until either party sends SessionClose (Phase 6). Implementations SHOULD NOT proceed to Phase 5 (receipt co-signing) until the conversation is concluded. 13.8.4. 13.8.4. Message Format (DIDComm basicmessage) The content field of each StreamingMessage MUST conform to the DIDComm basicmessage 2.0 protocol body: { "type": "https://didcomm.org/basicmessage/2.0/message", "id": "", "body": { "content": "" } } The DIDComm wrapping (plaintext, signed, or encrypted) is applied at the Envelope layer via PapToDIDComm (Section 5.6). For chat sessions, implementations SHOULD use at minimum DIDCommSigned to bind each message to the sender's session DID. 13.8.5. 13.8.5. Receipt Upon SessionClose, the receipt (Phase 5) MUST record: * action = "schema:CommunicateAction" * executed: a summary string, e.g., "schema:Conversation". * disclosed_by_initiator / disclosed_by_receiver: property references only (e.g., ["schema:name"]). Message *content* MUST NOT appear in receipts. * Both parties' session DIDs as initiating_agent_did / receiving_agent_did (ephemeral, unlinked from principal DIDs). 13.8.6. 13.8.6. Group Chat Rooms A group chat room is an agent with its own DID that implements AgentHandler and maintains one session per member: * The room DID is registered in the federation with capability: ["schema:CommunicateAction"]. * The room owner issues a separate CapabilityToken to each member, all targeting the room DID. * Each member runs the standard 6-phase handshake against the room DID. After Phase 4 (streaming mode open), the room agent fans out each StreamingMessage to all other connected members. Baur Expires 21 November 2026 [Page 58] Internet-Draft PAP May 2026 * Group membership is enforced by the token system: only principals holding a valid token may connect. Revocation follows the standard mandate revocation flow (Section 8). * Rooms MAY be hosted locally (Papillon instance) or on any federation peer. A room hosted on a federation peer is discoverable via its DID advertisement. 13.8.7. 13.8.7. Audio and Video Audio and video calls follow the same pattern as text chat, using WebRTC as the media transport: 1. PAP Phases 1–4 establish identity, authorization, and streaming mode. The CapabilityToken scope SHOULD include the permitted media types (e.g., text+audio+video). 2. *SDP negotiation* is carried via StreamingMessage frames: the offerer sends a StreamingMessage whose content.body contains the SDP offer; the answerer replies with SDP answer. ICE candidates are exchanged as subsequent frames. 3. WebRTC DTLS-SRTP establishes the media channel out-of-band. PAP does not inspect or relay media. 4. Implementations MAY route ICE/TURN through an OHTTP relay to conceal participant IP addresses. 5. The PAP receipt records call metadata (duration, participant session DIDs, permitted media scope) but MUST NOT include audio or video content. 13.8.8. 13.8.8. Privacy Properties Chat sessions inherit all PAP privacy guarantees: * *Ephemeral session DIDs* — neither party's principal DID appears in message frames or SDP. * *OHTTP relay* — IP addresses hidden from the relay operator. * *Receipts* — property references only; no message content. * *Discoverability* — controlled by the principal's federation advertisement; opt-in. * *Forward secrecy* — DIDComm anoncrypt (ECDH-ES + A256GCM) MAY be applied to StreamingMessage content for per-message forward secrecy. 14. Transport Binding 14.1. HTTP/JSON Transport PAP defines an HTTP/JSON transport binding for the 6-phase handshake. This binding is the default transport for PAP v1.0. Implementations MAY define additional transport bindings. Baur Expires 21 November 2026 [Page 59] Internet-Draft PAP May 2026 14.2. Agent Server Endpoints A receiving agent MUST expose the following HTTP endpoints: +======+========================+=====+==================+==================+ |Method|Path |Phase|Request |Response | +======+========================+=====+==================+==================+ |POST |/session |1 |TokenPresentation |TokenAccepted or | | | | | |TokenRejected | +------+------------------------+-----+------------------+------------------+ |POST |/session/{id}/did |2 |SessionDidExchange|SessionDidAck | +------+------------------------+-----+------------------+------------------+ |POST |/session/{id}/disclosure|3 |DisclosureOffer |DisclosureAccepted| +------+------------------------+-----+------------------+------------------+ |POST |/session/{id}/execute |4 |(empty body) |ExecutionResult | +------+------------------------+-----+------------------+------------------+ |POST |/session/{id}/receipt |5 |ReceiptForCoSign |ReceiptCoSigned | +------+------------------------+-----+------------------+------------------+ |POST |/session/{id}/close |6 |SessionClose |SessionClosed | +------+------------------------+-----+------------------+------------------+ Table 37 The {id} path parameter is the session ID returned in Phase 1. 14.3. Agent Handler Interface Implementations MUST implement a handler interface with the following operations: Baur Expires 21 November 2026 [Page 60] Internet-Draft PAP May 2026 +===================+=====+=====================+=====================+ |Operation |Phase|Input |Output | +===================+=====+=====================+=====================+ |handle_token |1 |CapabilityToken |(session_id, | | | | |receiver_session_did)| +-------------------+-----+---------------------+---------------------+ |handle_did_exchange|2 |session_id, |() | | | |initiator_session_did| | +-------------------+-----+---------------------+---------------------+ |handle_disclosure |3 |session_id, |() | | | |disclosures | | +-------------------+-----+---------------------+---------------------+ |execute |4 |session_id |JSON result | +-------------------+-----+---------------------+---------------------+ |co_sign_receipt |5 |TransactionReceipt |TransactionReceipt | | | | |(co-signed) | +-------------------+-----+---------------------+---------------------+ |handle_close |6 |session_id |() | +-------------------+-----+---------------------+---------------------+ Table 38 14.4. Endpoint Resolution Endpoint resolution maps a DID to a transport endpoint URL. In production, this SHOULD be backed by DID Document service endpoints. Implementations MAY use in-memory registries for development and testing. 14.5. Content Type All HTTP request and response bodies MUST use Content-Type: application/json. Implementations SHOULD set Accept: application/ json on requests. 14.6. Error Handling If a phase handler returns an error, the server MUST respond with HTTP status 500 and a ProtocolMessage::Error payload containing a code and message. If the request body does not match the expected message type for the endpoint, the server MUST respond with HTTP status 400. Baur Expires 21 November 2026 [Page 61] Internet-Draft PAP May 2026 14.7. WebSocket Transport Implementations MAY support a WebSocket transport binding as an alternative to the HTTP/JSON binding. The WebSocket binding is OPTIONAL and provides full-duplex communication for sessions that benefit from lower-latency message exchange. 14.7.1. 14.7.1. Connection Lifecycle 1. The initiating agent opens a WebSocket connection to the receiving agent's WebSocket endpoint. 2. All 6 phases of the session handshake (Section 6.3) are conducted as JSON messages over the WebSocket connection. 3. Each message MUST be a JSON-serialized Envelope (Section 8.2). 4. The connection MUST be closed after Phase 6 (session close). 14.7.2. 14.7.2. Endpoint Format A WebSocket endpoint MUST use the wss:// scheme. Implementations MUST NOT use unencrypted ws:// connections in production. The endpoint URL MUST be published in the agent's DID Document service array with type set to "PAPWebSocket": { "id": "did:key:z...#pap-ws", "type": "PAPWebSocket", "serviceEndpoint": "wss://agent.example.com/pap/ws" } 14.7.3. 14.7.3. Message Framing Each WebSocket text frame MUST contain exactly one JSON-serialized Envelope. Binary frames MUST NOT be used. Implementations MUST reject connections that send binary frames. 14.7.4. 14.7.4. Sequence Enforcement Envelope sequence number rules (Section 8.2.2) apply identically over WebSocket. Out-of-order messages MUST be rejected. 14.8. Oblivious HTTP (OHTTP) Transport Implementations MAY support Oblivious HTTP [RFC 9458] as a transport binding. OHTTP provides request unlinkability at the network layer, preventing the receiving agent's operator from correlating requests by IP address. Baur Expires 21 November 2026 [Page 62] Internet-Draft PAP May 2026 14.8.1. 14.8.1. Architecture An OHTTP deployment interposes a relay between the initiating agent and the receiving agent: Initiator -> OHTTP Relay -> Receiving Agent (Gateway) The relay sees the initiator's IP but not the request content. The receiving agent sees the request content but not the initiator's IP. 14.8.2. 14.8.2. Encapsulation Each PAP protocol message MUST be encapsulated as an OHTTP Binary HTTP request targeting the corresponding HTTP/JSON endpoint (Section 14.2). The Content-Type MUST remain application/json. 14.8.3. 14.8.3. Key Configuration The receiving agent MUST publish its OHTTP key configuration in its DID Document service array with type set to "PAPObliviousHTTP": { "id": "did:key:z...#pap-ohttp", "type": "PAPObliviousHTTP", "serviceEndpoint": "https://agent.example.com/pap/ohttp", "ohttpKeyConfig": "" } 14.8.4. 14.8.4. Relay Selection The initiating agent selects the OHTTP relay. The relay MUST NOT be operated by the same entity as the receiving agent. The protocol does not define relay discovery; implementations SHOULD allow the principal to configure trusted relays. 14.9. DIDComm Transport Implementations MAY support DIDComm Messaging v2 [DIDCOMM-V2] as a transport binding. DIDComm provides authenticated encryption at the message layer, enabling transport-independent secure messaging between agents identified by DIDs. 14.9.1. 14.9.1. Message Mapping Each PAP protocol message (Section 8.1) MUST be wrapped in a DIDComm plaintext message with the following mapping: Baur Expires 21 November 2026 [Page 63] Internet-Draft PAP May 2026 +===============+=============================================+ | DIDComm Field | Value | +===============+=============================================+ | type | https://pap.dev/protocol/1.0/{message_type} | +---------------+---------------------------------------------+ | from | Sender's DID (session DID after Phase 2) | +---------------+---------------------------------------------+ | to | Array containing recipient's DID | +---------------+---------------------------------------------+ | body | The PAP protocol message payload | +---------------+---------------------------------------------+ | created_time | Envelope timestamp (Unix epoch seconds) | +---------------+---------------------------------------------+ Table 39 Where {message_type} is the lowercase, hyphenated form of the PAP message type (e.g., token-presentation, session-did-exchange). 14.9.2. 14.9.2. Encryption DIDComm messages MUST use authenticated encryption (authcrypt) after Phase 2 when both session DIDs are known. Phase 1 messages MAY use anonymous encryption (anoncrypt) since the initiator's session DID is not yet established. 14.9.3. 14.9.3. Service Endpoint A DIDComm-capable agent MUST publish a DIDComm service endpoint in its DID Document: { "id": "did:key:z...#pap-didcomm", "type": "DIDCommMessaging", "serviceEndpoint": { "uri": "https://agent.example.com/pap/didcomm", "accept": ["didcomm/v2"] } } 14.10. Transport Negotiation When an agent supports multiple transport bindings, the initiating agent MUST select a transport by inspecting the receiving agent's DID Document service array. The preference order SHOULD be: 1. OHTTP (strongest privacy properties) 2. DIDComm (authenticated encryption at message layer) Baur Expires 21 November 2026 [Page 64] Internet-Draft PAP May 2026 3. WebSocket (lower latency for interactive sessions) 4. HTTP/JSON (default, widest compatibility) If the receiving agent's DID Document contains no service entries, the initiating agent MUST fall back to HTTP/JSON with endpoint resolution (Section 14.4). 14.11. DIDComm v2 Envelope Compatibility PAP defines an optional DIDComm v2 envelope compatibility layer that wraps PAP protocol envelopes inside DIDComm v2 message formats. This allows PAP agents to interoperate with DIDComm-native agents without changing the PAP protocol itself. This section specifies the detailed wire formats used by the DIDComm transport binding (Section 14.9). 14.11.1. 14.11.1. Design Principles * PAP mandate, session, and receipt semantics are fully preserved. * Only the outer transport envelope changes; the inner PAP Envelope (including its Ed25519 signature) travels intact inside the DIDComm message body. * The DIDComm layer provides additional transport-level integrity (JWS) or confidentiality (JWE) on top of PAP's own signatures. * This is a shim — existing pap-transport behavior is unaffected. 14.11.2. 14.11.2. Plaintext Messages A PAP envelope is wrapped in a DIDComm v2 plaintext message: { "id": "", "typ": "application/didcomm-plain+json", "type": "https://pap.baur.dev/proto/1.0/", "from": "", "to": [""], "created_time": , "body": { } } The type field uses PAP message type URIs under the namespace https://pap.baur.dev/proto/1.0/, with kebab-case slugs derived from the ProtocolMessage variant name (e.g., session-did-ack, execution- result, token-presentation). The body field contains the complete PAP Envelope including its signature field, so the receiving agent can verify the PAP-level signature independently of the DIDComm layer. Baur Expires 21 November 2026 [Page 65] Internet-Draft PAP May 2026 14.11.3. 14.11.3. Signed Messages (Ed25519 JWS) A signed DIDComm v2 message uses JWS General JSON Serialization (RFC 7515) with the EdDSA algorithm (RFC 8037): { "payload": "", "signatures": [{ "protected": "", "signature": "" }] } The signing input is ASCII(protected) || '.' || ASCII(payload) where both values are base64url-encoded without padding (RFC 4648 Section 5). The signature is computed with Ed25519 (RFC 8032). Verifiers MUST reject messages where: - The alg header value is not "EdDSA". - The signature does not verify against the expected key. - The decoded payload is not valid DIDComm v2 plaintext JSON. 14.11.4. 14.11.4. Encrypted Messages (ECDH-ES + A256GCM JWE) An encrypted DIDComm v2 message uses JWE JSON Serialization with anonymous encryption (anoncrypt): * *Key Agreement*: ECDH-ES (direct, no key wrapping) via X25519 Diffie-Hellman. The sender generates an ephemeral X25519 keypair. The recipient's Ed25519 public key is converted to X25519 using the Edwards-to-Montgomery birational map. * *Key Derivation*: Concat KDF (NIST SP 800-56A Section 5.8.1) with algId = "A256GCM", empty apu, and apv = SHA-256(recipient-did). * *Content Encryption*: AES-256-GCM with a random 96-bit IV. The base64url-encoded protected header serves as Additional Authenticated Data (AAD). { "protected": "", "recipients": [{ "header": { "kid": "" }, "encrypted_key": "" }], "iv": "", "ciphertext": "", "tag": "" } The protected header contains: Baur Expires 21 November 2026 [Page 66] Internet-Draft PAP May 2026 +=======+=======================================================+ | Field | Value | +=======+=======================================================+ | typ | "application/didcomm-encrypted+json" | +-------+-------------------------------------------------------+ | alg | "ECDH-ES" | +-------+-------------------------------------------------------+ | enc | "A256GCM" | +-------+-------------------------------------------------------+ | epk | {"kty":"OKP","crv":"X25519","x":""} | +-------+-------------------------------------------------------+ | apv | "" | +-------+-------------------------------------------------------+ Table 40 The encrypted_key field is empty for ECDH-ES direct key agreement (the content encryption key is derived directly from the shared secret). 14.11.5. 14.11.5. Ed25519 to X25519 Key Conversion DIDComm v2 encryption requires X25519 keys for key agreement. PAP agents use Ed25519 keys (via did:key). The conversion is: * *Public key*: Decompress the Ed25519 compressed Edwards Y coordinate, then apply the Edwards-to-Montgomery birational map to obtain the X25519 public key (32 bytes). * *Private key*: Compute SHA-512(Ed25519-seed)[0..32]. The X25519 library applies standard clamping (clear bits 0-2, clear bit 255, set bit 254). This conversion is consistent: the X25519 public key derived from the converted private key matches the X25519 public key derived from the original Ed25519 public key. 14.11.6. 14.11.6. Translation Rules +=========================+=============================+ | Direction | Operation | +=========================+=============================+ | PAP → DIDComm Plaintext | Serialize PAP Envelope into | | | DIDComm body | +-------------------------+-----------------------------+ | PAP → DIDComm Signed | Build plaintext, then apply | | | Ed25519 JWS | +-------------------------+-----------------------------+ | PAP → DIDComm Encrypted | Build plaintext, then apply | Baur Expires 21 November 2026 [Page 67] Internet-Draft PAP May 2026 | | ECDH-ES + A256GCM JWE | +-------------------------+-----------------------------+ | DIDComm Plaintext → PAP | Deserialize body field as | | | PAP Envelope | +-------------------------+-----------------------------+ | DIDComm Signed → PAP | Verify JWS, then extract | | | PAP Envelope from body | +-------------------------+-----------------------------+ | DIDComm Encrypted → PAP | Decrypt JWE, then extract | | | PAP Envelope from body | +-------------------------+-----------------------------+ Table 41 In all cases, the PAP Envelope.signature field (if present) remains intact and can be verified independently using the session's ephemeral key. 15. PAP URI Scheme 15.1. Overview The pap URI scheme identifies agents, capabilities, and resources within the Principal Agent Protocol. A pap:// URI is always an expression of *intent* — resolving one initiates a PAP mandate-scoped interaction, not a raw network request. The scheme family consists of three variants: +==============+====================================================+ | Scheme | Meaning | +==============+====================================================+ | pap:// | PAP-native transport; client negotiates protocol | +--------------+----------------------------------------------------+ | pap+https:// | PAP mandate scope applied over HTTPS transport | +--------------+----------------------------------------------------+ | pap+wss:// | PAP mandate scope applied over WebSocket | | | transport | +--------------+----------------------------------------------------+ Table 42 Baur Expires 21 November 2026 [Page 68] Internet-Draft PAP May 2026 pap+https:// and pap+wss:// are *recapture schemes*. They apply PAP semantics — mandate enforcement, selective disclosure, co-signed receipts — to existing transports. The remote endpoint does not need to implement PAP. The client enforces the protocol locally. A pap+https:// URI is still an HTTPS request under the hood; the principal's mandate scope wraps it regardless of whether the server is PAP-aware. 15.2. Syntax pap-uri = pap-scheme "://" pap-authority pap-path [ "?" pap-query ] pap-scheme = "pap" / "pap+https" / "pap+wss" pap-authority = registry-host / did-authority / catalog-name registry-host = host [ ":" port ] ; authority is the hostname only; agent slug appears in path did-authority = "did:key:" base58-multicodec-key ; PAP parsers MUST treat "did:key:" as an atomic authority ; token. Standard RFC 3986 host parsing (which disallows ; colons) MUST NOT be applied to did-authority. A PAP URI ; parser identifies did-authority by the "did:key:" prefix ; before applying any other rule. catalog-name = 1*( ALPHA / DIGIT / "-" / "_" ) ; MUST NOT be a reserved word (receipt, canvas, settings) ; resolved against local catalog before dispatch pap-path = registry-path / simple-path registry-path = "/agents/" agent-slug "/" schema-action-type simple-path = "/" schema-action-type ; Schema.org action type, e.g. "SearchAction" pap-query = pap-param *( "&" pap-param ) pap-param = schema-property "=" pap-value ; values MUST be percent-encoded per RFC 3986 §2.1 ; "+" MUST NOT be used as a space encoding in pap-query Examples: Baur Expires 21 November 2026 [Page 69] Internet-Draft PAP May 2026 ; Networked agent via Chrysalis registry pap://chrysalis.example.com/agents/arxiv/SearchAction?query=quantum%20computing ; Direct peer-to-peer via DID (no registry) pap://did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK/SearchAction ; Local catalog shorthand — resolved before dispatch pap://arxiv/SearchAction?query=quantum%20computing pap://wikipedia/ReadAction?name=Rust%20programming ; Receipt deep-link pap://receipt/RCP_abc123 ; Recapture schemes — PAP scope over existing transports pap+https://api.example.com/agents/bookings/BuyAction?offer=flight-abc pap+wss://stream.example.com/agents/feed/ListenAction 15.3. Resolution A conforming client MUST resolve a pap:// URI using the following priority chain, in order: 1. *Special authority* — if the authority is one of the reserved words (receipt, canvas, settings), resolve locally without any network lookup. See §15.7. Do not proceed to subsequent steps. 2. *did:key: authority* — if the authority begins with did:key:, resolve directly via DID Document endpoint discovery (Section 14.4). No registry lookup. Initiates a PAP handshake with the identified agent. 3. *Catalog name* — if the authority contains no . character and does not begin with did:, the client MUST check its local agent catalog for an entry whose name field matches the authority (case-insensitive). If found, rewrite the URI to the agent's registered DID and resolve via step 1. 4. *Registry hostname* — if the authority contains a . character, or matches localhost, or is a valid IPv4 address or IPv6 literal, treat it as a Chrysalis registry host. Resolve by querying the registry's /agents/{slug}/ routes (Section 14.1) using the path- embedded agent slug, and initiate a PAP handshake with the returned agent endpoint. The . heuristic MUST NOT be applied to localhost or IP literals; they are always treated as registry hosts. Baur Expires 21 November 2026 [Page 70] Internet-Draft PAP May 2026 If resolution fails at all steps, the client MUST render an inline error in place of the activated link, showing the unresolved URI and a human-readable explanation. The client MUST NOT navigate away from the current canvas or dismiss existing content. The client MUST NOT silently fall back to a raw HTTP request. 15.4. Action Type and Query Parameters The action type path segment MUST be a Schema.org action type (e.g. SearchAction, BuyAction, ReadAction). For registry URIs the full path is /agents/{slug}/{ActionType}; for catalog and DID URIs the path is /{ActionType}. Clients SHOULD use the action type to pre- filter agents during resolution — if a catalog agent does not advertise the requested action type in its capability array, it MUST NOT be selected. Query parameters MUST use Schema.org property names as keys. Values MUST be percent-encoded per RFC 3986 §2.1; + MUST NOT be used as a space encoding. Clients MAY pass query parameters directly to the agent as the intent payload. Agents MAY ignore unknown parameters. 15.5. Recapture Semantics (pap+https://, pap+wss://) When a pap+https:// or pap+wss:// URI is resolved: 1. The active mandate scope MUST be checked before the request is made. If no mandate is in scope, the client MUST NOT proceed. 2. The request is made over the underlying transport (HTTPS or WSS) with the standard PAP session headers included where the server accepts them. 3. The client MUST record what was disclosed and generate a receipt entry regardless of whether the server participates in the PAP handshake. 4. The remote endpoint's response is treated as agent output and rendered via the standard block renderer pipeline. For pap+wss:// URIs, the connection lifecycle (establishment, keepalive, and termination) follows the mandate-scoped session lifecycle defined in §5. Streaming-specific semantics (chunked responses, event framing) are deferred to v1.1. This allows principals to bring existing web services under PAP governance without requiring those services to be modified. Baur Expires 21 November 2026 [Page 71] Internet-Draft PAP May 2026 *v1.0 scope note:* In v1.0, pap+https:// and pap+wss:// URIs are parsed and classified by conforming clients. Full mandate enforcement (steps 1–4 above) requires the mandate enforcement layer, which is deferred to a post-v1.0 milestone. v1.0 clients MUST NOT silently downgrade a pap+https:// URI to an unscoped HTTPS request. They MUST either enforce the mandate or reject the request with a clear principal-visible error explaining that recapture enforcement is not yet available. 15.6. Link Rendering Any string value in a JSON-LD agent response that begins with pap://, pap+https://, or pap+wss:// MUST be rendered as a navigable link by conforming clients. Activating such a link MUST dispatch the URI as intent through the same pipeline as a principal-typed query — it is not a browser navigation event. This enables agent-rendered content to form a navigable graph of intent-links without requiring any special page routing. Every link is a new PAP interaction. *Agent-rendered link security:* Clients MUST visually distinguish links originating from agent-rendered content from links typed directly by the principal. Before dispatching an agent-rendered pap:// link, clients SHOULD display the full URI and the identity of the agent that produced it, and require explicit principal confirmation. This prevents injection attacks where a malicious or compromised agent response induces the client to execute unintended actions. Agent-rendered links MUST NOT activate the settings, canvas, or receipt special authorities (§15.7). Clients MUST silently reject such links and MAY log the attempt for principal review. 15.7. Special Authorities The following authority values are reserved and MUST be handled by the client without registry or catalog lookup: Baur Expires 21 November 2026 [Page 72] Internet-Draft PAP May 2026 +===========+=====================================+ | Authority | Meaning | +===========+=====================================+ | receipt | Deep-link to a receipt by session | | | ID. pap://receipt/{session-id} | | | opens the receipt detail view. | +-----------+-------------------------------------+ | canvas | Deep-link to a canvas block. | | | pap://canvas/{canvas-id}/{block-id} | | | navigates to the referenced block. | +-----------+-------------------------------------+ | settings | Opens the settings panel. | | | pap://settings/{tab} opens a | | | specific tab. | +-----------+-------------------------------------+ Table 43 16. Security Considerations 16.1. Cryptographic Algorithms PAP v1.0 uses exclusively: * *Ed25519* (RFC 8032) for all signatures. * *SHA-256* (FIPS 180-4) for all hashes. * *Base64url without padding* (RFC 4648 Section 5) for all binary- to-text encoding. * *Base58btc* for DID key encoding. Implementations MUST use these algorithms for PAP v1.0. All signable structures carry a SignatureAlgorithm field (serialized as the JWS alg string, e.g. "EdDSA") to enable forward-compatible algorithm negotiation. The field defaults to Ed25519 when absent. Implementations MUST reject algorithms they do not support. The did:key multicodec prefix encodes the algorithm of the public key. Future versions of this specification MAY introduce additional algorithms (e.g., ML-DSA-65 for post-quantum resistance). 16.2. Key Management * Principal private keys SHOULD be stored in hardware security modules or platform authenticators (WebAuthn). They MUST NOT be stored in plaintext in configuration files or environment variables in production. * Session private keys MUST be held only in memory for the duration of the session. They MUST NOT be persisted to disk. Baur Expires 21 November 2026 [Page 73] Internet-Draft PAP May 2026 * Signing keys for agent operators (used to sign advertisements) SHOULD be protected with access controls appropriate to the deployment environment. 16.3. Nonce Management * Capability token nonces MUST be stored in a consumed-nonce set for at least the duration of the token's validity period. * Implementations SHOULD periodically purge expired nonces to prevent unbounded growth of the consumed-nonce set. * If a receiver restarts and loses its consumed-nonce set, it SHOULD reject all tokens issued before the restart by comparing issued_at against its restart timestamp. 16.4. Replay Protection Multiple layers provide replay protection: 1. *Token nonces:* Each capability token has a UUID v4 nonce consumed on first use. 2. *Envelope sequencing:* Sequence numbers are monotonically increasing within a session. Out-of-order envelopes MUST be rejected. 3. *Token expiry:* Tokens carry an expires_at timestamp. Expired tokens MUST be rejected. 4. *Session ephemerality:* Session keys are discarded at close. A replayed session message cannot be verified against the original session keys. 16.5. Denial of Service * Implementations SHOULD rate-limit token presentation requests to prevent resource exhaustion from session initiation floods. * Federation sync operations SHOULD be rate-limited per peer. * Marketplace registries SHOULD limit the number of advertisements per operator DID. 16.6. Man-in-the-Middle * After Phase 2 (DID exchange), all envelopes MUST be signed by the sender's session key. An attacker who intercepts envelopes cannot forge valid signatures without the session private key. * The initial token presentation (Phase 1) is protected by the orchestrator's signature on the capability token. An attacker cannot forge a valid token without the orchestrator's private key. * Implementations SHOULD use TLS for all HTTP transport to protect against passive eavesdropping. Baur Expires 21 November 2026 [Page 74] Internet-Draft PAP May 2026 16.7. Context Leakage * The DisclosureOffer (Phase 3) MUST contain only SD-JWT disclosures permitted by the mandate's disclosure set. * The orchestrator MUST verify that the agent's requires_disclosure is satisfiable by the mandate before issuing a capability token. An agent MUST NOT receive a token if its disclosure requirements exceed the principal's authorization. * Receipts MUST NOT contain personal data values (Section 11.5). 16.8. Mandate Chain Depth Implementations SHOULD enforce a maximum mandate chain depth to prevent resource exhaustion during chain verification. A maximum depth of 10 is RECOMMENDED. 16.9. Clock Skew * Implementations MUST use UTC for all timestamps. * Implementations SHOULD tolerate clock skew of up to 30 seconds for token expiry and mandate TTL checks. * Implementations MAY use NTP or similar time synchronization protocols to minimize skew. 16.10. Canonical JSON Determinism The security of mandate hashing and signature verification depends on deterministic JSON serialization. Implementations MUST ensure that the canonical JSON form produces identical bytes for the same logical content. Implementations SHOULD: - Use a JSON serializer that produces consistent key ordering. - Represent numbers without unnecessary precision. - Use RFC 3339 with explicit UTC offset for all timestamps. If an implementation cannot guarantee deterministic JSON output, it MUST use an alternative canonical form (e.g., JCS [RFC 8785]) and document the choice. 16.11. Attack Surface Summary +===================+=============================+==============+ | Attack Vector | Mitigation | Spec Section | +===================+=============================+==============+ | Context profiling | Ephemeral session DIDs | 4.4, 6.3.2 | +-------------------+-----------------------------+--------------+ | Over-disclosure | SD-JWT structural binding + | 7, 9.3 | Baur Expires 21 November 2026 [Page 75] Internet-Draft PAP May 2026 | | marketplace filtering | | +-------------------+-----------------------------+--------------+ | Replay attacks | Nonce consumption + | 6.2.2, 8.2.2 | | | envelope sequencing | | +-------------------+-----------------------------+--------------+ | Delegation bypass | Scope containment + TTL | 5.4.5, 5.5 | | | bounds | | +-------------------+-----------------------------+--------------+ | Mandate tampering | Parent hash + signature | 5.3, 5.6 | | | chain | | +-------------------+-----------------------------+--------------+ | Platform lock-in | Federated discovery, no | 10 | | | central registry | | +-------------------+-----------------------------+--------------+ | Payment | ZK commitments (Lightning | 13.1 | | linkability | BOLT-11, Cashu ecash) | | +-------------------+-----------------------------+--------------+ | Session | Session keys discarded at | 4.4, 6.3.6 | | correlation | close | | +-------------------+-----------------------------+--------------+ | Stale | Decay state machine + non- | 5.7 | | authorization | renewal revocation | | +-------------------+-----------------------------+--------------+ | Advertisement | Signed advertisements, | 9.4 | | spoofing | registry rejects unsigned | | +-------------------+-----------------------------+--------------+ | Retention | TEE attestation for | 5.4.4.1, | | violation | no_retention sessions | 13.6 | +-------------------+-----------------------------+--------------+ | Vouch ring / | Vouch budget + age | 10.7.3 | | Sybil peers | requirement + diverse paths | | +-------------------+-----------------------------+--------------+ | Metric-based | Anti-ranking requirement on | 9.6 | | ranking capture | marketplace queries | | +-------------------+-----------------------------+--------------+ Table 44 Appendix A. Example: Zero-Disclosure Search This appendix illustrates a complete PAP transaction with zero personal disclosure. A.1. A.1. Setup Principal generates keypair -> did:key:zPrincipal Orchestrator keypair -> did:key:zOrch Search agent operator keypair -> did:key:zSearch Baur Expires 21 November 2026 [Page 76] Internet-Draft PAP May 2026 A.2. A.2. Root Mandate { "principal_did": "did:key:zPrincipal", "agent_did": "did:key:zOrch", "issuer_did": "did:key:zPrincipal", "parent_mandate_hash": null, "scope": { "actions": [{"action": "schema:SearchAction"}] }, "disclosure_set": {"entries": []}, "ttl": "2026-03-15T20:00:00+00:00", "decay_state": "Active", "issued_at": "2026-03-15T16:00:00+00:00", "payment_proof": null, "signature": "" } A.3. A.3. Marketplace Query query_satisfiable("schema:SearchAction", available=[]) -> [SearchAgent] (requires_disclosure: []) -> Filtered out: agents requiring personal disclosure A.4. A.4. Session Handshake Phase 1: Orchestrator -> SearchAgent: TokenPresentation SearchAgent -> Orchestrator: TokenAccepted(session_id, recv_did) Phase 2: Orchestrator -> SearchAgent: SessionDidExchange(init_did) SearchAgent -> Orchestrator: SessionDidAck Phase 3: Orchestrator -> SearchAgent: DisclosureOffer([]) SearchAgent -> Orchestrator: DisclosureAccepted Phase 4: SearchAgent -> Orchestrator: ExecutionResult({...}) Phase 5: Orchestrator -> SearchAgent: ReceiptForCoSign(receipt) SearchAgent -> Orchestrator: ReceiptCoSigned(receipt) Phase 6: Orchestrator -> SearchAgent: SessionClose SearchAgent -> Orchestrator: SessionClosed A.5. A.5. Receipt Baur Expires 21 November 2026 [Page 77] Internet-Draft PAP May 2026 { "session_id": "", "action": "schema:SearchAction", "initiating_agent_did": "did:key:zInitSess", "receiving_agent_did": "did:key:zRecvSess", "disclosed_by_initiator": [], "disclosed_by_receiver": ["operator:search_executed"], "executed": "schema:SearchAction executed", "returned": "schema:SearchResult returned", "timestamp": "2026-03-15T16:05:00+00:00", "signatures": ["", ""] } Zero personal properties disclosed. Both session DIDs are ephemeral and discarded. The receipt is auditable but contains no personal data. Appendix B. Example: Selective Disclosure Flight Booking B.1. B.1. Disclosure Set { "entries": [{ "type": "schema:Person", "permitted_properties": ["schema:name", "schema:nationality"], "prohibited_properties": ["schema:email", "schema:telephone"], "session_only": true, "no_retention": true }] } B.2. B.2. SD-JWT Claims Claims: {name: "Alice", email: "alice@example.com", nationality: "US", telephone: "+1-555-0100"} Disclosed: [name, nationality] Withheld: [email, telephone] (cryptographically uncommitted) B.3. B.3. Marketplace Filtering SkyBook Flight Agent: requires [name, nationality] -> satisfiable LuxAir Premium Agent: requires [name, nationality, email] -> FILTERED OUT StayWell Hotel Agent: wrong object type -> not matched B.4. B.4. Receipt Baur Expires 21 November 2026 [Page 78] Internet-Draft PAP May 2026 { "disclosed_by_initiator": [ "schema:Person.schema:name", "schema:Person.schema:nationality" ], "disclosed_by_receiver": ["operator:booking_confirmed"] } Values "Alice" and "US" never appear in the receipt. Appendix C. Example: 4-Level Delegation Chain Level 0: Principal (root of trust) Level 1: Orchestrator scope: [Search, Reserve(Flight), Reserve(Lodging), Pay] ttl: 4h Level 2: Trip Planner (delegated from Orchestrator) scope: [Search, Reserve(Flight)] (subset of Level 1) ttl: 3h (< 4h) parent_mandate_hash: hash(Level 1 mandate) Level 3: Booking Agent (delegated from Trip Planner) scope: [Reserve(Flight)] (subset of Level 2) ttl: 2h (< 3h) parent_mandate_hash: hash(Level 2 mandate) Attempted violations: - Booking Agent delegates PayAction -> DelegationExceedsScope - Booking Agent delegates with TTL > 2h -> DelegationExceedsTtl Chain verification: verify_chain([principal_key, orch_key, planner_key]) Appendix D. Conformance Test Matrix A conformant PAP v1.0 implementation MUST pass all tests in the *Core* category. Tests in the *Extension* category apply only when the implementation supports the corresponding extension. D.1. D.1. Core Protocol Tests +======+================================+=========+=============+ | ID | Test | Spec | Requirement | | | | Section | | +======+================================+=========+=============+ | C-01 | Root mandate sign and verify | 5.2 | MUST | +------+--------------------------------+---------+-------------+ Baur Expires 21 November 2026 [Page 79] Internet-Draft PAP May 2026 | C-02 | Mandate hash determinism (same | 5.3 | MUST | | | input produces same hash) | | | +------+--------------------------------+---------+-------------+ | C-03 | Scope containment: child | 5.4.5 | MUST | | | subset of parent accepted | | | +------+--------------------------------+---------+-------------+ | C-04 | Scope containment: child | 5.4.5, | MUST | | | exceeding parent rejected | 5.5 R1 | | +------+--------------------------------+---------+-------------+ | C-05 | Scope containment: child | 5.4.5 | MUST | | | broadening object constraint | | | | | rejected | | | +------+--------------------------------+---------+-------------+ | C-06 | Delegation TTL: child TTL <= | 5.5 R2 | MUST | | | parent TTL accepted | | | +------+--------------------------------+---------+-------------+ | C-07 | Delegation TTL: child TTL > | 5.5 R2 | MUST | | | parent TTL rejected | | | +------+--------------------------------+---------+-------------+ | C-08 | Parent hash binding: correct | 5.5 R3 | MUST | | | hash accepted | | | +------+--------------------------------+---------+-------------+ | C-09 | Parent hash binding: incorrect | 5.5 R3 | MUST | | | hash rejected | | | +------+--------------------------------+---------+-------------+ | C-10 | Issuer chain: child issuer_did | 5.5 R4 | MUST | | | == parent agent_did | | | +------+--------------------------------+---------+-------------+ | C-11 | Principal propagation: child | 5.5 R5 | MUST | | | principal_did == parent | | | | | principal_did | | | +------+--------------------------------+---------+-------------+ | C-12 | Root mandate: | 5.5 R6 | MUST | | | parent_mandate_hash is null | | | +------+--------------------------------+---------+-------------+ | C-13 | Mandate chain verification: | 5.6 | MUST | | | 2-level chain | | | +------+--------------------------------+---------+-------------+ | C-14 | Mandate chain verification: | 5.6 | MUST | | | 3-level chain | | | +------+--------------------------------+---------+-------------+ | C-15 | Mandate chain verification: | 5.6 | MUST | | | invalid signature in chain | | | | | rejected | | | +------+--------------------------------+---------+-------------+ | C-16 | Decay state: Active within TTL | 5.7 | MUST | +------+--------------------------------+---------+-------------+ | C-17 | Decay state: Degraded within | 5.7 | MUST | Baur Expires 21 November 2026 [Page 80] Internet-Draft PAP May 2026 | | decay window | | | +------+--------------------------------+---------+-------------+ | C-18 | Decay state: ReadOnly after | 5.7 | MUST | | | TTL expiry | | | +------+--------------------------------+---------+-------------+ | C-19 | Decay state: Suspended is | 5.7.1 | MUST | | | terminal (no renewal) | | | +------+--------------------------------+---------+-------------+ | C-20 | Decay state: invalid | 5.7.1 | MUST | | | transition rejected | | | +------+--------------------------------+---------+-------------+ | C-21 | Capability token sign and | 6.2 | MUST | | | verify | | | +------+--------------------------------+---------+-------------+ | C-22 | Capability token: wrong | 6.2.2 | MUST | | | target_did rejected | | | +------+--------------------------------+---------+-------------+ | C-23 | Capability token: nonce replay | 6.2.2 | MUST | | | rejected | | | +------+--------------------------------+---------+-------------+ | C-24 | Capability token: expired | 6.2.2 | MUST | | | token rejected | | | +------+--------------------------------+---------+-------------+ | C-25 | Session state machine: | 6.1 | MUST | | | Initiated -> Open -> Executed | | | | | -> Closed | | | +------+--------------------------------+---------+-------------+ | C-26 | Session state machine: invalid | 6.1 | MUST | | | transition rejected | | | +------+--------------------------------+---------+-------------+ | C-27 | Session state machine: early | 6.1 | MUST | | | termination from Initiated | | | +------+--------------------------------+---------+-------------+ | C-28 | SD-JWT commitment and | 7.4, | MUST | | | disclosure verification | 7.5 | | +------+--------------------------------+---------+-------------+ | C-29 | SD-JWT: disclosure hash not in | 7.5 | MUST | | | commitment rejected | | | +------+--------------------------------+---------+-------------+ | C-30 | SD-JWT: unsigned commitment | 7.4 | MUST | | | rejected | | | +------+--------------------------------+---------+-------------+ | C-31 | SD-JWT: zero-disclosure | 7.6 | MUST | | | session accepted | | | +------+--------------------------------+---------+-------------+ | C-32 | SD-JWT: partial disclosure | 7.3 | MUST | | | (subset of claims) | | | +------+--------------------------------+---------+-------------+ Baur Expires 21 November 2026 [Page 81] Internet-Draft PAP May 2026 | C-33 | Envelope sign and verify with | 8.2.1 | MUST | | | session keys | | | +------+--------------------------------+---------+-------------+ | C-34 | Envelope: wrong key | 8.2.2 | MUST | | | verification fails | | | +------+--------------------------------+---------+-------------+ | C-35 | Envelope: out-of-sequence | 8.2.2 | MUST | | | rejected | | | +------+--------------------------------+---------+-------------+ | C-36 | Envelope: tampered payload | 8.2.1 | MUST | | | detected | | | +------+--------------------------------+---------+-------------+ | C-37 | Receipt: co-signed by both | 11.3 | MUST | | | parties | | | +------+--------------------------------+---------+-------------+ | C-38 | Receipt: contains property | 11.5 | MUST | | | references, not values | | | +------+--------------------------------+---------+-------------+ | C-39 | Receipt: zero-disclosure | 11.5 | MUST | | | receipt valid | | | +------+--------------------------------+---------+-------------+ | C-40 | Receipt: wrong key co-sign | 11.4 | MUST | | | verification fails | | | +------+--------------------------------+---------+-------------+ | C-41 | Advertisement: unsigned | 9.4 | MUST | | | advertisement rejected by | | | | | registry | | | +------+--------------------------------+---------+-------------+ | C-42 | Advertisement: content hash | 9.5, | MUST | | | deduplication | 10.5 | | +------+--------------------------------+---------+-------------+ | C-43 | Marketplace: query by action | 9.3 | MUST | | | returns matching agents | | | +------+--------------------------------+---------+-------------+ | C-44 | Marketplace: disclosure | 9.3 | MUST | | | satisfiability filtering | | | +------+--------------------------------+---------+-------------+ | C-45 | VC envelope: wrap and unwrap | 12.2 | MUST | | | mandate | | | +------+--------------------------------+---------+-------------+ | C-46 | VC envelope: unsigned VC | 12.3 | MUST | | | rejected | | | +------+--------------------------------+---------+-------------+ | C-47 | Session: no_retention | 5.4.4.1 | MUST | | | disclosure rejected without | | | | | TEE attestation | | | +------+--------------------------------+---------+-------------+ | C-48 | Session attestation: sign and | 11.6 | MUST | Baur Expires 21 November 2026 [Page 82] Internet-Draft PAP May 2026 | | verify bilateral attestation | | | +------+--------------------------------+---------+-------------+ | C-49 | Session attestation: per- | 11.6 | MUST | | | action-type segmentation | | | | | enforced | | | +------+--------------------------------+---------+-------------+ Table 45 D.2. D.2. Transport Tests +======+===========================+==============+=============+ | ID | Test | Spec Section | Requirement | +======+===========================+==============+=============+ | T-01 | HTTP/JSON: full 6-phase | 14.2 | MUST | | | handshake over HTTP | | | +------+---------------------------+--------------+-------------+ | T-02 | HTTP/JSON: error response | 14.6 | MUST | | | with code and message | | | +------+---------------------------+--------------+-------------+ | T-03 | HTTP/JSON: wrong message | 14.6 | MUST | | | type returns 400 | | | +------+---------------------------+--------------+-------------+ | T-04 | WebSocket: full 6-phase | 14.7 | OPTIONAL | | | handshake over WebSocket | | | +------+---------------------------+--------------+-------------+ | T-05 | WebSocket: binary frame | 14.7.3 | OPTIONAL | | | rejected | | | +------+---------------------------+--------------+-------------+ | T-06 | OHTTP: encapsulated | 14.8 | OPTIONAL | | | request reaches gateway | | | +------+---------------------------+--------------+-------------+ | T-07 | DIDComm: message mapping | 14.9.1 | OPTIONAL | | | roundtrip | | | +------+---------------------------+--------------+-------------+ Table 46 D.3. D.3. Extension Tests +======+==============================+=========+=============+ | ID | Test | Spec | Requirement | | | | Section | | +======+==============================+=========+=============+ | E-01 | Payment proof: mandate with | 13.1, | OPTIONAL | | | valid proof accepted | 13.7 | | +------+------------------------------+---------+-------------+ | E-02 | Payment proof: unsupported | 13.7.2 | OPTIONAL | Baur Expires 21 November 2026 [Page 83] Internet-Draft PAP May 2026 | | format rejected | | | +------+------------------------------+---------+-------------+ | E-03 | Payment proof: double-spend | 13.7.2 | OPTIONAL | | | rejected | | | +------+------------------------------+---------+-------------+ | E-04 | Continuity token: creation | 13.3 | OPTIONAL | | | and expiry check | | | +------+------------------------------+---------+-------------+ | E-05 | Continuity token: expired | 13.3.1 | OPTIONAL | | | token rejected | | | +------+------------------------------+---------+-------------+ | E-06 | Continuity token: principal- | 13.3.2 | OPTIONAL | | | controlled TTL | | | +------+------------------------------+---------+-------------+ | E-07 | Auto-approval: policy within | 13.4 | OPTIONAL | | | mandate scope accepted | | | +------+------------------------------+---------+-------------+ | E-08 | Auto-approval: policy | 13.4.1 | OPTIONAL | | | exceeding mandate rejected | | | +------+------------------------------+---------+-------------+ | E-09 | Auto-approval: transaction | 13.4.1 | OPTIONAL | | | exceeding max_value requires | | | | | approval | | | +------+------------------------------+---------+-------------+ | E-10 | Recovery mandate: | 13.5.1 | OPTIONAL | | | pap:RecoverAction in scope | | | +------+------------------------------+---------+-------------+ | E-11 | Recovery mandate: delegation | 13.5.3 | OPTIONAL | | | attempt rejected | | | +------+------------------------------+---------+-------------+ | E-12 | Recovery mandate: short TTL | 13.5.3 | OPTIONAL | | | enforced | | | +------+------------------------------+---------+-------------+ | E-13 | TEE attestation: valid | 13.6.2 | OPTIONAL | | | attestation with matching | | | | | nonce | | | +------+------------------------------+---------+-------------+ | E-14 | TEE attestation: stale | 13.6.2 | OPTIONAL | | | attestation rejected | | | +------+------------------------------+---------+-------------+ | E-15 | TEE attestation: does not | 13.6.3 | OPTIONAL | | | expand mandate scope | | | +------+------------------------------+---------+-------------+ | E-16 | Marketplace: query results | 9.6 | MUST | | | not ranked by operator | | | | | metrics | | | +------+------------------------------+---------+-------------+ | E-17 | Marketplace: operator | 9.6 | MUST | Baur Expires 21 November 2026 [Page 84] Internet-Draft PAP May 2026 | | metrics excluded from | | | | | content hash | | | +------+------------------------------+---------+-------------+ Table 47 D.4. D.4. Federation Tests +======+=================================+=========+=============+ | ID | Test | Spec | Requirement | | | | Section | | +======+=================================+=========+=============+ | F-01 | Federation: QueryByAction | 10.3, | MUST | | | returns matching advertisements | 10.4 | | +------+---------------------------------+---------+-------------+ | F-02 | Federation: Announce and | 10.3, | MUST | | | AnnounceAck roundtrip | 10.4 | | +------+---------------------------------+---------+-------------+ | F-03 | Federation: content-hash | 10.5 | MUST | | | deduplication on merge | | | +------+---------------------------------+---------+-------------+ | F-04 | Federation: unsigned | 10.5 | MUST | | | advertisement skipped on merge | | | +------+---------------------------------+---------+-------------+ | F-05 | Federation: transitive peer | 10.6 | OPTIONAL | | | discovery | | | +------+---------------------------------+---------+-------------+ | F-06 | Federation: peer registration | 10.7.2 | SHOULD | | | requires minimum vouches | | | +------+---------------------------------+---------+-------------+ | F-07 | Federation: vouch budget | 10.7.3 | SHOULD | | | enforced (max 3/year) | | | +------+---------------------------------+---------+-------------+ | F-08 | Federation: probationary peer | 10.7.3 | SHOULD | | | cannot vouch | | | +------+---------------------------------+---------+-------------+ | F-09 | Federation: vouch signature | 10.7.2 | MUST | | | verification | | | +------+---------------------------------+---------+-------------+ Table 48 D.5. D.5. Trust Invariant Summary A conformant implementation MUST demonstrate all eight trust invariants hold: Baur Expires 21 November 2026 [Page 85] Internet-Draft PAP May 2026 +======+=============================+==================+ | # | Invariant | Key Tests | +======+=============================+==================+ | TI-1 | Mandate scope is | C-03, C-04, C-05 | | | cryptographically bounded | | +------+-----------------------------+------------------+ | TI-2 | Session DIDs are ephemeral | C-25, C-27 | | | and unlinkable to principal | | +------+-----------------------------+------------------+ | TI-3 | Receipts contain property | C-37, C-38, C-39 | | | references, never values | | +------+-----------------------------+------------------+ | TI-4 | Delegation chains enforce | C-06, C-07, | | | depth and TTL bounds | C-13, C-14 | +------+-----------------------------+------------------+ | TI-5 | Decay states follow the | C-16, C-17, | | | defined state machine | C-18, C-19, C-20 | +------+-----------------------------+------------------+ | TI-6 | no_retention requires TEE | C-47 | | | attestation | | +------+-----------------------------+------------------+ | TI-7 | Marketplace queries are | E-16, E-17 | | | ranking-free | | +------+-----------------------------+------------------+ | TI-8 | Peer vouching enforces | F-06, F-07, F-08 | | | budget and age constraints | | +------+-----------------------------+------------------+ Table 49 _End of specification._ Appendix E. References E.1. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC 3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC 4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. Baur Expires 21 November 2026 [Page 86] Internet-Draft PAP May 2026 [RFC 8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017. [DID-CORE] Sporny, M., Guy, A., Sabadello, M., and D. Reed, "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, July 2022. [DID-KEY] Longley, D. and M. Sporny, "The did:key Method v0.7", W3C Community Group Report. [SD-JWT-08] Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JWTs (SD-JWT)", Internet-Draft draft-ietf-oauth- selective-disclosure-jwt-08. [VC-DATA-MODEL-2.0] Sporny, M., et al., "Verifiable Credentials Data Model v2.0", W3C Recommendation. [WEBAUTHN] Balfanz, D., et al., "Web Authentication: An API for accessing Public Key Credentials Level 2", W3C Recommendation. E.2. Informative References [RFC 8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020. [RFC 9458] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458, January 2024. [DIDCOMM-V2] Curren, S., Looker, T., and O. Terbu, "DIDComm Messaging v2.0", Decentralized Identity Foundation, 2022. [RFC 6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011. Appendix F. IANA and Vocabulary References F.1. Schema.org Vocabulary PAP uses Schema.org (https://schema.org (https://schema.org)) as the vocabulary for action types, object types, and property references. The following Schema.org types are referenced in this specification: *Action Types:* - schema:SearchAction -- Search for information - schema:ReserveAction -- Reserve a resource (flight, hotel, etc.) - schema:PayAction -- Make a payment - schema:CheckAction -- Check a condition or status - schema:ReadAction -- Read a resource Baur Expires 21 November 2026 [Page 87] Internet-Draft PAP May 2026 *Object Types:* - schema:Flight -- A flight - schema:Lodging -- Lodging accommodation - schema:WebPage -- A web page *Entity Types:* - schema:Person -- A person - schema:Organization -- An organization - schema:Service -- A service - schema:Order -- An order - schema:Subscription -- A subscription *Property References:* - schema:name -- Name of a person or entity - schema:email -- Email address - schema:telephone -- Phone number - schema:nationality -- Nationality Implementations MAY use additional Schema.org types and properties. Implementations MAY define additional namespaced vocabularies using a prefix notation (e.g., custom:MyAction). Custom vocabularies SHOULD be documented. F.2. W3C Standards +==========+====================================+==============+ | Standard | URI | Usage | +==========+====================================+==============+ | DID Core | https://www.w3.org/TR/did-core/ | DID document | | 1.0 | (https://www.w3.org/TR/did-core/) | structure | +----------+------------------------------------+--------------+ | DID Key | https://w3c-ccg.github.io/did- | did:key | | Method | method-key/ (https://w3c- | derivation | | | ccg.github.io/did-method-key/) | | +----------+------------------------------------+--------------+ | VC Data | https://www.w3.org/TR/vc-data- | Credential | | Model | model-2.0/ (https://www.w3.org/TR/ | envelope | | 2.0 | vc-data-model-2.0/) | | +----------+------------------------------------+--------------+ Table 50 F.3. IETF Standards +===================+=======================+====================+ | Standard | RFC/Draft | Usage | +===================+=======================+====================+ | RFC 2119 | Key words | Requirement levels | +-------------------+-----------------------+--------------------+ | RFC 8174 | Key words update | Requirement levels | | | | clarification | +-------------------+-----------------------+--------------------+ | RFC 3339 | Date and Time on the | Timestamp format | | | Internet | | +-------------------+-----------------------+--------------------+ Baur Expires 21 November 2026 [Page 88] Internet-Draft PAP May 2026 | RFC 4648 | Base Encodings | Base64url encoding | +-------------------+-----------------------+--------------------+ | RFC 8032 | Edwards-Curve Digital | Ed25519 signatures | | | Signature Algorithm | | +-------------------+-----------------------+--------------------+ | RFC 8785 | JSON Canonicalization | Canonical JSON | | | Scheme | (RECOMMENDED) | +-------------------+-----------------------+--------------------+ | RFC 9458 | Oblivious HTTP | OHTTP transport | | | | binding | | | | (Section 14.8) | +-------------------+-----------------------+--------------------+ | draft-ietf-oauth- | SD-JWT | Selective | | selective- | | disclosure | | disclosure-jwt-08 | | | +-------------------+-----------------------+--------------------+ Table 51 F.4. WebAuthn +================+=================================+==============+ | Standard | URI | Usage | +================+=================================+==============+ | Web | https://www.w3.org/TR/webauthn- | Device-bound | | Authentication | 2/ (https://www.w3.org/TR/ | key | | Level 2 | webauthn-2/) | generation | +----------------+---------------------------------+--------------+ Table 52 F.5. Multicodec The Ed25519 public key multicodec prefix is 0xed01 as registered in the Multicodec table (https://github.com/multiformats/multicodec (https://github.com/multiformats/multicodec)). F.6. Reserved Namespace Prefixes +===========+========================+===============+ | Prefix | Namespace | Authority | +===========+========================+===============+ | schema: | https://schema.org | Schema.org | | | (https://schema.org) | Community | +-----------+------------------------+---------------+ | operator: | Implementation-defined | Agent | | | | operator | +-----------+------------------------+---------------+ Baur Expires 21 November 2026 [Page 89] Internet-Draft PAP May 2026 | pap: | Reserved for PAP | PAP | | | extensions | specification | +-----------+------------------------+---------------+ Table 53 Appendix G. Changelog G.1. v1.0 (2026-03-24) * Promoted specification from Draft to Approved status. * *Section 13.5:* Added recovery mandate extension with recovery proof binding and short-TTL constraints. * *Section 13.6:* Added TEE attestation extension with enclave measurement verification and trust boundary rules. * *Section 13.7:* Added payment proof validation requirements including format registry, double-spend protection, and privacy constraints. * *Section 14.7:* Added WebSocket transport binding with connection lifecycle, message framing, and sequence enforcement. * *Section 14.8:* Added Oblivious HTTP (OHTTP) transport binding with relay architecture and key configuration. * *Section 14.9:* Added DIDComm v2 transport binding with message mapping and authenticated encryption. * *Section 14.10:* Added transport negotiation rules with privacy- preference ordering. * *Appendix D:* Added conformance test matrix. * Updated all version references from v0.1 to v1.0. * Added DIDComm and WebSocket to normative/informative references. G.2. v0.7 (2026-03-10) * Added recovery mandate extension (Section 13.5). * Added TEE attestation extension (Section 13.6). * Added payment proof format registry and validation (Section 13.7). G.3. v0.6 (2026-02-28) * Added WebSocket transport binding (Section 14.7). * Added OHTTP transport binding (Section 14.8). * Added DIDComm transport binding (Section 14.9). * Added transport negotiation (Section 14.10). G.4. v0.4 (2026-02-01) * Initial public draft with core protocol: - Trust model and threat model (Section 3). - Identity layer with did:key (Section 4). Baur Expires 21 November 2026 [Page 90] Internet-Draft PAP May 2026 - Mandate structure and delegation rules (Section 5). - Session lifecycle with 6-phase handshake (Section 6). - SD-JWT disclosure protocol (Section 7). - Protocol messages and envelope (Section 8). - Marketplace advertisement schema (Section 9). - Federation protocol (Section 10). - Receipt format (Section 11). - Verifiable Credential envelope (Section 12). - Payment proof integration point (Section 13.1). - Continuity tokens (Section 13.3). - Auto-approval policies (Section 13.4). - HTTP/JSON transport binding (Section 14.1--14.6). Author's Address Todd Baur Baur Software Email: todd@baursoftware.com Baur Expires 21 November 2026 [Page 91]