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

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 21 Sep 2019 19:51:25 +0200

Hi all, 

I just published a draft about “OAuth 2.0 Rich Authorization Requests” (formerly known as “structured scopes”). 

https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 <https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02>

It specifies a new parameter “authorization_details" that is used to carry fine grained authorization data in the OAuth authorization request. This mechanisms was designed based on experiences gathered in the field of open banking, e.g. PSD2, and is intended to make the implementation of rich and transaction oriented authorization requests much easier than with current OAuth 2.0.

I’m happy that Justin Richer and Brian Campbell joined me as authors of this draft. We would would like to thank Daniel Fett, Sebastian Ebling, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable feedback during the preparation of this draft.

We look forward to getting your feedback. 

kind regards,
Torsten. 

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-lodderstedt-oauth-rar-02.txt
> Date: 21. September 2019 at 16:10:48 CEST
> To: "Justin Richer" <[email-masked]>, "Torsten Lodderstedt" <[email-masked]>, "Brian Campbell" <[email-masked]>
> 
> 
> A new version of I-D, draft-lodderstedt-oauth-rar-02.txt
> has been successfully submitted by Torsten Lodderstedt and posted to the
> IETF repository.
> 
> Name:		draft-lodderstedt-oauth-rar
> Revision:	02
> Title:		OAuth 2.0 Rich Authorization Requests
> Document date:	2019-09-20
> Group:		Individual Submission
> Pages:		16
> URL:            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
> Htmlized:       https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-02
> 
> 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: Janak Amarasena <[email-masked]>
Date: Sun, 22 Sep 2019 13:15:44 +0530

Hi,

Since the "authorization_details" parameter is newly introduced I feel it
would be better to show how this is used with the existing authorization
request at the beginning of the specification. Maybe a small sample of the
complete authorization request in the "introduction" section.

Also, in the "Security Considerations" section it says

Authorization details are sent through the user agent in case of an

OAuth authorization request, which makes them vulnerable to

modifications by the *user*.

Do we really need to worry that the "authorization_details" could be
manipulated by the user(Resource Owner) as the client is trying to access
the users' resources which the user is giving consent to? Also, the
resulting token will contain the given permissions as well.

Best Regards,
Janak Amarasena

On Sat, Sep 21, 2019 at 11:21 PM Torsten Lodderstedt <
[email-masked]> wrote:

> https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02
>
> It specifies a new parameter “authorization_details" that is used to carry
> fine grained authorization data in the OAuth authorization request. This
> mechanisms was designed based on experiences gathered in the field of open
> banking, e.g. PSD2, and is intended to make the implementation of rich and
> transaction oriented authorization requests much easier than with current
> OAuth 2.0.
>
> I’m happy that Justin Richer and Brian Campbell joined me as authors of
> this draft. We would would like to thank Daniel Fett, Sebastian Ebling,
> Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable
> feedback during the preparation of this draft.
>
> *From: [email-masked]
> *Subject: **New Version Notification for
> draft-lodderstedt-oauth-rar-02.txt*
> *Date: *21. September 2019 at 16:10:48 CEST
> *To: *"Justin Richer" <[email-masked]>, "Torsten Lodderstedt" <
> [email-masked]>, "Brian Campbell" <[email-masked]>
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.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-02
>
> Abstract:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 23 Sep 2019 20:08:33 +0200

Hi Janak, 

thanks for your feedback. 

> On 22. Sep 2019, at 09:45, Janak Amarasena <[email-masked]> wrote:
> 
> Hi,
> 
> Since the "authorization_details" parameter is newly introduced I feel it would be better to show how this is used with the existing authorization request at the beginning of the specification. Maybe a small sample of the complete authorization request in the "introduction" section.

Sounds reasonable, I put it on the list for the next revision. 

> modifications by the user.
> 
> Do we really need to worry that the "authorization_details" could be manipulated by the user(Resource Owner) as the client is trying to access the users' resources which the user is giving consent to? Also, the resulting token will contain the given permissions as well. 

I understand. I think the more general case of modifying the Authorization Request content, e.g. PKCE challenge, and swapping such parameters between different devices is the important attack vector. I will improve the text.

best regards,
Torsten. 

> 
> Best Regards,
> Janak Amarasena
> 
> On Sat, Sep 21, 2019 at 11:21 PM Torsten Lodderstedt <[email-masked]> wrote:
> Hi all, 
>

---

From: George Fletcher <[email-masked]>
Date: Tue, 24 Sep 2019 16:45:40 -0400

Just two questions...

1. What is the rationale that 'data' is really an array of arbitrary 
top-level claims? I find looking at the spec and not finding a 'data' 
section a little confusing.

2. What is the rationale for sending the JSON object as a urlencoded 
JSON string rather than a base64url encoded JSON string? The later would 
likely be smaller and easier to read:)

