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

[n-sakimura <[e-mail]>]

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.

On Fri, Jul 26, 2019 at 12:23 PM Nat Sakimura <[e-mail]> wrote:

>
> Thanks very much for the comments.
> Here are my responses to your comments.
>
> On Wed, Jul 3, 2019 at 2:59 PM Benjamin Kaduk via Datatracker <
> [e-mail]> wrote:
> >
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-oauth-jwsreq-19: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > 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.
>
> The simplest solution probably is to register the authorization request
> parameters to the JWT Claims registry.
> According to my checking, the relevant but not yet registered parameters
> are:
>
> 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
>
> > Relatedly, using "application/jwt" as the Content-type of the
> > HTTP response from dereferencing the request_uri with no explicit
> > indication of the type/profile of JWT used (whether in the content type
> > or in the JWT claims themselves) gives some risk of misinterpretation of
> > the content..  Consider, for example, when that request_uri is
> > dereferenced not by the authorization server in the process of
> > fulfilling an authorization request, but instead by some other service
> > that expects a different type of JWT.
>
> I am making the change to "application/oauth-authz-req+jwt" and add IANA
> request.
>
> >
> > This second point is a "discuss discuss" -- it's an important question
> > and I'd like to talk about it, but it's not clear that any change to the
> > document will be needed.
> >
> > The introduction notes as an advantage of JWT that:
> >
> >    (d)  (collection minimization) The request can be signed by a third
> >         party attesting that the authorization request is compliant with
> >         a certain policy.  For example, a request can be pre-examined by
> >         a third party that all the personal data requested is strictly
> >         necessary to perform the process that the end-user asked for,
> >         and statically signed by that third party.  The authorization
> >         server then examines the signature and shows the conformance
> >         status to the end-user, who would have some assurance as to the
> >         legitimacy of the request when authorizing it.  In some cases,
> >         it may even be desirable to skip the authorization dialogue
> >         under such circumstances.
> >
> > I'm pretty uncomfortable about suggesting that the authorization
> > dialogue can/should be skipped; do we need to keep this example?
> >
>
> I have actually deliberately put this text as there seem to be some
> disconnect between the engineering community and the privacy regulators
> community. Asking for "consent" is something that should be considered as
> an exception and should use other lawful basis if possible as UK ICO (The
> data protection regulator in the UK) advises. As the editor of "ISO/IEC
> 29184 Privacy notice and consent", which is being developed with close
> coordination with regulators such as European Data Protection Board, I
> would have to agree to that position and I took OAuth JAR as one of the
> opportunity to call it out. I will add some text explaining it such as:
>
> In some cases, it is deemed harmful to ask for consent when it is not
> necessary: i.e., the processing is performed under other lawful basis than
> consent, as it would make the consent, that should be an exception, stand
> out less. Under such circumstances, this mechanism can be used to skip the
> authorization dialogue.
>
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 1
> >
> >    While it is easy to implement, the encoding in the URI does not allow
> >    application layer security with confidentiality and integrity
> >    protection to be used.  While TLS is used to offer communication
> >
> > nit: this wording is a little hard to read; it might be easier to
> > reorder to "does not allow application layer security to be used to
> > provide confidentiality and integrity protection".
>
> Thanks. I will make the change.
>
> >
> >    The use of application layer security allows requests to be prepared
> >    by a third party so that a client application cannot request more
> >    permissions than previously agreed.  This offers an additional degree
> >    of privacy protection.
> >
> > (side note) what would an example of such a third party be.  (We already
> > have the resource owner, the client, and the authorization server ...
> > maybe it's a fourth party?)
>
> It is a fourth party, e.g., a trust framework provider or an information
> fiduciary.
> The text need to be modified though as I found an error.
> Since now all the OAuth Request parameters must be in the request object,
> only the pattern that can be supported for something like this is to push
> the request object to the TFP and have the TFP check if it meets the policy
> and return request_uri only it is evelauted as OK.
>
> >
> >    Furthermore, the request by reference allows the reduction of over-
> >    the-wire overhead.
> >
> > We only barely mentioned by-reference at this point (one line in the
> > Abstract), so I'd suggest "passing the request by reference".
>
> Thanks. I will make the change.
>
> >
> >    (4)  its development status that it is an RFC and so is its
> >         associated signing and encryption methods as [RFC7515] and
> >         [RFC7516]
> >
> > nit: I'd suggest "its development status as a Proposed Standard, along
> > with the associated signing and encryption methods [RFC7515] [RFC7516]."
>
> Thanks. I will make the change.
>
> >
> >    (c)  (confidentiality protection) The request can be encrypted so
> >         that end-to-end confidentiality can be provided even if the TLS
> >         connection is terminated at one point or another.
> >
> > nit: TLS is always terminated at or before the user-agent, though.  So
> > maybe the user agent needs to get called out here as well (there could
> > of course be TLS termination earlier than the user-agent in some cases,
> > too).
>
> Thanks. I will make the change.
>
> >
> >    2.  When the client does not want to do the crypto.  The
> >        Authorization Server may provide an endpoint to accept the
> >        Authorization Request through direct communication with the
> >        Client so that the Client is authenticated and the channel is TLS
> >        protected.
> >
> > How can you "not want to do [the] crypto" but still be doing TLS (with
> > crypto)?  Perhaps we're looking for "not want to pay the additional
> > overhead of JWS/JWE cryptography on top of TLS"?
>
> Thanks. I will make the change.
>
> >
> > Section 1.1
> >
> > RFC 8174 has updated BCP 14 boilerplate text to use.
>
> Thanks. I will make the change.
>
> >
> > Section 3
> >
> > nit: should this section be 2.3 to get wrapped into "terminology"?
>
> It could, but I suppose it could be as is.
>
> >
> > It might also be worth putting references in for the terms, though they
> > are largely common knowledge at this point.
>
> Hopefully, they are public knowledge ...
>
> >
> > Section 4
> >
> >    A Request Object (Section 2.1) is used to provide authorization
> >    request parameters for an OAuth 2.0 authorization request.  It MUST
> >    contains all the OAuth 2.0 [RFC6749] authorization request parameters
> >    including extension parameters.  The parameters are represented as
> >
> > nit: "all the parameters" kind of sounds like "all that are defined"..
> > But I think the intent here is "any parameter used to process the
> > request must come from the request object and URL query parameters are
> > ignored", so maybe "MUST contain all the parameters (including extension
> > parameters) used to process the OAuth 2.0 [RFC6749] authorization
> > request; parameters from other sources MUST NOT be used", akin to what
> > we say down in Sections 5 and 6.3..
> > But we need to be careful about the wording to not exclude the usage of
> > the "request" and "request_uri" query parameters to  find the Request
> > Object!
>
> Thanks. I will make the description more exact.
>
> >
> >    the JWT claims.  Parameter names and string values MUST be included
> >
> > nit: maybe "the JWT claims of the object"?
>
> Thanks. I will probably make it "the JWT claims of the request object."
>
> >
> >    any extension parameters.  This JSON [RFC7159] constitutes the JWT
> >    Claims Set defined in JWT [RFC7519].  The JWT Claims Set is then
> >    signed or signed and encrypted.
> >
> > nit: I  think we want "This JSON [RFC7159] object".
>
> Thanks. I will fix it as suggested.
>
> >
> > (Long quote incoming)
> >
> >    The following is an example of the Claims in a Request Object before
> >    base64url encoding and signing.  Note that it includes extension
> >    variables such as "nonce" and "max_age".
> >
> >      {
> >       "iss": "s6BhdRkqt3",
> >       "aud": "https://server..example.com <https://server.example.com>",
> >       "response_type": "code id_token",
> >       "client_id": "s6BhdRkqt3",
> >       "redirect_uri": "https://client..example.org/cb
> <https://client.example.org/cb>",
> >       "scope": "openid",
> >       "state": "af0ifjsldkj",
> >       "nonce": "n-0S6_WzA2Mj",
> >       "max_age": 86400
> >      }
> >
> >    Signing it with the "RS256" algorithm results in this Request Object
> >    value (with line wraps within values for display purposes only):
> >
> >      eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
> >      F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
> >      c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
> >      JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
> >      bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
> >      Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
> >      ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
> >      ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
> >      Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
> >      wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
> >      ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
> >      sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
> >      dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
> >      luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
> >      F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
> >      KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
> >      0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
> >      ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
> >      iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
> >
> > Decoding the base64 of the body, we see:
> > {
> >  "iss": "s6BhdRkqt3",
> >  "aud": "https://server.example.com",
> >  "response_type": "code id_token",
> >  "client_id": "s6BhdRkqt3",
> >  "redirect_uri": "https://client.example.org/cb
> <https://client..example.org/cb>",
> >  "scope": "openid",
> >  "state": "af0ifjsldkj",
> >  "nonce": "n-0S6_WzA2Mj",
> >  "max_age": 86400,
> >  "claims":
> >   {
> >    "userinfo":
> >     {
> >      "given_name": {"essential": true},
> >      "nickname": null,
> >      "email": {"essential": true},
> >      "email_verified": {"essential": true},
> >      "picture": null
> >     },
> >    "id_token":
> >     {
> >      "gender": null,
> >      "birthdate": {"essential": true},
> >      "acr": {"values": ["urn:mace:incommon:iap:silver"]}
> >     }
> >   }
> > }
> >
> > I'm not sure where the "claims" claim is coming from -- 6749 doesn't
> > seem to talk about it.  (Note that this example is used later on as
> > well.)
>
> It is an extension parameter that is registered in the OAuth authorization
> request registry.
> It is defined in OpenID Connect Core and OIDF is in the process of
> registering it to the JWT Claims registry as well. I have put them to show
> that extension parameters can also be used in the request object. Having
> said that, they may be confusing. I should just remove them.
>
> >
> > Section 5.2.1
> >
> >    It is possible for the Request Object to include values that are to
> >    be revealed only to the Authorization Server.  As such, the
> >    "request_uri" MUST have appropriate entropy for its lifetime.  For
> >    the guidance, refer to 5.1.4.2.2 of [RFC6819].  It is RECOMMENDED
> >    that it be removed after a reasonable timeout unless access control
> >    measures are taken.
> >
> > It sounds like a link to https://www.w3.org/TR/capability-urls/ might
> > also be useful.
> >
>
> Thanks. I will add it.
>
> > Section 5.2.2
> >
> > Do we want to remind the reader that the other query parameters are just
> > for backwards compatibility?
>
> It is probably be better to remove them as they are not allowed to be
> used.
>
> >
> > Section 5.2.3
> >
> >    The following is an example of this fetch process:
> >
> >      GET /request.jwt HTTP/1.1
> >      Host: tfp.example.org
> >
> > It's useful to show good hygeine in examples; can we get the extra
> > entropy in this request that we have in the previous example(s)?
>
> Thanks for pointing out. I will fix it. (The previous example also needs
> to be changed.)
>
> >
> > Section 6.2
> >
> >    The Authorization Server MUST perform the signature validation of the
> >    JSON Web Signature [RFC7515] signed request object.  For this, the
> >    "alg" Header Parameter in its JOSE Header MUST match the value of the
> >    pre-registered algorithm..  The signature MUST be validated against
> >    the appropriate key for that "client_id" and algorithm.
> >
> > Does "the pre-registered algorithm" concept exist in the specs outside
> > of draft-ietf-oauth-jwt-bcp?
>
> Yes. RFC7591 combined with some of the OAuth Dynamic Client Registration
> Metadata registry forms the concept. RFC7591 allows clients to register the
> claims that is in the OAuth Dynamic Client Registration Metadata registry