<div dir="ltr"><br><br><div class="gmail_quote">On Sun Feb 15 2015 at 17:22:49 John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">It might be used as a denial of service via xsrf.<div><br></div><div>I originally wanted to make the id_token_hint required to prevent that sort of thing from working.  </div><div>That was softened to a RECOMMENDED in the Session Management spec. </div><div><br></div><div>I suspect a compromise might be for the IdP to prompt the user if the request doesn’t contain a valid id_token_hint.</div></div></blockquote><div><br></div><div>This is already recommended in the Security Considerations section, but that's for the OpenID Connect Session Management spec: <a href="https://openid.net/specs/openid-connect-session-1_0.html#Security">https://openid.net/specs/openid-connect-session-1_0.html#Security</a></div><div>And the RP-Initiated Logout section already says the OP SHOULD  ask the End-User anyway: <a href="https://openid.net/specs/openid-connect-session-1_0.html#RPLogout">https://openid.net/specs/openid-connect-session-1_0.html#RPLogout</a></div><div><br></div><div>Actually, even with a valid id_token_hint you should IMO prompt the user. id_token_hint aren't secrets, they leak in id_token_hint to the authorization_endpoint and aren't generally revocable (I mean, in most implementations I believe).</div></div></div>