Subject: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-03.txt

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 4 Nov 2019 17:48:15 +0100

Hi all,

a new (significantly enhanced) revision of draft-lodderstedt-oauth-rar was just published. Here is the list of changes:

	• Reworked examples to illustrate privacy preserving use of authorization_details
	• Added text on audience restriction
	• Added description of relationship between scope and authorization_details
	• Added text on token request & response and authorization_details
	• Added text on how authorization details are conveyed to RSs by JWTs or token endpoint response
	• Added description of relationship between claims and authorization_details
	• Added more example from different sectors
	• Clarified string comparison to be byte-exact without collation

Thanks a lot for all contributions and the review feedback so far. I will present this draft in Singapore and would appreciate if the WG would consider this draft for adoption. 

best regards,
Torsten. 

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-lodderstedt-oauth-rar-03.txt
> Date: 4. November 2019 at 17:43:01 CET
> To: "Justin Richer" <[email-masked]>, "Torsten Lodderstedt" <[email-masked]>, "Brian Campbell" <[email-masked]>
> 
> 
> A new version of I-D, draft-lodderstedt-oauth-rar-03.txt
> has been successfully submitted by Torsten Lodderstedt and posted to the
> IETF repository.
> 
> Name:		draft-lodderstedt-oauth-rar
> Revision:	03
> Title:		OAuth 2.0 Rich Authorization Requests
> Document date:	2019-11-03
> Group:		Individual Submission
> Pages:		30
> URL:            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
> Htmlized:       https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-03
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-03
> 
> Abstract:
>   This document specifies a new parameter "authorization_details" that
>   is used to carry fine grained authorization data in the OAuth
>   authorization request.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Ryan Kelly <[email-masked]>
Date: Thu, 14 Nov 2019 18:31:11 +1100

Hi,

(I've been lurking on this list for a while but I don't think I've posted
here before, so...hi! I'm Ryan and I work on Firefox Accounts and related
systems at Mozilla).

Thanks for working on this!  It's an interesting and timely read for me as
we're starting to bump up against some limitations of the `scope`
parameter. I have some initial feedback below, and will hopefully be able
to send through more as I dig in in more detail.

  Cheers,

      Ryan

---

* Section 2.3: Relationship to "resource" parameter

The potential interactions between "locations" and "resource" seem very
complex and I'm not at all sure I understood them.

Paragraph 2 says that "locations" should take precedence over "resource"
when both appear in the authorization request, but doesn't explain what
this means in concrete terms. Can a client make a subsequent token request
that passes a value from "locations" in the "resource" parameter, even
though it wasn't specified in the "resource" parameter of the authorization
request?

In Paragraph 3, how should the AS deal with authorization details objects
that do not have a "locations" element? Should they be included regardless
of "resource"? What if the "resource" parameter refers to a value that was
present in "locations" but not in "resource" during the initial
authorization request?

The "matches as prefix of one of the URLs" part of Paragraph 3 seems a bit
unclear as well, given that there is no requirement that the "locations"
elements be well-formed URLs. Is this is simple string prefix match, or
some sort of path matching based on the components of the URL?

As a purely stylistic comment, I also found the example in this section a
bit artificial - I struggled to think of *why* a client might request an
authorization code with one set of authorization details, but then use the
"resource" parameter to immediately reduce them when exchanging the code
for a token. I wonder if using a refresh_token grant as part of the example
could help make it clearer, similar to what's done in
oauth-resource-indicators-08 Section 2.2.

* Section 3: Using "authorization_details"

Intuitively, I would expect to be able to use "authorization_details" in a
token request using grant_type=refresh_token, in the same way that I can
specify "scope". Section 3 doesn't seem to take a definitive stance on this
- IIUC Section 3.1 doesn't apply because this is not an authorization
request, and Section 3.3 seems to discourage it in favour of using the
"resource" parameter. Do you intend for this parameter to be allowed in
conjunction with a refresh token?

