[Openid-specs-fapi] Issue #147: Anonymous Point of Sale Backchannel Authentication (openid/fapi)

Dave Tonge dave.tonge at momentumft.co.uk
Wed Jun 13 04:44:49 UTC 2018


Thanks Sarah - this is definitely a valid use case that needs to be solved.

Regarding your comment "CIBA requires users to reveal an identifier to a
relying party.", this is not quite accurate.

CIBA requires the RP to pass either a `login_hint` or `id_token_hint`. The
current wording we have in the FAPI profile of CIBA says that:

> this profile explicitly requires login_hint to have the properties of a
nonce with the expectation being that it will be generated from an
authorization server owned client authentication device. Given the high
levels of friction that this may impose it's anticipated that Authorization
Servers may have to accept a id_token_hint as an alternative mechanism for
Client Subject identification.

> Should a TPP wish to link the id_token returned from an authorization
server to an identifier that can be provided in a more friendly manner as a
key for the id_token_hint, care must be taken to ensure that customer
identification mechanism used to retrieve the id_token is appropriate for
the channel being used. For illustration a QR club card may be an
appropriate identifier when using a POS terminal under CCTV but it might
not be an appropriate identifier when used in online ecommerce.

At a high level this means the FAPI CIBA profile supports the following
flows:

### Anon First Time Use ###

The RP will instruct the user to generate a one-time identifier with the OP
(this could be a QR code that is generated on the banking app). This
identifier must then be passed to the RP consumption device (in the case of
the QR code, the code could be scanned at the POS terminal).

### Subsequent Use ###

For subsequent use cases the RP can use a previously received `id_token` as
an `id_token_hint`. The `id_token` can essentially act as an anonymous
pairwise identifier. This `id_token` could have been received from a
previous CIBA flow or from a standard redirect flow.

---

The flow that you are advocating at a high level involves the RP generating
an assertion that contains their client identifier, authorisation details
such as amount and payee and a nonce. This assertion is then passed from
the RP consumption device to the OP authentication device. The backend
flows are then initiated by the OP calling out to the RP.

This flow is useful as it supports passing the nonce from the RP to the OP
rather than the other way around, however there are some downsides:

 - It requires the OP to call out to the RP (this is currently not
acceptable to most banks)
 - It doesn't support smoother flows for subsequent uses (something that we
anticipate to be quite common)

Semantically the flow is quite similar to the OAuth device flow and if the
WG decide to move forward with it, my suggestion would be that we do so as
a profile of that spec. (This could also solve the issue of the OP calling
out to the RP as the device flow spec supports the RP polling the OP.)

I'll see if the UK OpenBanking team are OK to share some of the use cases
they are planning to use CIBA for as they help illustrate the flows better
and show that it isn't required for the RP to collect a static identifier
from the user.

In summary, I'm very glad that more people are looking at "decoupled" flows
and am not closed to the idea of this new work item proposal - I just want
a more robust discussion on how CIBA doesn't solve the use-case mentioned.

Thanks

Dave

On 12 June 2018 at 19:18, Ralph Bragg via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> wrote:

