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
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:
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
didfield, withdid:web:api.aport.io:agents:ap_xxxas the example. Is the slot constrained todid:web, or is the JSON-schema deliberately open to other DID methods? Specifically, would adid:moltrust:xxxor 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:
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