Sounds good. I'm working on a draft. Once it's in a readable state, I'll post it for comments.
Thanks! On 2/19/08, Brett Carter <[EMAIL PROTECTED]> wrote: > > This is close to what I was thinking, however why not simply pass the > user's open id url to the external site, through some yet undefined > parameter. This way, there's little chance for cache poisoning. Passing > the open id url, the consumer site can just proceed with authentication > normally, using any cached data it has already. Also, I think IMG tags are > a better idea than IFRAMES, in another post. They're more compatible, for > one. > > > A point I didn't think of at first is that we have the converse issue of > being able to log out of federated sites as well. > -Brett > > > > On Feb 18, 2008, at 11:58 AM, John Ehn wrote: > > I think I've figured out the flow. It's seamless from the point of view > of the user. It will require explicit support from the Idenity Provider (on > top of AX), and the client website will need to have an AX update receiver > that supports this as well. No special support is needed in the web > browser. > > Turn on auto-logon on each site > > 1. Log into the relying party normally > 2. Site begins OpenID authentication, sends AX request asking for the > IsLoggedIn variable, and requests updates when the value changes. > 3. User selects whether or not they want this to occur (automatically > notify the site upon login) > 4. From the user's point-of-view, login now occurs automatically at that > site. > > Federated login > > 1. User logs in to OpenID Provider > 2. IsLoggedIn variable is updated with a pseudo-random value > 3. All sites subscribing to the IsLoggedIn variable are updated using AX. > 4. OpenID Provider displays a page loaded with hidden iframes pointing > to the same site URLs used for listening for AX updates. The IsLoggedIn > variable is included as an argument. > 5. Each site's iframe performs regular OpenID authentication using > the identity info already cached by the AX update receiver. > 6. As browser loads each iframe, it receives a standard login cookie from > each site. > 7. User can connect to each site and will be automatically logged in. > > Federated logout > > 1. User logs out of OpenID Provider > 2. IsLoggedIn variable is updated with a value of "false" > 3. All sites subscribing to the IsLoggedIn variable are updated using AX. > 4. Each receiving site expires the user session. > > Does this sound feasible? > > > On 2/18/08, John Ehn <[EMAIL PROTECTED]> wrote: > > > > This can be pretty easily done by piggy-backing on the Attribute > > Exchange extension. Have your OpenID Provider store a "IsLoggedIn" > > variable. When the value is updated, the OpenID Provider can update all the > > websites subscribing to the value. > > > > The tricky part is having the web browser be automatically identifiable > > from all of these supported sites. My first thought would be: > > > > * Store and send out the value in of the IsLoggedIn variable to all the > > websites > > * Give the browser multiple session cookies that are visible from each > > of the websites that the values was sent to, which contains a hash of the > > value plus the website URL. > > * When the website sees the cookie, it can take the cookie, generate and > > compare the hash. If the hashes match, automatically do an OpenID login > > * When the user logs out at the OpenID Provider, AX will update all > > subscribing websites, thereby logging the user out of all sites > > > > Although, I believe most web browsers won't let you store cookies that > > are visible from multiple sites. Perhaps someone more familiar with these > > mechanics and chip in? Maybe somehow detect the web browser's "signature" > > without involving any functionality in the browser itself? > > > > Thanks, > > > > John Ehn > > extremeswank.com > > > > On 2/18/08, Martin Paljak <[EMAIL PROTECTED]> wrote: > > > > > > > > > On Feb 18, 2008, at 5:11 PM, McGovern, James F (HTSC, IT) wrote: > > > > Likewise, I would think that for automatic signon, it would be a > > > good > > > > thing if the OpenID provider could tell the relying party how long > > > to > > > > leave an otherwise idle session open before timing it out. Not sure > > > if > > > > this would require an extension or not. > > > > > > expires_in from > > > http://openid.net/specs/openid-authentication-2_0.html#anchor20 > > > should do exactly this. > > > > > > m. > > > -- > > > Martin Paljak > > > http://martin.paljak.pri.ee > > > +3725156495 > > > > > > > > > _______________________________________________ > > > specs mailing list > > > specs@openid.net > > > http://openid.net/mailman/listinfo/specs > > > > > > > > > > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > >
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs