How do you trust a wallet? Attestations and hardware keys

An institution trusts a wallet through a chain of signed evidence, not through the wallet's own word. The wallet's provider must be listed in Tamga Network's signed trust list. For each credential request the provider hands the wallet two short-lived, signed statements: a wallet instance attestation (WIA) saying "this is a genuine, unrevoked installation of our wallet", and a key attestation (KA) saying where the credential keys live. The provider may only claim hardware storage it has verified from the phone platform's own evidence, Android key attestation or Apple App Attest. The institution checks all of this against the trust list before it issues anything. The network itself runs no wallet; it lists wallet providers.

Why does an institution care which wallet it issues to?

A Tamga credential is bound to a key on the person's device. Whoever holds that key can present the credential. If the key sat in ordinary app storage, it could be copied together with the credential to another phone, and the credential would no longer prove much. If the app were a modified copy, it could skip the consent screen or keep presentations it should not keep.

So before signing a diploma or an identity credential, the institution wants answers to three questions. Is this a wallet that follows the network's rules? Is this particular installation still in good standing? Are the keys it wants me to bind to really in secure hardware? The EU framework asks the same questions and answers them with the same two attestations, described in the Commission's technical specification TS3. Tamga follows that model (ADR-0025).

Who vouches for what?

Each link vouches only for what it can actually see:

1. The phone platform (Google's hardware attestation root, Apple's App Attest root) vouches that a key was generated in the device's secure hardware and that the request comes from a known app.
2. The wallet provider verifies that evidence once, when the installation registers, and from then on signs attestations for that installation.
3. The trust list names the wallet provider and its signing certificate. Without an active entry, the provider's attestations count for nothing.
4. The institution's issuer checks the attestations, binds the credential to the attested keys and signs it.

The network sits in the third link only. It writes the rules every provider must follow and publishes the list; it does not register phones, sign attestations or hold any device data.

What is in a wallet instance attestation?

A WIA is a signed JWT in the format of OpenID4VCI 1.0 Annex E. The fields come from TS3:

{
  "iss": "https://provider.wallet.example",
  "sub": "example-wallet",
  "wallet_name": "example-wallet",
  "wallet_version": "1.0.0",
  "wallet_link": "https://wallet.example/",
  "client_status": {
    "status": { "status_list": { "idx": 7341, "uri": "https://provider.wallet.example/status/wia" } },
    "exp": 1797000000
  },
  "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "…", "y": "…" } },
  "iat": 1791800000,
  "exp": 1791882800
}

Three details carry most of the privacy:

• sub is the same on every phone. It names the wallet solution, not the installation. The HAIP 1.0 profile requires this, and Tamga adopted it (ADR-0034).
• It lives less than 24 hours (23 hours in Tamga).
• Every credential request gets a fresh one, with a new proof-of-possession key in cnf and a new, unlinkable position in the provider's status list. A WIA is never reused for a second institution. Two institutions comparing notes cannot tell that the same phone talked to both, and the provider does not learn how many institutions a wallet deals with.

The installation's own long-term key, the unit key, is used only between the wallet and its provider. It is never shown to an institution.

What does a key attestation add?

The WIA says the installation is genuine. The key attestation, a separate JWT in the format of OpenID4VCI Annex D, says something about the keys a credential will be bound to:

• attested_keys: every key in a batch, since every credential is issued as 10 copies and each copy has its own key;
• key_storage and user_authentication: the storage and user-verification levels, in the ISO 18045 terms TS3 uses;
• key_storage_status: a status list entry the provider can revoke.

The status entry is deliberately coarse. There is one shared entry per storage type (software store, Secure Enclave, StrongBox), the first option TS3 allows. If one type of storage turned out to be broken, the provider could withdraw it for everyone at once, and the key attestation reveals nothing that identifies the installation. Each key appears in exactly one key attestation, each key attestation is used once, and the attestation travels in the header of the wallet's proof to the institution.

The rule that keeps this honest is WIA3: the storage level in a key attestation states the truth, and an unverified claim is never written into one.

How does the provider know a key is in hardware?

From the platform's signed evidence, never from what the app says about itself (wallet guide §4):

