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-