Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwsreq-11.txt> (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)) to Proposed Standard

From: Denis <[email-masked]>
Date: Fri, 3 Feb 2017 12:10:57 +0100

*Comments on I-D Action: draft-ietf-oauth-jwsreq-11.txt*

Two editorial comments first :

1. Guidance is a mass noun, not a count noun, plural doesn't make sense. 
Please change "guidances" into "guidance" twice in Section 11.

2. In Section 12 : Please remove my name (Denis Pinkas) from this section.

Other comments:

3. Section 1.1 (from boiler plate) states: The key words "MUST", "MUST 
NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are 
to be interpreted as described in RFC 2119 [RFC2119].

There is not a single other occurrence of the word SHALL within this 
document. In such case, I wonder how this document can be normative.
There are however many (useful) "non-normative examples. A non-normative 
example does not replace requirements.

Section 4 states:

*A Request Object (Section 2.1) is used to provide authorization*

*request parameters for an OAuth 2.0 authorization request.It*

*contains OAuth 2.0 [RFC6749] authorization request parameters*

*including extension parameters**.*

**

RFC 6749 contains 75 pages, but does not contain a single occurrence of 
the wording "authorization request parameter" nor of "extension parameter".
There should be either references to one or more specific sections of 
this document or, even better, a list of the mandatory/recommended/possible
authorization request parameters as well as a list of 
mandatory/recommended/possible extension parameters should be included 
in this document.

A clear distinction should be made between the parameters used to 
authenticate the request and the other ones.

4. The introduction states on page 4:

      (a) (integrity protection) The request can be signed so that the 
integrity of the request can be checked;

This should be changed into:

      (a) (integrity protection) The request can be authenticated either 
using a digital signature or using encryption under a secret key
           so that the integrity of the request can be checked;

5. The introduction states on page 4:

(d) (collection minimization) The request can be *signed* by a third 
party attesting that the authorization request is compliant tocertain 
policy.

The request is not /signed/ by a third party.

However, later on, there is the following explanation:

In addition, it allows requests to be prepared by a third party so that 
a client application cannot request
    more permissions than previously agreed.

If it is the intent, the sentence should be rephrased as:

(d) (collection minimization) The request can be *verified* by a third 
party attesting that the authorization request is compliant tocertain 
policy.

6. Section 10.1. the text states:

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

The wording"with then considered appropriate algorithm"is too vague. 
This should be changed into:

*When sending the authorization request object through "request"*

*parameter, it MUST either be signed using JWS [RFC7515] or encrypted*

*using JWE [RFC7516] using a symmetric key algorithm.*

7. Section 10.2 states:

This means that the request object is going to be prepared fresh each

time an authorization request is madeand caching cannot be used.

What are the implications ? Is it required/recommended to use a nonce ? 
The text should be made clearer.

8. Section 10.3 states:

10.3.Request Source Authentication

The source of the Authorization Request MUST always be verified.

There are several ways to do it in this specification.

(a)Verifying the JWS Signature of the Request Object.

It seems that the case of using a JWE encrypted using a secret key 
algorithm has been forgotten here. Please add it.

9. Section 10.3 states at its very end:

An extension specification

should be created as a preventive measure to address potential

vulnerabilities that have not yet been identified.

Writing a document for vulnerabilities that have not yet been identified 
is speculative. It would rather be better
either to remove this sentence or to explain what is meant by it.

10. Section 11.1 states:

*11.1.Collection limitation*

**

*When the Client is being granted access to a protected resource*

*containing personal data, the Client SHOULD limit the collection of*

*personal data to that which is within the bounds of applicable law*

*and strictly necessary for the specified purpose(s).***

The /presentation/ of personal data should be limited whether or not the 
protected resource contains personal data.

It is proposed to change this text into:

*When the Client requests an access to a protected resource, the Client*

*SHOULD limit the presentation of personal data to that which is within *

*the bounds of applicable law and strictly necessary for the specified *

*purpose(s).***

11. Section 11.2.1 states:

11.2.1.Request Disclosure

This specification allows extension parameters.

It would be useful to name either all of them or some of them. RFC 6749 
is not crystal clear about this.

Denis Pinkas (DP Security Consulting SAS)

==============================================================

> The IESG has received a request from the Web Authorization Protocol WG
> (oauth) to consider the following document:
> - 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization
>     Request (JAR)'
>    <draft-ietf-oauth-jwsreq-11.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2017-02-13. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>     The authorization request in OAuth 2.0 described in RFC 6749 utilizes
>     query parameter serialization, which means that Authorization Request
>     parameters are encoded in the URI of the request and sent through
>     user agents such as web browsers.  While it is easy to implement, it
>     means that (a) the communication through the user agents are not
>     integrity protected and thus the parameters can be tainted, and (b)
>     the source of the communication is not authenticated.  Because of
>     these weaknesses, several attacks to the protocol have now been put
>     forward.
>
>     This document introduces the ability to send request parameters in a
>     JSON Web Token (JWT) instead, which allows the request to be JWS
>     signed and/or JWE encrypted so that the integrity, source
>     authentication and confidentiality property of the Authorization
>     Request is attained.  The request can be sent by value or by
>     reference.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>      rfc6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) (Informational - IETF stream)
>      rfc6819: OAuth 2.0 Threat Model and Security Considerations (Informational - IETF stream)
>      rfc6973: Privacy Considerations for Internet Protocols (Informational - IAB stream)
> Note that some of these references may already be listed in the acceptable Downref Registry.
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 06 Feb 2017 14:08:34 +0000

Thanks Denis. Here is my proposed disposition on your comments.

> Please change "guidances" into "guidance" twice in Section 11.

Accepted.
Thanks.

> 2. In Section 12 : Please remove my name (Denis Pinkas) from this section.

Accepted.

> "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
> be interpreted as described in RFC 2119 [RFC2119].
>
> Noted.
There are bunch of MUST. At IETF we usually prefer MUST to SHALL, unlike in
ISO.

>
>
> Section 4 states:
>
>
>
> *   A Request Object (Section 2.1) is used to provide authorization*
>
> *   request parameters for an OAuth 2.0 authorization request.  It*
>
> *   contains OAuth 2.0 [RFC6749] authorization request parameters*
>
> *   including extension parameters**.  *
>
>
>
> There should be either references to one or more specific sections of this
> document or, even better, a list of the mandatory/recommended/possible
> mandatory/recommended/possible extension parameters should be included in
> this document.
>
>

Reject.
There are 4 flows in RFC6749. In each flow, there is a sub-section
dedicated to the Authorization request.
In them, the parameters used in the authorization request are very clearly
indicated. For example,

