Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-jwsreq

From: Denis <[email-masked]>
Date: Tue, 3 Jan 2017 17:52:22 +0100

Hello,

I have only recently subscribed to this mailing list and hence I was not 
present when the WGLC was launched on this document.

I have several concerns and comments about this draft :

*1°. The draft will be unable to move to Draft Standard*

The Intended status of draft-ietf-oauth-jwsreq is Standards Track.

RFC 5657 states: Advancing a protocol to Draft Standard requires 
documentation of the *interoperation *and implementation *o**f the 
protocol.*

The goal of RFC standard Track document is define *interoperable 
protocols, *hence not simply to define the syntax of a request leaving
dozens of possibilities about the treatment of the parameters that may 
be included in the request to the AS.

Generally speaking, the text is silent about the treatment of _every_ 
parameter of the JAR. In particular, what kind of verification and 
processing
SHALL be done by the Authorization Server on "aud", since both "iss" and 
"aud" SHOULD be present (see page 6) in the Authorization Request.

The document currently fails to *clearly indicate which parameters of 
the JAR are used by the Authorization Server to validate the JAR itself
and which parameters are used to build the requested access token*.

For example, is the "aud" parameter supposed to identify the AS or the RS ?

This means that the text should be sufficiently clear so that two 
different implementations can interoperate. This will not be the case if 
the text stays like this.

The goal of Standard Tracks RFCs is not to define frameworks but 
*interoperable protocols.*

In addition to this major concern, I have other concerns:

*2°. Security consideration: the Alice and Bob Collaboration attack (ABC 
attack)*

Since the time RFC 6819 was written, a new kind of attack has been 
mentioned on the WG mailing list:
the ABC attack (*Alice and Bob Collaboration attack*) where Bob accepts 
to collaborate with Alice to get an access token that Alice will then be 
able to use.

There is no external attacker, but only two users who agree to 
collaborate to cheat an application server.
It is a major problem typically when an access token only contains a 
claim like "older then 18".

This kind of attack is not mentioned in this draft, nor if it can be 
countered in the context of RFC 6749 (OAuth 2.0 Authorization Framework).

It would not be reasonable to consider the Alice and Bob Collaboration 
attack as being out of scope of the OAuth 2.0 Authorization Framework;
or ... if it is, this should be clearly stated in the abstract and in 
the security considerations section.

But in the later case, this would be as if a security hole would be left 
out of the scope of the OAuth 2.0 Authorization Framework.

OAuth was designed from a perspective that there is a trust relationship 
between the AS and RS so that things like AT token format were left 
unspecified.
This is a major design error. As long as the AT token format will be 
left unspecified, it will not be possible to counter the ABC attack.

JAR is applicable to all kinds of OAuth authorization request. It is 
considered as just another kind of encoding instead of query parameters.
In case query parameters are being transmitted within the URL, the ABC 
attack remains. So the ABC attack is not specific to this document only,
but to all this series of documents. :-(

Readers might think that the authentication of authorization requests 
solves one left opened security issue but in practice it does not.
Hence, this document can mislead many readers.

IMO, in order to counter the ABC attack it is first necessary to specify 
one or more token syntax and the trust relationships :

-between the token requestor and the AS,

-between the AS ands the RS, and

-between the token requestor and the RS,

The global security picture is governed by:

-the two ways protocol between the token requestor and the AS, as well 
as the format the access token request and the processing of each of its 
parameters by the AS,

-the construction of each of parameter of the access token by the AS,

-the two ways protocol between the token requestor and the RS, as well 
as the format of the access token itself and the validation of each of 
its parameters by the RS,

*3°.**Privacy consideration: Authorization Servers may be able to act as 
Big Brother*

Section 11 (Privacy Considerations) does not contain text to explain 
that an Authorization Server might be able to act as Big Brother
if it is able to know where each access token it issues will be used. 
The use of a audience parameter without any semantics in it should be 
recommended.

Other people have already pointed it out.

Basically, in this context, trust means that a user A trusts a server 
/_B for doing some actions C_/ (and not for any kind of action).
Thus, a user A can trust a server B to provide him with a subset of his 
attributes in an access token but he does not necessarily trust
that same server B to keep private the list of the servers where he will 
use this access token (if B would be in a position to know
the identity of these resource servers).

OpenID Connect is based on OAuth 2.0. OpenID Connect does either take 
into consideration this privacy issue.

*4°. Minors issues (when compared to the others):*

1) The abstract states:

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.

