Subject: [OAUTH-WG] WG Last Call on the RAR Document

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 7 Jun 2021 16:18:17 -0400

All,

This is to start a *WG Last Call *on the *RAR* document, that ends *June
22nd.*
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-05

Please, review the document and provide your feedback on the mailing list.
A feedback that states that you have reviewed the document and have no
concerns would also be very helpful.

Regards,
 Rifaat & Hannes

---

From: Dave Tonge <[email-masked]>
Date: Tue, 8 Jun 2021 12:33:50 +0200

Dear RAR authors

Thank you for your work on this draft - I believe it will be very helpful
to many ecosystems and am in favour of its progression.

A few nits:

*Whole Document*
 - "payment initiation" is I think a PSD2 specific term, I'm not sure about
its use in the document, perhaps just "payment API" is sufficient? If it is
used, perhaps it needs a definition?

*Introduction*
- "enables the AS to *mint* RS-specific" - I wonder whether "mint" is a
well enough understood term?

*Section 2*
 - final example in 2.1 - is the array of authorization details supposed to
be under the `resources` key?

*Section 3*
 - Should PAR be added to 6747,8628 and CIBA in section 3? I know it is
referenced in 12.4, but I think that RAR and PAR fit very well together and
it would be better to call out earlier on in the spec ( it is mentioned
extensively in the security and privacy considerations and so I think
therefore should be mentioned earlier)
 - I suggest that mention is made in section 3 that the RO may grant a
subset of the request authorization details. This is mentioned in section
7.1 but I feel it should be addressed in the authorization section.

*Section 7*
The title for section 7.1 could maybe adjusted to simply "Authorization
details in Token Response" as it deals with both enrichment and a subset
being returned.
In addition I don't think it is clear whether an AS is required to enrich
the authorization details. The statement is made

>  In order to allow the client to determine the
   accounts it is entitled to access, the authorization server will add
   this information to the respective authorization details object.

However a more standard approach currently is that the Client would simply
query an `/accounts` endpoint and would receive accounts to which it has
been given access to - without having to know their identifiers up front.
There could be a situation where a resource owner grants access to all
their accounts (including accounts opened in the future). Having the AS be
required to fill in the account identifiers in the token response could be
restrictive. I think this kind of enrichment is nice, but I suggest that it
be made clear that it is optional.

*Section 12*
* - *typo: "follwowing" -> "following"

Dave

On Mon, 7 Jun 2021 at 22:19, Rifaat Shekh-Yusef <[email-masked]>
wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Dave Tonge
CTO
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 .
Moneyhub Financial Technology Limited 2018 ©

DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.

-- 

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology 
Limited which is authorised and regulated by the Financial Conduct 
Authority ("FCA"). Moneyhub Financial Technology is entered on the 
Financial Services Register (FRN 809360) at https://register.fca.org.uk/ 
<https://register.fca.org.uk/>. Moneyhub Financial Technology is registered 
in England & Wales, company registration number 06909772. Moneyhub 
Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, 
Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email 
(including any attachments) is subject to copyright, and the information in 
it is confidential. Use of this email or of any information in it other 
than by the addressee is unauthorised and unlawful. Whilst reasonable 
efforts are made to ensure that any attachments are virus-free, it is the 
recipient's sole responsibility to scan all attachments for viruses. All 
calls and emails to and from this company may be monitored and recorded for 
legitimate purposes relating to this company's business. Any opinions 
expressed in this email (or in any attachments) are those of the author and 
do not necessarily represent the opinions of Moneyhub Financial Technology 
Limited or of any other group company.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 20 Jun 2021 12:33:38 +0200

Dear Dave,

thanks a lot for your review!

I create a PR with the changes you proposed. 

https://github.com/oauthstuff/draft-oauth-rar/pull/75 <https://github.com/oauthstuff/draft-oauth-rar/pull/75>

Please review and comment/approve. 

