They are distinct roles with distinct permissions. A wallet provider is not automatically a certificate authority, and a PID issuer is not automatically a relying party. The trust model works only when each entity is registered for the exact function it performs.
How the trust list separates the three roles
A trust list model only works if each participant is registered for the role it actually performs. The wallet provider is the holder and presentation layer for credentials, the issuer vouches for the credential content, and the relying party is the verifier that decides whether to accept it. Those permissions are not interchangeable, even if the same organisation participates in more than one role.
This separation matters because trust is role-specific, not organisation-wide. A provider can operate a wallet without being trusted to issue credentials, and an issuer can sign credentials without being trusted to consume them. The trust list is what makes those boundaries explicit.
Why role separation is the core of the model
The model prevents a common failure where one trusted name is assumed to cover every function. In practice, the wallet provider is responsible for secure storage, user control, and presentation of credentials. The issuer is responsible for creating credentials that other parties can validate. The relying party is responsible for checking evidence and deciding whether to rely on it for access, assurance, or a transaction.
The practical result is that trust must be granted at the right layer. If a wallet provider were treated as a certificate authority by default, or an issuer were treated as a verifier by default, the model would blur issuance, custody, and acceptance. That makes it harder to reason about who can assert, who can present, and who can trust.
For readers working with wallet ecosystems, NHIMG’s Digital Identity, eID and Identity Wallets Guide is the best starting point for the wallet, issuer, and verifier relationship in modern trust frameworks.
How to interpret registration, trust, and verification
Being “on the trust list” means the entity has been approved for a specific function, not for the entire ecosystem. That is why one organisation may appear in more than one place, but each appearance should map to a distinct role and assurance expectation. The same party may publish credentials in one context and verify them in another, but only if it is explicitly registered for both.
For implementers, the key question is whether the trust decision is bound to the role or merely to the brand. Role binding is what keeps wallets, issuers, and relying parties from inheriting permissions they were never meant to have. It also makes audit and policy enforcement possible, because the trust framework can test “who may do what” instead of assuming universal trust across the stack.
For the credential and trust-registry side of the model, NHIMG’s Verifiable Credentials Guide gives the clearest navigation path for issuer, holder, verifier, and trust registry concepts.
Where mistakes usually happen in practice
The most common mistake is collapsing role and reputation into one assumption. A wallet provider may be technically capable of acting as an issuer, but capability is not the same as approved function. Likewise, a relying party may consume credentials from many sources, but that does not make it an issuer or a wallet provider. The trust list exists to stop that role drift.
Another frequent error is treating trust frameworks as static labels rather than controlled registrations. If an organisation changes function, the trust relationship must change with it. Failing to re-register or restrict the role can create false acceptance paths, broken policy enforcement, or overbroad interoperability.
For a standards-based view of the broader trust model, the identity-wallet guidance in eIDAS 2.0, the EU Digital Identity Framework is a useful external reference because it formalises wallet and trust-service roles rather than treating them as interchangeable.
Risk and Threat Considerations
When role boundaries are unclear, the main risk is trust misassignment: an entity is allowed to sign, present, or verify in ways that exceed its approved function. That can lead to false acceptance, fraudulent onboarding, or credential misuse, especially where verifiers assume that a trusted wallet or issuer automatically implies trust in every other role.
Failure mechanism: Role confusion lets an attacker, integration error, or governance gap turn one approved participant into an unintended authority path, so credentials are accepted, issued, or consumed outside the intended trust boundary.
Impact: The result can be unauthorized access, weakened assurance, compromised interoperability decisions, or a trust list that no longer reflects actual security responsibility.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines — Digital Identity Guidelines | Trust-list roles depend on identity proofing, credentialing, and verifier trust decisions. |
| Recommendation — Align issuer and verifier registration to the applicable assurance and federation requirements. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity Management | Role separation requires controlled identities and explicitly assigned trust functions. |
| A.5.17 — Authentication information | Trust list participation depends on protected credentials used to prove and accept role authority. | |
| Recommendation — Define and maintain separate identity roles for wallet providers, issuers, and relying parties. Protect and rotate the credentials that support each trust-listed function. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud trust frameworks need distinct registration and access decisions for each participant role. |
| Recommendation — Register each wallet, issuer, and verifier under the exact IAM role it performs. | ||
Practitioner Guidance
What to verify: Confirm that each listed entity is approved for one explicit function, with separate records for wallet provider, issuer, and relying party where an organisation plays multiple roles. Treat any shared registration as a policy exception that needs clear scope.
Decision rule: If the trust relationship depends on “the organisation is known” rather than “this role is approved,” do not treat the control as sufficient. The registration must match the action being performed, not just the ecosystem participant.
Practitioner takeaway: The safest trust list design is role-bound, not name-bound, because interoperability is only trustworthy when issuance, custody, and verification are governed separately.
Related resources from NHI Mgmt Group
- Who is accountable when a payment trust chain fails across issuers, processors, and wallet providers?
- How does the consumer-secret-entitlement model help with governance at scale?
- How should security teams prevent data exfiltration in AI applications without relying on model output trust alone?
- Why does relying on network location create risk in a zero trust model?