Attribute preview tool

Overview

The Attribute Preview Tool shows you exactly which claims would appear in the ID Token for a specific test user and application combination - before a single real user logs in.

This matters because claim release in LuxID is the result of several layers working together:

1. The Claim Template attached to your Application on the LuxID side. This is the pinned set of claims your Application is entitled to receive. It is set by LuxID at registration time and changes require a Partner request (see Tokens and Claims - Requesting claims). The scope parameter in your authorisation request does not influence this set.
2. The consents the user has granted (for claims requiring individual user consent).
3. The user's actual attributes (a claim is only released if the user actually holds that attribute - for example, phone_number is only present if the user has registered a phone number).
4. The assurance level required for certain claims (for example, luxid_verified is only released if the user has completed LuxID Verified identity verification at the required assurance level).

The Attribute Preview Tool evaluates all four layers for a chosen test user and application, and produces a JSON sample of the ID Token claims that would result.

Access (once the planned LuxID Console is live): LuxID Console > Your Application > Preview > Attribute Release. Until then, LuxID can run an Attribute Preview against a UAT test user on request.

---

When to use it

Use the Attribute Preview Tool at these points in your development cycle:

Before writing claim-handling code: confirm which claims you will actually receive, so you can write your user profile mapping logic against real data shapes rather than assumptions.

After changing your Claim Template: verify that a template change produces the expected delta in released claims.

After adding a new scope: confirm the new scope translates to the additional claims you expect.

Before go-live: run through your full test user matrix to confirm no critical claims are missing.

After a UAT reset: re-verify that the Claim Template and consent grants are still correctly configured.

---

How to use the tool

Step 1 - select your Application

Choose the application you want to inspect from the application dropdown. The tool uses the currently saved Claim Template for that application.

Step 2 - select a test user

Choose a test user from your UAT pool. The tool evaluates that user's actual attribute values and consent grants.

To get meaningful results, you need test users that cover different attribute profiles. Examples:

Test user profile	Purpose
Basic user (email only, no phone, no LuxID Verified)	Baseline - confirms minimum claim set
User with phone number registered	Confirms phone_number claim release
LuxID Verified user (Substantial assurance)	Confirms luxid_verified and related claims
User who has previously consented to all claims	Confirms full claim release without consent prompt
User who has revoked consent for phone_number	Confirms claim is withheld when consent is absent

See Test users and simulation for how to create and manage test users with specific attribute profiles.

Step 3 - specify the requested scopes

Enter the scopes exactly as they would appear in your authorisation request. This is important: the Claim Template controls the maximum set of claims that can be released, but the scopes in the authorisation request determine which subset of those claims is eligible.

Example scope string:

openid profile email phone

Step 4 - review the output

The tool produces two outputs:

ID Token claims (JSON sample):

A JSON object representing the claims that would appear in the ID Token payload:

{
  "sub": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "iss": "https://login-uat.luxid.lu",
  "aud": "your-uat-client-id",
  "iat": 1748000000,
  "exp": 1748003600,
  "auth_time": 1748000000,
  "acr": "urn:luxid:acr:level:substantial",
  "amr": ["pwd", "otp"],
  "email": "testuser@example.lu",
  "email_verified": true,
  "given_name": "Jean",
  "family_name": "Dupont",
  "name": "Jean Dupont",
  "phone_number": "+352691000000",
  "phone_number_verified": true,
  "luxid_verified": true,
  "luxid_assurance_level": "substantial"
}

Note that iat, exp, and auth_time are shown with placeholder timestamps. The sub value shown is the real sub for the selected test user in UAT.

Claim release audit trail:

For each claim in the Claim Template, the tool shows the reason it was included or excluded:

Claim	Status	Reason
email	Released	Scope email requested, user holds attribute, consent granted
phone_number	Released	Scope phone requested, user holds attribute, consent granted
luxid_verified	Released	Scope luxid_verified requested, user is verified at Substantial level
address	Withheld	Scope address not requested in this preview
birthdate	Withheld	Scope profile requested but birthdate not in Claim Template
custom_claim_x	Withheld	User has not granted consent for this claim

This audit trail is the fastest way to diagnose why a claim is missing.

---

Reading the output

Claims present when you did not expect them

If the output includes a claim you did not expect (for example, luxid_assurance_level when you only asked for openid profile), it is likely because your Claim Template includes that claim as an always-released field not gated by a specific scope. Review your Claim Template with LuxID.

caution

Releasing more claims than necessary is a data minimisation concern under GDPR. Only release claims your application actually uses.

Claims absent when you expected them

Work through the audit trail. The most common causes are:

Scope not requested

The claim is in your Claim Template, but the corresponding scope was not included in the scope string you specified. Add the scope to your authorisation request.

Claim not in Claim Template

The scope was requested, but the specific claim is not enabled in your Claim Template. Edit the Claim Template with LuxID to add it.

User does not hold the attribute

The claim is correctly configured but the test user simply does not have that attribute. For example, a test user without a registered phone number will never produce a phone_number claim. Create a test user with the required attribute, or add the attribute to an existing test user via the Console.

Consent not granted

For claims that require individual user consent, the test user must have previously granted consent. If the test user has never completed the consent flow for your application, consent-gated claims will be withheld. Run the test user through the actual authorisation flow once to establish consent, then re-run the Attribute Preview Tool.

Assurance level requirement not met

Some claims (such as luxid_verified) are only released when the user's authentication assurance level meets a configured threshold. If the test user's last authentication was at Low assurance but luxid_verified requires Substantial, the claim will be withheld. Use the simulation options to specify the assurance level used in the preview, or authenticate the test user at the required level.

---

Interpreting luxid_verified and identity claims

LuxID Verified is LuxID's identity verification service, integrated with LuxTrust. When a user completes identity verification:

• luxid_verified: true
• luxid_assurance_level: "substantial" or "high" depending on the verification method used

These claims are only released if:

1. Your Claim Template includes them.
2. The requesting scope includes the relevant scope (luxid_verified).
3. The user has completed LuxID Verified.
4. The user's consent covers these claims.

To test this in UAT, create a test user with LuxID Verified status enabled. See Test users and simulation.

---

Comparing multiple test users

Run the tool multiple times with different test users to build a matrix of expected claim sets:

Test user	email	phone_number	luxid_verified	address
Basic user	Yes	No	No	No
User with phone	Yes	Yes	No	No
Verified user	Yes	Yes	Yes	No
Full-profile user	Yes	Yes	Yes	Yes

This matrix becomes your test plan. For each row, assert that the claims returned by the real token endpoint match this expected set.

---

Using the output in automated tests

Copy the JSON sample from the tool and use it as the expected payload in your integration tests:

// Example: assert that the token contains the expected claims
describe('LuxID token claims', () => {
  it('includes email and phone_number for a user with both attributes', () => {
    // idTokenPayload is the decoded payload from the real token endpoint
    expect(idTokenPayload.email).toBeDefined();
    expect(idTokenPayload.email_verified).toBe(true);
    expect(idTokenPayload.phone_number).toMatch(/^\+/);
  });

  it('does not include luxid_verified for a non-verified user', () => {
    expect(idTokenPayload.luxid_verified).toBeUndefined();
  });
});

---

Related

• Consent simulator - preview how claims are presented to the user
• Token debugger - inspect the actual tokens produced in UAT
• UserInfo endpoint - alternative claim delivery via the UserInfo endpoint
• Token introspection - server-side token validation and claim inspection
• Test users and simulation - create test users with specific attribute profiles
• OpenID Connect - full scope and claim reference