<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Could you give me a concrete text so that I will be able to understand your point exactly. </div><div><br>Nat</div>
<div><br>On Jul 29, 2013, at 10:29, Anthony Nadalin <<a href="mailto:tonynad@microsoft.com">tonynad@microsoft.com</a>> wrote:<br><br></div><div><span></span></div><blockquote type="cite"><div>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@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;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 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
        {mso-style-priority:99;
        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";}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.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>


<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Not in our case as our auth server serves many tenants and each tenant has many apps each app with different scopes, different revocation, etc, server is not
 very granular </span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></a></p>
<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""> Torsten Lodderstedt [<a href="mailto:torsten@lodderstedt.net">mailto:torsten@lodderstedt.net</a>]
<br>
<b>Sent:</b> Monday, July 29, 2013 1:19 AM<br>
<b>To:</b> Anthony Nadalin<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] Transient Client Secret Extension for OAuth</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p>Based on our experiences I would state, this data is the same across apps as this is server meta data.</p>
<p>Am 29.07.2013 10:13, schrieb Anthony Nadalin:</p>
<blockquote style="border:none;border-left:solid #1010ff 1.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">A single authorization server can support thousands of apps, so a config file is very problematic
 if not per  app and per app is very data intensive. The other point is exposing information gives attack points and to prevent those we have to get into authorization and seems we would repeat all the xri/xrd
</span></p>
<p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style><strong><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></strong><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> Torsten Lodderstedt
 [<a href="mailto:torsten@lodderstedt.net">mailto:torsten@lodderstedt.net</a>] <br>
<strong><span style="font-family:"Calibri","sans-serif"">Sent:</span></strong> Monday, July 29, 2013 1:08 AM<br>
<strong><span style="font-family:"Calibri","sans-serif"">To:</span></strong> Anthony Nadalin<br>
<strong><span style="font-family:"Calibri","sans-serif"">Cc:</span></strong> <a href="mailto:openid-specs-ab@lists.openid.net">
openid-specs-ab@lists.openid.net</a><br>
<strong><span style="font-family:"Calibri","sans-serif"">Subject:</span></strong> RE: [Openid-specs-ab] Transient Client Secret Extension for OAuth</span></p>
</div>
</div>
<p class="MsoNormal" style> </p>
<p>Can you give an example?</p>
<p>Am 29.07.2013 10:03, schrieb Anthony Nadalin:</p>
<blockquote style="border:none;border-left:solid #1010ff 1.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I think this gets us in a bind with information exposure, as this all can be very app dependent and
 not authorization server general</span></p>
<p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style><strong><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></strong><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">
<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a> [<a href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto:openid-specs-ab-bounces@lists.openid.net</a>]
<strong><span style="font-family:"Calibri","sans-serif"">On Behalf Of </span></strong>Torsten Lodderstedt<br>
<strong><span style="font-family:"Calibri","sans-serif"">Sent:</span></strong> Monday, July 29, 2013 12:58 AM<br>
<strong><span style="font-family:"Calibri","sans-serif"">To:</span></strong> <a href="mailto:openid-specs-ab@lists.openid.net">
openid-specs-ab@lists.openid.net</a><br>
<strong><span style="font-family:"Calibri","sans-serif"">Subject:</span></strong> Re: [Openid-specs-ab] Transient Client Secret Extension for OAuth</span></p>
</div>
</div>
<p class="MsoNormal" style> </p>
<p>Hi all,</p>
<p>I think OAuth authorization servers need a way to announce their capabilities (e.g. grant types, dyn client reg, revocation, support for tcse :-)) and respective endpoints. Using a config file at a well-known location</p>

<pre>/.well-known/oauth-configuration</pre>
<p>seems straightforward. For authorization servers, which are also OIDC OPs, the same (or a different) file might be exposed at</p>
<p>/.well-known/openid-configuration.</p>
<p>Thoughts?</p>
<p>regards,<br>
Torsten.</p>
<p>Am 29.07.2013 09:45, schrieb Nat Sakimura:</p>
<blockquote style="border:none;border-left:solid #1010ff 1.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style>Hmmm. Then, the client has lost its capability to find out whether the server is secure or not dynamically. 
</p>
<div>
<p class="MsoNormal" style>Do you mean that the client should find it out out-of-band? </p>
</div>
<div>
<p class="MsoNormal" style>That's possible, and is more OAuthy. </p>
</div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>So, instead of current 3.2, it can just state : </p>
</div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>The client MUST find out if the server supports this mode before issuing the authorizaiton request. The exact method of how it can be done is out of scope. </p>
</div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>Is that what you mean? </p>
</div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>Nat</p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
<div>
<p class="MsoNormal" style>2013/7/29 Brian Campbell <<a href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a>></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style>Pretty much just removing 3.1 and 3.2 and 2.2 from your draft.</p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
<div>
<p class="MsoNormal" style>On Mon, Jul 29, 2013 at 9:36 AM, Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>> wrote:</p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style>Yup. It is too late. The client needs to know whether the server is secure or not to start with. 
</p>
<div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>> <span style="font-size:13.5pt;font-family:"Arial","sans-serif"">I still think that a base definition of this shouldn't try and address discovering or publishing support for the
 functionality.</span></p>
