Re: [OAUTH-WG] WGLC Review of PAR

[Justin Richer]

Hi Brian, just a couple responses inline where it seemed fitting. Thanks for 
going through everything!
 — Justin

> On Aug 25, 2020, at 6:01 PM, Brian Campbell  
> wrote:
> 
> Thanks for the review and comments Justin. Replies (or attempts thereat) are 
> inline below.
> 
> 
> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer  > wrote:
> I’ve done a full read through of the PAR specification, and here are my notes 
> on it.
> 
> For additional context, I’ve implemented this specification for both a client 
> and a server in a couple of languages. Overall, I think it’s in good shape 
> and it makes sense from a developer’s perspective. I’ve got a few comments, 
> some small and some that might need more conversation within the WG,
> 
> Always nice to get feedback from implementation experience. Especially when 
> the overall is that it's "in good shape".
> 
> 
> Throughout: Suggest using “credentialed” instead of “confidential” client, as 
> introduced in OAuth 2.1 draft.
> 
> I'm hesitant to use *new* terminology from the 2.1 draft, which was just 
> recently adopted by the WG, in this document that is written as an extension 
> of OAuth 2.0 and is further along in the process going through WGLC. There's 
> a temporal dependency problem including potential risk of change after the 
> fact. 
> 
> Perhaps this draft could avoid use of the terms and be more explicit and 
> wordy with something like "clients having established authentication 
> credentials with the AS"? 

Fair point about the terminology, and while it’s verbose I think the more 
precise wording might be warranted here so as not to extend the problems and 
confusion with “confidential” clients as a term.

> 
>  
> §1: Suggest the problems list start with changing scopes or swapping client 
> IDs as scenarios in the first bullet, ACR is an esoteric use case for many 
> and not in OAuth 2 core, either remove it or put it at the end of the bullet.
> 
> Fair suggestion. Will look at reworking it a bit. 
>  
> 
>Suggest the second bullet note who the information needs to be protected 
> from, at least in passing. It’s not clear from this setup why the parameters 
> should be confidential, and this is a major motivation for this work.
> 
> Also a fair suggestion. Although there are some subtleties and complexities 
> that I think make this a little tricky to write. Will try though. 
> 
>  
>Avoid use of phrase “so-called” and just give the name “Request Object”.
> 
> Okay, yeah. I think a moment of terminology frustration slipped into the text 
> there. 
>  
> 
> 
>¶4: Perhaps overly pedantic but I suggest extending: “in exchange for a 
> request_uri value usable at the authorization server”. 
> 
> I like the pedanticness. 
>  
> 
>¶4/5: Alternatively, suggest combining these paragraphs: “This document 
> complements JAR by providing an interoperable way for the client to push its 
> authorization request parameters to the authorization server in exchange for 
> a request_uri usable at the authorization server. The document further allows 
> the client to push request objects as specified in JAR in exchange for a 
> request_uri usable at the authorization server.”
> 
>  Yeah, I think that working works better. 
> 
>  
> ¶12: “This is directly utilized” is a little ambiguous into what it’s 
> referring to. Would suggest rewording the start as: “This early stage client 
> authentication is used by this draft to allow confidential clients…” or 
> something of that sort.
> 
> Makes sense to be less ambiguous there. 
>  
> 
> ¶13: Not only is POST much harder to use, it’s also optional for the AS 
> to implement so it can’t be counted on by a client to be available generally. 
> (To be honest in retrospect we shouldn’t have included it in OAuth 2.)
> 
> Connect says the AS/OP must support both get and post. But your point on 
> optionality stands with respect to pure OAuth only ASs. Will add something 
> about that to the paragraph. 
>  
> 
> §2: Please provide a reference to JWT client assertion auth here (either the 
> assertion RFC or OIDC’s definition of the client auth methods mentioned). I 
> would also phrase this as direct guidance instead of a note/aside.
> 
> Will do. 
>  
> 
> §2.1: There’s some potential weirdness about client_id here. Since the authz 
> request was designed around not having client authentication, that request 
> requires client_id. However, here the client is authenticating, and the 
> client_id might be included elsewhere like the Basic header. A developer 
> might be curious about whether they need to include them twice.
> 
> Fair point about the weirdness. Suggestions on some text to preempt curiosity 
> or confusion? My thinking is that the client_id parameter should always be 
> sent so as to conform to the syntax of a regular authz request. But I'll 
> admit that, due to reusing client auth logic, my server implementation won't 
> strictly require client_id when it's include