> Hi,
>
> I also meant to say that CIBA supports both flows (for OB), the open
> banking intent ID can act an ephemeral sub. A customer could choose to do
> the identity linkage by scanning a QR code on their phone push to the OP
> from the OP user agent  or by providing an ID to the RP and then push to
> the OP user agent from the OP.
>
> Both models can be enabled at customers choice and depending on device
> type by a CIBA flow:
>
> Will share the OB deck and workings from the industry working group last
> week.
>
> We, at least in Europe, can not stop TPPs from asking PSU’s for Banking
> Identifiers.
>
> RB
>
>
>
>
>
> ------------------------------
> *From:* Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> on
> behalf of Ralph Bragg via Openid-specs-fapi <openid-specs-fapi at lists.
> openid.net>
> *Sent:* Tuesday, June 12, 2018 5:56:03 PM
> *To:* Financial API Working Group List; openid-specs-fapi at lists.openid.net
> *Cc:* Ralph Bragg; Sarah Squire
> *Subject:* Re: [Openid-specs-fapi] Issue #147: Anonymous Point of Sale
> Backchannel Authentication (openid/fapi)
>
> Hi Sarah,
>
> This flow was also presented and discussed, nearly exactly as described in
> your sequence diagram last week at the Open Banking Workshop (deck is
> available). It’s a common pattern.
>
> The model does not cater for output constrained devices ie a fuel station
> credit card reader.
>
> OB is considering supporting both models.
>
> Kind regards,
>
> Ralph
>
>
>
> ------------------------------
> *From:* Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> on
> behalf of Sarah Squire via Openid-specs-fapi <openid-specs-fapi at lists.
> openid.net>
> *Sent:* Tuesday, June 12, 2018 5:26:31 PM
> *To:* openid-specs-fapi at lists.openid.net
> *Cc:* Sarah Squire
> *Subject:* [Openid-specs-fapi] Issue #147: Anonymous Point of Sale
> Backchannel Authentication (openid/fapi)
>
> New issue 147: Anonymous Point of Sale Backchannel Authentication
> https://bitbucket.org/openid/fapi/issues/147/anonymous-
> point-of-sale-backchannel
>
> Sarah Squire:
>
> My team has serious reservations with the fact that CIBA requires users to
> reveal an identifier to a relying party.
>
> We have a proposal for a new backchannel flow that would allow for
> one-time-use anonymous pairwise IDs. The use case we had in mind
> specifically is for point of sale terminals like department stores or gas
> stations, but it is broadly applicable to many financial and non-financial
> transactions.
>
> Take a look at our proposal:
> https://www.websequencediagrams.com/?lz=dGl0bGUgQW5vbnltb3VzIFBvaW50IG
> 9mIFNhbGUgQmFja2NoYW5uZWwgQXV0aGVudGljYXRpb24KCkFsaWNlLT4AIw
> 4oUlAgRnJvbnRlbmQpOiBpbml0aWF0ZXMgdHJhbnNhYwA2BQAYGy0-
> TWVyY2hhbnQARgVCYWNrAEQGc2VuZHMgYW1vdW50LCB0ZXJtaW5hbElECgAb
> FQB4HwBHBm5vbmNlAG8eAIFBHGdlbmVyAIFXBVFSIGNvZGUgCm5vdGUgbGVm
> AII8BQCBfB0AKwhjb250YWlucyBzb2Z0d2FyZSBzdGF0ZW1lbnQsAIEbBiwg
> YW5kAIIzDACBfgcAgngIQmFuayBBcHAgKE8Agm4Nb3BlbnMgcHJlZmVycmVk
> IGJhbmtpbmcgYXBwbACDPAgAJhYAgzUfU2NhbgCBawkAKhkAgH8YdmVyaWZp
> ZXMgYQCEQQ4AKx1TZXJ2ZXIAgV0FAIQIClMAhA0FAIJ0CGluZm9ybQCFFgUA
> giwFVXNlcklEAIFcBgAsEwCETxlDcnlwdG9ncmFwaGljIGNoYWxsZW5nZSwg
> b25lLXRpbWUgcGFpcndpc2UAXAcsIHNpZ25lZACESAcAhFs0VACDUgtSZWNl
> aXZlZACGBx4AhncFOiBEaXNwbGF5IHBlbmRpbmcAhBkNbWVzc2FnAHgZAII_
> GQCBahcgcmVzcG9uc2UsIGNsaWVudCBjcmVkZW50aWFscwCCAhxhY2Nlc3Mg
> dG9rZW4gcmVxdWVzdACCfBsAhTgXUgAzBiBmb3IgY29ucwCGFgoAhSwZAIId
> B1B1c2ggbm90aWYAiTMHIHdpdGgAgQIIAEMOAIhXCACIewluYW1lAIZJIFBy
> b3ZpZGVzAIEQCACFGDNDAIFMBiBvYnRhaW5lZACBTg0AhRIsQQCCZwZUAIJo
> BWZvcgCFHRkAg2YxIEkAi0IJT0
>  F1dGggcGF5bWVudACDKygAhy4VdmFsaWRhdGUAhBgGLCByZXNvbHZlcwCBHR
> oAgWAybGxvdwCBHBgAhm1AY29tcGxldACMJh8AhyYHACQVCgoKCgo&s=magazine
>
>
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>
>


-- 
Dave Tonge
CTO
[image: Moneyhub Enterprise]
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 2nd Floor, Whitefriars Business Centre,
Lewins Mead, Bristol, BS1 2NT
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 561538) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 © . Moneyhub Financial Technology Limited 2018. 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/20180613/f45386e3/attachment-0001.html>


More information about the Openid-specs-fapi mailing list