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

Hi Nat,

Now it is my turn to apologize for taking a long time.

I think I see the general direction these changes are going in, and it's a
reasonable approach to the unfortunate situation we find ourselves in with
respect to JWT claims vs. OAuth parameters.  In effect, what we're doing is
making a "profile" (for lack of a better term) of JWT, that leverages the
mechanisms and algorithms of JWT but uses a different registry for
interpreting the claims in the token (that is, OAuth Parameters vs. JWT
Claims).  We can tell that this "profile" of JWT is being used because of
the context in which the JWT is transferred/received: if it's the "request"
parameter, that's part of the definition of the OAuth Parameter, and if
it's the result of dereferencing a "request_uri", the
application/oauth.authz.req+jwt media-type clearly indicates how the
contents should be interpreted.

However, the changes in the -20 do not give the reader much of any hint as
to this being what's expected to happen, and that stock RFC 7519 JWT is
*not* what's in use.  So I'd request that we take a close look at how the
document uses "JWT" vs. "JWT encoding" (etc.); add an explicit statement
that while the JWT encoding is in use, the contents are to be interpreted
by interpreting the JWT claims as OAuth Parameters (and not as per the IANA
registry of JWT claims); and add some discussion (similar to the above)
about how the application context makes it unambiguous whether the
JWT-encoded claims are standard JWT claims or OAuth Parmaters as per this
document.

With respect to my second ("discuss discuss") point, Nat and I did have a
discussion in-person and I accept that there may be some scenarios in which
skipping the authorization dialogue is appropriate, so the example can
remain.

Moving on from my Discuss position, I do get the sense from the ongoing
discussion on the list that there's not clear agreement about the current
formulation that requires all parameters (but "request" and "request_uri")
to be in the JAR, especially with respect to "client_id" that might be
needed to unpack the JAR in some cases!  So I'm not sure whether the WG
wants to bring the document back to the WG to iron out those issues before
it returns to the IESG.  I'm a little reluctant to switch my position to
"No Objection" until we have a clearer picture of what the WG wants to do
on this front -- in my understanding, we can't really publish the document
without at least some solution ("client_id") for the encrypted-request
key-lookup case.

Thanks,

Ben

On Sun, Oct 27, 2019 at 10:12:50AM +0100, Nat Sakimura wrote:
> 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 <noreply@ietf.org>:
> 
> > 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
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en