<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Hi Torsten</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Thanks for the detailed review.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Please see my comments below.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Dave</div></div><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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all, <br>
<br>
please find some comments on the CIBA draft below.<br>
<br>
First of all, I would like to thank you for moving this draft forward. The result is really impressive!<br>
<br>
- The term „consumption device“ is first used Section 1, 1st paragraph without description. Readers not familiar with the Mobile Connect/MODRNA terminology don’t know this term. <br></blockquote><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><span style="background-color:rgb(255,255,255)"><font color="#9900ff">Fair point - I've opened this issue: <a href="https://bitbucket.org/openid/mobile/issues/151/define-authentication-device-before-first" target="_blank">https://bitbucket.org/openid/mobile/issues/151/define-authentication-device-before-first</a></font></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- Section 4<br>
<br>
-- Poll and Ping Modes with Pairwise Identifiers<br>
<br>
„… which allows the OP to consider the host component of that URI as the Sector Identifier for the pairwise identifier calculation per Section 8.1 of OpenID Connect Core“ <br>
<br>
This text is a bit misleading as there are ways the OP can determine PPIDs without to incorporate the sector identifier URL (see 3rd example in OpenID Connect spec, section 8.1).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><font color="#9900ff">I may be missing something here, but even in the 3rd example in OIDC core, the sector identifier is used. I agree that the word "calculation" could be a bit misleading, as it could be a lookup rather than some hash function, but please let me know if i've missed something.</font></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
— 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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
2) The comparison of the host component of the JWKS URI and the sector identifier URI should work but to me seems like a workaround and imposes restrictions on the way RP construct URIs. Have you considered to put the respective JWKS URIs in the sector identifier JSON document? The syntax would need to be extended (as it is a simple JSON array right know). But this document serves a similar purpose for RPs than the openid-configuration file for OPs. So putting more metadata into it seems like a reasonable solution.  <br></blockquote><div><div><span style="color:rgb(153,0,255);font-family:"trebuchet ms",sans-serif"><span class="gmail_default"><br></span></span></div><div><span style="color:rgb(153,0,255);font-family:"trebuchet ms",sans-serif"><span class="gmail_default">So at the moment my understanding of our requirements here are:</span></span></div></div><div><span style="color:rgb(153,0,255);font-family:"trebuchet ms",sans-serif"><span class="gmail_default"> - in PING/POLL mode, Client must register with jwks_uri</span></span></div><div><span style="color:rgb(153,0,255);font-family:"trebuchet ms",sans-serif"><span class="gmail_default"> - if sector_identifier_uri is provided, it must point to a file that must CONTAIN the jwks_uri</span></span></div><div><span style="color:rgb(153,0,255);font-family:"trebuchet ms",sans-serif"><span class="gmail_default"><br></span></span></div><div><span style="color:rgb(153,0,255);font-family:"trebuchet ms",sans-serif"><span class="gmail_default">So I don't think we are requiring a host comparison - rather we are already following your suggestion (with the exception that we aren't </span></span></div><div><span style="color:rgb(153,0,255);font-family:"trebuchet ms",sans-serif"><span class="gmail_default">Please let me know if I've missed something or if you think the wording can be improved.</span></span></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">
— 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 color="#9900ff" face="trebuchet ms, sans-serif"><a href="https://bitbucket.org/openid/mobile/issues/152/guidance-around-verification-of-ownership">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">
- 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-plusReplyChip-0" href="mailto:joseph.heenan@fintechlabs.io" tabindex="-1">@Joseph Heenan</a> or <a class="gmail_plusreply" id="gmail-plusReplyChip-1" href="mailto:bcampbell@pingidentity.com" tabindex="-1">@Brian Campbell</a> can you remember?</span></span> </div><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 class="gmail_default" 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-plusReplyChip-2" href="mailto:Petteri.Stenius@ubisecure.com" tabindex="-1">@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><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.1.<br>
<br>
— Isn’t this section describing a OIDC request object (or JAR) just sent via a POST request? Why don’t you just referrer to it and focus the text on the extensions/differences needed in CIBA?<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">That was the original approach. But we decided there were too many differences and that it would be cleaner to define it from scratch.</span></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
— page 10 - the example shows the signed request and additionally a Basic AUTHORIZATION header. Do you intentionally use two mechanisms to authorize the request?<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">Yes, we took the decision that authentication at the backchannel endpoint should be the same as at the token endpoint. So whatever the client has set-up to use at the token endpoint - they use the same at the backchannel endpoint. The ability to sign the request is for non-repudiation purposes rather than authentication. </span></span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- section 7.2<br>
<br>
— bullet 1. "… It is RECOMMENDED that Clients not send shared secrets in the Authentication Request but rather that public key cryptography be used.“<br>
<br>
I agree with this recommendation but all examples use shared secrets (Basic authz) to authenticate and authorize the respective RP. I suggest you change the examples to use public crypto.<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 think this is a good suggestion, I've opened this issue: </span></span><font color="#9900ff" face="trebuchet ms, sans-serif"><a href="https://bitbucket.org/openid/mobile/issues/153/change-examples-to-use-public-key-crypto">https://bitbucket.org/openid/mobile/issues/153/change-examples-to-use-public-key-crypto</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">
- section 10.3.1.<br>
<br>
— Binding the iss & auth_req_id together with a signature is a good way to ensure authenticity of the data delivered to the RP via the push mechanism. Using the ID token as detached signature mechanism makes it a OpenID Connect only solution. That happened before with FAPI and we have seen what headache it might cause if such a mechanism shall be used for API authorization (OAuth) latter on. So basically you are limiting (at least the push mechanisms) to OpenID. I would advocate to come up with a solution applicable in both scenarios, OpenID and OAuth. Sending the data in a JWT and digitally signing it (like with JARM <a href="https://openid.net/specs/openid-financial-api-jarm-ID1.html" rel="noreferrer" target="_blank">https://openid.net/specs/openid-financial-api-jarm-ID1.html</a>) would be an option. <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">:-) Good point, although at the moment CIBA is probably tied to OIDC in a few more ways. I'll open an issue to look at this.</span></span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- section 14<br>
<br>
— „The OP SHOULD ensure that the "backchannel_client_notification_endpoint" configured at registration time is in the administrative authority of the Client. Otherwise, the OP would post authentication results to the wrong Client. How this check is done is outside the scope of this specification."  <br>
<br>
Any idea how the OP should fulfill this requirement? I haven't found a similar requirement on redirect URI handling in the OpenID Connect Core spec although the risk is the same. <br>
<br>
I think the notification endpoint could also be placed in the sector identifier URI (or shall we call it rp-openid-configuration :-)).<br>
<br>
kind regards,<br>
Torsten. <br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Openid-specs-mobile-profile mailing list<br>
<a href="mailto:Openid-specs-mobile-profile@lists.openid.net" target="_blank">Openid-specs-mobile-profile@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_7058364706213471900gmail_signature"><div dir="ltr"><div><div dir="ltr"><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"><div style="letter-spacing:normal;line-height:normal"><div style="padding:8px 0px"><span style="color:rgb(0,164,183);font-size:11px">Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL</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 style="color:rgb(0,164,183);font-size:11px;line-height:15.925px"></div><div style="letter-spacing:normal;line-height:normal"><span style="font-size:11px;line-height:15.925px"><br></span></div><div style="color:rgb(97,97,97);font-family:"Open Sans";letter-spacing:normal"><div style="line-height:1.4"><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;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"). Moneyhub Financial Technology is entered on the Financial Services Register </span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;font-size:0.75em;background-color:transparent">(FRN </span><span style="color:rgb(0,164,183);font-family:lato,"open sans",arial,sans-serif;font-size:10.5px;font-weight:700">809360</span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em">) at <a href="http://fca.org.uk/register" target="_blank">fca.org.uk/register</a>. M</span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:10.5px">oneyhub</span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em"> Financial Technology is registered in England & Wales, company registration number </span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em"> </span><span style="font-weight:bold;color:rgb(0,164,183);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em">06909772</span><span style="background-color:transparent"><font color="#333333" face="lato, open sans, arial, sans-serif"><span style="font-size:0.75em"> .</span></font></span></div><div style="font-family:lato,"open sans",arial,sans-serif;color:rgb(51,51,51);line-height:1.4"><span style="background-color:transparent;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;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:x-small">©</span></div><div style="font-family:lato,"open sans",arial,sans-serif;color:rgb(51,51,51);line-height:1.4"><span style="background-color:transparent;font-size:0.75em"><br></span></div><div style="font-family:lato,"open sans",arial,sans-serif;color:rgb(51,51,51);line-height:1.4"><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 Moneyhub 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></div></div></div></div></div></div></div>