Subject: RE: "private" Element Attribute

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 21 Oct 2002 12:40:31 -0400

Eric,

I knew I was going to regret reopening this issue, but the IESG hasn't
bought the "we've been through this and what you see is what we came up
with" argument.

Regarding the domain example I gave, your guess was correct: it could mean
that the registration event itself must remain undisclosed.

> 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?

I don't think that would do the trick.  The DCP stuff is in there and has
been for a while, yet Randy still asked the question.  I don't think it
addresses Randy's concern, even if we added additional elements to describe
more narrowly scoped server policies, based on the conversations I've had
with Randy and Patrik over the last few days.  Randy (and now Patrik)
believe that what is missing is a mechanism for a user/registrant/etc. to
flag individual elements that need to be protected in accordance with some
stated policy.  Blanket acceptance of whatever the stated policy might be
doesn't appear to address their concern.

-Scott-

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 21 Oct 2002 13:56:53 -0400

> bought the "we've been through this and what you see is what we came up

It could be worse. when I attempted to assist a current and former member
of that august body on a memo on the mechanism for http state management,
their responses were something along the lines of "we don't need help, we
are the IESG", or something significantly less cheritable.

Before we take our first step down this bunny trail we need to know if what
we are creating a mechanism for is a policy assertion by a registrant, or a
registry, or some intermediary, AND, if the policy can be observed in its
instantiation. The exection value of a "Do/Will not give FOO to Martians"
policy claim, wheather by the source of FOO or the sink of FOO is slightly
harder to evaluate than "Do not s/FOO/BAR/", at least in the case where the
source has access to the sink sufficient to detect non-tampering with FOO.

Now I think that adding these to <recipient> are sensible:

	<dns/>	(after all, that was the point, neh?)
	<whois>	(possibly several permutations, ARIN just published theirs
		 today, e.g., :43, uwho, arin, ripe, ++, ...)

I'm open to revisiting the <dcp>, so that it is no longer an announcement
mechanism for data collectors, but something that has manditory error
semantics (if present), e.g.,

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

causes a server error condition if the server-registry announced (regardless
of the scope of the announcement, a seperate topic) <dcp> is inconsistent
with the user-registrant asserted (new term) "data surrender policy" <dsp>.

Which default for no <dcp> (it is optional after all) is a choice. It could
mean "do whatever the user asserts", or "ignore asserts". The better choice
may be to make the <dcp> manditory, then deal with <dsp> != <dcp> cases.

I think this is a way to meet this:

	... what is missing is a mechanism for a user/registrant/etc. to
	flag individual elements that need to be protected in accordance
	with some stated policy.

Now we just need to decide if this is the protocol's job with the server
performing detection and enforcment (see error, above), or if the protocol's
job is to transport data which has access control, independent of the server.

	Blanket acceptance of whatever the stated policy might be doesn't
	appear to address their concern.

Error semantics give them what they need.

I'm at a loss to figure out why granularity smaller than the social/technial
split on the contact object is something Randy/Patrik/... are keen on.

Just to keep a straight face on the value of privacy, this isn't a function
that anyone appears willing to invest in. I've made $0.00 in the area since
the bubble burst, it seems to be everyone's violin d'ingres.

Oh well, at least the Silverbacks aren't calling it "Security", so some bit
of forward progress has been made since Pittsburg.

Cheers,
Eric

P.S. In P3P-esse, they are asking for a binding form of APPEL. Hence policy
negociation, or at least error semantics.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Oct 2002 10:23:33 -0400

On Mon, Oct 21, 2002 at 01:56:53PM -0400, Eric Brunner-Williams in Portland Maine wrote:

> Before we take our first step down this bunny trail we need to know
> if what we are creating a mechanism for is a policy assertion by a
> registrant, or a registry, or some intermediary, AND, if the policy
> can be observed in its instantiation.

It seems to me that the historic goal of the WG has been to be
agnostic about policy; and that whether registrants or registries get
to enforce the policy is itself a policy question.  But maybe the
answer (at the expense of yet more complexity) is to do something
analogous to the server*Prohibited/client*Prohibited status values? 
I don't really know, and I can't think of any firm proposals right
now; but would that help, in any case, to address the concern?

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                         +1 416 646 3304 x110

---

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

Andrew,

The <access> element asserts that the collector allows the originator
read-access to some datum.

Now P3P doesn't actually specify how this is provided, and hence how
the originator could detect a policy other than the assertion made in
the <access> element, that is, if <all/> were stated, and the originator
found that the actual read-access was <none/>, we've no way of knowing,
let alone attempting to "enforce" the <all/> assertion.

We are graced with <info>, so we actually can use <access> and <info> to
enforce data consistency within the EPP provisioning chain.

When a registrant changes her contact data, she can <push> that delta on
the registry (and possibly registrar) records, so she and not the registry
is the authoritative holder of the data, and the upstreams (registrars and
registries) simply consistent caches of her contact data.

So, unlike P3P for web sites (and cookies and Xforms and ...), we can move
beyond announcement to announcment plus evaluation of the truth value of
the announcement (for some things), which is necessary to enable any form
of protocol-based  enforcement (as opposed to dumping lawyers on the target
registry from some reasonable altitude).

Earlier Dan asked if anyone was implementing <dcp>. I haven't looked at your
client code in ages, are you?

Eric

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Oct 2002 22:16:37 -0400

On Tue, Oct 22, 2002 at 11:18:57AM -0400, Eric Brunner-Williams in

> client code in ages, are you?

I understand from the relevant developers (I'm just a lowly database
guy) that there has been some implementation work on this in the most
recent server iterations.  We're working on getting the server to
work first; the client will follow, I suppose.  

A