Re: Updated (and hopefully the last) EPP Privacy Proposal

[Joe Abley <jabley@isc.org>]

1. "do not disclose" seems non-extensible, when extensibility seems 
important.

There seems to be more than one party to whom disclosure could be 
controlled:

   + the registrant (unlikely!)
   + the sponsoring registrar (unlikely!)
   + non-sponsoring registrars
   + parties who have reliably identified themselves
   + parties who have agreed to abide by some terms and conditions
   + parties who have paid for access
   + parties who have not exceeded a threshold of data retrieval
   + parties within (or not within) a specific jurisdictional domain 
(e.g. a country, or a state)
   + parties specifically specified by the data owner
   + other defined groups
   + everybody else

There is also the potential to control disclosure according to the 
retrieval mechanism (web page, whois server, bulk export, etc).

Given that the addition of new "do not disclose" semantics has the 
potential to touch every field relating to domains, hosts and contacts, 
it seems reasonable to try and get this reasonably correct in the first 
cut. Hardly any of those questions need to be answered by the EPP spec, 
but the EPP spec should not prevent them from being answered.

The "dnd" functionality needs to be extensible in order to be useful, I 
think. I can't think of a way to make that happen using attributes.

2. A complete proposal should specify whether a "dnd"d field should be 
distinguished from a non-existent field when presenting data to clients 
(e.g. via <info> commands). If it should, then the proscribed manner in 
which that should be done should be included for <info>.

3. What should <check> return if the object being checked is marked as 
dnd="true" and the client doing the <check> is one to which disclosure 
is prohibited?

4. I like the <doNotDisclose> functionality you described in your 
earlier message more than the <noWhoIs> in your more recent message: 
<doNotDisclose> is a better name, and I think you want the <noWhois> to 
enclose the <extension>, rather than the other way round? A separate 
element also gives greater scope for extensibility.

The dnd attribute proposal looks implementable now, but I have doubts 
about whether the coarse functionality it provides is actually useful. 
The reasons those doubts bother me is that future revisions to the dnd 
functionality are going to touch a lot of fields within the schema, and 
it would be nice to avoid wholesale schema and data migration problems 
in the future if we can.

The <doNotDisclose> idea looks more extensible, and I think it is a 
more promising approach.

It might be worth mentioning that neither of these proposals touch the 
base EPP spec. I don't see how privacy concerns should stop the base 
EPP spec from proceeding, when it seems clear that their scope is 
limited to the object binding specifications which deal with data.


Joe

On Monday, Dec 30, 2002, at 09:08 Canada/Eastern, Hollenbeck, Scott 
wrote:

> 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