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

Nat Sakimura nat at sakimura.org
Thu Mar 23 20:57:57 UTC 2017


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


More information about the Openid-specs-fapi mailing list