Subject: "private" Element Attribute

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 21 Oct 2002 10:08:29 -0400

A heads-up to the WG related to IESG comment #8, described here [1]:

In the ongoing IESG discussion of our EPP documents, we (Patrik and I) have
come to the conclusion that we might need to add a new attribute to every
object element in the domain, contact, and host mappings.  This boolean
attribute, "private", 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.  Additional constraints can be
defined using the protocol extension mechanism.

Here are some examples:

<contact:email private="true">[email-masked]</contact:email>

<domain:name private="false">example.com</domain:name>

<host:addr ip="v4" private="true">192.1.2.3</host:addr>

<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.)

Patrik's point is that we start getting into the policy issues that bogged
us down earlier if we try to pick and choose the elements to which the
attribute should be added.  That's a good point that can get us past where
we failed a year or so ago, but it means that server operators might have to
deal with some operational inconsistencies.  We'll 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 address example above) when turning on the
attribute is counter to some policy.

If anyone has any issues with this approach, please mention them now.

-Scott-

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

---

From: janusz sienkiewicz <[email-masked]>
Date: Mon, 21 Oct 2002 10:58:50 -0400

Wouldn't it be more convenient to redefine private attribute as enumeration
versus boolean? For example:

could be replaced by:

<contact:email access=enumValue>[email-masked]</contact:email>

Where enumValue could be: private, public, noWhois, etc.

Among other petential benefits this approach could eliminate the inconvenience
of using <extension>.

Regards,

Janusz Sienkiewicz

---

From: Mike Lampson <[email-masked]>
Date: Mon, 21 Oct 2002 11:41:46 -0400

Scott,

Would "private" object elements appear to non-sponsoring entities
(Registrars) when they issue the "info" command?

My preference would be that "info" would only show non-private object
elements to non-sponsoring entities *unless* the non-sponsoring entity has a
valid AuthInfo code.  This allows the elements to remain private, but also
allows for the values to be disclosed to another Registrar if they have been
provided the correct AuthInfo code.  While this isn't necessary at a
protocol level to initiate a transfer, it is necessary at an administrative
level so that the potential gaining Registrar knows whose domain they are
actually transferring.  (It's better to verify that the Transfer is being
initiated by a current contact for the domain rather than a former employee
or other individual who may have somehow acquired the AuthInfo code.)

I expect that once a "private" attribute is implemented at a Registry that
you are not going to see just phone numbers and email addresses marked as
private, but entire contacts will be marked as private.  Hence my
recommendation for the "info" comand to show everything when a valid
AuthInfo code is included.

Just my 2cents,

Mike Lampson
The Registry at Info Avenue, LLC
(Really a Registrar, not a Registry)

----- Original Message -----
From: "Hollenbeck Scott" <[email-masked]>
To: "'ietf-provregcafaxse'" <[email-masked]>
Sent: Monday, October 21, 2002 10:08 AM
Subject: "private" Element Attribute

Here are some examples:

<extension>

-Scott-

[1]

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 21 Oct 2002 12:27:22 -0400

Scott,

This is "policy".

I proposed moving 954 to historic, so there would be no "IETF Impremature" for
repurposing social data. Bob Braden seems to be of the view that changing the
status of 954 would make the protocol go away. I don't know how, but he had a
"third-rail" response when he saw the draft in the announce list. He wasn't
alone in thinking I'd come down with the IETF-equivalent to head lice.

What is out there, the ICANN zoo, data wholesalers, data miners, the EU
Directives, its beyond us.

I understand that Patrik wants to stick a bi-valued switch on each object in
the tree. Sic transit gloria whois.

This no more extensible than Hong's dohicky for registry-private (nexus and
purpose) policy cruft. It doesn't get extensible until schematized.

Unrestricted third-party access (with no guarantee of accuracy) comes from
the <recipient> element, with a value of <public/>.

We could add the pestilential form specific to the domain name industry,
mandated by 954 (which the RIRs sanely ignore, but ICANN is fixated upon),
and add a <whois> element as a child of the <recipient>, and even allow it
child elements.

The effect would be that registries that publish via 954 (private) data
could announce their (US DoD EXPIRED, ICANN CONTEMPORARY MANDATED) policy.

If the WG consensus is to adopt Patrik's proposal, I suggest that the better
default value is "true", not "false".

I don't think Patrik's proposal sensible. Here's the example from -07, with
interlinear comments, with an "or" passage:

  S:    <dcp>
  S:      <access><all/></access>
		(the originator can see his/her data, detecting error, OK)
  S:      <statement>
  S:        <purpose><admin/><prov/></purpose>
		("admin" and provisioning only, OK)
  S:        <recipient><ours/></recipient>
		(the data is provisioned only and apparently not published)
or

  S:        <recipient><ours/><public/></recipient>
		(the data is provisioned and published via :43)
  S:        <retention><stated/></retention>
  S:      </statement>
  S:    </dcp>

It appears that we ment publication via the zone file is implicit in <ours/>.

Now we could change the sense of <ours/> to no-publication, just internal
use, and add a <dns/> and a <whois/> for publication forms and allow dcp's
like these:

  S:        <recipient><ours/><dns/><whois/></recipient>
		(classical 954)
or
  S:        <recipient><ours/><dns/><whois/><public/></recipient>
		(classical 954 plus some non-43 publication, ala IM et al)
or
  S:        <recipient><ours/><dns/><whois/><unrelated/></recipient>
		(classical 954 plus bulk sale to cash-n-carry marketers)
or
  S:        <recipient><ours/><dns/></recipient>
		(a dns-only registry, yeah!)

There is an interesting nuance on one of your examples:

Why would this ever be "private"? Since we don't have a dns-or-whois flag
(yet), isn't every domain published (via dns)? Ans: This could allow the
private registration of names, moving strings out of the registry's string
space, without disclosing the fact that the string has been taken for non-
administrative purposes.

The problem is that there is an equivalency-class of registries (and also
of registrars) who MUST do whatever silly thing is in their business paper,
In particular, they must ignore jurisdictional claims which conflict with
the policies contained in their business paper, and must provide whois:43
in its US DoD form (actually in its MILNET TAC (strongest) form).

As wide-spread as this abuse is, it is not generic, it is not automatically
applicable to the ccTLD registries, who would have to be crazy to sign the
ICANN contract, and irrelevent to the RIR registries, a class of non-TLD
registries that may use EPP.

As with Hong's dohickey, existance or absence of whois:43 is registry-private
policy cruft.

Incidently, noWhois as a policy could be fulfilled and the email data sold
to 3rd-party marketers, or used to promote additional registry (or registrar,
or reseller) products and services.

More than one cork is required to keep a boat afloat that has two or more
holes. Shooting whois:43 in the head is always a good idea. Leaving the
registries free to not implement an optional <dcp> that would disclose the
bulk sale of customer profiles is not an equally good idea.

Since the additional attribute would not be "optional" (it has two defined
values), this (limited) form of "privay enablement" would be manditory to
implement, unlike the <dcp>, which we've left optional.

The proposal (bivalue attribute added to all elements) doesn't add function
not already present in the <dcp>, with the implicit nuance that <dcp>s have
EPP-session scope, which leads to an operational set-up/tear-down overhead
to delta the <dcp> on per-object basis.

I'm opposed. I'm opposed to a scopeless bivalued semantic addition. I would
not like the idea any better if the proposal was to color every element, so
long as the color was either black or white. 

Now Randy's point was different, the scope of some semantic. At present, we
have a <dcp> in a <greeting>, providing EPP-session scope to whatever sort
of data collection practices semantic we have. Could we make the granularity
scope sensibly smaller than EPP-session?

Sure.

A point of my query yesterday was that some data is participant-private, so
the access model for blobs-o-gunk during onward-transport from the originator
(registrant) to the (authoritative) repositor{y,ies} might not be uniform.
Suppose for a moment we'd wicked-good element-wise XML crypto, and the email
address ([email-masked]) was delivered to the registry encrypted. The registry
could transparently publish "[email-masked]", making Patrick happy.

Comments by Janusz (enum), and Mike (<info> affected) noted while writing.
Enum is not the answer, per Scott. <info> scoping and contact-private-creep
seems reasonable and probable, assuming an outcome I'd prefer not.

Eric

> Randy:
> 
> 8.
> why do domain/contact/.. not have granular information about privacy?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 22 Oct 2002 14:09:22 +0200

On Mon, Oct 21, 2002 at 10:08:29AM -0400,
 Hollenbeck, Scott <[email-masked]> wrote 
 a message of 42 lines which said:

> should not be disclosed to third parties. 

OK, privacy is a touchy subject and a complicated one. I would
disagree with such "ultra-simple" proposals that give the impression
we do something for privacy-conscious people while we do not really
address the full range of the subject. 

