<div dir="ltr"><div><span id="docs-internal-guid-54520de1-2a5e-fa45-75fc-6ad44674c680"><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:28px;font-family:'Trebuchet MS';color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Note from OpenID Connect Meeting @ IETF 87 Berlin</span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Date & Time: 2013-07-28 14:00-17:00</span></p>
<p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Location: Charottenburg 1,  Intercontinental Hotel, Berlin</span></p>
<p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Attendee: Mike Jones, John Bradely, Nat Sakimura, Ande F. Niemann, Olef Bergmann, Stefanie Gerdes, Lucy Lynch, Leif Johannsson, Karn O’donohue, Joel Snyder, Tatsuya Hayashi, Dirk Balfanz, Torsten Lodderstedt, Brian Campbell. </span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap"></span><h1 dir="ltr" style="line-height:1.15;margin-top:10pt;margin-bottom:0pt">
<span style="font-size:21px;font-family:'Trebuchet MS';color:rgb(0,0,0);background-color:transparent;font-weight:normal;vertical-align:baseline;white-space:pre-wrap">MTI Discussion</span></h1><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">It was suggested that perhaps only requiring code flow for the server - parallel of what Basic Client is. Lengthy discussion about the interoperability with client libraries such as GIT KIT followed. The result was that perhaps for non-dynamic client, just supporting code may be OK, since the client needs to be configured by hand anyways. From editing point of view, the requirment for supporting response_type=”token” and “token id_token” in Messages 8.2 Dynamic OpenID Providers. </span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><h1 dir="ltr" style="line-height:1.15;margin-top:10pt;margin-bottom:0pt">
<span style="font-size:21px;font-family:'Trebuchet MS';color:rgb(0,0,0);background-color:transparent;font-weight:normal;vertical-align:baseline;white-space:pre-wrap">Nonce discussion</span></h1><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">The nonce is different from state in the sense that it iis signed while the state parameter is not signed. nonce is signed. So, state can be tampered / replaced while nonce cannot. This has some impact on the  </span></p>
<p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Re-emphasizing RFC 6749: 10.6 Authorization Code Redirection URI Manipulation Attack. </span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Replace “replay” with “token hijack” in the explanation of the nonce. It is really about preventing token hijack. It is a client generated identifier for its request, which is returned in a signed ID Token so that the client can correlate the request and the token response. </span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Describe in the security consideration about the protection nonce gives to the clients for the cases where server redirect_uri matching is not an exact match. </span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><h1 dir="ltr" style="line-height:1.15;margin-top:10pt;margin-bottom:0pt">
<span style="font-size:21px;font-family:'Trebuchet MS';color:rgb(0,0,0);background-color:transparent;font-weight:normal;vertical-align:baseline;white-space:pre-wrap">iOS Client Custome scheme</span></h1><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">For native app, get the tokens back to apps are done through registered custome URI scheme. Which app is going to get it is inditerministic as multiple apps can register the same scheme. </span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">On Android, it is addressed by given user a choice, but on iOS, it is rather random, so the chances for the attacker client to intercept the code is rather large. </span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">To mitigate it, one could send request token (left hash of the generated secret) in the request. Hangout client adds “secret” parameter on the request. Probably encoding the “secret” in the encrypted code. </span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">The discussion proceeded with the possibility of using the request token as the client secret in the Basic Authentication. The conclusion was that it may have layering problems. So, it was decided to have a new parameter to be sent with the code to the token endpoint. </span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><h1 dir="ltr" style="line-height:1.15;margin-top:10pt;margin-bottom:0pt">
<span style="font-size:21px;font-family:'Trebuchet MS';color:rgb(0,0,0);background-color:transparent;font-weight:normal;vertical-align:baseline;white-space:pre-wrap">OpenID 2.0 transition</span></h1><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Finally, the group discussed about the OpenID 2.0 transition to the Connect. It could be dealt with by requiring the user to login twice with OpenID 2.0 and OpenID Connect but the user experience is sub-optimal. </span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Instead, having openid.claimed_id in the ID Token and having oidc.issuer in XRDS would streamline the process. </span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">When the client received the ID Token, it does the resolution on the openid.claimed_id (Note: the cleint should have that capability to start with as it is supporting OpenID 2.0), and find the oidc.issuer and match this against id_token.issuer.</span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">In the case of directed identifier, the client MUST send the realm as the sector identifier in OpenID Connect. </span></p>
<p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><br></span></p>
<h1 style="line-height:1.15;margin-top:10pt;margin-bottom:0pt"><span style="font-size:21px;font-family:'Trebuchet MS';color:rgb(0,0,0);background-color:transparent;font-weight:normal;vertical-align:baseline;white-space:pre-wrap">2nd Implementer's Draft voting</span></h1>
<p style="margin-top:0pt;margin-bottom:0pt"><font color="#000000" face="Arial" size="1"><span style="line-height:17px;white-space:pre-wrap"><br></span></font></p><p style="margin-top:0pt;margin-bottom:0pt"><font color="#000000" face="Arial" size="1"><span style="line-height:17px;white-space:pre-wrap">Attendee was asked by the chairs to vote for the 2nd Implementer's Draft</span></font></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">The meeting adjorned at 17:00. </span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><br></span></div>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>
</div>