</div>
<div>
<p class="MsoNormal" style><span style="font-size:13.5pt;font-family:"Arial","sans-serif""> </span></p>
</div>
</div>
<div>
<p class="MsoNormal" style><span style="font-size:13.5pt;font-family:"Arial","sans-serif"">Could you kindly propose a concrete method? A concrete text would be even better. </span></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
<div>
<p class="MsoNormal" style>2013/7/29 Brian Campbell <<a href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a>></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">As John pointed out, putting metainfo about support into the token response is too late in the flow.</p>
</div>
<p class="MsoNormal" style>I still think that a base definition of this shouldn't try and address discovering or publishing support for the functionality.</p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
<div>
<p class="MsoNormal" style>On Mon, Jul 29, 2013 at 9:28 AM, Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>> wrote:</p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style>OK. Fair enough. 
</p>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>I will change it to the invalid_grant. </p>
</div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>What do you think about the idea for "meta"? </p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
<div>
<p class="MsoNormal" style>2013/7/29 Brian Campbell <<a href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a>></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style>It's really not client authentication. It's something that links the initial authorization request with the corresponding access token request, which enables detecting a particular
 problem/attack. Similar to a mismatch on the redirect URI value between the authorization request and the corresponding access token request, it's the grant (or transaction) that is invalid.</p>
<div>
<div>
<p class="MsoNormal" style> </p>
<pre><a href="http://tools.ietf.org/html/rfc6749#section-5.2">http://tools.ietf.org/html/rfc6749#section-5.2</a><br><br>           invalid_grant</pre>
<pre>               The provided authorization grant (e.g., authorization</pre>
<pre>               code, resource owner credentials) or refresh token is</pre>
<pre>               invalid, expired, revoked, does not match the redirection</pre>
<pre>               URI used in the authorization request, or was issued to</pre>
<pre style="margin-bottom:12.0pt">               another client. </pre>
<p class="MsoNormal" style>Discovery is maybe useful but is definitely not necessary. What is necessary is to define the parameter(s) and their treatment on the authorization request and access token request
 so that clients and servers can interop.  </p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
<div>
<p class="MsoNormal" style>On Mon, Jul 29, 2013 at 9:07 AM, Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>> wrote:<br>
<br>
<br>
<br>
</p>
<blockquote style="margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style>Hi Brian,
</p>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>inline: </p>
<div>
<p class="MsoNormal" style> </p>
<div>
<div>
<p class="MsoNormal" style>2013/7/29 Brian Campbell <<a href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a>><br>
<br>
<br>
<br>
</p>
<blockquote style="margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style>IMHO, invalid_grant is the proper error response code, not invalid_client.
</p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style> </p>
</div>
</div>
<div>
<p class="MsoNormal" style>I have thought a bit about that when I was writing it down. </p>
</div>
<div>
<p class="MsoNormal" style>invalid_grant is concerned about the token which has been previously issued. </p>
</div>
<div>
<p class="MsoNormal" style>invalid_client is concerned about the client authentication. </p>
</div>
<div>
<p class="MsoNormal" style>In the initial path, I had it as invalid_grant, then, I thought - well, it is the client </p>
</div>
<div>
<p class="MsoNormal" style>authentication that is failing when the client has provided invalid tcs. </p>
</div>
<div>
<p class="MsoNormal" style>The code is correct. It is the client authentication which is going wrong, is it not?</p>
</div>
<div>
<div>
<p class="MsoNormal" style> </p>
</div>
<blockquote style="margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-left:rgb">
<div>
<div>
<p class="MsoNormal" style><br>
Along the same lines, I'd like to see it named something more like "message correlation id" rather than anything involving client secret.</p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style> </p>
</div>
</div>
<div>
<p class="MsoNormal" style>The name "message correlation identifier" does not convey the nature of the parameter, which is the high entropy credential for the client. Just for the sake of the correlation,
 it does not have to have a high entropy. Thus, I have chosen the name. </p>
</div>
<div>
<div>
<p class="MsoNormal" style> </p>
</div>
<blockquote style="margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-left:rgb">
<div>
<div>
<p class="MsoNormal" style> </p>
</div>
<p class="MsoNormal" style>This is a general OAuth problem and I believe the solution should be general too. Thus, at least the base definition of the parameter(s) should not require discovery or rely on
 any of the Connect documents.</p>
