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
