<div dir="ltr"><div class="gmail_default"><div class="gmail_default"><font face="trebuchet ms, sans-serif">Thanks Sarah - this is definitely a valid use case that needs to be solved.</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">Regarding your comment "CIBA requires users to reveal an identifier to a relying party.", this is not quite accurate.</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">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:</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">> 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.</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">> 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.</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">At a high level this means the FAPI CIBA profile supports the following flows:</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">### Anon First Time Use ###</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">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).</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">### Subsequent Use ###</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">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. </font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">---</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">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.</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">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:</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"> - It requires the OP to call out to the RP (this is currently not acceptable to most banks)</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"> - It doesn't support smoother flows for subsequent uses (something that we anticipate to be quite common)</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">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.)</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">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.</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">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.</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">Thanks</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">Dave</font></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 12 June 2018 at 19:18, Ralph Bragg via Openid-specs-fapi <span dir="ltr"><<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">






<div>
<div id="m_7340529252878987424compose-container" style="direction:ltr">
<span><span></span></span>
<div>
<div style="direction:ltr">Hi,</div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">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.</div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">Both models can be enabled at customers choice and depending on device type by a CIBA flow:</div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">Will share the OB deck and workings from the industry working group last week.</div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">We, at least in Europe, can not stop TPPs from asking PSU’s for Banking Identifiers.</div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">RB</div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr"><br>
</div>
<div><br>
</div>
<div class="m_7340529252878987424acompli_signature"></div>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_7340529252878987424divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Openid-specs-fapi <<a href="mailto:openid-specs-fapi-bounces@lists.openid.net" target="_blank">openid-specs-fapi-bounces@<wbr>lists.openid.net</a>> on behalf of Ralph Bragg via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.<wbr>openid.net</a>><br>
<b>Sent:</b> Tuesday, June 12, 2018 5:56:03 PM<br>
<b>To:</b> Financial API Working Group List; <a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.<wbr>openid.net</a><br>
<b>Cc:</b> Ralph Bragg; Sarah Squire<br>
<b>Subject:</b> Re: [Openid-specs-fapi] Issue #147: Anonymous Point of Sale Backchannel Authentication (openid/fapi)</font>
<div> </div>
</div><div><div class="h5">
<div>
<div>
<div id="m_7340529252878987424x_compose-container" style="direction:ltr">
<span><span></span></span>
<div>
<div>
<div style="direction:ltr">Hi Sarah,</div>
<div><br>
</div>
<div style="direction:ltr">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.</div>
<div><br>
</div>
<div style="direction:ltr">The model does not cater for output constrained devices ie a fuel station credit card reader.</div>
<div><br>
</div>
<div style="direction:ltr">OB is considering supporting both models.</div>
<div><br>
</div>
<div style="direction:ltr">Kind regards,</div>
<div><br>
</div>
<div style="direction:ltr">Ralph</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div><br>
</div>
<div class="m_7340529252878987424x_acompli_signature"></div>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_7340529252878987424x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Openid-specs-fapi <<a href="mailto:openid-specs-fapi-bounces@lists.openid.net" target="_blank">openid-specs-fapi-bounces@<wbr>lists.openid.net</a>> on behalf of Sarah Squire via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.<wbr>openid.net</a>><br>
<b>Sent:</b> Tuesday, June 12, 2018 5:26:31 PM<br>
<b>To:</b> <a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.<wbr>openid.net</a><br>
<b>Cc:</b> Sarah Squire<br>
<b>Subject:</b> [Openid-specs-fapi] Issue #147: Anonymous Point of Sale Backchannel Authentication (openid/fapi)</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:11pt">
<div class="m_7340529252878987424PlainText">New issue 147: Anonymous Point of Sale Backchannel Authentication<br>
<a href="https://bitbucket.org/openid/fapi/issues/147/anonymous-point-of-sale-backchannel" target="_blank">https://bitbucket.org/openid/<wbr>fapi/issues/147/anonymous-<wbr>point-of-sale-backchannel</a><br>
<br>
Sarah Squire:<br>
<br>
My team has serious reservations with the fact that CIBA requires users to reveal an identifier to a relying party.<br>
<br>
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.<br>
<br>
Take a look at our proposal:<br>
<a href="https://www.websequencediagrams.com/?lz=dGl0bGUgQW5vbnltb3VzIFBvaW50IG9mIFNhbGUgQmFja2NoYW5uZWwgQXV0aGVudGljYXRpb24KCkFsaWNlLT4AIw4oUlAgRnJvbnRlbmQpOiBpbml0aWF0ZXMgdHJhbnNhYwA2BQAYGy0-TWVyY2hhbnQARgVCYWNrAEQGc2VuZHMgYW1vdW50LCB0ZXJtaW5hbElECgAbFQB4HwBHBm5vbmNlAG8eAIFBHGdlbmVyAIFXBVFSIGNvZGUgCm5vdGUgbGVmAII8BQCBfB0AKwhjb250YWlucyBzb2Z0d2FyZSBzdGF0ZW1lbnQsAIEbBiwgYW5kAIIzDACBfgcAgngIQmFuayBBcHAgKE8Agm4Nb3BlbnMgcHJlZmVycmVkIGJhbmtpbmcgYXBwbACDPAgAJhYAgzUfU2NhbgCBawkAKhkAgH8YdmVyaWZpZXMgYQCEQQ4AKx1TZXJ2ZXIAgV0FAIQIClMAhA0FAIJ0CGluZm9ybQCFFgUAgiwFVXNlcklEAIFcBgAsEwCETxlDcnlwdG9ncmFwaGljIGNoYWxsZW5nZSwgb25lLXRpbWUgcGFpcndpc2UAXAcsIHNpZ25lZACESAcAhFs0VACDUgtSZWNlaXZlZACGBx4AhncFOiBEaXNwbGF5IHBlbmRpbmcAhBkNbWVzc2FnAHgZAII_GQCBahcgcmVzcG9uc2UsIGNsaWVudCBjcmVkZW50aWFscwCCAhxhY2Nlc3MgdG9rZW4gcmVxdWVzdACCfBsAhTgXUgAzBiBmb3IgY29ucwCGFgoAhSwZAIIdB1B1c2ggbm90aWYAiTMHIHdpdGgAgQIIAEMOAIhXCACIewluYW1lAIZJIFByb3ZpZGVzAIEQCACFGDNDAIFMBiBvYnRhaW5lZACBTg0AhRIsQQCCZwZUAIJoBWZvcgCFHRkAg2YxIEkAi0IJT0" target="_blank">https://www.<wbr>websequencediagrams.com/?lz=<wbr>dGl0bGUgQW5vbnltb3VzIFBvaW50IG<wbr>9mIFNhbGUgQmFja2NoYW5uZWwgQXV0<wbr>aGVudGljYXRpb24KCkFsaWNlLT4AIw<wbr>4oUlAgRnJvbnRlbmQpOiBpbml0aWF0<wbr>ZXMgdHJhbnNhYwA2BQAYGy0-<wbr>TWVyY2hhbnQARgVCYWNrAEQGc2VuZH<wbr>MgYW1vdW50LCB0ZXJtaW5hbElECgAb<wbr>FQB4HwBHBm5vbmNlAG8eAIFBHGdlbm<wbr>VyAIFXBVFSIGNvZGUgCm5vdGUgbGVm<wbr>AII8BQCBfB0AKwhjb250YWlucyBzb2<wbr>Z0d2FyZSBzdGF0ZW1lbnQsAIEbBiwg<wbr>YW5kAIIzDACBfgcAgngIQmFuayBBcH<wbr>AgKE8Agm4Nb3BlbnMgcHJlZmVycmVk<wbr>IGJhbmtpbmcgYXBwbACDPAgAJhYAgz<wbr>UfU2NhbgCBawkAKhkAgH8YdmVyaWZp<wbr>ZXMgYQCEQQ4AKx1TZXJ2ZXIAgV0FAI<wbr>QIClMAhA0FAIJ0CGluZm9ybQCFFgUA<wbr>giwFVXNlcklEAIFcBgAsEwCETxlDcn<wbr>lwdG9ncmFwaGljIGNoYWxsZW5nZSwg<wbr>b25lLXRpbWUgcGFpcndpc2UAXAcsIH<wbr>NpZ25lZACESAcAhFs0VACDUgtSZWNl<wbr>aXZlZACGBx4AhncFOiBEaXNwbGF5IH<wbr>BlbmRpbmcAhBkNbWVzc2FnAHgZAII_<wbr>GQCBahcgcmVzcG9uc2UsIGNsaWVudC<wbr>BjcmVkZW50aWFscwCCAhxhY2Nlc3Mg<wbr>dG9rZW4gcmVxdWVzdACCfBsAhTgXUg<wbr>AzBiBmb3IgY29ucwCGFgoAhSwZAIId<wbr>B1B1c2ggbm90aWYAiTMHIHdpdGgAgQ<wbr>IIAEMOAIhXCACIewluYW1lAIZJIFBy<wbr>b3ZpZGVzAIEQCACFGDNDAIFMBiBvYn<wbr>RhaW5lZACBTg0AhRIsQQCCZwZUAIJo<wbr>BWZvcgCFHRkAg2YxIEkAi0IJT0</a><br>
 <wbr>F1dGggcGF5bWVudACDKygAhy4VdmFs<wbr>aWRhdGUAhBgGLCByZXNvbHZlcwCBHR<wbr>oAgWAybGxvdwCBHBgAhm1AY29tcGxl<wbr>dACMJh8AhyYHACQVCgoKCgo&s=<wbr>magazine<br>
