[Openid-specs-ab] Spec call notes 08-Aug-11

Wed Aug 10 21:09:01 UTC 2011

Correct Lite is a Lite client spec,  not a spec that describes a lite server.  The Server is expected to support token and code flows as well as provide a id_token.

I am working on those changes

John
On 2011-08-10, at 4:42 PM, Johnny Bufu wrote:

> The lite spec doesn't make it clear that it is only addressed to "lite client" implementations (this should probably be spelled out early on, in the abstract, followed by definitions that clarify the differences between a lite and full client).
> 
> This is in my opinion a major problem that needs to be fixed. Based on the last discussions I expected the lite version to be the minimal set of features that can be implemented. It may be so for lite clients, but for servers/providers there's a lot of essential information missing - they simply could not implement OpenID Connect Lite (and neither does Lite point servers to Messages or other documents).
> 
> If the ID token is a signed JWT, it should be introduced as such in Lite's terms, with a pointer to the definition in the Messages document and a note that lite clients don't need its contents, only servers and full clients.
> 
> The Lite spec should also clarify what path server implementers should follow, with clear distinctions about what's optional and required, e.g. servers MUST implement Messages, implementation of Session Management is OPTIONAL.
> 
> Johnny
> 
> On 11-08-10 12:14 PM, John Bradley wrote:
>> We could describe the token format in the lite spec, but that is going
>> to make it longer.
>> The goal was to have something around the 10-15 page mark.
>> 
>> The id_token is a signed JWT.
>> 
>> They are described in session management. Sec 3.1.1.
>> http://openid.net/specs/openid-connect-session-1_0.html
>> 
>> Now I also note looking at that spec sec 3.2.2 is referring to the
>> introspection endpoint as Check Session.
>> They are the same thing. I am happy to go with Check Session rather than
>> introspection.
>> We should have only one.
>> 
>> The introspection/Check session endpoint is just verifying the signature
>> of the JWT that is passed as it's access token and returning the
>> unpacked contents.
>> That became less clear when we tried to accommodate sending the
>> user_info access token.
>> We removed that, so we should put back the simple explanation of what
>> that endpoint is doing.
>> 
>> John
>> 
>> On 2011-08-10, at 2:19 PM, Edmund Jay wrote:
>> 
>>> It could be that I missed the discussion about the id_token being
>>> opaque only in the Lite spec.
>>> In the Session Management spec, it is a JWT.
>>> Breno, does that remain valid?
>>> If so, I will update the Messages spec.
>>> 
>>> 
>>> -- Edmund
>>> 
>>> ------------------------------------------------------------------------
>>> *From:*John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>>
>>> *To:*Johnny Bufu <jbufu at janrain.com <mailto:jbufu at janrain.com>>
>>> *Cc:*Edmund Jay <ejay at mgi1.com <mailto:ejay at mgi1.com>>;
>>> openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>
>>> *Sent:*Wed, August 10, 2011 11:09:43 AM
>>> *Subject:*Re: [Openid-specs-ab] Spec call notes 08-Aug-11
>>> 
>>> There is additional session related information in the id_token. It is
>>> only opaque ti the lite spec.
>>> A Full client just needs to check the signature and not use the
>>> introspection endpoint at all.
>>> This is the same thing Facebook is doing with signed request, we have
>>> just added a way for a client that docent understand crypto to
>>> validate the token.
>>> 
>>> Why not use the id_token both places.
>>> 
>>> We received strong push back that people had existing formats for
>>> access tokens that they did not want to change.
>>> My original preference was to use the same JWT for both.
>>> 
>>> Google, SalesForce and others wanted a separation between the two.
>>> T-Mobile also expressed that that was their preference when I talked
>>> to them at the IETF.
>>> 
>>> Allowing the client to send a access token to the introspection
>>> endpoint was also problematic for people like DT who want
>>> introspection to be stateless.
>>> 
>>> I guess the simple answer is that there may be different info in the
>>> two tokens.
>>> 
>>> John B.
>>> 
>>> On 2011-08-10, at 1:51 PM, Johnny Bufu wrote:
>>> 
>>> > Why are two tokens needed (access_token and id_token)? I don't see
>>> in the spec any reason that would prevent the use of just one token
>>> with both introspection and userinfo endpoints.
>>> >
>>> > Johnny
>>> >
>>> > On 11-08-08 05:15 PM, Edmund Jay wrote:
>>> >>
>>> >> Spec call notes 08-Aug-11
>>> >>
>>> >> Pam Dingle
>>> >> John Bradley
>>> >> Nat Sakimura
>>> >> Johnny Bufu
>>> >> George Fletcher
>>> >> Edmund Jay
>>> >>
>>> >>
>>> >>
>>> >> John made some changes to the OpenID Lite spec
>>> >> * changed the Introspection endpoint from GET request to POST request
>>> >> due to the fact the
>>> >> the ID Token may be intercepted by referral URLs/Logs, and other
>>> methods.
>>> >> Breno said in chat with Nat that GET and JSONP may be needed
>>> >> John to contact Breno offline for further discussions
>>> >> * made other non-controversial changes from feedback
>>> >>
>>> >> John will work on first draft of OpenID 2.0 compatibility/migration
>>> >> spec. Maybe available tomorrow.
>>> >>
>>> >> Edmund will post first draft of OpendID Connect Messages spec to the
>>> >> mailing list.
>>> >>
>>> >>
>>> >> Discussion of JWT and long header names:
>>> >> * most preferred longer names
>>> >> * most feel that it's too late to make major changes to spec
>>> >> * longer or shorter names can be implemented by defining long constant
>>> >> values by developers vice versa
>>> >> * perhaps better documentation in specs for short names
>>> >>
>>> >> Pam has written a OpenID Connect landing page which will be posted to
>>> >> the list for feedback
>>> >>
>>> >> WG to setup new support mailing list not encumbered by IPR agreements
>>> >> for general and support questions and feedback.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> <http://openid.net/specs/openid-connect-framework-1_0.html>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> Openid-specs-ab mailing list
>>> >>Openid-specs-ab at lists.openid.net
>>> <mailto:Openid-specs-ab at lists.openid.net>
>>> >>http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> > _______________________________________________
>>> > Openid-specs-ab mailing list
>>> >Openid-specs-ab at lists.openid.net
>>> <mailto: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/20110810/8c5b3458/attachment.p7s>