Hi Brian, It might make sense for OIX to run xauth.org - however I haven't seen a real proposal yet.
As David points out, there are some real unresolved issues (operational, governance, liability, etc) that haven't been sorted out yet. Allen On 6/8/10 11:29 AM, "Brian Kissel" <[email protected]> wrote: > Are folks opposed to the OIDF or OIX running the domain? Don has > suggested that in the past. If not them, any other suggestions? > > Cheers, > > Brian > ___________ > > Brian Kissel > CEO - JanRain, Inc. > [email protected] > Mobile: 503.342.2668 | Fax: 503.296.5502 > 519 SW 3rd Ave. Suite 600 Portland, OR 97204 > > Increase registrations, engage users, and grow your brand with RPX. Learn > more at www.rpxnow.com > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Allen Tom > Sent: Tuesday, June 08, 2010 11:24 AM > To: Eran Hammer-Lahav; John Panzer > Cc: [email protected] > Subject: Re: XAuth critiques > > I think that nearly everyone agrees that many of the UX, privacy, and > security issues that we have today with internet identity could > potentially > be solved using new identity features baked into browsers. > > However, while we wait for users to have browsers that support these > features, is there something that we can deploy today? Xauth could be an > interim solution until we do have support in the browser. It is > conceivable > that browsers could reuse the same Xauth JS interface. > > Again - I don't see why we can't work on both server based and browser > based > solutions in parallel. > > Regarding the privacy issues of having a centralized domain - the > overwhelming majority of sites already deploy centralized JS that already > correlates users across domains - so in this respect, Xauth is really > nothing new. Ad networks, website analytics, and "Like" buttons are just a > few examples. > > As far as I know, all of the serious proposals for using Xauth is just to > store the user's OP preference - a simple boolean flag that indicates that > the user behind the browser happens to be concurrently logged into a > particular IdP. This is already "public" information that some IdPs > already > support - for instance both Facebook and Google already support this > today: > > Facebook Connect Status: > http://wiki.developers.facebook.com/index.php/Detecting_Connect_Status > > Google's openid.ui.mode=x-has-session: > http://code.google.com/apis/accounts/docs/OpenID.html#Parameters > > The only new thing in Xauth is that RPs can just query a single API > (potentially loaded entirely from the browser's cache) to check all IdPs > where the user could be logged into. This is information that RPs can > already get by directly querying each IdP. The only difference is that > Xauth > can reduce the network overhead of checking the login status. > > It is true that there are serious challenges with having a centralized > domain - who runs this domain? How is it governed? Where does the data go? > These are real issues - however they're not really technical issues, and I > think they can be solved, if a "trusted third party" can run it. I still > have yet to see a serious proposal to actually run this domain though - so > perhaps this is not realistic. > > > Allen > > > > On 6/7/10 10:17 PM, "Eran Hammer-Lahav" <[email protected]> wrote: > >> >> If Google, Yahoo, Microsoft, and the rest of the companies supporting > the >> OpenID effort deployed the server-side half of this proposal, and spent > a >> little money on developing plug-ins for all the major browsers (with > Google >> and Microsoft able to also include it in the next release of their > browser), >> it will create the tipping point in getting some form of identity > selector in >> the browser. > > _______________________________________________ > 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
