Optional ReadonlyemailSurfaced as the email claim under the email scope.
Optional ReadonlyemailSurfaced as the OIDC email_verified claim under the email scope.
false and absent are not the same, and both reach relying parties
distinguishably: false says the Store tracks verification and this
address is not verified; absence says the Store does not model it at all.
A non-boolean is dropped rather than forwarded, so a truthy string cannot
become an affirmative claim in a signed token.
Optional ReadonlygroupsSurfaced as the non-standard groups claim under the groups scope.
ReadonlyidOptional ReadonlynameSurfaced as the name claim under the profile scope.
Optional ReadonlypictureSurfaced as the picture claim under the profile scope.
Readonlyusername
A user as returned by a UserRepository.
The claim-bearing fields below are the ones
extractUserClaimsreads when seeding a session's claims envelope, and they mirrorUserSessionClaimsexactly. They are declared rather than left to the index signature because a Store is reached across an untyped boundary —HttpUserRepositoryparses JSON — and until #297 the only thing telling an implementer thatemailVerifiedwas a boolean was the runtimetypeofcheck that silently dropped it when it wasn't.email_verifiedin an issued token is Store-owned state that auth.provider only reflects. Issuing the verification token, delivering it, and flipping the state belong to the Store; this library reads the result and binds it into the artifact (responsibility #4).The index signature stays: a Store may carry custom claims beyond these, and a consumer may map them through a custom claim filter.