For instance, many people would agree that their coordinates are
displayed in reply to a whois query but not that they are included in
a bulk transfer of the database to a spammer (ooops, I mean marketer).

I suggest instead to rely on a function of EPP: the fact that you can
include XML elements which are not in the official schema. For
instance, P3P <URL:http://www.w3.org/TR/P3P/> elements could be added
in the EPP flow from the registry to the registrar and APPEL elements
from the registrar to the registry.

That way, we would build on an existing and documented and recognized
and quite comprehensive framework (managing its privacy preferences is
complicated enough that we do not introduce a new framework).

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 22 Oct 2002 09:50:57 -0400

Stepane,

No "ultra-simple" proposals. I agree.

Example, personally identifying information (PII) disclosure

	a) via whois:43 (or other forms of whois-like services)
	   to j-random query engines
vs
	b) via bulk transfer
	   to corporate members of the "other" IAB
	   (Internet Advertizing Bureau)

The user acceptance is based upon probability (assumed low so an
"acceptable risk") vs certainty. In the whois:43 list there was
evidence that the probability of PII harvesting from whois:43 is
high.

> include XML elements which are not in the official schema.

Please see the discussion of the data collection policy <dcp> element,
in the -07 draft. This stuff got formalized for us around the London
meeting.

Unless the APPEL draft has changed significantly (and I'll check, I've
got some P3P Spec WG due diligence to do anyway), APPEL remains a
mechanism for user agents like IE6 or Mozilla to attempt to acquire a
P3P policy from some P3P policy author. It isn't a mechanism to assert
some access/retention/distribution/... policy upon a data flow from a
UA.

> complicated enough that we do not introduce a new framework).

Hmm. I don't want to make the same (IMO) error of judgement that has lead
to people thinking someone has the only comprehensive framework for FOO,
e.g., the Unicoders and character sets. That said, covering the three basic
forms of policy (EU Directives, OEDC Guidelines, and US FTC) took the P3P
activity some time. We have an additional issue, jurisdictionalization,
which shows up in the ICANN gTLD vs IANA ccTLD policy claims at the protocol
level, and possibly elsewhere, e.g., in delegations below the top level.

We have some of P3P's vocabulary. What are we missing, and speaking to the
point made by Randy, what do we need to do to get element-wise properties?

I have to write something sensible for the p3p workshop this week, so if
anyone has any ideas they'd like me to noodle about, drop me a line. Here
what the Chair sent yesterday:

	I hope all of you have seen the information about the
	upcoming workshop on the future of P3P. If not, please
	take a look at http://www.w3.org/2002/p3p-ws/
	
	I hope that a number of you will participate. Officially
	the deadline has passed, but we do have room for
	more participants, so please let me know ASAP if you
	want to participate. This workshop will help W3C
	decide what sort of P3P-related efforts to continue
	in the future, so it is important that we get input from
	a diverse set of people. We expect the workshop to
	be more discussion than presentation, so participation
	from people in this working group who are familiar with
	what is in the current spec will be very helpful.

Kitakitamatsinopowaw, (see you all again)
Eric

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 22 Oct 2002 15:55:16 +0200

On Tue, Oct 22, 2002 at 09:50:57AM -0400,
 Eric Brunner-Williams in Portland Maine <[email-masked]> wrote 
 a message of 68 lines which said:

> P3P policy from some P3P policy author. 

Not at all and it never was. It is a mechanism to export privacy
preferences from the user to the database maintainer, exactly the
thing we want with the <private> element.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 22 Oct 2002 10:55:48 -0400

Stephane,

I spent 2000 working for a "grey hat" in the privacy area, Engage, a CMGI
company. Engage shares trade at about US$ 0.07 last time I looked, down
slightly from US$ 160. Bulk and transactionally acquired PII (deterministic)
or demographic (probablistic) data was my interest, cookies and other bits
of web cruft, and onward-transport of customer-profiles from web sites that
performed data collection -- oddly, quite similar to our own provisioning
chain.

In October 2000 the P3P Spec WG decided to split the APPEL draft out from
the P3P Spec. I was one of those who voted for this split, and never took
a look at APPEL subsequent. I really like Marc Langheinrich (editor), but
it was delaying getting P3P to W3C RC status.

This is simply to say I was writing rather carelessly about APPEL.

From the high-level blurb, written by someone(s) in the P3P Policy and
Outreach (non-techies):

	... P3P is a standardized set of multiple-choice questions ...
	... a standard, machine-readable format ...
	... enabled browsers can [evaluate a policy statement] ...
	... compare it to the [user]'s own set of privacy preferences.

