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

> Am 13.02.2021 um 00:38 schrieb Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>:
> 
> 
> 
> On Tue, Feb 9, 2021 at 5:53 AM Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org> wrote:
> Find bellow my review of the draft:
> 
> 	• 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
> 
> 
> The "allows" seems correct there. 
> 
>  
> 
> 9.  Metadata
> which is an
>    JSON array. => which is a JSON array
> 
> Fixed this in the document source. Thanks!
>  
> 	• 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.
> 
> 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.

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.  

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

> 
>  
> 
> Any idea how to consider these two edge cases?
> 
> 
>  
> Best regards.
> /Francis
> 
> 
> From: OAuth <oauth-bounces@ietf.org> on behalf of Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
> Sent: Sunday, February 7, 2021 12:49 PM
> To: oauth <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt
>  
> 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 internet-drafts@ietf.org:
>> 
>> 
>> 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://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/&source=gmail-imap&ust=1613306557000000&usg=AOvVaw3-4SmuMFgxbz-cDK2Ir_a7
>> 
>> There is also an HTML version available at:
>> 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
>> 
>> A diff from the previous version is available at:
>> https://www.google.com/url?q=https://www.ietf.org/rfcdiff?url2%3Ddraft-ietf-oauth-rar-04&source=gmail-imap&ust=1613306557000000&usg=AOvVaw0TYqmFwryvAYznR2Ho5Oj6
>> 
>> 
>> 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/
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1613306557000000&usg=AOvVaw06g1z6o36BkkaqkiWc1Lw9
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> 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.