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

Dave Tonge dave.tonge at momentumft.co.uk
Tue May 30 14:19:39 UTC 2017

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:


   A Financial Institution or Service Provider uses the standard for its
   own applications and services.

   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:


   A bank uses the API for its own internal services (it is the OP and the

   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
however, I’m not yet aware of any bank who has decided to go down this

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

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
[image: Moneyhub Enterprise]
10 Temple Back, Bristol, BS1 6FL
t: +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. 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20170530/0a275366/attachment-0001.html>

More information about the Openid-specs-mobile-profile mailing list