[Openid-specs-ab] Issue #915: Session 4.2 - Computation of OP session_state in the IdP requires origin URI (openid/connect)

lainhart issues-reply at bitbucket.org
Tue Jan 21 17:03:25 UTC 2014


New issue 915: Session 4.2 - Computation of OP session_state in the IdP requires origin URI
https://bitbucket.org/openid/connect/issue/915/session-42-computation-of-op-session_state

lainhart:

When an RP is participating in OIDC Session Mgmt. it receives a session_state value from the authorization code flow, to be used in client side polling for OP-based session state change notifications.

Section 4.2 shows an example for some RP/OP iframes used for polling the session state change, and says the following using normative language:

"*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.*"

The example shows the calculation of a hash implemented with this normative language, which implies that the creation of the session_state parameter via the OP and passed to the RP in the authorization code flow has access to the same "source origin URL" that is used in the RP's call to PostMessage.  It's unclear how the OP has access to that value.

On the 01/20/2014 openid-specs-ab working group call, it was suggested that this was originally supported via a client registration parameter along the lines of "javascript-origin-uri", but that parameter has since been removed.

Is the origin source URL a critical part of the computation, such that its omission introduces security vulnerabilities?  I'm wondering if we can just drop this requirement.

Also, I'm also concerned as to whether or not the RP will/can get this value right at client registration time - i.e. there might be multiple source URLs that might be accessible via PostMessage.  This last question reflects my inexperience with this API, and may be a non-issue (e.g. the source URL may reflect the URL of the iframe).




More information about the Openid-specs-ab mailing list