RE: Operator Identity

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Nick,

OUR-HOST and same-party define domain hosts only, whereas you need a complete Url to both define the origin (https is not the same as http), and give the full path. You need the full path for the mutual referral, I.e. to identify a resource which in turn returns a header or a meta tag with its own Operator-Identity. Mutual referral is key to allowing APIs to break Same Origin Policy restrictions, this is similar to the way CORS allows cross-origin communication.

You have to be able to refer to non HTML returning resources, e.g. images, so you cannot rely on returned data in  the response, that is the reason for the response header. This is similar to the mechanism in CSP, and I borrowed the meta tag from CSP2 for the same reasons that has it. In some circumstances a shared CMS might not be able to return a client company’s identity in a response header so then you need to do it with HTML i.e.  the meta tag.


Mike




From: Nicholas Doty [mailto:npdoty@w3.org]
Sent: 02 December 2014 21:36
To: Mike O'Neill
Cc: public-tracking@w3.org; David Singer; Roy T. Fielding; Anne van Kesteren
Subject: Re: Operator Identity

gpg4o
 Unknown Signature from 40203EE90BBAB306 1 2 01 1417556178 9
 
 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>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJUfkTqAAoJEHMxUy4uXm2JeLkH/2per6735vu4ggjqPl2K8Tuw
vwrYQxDhYYSlU0OZYFnOsJJfm58XSRcokNovu5J1I7DOg15JFWj7LJcKdcqYScIi
snr8GNZp9RV1y9eaHCOzH2nkYvsI0tT8oI0fxF1ALksk+UUpMgyWDrk12YqSps/k
9I/UrgQJKbKIqdKEsX+4IElGAbd8h9oxMrQab2ltvmWMLNii9QIYZrwxlegtR3nT
71cVTkMHdslySDh5SQ4RyzmmZWYoKhBQTZAxjYCBiTKcVspZTo7TUUPUFnDbJWfN
Fz616Vpb86L2cVLweZf8d2c2NtC3WIMJuXd4sdnBHH6T5ZkyTD/svb9+7aGHHFM=
=dxsi
-----END PGP SIGNATURE-----