Anonymous Point of Sale Backchannel Authentication

[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=dGl0bGUgQW5vbnltb3VzIFBvaW50IG9mIFNhbGUgQmFja2NoYW5uZWwgQXV0aGVudGljYXRpb24KCkFsaWNlLT4AIw4oUlAgRnJvbnRlbmQpOiBpbml0aWF0ZXMgdHJhbnNhYwA2BQAYGy0-TWVyY2hhbnQARgVCYWNrAEQGc2VuZHMgYW1vdW50LCB0ZXJtaW5hbElECgAbFQB4HwBHBm5vbmNlAG8eAIFBHGdlbmVyAIFXBVFSIGNvZGUgCm5vdGUgbGVmAII8BQCBfB0AKwhjb250YWlucyBzb2Z0d2FyZSBzdGF0ZW1lbnQsAIEbBiwgYW5kAIIzDACBfgcAgngIQmFuayBBcHAgKE8Agm4Nb3BlbnMgcHJlZmVycmVkIGJhbmtpbmcgYXBwbACDPAgAJhYAgzUfU2NhbgCBawkAKhkAgH8YdmVyaWZpZXMgYQCEQQ4AKx1TZXJ2ZXIAgV0FAIQIClMAhA0FAIJ0CGluZm9ybQCFFgUAgiwFVXNlcklEAIFcBgAsEwCETxlDcnlwdG9ncmFwaGljIGNoYWxsZW5nZSwgb25lLXRpbWUgcGFpcndpc2UAXAcsIHNpZ25lZACESAcAhFs0VACDUgtSZWNlaXZlZACGBx4AhncFOiBEaXNwbGF5IHBlbmRpbmcAhBkNbWVzc2FnAHgZAII_GQCBahcgcmVzcG9uc2UsIGNsaWVudCBjcmVkZW50aWFscwCCAhxhY2Nlc3MgdG9rZW4gcmVxdWVzdACCfBsAhTgXUgAzBiBmb3IgY29ucwCGFgoAhSwZAIIdB1B1c2ggbm90aWYAiTMHIHdpdGgAgQIIAEMOAIhXCACIewluYW1lAIZJIFByb3ZpZGVzAIEQCACFGDNDAIFMBiBvYnRhaW5lZACBTg0AhRIsQQCCZwZUAIJoBWZvcgCFHRkAg2YxIEkAi0IJT0F1dGggcGF5bWVudACDKygAhy4VdmFsaWRhdGUAhBgGLCByZXNvbHZlcwCBHRoAgWAybGxvdwCBHBgAhm1AY29tcGxldACMJh8AhyYHACQVCgoKCgo&s=magazine

[Tom Jones]

I would support this. When i made the point last week that the GDPR did not seem to apply to banks, there was some push back, but the reality is that the GDPR should support this sort of solution, but the banks are moving in a different direction. I wonder how conflict of laws is handled in the EU?

[Nat Sakimura]

June 12 call participants agreed to start a new work on it. Sarah, Tony, and Nat volunteered.

[Dave Tonge]

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.

[Ralph Bragg]

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

[Ralph Bragg]

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 but as Dave says the model covers both solutions.

RB

[Suhas Chatekar]

@sarahsquire I have a question on the communication between the merchant and the bank server in your sequence diagram. Assuming, this is all a request-response style of data flow, you have 3 calls going from merchant to bank server but only 2 calls going from bank server to merchant. Shouldn't the number of requests and response be the same? You have got either 3 requests and 2 response or 2 requests and 3 response (sorry, it is not clear which one is a request and which one is a response. This could just be me being thick headed.)

[Dave Tonge]

It was discussed that the WG would rather focus on CIBA than the new draft.