4.1.1 <https://tools.ietf.org/html/rfc6749#section-4.1.1>.
Authorization Request

   The client constructs the request URI by adding the following
   parameters to the query component of the authorization endpoint URI ...

It is very difficult to miss.

Then, the possibility for the extension parameters are discussed in 8.2.
Needless to say, those extension parameters are going to be discussed in
other specifications.
Thus, it would be misleading just to say the parameters defined in 4.1.1,
4.2.1, etc.
As an editor, I feel better with the current language because it is at
least not wrong nor misleading.

> integrity of the request can be checked ;
>
>
>
>           so that the integrity of the request can be checked ;
>

Reject.
This paragraph is talking about the integrity protection and not the source
authentication.
And even for source authentication, saying that encryption under a secret
key is not accurate as it was discussed earlier in the WG mail.

I am not sure if "Introduction" needs to state everything that is explained
later. The idea of introduction probably is to give main points. The list
is not an exhaustive list of the benefit of using JWT as the authorization
request format. For example, being able to encrypt the request, which is
not listed there, has an advantage of preventing MITB to eavesdrop the
request. So I think it is ok as is.

> party attesting that the authorization request is compliant to certain
> policy.
>
> The request is not *signed* by a third party.
>
However, later on, there is the following explanation:
>
>
>
>    In addition, it allows requests to be prepared by a third party so
> that a client application cannot request
> party attesting that the authorization request is compliant to certain
> policy.
>
>
>
Reject
The third party indeed signs the request on behalf of the client as the
result of verification that the permission is the same as previously
agreed.

> *   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.*
>
>
>
> The wording" with then considered appropriate algorithm" is too vague.
> *   When sending the authorization request object through "request"*
>
> *   parameter, it MUST either be signed using JWS [RFC7515] or encrypted*
>
> *   using JWE [RFC7516] using a symmetric key algorithm.*
>
>
>
Reject.
In the above sentence, "*with then considered appropriate algorithm*"
 applies both on JWS and JWE.
The intent of the phrase is that a vulnerable algorithm should not be used.

Also, I do not understand why the algorithm has to be symmetric key
algorithm.

>    time an authorization request is made and caching cannot be used.
>
>
>
> Reject.
The implication is given right after the sentence. There is no variable
called "nonce" in RFC6749. Since this document is just defining another
encoding method for OAuth 2.0 authorization request as a framework, it does
not mandate these. An extension specification should define those
requirements.

>
>
> 8. Section 10.3 states:
>
>
>
> 10.3.  Request Source Authentication
>
>
>
>    (a)  Verifying the JWS Signature of the Request Object.
>
>
>
Accepted with modification.
You mean, symmetric key algorithm, is that right? I would add "or verifying
that the symmetric key for the JWE encryption is a correct one"

> either to remove this sentence or to explain what is meant by it.
Reject.
It is referring to the first paragraph of the sub-section. Also, precaution
when security is in question is a good thing.

> 10. Section 11.1 states:
>
>
>
> *11.1.  Collection limitation*
>
>
>
> *   When the Client is being granted access to a protected resource*
>
> *   containing personal data, the Client SHOULD limit the collection of*
>
> *   personal data to that which is within the bounds of applicable law*
>
> *   and strictly necessary for the specified purpose(s).*
>
>
>
> The *presentation* of personal data should be limited whether or not the

> *   When the Client requests an access to a protected resource, the Client*
>
> *   SHOULD limit the presentation of personal data to that which is within
> *
>
> *   the bounds of applicable law and strictly necessary for the specified *
>
> *   purpose(s).*
>
Reject.
You are not getting what OAuth does. The party that holds personal data is
the authorization server / resource.
It is not the client. The client is the party who is getting those
"resources" which may contain personal data.
Yes, the client can provide some personal data to the resource depending on
what that resource endpoint is, but that is out of scope for OAuth.
As far as OAuth is concerned, what is being sent from the client to the
resource is the access token.

> 11.2.1.  Request Disclosure
>
>
>
> It would be useful to name either all of them or some of them. RFC 6749 is
> not crystal clear about this.
>
Noted.
RFC6749 only defines how to define extension parameters.
This specification draws from OpenID Connect for some examples of extension
parameters such as nonce.
See section 4 for example.

> final comments on this action. Please send substantive comments to [email-masked] mailing lists by 2017-02-13. Exceptionally, comments may be
> The file can be obtained viahttps://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>
> IESG discussion can be tracked viahttps://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ballot/
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: Denis <[email-masked]>
Date: Thu, 9 Feb 2017 22:15:17 +0100

Hi Nat,

My replies to your proposed disposition of comments are embedded in the 
text.

> On Fri, Feb 3, 2017 at 8:11 PM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     3. Section 1.1 (from boiler plate) states: The key words "MUST",
>     "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
>     "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>     document are to be interpreted as described in RFC 2119 [RFC2119].
>
>     There is not a single other occurrence of the word SHALL within
>     this document. In such case, I wonder how this document can be
>     normative.
>     There are however many (useful) "non-normative examples. A
>     non-normative example does not replace requirements.
>
> Noted.
> There are bunch of MUST. At IETF we usually prefer MUST to SHALL, 
> unlike in ISO.
OK.
>
>      Section 4 states:
>
>     *A Request Object (Section 2.1) is used to provide authorization
>     request parameters for an OAuth 2.0 authorization request.It
>     contains OAuth 2.0 [RFC6749] authorization request parameters
>     including extension parameters**.*
>
>     RFC 6749 contains 75 pages, but does not contain a single
>     occurrence of the wording "authorization request parameter" nor of
>     "extension parameter".
>     There should be either references to one or more specific sections
>     of this document or, even better, a list of the
>     mandatory/recommended/possible
>     mandatory/recommended/possible extension parameters should be
>     included in this document.
>
> In them, the parameters used in the authorization request are very 
> clearly indicated. For example,
>
>
> Then, the possibility for the extension parameters are discussed in 
> 8.2. Needless to say, those extension parameters are going to be 
> discussed in other specifications.
> Thus, it would be misleading just to say the parameters defined in 
> 4.1.1, 4.2.1, etc.

draft-ietf-oauth-jwsreq-11states on page 7.

To sign, JSON Web Signature (JWS) [RFC7515] is used.The result is a

JWS signed JWT [RFC7519].If signed, the Authorization Request

Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience)

as members, with their semantics being the same as defined in the JWT

[RFC7519] specification.

To sign, JSON Web Signature (JWS) [RFC7515] is used.The result is a