(...)

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.

Since the main purpose is integrity protection and authentication, the 
JAR SHALL be signed and MAY be encrypted.

Replace with:

(...) which allows the request to be JAR to be signed and optionally 
encrypted (...)

2) On page 9 the text states:

The authorization request object MUST be either

(a)  JWS signed; or

(b)  JWE encrypted; or

(c)  JWS signed and JWE encrypted.

This should be replaced by:

The authorization request object MUST be either

(a)  JWS signed;

(b) JWE encrypted (when secret keys are being used); or

(c)  JWS signed and JWE encrypted.

4) On page 14, in section 6.3, the text states:

the Authorization Server then validates the request as specified in 
OAuth 2.0 [RFC6749].

This is rather vague, since no specific section from RFC 6749 is being 
pointed at.RFC 6749 is a framework with many options.
In the context of this draft, it would be beneficial to indicate which 
kind processing of the JAR parameters shall be done by the Authorization 
Server.
This issue clearly relates to the first major issue: interoperability.

Denis

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 03 Jan 2017 17:36:46 +0000

Hi,

Comments inline:

2017年1月4日(水) 1:52 Denis <[email-masked]>:

> dozens of possibilities about the treatment of the parameters that may be
> included in the request to the AS.
>
> Generally speaking, the text is silent about the treatment of *every*
> The document currently fails to
> *clearly indicate which parameters of the JAR are used by the
> Authorization Server to validate the JAR itself and which parameters are
> used to build the requested access token*.
>
> The goal of Standard Tracks RFCs is not to define frameworks but *interoperable
> protocols.*
>

It is interoperabole, in so much as RFC6749 and RFC7515 is.

> There is no external attacker, but only two users who agree to collaborate
> to cheat an application server.
> It is a major problem typically when an access token only contains a claim
> like "older then 18".
>
> or ... if it is, this should be clearly stated in the abstract and in the
> security considerations section.
>
>
> This is a major design error. As long as the AT token format will be left
> unspecified, it will not be possible to counter the ABC attack.
>

I disagree. In OAuth, AS and RS has pre-defined relationship - they are
tightly bound together and knows how to interpret/resolve the access token.
Access token format is totally out of scope of OAuth.

> considered as just another kind of encoding instead of query parameters.

Indeed it is.

> but to all this series of documents. :-(

ABC attack is out of socpe 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.

> Hence, this document can mislead many readers.

OAuth is not a federated authentication protocol.
OAuth is not even a federated authorization protocol by itself. You need to
build a profile upon it to do so.

> -          between the token requestor and the AS,
>
> -          between the AS ands the RS, and
>
> -          between the token requestor and the RS,
>

Sorry, but they are out of scope of this document as ABC attack is out of
scope of RFC6749 and RFC6750. They can be dealt with in POP document but
not this one.

> -          the two ways protocol between the token requestor and the AS,
> as well as the format the access token request and the processing of each
> of its parameters by the AS,
>
> -          the construction of each of parameter of the access token by
> the AS,
>
> -          the two ways protocol between the token requestor and the RS,
> as well as the format of the access token itself and the validation of each
> of its parameters by the RS,
>
>
>

That depends on the security assumptions. You should challenge RFC6749 and
not this document. This document merely provides another encoding for the
authorization request so that the request can be integrity protected and
source authenticated.

>
>
> *3°.* *Privacy consideration: Authorization Servers may be able to act as
> Big Brother*
>
>
>
> Section 11 (Privacy Considerations) does not contain text to explain that
> an Authorization Server might be able to act as Big Brother
> if it is able to know where each access token it issues will be used. The
> use of a audience parameter without any semantics in it should be
> recommended.
>
>
>
> Basically, in this context, trust means that a user A trusts a server *B
> for doing some actions C* (and not for any kind of action).

There is no notion of "his attributes" in OAuth. You seem to be conflating
general OAuth framework with some kind of identity protocols.

> the identity of these resource servers).

Big Brother or "calling home problem" is very well known, but as I have
pointed out earlier, in OAuth, the authorization server and resource
servers are tightly bound together, so it is not a problem. In this kind of
model, if you cannot trust your authorization server, you had better stop
using it altogether instead of asking for "better privacy". The consequence
of using an untrusted authorization server is much more grave.

>
> OpenID Connect is based on OAuth 2.0. OpenID Connect does either take into
> consideration this privacy issue.
>

OpenID Connect is a federated identity protocol built upon OAuth 2.0 and
that's why it is considering these privacy issues. OAuth does not need to
do the same.

> While it is easy to implement, it means that (a) the communication through
> the user agents are not integrity protected
>
> This document introduces the ability to send request parameters in a JSON
> Web Token (JWT) instead, which allows
>
> Since the main purpose is integrity protection and authentication, the JAR
> SHALL be signed and MAY be encrypted.
>
> Replace with:
>

As far as the integrity protection is concerned, JWE covers it.
For the source authentication, if the JWE uses symmetric key, it is also
covered.
So, JWS is not always required.

>    (c)  JWS signed and JWE encrypted.

That's acceptable. (Thanks for amending your proposal after several private
exchanges.)

> pointed at.
> RFC 6749 is a framework with many options.

Indeed it would be beneficial, but is also error prone. The implementer of
this document needs to consult RFC6749 closely anyways as all the
verificaiton 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.

Nat

>
>
> Denis
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: John Bradley <[email-masked]>
Date: Tue, 3 Jan 2017 16:45:10 -0300

Snip
> On Jan 3, 2017, at 2:36 PM, Nat Sakimura <[email-masked]> wrote:
> 
>  
> 
>  
> That's acceptable. (Thanks for amending your proposal after several private exchanges.)  
> 

Secret is not a clear term to use.  It should be JWE encrypted (when symmetric keys are bing used)  
The private part of a RSA keypair is also secret.

John B.

---

From: "Nat Sakimura" <[email-masked]>
Date: Wed, 4 Jan 2017 15:41:48 +0900

Yes, indeed. And when I wrote "acceptable", I meant "in principle", not
verbatim ;-)

Nat

--

PLEASE READ :This e-mail is confidential and intended for the

named recipient only. If you are not an intended recipient,

please notify the sender  and delete this e-mail.

From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, January 4, 2017 4:45 AM
To: Nat Sakimura <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-jwsreq

Snip

On Jan 3, 2017, at 2:36 PM, Nat Sakimura <[email-masked]
<mailto:[email-masked]> > wrote:

   (a)  JWS signed; or

   (b)  JWE encrypted; or

   (a)  JWS signed; 

 

Secret is not a clear term to use.  It should be JWE encrypted (when
symmetric keys are bing used)  

John B.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 4 Jan 2017 21:09:10 -0600

> *interoperable protocols.*

While I applaud the goal of interoperability, I must raise the big flag
that no one said anything about "Draft Standard" for this document,
and RFC 6410 eliminates the "Draft Standard" status.  And from a pragmatic
point of view, if it is necessary to first specify a framework before
one can get consensus to specify something fully specified and interoperable,
then that's a fine step to take.  So, I'm not sure that I'm convinced by
this particular item from your list.

-Ben

---

From: Denis <[email-masked]>
Date: Thu, 5 Jan 2017 22:07:32 +0100

Hello  Nat,

I have several text proposals to accommodate my previous comments.

1. On page 4, delete :

**

*The parameters "request" and "request_uri" are introduced as*

*additional authorization request parameters for the OAuth 2.0*

*[RFC6749] flows.The "request" parameter is a JSON Web Token (JWT)*

*[RFC7519] whose JWT Claims Set holds the JSON encoded OAuth 2.0*

*authorization request parameters.This JWT is integrity protected*

*and source authenticated using JWS.*

and move it after the first paragraph of section 4 where this text belongs.

2. At the very end of the Introduction on Page 5, add :

*This document defines the syntax of the JAR but does not define the 
semantics of every parameter of the request nor the way the 
Authorization Server shall process each parameter of the request. As a 
consequence, the document defines a framework for protecting the 
parameters of the token request, but does not specify how to construct 
an access token using the parameters of the request. This document used 
alone does not allow for interoperability. Additional documents are needed.*

