feat(amdp): v0.1.0 spec draft — ADR-040 Phase 1

[Baldri]

Was

Introduces amdp-spec/ — the Agent Mandate Discovery Protocol (AMDP) v0.1.0 draft — as a sibling specification to adcp-spec/ in the protocol-commerce monorepo. Phase 1 of the ADR-040 roadmap.

Warum

AMDP fills the missing fourth layer of the agent-commerce stack: cross-vertical mandate discovery. The other three layers — marketplace, capability-registry, transaction-protocol — already have multiple implementations (Circle Marketplace, IAB Tech Lab Agent Registry, UCP/ACP/AdCP). What none of them define is the cross-vertical, revocable, third-party-verifiable mandate that a relying party in one vertical can use to verify an agent acting on behalf of a principal whose identity lives in another vertical.

Per ADR-040 (Baldri/nexbid repo, merged 2026-05-17), Nexbid pursues the Open Standard route rather than launching another hosted product:

• Submission targets: IAB Tech Lab AAMP (Curation-Protocol window closes 30.06.2026) + Linux Foundation Agent-Infrastructure-WG
• EU-Authority via co-authoring + Lean-4 reference implementation, not hosted lock-in
• ICANN-Move not Google-Move
• Brand-Architektur-consistent: AMDP sits UNDER verticals (Nexbid, Mineralis), not next to them

Aenderungen

amdp-spec/ folder, 17 new files, +2,169 lines:

File	Purpose	Lines
README.md	Overview, stack diagram, quick start, cross-repo links	190
SPECIFICATION.md	Normative spec (10 sections: terminology, schema, taxonomies, signatures, resolver/discovery OpenAPI, errors, versioning)	746
CONFORMANCE.md	Role-based MUST/SHOULD/MAY for Issuer/Verifier/Resolver/Discovery, 15 test vectors	196
SECURITY.md	Threat model T1-T6, PQC migration phases, audit-log spec	271
CHANGELOG.md	v0.1.0 entry + v0.2.0 known open items	52
REFERENCES.md	ADR links, IETF/W3C/NIST refs, IAB/LF/UCP/ACP/AP2/x402/MCP refs	152
examples/	5 reference mandates + README + 5 explanatory .md files	562

Key technical decisions in v0.1.0:

• Schema: JSON Schema Draft 2020-12, COSE_Sign1 (RFC 9052), JCS canonicalization (RFC 8785), UUID v7 mandate IDs
• Signatures: Hybrid Ed25519 + ML-DSA-65 (RECOMMENDED), per ADR-025; pure Ed25519 for legacy; pure ML-DSA-65 reserved for PQC-only
• Endpoints: /.well-known/amdp/{verify,revoke,discover} with OpenAPI 3.1 inline specs
• Verticals v0.1: advertising, procurement, equity-research, public-services
• 15 stable error codes with HTTP status code mapping
• SemVer with pre-1.0 contract: breaking changes between MINOR versions explicitly permitted while v0.x

Tests

All 5 example mandates plus the README minimal mandate validate against the Mandate Document JSON Schema (SPECIFICATION.md section 2.1):

PASS  advertising-publisher-mandate.json
PASS  equity-research-family-office.json
PASS  multi-vertical-family-office.json
PASS  procurement-cross-vendor.json
PASS  public-services-citizen-request.json
ALL EXAMPLES VALIDATE

README minimal example: VALID

Validation tool: ajv 2020 (ajv/dist/2020.js) with ajv-formats, strict=false. Schema is extracted from SPECIFICATION.md Draft 2020-12 fenced code block; one UUID v7 variant-byte bug was caught and fixed during validation (c5fa- → 85fa-; the variant byte must start with [89ab]).

JSON parse-checks via jq empty on all 5 example files: OK.

No CI pipeline runs on *.md-only PRs in nexbid-dev/protocol-commerce (verified — only lean-build.yml workflow exists and is restricted to lean-verification/** paths).

Review-Punkte

Please pay particular attention to:

1. Taxonomy completeness for v0.1. Are the four initial verticals + 13 actions + 7 constraints the right starting set? Anything obviously missing for IAB Tech Lab submission?
2. Sub-delegation cross-vertical semantics (multi-vertical-family-office.json + SPECIFICATION.md section 2.2 + SECURITY.md mitigation M6.5). The example deliberately changes vertical (equity-research parent, procurement child) and the spec text says this is permitted "if operationally subordinate". v0.2.0 may want stricter rules — but for the draft this models the realistic Family-Office case.
3. Threat T3 (Constraint Bypass) mitigations. The spec is explicit that constraints MUST be evaluated server-side at the resolver, not client-side. The README and CONFORMANCE.md both reinforce this. Worth a sanity check that the OpenAPI surface doesn't accidentally enable client-side evaluation paths.
4. Hybrid signature deterministic ordering. SPECIFICATION.md section 6.4 mandates Ed25519 first, ML-DSA-65 second. Verify this matches the ADR-025 pattern in Baldri/nexbid/lean-verification/.
5. Cross-repo links (REFERENCES.md, README.md). All point to github.com/Baldri/nexbid/blob/main/... — please confirm Baldri/nexbid is the correct upstream slug (vs nexbid-dev/nexbid or similar).

Dokumentation

• All seven amdp-spec/ files carry a Version/Status/License header at the top
• Status: draft v0.1.0 is explicit throughout — no claims of "stable" anywhere
• License notice: spec is MIT; reference implementations (planned, separate repos) will be Apache 2.0
• No CLAUDE.md update needed in this PR — the source-of-truth ADR-040 lives in the nexbid repo, not in protocol-commerce
• Companion docs in nexbid repo (already merged on 2026-05-17):
  • docs/knowledge-base/adr/040-amdp-agent-mandate-discovery-protocol.md
  • docs/strategy/2026-05-17-amdp-google-fuer-agenten-ehrliche-positionierung.md
  • docs/outreach/2026-05-17-iab-amdp-submission-draft.md

Out of scope for this PR

• Lean 4 reference implementation. Lands in a follow-up PR. The 47 existing theorems in lean-verification/ (just imported via feat(lean): import 47 Lean 4 theorems — machine-checked auction core #1) establish the precedent; AMDP-specific theorems will be added on top.
• TypeScript SDK (amdp-sdk-typescript/). Planned for ADR-040 Phase 2 once the spec stabilizes.
• Conformance test suite npm package (@protocol-commerce/amdp-conformance). Planned for Phase 4.
• Test vector files (examples/test-vectors/). The 15 vectors are enumerated in CONFORMANCE.md section 6; the JSON files + key material come with the conformance suite (Phase 4).

🤖 Generated with Claude Code