<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I suppose some other hash could have been used besides S256. It however is probably not worth the trouble to make it configurable.<div class=""><br class=""></div><div class="">I think it was Google that came up with the S256 requirement.</div><div class=""><br class=""></div><div class="">Work on that session management spec has largely stalled. Google who originally proposed it, built something similar but incompatible. </div><div class="">I believe Microsoft is the only one to have widely implemented it. I think they are relatively happy with it in Azure.</div><div class=""><br class=""></div><div class="">Google is now proposing a integrated login/ session management API. <a href="http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20151116/005865.html" class="">http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20151116/005865.html</a></div><div class=""><br class=""></div><div class="">I am personally mostly concentrating on the backchannel logout spec as that can be used with native apps where the front channel ones won’t work. </div><div class=""><br class=""></div><div class="">As we know from SAML logout is harder than login. The front channel specs are best effort and are known to fail in lots of circumstances. </div><div class=""><br class=""></div><div class="">John B.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 4, 2016, at 11:12 AM, Thomas Broyer <<a href="mailto:t.broyer@gmail.com" class="">t.broyer@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi all,<div class=""><br class=""></div><div class="">I've been implementing Session Management over the passed days (both OP and RP), and have some feedback/questions about the current draft.</div><div class=""><br class=""></div><div class="">§3 Creating and Updating Sessions</div><div class="">> The generation of suitable Session State values is specified in Section 4.2, and is based on</div><div class="">> a salted cryptographic hash of Client ID, origin URL, and OP browser state.</div><div class=""><br class=""></div><div class="">I (somewhat) understand the need for a "salt" (as briefly described in §4.2 “incorporate sufficient randomness in the form of a salt so as to prevent identification of an End-User across successive calls to the OP's Authorization Endpoint.”; see below) but not really why it'd need to be a "cryptographic hash". Note that the only other mention of "crypto" is "CryptoJS" in the non-normative example code in §4.2, and there's no other mention of "hash" in the whole document.<br class=""></div><div class="">I “naively” implemented Session Management using the same algorithm as the non-normative example code ("sha256(client_id SP origin SP browser state SP salt) '.' salt") but I really wonder why it'd need such demanding algorithm as a cryptographic hash like SHA-256).</div><div class="">Couldn't a basic, I don't know, maybe, XOR be used?</div><div class="">I mean, everything's "public" here: the code for the OP iframe, the browser state (in the sense that it's known to the browser), the session state, the client_id, the RP origin; and while crypto in the browser is relatively widely available (this is assuming people run uptodate browsers; which is not the case: there are still a lot of people with outdated and now-unsupported Internet Explorer versions, or outdated versions of Firefox, because they installed "portable" versions to bypass privilege restrictions set by IT departments: one of our customers filed an issue about a rendering glitch in Firefox… 17!), it may not be worth the effort.</div><div class=""><br class=""></div><div class="">§4.2 OP iframe</div><div class="">> The RP MUST assign an id attribute to the iframe so that it can address it, as described above.</div><div class=""><br class=""></div><div class="">This is a technical implementation detail, it doesn't need a MUST; ad if the RP wants to do things differently (e.g. the iframe is created by a script and either stored in a global variable –accessible from the RP iframe– or passed as argument to a function called in the RP iframe's browsing context).</div><div class=""><br class=""></div><div class="">> The OP iframe MUST enforce that the caller has the same origin as its parent frame.</div><div class="">> It MUST reject postMessage requests from any other source origin.</div><div class=""><br class=""></div><div class="">How do you do that? window.parent.location.href is blocked by the same-origin policy. There's document.referrer but while the value will generally be equivalent to the parent window's location, this is not guaranteed.</div><div class="">The non-normative example code doesn't do that check BTW.</div><div class="">Anyway, to be able to postMessage to the iframe, the script needs to have a "handle" on it, which means it runs in the same origin as the parent window (to get access to the iframe in the document), so it's not really worth checking, right?</div><div class=""><br class=""></div><div class="">I actually wondered at some point why there'd need to be an RP iframe. It's really only useful for the "hidden redirects", but that doesn't mean the postMessage must come from the iframe; the iframe could communicate with the parent window (same origin anyway, as the RP iframe needs to be able to address the OP iframe) which communicates with the OP iframe using postMessage (the RP iframe could even be dynamically created only when needed –in response to a "changed" response message from the OP iframe, to redirect to the OP with prompt=none–, saving one HTTP request). If it was done that way, then the RP iframe could check that e.source === window.parent I suppose.</div><div class="">It's probably too late to change this though, and is possibly not a good thing to require as well.</div><div class=""><br class=""></div><div class="">§8 Security Considerations</div><div class=""><br class=""></div><div class="">That section doesn't talk about the need for "salting" the session state (more about privacy than security but still), and is silent about the threats that would require the session state to be a crytographic hash: what's the real issue? Examples of scenarios?</div><div class=""><br class=""></div><div class="">FWIW, my implementation at the OP is open source; feedback is welcome: <a href="https://github.com/ozwillo/ozwillo-kernel/blob/f7e03ff628c48931393faf1d35c473a7cb9e685d/oasis-webapp/src/main/resources/oasis-ui/check_session_iframe.html" class="">https://github.com/ozwillo/ozwillo-kernel/blob/f7e03ff628c48931393faf1d35c473a7cb9e685d/oasis-webapp/src/main/resources/oasis-ui/check_session_iframe.html</a></div><div class="">(the sha256.js script used as fallback comes from <a href="https://github.com/Caligatio/jsSHA" class="">https://github.com/Caligatio/jsSHA</a> BTW)</div></div>
_______________________________________________<br class="">Openid-specs-ab mailing list<br class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab<br class=""></div></blockquote></div><br class=""></div></body></html>