On Tue, 5 Nov 2019 at 03:48, Torsten Lodderstedt <[email-masked]>
wrote:

> Hi all,
>
> a new (significantly enhanced) revision of draft-lodderstedt-oauth-rar was
> just published. Here is the list of changes:
>
> Thanks a lot for all contributions and the review feedback so far. I will
> present this draft in Singapore and would appreciate if the WG would
> consider this draft for adoption.
>
> best regards,
> Torsten.
>
> Begin forwarded message:
>
> *From: [email-masked]
> *Subject: **New Version Notification for
> draft-lodderstedt-oauth-rar-03.txt*
> *Date: *4. November 2019 at 17:43:01 CET
> *To: *"Justin Richer" <[email-masked]>, "Torsten Lodderstedt" <
> [email-masked]>, "Brian Campbell" <[email-masked]>
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-03.txt
> Status:
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-03
>
> Abstract:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 14 Nov 2019 18:41:12 +0100

Hi Ryan,

> On 14. Nov 2019, at 08:31, Ryan Kelly <[email-masked]> wrote:
> 
> 
> 
> Hi,
> 
> (I've been lurking on this list for a while but I don't think I've posted here before, so...hi! I'm Ryan and I work on Firefox Accounts and related systems at Mozilla).

thanks a lot for posting your feedback! 

> 
> Thanks for working on this!  It's an interesting and timely read for me

Good to hear we are just in time :-)

> as we're starting to bump up against some limitations of the `scope` parameter. I have some initial feedback below, and will hopefully be able to send through more as I dig in in more detail.

please do

> The potential interactions between "locations" and "resource" seem very complex and I'm not at all sure I understood them.
> 
> Paragraph 2 says that "locations" should take precedence over "resource" when both appear in the authorization request, but doesn't explain what this means in concrete terms.

I see. This is related to the section 2.1. of draft-ietf-oauth-resource-indicators, where the use of the “resource” parameter in the authorization request is described as 

"When the "resource" parameter is used in an authorization request to
   the authorization endpoint, it indicates the identity of the
   protected resource(s) to which access is being requested.”

The “locations" elements of the authorisation details objects do the same but on a more detailed level. That’s why this information shall take precedence. Given there could be authorisation details objects that do not contain a locations element, it nevertheless could be useful to use “resource” in parallel.

However, one could also argue that client using locations should do you consequently and not use the “resource” parameter in the authorization request.

> Can a client make a subsequent token request that passes a value from "locations" in the "resource" parameter, even though it wasn't specified in the "resource" parameter of the authorization request?

yes. At the token endpoint, the “resource” parameter is the only way to describe what resource server the client want to use the token at.

draft-lodderstedt-oauth-rar does not use an alternative parameter at the token endpoint, it in some ways utilises the existing “resource” parameter. Or put the other way around, it makes the semantics of the “resource” parameter more explicit. 

Where draft-ietf-oauth-resource-indicators states

"To
   the extent possible, when issuing access tokens, the authorization
   server should downscope the scope value associated with an access
   token to the value the respective resource is able to process and
   needs to know.” 

draft-lodderstedt-oauth-rar makes that more explicit/transparent by requiring 

"The AS will select all authorization
   details object where the "resource" string matches as prefix of one
   of the URLs provided in the respective "locations" element."

> 
> In Paragraph 3, how should the AS deal with authorization details objects that do not have a "locations" element? Should they be included regardless of "resource”?

That’s a very good question. I see to options: 
- those elements are assigned to any access token
- those elements are assigned to an access token in case there was no “resource” parameter included in the token request. 

I’m leaning towards the latter approach. 

> What if the "resource" parameter refers to a value that was present in "locations" but not in "resource" during the initial authorization request?

See above - since locations take precedence, those locations shall match. 

> 
> The "matches as prefix of one of the URLs" part of Paragraph 3 seems a bit unclear as well, given that there is no requirement that the "locations" elements be well-formed URLs. Is this is simple string prefix match, or some sort of path matching based on the components of the URL?

