I think this means that the Selector MUST implement async firing capability. A user should not wait nor should this be syncronous. Likewise if a session has already been logged out, then by "contract" then the RP should simply ignore.
-----Original Message----- From: Johannes Ernst [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 2:25 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: Logout That might be hard from a usability perspective, and in my experience, the underlying user requirement tends to be a variation of "I am about to go to lunch with the guys waiting in the hall way, log me out of all apps I'm currently logged in but take no more than 10 seconds because otherwise they will leave without me. Or at least the critical ones." (which is where it gets hard to design this right) Where sessions come in is that again from a usability perspective, the user should not have to "log out" from apps that he currently isn't logged into (because the session expired, for example). On Apr 6, 2007, at 10:51, McGovern, James F ((HTSC, IT)) wrote: I would think that you wouldn't need to track the notion of a session but have something where the selector that tracked where the card was previously sent in terms of a list would allow you to graphically send another event. You could optionally walk a list based on each card. -----Original Message----- From: Johannes Ernst [ mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 12:29 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: Logout So far, neither OpenID nor CardSpace define the notion of a session, so no common logout is possible within the standard protocols. What we do in our code at NetMesh is to add a convention where RP-URL?lid=OPENID is the same thing as "submitted OpenID URL in the first form", to which the RP-URL responds with a redirect to the OP, while RP-URL?lid= means "become anonymous again" aka "logout". There are substantial usability issues with common logout in a decentralized, "internet-scale" approach, however, that nobody has really solved as far as I know. ************************************************************************* This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************************* _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