3. On page 7, replace:

***To encrypt, JWE [RFC7516] is used.Unless the algorithm used in JWE*

*allows for the source to be authenticated, JWS signature should also*

*be applied.*

by:

*To encrypt, JWE [RFC7516] is used.Unless the algorithm used in JWE*

*uses symmetrical cryptography and thus allows for the source to be 
authenticated, JWS signature should also be applied.*

4. In section 5, on page 9 replace:

*The authorization request object MUST be either*

**

*(a)JWS signed; or *

*(b)JWE encrypted; or *

*(c)JWS signed and JWE encrypted.*

by:

*The authorization request object MUST be either*

**

*(a)JWS signed using an asymmetrical algorithm; or *

*(b)JWE encrypted using a symmetrical algorithm; or *

*(c)JWS signed using an asymmetrical algorithm and JWE encrypted using an 
asymmetrical algorithm.*

5. In section 6.3 on page 14, ad at the very end of this section:

*This document does not define how the parameters of the request should 
be processed. *

6. On page 16, at the end of section 10 add:

*10.5.Alice and Bob collaboration attack*

**

*This is an attack towards the Authorization server where Bob works in 
collaboration with Alice in order to obtain an access token that Alice 
could then use. Integrity protection and authentication of the source of 
the communication of the JAR is not sufficient to counter that type of 
attack. *

7. On page 18, at the end of section 11 add:

*11.3. No disclosure to the AS where the access tokens will be used*

**

*One of the request parameters of the JAR may indicate where the
access token to be issued shall be used (e.g. using an "aud"
parameter). If this parameter is specified as a URL, the
Authorization Server will be able to know exactly where each access
token it issues will be used. It is thus recommended to use a value
that contains no semantics and that changes for every access token
request.*

**

In addition, there are two typos:

8. On page 1 in the abstract, change :

*authentication and confidentiallity property of the Authorization*

into:

*authentication and confidentiality property of the Authorization*

9. On page 17, section 11.1 change:

***Provider.Then, the Auhtorization Server issues HTTP GET request to*

into:

*Provider.Then, the Authorization Server issues HTTP GET request to*

Denis

