Human at the starting point.
A pseudonymous identifier and an assurance statement let a service recognise a returning person without requesting their name.
ZOREAL Identify
Be known.
On your terms.
Bring a document-backed identity to your sign-in.
Make the request clear. Choose what to share.
A verified
starting point.
starting point.
Identity grounded in
a government document chip.
What this example shares
Human proof
- Name
- Freja Lindqvist
- Other personal details
- Not requested
A name, when the interaction calls for it.
Specimen credential · Illustrative proof modes
Ask for what
the moment needs.
A meaningful introduction doesn’t have to reveal everything. Start with human proof, and add the information the interaction calls for.
Details with a purpose.
Request a name, an age threshold, or other permitted fields. Each piece of information has its own place in the exchange.
A clear request. A choice.
The person sees the receiving domain and what is being requested before approving the sign-in.
The foundation
A document. A person.
A device that connects them.
Enrollment brings the evidence together. Returning sign-ins build on that foundation, with the authentication method stated for each login.
Read the document.
The chip’s signed data is checked against the issuing state’s signature. The server verifies the evidence independently.
Connect it to the person.
The person’s face is compared with the document portrait. Capture evidence determines the assurance established.
Register the device.
A registered device key connects later approvals to the enrolled holder. A fresh capture can be requested when needed.
ZOREAL IDExample request
service.example
Example domainInformation requested
for this sign-in
- Private identifier
- Sign-in assurance
- Name
- Not requested
- Over 18
- Not requested
- Birthdate
- Not requested
- Document number
- Not requested
Illustrative requests · No information is sent by this preview
Every login
tells you how.
Knowing who enrolled and knowing how they authenticated are different things. Identify makes the method clear, so each interaction can ask for the evidence it needs.
An approval from the enrolled device.
The registered device approves the sign-in without a fresh capture. This is the default when the service has not requested live assurance.
Illustrative authentication evidenceRegistered device
Device approval · No fresh capture
Authentication method
The response describes what happened.zoreal.deviceFor websites and apps
A familiar button.
A more considered sign-in.
Bring ZOREAL into your authentication flow. Manage what your integration can ask for, and check the evidence that comes back.
Example sign-in page
A better introduction.
A person on one side.
Your service on the other.
OpenID ConnectOAuth 2.0 + PKCE
- 01
Add your website or app.
Register it as an asset, with a client identity of its own.
- 02
Establish your domain.
Prove domain control where required, so the request has a verified origin.
- 03
Define the information you need.
Set redirect addresses, authorised origins and the scopes the integration may request.
- 04
Connect. Then check the response.
Validate the authentication response and require the assurance your interaction needs.
The requested fields stay in your control.
A little more
clarity.
What’s shared, what’s proven, and how the pieces fit together.
What is the difference between human proof and identity details?
A sign-in can return a pseudonymous identifier and information about the verification and authentication behind it. Details such as a name, birthdate or document information are separate claims. A service requests the fields it needs, within the permissions of its integration, and the person sees the request before consenting.
Does every sign-in include a new live capture?
No. A service can request a fresh live capture, a registered-device approval, or reuse of a valid, previously consented session. Device approval is the default. The authentication result describes the method actually used; a request that requires live assurance is not silently replaced with a weaker result.
What do the flags on the credential mean?
The national flag shows the issuing country of the document used for enrollment. The EU flag also appears for an EU member state. They describe the specimen’s document origin; they do not mean nationality or document details are automatically shared at login.
Can an age check work without sharing a date of birth?
Yes. A service can request a registered age threshold, such as over 18, and receive a yes-or-no answer. That claim does not include an exact age or birthdate. Available claims depend on the information carried by the underlying document.
Is the same identifier used at every service?
The sign-in identifier is derived for the service’s registered sector. It stays consistent when the person returns within that sector, while unrelated sectors receive different identifiers. Separately shared details, such as a name or email, can still identify a person across services.
How do I add Identify to a website or app?
Start by registering the website or app as an asset. Configure its redirect addresses, origins and permitted scopes, and prove domain control where required. Connect the sign-in flow and validate its response with the assurance your service needs. Personal-data scopes require a verified domain and a confidential client.
A better introduction
starts here.
Bring proof of humanity to your next interaction.