<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 14, 2016 at 3:45 AM, Torsten Lodderstedt <span dir="ltr"><<a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div 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 </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF">
- add c_hash to id token<br></div></blockquote><div><br></div><div><div>I would rephrase these two extensions as "supporting the hybrid flow", c_hash is a REQUIRED claim for the hybrid flow, the conformance test ID for this is: <font face="monospace, monospace">OP-IDToken-c_hash</font></div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF">
- 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></div></blockquote><div><br></div><div>While every RP should probably verify the nonce to avoid cut-and-paste, my understand is that only a subset need to protect against mix-up, as only a certain type of RP is actually vulnerable to that attack. Please somebody correct me if I'm wrong, I'm keen to know what the profile of a vulnerable RP is.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF">
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></div></blockquote><div><br></div><div>We have a solution in Connect. We should document that solution.</div><div><br></div><div>The Connect solution requires no changes to Connect. The proposal here is simply documenting what people should do if they want to mitigate these potential attacks.</div><div><br></div><div>I don't believe the Connect WG should be constrained to solve problems without using the features of Connect.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF">
So from my perspective, there are two questions:<br>
1) Can we find a solution for OIDC and OAuth (for code)?<br></div></blockquote><div><br></div><div>That solution may well be: use Connect. At least, if you wanted to solve it today without any spec changes or extensions, that would be my advice.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF">
2) Can we make it a simpler one?<br></div></blockquote><div><br></div><div>I'm listening.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF">
<br>
best regards,<br>
Torsten.<div><div><br>
<br>
<div>Am 13.04.2016 um 06:22 schrieb Mike
Jones:<br>
</div>
<blockquote type="cite">
<div>
<p><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(0,32,96)">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.<u></u><u></u></span></p>
<p><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(0,32,96)"><u></u> <u></u></span></p>
<p><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(0,32,96)">
-- Mike<u></u><u></u></span></p>
<p><a name="m_215345308969227833_m_-1544105078182548349__MailEndCompose"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(0,32,96)"><u></u> <u></u></span></a></p>
<span></span>
<div>
<div style="border-style:solid none none;border-right-width:initial;border-bottom-width:initial;border-left-width:initial;border-right-color:initial;border-bottom-color:initial;border-left-color:initial;border-top-color:rgb(225,225,225);border-top-width:1pt;padding:3pt 0in 0in">
<p><b><span style="font-size:11pt;font-family:calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:calibri,sans-serif">
Openid-specs-ab
[<a 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 href="mailto:wdenniss@google.com"><wdenniss@google.com></a><br>
<b>Cc:</b> <a 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<u></u><u></u></span></p>
</div>
</div>
<p><u></u> <u></u></p>
<p>If they send it and don’t detect if it has
changed from the request then that is a definite error.<u></u><u></u></p>
<div>
<p><u></u> <u></u></p>
</div>
<div>
<p>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.<u></u><u></u></p>
</div>
<div>
<p><u></u> <u></u></p>
</div>
<div>
<p>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.<u></u><u></u></p>
</div>
<div>
<p><u></u> <u></u></p>
</div>
<div>
<p>John B.<u></u><u></u></p>
</div>
<div>
<p><u></u> <u></u></p>
<div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p>On Apr 12, 2016, at 5:34 PM,
William Denniss <<a href="mailto:wdenniss@google.com">wdenniss@google.com</a>>
wrote:<u></u><u></u></p>
</div>
<p><u></u> <u></u></p>
<div>
<p><br>
<br>
<u></u><u></u></p>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif">On
Tue, Apr 12, 2016 at 2:28 PM, John Bradley<span> </span><<a href="mailto:ve7jtb@ve7jtb.com"></a><a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>><span> </span>wrote:<u></u><u></u></span></p>
<blockquote style="border-style:none none none solid;border-top-width:initial;border-right-width:initial;border-bottom-width:initial;border-top-color:initial;border-right-color:initial;border-bottom-color:initial;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p><span style="font-size:9pt;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.<u></u><u></u></span></p>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif">That
should be a test all-ready.<u></u><u></u></span></p>
</div>
</div>
</blockquote>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;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:9pt;font-family:helvetica,sans-serif"> </span></i><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u><u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;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.<u></u><u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<blockquote style="border-style:none none none solid;border-top-width:initial;border-right-width:initial;border-bottom-width:initial;border-top-color:initial;border-right-color:initial;border-bottom-color:initial;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p><span style="font-size:9pt;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.<u></u><u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif">Servers
really should support the form post response
mode.<u></u><u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;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.<u></u><u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif">That
is secure. <u></u><u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;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.<u></u><u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;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.<u></u><u></u></span></p>
</div>
</div>
</blockquote>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif">+1
to all the above<u></u><u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"> <u></u><u></u></span></p>
</div>
<blockquote style="border-style:none none none solid;border-top-width:initial;border-right-width:initial;border-bottom-width:initial;border-top-color:initial;border-right-color:initial;border-bottom-color:initial;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif">John
B.<u></u><u></u></span></p>
</div>
<div>
<div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
<div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif">On
Apr 12, 2016, at 4:58 PM, William
Denniss <<a href="mailto:wdenniss@google.com"></a><a href="mailto:wdenniss@google.com">wdenniss@google.com</a>>
wrote:<u></u><u></u></span></p>
</div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
<div>
<div>
<div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><br>
On Tue, Apr 12, 2016 at
12:50 PM, Hans Zandbelt <<a href="mailto:hzandbelt@pingidentity.com"></a><a href="mailto:hzandbelt@pingidentity.com">hzandbelt@pingidentity.com</a>> wrote:<u></u><u></u></span></p>
<blockquote style="border-style:none none none solid;border-top-width:initial;border-right-width:initial;border-bottom-width:initial;border-top-color:initial;border-right-color:initial;border-bottom-color:initial;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p><span style="font-size:9pt;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?<u></u><u></u></span></p>
</blockquote>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;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.<u></u><u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;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.<u></u><u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif">You
raise an interesting point
regarding client
confidentiality.<u></u><u></u></span></p>
</div>
<div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"> <u></u><u></u></span></p>
</div>
<blockquote style="border-style:none none none solid;border-top-width:initial;border-right-width:initial;border-bottom-width:initial;border-top-color:initial;border-right-color:initial;border-bottom-color:initial;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p><span style="font-size:9pt;font-family:helvetica,sans-serif">On
4/12/16 9:23 PM, William
Denniss wrote:<u></u><u></u></span></p>
<blockquote style="border-style:none none none solid;border-top-width:initial;border-right-width:initial;border-bottom-width:initial;border-top-color:initial;border-right-color:initial;border-bottom-color:initial;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p style="margin-bottom:12pt"><span style="font-size:9pt;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 href="mailto:nroy@internet2.edu"></a><a href="mailto:nroy@internet2.edu">nroy@internet2.edu</a><br>
<mailto:<a href="mailto:nroy@internet2.edu"></a><a href="mailto:nroy@internet2.edu">nroy@internet2.edu</a>>> wrote:<br>
<br>
<span> </span>Would
it be possible to check
for the secure behavior
in Roland's<br>
<span> </span>test
suite and either not
certify non-mitigating
implementations, or<br>
<span> </span>offer
a risk mitigation add-on
cert for those that do
the right thing?<br>
<br>
<span> </span>Nick<br>
<br>
<span> </span>From:
Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net"></a><a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a><br>
<span> </span><mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net"></a><a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>>>
on behalf of<br>
<span> </span>William
Denniss <<a href="mailto:wdenniss@google.com"></a><a href="mailto:wdenniss@google.com">wdenniss@google.com</a> <mailto:<a href="mailto:wdenniss@google.com"></a><a href="mailto:wdenniss@google.com">wdenniss@google.com</a>>><br>
<span> </span>Date:
Tuesday, April 12, 2016
at 11:01 AM<br>
<span> </span>To:
"<a href="mailto:openid-specs-ab@lists.openid.net"></a><a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
<span> </span><mailto:<a href="mailto:openid-specs-ab@lists.openid.net"></a><a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>>"<br>
<span> </span><<a href="mailto:openid-specs-ab@lists.openid.net"></a><a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
<span> </span><mailto:<a href="mailto:openid-specs-ab@lists.openid.net"></a><a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>>><br>
<span> </span>Subject:
[Openid-specs-ab]
Defining a Hardened
(Mix-up and<br>
<span> </span>Cut-and-Paste
Proof) OpenID Connect
Profile<br>
<br>
<span> </span>One
item that came out of
the discussions on the
sidelines of IETF95<br>
<span> </span>with
folk from this WG
(specifically Nat, Mike,
John, Brian and<br>
<span> </span>myself)
was the need for the
Connect community to
respond to the<br>
<span> </span>recently
<<a href="http://arxiv.org/abs/1508.04324v2/"></a><a href="http://arxiv.org/abs/1508.04324v2/">http://arxiv.org/abs/1508.04324v2/</a>>
documented<br>
<span> </span><<a href="http://arxiv.org/abs/1601.01229v2/"></a><a href="http://arxiv.org/abs/1601.01229v2/">http://arxiv.org/abs/1601.01229v2/</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 href="mailto:Openid-specs-ab@lists.openid.net"></a><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"></a><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><u></u><u></u></span></p>
</blockquote>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif;color:rgb(136,136,136)"><br>
-- <br>
Hans Zandbelt
| Sr. Technical Architect<br>
<a href="mailto:hzandbelt@pingidentity.com">hzandbelt@pingidentity.com</a> |
Ping Identity</span><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u><u></u></span></p>
</blockquote>
</div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
</div>
<p><span style="font-size:9pt;font-family:helvetica,sans-serif">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><u></u><u></u></span></p>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<p><u></u> <u></u></p>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>