Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt

From: [email-masked]
Date: Sun, 07 Feb 2021 04:42:30 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : OAuth 2.0 Rich Authorization Requests
        Authors         : Torsten Lodderstedt
                          Justin Richer
                          Brian Campbell
	Filename        : draft-ietf-oauth-rar-04.txt
	Pages           : 36
	Date            : 2021-02-07

Abstract:
   This document specifies a new parameter "authorization_details" that
   is used to carry fine grained authorization data in the OAuth
   authorization request.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-rar-04.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-rar-04

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 7 Feb 2021 13:49:47 +0100

Hi all,

here is the list of changes in revision -04:

restructured draft for better readability
simplified normative text about use of the resource parameter with authorization_details 
added implementation considerations for deployments and products
added type union language from GNAP  
added recommendation to use PAR to cope with large requests and for request protection

Your feedback is highly appreciated.

best regards,
Torsten. 

> Am 07.02.2021 um 13:42 schrieb [email-masked]:
> 
> 
> https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/&source=gmail-imap&ust=1613306557000000&usg=AOvVaw3-4SmuMFgxbz-cDK2Ir_a7
> 
> https://www.google.com/url?q=https://www.ietf.org/archive/id/draft-ietf-oauth-rar-04.html&source=gmail-imap&ust=1613306557000000&usg=AOvVaw1J52xGTvk1ZAuBC_fUAIjJ
> 
> https://www.google.com/url?q=https://www.ietf.org/rfcdiff?url2%3Ddraft-ietf-oauth-rar-04&source=gmail-imap&ust=1613306557000000&usg=AOvVaw0TYqmFwryvAYznR2Ho5Oj6
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1613306557000000&usg=AOvVaw06g1z6o36BkkaqkiWc1Lw9

---

From: Francis Pouatcha <[email-masked]>
Date: Tue, 9 Feb 2021 12:52:48 +0000

Find bellow my review of the draft:

  1.  Redactional changes:

2.2.  Authorization Data Types

Interpretation of the value of the "type" parameter, and the object

   elements that the "type" parameter allows => allowed

9.  Metadata

which is an

   JSON array. => which is a JSON array

  1.  Application to existing APIs

reason-1: Current open banking initiatives are built on the of existing Data Standards like ISO20022 (PAIN, CAMT) which are XML's that do not provide direct translation to JSON. Some authorization server's might even be able to parse an ISO PAIN file to display the proper authorization request to the user.

reason-2: In some situation, it might be more privacy preserving to have the authorization request content negotiated between the AS and the RS. In this case the "scope" parameter shall only carry some sort of "grant-id" (known in the Berlin Group spec as consent-id). This will allow the AS to negotiate the data to be displayed directly with the RS.

Any idea how to consider these two edge cases?

Best regards.
/Francis

________________________________
From: OAuth <[email-masked]> on behalf of Torsten Lodderstedt <torsten=[email-masked]>
Sent: Sunday, February 7, 2021 12:49 PM
To: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt

Hi all,

  *   restructured draft for better readability
  *   simplified normative text about use of the resource parameter with authorization_details
  *   added implementation considerations for deployments and products
  *   added type union language from GNAP
  *   added recommendation to use PAR to cope with large requests and for request protection

best regards,
Torsten.

Am 07.02.2021 um 13:42 schrieb [email-masked]<mailto:[email-masked]>:

Abstract:

---

From: Brian Campbell <[email-masked]>
Date: Fri, 12 Feb 2021 16:38:10 -0700

>    elements that the "type" parameter allows => allowed
The "allows" seems correct there.

>    JSON array. => which is a JSON array

Fixed this in the document source. Thanks!

> reason-1: Current open banking initiatives are built on the of existing
> Data Standards like ISO20022 (PAIN, CAMT) which are XML's that do not
> provide direct translation to JSON. Some authorization server's might even
> be able to parse an ISO PAIN file to display the proper authorization
> request to the user.
>

That the APIs are XML doesn't necessarily mean that the details of the
authorization can't be represented in JSON. And, if really need be, XML can
be included as the value of some member in the authorization details and
defined as such by the type.

> reason-2: In some situation, it might be more privacy preserving to have
> the authorization request content negotiated between the AS and the RS. In
> this case the "scope" parameter shall only carry some sort of "grant-id"
> (known in the Berlin Group spec as consent-id). This will allow the AS to
> negotiate the data to be displayed directly with the RS.
>

RAR probably just isn't applicable in that kind of case.

> Best regards.
> /Francis
>
>
> ------------------------------
> *From:* OAuth <[email-masked]> on behalf of Torsten Lodderstedt
> <torsten=[email-masked]>
> *Sent:* Sunday, February 7, 2021 12:49 PM
> *To:* oauth <[email-masked]>
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt
>
> Hi all,
>
>    - restructured draft for better readability
>    - simplified normative text about use of the resource parameter with
>    authorization_details
>    - added implementation considerations for deployments and products
>    - added type union language from GNAP
>    - added recommendation to use PAR to cope with large requests and for
>    request protection
>
>
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_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._

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 15 Feb 2021 18:17:55 +0100

> Am 13.02.2021 um 00:38 schrieb Brian Campbell <bcampbell=[email-masked]>:
> 
> 
> 
> On Tue, Feb 9, 2021 at 5:53 AM Francis Pouatcha <fpo=[email-masked]> wrote:
> 	• Redactional changes:
> 	• Application to existing APIs
> That the APIs are XML doesn't necessarily mean that the details of the authorization can't be represented in JSON. And, if really need be, XML can be included as the value of some member in the authorization details and defined as such by the type. 
> 
>  

I think you are referring to different relationships, namely client to AS vs AS to RS. 

Authorization details carry the client’s request data (e.g. amount to be transferred) to the AS. Whatever the AS wants to negotiate with the RS to be displayed by the AS can be negotiated between AS and RS if needed via a suitable interface. However, I would assume this negotiation is informed by the client’s request data.  So both concepts are complementary in my opinion.  

 
> 	• restructured draft for better readability
> 	• simplified normative text about use of the resource parameter with authorization_details 
> 	• added implementation considerations for deployments and products
> 	• added type union language from GNAP  
> 	• added recommendation to use PAR to cope with large requests and for request protection
> 
> 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.