delegation.md draft + AAE / W3C VC alignment — observations and offer

Hi @uchibeke,

Read through OAP v1.0, the delegation.md working draft, and the arXiv paper. Your "complementary, not competing" framing in the conclusion is the right characterization, and it matches what I see when mapping OAP against W3C VC + DID architectures.

A few structural observations, plus one concrete offer.

## Structural convergence in delegation.md

The v1.1 delegation draft and the Agent Authorization Envelope (AAE) — currently published as IETF Internet-Draft, also referenced in W3C and A2A discussions — converge on close to identical mechanics:

- signed delegation token (Ed25519) ↔ signed envelope
- granted_capabilities ⊆ delegator.effective_capabilities ↔ scope narrowing as MUST
- depth_cap with depth_remaining-- per hop ↔ depth-limited chain
- chain_root_passport_id propagated unchanged ↔ principal-authority root reference
- mandatory expires_at, no never_expires ↔ time-bounded validity
- per-DT optional revocation_endpoint ↔ per-credential revocation surface

Both the AAE envelope and the principal-authority chain are documented in our recent arXiv paper (2605.06738 — "From Specification to Deployment: Empirical Evidence from a W3C VC + DID Trust Infrastructure for Autonomous Agents"), if you want the architectural framing in writing before the IETF draft revs.

The vocabularies differ (passport_id vs. credential subject, capability dotted-namespace vs. JSON-LD), but the architectural shape lines up cleanly. Worth knowing if v1.1 is still open for external input.

## One spec question

The OAP-Passport schema has an optional `did` field, with `did:web:api.aport.io:agents:ap_xxx` as the example. Is the slot constrained to `did:web`, or is the JSON-schema deliberately open to other DID methods? Specifically, would a `did:moltrust:xxx` or any other resolvable DID method be schema-valid?

If yes, that single field is the cleanest interop point — verifiers with broader DID-resolver support get the upstream principal-authority chain; verifiers without it still see a normal OAP-Passport. No code dependency either direction.

## Offer

If delegation.md v1.1 work is still open to external review, I can share:

- AAE Internet-Draft (current rev) for cross-reference
- A field-mapping table between AAE envelope shape and the delegation.md token shape (built from the analysis above)
- Notes on where W3C VC alignment is straightforward and where the source-of-truth boundary stays cleanly on the OAP side

Not pitching a merge, not asking for normative changes. Just offering the mapping work in case it saves time before v1.1 lands.

The complementarity holds regardless: OAP enforces at the tool-call boundary, AAE answers the upstream "does this agent have standing to act for this principal." Different layers, same threat surface.

— Lars, MolTrust