[Openid-specs-ab] New Core Review

John Bradley ve7jtb at ve7jtb.com
Thu Oct 31 00:11:43 UTC 2013

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> 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 at http://openid.net/specs/openid-connect-core-1_0-14.html#TokenEndpoint:
> Clients MUST use the HTTP POST method to make requests to the Token Endpoint. Request parameters are added using Form Serialization, perSection 12.2. The Token Endpoint MUST support the use of the HTTP POSTmethod defined in RFC 2616 [RFC2616] at the Token Endpoint.
> saying:
> It is not the case. If the Authorization Header is used, GET is perfectly valid.
> and yet http://tools.ietf.org/html/rfc6749#section-3.2 says:
> 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 in http://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] On Behalf Of Nat Sakimura
> Sent: Monday, October 21, 2013 10:56 AM
> To: 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 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
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131030/c6c589c0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131030/c6c589c0/attachment-0001.p7s>

More information about the Openid-specs-ab mailing list