JWS signed JWT [RFC7519].If signed, the Authorization Request

Object *MUST contain a client_id parameter* and SHOULD contain a
"iss" (issuer) *parameter* and an "aud" (audience) *parameter*, with
their semantics being the same as defined in the JWT RFC7519]
specification.

In section 5.2. Message Signature or MAC Validation, the text states:

When validating a JWS, the following steps are performed.

(...)

See Section 10.6 for security considerations on algorithm

validation.

There is no section 10.6 in this document. It seems to be section 10.3

Anyway, it is not the right place to place requirements in a security 
considerations section and the appropriate text
should be moved in the main body of the document.

RFC 6749 states in clause 4.Obtaining Authorization on page

6.2.JWS Signed Request Object

To perform JWS Signature Validation, the "alg" Header Parameter in

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

The important point is to provide guidance on how to map the 
client_idparameter with the appropriate key.
There is none at the present time.

Add:

Identifying the appropriate key MUST be done according to section 6
of RFC 7515 and using the Registered Header Parameter Names defined
in section 4.1 of RFC 7515, e.g. using the Header Parameters "jku",
"jwk", "kid", "x5u", "x5c", "x5t", or "x5t#S256".

>          (a) (integrity protection) The request can be signed so that
>     the integrity of the request can be checked;
>
>          (a) (integrity protection) The request can be authenticated
>     either using a digital signature or using encryption under a
>     secret key
> This paragraph is talking about the integrity protection and not the 
> source authentication.
> And even for source authentication, saying that encryption under a 
> secret key is not accurate as it was discussed earlier in the WG mail.
>
> I am not sure if "Introduction" needs to state everything that is 
> explained later. The idea of introduction probably is to give main 
> points. The list is not an exhaustive list of the benefit of using JWT 
> as the authorization request format. For example, being able to 
> encrypt the request, which is not listed there, has an advantage of 
> preventing MITB to eavesdrop the request. So I think it is ok as is.
>
Integrity protection cannot be verified without knowing the source of 
the information. Using encryption (which supports at the same time
an integrity service when secret keys are being used) is another way to 
be able to check the integrity of the request.

So I maintain may comment.

>     (d) (collection minimization) The request can be *signed* by a
>     third party attesting that the authorization request is compliant
>     tocertain policy.
>
>     (d) (collection minimization) The request can be *verified* by a
>     third party attesting that the authorization request is compliant
>     tocertain policy.
>
> Reject
> The third party indeed signs the request on behalf of the client as 
> the result of verification that the permission is the same as 
> previously agreed.

If it were the case, the client_id would indicate the name of the third 
party and the name of the user would be missing (or vice versa).

So I maintain my comment.

>     *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.*
>
>      The wording"with then considered appropriate algorithm"is too
>     vague. This should be changed into:
>
>     *When sending the authorization request object through "request"
>     parameter, it MUST either be signed using JWS [RFC7515] or encrypted
>     using JWE [RFC7516] using a symmetric key algorithm.*
>
>     Reject.
>

Maybe, this explains why you didn't understand the previous comment. 
With public key encryption, it is not possible to authenticate
the source of the request, while it is possible with secret key 
encryption when the encrypted data includes a cryptographic checksum
like a hash value and an error propagation method for the encryption 
algorithm.

So I maintain my comment.

>      What are the implications ? Is it required/recommended to use a
>     nonce ? The text should be made clearer.
>
> Reject.
> The implication is given right after the sentence. There is no 
> variable called "nonce" in RFC6749. Since this document is just defining
> another encoding method for OAuth 2.0 authorization request as a 
> framework, it does not mandate these.
> An extension specification should define those requirements.

Note that this section belongs to the security considerations section 
which SHOULD NOT be normative and should only provide guidance.

The sentence right after is the following:

It has a performance disadvantage, but where such disadvantage is

permissible, it should be considered.

It does not provide any guidance.

The key point is that a parameter able to detect replay needs to be 
included in the request. This should be indicated in the normative part.
It is unfortunate that RFC 7515 has not addressed replay protection of 
JWS and only mentions the problem is section 10.10 which is in the
security considerations section. Here it is:

10.10.Replay Protection

While not directly in scope for this specification, note that

applications using JWS (or JWE) objects can thwart replay attacks by

including a unique message identifier as integrity-protected content

in the JWS (or JWE) message and having the recipient verify that the

message has not been previously received or acted upon.

The text on page 7 should be changed into:

To sign, JSON Web Signature (JWS) [RFC7515] is used.The result is a
JWS signed JWT [RFC7519].If signed, the Authorization Request
Object *MUST contain a client_id parameter* *and a "nonce"* *extension
**parameter* *allowing to detect replay attacks *and SHOULD contain an 
"iss"
(issuer) *parameter* and an "aud" (audience) *parameter*, with their
semantics being the same as defined in the JWT specification[RFC7519].

Note that Page 7 uses the "nonce" parameter in the example.

    JSON Web Token Claims are listed at:
    https://www.iana.org/assignments/jwt/jwt.xhtml

"Nonce" is mentioned in OpenID Connect Core 1.0 incorporating errata set 1.

It is described as :

nonce

Value used to associate a Client session with an ID Token

This is too restrictive since now a nonce should be included in a JWS token.

The registration is as follows:

  * Parameter name: nonce
  * Parameter usage location: Authorization Request
  * Change controller: OpenID Foundation Artifact Binding Working Group
    - [email-masked]
  * Specification document(s): Section 3.1.2
    <http://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint>of
    this document
  * Related information: None

Section 3.1.2 states:

      3.1.2. Authorization Endpoint

The Authorization Endpoint performs Authentication of the End-User. This 
is done by sending the User Agent to the Authorization Server's
Authorization Endpoint for Authentication and Authorization, using 
request parameters defined by OAuth 2.0 and additional parameters
and parameter values defined by OpenID Connect.

Communication with the Authorization Endpoint MUST utilize TLS. See 
Section 16.17 
<http://openid.net/specs/openid-connect-core-1_0.html#TLSRequirements>for 
more information on using TLS

This has nothing to do with the nonce. Hence the nonce registration 
information has been badly defined.

The OpenID specification also states:

"The Client SHOULD check the noncevalue for replay attacks. The precise 
method for detecting replay attacks is Client specific".

This does not allow to interoperate.

Rather than correcting the registration information in the OpenID 
specification, it would be better to suppress it from the OpenID 
specification
and incorporate it within an IETF RFC.

In order to avoid nonces to be kept in a memory for ever, a good 
practice is to split the nonce in two parts:

  * one of them includes a UTC NumericDate using the format defined in
    RFC 7519,and
  * the other one includes a random number.

