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

From: Neil Madden <[email-masked]>
Date: Mon, 6 Jul 2020 17:32:39 +0100

I’m reading draft-ietf-oauth-rar-01 in a bit more detail now I have some time, and I have a few comments.

An assumption in the draft appears to be that the client knows ahead of time what it wants to gain access to and can describe it in detail. For example, the last example in section 2.1 is a client requesting access to particular files, which assumes that the client already knows the paths of the files it wants to access. This in turn seems to imply that the client already has some level of access to be able to determine this, e.g. to list directories, which may not be desirable. In many cases like this I think it’s more natural for the client to not know exactly what it is asking for but instead to want access to *some* file, chosen by the user. An example of this is the Dropbox Chooser [1] and Saver [2] APIs, which notably are not built on top of OAuth. In these cases it would be more natural for the client to send a more generic request and for the details to be filled in by the user as part of the consent process.

Another issue is that as far as I can see in the current draft, any client can initiate a rich authorization request at any time without any kind of prior approval. This seems problematic for the main example in the draft, i.e. payment initiation. As an attacker, if I can get a consent screen up on a user’s device requesting to move money around then it seems like half my job is already done - some fraction of users will probably approve such a transaction without properly checking it. It feels like the ability to ask for transaction approval should already be a privileged operation that should require consent and approval.

A related issue is that each approval is in effect a completely isolated incident. In a normal OAuth2 interaction I would grant an app some longish-term access to data and it would get an access token and optionally a refresh token. At some later point I can go to the AS and see that I have granted this access and revoke it if I choose. With RAR there is no representation of a long-term relationship between the RO and the client and each transaction starts from fresh. Again, this seems potentially problematic and not quite in keeping with how OAuth currently operates. Each grant of access is ephemeral. (Do refresh tokens make sense in the context of RAR?)

I think a better approach would be a two-phase authorization process:

1. In step 1 an app gets a normal long-lived access and/or refresh token that grants it permissions to ask to initial transactions (RARs) - e.g. with scope initiate_payments
2. In step 2 the app requests authorization for individual RARs/transactions using some proof of its grant from step 1

I have ideas for how this could be achieved, but I’d prefer to see what others think of this general idea rather than getting bogged down in specific details.

[1]: https://www.dropbox.com/developers/chooser <https://www.dropbox.com/developers/chooser>
[2]: https://www.dropbox.com/developers/saver <https://www.dropbox.com/developers/saver> 

— Neil

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 7 Jul 2020 23:08:50 +0300

On 06/07/2020 19:32, Neil Madden wrote:
> An assumption in the draft appears to be that the client knows ahead
> of time what it wants to gain access to and can describe it in detail.
> For example, the last example in section 2.1 is a client requesting
> access to particular files, which assumes that the client already
> knows the paths of the files it wants to access. This in turn seems to
> imply that the client already has some level of access to be able to
> determine this, e.g. to list directories, which may not be desirable.
> In many cases like this I think it’s more natural for the client to
> not know exactly what it is asking for but instead to want access to
> *some* file, chosen by the user. An example of this is the Dropbox
> Chooser [1] and Saver [2] APIs, which notably are not built on top of
> OAuth. In these cases it would be more natural for the client to send
> a more generic request and for the details to be filled in by the user
> as part of the consent process.
>
> Another issue is that as far as I can see in the current draft, any
> client can initiate a rich authorization request at any time without
> any kind of prior approval. This seems problematic for the main
> example in the draft, i.e. payment initiation. As an attacker, if I
> can get a consent screen up on a user’s device requesting to move
> money around then it seems like half my job is already done - some
> fraction of users will probably approve such a transaction without
> properly checking it. It feels like the ability to ask for transaction
> approval should already be a privileged operation that should require
> consent and approval.
>
> A related issue is that each approval is in effect a completely
> isolated incident. In a normal OAuth2 interaction I would grant an app
> some longish-term access to data and it would get an access token and
> optionally a refresh token. At some later point I can go to the AS and
> see that I have granted this access and revoke it if I choose. With
> RAR there is no representation of a long-term relationship between the
> RO and the client and each transaction starts from fresh. Again, this
> seems potentially problematic and not quite in keeping with how OAuth
> currently operates. Each grant of access is ephemeral. (Do refresh
> tokens make sense in the context of RAR?)

