Aller au contenu principal
Version 0.3Brouillon

Attribute enrichment

Not generally available

Attribute Enrichment is not currently offered. The enriched attributes described on this page (age brackets such as age_over_16 / age_over_18, residency signals, postal address, verified professional attributes) are not released today and are not advertised in the discovery document. Treat this page as a roadmap and confirm availability with LuxID before designing against it.

What is attribute enrichment?​

Attribute Enrichment allows Partner applications to request optional identity attributes beyond the standard OIDC profile claims.

These enriched attributes go beyond name, email, email_verified, and similar standard claims. They provide additional context about the user - their organisation affiliation, age bracket, residency, postal address, or verified professional attributes - without requiring the Partner to collect or verify this information independently.

Each enriched attribute requires explicit, granular user consent at the time the attribute is first requested. Users can review and revoke consent for individual attributes in their LuxID Account (opens in a new tab).

Design principles​

Explicit consent per claim. Enriched attributes are never shared without the user's active consent. LuxID presents a granular consent screen that lists each requested attribute individually, allowing the user to grant or decline each one separately. A user can grant access to their age bracket but decline to share their postal address, for example.

Data minimisation. Several enriched attributes are designed to be more privacy-preserving than their underlying data. Age brackets (age_over_18) expose less information than an exact birthdate. Residency signals (lu_resident) expose less than a full address. Use the least-identifying attribute that satisfies your use case.

Consent is revocable. Users can withdraw consent for any enriched attribute at any time via their LuxID Account (opens in a new tab). If consent is revoked, the affected claim will be absent from subsequent tokens. An user.consent.revoked event is emitted to the Event Hub.

Enriched attribute catalogue​

Organisation affiliation​

When available: Only for users who authenticate via a LuxID Pro enterprise federation. Not available for standard consumer LuxID Accounts.

Claim: luxid_organization

Format: a string carrying the organisation name or identifier the user federated through. It is paired with the luxid_federation_realm claim.

{
  "luxid_federation_realm": "post.lu",
  "luxid_organization": "POST Luxembourg"
}

Use cases: Personalising the application experience for enterprise users; routing users to organisation-specific features; access control by organisation.

Privacy note: Organisation affiliation is sourced from the corporate IdP assertion. The organisation (as data controller) controls what it releases to LuxID.

Age brackets​

When available: For users who have completed LuxID Verified identity proofing (which confirms birthdate). Not available for unverified accounts.

Claims: age_over_16, age_over_18, age_over_21

Format:

{
  "age_over_16": true,
  "age_over_18": true,
  "age_over_21": false
}

Each claim is a boolean derived from the user's verified birthdate. The exact birthdate is never shared.

Use cases:

  • Age-restricted content platforms (18+)
  • Services with minimum age requirements (16+ for GDPR consent capacity)
  • Alcohol and tobacco sales (21+ where applicable)
  • Any service requiring age confirmation without needing the exact date of birth

Privacy note: Age bracket claims are significantly more privacy-preserving than sharing a birthdate. Request only the specific bracket(s) your application requires. Do not request all three if your use case only needs age_over_18.

Dependency: Requires luxid_verified: true on the user's account. If the user is not verified, these claims are unavailable and LuxID will inform the user they need to complete identity verification.

Luxembourg residency signal​

When available: For users who have provided and consented to share their postal address, where the address can be confirmed as a Luxembourg address. Explicit consent required.

Claim: lu_resident

Format:

{
  "lu_resident": true
}

lu_resident: true indicates that the postal address on file for the user is in Luxembourg. lu_resident: false indicates a non-Luxembourg address. The claim is absent if the user has not provided an address or has not consented to residency signal sharing.

Use cases:

  • Services with Luxembourg-resident eligibility requirements
  • Regional offers or pricing applicable only to Luxembourg residents
  • Regulatory compliance for services limited to Luxembourg residents (e.g. certain financial products)

Privacy note: Residency is derived from the user's self-declared postal address. LuxID does not independently verify residency status with public authorities. If regulatory compliance requires confirmed residency, additional verification steps may be needed. Treat lu_resident as a convenience signal, not a legal confirmation of domicile.

Consent required: The user must explicitly consent to residency signal sharing. LuxID presents this as a distinct consent item separate from sharing the full postal address.

Postal address​

When available: For users who have added their address to their LuxID Account (opens in a new tab). Explicit consent required.

Claim: address (standard OIDC address claim, OpenID Connect Core §5.1.1 (opens in a new tab))

Format:

{
  "address": {
    "street_address": "12 Rue de la Poste",
    "locality": "Luxembourg",
    "postal_code": "L-2090",
    "country": "LU"
  }
}

Use cases:

  • Pre-filling delivery address in e-commerce flows
  • Billing address for financial services
  • Correspondence address for regulated services

Privacy note: Postal address is personal data requiring explicit consent per GDPR Article 6(1)(a). Only request this claim when your application has a clear, stated purpose for the address. Do not collect postal addresses speculatively.

