I have added investigating single logout to the charter. Paul: would value you participating around the feature once we have the WG started up -- hold these thoughts!
-- Dick 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