In this way only recent nonces (e.g. received during the last 5 minutes) 
need to be kept in memory.
Three or fourbytes for the random number will be sufficient.

In order to *allow for interoperability,* a format should be specified.

I propose a NumericDate defining the UTC time concatenated with a random 
number with three bytes.

"Nonce" has not been officially registered by IANA. An IANA 
Considerations section should be added in draft-ietf-oauth-jwsreq-*
*to register the "nonce" parameter.

On page 14, section 6.2., after the previous proposed text which is:

Identifying the appropriate key MUST be done according to section 6
of RFC 7515 and using the Registered Header Parameter Names defined
in section 4.1 of RFC 7515, e.g. using the Header Parameters "jku",
"jwk", "kid", "x5u", "x5c", "x5t", or "x5t#S256".

I proposed to add the following text:

To perform JWS Signature Validation, the "nonce" Header Parameter in

the JOSE Header MUST be present and MUST be checked to verify that
the signed request is not the replay of a previous signed request.

A section defining the nonce parameter should be added.

>      It seems that the case of using a JWE encrypted using a secret
>     key algorithm has been forgotten here. Please add it.
>
> You mean, symmetric key algorithm, is that right? I would add "or 
> verifying that the symmetric key for theJWE encryption is a correct one"

Accepted

>     Writing a document for vulnerabilities that have not yet been
>     identified is speculative. It would rather be better
> It is referring to the first paragraph of the sub-section. Also, 
> precaution when security is in question is a good thing.

This sentence is simply useless and thus should be deleted. Hence, I 
maintain this comment.

>     *When the Client is being granted access to a protected resource
>     containing personal data, the Client SHOULD limit the collection of
>     personal data to that which is within the bounds of applicable law
>     and strictly necessary for the specified purpose(s).***
>
>      The /presentation/ of personal data should be limited whether or
>     not the protected resource contains personal data.
>
>     *When the Client requests an access to a protected resource, the
>     Client
>     SHOULD limit the presentation of personal data to that which is within
>     the bounds of applicable law and strictly necessary for the specified
>     purpose(s).*
>
> Reject.
> You are not getting what OAuth does. The party that holds personal 
> data is the authorization server / resource.
> Yes, the client can provide some personal data to the resource 
> depending on what that resource endpoint is, but that is out of scope 
> for OAuth.
> As far as OAuth is concerned, what is being sent from the client to 
> the resource is the access token.

The dispute is whether the protected resource contains or not personal 
data.
The data contained by the protected resource may well be public data 
(or/and personal data).
It does not need to be only "personal data".

Hence, I maintain my comment.

>      It would be useful to name either all of them or some of them.
>     RFC 6749 is not crystal clear about this.
>
> Noted.
> This specification draws from OpenID Connect for some examples of 
> extension parameters such as nonce.

See my earlier comments where client_id and nonce shall be mandatory.

Denis
>>     [email-masked] <mailto:[email-masked]>  mailing lists by 2017-02-13. Exceptionally, comments may be
>>     sent [email-masked] <mailto:[email-masked]>  instead. In either case, please retain the
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 16 Feb 2017 02:04:23 +0900

Hi Denis,

Thought John's response went to you as well but apparently not.

My replies inline:

> My replies to your proposed disposition of comments are embedded in the
[snip]

>  Section 4 states:
>>
>>
>>
>>
>> *   A Request Object (Section 2.1) is used to provide authorization
>> request parameters for an OAuth 2.0 authorization request.  It    contains
>> OAuth 2.0 [RFC6749] authorization request parameters    including extension
>> parameters**.  *
>>
> 4.1.1 <https://tools.ietf.org/html/rfc6749#section-4.1.1>.  Authorization Request
>
> draft-ietf-oauth-jwsreq-11 states on page 7.
>
>
>
>    To sign, JSON Web Signature (JWS) [RFC7515] is used.  The result is a
>
>    JWS signed JWT [RFC7519].  If signed, the Authorization Request
>
>    To sign, JSON Web Signature (JWS) [RFC7515] is used.  The result is a
>
>    JWS signed JWT [RFC7519].  If signed, the Authorization Request
>
 I am kind of ok with the proposed text but if we do you want to single out
`client_id`, perhpas a reason should be added.
There are other REQIURED parameters in the Auhtorization Request defined in
RFC6749, you know.

> should be moved in the main body of the document.

Sorry, I cannot find the text you are refering to.

>
>
> RFC 6749 states in clause 4.  Obtaining Authorization on page
>
>
>
> 6.2.  JWS Signed Request Object
>
>
>
> The important point is to provide guidance on how to map the client_id
> parameter with the appropriate key.
> explained later. The idea of introduction probably is to give main points.
> The list is not an exhaustive list of the benefit of using JWT as the
> authorization request format. For example, being able to encrypt the
> request, which is not listed there, has an advantage of preventing MITB to
> eavesdrop the request. So I think it is ok as is.
>
> Integrity protection cannot be verified without knowing the source of the
> information.
>
Using encryption (which supports at the same time
> an integrity service when secret keys are being used) is another way to be
> able to check the integrity of the request.
>
>
>

I think the issue is that if you encrypt with a asymmetric algorithm then
the receiver has no idea who encrypted it.
If encrypted with a symmetric key (not secret key) then you know that it
came from someone who has access to that key.
That works because we only support AEAD encryption.

You can use asymmetric encryption but you need to sign first if you want to
know who it is from.

> party and the name of the user would be missing (or vice versa).

The value of `client_id` will be the requesting party.
The value of `iss` can be the third party.
But setting aside that, I guess your point actually is on the use of the
word "request". Authorization request is the entire thing that travels from
the client and not a part of it, and that is a fair point. Having said
that, I have a problem with your use of the word "verified". What about
this?

(d) (collection minimization) The data being requested can be *attested *by
> a third party that is compliant to collection minimization principle.
>

>> *   When sending the authorization request object through "request"
>> *   When sending the authorization request object through "request"
> Maybe, this explains why you didn't understand the previous comment. With
> public key encryption, it is not possible to authenticate
> the source of the request, while it is possible with secret key encryption
> when the encrypted data includes a cryptographic checksum

I understand this. My point is that this subsection is not talking about
what you just stated. This is a security consideration pointing out that an
alogrithm which has not become vulnerable must be used.

What you describe should instead go below the list (a)(b)(c) in section 5
or section 10.3.
"when symmetric keys are being used" probably is a bit too open to
interpretation. John is now creating a text on it.

> called "nonce" in RFC6749. Since this document is just defining

