<div dir="ltr">It's been nearly 2 months now, this is getting excessively frustrating.<div><br><div>I've received ONE offlist comment (thanks Mike S.) that Session Management actually wasn't good and I should rather do Front-Channel Logout (FWIW, the reason I got with Session Management is that it doesn't require re-registration of clients when they want to opt-in to single sign-out, and the Front-Channel Logout spec was –and still is, afaik– not quite ready yet).</div><div><br></div><div>IS THERE ANYBODY OUT THERE?</div><div><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 4, 2016 at 5:12 PM Thomas Broyer <<a href="mailto:t.broyer@gmail.com">t.broyer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>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><br></div><div>§3 Creating and Updating Sessions</div><div>> The generation of suitable Session State values is specified in Section 4.2, and is based on</div><div>> a salted cryptographic hash of Client ID, origin URL, and OP browser state.</div><div><br></div><div>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></div><div>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>Couldn't a basic, I don't know, maybe, XOR be used?</div><div>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><br></div><div>§4.2 OP iframe</div><div>> The RP MUST assign an id attribute to the iframe so that it can address it, as described above.</div><div><br></div><div>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><br></div><div>> The OP iframe MUST enforce that the caller has the same origin as its parent frame.</div><div>> It MUST reject postMessage requests from any other source origin.</div><div><br></div><div>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>The non-normative example code doesn't do that check BTW.</div><div>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><br></div><div>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>It's probably too late to change this though, and is possibly not a good thing to require as well.</div><div><br></div><div>§8 Security Considerations</div><div><br></div><div>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><br></div><div>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" target="_blank">https://github.com/ozwillo/ozwillo-kernel/blob/f7e03ff628c48931393faf1d35c473a7cb9e685d/oasis-webapp/src/main/resources/oasis-ui/check_session_iframe.html</a></div><div>(the sha256.js script used as fallback comes from <a href="https://github.com/Caligatio/jsSHA" target="_blank">https://github.com/Caligatio/jsSHA</a> BTW)</div></div></blockquote></div></div></div></div>