Identity

Digital identity is four distinct problems, routinely conflated. A person proving they are human is a different problem than an organization proving it authorized a specific agent to commit $5 million on its behalf. Treating these as one problem produces systems that are either too weak for high-stakes commitments or too burdensome for routine interactions.

Integra separates identity into four tiers, each with distinct verification requirements, distinct contract surfaces, and distinct trust anchors.

Four Tiers of Identity

Tier 1: Human — "Is this a person?"

The foundational identity question. Not "which person?" but "is there a real human behind this action?" This tier defeats Sybil attacks and establishes that the system is interacting with a biological person, not a bot farm.

Verification methods: ZK passport verification (Noir circuits verifying passport data without revealing it), mobile driver's license (mDL) verification, proof-of-personhood protocols, and SIWE (Sign-In with Ethereum) as a baseline wallet-binding mechanism.

Capability level: CORE_VIEW | CORE_CLAIM (0x03) — the party can view records and claim agreement tokens, establishing that a verified human is behind the wallet address.

Tier 2: Entity — "On whose behalf?"

A human is a person. An entity is a legal construct — a corporation, a partnership, a government agency — that can own property, enter contracts, and be sued. Tier 2 verifies that a person acts with authority on behalf of a specific legal entity.

Verification methods: vLEI (verifiable Legal Entity Identifier) chain validation, KYB (Know Your Business) provider verification, UCP business profiles, corporate filing verification.

Capability level: CORE_VIEW | CORE_CLAIM | CORE_TRANSFER (0x07) — the entity can view, claim, and transfer agreement rights, reflecting the full range of corporate authority.

Tier 3: Agreement — "Is this commitment real?"

This tier is unusual because the record itself IS the identity. The IntegraRecordV1 is the permanent, content-addressed anchor for the agreement. Its hash proves the commitment exists. Its resolvers prove what was agreed. Its tokenizer proves who the parties are.

Contract surfaces: contentHash (what was committed), resolvers (enforcement rules), tokenizer (party structure), policy (transfer restrictions). The agreement's identity is its on-chain footprint.

Tier 4: Agent — "Is this agent authorized?"

The newest and most structurally different tier. An agent is not a person or an entity — it is software acting on behalf of a person or entity, with bounded authority that may change between interactions.

Verification methods: Platform attestation (the agent platform vouches for the agent's identity and capabilities), delegation chain verification (proving the chain from human to entity to agent), bounded authority (the agent can negotiate but not commit above a threshold).

Capability level: CORE_VIEW (0x01) — baseline agent capability. Higher capabilities require explicit delegation from Tier 1 or Tier 2 identities.

The Structural Asymmetry

The four tiers are not symmetric. Three of them — human identity, entity attestation, and agent authorization — describe actors: they establish who someone is, on whose behalf they operate, and with what authority. Tier 3 — agreement integrity — describes the commitment itself: the terms, the jurisdiction, the governing law.

This creates a structural asymmetry. The blockchain record is both a trust tier in its own right (the content of the agreement must be independently verifiable) and the binding surface for every other tier. Human credentials, entity attestations, and agent delegations all converge on the record. The record carries them all. Remove the record, and the other three tiers have no shared point of reference. Remove any of the other three, and the record becomes an unattributable artifact — terms without parties, or parties without terms.

For agent authorization specifically, two mechanisms address the actor-bound nature of Tier 4: a per-record executor slot grants access to a specific record, while a cross-record attestation proves what the agent is authorized to do in general. The executor says "can touch this record"; the attestation says "with these bounds." Agents are transient actors — they may be spawned, replaced, or revoked — while the record and its identity bindings persist for the life of the relationship.

The Composition Pattern

Despite the asymmetry, identity at every tier follows the same composition formula:

Identity at any tier =
    Provider           (verify the claim)
  + Attestation        (anchor the proof on-chain)
  + Capability bitmask (scope the authority)
  + Gatekeeper         (enforce at the record boundary)

A human presents a ZK passport proof → a provider verifies it → an attestation is anchored → the gatekeeper checks the attestation before allowing the human to become a record party. An entity presents a vLEI chain → a provider verifies it → an attestation is anchored → the gatekeeper enforces. An agent presents a delegation credential → the same pattern.

The uniformity is the point. The architecture does not have separate identity systems for humans, entities, and agents. It has one composition pattern applied at every tier, with providers swapped below the interface. The provider pattern — stable interface, swappable implementation — is what makes permanent identity fragmentation a solvable engineering problem rather than an architectural crisis.

The Cross-Protocol Bridge

Four commerce protocols created four incompatible identity silos.

Mastercard's Verifiable Intent uses SD-JWT credential chains. Google's Agent Payments Protocol uses Verifiable Digital Credentials with OAuth2. Google and Shopify's Universal Commerce Protocol uses HTTP Message Signatures (RFC 9421). OpenAI and Stripe's Agentic Commerce Protocol uses bearer tokens. An identity verified by one protocol is invisible to the others.

The cross-protocol identity bridge resolves this by separating verification from attestation:

1. Verify off-chain — The identity worker verifies protocol-specific credentials using each protocol's native verification mechanism. A VI SD-JWT is verified against Mastercard's signature chain. An AP2 VDC is verified against Google's credential format. Each protocol's credential is verified in its own language.

2. Attest on-chain — Verified credentials are distilled into a protocol-agnostic EAS (Ethereum Attestation Service) attestation using a 9-field schema. The attestation records what was verified, to what assurance level, by which method — without encoding any protocol-specific format.

3. Enforce uniformly — The IdentityGatekeeperV1 consumes these attestations identically, regardless of which protocol's credential produced them. A human verified via VI's SD-JWT and a human verified via AP2's VDC produce the same attestation format and are enforced by the same gatekeeper logic.

The result: a single identity attestation works across VI, AP2, UCP, and ACP. The capability bitmask encodes what was verified. The identityMetadataHash encodes the verification details without revealing them on-chain. The bridge turns four identity silos into one composable identity layer.

Root of Trust

The identity bridge operates in two modes, with a third as the long-term destination.

Direct Verification

For certain identity types, Integra IS the verifier. ZK passport circuits run Integra's Noir code to verify passport data. SIWE verification validates Ethereum signatures directly. vLEI chain validation follows the GLEIF trust hierarchy independently.

In these cases, the root of trust is straightforward: Integra performed the verification, Integra issues the attestation, Integra is the legitimate root of trust. There is no intermediary whose authority must be borrowed.

Notarial Observation

For commerce protocol credentials — a VI SD-JWT, an AP2 VDC — Integra observes a valid credential from another provider and issues an attestation recording that observation. The root of trust is observational: Integra records what it saw; the original issuer (Mastercard, Google) asserts the identity.

This is weaker than an API call to the original issuer (which carries the issuer's authority directly) but stronger than a database log entry (which is unverifiable by third parties). The identityMetadataHash encodes the original issuer and a reference to the original credential for independent re-verification. But the attestation itself is signed by Integra, not the original issuer.

Issuer-Native Attestation (Destination)

The durable solution is for original issuers to issue EAS attestations directly. Mastercard issues an EAS attestation for a VI-verified identity. Google issues one for an AP2-verified agent. The IAttestationProvider interface is already issuer-agnostic — any authorized issuer can issue attestations that the gatekeeper consumes.

The notarial model is the bootstrap. Direct issuance is the destination. The architecture supports both today.

Why On-Chain Attestations?

The typical enterprise approach to identity is simpler: call an API. When you need to verify a user, call Mastercard's API. Get a response. Move on. Why put identity attestations on a blockchain?

The honest answer is that neither model is universally superior.

API Gateways Excel At

On-Chain Attestations Excel At

The Verdict

The correct architecture uses both. API for operational checks — fast, rich, real-time. On-chain attestations for the durable path — persistence, composability, on-chain enforcement, and evidentiary use.

The commerce protocols handle the transaction moment with off-chain credentials verified via API. Integra handles the agreement lifecycle with on-chain attestations verified by smart contracts. The API handles the fast path. The attestation handles the durable path.

On cost: L2 attestation costs ($0.01 to $0.10) are negligible for trust-establishment events. A $0.05 attestation on a $187,000 equipment purchase is a rounding error. The attestation is issued once and verified many times for free (via eth_call). For a cross-record identity attestation verified by every agreement the user enters, the amortized cost quickly falls below API call costs.

Identity Gatekeeper

The IdentityGatekeeperV1 is the on-chain enforcement point for identity. It gates record interactions based on cross-record attestations verified by CrossRecordIdentityProviderV1.

The same contract is deployed as multiple instances with different capability thresholds:

The critical behavior: the gatekeeper re-verifies the attestation on every canOwn() call. It does not cache results. If an attestation is revoked or expires between the last interaction and the current one, the party is immediately blocked. There is no stale cache, no race condition, no grace period.

This design means identity enforcement is always current. A revoked credential blocks the next interaction — not the interaction after some cache TTL expires. For dispute resolution, where the stakes of a single unauthorized action can be significant, this immediacy is not optional.

The gatekeeper does not track interactions, monitor commerce, or manage disputes. Identity is its only concern. That single responsibility, composed with the other resolvers on the same record, provides the full trust stack.