Engineering · 2026-05-31

Credential Chaining: Deriving Trust from a Sequence of Issuer Attestations

By J. W. Bouckaert

A single credential is the wrong unit of trust

A verifiable credential answers exactly one question: did the issuer name in this object sign the claims it contains, and is the holder presenting it the subject those claims refer to. That is a strong cryptographic fact. It is also a narrow one, because most real authorization decisions—a high-value transfer, a regulated account opening, an agent acting on behalf of a principal—depend on the joint truth of several questions, each of which a different issuer is in the best position to answer.

A government does not know whether the SIM in your phone was swapped twelve minutes ago. A carrier does not know whether the device hosting your passkey is the same device that bound it. A FIDO authenticator does not know whether the legal identity the relying party thinks it is binding to is the same legal identity a state authority issued. Each issuer holds one slice of the picture, and the verifier's job is to compose those slices into a single decision.

Credential chaining is the composition layer. It treats issuer attestations as nodes in a directed graph, and the binding from one credential to the next as an edge that the verifier checks before it trusts the graph as a whole.

The rest of this piece is the model, the wire format, and the verifier algorithm PasskeyBridge uses to do this. It assumes familiarity with the W3C Verifiable Credentials Data Model 2.0 and the SD-JWT-VC wire format, one of the two credential formats the EUDI Wallet Architecture and Reference Framework adopts (the other being ISO/IEC 18013-5 mDoc).

The three-link chain in practice

The canonical PasskeyBridge chain for a high-assurance transaction has three links. The numbering matters; each link binds to the one before it.

The shape is intentional. Link 1 is heavy and slow-changing; it is what a regulator points at. Link 2 is light and fast-changing; it is what catches a SIM swap that happened between the last login and this one. Link 3 is ephemeral and per-ceremony; it is what proves a human rather than a script is on the other end of the line.

For the security properties of the individual links, see our earlier pieces on why passkeys alone are not enough without carrier signals, the carrier signal freshness model, and the zero-PII architecture the binding hashes ride on top of.

A directed graph rather than a list

A list implies a single linear path. The real shape is a directed acyclic graph because some links cite more than one parent. A typical example: a carrier attestation may need to chain to both the government ID VC (for subject binding) and to a separate device-attestation credential issued under WebAuthn Level 3 (for the hardware the SIM is sitting in). The verifier walks the graph from the root attestations down to the leaf assertion, and the check at every node is the same.

            ┌──────────────────────┐
            │  Government ID VC    │   ← root attestation, signed by state issuer
            └──────────┬───────────┘
                       │
            ┌──────────▼───────────┐
            │  Carrier Attestation │   ← binds to hashed subject of root
            │       VC             │
            └──────────┬───────────┘
                       │
            ┌──────────▼───────────┐
            │  Passkey Assertion   │   ← signed by key enrolled under link 2
            │      (per-ceremony)  │
            └──────────────────────┘

The acyclic constraint is what makes the verifier terminating. A cycle would mean two credentials each claiming the other as a parent, which is meaningless under VC semantics and is a fast rejection at parse time.

The binding edge: How a credential cites its parent

The interesting part of chaining is the edge that connects two credentials. There are three competing mechanisms in the field, with different trust properties:

1. Subject-identifier hashing. Credential N+1's credentialSubject contains a hashed identifier that matches a salted hash inside credential N. This is the model PasskeyBridge uses, because it preserves the zero-PII property of the wider stack: the verifier never sees a plaintext government ID, only a hash that two issuers independently computed against the same canonical subject.
2. Linked Data Proofs. Credential N+1's proof block cites credential N's id URI directly. Simple, but it leaks the credential identifier and assumes both credentials are resolvable to the verifier, which fails the moment a credential is held privately in a wallet.
3. Signed presentation envelope. The wallet wraps both credentials in a Verifiable Presentation that is itself signed; the binding is implied by the presentation rather than the credentials. Acceptable when the wallet is in the trust framework, weaker when the wallet is just a transport.

The subject-identifier-hashing model is also what makes the chain resilient under Schrems III data residency constraints: the verifier evaluates a chain of hashes, never a chain of personal data.

The verifier algorithm

The verifier executes five stages in order. Any stage failing rejects the chain; the reason for rejection is part of the structured explanation returned to the policy engine.

