@zanii/identity-bridge

Consume enterprise agent identity — don't compete with it. Enterprises just deployed Microsoft Entra Agent ID, Okta for AI Agents, and SPIFFE. Asking them to rip that out for a Zanii did:key loses the deal. Instead bind the identity they already trust to a Zanii key, so a Zanii receipt is provably by the agent their IdP governs — one keypair, two identity systems.

npm install @zanii/identity-bridge @zanii/core

import { buildBinding, verifyBinding, bindingReceipt } from '@zanii/identity-bridge';

// the agent signs the Zanii side of the binding to its Entra identity:
const binding = buildBinding(
  { did: agent.did, scheme: 'entra', externalId: entraObjectId, issuer: tenant, ts: now },
  agent.privateKey,
);
await zanii.record(bindingReceipt(binding));   // anchor it into the agent's history

// anyone verifies both sides — the did:key signature AND the enterprise token:
const check = await verifyBinding(binding, presentedToken, myEntraVerifier);
check.ok;        // did:key signed it, AND the IdP authenticated a token for the SAME subject
check.identity;  // { scheme, external_id, issuer }

Python: from zanii.identity_bridge import build_binding, verify_binding, ...

Injected verification (the @zanii/attest discipline)

This package does not fetch Entra JWKS or validate a SPIFFE X.509 chain — that pins you to token formats that change and needs live tenants to test. You pass a verifyToken(token) → { scheme, external_id, issuer } | null — your existing Entra/SPIFFE/OIDC middleware already does exactly this. We verify the binding; you supply the trust root. Schemes: entra, spiffe, oidc (scheme-agnostic — a SPIFFE SVID binds the same way an Entra JWT does).

The two-way check fails unless both sides agree: a binding signed by the Zanii key but backed by a token for a different subject is rejected with subject mismatch.

The limit, stated up front

The binding is only as strong as the injected verifier. It proves "the holder of this did:key presented a token your IdP issued for subject X" — it does not re-derive Microsoft's or SPIFFE's trust, and it cannot vouch for an IdP you don't actually check. Bind an identity you verify; never one you merely received.