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

[Dave Tonge <[e-mail]>]

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=
[e-mail]> wrote:

>
>
> > On 8. Jul 2020, at 23:52, Neil Madden <[e-mail]> wrote:
> >
> >>
> >> On 8 Jul 2020, at 20:56, Torsten Lodderstedt <[e-mail]>
> wrote:
> >>
> >>> Am 08.07.2020 um 20:46 schrieb Neil Madden <[e-mail]
> >:
> >>>
> >>> On 8 Jul 2020, at 19:03, Torsten Lodderstedt <[e-mail]>
> 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.
>
> 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.
> >>>
> >>> 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.
>
> 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
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> 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: [phone]

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.