The original motivation for RAR was indeed transactions, which require
parameters, and this class of use cases do typically imply "ephemeral"
access (single-use token).

But nothing precludes RAR from being used for long term access (with a
refresh token) and there are one or two simple examples in the spec
which can be interpreted as such.

> 1. In step 1 an app gets a normal long-lived access and/or refresh
> token that grants it permissions to ask to initial transactions (RARs)
> - e.g. with scope initiate_payments
> 2. In step 2 the app requests authorization for individual
> RARs/transactions using some proof of its grant from step 1

Such a two-phase authorisation can make good sense in cases when user
trust needs to be built up.

Mentioning this and / or some other pattern can be useful, but I don't
think we should make this normative for RAR, because there can well be
use cases which won't need this.

>
> I have ideas for how this could be achieved, but I’d prefer to see
> what others think of this general idea rather than getting bogged down
> in specific details.
>
> [1]: https://www.dropbox.com/developers/chooser
> [2]: https://www.dropbox.com/developers/saver 
>
> — Neil

---

From: Neil Madden <[email-masked]>
Date: Wed, 8 Jul 2020 08:14:32 +0100

> use cases which won't need this.

Do you have any examples? 

I think this is something the draft needs to address. 

Neil

---

From: Justin Richer <[email-masked]>
Date: Wed, 8 Jul 2020 10:40:27 -0400

The two-phase approach is exactly what OBUK does, where you get one access token using client credentials before getting a more specific one in context of the user’s consent. This ends up being awkward to implement at best, since OAuth involves the user too early in the process to allow for this kind of thing. PAR might help address this dichotomy, but RAR can provide places for this to fill in.

With XYZ, I tried to design for that kind of multi-stage transaction pattern more explicitly, with the idea that you could continue your request in context and vary it over time, or even start a new request in the context of an existing one. This is something that I intend to continue with the soon-to-be-formed GNAP working group, if you want to bring this use case there.

 — Justin

> On Jul 6, 2020, at 12:32 PM, Neil Madden <[email-masked]> wrote:
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Neil Madden <[email-masked]>
Date: Wed, 8 Jul 2020 17:17:10 +0100

> The two-phase approach is exactly what OBUK does, where you get one access token using client credentials before getting a more specific one in context of the user’s consent. This ends up being awk…

I’m not sure how client credentials would help here. The point I’m making is that the _user_ needs to consent to two separate things:

1. An initial consent to allow this app/service to initiate payment requests on my behalf.
2. Consent to individual transactions.

RAR (and open banking?) completely omits step 1 at the moment, which seems crucial. Especially if you’re doing something like CIBA backchannel where step 1 is effectively consent for this app to spam my phone with payment approval requests.

> With XYZ, I tried to design for that kind of multi-stage transaction pattern more explicitly, with the idea that you could continue your request in context and vary it over time, or even start a ne…

RAR is adopted by the OAuth WG so I think this needs to be discussed here.

— Neil

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 8 Jul 2020 18:20:10 +0200

Hi Neil, 

> On 8. Jul 2020, at 16:40, Justin Richer <[email-masked]> wrote:
> 

That’s a very good point.

There are scenarios where the client knows the resources it wants to interact with in advance, potentially from another transaction (e.g. first access to account list, payment initiation afterwards). 

The scenario you are describing is viable as well. In such a case, the request would be fairly generic but the AS (or the RS) would need to make transparent to the client what resources it just obtained access for. Interestingly, this might also happen if the client wants to access accounts. It could just request access to accounts and the user, in the consent, selects the accounts to disclose to the client. In our design at yes, we reflect this in an augmented authorization_details object in the token response (an addition for the spec I have on my list). 

>> Another issue is that as far as I can see in the current draft, any client can initiate a rich authorization request at any time without any kind of prior approval. This seems problematic for the…

I think RAR will almost always be used in conjunction with PAR. This means the client is authenticated before the user interaction starts preventing the attack you mentioned. I think we should at least recommend this in the draft. 

>> A related issue is that each approval is in effect a completely isolated incident. In a normal OAuth2 interaction I would grant an app some longish-term access to data and it would get an access t…

Some of the use cases initially causing the development of RAR are transactional (as pointed out by Vladimir) others are not. RAR is about a richer vocabulary for describing the scope of access.

