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

[Pam Dingle]

Question:

In section 3.2.1 (Introspection Request),  id_token is listed as required.
 In section 3.2.2 (Introspection Response),  there is an example shown where
the request is:


GET /id_token?access_token=eyJ0eXAiOiJKV1QiL HTTP/1.1
Host: server.example.com

If id_token is required, shouldn't it be shown in the request rather than
(or maybe in addition to?) the access_token?



On Fri, Jul 29, 2011 at 9:56 PM, Mike Jones <Michael.Jones at microsoft.com>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
>
>


-- 
*Pamela Dingle*  |  Sr. Technical Architect
*Ping**Identity*  |   www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
*O:* 303-999-5890   *M:* 303-999-5890
*Email:* pdingle at pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
*Connect with Ping*
Twitter: @pingidentity
LinkedIn Group: Ping's Identity Cloud
Facebook.com/pingidentitypage
*Connect with me*
Twitter: @pamelarosiedee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110801/d8306c07/attachment.html>