<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Thing to do, for your level of interest, is join at a level sufficient to access lists where folks debate actively.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I see things too simplistically. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Once saml2 became a religious group (Far too tied up with us govt interests) openid found a way to transform itself from a sideline into a mainstream effort. And to that I have to give credit (since it guessed correctly the end of pure web). </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">While the vendor community still has far too many links with us and uk spying-related manipulations, I also see that it has found a way to negotiate on difficult issues - such as session management and metadata that facilitates opened at a level saml2 never contemplated (while giving away all notions of privacy, unlike saml2 sessions)</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Crypto politics as normal. Join in!<br><br>Sent from my iPhone</div><div><br>On Apr 3, 2016, at 07:18, <a href="mailto:boris8479@gmail.com">boris8479@gmail.com</a> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="Generator" content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><div class="WordSection1"><p class="MsoNormal">Peter,</p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Thanks for the replay. I need to understand what is the vision for OpenID Connect session. The spec is currently in Draft 26. I do completely understand the idea of the RP and OP frames. If it is going like it is today, I believe it needs some additional clarifications and security concerns in the spec. Are there any big changes coming? I also see the community is working on the Identity Events, maybe it is to replace the session one. Any thoughts on that are highly appreciated.</p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Regards,</p><p class="MsoNormal">Boris Georgiev<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> for Windows 10</p><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p><div style="mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal" style="border:none;padding:0in"><b>From: </b><a href="mailto:home_pw@msn.com">Peter Williams</a><br><b>Sent: </b>Thursday, March 31, 2016 9:10 PM<br><b>To: </b><a href="mailto:boris8479@gmail.com">boris8479@gmail.com</a><br><b>Cc: </b><a href="mailto:openid-general@lists.openid.net">openid-general@lists.openid.net</a><br><b>Subject: </b>Re: [OpenID] Some thoughts on Open ID Connect Session</p></div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">The original model was that a token transferred a session.</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p></o:p></span></p><div id="AppleMailSignature"><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p></div><div id="AppleMailSignature"><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">Before opened connect added authentication tokens, it did not adhere to the original model.<o:p></o:p></span></p></div><div id="AppleMailSignature"><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p></div><div id="AppleMailSignature"><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">Thus an rp-local session would take a hint, from the authz token.<o:p></o:p></span></p></div><div id="AppleMailSignature"><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p></div><div id="AppleMailSignature"><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">Now the original model had a variant in which independent sessions, on Idp(s) and rp(s) could be mapped , by token minting intermediaries (see wsfedp protocol from vrsn/iBm/Msft and excellent use in Msft azure cloud). <o:p></o:p></span></p></div><div id="AppleMailSignature"><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p></div><div id="AppleMailSignature"><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">But that's not opened connect today. Opened connect may be that tomorrow being somewhat of a follower (of models) as they finally find relevance in app, web, Pc-app world <br><br>Sent from my iPhone<o:p></o:p></span></p></div><div><p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><br>On Mar 31, 2016, at 16:31, <a href="mailto:boris8479@gmail.com">boris8479@gmail.com</a> wrote:<o:p></o:p></span></p></div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div><p class="MsoNormal">Hi Community,<o:p></o:p></p><p class="MsoNormal"> </p><p class="MsoNormal">My name is Boris Georgiev and I am in charge for Application Security in a large financial institution. I do appreciate bringing up the standard Open ID Connect. I am excited after so many years, finally there is a standard. However, when facing up with Open ID Connect Session spec, I started to experience some disappointments.<o:p></o:p></p><p class="MsoNormal"> </p><p class="MsoNormal">Section 3 says: “In Open ID Connect, the session at the RP typically starts when the RP validates the End-User's ID Token”. In my mind, as I am trying to protect everything, I am about to receive the session together with the ID token, i.e. via the token API. However, reading further, the spec states that the variable session_state is returned in “the authentication response” which was changed few specifications back from “the authorization response”. The reference to 3.1.1.5 core shows example with the authorization code, and there is no example, showing the code and the session_state together. I was thinking initially that it is my confusion only, however I showed it to other engineers, native English speakers and they were confused too. I do believe this needs to be explained better, which session is which. So far I did not like the fact, that the session state is returned in a redirect via GET request, which we all know its vulnerabilities.<o:p></o:p></p><p class="MsoNormal"> </p><p class="MsoNormal">Further, section 4 explains that this is all about session state change notification, so the RP can refresh the ID token, avoiding the network traffic. So far so good. Finally, section 4.2 explains that the session actually is hashed and re-calculated at the OP frame. I think finally, the session is safe. However, to my disbelief, the spec explains that OP frame “may” use a cookie which is not http only, so it can be accessed by a JavaScript. Here I start wondering how people with security regulations similar to mine pass audit.<o:p></o:p></p><p class="MsoNormal"> </p><p class="MsoNormal">If the session is passed to the OP frame in some other secure way and if it is not used for any other purpose but for the session change notification, this will solve the problem. However the spec does not list it anywhere as a security concern, neither recommends secure ways. Moreover, I saw open source implementations out there, where the same cookie is driving the Single-Sign-On at the Authorization Server. This means, once the value of this cookie is obtained, it can be used to invoke the authorization API, bypass authentication and if implicit grant is requested, the attacker can get access tokens. The last safeguard is the callback URL, which can be easily bypassed by overwriting the local hosts file. Sounds like a complex and almost impossible, however in the financial industry the security is attempted to be penetrated by the brightest minds across the globe where patience and persistence can be well awarded. I need just one case like that to end my career. Therefore I do need to think about closing all the gaps and I still cannot find piece, thinking what else can be out there.<o:p></o:p></p><p class="MsoNormal"> </p><p class="MsoNormal">I do believe the above security concerns need to be listed in the spec. And I do believe this non http cookie idea needs to be listed in the security concerns, instead of being recommended.<o:p></o:p></p><p class="MsoNormal"> </p><p class="MsoNormal">If you need my opinion how it can be improved:<o:p></o:p></p><p class="MsoNormal"> </p><p class="MsoNormal">There is already a mechanism to protect token exchange. This is via the authorization code and token API. I thing, passing it from there will eliminate the need of encryption. Then, the session_state can be embedded in the script of the RP frame and comparison/calculation logic to be embedded in the OP frame (not via a cookie). Encryption is great, but one of the goals of OAuth is for authentication/authorization not to be done too often. The solution is acceptable for desktops, powered by the power grid, but for a thin device, one cannot do often encryption operations and expect a great battery life. I do not know if anyone ever considered that and was there any reason not to be pursued.<o:p></o:p></p><p class="MsoNormal"> </p><p class="MsoNormal">Regards,</p><p class="MsoNormal">Boris Georgiev<o:p></o:p></p></div></blockquote><p class="MsoNormal" style="mso-margin-top-alt:5.0pt;margin-right:.5in;margin-bottom:5.0pt;margin-left:.5in"><span style="font-family:"Times New Roman",serif">_______________________________________________<br>general mailing list<br><a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-general">http://lists.openid.net/mailman/listinfo/openid-general</a><o:p></o:p></span></p><p class="MsoNormal"><o:p> </o:p></p></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>general mailing list</span><br><span><a href="mailto:general@lists.openid.net">general@lists.openid.net</a></span><br><span><a href="http://lists.openid.net/mailman/listinfo/openid-general">http://lists.openid.net/mailman/listinfo/openid-general</a></span><br></div></blockquote></body></html>