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
