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.
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";
],
"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?
Dave
On Thu, 9 Jul 2020 at 12:24, Neil Madden <[email protected]> wrote:
>
>
> On 9 Jul 2020, at 09:53, Vladimir Dzhuvinov <[email protected]>
> wrote:
> On 09/07/2020 11:07, Neil Madden wrote:
>
>
>
> An AS is always free to implement the 2 step solution that you proposed
> and indeed it could be easier to implement with RAR in the manner you
> described, but I don't think it should be the prescribed approach.
>
>
> How can an AS implement this with RAR? This is my point - there is no
> mechanism at all in RAR to link a transaction to any kind of prior consent.
> It’s not about mandating such an approach, it’s about *supporting* it at
> all. Every transaction in RAR is a blank slate at the moment.
>
> The ability to reference an existing grant is a general problem with OAuth.
>
> The grant management draft has a "grant_id" parameter which can be used to
> reference prior consent. I suppose to reference prior consent as context
> only a new grant_management_mode may be needed.
>
>
> https://bitbucket.org/openid/fapi/src/master/Financial_API_Grant_Management.md
>
> We also have OAuth Incremental Authorization, which references a refresh
> token:
>
> https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-04
>
> Thanks, these are useful references. The grant_id approach could work.
> Incremental authZ is an interesting comparison, but in that case the new
> grant replaces the old one, whereas in transactional auth each grant is
> separate. Another potential issue is that the proof of the existing grant
> is only presented at the token endpoint, after the flow has completed.
> Although this does stop the kind of attacks I was worried about, it would
> be better to check this up front if possible. That’s certainly an
> interesting reference though, and one I hadn’t considered before in this
> context, so thanks for mentioning it.
>
> I think I prefer an approach using PAR, with the following
> additions/modifications:
>
> 1. Ability to make PAR mandatory for approval of some scopes and/or for
> particular clients (determined by AS policy).
> 2. Ability to authorize the call to the PAR endpoint using an access token
> instead of client authentication.
> - AS policy can decide what type of authorization is required for a
> particular request: user-approved access token, client_credentials access
> token (i.e., current OB UK), or direct client authentication.
> 3. If a user-approved AT is used in step 2, then the AS MUST ensure that
> the same user is involved in the subsequent authorization flow.
>
> There is precedent for step 2 - e.g., token introspection currently allows
> an access token instead of client authentication.
>
> If RAR was then updated to discuss this issue in the security
> considerations (or elsewhere) with a reference to these features of PAR
> then I think I would be pretty happy with that.
>
> — Neil
>
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Dave Tonge
CTO
[image: Moneyhub Enterprise]
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
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.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
