On 09/07/2020 19:06, Dave Tonge wrote:
>
> 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";
> ],
> "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 I like about this proposal:
1. It keeps the linking / referencing self-contained, i.e. within the
RAR authorization_details.
2. It doesn't require anything else in terms of OAuth, such a new
top-level authz request parameter.
3. Applications / deployments are free how to define the "linking" /
"context" between RARs.
4. Does not complicate the RAR spec further (the normative bits).
Vladimir
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