In the beforementioned account information scenario, the client would, for example, ask for read access to several accounts. Access to balance for one and access to balance & transaction history for another account. This could easily be expressed using RAR and would be a long term grant. If the client for the same user asks for access to another account (and the user approves), the AS should add this to the same underlying grant. This effectively means, the client could use the same token (refresh and access token) to access all accounts. 

>> 1. In step 1 an app gets a normal long-lived access and/or refresh token that grants it permissions to ask to initial transactions (RARs) - e.g. with scope initiate_payments

I agree. This is PAR. PAR + RAR is in the end a generalised version of the UK OB consent pattern. 

>> I have ideas for how this could be achieved, but I’d prefer to see what others think of this general idea rather than getting bogged down in specific details.

best regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 8 Jul 2020 18:21:02 +0200

> On 8. Jul 2020, at 18:17, Neil Madden <[email-masked]> wrote:
> 

What in particular should the use consent with in this step?

---

From: Neil Madden <[email-masked]>
Date: Wed, 8 Jul 2020 17:59:46 +0100

> On 8 Jul 2020, at 17:21, Torsten Lodderstedt <[email-masked]> wrote:
> 
> 
> 

“FooPay would like to:
 - initiate payments from your account (you will be asked to approve each one)”

The point is that a client that I don’t have any kind of relationship with can’t just send me a request to transfer $500 to some account.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 8 Jul 2020 20:03:03 +0200

> On 8. Jul 2020, at 18:59, Neil Madden <[email-masked]> wrote:
> 
> 
> 

Are we talking about legal consent or a security measures here?

In case of open banking the user legally consents to this process at the client (TPP) even before the OAuth/Payment Initiation dance starts.

---

From: Neil Madden <[email-masked]>
Date: Wed, 8 Jul 2020 19:39:04 +0100

Hi Torsten,

> On 8 Jul 2020, at 17:20, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi Neil, 
> 

Ok, it sounds like this can be incorporated into the draft. 

> I think RAR will almost always be used in conjunction with PAR. This means the client is authenticated before the user interaction starts preventing the attack you mentioned. I think we should at l…

See other discussion. Client authentication is not the issue here, it’s about user consent. The underlying assumption appears to be that all legitimate clients registered with a bank are trustworthy because of vetting, reputation etc. Even putting aside that issue, as a user, if an app or service acts in a way that I don’t like then I should be able to stop using that app regardless of whether the app has violated any rules. 

In normal OAuth I can always go and revoke a grant to indicate that I no longer use that app/service. In RAR I don’t have that option because every transaction starts from scratch. I’m not arguing that every use of RAR will require this kind of two-phase user authorization approach, but that the current description of RAR seems to preclude using the normal OAuth mechanisms to manage this relationship in the transactional case. If PAR can bridge that gap, it would be good to explicitly call that out.

> In the beforementioned account information scenario, the client would, for example, ask for read access to several accounts. Access to balance for one and access to balance & transaction history fo…

I am generally against proposals that encourage accumulating authority in a single token, so I’m not convinced this is a good idea. But for the sake of argument, I’ll assume that there are good non-transactional applications of RAR. 

> I agree. This is PAR. PAR + RAR is in the end a generalised version of the UK OB consent pattern. 

PAR currently only allows client credentials to authorize requests to the pushed auth endpoint. But what I’m describing would instead use an access token (authorized by the user). This seems closer to what OB currently does, but using a user-approved access token rather than a client_credentials granted one.

There are other approaches, for example based on macaroon 3rd-party caveats. I’ll try to knock up a decent description or demo of the approach because it has some appealing properties. But whatever the implementation, the important thing is that there is some consideration of these issues. 

— Neil

---

From: Neil Madden <[email-masked]>
Date: Wed, 8 Jul 2020 19:46:50 +0100

> Are we talking about legal consent or a security measures here?

Normal OAuth consent. My phone is my resource, and I am its resource owner. If a client wants to send payment requests to my phone (e.g. via CIBA backchannel) then it should have to get my permission first. Even without backchannel requests, I’d much rather that only the three clients I’ve explicitly consented to can ask me to initiate payments rather than the hundreds/thousands clients my bank happens to have a relationship with.

