[Openid-specs-ab] First version of OpenID Connect Lite spec ready for working group review

[John Bradley]

On 2011-08-01, at 7:48 PM, Johnny Bufu wrote:

> 
> On 11-07-29 09:56 PM, Mike Jones wrote:
>> Please give it a read!
>> OpenID Connect Lite: http://openid.net/specs/openid-connect-lite-1_0.html
> 
> I gave it a read, here's my feedback:
> 
> 
> 3.1.1.  Client Prepares an Authorization Request
> 
> "when an Access Token for the UserInfo endpoint is being requested in addition to an ID Token"
> 
> How is an additional access token for the UserInfo endpoint requested, (and how is such a request omitted)? It's not clear whether including 'token' in the response_type parameter is the way to signal it, or something else triggers this feature of the request.

The spec will be changed so that the id_token is always returned.   You ask for code or token to indicate the response type.
> 
> Is 'callback' the authorization response? If yes, use the same term rather than an undefined, potentially confusing one.

Will make change
> 
> The specific processing and behavior associated with each of the 'display' parameter values is undefined, implementers are free to ignore them as far as the spec is concerned.
> 
> The specific processing and behavior associated with each of the 'prompt' parameter values is undefined, implementers are free to ignore them as far as the spec is concerned.

Breno suggested that this should be documented in a OAuth extension rather than the openID spec.  We should add text or create the appropriate additional spec.

> 
> As currently defined, the nonce does not fulfill its declared purpose of mitigating replay attacks in any way. The spec says which messages carry it, but does not say how and by whom verifications should be performed.

Add text clarifying the RP must verify the nonce.

> 
> 3.1.4.  Authorization Server Obtains the End-User Consent/Authorization
> 
> "the Authorization Server MUST obtain an authorization decision"
> 
> This is unachievable, the user cannot be forced to answer a question if they don't want to. The spec should explicitly define the (negative) authorization outcome in this case.

Clarify text
> 
> 3.2.1.  Introspection Request
> 
> "ID Token obtained from an OpenID Connect authorization request"
> 
> - should it not say "authorization response"?
OK
> - authorization response (3.1.5.1) does not contain an ID Token either
Will fix
> 
> How is the ID Token sent via the authorization header? id_token=<value>, just the value, or some other way?

Introspection request should be changed to POST and sent in body.

> 
> 3.2.2.  Introspection Response
> 
> Example request lists an access_token instead of an id_token parameter.

Changer example
> 
> 3.2.3.  Error Codes
> 
> invalid_access_token error code is defined, but an access token is not mentioned in 3.2.1 Introspection Request.

Remove access token no longer valid.
> 
> 3.2.4.1.  Request Verification
> 
> "all required parameters are present and valid"
> 
> What are the rules for determining if each parameter value is valid or not?

add
> 
> 
> Johnny
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110808/81185697/attachment.p7s>