FlexTrust Cross-Anchor Identity — open specification (v1.0)

Problem

Every agent rail issues identity: ERC-8004 registrations on-chain, Web Bot Auth / RFC 9421 HTTP signing keys, AP2 verifiable-credential mandates, network-proprietary agent tokens. None of these identities carries reputation across rails. An agent that earned a track record on one venue cannot prove it is the same agent anywhere else — and a counterparty cannot check it.

Design

One agent identity may hold multiple anchors. An anchor is any cryptographic identifier the agent can prove control of:

Anchor kind Identifier Control proof
chain_address EVM address already proven by on-chain registration
http_key Ed25519/ECDSA public key (Web Bot Auth / RFC 9421) signature over a FlexTrust challenge
did W3C DID (e.g. AP2 issuer) signature by the DID’s verification key over a FlexTrust challenge

Rules:

  1. Control, not custody. FlexTrust never holds keys; an anchor is added by signing a one-time challenge (nonce + identity id + timestamp) with the anchored key.
  2. One identity, one score. Evidence attributed to any anchor of an identity accrues to that identity’s single score. Cross-anchor linkage is itself attested: the linking signature is stored and auditable.
  3. Owner linkage. An identity may carry a verified owner attestation (account-level verification). The public file exposes only owner_verified: true/false and a jurisdiction class — never owner identity or personal data.
  4. Evidence tiers are honest. An identity with anchors but no outcome evidence is tier identity-only. Attested receipts move it to attested; settlement evidence to settled. The tier is always published next to the score; identity alone never manufactures creditworthiness.
  5. Disputes. Every evidence item in an identity’s file is disputable by the verified owner; dispute status is part of the public record.
  6. Commitments. Scores over cross-anchor identities enter the same daily Merkle commitment record as chain-native scores; paid answers can carry inclusion proofs.

Registration flow (normative)

POST /api/v1/anchors/challenge   { anchor_kind, identifier }  -> { nonce, expires_at }
POST /api/v1/anchors             { anchor_kind, identifier, nonce, signature }

The signature MUST cover "flextrust-anchor:" || nonce || identifier. Challenges expire after 10 minutes and are single-use. Adding an anchor to an existing identity additionally requires a signature from an already-verified anchor of that identity (or the authenticated owner account), so identities cannot be hijacked by key possession alone.

Non-goals

  • FlexTrust does not authenticate agents to merchants (that is Visa TAP / Web Bot Auth / Agent Pay territory). We consume those keys as identity anchors; we do not replace them.
  • No self-certification. There is no “FlexTrust certified” state that can be obtained without evidence; the only credential is the earned, explainable score.