<font size=2 face="sans-serif">Here are some comments on draft 00 of OpenID
Connect HTTP-Based Logout 1.0.</font>
<br>
<br><font size=2 face="sans-serif">re: 2. Relying Party Logout Functionality</font>
<br>
<br><font size=2 face="sans-serif">> Upon receiving the GET, the RP
clears state associated with the logged-in session, including any cookies,
and then returns an image and a HTTP 200 status code.</font>
<br>
<br><font size=2 face="sans-serif">The RP's response also needs anti-caching
headers (Cache-Control: no-store, Pragma: no-cache) to prevent the user
agent from caching the response. Otherwise caching of one logout response
could interfere with future logouts.</font>
<br>
<br><font size=2 face="sans-serif">> If the RP supports OpenID Connect
Dynamic Client Registration 1.0 [OpenID.Registration], it uses this metadata
value to register the logout URL:</font>
<br>
<br><font size=2 face="sans-serif">Regardless of whether the RP supports
OpenID.Registration, the RP's registration with the OP needs to include
the logout URL, logout_use_iframe and logout_session_required settings
(when OP supports latter). This makes it awkward to frame this section
entirely in terms of OpenID.Registration. Since a parameter is passed to
the logout URL, it might be clearer to call it the RP's Logout endpoint
(cf. OAuth2 Redirection endpoint). Like other OAuth2/OIDC endpoint URIs,
the spec should spell out the restrictions on the endpoint URI; e.g., "The
Logout endpoint URI MUST be an absolute URI as defined by [RFC3986] Section
4.3. The Logout endpoint URI MAY include an "application/x-www-form-urlencoded"
formatted (per [RFC 6749] Appendix B) query component ([RFC3986] Section
3.4), which MUST be retained when adding additional query parameters. The
Logout endpoint URI MUST NOT include a fragment component."</font>
<br>
<br><font size=2 face="sans-serif">re: 3. OpenID Provider Logout Functionality</font>
<br>
<br><font size=2 face="sans-serif">> sid (Session ID) OPTIONAL. String
identifier for a Session - a pairing of an OP to a User Agent or device
for a logged-in End-User.</font>
<br>
<br><font size=2 face="sans-serif">Shouldn't the Session ID bind in the
RP as well? If an OP were to use the same sid value across multiple RPs,
it would be easy enough for a naughty RP to cause another RP2 to logout,
with no way for RP2 to defend itself.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Jim</font>