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 <jric...@mit.edu> wrote:
>
> 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 <gffle...@aol.com> 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) ?
>
> On 9/26/19 11:02 AM, Aaron Parecki wrote:
>
> 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
>
>
>
> On Sat, Sep 21, 2019 at 7:51 PM Torsten Lodderstedt
> <tors...@lodderstedt.net> wrote:
>
> 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
>
> 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: internet-dra...@ietf.org
> Subject: New Version Notification for draft-lodderstedt-oauth-rar-02.txt
> Date: 21. September 2019 at 16:10:48 CEST
> To: "Justin Richer" <i...@justin.richer.org>, "Torsten Lodderstedt" 
> <tors...@lodderstedt.net>, "Brian Campbell" <bcampb...@pingidentity.com>
>
>
> 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
>
>
> _______________________________________________
> 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
>
>
>

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

Reply via email to