I am opposed to the OIDF running it. Might make sense for OIX, but I am not involved in that organization.
On 2010-06-08, at 11:31 AM, David Recordon wrote: > I am opposed given that it's unclear how the operational costs would > be covered and there is increased liability since whomever runs the > domain could do something malicious with the data. At least the OpenID > Foundation isn't setup to provide this sort of infrastructure today. > > --David > > > On Tue, Jun 8, 2010 at 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 >> > _______________________________________________ > 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