Re: [OAUTH-WG] WGLC Review of PAR

[Brian Campbell]

Thanks for the review and comments Justin. Replies (or attempts thereat)
are inline below.


On Wed, Aug 19, 2020 at 2:06 PM Justin Richer  wrote:

> I’ve done a full read through of the PAR specification, and here are my
> notes on it.
>
> For additional context, I’ve implemented this specification for both a
> client and a server in a couple of languages. Overall, I think it’s in good
> shape and it makes sense from a developer’s perspective. I’ve got a few
> comments, some small and some that might need more conversation within the
> WG,
>

Always nice to get feedback from implementation experience. Especially when
the overall is that it's "in good shape".


Throughout: Suggest using “credentialed” instead of “confidential” client,
> as introduced in OAuth 2.1 draft.
>

I'm hesitant to use *new* terminology from the 2.1 draft, which was just
recently adopted by the WG, in this document that is written as an
extension of OAuth 2.0 and is further along in the process going through
WGLC. There's a temporal dependency problem including potential risk of
change after the fact.

Perhaps this draft could avoid use of the terms and be more explicit and
wordy with something like "clients having established authentication
credentials with the AS"?



> §1: Suggest the problems list start with changing scopes or swapping
> client IDs as scenarios in the first bullet, ACR is an esoteric use case
> for many and not in OAuth 2 core, either remove it or put it at the end of
> the bullet.
>

Fair suggestion. Will look at reworking it a bit.


   Suggest the second bullet note who the information needs to be protected
> from, at least in passing. It’s not clear from this setup why the
> parameters should be confidential, and this is a major motivation for this
> work.
>

Also a fair suggestion. Although there are some subtleties and complexities
that I think make this a little tricky to write. Will try though.



>Avoid use of phrase “so-called” and just give the name “Request Object”.
>

Okay, yeah. I think a moment of terminology frustration slipped into the
text there.



>¶4: Perhaps overly pedantic but I suggest extending: “in exchange for a
> request_uri value usable at the authorization server”.
>

I like the pedanticness.


>
>¶4/5: Alternatively, suggest combining these paragraphs: “This document
> complements JAR by providing an interoperable way for the client to push
> its authorization request parameters to the authorization server in
> exchange for a request_uri usable at the authorization server. The document
> further allows the client to push request objects as specified in JAR in
> exchange for a request_uri usable at the authorization server.”
>

 Yeah, I think that working works better.



> ¶12: “This is directly utilized” is a little ambiguous into what it’s
> referring to. Would suggest rewording the start as: “This early stage
> client authentication is used by this draft to allow confidential clients…”
> or something of that sort.
>

Makes sense to be less ambiguous there.


>
> ¶13: Not only is POST much harder to use, it’s also optional for the
> AS to implement so it can’t be counted on by a client to be available
> generally. (To be honest in retrospect we shouldn’t have included it in
> OAuth 2.)
>

Connect says the AS/OP must support both get and post. But your point on
optionality stands with respect to pure OAuth only ASs. Will add something
about that to the paragraph.


>
> §2: Please provide a reference to JWT client assertion auth here (either
> the assertion RFC or OIDC’s definition of the client auth methods
> mentioned). I would also phrase this as direct guidance instead of a
> note/aside.
>

Will do.


>
> §2.1: There’s some potential weirdness about client_id here. Since the
> authz request was designed around not having client authentication, that
> request requires client_id. However, here the client is authenticating, and
> the client_id might be included elsewhere like the Basic header. A
> developer might be curious about whether they need to include them twice.
>

Fair point about the weirdness. Suggestions on some text to preempt
curiosity or confusion? My thinking is that the client_id parameter should
always be sent so as to conform to the syntax of a regular authz request.
But I'll admit that, due to reusing client auth logic, my server
implementation won't strictly require client_id when it's included
elsewhere like the Basic header.


