W3C home > Mailing lists > Public > public-tracking@w3.org > August 2012

Re: Service Provider Status (ISSUE-137)

From: Rob van Eijk <rob@blaeu.com>
Date: Thu, 30 Aug 2012 22:39:11 +0200
To: <public-tracking@w3.org>
Message-ID: <0035dec071530065b2eeaf72172d5150@xs4all.nl>
We are dealing with entities processing data on behalf of multiple 
first parties for a myriad of purposes.

Since Issue 137 is a TPE issue, why not use the technical argument of 
machine-readable identification of service providers at the moment they 
are processing data on behalf of the first party? If the argument is 
that a legal policy is close by, you avoid a technical solution. Isn't 
the task at hand in the TPE to contribute to transparancy on a HTTP 
transaction level?

Rob


Roy T. Fielding schreef op 2012-08-30 21:07:
> On Aug 29, 2012, at 12:17 PM, Jonathan Mayer wrote:
>
>> Some possible status ambiguities for service providers.  All are 
>> solvable with trivial engineering.
>
> You seem to forget that service providers are acting on
> in the place of a first party.
>
>> -If a service provider is using its own domain:
>> 	-Is the entity a first party, third party, or service provider?
>
> It is a first party.
>
>> 	-Which party is it providing outsourcing services to?  (Might be 
>> multiple parties in different roles.)
>
> The party that owns the URI in the policy link, which is
> required for this case.
>
>> -If a service provider is using a different party's domain (e.g. a 
>> CNAMEd analytics service):
>> 	-Who is the service provider?
>
> See the first party's policy information.  There is no need for
> a machine-readable identification of service providers while
> they are acting in the place of a first party.  If there is,
> please explain why there is no equivalent identification of
> subsidiaries and employees within non-service provider first
> parties that will be handling the request on behalf of their
> controlling interest.
>
> ....Roy
Received on Thursday, 30 August 2012 20:39:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:54 UTC