Request: the address claim must be in your Application's Claim Template. Send a spec-valid scope (the address scope is conventional but does not by itself gate release) - the example below shows a typical request:

GET https://login.luxid.lu/mga/sps/oauth/oauth20/authorize
  ?client_id=<your_client_id>
  &response_type=code
  &redirect_uri=<your_callback>
  &scope=openid profile email address
  &state=<state>
  &nonce=<nonce>

Full example: enriched ID Token​

A user who has consented to share their organisation, age bracket, residency, and address:

{
  "iss": "https://login.luxid.lu",
  "sub": "a3f2c1d8-9b4e-4a2f-8c1d-3e7b9a2f1c4d",
  "aud": "app_partner_prod",
  "iat": 1748477500,
  "exp": 1748481100,
  "auth_time": 1748477500,
  "acr": "urn:luxid:acr:level:substantial",
  "amr": ["pwd", "otp"],
  "email": "marie.dupont@example.lu",
  "email_verified": true,
  "name": "Marie Dupont",
  "given_name": "Marie",
  "family_name": "Dupont",
  "luxid_verified": true,
  "luxid_verification_level": "substantial",
  "luxid_verified_at": "2026-04-15T10:30:00Z",
  "age_over_16": true,
  "age_over_18": true,
  "age_over_21": false,
  "lu_resident": true,
  "address": {
    "street_address": "12 Rue de la Poste",
    "locality": "Luxembourg",
    "postal_code": "L-2090",
    "country": "LU"
  },
  "luxid_organization": "POST Luxembourg"
}

Configuration​

Requesting enriched claims​

Reminder on LuxID's claim model. Which enriched attributes you receive is governed by your Application's Claim Template on the LuxID side, not by the scope parameter. Adding address (or any other scope) to your request does not unlock a claim that is not in your Claim Template. Enriched and standard claims alike are added to your Claim Template via a request to LuxID. See Tokens and Claims - Requesting claims.

Send a spec-valid scope parameter (openid at minimum) and, where you want to mark specific claims essential or optional, use the OIDC claims request parameter. The claims parameter lets you flag individual claims.

The examples below use age_over_18 - a roadmap claim that is not live today (like all age claims). The syntax applies unchanged to any claim in your approved Claim Template:

{
  "id_token": {
    "age_over_18": null,
    "lu_resident": null,
    "luxid_organization": null
  }
}

Setting a claim to null (as opposed to {"essential": true}) requests the claim as optional - the authorisation flow will succeed even if the user declines consent for that specific claim.

To make a claim essential (fail authorisation if the user does not consent or the claim is unavailable):

{
  "id_token": {
    "age_over_18": { "essential": true }
  }
}

Enabling enriched claims in the console​

Enriched claims are not self-serve: each enriched Claim Template must be attached to your Application with LuxID and approved by LuxID staff before it can flow at runtime. This approval step is not a formality - LuxID assesses whether each enriched attribute is proportionate to the stated purpose of your Application. A Partner registering a loyalty card app, for example, would not be approved for luxid_professional_title or luxid_verified_name. This pre-approval model applies to all enriched claims and mirrors the same privacy-guardrail principle that governs standard OIDC claims: claim entitlement is a configuration-time decision, not a runtime one. At runtime, the scope and claims parameters can only select from the already-approved enriched set; requesting an unapproved enriched claim results in that claim being absent from the token (or invalid_scope if the scope itself was not approved).

To submit enriched claims for approval:

  1. Navigate to your Application settings.
  2. Open the Claims tab.
  3. Enable the enriched claim categories you intend to request (Identity Verification, Age Brackets, Address, Organisation, Professional Attributes).
  4. Save and submit for review via LuxID or the Console request workflow.

Attempting to request an enriched claim that has not been approved in the Console will result in the claim being silently omitted from the token.

Lawful basis. Enriched attribute sharing is based on GDPR Article 6(1)(a) - the user's explicit consent. LuxID obtains this consent at the time the attribute is first requested, via the Universal Login consent screen.

Granularity. Consent is obtained per attribute, not as a blanket "share all my data". This is required by GDPR Article 7 and Recital 43 (consent must be specific and granular for separate processing purposes).

Withdrawal. Users can withdraw consent for any enriched attribute at any time in their LuxID Account (opens in a new tab) under Applications > [Your Application] > Data Shared. On withdrawal, LuxID emits a user.consent.revoked event to the Event Hub and stops including the affected claim in subsequent tokens.

Right to erasure. If a user deletes their LuxID Account, all consented attribute data is deleted with the account. Partners receive a user.deleted event and must assess their own GDPR obligations for data held in their systems.

Data minimisation in practice. Request only the enriched attributes your application needs for its stated purpose. If your application needs to verify that a user is 18+, request age_over_18 - not the user's full birthdate, not luxid_verified_name, not their address. Each additional attribute increases the sensitivity of the token and the scope of your GDPR data processing.

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