> Hi,
>
> Comments inline:
>
> 2017年1月4日(水) 1:52 Denis <[email-masked] 
> <mailto:[email-masked]>>:
>
>     Hello,
>
>     I have only recently subscribed to this mailing list and hence I
>     was not present when the WGLC was launched on this document.
>
>
>     dozens of possibilities about the treatment of the parameters that
>     may be included in the request to the AS.
>
>     Generally speaking, the text is silent about the treatment of
>     _every_ parameter of the JAR. In particular, what kind of
>     verification and processing
>
>     SHALL be done by the Authorization Server on "aud", since both
>     "iss" and "aud" SHOULD be present (see page 6) in the
>     Authorization Request.
>
>     The document currently fails to *clearly indicate which parameters
>     of the JAR are used by the Authorization Server to validate the
>     JAR itself
>     different implementations can interoperate. This will not be the
>     case if the text stays like this.
>
>     *2°. Security consideration: the Alice and Bob Collaboration
>     attack (ABC attack)*
>
>     the ABC attack (*Alice and Bob Collaboration attack*) where Bob
>     accepts to collaborate with Alice to get an access token that
>     Alice will then be able to use.
>
>     It is a major problem typically when an access token only contains
>     a claim like "older then 18".
>
>     This kind of attack is not mentioned in this draft, nor if it can
>     be countered in the context of RFC 6749 (OAuth 2.0 Authorization
>     Framework).
>
>     It would not be reasonable to consider the Alice and Bob
>     Collaboration attack as being out of scope of the OAuth 2.0
>     Authorization Framework;
>     or ... if it is, this should be clearly stated in the abstract and
>     in the security considerations section.
>
>
>     But in the later case, this would be as if a security hole would
>     be left out of the scope of the OAuth 2.0 Authorization Framework.
>
>
>     OAuth was designed from a perspective that there is a trust
>     relationship between the AS and RS so that things like AT token
>     format were left unspecified.
>     This is a major design error. As long as the AT token format will
>     be left unspecified, it will not be possible to counter the ABC
>     attack.
>
>
> I disagree. In OAuth, AS and RS has pre-defined relationship - they 
> are tightly bound together and knows how to interpret/resolve the 
> access token.
>     JAR is applicable to all kinds of OAuth authorization request. It
>     is considered as just another kind of encoding instead of query
>     parameters.
>
>
> Indeed it is.
>
>     In case query parameters are being transmitted within the URL, the
>     ABC attack remains. So the ABC attack is not specific to this
>     document only,
> ABC attack is out of socpe 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.
>
>     Readers might think that the authentication of authorization
>     requests solves one left opened security issue but in practice it
>     does not.
> OAuth is not even a federated authorization protocol by itself. You 
> need to build a profile upon it to do so.
>
>     IMO, in order to counter the ABC attack it is first necessary to
>     specify one or more token syntax and the trust relationships :
>
> Sorry, but they are out of scope of this document as ABC attack is out 
> of scope of RFC6749 and RFC6750. They can be dealt with in POP 
> document but not this one.
>
>     -the two ways protocol between the token requestor and the AS, as
>     well as the format the access token request and the processing of
>     each of its parameters by the AS,
>
>     -the two ways protocol between the token requestor and the RS, as
>     well as the format of the access token itself and the validation
>     of each of its parameters by the RS,
>
>
> That depends on the security assumptions. You should challenge RFC6749 
> and not this document. This document merely provides another encoding 
> for the authorization request so that the request can be integrity 
> protected and source authenticated.
>
>     *3°.**Privacy consideration: Authorization Servers may be able to
>     act as Big Brother*
>
>     Section 11 (Privacy Considerations) does not contain text to
>     explain that an Authorization Server might be able to act as Big
>     Brother
>     if it is able to know where each access token it issues will be
>     used. The use of a audience parameter without any semantics in it
>     should be recommended.
>
>     Basically, in this context, trust means that a user A trusts a
>     server /_B for doing some actions C_/ (and not for any kind of
>     action).
>     Thus, a user A can trust a server B to provide him with a subset
>     of his attributes in an access token but he does not necessarily
>     trust
>
>
> There is no notion of "his attributes" in OAuth. You seem to be 
> conflating general OAuth framework with some kind of identity protocols.
>
>     that same server B to keep private the list of the servers where
>     he will use this access token (if B would be in a position to know
> Big Brother or "calling home problem" is very well known, but as I 
> have pointed out earlier, in OAuth, the authorization server and 
> resource servers are tightly bound together, so it is not a problem. 
> In this kind of model, if you cannot trust your authorization server, 
> you had better stop using it altogether instead of asking for "better 
> privacy". The consequence of using an untrusted authorization server 
> is much more grave.
>
>     OpenID Connect is based on OAuth 2.0. OpenID Connect does either
>     take into consideration this privacy issue.
>
>
> OpenID Connect is a federated identity protocol built upon OAuth 2.0 
> and that's why it is considering these privacy issues. OAuth does not 
> need to do the same.
>
>     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
>
>     Since the main purpose is integrity protection and authentication,
>     the JAR SHALL be signed and MAY be encrypted.
>
>     Replace with:
>
>     (...) which allows the request to be JAR to be signed and
>     optionally encrypted (...)
>
>
> For the source authentication, if the JWE uses symmetric key, it is 
> also covered.
>     the Authorization Server then validates the request as specified
>     in OAuth 2.0 [RFC6749].
>
>
>     This is rather vague, since no specific section from RFC 6749 is
>     being pointed at.
>     In the context of this draft, it would be beneficial to indicate
>     which kind processing of the JAR parameters shall be done by the
>     Authorization Server.
> Indeed it would be beneficial, but is also error prone. The 
> implementer of this document needs to consult RFC6749 closely anyways 
> as all the verificaiton 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.
>
> Nat
>
>
>
>     Denis
>
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 6 Jan 2017 16:25:47 -0500

Hello,

I have added this document to the telechat on 2/2 and can bump it out
further if needed.  The comments that are outstanding should be addressed
and a new draft published.  Once there is agreement on the updates and the
version has been published, I'll start IETF last call.

Thank you & happy new year!
Kathleen

On Wed, Dec 28, 2016 at 11:27 AM, Kathleen Moriarty <
[email-masked]> wrote:

> Hi Nat,
>
> Thank you for the updates.  Please let me know when you publish a new
> version.  I'll start last call after the new year.  inline.
>
> On Tue, Dec 27, 2016 at 7:57 PM, Nat Sakimura <[email-masked]> wrote:
>
>> Hi
>>
>> Sorry to have taken so long to respond -- too much travel.
>>
>
> I hope you are able to rest a bit!
>
>
>>
>> My responses inline.
>>
>> On Sat, Oct 29, 2016 at 12:39 AM Kathleen Moriarty <
>> [email-masked]> wrote:
>>
>>> Hello,
>>>
>>> I just reviewed draft-ietf-oauth-jwsreq, and it looks great and seems to
>>> be a nice addition to help with security.  Thanks for your work on it.
>>>
>>> I only have a few comments.
>>>
>>> The first is just about some wording that is awkward in the TLS section.
>>>
>>> What's there now:
>>>
>>> Client implementations supporting the Request Object URI method MUST
>>>    support TLS as recommended in Recommendations for Secure Use of
>>>    Transport Layer Security (TLS) and Datagram Transport Layer Security
>>>    (DTLS) [RFC7525].
>>>
>>> How about:
>>>
>>> Client implementations supporting the Request Object URI method MUST
>>>    support TLS following Recommendations for Secure Use of
>>>    Transport Layer Security (TLS) and Datagram Transport Layer Security
>>>    (DTLS) [RFC7525].
>>>
>>> Not a major change and just editorial, so take it or leave it.
>>>
>>
>> Accepted as presented in my personal copy.
>> See: https://bitbucket.org/Nat/oauth-jwsreq/commits/0de915b22f13
>>
>>
>>>
>>> 2. In section 10, the introduction sentence leaves me wondering where
>>> the additional attacks against OAuth 2.0 should also have a pointer in this
>>> sentence:
>>>
>>>    In addition to the all the security considerations discussed in OAuth
>>>    2.0 [RFC6819], the following security considerations should be taken
>>>    into account.
>>>
>>>
>>>
>> An IETF document about them has not been adopted yet. Shall I just add a
>> sentence or two describing the threats that each sub-sections are dealing
>> with? Or shall I point to the research papers that I was reading? (Some of
>> them are not freely available though.)
>>
>
> Any document that describes them will likely be an 'updates' to the OAuth
> spec, so we should be okay.  Is the WG likely to adopt a draft soon?  If
> so, we could wait to start IETF last call.
>
>
>>
>>> 3. Nit: in first line of 10.4:
>>>
>>> Although this specification does not require them, researchs
>>>
>>> s/researchs/researchers/
>>>
>>
>> In fact, I meant either "research" or "researches" as I was not pointing
>> to persons but rather the work done by them.
>> I fixed it as "research" in my personal copy.
>> See: https://bitbucket.org/Nat/oauth-jwsreq/commits/0ec83d0c0c36
>>
>>
>>> 4. I'm sure you'll be asked about the following:
>>>
>>>    ISO/IEC 29100
>>>    [ISO29100] is a freely accessible International Standard and its
>>>    Privacy Principles are good to follow.
>>>
>>> What about the IETF privacy considerations for protocols, RFC6973, were
>>> they also considered?  I think you are covering what's needed, but no
>>> mention of it and favoring an ISO standard seems odd., using both is fine.
>>>
>>
>> Good point. ISO/IEC 29100 is a high level document so the coverage is
>> wider but does not get into concrete details where as RFC6973 gives more
>> concrete guidance.  They complement each other. I have added a paragraph
>> about RFC6873 in my personal copy.
>>
>> See: https://bitbucket.org/Nat/oauth-jwsreq/commits/9030e1be5cac
>>
>>
> I think you've covered the important privacy considerations from 6973, so
> the statement added on it should make that clear so the reader knows you've
> done the work for them already.
>
> Please let me know when the update has been posted.
>
> Thank you,
> Kathleen
>
>>
>>> Thank you.
>>> --
>>>
>>> Best regards,
>>> Kathleen
> Best regards,
> Kathleen

-- 

Best regards,
Kathleen