This page (revision-5) was last changed on 29-Nov-2024 16:16 by -jim

This page was created on 29-Nov-2024 16:16 by unknown

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
5 29-Nov-2024 16:16 7 KB -jim to previous
4 29-Nov-2024 16:16 7 KB -jim to previous | to last
3 29-Nov-2024 16:16 6 KB -jim to previous | to last
2 29-Nov-2024 16:16 6 KB -jim to previous | to last
1 29-Nov-2024 16:16 6 KB unknown to last

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 9 changed 3 lines
|[openid]|[sub]|[string]|Subject - [REQUIRED]. Subject Identifier. A locally unique and never reassigned [Case-sensitive] identifier within the Issuer for the End-User, which is intended to be consumed by the Client, e.g., 24400320. It [MUST NOT] exceed 255 [ASCII] characters in length.
|[openid]|[auth_time]|[string]|Time when the End-User authentication occurred. Its value is a [JSON] number representing the number of seconds from 1970-01-01T0:0:0Z as measured in [UTC] until the date/time. When a max_age request is made or when auth_time is requested as an Essential Claim, then this Claim is [REQUIRED]; otherwise, its inclusion is [OPTIONAL]. The auth_time Claim semantically corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] auth_time response parameter.
|[openid]|[acr]|[string]|[OPTIONAL]. If the acr Claim is requested as an Essential Claim for the ID Token with a values parameter requesting specific Authentication Context Class Reference values and the implementation supports the claims parameter, the Authorization Server MUST return an acr Claim Value that matches one of the requested values. The Authorization Server MAY ask the End-User to re-authenticate with additional factors to meet this requirement. If this is an Essential Claim and the requirement cannot be met, then the Authorization Server MUST treat that outcome as a failed authentication attempt.
|[openid]|[sub]|[string]|Subject - Identifier for the End-User at the Issuer.
|[openid]|[auth_time]|[string]|Subject - Identifier for the End-User at the Issuer.
|[openid]|[aud]|[string]|Subject - Identifier for the End-User at the Issuer.
At line 22 changed 3 lines
|[profile]|[email_verified]|[boolean]|[True] if the End-User's e-mail address has been verified; otherwise false. When this Claim Value is true, this means that the OP took affirmative steps to ensure that this e-mail address was controlled by the End-User at the time the verification was performed. The means by which an e-mail address is verified is context-specific, and dependent upon the trust framework or contractual agreements within which the parties are operating.
|[profile]|[gender]|[string]|End-User's gender. Values defined by this specification are female and male. Other values MAY be used when neither of the defined values are applicable. Part of the [Default Profile Claims]
|[profile]|[Birthdate]|[string]|End-User's [birthday] Part of the [Default Profile Claims]
|[email_verified]|[boolean]|[True] if the End-User's e-mail address has been verified; otherwise false. When this Claim Value is true, this means that the OP took affirmative steps to ensure that this e-mail address was controlled by the End-User at the time the verification was performed. The means by which an e-mail address is verified is context-specific, and dependent upon the trust framework or contractual agreements within which the parties are operating.
|[gender]|[string]|End-User's gender. Values defined by this specification are female and male. Other values MAY be used when neither of the defined values are applicable. Part of the [Default Profile Claims]
|[BirthDate]|[string]|End-User's birthday, represented as an ISO 8601:2004 [ISO 8601-2004] YYYY-MM-DD format. The year __MAY be__ 0000, indicating that it is omitted. To represent only the year, YYYY format is allowed. Note that depending on the underlying platform's date related function, providing just year can result in varying month and day, so the implementer's need to take this factor into account to correctly process the dates. Part of the [Default Profile Claims]