[Openid-specs-ab] end_session endpoint parameter specs

John Bradley ve7jtb at ve7jtb.com
Thu Jan 23 00:51:42 UTC 2014


One point that was maid in favour of allowing a client_id was that it might be useful in helping the idp look up the post logout URI to validate it.

I don't know that it is actually easier than just indexing the URI itself.  

Following a post logout redirect without a id_token even if it is registered may be a bad idea. 

John B.


On Jan 22, 2014, at 7:19 PM, Breno de Medeiros <breno at google.com> wrote:

> The requirement that login be available if a login was not processed is incompatible with any form of 'XSRF' protection of the logout endpoint.
> 
> I propose that we make id_token_hint RECOMMENDED, explain that IDPs MAY require it to be present to perform logout, but not add another mechanism based on client_id, which is solving no problem I am aware of.
> 
> So if the IDP supports logout, it may specify id_token_hint required or not, or behave differently (e.g., require user confirmation if id_token_hint absent). You can add a discussion on security considerations.
> 
> Again, I am against adding another mechanism for id_token_hint, and I think that the current approach to make it RECOMMENDED is the correct one. I argue for no change except added discussion in security reqs.
> 
> 
> 
> 
> On Mon, Jan 20, 2014 at 8:28 AM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
> Hi Todd,
> 
> this page would not necessarily have a client id.
> 
> Regards,
> Torsten.
> 
> 
> 
> Todd W Lainhart <lainhart at us.ibm.com> schrieb:
> Hi Torsten - 
> 
> > We see the need to trigger a logout from pages, which did not previously process a login (portal, landing page). 
> 
> Would your page have a client_id available?  It's a requirement that the provided post_logout_uri be registered.  I was trying to intuit how that would be done given the current param spec, in which the client_id was only available (perhaps) as the "aud" field of the id_token.
> 
> 
> 
> 
> Todd Lainhart
> Rational software
> IBM Corporation
> 550 King Street, Littleton, MA 01460-1250
> 1-978-899-4705
> 2-276-4705 (T/L)
> lainhart at us.ibm.com
> 
> 
> 
> 
> 
> From:        Torsten Lodderstedt <torsten at lodderstedt.net> 
> To:        Todd W Lainhart/Lexington/IBM at IBMUS, 
> Cc:        "openid-specs-ab at lists.openid.net" <openid-specs-ab at lists.openid.net> 
> Date:        01/18/2014 03:44 AM 
> Subject:        Re: [Openid-specs-ab] end_session endpoint parameter specs 
> 
> 
> 
> Hi Todd, 
> 
> I think your proposal to make the id token hint required if the post logout uri is present limits applicability of the logout mechanism. We see the need to trigger a logout from pages, which did not previously process a login (portal, landing page). This would be impossible. 
> 
> General note: I think the security consideration section must discuss open redirection at the end session endpoint. I assume registration of post logout uri serves the purpose of preventing this threat but this is not documented. 
> 
> regards, 
> Torsten. 
> 
> Am 17.01.2014 um 22:45 schrieb Todd W Lainhart <lainhart at us.ibm.com>:
> 
> Last week I filed: 
> 
> https://bitbucket.org/openid/connect/issue/914/session-5-missing-client_id-parameter 
> 
> ...where I stated that a required client_id parm was missing that allowed for the verification of the post_logout_uri value.  I've implemented this endpoint, and I think that I see that this parm may not be necessary. 
> 
> Section 5 of the session mgmt. spec says this: 
> 
> //=========== 
> This specification also defines the following parameters that are passed as query parameters in the logout request:
> id_token_hint 
> RECOMMENDED. Previously issued ID Token passed to the logout endpoint as a hint about the End-User's current authenticated session with the Client. This is used as an indication of the identity of the End-User that the RP is requesting be logged out by the OP. The OP need not be listed as an audience of the ID Token when it is used as an id_token_hint value. 
> post_logout_redirect_uri 
> OPTIONAL. URL to which the RP is requesting that the End-User's User Agent be redirected after a logout has been performed. The value MUST have been previously registered with the OP, either using the post_logout_redirect_uris Registration parameter or via another mechanism. If supplied, the OP SHOULD honor this request following the logout. 
> 
> 
> //=========== 
> 
> I would reword these definitions to say something along the following lines: 
> 
> post_logout_redirect_uri  OPTIONAL.  The URL to which the RP is requesting that the End-User's User Agent be redirected to after the logout has been performed.  The value MUST have been previously registered with the OP, either using the post_logout_redirect_uris Registration parameter or via another mechanism.  If supplied, id_token_hint MUST be specified. 
> 
> id_token_hint REQUIRED if "post_logout_redirect_uri" is specified, otherwise RECOMMENDED.  The previously issued ID Token passed to the logout endpoint as a hint about the End-User's current authenticated session with the Client. This is used as an indication of the identity of the End-User that the RP is requesting be logged out by the OP. If "post_logout_redirect_uri" is specified, then the "aud" member of this token MUST be a single element, and MUST be the client_id to which the specified "post_logout_redirect_uri" is registered. 
> 
> Additionally, a decision should be made as to whether a state parameter should be included that can be round-tripped via the post_logout_redirect_uri.  Either that, or the value of the id_token_hint parm is returned via the post_logout_redirect_uri redirect. 
> 
> The implication of this is that the end_session_endpoint can be called with no parameters, an id_token_hint, or both id_token_hint and post_logout_redirect_uri.
> 
> 
> 
> 
> 
> 
> 
> 
> Todd Lainhart
> Rational software
> IBM Corporation
> 550 King Street, Littleton, MA 01460-1250
> 1-978-899-4705
> 2-276-4705 (T/L)
> lainhart at us.ibm.com
> 
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab 
> 
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> 
> 
> 
> -- 
> --Breno
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140122/da63ac0e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140122/da63ac0e/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list