[Openid-specs-ab] First full HTML-based logout spec published

Mike Jones Michael.Jones at microsoft.com
Thu Sep 10 06:55:50 UTC 2015


http://openid.net/specs/openid-connect-logout-1_0-03.html addresses the issue raised by Jim as:



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



The Session ID Claim definition now includes:
sid (session ID)
OPTIONAL. String identifier for a Session. This represents a Session of an OP at an RP to a User Agent or device for a logged-in End-User.



                                                            Thanks Jim!

                                                            -- Mike



-----Original Message-----
From: John Bradley [mailto:ve7jtb at ve7jtb.com]
Sent: Tuesday, August 04, 2015 5:24 AM
To: Mike Jones
Cc: Jim des Rivieres; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] First full HTML-based logout spec published



The SID should probably use the same pairwise logic as the subject.



If it is not a pairwise subject than making the SID pairwise is not adding anything.



If the subject is pairwise then SID should be created using using the sector_identifier_uri if configured, otherwise the host component of the redirect_uri.



John B.



> On Aug 3, 2015, at 10:32 PM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:

>

> Replies inline…

>

> From: Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Jim des Rivieres

> Sent: Monday, March 16, 2015 8:34 AM

> To: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>

> Subject: Re: [Openid-specs-ab] First full HTML-based logout spec published

>

> Here are some comments on draft 00 of OpenID Connect HTTP-Based Logout 1.0.

>

> re: 2. Relying Party Logout Functionality

>

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

>

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

>

> The cache-control language was added at https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.bitbucket.org%2fopenid-connect-logout-1_0.html%23RPLogout.&data=01%7c01%7cMichael.Jones%40microsoft.com%7c4672c8a908354dafc41e08d29cc7a353%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=G%2fJHHUNU3X%2bp5IzRRCuDvFcrTyLXOO%2fRqSYkVBPOUqI%3d

>

> > If the RP supports OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration], it uses this metadata value to register the logout URL:

>

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

>

> The logout URI syntax language was added at https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.bitbucket.org%2fopenid-connect-logout-1_0.html%23RPLogout.&data=01%7c01%7cMichael.Jones%40microsoft.com%7c4672c8a908354dafc41e08d29cc7a353%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=G%2fJHHUNU3X%2bp5IzRRCuDvFcrTyLXOO%2fRqSYkVBPOUqI%3d

>

> re: 3. OpenID Provider Logout Functionality

>

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

>

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

>

> There had been some discussion of the scope of Session IDs in the working group that makes me think that sometimes the same ID would want to be used across RPs.  But I may just be misremembering this.  I’ll plan to have this discussed during the next working group call.

>

> Regards,

> Jim

>

>                                                                 -- Mike

>

> _______________________________________________

> Openid-specs-ab mailing list

> Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>

> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.openid.net%2fmailman%2flistinfo%2fopenid-specs-ab&data=01%7c01%7cMichael.Jones%40microsoft.com%7c4672c8a908354dafc41e08d29cc7a353%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=GDdqFlWoNQvEu4%2bFTPvaETcRd4zKoBgr82qfVq%2fGgAw%3d


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150910/5258e65f/attachment-0001.html>


More information about the Openid-specs-ab mailing list