Aller au contenu principal
Version 0.2Brouillon

Privacy and consent

LuxID is a privacy-first identity service. Three principles drive every design choice: data minimisation, explicit consent, and revocability. This page explains how each one shows up in your integration, where the Partner's responsibility starts and LuxID's ends, and how the model maps to GDPR (Regulation (EU) 2016/679 (opens in a new tab)).

Data minimisation​

You declare the Claim Templates your Application needs with LuxID. You can only declare claims that LuxID supports (see Tokens and claims), and you can only request them at runtime if they are attached to the Application.

The principle: only request what your service actually uses. A coffee subscription app does not need birthdate. A delivery app does not need family_name if you already collect a display name from the user inside your product.

This is not a soft recommendation: LuxID reviews and approves each Claim Template attached to an Application before that Application can be activated. The review is part of the go-live gate (see Service provider onboarding). LuxID staff assess whether the declared claims are proportionate to the stated purpose of the Application, and may push back or refuse approval if the claim set looks excessive. This prior-approval model is a deliberate platform design principle - LuxID acts as a privacy guardrail ("garde-fou") between Partners and users, ensuring over-collection cannot happen simply by changing a runtime parameter. At runtime, the scope and claims parameters can only narrow what the client requests from the already-approved superset; they cannot unlock claims outside it.

Two consequences:

  • The consent screen will list each claim. The shorter the list, the higher the consent rate. Removing a claim from the list at any time is allowed; adding one triggers re-consent.
  • The audit story is simpler. If you process less personal data, your retention, breach, and access-request obligations shrink proportionally.

LuxID will challenge over-broad claim requests during the Partner onboarding review. Plan ahead.

The user must accept the LuxID consent screen for every Application on first sign-in. The consent screen shows:

  • The Application name and logo (configured with LuxID).
  • A list of the requested claims with human-readable labels in the user's language (en / fr / de / lb).
  • An "Allow" and a "Cancel" action. Cancel returns error=access_denied to the Application.

Consent is stored per Application and per version of the requested claim set. When you change the Claim Templates attached to your Application (add or remove a claim), the next sign-in re-displays the consent screen. The user's previous decisions for unchanged claims are pre-selected; the new ones require an explicit acknowledgement.

Revocability​

The user can revoke consent for any Application at any time from https://account.luxid.lu/ (opens in a new tab) under Account / Applications. Revocation has three effects:

  • The Subscription is terminated. The next time the user lands at your Application, they sign in as a new user (and if they were the last user in the Sphere, with a brand new sub).
  • The refresh token issued to your Application is invalidated. The next call to the token endpoint with that refresh token returns invalid_grant.
  • A user.consent.revoked event is planned for the Event Hub (today the Event Hub emits only ClaimValuesChanged). Once it is available, you will be able to subscribe to it to clean up local data eagerly rather than wait for the next session check; until then, detect revocation from the invalid_grant returned on the next token call.
Handle revocation gracefully

Your Application must handle revocation gracefully: on invalid_grant, force interactive sign-in. Do not surface technical error pages.

The consent lifecycle:

Sphere choice as a privacy decision​

The Sphere your Application sits in determines whether the user can be correlated across Applications.

  • Two Applications in the same Sphere see the same sub for the same user. They can link their internal records.
  • Two Applications in different Spheres see different sub values for the same user. They cannot tell whether the same person uses both, unless they cross-reference other claims (an email address, a phone number) that the user explicitly released to both.

Choose with care. Putting all your Applications in one Sphere is convenient for a Partner that wants a unified customer view. Spreading them across Spheres is the right call when you want strict separation, for example between a B2C product line and a B2B back office under the same Organization.

You configure the Sphere when you register the Application. Changing it later is a structural change: the existing sub values become invalid in the new Sphere, and your Application is effectively re-created from the user's perspective. Do not migrate Spheres without a strong reason.

See Roles in the ecosystem for the full Sphere model.

GDPR alignment​

