RE: [Agent/Domain] brainstorming

Jack,
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

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.

Terminology:
- 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
relationships.

Questions/Problems:
- 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

Ideas:
- Ability to denote agent status (in ENTITY element as addition to business
dataset?)
- 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
entity
- 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
Coremetrics

Received on Tuesday, 8 April 2003 17:07:14 UTC