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

[Neil Madden]

> On 8 Jul 2020, at 20:56, Torsten Lodderstedt  wrote:
> 
>>> Am 08.07.2020 um 20:46 schrieb Neil Madden :
>>> 
>> On 8 Jul 2020, at 19:03, Torsten Lodderstedt  
>> wrote:
> 
> What in particular should the use consent with in this step?
 
 “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. 
>>> 
>>> 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.
> 
> 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.. 

>>> 
>>> 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?
> 
> 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___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

> Am 08.07.2020 um 20:46 schrieb Neil Madden :
> 
> On 8 Jul 2020, at 19:03, Torsten Lodderstedt  
> wrote:
 
 What in particular should the use consent with in this step?
>>> 
>>> “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. 
>> 
>> 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.

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?

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

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

> 
> — Neil


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Neil Madden]

On 8 Jul 2020, at 19:03, Torsten Lodderstedt  wrote:
>>> 
>>> What in particular should the use consent with in this step?
>> 
>> “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. 
> 
> 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___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Neil Madden]

Hi Torsten,

> On 8 Jul 2020, at 17:20, Torsten Lodderstedt  wrote:
> 
> Hi Neil, 
> 
>> On 8. Jul 2020, at 16:40, Justin Richer  wrote:
>> 
>> 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  wrote:
>>> 
>>> 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.
> 
> 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). 

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

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

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.

>>> A related issue is that each approval is in effect a completely 

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

[Torsten Lodderstedt]

> On 8. Jul 2020, at 18:59, Neil Madden  wrote:
> 
> 
> 
>> On 8 Jul 2020, at 17:21, Torsten Lodderstedt  wrote:
>> 
>> 
>> 
>>> On 8. Jul 2020, at 18:17, Neil Madden  wrote:
>>> 
 On 8 Jul 2020, at 15:40, Justin Richer  wrote:
 
 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.
>>> 
>>> 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.
>> 
>> What in particular should the use consent with in this step?
> 
> “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. 

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. 

> 
>> 
>>> 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 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.
>>> 
>>> RAR is adopted by the OAuth WG so I think this needs to be discussed here.
>>> 
>>> — Neil
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Neil Madden]

> On 8 Jul 2020, at 17:21, Torsten Lodderstedt  wrote:
> 
> 
> 
>> On 8. Jul 2020, at 18:17, Neil Madden  wrote:
>> 
>>> On 8 Jul 2020, at 15:40, Justin Richer  wrote:
>>> 
>>> 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.
>> 
>> 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.
> 
> What in particular should the use consent with in this step?

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

> 
>> 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 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.
>> 
>> RAR is adopted by the OAuth WG so I think this needs to be discussed here.
>> 
>> — Neil
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

> On 8. Jul 2020, at 18:17, Neil Madden  wrote:
> 
> On 8 Jul 2020, at 15:40, Justin Richer  wrote:
>> 
>> 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.
> 
> 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.

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

> 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 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.
> 
> RAR is adopted by the OAuth WG so I think this needs to be discussed here.
> 
> — Neil
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

Hi Neil, 

> On 8. Jul 2020, at 16:40, Justin Richer  wrote:
> 
> 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  wrote:
>> 
>> 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.

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

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 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?)

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 

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

[Neil Madden]

On 8 Jul 2020, at 15:40, Justin Richer  wrote:
> 
> 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.

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

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

— Neil
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Justin Richer]

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  wrote:
> 
> 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 
> 
> [2]: https://www.dropbox.com/developers/saver 
>  
> 
> — Neil
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Neil Madden]

On 7 Jul 2020, at 21:09, Vladimir Dzhuvinov  wrote:
> 
> 
>> On 06/07/2020 19:32, Neil Madden wrote:
>> 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?)
> 
> 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.
> 
>> 
>> 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
> 
> 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.
> 

Do you have any examples? 

I think this is something the draft needs to address. 

Neil
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth