On 9 Jul 2020, at 17:06, Dave Tonge <[email protected]> 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_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