</div>
</blockquote>
<div>
<p class="MsoNormal" style> </p>
</div>
</div>
<div>
<p class="MsoNormal" style>OAuth generally does not need discovery. However, this spec really needs it, at least in one form or another. </p>
</div>
<div>
<p class="MsoNormal" style>I have thought of making a new file but then that would amount to having the client hit those discovery endpoints twice. </p>
</div>
<div>
<p class="MsoNormal" style>I did not want the duplicate situation that resulted in the dynamic client registration. That's why I am referring OpenID Connect. </p>
</div>
<div>
<p class="MsoNormal" style>OpenID Connect originated the Discovery and Registration. On the hind site, even registration should have been referring OpenID Connect documents instead of duplicating. At least,
 that's how academic papers work :-)</p>
</div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>Another idea is to have the metadata come back in the token response. </p>
</div>
<div>
<p class="MsoNormal" style>I actually prefer this. It increases the server traffic a bit, though. </p>
</div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>The way it works is this. </p>
</div>
<div>
<p class="MsoNormal" style>Instead of doing the discovery and caching it at the client, the client finds the server capability from the token endpoint reference. For this, the server includes something like: </p>
</div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>"meta": {</p>
</div>
<div>
<p class="MsoNormal" style>   "tcs_supported":true;</p>
</div>
<div>
<p class="MsoNormal" style>}</p>
</div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>You guys know that I like this idea because then I would have a stub to put link relationship there as well. </p>
</div>
<div>
<p class="MsoNormal" style>Do you like the idea? If so, I can update the draft in this manner. </p>
</div>
<div>
<p class="MsoNormal" style>Well, perhaps I should anyways. </p>
</div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>Thanks for pointing out. </p>
</div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>Best, </p>
</div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>Nat</p>
</div>
<div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style> </p>
</div>
<blockquote style="margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-left:rgb">
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
<div>
<div>
<div>
<p class="MsoNormal" style>On Sun, Jul 28, 2013 at 9:39 PM, Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>> wrote:</p>
</div>
</div>
<blockquote style="margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-left:rgb">
<div>
<div>
<div>
<p class="MsoNormal" style>As some of you knows, passing the code securely to a native app on iOS platform is next to impossible. Malicious application may register the same custom scheme as the victim application
 and hope to obtain the code, whose success rate is rather high.  </p>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>We have discussed about it during the OpenID Conenct Meeting at IETF 87 today, and I have captured the discussion in the form of I-D. It is pretty short and hopefully easy to read. </p>
</div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>You can find it at: </p>
</div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style><a href="https://bitbucket.org/Nat/drafts/src/">https://bitbucket.org/Nat/drafts/src/</a></p>
</div>
<div>
<p class="MsoNormal" style> </p>
</div>
<div>
<p class="MsoNormal" style>Comments are welcome. </p>
</div>
<div>
<div>
<p class="MsoNormal" style> </p>
</div>
<p class="MsoNormal" style>--
<br>
Nat Sakimura (=nat) </p>
<div>
<p class="MsoNormal" style>Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/">http://nat.sakimura.org/</a><br>
@_nat_en</p>
</div>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">_______________________________________________<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></p>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
<div>
<p class="MsoNormal" style><br>
<br clear="all">
</p>
<div>
<p class="MsoNormal" style> </p>
</div>
<p class="MsoNormal" style>--
<br>
Nat Sakimura (=nat) </p>
<div>
<p class="MsoNormal" style>Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/">http://nat.sakimura.org/</a><br>
@_nat_en</p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style><br>
<br clear="all">
</p>
<div>
<p class="MsoNormal" style> </p>
</div>
<p class="MsoNormal" style>--
<br>
Nat Sakimura (=nat) </p>
<div>
<p class="MsoNormal" style>Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/">http://nat.sakimura.org/</a><br>
@_nat_en</p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style><br>
<br clear="all">
</p>
<div>
<p class="MsoNormal" style> </p>
</div>
<p class="MsoNormal" style>--
<br>
Nat Sakimura (=nat) </p>
<div>
<p class="MsoNormal" style>Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/">http://nat.sakimura.org/</a><br>
@_nat_en</p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style><br>
<br clear="all">
</p>
<div>
<p class="MsoNormal" style> </p>
</div>
<p class="MsoNormal" style>--
<br>
Nat Sakimura (=nat) </p>
<div>
<p class="MsoNormal" style>Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/">http://nat.sakimura.org/</a><br>
@_nat_en</p>
</div>
</div>
<p class="MsoNormal" style> </p>
<pre>_______________________________________________</pre>
<pre>Openid-specs-ab mailing list</pre>
<pre><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></pre>
<pre><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></pre>
</blockquote>
<div>
<p class="MsoNormal" style> </p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style> </p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
</div>


</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Openid-specs-ab mailing list</span><br><span><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></span><br>
<span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br></div></blockquote></body></html>