Thanks,
George

On 9/21/19 1:51 PM, Torsten Lodderstedt wrote:
> Hi all,
>
> I just published a draft about ???OAuth 2.0 Rich Authorization Requests??? 
> (formerly known as ???structured scopes???).
>
> It specifies a new parameter?????authorization_details"??that is used to 
> carry fine grained authorization data in the OAuth authorization 
> request. This mechanisms was designed based on experiences gathered in 
> the field of open banking, e.g. PSD2, and is intended to make the 
> implementation of rich and transaction oriented authorization requests 
> much easier than with current OAuth 2.0.
>
> I???m happy that Justin Richer and Brian Campbell joined me as authors 
> of this draft. We would would like to thank Daniel Fett, Sebastian 
> Ebling, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their 
> valuable feedback during the preparation of this draft.
>
>> *From: [email-masked] <mailto:[email-masked]>
>> *To: *"Justin Richer" <[email-masked] 
>> <mailto:[email-masked]>>, "Torsten Lodderstedt" 
>> <[email-masked] <mailto:[email-masked]>>, "Brian 
>> Campbell" <[email-masked] 
>> <mailto:[email-masked]>>
>>
>>
>> Name:draft-lodderstedt-oauth-rar
>> Revision:02
>> Title:OAuth 2.0 Rich Authorization Requests
>> Document date:2019-09-20
>> Group:Individual Submission
>> Pages:16
>> URL: 
>> ????This document specifies a new parameter "authorization_details" that
>> ????is used to carry fine grained authorization data in the OAuth
>> ????authorization request.
>>
>>
>>
>>
>> until the htmlized version and diff are available at tools.ietf.org 
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
>
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 24 Sep 2019 16:33:37 -0700

The idea behind the “locations”, “actions”, “data”, and “identifier” data element types mirrors what I’ve seen “scope” used for in the wild. They roughly equate to “where something is”, “what I want to do with it”, “what kind of thing I want”, and “the exact thing I want”, respectively. I’m completely open for better names, and have even been thinking “datatype” might be better than just “data” for the third one.

As for encoding, I think that form encoding makes sense because it’s the simplest possible encoding that will work. I personally don’t see a need to armor this part of the request with base64, as it is in JOSE, and doing so would make it one more step removed from easy developer understanding. 

-- Justin Richer

Bespoke Engineering
+1 (617) 564-3801
https://bspk.io/

> On Sep 24, 2019, at 1:45 PM, George Fletcher <[email-masked]> wrote:
> 
> Just two questions...
> 
> 1. What is the rationale that 'data' is really an array of arbitrary top-level claims? I find looking at the spec and not finding a 'data' section a little confusing.
> 
> 2. What is the rationale for sending the JSON object as a urlencoded JSON string rather than a base64url encoded JSON string? The later would likely be smaller and easier to read:)
> 
> Thanks,
> George
> 
>> Hi all,??
>> I just published a draft about ???OAuth 2.0 Rich Authorization Requests??? (formerly known as ???structured scopes???).??
>> 
>> It specifies a new parameter?????authorization_details"??that is used to carry fine grained authorization data in the OAuth authorization request. This mechanisms was designed based on experiences gathered in the field of open banking, e.g. PSD2, and is intended to make the implementation of rich and transaction oriented authorization requests much easier than with current OAuth 2.0.
>> 
>> I???m happy that Justin Richer and Brian Campbell joined me as authors of this draft. We would would like to thank Daniel Fett, Sebastian Ebling, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable feedback during the preparation of this draft.
>> 
>> We look forward to getting your feedback.??
>> 
>> kind regards,
>> Torsten.??
>> 
>>> Begin forwarded message:
>>> 
>>> From: [email-masked] <mailto:[email-masked]>
>>> To: "Justin Richer" <[email-masked] <mailto:[email-masked]>>, "Torsten Lodderstedt" <[email-masked] <mailto:[email-masked]>>, "Brian Campbell" <[email-masked] <mailto:[email-masked]>>
>>> 
>>> 
>>> URL: ??????????????????????https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt <https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt>
>>> Status: ????????????????https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ <https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/>
>>> Htmlized: ????????????https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 <https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02>
>>> Htmlized: ????????????https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar <https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar>
>>> Diff: ????????????????????https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-02 <https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-02>
>>> 
>>> Abstract:
>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>>> 
>>> The IETF Secretariat
>>> 
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 26 Sep 2019 17:02:02 +0200

Hi Torsten,

Overall I am a fan of a way to provide more structure in authorization
requests, and I'm excited to see this draft, so thanks for that.

