Privacy Policy for Kantega Lommebok

About Kantega Lommebok

Kantega Lommebok is made by Kantega AS. We provide wallet services to the Norwegian Digitalisation Agency's sandbox for digital credentials: issuance, verification, credential management, and wallets for iOS, Android and the web.

Our solutions are built on the European digital identity standards (eIDAS 2.0 and the EUDI Wallet). The wallets use OpenID4VCI 1.0 for issuance and OpenID4VP 1.0 for presentation, and are built to interoperate with other solutions under the OpenID4VC High Assurance Interoperability Profile (HAIP) 1.0. Our issuer service follows the FAPI 2.0 Security Profile and is tested against the OpenID Foundation conformance suite.

We aim to give the Nordic market high-quality wallet services, from early exploration to production-ready solutions.

Important: Kantega Lommebok is not an approved or certified EUDI Wallet, and the credentials it holds are not valid identification. Do not enter real personal data, and do not use credentials that are valid in the real world.

Want to collaborate, explore digital credentials or build your own wallet? Contact us at post@kantega.no or on kantega.id.

In short

Kantega does not collect personal data about you through this app. Everything the app stores stays locally on your own device. Kantega AS operates no server that receives your credentials, activity log or PIN. We cannot see them and we cannot retrieve them.

Data leaves the device only when you obtain or share a credential yourself — and then it goes to the issuer or verifier you chose, never to us.

The app contains no analytics, no advertising and no advertising ID, and we collect no usage statistics.

We do not recommend using real data in Kantega Lommebok in any way. Do not enter real personal data, and do not use credentials that are valid in the real world.

Who is responsible

Kantega AS is responsible for the app and for this policy. Contact: post@kantega.no.

Because no data from the app ever reaches us, we process no personal data about you as a user of the wallet. If you share a credential, the recipient — the issuer or verifier you chose — is responsible for what they receive, under their own terms.

What the app stores on your device

• The credentials you receive, including the attributes they contain (for example name, date of birth and other attributes).
• Private keys for those credentials, used to sign when you obtain or share a credential. They are generated on the device and never leave it.
• The name you enter during onboarding, used to create a local example credential.
• Your PIN, stored as a salted, one-way key — never as the digits you typed.
• An activity log of what you have received and shared, when, and with whom.
• A diagnostics log of technical protocol events, for troubleshooting.
• Settings, such as language, display preferences and toggles.

None of this is sent to Kantega.

How it is protected on the device

The wallet relies on the security mechanisms the operating system itself provides, not on inventions of our own:

• Keys are held in the device's secure hardware — the Secure Enclave on iOS, the Android Keystore (StrongBox where the device has it) on Android. A key can be used to sign, but it cannot be read out, not even by the app. Credential keys are additionally bound to user authentication, so the device requires Face ID, Touch ID, a fingerprint or the screen-lock code before a signature is produced. Two exceptions are worth knowing about: credentials issued by older versions of the app may have keys without that binding (the credential details show what applies to each credential), and on a device with no screen lock the operating system cannot impose the requirement at all. On iOS the binding covers SD-JWT credentials; the mDoc path uses a library that cannot express the same requirement.
• The PIN is never stored in clear text. It is stored as a salted key derived with PBKDF2-HMAC-SHA256 (210,000 iterations), together with the parameters used. The app also throttles attempts, so guessing is slowed down. The PIN is a convenience lock on the screens; the real protection of the keys is the device's own authentication.
• The contents are not backed up to the cloud. On iOS, credentials and keys are stored so that they exist only on this device, and the activity log is marked to stay out of backups. On Android, backup is disabled for the app, so the contents are copied neither to Google Drive nor across to a new phone.

What leaves your device, and when

Data leaves the device only when you initiate an action:

• When you obtain a credential, the app contacts the issuer you received an offer from and exchanges what the protocol requires in order to issue the credential to you.
• When you share a credential, you see who is asking and which attributes they request, and you choose whether to share. If you do, the selected attributes are sent to that recipient — and only to them.

