<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi all,<br>
<br>
I would like to take the perspective of an OP (with a reasonable
number of active RPs), which currently only supports code. The same
endpoint serves OpenId Connect, plain OAUth and combined requests.<br>
<br>
Let me first summarize what I understand about the proposed profile,
which is supposed to stop mix up and code injection/CnP:<br>
- response type: "code id_token"<br>
- response_mode: "form_post"<br>
- Clients must use nonces<br>
<br>
extensions to OP:<br>
- issue ID token in the front channel<br>
- add c_hash to id token<br>
- add new response mode form post <br>
<br>
extensions every RP:<br>
- support receiving form post<br>
- add several checks in the front channel (before exchanging the
code):<br>
-- verify id token (iss, aud, signature)<br>
-- verify c_hash<br>
-- verify nonce is the same as send in request<br>
<br>
Am I missing anything?<br>
<br>
Apperently, this solution would not work for plain OAuth. Moreover,
I personally think this significantly adds complexity (and cost) to
both ends, OP as well as RPs, in comparison to other potential
mitigations. Experience shows that complexity is the enemy of
correct/reliable implementations, which is esp. dangerous when it
comes to security for mass market/internet services.<br>
<br>
So from my perspective, there are two questions:<br>
1) Can we find a solution for OIDC and OAuth (for code)?<br>
2) Can we make it a simpler one?<br>
<br>
best regards,<br>
Torsten.<br>
<br>
<div class="moz-cite-prefix">Am 13.04.2016 um 06:22 schrieb Mike
Jones:<br>
</div>
<blockquote
cite="mid:SN1PR0301MB16452A858569C0A7D8586610F5960@SN1PR0301MB1645.namprd03.prod.outlook.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#002060;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">It
is always mandatory for the server to include the nonce in
the ID Token if provided in the request and it is likewise
always mandatory for the RP to validate the nonce, if
present in the ID Token. For all response_type values other
than “code”, including a nonce in the request is also
mandatory.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">
-- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><a moz-do-not-send="true"
name="_MailEndCompose"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"><o:p> </o:p></span></a></p>
<span style="mso-bookmark:_MailEndCompose"></span>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">
Openid-specs-ab
[<a class="moz-txt-link-freetext" href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto:openid-specs-ab-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>John Bradley<br>
<b>Sent:</b> Tuesday, April 12, 2016 5:31 PM<br>
<b>To:</b> William Denniss <a class="moz-txt-link-rfc2396E" href="mailto:wdenniss@google.com"><wdenniss@google.com></a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-ab] Defining a
Hardened (Mix-up and Cut-and-Paste Proof) OpenID Connect
Profile<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If they send it and don’t detect if it has
changed from the request then that is a definite error.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If they don’t send it, it should be a
warning as there are some cases with a simple preconfigured
client that not checking may be OK.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I personally argued at the time to always
check it, so I am not going to push back very hard on making
it mandatory to check other than it is a change to the spec.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">John B.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Apr 12, 2016, at 5:34 PM,
William Denniss <<a moz-do-not-send="true"
href="mailto:wdenniss@google.com">wdenniss@google.com</a>>
wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">On
Tue, Apr 12, 2016 at 2:28 PM, John Bradley<span
class="apple-converted-space"> </span><<a
moz-do-not-send="true"
href="mailto:ve7jtb@ve7jtb.com"><a class="moz-txt-link-abbreviated" href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a></a>><span
class="apple-converted-space"> </span>wrote:<o:p></o:p></span></p>
<blockquote style="border:none;border-left:solid
#CCCCCC 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">The
AS is all-ready required to include nonce in
the id_token if it is present in the request.
That is a MUST in the spec.<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">That
should be a test all-ready.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">There
is: </span><i><span
style="font-size:9.5pt;font-family:"Helvetica",sans-serif">ID
Token has nonce when requested for code flow
[Basic] (OP-nonce-code)</span></i><i><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> </span></i><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">So
for this, it's more that we need to add an RP
test to ensure that RPs are actually sending and
verifying nonce.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid
#CCCCCC 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Basically
fragment encoding is not a good idea any
more other than for JS in the browser or for
native apps using view controllers or system
browsers.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Servers
really should support the form post response
mode.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">A
client that wants to be secure can send
nonce and use “code id_token” if they want
offline or “token id_token” if they don’t
want offline.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">That
is secure. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">There
are other mitigations we talked about in
OAuth with returning the client_id and iss
as parameters rather than returning a
id_token.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">The
client really only needs to check those two
values in the front channel, but I would not
want to change the spec to say that.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">+1
to all the above<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> <o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid
#CCCCCC 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">John
B.<o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
<div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">On
Apr 12, 2016, at 4:58 PM, William
Denniss <<a
moz-do-not-send="true"
href="mailto:wdenniss@google.com"><a class="moz-txt-link-abbreviated" href="mailto:wdenniss@google.com">wdenniss@google.com</a></a>>
wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
On Tue, Apr 12, 2016 at
12:50 PM, Hans Zandbelt <<a
moz-do-not-send="true"
href="mailto:hzandbelt@pingidentity.com"><a class="moz-txt-link-abbreviated" href="mailto:hzandbelt@pingidentity.com">hzandbelt@pingidentity.com</a></a>> wrote:<o:p></o:p></span></p>
<blockquote
style="border:none;border-left:solid
#CCCCCC 1.0pt;padding:0in 0in
0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">from
an implementers/deployment
standpoint I would argue
that if the id_token is
delivered in the front
channel, I may just as
well get the access token
from there too rather than
having to deal with the
overhead of calling the
token endpoint, esp. since
at_hash is there to
protect integrity<br>
<br>
so I'd favor
response_mode=form_post,
response_type="id_token
token" over hybrid<br>
<br>
I realize that this
doesn't leverage the
possibility of using a
client secret to get the
access token but it
doesn't really seem to
matter security-wise at
this point as the id_token
was delivered without
leveraging it as well<br>
<br>
anything wrong with that
line of reasoning?<o:p></o:p></span></p>
</blockquote>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">1)
Server won't have offline
access with "id_token
token". 2) The primary
case we are dealing with
today is the code flow,
and we are really just
suggesting clients add
security checks onto their
existing flows by
leveraging id_token.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">It's
true that you could do
many of the same checks
with "id_token token" to
verify that the access
token was issued by the
correct party and avoid
cut-and-paste and mix-up,
if you only needed a
once-off access token.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">You
raise an interesting point
regarding client
confidentiality.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> <o:p></o:p></span></p>
</div>
<blockquote
style="border:none;border-left:solid
#CCCCCC 1.0pt;padding:0in 0in
0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">On
4/12/16 9:23 PM, William
Denniss wrote:<o:p></o:p></span></p>
<blockquote
style="border:none;border-left:solid
#CCCCCC 1.0pt;padding:0in
0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"
style="margin-bottom:12.0pt"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Good
point.<br>
<br>
Regarding the OP tests,
the following are
relevant to mitigate the<br>
cut-and-paste and mix-up
attacks:<br>
<br>
1. ID Token has nonce
when requested for code
flow [Basic]
(OP-nonce-code)<br>
2. Request with
response_mode=form_post
[Extra]
(OP-Response-form_post)<br>
<br>
1) is important for
preventing cut-and-paste
(the id token needs to<br>
contain the 'nonce')<br>
2) is important for
preventing mix-up as it
means the redirect
endpoint<br>
gets the id_token on the
response at the server,
as opposed to in the<br>
URI fragment.<br>
<br>
Unfortunately, form_post
is optional for OPs, and
sending the nonce on<br>
the code flow is
optional for RPs (though
fortunately to it is<br>
compulsory for OPs to
support thanks to
OP-nonce-code).<br>
<br>
We could add an hardened
OP test for:<br>
– Forcing nonce to be
present on the code flow<br>
<br>
We should definitely
have RP tests for:<br>
– sending and validating
nonce on the code flow<br>
– validating the c_hash,
iss, aud on the hybrid
flow<br>
<br>
How we would profile
these tests I'm not
sure; would they go in
the<br>
Basic testing profile,
or in a new Hardened
one? We could move<br>
OP-Response-form_post to
the Basic profile if we
wanted to be<br>
opinionated, or define a
new profile.<br>
<br>
The good news is that
supporting the features
required to mitigate<br>
mix-up &
cut-and-paste is not all
that hard to do in
Connect.<br>
<br>
<br>
On Tue, Apr 12, 2016 at
10:46 AM, Nick Roy <<a
moz-do-not-send="true"
href="mailto:nroy@internet2.edu"><a class="moz-txt-link-abbreviated" href="mailto:nroy@internet2.edu">nroy@internet2.edu</a></a><br>
<mailto:<a
moz-do-not-send="true"
href="mailto:nroy@internet2.edu"><a class="moz-txt-link-abbreviated" href="mailto:nroy@internet2.edu">nroy@internet2.edu</a></a>>> wrote:<br>
<br>
<span
class="apple-converted-space"> </span>Would
it be possible to check
for the secure behavior
in Roland's<br>
<span
class="apple-converted-space"> </span>test
suite and either not
certify non-mitigating
implementations, or<br>
<span
class="apple-converted-space"> </span>offer
a risk mitigation add-on
cert for those that do
the right thing?<br>
<br>
<span
class="apple-converted-space"> </span>Nick<br>
<br>
<span
class="apple-converted-space"> </span>From:
Openid-specs-ab <<a
moz-do-not-send="true"
href="mailto:openid-specs-ab-bounces@lists.openid.net"><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a></a><br>
<span
class="apple-converted-space"> </span><mailto:<a
moz-do-not-send="true"
href="mailto:openid-specs-ab-bounces@lists.openid.net"><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a></a>>>
on behalf of<br>
<span
class="apple-converted-space"> </span>William
Denniss <<a
moz-do-not-send="true"
href="mailto:wdenniss@google.com"><a class="moz-txt-link-abbreviated" href="mailto:wdenniss@google.com">wdenniss@google.com</a></a> <mailto:<a
moz-do-not-send="true"
href="mailto:wdenniss@google.com"><a class="moz-txt-link-abbreviated" href="mailto:wdenniss@google.com">wdenniss@google.com</a></a>>><br>
<span
class="apple-converted-space"> </span>Date:
Tuesday, April 12, 2016
at 11:01 AM<br>
<span
class="apple-converted-space"> </span>To:
"<a
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a></a><br>
<span
class="apple-converted-space"> </span><mailto:<a
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a></a>>"<br>
<span
class="apple-converted-space"> </span><<a
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a></a><br>
<span
class="apple-converted-space"> </span><mailto:<a
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a></a>>><br>
<span
class="apple-converted-space"> </span>Subject:
[Openid-specs-ab]
Defining a Hardened
(Mix-up and<br>
<span
class="apple-converted-space"> </span>Cut-and-Paste
Proof) OpenID Connect
Profile<br>
<br>
<span
class="apple-converted-space"> </span>One
item that came out of
the discussions on the
sidelines of IETF95<br>
<span
class="apple-converted-space"> </span>with
folk from this WG
(specifically Nat, Mike,
John, Brian and<br>
<span
class="apple-converted-space"> </span>myself)
was the need for the
Connect community to
respond to the<br>
<span
class="apple-converted-space"> </span>recently
<<a
moz-do-not-send="true"
href="http://arxiv.org/abs/1508.04324v2/"><a class="moz-txt-link-freetext" href="http://arxiv.org/abs/1508.04324v2/">http://arxiv.org/abs/1508.04324v2/</a></a>>
documented<br>
<span
class="apple-converted-space"> </span><<a
moz-do-not-send="true"
href="http://arxiv.org/abs/1601.01229v2/"><a class="moz-txt-link-freetext" href="http://arxiv.org/abs/1601.01229v2/">http://arxiv.org/abs/1601.01229v2/</a></a>>
security threats.<br>
<br>
Connect is actually
in a much stronger place
for mitigating these<br>
attacks (as noted in
the papers themselves)
than pure OAuth, with<br>
the id_token
offering a cryptographic
binding of the code to
the<br>
issuer, audience and
session identifier
(nonce).<br>
<br>
However, certain
steps need to be
followed, for example
using<br>
'nonce' with the
code flow (which is
optional to implement
for<br>
clients) to protect
against cut-and-paste,
and using the form-post<br>
response type with
the hybrid flow to
verify that the code was<br>
issued by the
expected IdP, to ensure
the code is exchanged at
the<br>
correct token
endpoint (mitigating
mix-up).<br>
<br>
We discussed last
week creating a profile
of Connect that
recommends<br>
those practices to
mitigate these classes
of attack as a response
to<br>
the security
researchers' findings. I
wanted to share that<br>
suggestion with the
list, and continue the
conversation.<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing
list<br>
<a
moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net"><a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></a><br>
<a
moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"><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></a><o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#888888"><br>
-- <br>
Hans Zandbelt
| Sr. Technical Architect<br>
<a moz-do-not-send="true"
href="mailto:hzandbelt@pingidentity.com">hzandbelt@pingidentity.com</a> |
Ping Identity</span><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p></o:p></span></p>
</blockquote>
</div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">_______________________________________________<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">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></span></p>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</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>