]> SimpleLogin

beltram.ietf@pm.me

Self-Issued Consulting

United States michael_b_jones@hotmail.com https://self-issued.info/

Security Secure Patterns for Internet CrEdentials Openid Connect Standard Claims This document registers OpenID Connect standard claims already used in JSON Web Tokens for use in CBOR Web Tokens. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Secure Patterns for Internet CrEdentials Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction OpenID Connect is an authentication standard including standard claims already in use for JSON Web Tokens (JWT) . CBOR Web Tokens (CWT) have a claims registry, but do not include most of these claims. This draft aims at unifying use of OpenID Connect claims in JWTs and CWTs.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

OpenID Connect Claims This section enumerates the OpenID Connect claims that are registered, including the fields necessary for registration with IANA; see . The definitions of each field are taken from verbatim.

name

Claim Name:

name

Claim Description:

End-User's full name in displayable form including all name parts, possibly including titles and suffixes, ordered according to the End-User's locale and preferences.

JWT Claim Name:

name

Claim Key:

TBD1 (170 suggested)

Claim Value Type(s):

text string

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

given_name

Claim Name:

given_name

Claim Description:

Given name(s) or first name(s) of the End-User.

JWT Claim Name:

given_name

Claim Key:

TBD2 (171 suggested)

Claim Value Type(s):

text string

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

family_name

Claim Name:

family_name

Claim Description:

Surname(s) or last name(s) of the End-User.

JWT Claim Name:

family_name

Claim Key:

TBD3 (172 suggested)

Claim Value Type(s):

text string

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

middle_name

Claim Name:

middle_name

Claim Description:

Middle name(s) of the End-User.

JWT Claim Name:

middle_name

Claim Key:

TBD4 (173 suggested)

Claim Value Type(s):

text string

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

nickname

Claim Name:

nickname

Claim Description:

Casual name of the End-User that may or may not be the same as the given_name.

JWT Claim Name:

nickname

Claim Key:

TBD5 (174 suggested)

Claim Value Type(s):

text string

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

preferred_username

Claim Name:

preferred_username

Claim Description:

Shorthand name by which the End-User wishes to be referred to at the Resource Server.

JWT Claim Name:

preferred_username

Claim Key:

TBD6 (175 suggested)

Claim Value Type(s):

text string

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

profile

Claim Name:

profile

Claim Description:

URL of the End-User's profile page.

JWT Claim Name:

profile

Claim Key:

TBD7 (176 suggested)

Claim Value Type(s):

text string

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

picture

Claim Name:

picture

Claim Description:

URL of the End-User's profile picture. This URL MUST refer to an image file, rather than to a Web page containing an image.

JWT Claim Name:

picture

Claim Key:

TBD8 (177 suggested)

Claim Value Type(s):

text string

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

website

Claim Name:

website

Claim Description:

URL of the End-User's Web page or blog.

JWT Claim Name:

website

Claim Key:

TBD9 (178 suggested)

Claim Value Type(s):

text string

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

email

Claim Name:

email

Claim Description:

End-User's preferred e-mail address.

JWT Claim Name:

email

Claim Key:

TBD10 (179 suggested)

Claim Value Type(s):

text string

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

email_verified

Claim Name:

email_verified

Claim Description:

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.

JWT Claim Name:

email_verified

Claim Key:

TBD11 (180 suggested)

Claim Value Type(s):

bool

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

gender

Claim Name:

gender

Claim Description:

End-User's defined gender. Values defined by this specification are female and male. Other values MAY be used when neither of the defined values are applicable.

JWT Claim Name:

gender

Claim Key:

TBD12 (181 suggested)

Claim Value Type(s):

text string

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

birthdate

Claim Name:

birthdate

Claim Description:

End-User's birthday, represented as an 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 implementers need to take this factor into account to correctly process the dates.

JWT Claim Name:

birthdate

Claim Key:

TBD13 (182 suggested)

Claim Value Type(s):

text string

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

zoneinfo

Claim Name:

zoneinfo

Claim Description:

String from IANA Time Zone Database representing the End-User's time zone.

JWT Claim Name:

zoneinfo

Claim Key:

TBD14 (183 suggested)

Claim Value Type(s):

text string

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

locale

Claim Name:

locale

Claim Description:

End-User's locale, represented as a BCP47 language tag.

JWT Claim Name:

locale

Claim Key:

TBD15 (184 suggested)

Claim Value Type(s):

text string

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

phone_number

Claim Name:

phone_number

Claim Description:

End-User's preferred telephone number.

JWT Claim Name:

phone_number

Claim Key:

TBD16 (185 suggested)

Claim Value Type(s):

text string

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

phone_number_verified

Claim Name:

phone_number_verified

Claim Description:

True if the End-User's phone number has been verified; otherwise false. When this Claim Value is true, this means that the OP took affirmative steps to ensure that this phone number was controlled by the End-User at the time the verification was performed. The means by which a phone number is verified is context specific, and dependent upon the trust framework or contractual agreements within which the parties are operating. When true, the phone_number Claim MUST be in E.164 format and any extensions MUST be represented in format.

