Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)

[Brian Campbell <[e-mail]>]

To be accurate, I'm one of the DEs on the JWT Claims registry
https://www.iana.org/assignments/jwt/jwt.xhtml while Hannes is the DE on
the OAuth Parameters registry
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters
FWIW.

To completely lock it all down and absolutely avoid collisions in all cases
(all cases that bother to consult the registries anyway), I suppose the two
registries would need to be reconciled and then kept perfectly in sync
going forward. Or even merged into a single super registry. But, to me
anyway, that seems like a huge PITA that's overkill and doesn't account for
the context of use with respect to likelihood of actual collisions.

JAR is a  specific application of JWT that is being used to convey an OAuth
authz request. The collisions that need to be avoided are in that narrow
context. JAR explicitly uses a few core JWT claims (aud, iss) so those need
to be accounted for by registering them as OAuth authorization request
parameters (with some explanation as such).  And one could reasonably
imagine some of the other core claims which are about the token itself
being used as well (exp, iat, nbf, jti, cnf, etc). So those should probably
be accounted for as well.

But most/all of the other JWT claims that have been registered, the SIP
CSeq numeric header field parameter value for example, are highly unlikely
to ever be used in the context of an OAuth authorization request. So won't
be a collision issue in the narrow context of a JWT secured authorization
request.  I think it's unlikely enough to be an issue that I think it's
sufficient to only register the core meta JWT claim names into the OAuth
parameters registry for the authorization request usage location.

True, that's not 100% guaranteed to guard against all collisions. But I
think it's pragmatic trade off that guards against all likly real world
collisions.

And if we are really worried about avoiding it 100% guaranteed all the
time, then JAR should wrap the authorization request parameters in a JSON
object so they have their own effectively distinct namespace. But I realize
that's a major change at this stage. Which leads me back to looking for a
simple(ish) and pragmatic approach to avoiding actual likely collisions.






On Sun, Jul 28, 2019 at 4:18 PM n-sakimura <[e-mail]> wrote:

> Brian,
>
> You are the expert on the particular IANA registries so I probably are
> missing something.
>
> I was thinking that registering JWT claims to OAuth registry is sufficient
> till seeing Ben’s comment, and I was tracking that it is being done by Mike
> as part of the errata process for OIDC Core. However, after reading Ben’s
> comment that mentioning the OAuth extensions, and I checked that quite a
> few claims are now being registered to JWT Claims Registry from outside the
> OAuth community, I started to feel that it may not be sufficient. But I
> must be missing something as you point out that is still sufficient.
>
> Could you please explain how the collision between the future OAuth
> extension and JWT claims can be avoided by registering main JWT claims to
> the OAuth Parameter registry?
> If that is the case, I am all for it as then we do not get back to IANA
> process.
>
> Best,
>
> Nat
>
> Nat Sakimura | 崎村夏彦
> Nomura Research Institute
>
>
> このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、送信者にご連絡のうえ、このメールを削除してくださいますようお願い申し上げます。
>
> PLEASE READ：This e-mail is confidential and intended for the named
> recipient only. If you are not an intended recipient, please notify the
> sender and delete this e-mail.
>
> ------------------------------
> *差出人:* Brian Campbell <[e-mail]>
> *送信日時:* Saturday, July 27, 2019 5:47:15 AM
> *宛先:* Nat Sakimura <[e-mail]>
> *CC:* Benjamin Kaduk <[e-mail]>; [e-mail] <
> [e-mail]>; [e-mail] <
> [e-mail]>; The IESG <[e-mail]>; oauth <[e-mail]>
> *件名:* Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
> draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
>
> Nat, you suggest that the "simplest solution probably is to register the
> authorization request parameters to the JWT Claims registry." However, as
> I've attempted to articulate several times this week (
> https://mailarchive.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBStRtcs
> and
> muliple comments on https://bitbucket.org/openid/connect/issues/1019) and
> even back in 2017 (
> https://mailarchive.ietf.org/arch/msg/oauth/_E14Trqu962cReu3t6FquPEyigY),
> I
> believe the pragmatic solution to this is to register some of the main JWT
> claims into the OAuth parameters registry (not the other way around, as
> you're suggesting which wouldn't even have caught the one name collision
> we've actually had where a draft, more than one actually, wanted to call an
> authorization request parameter "aud", which would conflicted with the JWT
> claim of the same name and cause big problems when used together with JAR).
> I suppose the iron clad way to "fix" this would be to merge the two
> registries and keep them in sync forever. But that seems awfully heavy
> handed and unnecessary. JAR is a specific application of JWT being used to
> convey an OAuth authz request. JAR explicitly uses a few core JWT claims
> (aud, iss) and one could reasonably imagine other core ones being used as
> well (exp, iat, nbf, jti, etc). An authorization request parameter being
> introduced that uses one of those names is far and away the most likely
> point of collision (and has already happened, as noted previously). A new
> JWT claim being introduced that collides with an existing authorization
> request parameter name AND would be used in the context of JAR is far far
> less likely to happen. So unlikely, in fact, that I don't think it's
> necessary or even useful to pollute the JWT claims registry with the names
> of all the authorization request parameters. I happen to be one of the DEs
> on the JWT claims registry so, in theory, I have some idea what I'm talking
> about here. In theory. And I do have to be upfront at this point and say
> that I will push back on a request for registration of a bunch of
> authorization request parameters into the JWT claims registry without
> without more compelling reason.
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._