<a href="https://bitbucket.org/openid/connect/issue/915/session-42-computation-of-op-session_state"><font size=2 color=blue face="sans-serif">https://bitbucket.org/openid/connect/issue/915/session-42-computation-of-op-session_state</font></a><font size=2 face="sans-serif">
describes how the origin URI available in the client-side PostMessage call
to the OP's session iframe must also be made available to the OP when the
session_state parameter is calculated in the auth_code flow.</font>
<br>
<br><font size=2 face="sans-serif">Can someone describe the opportunity
for exploit should the origin_uri *not* be included in the session_state
computation?</font>
<br>
<br><font size=2 face="sans-serif">In other words, in the OP session/JS
code excerpted from the spec below, what exploit opportunities are opened
if the session_state computation on both server and client did not include
an e.origin value (which I've commented out below)?</font>
<br>
<br><font size=2 face="Courier New">    // Here, the session_state
is calculated in this particular way,<br>
    // but it is entirely up to the OP how to do it under the<br>
    // requirements defined in this specification.<br>
    var ss = CryptoJS.SHA256(client_id + ' ' + /*e.origin + '
'*/ +<br>
      opbs + [' ' + salt]) [+ "." + salt];</font>
<br>
<br><font size=2 face="sans-serif"><br>
</font>
<br>
<table width=223 style="border-collapse:collapse;">
<tr height=8>
<td width=223 bgcolor=white style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><font size=1 face="Verdana"><b><br>
<br>
<br>
Todd Lainhart<br>
Rational software<br>
IBM Corporation<br>
550 King Street, Littleton, MA 01460-1250</b></font><font size=1 face="Arial"><b><br>
1-978-899-4705<br>
2-276-4705 (T/L)<br>
lainhart@us.ibm.com</b></font></table>
<br>