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

Dave Tonge dave.tonge at momentumft.co.uk
Tue May 30 10:17:33 UTC 2017


Hi Axel

Thanks for the email.

*Signed Request Object*
I'm glad for the change to recommend "Signed Request Object" although the
current draft could be confusing for implementers, for example:

The Client MUST authenticate to the Backchannel Authentication Endpoint
> using the authentication method registered for its client_id, as described
> in Section 9 of [OpenID.Core]. The RECOMMENDED method to authenticate the
> Client is using an OpenID Connect Signed Request Object as described in
> OpenID.Core.


Section 9 of OIDC describes client authentication methods for the token
endpoints (e.g client_secret_basic, client_secret_post, client_secret_jwt &
private_key_jwt) - however it seems that the CIBA spec is recommending
simply sending a signed request object without using any of these 4
methods. I think this is fine and we are taking a similar approach in FAPI
when defining the request object endpoint
<https://bitbucket.org/openid/fapi/src/53d8de443d6727ea547fef173ee532858c183e14/Financial_API_WD_002.md?at=master&fileviewer=file-view-default#markdown-header-72-request>.
However, I think the current CIBA draft is confusing. Essentially we are
defining a 5th method for client authentication - sending a signed request
object. It should be clear in both drafts that sending a signed request
object is the recommended method and can (should?) be used instead of the
client authentication methods described in section 9 of OIDC.

*Binding Message*
Thanks for the explanation, I'm glad I've understood the use case.
PSD2 requires Strong Customer Authentication (i.e. multi-factor), but it
has been established that this can be performed on a single device (e.g. a
smartphone). PSD2 also requires dynamic linking - that is an
"authentication code" (PSD2 term) is bound to a specific amount and a
specific payee; however it doesn't need to be bound to a specific
transaction. I think you are right that the format of the binding message
is in the competitive space, however, I would like to explore whether there
is a requirement for the spec to support requiring the user to enter a
binding message or code.

I agree with you that the binding message is to support the user, however,
when it comes to payments, legislation shifts some of that liability from
the user to the payment processor. If fraud occurred because a user didn't
bother to compare binding messages it would be hard for a bank to push that
liability to the user. Therefore to get this spec adopted by banks and the
like, we may need to provide the functionality to require a user to enter
some sort of binding code - perhaps this is different from the binding
message.

I'd be interested in Nat and John's view on this though.

Thanks

Dave


On 26 May 2017 at 14:21, <Axel.Nennker at telekom.de> wrote:

> Hi Dave,
>
>
>
> thanks for the review!
>
>
>
> The latest editor version in HTML of CIBA is always at this location:
>
> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?
> Submit=Submit&format=ascii&mode=html&type=ascii&url=
> https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-
> client-initiated-backchannel-authentication.xml?at=default
>
> The raw xml2rfc version is here: https://bitbucket.org/openid/
> mobile/raw/tip/draft-mobile-client-initiated-backchannel-
> authentication.xml
>
>
>
> I created an issue regarding the Terminology Consumption Device:
>
> https://bitbucket.org/openid/mobile/issues/53/ciba-
> terminology-consumption-device
>
>
>
> Typo fixed by https://bitbucket.org/openid/mobile/commits/
> be7ab6b50447b82dd7d77f4fc2044c101be44069
>
>
>
> Regarding Client Authentication:
>
> I see CIBA as a generic spec introducing back-channel to MODRNA
> Authentication or OIDC.
>
> So FAPI should reference CIBA if back-channel is used in FAPI AND profile
> CIBA to FAPI’s higher security needs
>
> e.g. by restricting the Client Authentication Methods.
>
> We currently RECOMMEND a signed request object for request authentication
> while prohibiting alg=none.
>
> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?
> Submit=Submit&format=ascii&mode=html&type=ascii&url=
> https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-
> client-initiated-backchannel-authentication.xml?at=default#
> rfc.section.3.3.1
>
> The rationale is this: OAuth2 was specified as a simple authorization
> framework with client_id and client_secret as a simple form of client
> authentication.
>
> This was because developers and admins never managed to get the Liberty
> Alliance implementation right.
>
> So CIBA allows client_id and client_secret but use cases for Banks and
> PSPs need better security and should profile CIBA for better Client
> Authentication.
>
> https://openid.net/specs/openid-connect-core-1_0.html#
> NeedForSignedRequests
>
>
>
> Binding_message: Binding_message was introduced in MODRNA Authentication
> <https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/openid-connect-modrna-authentication-1_0.xml?at=default#rfc.section.7>
> . Protects the user not the RP.
>
> If you want it to be MANDATORY for payments then please profile MODRNA
> Authentication and CIBA and specify FAPI.
>
> CIBA does not talk much about binding_message and binding_message
> potential use cases because CIBA is a quite generic protocol for
> back-channel authentication.
>
> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?
> Submit=Submit&format=ascii&mode=html&type=ascii&url=
> https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-
> client-initiated-backchannel-authentication.xml?at=default#rfc.section.3.4
>
> Payment and handling of binding_messages is out-of-scope for CIBA. If CIBA
> is used for payment transaction authorization then there probably should be
> a contract between the OP and the PSP specifying how the binding_message
> looks like. I like your petrol station use case that is exactly what CIBA
> is designed for. Also I am not sure what PSD2 actually mandates to be shown
> at the Authentication Device. The pump is showing the price and the
> binding_message “e.g. ‘Correct *Horse* Battery *Staple*’” and the
> binding_message is also displayed on the user’s AT to protect the user.
> Potential PIN entry is a separate issue. Reentering the binding_message at
> the pump does improve the pump’s assurance but might introduce an error
> prone UX. YMMW.
>
>
>
> Regarding Token Request Validation:
>
> https://bitbucket.org/openid/mobile/commits/c2de67a23791bf8962602fd6746a66
> bef63e4168
>
> I did not reference 3.1.3 because we have no redirect_url
>
>
>
> Regarding the authentication of the OP at the Client Notification
> Endpoint:
>
> https://bitbucket.org/openid/mobile/issues/54/ciba-client-
> notification-endpoint
>
>
>
> Regarding signing results:
>
> https://bitbucket.org/openid/mobile/issues/55/ciba-signed-result-objects
>
>
>
> kind regards
>
> Axel
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* Openid-specs-fapi [mailto:openid-specs-fapi-
> bounces at lists.openid.net] *On Behalf Of *Dave Tonge via Openid-specs-fapi
> *Sent:* Freitag, 26. Mai 2017 12:59
> *To:* Openid-specs Fapi <openid-specs-fapi at lists.openid.net>
> *Subject:* [Openid-specs-fapi] Initial review of MODRNA Client initiated
> Backchannel Authentication Flow 1.0
>
>
>
> 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.
>



-- 
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-mobile-profile/attachments/20170530/9e62372a/attachment-0001.html>


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