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

Mike Jones Michael.Jones at microsoft.com
Tue Aug 5 01:11:51 UTC 2014

Todd, getting back to this, at the working group meeting at ForgeRock during RSA, we'd discussed just using the registered redirect_uri values to initialize this value.  If there are multiple redirect_uri values with different hostnames, then the caller's redirect_uri value would be used.

Could you take a stab at supplying wording to add to the spec along those lines?

				-- Mike

-----Original Message-----
From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of lainhart
Sent: Tuesday, January 21, 2014 9:03 AM
To: openid-specs-ab at lists.openid.net
Subject: [Openid-specs-ab] Issue #915: Session 4.2 - Computation of OP session_state in the IdP requires origin URI (openid/connect)

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


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).

Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net

More information about the Openid-specs-ab mailing list