<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-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@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;}
/* 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;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.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">+1 to making clear MTI statements in the specs<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""> openid-specs-ab-bounces@lists.openid.net [mailto:openid-specs-ab-bounces@lists.openid.net]
<b>On Behalf Of </b>Nat Sakimura<br>
<b>Sent:</b> Friday, June 15, 2012 8:38 AM<br>
<b>To:</b> Brian Campbell<br>
<b>Cc:</b> openid-specs-ab@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-ab] Please respond: poll on claims_in_id_token switch in the scope<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Everything in the Standard, especially the request, needs to be understood by an IdP. <o:p></o:p></p>
<div>
<p class="MsoNormal">A parameter marked "OPTIONAL" just means that it is optional per request. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">It does not mean that it is optional for an IdP to implement. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">An IdP MUST at least understand them. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Obviously, a client can choose to implement only a subset of it, as it is the client which is making the request. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I will file a bug to define MTI clearly as a separate section. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Best, <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Nat<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, Jun 15, 2012 at 10:53 PM, Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Can you point me to the spec text that says that? I didn't see it.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
On Fri, Jun 15, 2012 at 7:50 AM, Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>> wrote:<br>
> Just one point. Support for the request object is not optional for the IdP.<br>
> It is only optional to the clients.<br>
><br>
> =nat<br>
><br>
> On Fri, Jun 15, 2012 at 6:21 AM, Brian Campbell <<a href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a>><br>
> wrote:<br>
>><br>
>> I've tried to articulate some thoughts before the call tomorrow - lots<br>
>> inline below...<br>
>><br>
>> On Thu, Jun 7, 2012 at 11:11 AM, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>> wrote:<br>
>> > Yes the request object is the general case.  We have always been able to<br>
>> > return claims in the id_token using that.<br>
>><br>
>> You and Mike have both said that the request object is the general<br>
>> case throughout this discussion. Coming from the spec authors/editors,<br>
>> that statement needs to be given its due respect. But as an<br>
>> implementer I'd like to offer a somewhat different perspective. I'm<br>
>> building OP functionality into an existing OAuth AS product so, to me,<br>
>> the general case for everything is OAuth. Things that fit nicely<br>
>> within OAuth or extend easily from it are welcome as an implementer<br>
>> while things that crosscut existing concepts or functionality are<br>
>> unwelcome and cumbersome.<br>
>><br>
>> Support for the OpenID Request Object  is an optional and, even after<br>
>> several readings of the spec, is frankly rather confusing. To me<br>
>> (again looking at it as an implementer), the Request Object is kind of<br>
>> an afterthought and something I'll try to back in support for later as<br>
>> needed and to the extent it doesn't interfere  with other<br>
>> functionality. I might be alone in this view but some other discussion<br>
>> suggest I'm not the only one - for example, 'By now we did not get<br>
>> down to the "request object"' from<br>
>><br>
>> <a href="http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120604/002030.html" target="_blank">
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120604/002030.html</a>.<br>
>><br>
>> I'm not trying to say one way or the other is right but only that<br>
>> there are different ways of looking at this which are likely informed<br>
>> by one's experience and what they're doing with this suite of specs.<br>
>><br>
>> > The simple thing is to say that if you want claims in the id_token use<br>
>> > the<br>
>> > request object.   No new response types required.<br>
>> ><br>
>> > The question at the meeting was how do we do it without a request object<br>
>> > being required.<br>
>><br>
>> I'm starting to wonder if we even need a shorthand way to request claims<br>
>> in<br>
>> the id token. In many of the cases it seems like it is something that<br>
>> is ultimately up to the IdP/OP. Was not the impetus for this the so<br>
>> called 'self issued' OP on a phone that couldn't have a user info<br>
>> endpoint? In that case, does the client really need to request that<br>
>> the claims be returned in the id token? The AS can't do anything else<br>
>> with them (other than omit them, I guess).<br>
>><br>
>> > I am against adding a new response type because there is no new<br>
>> > response.<br>
>><br>
>> Agree.<br>
>><br>
>> > If anything they are new scopes because they are returning the info from<br>
>> > a<br>
>> > new endpoint.<br>
>><br>
>> I'm not sure I agree there. I guess it depends on how you interpret or<br>
>> define the scopes and, admittedly, that is left pretty open ended by<br>
>> the OAuth Framework. But I think about scopes as making more sense as<br>
>> being something an end user grants access to rather than about how<br>
>> that access might be exercised.  If, as an end user, I approve access<br>
>> to my profile information, I don't really care how the client access<br>
>> it (as long as it's not irresponsible).<br>
>><br>
>> > Having a scope that modifies other scopes endpoints works, but has been<br>
>> > pointed out as awkward to program.<br>
>> ><br>
>> > A new OAuth parameter just for this also seems a bit overkill.<br>
>><br>
>> From my perspective this seems like the simplest way to deal with it.<br>
>><br>
>> This text could be added near the bottom of Messages §2.1.2<br>
>><br>
>> claims_in_id_token<br>
>>    OPTIONAL. If this parameter is present and its value is true, the<br>
>> client is requesting that the voluntary claims requested with the<br>
>> profile, email, address, and phone scope values are returned in the ID<br>
>> Token, rather than from the UserInfo Endpoint. The default is false.<br>
>><br>
>> And then add the following boilerplate text to Standard (BTW, is there<br>
>> a reason all these parameter are defined in one spec but registered in<br>
>> a different one?).<br>
>><br>
>> 9.1.X.  Authorization Request Parameter (claims_in_id_token)<br>
>><br>
>> The following is a parameter registration request for the<br>
>> Authorization Request in this specification:<br>
>><br>
>>    Parameter name: claims_in_id_token<br>
>>    Parameter usage location: Authorization Request<br>
>>    Change controller: IETF<br>
>>    Specification document(s): [[ this document ]]<br>
>>    Related information: None<br>
>><br>
>><br>
>> > So the options in preference from my perspective are:<br>
>> ><br>
>> > 1)  New scopes specific to delivering the claims in the id_token.<br>
>> > 2)  Scope that modifies the existing scopes (profile, email, address,<br>
>> > phone)<br>
>> > As we have it now.<br>
>> > 3)  Clients must user the request object to get claims in the id_token.<br>
>> ><br>
>> > This is a convenience for Self Issued and other IdP who don't want to<br>
>> > support the extra round trip.<br>
>><br>
>> Again, if it's really for the IdP, do we need a shorthand way for the<br>
>> client to request it?<br>
>><br>
>> > I don't want to complicate the common case by adding more OAuth<br>
>> > parameters<br>
>> > or return types we have enough.<br>
>><br>
>> An optional parameter with a default that behaves as it already does<br>
>> when omitted seems like the simplest and least complicated.<br>
>><br>
>> > John B.<br>
>> ><br>
>> > On 2012-06-07, at 11:36 AM, Mike Jones wrote:<br>
>> ><br>
>> > I have to respectfully disagree with your statement than an ID Token<br>
>> > with<br>
>> > claims is a different kind of token from one which doesn’t include<br>
>> > them.  I<br>
>> > believe that looking at the general case, which is using the OpenID<br>
>> > Request<br>
>> > Object, will help illustrate why I believe that this is the case.<br>
>> ><br>
>> > Both the ID Token and the UserInfo endpoint return claims.  There are<br>
>> > sections of the OpenID Request Object for requesting claims for each<br>
>> > location.  For instance, the following request object body requests that<br>
>> > the<br>
>> > “email” and “email_verified” claims be returned in both locations:<br>
>> ><br>
>> > {“id_token”:{<br>
>> >     “claims”:<br>
>> >         {“email”: null},<br>
>> >          “email_verified”: null}),<br>
>> > “userinfo”:{<br>
>> >     “claims”:<br>
>> >         {“email”: null,<br>
>> >          “email_verified”: null }}<br>
>> > }<br>
>> ><br>
>> > Whether the “email” and “email_verified” claims are present in the ID<br>
>> > Token<br>
>> > doesn’t make it a different kind of token.  It just changes the claims<br>
>> > present in the ID Token.  One thing that becomes apparent when<br>
>> > considering<br>
>> > things in this manner is that no new response types are needed to return<br>
>> > requested claims in the ID token.<br>
>> ><br>
>> > I think it would be useful for people to first work out their request<br>
>> > examples as OpenID Request Objects and *then* consider what shorthands<br>
>> > we<br>
>> > want to have to achieve those same things for simple cases without using<br>
>> > an<br>
>> > OpenID Request Object (if any).  The Request Object is the general case,<br>
>> > and<br>
>> > the architecture should derive from it.  Anything expressible in the<br>
>> > shorthand syntax must also be (naturally) expressible in the general<br>
>> > form.<br>
>> ><br>
>> >                                                             -- Mike<br>
>> ><br>
>> ><br>
>> > From: matake, nov [mailto:<a href="mailto:nov@matake.jp">nov@matake.jp</a>]<br>
>> > Sent: Thursday, June 07, 2012 2:17 AM<br>
>> > To: Nat Sakimura<br>
>> > Cc: Mike Jones; <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
>> > Subject: Re: [Openid-specs-ab] Please respond: poll on<br>
>> > claims_in_id_token<br>
>> > switch in the scope<br>
>> ><br>
>> > Forgive me sending more in this ML.<br>
>> ><br>
>> >> Mike<br>
>> > I feel id_token which includes userinfo is different kind of token from<br>
>> > which doesn't include it.<br>
>> ><br>
>> >> Nat<br>
>> > I prefer<br>
>> > 1. b)<br>
>> > 2. a)<br>
>> > 3. a)<br>
>> ><br>
>> > If we define new response_type, what we need is defining new 4 patterns<br>
>> > listed below.<br>
>> > From a ruby openid-connect library developer's view, those 4 is not so<br>
>> > complicated.<br>
>> ><br>
>> > ===<br>
>> > # Current defined response types<br>
>> > code<br>
>> > token<br>
>> > id_token<br>
>> > code id_token<br>
>> > id_token token<br>
>> > code id_token token<br>
>> ><br>
>> > # New response types<br>
>> > id_token_with_claims<br>
>> > code id_token_with_claims<br>
>> > id_token_with_claims token<br>
>> > code id_token_with_claims token<br>
>> ><br>
>> > # Not defined<br>
>> > id_token id_token_with_claims<br>
>> > code id_token id_token_with_claims<br>
>> > id_token id_token_with_claims token<br>
>> >  :<br>
>> > ===<br>
>> ><br>
>> > I don't think defining separate "userinfo" response_type introduces more<br>
>> > patterns (aka flexibility?) listed here.<br>
>> > At least I don't know any use-case except for ones listed above.<br>
>> > (ie. "userinfo token", which will require returning userinfo token<br>
>> > separated<br>
>> > from id_token)<br>
>> ><br>
>> > ps.<br>
>> > If we have call, I'll join.<br>
>> > Both early morning and night (after 10pm) in JST works for me.<br>
>> ><br>
>> > 2012/6/7 Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>><br>
>> > OK. I seemed to have screwed up the list of options etc.<br>
>> ><br>
>> > Also, as the list is terse and it did not include the precise definition<br>
>> > of<br>
>> > each terms, it led to people talking about different things using the<br>
>> > same<br>
>> > word. This is another screwing up on my part.<br>
>> ><br>
>> > Rather than doing it through mailing list poll, it probably is better to<br>
>> > have a call on this issue in a very near future at a time where European<br>
>> > participants can also call in, e.g., 11pm JST, 4pm CDT (EU), 10am EDT,<br>
>> > 7am<br>
>> > PDT. That will let people speak up, explain the meaning, etc. and a<br>
>> > whole<br>
>> > lot more constructive. Perhaps we should do a doodle poll on the timing.<br>
>> ><br>
>> > Nat<br>
>> ><br>
>> > On Thu, Jun 7, 2012 at 4:42 PM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>><br>
>> > wrote:<br>
>> > This list left out the possibility that John discussed of having<br>
>> > separate<br>
>> > scope request values such as email_id that specifically request that<br>
>> > sets of<br>
>> > scope values be included in the ID Token.  (I'm not necessarily in favor<br>
>> > of<br>
>> > this, but it was discussed at Yahoo and on the list, so should be part<br>
>> > of<br>
>> > what people react to.)<br>
>> ><br>
>> > This list left out the suggest of Brian's that a different request<br>
>> > parameter<br>
>> > be defined to act as the switch that the profile, email, address, and<br>
>> > phone<br>
>> > scope values return claims in the ID Token, rather than the switch being<br>
>> > the<br>
>> > claims_in_id_token scope.  If we're reconsidering all options, this one<br>
>> > shouldn't be excluded.<br>
>> ><br>
>> > I don't think there had been any discussion on the list to date since<br>
>> > the<br>
>> > decisions at Yahoo proposing your option 1b (using a different response<br>
>> > type).  I've heard people discussing *how* claims should be directed to<br>
>> > the<br>
>> > ID Token - not *whether* they should be.  I hope we don't try to reopen<br>
>> > that<br>
>> > part of the decision as well, especially because no one has proposed<br>
>> > reopening it.  As such, I don't believe that it's productive to discuss<br>
>> > 1b,<br>
>> > 2, or 3b, given that no one has suggested that they are dissatisfied<br>
>> > with<br>
>> > the option to return claims in the ID token - only the syntax for saying<br>
>> > to<br>
>> > do it.<br>
>> ><br>
>> > My two cents worth...<br>
>> ><br>
>> >                                -- Mike<br>
>> ><br>
>> ><br>
>> > -----Original Message-----<br>
>> ><br>
>> > From: <a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a> [mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>]<br>
>> > On Behalf Of Nat Sakimura<br>
>> > Sent: Wednesday, June 06, 2012 11:57 PM<br>
>> > To: Roland Hedberg<br>
>> > Cc: <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
>> > Subject: [Openid-specs-ab] Please respond: poll on claims_in_id_token<br>
>> > switch<br>
>> > in the scope<br>
>> ><br>
>> > I would like to take this issue to a closure quickly.<br>
>> > These issues were discussed at F2F on May 1.<br>
>> > However, that was only among the f2f participant.<br>
>> > I understand the current comments are from those who were not at F2F,<br>
>> > and<br>
>> > implementers' comments from those implementing it.<br>
>> > I would appreciate a quick response to the following questions so to sum<br>
>> > up<br>
>> > a bit to help the progress in this issue:<br>
>> ><br>
>> > 1. Please indicate which is your preferred way.<br>
>> ><br>
>> >    a) Using claims_in_id_token switch in the "scope"<br>
>> >    b) Using a new response type.<br>
>> ><br>
>> >    Note: on May 1 F2F, 1-a) was chosen. This is how the current draft<br>
>> > was<br>
>> > prepared. (cf. issue #561)<br>
>> ><br>
>> > 2. If 1-b) is chosen, which do you prefer:<br>
>> ><br>
>> >    a) A combined response type: e.g., id_token_with_userinfo<br>
>> >    b) combination of id_token and userinfo<br>
>> ><br>
>> > 3. As a method for returning userinfo claims in the front channel, which<br>
>> > do<br>
>> > you prefer?<br>
>> ><br>
>> >     a) Claims in id_token<br>
>> >     b) separate userinfo token with its metadata in id_token?<br>
>> ><br>
>> >     Note: At the F2F, a) was chosen.<br>
>> ><br>
>> > Thanks for your cooperation.<br>
>> ><br>
>> > Nat Sakimura<br>
>> ><br>
>> > On 2012/06/07, at 15:29, Roland Hedberg <<a href="mailto:roland.hedberg@adm.umu.se">roland.hedberg@adm.umu.se</a>><br>
>> > wrote:<br>
>> ><br>
>> >><br>
>> >> 7 jun 2012 kl. 07:40 skrev nov matake:<br>
>> >><br>
>> >>> I'm OK with both making single "id_token_with_userinfo" response type<br>
>> >>> or<br>
>> >>> combination of "id_token" and "userinfo".<br>
>> >><br>
>> >><br>
>> >> I'm definitely in favor of the later.<br>
>> >> That is letting 'id_token' contain metadata about the userinfo and the<br>
>> >> authentication, and 'userinfo' pure user info.<br>
>> >> Similar to the structure of the openid request object.<br>
>> >><br>
>> >> -- Roland<br>
>> >> ------------------------------------------------------<br>
>> >> Roland Hedberg<br>
>> >> IT Architect/Senior Researcher<br>
>> >> ICT Services and System Development (ITS) Umeċ University<br>
>> >> SE-901 87 Umeċ, Sweden<br>
>> >> Phone <a href="tel:%2B46%2090%20786%2068%2044">+46 90 786 68 44</a><br>
>> >> Mobile <a href="tel:%2B46%2070%20696%2068%2044">+46 70 696 68 44</a><br>
>> >> <a href="http://www.its.umu.se" target="_blank">www.its.umu.se</a><br>
>> >><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><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><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Nat Sakimura (=nat)<br>
>> > Chairman, OpenID Foundation<br>
>> > <a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
>> > @_nat_en<br>
>> ><br>
>> ><br>
>> ><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><br>
>> ><br>
>> ><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><br>
>> ><br>
>> ><br>
>> ><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><br>
>> ><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><br>
><br>
><br>
><br>
><br>
> --<br>
> Nat Sakimura (=nat)<br>
> Chairman, OpenID Foundation<br>
> <a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
> @_nat_en<br>
><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
Nat Sakimura (=nat)<o:p></o:p></p>
<div>
<p class="MsoNormal">Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>