> In case of open banking the user legally consents to this process at the client (TPP) even before the OAuth/Payment Initiation dance starts. 

How does the bank (ASPSP) confirm that this actually happened?

— Neil

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 8 Jul 2020 21:56:54 +0200

> Am 08.07.2020 um 20:46 schrieb Neil Madden <[email-masked]>:
> 

To me it sounds like you would like to require a client to get user authorization to send an authorization request. Would you require the same if I would use scope values to encode a payment initiation request?

> How does the bank (ASPSP) confirm that this actually happened?

It does not because it is not the responsibility of the ASPSP. The TPP is obliged by law to obtain consent.

---

From: Neil Madden <[email-masked]>
Date: Wed, 8 Jul 2020 22:52:12 +0100

> On 8 Jul 2020, at 20:56, Torsten Lodderstedt <[email-masked]> wrote:
> 

Yes. If something is sufficiently high value to require per-transaction authorization then initiating transactions itself becomes a privileged operation. 

> It does not because it is not the responsibility of the ASPSP. The TPP is obliged by law to obtain consent.

If the TPP can be trusted to obey the law about this, why not also trust them to be honest about transactions? Why enforce one thing with access tokens but take the other on trust? Especially as the actual transactions are more likely to have a rigorous audit trail. 

If we could trust clients to obtain consent we wouldn’t need OAuth at all. 

— Neil

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 9 Jul 2020 08:33:34 +0200

> On 8. Jul 2020, at 23:52, Neil Madden <[email-masked]> wrote:
> 
>> 

The per transaction authorization alone is a significant increase in security. What is the added value of requiring an authorization to send a per-transaction authorisation request in an additional step?

> If we could trust clients to obtain consent we wouldn’t need OAuth at all. 

I thought the same initially, but we must distinguish between legal consent and strong authentication/transaction authorization in such a case. Legal consent can be obtained in various ways including the traditional OAuth user consent but also in other places. Authenticating the user (probably with 2FA) and getting authorization for a certain transaction (the meaning of PSD2 SCA) must be conducted by the AS.

---

From: Dave Tonge <[email-masked]>
Date: Thu, 9 Jul 2020 09:28:32 +0200

Hi Neil

>From a conceptual point of view I'm not really sure what RAR changes from
vanilla OAuth?
For example what is the difference between a client redirecting a user to
an AS in order to:
 - grant access to sensitive health data
 - initiate a specific payment
 - grant full read/write access to file storage containing
sensitive commercial data

All of the above could happen with RAR or vanilla OAuth.

Ironically in most jurisdictions, there is more protection for a user if
they are tricked into initiating a payment vs whether they are tricked into
granting access to data. Payments can be refunded, data cannot.

>From my perspective if an AS is granting access to sensitive data,
payments, etc. then it has an obligation to protect its users by not
allowing any random client to to start an authorization flow. In the case
of Open Banking, this obligation is taken care of by national regulators,
but other commercial OAuth deployments often employ some form of vetting of
clients before allowing them to request sensitive data. In addition certain
sensitive actions can always require step-up authentication - this is also
the case in OpenBanking, a payment to a new payee or over a certain amount
will always require multi-factor authentication even if the user has a
valid logged in session.

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.

Dave

On Thu, 9 Jul 2020 at 08:34, Torsten Lodderstedt <torsten=
[email-masked]> wrote:

> >>> Am 08.07.2020 um 20:46 schrieb Neil Madden <[email-masked]
> >:
> >>>
> >>>>> The point is that a client that I don’t have any kind of
> relationship with can’t just send me a request to transfer $500 to some
> account.
> >>>>
> >>> Normal OAuth consent. My phone is my resource, and I am its resource
> owner. If a client wants to send payment requests to my phone (e.g. via
> CIBA backchannel) then it should have to get my permission first. Even
> without backchannel requests, I’d much rather that only the three clients
> I’ve explicitly consented to can ask me to initiate payments rather than
> the hundreds/thousands clients my bank happens to have a relationship with.
> >>
> >> To me it sounds like you would like to require a client to get user
> authorization to send an authorization request. Would you require the same
> if I would use scope values to encode a payment initiation request?
> >
> > Yes. If something is sufficiently high value to require per-transaction
> authorization then initiating transactions itself becomes a privileged
> operation.
>
> The per transaction authorization alone is a significant increase in
> security. What is the added value of requiring an authorization to send a
> per-transaction authorisation request in an additional step?
>
> >
> >>>>
> >>>> In case of open banking the user legally consents to this process at
> the client (TPP) even before the OAuth/Payment Initiation dance starts.
> >>>
> > If the TPP can be trusted to obey the law about this, why not also trust
> them to be honest about transactions? Why enforce one thing with access
> tokens but take the other on trust? Especially as the actual transactions
> are more likely to have a rigorous audit trail.
> >
> I thought the same initially, but we must distinguish between legal
> consent and strong authentication/transaction authorization in such a case.
> Legal consent can be obtained in various ways including the traditional
> OAuth user consent but also in other places. Authenticating the user
> (probably with 2FA) and getting authorization for a certain transaction
> (the meaning of PSD2 SCA) must be conducted by the AS.
>
> >
> > — Neil
>

