On Mon, Jun 7, 2010 at 2:27 PM, Peter Watkins <[email protected]> wrote:
> On Mon, Jun 07, 2010 at 01:26:53PM -0700, John Panzer wrote: > > On Mon, Jun 7, 2010 at 1:13 PM, SitG Admin > > <[email protected]>wrote: > > > > Intent differs from effect. Breaking privacy to encourage browsers to > fix > > > it for you is provocative, whether meant to be so or not. > > > OK. To be clear, I do not believe that XAuth breaks privacy. > > Do you mean that your current, centralized XAuth implementation doesn't > break > privacy, or that your "end game" desired XAuth would not break privacy? > Both. > > > I think it would be great to have a discussion about privacy and security > > aspects of XAuth. Which should start with a discussion about what attacks > > we're worried about preventing, and how XAuth affects them. As an > example, > > there could be a security concern that knowing that I have an active > session > > with Google may help phishers know which identity provider to simulate > when > > I go to their site. Or, there may be a concern that XAuth will help > sites > > broadcast the fact that I have a "session" with them to the world, and > thus > > expose linkages I would prefer not to have exposed. Or there may be > worries > > that XAuth would allow sites to 'spam' my list of available IdPs if they > can > > get me to visit them. These are all certainly issues, but they require > > individual discussions, and it's not clear to me that moving > functionality > > to the browser affects any of these issues in a fundamental way. > > Exactly. That's why I ask about "current" vs "end game". Do you think those > concerns are not significant enough to say that the current XAuth "breaks" > privacy, or do you imagine some browser-based intelligent XAuth system that > would defend against those attacks? > I don't think they add significant risk to the status quo. Note that it is today possible for a rogue RP and rogue IdP to collude to leak your identity with or without XAuth. XAuth provides mechanisms to allow IdPs to whitelist the RPs they'll expose information to. IdPs can also require user opt-in to turn on XAuth. I don't think it's that useful to require opt-in for services used by more than 50% of the population, but it could be useful for myownname.com personal IdP. I think that browser support would make some things easier -- perhaps defending against "pretend" IdPs that use social engineering to get themselves on your IdP list -- but (a) those attacks aren't privacy issues and (b) they appear low value to me. I will agree that things would be more secure if we encased every client computer in concrete with no 'net connection and sank them to the bottom of the ocean. > > If you take these privacy & security concerns seriously, why not document > them the way Mozilla's Account Manager project does? > > https://wiki.mozilla.org/Labs/Weave/Identity/Account_Manager/Spec/Latest#Security_Considerations Sir, I am but one man. And XAuth isn't even my project. But yes, I think that http://groups.google.com/group/xauth should discuss security considerations and document them. > > I haven't given a lot of thought to this, but it appears to me that the > current XAuth setup isn't some rough draft of an oversimplified account > management mechanism that could easily be extended or improved. It looks > to me like a pretty mature, feature-complete system. I mean, you seem > pretty > tied to some very specific HTML5 tech in XAuth, and adding more > intelligence > or controls to make XAuth more "private" doesn't look very straightforward > to me. Would browsers treat postMessage() calls to an XAuth resource > differently than other HTML5 postMessage() calls? > No. I'm envisioning that browsers would directly replace the higher-level JS API so there would be no postMessage() calls at all. Why would there need to be? The providers just need to call setters and the relying parties to call getters (or queriers). > > BTW, I think it's a little sad that Google is pushing this early > centralized > model for gaining "deployment experience" when you could bake this into > Chrome > and Firefox extensions (or even release custom builds of Firefox) to test > the > system with decentralized code. > Sure, we could host extensions at xauth.org. And then people could download them. From, um, a centralized site. How is that more decentralized exactly? > > -Peter > >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