> Am 08.06.2021 um 12:33 schrieb Dave Tonge <[email-masked]>:
> 
> Dear RAR authors
> 
> Thank you for your work on this draft - I believe it will be very helpful to many ecosystems and am in favour of its progression.

Thank you. 

> 
> A few nits:
> 
> Whole Document
>  - "payment initiation" is I think a PSD2 specific term, I'm not sure about its use in the document, perhaps just "payment API" is sufficient? If it is used, perhaps it needs a definition?

I changed the wording and added a short explanation of the term. Please have a look.

>  
> Introduction
> - "enables the AS to mint RS-specific" - I wonder whether "mint" is a well enough understood term?

Changed it to „issue"

> 
> Section 2
>  - final example in 2.1 - is the array of authorization details supposed to be under the `resources` key?

Good catch. I assume this is a remaining of the back port from GNAP. Fixed it.

> 
> Section 3
>  - Should PAR be added to 6747,8628 and CIBA in section 3? I know it is referenced in 12.4, but I think that RAR and PAR fit very well together and it would be better to call out earlier on in the spec ( it is mentioned extensively in the security and privacy considerations and so I think therefore should be mentioned earlier)

I added a paragraph including references to the security/privacy/implementation considerations.

>  - I suggest that mention is made in section 3 that the RO may grant a subset of the request authorization details. This is mentioned in section 7.1 but I feel it should be addressed in the authorization section. 

I added a note on that.

> 
> Section 7
> The title for section 7.1 could maybe adjusted to simply "Authorization details in Token Response" as it deals with both enrichment and a subset being returned.

Can you please refer to text in 7.1 taking about subsets? 

> In addition I don't think it is clear whether an AS is required to enrich the authorization details. The statement is made
> 
> However a more standard approach currently is that the Client would simply query an `/accounts` endpoint and would receive accounts to which it has been given access to - without having to know their identifiers up front. There could be a situation where a resource owner grants access to all their accounts (including accounts opened in the future). Having the AS be required to fill in the account identifiers in the token response could be restrictive. I think this kind of enrichment is nice, but I suggest that it be made clear that it is optional.

Rephrased it to clearly point out this is _a_ design option.
> 
> Section 12
>  - typo: "follwowing" -> "following"
> 

fixed. 

best regards,
Torsten. 

> Dave
> 
> 
> 
> 
> On Mon, 7 Jun 2021 at 22:19, Rifaat Shekh-Yusef <[email-masked] <mailto:[email-masked]>> wrote:
> All,
> 
> This is to start a WG Last Call on the RAR document, that ends June 22nd.
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-05 <https://www.google.com/url?q=https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-05&source=gmail-imap&ust=1623753262000000&usg=AOvVaw1nqrwpNU-gCB0XXukNArYO>
> 
> A feedback that states that you have reviewed the document and have no concerns would also be very helpful.
> 
> Regards,
>  Rifaat & Hannes
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1623753262000000&usg=AOvVaw2EuCMd5rhjT2dwxeQnZXh7>
> 
> 
> -- 
> Dave Tonge
> CTO
>  <https://www.google.com/url?q=http://www.google.com/url?q%3Dhttp%253A%252F%252Fmoneyhubenterprise.com%252F%26sa%3DD%26sntz%3D1%26usg%3DAFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A&source=gmail-imap&ust=1623753262000000&usg=AOvVaw2yNcpQiGCRg8dcbEYb3RP2>
> t: +44 (0)117 280 5120
> 
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at fca.org.uk/register <https://www.google.com/url?q=http://fca.org.uk/register&source=gmail-imap&ust=1623753262000000&usg=AOvVaw1iKdmU3ux71hBxbtoWOq-S>. Moneyhub Financial Technology is registered in England & Wales, company registration number  06909772 .
> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
> 
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://www.google.com/url?q=https://register.fca.org.uk/&source=gmail-imap&ust=1623753262000000&usg=AOvVaw2tR54FgMdG0bdY3zyLcvST>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 
> 
> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
> 
> 
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1623753262000000&usg=AOvVaw2EuCMd5rhjT2dwxeQnZXh7