>
> ¶2: Of necessity, this spec mixes parameters in the authorization
> endpoint and token endpoint registries into a single request. Is there any
> danger of conflict between them? The registry holds them in one list but
> they could possibly have different semantics in both places.
>

I think that technically such danger does exist but that it's highly
unlikely in practice. Especially because the only token endpoint parameters
that are relevant to PAR are those that deal with client authentication
(currently c

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Denis]

Here is an additional comment:

The text mentions in the Introduction:

   In example is a resource server using verified person data
   to create certificates, which in turn are used to create qualified
   electronic signatures.

The problem is the following: the AS has no way to verify that the User 
has effectively authorized the RS
to use the JWT Response for such a purpose. A "User Consent" phase for 
such a usage has not been addressed.


This concern is identified in RFC 6973 as:

5.2.3.  Secondary Use

   Secondary use is the use of collected information about an individual
   without the individual’s consent for a purpose different from that
   for which the information was collected.  Secondary use may violate
   people’s expectations or desires.  The potential for secondary use
   can generate uncertainty as to how one’s information will be used in
   the future, potentially discouraging information exchange in the
   first place.  Secondary use encompasses any use of data, including
   disclosure.

The progression of this draft is really questionable. The User has 
currently no way to allow or to disallow this protocol
which is between a RS and an AS.  It would not be reasonable to say that 
this concern is outside the scope of this draft.


Denis



This draft contains a "Privacy considerations" section (Section 9).
.
The content of this section is as follows:

   The token introspection response can be used to transfer personal
   identifiable information from the AS to the RS.  The AS MUST ensure a
   legal basis exists for the data transfer before any data is released
   to a particular RS.  The way the legal basis is established might
   vary among jurisdictions and MUST consider the legal entities
   involved.

   For example, the classical way to establish the legal basis is by
   explicit user consent gathered from the resource owner by the AS
   during the authorization flow.

   It is also possible that the legal basis is established out of band,
   e.g. in an explicit contract or by the client gathering the resource
   owner’s consent.

   If the AS and the RS belong to the same legal entity (1st party
   scenario), there is potentially no need for an explicit user consent
   but the terms of service and policy of the respective service
   provider MUST be enforced at all times.

   In any case, the AS MUST ensure that the scope of the legal basis is
   enforced throughout the whole process.  The AS MUST retain the scope
   of the legal basis with the access token, e.g. in the scope value,
   and the AS MUST determine the data a resource server is allowed to
   receive based on the resource server’s identity and suitable token
   data, e.g. the scope value.

It is not believed that these explanations are useful, nor sufficient.

Talking a "legal basis" without translating legal constraints into 
technical constraints is not useful.
Since sensitive information may be returned, the text should say that 
AS should/must make sure that the requesting RS is indeed

authenticated and allowed to perform this operation.

However, section 4 is only using the verb "SHOULD" whereas it should 
use the verb "SHALL" :


The AS SHOULD authenticate the caller at the token introspection
endpoint.

Talking of "an explicit user consent gathered from the resource owner 
by the AS" does not make sense.
Either the operation is allowed or is not allowed by the RO, but there 
is no "RO consent".


*About **RFC 7662 (OAuth 2.0 Token Introspection)*

One might think that the important considerations have already been 
provided when issuing RFC 7662 (OAuth 2.0 Token Introspection)

which contains a Privacy considerations section (section 5).

The third sentence states:

One method is to transmit user identifiers as opaque
service-specific strings, potentially returning different
identifiers to each protected resource.

This would mean that the response would not reflect the content of the 
token. Furthermore, the RS would not even be informed of such a 
transformation.


The last sentence even states:

Omitting privacy-sensitive information from an introspection
response is the simplest way of minimizing privacy issues.

In such a case, the introspection query becomes more or less useless.

What should have been said in RFC 7662 (OAuth 2.0 Token Introspection) ?

The fact that using an introspection call can be avoided and should be 
avoided for privacy reasons. While "in OAuth 2.0 [RFC6749],
the contents of tokens are opaque to clients", it is not opaque to 
RSs. As soon as the RS knows the format of the access token and is able

