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

[John Bradley]

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>
> To: Johnny Bufu <jbufu at janrain.com>
> Cc: Edmund Jay <ejay at mgi1.com>; 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
> >> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> > _______________________________________________
> > 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/20110810/3dbf1e86/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/20110810/3dbf1e86/attachment.p7s>