Does it not? It is providing a guidance that the implementation should
consider not using cached request and create the request afresh each time
so that the entire request can be signed etc.

> included in the request. This should be indicated in the normative part.

This security consideration is not about the replay attack but request
tampering.

It is unfortunate that RFC 7515 has not addressed replay protection of JWS
> and only mentions the problem is section 10.10 which is in the

> 10.10.  Replay Protection
>    To sign, JSON Web Signature (JWS) [RFC7515] is used.  The result is a
>    JWS signed JWT [RFC7519].  If signed, the Authorization Request
>    Object *MUST contain a client_id parameter* *and a "nonce"*
> *extension *   *parameter* *allowing to detect replay attacks *and SHOULD
> contain an "iss"

I agree that inclusion of nonce etc. to thwart the replay attack has to be
done in the normative section and not in the security consideration.
Having said that, as I stated before, this specification is just defining
another encoding for RFC6749. As the result, the replay protection etc. has
to be deferred to an extension spec, such as OIDC.

> JSON Web Token Claims are listed at: https://www.iana.org/
> assignments/jwt/jwt.xhtml
>
>    - Parameter name: nonce
>    - Parameter usage location: Authorization Request
>    - Change controller: OpenID Foundation Artifact Binding Working Group
>    - Specification document(s): Section 3.1.2
>    <http://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint>
>    of this document
>    - Related information: None
>
>
> Section 3.1.2 states:
> Authorization Endpoint for Authentication and Authorization, using request
> parameters defined by OAuth 2.0 and additional parameters
> <http://openid.net/specs/openid-connect-core-1_0.html#TLSRequirements>
> for more information on using TLS
>
>
>
> "The Client SHOULD check the nonce value for replay attacks. The precise

Out of scope for this specification.
Also, you should discuss something on OIDC on a sperarate list, not here.

>
>
> In order to avoid nonces to be kept in a memory for ever, a good practice
> is to split the nonce in two parts:
>
>    - one of them includes a UTC NumericDate using the format defined in
>    RFC 7519, and
>    - the other one includes a random number.
>
>
> Three or four bytes for the random number will be sufficient.
>
>
>
> "Nonce" has not been officially registered by IANA. An IANA Considerations
> section should be added in draft-ietf-oauth-jwsreq-
> to register the "nonce" parameter.
>

Everything related to nonce is out of scope. You should write a new I-D.

> A section defining the nonce parameter should be added.

[snip]

> Agree to disagree.

>> *    When the Client is being granted access to a protected resource
>> personal data to that which is within the bounds of applicable law    and
>> strictly necessary for the specified purpose(s).*
>>
>>  The *presentation* of personal data should be limited whether or not
>> the protected resource contains personal data.
>>
>> *   When the Client requests an access to a protected resource, the
>> Client    SHOULD limit the presentation of personal data to that which is
>> within    the bounds of applicable law and strictly necessary for the
>> specified    purpose(s).*
>>
> Reject.
> Yes, the client can provide some personal data to the resource depending
> on what that resource endpoint is, but that is out of scope for OAuth.
> I do not understand your comment now. Your previous proposeal seems to be
unrelated to the above comment.

> See my earlier comments where client_id and nonce shall be mandatory.
client_id is mandatory in RFC6749. Nonce is not defined in RFC6749 and
hence out of scope for this specification.

> Denis

[snip]

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

---

From: Denis <[email-masked]>
Date: Fri, 17 Feb 2017 21:51:18 +0100

Hi Nat,

Thank you for the forwarding of the detailed responses made by John.
Instead of replying between the lines, I have grouped my concerns under 
7 items that are detailed below.

======================================================================

ITEM 1

======================================================================

RFC 6749 states in section 10.2 (from the security considerations 
section on page 54):

The authorization server SHOULD NOT process repeated authorization 
requests automatically
(without active resource owner interaction) without authenticating the 
client or relying on other measures
to ensure that the repeated request comes from the original client and 
not an impersonator.

With such a vague guidance that are dozens of possibilities, none of 
them is being defined.

How would two implementations be able to interoperate ? The answer is 
simple: they can't.

Nevertheless, replay protection of a Token Request should be addressed 
in the current draft and presently it isn't.
In order to address this concern, I make a proposal.

An Authorization Server should be able to "easily" check (i.e. without 
losing to much computing time in order to decrease
the efficiency of DoS attacks) whether a Token Request is a replay or 
not from a previous Token Request.

