Trust Networks

Signature verification tells you a credential is authentic and untampered — but not whether the issuer is someone you should believe. Anyone can generate keys and sign a credential claiming anything. A Trust Network answers the question signatures can't: which issuers does this verifier trust, and for what?

What a trust network is

A trust network is a governed registry of organisations — issuers and verifiers — that have been vetted and admitted by the network operator (iDen2 or a delegated governance body). Membership, not cryptography alone, is what makes a credential trustworthy.

The identifiers you'll see

Field	Where it appears	What it means
trustNetworkId	VerificationSession	The trust network your verification belongs to. Your configuration is bound to one network.
verifierMemberId	VerificationSession; inside client_metadata in the authorizationUrl	Your identity (URN) as a verifier in the network. Holder wallets use it to look up and display your organisation's name and logo on the consent screen — so holders know who is asking.
issuerMemberId	verificationResult	The identity of the issuer whose credential was presented. Use it to apply issuer-specific business logic.

Note that verifierMemberId is distinct from the client_id query parameter in the authorizationUrl: client_id is an internal value used for KB-JWT audience validation, while verifierMemberId is your trust network identity used for display and trust lookup. See the Verification Integration Guide.

How trust is established

1. Onboarding — an organisation applies to join the network and is vetted by the network operator.
2. Registration — once admitted, its identity (member ID, display metadata, signing keys/DIDs) is recorded in the network registry.
3. Issuance — credentials issued by a member embed the member's signing identity.
4. Verification — when a credential is presented, Verification Gateway resolves the issuer's signing identity against the registry. If the issuer is a member in good standing, verificationResult.issuerTrusted is true; otherwise the session fails with failureReason: "issuer_not_trusted".

Trust is therefore transitive through the network, not bilateral: you never exchange keys or contracts with individual issuers. Joining the network is what establishes mutual trust with every other member.

What this means in practice

• A failed session with issuer_not_trusted is not a bug — the holder presented a structurally valid credential from an issuer outside your network. If you believe that issuer should be trusted, contact iDen2 to suggest their inclusion in the trust network. In the end, it is up to the verifier to decide whether to trust the issuer, however.
• issuerTrusted: true tells you membership; combine it with signatureValid and revocationStatus before granting access (Security Best Practices).

Where to go next

• Credential Registry — the companion component: is a trusted credential still valid?
• Architecture: Trust Network — how the registry fits into iDen2's architecture
• OpenID4VP — where trust checks happen in the verification flow