[Openid-specs-ab] OpenID Connect Lite feedback

[Allen Tom]

Hi all,

I took at look at the OpenID Connect Lite 1.0 - draft 06 spec, and I think
it's great that the WG is writing a self contained easy to read spec for
implementors. I haven't been following OpenID Connect all that closely, so
perhaps I can give a fresh perspective on what's been written so far.

*General Feedback:*

Since the ID Token is a new concept, it would be a good idea to explain what
it is, and how/when implementors should use it.

Implicit vs code flow: Implementors should be given more guidance as to how
to decide which flow to use. The introduction to Section 3 definitely needs
some more clarification.  Widely used documentation from
existing implementations use the terms Server Side Flow for Code, and Client
Side Flow for Implicit.

Why can't the Introspection and UserInfo endpoints be combined into a single
endpoint?

Feedback on specific sections:

*Section 3.1.1*
*
*
PPID Scope - Unless there's widespread demand from implementors for PPID
responses, I'd recommend moving PPID responses to an extension. As far as I
know, PPID identifiers are not widely used for "Connect" type deployments,
and mentioning it in the Lite spec hurts readability.

Display: none,popup,touch,mobile - These values should be defined, or
otherwise moved to an extension. Listing optional values without defining
them hurts readability.

Prompt: login,consent,select_account - Either define them, or remove them.
Same situation as with the Display parameter.


*Section 3.1.4 *

Paragraph needs to be rewritten - it's unclear what implementors are
supposed to do.

*Section 3.1.5.1*

Shouldn't there be an id_token in the response? Section 3.1.1 says that
response_type=id_token was required in the request.

*Section 3.2.2*

iss - Is this like the client_id, but for the server? How is this used?
What's to stop a server from reusing another server's iss?

user_id - is this globally unique? Unique for the domain?

aud/issued_to - why two different parameters for the same thing?

exp - in addition to the expiration timestamp, it might be useful to return
a boolean indicating whether or not the token is valid or expired. (Clients
might not know what time it is)


*Section 4.1 *

The description for the id parameter is confusing.


I hope my feedback was helpful,
Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110808/729dd646/attachment.html>