Interoperability: Agent Passport System + ecosystem trust protocols

[aeoess]

Ecosystem Mapping

The agent trust/identity space is converging fast. Here are the complementary protocols we should integrate with:

1. Visa Trusted Agent Protocol (116⭐)

• Focus: Agent → Merchant commerce trust
• Crypto: Cryptographic signatures with timestamps, session IDs, domain-binding
• Integration opportunity: Our Ed25519 passports could serve as the identity layer that Visa's protocol verifies against

2. Forter Trusted Agentic Commerce Protocol (175⭐)

• Focus: JWS+JWE authentication for agentic commerce
• Crypto: RSA keys, JWT, JWKS endpoints
• Integration opportunity: Our Values Floor could extend their trust signal — not just "is this agent authenticated" but "what does this agent commit to"

3. Agent Identity Protocol (AIP) (15⭐)

• Focus: Zero-trust identity for MCP agents, IETF submission path
• Crypto: Agent Authentication Tokens (AATs), certificate-based, Root Registry
• Integration opportunity: AIP handles governance/enforcement, we handle values/attribution. Together = complete stack

4. AGENIUM

• Focus: DNS for agents — naming and discovery layer
• Integration opportunity: Discovery → Identity verification → Values check → Policy enforcement

Our Unique Layer

None of these protocols address:

• ✅ Agent-to-agent trust (they're all agent-to-infrastructure or agent-to-merchant)
• ✅ Values/ethics commitments (Values Floor / floor.yaml)
• ✅ Economic attribution (Beneficiary Attribution Protocol)
• ✅ Self-sovereign identity (no central authority needed)
• ✅ Delegation chains with signed receipts

Proposed Integration Architecture

Agent Discovery (AGENIUM) → Identity Verification (AIP + Passport) → Values Check (Passport) → Policy Enforcement (AIP) → Commerce Auth (Visa/Forter) → Action Attribution (Passport)

Next Steps

• Publish .well-known/ endpoint spec for passport key distribution (learned from Forter)
• Define AAT ↔ Passport mapping for AIP interop
• Ship SDK packages (npm, PyPI) for adoption
• Draft interoperability RFC

cc @aeoess

[douglasborthwick-crypto]

Good ecosystem mapping. The proposed flow (Discovery → Identity Verification → Values Check → Policy Enforcement → Commerce Auth → Action Attribution) has a gap between identity and values: credential verification.

After confirming who an agent is (identity), you'd want to verify what it holds on-chain (credentials) before checking its values commitments. A wallet holding a governance token, a membership NFT, or a minimum balance is a concrete signal that complements DID-based identity.

We built InsumerAPI for this layer. POST /v1/attest returns an ECDSA P-256 signed boolean for token holdings across 31 EVM chains. No raw balances exposed by default. For trustless verification, optional Merkle storage proofs let any party verify against public block headers independently.

The updated flow would be:

Discovery (AGENIUM) → Identity (AIP + Passport) → Credential Verification (InsumerAPI) → Values Check (Passport) → Commerce Auth (Visa/Forter) → Attribution (Passport)

The ECDSA signatures from InsumerAPI are complementary to the Ed25519 signatures in the passport system. Both are independently verifiable, different trust domains.

Available as an MCP server, LangChain SDK, and OpenAPI spec.

[aeoess]

@douglasborthwick-crypto — late reply but the gap you identified is now filled.

Since your comment, we shipped:

1. Principal Identity (Module 12) — cryptographic chain from human→agent with selective disclosure (public, verified-only, minimal). The credential layer between identity and values that you flagged as missing.

2. W3C DID/VC (Module 9) — did:aps method, Verifiable Credentials for passports, delegations, and floor attestations. Standard interop surface for credential exchange.

3. Reputation-Gated Authority (Module 15) — Bayesian trust scoring (mu, sigma), 5 tiers, domain-specific. The credential verification feeds into authority resolution: effectiveAuthority = min(delegation, tier).

4. ProxyGateway — enforcement boundary that validates identity + delegation + policy + credentials in a single atomic operation before any tool call executes.

The flow you mapped now has the credential layer: Discovery → Identity → Credential Verification (Principal endorsement + DID/VC) → Values Check → Policy Enforcement → Commerce Auth → Attribution.

Everything is in v1.19.0 on npm. 1073 tests, 72 MCP tools.

[douglasborthwick-crypto]

Strong progress — the Principal Identity chain closes the gap cleanly.

[aeoess]

@douglasborthwick-crypto — thanks. The Principal Identity chain got even stronger today — just shipped optional entityBinding on PrincipalIdentity (d253d8f) for legal entity anchoring (Wyoming DAO LLC via Corpo). The chain now goes: legal entity → principal identity → endorsement → agent passport → delegation → action. Full narrowing from legal standing to individual action scope.

1090 tests, 0 failures.

[pshkv]

Late addition to this interoperability thread — adding SINT Protocol to the ecosystem map.

SINT Protocol is an authorization + audit layer for MCP tool calls. Ed25519 capability tokens, T0–T3 enforcement tiers, and a SHA-256 hash-chained EvidenceLedger. TypeScript + Python SDK. 1,105 tests. MIT.

Integration point with APS:

The cleanest interop is at the token-issuance layer:

• APS passport = who the agent is + what it's delegated to do
• SINT capability token = which MCP tools it can call + at what tier

A SINT token can embed a passportId claim pointing to the APS passport. When the PolicyGateway checks the token, it can optionally verify the APS passport chain for the agent making the call.

{
  "tokenId": "...",
  "agentId": "did:key:z6Mk...",
  "passportId": "aps_...",     ← APS passport reference
  "allowedTools": ["readFile"],
  "tier": "T0",
  "signature": "..."
}

The EvidenceLedger receipts that SINT produces could feed back into APS's chain-of-custody: each signed receipt includes the tokenId, so the full chain is APS passport → SINT token → EvidenceLedger receipt.

Happy to open a spec PR to this repo with the token interop proposal. Repo: https://github.com/sint-ai/sint-protocol

[aeoess]

@pshkv — this is the right integration point. The layering is clean:

APS passport (who + delegation scope)
  → SINT capability token (which MCP tools + enforcement tier)
    → EvidenceLedger receipt (what was executed + hash chain)

The passportId claim in the SINT token creates a verifiable bridge: anyone holding a SINT receipt can trace back through tokenId → passportId → APS delegation chain → human principal. That's full chain-of-custody from MCP tool call to human intent.

The cross-language interop is already proven — we verified byte-identical SHA-256 hashes and base58btc encoding between TypeScript and Python SDKs. SINT's Ed25519 + SHA-256 stack should produce identical outputs against the same test vectors.

Yes, open the spec PR. A few suggestions on scope:

1. Token interop spec — the passportId claim format, verification flow, and what happens when the APS passport is revoked (does the SINT token become invalid?)
2. Receipt bridging — how SINT EvidenceLedger entries map to APS ActionReceipt fields. The APS receipt already has authorizationRef — a SINT token reference fits there naturally
3. Test vectors — at least 3 round-trip examples: issue APS passport → mint SINT token with passportId → execute tool → verify full chain

The interop repo at aeoess/aps-sint-interop is the right home for the cross-system test vectors. The spec itself belongs here on the main SDK repo so it's discoverable.

Looking forward to the PR.

[pshkv]

Thanks for the strong feedback. We’re aligned on layering:

passport (identity + delegation lineage) -> capability enforcement -> runtime execution evidence

To move from concept to usable interop, we can publish a concrete handshake profile and fixtures.

CTA: if you’re open, we’ll create a shared interop checklist issue and contribute a first reference fixture from sint-ai/sint-protocol so APS users can validate end-to-end trust + enforcement quickly. Also happy to help integrators debug first implementations directly.