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

Nat Sakimura nat at sakimura.org
Fri Mar 24 03:06:28 UTC 2017



---
Nat Sakimura
Chairman, OpenID Foundation

On 2017-03-24 07:48, Dave Tonge 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/html/draft-ietf-oauth-jwsreq-12#section-10.3
> [7] paragraph D explains it fully.
> 
> The 4 suggested endpoints look good, although I would maybe join 3 and
> 4?

Possibly. But they are semantically different so it would be better
to have separate endpoint from the REST principle, IMHO.

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

Yes. The original intent of the signed request object was exactly this.

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

To me, the intent is committed once the user authorizes the transaction
at the Authorization Endpoint. As the result, the AuthZ EP returns
`code` and `id_token` (which actually is nothing but a detached 
signature
for the response).

The access token that you get using `code` is used for status check
and to get the receipt, IMHO.

Best,

Nat

> 
> 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]
>>> [1] 
>>> or could be part of the request object:
>>> http://openid.net/specs/openid-connect-core-1_0.html#JWTRequests
>>> [2] [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] [3]
>>> 
>>> Thanks
>>> 
>>> Dave​
>>> 
>>> --
>>> 
>>> Dave Tonge
>>> CTO
>>>  [4]
>>> 10 Temple Back, Bristol, BS1 6FLt: +44 (0)117 280 5120
>>> 
>>> 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 [4] [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
>>> [1]
>>> [2]
>>> http://openid.net/specs/openid-connect-core-1_0.html#JWTRequests
>>> [2]
>>> [3] https://docs.kantarainitiative.org/uma/rec-uma-core.html [3]
>>> [4]
>>> 
>> 
> http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A
>>> [5]
>>> [5] http://fca.org.uk/register [4]
>>> 
>>> _______________________________________________
>>> Openid-specs-fapi mailing list
>>> Openid-specs-fapi at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi [6]
>> 
>> _______________________________________________
>> Openid-specs-fapi mailing list
>> Openid-specs-fapi at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi [6]
> 
> --
> 
> Dave Tonge
> CTO
>  [8]
> 10 Temple Back, Bristol, BS1 6FLt: +44 (0)117 280 5120
> 
> 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 [4]. 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://fca.org.uk/register
> [5]
> http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&amp;sa=D&amp;sntz=1&amp;usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A
> [6] http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> [7] https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-12#section-10.3
> [8]
> http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A


More information about the Openid-specs-fapi mailing list