[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Mon, 16 Dec 2002 14:44:04 -0500
Sender: owner-ietf-provreg@cafax.se
Subject: Another Privacy Proposal

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>jdoe@example.com</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-

Home | Date list | Subject list