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

John Bradley ve7jtb at ve7jtb.com
Sat Jul 30 13:48:43 UTC 2011


We have a question for the fb people.

We made the user ID in the user info endpoint id to be consistent with graph API.

We made user ID in the ID token/ introspection endpoint user_id because there is a desire to have long names.

Having the same thing called two things is obviously wrong.

So the question is should we be consistent with what Facebook has now or use something more descriptive because you want to move in that direction.

I am good ether way though have a slight preference for user_id because it is less ambiguous. 

John B.


On 2011-07-30, at 12:56 AM, Mike Jones wrote:

> Thanks to much heavy lifting by Nat and John, we now have a first draft of the OpenID Connect Lite spec ready for you to review.  The goal is that developers should be able to implement a minimal OpenID Connect implementation using only the information contained in this specification.  (They’ll also have to implement Discovery and Registration if they want to enable interactions between parties that are not pre-configured to know about one another.)  Please give it a read!
>  
> OpenID Connect Lite:  http://openid.net/specs/openid-connect-lite-1_0.html
>  
> Major changes relative to the former HTTP Redirect Binding spec are:
> ·        Removed the code flow. Only the token flow is REQUIRED in Lite.
> ·        Make requesting the id_token be REQUIRED. The id_token is treated as opaque.
> ·        Make requesting the token OPTIONAL, depending upon whether an Access Token for the UserInfo endpoint is needed or not.
> ·        Dropped the schema parameter to the Introspection endpoint, which was formerly a string with the value user_id. This is unnecessary since the id_token parameter already can be used to disambiguate the intended uses(s) of the endpoint.
> ·        Dropped the requested audience from the Lite spec, which was formerly the identifier of the target audience of the response. This could be part of the Standard spec, but is an advanced scenario, and so not appropriate for Lite.
> ·        Reference the Discovery and Registration specs, since they're needed for interaction between non-pre-configured parties (so that OpenID Connect installations can be Open).
> ·        Rearranged sections for readability.
>  
> This replaces the parts of the former HTTP Redirect Binding spec that were mandatory to implement.  To complete the refactoring, the Messages spec and Standard spec still need to be produced from parts of the current Core, Framework, and HTTP Redirect Binding specs.  All the specs under the old organization are still also live.
>  
>                                                             Thanks all,
>                                                             -- Mike
>  
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110730/40d1f771/attachment.html>
-------------- 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/20110730/40d1f771/attachment.p7s>


More information about the Openid-specs-ab mailing list