[Openid-specs-ab] New Core Review

n-sakimura n-sakimura at nri.co.jp
Thu Oct 31 02:29:17 UTC 2013


OK. I got carried away. I looked at

para 3 that says: "

The endpoint URI MAY include an "application/x-www-form-urlencoded"
    formatted (perAppendix B  <http://tools.ietf.org/html/rfc6749#appendix-B>) query component ([RFC3986] Section 3.4  <http://tools.ietf.org/html/rfc3986#section-3.4>),


and thought RFC6749 is allowing GET but that is not the case as the para 
5 mandates POST.

Sorry about that. I withdraw the comment.

Nat

(2013/10/31 9:11), John Bradley wrote:
> I agree with Mike the token endpoint is always form POST.
>
> 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.
>
> 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.
>
>
>
> On Oct 30, 2013, at 8:43 PM, Mike Jones <Michael.Jones at microsoft.com 
> <mailto:Michael.Jones at microsoft.com>> wrote:
>
>> I have two questions about points you made in your review that affect 
>> the normative functionality of the spec, Nat.
>> 1.  You objected to this text 
>> athttp://openid.net/specs/openid-connect-core-1_0-14.html#TokenEndpoint:
>> Clients MUST use the HTTPPOSTmethod to make requests to the Token 
>> Endpoint. Request parameters are added using Form Serialization, 
>> perSection 12.2 
>> <http://openid.net/specs/openid-connect-core-1_0-14.html#FormSerialization>. 
>> The Token Endpoint MUST support the use of the HTTPPOSTmethod defined 
>> inRFC 2616 
>> <http://openid.net/specs/openid-connect-core-1_0-14.html#RFC2616>[RFC2616] 
>> at the Token Endpoint.
>> saying:
>> It is not the case. If the Authorization Header is used, GET is 
>> perfectly valid.
>> and yethttp://tools.ietf.org/html/rfc6749#section-3.2says:
>> The client MUST use the HTTP "POST" method when making access token 
>> requests.
>> 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?
>> 2.  You added this bullet to the Token Request Validation list 
>> inhttp://openid.net/specs/openid-connect-core-1_0-14.html#TokenRequestValidation:
>> ·Check if the received code is associated with a previously created 
>> ID Token
>> 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?
>> Thanks,
>> -- Mike
>> *From:*openid-specs-ab-bounces at lists.openid.net 
>> <mailto:openid-specs-ab-bounces at lists.openid.net> 
>> [mailto:openid-specs-ab-bounces at lists.openid.net]*On Behalf Of*Nat 
>> Sakimura
>> *Sent:*Monday, October 21, 2013 10:56 AM
>> *To:*openid-specs-ab at lists.openid.net 
>> <mailto:openid-specs-ab at lists.openid.net>
>> *Subject:*[Openid-specs-ab] New Core Review
>> Assuming no text has been added / crafted apart from the section 2 
>> and section 11, I think I am done with it.
>> Two versions: One is more radical than the other: the file name 
>> indicates it.
>> The radical one merges implicit and hybrid into Multiple Response Types.
>> In fact, there is no pure "implicit" authentication. It is always 
>> Hybrid.
>> So, this probably is more logical. I also got rid of the word "Code 
>> Flow".
>> It is an undefined word now that OAuth got rid of the term.
>> I replaced it with Code Grant.
>> I also removed bunch of redundant text.
>> 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).
>> They are:
>> 1. The fragment handling.
>> 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.
>> 2. Relationship of Access Tokens
>> 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.
>> It is now almost 3:00am. I am going to the bed now.
>> Cheers,
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net 
>> <mailto:Openid-specs-ab at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab


-- 
Nat Sakimura (n-sakimura at nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131031/0ec78454/attachment.html>


More information about the Openid-specs-ab mailing list