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

[Nat Sakimura <[e-mail]>]

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",
>       "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.)

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.
The registry has

   - request_object_signing_alg
   - request_object_encryption_alg

besides others. Having said that, it is a bit obscure so I probably should
put some more explanation around it.

>
> Section 8
>
>    HTTP clients MUST also verify the TLS server certificate, using
>    subjectAltName dNSName identities as described in [RFC6125], to avoid
>    man-in-the-middle attacks.  The rules and guidelines defined in
>
> It's probably easier to just say "using DNS-ID [RFC6125], to avoid
> man-in-the-middle attacks".

Thanks. I will do so.

>
> 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.)

OIDC is an extension of OAuth and it should be fine as is.
What we need to be careful is that there will be no conflict going forward.
I will put the instruction update that will be provided by Mike (Jones).

>
> Section 10
>
> We probably also want to reference draft-ietf-oauth-jwt-bcp.

Thanks. I will put the reference as draft.

>
> 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?

Very good catch. It should be changed to align with other sections.

>
> 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.

You are right. This one should be removed.

>
>    (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.)

Thanks for pointing it out. Changing as follows would be ok?

(d) When Authorization Server is providing an endpoint that provides a
Request Object URI in exchange for a Request Object,
the Authorization Server MUST perform Client
Authentication to accept the Request Object and bind the Client
Identifier to the Request Object URI it is providing. Since
Request Object URI can be replayed, the lifetime of the Request
Object URI MUST be short and preferably one-time use. The
entropy of the Request Object URI MUST be sufficiently large.
The adequate shortness of the validity and the entropy of the
Request Object URI depends on the risk calculation based on the
value of the resource being protected. A general guidance for
the validity time would be less than a minute and the Request
Object URI is to include a cryptographic random value of 128bit
or more at the time of the writing of this specification.

>
>    (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?

Yes. I will add wording around it.

>
> Section 10.3
>
> I'm not entirely sure what "[t]he endpoints that come into question in
> this specification" is supposed to mean -- is it just "the OAuth 2.0
> endpoints presently defined in Standards-Track RFCs"?

Yes. RFC6749, RFC6750, and RFC8414.

>
>    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?

In the Authorization request.
I thought it would be too onerous to state

In [RFC6749], while Redirection URI is included in the Authorization
> Request,
> others are not included in the Authorization Request.  As the result, the
> same
> applies to Authorization Request Object.


Would you like to add "in the Authorization Request" as above?

>
> Section 10.4
>
> It's probably also worth citing the generic URI security considerations
> from RFC 3986, here.

I will do so. Thanks.

>
> 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.

Thanks. I will do so.

>
> 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.

So, I should probably expand the text.
The process is two steps:

1. (Certification Process) The TFP examines the business process of the
client and determines what claims they needs: This is the certification
process. Once the client is certified, then they are issued a client
credential to authenticate against to push request objects to the TFP to
get the request_uri.

2. (Translation Process) The client uses the client credential that it got
to push the request object to the TFP to get the request_uri.

>
> 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.

The third paragraph is also important from the privacy point of view.
In a trust framework that has a policy to only allow TFP vetted request
object,
then the Authorization Server must make sure that it was.
One way to do it is to check the authority 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").

Thanks. I will fix it.

>
>    Therefore, per-user Request Object URI should be avoided.
>
> nit: I think this is better as "static per-user Requeste Object URIs".

Thanks. I will fix it.

>
> Section 13
>
> Are there two different paragraphs for "contributions from the OAuth WG
> members"?  Are they reflecting different types of contribution?

Thanks. I have merged them.


> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en