- From: Nicholas Doty <npdoty@w3.org>
- Date: Tue, 2 Dec 2014 16:36:17 -0500
- To: Mike O'Neill <michael.oneill@baycloud.com>
- Cc: public-tracking@w3.org, David Singer <singer@apple.com>, "Roy T. Fielding" <fielding@gbiv.com>, Anne van Kesteren <annevk@annevk.nl>
- Message-Id: <DB0426B9-0EA6-4271-98C5-D52DDB6D596F@w3.org>
Hi Mike, Thanks for writing this up. I think we have two different existing mechanisms that are intended to solve this particular use case (of indicating multiple domains that actually belong to the same organization, or party). P3P defined OUR-HOST: http://www.w3.org/TR/P3P11/#oho_ex DNT defines same-party: http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#rep.same-party I'm uncertain whether either of those are or are likely to be used. We have identified that there may be some issues with keeping such a list up to date if you're a large organization. And more relevant, sites are unlikely to go to the trouble of indicating their party lists unless they see a concrete advantage to doing so. DNT suggests that that's possible depending on how user agents treat unaffiliated domains that all claim first-party status, for example. I don't see that we need a third mechanism to solve this problem. Mike, if there is a difference, can you explain why this would be more useful than existing solutions? As you note, it might make more sense to take this to a different deliverable or different WG, but I think the same question will apply. Thanks, Nick P.S. HTML attachments to emails to public-tracking actually do have Web-accessible permalinks, e.g.: http://lists.w3.org/Archives/Public/public-tracking/2014Dec/att-0000/OperatorIdentity.html We can also host files on w3.org if necessary, but I think typically it's not necessary, and depends on getting me to commit the files, which is probably an unnecessary roadblock. On December 2, 2014, at 3:22 PM, Mike O'Neill <michael.oneill@baycloud.com> wrote: > Signed PGP part > In the last call I promised to expand on the idea for self-referral as a more general purpose way to extend the confirm, or store, APIs to other origins. It took a bit longer than I thought, and it needs loads more work but here it is. > > It is an HTML formatted text file using ReSpec script and I have attached it to this. I do not know how to upload it to the W3C site to make it is available via a link, so it is on our website here, http://baycloud.com/Operator-Identity > > This may be useful for other APIs so I have written it as a stand-alone Member submission for a stand-alone spec. document . What I suggested was that, if we decided we had to lose the “cookie like” domain property from the property bag following Anne van Kesteren’s LC comment, we could refer to a new spec (similar to this one) which would allow cross-origin access for same parties and service providers. > > I originally thought it could leverage the WebApps Security WG Content-Security-Policy but the fundamental purpose is different enough that maybe it should be in its own spec. I shamelessly borrowed from CSP2 anyway. > > If anybody think it is worth pursuing I can carry on working on it. > > Mike > > > <PGPexch.htm><OperatorIdentity.html><PGPexch.htm.sig><OperatorIdentity.html.sig>
Received on Tuesday, 2 December 2014 21:36:27 UTC