[Openid-specs-ab] OpenID Connect Meeting at ForgeRock 27-Feb-14
Mike Jones
Michael.Jones at microsoft.com
Fri Feb 28 03:29:16 UTC 2014
OpenID Connect Meeting at ForgeRock 27-Feb-14
Allan Foster
Chuck Mortimore
Caleb Baker
Roland Hedberg
Mike Jones
Pamela Dingle
Chuck Mortimore
Greg Keegstra
Garyl Erickson
Naveen Agarwal
Guibin Kong
Breno de Medeiros
Justin Richer
Todd Lainhart
Agenda:
Testing/Certification
Public Interops and Demos
Session Management
Transition from OpenID 2.0 to OpenID Connect
Dynamic Registration
Testing/Certification:
Roland does have resources available to maintain and improve the test suite
He is already having parts of it rewritten and re-hosting it himself
Roland plans to add additional negative tests
Mike knows of several minor inconsistencies with the final specs that need to be corrected
Roland will deploy a version that lets unmodified IdP pages with JavaScript be used
This will let production OPs be tested - at the cost of the tester having to log in a number of times
It was agreed that we can use the test suite as a basis for self-certification
Roland can be at IIW and we can do in-person testing there
Mike will propose a few self-certification profiles
Public Interops and Demos:
Chuck asked whether we wanted to have public interops and demos
Public demos and interops are great forcing functions
They generates positive press
IIW May 6-8 is a good place to do actual interop work
EIC is the week after IIW - we could make noise about interop then
Public stuff should describe scenarios / stories, such as:
RP SSO
Mobile device using Connect for Authentication
Chuck could get an app running that can use multiple OPs
CIS July 19-22 we could announce initial self-certification results
Pat Patterson and Chuck are doing some OpenID Connect presentations in the next few weeks
Pam wants us to have some video presentations
Naveen said that there's an easy way to get an ID Token and Code from the Android account manager
He said that we could demonstrate that
Session Management:
We discussed issue #915 - Session 4.2 - Computation of OP session_state in the IdP requires origin URI
Google can register multiple origins
Just like multiple redirect URIs
As a result, the origin has to be supplied dynamically
The session state value needs to be a function of the origin it will be checked from
One possibility is another parameter expressing a cookie domain
Based on feedback from Google developers
The proposal to register one js_origin_uri is insufficiently flexible when clients have multiple redirect_uris
Breno would prefer that we reuse the dynamic redirect_uri to determine the origin rather than the js_origin_uri parameter
Breno is discussing another parameter in HTTP set cookie configuration format - RFC 6265
Example:
redirect_uri=https://login.yahoo.com/openidconnect
Want session state to also be valid at http://photos.yahoo.com
Domain: .yahoo.com, not secure
"secure", "login.yahoo.com"
"", ".yahoo.com"
OP needs to know ahead of time where cookie would be set
Chuck said that cookie policy is far more expressive than we want/need here
Breno doesn't want to invent a new security concept
We need the domain part and the secure/insecure part but not the other parts
Pam asked whether this information would passed dynamically or at registration time
Breno confirmed with his security people that using postMessage to convey one bit isn't a security problem
"changed" versus "unchanged"
Naveen reviewed some of Google's reasons for token caching
They are planning to have a GetToken JavaScript API call
We agreed that caching is still fluid and out of scope for the current Session Management work
We could later do this in another spec
Token caching provides more responsiveness to simply written RPs by avoiding network traffic, when possible
However, the caching API might not want to or need to do the polling that the current spec does
Having widgets have different Client IDs at different sites could be problematic for caching
Guibin presented Google's design thoughts about caching
It has parameters like crossTabs, crossDomains, crossClients, etc.
monitorClient(clientId)
fetchTokenResponse(clientId, request, forceRefresh, identifier)
Monitor Session State
Do we need additional parameters on logout for the multi-logout case?
Breno: We might be able to encode all the information needed in the session_state
Google currently passes an auth_user parameter, but they think they can get rid of that
Transition from OpenID 2.0 to OpenID Connect:
http://googledevelopers.blogspot.com/2014/02/welcome-openid-connect.html has pointers to info
https://developers.google.com/accounts/docs/OpenID#openid-connect describes Google's current migration approach
See "Migrating to OAuth 2.0 login (OpenID Connect)"
Use an openid.realm parameter in an OpenID Connect request
The realm is returned in the ID Token, which includes an OpenID 2.0 identifier
Nat is concerned that Google's current approach would allow a rogue OP to assert another OP's openid.realm
The RP would have to do discovery to prevent this
Or the OpenID 2.0 discovery document could publish the OpenID Connect issuer public key
Nat asked about a batch update operation
Specifying a list of OpenID 2.0 verified identifiers and returning the OpenID Connect identifiers
More work is needed on recommendations for transitioning
Dynamic Registration:
Google uses the Client ID to tie the client to a developer to prevent abuse
The developer is identified by a Google account
The account creation machinery tries to prevent bogus account creation
IMAP clients are a key use case
Google wants the IMAP client to be issued an instance ID tied to the user
They don't want a shared Client ID for all instances of the mail client
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140228/5dd3a3ea/attachment.html>
More information about the Openid-specs-ab
mailing list