[Openid-specs-ab] openid connect specs review

Thu Jul 7 03:30:16 UTC 2011

Thanks for the feedback.

John B.
On 2011-07-06, at 8:29 PM, Johnny Bufu wrote:

> 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.
> 
> ----------------------------------------------------------------
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab