[Openid-specs-ab] Spec call notes 04-Aug-11
Mike Jones
Michael.Jones at microsoft.com
Fri Aug 5 02:12:03 UTC 2011
Reacting to the JWT comments below - the header is first in JWT to provide a clear and actionable description of what comes next. It may be a signature. It may be encrypted content. The FB field order doesn't have this useful property.
JWT has significant and growing adoption as-is. At most, perhaps we could entertain a discussion about using longer member names in some circumstances. But I believe that trying to undo the numerous and interlocking consensus decisions that led to the JWT, JWS, and soon the JSE format, would be highly counter-productive.
Best wishes,
-- Mike
From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Edmund Jay
Sent: Thursday, August 04, 2011 5:33 PM
To: openid-specs-ab at lists.openid.net
Subject: [Openid-specs-ab] Spec call notes 04-Aug-11
Spec call notes 04-Aug-11
John Bradley
Nat Sakimura
Johnny Bufu
Allen Tom
George Fletcher
Edmund Jay
Breno de Medeiros (joined later)
Updates
John waiting for more feedback on Lite/Discovery/Registration specs
before writing new drafts
Newcastle is doing some work on registration that may be used for
feedback/reference
Breno met with Facebook and discussed some issues with JWT
- FB would like to use longer parameter names and change order of
signature parameters by putting the signature first.
- Discussed using FB signed requests and how to make it more functionally
like JWT.
- Issue unresolved, put off for later.
Edmund needs to update Messages spec using todays feedback before
circulating
John asked about response_type, scope, and how id_token is returned
- The 'respone_type' will no longer include id_token value since it
only indicates the flow method used
- The 'scope' parameter specifies a additive list on what is to be
returned at userinfo endpoint
openid - returns ID Token only
profile - default userinfo claims excluding email/address and possibly others
email - returns email
address - returns address
other values to be determined
Breno raised the issue of how to facilitate work on the OpenID Connect specs
Disussed writing specs in more generic way and put specifics and options in
extension specs separately later.
- Nat/John agree that extension should be part of a WG and should not be done
willy nilly
John suggested pushing Lite spec to implementor's draft first.
- Nat says not a good idea
Breno to find time to rework/collaborate on Session Management spec.
Nat will try to find resource to help Breno in next few days
Current spec set is the following:
Messages (merge of former Core, Framewor, and UserInfo)
Standard (Binding for Messages) - to be written
Lite (Minimal Binding spec for RPs)
Session Management
Registration
Discovery
OpenID Connect Discovery: http://openid.net/specs/openid-connect-discovery-1_0.html
OpenID Connect Dynamic Client Registration: http://openid.net/specs/openid-connect-registration-1_0.html
OpenID Connect Lite: http://openid.net/specs/openid-connect-lite-1_0.html
OpenID Connect Session Management: http://openid.net/specs/openid-connect-session-1_0.html
OpenID Connect Messages - not yet available
OpenID Conenct Standard - not yet available
<http://openid.net/specs/openid-connect-framework-1_0.html>
All available specs are in SubVersion at http://svn.openid.net/repos/specifications/connect/1.0/.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110805/92456629/attachment.html>
More information about the Openid-specs-ab
mailing list