BK: DISCUSS Comment: Name space issues

[Nat Sakimura]

My apologies; my previous position was incomplete.  Updated to note
namespacing issues, and one minor terminology nit about "DNS-ID".

There seem to be some pretty serious namespacing issues that are not
discussed at all in this document.  Specifically, using JWT as a
container for OAuth 2.0 authorization request parameters (including
extension parameters) introduces the usage of many new names (of JSON
name/value pairs) into the JWT claims namespace.  Furthermore, the
addition is not bounded, as any new OAuth extension parameters are
implicitly permitted to be used as well!  The IANA Considerations make
no mention of the collapsed namespace for JWT claims and OAuth 2.0
(authorization request) parameters, leaving substantial potential for
collisions in the future.

John to suggest a text to go into IANA consideration.

[Nat Sakimura]

• Register all the current authz request parameters to the JWT registry.
• No new oauth extension parameter names MAY conflict with then registered JWT registry.
• All new extension parameter MUST be registered to JWT registry.

[Nat Sakimura]

Just checked registry.

OAuth authz req params are:

• response_type
• client_id
• redirect_uri
• scope
• state

Out of which, the followings are already regsitered:

• scope
• client_id

So, the followings remain to be registered:

• response_type
• redirect_uri
• state

For OIDC extension parameters, nonce is registered but the followings needs to be registered:

• display
• prompt
• max_age
• ui_locales
• id_token_hint
• login_hint
• acr_values

There will be much more if we expand to https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters

[Nat Sakimura]

Followings are OAuth Authz Params that are not registered in the JWT Claims.

I suppose those that are sourced from OIDF are going to be registered by them, so this spec should just deal with IESG and IETF ones. Thus:

‌

This specification adds the following values to the "JSON Web Token Claims" registry established by [RFC7519].

• Claim Name: "code_challenge"
• Claim Description: OAuth PKCE Code Challenge
• Change Controller: IESG
• Specification Document(s): Section 3 of RFC 7636

‌

• Claim Name: "code_challenge_method"
• Claim Description: OAuth PKCE Code Challenge
• Change Controller: IESG
• Specification Document(s): Section 3 of RFC 7636

‌

• Claim Name: "redirect_uri"
• Claim Description: OAuth Redirection URI
• Change Controller: IETF
• Specification Document(s): Section 4.1.1 of RFC 6749

‌

• Claim Name: "response_type"
• Claim Description: OAuth Authorization Response type
• Change Controller: IETF
• Specification Document(s): Section 3.1.1 of RFC 6749

‌

• Claim Name: "state"
• Claim Description: OAuth state parameter
• Change Controller: IETF
• Specification Document(s): Section 4.1.1 of RFC 6749

‌

• Claim Name: "vtr"
• Claim Description: Vector of Trust request
• Change Controller: IESG
• Specification Document(s): Section 4.1 of RFC 8485

[Nat Sakimura]

fixes #84 - put registration into subsection

→ <<cset 7d41d3ffae57>>