All such traffic is encrypted (HTTPS/TLS). Kantega does not see this traffic and does not receive your credentials.

Who receives the data

The recipient is the issuer or verifier you choose yourself, by scanning a QR code or opening a link. That is usually the European Commission's public test environments (issuer.eudiw.dev, verifier.eudiw.dev) or test environments at the Norwegian Digitalisation Agency. They process what you send under their own terms — not Kantega.

This is another reason we do not recommend real data: real personal data would then be sent to a test environment, not to an operated service.

Camera

The app uses the camera to read QR codes. Images are processed in real time within the app. No images are stored and no images are transmitted.

Biometrics

Face ID, Touch ID and fingerprint recognition are handled by the operating system. The app asks for a confirmation and receives only “approved” or “denied” in return — never your biometrics, which stay in the device's secure hardware.

Bluetooth and proximity sharing

The standard for presenting a credential to a reader nearby (ISO 18013-5) uses Bluetooth.

• On iOS the feature is available, and Bluetooth is used only when you start such a sharing session yourself.
• On Android the app requests Bluetooth permission because the feature is planned, but it is not in use today, and no data is shared over Bluetooth.

Diagnostics and statistics

The app keeps a local diagnostics log and local operational statistics, both on your device:

• The diagnostics log contains technical protocol events. Content that may be sensitive — tokens, nonces and error response bodies from an issuer or verifier — is masked before it is written. The log never leaves the phone unless you choose to share it from Settings → Diagnostics.
• The statistics count how many issuances, presentations and storage operations succeeded or failed, and which failure type occurred. They contain counters and failure codes, not credential content, addresses or identifiers, and there is no code in the app that sends them anywhere. You can see the same statistics yourself under Settings → Diagnostics.
• The operating system's own crash diagnostics are read into the local log: on iOS via MetricKit (crash, hang and termination diagnostics for the app itself), on Android via the system's record of why the previous process ended (crash, ANR, low-memory kill). This is metadata about the app's process, not about you.

In addition, the platforms give us aggregated crash statistics when you have enabled sharing of diagnostics and usage data in your device settings: “App Store Connect” on iOS and “Android vitals” on Google Play. These are platform features from Apple and Google, you control them in the device settings rather than in the app, and we see only aggregated numbers — never linked to you.

Optional features you switch on yourself

Some experimental features are off by default and contact other services only once you enable them in Settings. The main one is wallet attestation, where the app asks a wallet provider (today the European Commission's test environment wallet-provider.eudiw.dev) to attest that it is a genuine wallet installation. With the switch off, no such contact takes place.

On Android the app can also ask Google Play services for a Play Integrity verdict about the installation. That feature requires a project configuration which is not set in the published app, and is therefore inactive.

How long data is kept, and how you delete it

For as long as you keep it. There are three ways to delete:

1. Delete an individual credential from the credential details.
2. Settings → Reset wallet removes all credentials, keys, the PIN and the activity log from the device. It requires two confirmations and cannot be undone.
3. Uninstall the app, or clear the app's data in the device settings, and everything goes with it.

The diagnostics log is not touched by the reset — the fact that the one irreversible action is recorded is the whole reason the log exists. You clear it separately under Settings → Diagnostics.

Because we hold no copies, deleted credentials cannot be restored — they must be issued again. And because nothing is stored with us, there is nothing at Kantega to request access to or deletion of. If you have sent data to a test environment by sharing a credential, such a request must be directed to whoever operates that environment.

Your rights

You have the rights granted by the GDPR, including access, rectification and erasure. Since Kantega stores no data from the app, these apply in practice towards the recipients you have shared with. If you have questions, contact us at post@kantega.no. If you believe personal data about you is processed unlawfully, you may lodge a complaint with the Norwegian Data Protection Authority (Datatilsynet).

Changes

If we change what the app stores or transmits, we will update this policy and the date at the top.