tracking: Trust Passport cross-org federation protocol (deferred, depends on signing infrastructure)

[telleroutlook]

What this is

A strategic gap identified during an ecosystem audit (2026-07-18). Tracked here as an org-level reminder so it is not forgotten.

The gap

agent-trust-infra's Trust Passport is currently a single-organization, offline-verified artifact:

• Issued as a self-signed JSON document (no cryptographic signature — attestation.signature field exists in schema but is not implemented)
• Verified by local schema validation + isExpired() only — no network call
• Revocation is a boolean flag inside the document itself — no external revocation list
• No .well-known endpoint, no DID-based discovery, no cross-org lookup mechanism

This means a Trust Passport cannot be verified by a party outside the issuing organization without receiving the raw JSON file manually. There is no way for Organization A to verify that a Trust Passport issued by Organization B is authentic, unexpired, and not revoked — without trusting the file they were handed.

Why it is deferred

The prerequisite — cryptographic signing of the passport — is not yet implemented. Building a federation/discovery protocol on top of unsigned documents is not meaningful. The correct sequencing is:

1. First: implement passport signing (roadmap points to Sigstore/in-toto as the preferred approach, rather than self-rolled PKI) — tracked in agent-trust-infra
2. Then: implement .well-known/agent-trust-passport discovery endpoint so a verifier can fetch a live passport by agent identity without receiving a file
3. Then: implement a revocation list / status channel so a verifier can check whether a passport has been revoked since issuance
4. Finally: federated resolver — a lightweight protocol (analogous to DNS or Certificate Transparency) that lets any party resolve and verify a Trust Passport by agent identifier across organizational boundaries

This is explicitly Phase 6–7 on the agent-trust-infra roadmap.

What the federation protocol would need to include

1. .well-known/agent-trust-passport endpoint spec — standard URL path + response format for serving a signed passport document by agent identity
2. Revocation list format — a periodically updated JSON/JWS document listing revoked passport IDs, hosted at a well-known URL, analogous to a CRL or OCSP responder
3. Passport Resolver service — an optional hosted resolver (Trustavo could serve this role) that caches and indexes passports from registered issuers, allowing lookup by agent ID without knowing the issuer's domain
4. Verification library update — extend trust-passport-core's validateTrustPassport() to optionally fetch and verify a live passport rather than only validating a locally-provided document

Prerequisite tracking

• agent-trust-infra: implement cryptographic signing (Sigstore/in-toto)
• agent-trust-infra: implement revocation propagation
• Once both land: revisit this issue and scope the federation protocol

Status

Deferred — blocked on signing infrastructure. Do not start until attestation.signature is a real implementation in agent-trust-infra.

[telleroutlook]

Acknowledged as a strategic tracking item for cross-org federation protocol. This appears to be a legitimate architectural gap deferred due to signing infrastructure dependencies. Consider adding a timeline or milestone label when this becomes actionable.

— automated triage by patrol bot

[telleroutlook]

Strategic feature request acknowledged. This architectural enhancement is appropriately deferred pending signing infrastructure dependencies. Tracked as org-level reminder for future roadmap planning.

— automated triage by patrol bot

[telleroutlook]

Thanks for documenting this strategic gap — confirming it's tracked as a deferred feature. We'll revisit once the underlying signing infrastructure (Sigstore/in-toto, DID discovery, signature field implementation) lands, since federation can't meaningfully precede that foundation.

— automated triage by patrol bot