W3C home > Mailing lists > Public > public-p3p-spec@w3.org > April 2003

RE: [Agent/Domain] brainstorming

From: Humphrey, Jack <JHumphrey@coremetrics.com>
Date: Tue, 8 Apr 2003 17:11:37 -0500
Message-ID: <85063BBE668FD411944400D0B744267A025182FD@ausmail.core.coremetrics.com>
To: "'Dobbs, Brooks'" <bdobbs@doubleclick.net>, public-p3p-spec@w3.org


The basic problem I'm trying to address affects business agents as well as
domains owned by the same entity, and it is that there is no way to declare
those relationships so that a user agent can make better decisions about
applying restrictions.

A secondary problem is that an agent might indeed just be collecting data on
behalf of the PRIMARY entity (e.g. the service/site with which the user is
actually interacting), and therefore want to augment the first party's
policy instead of defining it for them. 

Not sure I see your point about the Dobbsco agent cookie being a shared
resource across multiple entities. If the agent uses an identifier in a
dobbsco.com cookie, but does not use that cookie to link data across its
clients, then we're back to the linked versus linkable argument.

In any case, even if the 1:1 exists, it might not necessarily be proper for
Dobbsco (the agent) to declare itself to be Gatesco (the first party). For
example, the Dobbsco agent might want to declare certain ways in which it
uses the data in a non-identifiable way (e.g. administrative purposes), but
defer declaration of the ultimate purposes of the collection to Gatesco.

But let's suppose that Dobbsco declaring itself to be Gatesco was okay --
it's not possible now to do that in a way that indicates to the user agent
that Dobbsco is not a true third-party, is it? (assuming that we're talking
about a dobbsco.com cookie set in the context of the gatesco.com web site)

It seems to me that there's more accountability if the policy on the agent
site can refer to a policy posted on the first party site, instead of
declaring the first party's policies on their behalf.


-----Original Message-----
From: Dobbs, Brooks [mailto:bdobbs@doubleclick.net]
Sent: Tuesday, April 08, 2003 4:07 PM
To: 'Humphrey, Jack'; public-p3p-spec@w3.org
Subject: RE: [Agent/Domain] brainstorming

I guess I am still confused what problem we are attempting to address.  My
concern is that there should not be a method of obfuscating the traditional
declaratations via the use of some type of an AGENT token.  If data is being
"used" in given ways the fact that it was collected by an agent is really
immaterial in that it is still expressible under given syntax.

So I have always taken it that if I, e.g. BrooksCo was acting as an agent in
say a Site Analytics or Ad Serving capacity for GatesCo and providing a
pairing of unique identifiers back to GatesCo (say  a cookie id and an
identifier meaningless to me but identifiable to Gatesco) that the correct
declarations would be perfectly expressible under current syntax:
ENTITY: has to be Dobbsco the agent unless acting in a 1:1 capacity soley
for Gatesco in other words the cookie is not a shared resource across
multiple other entities for whom Dobbsco is acting as an agent.  If a 1:1
exists then simply have the entity described as Gatesco.
RECIPIENT: OURS (unless Gatesco provides the data externally and then modify
from their perspective)
ALL the rest in accordance to how GATESCO is using the data...  if dobbsco
has no rights to the data and is only acting as a processor the only duty I
see for him is to get from Gatesco what the correct statements would be.

Not sure but are we attempting to come up with a token that in effect says -
"I am not sure what Gatesco is doing with data, I am just the collector and
not using it myself?"


Brooks Dobbs
Director of Privacy Technology
DoubleClick, Inc.

office: 404.836.0525
fax: 404.836.0521
email: bdobbs@doubleclick.net

-----Original Message-----
From: Humphrey, Jack [mailto:JHumphrey@coremetrics.com]
Sent: Monday, April 07, 2003 4:28 PM
To: public-p3p-spec@w3.org
Subject: [Agent/Domain] brainstorming

There haven't been any responses to my previous attempt to get this
discussion going, so I'm going to attempt to summarize my view of the
problem and the ideas I've had so far. I look forward to some discussion.

I'd like to schedule a conference call of the task force for this week, so
if you think you'd like to be involved, please email me directly.

- Business agent: an entity that acts on behalf of another entity
- Business domains: list of DNS domains or hosts that are owned (directly or
indirectly) by a single entity
- First-party business: entity providing the primary site or service with
which user is interacting
- Third-party business: separately-owned entity that may have access to data
collected during user's interaction with first-party business
- Third-party context: non-primary domains that are owned by either: the
first-party business (other business domains), business agents for the
first-party business, or third-party businesses

The basic premise I'm working under is that user agents should only restrict
true third-party businesses, not sites/services provided by the first-party
business or its agents. We should consider changes to the specification for
required/recommended user agent behavior as well as the more fundamental
changes (discussed below) to make it possible to describe these

- Agent: how to denote that it is an agent of the first-party business
- Agent: how to denote which data is collected on behalf of the first party
- Agent: how to denote that purposes are stated in the first party policy
- Agent: how to denote that a domain belongs to an agent acting on behalf of
the business and should not be treated as a third-party domain
- Domain: how to denote that other domains are part of the same business and
should not be treated as third-party domains
- How to map these changes to compact policies
- How does policy reference file need to change

- Ability to denote agent status (in ENTITY element as addition to business
- Ability to list business domains (in ENTITY element?)
- If not otherwise specified, a domain in the third-party context should be
considered a third-party business and restricted as such.
- New recipient element (e.g. "<FIRST-PARTY>") for an agent's policy, to
denote that data is being collected on behalf of the first-party business
- Ability for policy to reference the first-party policy that should apply
(e.g. URI attribute on new recipient element)
- New purpose element (e.g. "<FIRST-PARTY-USES>") for an agent's policy, to
denote that data will be used for purposes declared in referenced policy
- New P3P HTTP header to reference first-party domain or business domains
list, or compact policy token(s) to force use of full policy

Jack Humphrey
Received on Tuesday, 8 April 2003 18:11:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:17 UTC