<br>
<br>
______________________________<wbr>_________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.<wbr>openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>fapi</a><br>
</div>
</span></font></div>
</div></div></div>

<br>______________________________<wbr>_________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net">Openid-specs-fapi@lists.<wbr>openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>fapi</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:1em;font-weight:bold;line-height:1.4"><div style="color:rgb(97,97,97);font-family:'Open Sans';font-size:14px;font-weight:normal;line-height:21px"><div style="font-family:Arial,Helvetica,sans-serif;font-size:0.925em;line-height:1.4;color:rgb(220,41,30);font-weight:bold"><div style="font-size:14px;font-weight:normal;color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;line-height:normal"><div style="color:rgb(0,164,183);font-weight:bold;font-size:1em;line-height:1.4"><div style="font-weight:400;color:rgb(51,51,51);line-height:normal"><div style="color:rgb(0,164,183);font-weight:bold;font-size:1em;line-height:1.4">Dave Tonge</div><div style="font-size:0.8125em;line-height:1.4">CTO</div><div style="font-size:0.8125em;line-height:1.4;margin:0px"><a href="http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A" style="color:rgb(131,94,165)" target="_blank"><img alt="Moneyhub Enterprise" height="50" src="http://content.moneyhub.co.uk/images/teal_Moneyhub-Ent_logo_200x50.png" title="Moneyhub Enterprise" width="200" style="border:none;padding:0px;border-radius:2px;margin:7px"></a></div><div style="padding:8px 0px"><div style="padding:8px 0px"><span style="color:rgb(0,164,183);font-size:11px">Moneyhub Financial Technology, 2nd Floor, Whitefriars Business Centre, Lewins Mead, Bristol, BS1 2NT</span></div><span style="font-size:11px;line-height:15.925px;color:rgb(0,164,183);font-weight:bold"></span></div><span style="font-size:11px;line-height:15.925px;color:rgb(0,164,183);font-weight:bold">t: </span><span style="font-size:11px;line-height:15.925px">+44 (0)117 280 5120</span><br></div><div style="font-weight:400;color:rgb(97,97,97)"><font color="#00a4b7"><span style="font-size:11px;line-height:15.925px"><br></span></font><div style="color:rgb(51,51,51);line-height:1.4"><span style="font-size:0.75em">Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). </span><span style="font-size:10.5px">Moneyhub</span><span style="font-size:0.75em"> Financial Technology is entered on the Financial Services Register </span><span style="font-size:0.75em;background-color:transparent">(FRN </span><span style="font-size:0.75em;background-color:transparent;color:rgb(0,164,183);font-weight:bold">561538</span><span style="font-size:0.75em;background-color:transparent">) at <a href="http://fca.org.uk/register" target="_blank">fca.org.uk/register</a>. </span><span style="font-size:10.5px">Moneyhub</span><span style="font-size:0.75em;background-color:transparent"> Financial Technology is registered in England & Wales, company registration number </span><span style="font-size:0.75em;color:rgb(0,164,183);font-weight:bold;background-color:transparent">06909772</span><span style="font-size:0.75em;background-color:transparent"> </span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;background-color:transparent"><font size="1">©</font></span><span style="font-size:0.75em;background-color:transparent"> . </span><span style="font-size:10.5px">Moneyhub</span><span style="background-color:transparent;font-size:0.75em"> Financial Technology Limited 2018. </span><span style="background-color:transparent;font-size:0.75em;color:rgb(136,136,136)">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.</span></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>