[Openid-specs-ab] session_state calculation

[Todd W Lainhart]

Thanks John.

> The client is communicating via post message to the JS hosted at the 
IDP.  In that call the JS origin of the caller is available. 

I've got that part.  But the session_state that the RP is passing in the 
JS is the one that was given to it by the OP during the auth_code flow. 
According to the comparison algorithm, that session_state must include in 
its hash the client's origin, which is known to the browser, not the OP.

Maybe I'm missing something obvious.




Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart at us.ibm.com




From:   John Bradley <ve7jtb at ve7jtb.com>
To:     Todd W Lainhart/Lexington/IBM at IBMUS, 
Cc:     "openid-specs-ab at lists.openid.net" 
<openid-specs-ab at lists.openid.net>, Breno de Medeiros <breno at google.com>
Date:   01/14/2014 02:57 PM
Subject:        Re: [Openid-specs-ab] session_state calculation



Breno is probably going to give a better answer. 

The client is communicating via post message to the JS hosted at the IDP. 
In that call the JS origin of the caller is available. 

John B 

Sent from my iPhone

On Jan 14, 2014, at 12:05 PM, Todd W Lainhart <lainhart at us.ibm.com> wrote:

Section 4.2 of the Session Mgmt. spec talks about how the OP iframe 
calculates the session_state to be compared to that given previously to 
the RP in the auth code flow.  That section says this: 

"The OP iframe MUST recalculate it from the previously obtained Client ID, 
the source origin URL (from the postMessage), and the current OP Browser 
state. If the received value and the calculated value do not match, then 
the OP iframe MUST postMessage the string changed back to the source. If 
it matched, then it MUST postMessage the string unchanged. " 

...which implies that the OP will have to calculate that value at the 
authorization endpoint. 

If I'm understanding this, I'm not getting how the OP can reliably know 
what the source origin URL is at the time the session_state is provisioned 
and given to the RP. 

Am I missing something?  I've included the example from Section 4.2 of the 
Session Mgmt. spec below. 

   -- Todd 



 window.addEventListener("message", receiveMessage, false);

 function receiveMessage(e){ // e has client_id and session_state

   // Validate message origin
   client_id = message.split(' ')[0];
   session_state = message.split(' ')[1];
   var salt = session_state.split('.')[1];

   // get_op_browser_state() is an OP defined function
   // that returns the browser's login status at the OP.
   // How it is done is entirely up to the OP.
   var opbs = get_op_browser_state();

   // Here, the session_state is calculated in this particular way,
   // but it is entirely up to the OP how to do it under the
   // requirements defined in this specification.
   var ss = CryptoJS.SHA256(client_id + ' ' + e.origin + ' ' +
     opbs + [' ' + salt]) [+ "." + salt];

   if (e.session_state == ss) {
     stat = 'unchanged';
   } else {
     stat = 'changed';
   }

   e.source.postMessage(stat, e.origin);
 }; 






Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart at us.ibm.com

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140115/62f8b8de/attachment.html>