-- 
Dave Tonge
CTO
<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.

---

From: Neil Madden <[email-masked]>
Date: Thu, 9 Jul 2020 08:51:54 +0100

> On 9 Jul 2020, at 07:33, Torsten Lodderstedt <[email-masked]> wrote:
> 
> 
> 

Because Open Banking allows any client at any time to send an asynchronous back channel request to my phone to approve a payment. This is pretty risky. 

I can’t think of another transactional auth system that allows this without some kind of initial indication of user consent. For example, in Apple Pay all payment requests must be initiated from an explicit user gesture, providing some indication that the user wants to use this. The Dropbox Chooser and Saver APIs also have to be triggered from a user gesture. Again, this provides some confirmation that the user actually initiated the interaction. 

In OAuth, the AS doesn’t have this level of integration into the client’s UI so it needs some other way to establish user consent. By the time the user has a payment confirmation request on their screen it’s too late. 

> I thought the same initially, but we must distinguish between legal consent and strong authentication/transaction authorization in such a case. Legal consent can be obtained in various ways includi…

Do you mean legal protection for the bank or their users? As a user, if an OB client acts in a way that I don’t like, but doesn’t break any actual laws or policies, what’s my recourse? In normal OAuth I can revoke the grant to that client. This is not possible in transactional uses of RAR, and that seems like a big difference that significantly changes the relationship between users and clients. 

— Neil

---

From: Neil Madden <[email-masked]>
Date: Thu, 9 Jul 2020 09:07:55 +0100

> On 9 Jul 2020, at 08:28, Dave Tonge <[email-masked]> wrote:
> 
> 
> Hi Neil
> 
> From a conceptual point of view I'm not really sure what RAR changes from vanilla OAuth?
> For example what is the difference between a client redirecting a user to an AS in order to:
>  - grant full read/write access to file storage containing sensitive commercial data

The difference is that one of these is transactional and the others aren’t. Normal OAuth relationships are durative and give the user some measure of control to manage that relationship over time. The transactional uses of RAR preclude this because every transaction is a completely isolated interaction. 

Unless you are suggesting dropping the transactional use-cases from RAR then this should be considered and addressed. 

> Ironically in most jurisdictions, there is more protection for a user if they are tricked into initiating a payment vs whether they are tricked into granting access to data. Payments can be refunded, data cannot.

> From my perspective if an AS is granting access to sensitive data, payments, etc. then it has an obligation to protect its users by not allowing any random client to to start an authorization flow.

I’m glad we agree. 

> In the case of Open Banking, this obligation is taken care of by national regulators, but other commercial OAuth deployments often employ some form of vetting of clients before allowing them to request sensitive data. In addition certain sensitive actions can always require step-up authentication - this is also the case in OpenBanking, a payment to a new payee or over a certain amount will always require multi-factor authentication even if the user has a valid logged in session.

Putting aside the question of whether regulation is an adequate substitute for user consent, RAR is being proposed as a general specification, not within the context of any specific regulatory framework. It’s not ok to just assume this will all be handled by deployments. 

> 
> 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. 

— Neil

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 9 Jul 2020 11:53:38 +0300

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

Vladimir

---

From: Neil Madden <[email-masked]>
Date: Thu, 9 Jul 2020 11:23:31 +0100

> On 9 Jul 2020, at 09:53, Vladimir Dzhuvinov <[email-masked]> wrote:
> 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 <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 <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