I do have some concerns about one aspect of this. Given its clear
intended use as a way to create authorization requests to do things
like transfer money between bank accounts, I don't think it's
appropriate for that kind of data to be sent in the front channel at
all. By encoding a rich authorization request with bank account
numbers and account names in a query string, that opens up several new
opportunities for an attacker to steal private/sensitive information
(browser extensions, proxy servers, etc).

This differs from the plain OAuth authorization request because
traditionally the request does not include any identifying information
about any user or even about the particular transaction. At most, the
request identifies the client and combination of coarse-grained scopes
the client is requesting, none of which can identify a user. However
with the examples provided in this document, as well as many
additional uses of this mechanism, it includes potentially a lot of
identifying information about users including their name, bank account
numbers, and even relationships to other parties (e.g. creditorName).
When the authorization request is sent to the AS in a URL, regardless
of whether it's in plaintext like the simple example here, or signed
as a JWT request, that data is visible to anything that can access the
URL between the user's device and the AS. This seems like a huge
potential for a privacy leak.

I realize this draft currently points to JWT Secured Authorization
Requests (JAR) in several places where these concerns come up. The
problem is that JAR doesn't actually *require* an encrypted JWT, so
the privacy implications aren't accounted for here.

I would much rather see this document require your other recent
submission, Pushed Authorization Requests. Given the privacy
implications, it makes sense to limit the use of rich authorization
requests to pushed authorization requests, so that this rich data is
never made available to intermediaries in the front channel.

If there is a good reason to continue allowing authorization requests
as a GET without the new pushed request step, then at least I would
want to see RAR require encrypted JWTs as described by JAR.

Thanks for considering this!

----
Aaron Parecki
aaronparecki.com

---

From: George Fletcher <[email-masked]>
Date: Thu, 26 Sep 2019 12:18:58 -0400

This is a great point about personal information. However, there are 
uses for authorization_details that don't specifically relate to 
personal information. Think an enhancement that has language preference, 
maybe a device identifier. Maybe we can add more text in the security 
considerations section stating that it's best practice to use PAR for 
any authorization_details that are considered personal information (PI) 
or personally identifying information (PII) ?

On 9/26/19 11:02 AM, Aaron Parecki wrote:
>> I just published a draft about ???OAuth 2.0 Rich Authorization Requests??? (formerly known as ???structured scopes???).
>>
>> It specifies a new parameter ???authorization_details" that is used to carry fine grained authorization data in the OAuth authorization request. This mechanisms was designed based on experiences gathered in the field of open banking, e.g. PSD2, and is intended to make the implementation of rich and transaction oriented authorization requests much easier than with current OAuth 2.0.
>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 26 Sep 2019 16:41:27 +0000

I agree with George that this is a good fit for a security consideration, not a normative requirement. While it’s best to always protect the request data, this isn’t all that much different from having scopes that might leak personal information. Like for example, asking for access to HIV information for a health record. It’s made more explicit and potentially worse by RAR, but it’s far from unique.

This combination of issues is part of why XYZ effectively requires a combination of PAR and RAR for all requests.

— Justin

On Sep 26, 2019, at 9:18 AM, George Fletcher <[email-masked]<mailto:[email-masked]>> wrote:

This is a great point about personal information. However, there are uses for authorization_details that don't specifically relate to personal information. Think an enhancement that has language preference, maybe a device identifier. Maybe we can add more text in the security considerations section stating that it's best practice to use PAR for any authorization_details that are considered personal information (PI) or personally identifying information (PII) ?

Hi Torsten,

----
Aaron Parecki
aaronparecki.com<http://aaronparecki.com>

On Sat, Sep 21, 2019 at 7:51 PM Torsten Lodderstedt
<[email-masked]><mailto:[email-masked]> wrote:

Hi all,

kind regards,
Torsten.

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-lodderstedt-oauth-rar-02.txt
Date: 21. September 2019 at 16:10:48 CEST
To: "Justin Richer" <[email-masked]><mailto:[email-masked]>, "Torsten Lodderstedt" <[email-masked]><mailto:[email-masked]>, "Brian Campbell" <[email-masked]><mailto:[email-masked]>

Abstract:

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<http://tools.ietf.org>.

The IETF Secretariat

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

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

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 26 Sep 2019 18:56:56 +0200

This is absolutely something that needs to be mentioned in the
security & privacy considerations.

My worry is that by leading with an example of account numbers in the
request URL, we're sending the wrong message.

I do see the value in rich authorization requests with no PII like
George described, so I would be happy if:

* the example in this draft of the GET request was an example with no PII
* there was an additional example using PAR that includes the full
bank account transfer in the current draft

----
Aaron Parecki
aaronparecki.com

On Thu, Sep 26, 2019 at 6:42 PM Justin Richer <[email-masked]> wrote:
> On Sep 26, 2019, at 9:18 AM, George Fletcher <[email-masked]> wrote:
>