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<mailto: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<http://aaronparecki.com> On Sat, Sep 21, 2019 at 7:51 PM Torsten Lodderstedt <tors...@lodderstedt.net><mailto: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<mailto: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><mailto:i...@justin.richer.org>, "Torsten Lodderstedt" <tors...@lodderstedt.net><mailto:tors...@lodderstedt.net>, "Brian Campbell" <bcampb...@pingidentity.com><mailto: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<http://tools.ietf.org>. The IETF Secretariat _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth