Draft 1 - Lasted modified October 31, 2013
Table of contents
The specification makes use of the terms as defined in OpenID
Connect Core 1.0 [OpenID.Core] and OpenID Connect Session
Management 1.0 [OpenID.Session]:
[Editor's note: This specification sticks with the 2 roles. Elsewhere we have used the term "member" or "member client" to refer to a specially-registered client that is a member of a Jazz SSO group. In this specification, we simply refer to "Relying Party". Furthermore, there is nothing in this specification that is specific to resource servers vs clients.]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in [RFC2119].
Certain security-related terms are to be understood in the sense defined in [RFC4949]. These terms include, but are not limited to, "authentication", "authorization", "certificate", "credential", "identity", "validate", and "verify".
Unless otherwise noted, all the protocol parameter names and values are case sensitive.
The sign-out notification is made as a request to a sign-out callback endpoint, ordinarily hosted on the Relying Party.
A Relying Party's sign-out callback endpoint URI is registered with the OpenID Provider. The means of registering Relying Parties with an OpenID Provider is outside the scope of this specification.
A sign-out callback endpoint URI MAY include an "application/x-www-form-urlencoded" formatted (per [RFC6749] Appendix B) query component ([RFC3986] Section 3.4). The endpoint URI MUST NOT include a fragment component. The endpoint SHOULD require the use of TLS as described in [RFC6749] Section 1.6.
A sign-out callback endpoint MUST support the use of the HTTP "POST" method [RFC2616], and MUST NOT require authentication.
Parameters sent without a value MUST be treated as if they were omitted from the request. The Relying Party MUST ignore unrecognized request parameters. Request parameters MUST NOT be included more than once.
Following is a non-normative example of a sign-out notification request:POST https://a.example.com/signout_cb HTTP/1.1 Content-Type: application/x-www-form-urlencoded id_token=xny556A06937a62Hf.ggd826538.57238
Sign-out notifications, like other event notifications, are performed for their effect on the receiver. Refer to [RFC2616] Section 10 for general guidance on response status codes.
Following is a non-normative example of a successful response to a sign-out notification request:HTTP/1.1 204 No Content
Sign-out notifications are intended to provide one-time, best effort notification from OpenID Provider to Relying Party that a session at the OpenID provider is over. It would be a mistake for confuse this with a reliable messaging mechanism, which would guarantee that a message sent by the send will (eventually) be received by the intended recipient. Almost nothing about sign-out notifications comes with a guarantee.
Shortly after a session expires or is overtly terminated, the OpenID Provider sends out notifications of this event. Notifications SHOULD be sent to Relying Parties that have registered a sign-out callback endpoint. If a Relying Party had obtained an ID token for the expired session, the OpenID Provider SHOULD send a sign-out notification to the Relying Party's registered sign-out callback endpoint passing the exact same ID token.
The OpenID Provider MAY send additional sign-out notifications. For instance, the OpenID Provider MAY notify a Relying Party more than once.
The OpenID Provider MAY send fewer sign-out notifications, or perhaps none at all. The latter might happen in server configuration where an OpenID Provider on the Internet is unable to open connections to Relying Parties sitting behind a corporate firewall.
From the perspective of the Relying Party's developer, supporting a sign-out callback endpoint can improve the timeliness of the Relying Party's discovering that a session with its OpenID provider is over. However, the Relying Party must be written to behave acceptably even when sign-out notifications are spotty or non-existent.
How the Relying Party reacts to sign-out notifications is outside the scope of this specification. But, as an example, a Relying Party could use the ID token (string) to search its internal state for a record of a local session with some user-agent, and then unbind the ID token from that local session with that user-agent, release licenses, etc. (i.e., do the things it would have done had the user-agent instructed the Relying Party to terminate the session, rather than giving that instruction to some other Relying Party).
A Relying Party that explicitly terminates a session at its OpenID Provider via its end session endpoint MAY receive a sign-out notification for that session.