<div dir="ltr">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. <div><br></div><div>Also, John has pointed out that expanding the feature will cause interoperability problems. </div>
<div><br></div><div>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. </div><div>
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. </div><div><br></div><div>The reason sited in support of form POSTing were as follows: </div>
<div><br></div><div>1) It is done by SAML and WS. </div><div>2) Fragment would not be able to hold large payload. </div><div>3) If it is not there, implementers will do stupid things like including access token in the query parameter. </div>
<div>4) If the browser is not Javascript enabled, it is the last resort. </div><div><br></div><div>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. </div>
<div>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.) </div>
<div>The reason 3) is not a good one either. We should just write an implementers NOTE that they should never do this. </div><div>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. </div>
<div><br></div><div>I understand that there are people who want to do it. </div><div>Even some of NRI's internal developers wants to do it. </div><div>However, that is not a good enough reason to get it into the core at this point in time. </div>
<div>In addition, there will be bunch of moving parts that we have to fix if we were to do it. </div><div>We should not do it in three days. We should take more time to consider various implications. </div><div>We are finalizing the core spec now. The cut off date is end of this week. </div>
<div><br></div><div>It should be done as an extension. I oppose to do it in the core. </div><div>Our priority to get the Core out of the door, now. </div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2013/10/17 Mike Jones <span dir="ltr"><<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal">Spec call notes 17-Oct-13<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Mike Jones<u></u><u></u></p>
<p class="MsoNormal">Brian Campbell<u></u><u></u></p>
<p class="MsoNormal">George Fletcher<u></u><u></u></p>
<p class="MsoNormal">John Bradley<u></u><u></u></p>
<p class="MsoNormal">Nat Sakimura<u></u><u></u></p>
<p class="MsoNormal">Edmund Jay<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Agenda:<u></u><u></u></p>
<p class="MsoNormal"> Open Issues<u></u><u></u></p>
<p class="MsoNormal"> Multiple response type requests returning values in ways other than fragments<u></u><u></u></p>
<p class="MsoNormal"> Document Restructuring and Review<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Open Issues:<u></u><u></u></p>
<p class="MsoNormal"> #873: session 4.1. Can we use opbs with http (not httponly)<u></u><u></u></p>
<p class="MsoNormal"> We developed proposed text for this<u></u><u></u></p>
<p class="MsoNormal"> #879 & #880: Hosting <a href="http://self-issued.me" target="_blank">self-issued.me</a><u></u><u></u></p>
<p class="MsoNormal"> John will get the cheapest Amazon VM and give Edmund access to it<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Multiple response type requests returning values in ways other than fragments<u></u><u></u></p>
<p class="MsoNormal"> Microsoft has asked for a POST binding, like WS-Federation and SAML have<u></u><u></u></p>
<p class="MsoNormal"> Ping has an extra response_type component x_post<u></u><u></u></p>
<p class="MsoNormal"> This causes the responses to POST to be returned as form-encoded body content<u></u><u></u></p>
<p class="MsoNormal"> Google has a way of registering clients to use a postMessage binding<u></u><u></u></p>
<p class="MsoNormal"> They do that by registering a JavaScript origin, rather than response_type<u></u><u></u></p>
<p class="MsoNormal"> AOL's OpenID 2.0 provider often uses the POST response because of large AX responses<u></u><u></u></p>
<p class="MsoNormal"> John had proposed a registration parameter for this:<u></u><u></u></p>
<p class="MsoNormal"> redirect_type fragment | POST | postMessage<u></u><u></u></p>
<p class="MsoNormal"> This would be discoverable as<u></u><u></u></p>
<p class="MsoNormal"> redirect_types_supported<u></u><u></u></p>
<p class="MsoNormal"> Another reason for this is to not hit fragment size limits<u></u><u></u></p>
<p class="MsoNormal"> Mike will file a bug on this to make a concrete proposal<u></u><u></u></p>
<p class="MsoNormal"> We will discuss this at the Monday meeting<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Document Restructuring and Review:<u></u><u></u></p>
<p class="MsoNormal"> Mike posted a Word version of the Core spec with tracked changes turned on<u></u><u></u></p>
<p class="MsoNormal"> People are requested to mark it up with specific proposed changes this week<u></u><u></u></p>
</div>
</div>
<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></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>
</div>