<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=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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;}
p
{mso-style-priority:99;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
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";}
p.msochpdefault, li.msochpdefault, div.msochpdefault
{mso-style-name:msochpdefault;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Calibri","sans-serif";}
span.emailstyle17
{mso-style-name:emailstyle17;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle20
{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";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
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">There’s no sneaking going on here, any more than there was to add “token_endpoint_auth_signing_alg” for issue #875 (which I know you were in favor of, even
though it was also a late addition).<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">There’s no mystery why this came up now. As discussed on Monday’s and today’s calls, during interop testing with Microsoft’s current implementation, we discovered
that the developers were returning the ID Token as a query parameter when using the “code id_token” flow, because it’s easier for relying parties to code to than having to write JavaScript to handle the fragment and post the result back to an internal site.
In response, we changed Multiple Response Types earlier this week to explicitly prohibit this and communicated that back to the team here. They asked for a POST binding instead, because it’s also easier than the fragment handling, and because they already
have code to handle this for both SAML and WS-Federation. It was odd to them that we didn’t have this alternative in OpenID Connect (which we do in OpenID 2.0, by the way).<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">At first I pushed back, but when I realized that Ping also already had this feature and that Google isn’t using the fragment encoding either, I started to agree
that this made sense. So I brought it up on the call and agreed to write up proposed text.<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">Nothing Machiavellian going on, any more than there was with #875. Hopefully you’ll review the proposed text when it comes out. I think you’ll find that it’s
pretty straightforward. (If it wasn’t straightforward, I wouldn’t be advocating it.)<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>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<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""> Richer, Justin P. [mailto:jricher@mitre.org]
<br>
<b>Sent:</b> Thursday, October 17, 2013 1:38 PM<br>
<b>To:</b> Anthony Nadalin; Nat Sakimura; Mike Jones<br>
<b>Cc:</b> openid-specs-ab@lists.openid.net<br>
<b>Subject:</b> RE: [Openid-specs-ab] Spec call notes 17-Oct-13<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">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<o:p></o:p></span></p>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><span style="color:black">
<hr size="3" width="100%" align="center">
</span></div>
<div id="divRpF193203">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">
<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a> [openid-specs-ab-bounces@lists.openid.net] on behalf of Anthony Nadalin [tonynad@microsoft.com]<br>
<b>Sent:</b> Thursday, October 17, 2013 2:04 PM<br>
<b>To:</b> Nat Sakimura; Mike Jones<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] Spec call notes 17-Oct-13</span><span style="color:black"><o:p></o:p></span></p>
</div>
<div>
<div>
<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><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span></a><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">
<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>]
<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 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><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:black">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. <o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="color:black">It is a process and trust issue. Also, the timing is critical for several things that you probably have already heard. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">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. <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">And do not mix up Google's postMessage and Form encoding + POSTing. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">The fragment encoding was supposed to be used with postMessage and that's what Google is doing. <o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Even if you had the new feature text on Monday, there is not enough review period. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">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. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">We MUST NOT push any new feature through so quickly. <o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Sorry to be a process police here, but that's what I have to do as a chair. <o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:black">2013/10/18 Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>><o:p></o:p></span></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"><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><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><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><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><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><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><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><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> -- Mike</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"> Nat Sakimura [mailto:<a 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 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><span style="color:black"><o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:black">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. <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Also, John has pointed out that expanding the feature will cause interoperability problems. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">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. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">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. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">The reason sited in support of form POSTing were as follows: <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">1) It is done by SAML and WS. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">2) Fragment would not be able to hold large payload. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">3) If it is not there, implementers will do stupid things like including access token in the query parameter. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">4) If the browser is not Javascript enabled, it is the last resort. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">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. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">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.) <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">The reason 3) is not a good one either. We should just write an implementers NOTE that they should never do this. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">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. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">I understand that there are people who want to do it. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Even some of NRI's internal developers wants to do it. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">However, that is not a good enough reason to get it into the core at this point in time. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">In addition, there will be bunch of moving parts that we have to fix if we were to do it. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">We should not do it in three days. We should take more time to consider various implications. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">We are finalizing the core spec now. The cut off date is end of this week. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">It should be done as an extension. I oppose to do it in the core. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Our priority to get the Core out of the door, now. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:black">2013/10/17 Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>><o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="color:black">Spec call notes 17-Oct-13<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Mike Jones<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Brian Campbell<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">George Fletcher<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">John Bradley<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Nat Sakimura<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Edmund Jay<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Agenda:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> Open Issues<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> Multiple response type requests returning values in ways other than fragments<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> Document Restructuring and Review<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Open Issues:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> #873: session 4.1. Can we use opbs with http (not httponly)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> We developed proposed text for this<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> #879 & #880: Hosting
<a href="http://self-issued.me" target="_blank">self-issued.me</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> John will get the cheapest Amazon VM and give Edmund access to it<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Multiple response type requests returning values in ways other than fragments<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> Microsoft has asked for a POST binding, like WS-Federation and SAML have<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> Ping has an extra response_type component x_post<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> This causes the responses to POST to be returned as form-encoded body content<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> Google has a way of registering clients to use a postMessage binding<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> They do that by registering a JavaScript origin, rather than response_type<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> AOL's OpenID 2.0 provider often uses the POST response because of large AX responses<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> John had proposed a registration parameter for this:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> redirect_type fragment | POST | postMessage<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> This would be discoverable as<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> redirect_types_supported<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> Another reason for this is to not hit fragment size limits<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> Mike will file a bug on this to make a concrete proposal<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> We will discuss this at the Monday meeting<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Document Restructuring and Review:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> Mike posted a Word version of the Core spec with tracked changes turned on<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> People are requested to mark it up with specific proposed changes this week<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black"><br>
_______________________________________________<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></span></p>
</div>
<p class="MsoNormal"><span style="color:black"><br>
<br clear="all">
<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="color:black">-- <br>
Nat Sakimura (=nat)<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:black">Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span style="color:black"><br>
<br clear="all">
<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="color:black">-- <br>
Nat Sakimura (=nat)<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:black">Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>