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

Nat Sakimura nat at sakimura.org
Fri Mar 24 20:50:59 UTC 2017


We could potentially add "Notes".
I feel that real thing should be in Part 5 but it would be useful to 
have these as notes or examples for the readers to understand why it is 
like that.

---
Nat Sakimura
Chairman, OpenID Foundation

On 2017-03-24 23:57, Dave Tonge wrote:
> Thanks Nat - this is really helpful.
> Do any of these considerations need to feed into the Read/Write
> Security Profile?
> 
> Dave
> 
> On 24 March 2017 at 03:06, Nat Sakimura <nat at sakimura.org> wrote:
> 
>> ---
>> 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
>>> [1]
>>> [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
>> [2]
>> 
>> [1]
>> [1] 
>> or could be part of the request object:
>> http://openid.net/specs/openid-connect-core-1_0.html#JWTRequests
>> [3]
>> [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 [4] [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 [5] [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
>> [2]
>> [1]
>> [2]
>> http://openid.net/specs/openid-connect-core-1_0.html#JWTRequests
>> [3]
>> [2]
>> [3] https://docs.kantarainitiative.org/uma/rec-uma-core.html [4]
>> [3]
>> [4]
> 
> http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A
> [7]
> 
>>> [5]
>>> [5] http://fca.org.uk/register [5] [4]
>>> 
>>> _______________________________________________
>>> Openid-specs-fapi mailing list
>>> Openid-specs-fapi at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi [6]
>>> [6]
>> 
>> _______________________________________________
>> Openid-specs-fapi mailing list
>> Openid-specs-fapi at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi [6] [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 [5] [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]
>  [2] http://openid.net/specs/openid-connect-core-1_0.html#JWTRequests
> [3]
>  [3] https://docs.kantarainitiative.org/uma/rec-uma-core.html [4]
>  [4] http://fca.org.uk/register [5]
>  [5]
> 
> http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&amp;sa=D&amp;sntz=1&amp;usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A
> [8]
>  [6] http://lists.openid.net/mailman/listinfo/openid-specs-fapi [6]
>  [7]
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-12#section-10.3
> [1]
>  [8]
> 
> http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A
> [7]
> 
> --
> 
> Dave Tonge
> CTO
>  [9]
> 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 [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] https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-12#section-10.3
> [2] 
> http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter
> [3] http://openid.net/specs/openid-connect-core-1_0.html#JWTRequests
> [4] https://docs.kantarainitiative.org/uma/rec-uma-core.html
> [5] http://fca.org.uk/register
> [6] http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> [7]
> http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&amp;sa=D&amp;sntz=1&amp;usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A
> [8]
> http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&amp;amp;sa=D&amp;amp;sntz=1&amp;amp;usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A
> [9]
> 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