Session 4.2 - Computation of OP session_state in the IdP requires origin URI

[Former user]

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

[Former user]

I'll propose specific text.

[Former user]

I'll offer the following strawman. A concern that I have is whether or not the RP can know at registration time the PostMessage e.origin value.

Section 5.1.1

Add:

js_origin_uri

REQUIRED. This value MUST equal the value of the origin URI passed by "PostMessage" to the OP session_iframe, as described in Section 4.2.

Section 3:

Replace:

Session State. JSON string that represents the End-User's login state at the OP. This string is opaque to the RP. This is REQUIRED if session management is supported.

...with...

Session State. A JSON string that represents the End-User's login state at the OP. This string is opaque to the RP, and is composed of the registered client_id for that RP, its registered js_origin_uri value and the OP browser state, such that it can be used by the OP session_iframe to detect login state changes as described in Section 4.2. REQUIRED if session management is supported.

[Michael Jones]

Registering one js_origin_uri is unsufficiently flexible when clients have multiple redirect_uris. This was discussed at the 27-Feb-14 in-person meeting.

In the simple case, the dynamic redirect_uri could be used. We are also discussing possibly specifying a cookie origin parameter, but it would be optional. The possible format for that is still under discussion.

[Former user]

Here's some new text based on Mike's request:

=================

http://openid.net/specs/openid-connect-session-1_0-21.html#CreatingUpdatingSessions

3. Creating and Updating Sessions

Proposed revised text:

" In OpenID Connect, the session at the RP typically starts when the RP validates the End-User's ID Token. Refer to the OpenID Connect Core 1.0 [OpenID.Core] specification to find out how to obtain an ID Token and validate it. When the OP supports session management, it MUST also return the Session State as an additional session_state parameter in the Authentication Response. The OpenID Connect Authentication Response is specified in Section 3.1.2.5 of OpenID Connect Core 1.0.

This parameter is:

session_state Session State. JSON string that represents the End-User's login state at the OP. It MUST NOT contain the space (" ") character. This value is opaque to the RP. This is REQUIRED if session management is supported.

The session state value is initially calculated on the server. The same session state value is also recalculated by the OP iframe in the browser client. The generation of suitable session state values is specified in Section 4.2, and is based on a salted cryptographic hash of Client ID, origin URL, and OP browser state. For origin URL, the server can use the origin URL of the Authentication Response following the algorithm specified in RFC 6454, Section 4. "

http://openid.net/specs/openid-connect-session-1_0-21.html#OPiframe

Fix multiple errors in Javascript snippet:

"

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

"

Change all "Authorization Request/Response" to "Authentication Request/Response".

http://openid.net/specs/openid-connect-session-1_0-21.html#ParametersContents

Change "Authorization Response" to "Authentication Response".

http://openid.net/specs/openid-connect-session-1_0-21.html#rfc.references1

Add normative reference:

[RFC6454] Barth, A. ''The Web Origin Concept,'' RFC6454, Dec. 2011.

[Michael Jones]

Thanks, Todd. We will apply these changes to the spec and have it reviewed.

[Michael Jones]

Fixed issue #915 - Computation of OP session_state in the IdP requires origin URI

→ <<cset 588868d595e2>>