<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">OK. I got carried away. I looked at <br>
<br>
para 3 that says: "<br>
<pre class="newpage" style="font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-before: always; color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">The endpoint URI MAY include an "application/x-www-form-urlencoded"
formatted (per <a href="http://tools.ietf.org/html/rfc6749#appendix-B">Appendix B</a>) query component (<a href="http://tools.ietf.org/html/rfc3986#section-3.4">[RFC3986] Section 3.4</a>),</pre>
<br>
and thought RFC6749 is allowing GET but that is not the case as
the para 5 mandates POST. <br>
<br>
Sorry about that. I withdraw the comment. <br>
<br>
Nat<br>
<br>
(2013/10/31 9:11), John Bradley wrote:<br>
</div>
<blockquote
cite="mid:1D42D429-F27B-4C17-B1B4-75DECF588234@ve7jtb.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=windows-1252">
I agree with Mike the token endpoint is always form POST.
<div><br>
</div>
<div>2 I don't know that saying this adds value, as the code is a
reference if the AS finds it then it uses that info. </div>
<div><br>
</div>
<div>If I were to add anything I would remind developers that code
needs to be single use or a short lifetime. That they tend to
get wrong.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
<div>
<div>On Oct 30, 2013, at 8:43 PM, Mike Jones <<a
moz-do-not-send="true"
href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div lang="EN-US">
<div class="WordSection1">
<div><span>I have two questions about points you made in
your review that affect the normative functionality
of the spec, Nat.</span></div>
<div><span> </span></div>
<div><span>1. You objected to this text at<span
class="Apple-converted-space"> </span><a
moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-core-1_0-14.html#TokenEndpoint">http://openid.net/specs/openid-connect-core-1_0-14.html#TokenEndpoint</a>:</span></div>
<div><span lang="EN">Clients MUST use the HTTP<span
class="Apple-converted-space"> </span></span><tt><span
lang="EN">POST</span></tt><span lang="EN"><span
class="Apple-converted-space"> </span>method to
make requests to the Token Endpoint. Request
parameters are added using Form Serialization, per<a
moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-core-1_0-14.html#FormSerialization"><span>Section 12.2</span></a>.
The Token Endpoint MUST support the use of the HTTP<span
class="Apple-converted-space"> </span></span><tt><span
lang="EN">POST</span></tt><span lang="EN">method
defined in<span class="Apple-converted-space"> </span><a
moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-core-1_0-14.html#RFC2616"><span>RFC
2616</span></a><span
class="Apple-converted-space"> </span>[RFC2616] at
the Token Endpoint.</span><span></span></div>
<div><span>saying:</span></div>
<div><span>It is not the case. If the Authorization
Header is used, GET is perfectly valid.</span></div>
<div><span>and yet<span class="Apple-converted-space"> </span><a
moz-do-not-send="true"
href="http://tools.ietf.org/html/rfc6749#section-3.2">http://tools.ietf.org/html/rfc6749#section-3.2</a><span
class="Apple-converted-space"> </span>says:</span></div>
<div><span lang="EN">The client MUST use the HTTP "POST"
method when making access token requests.</span></div>
<div><span> </span></div>
<div><span>It seems that your comment contradicts a MUST
in RFC 6749. Should I therefore ignore it, or is
there a reason that it is valid, despite what’s
above?</span></div>
<div><span> </span></div>
<div><span>2. You added this bullet to the Token
Request Validation list in<span
class="Apple-converted-space"> </span><a
moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-core-1_0-14.html#TokenRequestValidation">http://openid.net/specs/openid-connect-core-1_0-14.html#TokenRequestValidation</a>:</span></div>
<div><span><span>·<span> <span
class="Apple-converted-space"> </span></span></span></span><span>Check
if the received code is associated with a previously
created ID Token</span><span></span></div>
<div><span> </span></div>
<div><span>Is what you actually meant “Verify that the
code is associated with an OpenID Connect
Authentication Request?” I think the language about
“previously created” is too restrictive. Also,
given that Authorization Servers can accept requests
without the “openid” scope, should we actually be
saying even that much?</span></div>
<div><span> </span></div>
<div><span>
Thanks,</span></div>
<div><span>
-- Mike</span></div>
<div><span> </span></div>
<div><b><span>From:</span></b><span><span
class="Apple-converted-space"> </span><a
moz-do-not-send="true"
href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>
[<a moz-do-not-send="true"
href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto:openid-specs-ab-bounces@lists.openid.net</a>]<span
class="Apple-converted-space"> </span><b>On Behalf
Of<span class="Apple-converted-space"> </span></b>Nat
Sakimura<br>
<b>Sent:</b><span class="Apple-converted-space"> </span>Monday,
October 21, 2013 10:56 AM<br>
<b>To:</b><span class="Apple-converted-space"> </span><a
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
<b>Subject:</b><span class="Apple-converted-space"> </span>[Openid-specs-ab]
New Core Review</span></div>
<div> </div>
<div>
<div>Assuming no text has been added / crafted apart
from the section 2 and section 11, I think I am done
with it. </div>
<div>
<div> </div>
</div>
<div>
<div>Two versions: One is more radical than the
other: the file name indicates it. </div>
</div>
<div>
<div>The radical one merges implicit and hybrid into
Multiple Response Types. </div>
</div>
<div>
<div>In fact, there is no pure "implicit"
authentication. It is always Hybrid. </div>
</div>
<div>
<div>So, this probably is more logical. I also got
rid of the word "Code Flow". </div>
</div>
<div>
<div>It is an undefined word now that OAuth got rid
of the term. </div>
</div>
<div>
<div>I replaced it with Code Grant. </div>
</div>
<div>
<div> </div>
</div>
<div>
<div>I also removed bunch of redundant text. </div>
</div>
<div>
<div> </div>
</div>
<div>
<div>There are a few technical changes. Otherwise,
though it may seem to be a lot of change, they are
all editorial. Technical changes are marked in the
comment with (te). </div>
</div>
<div>
<div> </div>
</div>
<div>
<div>They are: </div>
</div>
<div>
<div> </div>
</div>
<div>
<div>1. The fragment handling. </div>
</div>
<div>
<div> </div>
</div>
<div>
<div>Section 2.2.2.7 says that fragment has to be
sent to the Web Server. This is not true. The
javascript client may consume it by itself. This
was a new text added in the new Core. I propose to
remove it entirely. </div>
</div>
<div>
<div> </div>
</div>
<div>
<div>2. Relationship of Access Tokens</div>
</div>
<div>
<div> </div>
</div>
<div>
<div>The proposed text says they should be the same.
I contend that they actually should be different.
This, again, is a new text introduced in the new
core. </div>
</div>
<div>
<div> </div>
</div>
<div>
<div>It is now almost 3:00am. I am going to the bed
now. </div>
</div>
<div>
<div> </div>
</div>
<div>
<div>Cheers, </div>
</div>
<div>
<div> </div>
</div>
<div>
<div> </div>
</div>
<div>
<div>
<div> </div>
</div>
<div>--<span class="Apple-converted-space"> </span><br>
Nat Sakimura (=nat)</div>
<div>
<div>Chairman, OpenID Foundation<br>
<a moz-do-not-send="true"
href="http://nat.sakimura.org/"
target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div>
</div>
</div>
</div>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Nat Sakimura (<a class="moz-txt-link-abbreviated" href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a>)
Nomura Research Institute, Ltd.
<a class="moz-txt-link-freetext" href="Tel:+81-3-6274-1412">Tel:+81-3-6274-1412</a> Fax:+81-3-6274-1547
本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ござӓ
6;|
14;せんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。
PLEASE READ:
The information contained in this e-mail is confidential and intended for the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.
</pre>
</body>
</html>