Until the evidence is verified, the installation counts as software level. The network's wallet rules then decide what that means. Wallets are graded W1 (software keys), W2 (the device's secure area: Secure Enclave or StrongBox) and W3 (a certified secure element, for the state phase). W2 is the minimum. A software-key wallet is not supported; the only exception is the network's own test key in the sandbox list, used for its demonstration scenes (rule WL3).

Hardware keys are also tied to the phone lock. A credential key can be used only while the phone is unlocked, and each presentation is approved with the device's biometrics or passcode (rule WL11).

On Android, a provider may additionally send a Play Integrity verdict, which shows that the app came from the store. Today it is optional: it never lowers the level taken from the key attestation and its absence does not block registration. Making it mandatory would change the decision and needs a separate decision record.

What does the institution check before it issues?

At the authorisation and token endpoints the issuer verifies the WIA: its signature, that the signing key belongs to a wallet provider whose entry in the trust list is ACTIVE, its validity period, the proof of possession of the cnf key, and that client_status is not revoked.

At the credential endpoint it verifies the key attestation: its signature and provider key, that the wallet's proof was signed with the first attested key over the issuer's fresh nonce, that key_storage_status is not revoked, and that the storage level meets the institution's own minimum. Only then does it sign, binding each copy to one of the attested keys. An issuer never issues against a revoked WIA or key attestation (rule WIA4). The protocol view of these steps is in the OpenID4VCI deep dive.

One transition is written down openly: until the pilot, an issuer also accepts a wallet proof without a key attestation. That path is removed at the pilot.

How is a wallet, or a whole wallet product, withdrawn?

There are three levels, from narrow to wide:

Credentials already on a phone are separate from this: they are withdrawn by the institutions that issued them, through their own status lists. Revoking an installation stops it from obtaining new credentials.

Withdrawing a lost or stolen phone remotely needs some way for the person to prove who they are without that phone. The decision leaves this to a later step.

Why doesn't Tamga Network run wallets?

Because a network that ran a wallet would be judging its own product. In the EU model each wallet is operated by the organisation that offers it, and the trust framework only lists wallet providers. Tamga Network follows the same split (ADR-0042):

• the network operates no wallet app, wallet provider or wallet website, and no wallet service runs under the network's domain names;
• it recognises a wallet only by its entry in the trust list, which any provider can obtain by following the published rules;
• its interfaces and packages do not hard-code any wallet's name;
• there is one sandbox, and it belongs to the network: a wallet developer runs their own provider and registers it in the sandbox list.

Tamga Wallet is one of the wallets on the network. It is a separate product and enters the list the same way as any other. On 8 October 2026 its provider (TAMGA-WP-1) has one entry in the production list and the same entry in the sandbox list, both RESERVED: the place is held, but the entry carries no signing key until the wallet's operator supplies its own certificate, so no attestation can pass against it yet. The sandbox list also contains the network's own test provider for its scenes. Registration is done by hand today, with project management approval; self-registration of wallet providers needs a separate decision.

What are the honest limits today?

• Device testing is still ahead. Hardware keys and device attestation are implemented; testing on real devices comes with the app-store release (ARF §2.8).
• No active wallet provider in the production list yet. The only entry is reserved, as described above.
• Play Integrity is optional, and the transition that accepts proofs without a key attestation lasts until the pilot.
• Remote withdrawal of a lost phone waits for a later step.
• No certified secure element yet. W3 belongs to the state phase.
• Attestations prove the software and the keys, not the person. Who the person is, is a separate question answered by identity verification at the institution.

Frequently asked questions

Can any wallet join Tamga Network?

Any wallet whose provider follows the published rules and passes the conformance tests can be listed. The network recognises wallets by their trust list entry, not by name.

Does the wallet provider learn which institutions I use?

No. Each credential request uses a fresh attestation with a new key and a new status position, so the provider does not see how many institutions a wallet talks to, and institutions cannot link the same phone across each other.

What happens if my phone has no secure hardware?

The installation stays at software level, and the network's rules do not support software-key wallets for real credentials. The wallet should tell the person clearly instead of continuing silently.

Can a wallet product be removed from the network?

Yes. The registrar can suspend or revoke the provider's entry in the trust list, and from that moment its attestations no longer pass at any issuer.