Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Neil Madden <[e-mail]>]

On 9 Jul 2020, at 17:06, Dave Tonge <[e-mail]> wrote:
> 
> Hi Neil
> 
> RAR doesn't have to be transactional and people are already using standard OAuth for transactions without RAR.
> But I take your point that RAR is promoting a more transactional use of OAuth. 
> However I still don't agree that there is a fundamental difference. Revocation of access is irrelevant, as I mentioned if access was granted in error, then the damage is already done whether the user revokes or not.

This is not true. I’m not talking about revoking individual transaction tokens, I’m talking about revoking the permission to ask for transaction tokens.

> 
> I'm not sure whether it is worth standardising the approach of linking one OAuth request to another, and I'm definitely not sure about it for RAR.
> 
> It is an interesting suggestion of allowing a user access token to be presented at the PAR endpoint, but I'm not sure that is needed.
> If a particular implementation wants to allow a two stage transaction, they can simply pass some reference to the first auth in the subsequent RAR auth flows, e.g.
> 
> First flow, a user grants access with the simple scope of "make_payments", the access token issued at the end of the grant allows access to a resource server endpoints /payment-consents. The payload the client receives back when hitting that endpoint is {id: "123", paymentsStarted:[], paymentsCompleted:[]}
> The second flow the client uses RAR with authorization_details containing this object:
> 
>     {
>          "type": "payment_initiation",
>          "actions": [
>             "initiate",
>             "status",
>             "cancel"
>          ],
>          "locations": [
>             "https://example.com/payments <https://example.com/payments>"
>          ],
>          "instructedAmount": {
>             "currency": "EUR",
>             "amount": "123.50"
>          },
>          "creditorName": "Merchant123",
>          "creditorAccount": {
>             "iban": "DE02100100109307118603"
>          },
>          "remittanceInformationUnstructured": "Ref Number Merchant",
>          "paymentConsentId": "123",
>       }
> 
> This type of flows seems to better separate the AS and the RS
> 
> What do you think?

Isn’t this paymentConsentId just an access token in all but name? The point is that the AS shouldn’t process the transaction request if the user hasn’t authorized this client to do so. So the AS needs to be able to tie this paymentConsentId to the actual consent and check that it appropriate authorizes this request, which is what an access token does.

— Neil