Discovery

https://auth-id.lavisionit.com/oidc/.well-known/openid-configuration

The rules

• Authorization code with PKCE (S256), and nothing else.
• Client authentication by private_key_jwt (ES256 or RS256): you give your public keys, never a secret.
• An identifier (sub) of your organisation’s own: never the same as another’s.
• Profile claims are read at userinfo; the ID token carries sub, the level (acr), the method (amr: sms, or pop and user for a passkey) and the time of authentication (auth_time).
• Logout both ways: end_session_endpoint with id_token_hint and a registered return address; a logout token (back-channel logout) to the address you register, as soon as the person’s session ends here.
• Pushed authorization requests (PAR), signed responses (JARM, response_mode=jwt) and key-bound tokens (DPoP): offered to every organisation, required of none for now.
• Levels (acr_values): 0 declared, 1 phone verified, 2 identity document checked in person, 3 national identity. A sign-in’s acr is the person’s level capped by how they signed in: 2 at most by SMS, 3 only with a passkey (/.well-known/identity-levels).
• Every release is recorded and the person sees it; they may withdraw your access at any time.

The claims

What each class may ask for

Example

https://auth-id.lavisionit.com/oidc/auth?client_id=YOUR_CLIENT_ID&response_type=code&scope=openid%20profile&redirect_uri=https%3A%2F%2Fyour.example%2Fcallback&state=STATE&nonce=NONCE&code_challenge=S256_CHALLENGE&code_challenge_method=S256&acr_values=1

curl -X POST https://auth-id.lavisionit.com/oidc/token \
  -d grant_type=authorization_code -d code=CODE \
  -d redirect_uri=https://your.example/callback -d code_verifier=VERIFIER \
  -d client_id=YOUR_CLIENT_ID \
  -d client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer \
  -d client_assertion=SIGNED_JWT  # iss=sub=YOUR_CLIENT_ID, aud=https://auth-id.lavisionit.com/oidc, jti, exp

Verifying an identity (eKYC)

An organisation admitted to the kyc.verify / kyc.full scopes (government, finance, health and telecom classes) asks, with a token in its own name (client_credentials), whether the information it holds about a person — known by its sub — matches: POST /kyc/verifications with subject and any of givenNames, familyName, dateOfBirth, document, minLevel. The person approves by SMS (« YES 4821 »); the organisation polls GET /kyc/verifications/:id and reads APPROVED with yes/no per attribute — never the value —, or DENIED / EXPIRED. Three requests per person per hour. Since Unit 82 the organisation may also ask in the person’s presence, by the number the person gives it: number (and countryCode) in place of subject. The person approves the same way, and the answer brings the organisation the identifier (subject) it will know the person by from then on — as a sign-in would have. Twenty unknown numbers an hour, no more. Instead of polling, the organisation may receive the decision at the https address it registers on its portal: a JSON POST { id, event: "verification.decided", at, data } (data: what the poll would have answered), signed X-ConsoleID-Signature: t=…,v1=HMAC-SHA256(secret, t + "." + body) with the secret the portal showed it once; six attempts over ten minutes, then the abandonment is recorded.

Being admitted

Write to the operator of Console ID with your signed data-sharing agreement, your legal basis, your redirect URIs (https, one domain), your public keys (a JWKS or its address), the claims you ask for and, if you wish, your logout addresses (post-logout return, back-channel logout). An administrator records your application and approves it under your class’s policy.