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

[janusz sienkiewicz <janusz@libertyrms.info>]

I am in favour of solution [3] the one with <doNotDisclose> element.

For the client side the attribute based approach and <doNotDisclose> approach
introduce the same level of complexity. For the server side the attribute based
approach is more cumbersome. The server has to check all object elements in epp
request to determine if there are any discrepancies from default disclosure
policy. The <doNotDisclose> approach leads to a simpler algorithm. The server
has to check just one element to find all relevant information.

I would suggest a modification to <doNotDisclose> approach. The approach in its
original shape is not symmetric for all registry implementations. For example a
registry that does not disclose any contact information has to use more complex
xml syntax than the one that discloses all contact information.

The following changes should introduce more symmetry and flexibility:

(1) The default disclosure behaviour for various object mappings should be a
part of server policy.  The server could inform the client about its policies
through <dcp> or any new response element.

(2) <doNotDisclose> element should be replaced by <disclose> with boolean flag
attribute (<disclose flag="no">).



Similiar symmetry issue exists in attribute based proposal. The default values
of dnd attributes for domain, host and contact object
mappings should be a part of server policy.


Janusz Sienkiewicz

"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