[Openid-specs-ab] [openid-connect-session] Checking post_logout_request_uri

[Brian Campbell]

(adding the WG mailing list this oldish thread from the interop list
https://groups.google.com/forum/#!topic/openid-connect-interop/lcvz7EXcUJ4)

"If the RP doesn't send you an id_token_hint to authenticate its identity,
the simple thing (and probably the best thing) to do is to not do a
post-logout redirect." -> if that's the expected/intended behavior, the
spec should say so

"The problem with sending a client_id is that it's not a secret.  Anyone
can spoof it, so it has no value in authenticating the client."  -> that's
true but the same mechanism is used in OAuth/Connect at the authorization
endpoint to identify the client and determine allowed redirect URI(s). Why
is it different here?



On Fri, Apr 17, 2015 at 2:55 PM, Mike Jones <Michael.Jones at microsoft.com>
wrote:

> If the RP doesn't send you an id_token_hint to authenticate its identity,
> the simple thing (and probably the best thing) to do is to not do a
> post-logout redirect.  The problem with sending a client_id is that it's
> not a secret.  Anyone can spoof it, so it has no value in authenticating
> the client.
>
>                                 -- Mike
>
> -----Original Message-----
> From: openid-connect-interop at googlegroups.com [mailto:
> openid-connect-interop at googlegroups.com] On Behalf Of Clément OUDOT
> Sent: Friday, April 17, 2015 1:01 AM
> To: openid-connect-interop at googlegroups.com
> Subject: Re: [openid-connect-session] Checking post_logout_request_uri
>
> 2015-04-16 21:31 GMT+02:00 Brian Campbell <bcampbell at pingidentity.com>:
> > This question (or very close) has come up before. It sure seems like
> > something needs to be added or adjusted or clarified in the spec.
> >
> > If a request is received at the end_session_endpoint with only
> > post_logout_redirect_uri and state parameters, what should the OP do?
> > Is that an error condition? Are the parameters just ignored? Is the
> > expectation that the calling client be looked up based on the
> > post_logout_redirect_uri (I'm guessing some OP/AS implementations
> > won't want to index on the value just to support sending the user back
> somewhere after maybe logging out)?
> >
> > What if a client wants to use post_logout_redirect_uri but doesn't
> > want to hold onto the id token in order to use it as an id_token_hint?
> > Or doesn't like the idea of passing id tokens around as parameters?
> >
> > Does the id_token_hint mean that, to use John's words, "it is a trusted
> RP"?
> > Nothing says that that I see. It mostly just talks about being a "hint
> > about the End-User's current authenticated session with the Client."
> > What if it's expired? What if it's encrypted? Should the signature
> > verify? What if keys have rotated so as to make signature verification
> > impossible? If there is a problem, should the client be informed of
> > the error? Or the user? Or ignore it and move on?
> >
> > I feel like a different set of questions come to mind each time I read
> > this bit of the spec. That's what came to mind today.
>
>
> I agree, so why not just change the specification (it is still a
> draft) to require client_id (if redirection is asked) as GET parameter of
> the logout request?
>
>
> Clément.
>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenID Connect Interop" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openid-connect-interop+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenID Connect Interop" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openid-connect-interop+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150603/54db0d5c/attachment.html>