[Openid-specs-ab] session management - front channel logout - expired id_token hint

[Brock Allen]

Can you clarify or elaborate on what you’re saying on your last email? I
don’t quite follow. Thanks

On Sat, Aug 31, 2019 at 11:04 AM Filip Skokan via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> That of course comes from the POV where killing a session is comparable to
> a no-op and maybe that the session is only dropped if the client has been
> encountered in it?
>
> Odesláno z iPhonu
>
> 31. 8. 2019 v 8:49, Filip Skokan <panva.ip at gmail.com>:
>
> Hi Phil, everyone,
>
>
> https://bitbucket.org/openid/connect/issues/1087/rp-initiated-logout-insufficient
>
> An issue i opened on the subject a while back with no group response.
>
> I always assumed the exp is to be ignored because of the short ttl nature
> of an id token.
>
> Odesláno z iPhonu
>
> 31. 8. 2019 v 2:26, Phil Hunt via Openid-specs-ab <
> openid-specs-ab at lists.openid.net>:
>
> A question has arisen based on differences observed in multiple
> implementations.
>
> When executing front channel logout per the session management spec it is
> unclear what the response should be if “id_token_hint” contains an expired
> token.  The processing rules allow you to ignore audience but they say
> nothing about an expired token.
>
> id_token_hintRECOMMENDED. 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.
>
> Section 6 says…
> "If any of the validation procedures defined in this specification fail,
> any operations requiring the information that failed to correctly validate
> MUST be aborted and the information that failed to validate MUST NOT be
> used."
>
> The problem is, the spec never calls for the token to be validated but it
> does say you can skip the audience.
>
> In this case what is the correct response?  It seems like an error should
> be returned.  Though killing an expired session doesn’t seem like much more
> than a no-op.  It seems like this would provide better UX.
>
> The concern is that if accepted it might be used as a DoS attack to cause
> the redirect url to be invoked when it shouldn’t.
>
> Phil Hunt | OCI IDCS Cloud Identity & Security Architect
> Oracle Corporation, Oracle Cloud Infrastructure
> @independentid
> www.independentid.com
> phil.hunt at oracle.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
>
-- 

-Brock
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190831/cdf5278d/attachment.html>