to validate its security features, this call should be avoided.

So what should be mentioned in section 9 ?

The fact that the AS will know exactly when the introspection call has 
been made and thus be able to make sure which client
has attempted perform an access to that RS and at which instant of 
time. The use of this call allows an AS to track where a

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Denis]

This draft contains a "Privacy considerations" section (Section 9).
..
The content of this section is as follows:

   The token introspection response can be used to transfer personal
   identifiable information from the AS to the RS.  The AS MUST ensure a
   legal basis exists for the data transfer before any data is released
   to a particular RS.  The way the legal basis is established might
   vary among jurisdictions and MUST consider the legal entities
   involved.

   For example, the classical way to establish the legal basis is by
   explicit user consent gathered from the resource owner by the AS
   during the authorization flow.

   It is also possible that the legal basis is established out of band,
   e.g. in an explicit contract or by the client gathering the resource
   owner’s consent.

   If the AS and the RS belong to the same legal entity (1st party
   scenario), there is potentially no need for an explicit user consent
   but the terms of service and policy of the respective service
   provider MUST be enforced at all times.

   In any case, the AS MUST ensure that the scope of the legal basis is
   enforced throughout the whole process.  The AS MUST retain the scope
   of the legal basis with the access token, e.g. in the scope value,
   and the AS MUST determine the data a resource server is allowed to
   receive based on the resource server’s identity and suitable token
   data, e.g. the scope value.

It is not believed that these explanations are useful, nor sufficient.

Talking a "legal basis" without translating legal constraints into 
technical constraints is not useful.
Since sensitive information may be returned, the text should say that AS 
should/must make sure that the requesting RS is indeed

authenticated and allowed to perform this operation.

However, section 4 is only using the verb "SHOULD" whereas it should use 
the verb "SHALL" :


   The AS SHOULD authenticate the caller at the token introspection
   endpoint.

Talking of "an explicit user consent gathered from the resource owner by 
the AS" does not make sense.
Either the operation is allowed or is not allowed by the RO, but there 
is no "RO consent".


*About **RFC 7662 (OAuth 2.0 Token Introspection)*

One might think that the important considerations have already been 
provided when issuing RFC 7662 (OAuth 2.0 Token Introspection)

which contains a Privacy considerations section (section 5).

The third sentence states:

   One method is to transmit user identifiers as opaque
   service-specific strings, potentially returning different
   identifiers to each protected resource.

This would mean that the response would not reflect the content of the 
token. Furthermore, the RS would not even be informed of such a 
transformation.


The last sentence even states:

   Omitting privacy-sensitive information from an introspection
   response is the simplest way of minimizing privacy issues.

In such a case, the introspection query becomes more or less useless.

What should have been said in RFC 7662 (OAuth 2.0 Token Introspection) ?

The fact that using an introspection call can be avoided and should be 
avoided for privacy reasons. While "in OAuth 2.0 [RFC6749],
the contents of tokens are opaque to clients", it is not opaque to RSs. 
As soon as the RS knows the format of the access token and is able

to validate its security features, this call should be avoided.

So what should be mentioned in section 9 ?

The fact that the AS will know exactly when the introspection call has 
been made and thus be able to make sure which client
has attempted perform an access to that RS and at which instant of time. 
The use of this call allows an AS to track where and when

its clients have indeed presented an issued access token.

Denis


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'JWT Response for OAuth Token
Introspection'
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
last-c...@ietf.org mailing lists by 2020-09-04. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

This specification proposes an additional JSON Web Token (JWT)
secured response for OAuth 2.0 Token Introspection.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/


No IPR declarations have been submitted directly on this I-D.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC on Pushed Authorization Requests draft

[Denis]

This document does not include a "Privacy considerations" section, but 
it should.


Denis


All,

This is a WGLC on the *Pushed Authorization Requests *document:
https://www.ietf.org/id/draft-ietf-oauth-par-03.html

Please, take a look and provide feedback on the list by *August 25th.*

Regards,
 Rifaat & Hannes


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth