Accepting a credential means relying on evidence presented by a customer or partner. Issuing one means the bank becomes the source of a trusted claim, which creates additional obligations for lifecycle control, revocation, assurance and downstream accountability.
Accepting a Wallet Credential vs Issuing One
Accepting a wallet credential is fundamentally a verification decision: you consume a claim presented by a customer or partner and decide whether it is trustworthy enough for your use case. Issuing a wallet credential is a trust-creation decision: you become the authority behind the claim, so the bar moves from simple verification to lifecycle, revocation, assurance, policy, and accountability.
That difference is easy to miss because both actions involve the same exchange format, but they sit on opposite sides of trust. Acceptance is about how much confidence you need before relying on the presented evidence. Issuance is about what it takes to stand behind the evidence yourself, including proofing, governance, and the operational controls needed to keep that trust valid over time.
For practitioners, the distinction is closer to “consume and evaluate” versus “mint and govern.” When you accept a credential, your main concern is whether the issuer is credible and whether the presentation fits your acceptance policy. When you issue one, you also own the consequences if the claim is wrong, stale, overbroad, or later needs to be withdrawn.
What Changes When the Bank Becomes the Source of Trust?
Accepting a wallet credential lets the bank treat the credential as an external assertion. The bank can validate format, issuer, signature, freshness, and presentation context without taking on responsibility for the full lifecycle of the underlying claim. That makes the control problem narrower: trust the issuer enough to consume the credential, but do not assume ownership of how it was created or how long it should remain valid.
Issuing a wallet credential expands the scope materially. The bank now has to define the trust basis for the claim, decide who or what is entitled to receive it, and maintain the processes that keep the claim current. OWASP Non-Human Identity Top 10 is useful here because the same lifecycle discipline that protects machine and service credentials also applies when an organisation becomes the issuing authority for a wallet credential.
The practical consequence is that issuance is not just an API or product feature. It is a governance commitment. If the bank issues the credential, it needs clear rules for proofing, eligibility, revocation, expiry, re-issuance, and auditability so the credential remains trustworthy after first use.
Lifecycle, Assurance, and Accountability Drive the Real Operational Difference
Accepting a credential usually requires a bounded set of checks, then a decision to rely on it. Issuing a credential requires evidence that the subject really qualifies, that the claim is accurate at the moment of issuance, and that the bank can later update or revoke it when the underlying state changes. That is why issuance creates stronger obligations around lifecycle control and downstream accountability than acceptance does.
RFC 6749: The OAuth 2.0 Authorization Framework is a helpful analogue because it shows how issuance and delegated use are different responsibilities from simple token acceptance. In both cases, the party creating the trust object must be explicit about who can get it, how it is used, and when it should stop working.
OWASP API Security Top 10 also maps well to the operational side of issuance, especially where wallet credentials are delivered through APIs. If the issuing flow is weakly authenticated or improperly authorised, the bank may mint claims it should never have created, which turns an identity decision into a systemic trust problem.
Acceptance and issuance also differ in who absorbs the blast radius. With acceptance, the bank can limit reliance to a specific workflow or service. With issuance, a mistake can propagate across many downstream relying parties because the bank’s credential may be treated as authoritative elsewhere.
Risk and Threat Considerations
Issuing a wallet credential increases exposure because the bank is no longer only verifying trust, it is manufacturing it. If the proofing, authorisation, or revocation process is weak, an attacker may obtain a credential that others will treat as authoritative, and a legitimate user may keep relying on a claim that should already have been withdrawn.
Failure mechanism: The control failure usually appears when issuance is treated as a technical delivery step rather than a governed trust decision. Weak identity proofing, poor revocation handling, or stale status propagation can leave a valid-looking credential in circulation after the underlying entitlement has changed.
Impact: The result can be unauthorised access, false assurance to relying parties, audit gaps, and difficult incident response because the bank has effectively signed the trust object that is now being misused.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Wallet credentials can expose sensitive trust material if issued or handled poorly. |
| NHI-07 — Long-Lived Secrets | Issued credentials need expiry and renewal controls to limit stale trust. | |
| NHI-01 — Improper Offboarding | Issued wallet credentials need revocation when the subject no longer qualifies. | |
| Recommendation — Minimise exposure paths and rotate leaked credential material immediately. Use short-lived credentials and enforce expiry for issued trust artefacts. Revoke issued credentials promptly when eligibility or employment changes. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Issuance flows depend on strong authentication before minting trusted claims. |
| Recommendation — Harden issuance endpoints so only strongly authenticated callers can mint claims. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Issuance requires lifecycle control over credentials, expiry, and revocation. |
| IA-2 — Identification and Authentication (Organizational Users) | Acceptance and issuance both depend on strong identity proof before trust is granted. | |
| Recommendation — Manage credential lifecycle with expiry, revocation, and replacement controls. Require strong authentication before issuing or relying on wallet credentials. | ||
Practitioner Guidance
Decision rule: If the bank is only consuming the credential for a local trust decision, treat the problem as acceptance policy, issuer trust, and validation quality. If the bank is minting the credential, treat it as an issuance programme with lifecycle ownership, revocation authority, and downstream accountability.
What to verify: Before trusting an issuance design, verify that you can answer three questions cleanly: who may be issued the credential, how fast can it be revoked or expired, and how will relying parties know the credential is no longer valid?
Common mistake: Teams often understate issuance risk by assuming wallet credentials behave like ordinary evidence. They do not, because once you issue the credential you inherit the obligation to keep the claim true over time, not just true at the moment of creation.
Practitioner takeaway: Acceptance is a trust check; issuance is a trust commitment. The moment you become the source of the claim, lifecycle control and revocation become part of the security design, not an afterthought.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?