<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
HI John,<br>
<br>
<div class="moz-cite-prefix">Am 17.10.2013 23:57, schrieb John
Bradley:<br>
</div>
<blockquote
cite="mid:7B19D404-FAC6-4620-B01E-218AE6F753F9@ve7jtb.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Torsten,
<div><br>
</div>
<div>This is not really about the code response type. (Though it
might be observed that code to a public client would be safer
with POST than GET as the code would not leak in the referrer)</div>
</blockquote>
yeah, do you think this is a practical problem? I would assume the
typical public clients utilizing the code grant type is an native
app. I don't think they have real issues with HTTP referrers). But
we can reason about this over a beer at Vancouver :-)<br>
<br>
<blockquote
cite="mid:7B19D404-FAC6-4620-B01E-218AE6F753F9@ve7jtb.com"
type="cite">
<div><br>
</div>
<div>The issue is with the "code id_token", "token id_token",
"code token id_token" and "id_token" response types where the
recipient is not JS in the browser but a host.</div>
<div><br>
</div>
<div>The "code id_token" response type was intended to give the
client a fast way to customize the UI while it asynchronously
fetches additional data in the back end.</div>
<div><br>
</div>
<div>Currently the redirect_uri must contain JS that parses the
fragment and sends the contents of the fragment as a form
encoded POST to the client.</div>
<div><br>
</div>
<div>Some people want to optimize that by having the Authorization
server send JS that autoposts a form with the paramaters like
openID 2.</div>
</blockquote>
<blockquote
cite="mid:7B19D404-FAC6-4620-B01E-218AE6F753F9@ve7jtb.com"
type="cite">
<div><br>
</div>
<div>There might be a alight speed advantage, but the main
advantage is a simpler client (you will now point out that
simple clients should use code).</div>
</blockquote>
<br>
I'm just surprised. I was said some time ago there are people out
there, who consider processing fragments in JS code and post the
result to the backend easier than everthing else in the world :-) <br>
<br>
Seriously speaking, one can POST the result of the authorization
transaction to the backend from a OP-provided page. But why would
anyone want to post both a code as well as tokens to a backend at
the same time. Does this make any sense to you? One or the other is
totally sufficient. As you have written above the additional
ID/access token was intended to "... give the client a fast way to
customize the UI while it asynchronously fetches additional data in
the back end." But if the server automatically posts the response to
the clients backend there is no client UI involved in this process
at all. BTW: This also means the user experience will be as good or
as bad as with HTTP redirects.<br>
<br>
<blockquote
cite="mid:7B19D404-FAC6-4620-B01E-218AE6F753F9@ve7jtb.com"
type="cite">
<div><br>
</div>
<div>The downside to POST in a redirect is well understood as
having sub-optimal UI with browser flashing and possibly needing
to present a submit button as compared to postMessage or
fragment encoding.</div>
<div><br>
</div>
<div>My personal feeling is that this is a OAuth issue, though one
that impacts Connect. </div>
<div><br>
</div>
</blockquote>
<br>
I don't see the issue at all.<br>
<br>
<blockquote
cite="mid:7B19D404-FAC6-4620-B01E-218AE6F753F9@ve7jtb.com"
type="cite">
<div>My main concern is forcing something through in Connect may
not align with a OAuth WG is that it will require more work for
implementers in the long run.</div>
<div><br>
</div>
<div>There is nothing in the current spec that is any way
unworkable, however using POST can be a useful optimization in
some specific environments.</div>
<div><br>
</div>
<div>I suspect that this is partially a fragment encoding is new
and unfamiliar while POST is well understood by developers
issue. </div>
<div>If everyone moved from fragment to POST for Connect it would
not be a positive UI direction.</div>
<div><br>
</div>
<div>I have not totally made my mind up yet, but am leaning
towards this being a OAuth extension rather than something
specific to Connect.</div>
</blockquote>
<br>
regards,<br>
Torsten.<br>
<blockquote
cite="mid:7B19D404-FAC6-4620-B01E-218AE6F753F9@ve7jtb.com"
type="cite">
<div><br>
</div>
<div>John B.</div>
<div><br>
<div>
<div>On 2013-10-17, at 6:19 PM, Torsten Lodderstedt <<a
moz-do-not-send="true"
href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF"> Hi all,<br>
<br>
can someone please explain the problems, which shall be
resolved by POSTing responses? As far as I understand,
POSTing responses in OpenID 2.0 were neccessary in order
to transport large amounts of data (esp. when utilizing
AX). In OAuth and Connect, there is just the authz code +
state sent to the client in the grant type code. I don't
expect them to blow up the redirect URI.<br>
<br>
regards,<br>
Torsten. <br>
<br>
<div class="moz-cite-prefix">Am 17.10.2013 22:38, schrieb
Richer, Justin P.:<br>
</div>
<blockquote
cite="mid:B33BFB58CCC8BE4998958016839DE27E33BDF16D@IMCMBX01.MITRE.ORG"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<style>
<!--
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:Calibri}
@font-face
{font-family:Tahoma}
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
{color:blue;
text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline}
span.EmailStyle17
{font-family:"Calibri","sans-serif";
color:#1F497D}
.MsoChpDefault
{font-family:"Calibri","sans-serif"}
@page WordSection1
{margin:1.0in 1.0in 1.0in 1.0in}
-->
</style>
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
<div style="direction: ltr; font-family: Tahoma;
font-size: 10pt; ">I completely agree with Nat. There
have been many months for people to comment on,
interop with, and add features to the set. I think
that changing something this fundamental this late in
the game with so little testing behind it is
ludicrous. I don't understand how this is coming up
all of a sudden. From my perspective, it sounds like
one contingent is trying to sneak something in just
under the wire and hoping nobody will notice. <br>
<br>
This can easily be defined as an extension and it
would do much more harm than good trying to cram it in
now.<br>
<br>
As to Tony's contention: plenty of us are deploying
and exactly what you keep calling impossible. There
are numerous existence proofs in contrast to your
position.<br>
<br>
-- Justin<br>
<br>
<div style="font-family: 'Times New Roman'; font-size:
16px; ">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF193203"><font
size="2" face="Tahoma"><b>From:</b> <a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>
[<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>]
on behalf of Anthony Nadalin [<a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:tonynad@microsoft.com">tonynad@microsoft.com</a>]<br>
<b>Sent:</b> Thursday, October 17, 2013 2:04 PM<br>
<b>To:</b> Nat Sakimura; Mike Jones<br>
<b>Cc:</b> <a moz-do-not-send="true"
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] Spec call
notes 17-Oct-13<br>
</font><br>
</div>
<div>
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D">If you can’t deploy this
stuff it’s no good, it would then be a board
issue to approve or disapprove and I know
where I would vote</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:#1F497D"> </span></a></p>
<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"">
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>
[<a moz-do-not-send="true"
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>Nat Sakimura<br>
<b>Sent:</b> Thursday, October 17, 2013 9:55
AM<br>
<b>To:</b> Mike Jones<br>
<b>Cc:</b> <a moz-do-not-send="true"
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] Spec
call notes 17-Oct-13</span></p>
<div> <br class="webkit-block-placeholder">
</div>
<div>
<p class="MsoNormal">I completely disagree. We
have feature frozen months ago and we should
not allow any feature bloat now. We have
decided it and we must adhere to it. </p>
<div>
<div>
<p class="MsoNormal">It is a process and
trust issue. Also, the timing is
critical for several things that you
probably have already heard. </p>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">If it could not be
done with an extension, I would be more
sympathetic. However, in this case, you
can do it as an extension, and that is
still conformant once that extension
gets voted. The core does not prohibit
it. </p>
<div>
<div> <br
class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">And do not mix up
Google's postMessage and Form encoding
+ POSTing. </p>
</div>
<div>
<p class="MsoNormal">The fragment
encoding was supposed to be used with
postMessage and that's what Google is
doing. </p>
</div>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">Even if you had the
new feature text on Monday, there is not
enough review period. </p>
</div>
<div>
<p class="MsoNormal">Also, note that the
Monday meeting has no authority to
decide on such things. It has to be done
in the list, and we have to give ample
time to respond. </p>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">We MUST NOT push any
new feature through so quickly. </p>
</div>
</div>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal">Sorry to be a process
police here, but that's what I have to do
as a chair. </p>
</div>
</div>
<div>
<div style="margin-bottom: 12pt; "> <br
class="webkit-block-placeholder">
</div>
<div>
<p class="MsoNormal">2013/10/18 Mike Jones
<<a moz-do-not-send="true"
href="mailto:Michael.Jones@microsoft.com"
target="_blank">Michael.Jones@microsoft.com</a>></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>
<div>
<p class="MsoNormal" style=""><span
style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D">I actually think
that getting the features right,
such that developers will actually
use what’s in the spec, rather
than do something non-conformant,
is more important than a few days
of schedule.</span></p>
<div style=""><span
style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D"> </span><br
class="webkit-block-placeholder">
</div>
<p class="MsoNormal" style=""><span
style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D">It’s pretty telling
that Google, Ping, and Microsoft
all are using something other than
fragment encoding in some cases
for Implicit/Hybrid flows. Far
better to enable interop on these
non-fragment return types than
have everyone do something outside
the spec.</span></p>
<div style=""><span
style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D"> </span><br
class="webkit-block-placeholder">
</div>
<p class="MsoNormal" style=""><span
style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D">As we said on the
call, I’ll write up a concrete
proposal so people can review it
in advance of Monday.</span></p>
<div style=""><span
style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D"> </span><br
class="webkit-block-placeholder">
</div>
<p class="MsoNormal" style=""><span
style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D">Yes, we’re late in
the process, but far better to
make a late addition than to ship
something that we know has defects
that will cause people to do
things not in the spec.</span></p>
<div style=""><span
style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D"> </span><br
class="webkit-block-placeholder">
</div>
<p class="MsoNormal" style=""><span
style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D">
-- Mike</span></p>
<div style=""><span
style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D"> </span><br
class="webkit-block-placeholder">
</div>
<p class="MsoNormal" style=""><b><span
style="font-size:10.0pt;
font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;
font-family:"Tahoma","sans-serif"">
Nat Sakimura [mailto:<a
moz-do-not-send="true"
href="mailto:sakimura@gmail.com"
target="_blank">sakimura@gmail.com</a>]
<br>
<b>Sent:</b> Thursday, October 17,
2013 9:19 AM<br>
<b>To:</b> Mike Jones<br>
<b>Cc:</b> <a
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank">openid-specs-ab@lists.openid.net</a><br>
<b>Subject:</b> Re:
[Openid-specs-ab] Spec call notes
17-Oct-13</span></p>
<div>
<div>
<div style=""> <br
class="webkit-block-placeholder">
</div>
<div>
<p class="MsoNormal" style="">Please
add to the note that Nat has
pointed out that this is not
the time to add a new feature
that it can and should be
dealt with extension. </p>
<div>
<div style=""> <br
class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal" style="">Also,
John has pointed out that
expanding the feature will
cause interoperability
problems. </p>
</div>
<div>
<div style=""> <br
class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal" style="">As
part of the AOL's OpenID 2.0
provider explanation, it was
pointed out that the UI
would show flash and button,
and that was the reason we
have dropped it from the
current Connect spec. </p>
</div>
<div>
<p class="MsoNormal" style="">In
fact, not only AOL but many
others did it in OpenID 2.0
as that was the only option,
and it was also something
that many of us wanted to
escape from. </p>
</div>
<div>
<div style=""> <br
class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal" style="">The
reason sited in support of
form POSTing were as
follows: </p>
</div>
<div>
<div style=""> <br
class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal" style="">1)
It is done by SAML and WS. </p>
</div>
<div>
<p class="MsoNormal" style="">2)
Fragment would not be able
to hold large payload. </p>
</div>
<div>
<p class="MsoNormal" style="">3)
If it is not there,
implementers will do stupid
things like including access
token in the query
parameter. </p>
</div>
<div>
<p class="MsoNormal" style="">4)
If the browser is not
Javascript enabled, it is
the last resort. </p>
</div>
<div>
<div style=""> <br
class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal" style="">In
the above, 1) does not make
sense. The web technology
has advanced so much since
they were designed. We have
considered the option
previously and dropped. </p>
</div>
<div>
<p class="MsoNormal" style="">As
to 2) is concerned, the
statement is false. Fragment
can hold pretty big payload.
It was tested during the
self-issued testing, and we
found out that the limit is
actually pretty large. We
were sending photos as a
claim in id_token as a
result of it. (Note: I need
to double check - since we
were concerned mostly on
mobile platform, we may not
have tested IE.) </p>
</div>
<div>
<p class="MsoNormal" style="">The
reason 3) is not a good one
either. We should just write
an implementers NOTE that
they should never do this. </p>
</div>
<div>
<p class="MsoNormal" style="">As
a result, only the credible
reason is 4). However, this
means that a lot of other
things at the destination
site will break, too. </p>
</div>
<div>
<div style=""> <br
class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal" style="">I
understand that there are
people who want to do it. </p>
</div>
<div>
<p class="MsoNormal" style="">Even
some of NRI's internal
developers wants to do it. </p>
</div>
<div>
<p class="MsoNormal" style="">However,
that is not a good enough
reason to get it into the
core at this point in time. </p>
</div>
<div>
<p class="MsoNormal" style="">In
addition, there will be
bunch of moving parts that
we have to fix if we were to
do it. </p>
</div>
<div>
<p class="MsoNormal" style="">We
should not do it in three
days. We should take more
time to consider various
implications. </p>
</div>
<div>
<p class="MsoNormal" style="">We
are finalizing the core spec
now. The cut off date is end
of this week. </p>
</div>
<div>
<div style=""> <br
class="webkit-block-placeholder">
</div>
</div>
<div>
<p class="MsoNormal" style="">It
should be done as an
extension. I oppose to do it
in the core. </p>
</div>
<div>
<p class="MsoNormal" style="">Our
priority to get the Core out
of the door, now. </p>
</div>
<div>
<div style=""> <br
class="webkit-block-placeholder">
</div>
</div>
</div>
<div>
<div style="margin-bottom: 12pt;
"> <br
class="webkit-block-placeholder">
</div>
<div>
<p class="MsoNormal" style="">2013/10/17
Mike Jones <<a
moz-do-not-send="true"
href="mailto:Michael.Jones@microsoft.com"
target="_blank">Michael.Jones@microsoft.com</a>></p>
<div>
<div>
<p class="MsoNormal"
style="">Spec call notes
17-Oct-13</p>
<div style=""> <br
class="webkit-block-placeholder">
</div>
<p class="MsoNormal"
style="">Mike Jones</p>
<p class="MsoNormal"
style="">Brian Campbell</p>
<p class="MsoNormal"
style="">George Fletcher</p>
<p class="MsoNormal"
style="">John Bradley</p>
<p class="MsoNormal"
style="">Nat Sakimura</p>
<p class="MsoNormal"
style="">Edmund Jay</p>
<div style=""> <br
class="webkit-block-placeholder">
</div>
<p class="MsoNormal"
style="">Agenda:</p>
<p class="MsoNormal"
style="">
Open Issues</p>
<p class="MsoNormal"
style="">
Multiple response type
requests returning
values in ways other
than fragments</p>
<p class="MsoNormal"
style="">
Document Restructuring
and Review</p>
<div style=""> <br
class="webkit-block-placeholder">
</div>
<p class="MsoNormal"
style="">Open Issues:</p>
<p class="MsoNormal"
style="">
#873: session 4.1. Can
we use opbs with http
(not httponly)</p>
<p class="MsoNormal"
style="">
We developed proposed
text for this</p>
<p class="MsoNormal"
style="">
#879 & #880: Hosting
<a
moz-do-not-send="true"
href="http://self-issued.me/" target="_blank"> self-issued.me</a></p>
<p class="MsoNormal"
style="">
John will get the
cheapest Amazon VM and
give Edmund access to it</p>
<div style=""> <br
class="webkit-block-placeholder">
</div>
<p class="MsoNormal"
style="">Multiple
response type requests
returning values in ways
other than fragments</p>
<p class="MsoNormal"
style="">
Microsoft has asked for
a POST binding, like
WS-Federation and SAML
have</p>
<p class="MsoNormal"
style="">
Ping has an extra
response_type component
x_post</p>
<p class="MsoNormal"
style="">
This causes the
responses to POST to be
returned as form-encoded
body content</p>
<p class="MsoNormal"
style="">
Google has a way of
registering clients to
use a postMessage
binding</p>
<p class="MsoNormal"
style="">
They do that by
registering a JavaScript
origin, rather than
response_type</p>
<p class="MsoNormal"
style="">
AOL's OpenID 2.0
provider often uses the
POST response because of
large AX responses</p>
<p class="MsoNormal"
style="">
John had proposed a
registration parameter
for this:</p>
<p class="MsoNormal"
style="">
redirect_type fragment
| POST | postMessage</p>
<p class="MsoNormal"
style="">
This would be
discoverable as</p>
<p class="MsoNormal"
style="">
redirect_types_supported</p>
<p class="MsoNormal"
style="">
Another reason for this
is to not hit fragment
size limits</p>
<p class="MsoNormal"
style="">
Mike will file a bug on
this to make a concrete
proposal</p>
<p class="MsoNormal"
style="">
We will discuss this at
the Monday meeting</p>
<div style=""> <br
class="webkit-block-placeholder">
</div>
<p class="MsoNormal"
style="">Document
Restructuring and
Review:</p>
<p class="MsoNormal"
style="">
Mike posted a Word
version of the Core spec
with tracked changes
turned on</p>
<p class="MsoNormal"
style="">
People are requested to
mark it up with specific
proposed changes this
week</p>
</div>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt"><br>
_______________________________________________<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></p>
</div>
<p class="MsoNormal" style=""><br>
<br clear="all">
</p>
<div>
<div style=""> <br
class="webkit-block-placeholder">
</div>
</div>
<p class="MsoNormal" style="">--
<br>
Nat Sakimura (=nat)</p>
<div>
<p class="MsoNormal" style="">Chairman,
OpenID Foundation<br>
<a moz-do-not-send="true"
href="http://nat.sakimura.org/"
target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
</p>
<div>
<div> <br class="webkit-block-placeholder">
</div>
</div>
<p class="MsoNormal">-- <br>
Nat Sakimura (=nat)</p>
<div>
<p class="MsoNormal">Chairman, OpenID
Foundation<br>
<a moz-do-not-send="true"
href="http://nat.sakimura.org/"
target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</p>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" 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>
</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>