Wallet provider practice statement

1. What this statement is

The Tamga Wallet app is registered with a wallet provider. When an institution issues a credential, the provider gives short-lived wallet attestations that prove the wallet is a genuine Tamga Wallet and say where the credential keys are stored, and it publishes the status lists of those attestations. This page is the public practice statement required by the European standard ETSI TS 119 471: it says what the provider does and how, what it does not do, and where it still falls short.

• The provider is registered in the Tamga Network trusted lists and follows Tamga Network's rules (the Tamga ARF and its wallet attestation policy). Tamga Wallet is not part of Tamga Network; Tamga Wallet operates the provider.
• The provider and the wallet are not certified (no EU certification). This statement is not a certificate or a claim of "EU approval".
• How personal data is processed is in the privacy policy; the terms are in the terms of use.

2. The provider

3. What we issue: wallet attestations

• Format: signed JWT (ES256), following the EU technical specification for wallet attestations and Tamga Network's wallet attestation policy. Only the holder of the bound key can use an attestation (proof of possession).
• Unlinkability: a new key and a new status entry per transaction mean institutions cannot link two transactions of the same wallet through the attestations. The provider gives the mapping between status entries and wallets to no institution and no verifier, and it does not learn which institutions the wallet talks to.
• The key storage level is honest: unless device attestation is verified the level is "software", and the KA says so as iso_18045_basic. The phone's own claim is ignored.
• Revocation maintenance period: client_status.exp in the WIA and key_storage_status.exp in the KA are normally 60 days; if the issuing institution asks for longer, up to 730 days (at least 31 days). The provider commits to publishing its status lists for that period.
• Daily limit per wallet against abuse: at most 50 WIAs and 200 KAs (UTC day).

4. Wallet registration and device attestation