ISO/IEC 10181-2:1996 (Information technology -- Open Systems 
Interconnection -- Security frameworks for open systems:
Authentication framework) published more than 20 years ago defines two 
methods: the use of challenges or the use of unique numbers.
Unique numbers are also called "nonces" (as a contraction of "number 
once") but their meaning is fully different from the meaning made by
the OpenID Connect Core specification, since a unique number as defined 
in that specification is in fact a "challenge" as defined by ISO/IEC 
10181-2.

Hereafter is the definition of a nonce as defined in the OpenID Connect 
Core specification:

nonce

String value used to associate a Client session with an ID Token, and to 
mitigate replay attacks. The value is passed through unmodified
from the Authentication Request to the ID Token. If present in the ID 
Token, Clients MUST verify that the nonceClaim Value is equal to
µthe value of the nonceparameter sent in the Authentication Request. If 
present in the Authentication Request, Authorization Servers MUST
include a nonceClaim in the ID Token with the Claim Value being the 
nonce value sent in the Authentication Request. Authorization Servers
SHOULD perform no other processing on noncevalues used. The noncevalue 
is a case sensitive string.

A unique number (according to ISO/IEC 10181-2) is generated by a client 
and is used by a server to check the freshness of a request
without the need for the server to remember it more than a couple or a 
dozen of minutes. It is composed of a UTC time and a random number.
A unique number is generated by the client and checked by the 
Authorization Server.

Similarly, in order to allow a Client to verify that the Access Token 
corresponds to the content of the Authorization Request,
some data SHOULD be included in the Access Token.

The OpenID Connect Core specification has defined a "nonce" that allows 
to perform the second check, but not to perform the first one.

In order to avoid the Authorization Server to remember unique numbers 
(as defined in ISO/IEC 10181-2) for ever, each Authorization Request needs
to contain a UTC time, so that unique numbers that are out of a time 
window (of, let us say, a couple or a dozen of minutes) can be removed
from the memory the Authorization Server.

Fortunately, RFC 7519, Section 4.1.6 has defined "iat" which means 
"Issued At".

This means that the Authorization Request as defined in the draft 
specification SHALL contain a unique number that consists of
both a "iat" parameter and a random number.

Let us call that second parameter "rdn" for "random number" and let us 
register it at IANA it /within this future RFC/ as a being an int32,
which is quite sufficient for the intended purpose.

rdn

Integer value used by a Client in an Authentication Request for two 
purposes. Firstly, when associated with a "iat" parameter,
to allow an Authorization Server to detect the replay of an 
Authentication Request and secondly to allow a Client to check
the freshness of an Access Token. In order to detect the replay of an 
Authentication Request, the Authorization Server MUST
be able to (a) use a local clock loosely synchronized with the UTC, and 
(b) construct a table where the "iat" parameter and
the "rdn" parameter from each well-formed and accepted Authentication 
Request are memorized. Only the "iat" parameters
and the "rdn" parameters received during a short time window (e.g. a 
couple or dozen of minutes) need to be memorized.

After checking that the Authentication Request is well formed, its 
processing SHOULD continue by checking that the "iat" parameter.
If the "iat" parameters is outside the time window, the Authentication 
Request SHALL be discarded by the Authorization Server.
If the "iat" parameters is inside the time window, the Authorization 
Server SHALL check if the "iat" parameter associated
with that "rdn" parameter are not already memorized in the table. If it 
is the case, the Authentication Request SHALL be discarded
by the Authorization Server. Otherwise, the Authentication Request is 
not a replay of a previous Authentication Request and
the processing of the Authentication Request SHOULD continue.

The value of the rdn parameter is passed through unmodified from the 
Authentication Request to the Authorization Server.
It MAY be included in the Access Token by the Authorization Server. If 
present in the Access Token, Clients MUST verify
that the rdn Claim Value is equal to the value of the rdn parameter sent 
in the Authentication Request and if it is not the case,
the Access Token SHALL be discarded.

Note that this allows to optimize the number of parameters without the 
need to use the nonce parameter (as defined in the OpenID Connect Core 
specification)
which is not defined in any RFC for the moment.

The end result of this argumentation is that the Authorization Request - 
as defined in this draft specification -
SHALL contain both an "iat" parameter and a "rdn" parameter. Please take 
a look at the next item before expressing a position on this item.

======================================================================

ITEM 2

======================================================================

Nat: The implementer of this document needs to consult RFC6749 closely 
anyway as all the verification requirements still holds,
so as an editor, I would rather keep it as it is. It is not "reader 
friendly" but cannot go wrong with the approach to just referencing RFC6749.

John: There are 4 flows in RFC6749. In each flow, there is a sub-section 
dedicated to the Authorization request.
In them, the parameters used in the authorization request are very 
clearly indicated. (...) Thus, it would be misleading just to say
the parameters defined in 4.1.1, 4.2.1, etc. As an editor, I feel better 
with the current language because it is at least not wrong nor misleading.

I proposed:

John:  I am kind of ok with the proposed text but if we do you want to 
single out `client_id`, perhaps a reason should be added.
There are other REQUIRED parameters in the Authorization Request defined 
in RFC6749, you know.

The mandatory parameters to be included in the request should be 
identified. They are composed of :

(a)the common denominator of the REQUIRED parameters defined in 4.1.1, 
4.2.1, etc,

(b)the parameters that are necessary to address the detection of the 
replay of previous well-formed requests, and

(c)the parameters that are necessary to address the detection of the 
replay of a previous well-formed token.

The common denominator of the REQUIRED parameters defined in 4.1.1, 
4.2.1, etc, is the client_id parameter (indicated as "REQUIRED").

The parameters that are necessary to address the detection of the two 
cases of replay are the "iat" and the "rdn" parameters.

As a reader, I feel better to know which parameters are REQUIRED, 
leaving other details in RFC 6749.

As a conclusion, the draft should indicate that the following parameters 
are always REQUIRED: client_id, iat and rdn.

Hence my proposal:

*Object MUST contain a "client_id" parameter, i.e. **a string 
representing the registration information
provided by the end-user that is unique to the authorization server,**an 
"iat" parameter and
a "rdn" parameter and SHOULD contain a "iss" (issuer) parameter and an 
"aud" (audience) parameter,
with their semantics being the same as defined in the JWT [RFC7519] 
specification.*

======================================================================

ITEM 3

======================================================================

Nat: ABC attack is out of scope for OAuth. It is not a new attack. The 
resource owner handing a bearer token
to another party willfully is not a threat in the bearer token model.

Nat: ABC attack is out of scope of RFC 6749 and RFC6750. They can be 
dealt with in POP document but not this one.

Denis: RFC 6749 (The OAuth 2.0 Authorization Framework) has been 
published in October 2012. RFC 6819 (OAuth 2.0 Threat Model and Security 
Considerations)
has been published in January 2013, hence after RFC 6749, so RFC 6749 
could not reference RFC 6819. /The carriage had been placed before the 
horse/.

RFC 6819 implicitly talks about the ABC attack in section 5.1.6:

5.1.6.Access Tokens

The following measures should be used to protect access tokens:

(...).

oEnsure that client applications do not share tokens with 3rd parties.

You said:"They can be dealt with in POP document".

Unfortunately, at the present time, this is not the case.

The key point is that none of the documents issued by the OAuth WG 
(neither by the Tokbind WG) indicates how to
"Ensure that client applications do not share tokens with 3rd parties".

The charter of the Tokbind WG (unbearable) states (see: 
https://datatracker.ietf.org/wg/tokbind/charter) :

"It is a goal of this working group to enable defense against attacks 
that involve unauthorized replay of security tokens.
Other issues associated with the use of security tokens are out of scope".

However, draft-ietf-tokbind-protocol-13 (The Token Binding Protocol 
Version 1.0) /issued yesterday/ explicitly states:

The Token Binding protocol does not prevent cooperating clients from

sharing a bound token. A client could intentionally export a bound

token with the corresponding Token Binding private key, or perform

signatures using this key on behalf of another client.

So neither the OAuth WG nor the TokBind WG have, at this time, a draft 
that is potentially able to counter the ABC attack.

So saying that the "ABC attack is out of scope for OAuth" is not the 
right wording.
Saying that the "ABC attack has not been taken into consideration for 
OAuth 2.0" is *a fact*.
That *fact *should not be hidden in the current draft.

Since it is unlikely that RFC 6819 will be soon replaced by another RFC, 
it is necessary to mention that threat in the security considerations 
section.
This does not mean that this threat shall be solved in the current 
draft, but readers should be aware that the ABC attack is not countered 
using this draft.

A text along the following one should be added into the security 
consideration section:

In case of a cooperation between clients, the format of the JWT Secured 
Authorization Request
described in this document does not prevent a client from asking a token 
to an Authorization Server
that, once being obtained, may be successfully passed from one client to 
another one without
the resource server to which it is intended being able to notice it.

Note that a /different/ format of a signed request would be one piece of 
a puzzle able to solve it.

======================================================================

ITEM 4

======================================================================

Hereafter is another topic both about the "client_id" and "collection 
minimization" which apparently do not related to each other
... but they do as it is explained below.

1) The draft states:

I commented:

The important point is to provide guidance on how to map the client_id 
parameter with the appropriate key. There is none at the present time.

I suggested to add:

Identifying the appropriate key MUST be done according to section 6 of 
RFC 7515
and using the Registered Header Parameter Names defined in section 4.1 
of RFC 7515,
e.g. using the Header Parameters "jku", "jwk", "kid", "x5u", "x5c", 
"x5t", or "x5t#S256".

There was no comment/opinion from John about this proposal.

2)About "collection minimization"