JWT Claim Name:

phone_number_verified

Claim Key:

TBD17 (186 suggested)

Claim Value Type(s):

bool

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

address

Claim Name:

address

Claim Description:

End-User's preferred postal address.

JWT Claim Name:

address

Claim Key:

TBD18 (187 suggested)

Claim Value Type(s):

map

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

Address Claim To further reduce the size of this prevalent and large claim, these unsigned integer labels for its members are defined: Address labels

Name	Label	Type	Description
formatted	1	text string	Full mailing address, formatted for display or use on a mailing label. This field MAY contain multiple lines, separated by newlines. Newlines can be represented either as a carriage return/line feed pair ("\r\n") or as a single line feed character ("\n").
street_address	2	text string	Full street address component, which MAY include house number, street name, Post Office Box, and multi-line extended street address information. This field MAY contain multiple lines, separated by newlines. Newlines can be represented either as a carriage return/line feed pair ("\r\n") or as a single line feed character ("\n").
locality	3	text string	City or locality component.
region	4	text string	State, province, prefecture, or region component.
postal_code	5	text string	Zip code or postal code component.
country	6	text string	Country name component.

We strictly map the definition of claims in Section 5.1.1 of : all the claims are optional and "formatted" can either be used instead or in addition of all the other fields.

updated_at

Claim Name:

updated_at

Claim Description:

Time the End-User's information was last updated. Its value is a NumericDate as defined in Section 2 of .

JWT Claim Name:

updated_at

Claim Key:

TBD19 (188 suggested)

Claim Value Type(s):

integer or floating-point number

Change Controller:

IETF

Specification Document(s):

Section 5.1 of

Security Considerations This document registers existing OpenID Connect standard claims already used in JSON Web Tokens for use in CBOR Web Tokens without changing their semantics. The Security and Privacy Considerations respectively of Sections 16 and 17 of also apply.

IANA Considerations All claims defined in are registered in the (CBOR Web Token (CWT) Claims) Registry (part of the eponymous registry group). No new IANA registry is created. In case any of the suggested code points would have been claimed by the time the IESG approves the document for publication as an RFC, IANA is asked to assign Claim Key values from the 170-256 range.

References Normative References n.d. n.d. IANA CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. [STANDARDS-TRACK] Informative References JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.

CDDL Schema The following CDDL Schema includes example values for each item.

A CDDL description of each claim tstr) ; "Jane Doe" given_name = (TBD2 => tstr) ; "Jane" family_name = (TBD3 => tstr) ; "Doe" middle_name = (TBD4 => tstr) ; "Ellen" nickname = (TBD5 => tstr) ; "Jane D." preferred_username = (TBD6 => tstr) ; "j.doe" profile = (TBD7 => tstr) ; "https://example.org/about.html" picture = (TBD8 => tstr) ; "https://example.org/avatar.png" website = (TBD9 => tstr) ; "https://example.org" email = (TBD10 => tstr) ; "janedoe@example.com" email_verified = (TBD11 => bool) ; true gender = (TBD12 => tstr) ; "female" birthdate = (TBD13 => tstr) ; "1970-03-22" zoneinfo = (TBD14 => tstr) ; "America/Los_Angeles" locale = (TBD15 => tstr) ; "en_US" phone_number = (TBD16 => tstr) ; "+1 (425) 555-1212" phone_number_verified = (TBD17 => bool) ; true address = { &(formatted: 1) ^ => tstr, ; "1234 Hollywood Blvd. Los Angeles CA," ; " 90210 United States of America" &(street_address: 2) ^ => tstr, ; "1234 Hollywood Blvd." &(locality: 3) ^ => tstr, ; "Los Angeles" &(region: 4) ^ => tstr, ; "CA" &(postal_code: 5) ^ => tstr, ; "90210" &(country: 6) ^ => tstr, ; "United States of America" } updated_at = (TBD19 => int / float) ; 1730123071 TBD1 = 170 TBD2 = 171 TBD3 = 172 TBD4 = 173 TBD5 = 174 TBD6 = 175 TBD7 = 176 TBD8 = 177 TBD9 = 178 TBD10 = 179 TBD11 = 180 TBD12 = 181 TBD13 = 182 TBD14 = 183 TBD15 = 184 TBD16 = 185 TBD17 = 186 TBD18 = 187 TBD19 = 188 ]]>

Acknowledgments The authors would like to thank the following individuals for their contributions to this specification: Martin Thompson and David Waite.

Document History -04

• Moved claim definitions into the body of the specification.

-03

• Defined numeric labels for address claim items.
• Copied text describing gender claim values from .

-02

• Update descriptions of email_verified, phone_number_verified, and birthdate claims using text from .
• Use TBDn names for CWT requested claim numbers.

-01

• Aligned terminology with OpenID Connect specification.
• Added Michael B. Jones as an editor.

-00

• Initial working group draft, based on draft-maldant-spice-oidc-cwt-02.