Authorization Request

Must be code for Authorization Code flow.

OIDC Client ID issued to the RP.

Registered redirect URI for the client.

Space-separated list of requested scopes. Must include openid.

Example: openid profile email

Opaque value for CSRF protection. Returned unchanged in the callback.

Random value to associate the ID token with the client session.

PKCE code challenge derived from the code verifier using S256.

Must be S256.

URL-encoded JSON object specifying requested claims. Supports two namespaces.

Standard OIDC claims#

Standard scopes (openid, profile, email, phone) can be requested via the scope parameter. Individual OIDC claims can also be requested here using scope-keyed objects, e.g. {"profile":["given_name","family_name"]}.

TrueVault claims (true namespace)#

The true key holds an array of TrueVault selective disclosure claim keys, named {credential}.{field} or document.{doc_type}.{field}:

{"true": ["trueidentity.valid", "sanctionscheck.is_sanctioned"]}

Essential claims#

Marking a claim essential tells us to obtain the credential during the journey if the person does not already hold one, rather than returning nothing:

{"true": {"acicncchc.credential": {"essential": true}}}

This is how you ask for a check to be performed rather than merely read. The whole credential becomes mandatory, not the single claim, though you still receive only the claims you asked for.

Only obtainable credentials can be marked essential: acicncchc, vevortw, sanctionscheck, courtcheck, student and phonenumber. document.* claims never can - require a document through the ruleset instead. Both cases return invalid_request at the authorization request, before the person sees anything.

Which claims exist#

The complete, current list is published in the discovery metadata under true_claims_supported, which is the one to read from code. Read it from there rather than hard-coding a list and you will pick up new claims without a release.

For what each claim means, what it returns and which to prefer, see Claims and credentials, and the claim reference for the full list. It is not repeated here: a catalogue kept in two places is a catalogue that disagrees with itself.

An unrecognised claim key is rejected rather than ignored, so a typo fails at the authorization request instead of quietly returning nothing.

Example: {"true":["trueidentity.credential","trueidentity.given_name","trueidentity.family_name","trueidentity.birth_date","trueidentity.email","trueidentity.phone","trueidentity.email_verified","trueidentity.phone_verified","trueidentity.names_verified","document.passport.travel_document_number","document.passport_foreign.passport_number","document.driving_license.licence_number"]}

Identity verification ruleset to apply. Determines the minimum document and verification requirements for the onboarding session. Must be in the client's allowed rulesets. Falls back to the client's default ruleset if not provided.

Example: bronze

Acting On Behalf Of — delegation UID. When provided, the request is made under a delegation relationship, allowing one RP to act on behalf of another. The delegation must be valid and include the oauth.core.authorization scope.

Pre-seed the user's phone number for the onboarding session. Must be provided with phone_country_code.

Example: 0412345678

Country code for the pre-seeded phone number (e.g. 61 for Australia). Required when phone is provided.

Example: 61

Pre-seed the user's email address for the onboarding session.

Example: user@example.com

Redirect to identity verification flow. After completion, the user is redirected to redirect_uri with code, state, and optionally session_state parameters.

Invalid request parameters

Error code as defined in RFC 6749.

Human-readable error description.