[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&sa=D&sntz=1&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