The introduction states on page 4:

(d) (collection minimization) The request can be signed by a third party
attesting that the authorization request is compliant to certain
policy.

In addition, it allows requests to be prepared by a third party
so that a client application cannot request more permissions
than previously agreed.

John explained:

But setting aside that, I guess your point actually is on the use of the 
word "request". Authorization request is the entire thing that travels
from the client and not a part of it, and that is a fair point. Having 
said that, I have a problem with your use of the word "verified". What 
about this?

(d) (collection minimization) The data being requested can be
attested by a third party that is compliant to collection
minimization principle.

3) Denis proposal to solve this comment:

After:

*The signature MUST be validated against the appropriate key for that 
"client_id" and algorithm.*

I suggest to add:

*Identifying the appropriate key MUST be done according to section 6 of 
RFC 7515
and using the Registered Header Parameter Names defined in section 4.1 
of RFC 7515,
e.g. using the Header Parameters "jku", "jwk", "kid", "x5u", "x5c", 
"x5t", or "x5t#S256".
That key may be either associated with the client_id which is a **string 
unique to the authorization
server representing the registration information originally provided by 
the end-user or
***associated *with a third party with which the authorization server 
has a trust relationship with it. ***

I also propose to change item d) in the following way:

(d) (collection minimization) The request can be signed by a third party
*rather than by an end-user *attesting that the authorization request
is compliant to certain policy. (...)

======================================================================

ITEM 5

======================================================================

One the following issue, I believe that I agree with John on the 
rational. However, John was unclear whether he accepted the proposed change
or an alternative one capturing the same concept.

The introduction states on page 4:

(a) (integrity protection) The request can be authenticated either using 
a digital signature or using encryption under a secret key
so that the integrity of the request can be checked;

Reject.

I am not sure if "Introduction" needs to state everything that is 
explained later. The idea of introduction probably is to give main points.
The list is not an exhaustive list of the benefit of using JWT as the 
authorization request format. For example, being able to encrypt
the request, which is not listed there, has an advantage of preventing 
MITB to eavesdrop the request. So I think it is ok as is.

the information.

Using encryption (which supports at the same time an integrity service 
when secret keys are being used) is another way to be able to check the 
integrity of the request.

John: I think the issue is that if you encrypt with a asymmetric 
algorithm then the receiver has no idea who encrypted it.

Denis response: That is correct.

John: If encrypted with a symmetric key (not secret key) then you know 
that it came from someone who has access to that key. That works because 
we only support AEAD encryption.

Denis response: That is correct (/except than for me, since a symmetric 
key is a perfect synonym for a secret key/) :-)

John: You can use asymmetric encryption but you need to sign first if 
you want to know who it is from.

Denis response: It does not matter.

My proposal is to change the sentence into:

(a) (integrity protection) The request can be authenticated either using 
a digital signature or using encryption
under a /symmetric/ key so that the integrity of the request can be checked;

If you believe something should be changed in that proposal, please make 
another proposal.

======================================================================

ITEM 6

======================================================================

10. Section 11.1 states:

*11.1. Collection limitation

*

*When the Client is being granted access to a protected resource**
containing personal data, the Client SHOULD limit the collection of
personal data to that which is within the bounds of applicable law
    and strictly necessary for the specified purpose(s).*

  The /presentation/ of personal data should be limited whether or not 
the protected resource contains personal data.

We have trouble to understand each other.

1° This condition applies at the time of the request, not at the time of 
the granting.

2° The protected resource may contain either personal data or public 
data or both, so there is no need to specify "personal data".

3° Personal data is /presented /by the client, it is not /collected/.

In blue, you have the changes I propose:

*When the Client requests an access to a protected resource containing
personal data, the Client SHOULD limit the presentation of personal
data to that which is within the bounds of applicable law and strictly 
necessary
for the specified purpose(s).*

======================================================================

ITEM 7

======================================================================

John: This specification draws from OpenID Connect for some examples of 
extension parameters such as nonce.

On page 16 the text states:

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

The key point is whether it is appropriate */in the main body of this 
document/ *to provide examples that include parameters
such as "nonce" and "max_age" that are not described in any RFC. The 
text does not even indicate where these extensions
are coming from. It would be more appropriate to use extensions that are 
defined in IETF RFCs.

Since the replay protection of the request MUST be achieved, remove 
*"nonce": "n-0S6_WzA2Mj**"*and replace it with:

*   "iat": 1487354400*

*   "rdn": 7945123 *

remove: *"max_age": 86400*

*
*

and finally remove: *N**ote that it includes extension**variables such 
as "nonce" and "max_age".

*

Denis

