[Openid-specs-fapi] Initial review of OpenID Connect User Questioning API 1.0

[Tom Jones]

there is another way to look at the impact of questioning on the
FI/Customer experience, and that is to examine the use cases as see if the
questioning api could improve either the experience or the security of each
use case.

Here are a few real-world use cases of which i am aware.

1. The use signs up to get notification of events. He is allows to select
the events at some level of detail. Examples are: a) low balance, b)
deposits, c) bill payments scheduled.
2. The events require responses from the user, many for the same events. a)
low balance can trigger a transfer, b) deposits may initiate pending
payments, c) bills received may initiate a variety of responses from
setting up a new vendor account, to accepting the bill for payment at a
time that is comeasurate with the due date.

it seems to me that solving real problems is preferable to broad sweeping
generalization.

It also seems to me that sms messaging is already solving these today, so
it is incumbent upon us to determine if FAPI can offer a better solution
than what exists today.

..tom

On Tue, May 30, 2017 at 7:19 AM, Dave Tonge via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> wrote:

> Dear FAPI & MODRNA list members,
>
> As discussed in the last FAPI call we agreed to review the User
> Questioning API from a FAPI perspective.
>
> I’ve reviewed the spec and here are my initial thoughts:
>
> General thoughts on scope
>
> The FAPI spec has been designed for the following scenarios:
>
>
>    1.
>
>    A Financial Institution or Service Provider uses the standard for its
>    own applications and services.
>    2.
>
>    A Financial Institution or Service Provider uses the standard to
>    expose an API for third party applications and services to use.
>
>
> My main interest is in the 2nd scenario and I don’t believe the user
> questioning API supports this.
>
> From my understanding the user questiong API allows a “client” to receive
> a “user statement token” from an OP that asserts:
>
>    -
>
>    A unique identifier for the user
>    -
>
>    That the user was authenticated with a given AMR / ACR
>    -
>
>    That the user has been shown a question and a list of possible
>    statements
>    -
>
>    The statement that the user has selected
>    -
>
>    The datetime that the user selected the statement
>
>
> This token is signed by the OP.
>
> From a financial API perspective I believe this spec would only work in
> the following use cases:
>
>
>    1.
>
>    A bank uses the API for its own internal services (it is the OP and
>    the RP)
>    2.
>
>    A bank delegates authentication and authorisation to a separate OP
>    (e.g. an MNO)
>
>
> In Europe banks will soon be required to perform ‘strong customer
> authentication’ (SCA) when processing payments initiated online or when
> granting access to account information. I know that the GSMA and some MNO’s
> view “moble connect” as a solution to SCA
> <https://www.eba.europa.eu/regulation-and-policy/payment-services-and-electronic-money/regulatory-technical-standards-on-strong-customer-authentication-and-secure-communication-under-psd2?p_p_auth=T7ZGiycR&p_p_id=169&p_p_lifecycle=0&p_p_state=maximized&p_p_col_id=column-2&p_p_col_pos=1&p_p_col_count=2&_169_struts_action=%2Fdynamic_data_list_display%2Fview_record&_169_recordId=1614919>,
> however, I’m not yet aware of any bank who has decided to go down this
> path.
>
> If a bank does use MNO’s as idPs, then this API could make sense for the
> bank to use and could be a solution to SCA.
>
> The spec will not work for “payment initiation service providers” or
> “account information service providers” though. For those use cases, the
> client is a third party who is requesting access or initiating a payment,
> and the OP is a bank who performs authentication and authorisation and then
> grants access or executes the payment.
>
>
> Two modes of operation
>
> The user questioning API can be used with an access token tied to an
> end-user or an access token not tied to any end-user. I presume an access
> token not tied to an end user would have been issued via a client
> credentials grant.
>
> I think it would be helpful to make these two modes clearer, i.e.
>
>    -
>
>    One mode involves a client asking a question of a user who has
>    previously granted the client permission to ask questions
>    -
>
>    The other mode involves a client being granted access to ask questions
>    for any/some users at the OP
>
>
> I think these 2 use cases should be made clearer.
>
> Reachability mean
>
> I think this phrase either needs a definition or should be adjusted to
> something like “reachability method”.
>
> Spelling / Grammar:
>
> The OP SHOULD consider the first authentication methods of the wished_amr
> list as the more prioritary highest priority.
>
> 4.2.1 Polling Request
>
> What happens if the access token used to ask the question has expired and
> the user hasn’t granted “offline access” (i.e. there is no refresh token).
> I would have thought that once the question has been asked, the client
> should have access to retrieve the answer to the question using its client
> credentials?
>
> 4.3.2 User Questioning Error Response
>
> For the success response, the payload is signed so the client has a high
> degree of assurance about the source authentication and integrity of the
> payload. However, for the error response, the client is relying on a bearer
> token. Should error responses be signed as well?
>
> 4.3.4 Response Acknowledgement
>
> What happens if the client doesn’t respond with an HTTP 200 OK? Should the
> OP retry?
>
>
> ________
>
>
> I hope this review helps and again I apologise if there are any parts of
> the spec that I've misunderstood or misinterpreted.
>
>
>
> --
> 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/20170530/a98bc7a9/attachment-0001.html>