---

From: Dave Tonge <[email-masked]>
Date: Thu, 9 Jul 2020 18:06:42 +0200

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-masked]> 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
> 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 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.
>
>
> 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.
>
> 1. Ability to make PAR mandatory for approval of some scopes and/or for
> particular clients (determined by AS policy).
>   - 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
>

-- 

DISCLAIMER: This email

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 9 Jul 2020 19:47:19 +0300

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:
>
>     {
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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 9 Jul 2020 19:10:18 +0200

> Because Open Banking allows any client at any time to send an asynchronous back channel request to my phone to approve a payment. This is pretty risky. 

Can you please explain how you came to that conclusion and how it relates to RAR?

In the simplest of all scenarios the client sends authorization details instead of scope values through the user browser and this way starts the authorization process with the AS.

When RAR is combined with PAR, the client first stores the authorization request including authorization details at the AS in exchange for a reference to this data. It then uses this reference to start the authorization process. This is more secure and robust than sending the data through the browser. 

So what is the risk here and why do you think unsolicited backchannel requests are sent to your device?

---

From: Neil Madden <[email-masked]>
Date: Thu, 9 Jul 2020 18:17:27 +0100

On 9 Jul 2020, at 17:06, Dave Tonge <[email-masked]> 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:
> 
>     {
>             "https://example.com/payments <https://example.com/payments>"
>          ],
>          "instructedAmount": {
>             "currency": "EUR",
>             "amount": "123.50"
>          },
>          "paymentConsentId": "123",
>       }
> 

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

---

From: Neil Madden <[email-masked]>
Date: Thu, 9 Jul 2020 18:28:16 +0100

> Can you please explain how you came to that conclusion and how it relates to RAR?

https://openbankinguk.github.io/read-write-api-site3/v3.1.6/profiles/payment-initiation-api-profile.html <https://openbankinguk.github.io/read-write-api-site3/v3.1.6/profiles/payment-initiation-api-profile.html>

Client (PISP) initiates a payment-order consent using a client_credentials access token, then launches a CIBA backchannel authorization request. What prevents this?

This relates to RAR, because RAR also has no protection against this. If you use RAR in combination with a backchannel authorization method then the same issue applies. This is a general issue with backchannel approaches, but it is particularly a risk here because RAR is pitching itself as a way to do payment transactions.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 9 Jul 2020 19:34:29 +0200

> On 9. Jul 2020, at 19:28, Neil Madden <[email-masked]> wrote:
> 
> https://openbankinguk.github.io/read-write-api-site3/v3.1.6/profiles/payment-initiation-api-profile.html
> 

The fact that the PISP cannot issue this request without a valid user identifier. The demos I’m remembering use a traditional first authorization flow to establish this identifier.

> 
> This relates to RAR, because RAR also has no protection against this. If you use RAR in combination with a backchannel authorization method then the same issue applies. This is a general issue with backchannel approaches,

Exactly! It's a problem with any kind of backchannel initiated _user interaction_. 

> but it is particularly a risk here because RAR is pitching itself as a way to do payment transactions.

The problem is the backchannel request, not RAR. RAR is just a more elaborated scope.

---

From: Neil Madden <[email-masked]>
Date: Thu, 9 Jul 2020 18:58:16 +0100

> On 9 Jul 2020, at 18:34, Torsten Lodderstedt <[email-masked]> wrote:
> 

An identifier is not an access token or credential.

> The problem is the backchannel request, not RAR. RAR is just a more elaborated scope.

I don’t agree. It’s particularly acute with backchannel requests, but it still exists with front channel. If I can redirect your browser to a payment confirmation screen, what percentage of users will click ok? I would guess more than 0. It’s a problem precisely because a one-off interaction is enough to authorize a transaction.

It might be that in OB they accept this risk and mitigate it in other ways, e.g. making it easy to reverse transactions, or through sufficient vetting of clients and big legal consequences. As a UK banking user, that wouldn’t make me very happy but OK. The point is that RAR can’t make payment transactions the primary use-case, emphasised throughout the draft, and then fail to even discuss this issue or make any kind of suggestion as how to handle it. 

— Neil

---

From: Francis Pouatcha <[email-masked]>
Date: Sun, 12 Jul 2020 20:51:54 -0400

Hi Neil,

