Updated (and hopefully the last) EPP Privacy Proposal

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

In ongoing background discussions with the IESG regarding our EPP documents,
we (Jaap, Ed, several IESG members, and I) have continued to talk about the
IESG's privacy-related comments and the responses to those comments that
have been sent to the WG mailing list.  We've concluded that we need to add
a "must implement" feature to the protocol to allow data elements to be
tagged with a binary indicator of data owner preference for disclosure of
information to third parties that aren't involved in the provisioning
transaction.  Back in October [1] I described a proposal to use an XML
attribute for this purpose.  Over the last few weeks ([2], [3]) I suggested
a few other options.  Considering all of our options, I would again like to
suggest an XML attribute-based approach to address this last remaining IESG
review issue.

This does not mean that the binary indicator is the only way that privacy
preferences or policies can be expressed.  Expression of more specific
privacy policies can be accomplished using the protocol's extension
mechanism.

The proposal is to add a new attribute to every object element in the
domain, contact, and host mappings.  This boolean attribute, "dnd" (for Do
Not Disclose), will be used to note that the value of an element should not
be disclosed to third parties.  It will have a default value of "false"
(meaning it is ok to disclose info) in the domain and host mappings, and a
default value of "true" (meaning it is NOT ok to disclose info) in the
contact mapping.  The defaults can be over-ridden and explicitly specified
by clients.  Additional constraints can be defined using the protocol
extension mechanism.

Here are some examples:

<contact:email dnd="true">jdoe@example.com</contact:email>
<contact:email>jdoe@example.com</contact:email>
Both of the above mean "do not disclose this email address to third
parties".

<contact:email dnd="false">jdoe@example.com</contact:email>
This means that the data owner gives permission for the email address to be
disclosed to third parties.

<extension>
  <noWhois><contact:email></noWhois>
</extension>

(This extension example isn't syntactically valid, but I wanted it to be
short, clear, and to the point without the clutter needed to make it valid.
In this case it means that the email address should not be published via
whois.)

I'll also have to add some notes to explain that server policy might not
recognize the value of an attribute if it's turned on (like in the email
address example above) when turning on the attribute is counter to some
policy.

A measure of WG support or dissatisfaction with this proposal would be
helpful.  Would you please send a note to the mailing list to let the chairs
know if you either support the proposal as a way to move forward or if you
do not support the proposal?  If you do not support the proposal it would be
helpful if you explained why and could suggest modifications (if possible)
to make it acceptable.

If you do not support the proposal, please recognize that we have been stuck
on this issue for quite a while and we need to do something.  On the one
hand, we are aware of the differences in privacy policy, laws, et al. facing
each registry.  On the other hand, we are being asked to define one standard
protocol that is rigorous enough to not let privacy slide by.  So the
question is - does this proposal (including extension support) allow for all
known policies to be expressed within EPP?

-Scott-

[1]
http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00041.html

[2]
http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00089.html

[3]
http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00093.html