What the person sees

The concrete release, who you are, until revoked, and a passkey.

The concrete release, not your scope list

The screen does not show email and identity_documents as scope codes. It shows what approving would actually release, computed against this person's records:

fields: The actual claim names userinfo would be able to answer with.
documents: Each identity document named individually — displayName, documentType, issuingCountry. No document outside this list is ever released under the resulting consent.
documentFields: Which document fields are included.
contacts: For email and for phone: none or primary_verified, and a count. The values themselves are not shown on the screen.

The document ids are pinned onto the interaction when the screen is built and re-used at approval. Approval cannot release a document the screen did not list, even if the person added one in another tab in between.

Who they are told you are

Above the release, the screen carries publisher facts: the environment (a sandbox application is labelled a test app, usable only by its team and its test identities), the production approval status of the client, and who publishes it.

How the publisher name is chosen

publisher_profile: When the application names a publisher profile, the screen shows that profile's display name, or its legal name. See Publisher verification.
verified_legal_name: Otherwise, an individual developer's production application that requests personal data is published under their verified legal name. Not a handle, not the application name.
publisher_display_name: Otherwise, the developer's publisher display name, or their account display name.
none: When no name the rule allows exists, the application name is shown instead.

The screen also states whether the publisher is verified or unverified — a named business answers for itself, otherwise the developer's own identity does. This is the practical meaning of the verified_publisher go-live check: by the time real people see your application, the name above the release is a name somebody stood behind.

Until revoked — and they are told so first

An application consent has no expiry. expiresAt is always null and the duration is until_revoked. That is not a default that could be overridden: a time-bound application consent is explicitly rejected with APPLICATION_CONSENT_EXPIRY_NOT_SUPPORTED.

The screen shows the duration before the person decides, not in a confirmation afterwards. They are agreeing to an open-ended connection knowingly, and they are the ones who end it.

There is one consent per person and application, and it is updated in place. A returning sign-in that asks for nothing new reuses it: no new version, no new record, no event. When a sign-in adds a scope, a new version is written with version + 1 that supersedes the previous one and carries everything it granted plus the addition. There is exactly one granted version per person and application, and the person's *Connected on* date is the first version's, however many times what they share has changed.

Approval is passkey-grade

The approve route requires a strong session. An emailed code is not enough — it proves the mailbox, not the person. In practice, whoever approves the release of a legal name has just re-proved that they are the account holder.

This is also why Sign in as a test identity needs a signed-in team member and a fresh confirmation for that exact authorization request: the sandbox does not relax the rule, it substitutes an invented person under it.

What this does not do

Approval takes no scope selection. The person's alternatives are approve everything shown, or cancel. The one choice they can make is which of their identity documents to share, when more than one qualifies under your document policy — the approve route accepts their documentIds, and only ids the screen listed. A returning person is not shown the consent at all unless you added a scope or sent prompt=consent.
You cannot explain yourself per claim. One purpose string, 200 characters, above the whole release.
You cannot see the screen's decision content from your side. What you learn is the outcome: a code, or access_denied.

Verified against API commit 234dba22 on 2026-10-18. The routes, scopes, checklist, events and limits on these pages are read from that export, not typed.