[Openid-specs-ab] New Core Review

Mike Jones Michael.Jones at microsoft.com
Wed Oct 30 23:43:16 UTC 2013


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, per Section 12.2<http://openid.net/specs/openid-connect-core-1_0-14.html#FormSerialization>. The Token Endpoint MUST support the use of the HTTP POST method defined in RFC 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 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131030/99d3ec03/attachment.html>


More information about the Openid-specs-ab mailing list