[Openid-specs-fapi] Initial review of OpenID Connect User Questioning API 1.0
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.
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
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.
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
I hope this review helps and again I apologise if there are any parts of
the spec that I've misunderstood or misinterpreted.
[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...
More information about the Openid-specs-fapi