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

[Nat Sakimura <[e-mail]>]

Hi

Took a long time but finally all the changes needed to resolve the DISCUSS
comments are (hopefully) applied as -20.

There is one change that impacts the process: the draft now has IANA
request so it needs to be referred back to IANA.

The IETF datatracker status page for this draft is:
datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

Best,

Nat Sakimura

2019年7月3日(水) 4:21 Benjamin Kaduk via Datatracker <[e-mail]>:

> 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:
> ----------------------------------------------------------------------
>
> This 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.
>
> Once this (and some of the more substantive items in the Comment
> section) is resolved, I'd be happy to ballot Yes.
>
> 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?
> Maybe just talking about what an expected use case could be would
> help alleviate my unease.
>
>
> ----------------------------------------------------------------------
> 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".
>
>    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?)
>
>    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".
>
>    (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]."
>
>    (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).
>
>    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"?
>
> Section 1.1
>
> RFC 8174 has updated BCP 14 boilerplate text to use.
>
> Section 3
>
> nit: should this section be 2.3 to get wrapped into "terminology"?
>
> It might also be worth putting references in for the terms, though they
> are largely common knowledge at this point.
>
> 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!
>
>    the JWT claims.  Parameter names and string values MUST be included
>
> nit: maybe "the JWT claims of the 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".
>
> (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",
>       "response_type": "code id_token",
>       "client_id": "s6BhdRkqt3",
>       "redirect_uri": "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",
>  "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.)
>
> 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.
>
> Section 5.2.2
>
> Do we want to remind the reader that the other query parameters are just
> for backwards compatibility?
>
> 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)?
>
> 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?
>
> Section 9
>
> The error codes we list in Section 7 are already registered, for the
> OIDC usage.  Do we want to say anything about that?   (I guess it would
> be disallowed by process to try to update the existing registration to
> also point at this document.)
>
> Section 10
>
> We probably also want to reference draft-ietf-oauth-jwt-bcp.
>
> Section 10.1
>
>    When sending the authorization request object through "request"
>    parameter, it MUST either be signed using JWS [RFC7515] or encrypted
>    using JWE [RFC7516] with then considered appropriate algorithm.
>
> Up in Section 5 we only allow (a) signed and (b) signed then encrypted;
> similarly, in Section 4 we reiterate "signed then encrypted".  Why is it
> okay to talk about just "signed or encrypted" here?
>
> Section 10.2
>
>    (b)  Verifying that the symmetric key for the JWE encryption is the
>         correct one if the JWE is using symmetric encryption.
>
> Similarly to the previous point, you also need to check the signature,
> which will always be there.
>
>    (d)  Authorization Server is providing an endpoint that provides a
>         Request Object URI in exchange for a Request Object.  In this
>
> I don't think this is a complete sentence (and it's definitely not a
> parallel construction with (a)-(c)!).  I think perhaps a crisp one-line
> summary of this method would be "Delegating the authorization check to a
> separate "Request Object to Request Object URI" endpoint on the
> Authorization Server".  (The writing in the rest of this paragraph could
> also use an editing pass.)
>
>    (e)  A third party, such as a Trust Framework Provider, provides an
>         endpoint that provides a Request Object URI in exchange for a
>         Request Object.  The same requirements as (b) above apply.  In
>         addition, the Authorization Server MUST know out-of-band that
>         the Client utilizes the Trust Framework Operator.
>
> The Authorization Server also has to trust the third-party provider to
> actually do its job and not misbehave, right?
>
> Section 10.3
>
> I'm not entirely sure what "[t]he endpoints ithat come into question in
> this specification" is supposed to mean -- is it just "the OAuth 2.0
> endpoints presently defined in Standards-Track RFCs"?
>
>    In [RFC6749], while Redirection URI is included, others are not
>    included in the Authorization Request.  As the result, the same
>    applies to Authorization Request Object.
>
> nit: included in what?
>
> Section 10.4
>
> It's probably also worth citing the generic URI security considerations
> from RFC 3986, here.
>
> Section 10.4.1
>
>    "request_uri", and (d) do not perform recursive GET on the
>    "request_uri".
>
> nit: remove the "do" in order to make the construction parallel.
>
> Section 12.1
>
>    It is often hard for the user to find out if the personal data asked
>    for is strictly necessary.  A Trust Framework Provider can help the
>    user by examining the Client request and comparing to the proposed
>    processing by the Client and certifying the request.  After the
>    certification, the Client, when making an Authorization Request, can
>    submit Authorization Request to the Trust Framework Provider to
>    obtain the Request Object URI.
>
> side note: In my head the act of certification was the act of making the
> translation to a Request Object URI, so I'm kind of curious where my
> vision differs from reality.
>
> The third paragraph seems to mostly just be describing the procedure of
> how this flow works, which would not necessarily be specific to the
> privacy considerations section.
>
> Section 12.2.2
>
>    Even if the protected resource does not include a personally
>    identifiable information, it is sometimes possible to identify the
>    user through the Request Object URI if persistent per-user Request
>    Object URI is used.  A third party may observe it through browser
>
> nit: need an article for "persistent per-user Request Object URI" (or
> make it plural, as "URIs are used").
>
>    Therefore, per-user Request Object URI should be avoided.
>
> nit: I think this is better as "static per-user Requeste Object URIs".
>
> Section 13
>
> Are there two different paragraphs for "contributions from the OAuth WG
> members"?  Are they reflecting different types of contribution?
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en