simple string match

> 
> As a purely stylistic comment, I also found the example in this section a bit artificial - I struggled to think of *why* a client might request an authorization code with one set of authorization details, but then use the "resource" parameter to immediately reduce them when exchanging the code for a token. I wonder if using a refresh_token grant as part of the example could help make it clearer, similar to what's done in oauth-resource-indicators-08 Section 2.2.

I think asking for an access token for a single resource server is just consequent, since it ensures all access tokens are tightly audience restricted. But you are making a good point, a further example utilising the refresh token to obtain another access token for the other resource server will certainly make things clearer.

> Intuitively, I would expect to be able to use "authorization_details" in a token request using grant_type=refresh_token, in the same way that I can specify "scope". Section 3 doesn't seem to take a definitive stance on this - IIUC Section 3.1 doesn't apply because this is not an authorization request, and Section 3.3 seems to discourage it in favour of using the "resource" parameter. Do you intend for this parameter to be allowed in conjunction with a refresh token?

What would be the use case for passing an authorization details parameter to the token request with a refresh token? The client shouldn’t be able to change the authorization details of the underlying grant, so using the “resource” parameter to select another subset of the granted authorization details should be sufficient. 

best regards,
Torsten. 

> 
> 
> 
> On Tue, 5 Nov 2019 at 03:48, Torsten Lodderstedt <[email-masked]> wrote:
> Hi all,
>

---

From: Ryan Kelly <[email-masked]>
Date: Mon, 25 Nov 2019 14:17:56 +1100

On Fri, 15 Nov 2019 at 04:41, Torsten Lodderstedt <[email-masked]>
wrote:

> > In Paragraph 3, how should the AS deal with authorization details
> objects that do not have a "locations" element? Should they be included
> regardless of "resource”?
>
> - those elements are assigned to an access token in case there was no
> “resource” parameter included in the token request.
>
> > What if the "resource" parameter refers to a value that was present in
> "locations" but not in "resource" during the initial authorization request?
>

Gotcha, thanks. I think this is the part I wasn't clear on regarding the
meaning of "take precedence" at the authorization endpoint, and I wonder if
it can be made more explicit in the earlier section.

> > The "matches as prefix of one of the URLs" part of Paragraph 3 seems a
> bit unclear as well, given that there is no requirement that the
> "locations" elements be well-formed URLs. Is this is simple string prefix
> match, or some sort of path matching based on the components of the URL?
>
> simple string match
>

Does the AS need to take any particular care about resource names that
might accidentally be prefixes of each other, such as "
https://example.com/payments" and "https://example.com/payme"?  That seems
really contrived, but perhaps I'm just not creative enough to think of a
more realistic example.

> > Intuitively, I would expect to be able to use "authorization_details" in
> a token request using grant_type=refresh_token, in the same way that I can
> What would be the use case for passing an authorization details parameter
> to the token request with a refresh token? The client shouldn’t be able to
> change the authorization details of the underlying grant, so using the
> “resource” parameter to select another subset of the granted authorization
> details should be sufficient.
>

I was thinking of situations where there might be "high risk" and "low
risk" actions authorized for a single resource server, and the client may
want to make an access token that is scoped down to just the low-risk ones,
to minimize the impact of a potential compromise of that token. But perhaps
that's better dealt with by the work on sender-constrained tokens to reduce
the risk of the token being compromised in the first place.

  Cheers,

    Ryan

---

From: Brian Campbell <[email-masked]>
Date: Mon, 25 Nov 2019 13:41:53 -0700

On Sun, Nov 24, 2019 at 8:18 PM Ryan Kelly <[email-masked]> wrote:

> https://example.com/payments" and "https://example.com/payme"?  That
> seems really contrived, but perhaps I'm just not creative enough to think
> of a more realistic example.
>

That particular example is maybe somewhat contrived but that kind of thing
will undoubtedly occur at some point. I do think that some sort of path
matching would be more appropriate for this.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._