Its a data collection practice announcement format specification, intended
for data collection implementors and policy evaluation implementors. It is
not a user preference announcement language, nor is it a mechanism to
negociate data collection practices.

From the high-level blurb, written either by Marc (editor) or Lorrie (chair):

	... the language for exchanging privacy preferences ...

	This document complements the P3P1.0 specification [P3P10] by
	specifying a language for describing collections of preferences
	regarding P3P policies between P3P agents.

In all the discussion I've had with data collectors and policy evaluation
engine implementors in 2000, 2001, and 2002 I can't recall anyone making
the case that a use-case for APPEL was communicating between the data
source and the data sink. It was always between data sources (users) and
between template providors (privacy advocates) and users.

I spent 2001 working for a gTLD operator that never really "got" privacy
and I expect engages in bulk transactions and otherwise repurposes user
data. Like others, but not all others.

Please let me know what makes sense for the .fr operator, and others too.

Eric

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 23 Oct 2002 14:26:29 +0200

> in the -07 draft. This stuff got formalized for us around the London

I was not there and I find nothing in the mailing list archive.

<dcp> has exactly the same problem: while it acknowledges the work of
the P3P WG, it tries to reinvent P3P, instead of using it. At the cost
of great complexity, EPP uses the whole XML zoo, including the ability
to add any XML element (not just those specified in EPP) in an EPP
element. Why not use <POLICY> and not <dcp>?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 23 Oct 2002 14:35:11 +0200

On Tue, Oct 22, 2002 at 10:55:48AM -0400,
 Eric Brunner-Williams in Portland Maine <[email-masked]> wrote 
 a message of 51 lines which said:

> the P3P Spec.
...
> not a user preference announcement language,

P3P, yes. Not APPEL.

> source and the data sink.

It was discussed on the W3C P3P-policy mailing lists. See the archives
at <URL:http://lists.w3.org/Archives/Public/www-p3p-policy/> for
instance the thread "Policy for an Internet registry".

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 23 Oct 2002 12:03:47 -0400

> I was not there and I find nothing in the mailing list archive.

Some was via voca during the WG face-to-face. Scott's provided pointers to
the WG list archive.

> the P3P WG, it tries to reinvent P3P, instead of using it.

We took some of the vocabulary. We didn't take the binding of p3p to
http, either in the URI (WKL) form, or in the subsequent forms for a
p3p header (I'm co-author of that in the p3p spec), nor in the later
forms (html link tag, xhtml link tag xform (pending CR)).

We took something quite close to the application of p3p's vocabulary to
cookies (compact policies) -- policy-on-apdu, not policy-on-uri, and put
<dcp>-on-session (sessionlessly on-object, I think).

> Why not use <POLICY> and not <dcp>?

For everyone's benefit, and this may not be current (shame Eric, shame!):
(from: http://www.w3.org/2000/10/XMLSchema.dtd)
<!-- ************* POLICY ************* -->
 <element name='POLICY'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <element ref='p3p:TEST' minOccurs='0'/>
    <element ref='p3p:EXPIRY' minOccurs='0'/>
    <element ref='p3p:DATASCHEMA' minOccurs='0'/>
    <element ref='p3p:ENTITY'/>
    <element ref='p3p:ACCESS'/>
    <element ref='p3p:DISPUTES-GROUP' minOccurs='0'/>
    <element ref='p3p:STATEMENT' minOccurs='0' maxOccurs='unbounded'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
   <attribute name='discuri' type='uriReference' use='required'/>
   <attribute name='opturi' type='uriReference' use='optional'/>
   <attribute name='name' type='ID' use='optional'/>
  </complexType>
 </element>

Meta-Issues:

a. Personally I don't think it helps us to mandate UTF-8 for a portion
   of the data between EPP endpoints,

b. We haven't mandated genuine P3P at the initial (to onward-transport
   via EPP) data-collection (registrar, or re-seller, or more
   generally, agent) site, and mandated getting the P3P at that point
   consistent with the DCP at the registrar.

c. We haven't mandated genuine P3P at the registry (recall, registries
   don't "talk" to registrants),

c. We haven't (yet) provided for transparent, or transparent subsetting
   of an instance of P3P to the EPP client from the EPP server, or
   the reverse in the case of APPEL-esque thingies I still haven't looked
   at.

<POLICY> Element Issues:

Numerous.

Please see <dcp>.

Eric