<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi all,<br>
<br>
it's my impression that every particpant in this discussion has some
threats and counter measures in mind but nothing is explicitely
spelled out/documented. I repeat my statement that first of all the
relevant threats must be documented. As always, there will be
different measures to mitigated those threats and the WG should
discuss/decide, which counter measures are backed into the protocol
and which of them are just explained/recommended.<br>
<br>
I see open redirection as a potential threat. We use a global
whitelist for post url's to mitigate it. Id token hints and
pre-registered urls are another way of achieving the same goal.<br>
Regarding XSRF: the logout request will terminate the session -
where is the risk?<br>
<br>
regards,<br>
Torsten.<br>
<br>
<br>
<div class="moz-cite-prefix">Am 23.01.2014 01:51, schrieb John
Bradley:<br>
</div>
<blockquote
cite="mid:0DE0AAE4-F7B7-40C2-A5F8-08B7989AE5AA@ve7jtb.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
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.
<div><br>
</div>
<div>I don't know that it is actually easier than just indexing
the URI itself. </div>
<div><br>
</div>
<div>Following a post logout redirect without a id_token even if
it is registered may be a bad idea. </div>
<div><br>
</div>
<div>John B.</div>
<div><br>
</div>
<div><br>
<div>
<div>On Jan 22, 2014, at 7:19 PM, Breno de Medeiros <<a
moz-do-not-send="true" href="mailto:breno@google.com">breno@google.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">The requirement that login be available if a
login was not processed is incompatible with any form of
'XSRF' protection of the logout endpoint.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, Jan 20, 2014 at 8:28 AM,
Torsten Lodderstedt <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:torsten@lodderstedt.net"
target="_blank">torsten@lodderstedt.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Hi Todd,<br>
<br>
this page would not necessarily have a client id.<br>
<br>
Regards,<br>
Torsten.<br>
<br>
<div class="gmail_quote"><br>
<br>
Todd W Lainhart <<a moz-do-not-send="true"
href="mailto:lainhart@us.ibm.com"
target="_blank">lainhart@us.ibm.com</a>>
schrieb:
<div>
<div class="h5">
<blockquote class="gmail_quote"
style="margin:0pt 0pt 0pt
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<font face="sans-serif">Hi Torsten -</font>
<br>
<br>
<font face="sans-serif">> </font><font
size="3">We see the
need to trigger a logout from pages, which
did not previously process a
login (portal, landing page).</font>
<br>
<br>
<font face="sans-serif">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.<br>
</font>
<br>
<table style="border-collapse:collapse"
width="223">
<tbody>
<tr height="8">
<td
style="border-style:solid;border-color:#000000;border-width:0px
0px 0px 0px;padding:0px 0px"
width="223" bgcolor="white"><font
face="Verdana" size="1"><b><br>
<br>
<br>
Todd Lainhart<br>
Rational software<br>
IBM Corporation<br>
550 King Street, Littleton, MA
01460-1250</b></font><font
face="Arial" size="1"><b><br>
<a moz-do-not-send="true"
href="tel:1-978-899-4705"
value="+19788994705"
target="_blank">1-978-899-4705</a><br>
2-276-4705 (T/L)<br>
<a moz-do-not-send="true"
href="mailto:lainhart@us.ibm.com"
target="_blank">lainhart@us.ibm.com</a></b></font></td>
</tr>
</tbody>
</table>
<br>
<br>
<br>
<br>
<br>
<font color="#5f5f5f" face="sans-serif"
size="1">From:
</font><font face="sans-serif" size="1">Torsten
Lodderstedt
<<a moz-do-not-send="true"
href="mailto:torsten@lodderstedt.net"
target="_blank">torsten@lodderstedt.net</a>></font>
<br>
<font color="#5f5f5f" face="sans-serif"
size="1">To:
</font><font face="sans-serif" size="1">Todd
W Lainhart/Lexington/IBM@IBMUS,
</font>
<br>
<font color="#5f5f5f" face="sans-serif"
size="1">Cc:
</font><font face="sans-serif" size="1">"<a
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank">openid-specs-ab@lists.openid.net</a>"
<<a moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank">openid-specs-ab@lists.openid.net</a>></font>
<br>
<font color="#5f5f5f" face="sans-serif"
size="1">Date:
</font><font face="sans-serif" size="1">01/18/2014
03:44 AM</font>
<br>
<font color="#5f5f5f" face="sans-serif"
size="1">Subject:
</font><font face="sans-serif" size="1">Re:
[Openid-specs-ab]
end_session endpoint parameter specs</font>
<br>
<hr noshade="noshade">
<br>
<br>
<br>
<font size="3">Hi Todd,</font>
<br>
<br>
<font size="3">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.</font>
<br>
<br>
<font size="3">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.</font>
<br>
<br>
<font size="3">regards,</font>
<br>
<font size="3">Torsten.</font>
<br>
<font size="3"><br>
Am 17.01.2014 um 22:45 schrieb Todd W
Lainhart <</font><a
moz-do-not-send="true"
href="mailto:lainhart@us.ibm.com"
target="_blank"><font color="blue"
size="3"><u>lainhart@us.ibm.com</u></font></a><font
size="3">>:<br>
</font>
<br>
<font face="sans-serif">Last week I filed:</font><font
size="3">
<br>
</font><font color="blue" size="3"><u><br>
</u></font><a moz-do-not-send="true"
href="https://bitbucket.org/openid/connect/issue/914/session-5-missing-client_id-parameter"
target="_blank"><tt><font color="blue"><u>https://bitbucket.org/openid/connect/issue/914/session-5-missing-client_id-parameter</u></font></tt></a><font
size="3">
<br>
</font><font face="sans-serif"><br>
...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.</font><font
size="3">
<br>
</font><font face="sans-serif"><br>
Section 5 of the session mgmt. spec says
this:</font><font size="3"> <br>
</font><font face="sans-serif"><br>
//===========</font><font size="3"> </font><font
face="Verdana"><br>
This specification also defines the
following parameters that are passed
as query parameters in the logout request:</font><font
size="3"> </font>
<p><font face="Verdana">id_token_hint</font><font
size="3"> </font><font face="Verdana"><br>
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 </font><font color="#002060"
face="Courier New">id_token_hint</font><font
face="Verdana">
value.</font><font size="3"> </font><font
face="Verdana"><br>
post_logout_redirect_uri</font><font
size="3"> </font><font face="Verdana"><br>
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 </font><font
color="#002060" face="Courier New">post_logout_redirect_uris</font><font
face="Verdana">
Registration parameter or via another
mechanism. If supplied, the OP SHOULD
honor this request following the logout.</font><font
size="3"> </font><font
face="sans-serif"><br>
</font><font size="3"><br>
</font><font face="sans-serif"><br>
//===========</font><font size="3"> <br>
</font><font face="sans-serif"><br>
I would reword these definitions to say
something along the following lines:</font><font
size="3">
<br>
</font><font face="sans-serif"><br>
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.</font><font
size="3">
<br>
</font><font face="sans-serif"><br>
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.</font><font size="3"> <br>
</font><font face="sans-serif"><br>
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.</font><font
size="3"> <br>
</font><font face="sans-serif"><br>
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.</font><font
size="3">
</font>
</p>
<div>
<br class="webkit-block-placeholder">
</div>
<table style="border-collapse:collapse"
width="223">
<tbody>
<tr height="8">
<td
style="border-style:solid;border-color:#000000;border-width:0px
0px 0px 0px;padding:1px 1px"
width="221" bgcolor="white"><font
size="3"><br>
<br>
</font><font face="Verdana" size="1"><b><br>
<br>
<br>
<br>
Todd Lainhart<br>
Rational software<br>
IBM Corporation<br>
550 King Street, Littleton, MA
01460-1250</b></font><font
face="Arial" size="1"><b><br>
<a moz-do-not-send="true"
href="tel:1-978-899-4705"
value="+19788994705"
target="_blank">1-978-899-4705</a><br>
2-276-4705 (T/L)</b></font><font
color="blue" face="Arial" size="1"><b><u><br>
</u></b></font><a
moz-do-not-send="true"
href="mailto:lainhart@us.ibm.com"
target="_blank"><font color="blue"
face="Arial" size="1"><b><u>lainhart@us.ibm.com</u></b></font></a></td>
</tr>
</tbody>
</table>
<br>
<br>
<font size="3">_______________________________________________<br>
Openid-specs-ab mailing list</font><font
color="blue" size="3"><u><br>
</u></font><a moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank"><font color="blue"
size="3"><u>Openid-specs-ab@lists.openid.net</u></font></a><font
color="blue" size="3"><u><br>
</u></font><a moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
target="_blank"><font color="blue"
size="3"><u>http://lists.openid.net/mailman/listinfo/openid-specs-ab</u></font></a>
<br>
<div><br class="webkit-block-placeholder">
</div>
</blockquote>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net">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>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
--Breno<br>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<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><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>