[Openid-specs-ab] openid connect specs review

Thu Jul 7 00:29:48 UTC 2011

Hello spec editors,

I've given a close read to the following specifications. Below are 
comments about parts that I've found unclear or confusing, and questions 
for which I didn't find answers in the specs and would hold me back if I 
were to implement them.

Thanks,
Johnny

----------------------------------------------------------------

Core (draft 07 / June 29, 2011):

1. Terminology

"Claims Provider" is not formally defined, but used in another definition.

Base64url is defined but not used anywhere.

UserInfo Endpoint... "returns information about the current user":
The impression is that the UserInfo Endpoint is called without involving 
the user/agent (a back-channel/API-like call). It's not clear what 
"current" would mean in this case - perhaps "associated with the 
presented access token"?

RP is defined as "Client and Resource Servers"
UserInfo Endpoint is defined as "protected resource"

It can be inferred that the UserInfo Endpoint is a protected resource 
served by the RP (since the RP is the only defined Resource Server).

3. Messages

"ID Token" is referenced but not defined.

3.1.1.  Authorization Request

response_type: "Acceptable values are code, token, and none."

Is the list complete? If yes, see next review item. If not, and anything 
is acceptable (per protocol binding specs, I imagine) what's the purpose 
in listing only some of the acceptable values here (instead of deferring 
to the relevant specs)?

3.1.2 Authorization Response

"Response values for other requested response_type parameters are 
returned in the Access Token Endpoint (Need Confirmation)."

It is implied that other response_type values are accepted than the ones 
listed in section 3.1.1.

3.1.3.1.  Error Codes

It's not clear to me how error codes can be extended:
"by string prefixed by x_".

Which "string"? Any error code string that someone wants to come up 
with, or only the ones that have already been defined in OAuth 2.0 and 
OpenID Connnect Core?

4.2.  JSON Serialization

Where is the "openid": {...} (JSON) construct from the example defined? 
This comes in as a surprise in the reading of the spec.

----------------------------------------------------------------

Framework (draft 01 / July 5, 2011):

2.  Terminology

Identity Provider has the same definition as OpenID Provider in Core: if 
it's the same entity then OP should be used; if different then the 
definition should point out what the difference is.

3.1.1.  OpenID Request Object

"the OpenID Request object is passed as the value of a "request" OAuth 
2.0 parameter"

OAuth 2.0 doesn't define a parameter named "request" that I could find.

ID Token is referenced but not defined.

Session Token referenced but not defined.

3.2.  Authorization Response

Pointer should be to Core/Section 3.1.2 instead of 4.1.2.

3.3.1.  Error Codes

Does session_selection_required correspond to an error in processing the 
prompt:select_account from a Authorization Request?

The error codes seem to convey what the server wants, and not 
necessarily what generated the error and would be more helpful in fixing 
it by the one who receives the error.

4.  UserInfo Endpoint

"Claims object" not formally defined - reader left to guess/assume it's 
the same as ""clm" object" described in section 3.1.1 / OpenID Request 
Object.

4.3.  Requests

"RESERVED" is capitalized but not defined by RFC2119; capitalization 
suggest specially defined meaning. I suggest it shouldn't be capitalized 
if there is no special meaning defined elsewhere.

What is a (request/response) schema? I didn't find a definition or 
introduction to the purpose of schema in any of the specs I've read so 
far. See also the related note on UserInfo / Section 2.1.

4.4.  Responses

"See the OpenID Connect Core [OpenID.CC] specification on how to request 
a different format."

Core doesn't define UserInfo response formats.

8.2.  Authorization Response Verification
8.4.  UserInfo Response Verification

"3.Check that current time is within the validity period."

It not clear what is and who defines the validity period. Are 
verification steps 2 & 3 just SSL certificate verification?

8.2.  Authorization Response Verification

Is "User Info API request" the same as a regular request to the UserInfo 
Endpoint (these are not referred to as APIs before this occurrence)? If 
so then the same spelling should be used to avoid confusion that it 
might be something else.

----------------------------------------------------------------

UserInfo (draft 03 / July 05, 2011):

2.  UserInfo Endpoint

Claim objects are not formally defined.

2.1.  Requests

Which endpoint type from OAuth 2.0 / Bearer Token does the UserInfo 
Endpoint comply to?

What constitutes a (valid) schema name that MAY be used?

What's the difference between the terms "schema" and "format" in the 
context of the UserInfo specification? They seem to be used 
interchangeably - if there is no difference and neither is formally 
defined, I suggest using the more generic "format" term.

"RESERVED" is capitalized but not defined by RFC2119; capitalization 
suggest specially defined meaning. I suggest it shouldn't be capitalized 
if there is no special meaning defined elsewhere.

2.2.  Responses

"See the OpenID Connect Core [OpenID.CC] specification on how to request 
a different format."

Core doesn't define UserInfo response formats.

----------------------------------------------------------------

HTTP Redirect Binding (draft 01 / June 30, 2011):

3.1.  Authorization Code Flow

"the party that receives message MUST verify it according to the 
verification rule set in OpenID Connect Core 1.0 [OpenID.CC] and OpenID 
Connect Framework 1.0 [OpenID.CF]."

There are no rules defined in Core.

3.1.1.1.  Query Parameters Method

Which HTTP methods are allowed? Being a HTTP binding profile I would 
expect, as an implementer, to find this answer here.

3.1.1.1.1.  Client sends a request to the Authorization Server

"any other valid means of directing the User-Agent to the URL" is 
ambiguous and open-ended, a HTTP binding specification should define 
what's acceptable.

scope: "openid" is missing from example.

3.1.1.2.  Request Parameter Method

"The JWT object MAY be signed or signed and encrypted via JWS [JWS] and 
JWE [JWE] respectively, thereby providing non-repudiation and/or 
security of the request."

Non-repudiation is only one of the main benefits provided by signatures, 
while "security" is a too-generic term. I would suggest:
"providing authentication, integrity, non-repudiation and/or 
confidentiality"

And again, the allowed HTTP methods should be specified.

The second example should be replaced with the actual JWT (as the 
comment there says).

3.2.5.1.  End-User Grants Authorization

Core defines only code, token, none as acceptable response_type values, 
which would suggest that id_token would then be unacceptable. (See also 
note on Core/Section 3.1.1)

Also, I couldn't find where "id_token" is listed as possible/acceptable 
value for the response_type parameter, and what its meaning would be.

----------------------------------------------------------------