1. Parse. Decode each credential to its canonical form (SD-JWT-VC selective-disclosure form is the wire format here; JSON-LD VCs are normalised via JCS before signature verification).
2. Topology check. Confirm the graph is acyclic, that every cited parent is present in the presentation, and that the leaf is the assertion the relying party actually requested.
3. Cryptographic chain check. For each edge: verify the child's signature against the issuer's published key (resolved via did:web for institutional issuers, via the eIDAS 2.0 trust list for state-issued credentials), then verify that the binding from child to parent is well-formed under the chosen edge mechanism.
4. Freshness check. For each node, compute now - issuance and reject any node whose TTL has expired. The TTL is encoded in the credential's validFrom / validUntil for long-lived links and in a status credential for short-lived ones; see StatusList2021 vs accumulators for the trade-offs.
5. Composite scoring. Aggregate per-link confidence scores into a single decision. The weights are policy-driven and tenant-configurable; the default profile favours legal-identity strength on KYC paths and freshness on transaction paths.

The verifier emits not a boolean, but a structured decision object: the composite score, the per-link contributions, the reason for any downgrade, and a hash of the exact graph that was evaluated. The hash is what makes the decision auditable; a regulator asking "what did the verifier see?" can recompute the same hash from the same presentation and confirm the answer.

Composite scoring: A worked example

A representative weighting on a high-value transaction path:

The aggregator is not a simple weighted sum. Each link contributes only if its predecessor in the chain also contributes; a missing carrier link does not just zero its own term, it suppresses the passkey term as well, because a passkey enrolled under a SIM that has since swapped is no longer a meaningful binding. This is the multiplicative property that distinguishes a chain from a set—and it is what a flat presentation-exchange aggregation cannot express.

For policies that need a single number, the output is normalised to 0–100; for policies that need a structured decision, the per-link object is what gets passed downstream. The identity threat response playbook engine consumes both forms.

Provenance: The audit trail each chain carries

Every chain evaluated by the verifier produces an audit record with four fields, none of which contain plaintext personal data:

• graph_hash: SHA-256 over the canonical JCS representation of the directed graph that was evaluated.
• issuer_dids: the set of issuer identifiers (as resolved DIDs) that participated in the chain.
• per_link_decisions: the structured result for every node, including any TTL downgrades.
• composite: the final score and the policy version that produced it.

The same record is the substrate for cross-tenant trust sharing in our A2A trust negotiation model. An agent that has been issued a chain by one tenant can present the chain hash to a counterparty, who can re-resolve the issuer DIDs against the same trust frameworks and recompute the same composite without needing the original presentation.

Against a single larger credential

A reasonable objection: why not have the government issuer sign a credential that includes the SIM identifier and the passkey credential ID, and skip the chain entirely? Three reasons.

1. Separation of issuance authority. The government cannot speak for the carrier; the carrier cannot speak for the device. Forcing one issuer to vouch for what another issuer alone can attest is exactly the trust collapse that VC-based architectures exist to prevent.
2. Different freshness models. A single credential has a single TTL. A chain lets each link expire on its own schedule, which is what makes a long-lived legal identity coexist with a short-lived carrier signal in a single decision.
3. Selective disclosure cleanly per-link. SD-JWT-VC's selective disclosure works on a single credential. A chain lets the wallet disclose only the claims each verifier actually needs from each issuer, which is the privacy property the EUDI Wallet's data-minimisation requirements ultimately turn on.

Failure modes the chain catches that a single credential misses

The interesting argument for chaining is not that it adds links, but that it catches specific failure modes that a single credential cannot:

• Stale carrier signal under valid government ID. A government ID VC is still valid; a carrier attestation has expired. The chain downgrades. A single-credential model that included the carrier signal in the government VC would not have noticed.
• Passkey enrolled under a different SIM than the one now active. A SIM swap between enrolment and assertion breaks the binding from link 3 to link 2 without invalidating either credential in isolation. The chain rejects; a flat set does not.
• Issuer revocation cascading. A carrier withdraws an attestation issuer's key. Every chain that included a credential signed by that issuer is automatically downgraded at next freshness check, without any per-chain notification. See our piece on revocation cascade for the operational details.

Position in 2026

Credential chaining is not a new invention; the W3C VC Data Model has always allowed credentials to cite other credentials. What is new in 2026 is the combination of (1) widespread wallet support for SD-JWT-VC and selective disclosure, (2) the eIDAS 2.0 implementing acts reaching their formal milestones, and (3) the carrier-side identity APIs converging on GSMA Open Gateway and CAMARA. The infrastructure to issue each link of a multi-issuer chain exists in production; the verifier-side composition layer is what closes the loop.

For PasskeyBridge, the chain is the unit of trust the verifier evaluates, the audit record exposes, and the policy engine acts on. The three-link composition is the default; the graph is general, and richer chains—delegated agent credentials, non-terrestrial trust anchors for satellite-served sessions, physics-anchored settlement tokens for high-value transactions—plug in as additional nodes without changing the verifier's algorithm.

A single credential answers one question. A chain answers the one that the relying party actually has to act on.

Start free · Test the API