• On setup the app generates a random wallet unit key and sends the provider a registration signed with it. No account, name, phone number, email or device identifier is asked for.
• Device attestation: on Android, Google hardware key attestation (root certificates and Google's revocation list, refreshed at least every 24 hours); on iPhone, Apple App Attest. Play Integrity is optional (not mandatory today). Only the result is kept (are the keys in the secure chip); no device identifier is stored.
• Hardware only: the provider issues WIAs only to wallets whose device attestation is verified (keys in secure hardware). A phone without it can register but cannot receive credentials. iPhone support opens once the Apple developer registration is complete; until then an iPhone registration gets the answer "iOS not supported yet".
• Acceptance of the terms of use: the terms are shown in the app before the wallet is created and accepted by a deliberate action. The evidence holds no personal data: on the phone the accepted version and time; at the provider the version and registration time written into the wallet's record. It is kept with the wallet's record and deleted with it.
• Security signals: the daily WIA renewal carries the app version, the operating system's major version, the Android patch month and the integrity result. An app below the minimum supported version gets no WIA ("Update"). If integrity is critical twice within 24 hours the wallet goes to review by a person; there is no automatic revocation.

5. Keys

• The provider has one signing key: ES256 (P-256). It signs only WIAs, KAs and the provider's own status lists, and is used for nothing else.
• The key was generated on the server when the server was set up. Its certificate follows the ETSI TS 119 412-6 profile (organisation identifier VATTR-1870632151 in the subject, wallet-provider type), is valid for 3 years and is bound to the TAMGA-WP-1 entry in Tamga Network's trusted lists. The fingerprint is published on the provider information page.
• Today the key is in a file on the server that only the provider service can read; it is also in the encrypted backups and in an encrypted copy off the server (§9).
• Known deviation (closed before the pilot): the European standard asks for the signing key to be kept in a certified hardware security module (HSM) or an equivalent cloud key service, and generated in a documented key ceremony with at least two people present. Tamga Network allows this deviation in its list phase; before a pilot with real people the key moves to an HSM or certified key service and a ceremony report is kept.
• Key changes (expiry or suspicion) go through the entry at Tamga Network: the new certificate enters the list and the old key is retired.

6. Revocation

When a wallet is revoked, the provider gives it no new WIA and marks every WIA entry it issued as "invalid" in the status list. A revoked wallet cannot register again.

• The reason comes from a closed list: the person's request · the phone's security is broken · a flaw in a secure hardware type · a flaw in an app version · a flaw in the identity scheme.
• Impartiality: a revocation decision rests only on the security criteria above; no commercial relationship with an institution or customer influences it. Every provider decision is written to an internal audit record with who decided, the reason and the scope.
• Notice: within 24 hours of a provider revocation, independently of the wallet — on the My wallet status page (provider.tamgawallet.com/check), opened with the revocation code: the reason, the date and what to do; if several wallets are affected, on the Security advisories page. The app also shows the reason when it opens.
• Revoking the wallet does not revoke credentials institutions have already issued (Tamga Network's rule); each institution revokes its own credential under its own rules.

7. Status lists

• WIA lists at provider.tamgawallet.com/status/wia (and, after a list fills, new lists with opaque identifiers, /status/wia/<id>); the KA list at /status/ka. Format: IETF Token Status List; the list token is signed with the provider's key on every request and may be cached for at most 1 hour.
• Every list has at least 100,000 entries (EU minimum 10,000). The active list is sealed at 80% and a new list opens; entries are never reused. A sealed list is published until its longest maintenance period + 30 days has passed, then closed.
• Anyone can read the lists; they do not say which entry belongs to which wallet.

8. Records we keep and for how long

• IP addresses are not passed to the application and not logged. Rate limiting keeps the IP in memory only. The server's critical error log may contain an IP; it is deleted after about 24 hours.
• The provider passes wallet data to no other service, does not sell it and does not match it with institutions.

9. Security, access and backups

• All endpoints only over TLS; the server accepts only ports 22/80/443, unused services and ports are closed. The service runs under its own user in a strict system sandbox; internal operation endpoints are closed to the outside.
• Access: the server is reached only with an SSH key (password login disabled, attempt limits and automatic bans). Every operational account that can reach the signing key or cause attestations to be issued requires multi-factor authentication (server, hosting, domain and code accounts); unauthorised login attempts are recorded on the server.
• Backups: an encrypted (AES-256) backup every night; 14 days on the server; an encrypted copy off the server at least weekly; the backup key kept separately. Restoration is rehearsed monthly and whenever the key changes. Backups are mandatory because revocation can only be preserved with these records.
• External services used: hosting (server, Germany), domain management, TLS certificates (Let's Encrypt), Apple's and Google's root certificates and Google's key attestation revocation list for device attestation; Google's verification service if Play Integrity is turned on.

10. Incidents and vulnerabilities

• If you find a vulnerability: security@tamgawallet.com. Details on the Security page.
• A critical incident is reported to Tamga Network (the scheme owner) within 4 hours, a high-severity incident within 24 hours.
• If the signing key is compromised: Tamga Network is informed and the key is suspended in the trusted list; every affected WIA and KA entry is revoked; people are told outside the wallet (Security advisories, My wallet status); the service is set up again with a new key.
• If a flaw is found in an app version, wallets below that version get no WIA ("Update") or, if needed, the version range is revoked (§6).

11. Known deviations

Where today's operation differs from the European standard (ETSI TS 119 471), it says so:

• The signing key is not in an HSM and there is no ceremony report — closed before the pilot (§5).
• WIA/KA issuance events are not kept in a separate event log: there are only the WIA entries needed for revocation in the wallet record and the IP-free server log (14 days).
• A small team runs the service today; segregation of duties and trusted roles are written down before the pilot; a written risk assessment and information security policy are in preparation.
• KA revocation is one shared entry per key storage type (not per key).
• The provider and the app are not certified.

12. If the service ends

If Tamga Wallet decides to close the provider, a written termination plan applies:

1. Advance notice: at least 3 months before closing, Tamga Network and the issuing institutions are informed; people are told through a security advisory and a banner on this site (reminders 1 month and 1 week before). The app is removed from the stores 1 month before closing.
2. Closing day: new registrations, WIAs and KAs stop; all active wallets are revoked (with an advisory). Credentials on the phone are not deleted and can be presented while they are valid; no new credentials can be received. You can get your credentials again from the institutions into another EU-compatible wallet; the app's transfer file lists which credential comes from which institution.
3. The lists continue: status lists are published until the maintenance period of the last attestation issued (at most 730 days) + 30 days has passed, or handed over to a successor with Tamga Network's approval. Final state: every WIA entry revoked; key storage type entries unchanged.
4. Data deletion: crash reports and aggregate counts on the closing day; wallet records 30 days after closing; revocation traces and the lists when list publication ends. The signing key and all its copies are destroyed, with a record, when list publication ends.

13. Changes

This statement is updated when the provider's operation changes; the version and date are at the top of this page. Important changes that affect people are announced on this site.