[Openid-specs-fapi] Fine-grained authorization for payments

Fri Mar 24 00:53:04 UTC 2017

The context of these emails is a bit unclear. The only piece in the spec on
the FAPI site is a transfer, which I take to be a intra-bank transfer.

It is unclear if the above is about a payment object sent to the bank of
the "user" making a payment to a bank account of a "recipient,

or if it is about a payment object sent to the bank of the 'user'
requesting that the bank make a payment to a previously established
correspondent of the 'user'

In any case the receipt might be only an acknowledgement that a payment
will occur on a future date, or it might be a completely async response to
money becoming available to the recipient.

I guess that more context of the problem being solved would be helpful.
..tomj

On Thu, Mar 23, 2017 at 3:48 PM, Dave Tonge via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> wrote:

> Hi Tom, Nat
>
> Thanks for the replies.
>
> Tom - as Nat said I fully expect the FI's to run their own checks, I'm
> just talking about kicking off the process.
> In Europe with PSD2 we have legislation that bank customers can use PISPs
> (payment initiation service providers) to initiate payments.
>
> Nat, thanks I didn't realise about the request object registration
> endpoint - it seems an excellent fit. The OIDC spec isn't particularly
> clear about it though, but https://tools.ietf.org/htm
> l/draft-ietf-oauth-jwsreq-12#section-10.3 paragraph D explains it fully.
>
> The 4 suggested endpoints look good, although I would maybe join 3 and 4?
>
> I have a couple of follow up questions:
>
> 1. Would you envisage passing the fine-grained payment details in the
> claims property of the request object?
> 2. The "commit of intent" API I see as being an auth code flow.
> Essentially the resource owner is granting access to a very specific
> resource (a single payment transaction). However if we follow an auth code
> flow then we would expect to end up with an access token. That token could
> then be used to commit the intent. Does this make sense to you?
>
> Thanks again - I will feed this into the UK Open Banking group.
> I'm also working on the ability to share some of the proposed endpoints
> form that group with the FAPI WG.
>
> Thanks
>
> Dave
>
>
>
>
>
> On 23 March 2017 at 20:57, Nat Sakimura via Openid-specs-fapi <
> openid-specs-fapi at lists.openid.net> wrote:
>
>> Hi
>>
>> Just briefly on the point of the outbound access by the banks.
>>
>> Banks can provide request object registration endpoint that produces
>> requiest_uri.
>> This should solve the problem. In fact, this was one of the main use case.
>> That's why the spec is saying "The request_uri value MUST be reachable by
>> the Authorization Server, and SHOULD be reachable by the Client." in
>> section 6.2 of the OpenID Connect Core.
>>
>> I do not think UMA has anything to do here.
>>
>> Also, I should note that any transfer/payment request is only request.
>> After the request is being authorized by the user and committed, banks
>> needs to screen it for AML purposes etc. So, having sufficient funds alone
>> is not a sufficient condition for it to go through. Payment will not be
>> synchronous.
>>
>> So, in general, form the API point of view,
>>
>> 1. Creation of the intent (registering of the request object: request
>> object endpoint)
>> 2. Commit of the intent (preferably done on a second channel:
>> authorization endpoint and user questioning)
>> 3. Payment status check / callback / notification (status check endpoint)
>> 4. Getting Payment result / receipt (payment result endpoint)
>>
>> are needed.
>>
>> Also, in case of the money transfer, it often is required to have:
>>
>> 0.1. Destination information verification endpoint
>> 0.2. Pre-registered destination account information endpoint
>>
>> I have a bit of documentation explaining what NRI as a backend service
>> provider for banks does in Japan, but they are in Japanese...
>>
>> Best,
>>
>> ---
>> Nat Sakimura
>> Chairman, OpenID Foundation
>>
>> On 2017-03-24 01:16, Dave Tonge via Openid-specs-fapi wrote:
>>
>>> Dear FAPI WG Members
>>>
>>> When it comes to payments, standard OAuth scopes are too
>>> coarse-grained to
>>> be the sole communication of the "access" to be authorised. The most
>>> common scenario
>>> for payments via a FAPI API is likely to be one-off payments of a
>>> specific amount
>>> to a specific payee (and from a specific account at a specific time).
>>>
>>> If the FAPI spec doesn't address the communication of this data, there
>>> are likely
>>> to be multiple incompatible implementions.
>>>
>>> Proposals that I've come accross include having a "staging" endpoint
>>> where the
>>> client registers "intent" to perform an action by sending a payload
>>> with the
>>> specific payment details and receives a "ticket id". This ticket id is
>>> then
>>> included along with high level scopes in an authorization code flow.
>>> The
>>> ticket id could be included in the claims parameter:
>>> http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter
>>> [1]
>>> or could be part of the request object:
>>> http://openid.net/specs/openid-connect-core-1_0.html#JWTRequests [2]
>>>
>>> While it could be preferable to avoid having a separate staging
>>> endpoint - and
>>> put any extra data in a signed request object, the reality is that the
>>> request
>>> could be too large. While this could be solved by passing in a
>>> "request_uri"
>>> that points at a request object,  this has issues as many banks
>>> currently have
>>> strict restrictions on outbound network access. Also it seems that
>>> the
>>> "request_uri" option would work best when the parameters in the
>>> request object
>>> are fairly static.
>>>
>>> What do FAPI members think about this problem?
>>> Are there existing standards that we could refer, for example it would
>>> seem
>>> that the UMA spec would help here?
>>> https://docs.kantarainitiative.org/uma/rec-uma-core.html [3]
>>>
>>> Thanks
>>>
>>> Dave
>>>
>>> --
>>>
>>> Dave Tonge
>>> CTO
>>>  [4]
>>> 10 Temple Back, Bristol, BS1 6FLt: +44 (0)117 280 5120
>>> <+44%20117%20280%205120>
>>>
>>> Moneyhub Enterprise is a trading style of Momentum Financial
>>> Technology Limited which is authorised and regulated by the Financial
>>> Conduct Authority ("FCA"). Momentum Financial Technology is entered
>>> on the Financial Services Register (FRN 561538) at
>>> fca.org.uk/register [5]. Momentum Financial Technology is registered
>>> in England & Wales, company registration
>>> number 06909772 © . Momentum Financial Technology Limited
>>> 2016. 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 Momentum
>>> Financial Technology Limited or of any other group company.
>>>
>>> Links:
>>> ------
>>> [1] http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter
>>> [2] http://openid.net/specs/openid-connect-core-1_0.html#JWTRequests
>>> [3] https://docs.kantarainitiative.org/uma/rec-uma-core.html
>>> [4]
>>> http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.
>>> com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A
>>> [5] http://fca.org.uk/register
>>>
>>> _______________________________________________
>>> Openid-specs-fapi mailing list
>>> Openid-specs-fapi at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>>>
>> _______________________________________________
>> Openid-specs-fapi mailing list
>> Openid-specs-fapi at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>>
>
>
>
> --
> Dave Tonge
> CTO
> [image: Moneyhub Enterprise]
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
> 10 Temple Back, Bristol, BS1 6FL
> t: +44 (0)117 280 5120 <+44%20117%20280%205120>
>
> Moneyhub Enterprise is a trading style of Momentum Financial Technology
> Limited which is authorised and regulated by the Financial Conduct
> Authority ("FCA"). Momentum Financial Technology is entered on the
> Financial Services Register (FRN 561538) at fca.org.uk/register. Momentum
> Financial Technology is registered in England & Wales, company registration
> number 06909772 © . Momentum Financial Technology Limited 2016. 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 Momentum Financial
> Technology Limited or of any other group company.
>
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>
>

-- 
..tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20170323/aae2e240/attachment-0001.html>