> On Fri, Feb 10, 2017 at 6:15 AM, Denis <[email-masked] 
>     My replies to your proposed disposition of comments are embedded
>     in the text.
>
> [snip]
>
>>          Section 4 states:
>>
>>         occurrence of the wording "authorization request parameter"
>>         nor of "extension parameter".
>>         There should be either references to one or more specific
>>         sections of this document or, even better, a list of the
>>         A clear distinction should be made between the parameters
>>         used to authenticate the request and the other ones.
>>
>>
>>     Reject.
>>     There are 4 flows in RFC6749. In each flow, there is a
>>     sub-section dedicated to the Authorization request.
>>     In them, the parameters used in the authorization request are
>>     very clearly indicated. For example,
>>
>>
>>             4.1.1
>>             <https://tools.ietf.org/html/rfc6749#section-4.1.1>.
>>             Authorization Request
>>
>>
>>
>>     Then, the possibility for the extension parameters are discussed
>>     in 8.2. Needless to say, those extension parameters are going to
>>     be discussed in other specifications.
>>     Thus, it would be misleading just to say the parameters defined
>>     in 4.1.1, 4.2.1, etc.
>>     As an editor, I feel better with the current language because it
>>     is at least not wrong nor misleading.
>
>  I am kind of ok with the proposed text but if we do you want to 
> single out `client_id`, perhpas a reason should be added.
> There are other REQIURED parameters in the Auhtorization Request 
> defined in RFC6749, you know.
>
>     Anyway, it is not the right place to place requirements in a
>     security considerations section and the appropriate text
>>              (a) (integrity protection) The request can be signed so
>>         that the integrity of the request can be checked;
>>
>>              (a) (integrity protection) The request can be
>>         authenticated either using a digital signature or using
>>         encryption under a secret key
>>     This paragraph is talking about the integrity protection and not
>>     the source authentication.
>>     And even for source authentication, saying that encryption under
>>     a secret key is not accurate as it was discussed earlier in the
>>     WG mail.
>>
>>     explained later. The idea of introduction probably is to give
>>     main points. The list is not an exhaustive list of the benefit of
>>     using JWT as the authorization request format. For example, being
>>     able to encrypt the request, which is not listed there, has an
>>     advantage of preventing MITB to eavesdrop the request. So I think
>>     it is ok as is.
>>
>     Integrity protection cannot be verified without knowing the source
>     of the information.
>
>     an integrity service when secret keys are being used) is another
>     way to be able to check the integrity of the request.
>
> I think the issue is that if you encrypt with a asymmetric algorithm 
> then the receiver has no idea who encrypted it.
> If encrypted with a symmetric key (not secret key) then you know that 
> it came from someone who has access to that key.
> You can use asymmetric encryption but you need to sign first if you 
> want to know who it is from.
>
>
>>         (d) (collection minimization) The request can be *signed* by
>>         a third party attesting that the authorization request is
>>         compliant tocertain policy.
>>
>>         In addition, it allows requests to be prepared by a third
>>         party so that a client application cannot request
>>         (d) (collection minimization) The request can be *verified*
>>         by a third party attesting that the authorization request is
>>         compliant tocertain policy.
>>
>>     Reject
>>     The third party indeed signs the request on behalf of the client
>>     as the result of verification that the permission is the same as
>>     previously agreed.
>
>     If it were the case, the client_id would indicate the name of the
>     third party and the name of the user would be missing (or vice versa).
>
>
> But setting aside that, I guess your point actually is on the use of 
> the word "request". Authorization request is the entire thing that 
> travels from the client and not a part of it, and that is a fair 
> point. Having said that, I have a problem with your use of the word 
> "verified". What about this?
>>
>>     (d) (collection minimization) The data being requested can be
>>     *attested *by a third party that is compliant to collection
>>     minimization principle.
>>
>
>
>>          The wording"with then considered appropriate algorithm"is
>>         too vague. This should be changed into:
>>
>>     In the above sentence, "*with then considered appropriate
>>     algorithm*"  applies both on JWS and JWE.
>>     Also, I do not understand why the algorithm has to be symmetric
>>     key algorithm.
>
>     Maybe, this explains why you didn't understand the previous
>     comment. With public key encryption, it is not possible to
>     authenticate
>     like a hash value and an error propagation method for the
>     encryption algorithm.
>
>
> I understand this. My point is that this subsection is not talking 
> about what you just stated. This is a security consideration pointing 
> out that an alogrithm which has not become vulnerable must be used.
>
> What you describe should instead go below the list (a)(b)(c) in 
> section 5 or section 10.3.
>>          What are the implications ? Is it required/recommended to
>>         use a nonce ? The text should be made clearer.
>>
>>     Reject.
>     Note that this section belongs to the security considerations
>     section which SHOULD NOT be normative and should only provide
>     guidance.
>
> consider not using cached request and create the request afresh each 
> time so that the entire request can be signed etc.
>
>     The key point is that a parameter able to detect replay needs to
>     be included in the request. This should be indicated in the
>     normative part.
>
>
>     It is unfortunate that RFC 7515 has not addressed replay
>     protection of JWS and only mentions the problem is section 10.10
>     which is in the
>     *extension
>     **parameter* *allowing to detect replay attacks *and SHOULD
>     contain an "iss"
> I agree that inclusion of nonce etc. to thwart the replay attack has 
> to be done in the normative section and not in the security 
> consideration.
> Having said that, as I stated before, this specification is just 
> defining another encoding for RFC6749. As the result, the replay 
> protection etc. has to be deferred to an extension spec, such as OIDC.
>
>
>         <https://www.iana.org/assignments/jwt/jwt.xhtml>
>
>       * Change controller: OpenID Foundation Artifact Binding Working
>         Group - [email-masked]
>         <mailto:[email-masked]>
>     The Authorization Endpoint performs Authentication of the
>     End-User. This is done by sending the User Agent to the
>     Authorization Server's
>     Communication with the Authorization Endpoint MUST utilize TLS.
>     See Section 16.17
>     This has nothing to do with the nonce. Hence the nonce
>     registration information has been badly defined.
>
>     "The Client SHOULD check the noncevalue for replay attacks. The
>     precise method for detecting replay attacks is Client specific".
>
>       * one of them includes a UTC NumericDate using the format
>         defined in RFC 7519,and
>     In this way only recent nonces (e.g. received during the last 5
>     minutes) need to be kept in memory.
>     I propose a NumericDate defining the UTC time concatenated with a
>     random number with three bytes.
>
>     This sentence is simply useless and thus should be deleted. Hence,
>     I maintain this comment.
>
>
> Agree to disagree.
>
>
>>         10. Section 11.1 states:
>>
>>          The /presentation/ of personal data should be limited
>>         whether or not the protected resource contains personal data.
>>
>>         *When the Client requests an access to a protected resource,
>>         the Client
>>     You are not getting what OAuth does. The party that holds
>>     personal data is the authorization server / resource.
>>     It is not the client. The client is the party who is getting
>>     those "resources" which may contain personal data.
>>     depending on what that resource endpoint is, but that is out of
>>     scope for OAuth.
>>     As far as OAuth is concerned, what is being sent from the client
>>     to the resource is the access token.
>
>     The dispute is whether the protected resource contains or not
>     personal data.
>     The data contained by the protected resource may well be public
>     data (or/and personal data).
> I do not understand your comment now. Your previous proposeal seems to 
> be unrelated to the above comment.
>
>
>>         **
>>
>>          It would be useful to name either all of them or some of
>>         them. RFC 6749 is not crystal clear about this.
>>
>>     Noted.