<div dir="ltr">+1 to not to use a normative language here and just defer it to the Multiple Response Type doc or a profile doc. <div style>FYI, the Multiple Response Type doc. is using SHOULD. </div><div style>If we want to allow something like postMessage, we should not be too prescriptive. </div>
<div style>It is a core specification, and we have to have some room to move around. </div><div style>SHOULD is OK, but perhaps just saying "as in Multiple Response Type" suffices. </div><div style><br></div><div style>
As to the normative language use is concerned, I have done a fresh pass of the Messages and found a lot of them too restrictive. We have been fixated with the idea of the user agent being a web browser or smart phones. That assumption is not true. It could very well be a fridge with blinking LED light, so MUST in anything related to a user interface is a bit too much. SHOULD is the strongest language we can use. </div>
<div style><br></div><div style>Similarly, we have been stepping on potential regulatory issues with MUSTs. We have to avoid them as well. </div><div style><br></div><div style>I have not read Registration, Discovery, Basic, and Implicit in this respect. I encourage you guys to read them in this respect. Even just critically reading those MUST and MUST NOT would help. </div>
<div style><br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/6/5 Brian Campbell <span dir="ltr"><<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>I've also got a draft of a POST style response type, FWIW.<br><br></div>It shouldn't be a MUST. But SHOULD probably isn't right either. Response types are terribly confusing (we often use text like "<span style="font-family:verdana,charcoal,helvetica,arial,sans-serif">includes the string" which is convenient but not technically correct) but that ship has sailed. <br>
<br></span></div><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif">What I'm suggesting is that </span>OAuth 2.0 Multiple Response Type Encoding Practices deal with the response type situation. Any normative language in the other docs is likely only to cause inconsistencies or other problems.<br>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 4, 2013 at 9:04 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>It was left open to allow a POST message response to be defined in Future. Google has a draft for that but it has not been advanced yet. So no to MUST. <br>
<br>Sent from my iPhone</div><div><div><div><br>On 2013-06-04, at 4:28 PM, Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>> wrote:<br><br></div>
<blockquote type="cite">
<div><div dir="ltr"><div>One way or the other it should match up to OAuth 2.0 Multiple
Response Type Encoding Practices so as not to have inconsistencies in
the spec suite. <br><br></div>It's maybe better to not have a MUST or SHOULD here at all.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 1, 2013 at 7:09 PM, Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>In the 2nd paragraph of </div><h3 style="font-family:helvetica,monaco,'MS Sans Serif',arial,sans-serif;color:rgb(51,51,51);background-color:transparent">
2.2.6.1. End-User Grants Authorization</h3>
<div>of Standard, it states: </div><div><br></div><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif">Note that if the </span><tt style="color:rgb(0,51,102);font-family:'Courier New',Courier,monospace">response_type</tt><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif"> parameter in the Authorization Request includes the string value </span><tt style="color:rgb(0,51,102);font-family:'Courier New',Courier,monospace">token</tt><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif"> or </span><tt style="color:rgb(0,51,102);font-family:'Courier New',Courier,monospace">id_token</tt><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif">, all response parameters SHOULD be added to the fragment component of the redirection URI. Otherwise, the response parameters are added to the query component of the redirection URI.</span><br clear="all">
<div><br></div><div>Is it SHOULD? Is it not MUST? </div><div>SHOULD means that it can be sent otherwise, e.g., as query string. </div><span><font color="#888888"><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>
</font></span></div>
<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><br>
<br></blockquote></div><br></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" target="_blank">Openid-specs-ab@lists.openid.net</a></span><br>
<span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br></div></blockquote></div></div></div></blockquote></div><br>
</div>
</div></div></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>