Extension proposal for last call period

I would like to propose a possible extension to P3P 1.0.  This extension is
designed primarily to afford easier compliance with the Child Online Privacy
Protection Act (COPPA) in the US.  However, I believe it would be quite
useful outside of this context as well.

My proposed extension deals with the mechanism provided by P3P to declare a
piece of data required or optional.  COPPA, simply put, does not accept such
a simple designation.  COPPA uses a concept, which I think of as
"independence of services", that functions as follows:

Each service a web site offers to its users requires some set of personal
data, without which the service cannot reasonably function.  COPPA mandates
that if a web site offers multiple services that require different (but
possibly overlapping) data sets, a user must be allowed to consent to the
collection of only the personal data that is required for whatever
service(s) the user wants, without consenting to the collection of data
required by the unwanted services.

In order to provide this functionality for a privacy policy, it is extremely
helpful for a site to be able to list the specific pieces of data that are
required for each service offered.  Thus, a user can choose to permit the
collection of only the data that is absolutely neccessary.  There are
several possible ways to implement this using P3P as it now stands, but each
has flaws:

1. Create separate privacy policies (and thus separate P3P documents) for
each individual service.  From a technical standpoint, this seems to be a
completely reasonable solution.  From a practical point of view, however,
most sites only want to have one privacy policy to maintain.  In addition,
having multiple privacy policies opens the way for different policies on a
given site to conflict with one another and possibly create legal
liabilities.

2. Create a single privacy policy, but use the existing optional attribute
in the data element.  This attribute would be set to "no" only in those
cases where every service offered by the web site required a particular
piece of data.  Unfortunately, in many cases, this would not be very helpful
(virtually all info on a portal site would be optional by this definition).

3. The purpose element of the statement could contain an 'other' element
with a list of the names of services requiring the data:

<statement>
   <data-group>
      <data (attributes here) />
      <purpose>
         pusposes here
         <other>list of services here</other>
      </purpose>
   </data-group>
</statement>

In some cases, multiple pieces of data will be used by the same set of
services, and thus can be grouped together in the code example above.  But,
the worst (and possibly common) case requires the separation of each data
element into its own statement in order to specify the services for which it
is required.  Even if this is acceptable, an extension is still needed in
order for user agents to understand what the list of services in the other
element actually represents.

I propose strengthening the optional attribute of the data element by
allowing the data element to contain a new element, possibly called
"required-group", that would in turn contain one or more "required"
elements.  Each required element would have either the name of a service, or
possibly some unique identifier that would reference a  "service" element
found elsewhere in the document.  This scheme would allow user agents to
identify the minimal set of data a user would need to consent to the
collection of in order to use the desired set of services offered by a web
site.  It would also allow web sites to comply more fully with COPPA's
independence of services requirements, or simply to offer users a more
complete picture of how their data is used.

I have only very recently read the P3P spec, and I might be missing
something here.  So, if anyone knows of a better way of dealing with this
problem, especially in terms of COPPA compliance, I would appreciate some
feedback.

Thanks,

Jason Axtell
Software Engineer, Fujo, Inc.
jasona@fujo.com

Received on Tuesday, 25 January 2000 20:55:59 UTC