<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="color:rgb(56,118,29)">A few additional little comments inline:</span><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 4, 2019 at 11:56 PM Dave Tonge <<a href="mailto:dave.tonge@momentumft.co.uk">dave.tonge@momentumft.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 3 Feb 2019 at 17:01, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>> wrote:<br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
— The second paragraph describes the way to ensure the RP is entitled to obtain PPIDs for a certain sector identifier. I see two drawbacks:<br>
<br>
1) only the host component of the URIs involved is used to check for equality. This means RP’s residing on the same host in a shared environment automatically share the same sector identifier even if they are good citizens and use different sector identifier URIs. This is basically an issue of the OpenID Connect Core spec.<br></blockquote><div><br></div><div><span style="color:rgb(153,0,255);font-family:"trebuchet ms",sans-serif"><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Yep, I see this issue - but we should probably raise it against OIDC Core</span></span> </div></div></div></div></div></div></blockquote><div><br></div><div><span style="color:rgb(56,118,29)">I believe it has been raised <a href="https://bitbucket.org/openid/connect/issues/1058/sector_identifier_uri-should-have-a-well">https://bitbucket.org/openid/connect/issues/1058/sector_identifier_uri-should-have-a-well</a> but would be a breaking change to finalized spec(s) so isn't likely to change.  </span><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
— The third paragraph specifies in rather weak language how the client shall demonstrate possession of the respective private keys. Moreover, the check is deferred to the actual use of the CIBA functions. In contrast, in case of standard OIDC the check whether a redirect_uri belongs to the authorized destinations for certain PPIDs is checked at registration time. Deferring the check to the CIBA use puts the respective RP record in kind of a middle state.<br>
<br>
Have you considered to let the dynamic registration function of the OP perform the check? One could use one of the methods cited in the spec (mTLS or private_key_jwt) to conduct the proof. Such an approach would allow to conduct all the checks necessary in one place and a single action and either accept or refuse the registration. <br>
<br></blockquote><div><br></div><div><span style="color:rgb(153,0,255);font-family:"trebuchet ms",sans-serif"><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif">I agree that it would be preferable for the check to be performed at registration time. I'm not sure if this requires a normative change - possibly some additional guidance would help. I've opened this issue: </span></span><font face="trebuchet ms, sans-serif" color="#9900ff"><a href="https://bitbucket.org/openid/mobile/issues/152/guidance-around-verification-of-ownership" target="_blank">https://bitbucket.org/openid/mobile/issues/152/guidance-around-verification-of-ownership</a></font><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div></div></div></div></blockquote><div><br></div><div><span style="color:rgb(56,118,29)">In many cases clients aren't actually dynamically registered but configured with the AS/OP via some other means. Also I suspect that defining/using client authentication methods for registration is nowhere near as straightforward as it might seem.</span><br></div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- section 7.1.  <br>
<br>
— client_notification_token - limiting the size of the token to 1024 characters seems a bit short in case the RP decides to use self contained tokens (e.g. JWTs).<br></blockquote><div><br></div><div><span style="color:rgb(153,0,255);font-family:"trebuchet ms",sans-serif"><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif">I thought that we discussed this, but I'm struggling to find the issue. <a class="gmail_plusreply" id="gmail-m_-2048569966782478134gmail-plusReplyChip-0" href="mailto:joseph.heenan@fintechlabs.io" target="_blank">@Joseph Heenan</a> or <a class="gmail_plusreply" id="gmail-m_-2048569966782478134gmail-plusReplyChip-1" href="mailto:bcampbell@pingidentity.com" target="_blank">@Brian Campbell</a> can you remember?</span></span> </div></div></div></div></div></div></blockquote><div><br></div><div><span style="color:rgb(56,118,29)">This is the one <a href="https://bitbucket.org/openid/mobile/issues/104/ciba-client_notification_tokens-length-and">https://bitbucket.org/openid/mobile/issues/104/ciba-client_notification_tokens-length-and</a></span></div><div><span style="color:rgb(56,118,29)"><br></span></div><div><span style="color:rgb(56,118,29)">I chose 1024 somewhat arbitrarily to "allow for a reasonable sized JWT to be used as the client_notification_token" but I suppose it depends on what one views as "reasonable". I think 1024 is enough though. <br></span></div><div><span style="color:rgb(56,118,29)"><br></span></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
— user_code - I think I understand the rationale of this feature but I’m a bit concerned about its practicability. It shall ensure no CIBA request is sent out to the user’s authentication device without prior confirmation using a secret the user knows. It reminds me of the static PIN codes in the Mastercard 3DS authorization scheme. It failed simply because users set up and immediately forgot their PIN codes resulting in terrible conversion rates. I bet user’s will most likely forget this use code as well. 3DS solved the problem by introducing dynamic PIN codes, e.g. sent to the user via text message. That’s most likely not a viable solution for CIBA (:—)).<br>
<br></blockquote><div><div style="font-family:"trebuchet ms",sans-serif"><span style="color:rgb(153,0,255)">This is a valid concern, but perhaps the difference here is that users won't be forced to use the mechanism. The idea is that they will have to explicitly opt-in to get this added protection. <a class="gmail_plusreply" id="gmail-m_-2048569966782478134gmail-plusReplyChip-2" href="mailto:Petteri.Stenius@ubisecure.com" target="_blank">@Petteri Stenius</a> do you have any thing else to add here? Perhaps we need some guidance around this issue?</span></div><br></div></div></div></div></div></div></blockquote><div><br></div><div><span style="color:rgb(56,118,29)">The whole mechanism is optional FWIW. <br></span></div><div><br></div><div> </div></div></div></div></div></div></div>

<br>
<i style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-ui,-apple-system,system-ui,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;color:rgb(85,85,85)"><span style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"><font size="2">CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.</font></span></i>