<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">In my mind, the RP should never be
generating an ID token. For logout (or other id_token_hint uses),
the RP should pass along the ID token that it received from its
last login event, even if it's expired. It's essentially a
"session key", tying the two actions together. The IdP can
validate the token even if it's dead already (check issuer,
signatures, etc) and make sense of it in context of the requested
action.<br>
<br>
-- Justin<br>
<br>
On 2/17/2015 4:51 AM, Thomas Broyer wrote:<br>
</div>
<blockquote
cite="mid:CAEayHEPLptKX2--uq=5u7=aQWPn01zK_FVMEqPXiAo_bLAb_kA@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">One issue with this scheme is that this is
typically implemented as web page with <img> elements and
a <meta refresh> to redirect to some other place after all
images have loaded, but empty/blank in all other aspects. That
means that an misbehaving RP could impair the UX of the whole
"platform" (and more specifically the OP) if it doesn't respond
in a timely manner. Because there's no way to indicate timeouts
in HTML, the only way to workaround this is to add JavaScript
(setTimer in DOMContentLoaded, to trigger redirection before
onload if that ones takes too much time, possibly cancelled in
onunload if onload comes fast enough –shouldn't technically be
needed, but not all browsers behave the same IIRC); and/or to
add a message with a link to be clicked "if logging out takes
too much time".<br>
<div><br>
</div>
<div>Otherwise OK with the proposal overall. My notes below:</div>
<div><br>
</div>
<div>I don't quite understand why it talks about the
end_session_endpoint and post_logout_redirect_uris; it should
just defer to RP-Initiated Logout, saying it extends it (so it
must indeed be supported by the OP).</div>
<div><br>
</div>
<div>In “OP Logout Functionality”, “register this related
metadata value” should probably be “advertize this related
metadata value”.</div>
<div><br>
</div>
<div>What claims should be included in the id_token? What does
the "exp" claim would stand for? IIUC, the "exp" claim for the
ID Token initially returned during authentication represents
the authentication expiration [1], but the logout_uri is
called after the authentication has been revoked or has
expired here, so the "exp" claim cannot have that meaning in
this specific case. Should the id_token here be generated
specifically for this call, with a very short expiration? or
should/could it be the same as the one last sent to the RP
during authentication? How should the RP validate it? (because
it's not “received via direct communication between the Client
and the Token Endpoint”, I suppose the RP MUST validate the
signature?)</div>
<div><br>
</div>
<div>[1] This, to begin with, is really not clear at all; it's
only said once “in passing” in <<a moz-do-not-send="true"
href="https://openid.net/specs/openid-connect-core-1_0.html#Authentication">https://openid.net/specs/openid-connect-core-1_0.html#Authentication</a>>
without even mentioning the "exp" claim explicitly (“The
Authentication result is returned in an ID Token, as defined
in Section 2. It has Claims expressing such information as the
Issuer, the Subject Identifier, when the authentication
expires, etc.”; and note that this section, and thus this
sentence, is absent from openid-connect-basic-1_0 for
instance.) The "exp" claim is always defined as the
“expiration time on or after which the ID Token MUST NOT be
accepted for processing”, which is reflected in the “ID Token
Validation” section <<a moz-do-not-send="true"
href="https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation">https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation</a>>,
but that one only applies to validating the id_token received
during authentication, not how the OP should validate
id_token_hint at the authorization endpoint or
end_session_endpoint, or the id_token at the logout_uri here.
FWIW, I had originally understood that as that the ID Token
could have a validity timeframe of a few minutes only, and
that's how I implemented it! And the examples using an ID
Token with a validity timeframe of 1000 seconds (approx. 15
minutes) don't help in the understanding. <span
style="font-size:13.1999998092651px;line-height:19.7999992370605px">It's
never said either how an RP should behave should the ID
Token expire: should it re-authenticate (possibly using
prompt=none and id_token_hint –note that the ID Token could
have expired here, so having a definition of how the OP
should validate it would be great) to check the user is
still authenticated at the OP and possibly get a new ID
Token?</span></div>
</div>
<br>
<div class="gmail_quote">On Tue Feb 17 2015 at 03:45:31 Mike Jones
<<a moz-do-not-send="true"
href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span style="color:#1f497d">An
updated version is attached. Changes were:</span></p>
<p class="MsoNormal"
style="margin-right:0in;margin-bottom:6.0pt;margin-left:1.0in">
16-Feb-15 Added an optional <span
style="font-family:"Courier New"">id_token</span>
parameter to the
<span style="font-family:"Courier New"">logout_uri</span>
to authenticate requests and differentiate between
sessions, plus related metadata values. Added that
non-200 HTTP status codes can be used when the logout
fails. Clarified when post-logout redirection to an RP
occurs.</p>
<p class="MsoNormal"><span style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="color:#1f497d">I believe
that this addresses the comments received to date.</span></p>
<p class="MsoNormal"><span style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="color:#1f497d">
-- Mike</span></p>
</div>
</div>
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p> </p>
<p> </p>
<p>-----Original Message-----<br>
From: Openid-specs-ab [mailto:<a moz-do-not-send="true"
href="mailto:openid-specs-ab-bounces@lists.openid.net"
target="_blank">openid-specs-ab-bounces@lists.openid.net</a>]
On Behalf Of Mike Jones<br>
Sent: Sunday, February 15, 2015 11:03 PM<br>
To: John Bradley; Torsten Lodderstedt<br>
Cc: <a moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank">openid-specs-ab@lists.openid.net</a><br>
Subject: Re: [Openid-specs-ab] OpenID Connect Logout
using HTTP GET</p>
<p> </p>
<p>I'm increasingly thinking that we should allow the OP
to include the ID Token for the RP as a query parameter
in the logout request. I'm thinking this for two
reasons:</p>
<p>1. It would validate to the RP that the logout request
is legitimate.</p>
<p>2. It would tell the RP which session to log out,
should multiple users be logged in at the RP from the
OP.</p>
<p> </p>
<p>I don't think we should make including the ID Token
required, since deployment circumstances will differ.
In some cases, the extra validation is important. In
others, it isn't.</p>
<p> </p>
<p>If we do this, in the Discovery and Recovery metadata,
we should have the RP and the OP say whether the require
and provide the ID Token value as part of the logout
message to the RP.</p>
<p> </p>
<p>
-- Mike</p>
<p> </p>
<p>-----Original Message-----</p>
<p>From: John Bradley [<a moz-do-not-send="true"
href="mailto:ve7jtb@ve7jtb.com" target="_blank"><span
style="color:windowtext;text-decoration:none">mailto:ve7jtb@ve7jtb.com</span></a>]
</p>
<p>Sent: Sunday, February 15, 2015 11:34 AM</p>
<p>To: Torsten Lodderstedt</p>
<p>Cc: Thomas Broyer; Mike Jones; <a
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank">
<span style="color:windowtext;text-decoration:none">openid-specs-ab@lists.openid.net</span></a></p>
<p>Subject: Re: [Openid-specs-ab] OpenID Connect Logout
using HTTP GET</p>
<p> </p>
<p>Both</p>
<p> </p>
<p> </p>
<p>forcing a user to logout of a RP might also be used as
part of a larger phishing attack, especially if the IdP
returns the user to the bad guys landing page by
redirecting to the post_logout_redirect_uri.</p>
<p>That redirect URI needs to be registered but without
authenticating the RP via having a id_token for the user
Bad RP A could log the user out of all sessions and
redirect the user to itself, without the user currently
being logged in.</p>
<p> </p>
<p>Without the id_token all the IdP can do is log the user
out of all sessions.
</p>
<p> </p>
<p>Though when we start talking about IdP session
management things get a bit fuzzy, Many IdP will
automatically log the user back in to a RP if they are
still logged in to the IdP, the IdP may not have any
real notion of state per RP connection.</p>
<p> </p>
<p>John B.</p>
<p>On Feb 15, 2015, at 1:29 PM, Torsten Lodderstedt <<a
moz-do-not-send="true"
href="mailto:torsten@lodderstedt.net" target="_blank"><span
style="color:windowtext;text-decoration:none">torsten@lodderstedt.net</span></a>>
wrote:</p>
<p>> </p>
<p>> </p>
<p>> against the RP or the user?</p>
<p>> </p>
<p>> Am 15.02.2015 um 17:22 schrieb John Bradley:</p>
<p>>> It might be used as a denial of service via
xsrf.</p>
<p>> </p>
<p> </p>
</div>
</div>
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p>_______________________________________________</p>
</div>
</div>
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p>Openid-specs-ab mailing list</p>
<p><a moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank"><span
style="color:windowtext;text-decoration:none">Openid-specs-ab@lists.openid.net</span></a></p>
<p><a moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
target="_blank"><span
style="color:windowtext;text-decoration:none">http://lists.openid.net/mailman/listinfo/openid-specs-ab</span></a></p>
</div>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</body>
</html>