[Openid-specs-fapi] Initial review of MODRNA Client initiated Backchannel Authentication Flow 1.0

[Dave Tonge]

Hi all,

We discussed on the last call that it would be good to review the
MODRNA backchannel auth and user questioning specs from a FAPI perspective.

I've started to go through them both and here are my initial thoughts on
the Backchannel Authentication spec
<http://openid.net/specs/openid-connect-modrna-client-initiated-backchannel-authentication-1_0.html#rfc.section.4.1>
:

2. Terminology

The definition for Consumption Device states that it is “most probably a
browser”. It is envisaged that this will often not be the case, for payment
APIs, e.g. the flow could be initiated via a POS device.

3. Overview

Spelling mistake - “inmediatly” -> “immediately”

4.1 Authentication Request

Client Authentication - this should be restricted to the methods listed in
FAPI (i.e. private_key_jwt or MTLS)

Client_notification_token - this is a bearer token used by the OP when
notifying the client via the `client_notification_endpoint`. In the FAPI
spec we are moving away from bearer tokens to either sender contained
tokens or OATB tokens. While this token is used for OP -> client rather
than client -> OP should we still consider constraining the tokens?


A simpler approach may be to ensure that the OP signs any payload sent to
the `client_notification_endpoint`. Currently, these payloads (error or
success) are plain JSON payloads. The success payload contains an
`id_token`, but this token contains claims about the identity of the user
rather than acting as a detached signature for the access token (and
refresh token)

Binding_message - as I understand it the binding message is shown to the
user on both the consumption and the authentication device. The spec then
relies on the user checking that both messages are the same. If the spec
were to be used for payments then I would suggest that the binding message
is shown on the consumption device and entered by the user on the
authentication device. This would be more secure than relying on the user
to cross-check both messages are the same.


For example, this spec could be used to support bank payments at a petrol
station - the user could enter their phone number into the POS device, they
would then receive a notification from their banking app asking them to
authorise a payment. However what is to prevent someone entering the user’s
phone number at the same time at the same petrol station when paying for
fuel of the same amount. If the POS device displayed a 6 digit pin to the
user, and the user entered that pin as part of the authorization flow in
their banking app, then all parties would have a higher degree of
confidence about the transaction.

The binding message should be required and not optional for payments.

4.2.1 Authentication Request Validation

The authentication request is a plain JSON payload, but because this is
happening over a channel protected by client authentication this should be
sufficient.

5. OpenID Provider Obtains End-user Consent/Authorization

The spec is focussed on user authentication rather than a user authorising
a specific action, e.g. making a payment. The wording in this section could
be confusing to those implementing it for a financial API.

In order to support fine-grained authorisation, the spec would need to
support the OIDC claims parameter and guidance would need to be provided to
implementers on example flows for payments and account information access.

6.1 Token Request Using Polling Mechanism

The spec should refer back to OIDC Core - 3.1.3 - token endpoint - as all
the verification steps described there should be performed.

In addition, it should be made clear in the spec that the `auth_req_id`
MUST be bound to the client to which it was issued. At the moment it would
seem that any client could send any `auth_req_id`.

6.2 Successful Token Polling Response

To conform with FAPI, the tokens returned in this response should be bound
to the client either using MTLS or OATB.

6.3.1 Succesful Token Notification

As per the notes on client_notification_token, I suggest that this payload
is signed to ensure source authentication and integrity.

Other notes:

   -

   No mention of what happens if the client notification endpoint is down
   (e.g. retries)
   - No mention of what acknowledgement the client should give to the OP
   when it receives a notification



_________
​
I believe that this spec could be useful for Financial APIs, however, it is
more coupled to OIDC than the current FAPI drafts. It could be that we have
to draft a new part to the FAPI spec that references this spec, but is more
in line with the rest of the FAPI draft and geared towards the use-case of
financial APIs.

I have started a review of the user questioning API and will send that to
the list shortly. However, on initial inspection, it doesn't result in
access tokens being issued to the client and would, therefore, be
unsuitable for "account information" access.

This was my first review of the MODRNA specs and I may well have
misinterpreted some of the specs. I hope that members of this group or are
also members of the MODRNA group will help to correct any mistakes I may
have made.

Thanks

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

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-fapi/attachments/20170526/b266dbd0/attachment.html>