IMHO the purpose of RAR is to provide a rich substitute for oAuth2 scopes.

The point you are addressing in this thread is nevertheless very pertinent,
even though not directly related to RAR.

Proof of RO (PSU) authorized interaction between the RO and the Client
(TPP) prior to starting an payment authorization request is essential.

The NextGenPSD2 specification addresses the problem with a so-called oAuth2
pre-step option. As this requires two authorization operations (SCA) for
the release of a single payment, banks implementing oAuth2 pre-step fell
under the scrutiny of the EBA (European Banking Association) last June. Now
those banks have the burden of proving to their NCA's (national
market/country authorities) that pre-step is necessary to mitigate the very
problem you are raising in this thread.

Let settle with:
- RAR as a payload for carrying authorization details
- The decision on whether to protect an authorization transaction with a
preceding RO authorization to do so shall be left to the target oAuth2
profile.

Best regards
/Francis

On Thu, Jul 9, 2020 at 1:58 PM Neil Madden <[email-masked]>
wrote:

> >>>>>>>> Normal OAuth consent. My phone is my resource, and I am its
> resource owner. If a client wants to send payment requests to my phone
> (e.g. via CIBA backchannel) then it should have to get my permission first.
> Even without backchannel requests, I’d much rather that only the three
> clients I’ve explicitly consented to can ask me to initiate payments rather
> than the hundreds/thousands clients my bank happens to have a relationship
> with.
> >>>>>>>
> >>>>>>> To me it sounds like you would like to require a client to get
> user authorization to send an authorization request. Would you require the
> same if I would use scope values to encode a payment initiation request?
> >>>>>>
> >>>>>> Yes. If something is sufficiently high value to require
> per-transaction authorization then initiating transactions itself becomes a
> privileged operation.
> >>>>>
> >>>> Because Open Banking allows any client at any time to send an
> asynchronous back channel request to my phone to approve a payment. This is
> pretty risky.
> >>>
> >> Client (PISP) initiates a payment-order consent using a
> client_credentials access token, then launches a CIBA backchannel
> authorization request. What prevents this?
> >
> > The fact that the PISP cannot issue this request without a valid user
> identifier. The demos I’m remembering use a traditional first authorization
> flow to establish this identifier.
>
> >> This relates to RAR, because RAR also has no protection against this.
> If you use RAR in combination with a backchannel authorization method then
> the same issue applies. This is a general issue with backchannel approaches,
> >
> I don’t agree. It’s particularly acute with backchannel requests, but it
> still exists with front channel. If I can redirect your browser to a
> payment confirmation screen, what percentage of users will click ok? I
> would guess more than 0. It’s a problem precisely because a one-off
> interaction is enough to authorize a transaction.
>
> It might be that in OB they accept this risk and mitigate it in other
> ways, e.g. making it easy to reverse transactions, or through sufficient
> vetting of clients and big legal consequences. As a UK banking user, that
> wouldn’t make me very happy but OK. The point is that RAR can’t make
> payment transactions the primary use-case, emphasised throughout the draft,
> and then fail to even discuss this issue or make any kind of suggestion as
> how to handle it.
>
> — Neil
>

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 13 Jul 2020 10:29:35 +0200

> On 9. Jul 2020, at 19:58, Neil Madden <[email-masked]> wrote:
> 
> The point is that RAR can’t make payment transactions the primary use-case, emphasised throughout the draft, and then fail to even discuss this issue or make any kind of suggestion as how to handle it. 

I’m still trying to understand the issue and your proposed solution. What you are suggesting is an OAuth authorization to subsequently send another more detailed or transactional OAuth authorization. 

If your basic assumption is that users just accept a payment conformation screen, why do you think the additional pre-authorization won’t be accepted straight away?

The way PSD2 uses to secure such transactions is transaction authorization using a dynamic second factor (called strong customer authentication). I assume the rational is SCA will make users think before they confirm.

---

From: Neil Madden <[email-masked]>
Date: Mon, 13 Jul 2020 15:16:31 +0100

> On 13 Jul 2020, at 01:52, Francis Pouatcha <[email-masked]> wrote:
> 
> 
> Hi Neil,
> 
> The point you are addressing in this thread is nevertheless very pertinent, even though not directly related to RAR. 

I think it is absolutely related. 

