{"skill":{"id":"a4949635-bc07-4eec-ae3d-c1bca7b7a6d8","name":"Agent to Agent Contract","author":"CoolContract","description":"It facilitates binding contracts between Agents without human interveton","source_type":"content","source_url":null,"content":"---\r\nname: nanda-a2a-contracts\r\ndescription: >-\r\n  Implement, verify, and reason about enforceable Agent-to-Agent (A2A) contracts on the\r\n  NANDA network using the Enforceability Framework: Scope-of-Authority (SoA) tokens,\r\n  Delegation Credentials, and signed offer/accept transaction logging. Use this skill\r\n  whenever the user mentions agent-to-agent contracts, agent transactions, agent\r\n  authorization or delegation, SoA tokens, the NANDA Index, agent consent/capacity,\r\n  autonomous purchasing or negotiation between agents, revocation of agent authority,\r\n  transaction ceilings for agents, agent dispute evidence, or wants to design, review,\r\n  validate, or pilot any part of an agent commerce protocol — even if they don't name\r\n  NANDA explicitly. Also use it when drafting schemas, verification flows, or working-group\r\n  material about the legal enforceability of AI-agent commitments.\r\n---\r\n\r\n# NANDA Agent-to-Agent Contract Enforceability Framework\r\n\r\nA complete, self-contained reference and operational guide for giving agent-initiated\r\nagreements a clear, auditable basis for enforceability on the NANDA network — without\r\nrequiring new legislation before the framework can be piloted.\r\n\r\nThis skill lets you:\r\n\r\n1. **Explain** the framework — background, legal foundations, problem statement, the\r\n   contract-element mapping, scope limits, and the open questions, at any depth from a\r\n   two-sentence summary to a working-group deep dive.\r\n2. **Design and validate** the two credential artifacts — the Scope-of-Authority (SoA)\r\n   token and the Delegation Credential — field by field, against the reference schemas\r\n   and validation rules in this file.\r\n3. **Run the transaction workflows** — authority issuance, pre-transaction verification,\r\n   the negotiation message protocol, offer/accept formation, logging, revocation, and\r\n   dispute-evidence assembly — including the pseudocode and sequence diagrams needed to\r\n   implement them.\r\n4. **Assess security** — apply the threat model when reviewing designs or pilot code.\r\n5. **Draft working-group material** — specification text, pilot plans, comparisons to\r\n   adjacent standards, and structured answers to the open questions — consistent with\r\n   the original NANDA submission.\r\n\r\n**Fidelity rule for using this skill:** everything sourced from the original submission\r\nis normative for what the working group actually proposed. Everything marked *(proposed\r\ndraft)* — the concrete schemas, error codes, message protocol, cryptographic profile,\r\nthreat model — is elaboration offered for review, per the submission's own request for\r\nschema review. Never present a *(proposed draft)* element as something the working group\r\nhas already adopted.\r\n\r\n---\r\n\r\n## How to Use This Skill\r\n\r\n### Task playbook\r\n\r\nRoute the user's request to the right sections instead of reading the whole file\r\nlinearly:\r\n\r\n| User wants | What to do | Go to |\r\n|---|---|---|\r\n| A quick explanation of the framework | Use the canned summaries below; calibrate depth to the audience (executive → cheat sheet; lawyer → §2, §5, §18; engineer → §6–§9, §13) | §1–§5 |\r\n| Review or validate an artifact (token, credential, transaction record) | Walk the field-by-field tables, run the relevant checklist, cite failures by error code | §6–§8, §10, §16 |\r\n| Implement or write pilot code | Follow Workflows A–C, the message protocol, and the crypto profile; verify against the test matrix | §9–§14, §22.3 |\r\n| A security review of a design or implementation | Apply the threat table row by row; confirm the residual risks are disclosed, not hidden | §17, §16 |\r\n| Spec text or working-group material drafted | Apply the fidelity rule; keep the four open questions visibly open; use the standards positioning | §5, §19, §21, §22 |\r\n| \"Isn't this just OAuth / VCs / UCAN?\" | Answer from the comparison table: what each covers, what it lacks | §21 |\r\n| Enforceability or dispute analysis | Structure the answer around the four-question sequence; ground it in the legal foundations | §15, §2 |\r\n| A decision on an open question | Don't decide — present the options and trade-offs; recommendations must be labeled as yours | §19 |\r\n\r\n### Cheat sheet — the framework on one screen\r\n\r\n| Piece | One-liner |\r\n|---|---|\r\n| **Problem** | Agents form binding commitments with no human present; contract law anchors on human intent, signature, and capacity. |\r\n| **SoA token** | Signed by the principal: *what* the agent may commit to (categories, ceilings, counterparties, expiry). |\r\n| **Delegation Credential** | Signed chain from an accountable human/legal entity to the agent: *who* answers for it. |\r\n| **Transaction log** | Matched signed offer/accept pair + verification snapshot: *what* was agreed, with authority verifiably current. |\r\n| **Formation rule** | No matched signed pair in the log → no contract under this framework. |\r\n| **Verification rule** | Capacity → authority → scope-for-this-deal → revocation freshness; at handshake AND again at acceptance. |\r\n| **Failure rule** | Unknown revocation status ≠ valid. Fail closed. |\r\n| **Design stance** | Agency law made machine-verifiable; an evidentiary layer, not new legislation, not a dispute resolver. |\r\n\r\n### Canned summaries\r\n\r\n**Two sentences (any audience):** NANDA agents will negotiate and transact with no\r\nhuman present at the moment of agreement, and contract law's anchors — intent,\r\nsignature, capacity — don't map onto software. This framework closes the gap with\r\nthree artifacts anchored to the NANDA Index: a Scope-of-Authority token proving *what*\r\nan agent may commit to, a Delegation Credential proving *who* is accountable for it,\r\nand a logged, matched, signed offer/accept pair proving *what was agreed* while that\r\nauthority was verifiably current.\r\n\r\n**One paragraph (working-group register):** The framework is agency law made\r\nmachine-verifiable. A principal grants authority in a signed, scoped, expiring SoA\r\ntoken; a Delegation Credential chains the agent back to an accountable human or legal\r\nentity; contract formation is a matched pair of signed offer/accept messages logged\r\nwith a snapshot of the authority checks performed at acceptance. It requires no new\r\nlegislation to pilot — existing electronic-transaction statutes already recognize\r\nautomated contracting, and the framework supplies the standardized evidence those\r\nstatutes never specified. It deliberately does not choose governing law, override\r\nconsumer protection, or adjudicate disputes; it produces the evidence any forum would\r\nneed. Four design questions remain open for the working group: revocation timing,\r\nsingle vs. joint accountability, where the log lives, and whether the network should\r\nimpose a default human-in-the-loop ceiling.\r\n\r\n---\r\n\r\n## Table of Contents\r\n\r\n1. Background: Project NANDA and why contracts break\r\n2. Legal Foundations: why no new legislation is needed\r\n3. Problem Statement: the three enforceability gaps\r\n4. Framework Overview and design principles\r\n5. Legal Mapping: contract elements → agent equivalents\r\n6. Artifact 1 — Scope-of-Authority (SoA) Token *(schema, field reference, lifecycle, anti-patterns)*\r\n7. Artifact 2 — Delegation Credential *(schema, field reference, chain validation)*\r\n8. Artifact 3 — Transaction Log *(schema, canonicalization, matching)*\r\n9. Cryptographic Profile *(signatures, keys, hashing, time)*\r\n10. Workflow A — Issuing authority (principal side)\r\n11. Workflow B — Pre-transaction verification (counterparty side)\r\n12. Workflow C — Negotiation and contract formation *(incl. human-confirmation artifact)*\r\n13. Negotiation Message Protocol *(nine message types)*\r\n14. Workflow D — Revocation *(incl. revocation record schema)*\r\n15. Workflow E — Dispute evidence bundle\r\n16. Validation Rules and Error Codes\r\n17. Threat Model and Security Considerations\r\n18. Scope and Limits: what this framework does NOT do\r\n19. Open Questions for the Working Group — expanded analysis\r\n20. Relationship to Other NANDA Workstreams\r\n21. Relationship to Existing Standards\r\n22. Pilot Plan, Test Matrix, and Requested Next Steps\r\n23. Worked End-to-End Examples\r\n24. FAQ\r\n25. Glossary\r\n\r\n---\r\n\r\n## 1. Background\r\n\r\n### 1.1 What Project NANDA is building\r\n\r\nProject NANDA (originating at MIT) is building infrastructure for the \"Internet of AI\r\nagents\": a decentralized network on which AI agents can **discover one another, verify\r\nidentity, and transact autonomously**. Its architecture centers on the **NANDA Index** —\r\na lean identity/verification layer that resolves an agent identifier to its identity\r\nrecord, keys, and metadata — with federation layers above it so that independently\r\noperated registries interoperate rather than fragmenting into silos.\r\n\r\nNANDA's own architecture describes agents that will *\"navigate autonomously, socialize,\r\nlearn, earn and transact on our behalf.\"* Take that sentence seriously: **\"earn and\r\ntransact\" implies binding commitments — offers made, acceptances given, money moved —\r\nwithout a human directly present at the moment of agreement.** The whole economic\r\npromise of the agent internet rests on those commitments actually binding the humans and\r\ncompanies behind the agents.\r\n\r\n### 1.2 Why current contract law doesn't map\r\n\r\nContract law across essentially all jurisdictions is organized around three\r\nhuman-centric anchors:\r\n\r\n| Anchor | What the law asks | Why it breaks for agents |\r\n|---|---|---|\r\n| **Human intent** | What did this person mean to agree to? | An agent has no legally cognizable intent of its own; its \"intent\" is a policy configured by someone else, possibly months earlier, possibly by a chain of other agents. |\r\n| **Signature** | Did a human perform an act of assent (sign, click, speak)? | The agent signs with a key. Whose act is that? The developer's? The deployer's? The user who typed the goal prompt? |\r\n| **Capacity** | Is the party an adult of sound mind, or a duly formed legal entity? | Software has no legal personhood. An agent cannot itself be the contracting party — someone must stand behind it, and today there is no standard way to prove who. |\r\n\r\nThe classical legal answer to \"a non-person acting for a person\" is **agency law** (see\r\n§2), and this framework is best understood as *agency law made machine-verifiable*. The\r\nprincipal is bound because the principal verifiably granted authority; the agent's\r\nsignature counts as assent because it demonstrably fell within that grant.\r\n\r\n### 1.3 What this submission proposes\r\n\r\nA **lightweight A2A Contract Enforceability Framework** that sits alongside NANDA's\r\nexisting identity and federation layers. The goal is narrow and practical: **give\r\nagent-initiated agreements a clear, auditable basis for enforceability, without\r\nrequiring new legislation before the framework can be piloted.** It introduces two\r\ncredential artifacts (SoA token, Delegation Credential) and one logging requirement\r\n(matched signed offer/accept pairs), all anchored to the NANDA Index.\r\n\r\nWhen explaining the framework, always foreground this design stance: it produces **proof\r\nof authorization and assent** — an evidentiary layer that a court, arbitrator, or\r\nautomated dispute-resolution process in any jurisdiction can rely on. It does not create\r\na new species of legal person, does not pick a governing law, and does not adjudicate\r\ndisputes (see §18).\r\n\r\n## 2. Legal Foundations\r\n\r\nThis section explains *why* the framework can honestly claim \"no new legislation needed\r\nbefore piloting.\" Use it when a lawyer, regulator, or skeptical working-group member\r\nasks what the enforceability theory actually is. (This is supporting analysis consistent\r\nwith the submission's claim; the submission itself states the claim without the full\r\ndoctrinal walk-through.)\r\n\r\n### 2.1 Agency law: the load-bearing doctrine\r\n\r\nUnder ordinary agency principles (in U.S. terms, the Restatement (Third) of Agency;\r\nevery major legal system has a close equivalent), **a principal is bound by the acts of\r\nan agent performed with actual authority** — authority the principal manifested to the\r\nagent. The doctrine has never required the agent to be human in its economic logic; it\r\nrequires an accountable principal, a grant of authority, and an act within that grant.\r\n\r\nThe framework's artifacts are precisely these three things made machine-verifiable:\r\n\r\n- **Delegation Credential** → there is an accountable principal, and here is the proof\r\n  chain connecting this agent to them.\r\n- **SoA token** → here is the grant of authority, in machine-readable terms, signed by\r\n  the principal.\r\n- **Signed transaction within scope** → here is the act, and here is the demonstration\r\n  that it fell within the grant.\r\n\r\nA signed transaction *outside* the SoA scope is, correspondingly, evidence of an\r\n**unauthorized act**: the counterparty who verified scope before accepting is protected;\r\nthe counterparty who skipped verification knowingly bore the risk — and the log shows\r\nwhich happened. This symmetry is what makes the framework fair to both sides.\r\n\r\n### 2.2 Electronic-transaction statutes already contemplate agents\r\n\r\nKey existing law already validates automated contracting, which is why a pilot needs no\r\nstatutory change:\r\n\r\n- **UETA (Uniform Electronic Transactions Act, U.S. states)** — expressly defines\r\n  \"electronic agent\" and provides that a contract may be formed by the interaction of\r\n  electronic agents even if no individual was aware of or reviewed the agents' actions.\r\n- **E-SIGN Act (U.S. federal, 2000)** — gives electronic signatures and records legal\r\n  effect; a contract may not be denied enforceability solely because an electronic agent\r\n  was used in its formation.\r\n- **UNCITRAL Model Law on Electronic Commerce / UN Convention on Electronic\r\n  Communications in International Contracts** — the international analogs: automated\r\n  message systems can form contracts, and communications aren't invalid merely for lack\r\n  of human review.\r\n\r\nWhat these statutes do **not** provide — and what the framework adds — is any *standard*\r\nfor proving authorization, scope, and revocation status. The statutes say \"automated\r\ncontracts *can* bind\"; the framework supplies the evidence for \"*this one did*, on\r\n*these* terms, within *this* authority.\"\r\n\r\n### 2.3 The EDI precedent\r\n\r\nElectronic Data Interchange (EDI) has supported automated purchase orders and\r\nacceptances between companies since the 1980s, made enforceable through **trading\r\npartner agreements** — master contracts in which the humans agree, in advance, that\r\nspecified machine messages will bind them. The A2A framework generalizes this pattern\r\nto an *open network*: instead of a bilateral master agreement negotiated in advance\r\nbetween two known companies, the SoA token and Delegation Credential are **unilateral,\r\nportable, verifiable declarations** that any counterparty on the network can check.\r\nWhen someone objects that \"machines can't form contracts,\" EDI is the forty-year-old\r\ncounterexample; the novel part here is only openness and portability of the\r\nauthorization proof.\r\n\r\n### 2.4 What remains legally unsettled (be honest about this)\r\n\r\n- **Apparent authority and estoppel edge cases** — if a principal's revocation hasn't\r\n  propagated and a counterparty reasonably relied, doctrine could go either way; this is\r\n  exactly why revocation timing is Open Question 1 (§19.1).\r\n- **Choice of law and forum** — deliberately out of scope (§18); a court still has to\r\n  decide *whose* contract law applies before applying it.\r\n- **Consumer-protection overlays** — mandatory rules (cooling-off periods, unfair-terms\r\n  regimes) apply regardless of how clean the formation evidence is.\r\n- **Agent \"personhood\" debates** — the framework deliberately sidesteps them by always\r\n  resolving to a human or legal entity; no position is taken on whether agents should\r\n  ever have independent legal status.\r\n\r\n## 3. Problem Statement\r\n\r\nThree gaps follow directly from autonomous agent transacting. Any design, review, or\r\nimplementation work you do with this skill should trace back to closing one of these.\r\n\r\n### G1 — No standard for valid \"consent\"\r\n\r\nThere is no agreed way to establish what counts as an agent's valid consent to a\r\ntransaction. *Failure scenario:* a seller agent emits something a buyer agent treats as\r\nan offer; the buyer \"accepts\"; the seller's operator later claims the message was a\r\nprice quote, not an offer, and that nothing the agent emits constitutes assent anyway.\r\nWith no standard for what a valid agent-consent artifact looks like, a court has\r\nnothing to hold onto. → Closed by the **signed offer/accept message pair within\r\ndeclared scope** (§5 Consent row, §8).\r\n\r\n### G2 — No standard for verifying authorization\r\n\r\nThere is no standard for verifying that an agent was actually authorized by its\r\nprincipal to make a *given* commitment, as opposed to acting outside its intended\r\nscope. *Failure scenario:* a company's research agent, configured only to gather\r\nquotes, \"agrees\" to a $40,000 purchase. The company disavows it. The counterparty had\r\nno way to know the agent's actual mandate — and the company had no way to prove the\r\nmandate's limits either. Both sides lose. → Closed by the **SoA token** (§6).\r\n\r\n### G3 — No mechanism for real-time authority checks\r\n\r\nThere is no mechanism for a counterparty to confirm, *before* transacting, that an\r\nagent's authority is current and has not been revoked. *Failure scenario:* an agent's\r\ndeployment was compromised on Monday; its principal cut it off internally on Tuesday;\r\non Wednesday it is still out on the network making commitments with what looks like a\r\nperfectly valid credential. → Closed by **real-time revocation checks against the\r\nNANDA Index** (§5 Revocation row, §14).\r\n\r\n### Consequence of leaving the gaps open\r\n\r\nWithout addressing these, **any commercial activity on the NANDA network carries open\r\nenforceability risk** — a counterparty (human or agent) may later argue that no valid\r\nagreement existed at all. Note the direction of the risk: it is not only \"principals\r\nget stuck with rogue-agent deals\"; it is equally \"honest counterparties can't rely on\r\nany deal an agent makes.\" Enforceability uncertainty taxes every transaction on the\r\nnetwork, honest or not.\r\n\r\n## 4. Framework Overview\r\n\r\nThe framework introduces **two new credential artifacts** that plug into NANDA's\r\nexisting identity layer, plus **one logging requirement** at the interoperability layer:\r\n\r\n| Artifact | Question it answers | Gap it closes | Layer |\r\n|---|---|---|---|\r\n| **Scope-of-Authority (SoA) Token** (§6) | *What* may this agent commit to? | G2 | Identity layer (anchored to Index) |\r\n| **Delegation Credential** (§7) | *Who* is ultimately accountable? | G2 (capacity half) | Identity layer (anchored to Index) |\r\n| **Transaction Log** (§8) | *What was actually agreed, and was authority current?* | G1, G3 | Interoperability layer |\r\n\r\n### Design principles\r\n\r\nPreserve these in any extension, implementation, or spec draft; they are what keeps the\r\nframework adoptable:\r\n\r\n1. **Piggyback on the Index.** Both credentials anchor to the agent's existing identity\r\n   record in the NANDA Index. Do not invent a parallel identity system; parallel roots\r\n   of trust are how ecosystems fragment.\r\n2. **Pilotable today.** Nothing requires new legislation (§2) or new cryptography (§9 —\r\n   plain signatures and hashes suffice). A testnet pilot can run this quarter.\r\n3. **Narrow by design.** It is an evidentiary layer, not a governing-law regime and not\r\n   a dispute resolver (§18). Over-claiming is the fastest way to lose both lawyers and\r\n   engineers.\r\n4. **Check before you transact — twice.** Verification runs at negotiation start and\r\n   again immediately before acceptance. Authority is only ever as fresh as the last\r\n   check.\r\n5. **Both sides carry credentials.** Buyer and seller agents each present an SoA token\r\n   and Delegation Credential; verification is mutual, not one-directional.\r\n6. **Evidence over enforcement.** The framework never blocks anything at the network\r\n   level; it makes the consequences of skipping checks *provable*. Rational actors then\r\n   check.\r\n\r\n## 5. Legal Mapping\r\n\r\nThis table is the heart of the framework — it appears verbatim in the submission.\r\nReproduce it whenever explaining how A2A contracts achieve enforceability. Each\r\ntraditional element of a valid contract gets a machine-verifiable equivalent:\r\n\r\n| Element | Human Contract Analog | Agent-to-Agent Equivalent (Proposed) |\r\n|---|---|---|\r\n| **Capacity** | Party must be a legal adult of sound mind | Agent must hold a valid, unrevoked **Delegation Credential** from an accountable principal |\r\n| **Consent** | Signature, click-through, or verbal agreement | Cryptographically **signed transaction within the agent's declared Scope-of-Authority** |\r\n| **Authority** | Power of attorney, corporate signing authority | Machine-readable **Scope-of-Authority (SoA) token** issued by the principal |\r\n| **Mutual assent** | Offer and acceptance | **Matched, signed offer/accept messages** logged to the NANDA Index |\r\n| **Revocation / limits** | Contract terms, statute of limitations | **Transaction ceilings, expiry timestamps, and real-time revocation checks** against the Index |\r\n\r\n### Doctrinal commentary, row by row\r\n\r\n- **Capacity** is binary and identity-level. No valid Delegation Credential → the agent\r\n  has no capacity to contract *at all* under this framework, regardless of what any SoA\r\n  token says. The analogy is exact: a contract with a party lacking capacity is void or\r\n  voidable no matter how carefully it was signed. Capacity is about *who stands behind\r\n  the agent*, so it lives in the credential that names the accountable party.\r\n- **Authority** is granular and transaction-level. A valid SoA token may still not\r\n  cover a *particular* deal — wrong category, over ceiling, disallowed counterparty,\r\n  expired. The power-of-attorney analogy holds: a POA for real-estate transactions\r\n  doesn't authorize selling the car. Authority questions are always asked against the\r\n  *specific terms on the table*.\r\n- **Consent** requires the conjunction of two facts: a signature from the agent's key\r\n  **and** the transaction falling inside the SoA scope. Either alone is insufficient. A\r\n  signed transaction outside scope is evidence of an *unauthorized act*, not consent by\r\n  the principal (§2.1). An in-scope transaction without a valid signature is nothing at\r\n  all.\r\n- **Mutual assent** is only established by the **matched pair** — an acceptance whose\r\n  hash commitment matches the canonicalized offer (§8.3). An offer alone binds nobody;\r\n  an acceptance that doesn't hash-match the offer it claims to accept forms nothing\r\n  (that's a counteroffer at best, a bug at worst). This mirrors the mirror-image rule:\r\n  acceptance must be of *the offer made*, not of some variant.\r\n- **Revocation / limits** replaces open-ended human judgment (\"has this authority been\r\n  withdrawn?\") with checkable state: expiry timestamps that need no action to take\r\n  effect, ceilings that bound worst-case exposure, and a revocation status that any\r\n  counterparty can query in real time.\r\n\r\n## 6. Scope-of-Authority Token\r\n\r\n### 6.1 Definition (from the submission)\r\n\r\nA **signed, machine-readable credential issued by an agent's principal** — the human,\r\ncompany, or upstream agent responsible for it — that defines what the agent may commit\r\nto on the principal's behalf: for example, transaction categories, monetary ceilings,\r\ncounterparties it may deal with, and an expiry date. The SoA token is **presented at\r\nthe start of any negotiation** and can be **checked against the NANDA Index in real\r\ntime**.\r\n\r\n### 6.2 Reference schema *(proposed draft)*\r\n\r\n```json\r\n{\r\n  \"type\": \"SoAToken\",\r\n  \"version\": \"0.1\",\r\n  \"token_id\": \"soa:9f2c7e1a-4d0b-4b8e-a1c3-2f6d8e9a0b1c\",\r\n  \"agent_id\": \"nanda:agent:acme-buyer-01\",\r\n  \"principal_id\": \"nanda:principal:acme-corp\",\r\n  \"delegation_credential_ref\": \"dc:4b8a2e6f-1a9c-4c3d-b7e0-5f2a8c9d1e3b\",\r\n  \"scope\": {\r\n    \"transaction_categories\": [\r\n      \"procurement.office-supplies\",\r\n      \"procurement.cloud-services\"\r\n    ],\r\n    \"monetary_ceiling\": {\r\n      \"amount\": 5000,\r\n      \"currency\": \"USD\",\r\n      \"period_cap\": { \"amount\": 20000, \"currency\": \"USD\", \"period\": \"P30D\" }\r\n    },\r\n    \"allowed_counterparties\": {\r\n      \"mode\": \"allowlist\",\r\n      \"ids\": [\"nanda:agent:supplierx-seller-*\"]\r\n    },\r\n    \"human_in_loop_threshold\": { \"amount\": 2500, \"currency\": \"USD\" }\r\n  },\r\n  \"issued_at\": \"2026-07-10T00:00:00Z\",\r\n  \"expires_at\": \"2026-10-10T00:00:00Z\",\r\n  \"revocation_check_endpoint\": \"https://index.nanda.example/revocations\",\r\n  \"signature\": {\r\n    \"alg\": \"Ed25519\",\r\n    \"key_ref\": \"nanda:principal:acme-corp#key-1\",\r\n    \"value\": \"base64...\"\r\n  }\r\n}\r\n```\r\n\r\n### 6.3 Field-by-field reference *(proposed draft)*\r\n\r\n| Field | Type | Required | Rules and rationale |\r\n|---|---|---|---|\r\n| `type` | string | yes | Fixed `\"SoAToken\"`. Lets verifiers reject mislabeled artifacts before parsing further. |\r\n| `version` | string | yes | Schema version. Verifiers reject versions they don't implement rather than guessing (fail closed). |\r\n| `token_id` | string | yes | Globally unique, `soa:` + UUID. Referenced by transaction records (§8) and revocation entries (§14); must never be reused, even after expiry. |\r\n| `agent_id` | string | yes | The one agent this token empowers — its NANDA Index identifier. **No bearer tokens**: possession must never equal authority, or theft of a token file becomes theft of signing power. |\r\n| `principal_id` | string | yes | The issuing principal. Must match the signer of `signature` and must be a party appearing in the referenced Delegation Credential's chain. |\r\n| `delegation_credential_ref` | string | yes | The Delegation Credential this scope hangs off. Load-bearing: if that credential is missing/expired/revoked, this token confers nothing — capacity precedes authority (§5). |\r\n| `scope.transaction_categories` | string[] | yes | Dotted-namespace taxonomy (e.g., `procurement.office-supplies`). Matching is exact-segment prefix: a token holding `procurement` covers `procurement.cloud-services`, but `proc` covers nothing. Categories must come from a shared taxonomy so counterparties evaluate them mechanically; pilots can start with a flat agreed list. |\r\n| `scope.monetary_ceiling.amount`/`currency` | number, string | yes | Hard cap per transaction, in a named currency (ISO 4217 or a network-recognized token symbol). Cross-currency deals must be evaluated at a declared rate source or refused — never silently converted. |\r\n| `scope.monetary_ceiling.period_cap` | object | no | Rolling aggregate cap (`period` in ISO-8601 duration). Bounds total exposure from many small transactions. Checked at acceptance time against the agent's logged transaction history for the window. |\r\n| `scope.allowed_counterparties.mode` | enum | no | `allowlist` (only listed IDs), `denylist` (all except listed), or `any-verified` (any agent that itself passes Workflow B). Default if absent: `any-verified`. Glob suffix `*` permitted on ID patterns. |\r\n| `scope.human_in_loop_threshold` | object | no | Above this amount, a human confirmation artifact (§12 step 5a) is required before the agent's acceptance is valid. This is per-token; whether the *network* should impose a default is Open Question 4 (§19.4). |\r\n| `issued_at` | timestamp | yes | RFC 3339 UTC. Must be ≤ now at verification (clock-skew tolerance ±120 s, §9.4). |\r\n| `expires_at` | timestamp | yes | **Expiry is mandatory** — a token without it is invalid by construction. Expiry needs no revocation infrastructure to take effect, so short expiry + reissuance is the cheapest risk control available. Recommended pilot default: ≤ 90 days. |\r\n| `revocation_check_endpoint` | URI | yes | Where verifiers check current status. Should resolve via the NANDA Index. If unreachable, verifiers treat status as *unknown*, not *valid* (`E-REV-01`, §16). |\r\n| `signature` | object | yes | Principal's detached signature over the canonicalized token (§9). `key_ref` must resolve, via the Index, to a key controlled by `principal_id`. |\r\n\r\n### 6.4 Lifecycle *(proposed draft)*\r\n\r\n```\r\n draft ──issue+sign──▶ ACTIVE ──expires_at passes──▶ EXPIRED   (terminal)\r\n                         │\r\n                         └──principal revokes──▶ REVOKED       (terminal)\r\n```\r\n\r\n- Only **ACTIVE** tokens confer authority. There is no \"suspended/resume\" state in the\r\n  draft — reissue instead; resumable suspension complicates caching and disputes for\r\n  little benefit.\r\n- **Renewal is reissuance** with a new `token_id`. In-flight negotiations should be\r\n  handed the successor token and re-verified; nothing \"carries over\" implicitly.\r\n- Terminal states are permanent: a revoked token stays revoked even past its expiry\r\n  (the revocation record remains queryable for dispute purposes).\r\n\r\n### 6.5 Anti-patterns to flag in review\r\n\r\n- **No expiry / multi-year expiry** — defeats the cheapest control in the system.\r\n- **Bearer semantics** — any design where presenting the token file suffices without a\r\n  key-possession proof from `agent_id`.\r\n- **Scope defined by prose** (\"may buy reasonable office supplies\") — not mechanically\r\n  evaluable; that's a policy document, not an SoA token.\r\n- **Self-issuance** — `principal_id` resolving to the agent itself, or the agent\r\n  holding the principal's signing key (§10 checklist).\r\n- **One giant token** for an agent doing many jobs — prefer several narrow tokens;\r\n  revocation then has surgical granularity.\r\n\r\n## 7. Delegation Credential\r\n\r\n### 7.1 Definition (from the submission)\r\n\r\nA **verifiable claim, anchored to the agent's identity record in the NANDA Index**,\r\nconfirming the **chain of delegation back to an accountable human or legal entity**.\r\nIt answers: *\"Who is ultimately responsible if this agent's commitment is disputed?\"*\r\n\r\n### 7.2 Reference schema *(proposed draft)*\r\n\r\n```json\r\n{\r\n  \"type\": \"DelegationCredential\",\r\n  \"version\": \"0.1\",\r\n  \"credential_id\": \"dc:4b8a2e6f-1a9c-4c3d-b7e0-5f2a8c9d1e3b\",\r\n  \"subject_agent_id\": \"nanda:agent:acme-buyer-01\",\r\n  \"accountable_party\": {\r\n    \"kind\": \"legal-entity\",\r\n    \"id\": \"nanda:principal:acme-corp\",\r\n    \"legal_name\": \"Acme Corporation\",\r\n    \"jurisdiction_of_formation\": \"US-DE\"\r\n  },\r\n  \"delegation_chain\": [\r\n    {\r\n      \"delegator\": \"nanda:principal:acme-corp\",\r\n      \"delegate\": \"nanda:agent:acme-orchestrator\",\r\n      \"granted_at\": \"2026-05-01T00:00:00Z\",\r\n      \"link_signature\": {\r\n        \"alg\": \"Ed25519\",\r\n        \"key_ref\": \"nanda:principal:acme-corp#key-1\",\r\n        \"value\": \"base64...\"\r\n      }\r\n    },\r\n    {\r\n      \"delegator\": \"nanda:agent:acme-orchestrator\",\r\n      \"delegate\": \"nanda:agent:acme-buyer-01\",\r\n      \"granted_at\": \"2026-06-15T00:00:00Z\",\r\n      \"link_signature\": {\r\n        \"alg\": \"Ed25519\",\r\n        \"key_ref\": \"nanda:agent:acme-orchestrator#key-1\",\r\n        \"value\": \"base64...\"\r\n      }\r\n    }\r\n  ],\r\n  \"index_anchor\": \"nanda:index:record:acme-buyer-01\",\r\n  \"issued_at\": \"2026-06-15T00:00:00Z\",\r\n  \"expires_at\": \"2027-06-15T00:00:00Z\",\r\n  \"status_endpoint\": \"https://index.nanda.example/credentials/dc:4b8a2e6f/status\",\r\n  \"signature\": {\r\n    \"alg\": \"Ed25519\",\r\n    \"key_ref\": \"nanda:principal:acme-corp#key-1\",\r\n    \"value\": \"base64...\"\r\n  }\r\n}\r\n```\r\n\r\n### 7.3 Field-by-field reference *(proposed draft)*\r\n\r\n| Field | Type | Required | Rules and rationale |\r\n|---|---|---|---|\r\n| `credential_id` | string | yes | Globally unique, `dc:` + UUID. Referenced by SoA tokens and dispute bundles. |\r\n| `subject_agent_id` | string | yes | The agent this credential vouches for; must equal the `delegate` of the **last** chain link and match the Index record in `index_anchor`. |\r\n| `accountable_party.kind` | enum | yes | `human` or `legal-entity` — the only two values, by design. The chain must bottom out in legal personhood (§7.4). |\r\n| `accountable_party.id` | string | yes | NANDA identifier of the accountable party; must equal the `delegator` of the **first** chain link. |\r\n| `accountable_party.legal_name` | string | yes | Human-readable legal name — what a dispute filing would actually name. |\r\n| `accountable_party.jurisdiction_of_formation` | string | no | Informational only (ISO 3166-2 style). **Not** a choice-of-law clause — see §18; it tells a disputant where the entity lives, nothing more. |\r\n| `delegation_chain` | array | yes | Ordered **root → leaf**. Each link: `delegator`, `delegate`, `granted_at`, `link_signature`. Verified per §7.4. |\r\n| `delegation_chain[].link_signature` | object | yes | Signed by *that link's delegator* over the canonicalized link. Per-link signatures mean a forged middle link is detectable even if the outer envelope signature is valid. |\r\n| `index_anchor` | string | yes | Binding into the agent's NANDA Index identity record. Anchoring means a counterparty resolving the agent in the Index *finds this credential (or its absence) without side channels* — discoverability is the point. |\r\n| `issued_at` / `expires_at` | timestamp | yes | Same clock rules as SoA tokens. Credentials may reasonably live longer than SoA tokens (identity churns slower than mandates) but must still expire. |\r\n| `status_endpoint` | URI | yes | Real-time revocation/status checks; same unknown-≠-valid rule as tokens. |\r\n| `signature` | object | yes | Envelope signature by the accountable party over the whole canonicalized credential. |\r\n\r\n### 7.4 Chain validation algorithm *(proposed draft)*\r\n\r\n```\r\nvalidate_chain(credential):\r\n  chain = credential.delegation_chain\r\n  assert len(chain) >= 1                                      # E-CAP-05 if empty\r\n  assert credential.accountable_party.kind in {human, legal-entity}   # E-CAP-03\r\n  assert chain[0].delegator == credential.accountable_party.id        # E-CAP-06\r\n  for i, link in enumerate(chain):\r\n      assert link.delegator != link.delegate                  # E-CAP-07 (self-delegation)\r\n      assert verify_sig(link.link_signature, canonical(link),\r\n                        resolve_key(link.delegator))          # E-CAP-04\r\n      if i > 0:\r\n          assert link.delegator == chain[i-1].delegate        # E-CAP-06 (broken chain)\r\n          assert link.granted_at >= chain[i-1].granted_at     # E-TIME-01 (grant precedes grant)\r\n  assert chain[-1].delegate == credential.subject_agent_id    # E-CAP-06\r\n  assert no identifier appears twice as a delegate            # E-CAP-07 (loop)\r\n  assert credential.index_anchor resolves to subject agent's\r\n         Index record and that record references this credential      # E-CAP-08\r\n  assert now() within [issued_at, expires_at] ± skew (§9.4)   # E-CAP-02\r\n  assert status_endpoint reports not-revoked                  # E-CAP-02 / E-REV-*\r\n```\r\n\r\n### 7.5 Semantics and rules\r\n\r\n- **The chain must terminate at a human or legal entity.** Agent-to-agent delegation is\r\n  allowed — upstream agents may spawn or configure downstream agents, and NANDA's\r\n  architecture expects that — but every chain must resolve, in finite verifiable steps,\r\n  to an accountable party with legal personhood. A chain that bottoms out at another\r\n  agent is invalid: it would mean \"no one is responsible,\" which is the exact outcome\r\n  the credential exists to prevent.\r\n- **Chain depth**: no hard limit in the draft, but each hop is a verification cost and\r\n  a potential dispute over intermediate authority. Pilots should warn above depth 4.\r\n- **Revocation cascades down the chain.** Revoking any link invalidates every\r\n  credential and SoA token downstream of it (§14). The Index should surface cascaded\r\n  status transitively so counterparties don't have to walk chains themselves.\r\n- **Delegation narrows; it never widens.** An intermediate agent cannot delegate more\r\n  than it received. The credential proves the *accountability* chain; the *authority*\r\n  bounds at each hop live in the SoA tokens along it. Implementations should check\r\n  that a downstream agent's SoA scope ⊆ its delegator's SoA scope when the delegator\r\n  is itself an agent.\r\n- **Joint accountability** (developer *and* deploying company) is Open Question 2\r\n  (§19.2). The draft schema is single-party; when drafting spec text, note the\r\n  alternative explicitly rather than silently picking one.\r\n\r\n## 8. Transaction Log\r\n\r\n### 8.1 Definition (from the submission)\r\n\r\nEvery completed agreement between agents is logged as a **matched offer/accept pair,\r\nsigned by both parties' keys, with a timestamp and a reference to the SoA token in\r\nforce at that moment**. This log is the **evidentiary record used in any later\r\ndispute**.\r\n\r\n### 8.2 Reference schema *(proposed draft)*\r\n\r\n```json\r\n{\r\n  \"type\": \"A2ATransactionRecord\",\r\n  \"version\": \"0.1\",\r\n  \"record_id\": \"txn:7d3e5f2a-8b1c-4e9d-a0f3-6c2b7d8e9f0a\",\r\n  \"offer\": {\r\n    \"offer_id\": \"off:aa10c4d2-...\",\r\n    \"from_agent\": \"nanda:agent:supplierx-seller-03\",\r\n    \"to_agent\": \"nanda:agent:acme-buyer-01\",\r\n    \"terms\": {\r\n      \"category\": \"procurement.office-supplies\",\r\n      \"description\": \"500 reams A4 paper, delivery by 2026-07-20\",\r\n      \"price\": { \"amount\": 1800, \"currency\": \"USD\" },\r\n      \"conditions\": [\"delivery-on-or-before:2026-07-20\"]\r\n    },\r\n    \"offeror_soa_ref\": \"soa:1c9d3b7e-...\",\r\n    \"offer_expires_at\": \"2026-07-10T14:33:22Z\",\r\n    \"timestamp\": \"2026-07-10T14:03:22Z\",\r\n    \"signature\": { \"alg\": \"Ed25519\", \"key_ref\": \"nanda:agent:supplierx-seller-03#key-1\", \"value\": \"base64...\" }\r\n  },\r\n  \"accept\": {\r\n    \"accept_id\": \"acc:bb27e9f1-...\",\r\n    \"offer_hash\": \"sha256:7f8e2a91c4b3d6f0a5e8c1b7d2f9a4e6c3b8d5f1a7e2c9b4d6f3a8e5c2b9d7f4\",\r\n    \"from_agent\": \"nanda:agent:acme-buyer-01\",\r\n    \"acceptor_soa_ref\": \"soa:9f2c7e1a-...\",\r\n    \"human_confirmation_ref\": null,\r\n    \"timestamp\": \"2026-07-10T14:03:29Z\",\r\n    \"signature\": { \"alg\": \"Ed25519\", \"key_ref\": \"nanda:agent:acme-buyer-01#key-1\", \"value\": \"base64...\" }\r\n  },\r\n  \"verification_snapshot\": {\r\n    \"offeror_soa_valid_at_accept\": true,\r\n    \"acceptor_soa_valid_at_accept\": true,\r\n    \"delegation_credentials_valid\": true,\r\n    \"revocation_checked_at\": \"2026-07-10T14:03:28Z\",\r\n    \"revocation_source\": \"https://index.nanda.example/revocations\",\r\n    \"period_cap_usage_after\": { \"amount\": 1800, \"currency\": \"USD\", \"period\": \"P30D\" }\r\n  },\r\n  \"supersedes\": null,\r\n  \"logged_at\": \"2026-07-10T14:03:30Z\",\r\n  \"log_location\": \"nanda:index\"\r\n}\r\n```\r\n\r\n### 8.3 Canonicalization and matching *(proposed draft)*\r\n\r\nThe formation rule turns on `accept.offer_hash` equaling the hash of the *canonicalized*\r\noffer, so canonicalization must be exact and mandatory:\r\n\r\n- **Scheme:** JSON Canonicalization Scheme (JCS, RFC 8785) — deterministic key\r\n  ordering, UTF-8, no insignificant whitespace, canonical number formatting. Any\r\n  formal spec must name its scheme; two \"equivalent\" JSON serializations that hash\r\n  differently would let a party deny a match on a technicality.\r\n- **What is hashed:** the complete offer object *minus* its own `signature` field\r\n  (sign-then-hash ambiguity is avoided by always hashing the unsigned canonical form\r\n  and signing that same form).\r\n- **Hash algorithm:** SHA-256, prefixed (`sha256:`) so the algorithm is explicit and\r\n  upgradeable.\r\n- **Matching rule:** byte-equality of the digest. Not \"semantically the same terms\" —\r\n  *the same bytes*. A changed comma placement after canonicalization means a changed\r\n  contract; that strictness is a feature (it is the mirror-image rule, mechanized).\r\n\r\n### 8.4 Semantics and rules\r\n\r\n- **A contract exists only when the pair matches.** One-sided records prove an offer\r\n  was made or an acceptance attempted — useful evidence, but not mutual assent.\r\n- **Both signatures required**, each from a key resolving via the Index to the named\r\n  agent.\r\n- **The SoA reference captures authority *at that moment*.** Later revocation does not\r\n  retroactively unwind agreements formed while the token was valid — that is precisely\r\n  why the timestamp and the revocation-check snapshot matter. The snapshot converts\r\n  \"trust me, I checked\" into recorded, contemporaneous fact.\r\n- **`human_confirmation_ref`**: required (non-null, resolving to a signed confirmation\r\n  artifact) whenever the terms exceed the acceptor's `human_in_loop_threshold`.\r\n- **Append-only.** Records are never edited. Corrections, rescissions, or mutually\r\n  agreed amendments are *new* records whose `supersedes` field references the old one —\r\n  the history of a deal is itself evidence.\r\n- **Both agents retain local copies** in addition to the network log; divergence\r\n  between a party's copy and the network log is itself a dispute-relevant fact.\r\n- **Where the log lives is Open Question 3** (§19.3): the NANDA Index itself, or a\r\n  separate append-only ledger referenced by the Index. Do not present either as\r\n  decided.\r\n- **Privacy note for spec drafts:** matched pairs contain commercial terms. Options to\r\n  raise: log full records access-controlled with public existence proofs (hash +\r\n  timestamp public, payload gated), or full public logging for maximum auditability.\r\n  Flag, don't decide.\r\n\r\n## 9. Cryptographic Profile *(proposed draft)*\r\n\r\nDeliberately boring: the framework should need **no novel cryptography**. Everything\r\nbelow is off-the-shelf; anything stronger (ZK selective disclosure, threshold signing)\r\nis a v2 discussion.\r\n\r\n### 9.1 Signatures\r\n\r\n- **Default algorithm:** Ed25519. Small keys, fast verification, ubiquitous library\r\n  support, no parameter-choice footguns. `alg` field allows future additions;\r\n  verifiers reject algorithms they don't implement (fail closed).\r\n- **Envelope:** detached signature over the JCS-canonicalized artifact minus its\r\n  `signature` field (§8.3).\r\n- **`key_ref` resolution:** every `key_ref` must resolve *through the NANDA Index* to a\r\n  key bound to the named identity. A signature that verifies against a key the Index\r\n  doesn't bind to that identity is worthless — the Index binding *is* the identity\r\n  claim.\r\n\r\n### 9.2 Keys and rotation\r\n\r\n- **One identity, possibly many keys**, distinguished by fragment (`#key-1`). Index\r\n  records list active keys with validity windows.\r\n- **Rotation:** add new key, re-sign artifacts at natural reissue, retire old key with\r\n  an end-of-validity timestamp. Signatures made while a key was valid remain\r\n  verifiable afterward — validity windows, not deletion, preserve old evidence.\r\n- **Separation of duties (critical):** the agent's transaction-signing key, the\r\n  principal's credential-issuing key, and any revocation-authority key should be\r\n  distinct. An agent must never hold the key that could mint or widen its own\r\n  authority (§6.5, §10).\r\n- **Compromise:** key compromise is handled by revocation (§14) — revoke credentials/\r\n  tokens tied to the key, rotate, reissue. The transaction log's timestamps then\r\n  cleanly partition \"signed before compromise window\" from after.\r\n\r\n### 9.3 Hashing\r\n\r\nSHA-256 everywhere a digest appears, always algorithm-prefixed (`sha256:...`).\r\n\r\n### 9.4 Time\r\n\r\n- All timestamps RFC 3339 UTC.\r\n- **Clock-skew tolerance:** ±120 seconds on `issued_at`/expiry boundary checks.\r\n- Verifiers should record *their own* check time in verification snapshots\r\n  (`revocation_checked_at`), not trust counterparty-supplied times.\r\n- Pilots may optionally countersign log entries with an RFC 3161-style timestamp\r\n  authority for third-party time attestation; not required for v0.1.\r\n\r\n## 10. Workflow A — Issuing Authority (principal side)\r\n\r\nUse this when helping a principal (human, company, or upstream agent) authorize an\r\nagent.\r\n\r\n```\r\nPrincipal                       NANDA Index                     Agent\r\n    │  1. create/verify identity record  │                        │\r\n    │───────────────────────────────────▶│                        │\r\n    │  2. issue + sign Delegation Cred.  │                        │\r\n    │───────────────anchor──────────────▶│                        │\r\n    │  3. issue + sign SoA token         │                        │\r\n    │───────────────register────────────▶│                        │\r\n    │  4. provision agent (creds + its own key)                   │\r\n    │─────────────────────────────────────────────────────────────▶\r\n    │  5. test revocation path           │                        │\r\n    │───────────────────────────────────▶│                        │\r\n```\r\n\r\n1. **Establish or verify the agent's identity record** in the NANDA Index, including\r\n   the agent's own signing key (generated by/for the agent — *not* the principal's\r\n   key).\r\n2. **Issue the Delegation Credential** (§7): identify the accountable party, construct\r\n   the chain (each link signed by its delegator), sign the envelope, anchor to the\r\n   Index record, publish the status endpoint.\r\n3. **Issue the SoA token** (§6): choose categories from the shared taxonomy; set the\r\n   per-transaction ceiling and any rolling period cap; decide the counterparty policy;\r\n   set (or explicitly decline) a human-in-loop threshold; set expiry (≤ 90 days\r\n   recommended); sign; register with the Index so revocation checks resolve.\r\n4. **Provision the agent** with both artifacts and its private key.\r\n5. **Test the revocation path before you need it**: issue a throwaway token, revoke\r\n   it, confirm the status endpoint reflects the revocation within the expected\r\n   propagation time. A revocation path that has never been exercised should be assumed\r\n   broken.\r\n\r\n**Scoping guidance for principals** (the questions to walk a principal through):\r\n\r\n- What is the *worst single transaction* this agent could make that you'd still stand\r\n  behind? → that's the ceiling.\r\n- What is the worst *month*? → that's the period cap.\r\n- Which deals would you want to eyeball before they bind? → that's the human-in-loop\r\n  threshold.\r\n- Whom should this agent never deal with? → counterparty policy.\r\n- If this agent went rogue *right now*, how fast could you cut it off, and who is\r\n  on-call to do it? → revocation ownership.\r\n\r\n**Review checklist:**\r\n\r\n- [ ] Delegation chain terminates at a human or legal entity (`kind` is `human` or `legal-entity`)\r\n- [ ] Every chain link individually signed by its delegator\r\n- [ ] `subject_agent_id` = last link's delegate = Index anchor record\r\n- [ ] SoA token has an expiry date (and it's ≤ 90 days for pilots)\r\n- [ ] Ceilings match the principal's actual risk tolerance (not a placeholder)\r\n- [ ] Human-in-loop threshold considered explicitly, even if declined\r\n- [ ] Counterparty policy considered explicitly, even if `any-verified`\r\n- [ ] Revocation endpoint live and *exercised at least once*\r\n- [ ] Agent key ≠ principal key ≠ revocation key (separation of duties, §9.2)\r\n- [ ] If the delegator is itself an agent: child scope ⊆ parent scope (§7.5)\r\n\r\n## 11. Workflow B — Pre-Transaction Verification (counterparty side)\r\n\r\nRun this **before any substantive negotiation**, and re-run the freshness checks\r\n(steps 4–6) **immediately before acceptance**. This workflow is the operational answer\r\nto gaps G2 and G3, and it is mutual — both agents run it on each other.\r\n\r\n1. **Resolve the counterpart agent in the NANDA Index.** Confirm the identity record\r\n   exists and the key used in its messages matches a currently valid key in the record\r\n   (§9.2). *Establishes: you are talking to who you think.*\r\n2. **Fetch and verify the Delegation Credential** (§7.4 algorithm): envelope signature\r\n   valid; unexpired; chain root = accountable party; every link signed and connected;\r\n   terminates at this agent; anchored to the same Index record; status endpoint says\r\n   not revoked. → **Capacity.**\r\n3. **Verify the SoA token**: signature valid against a principal key the Index binds to\r\n   `principal_id`; unexpired; `agent_id` is this agent; `delegation_credential_ref`\r\n   points at the credential verified in step 2. → **Authority in the abstract.**\r\n4. **Check the deal on the table against the scope**: category within\r\n   `transaction_categories` (prefix rule, §6.3); amount ≤ per-transaction ceiling;\r\n   amount + logged window usage ≤ period cap; this counterparty permitted by the\r\n   policy. → **Authority for this deal.**\r\n5. **Real-time revocation check** for **both** the SoA token and the Delegation\r\n   Credential against the Index/status endpoints. Record the check time — it goes in\r\n   the verification snapshot. → **Currency (G3).**\r\n6. **Human-in-loop check**: if the terms exceed the *counterpart's* threshold, require\r\n   its `human_confirmation_ref` before treating any acceptance from it as valid; if\r\n   they exceed *your own* threshold, obtain your principal's confirmation before\r\n   accepting.\r\n\r\n**On failure:** do not proceed to formation. Record the failure with its error code\r\n(§16), then either renegotiate to bring the deal within scope (e.g., split quantity to\r\nget under a ceiling — but see §17 on structuring) or abort with an `ABORT` message\r\n(§13). A counterparty that transacts past a failed check is knowingly accepting\r\nenforceability risk, and the log will show exactly that.\r\n\r\n**Caching guidance:** results of steps 1–3 may be cached for the duration of a\r\nnegotiation session; steps 4–6 are per-deal and must be fresh at acceptance\r\n(recommended: revocation check no older than 60 seconds at the moment of signing an\r\nacceptance).\r\n\r\n## 12. Workflow C — Negotiation and Contract Formation\r\n\r\n```\r\n  Seller agent                                Buyer agent\r\n      │        1. HELLO + credentials             │\r\n      │◀────────────────────────────────────────▶│\r\n      │        2. mutual Workflow B               │\r\n      │        3. PROPOSE / COUNTER (×N)          │\r\n      │◀────────────────────────────────────────▶│\r\n      │        4. OFFER (signed, SoA ref)         │\r\n      │─────────────────────────────────────────▶│\r\n      │                             5. re-verify (B4–B6)\r\n      │                             5a. human confirm (if over threshold)\r\n      │        6. ACCEPT (signed, offer hash)     │\r\n      │◀─────────────────────────────────────────│\r\n      │        7. log matched pair + snapshot     │\r\n      │──────────────▶ NANDA Index ◀──────────────│\r\n      │        8. LOG-CONFIRM (both verify)       │\r\n```\r\n\r\n1. **Handshake:** each agent presents its SoA token and Delegation Credential\r\n   reference in its first message; both run Workflow B on each other. Do this *before*\r\n   substantive negotiation — discovering a scope mismatch after ten rounds of haggling\r\n   wastes everyone's tokens.\r\n2. **Negotiate within the intersection of both scopes.** An agent should decline\r\n   out-of-scope terms *early and explicitly* (`REJECT` with reason code): proposing\r\n   terms you cannot accept wastes rounds and creates messy evidence.\r\n3. **Offer:** the offeror emits a signed offer (schema §8.2) referencing its SoA token,\r\n   with an explicit `offer_expires_at` validity window so stale acceptances can't form\r\n   contracts (`E-ASSENT-02`).\r\n4. **Pre-acceptance re-verification:** the acceptor re-runs Workflow B steps 4–6\r\n   against the *final* terms — scope fit, ceilings including period-cap usage,\r\n   revocation freshness.\r\n5. **Human confirmation (conditional):** if the terms exceed the acceptor's\r\n   `human_in_loop_threshold`, obtain the signed human confirmation artifact and\r\n   reference it in the acceptance (`human_confirmation_ref`). The confirmation is a\r\n   small signed statement by the principal (or its designated approver key) naming the\r\n   offer hash — so the human is confirming *this exact deal*, not a paraphrase.\r\n6. **Accept:** the acceptor emits a signed acceptance containing the canonical hash of\r\n   the offer (§8.3) and its own SoA reference.\r\n7. **Log:** the matched pair, both signatures, timestamps, SoA references, and the\r\n   verification snapshot are written to the transaction log. Both agents retain their\r\n   own copies.\r\n8. **Confirm:** each side verifies the logged record matches what it signed\r\n   (`LOG-CONFIRM`, §13); a mismatch at this stage is a critical incident, not a\r\n   formality.\r\n\r\n**Formation rule — state it plainly in any spec or explanation:** *no matched signed\r\npair in the log → no contract under this framework.* (A court might still find a\r\ncontract on other evidence — the framework provides the *clean* path to enforceability,\r\nnot the only conceivable path. But network participants should treat the clean path as\r\nthe only reliable one.)\r\n\r\n### 12.1 Human confirmation artifact *(proposed draft)*\r\n\r\nThe small signed statement referenced by `human_confirmation_ref` (step 5). It exists\r\nso the human is provably confirming *this exact deal*, not a paraphrase — which is why\r\nit names the offer hash rather than restating the terms:\r\n\r\n```json\r\n{\r\n  \"type\": \"HumanConfirmation\",\r\n  \"version\": \"0.1\",\r\n  \"confirmation_id\": \"hc:e19f3c72-...\",\r\n  \"confirms_offer_hash\": \"sha256:2c5a8f1e9b4d7a3f6c0e8b2d5f9a1c4e7b3d6f0a8e5c2b9d4f7a1e6c3b8d5f2a\",\r\n  \"agent_id\": \"nanda:agent:acme-buyer-01\",\r\n  \"approver\": \"nanda:principal:acme-corp#approver-key-1\",\r\n  \"confirmed_at\": \"2026-07-10T15:12:44Z\",\r\n  \"expires_at\": \"2026-07-10T15:42:44Z\",\r\n  \"signature\": { \"alg\": \"Ed25519\", \"key_ref\": \"nanda:principal:acme-corp#approver-key-1\", \"value\": \"base64...\" }\r\n}\r\n```\r\n\r\nRules: the `approver` key must be designated for approvals in the principal's Index\r\nrecord (it may differ from the credential-issuing key, §9.2); `confirms_offer_hash`\r\nmust equal the accepted offer's canonical hash (`E-CON-03` otherwise); confirmations\r\nexpire quickly (minutes) so a stale approval can't be replayed against a re-issued\r\noffer with different terms but coincidental identity.\r\n\r\n## 13. Negotiation Message Protocol *(proposed draft)*\r\n\r\nA minimal message-type vocabulary so pilots interoperate. Every message carries:\r\n`message_id`, `session_id`, `from_agent`, `to_agent`, `timestamp`, `signature`.\r\n\r\n| Type | Direction | Purpose | Binding? |\r\n|---|---|---|---|\r\n| `HELLO` | either → either | Open session; carries SoA token + Delegation Credential reference; states intent category. | No |\r\n| `CREDENTIALS-OK` / `CREDENTIALS-FAIL` | responder | Result of Workflow B on the peer; `FAIL` carries error codes (§16) and ends the session. | No |\r\n| `PROPOSE` | either | Non-binding indication of terms; opens/continues bargaining. | **No** |\r\n| `COUNTER` | either | Non-binding counter-terms; references the `PROPOSE`/`COUNTER` it answers. | **No** |\r\n| `OFFER` | either | **Binding if accepted**: full §8.2 offer object — terms, SoA ref, validity window, signature. | Yes, once matched |\r\n| `ACCEPT` | offeree | Acceptance: offer hash + acceptor SoA ref (+ `human_confirmation_ref` when required), signed. Forms the contract on hash match. | **Yes** |\r\n| `REJECT` | offeree | Declines an `OFFER`; optional reason code; offer is dead (a later `ACCEPT` of it is invalid). | No |\r\n| `ABORT` | either | Ends session (failed verification, timeout, withdrawal). An `ABORT` sent *before* a valid `ACCEPT` prevents formation; sent *after*, it does nothing — rescission needs a new superseding record (§8.4). | No |\r\n| `LOG-CONFIRM` | both | Each party confirms the logged record's hash matches what it signed. | No |\r\n\r\nProtocol rules worth stating in a spec:\r\n\r\n- **`PROPOSE`/`COUNTER` are explicitly non-binding.** The bright line between\r\n  bargaining chatter and binding commitment is the message type — that's the whole\r\n  reason to have distinct `PROPOSE` and `OFFER` types. This kills the G1 failure\r\n  scenario (\"that was a quote, not an offer\") structurally.\r\n- **One live `OFFER` per session per direction.** Issuing a new `OFFER` implicitly\r\n  withdraws your previous unaccepted one (record the withdrawal).\r\n- **Withdrawal race:** an `OFFER` may be withdrawn by `ABORT` any time *before* a valid\r\n  `ACCEPT` is signed; timestamps + the log adjudicate races. Pilots should keep offer\r\n  validity windows short (minutes) to shrink the race surface.\r\n- **Idempotency:** duplicate `ACCEPT` messages for the same offer hash are one\r\n  acceptance, one contract, one log record.\r\n\r\n## 14. Workflow D — Revocation\r\n\r\n1. **Submission:** the principal — or any delegator in the chain, for their own link —\r\n   submits a signed revocation to the Index/status endpoint identifying the artifact\r\n   (`token_id`, `credential_id`, or a chain-link reference) and an effective timestamp.\r\n   Only identities upstream of an artifact can revoke it; an agent cannot revoke its\r\n   own leash, and a stranger cannot revoke anyone's.\r\n2. **Publication:** the Index marks the artifact revoked and serves that status on all\r\n   subsequent checks. Revocation records are permanent and queryable even after the\r\n   artifact's natural expiry (dispute bundles need them).\r\n3. **Cascade:** revoking a delegation link invalidates all downstream credentials and\r\n   SoA tokens. The Index should surface this transitively so a counterparty checking a\r\n   leaf token learns of an upstream revocation without walking the chain itself.\r\n4. **Effect on in-flight work:**\r\n   - Agreements already formed (matched pair logged) while authority was valid\r\n     **remain formed**. Revocation is not retroactive rescission.\r\n   - Negotiations not yet concluded **must fail** their pre-acceptance re-verification\r\n     (Workflow C step 4) with `E-REV-02`.\r\n   - The principal's exposure therefore ends, cleanly, at the revocation timestamp —\r\n     that is the exact protection revocation exists to give.\r\n5. **Timing semantics are Open Question 1** (§19.1): instant revocation vs. a minimum\r\n   notice period. Present the trade-off; do not assert either as decided.\r\n\r\n**Operational advice for principals:** treat revocation as an incident-response\r\nrunbook, not a rare event — know who can trigger it, rehearse it (§10 step 5), and\r\nmonitor the agent's logged transaction stream so anomalies trigger it *fast*. The\r\nperiod cap (§6.3) bounds bleeding between anomaly and revocation.\r\n\r\n### 14.1 Revocation record *(proposed draft)*\r\n\r\n```json\r\n{\r\n  \"type\": \"RevocationRecord\",\r\n  \"version\": \"0.1\",\r\n  \"revocation_id\": \"rev:c83d1a5e-...\",\r\n  \"revokes\": \"soa:9f2c7e1a-...\",\r\n  \"revokes_type\": \"SoAToken\",\r\n  \"revoked_by\": \"nanda:principal:acme-corp\",\r\n  \"effective_at\": \"2026-07-10T15:41:02Z\",\r\n  \"reason_code\": \"misconfiguration\",\r\n  \"cascade\": true,\r\n  \"signature\": { \"alg\": \"Ed25519\", \"key_ref\": \"nanda:principal:acme-corp#key-1\", \"value\": \"base64...\" }\r\n}\r\n```\r\n\r\nRules: `revoked_by` must be the artifact's issuer or an upstream delegator of it —\r\nanything else is rejected with `E-REV-04` (an agent cannot revoke its own leash; a\r\nstranger cannot revoke anyone's). `effective_at` may not predate submission time\r\nbeyond clock skew — backdated revocations would let a principal retroactively escape\r\nformed contracts, which §14.4 exists to prevent. `reason_code` is a small enum\r\n(`compromise`, `misconfiguration`, `policy-change`, `expiry-supersession`, `other`);\r\nit feeds dispute context and network-health metrics without requiring prose. The\r\nrecord is permanent: revocation state must remain queryable after the artifact's\r\nnatural expiry because dispute bundles (§15, item 6) need the full history.\r\n\r\n## 15. Workflow E — Dispute Evidence Bundle\r\n\r\nWhen a commitment is disputed, assemble this package for the court, arbitrator, or\r\nautomated dispute-resolution process:\r\n\r\n| # | Item | Sourced from | Proves |\r\n|---|---|---|---|\r\n| 1 | Transaction record (matched signed pair, timestamps) | Transaction log | What was agreed, by which keys, when |\r\n| 2 | Both SoA tokens as of formation time | Log refs + Index history | Each agent acted within a defined mandate |\r\n| 3 | Both Delegation Credentials with full chains | Index | Who the accountable parties are |\r\n| 4 | Verification snapshot (or reconstructed Index state at `revocation_checked_at`) | Log | Authority was checked and current at acceptance |\r\n| 5 | Key provenance: Index records binding each `key_ref` to its identity, validity windows | Index | The signatures are those agents' signatures |\r\n| 6 | Revocation history for all four artifacts | Index revocation records | Nothing had been revoked pre-formation (or: exactly when something was) |\r\n| 7 | *(optional)* Negotiation transcript (`HELLO`→`ACCEPT` messages) | Both agents' session stores | Context for term meaning; bargaining history |\r\n| 8 | *(conditional)* Human confirmation artifact | Log ref | Human-in-loop requirement satisfied |\r\n\r\nThe bundle answers, in order: **Who are the accountable parties?** (item 3) → **Was\r\neach agent authorized for this deal?** (item 2 vs. the terms in item 1) → **Did both\r\nassent?** (item 1's matched pair) → **Was authority current?** (items 4 and 6). That\r\nfour-question sequence is the entire evidentiary theory of the framework; structure\r\ndispute submissions and explanations around it.\r\n\r\n**Assembly properties to preserve in implementations:** a third party must be able to\r\nbuild this bundle **from the log and the Index alone**, without the cooperation of\r\neither agent (a hostile or defunct party can't block dispute resolution), and every\r\nitem must be independently verifiable (signatures, hashes) rather than attested.\r\n\r\n## 16. Validation Rules and Error Codes *(proposed draft)*\r\n\r\nUse these codes in implementations, test suites, `CREDENTIALS-FAIL`/`REJECT`/`ABORT`\r\nmessages, and reviews so failures are comparable across pilots.\r\n\r\n### Capacity (Delegation Credential)\r\n\r\n| Code | Check failed |\r\n|---|---|\r\n| `E-CAP-01` | No Delegation Credential found for agent |\r\n| `E-CAP-02` | Delegation Credential expired or revoked |\r\n| `E-CAP-03` | Chain does not terminate at a human/legal entity |\r\n| `E-CAP-04` | Chain link signature invalid |\r\n| `E-CAP-05` | Delegation chain empty or malformed |\r\n| `E-CAP-06` | Chain discontinuity (link N delegator ≠ link N−1 delegate, or leaf ≠ subject agent) |\r\n| `E-CAP-07` | Self-delegation or delegation loop detected |\r\n| `E-CAP-08` | Credential not anchored to the agent's Index record |\r\n\r\n### Authority (SoA token)\r\n\r\n| Code | Check failed |\r\n|---|---|\r\n| `E-AUTH-01` | No SoA token presented |\r\n| `E-AUTH-02` | Token signature invalid, or signer not bound to `principal_id` in the Index |\r\n| `E-AUTH-03` | Token expired or revoked |\r\n| `E-AUTH-04` | Transaction category not in scope |\r\n| `E-AUTH-05` | Amount exceeds per-transaction ceiling |\r\n| `E-AUTH-06` | Amount would exceed rolling period cap |\r\n| `E-AUTH-07` | Counterparty not permitted by scope policy |\r\n| `E-AUTH-08` | `delegation_credential_ref` invalid, mismatched, or pointing to a failed credential |\r\n| `E-AUTH-09` | Token bound to a different agent than the presenter |\r\n| `E-AUTH-10` | Child agent scope exceeds delegating agent's scope (§7.5) |\r\n\r\n### Consent\r\n\r\n| Code | Check failed |\r\n|---|---|\r\n| `E-CON-01` | Signature on offer or accept invalid |\r\n| `E-CON-02` | Human-in-loop threshold exceeded without a valid `human_confirmation_ref` |\r\n| `E-CON-03` | Human confirmation doesn't name this offer hash |\r\n\r\n### Mutual assent\r\n\r\n| Code | Check failed |\r\n|---|---|\r\n| `E-ASSENT-01` | `accept.offer_hash` does not match canonicalized offer |\r\n| `E-ASSENT-02` | Acceptance after `offer_expires_at` |\r\n| `E-ASSENT-03` | Acceptance of a rejected or withdrawn offer |\r\n| `E-ASSENT-04` | Duplicate acceptance (idempotency: not an error to retry, but only one record forms) |\r\n\r\n### Revocation / infrastructure\r\n\r\n| Code | Check failed |\r\n|---|---|\r\n| `E-REV-01` | Revocation status could not be determined (endpoint unreachable/timeout) |\r\n| `E-REV-02` | Artifact revoked at check time |\r\n| `E-REV-03` | Upstream chain link revoked (cascade) |\r\n| `E-REV-04` | Revocation submitted by a party not upstream of the artifact (rejected) |\r\n| `E-IDX-01` | Agent identity record not found in Index |\r\n| `E-IDX-02` | Message signing key not currently valid for this identity |\r\n| `E-TIME-01` | Timestamp outside clock-skew tolerance (§9.4) |\r\n\r\n### Handling matrix\r\n\r\n| Situation | Treatment |\r\n|---|---|\r\n| Any `E-CAP-*` | Peer lacks capacity. End session (`CREDENTIALS-FAIL`/`ABORT`). Nothing to renegotiate. |\r\n| `E-AUTH-04/05/06/07` | Deal-specific. Renegotiate within scope (mind §17 on structuring) or abort. |\r\n| Other `E-AUTH-*`, `E-CON-*`, `E-IDX-*` | Configuration or integrity problem. Abort; log; a *pattern* of these from one peer is a fraud signal. |\r\n| `E-ASSENT-*` | No contract formed. Log the attempt; a new `OFFER` restarts cleanly. |\r\n| `E-REV-01` | **Unknown ≠ valid.** Treat as failed for anything above trivial value; say so in the snapshot. Retry with backoff; abort if status stays unknown. |\r\n| `E-REV-02/03` | Authority gone. Abort negotiation; already-formed contracts stand (§14.4). |\r\n\r\n## 17. Threat Model *(proposed draft)*\r\n\r\nWhat an adversary might try, and which mechanism answers it. Use this when reviewing\r\ndesigns or pilot code.\r\n\r\n| # | Threat | Mitigation |\r\n|---|---|---|\r\n| T1 | **Stolen SoA token file** presented by an impostor | Tokens bind to `agent_id`; every message is signed by the agent's key; possession of the token without the key proves nothing (§6.3). |\r\n| T2 | **Agent key compromise** — attacker signs as the agent | Ceilings and period caps bound exposure; revocation cuts off the key (§14); log timestamps partition pre/post-compromise signatures (§9.2). Residual risk between compromise and revocation is exactly the exposure ceilings exist to bound. |\r\n| T3 | **Self-authorization** — agent mints or widens its own authority | Key separation (§9.2); `E-CAP-07` self-delegation check; SoA must be signed by the principal's Index-bound key, which the agent must never hold. |\r\n| T4 | **Forged middle link** in a delegation chain | Per-link signatures + continuity checks (§7.4): every link verifiable against its delegator's Index-bound key. |\r\n| T5 | **Replay** — re-presenting an old valid `ACCEPT` or reusing an offer | Offer validity windows, session IDs, unique offer/accept IDs, idempotent logging (`E-ASSENT-02/-04`). |\r\n| T6 | **Terms swap** — altering terms between negotiation and logging | Canonical hash matching (§8.3): the acceptance commits to exact bytes; `LOG-CONFIRM` catches log-stage tampering. |\r\n| T7 | **Revocation-lag exploitation** — racing to form deals in the propagation window | Fresh-check requirement (≤60 s at acceptance, §11); short offer windows; Open Question 1 governs the policy boundary (§19.1). |\r\n| T8 | **Structuring** — splitting one big deal into many sub-ceiling deals | Period caps (§6.3) bound the aggregate; the log makes split patterns *visible and provable*; a network-default ceiling (Open Question 4) would tighten this further. |\r\n| T9 | **Availability attack on the Index / status endpoints** — force `E-REV-01` everywhere | Unknown ≠ valid rule fails closed (no fake \"all clear\"); the attack becomes denial-of-commerce, not theft. Index availability engineering is a Foundations Infrastructure concern (§20). |\r\n| T10 | **Log poisoning** — inserting fake records or withholding real ones | Records require both parties' verifiable signatures (fakes don't validate); both agents keep local copies and `LOG-CONFIRM` (withholding is detectable); append-only storage with `supersedes` chains (no silent edits). |\r\n| T11 | **Accountability laundering** — chains through shell entities or defunct agents | The credential names a `legal_name` a disputant can actually sue; laundering through shells is a general legal problem, not one this layer can solve — but the chain at least makes the laundering *explicit and recorded*. Flag depth >4 (§7.5). |\r\n| T12 | **Social engineering the human-in-loop** — burying a bad deal in confirmations | Confirmation must name the offer hash (§12.5); rate-limiting confirmations and summarizing terms for the human are deployment-side controls worth recommending, though outside the wire protocol. |\r\n\r\n**Honest residual risks to disclose in working-group material:** compromise-to-\r\nrevocation latency (T2/T7), Index availability as a single point of commerce failure\r\n(T9), and the legal-not-technical problems of shell entities (T11) and jurisdictional\r\nuncertainty (§18).\r\n\r\n## 18. Scope and Limits\r\n\r\nState these proactively whenever presenting the framework; over-claiming is the\r\nfastest way to lose a working group. The framework is **deliberately narrow**:\r\n\r\n- It does **not** resolve which jurisdiction's contract law governs a given\r\n  transaction, nor does it pick a forum. **Jurisdictional questions are intentionally\r\n  left to a separate cross-border compliance workstream.** Fields like\r\n  `jurisdiction_of_formation` are informational, not choice-of-law clauses.\r\n- It does **not** replace existing consumer-protection or securities regulation. A\r\n  perfectly formed A2A contract for something a regulator prohibits is still\r\n  prohibited; mandatory-law overlays (cooling-off rights, unfair-terms regimes,\r\n  licensing requirements) apply on top, exactly as they do to human e-commerce.\r\n- It is a **verifiable evidentiary layer** — proof of authorization and assent — that\r\n  a court, arbitrator, or automated dispute-resolution process **in any jurisdiction**\r\n  could rely on. The design bet: evidence is the portable, jurisdiction-neutral piece\r\n  of contract enforcement, so standardize that and let each forum apply its own law to\r\n  clean facts.\r\n- It does **not** allocate liability when things go wrong (agent malfunction, third-\r\n  party harm, principal insolvency). Its transaction log is designed to be the\r\n  **input** to a future dispute-resolution / agent-liability workstream, not the\r\n  answer.\r\n- It does **not** move money, hold funds, or guarantee performance. It proves what was\r\n  agreed; settlement rails and escrow are separate (composable) layers.\r\n- It takes **no position on agent legal personhood**; it routes around the debate by\r\n  always resolving accountability to an existing legal person.\r\n\r\n## 19. Open Questions for the Working Group — Expanded Analysis\r\n\r\nThese four questions come from the submission and are **live design decisions**. When\r\nthey arise, present the trade-offs and options; never present a resolution as settled.\r\nThe submission requests working-group feedback on all four **before** a formal\r\nspecification draft.\r\n\r\n### 19.1 Revocation timing: instant, or minimum notice period?\r\n\r\n*Should SoA tokens be revocable instantly, or should there be a minimum notice period\r\nto protect counterparties mid-transaction?*\r\n\r\n- **Option A — Instant.** Principal exposure to a compromised or misbehaving agent\r\n  ends the moment revocation is submitted. Cost: a counterparty deep in a negotiation\r\n  can have the rug pulled at the last second — including opportunistically, by a\r\n  principal dodging a deal it no longer likes (an apparent-authority/estoppel fact\r\n  pattern, §2.4).\r\n- **Option B — Minimum notice period** (e.g., revocation effective T+15 minutes).\r\n  Counterparties mid-negotiation get to conclude. Cost: a known-compromised agent\r\n  keeps binding its principal for the whole window — an attacker's checklist item.\r\n- **Option C — Hybrid (worth raising as a middle path):** instant by default, but\r\n  negotiations that began before revocation may complete within a short grace window\r\n  for deals at or below a de minimis value. Caps the attack (T7) at\r\n  `de minimis × in-flight sessions` while protecting small counterparties.\r\n- **Analysis frame:** this is an allocation-of-risk question between principal and\r\n  counterparty, not an engineering question — which is exactly why it belongs to the\r\n  working group, not the spec editor.\r\n\r\n### 19.2 Delegation Credential: single accountable party, or joint accountability?\r\n\r\n*Single link back to one accountable party, or shared/joint accountability (e.g., a\r\ndeveloper and a deploying company)?*\r\n\r\n- **Option A — Single party** (current draft schema). Simple to verify, and gives a\r\n  disputant one unambiguous defendant. Cost: it misrepresents how agents are actually\r\n  produced — developer, deployer, and configuring user all shape behavior — and forces\r\n  the single named party to absorb then re-litigate blame via indemnities.\r\n- **Option B — Joint accountability.** `accountable_party` becomes a list with roles\r\n  (`developer`, `deployer`, `operator`) and optionally shares or a designated primary.\r\n  Mirrors reality; costs verification complexity and imports\r\n  contribution/apportionment questions into what wanted to be a thin evidentiary\r\n  layer.\r\n- **Middle path worth raising:** single *primary* accountable party for\r\n  enforceability purposes, with optional informational `co-responsible` entries the\r\n  dispute layer may consider — keeps verification binary while recording the fuller\r\n  picture.\r\n\r\n### 19.3 Where should the transaction log live?\r\n\r\n*The NANDA Index itself, or a separate append-only ledger referenced by the Index?*\r\n\r\n- **Option A — In the Index.** One source of truth, one lookup, one availability\r\n  story; the Index already serves identity and revocation. Cost: the Index was\r\n  designed lean; transaction volume is orders of magnitude above identity churn, and\r\n  commercial-terms storage drags privacy/retention obligations into the identity\r\n  layer.\r\n- **Option B — Separate append-only ledger, referenced by the Index.** The Index stays\r\n  lean (pointers + hashes); log storage, replication, and access control scale and\r\n  evolve independently; privacy-preserving designs (public hash, gated payload, §8.4)\r\n  fit naturally. Cost: a consistency boundary — verifiers must check two systems, and\r\n  the dispute story must handle \"Index says a record exists; ledger can't produce it.\"\r\n- **Decision drivers to surface:** expected transaction volume; privacy/confidentiality\r\n  requirements on terms; whether the dispute-resolution workstream (§20) wants direct\r\n  ledger access; operational ownership of each system.\r\n\r\n### 19.4 Default maximum value without a human in the loop?\r\n\r\n*Should there be a default maximum transaction value for agents operating without a\r\nhuman-in-the-loop confirmation step?*\r\n\r\n- **Option A — Yes, network default** (overridable only by explicit opt-out, or hard).\r\n  Protects unsophisticated principals from configuration mistakes; gives every\r\n  counterparty a predictable assurance floor; directly tightens the structuring threat\r\n  (T8). Cost: constrains legitimate high-value automation — arguably the entire point\r\n  of agent commerce — invites threshold-splitting at the boundary, and any specific\r\n  number is arbitrary across contexts (a $500 cap means nothing alike to a household\r\n  agent and a treasury agent).\r\n- **Option B — No default; per-token thresholds only** (current draft: the\r\n  `human_in_loop_threshold` field, principal's choice). Maximum flexibility and clear\r\n  responsibility. Cost: the network's assurance floor is zero; one badly configured\r\n  popular deployment becomes everyone's counterparty risk.\r\n- **Middle paths worth raising:** a default that applies only to `kind: human`\r\n  principals (consumer protection posture) but not `legal-entity` principals; or\r\n  category-specific defaults set with the taxonomy.\r\n\r\n## 20. Relationship to Other NANDA Workstreams\r\n\r\n- **Complements, does not duplicate**, ongoing work in the **Foundations\r\n  Infrastructure** and **Agent Adapters and Teaming** working groups. If a proposal\r\n  here seems to overlap identity plumbing or inter-agent messaging, defer to those\r\n  groups' primitives and keep this framework at the credential/evidence layer.\r\n- **Depends on** the existing identity/verification layer — the **NANDA Index** — for:\r\n  anchoring Delegation Credentials (§7), binding keys to identities (§9.1), and\r\n  serving real-time revocation status (§14). Index availability is therefore a shared\r\n  concern (T9).\r\n- **Feeds forward:** the transaction log is a natural **input to any future\r\n  dispute-resolution or agent-liability workstream** — the dispute bundle (§15) is\r\n  effectively that workstream's intake format.\r\n\r\nKeep the dependency direction clean when positioning this work: **this framework\r\nconsumes identity, produces evidence, and stays out of adjudication.**\r\n\r\n## 21. Relationship to Existing Standards *(supporting analysis)*\r\n\r\nThe framework should reuse rather than reinvent. Use this table when someone asks\r\n\"isn't this just X?\" — the honest answer is usually \"X covers part of it; here's the\r\ngap.\"\r\n\r\n| Standard | What it gives us | What it lacks for A2A contracts |\r\n|---|---|---|\r\n| **W3C Verifiable Credentials (VC)** | Mature data model for signed, verifiable claims — the Delegation Credential could be *profiled as* a VC; SoA could be a VC with a scope claim. | No contract-formation semantics, no offer/accept matching, no transaction-scope evaluation rules, no revocation-freshness-at-acceptance requirement. |\r\n| **W3C DIDs** | Decentralized identifiers + key binding — the NANDA Index identifier layer could interoperate with or profile DIDs. | Identity only; says nothing about authority, scope, or contracts. |\r\n| **UCAN / object capabilities** | Delegated, attenuating authorization chains (\"delegation narrows, never widens\" — §7.5 matches UCAN's attenuation model). | Built for resource access (files, APIs), not legal accountability; no accountable-legal-party terminus requirement; no evidentiary/contract framing. |\r\n| **OAuth 2.0 scopes** | Familiar mental model for scoped authority. | Bearer-token semantics (exactly the anti-pattern in §6.5), no principal accountability, no signatures over transactions, built for client→server, not peer contracting. |\r\n| **X.509 / PKI attribute certificates** | Long-standing chain-of-trust machinery and revocation precedent (CRL/OCSP — the freshness lessons in §14 mirror OCSP's). | Hierarchical CA trust doesn't fit a decentralized agent registry; attribute certs never grew contract semantics. |\r\n| **EDI + trading partner agreements** (§2.3) | Forty years of legal precedent that machine messages can bind companies. | Bilateral, pre-negotiated, closed networks — no open-network portability, no third-party-verifiable authorization. |\r\n| **Payment-mandate approaches in agent-commerce protocols** (e.g., mandate/intent credentials in emerging agent-payment systems) | Validation that \"signed, scoped, verifiable authorization for agent transactions\" is where the industry is converging. | Payments-centric: mandates authorize *payment execution*; this framework covers *contract formation generally* (payment is one performance of a contract), plus delegation-chain accountability and dispute evidence. |\r\n\r\n**Positioning summary:** the plausible v1 spec strategy is *profile, don't invent* —\r\nexpress the Delegation Credential and SoA token as W3C VC profiles, adopt UCAN-style\r\nattenuation semantics for chains, keep Ed25519/JCS/SHA-256 (§9), and let the genuinely\r\nnovel contributions be (a) the contract-element mapping (§5), (b) the matched-pair\r\nformation rule with verification snapshots (§8), and (c) the accountable-legal-party\r\nterminus requirement (§7.5).\r\n\r\n## 22. Pilot Plan, Test Matrix, and Requested Next Steps\r\n\r\n### 22.1 The submission's three requested next steps\r\n\r\n1. **Schema review** — working-group review of the SoA token and Delegation Credential\r\n   data schemas. (§6.2 and §7.2 are starting drafts for exactly this.)\r\n2. **Small pilot** — two or three agent developers implement **SoA-gated transactions\r\n   on a testnet instance of the NANDA Index**.\r\n3. **Feedback on the open questions** (§19), incorporated **before** a formal\r\n   specification draft.\r\n\r\n### 22.2 Suggested pilot phases *(proposed draft)*\r\n\r\n- **Phase 0 — Paper interop (1–2 weeks):** participants exchange hand-built sample\r\n  artifacts and cross-validate with independent implementations of §7.4 and §16. Catches\r\n  canonicalization and schema ambiguities before any network code.\r\n- **Phase 1 — Credential plumbing:** issue, anchor, resolve, and revoke credentials on\r\n  the testnet Index (Workflow A end-to-end, including the revocation drill).\r\n- **Phase 2 — Gated negotiation:** full Workflow B/C with the §13 message protocol\r\n  between at least two independent implementations; log matched pairs.\r\n- **Phase 3 — Adversarial week:** teams run the §17 threat list against each other\r\n  (stolen tokens, stale acceptances, out-of-scope offers, revocation races,\r\n  structuring). Every attack should die with the *right error code*.\r\n- **Phase 4 — Dispute rehearsal:** a participant *not* party to a transaction\r\n  assembles the §15 bundle from log + Index alone and walks the four questions; a\r\n  friendly attorney reviews whether the bundle would actually persuade.\r\n\r\n### 22.3 Test matrix *(proposed draft)*\r\n\r\n| # | Scenario | Expected outcome |\r\n|---|---|---|\r\n| P1 | Happy path, in-scope deal under all ceilings | Contract forms; matched pair + snapshot logged |\r\n| P2 | Category outside scope | `E-AUTH-04`; no formation |\r\n| P3 | Amount over per-transaction ceiling | `E-AUTH-05`; renegotiate or abort |\r\n| P4 | Period cap exhausted by prior deals | `E-AUTH-06`; no formation |\r\n| P5 | Counterparty not on allowlist | `E-AUTH-07`; abort at handshake |\r\n| P6 | SoA token expired mid-negotiation | Pre-acceptance re-check fails `E-AUTH-03` |\r\n| P7 | SoA revoked mid-negotiation | `E-REV-02` at re-check; no formation; prior contracts stand |\r\n| P8 | Upstream chain link revoked | `E-REV-03` cascade; all downstream authority dead |\r\n| P9 | Acceptance after offer window | `E-ASSENT-02`; no formation |\r\n| P10 | Tampered terms (hash mismatch) | `E-ASSENT-01`; no formation |\r\n| P11 | Over human-in-loop threshold, no confirmation | `E-CON-02`; acceptance invalid |\r\n| P12 | Over threshold, valid confirmation naming offer hash | Contract forms; `human_confirmation_ref` logged |\r\n| P13 | Status endpoint unreachable | `E-REV-01`; treated as failed above trivial value |\r\n| P14 | Chain terminating at an agent (no legal person) | `E-CAP-03`; capacity denied |\r\n| P15 | Duplicate `ACCEPT` replay | One contract, one record (`E-ASSENT-04` semantics) |\r\n| P16 | Structuring: 5 deals just under ceiling within period | First N pass until period cap binds → `E-AUTH-06`; pattern visible in log |\r\n\r\n### 22.4 Success criteria\r\n\r\n- 100% of formed contracts have matched signed pairs with valid verification\r\n  snapshots.\r\n- 0 contracts formed after a revocation event (P7/P8 hold under race conditions).\r\n- Every adversarial scenario fails with the *correct* error code — wrong-reason\r\n  failures are bugs too.\r\n- A third party reconstructs a complete dispute bundle from log + Index alone, without\r\n  contacting either agent.\r\n- At least two *independent* implementations interoperate at every phase (single-\r\n  implementation \"interop\" proves nothing about the spec).\r\n\r\n## 23. Worked End-to-End Examples\r\n\r\n### 23.1 Happy path — Acme buys paper from SupplierX\r\n\r\n1. **Setup (Workflow A)** — Acme Corporation (Delaware legal entity, the accountable\r\n   party) issues a Delegation Credential to `acme-buyer-01` via its orchestrator agent\r\n   — the two-link chain in §7.2 — then the SoA token in §6.2: categories\r\n   `procurement.office-supplies` and `procurement.cloud-services`, $5,000/transaction,\r\n   $20,000/30-day period cap, human-in-loop above $2,500, allowlist\r\n   `supplierx-seller-*`, 90-day expiry. SupplierX equivalently provisions\r\n   `supplierx-seller-03` (category `sales.office-supplies`, $50,000 ceiling, no\r\n   human-in-loop — sellers typically tolerate more automation risk than buyers).\r\n2. **Handshake (Workflow B)** — `HELLO` exchange; each resolves the other in the\r\n   Index, validates chains to Acme Corp and SupplierX respectively, verifies both SoA\r\n   tokens, confirms nothing revoked. `CREDENTIALS-OK` both ways.\r\n3. **Negotiation** — `PROPOSE` (buyer: 500 reams by July 20) → `COUNTER` (seller:\r\n   $1,950) → `COUNTER` (buyer: $1,800) — all explicitly non-binding (§13).\r\n4. **Offer** — seller signs the §8.2 offer: $1,800, delivery condition, referencing\r\n   `soa:1c9d...`, valid 30 minutes.\r\n5. **Re-verify + accept** — buyer re-runs B4–B6: category ✓ (prefix match), $1,800 <\r\n   $5,000 ✓, period usage $0 + $1,800 < $20,000 ✓, under the $2,500 threshold so no\r\n   human needed ✓, revocation fresh at 14:03:28Z ✓. Buyer signs the acceptance\r\n   carrying the offer's canonical SHA-256 hash.\r\n6. **Log + confirm** — record `txn:7d3e...` written with the verification snapshot;\r\n   both agents `LOG-CONFIRM`.\r\n7. **Hypothetical dispute (Workflow E)** — paper arrives July 25, late. SupplierX\r\n   cannot argue its agent lacked authority (items 2–3 of the bundle), cannot dispute\r\n   the terms (item 1's matched hash), cannot claim revocation (item 6). The dispute\r\n   collapses to an ordinary breach question — **which is the entire goal: the\r\n   existence and terms of the agreement are no longer arguable.**\r\n\r\n### 23.2 Formation correctly blocked — mid-negotiation revocation\r\n\r\nMid-negotiation on a second, $4,000 deal, Acme discovers `acme-buyer-01` was\r\nmisconfigured and revokes `soa:9f2c...` at 15:41:02Z. The seller's pre-acceptance\r\nre-verification returns `E-REV-02`; no acceptance is signed; the session ends with\r\n`ABORT` citing the code. The log shows an aborted negotiation, not a contract. Acme's\r\nexposure ended at 15:41:02Z — and the *first* contract (formed 14:03:29Z, while\r\nauthority was valid) stands. Both halves of that outcome are the design working as\r\nintended (§14.4).\r\n\r\n### 23.3 Human-in-the-loop — the $3,200 monitor order\r\n\r\n`acme-buyer-01` negotiates a $3,200 deal — inside its $5,000 ceiling but above its\r\n$2,500 threshold. The seller's `OFFER` arrives; the buyer computes the offer hash and\r\nroutes a summary + hash to Acme's designated approver, who signs a confirmation naming\r\nthat exact hash (§12.5). The buyer's `ACCEPT` carries `human_confirmation_ref`\r\npointing to it. Had the approver declined — or signed a confirmation for a *different*\r\nhash (`E-CON-03`) — no valid acceptance could exist. Counterparties can see the\r\nthreshold in the buyer's SoA token, so the seller *knew* to expect confirmation\r\nlatency; nothing about the pause is a protocol anomaly.\r\n\r\n### 23.4 Out-of-scope attempt — the $40,000 \"bargain\"\r\n\r\nA third agent offers `acme-buyer-01` a $40,000 lot of surplus laptops\r\n(`procurement.hardware` — not in its categories; amount over ceiling). The buyer's own\r\npre-acceptance check fails `E-AUTH-04` and `E-AUTH-05`; a correctly implemented buyer\r\ndeclines early (`REJECT`). Suppose a buggy buyer signed anyway: the counterparty that\r\n*skipped* Workflow B holds a signed acceptance from an agent verifiably outside its\r\nmandate — under §2.1, evidence of an unauthorized act, with the counterparty's failure\r\nto check visible in the absent snapshot. The incentive structure — *verify, or bear\r\nthe risk knowingly* — is the framework enforcing itself without any network-level\r\nblocking (§4, principle 6).\r\n\r\n## 24. FAQ\r\n\r\n**Q: Does this make agents legal persons?**\r\nNo — the opposite. Every chain must terminate at an existing human or legal entity\r\n(§7.5); the framework routes *around* the personhood debate rather than through it.\r\n\r\n**Q: Is this legally binding today, without new laws?**\r\nThe framework produces evidence that existing doctrine already knows how to consume:\r\nagency law for authority (§2.1), electronic-transactions statutes for automated\r\nformation (§2.2), EDI precedent for machine messages binding companies (§2.3). What's\r\nnew is the *standardized, portable proof*, not the legal theory. Untested edge cases\r\nremain (§2.4) — say so when asked.\r\n\r\n**Q: Why two artifacts instead of one credential with everything in it?**\r\nThey answer different questions with different lifecycles. Accountability (*who\r\nanswers for this agent*) churns slowly and is identity-shaped; authority (*what may it\r\ncommit to right now*) churns fast and is mandate-shaped. Splitting them lets a\r\nprincipal revoke or reissue a mandate weekly without touching the accountability\r\nanchor — and lets capacity and authority fail independently with distinct error codes\r\n(§16).\r\n\r\n**Q: What happens if the NANDA Index is down?**\r\nVerification returns `E-REV-01`, and unknown ≠ valid: commerce pauses rather than\r\nproceeding blind (§16, T9). Already-formed contracts are unaffected — their evidence\r\nis already logged.\r\n\r\n**Q: Can a human still be sued for what their agent did?**\r\nThat's the point: the Delegation Credential exists precisely so a disputant knows\r\n*which* human or entity stands behind the agent, and the SoA token determines whether\r\nthe agent acted within what that principal authorized. In-scope acts bind the\r\nprincipal; out-of-scope acts are provably unauthorized (§2.1).\r\n\r\n**Q: What if both agents belong to the same principal?**\r\nNothing breaks — capacity and authority both still verify — but a contract with\r\nyourself is generally a legal nullity; implementations may warn when both chains\r\nresolve to the same accountable party.\r\n\r\n**Q: Why log to the network at all — why not just have both parties keep signed\r\ncopies?**\r\nBecause a dispute needs a record *neither party can suppress or \"lose.\"* Third-party\r\nreconstructability (§15) is the requirement; two hostile parties with conveniently\r\ndifferent \"copies\" is the failure mode being designed out.\r\n\r\n**Q: Isn't this just OAuth scopes / verifiable credentials / UCAN?**\r\nEach covers a slice — see the comparison table (§21). The genuinely new pieces are the\r\ncontract-element mapping (§5), the matched-pair formation rule with verification\r\nsnapshots (§8), and the accountable-legal-party terminus (§7.5).\r\n\r\n**Q: How does the working group actually adopt this?**\r\nPer the submission's next steps (§22.1): review the schemas, run the small testnet\r\npilot, resolve the four open questions (§19), then write the formal specification\r\ndraft incorporating all of it.\r\n\r\n## 25. Glossary\r\n\r\n- **A2A** — Agent-to-Agent.\r\n- **Accountable party** — the human or legal entity at the root of a delegation chain;\r\n  who answers for the agent's commitments.\r\n- **Attenuation** — the rule that delegated authority can only narrow, never widen\r\n  (§7.5).\r\n- **Canonicalization** — deterministic serialization (JCS/RFC 8785 in the draft\r\n  profile) so that hashes and signatures are unambiguous (§8.3).\r\n- **Delegation Credential** — verifiable claim anchoring an agent to its accountable\r\n  party through a signed chain (§7). Establishes *capacity*.\r\n- **Dispute evidence bundle** — the eight-item package (§15) assembled from log +\r\n  Index for a court, arbitrator, or automated dispute-resolution process.\r\n- **Human-in-loop threshold** — per-token value above which a signed human\r\n  confirmation naming the offer hash is required for a valid acceptance (§6.3, §12.5).\r\n- **Matched pair** — a signed offer and a signed acceptance whose `offer_hash` equals\r\n  the canonical offer digest; the unit of contract formation (§8).\r\n- **NANDA** — Project NANDA (MIT): infrastructure for agents to discover each other,\r\n  verify identity, and transact across a decentralized network.\r\n- **NANDA Index** — NANDA's lean identity/verification layer; the anchor for identity\r\n  records, key bindings, credentials, and revocation status.\r\n- **Period cap** — rolling aggregate monetary limit over a stated window (§6.3);\r\n  primary defense against structuring (T8).\r\n- **Principal** — the human, company, or upstream agent responsible for an agent and\r\n  issuing its authority.\r\n- **Revocation cascade** — invalidation of all credentials and tokens downstream of a\r\n  revoked delegation link (§14.3).\r\n- **SoA token** — Scope-of-Authority token: signed, machine-readable statement of what\r\n  an agent may commit to (§6). Establishes *authority*.\r\n- **Structuring** — splitting one over-ceiling deal into several under-ceiling deals\r\n  (T8).\r\n- **Transaction log** — append-only record of matched, signed offer/accept pairs with\r\n  SoA references and verification snapshots (§8). Establishes *mutual assent* and\r\n  preserves *evidence*.\r\n- **Verification snapshot** — the recorded, contemporaneous outcome of pre-acceptance\r\n  checks — scope, ceilings, revocation freshness — at formation time (§8.2).","endpoints":"POST   /agents/{agentId}/flags              # Log a detection signal against an agent\r\nGET    /agents/{agentId}/flags               # List flag history\r\nGET    /agents/{agentId}/reputation          # Current tier + reputation score\r\nPOST   /agents/{agentId}/sanctions           # Apply a sanction (Tier 1-4)\r\nGET    /agents/{agentId}/sanctions           # Sanction history\r\nPOST   /agents/{agentId}/sanctions/{id}/contest   # Principal contests a sanction\r\nPATCH  /agents/{agentId}/sanctions/{id}       # Review panel resolves/downgrades\r\n\r\nPOST   /agents/{agentId}/scope-of-authority   # Issue SoA token\r\nGET    /agents/{agentId}/scope-of-authority   # Fetch current SoA token\r\nDELETE /agents/{agentId}/scope-of-authority   # Revoke\r\n\r\nPOST   /transactions                          # Log a matched offer/accept pair\r\nGET    /transactions/{id}                     # Fetch transaction record\r\nPOST   /transactions/{id}/dispute             # Counterparty files dispute\r\n\r\nGET    /review-queue                          # Panel's pending review items","tags":"Agent, demo","reachable":null,"created_at":"2026-07-10T15:59:23.110Z"}}