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

Anders Rundgren anders.rundgren.net at gmail.com
Wed Jun 13 19:01:36 UTC 2018


On 2018-06-13 18:34, tom jones via Openid-specs-fapi wrote:
> I have built an RP with OIDC dynamic registration and fought with the problem of how the user will provide the information to the RP to allow an authentication process to move forward, even with standard OIDC authn. I have also worked on a huge ADFS deployment with 100,000 users and 1,000 web sites. In all cases it seems that the user trying to access the RP has little option but to enter their entire user name at the IDP into the RP in order for the authentication to proceed. No other user experience I have found seems to work.  If someone has a use case that allows a user to authenticate with somewhat random IdP at an RP _that will work for the user_, I would love to hear it.
> 
> Of course if the is some smart user token involved, then the token can provide the needed information, but when the user is entering data on a keyboard, I see no real alternative.

Neither do I.  OTOH, why bother with anything but smart tokens?

Microsoft pioneered this technology back in 2005: https://en.wikipedia.org/wiki/Information_Card

Then Microsoft suddenly shelved this concept.  However, *lots* of people have continued exploring it including myself as you can see in the upper right corner of: https://cyberphone.github.io/doc/saturn/saturn-authorization.pdf

W3C's Credential Management API https://www.w3.org/TR/credential-management-1/ addresses the same problem but with a rather different take on the token.

Anders

> 
> thx ..tom
> 
> *From: *Dave Tonge via Openid-specs-fapi <mailto:openid-specs-fapi at lists.openid.net>
> *Sent: *Tuesday, June 12, 2018 9:45 PM
> *To: *Financial API Working Group List <mailto:openid-specs-fapi at lists.openid.net>
> *Cc: *Dave Tonge <mailto:dave.tonge at momentumft.co.uk>; Sarah Squire <mailto:issues-reply at bitbucket.org>
> *Subject: *Re: [Openid-specs-fapi] Issue #147: Anonymous Point of SaleBackchannel Authentication (openid/fapi)
> 
> 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 <mailto: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 <mailto:openid-specs-fapi-bounces at lists.openid.net>> on behalf of Ralph Bragg via Openid-specs-fapi <openid-specs-fapi at lists.openid.net <mailto: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 <mailto: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 <mailto:openid-specs-fapi-bounces at lists.openid.net>> on behalf of Sarah Squire via Openid-specs-fapi <openid-specs-fapi at lists.openid.net <mailto:openid-specs-fapi at lists.openid.net>>
>     *Sent:* Tuesday, June 12, 2018 5:26:31 PM
>     *To:* openid-specs-fapi at lists.openid.net <mailto: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=dGl0bGUgQW5vbnltb3VzIFBvaW50IG9mIFNhbGUgQmFja2NoYW5uZWwgQXV0aGVudGljYXRpb24KCkFsaWNlLT4AIw4oUlAgRnJvbnRlbmQpOiBpbml0aWF0ZXMgdHJhbnNhYwA2BQAYGy0-TWVyY2hhbnQARgVCYWNrAEQGc2VuZHMgYW1vdW50LCB0ZXJtaW5hbElECgAbFQB4HwBHBm5vbmNlAG8eAIFBHGdlbmVyAIFXBVFSIGNvZGUgCm5vdGUgbGVmAII8BQCBfB0AKwhjb250YWlucyBzb2Z0d2FyZSBzdGF0ZW1lbnQsAIEbBiwgYW5kAIIzDACBfgcAgngIQmFuayBBcHAgKE8Agm4Nb3BlbnMgcHJlZmVycmVkIGJhbmtpbmcgYXBwbACDPAgAJhYAgzUfU2NhbgCBawkAKhkAgH8YdmVyaWZpZXMgYQCEQQ4AKx1TZXJ2ZXIAgV0FAIQIClMAhA0FAIJ0CGluZm9ybQCFFgUAgiwFVXNlcklEAIFcBgAsEwCETxlDcnlwdG9ncmFwaGljIGNoYWxsZW5nZSwgb25lLXRpbWUgcGFpcndpc2UAXAcsIHNpZ25lZACESAcAhFs0VACDUgtSZWNlaXZlZACGBx4AhncFOiBEaXNwbGF5IHBlbmRpbmcAhBkNbWVzc2FnAHgZAII_GQCBahcgcmVzcG9uc2UsIGNsaWVudCBjcmVkZW50aWFscwCCAhxhY2Nlc3MgdG9rZW4gcmVxdWVzdACCfBsAhTgXUgAzBiBmb3IgY29ucwCGFgoAhSwZAIIdB1B1c2ggbm90aWYAiTMHIHdpdGgAgQIIAEMOAIhXCACIewluYW1lAIZJIFByb3ZpZGVzAIEQCACFGDNDAIFMBiBvYnRhaW5lZACBTg0AhRIsQQCCZwZUAIJoBWZvcgCFHRkAg2YxIEkAi0IJT0
>       F1dGggcGF5bWVudACDKygAhy4VdmFsaWRhdGUAhBgGLCByZXNvbHZlcwCBHRoAgWAybGxvdwCBHBgAhm1AY29tcGxldACMJh8AhyYHACQVCgoKCgo&s=magazine
> 
> 
>     _______________________________________________
>     Openid-specs-fapi mailing list
>     Openid-specs-fapi at lists.openid.net <mailto: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 <mailto:Openid-specs-fapi at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> 
> 
> 
> -- 
> 
> *Dave Tonge*
> 
> CTO
> 
> 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 <http://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.
> 
> 
> 
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> 



More information about the Openid-specs-fapi mailing list