John,
For a while, I was rather reluctant to support checkid_immediate simply because of the log-off issue. For that to work, then one obviously had to have some notion of being "logged on" at the OP. So, I thought about it for a while. and all of the issues you raise are valid. What I decided to do (as I described) seemed to be the simplest approach and that made the most sense to me. I would not, for example, want the action of logging out of Facebook to log me off of Slashdot. So, I preferred to go with your option (a). I clearly had no way to do (b) or (c) anyway, but I would not want that behavior. With the model I am using, users would have to be told where to go log off the OP, which is why I made that location the same as the ID used to log in. That seemed most logical. Still, it does concern me to some extent that people might forget to go log off and stay logged into the OP. One can then close the browser and walk away. Somebody else can come to the browser and type www.facebook.com and they're automatically logged in (thanks to checkid_immediate). So, I'd say the option to remain logged in and to respond positively to checkid_immediate should be considered carefully. It's a nice feature to have if users understand it. It's just not clear that they would. Paul From: John Bradley [mailto:[email protected]] Sent: Monday, May 24, 2010 12:04 AM To: Paul E. Jones Cc: 'Dick Hardt'; 'OpenID Specs Mailing List' Subject: Re: OpenID v.Next Core Protocol Charter That is a reasonable approach and can be done within the existing spec by best practices if OPs support checkID immediate. the problem tends to be the scope of a logout button at the RP. Should that: a) only log the user out of the RP b) The RP + the OP c) The OP + all RP the user is logged into. SAML has two methods for c using front channel using http redirects. This is unreliable because users tend to close browsers and this results in a unpredictable state. The other is to use a back channel approach where the OP directly messages each RP that the user has logged out. It works better but is more complicated. A better approach would be for session cookies to be easily identifiable in the browser and give the user a reasonable UI for removing them. That would be protocol independent. Some RP are also hesitant to allow a 3rd party that is not the IdP to initiate the users logout. What is Facebook could send a message logging out users from Google and Microsoft without the users consent? SLO has traditionally been part of federations where it is covered by legal agreements. The hardest part is getting the user to understand what is happening at a logout button. Login is much simpler conceptually. I will have a look at your draft. My option B may be something that we might want to scope however many large IdP don't want users to ever logout. The complexities in SLO are more to do with user experience and politics than technology. I am OK with taking it on if there is a desire, but it should not block other progress. John B. On 2010-05-23, at 8:18 PM, Paul E. Jones wrote: John, What I did on my own server is, when I log in, I have a check-box that asks whether I want to stay logged in all the time. If I check that box, I return a cookie (over TLS) with a 30-day duration. When I visit an OpenID-enabled site and enter my ID, I don't get prompted for a password. Rather, the browser passes the cookie (again over TLS) and logs me in automatically. It also updates the TTL on the cookie. In effect, I stay logged in all the time. If I visit my OpenID URL, the server sees that I'm logged in and puts a "log off" button on the page. I can click that and the browser cookies get deleted and the server deletes the associated data. This works pretty well as a means of logging off. However, one still has to remember to log off from each application that might also utilize cookies to keep you logged in. If web sites only used session cookies with a relatively short TTL and OPs used cookies like I do, then clicking "log off" on the user's OpenID page and the closing the browser should effectively serve as a log off for all applications. It does make use of "cookies" and some people feel cookies are terribly evil, but for managing session state (i.e., associating users with browser), it seems to be a fairly reasonable solution - especially if the cookies are secure. TLS provides that, though we need something better for HTTP. I wrote a draft for that, but it's not moved too far in the IETF (yet): http://tools.ietf.org/html/draft-salgueiro-secure-state-management Paul From: [email protected] [mailto:[email protected]] On Behalf Of John Bradley Sent: Saturday, May 22, 2010 12:58 PM To: Dick Hardt Cc: OpenID Specs Mailing List Subject: Re: OpenID v.Next Core Protocol Charter Single logout is notoriously difficult to get correct. SAML has never managed it. I support looking at it as a option or extension, but would not want to hold up the core spec for it. Other protocols have expended large amounts of time on it without a solution that can be understood by the users properly. John B. On 2010-05-22, at 8:47 AM, Dick Hardt wrote: Great point Torsten. If there is interest in exploring single logout, then it likely belongs in this WG. Are others interested in exploring single logout? -- Dick On 2010-05-22, at 2:30 AM, Torsten Lodderstedt wrote: does this or another group consider to incorporate some kind of single logout support into OpenId? regards, Torsten. At IIW yesterday I held a session on bashing the OpenID v.Nest Core Protocol Charter. Below is the current draft. Comments and/or questions welcome. Anyone interested in being a fellow proposer please let me know and I will add you. -- Dick (a) Charter. (i) WG name: OpenID v.Next Core Protocol. (ii) Purpose: Produce a core protocol specification or family of specifications for OpenID v.Next that address the limitations and drawbacks present in the OpenID 2.0 that limit OpenID's applicability, adoption, usability, privacy, and security. Specific goals are: . define message flows and verification methods, . enable support for controlled release of attributes, . enable aggregation of attributes from multiple verifiable sources, . enable support for a spectrum of clients, including passive clients per current usage, thin active clients, and active clients with OP functionality, . enable authentication to and use of attributes by non-browser applications, . enable the use of public key technology to enhance scalability and performance, . enable optimized protocol flows combining authentication, attribute release, and resource authorization, . define profiles and support features intended to enable OpenID to be used at levels of assurance higher than NIST SP800-63 v2 level 1 , . define an extension mechanism . ensure the use of OpenID on mobile devices, . ensure the use of OpenID on existing browsers with URL length restrictions, . complement OAuth 2.0 . minimize migration effort from OpenID 2.0 . seamlessly integrate with and complement the other OpenID v.Next specifications. Compatibility with OpenID 2.0 is an explicit non-goal for this work. (iii) Scope: Produce a next generation OpenID core protocol specification or specifications, consistent with the purpose statement. (iv) Proposed List of Specifications: OpenID v.Next Core Protocol and possibly related specifications. (v) Anticipated audience or users of the work: Implementers of OpenID Providers, Relying Parties, Active Clients, and non-browser applications utilizing OpenID. (vi) Language in which the WG will conduct business: English. (vii) Method of work: E-mail discussions on the working group mailing list, working group conference calls, and face-to-face meetings at the Internet Identity Workshop and OpenID summits. (viii) Basis for determining when the work of the WG is completed: Work will not be deemed to be complete until there is a consensus that the resulting protocol specification or family of specifications fulfills the working group goals. Additional proposed changes beyond that initial consensus will be evaluated on the basis of whether they increase or decrease consensus within the working group. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope. (b) Background Information. (i) Related work being done in other WGs or organizations: OpenID Authentication 2.0 and related specifications, including Attribute Exchange (AX), Contract Exchange (CX), Provider Authentication Policy Extension (PAPE), and the draft User Interface (UI) Extension. OAuth, OAuth WRAP, and OAuth 2.0. OpenID Connect proposal. SAML 2.0 Core and SAML Authn Context. (ii) Proposers: Dick Hardt, [email protected] (chair) Michael B. Jones, [email protected] Breno de Medeiros, [email protected] Ashish Jain, [email protected] George Fletcher, [email protected] (iii) Anticipated Contributions: None. _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