LuxID operates exclusively within the EU. Production is in Luxembourg. There are no transfers outside the EEA by default.

Lawful basis​

For each claim you request, identify a lawful basis under GDPR Article 6:

  • Contract (Art. 6(1)(b)): claims essential to delivering your service. Example: email for a service that requires email-based delivery; name for a banking service that legally requires identification.
  • Consent (Art. 6(1)(a)): optional claims that enrich the experience but are not essential. Example: phone_number if you only use it for an optional SMS notification feature.
  • Legal obligation (Art. 6(1)(c)): claims required by law. Example: birthdate and name for an obliged entity under anti-money-laundering rules.

The consent screen presented by LuxID is the user's consent at the identity layer: the user agrees to release the claim to your Application. The lawful basis of your subsequent processing is your own determination and must appear in your privacy notice.

Controller and processor roles​

LuxID is the controller for authentication data: account profile, credentials, MFA methods, audit logs of authentication events, consent records.

When you receive a claim from LuxID and store it in your own systems, you become the controller of that copy. You are then responsible for your retention, access, and security obligations on that copy.

LuxID does not act as a processor on your behalf. The standard relationship between LuxID (POST Luxembourg) and a Partner is controller-to-controller, which is why there is no separate Data Processing Agreement - see GDPR and data protection. This holds for LuxID Pro enterprise federation as well: LuxID and the Partner remain independent controllers.

User rights (articles 15 to 22)​

RightWhere users exercise it
Access (Art. 15)LuxID-held data: https://account.luxid.lu/ (opens in a new tab) -> Privacy / Data export. Partner-held data: with the Partner.
Rectification (Art. 16)LuxID profile: account dashboard. Partner profile: with the Partner.
Erasure (Art. 17)LuxID Account: account dashboard (deletes the LuxID Account; cascades through Subscriptions). Partner data: with the Partner.
Portability (Art. 20)LuxID data export at account dashboard. Partner data: with the Partner.
Restriction (Art. 18)Revoke Application consent at account dashboard.
Objection (Art. 21)Revoke Application consent.

Your Application must handle a Partner-side erasure request by deleting the data your service holds about that user. A user.deleted event - indicating that the LuxID Account itself was deleted by the user - is planned for the Event Hub but not emitted yet; once available, you will be able to treat it as a hard-delete trigger for any data you can lawfully erase.

Transparency​

Your privacy notice must mention the LuxID integration. The expected text is short:

Sign-in to this service is provided by LuxID, a Luxembourgish digital identity service operated by POST Luxembourg. When you sign in, LuxID releases the following information about you to us: [list claims]. You can review and revoke this release at any time at https://account.luxid.lu/ (opens in a new tab). Our processing of this information is governed by [link to your privacy notice].

A reusable template is in Legal agreements and templates.

Retention​

LuxID retains authentication logs for a period defined in the LuxID Agreement and SLA; the exact retention depends on the data category. You manage your own retention for any data you receive.

Refresh tokens issued to your Application have a configured lifetime (about 3 months). LuxID does not retain plain tokens; it stores hashed references for revocation checks.

Breach notification​

If you become aware of a breach affecting LuxID-released data on your side, notify the relevant supervisory authority within 72 hours as required by GDPR Article 33, and notify LuxID at LuxID so the platform can correlate signals.

If LuxID experiences a breach affecting data it holds, you will be notified through the Partner contact list within 24 hours of detection, per the LuxID Agreement. This contractual clock is separate from the statutory 72-hour clock above; see GDPR and data protection.

Children and family accounts​

LuxID does not currently offer family accounts, child accounts, or accounts for minors below the digital consent age. Do not assume the existence of an "age below 16" path. LuxID does not currently release any age signal: the age_over_16 claim exists in the OIDC schema but is not offered today.

Family/child accounts are on the roadmap. See Change management and roadmap.

Cross-references​

Mise à jour le 2026-07-03
Sur cette page