Also, we have been talking about OpenID connect most in terms of the login flow, but one of the differences between OpenID connect and OpenID 2.0 is that it attempts to make it easier to implement full session lifecycle management (e.g., all the proposed approaches provide a 'cookie' that RPs could choose to use and offload session management to the provider).
I would like to propose that "Provide better support for session management" be an explicit requirement for OpenID Connect, as it appears that existing formulations reflect the importance of this requirement. In that vein, there are other flows that have been discussed in regards to OpenID 2.0 that could be used as 'food for thought' for the OpenID connect effort. - A 'switch account' flow. RPs have had difficulties handling the husband/wife shared machine use case, where there is a mismatch between the currently signed user in the IDP and the user trying to login to the RP. - A re-auth flow (should come for free via PAPE translation effort which is already proposed) - Account properties exchange (e.g., account creation date, password reset date), which are useful signals about account hijacking activity and thus part of the account lifecycle management. - A sign-out flow (discussed on and off in OpenID mailing lists) - An account unlink/disconnect flow (raised at least once by FB in regards to OpenID) On Mon, Jun 21, 2010 at 18:58, Allen Tom <[email protected]> wrote: > Hi All, > > There¹s been a lot of discussion the past few weeks around specific > technical proposals focused on moving OpenID forward. We wanted to take a > step back and make sure that we understand the problems that there are broad > consensus around solving over the next six to nine months. While there has > also been some discussion around use cases and charters, there hasn¹t yet > been broad consensus. > > Today Yahoo!, Google, and Facebook met with some of the authors of Artifact > Binding, the OpenID Connect proposal, and OAuth 2.0 to discuss our specific > future requirements. We put together a summary document of 20+ items that > we would like to see and wanted to start a discussion around them. Today > helped to verify our instinct that we could achieve these OpenID goals by > layering features on top of OAuth 2.0 while specifically maintaining the > decentralized nature of OpenID. > > After this discussion it seems that the Connect work group charter can > encompass this work and thus provides a mailing list and IPR policy to work > on these items. Facebook, Google, and Yahoo! expect to be able to sign the > contributor agreements for the OpenID Connect working group relatively soon. > > We hope that other OpenID community members and organizations will provide > feedback on how this list compares to their needs and/or get involved in > flushing out the technical details. > > Here's the list of features that we would like to see implemented in a > future version of OpenID: > > http://wiki.openid.net/Future-OpenID-Technical-Requirements > > Feedback and discussion is more than welcome! > > Allen > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
