The only claims a federated profile may contribute to the top-level claims
envelope, and then only where the local record left the field absent and the
mapped value is a string. A promotable claim whose mapped value is any other
type is dropped rather than promoted — an adapter is reached across an
untyped boundary, and a name that is an object would reach a signed token.
Deliberately excluded:
groups (and any roles / scope / permissions an adapter invents)
— authorization input. An IdP that could write these would be granting
itself local authorization, which is #279.
emailVerified — Store-owned state since #297, readable by
oauth.requireEmailVerified as a gate on token issuance, and surfaced to
relying parties as the signed email_verified claim. An upstream IdP
verifies an address it controls; it has no knowledge of the local
account's address, which the provider:sub linkage never forces to match.
A deployment that wants to act on the IdP's assertion reads
claims.federated?.[<provider>]?.emailVerified and publishes the result on
the User — the Store is where #297 put the field, and that is the opt-in.
Exported so a deployment can assert on the set from its own tests.
The only claims a federated profile may contribute to the top-level claims envelope, and then only where the local record left the field absent and the mapped value is a string. A promotable claim whose mapped value is any other type is dropped rather than promoted — an adapter is reached across an untyped boundary, and a
namethat is an object would reach a signed token.Deliberately excluded:
groups(and anyroles/scope/permissionsan adapter invents) — authorization input. An IdP that could write these would be granting itself local authorization, which is #279.emailVerified— Store-owned state since #297, readable byoauth.requireEmailVerifiedas a gate on token issuance, and surfaced to relying parties as the signedemail_verifiedclaim. An upstream IdP verifies an address it controls; it has no knowledge of the local account's address, which theprovider:sublinkage never forces to match. A deployment that wants to act on the IdP's assertion readsclaims.federated?.[<provider>]?.emailVerifiedand publishes the result on theUser— the Store is where #297 put the field, and that is the opt-in.Exported so a deployment can assert on the set from its own tests.