What it takes to issue a credential a bank will accept

Any system can print a QR code onto a certificate. The question a bank's compliance officer asks is different: who issued this, were they entitled to, has it been revoked since, and can I prove to my regulator that I checked.

Three things a relying party needs

An issuer it can resolve. The credential has to name its issuer in a way that resolves to a key the relying party can verify, without a private agreement between the two institutions. That is what a trust registry is for: a published, signed list of who may issue what. Without it, every new relying party is a bilateral integration project.

A revocation answer that does not leak. Revocation checking is where privacy quietly fails. A naive design has the verifier ask the issuer "is credential 4471 still valid?", which tells the issuer exactly who is checking on whom and when. Status lists solve this: the issuer publishes a compressed bitstring, the verifier downloads it and reads one bit. The issuer learns nothing.

Selective disclosure that survives a lawyer. A bank opening an account usually needs to know that the holder is over eighteen and resident at a given address. It does not need a full copy of a birth record. Credentials that support selective disclosure let the holder prove the predicate instead of handing over the document — and, crucially, let the bank keep an auditable record of what it verified rather than a copy of what it was shown.

Where implementations usually go wrong

The common failure is treating the wallet as the product. The wallet is the least interesting component; it is a view over keys. The hard parts are the issuance pipeline that binds a credential to a verified identity in the first place, the registry that tells the world which issuers count, and the operational question of what happens at three in the morning when a signing key is compromised.

The second failure is designing for the online case only. In much of the world a verification happens where connectivity does not. That forces design decisions early: offline-verifiable signatures, cached status lists with a stated maximum age, and an explicit rule for what a verifier does when the cache is stale — refuse, or accept and flag. That rule belongs in policy, written down, not in a developer's judgement at the counter.

What this means for a national programme

A credential scheme is governance with a technical appendix. The specifications are largely settled and interoperable; what is not settled, in any given country, is who may issue, who may verify, what a verifier may keep, and who answers when a credential is wrong. Those questions take longer than the software and they cannot be delegated to the vendor. The useful thing a technology partner can do is make the answers configurable rather than hard-coded, and hand over the configuration along with the source.