<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-2022-jp">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"MS Mincho";
        panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
        {font-family:SimSun;
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
        {font-family:SimSun;
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Verdana;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:"\@MS Mincho";
        panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
        {font-family:"\@SimSun";
        panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:SimSun;
        mso-fareast-language:ZH-CN;}
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;}
samp
        {mso-style-priority:99;
        font-family:SimSun;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";
        mso-fareast-language:ZH-CN;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";
        mso-fareast-language:ZH-CN;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The agreed upon fix to this is now checked in.  I$B!G(Bll just note for the record that, despite us talking about an id_token_hint parameter to the login initiation
 endpoint request, we did not define the use of id_token_hint there – only login_hint.  Given our intention to define passing an ID Token in an extension, this is probably fine, but I wanted to make sure people were aware of the current text in the spec.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">                                                            -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><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""> Brian Campbell [mailto:bcampbell@pingidentity.com]
<br>
<b>Sent:</b> Monday, December 02, 2013 1:00 PM<br>
<b>To:</b> Mike Jones<br>
<b>Cc:</b> John Bradley; Nat Sakimura; Openid-specs Ab<br>
<b>Subject:</b> Re: [Openid-specs-ab] Login Initiation endpoint.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">IdP initiated SSO via the POST binding is arguably one of the most successful aspects of SAML and there's not an obviously analogous thing in Connect, which I do believe will be a point of friction in migration
 and adoption. With that in mind, I agree with Mike that's worth discussing. However, it is a pretty significant change (technically and philosophically) to be considering given the goal of going final early next year.<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Sending it via an (auto) form post rather than a redirect keeps the token out of the URL, which prevents the token from leaking to other sites via the referer [sic] header. The post body is also logged in a
 lot fewer places where the query string often ends up in request logs and browser history and other places you don't want a credential to end up. There are probably other reasons not to pass a token in the URL but those two come to mind first.<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">The question about id_token_hint in the query string is a good one. It's probably not a great idea to pass it that way but I *think* that proper nonce checking would prevent using an id token leaked via id_token_hint
 from being used to by an attacker to sign in and create a session. The general question probably deserves some more discussions though. If the login initiation endpoint accepted an id_token directly to create a session, however, the protections the nonce gives
 don't apply and, in some cases, a leaked id_token_hint could likely be used maliciously.
<o:p></o:p></p>
</div>
<p class="MsoNormal">Honestly, I've never really understood the CSRF issue with login. What is the concern? That some other CSRF vulnerable action will be taken after the session is created via CSRF login? Or is it something more fundamental? How do IDPs typically
 prevent CSRF'd SSO? Or do they? <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, Nov 26, 2013 at 5:25 PM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I$B!G(Bd like this to be a topic on Monday$B!G(Bs call.  I understand people$B!G(Bs initial reaction against making
 additions now, but I think this at least deserves serious discussion, because the feature request is driven by developers actually deploying the protocol and trying to migrate from SAML.  It$B!G(Bs not a whimsical made-up feature or coming from out of the blue. 
 Not having this could be a perceived deployment blocker relative to SAML.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">John, in the meantime, can you please speak to why CSRF is not a problem when the proposed parameter
 is used?</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Also, can you speak to why you want the parameter passing mechanism to be form post?  Even if we
 don$B!G(Bt add the id_token parameter, does the current id_token_hint parameter need to be sent via form post rather than as a query parameter?  If this is true, why is it ok to pass the id_token_hint value to the authorization endpoint as a query parameter?  (Or
 is it actually not OK?)</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">                                                                -- Mike</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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"">
<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a> [mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>John Bradley<br>
<b>Sent:</b> Tuesday, November 26, 2013 5:15 AM<br>
<b>To:</b> Nat Sakimura<br>
<b>Cc:</b> Openid-specs Ab<br>
<b>Subject:</b> Re: [Openid-specs-ab] Login Initiation endpoint.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">SAML relies on the IdP to prevent CSRF as the login session starts at the IdP.  The RP/SP knows that it is idP initiated.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">This is a common pattern in SSO where the user is redirected to another related site with a SAML assertion that the recipient RP uses to establish a new session with the user.   <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">This is much safer then trying to use cross domain cookies which is the other common tactic.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I was looking at George's proposal to bootstrap a web session from a native app. He had to invent a new endpoint and special access token to do it as there was no way to accomplish
 it with the current endpoint.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I am OK with saying that it is a bootstrap id_token hint and can't directly be used by the client.   However there are a bunch of things that can't be done as the IdP/AS can't pass
 any state to itself through the request.   Allowing a bootstrap id_token to be sent and returned in the authorization request as the id_token_hint is the simplest way to send signed state.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The important thing I missed in the proposal was sending it as a form-post body to prevent leaking the id_token in referrer.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">If we wan't to leave this for an extension we should at least say the login initiation endpoint can take a form POST so later extensions are easier.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">John B.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Nov 26, 2013, at 4:39 AM, Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">+1<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I wonder how these SAML implementations are dealing with CSRF. <br>
<br>
=nat via iPhone<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><br>
Nov 26, 2013 3:03<span lang="ZH-CN" style="font-family:"MS Mincho"">$B!"(B</span>"Richer, Justin P." <<a href="mailto:jricher@mitre.org" target="_blank">jricher@mitre.org</a>>
<span lang="ZH-CN" style="font-family:"MS Mincho"">$B$N%a%C%;!<%8(B</span>:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I really don't like this. It goes against the structure of how OAuth works, and there's no way for the RP to put anything into the id token (like nonce, state, etc.) to bind to
 a particular session and prevent a stolen id token being used to log in directly by another user. The fact that the RP starts the auth conversation is important, and I'm not at all comfortable with having this workaround. 
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">At the very least, this should be proposed as an extension and get hammered out separately. (But even then I don't think it has legs.)<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> -- Justin<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Nov 25, 2013, at 10:58 AM, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">For Core Section 3 I would like to add the following optional parameter to the login initiation endpoint.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-top:6.0pt;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Verdana","sans-serif"">id_token</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Verdana","sans-serif"">OPTIONAL. If the initiator is the iss then it may include an initial id_token.  The value of exp SHOULD be set to a small value in the range of 5 minutes. </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Verdana","sans-serif"">The id_token must contain a valid aud restricting it to the client receiving it.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Verdana","sans-serif"">If the client receives a value for this string-valued parameter, it MUST include it in the subsequent authorization request as the id_token</span><samp><span style="font-size:10.0pt">_hint</span></samp><span style="font-size:10.0pt;font-family:"Verdana","sans-serif""> parameter
 value.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Verdana","sans-serif""> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Verdana","sans-serif""> </span><o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Verdana","sans-serif"">I have been getting push back from people looking to convert from SAML that Connect forces many more round trips than SAML for doing IdP initiated login.  </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Verdana","sans-serif"">Sending an initial short lived id_token lets the client do the quick customization of the UI that the id_token was intended to enable while allowing the client to get access tokens and a new
 id_token in the background using prompt=none.  </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Verdana","sans-serif""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Verdana","sans-serif"">This also reduces the eventual pressure to add more parameters to the endpoint as the AS can tack on additional claims it needs to maintain state.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Verdana","sans-serif""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Verdana","sans-serif"">I think we did have the id_token as a parameter at wine point then changed it to the login_hint when that was added to make it more general.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Verdana","sans-serif""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Verdana","sans-serif"">I know this is a late addition request.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Verdana","sans-serif""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:24.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Verdana","sans-serif"">John B.</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p>
</blockquote>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<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" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>