Subject: Another Privacy Proposal

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 16 Dec 2002 14:44:04 -0500

In continued discussions with the IESG around their privacy-related
comments, I've asked them to consider another alternative to address their
comments.  First, though, I should note that during the course of the
discussion we received a critical clarification: what they're looking to
have added is a means to identify data elements for which the data owner
would like to note that the data should not be disclosed to third parties.
"Third parties" means some entity other than the client and server operator.

Here's my idea:

We can add a new element wrapper that allows the client to note the specific
element values that should not be disclosed to third parties, like this:

<contact:doNotDisclose>
  <contact:email>
  <contact:voice>
</contact:doNotDisclose>

The definition of the wrapper would allow all of the data elements (like,
name, address, email, voice, fax, etc.) to be included, if desired.  The
element could be optional so that it wouldn't be present at all if no
restrictions are requested.  Here's what it might look like when
incorporated into a command to create a contact object:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
  <command>
    <create>
      <contact:create
       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
       xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
       contact-1.0.xsd">
        <contact:id>sh8013</contact:id>
        <contact:postalInfo type="int">
          <contact:name>John Doe</contact:name>
          <contact:org>Example Inc.</contact:org>
          <contact:addr>
            <contact:street>123 Example Dr.</contact:street>
            <contact:street>Suite 100</contact:street>
            <contact:city>Dulles</contact:city>
            <contact:sp>VA</contact:sp>
            <contact:pc>20166-6503</contact:pc>
            <contact:cc>US</contact:cc>
          </contact:addr>
        </contact:postalInfo>
        <contact:voice x="1234">+1.7035555555</contact:voice>
        <contact:fax>+1.7035555556</contact:fax>
        <contact:email>[email-masked]</contact:email>
        <contact:authInfo>
          <contact:pw>2fooBAR</contact:pw>
        </contact:authInfo>
<!-- New elements here. -->
        <contact:doNotDisclose>
          <contact:email>
          <contact:voice>
        </contact:doNotDisclose>
<!-- End of new elements. -->
      </contact:create>
    </create>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

I'll also have to come up with text to describe how this works, and to note
that how discrepancies between client-specified preferences and server
policies are addressed is a matter of server policy.  For example, if a
client says "do not disclose my email address", but the server operator's
policy is to publish that address in some publicly visible way, then the
server response to this kind of conflicting request may vary depending on
operational policies.

I'm still working this proposal through the IESG.  Does it sound like a way
forward to the WG?  Note that the IESG request is to include this sort of
facility in the domain and host mappings, too.

-Scott-

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 17 Dec 2002 10:02:34 +0100

On Mon, Dec 16, 2002 at 02:44:04PM -0500,
 Hollenbeck, Scott <[email-masked]> wrote 

> would like to note that the data should not be disclosed to third

Like every other proposal I've seen on this list about privacy, this
suggestion solves only a very small part of the problem. For instance,
it does not distinguish between individual access and bulk access by
third parties (while many registries, such as AFNIC for the .fr ccTLD
or the RIPE-NCC for their IP addresses database, allow unrestricted
individual access  but completely prohibit bulk access). Also, it does
not distinguish between the uses of the data (research, marketing, IPR
harassment, etc). 

I do not think it is possible to come with a reasonable
"one-paragraph" solution to this difficult problem. I suggest to defer
it to extensions, possibly using the P3P namespace and elements.

If a proposal like the last one is retained, I suggest to add the
following warning:

Some registries may use extensions or other registry-specific
mechanism (possibly out-band, such as local laws) to gather privacy
requirments. The lack of a <doNotDisclose> element MUST NOT be
interpreted as the complete absence of privacy requirments.