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

[Tom Jones]

First of all, don't flatter yourselves to think that any fiduciary
institution will accept any payment object from FAPI w/o running it through
their own anti-fraud measures.

Account holders generally have full statutory control of their accounts.
That is not your concern.

Agents for account holders, called users in some of your docs, have limited
authority, usually based on amount of payment. In some cases more that one
agent must sign a payment order for it to be valid.

Secondary authorizations are often used, such as total amounts sent by a
different channel.

So the identity of the agent (user) is required for the FI to make a
determination, among many other criteria out side of the payment path.

AFAICT there is no real proposal for a payment object at this time, nor is
there any real proposal for the path that a payment object might take.
These need to be determined before you get into names of fields.
..tom

On Thu, Mar 23, 2017 at 9:16 AM, Dave Tonge via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> 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
> or could be part of the request object:
> http://openid.net/specs/openid-connect-core-1_0.html#JWTRequests
>
> 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
>
>
> ​Thanks
>
> Dave​
>
>
>
> --
> 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/49392ab1/attachment-0001.html>