> 
> Proof of RO (PSU) authorized interaction between the RO and the Client (TPP) prior to starting an payment authorization request is essential.
> 
> The NextGenPSD2 specification addresses the problem with a so-called oAuth2 pre-step option. As this requires two authorization operations (SCA) for the release of a single payment, banks implementing oAuth2 pre-step fell under the scrutiny of the EBA (European Banking Association) last June. Now those banks have the burden of proving to their NCA's (national market/country authorities) that pre-step is necessary to mitigate the very problem you are raising in this thread.

I’m not sure this is the same issue I’m raising in this thread. In particular, what I’m suggesting would *not* need two authorization requests per payment. What I am suggesting is that there is one long-lived authorization between the RO and a client and then individual authorizations of each transaction: 1 + N not 2N. 

> - The decision on whether to protect an authorization transaction with a preceding RO authorization to do so shall be left to the target oAuth2 profile.
> 
>> On Thu, Jul 9, 2020 at 1:58 PM Neil Madden <[email-masked]> wrote:
>>

---

From: Neil Madden <[email-masked]>
Date: Mon, 13 Jul 2020 15:33:02 +0100

> On 13 Jul 2020, at 09:29, Torsten Lodderstedt <[email-masked]> wrote:
> 
> 
> 

It’s not about having two authorization screens. It’s about allowing users to manage their relationship with a client just as they can for any other OAuth client. If a normal OAuth client behaves badly I can go and revoke my grant of access to that client. I can’t do that with the transactional uses of RAR because each one is a blank slate. 

Having individual transactions tied to an overall grant of authority lets the user control which clients they interact with and which they trust. 

To me, this (user consent and control) is a fundamental strength of OAuth and any approach to transactional authorization using OAuth should preserve this. 

The other point I was making is that when the transactional authorization occurs over a backchannel then it is much better if the user has previously explicitly authorized that client over a front channel - eg when they first installed an app. I’m not suggesting that the AS would send two backchannel authorization requests instead of one. 

> The way PSD2 uses to secure such transactions is transaction authorization using a dynamic second factor (called strong customer authentication). I assume the rational is SCA will make users think…

I hope so. But given that authN usually occurs before the consent stage, the user may not know what it is they are consenting to before they complete 2FA. 

— Neil

---

From: Francis Pouatcha <[email-masked]>
Date: Mon, 13 Jul 2020 11:44:24 -0400

> The NextGenPSD2 specification addresses the problem with a so-called
> oAuth2 pre-step option. As this requires two authorization operations (SCA)
> for the release of a single payment, banks implementing oAuth2 pre-step
> fell under the scrutiny of the EBA (European Banking Association) last
> June. Now those banks have the burden of proving to their NCA's (national
> I’m not sure this is the same issue I’m raising in this thread. In
> particular, what I’m suggesting would *not* need two authorization requests
> per payment. What I am suggesting is that there is one long-lived
> authorization between the RO and a client and then individual
> authorizations of each transaction: 1 + N not 2N.
>
For the first payment you will need 2 authorizations. This is what I mean
with the pre-step above.

And I understand you want to introduce grant management for the first
durable authorization, so RO can revoque this correct?

>> >>>>> The per transaction authorization alone is a significant increase
>> in security. What is the added value of requiring an authorization to send
>> a per-transaction authorisation request in an additional step?
>> >>>>

---

From: Neil Madden <[email-masked]>
Date: Mon, 13 Jul 2020 18:18:03 +0100

On 13 Jul 2020, at 16:44, Francis Pouatcha <[email-masked]> wrote:
> For the first payment you will need 2 authorizations. This is what I mean with the pre-step above.

Well it’s still only 1 authorization for the actual payment. The first authorization is the permission to initiate subsequent payment authorizations. I would imagine that most forms of fine-grained or transactional authorization will be used alongside more traditional forms of OAuth authorization, so this would be pretty natural in practice. For example, on first launch of an app you might get a consent screen like:

FooPay would like to:
 - List your accounts
 - View your account balance
 - Initiate payments from your account (you’ll be asked to approve each one)

> 
> And I understand you want to introduce grant management for the first durable authorization, so RO can revoque this correct?

This is a pretty standard feature of AS software, so I’d opt for “preserve” rather than “introduce”.

— Neil