Re: grrp-reqs-06, 11. Security Considerations [3]

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

Scott,

Well I knew it wasn't added at my request as I recall mentioning onward
transport, jurisdictional issues, and data collection at San Diego.

You make two points:

	1. a mechanism capable of articulating a policy is not necessary
	   for session policing (A & I excepted, naturally), as contract
	   enforcement is available.

	2. a mechanism capable of articulating data collection policy or
	   the applicable jurisdiction of the data providor and collector
	   would be complex.

Having finished last November a consortia activity for the bulk transport
of customer profile data, which presumes the data originates from http
activity policed via P3P, and which looks dead similar to our notion of
social information, I'm convinced neither point is defensible.

Consider the case of intra-entity social data flows, the motivation that
brought IBM and HP to CPExchange, which is equivalent to the problem
NSI-as-Registrar and NSI-as-Registry-Operator face. How does contract law
protect the participants? J-Random-Reseller originates Registrant-J's data
to NSI-as-Registrar, which onward-transports J's data to NSI-as-Registry,
and a policy botch is detected. Is the remedy J or J-Random-Reseller forcing
NSI-as-Registrar to sue NSI-as-Registry for breach or specific performance?

Next, consider the case of inter-entity social data flows, without any
jurisdictional complications (67 RegistRARs and one Registry merrily
playing in CONUS only). No entity may make recourse to transaction- or
session-specific mechanisms to associate policy (other than A & I, sigh)
with any datum. Everything better look like a nail.

Finally, the above with jurisdictional complications, Sven Moers in Berlin
goes to a local reseller who uses Harald Alvestrand's Oslo-based regional
reseller who uses a UK-based Registrar to access a US-based Registry. All
hypothetical, but in real life Sven works at the Berlin Data Protection
office. Jurisdiction shopping (the communicating parties have some sort of
legal arrangement in place) will either be entertaining, or everything better
look like a Deleware Nail.

Do you assert that there no requirement for data collection considerations,
equivalent to your first point?

(as I understand your first point, typing words on someone else's keyboard
at least as error-prone as typing on myown keyboard)

If so then there is no reason to look at any mechanism to see if one or more
offer tractible solutions to an inextant requirement, however I can't help
but point out that from draft-jaye-http-trust-state-mgt-01.txt to Section 4
of the P3P CR draft we managed to express data collection in a few bytes,
and we've fewer than the old RIP limit on the number of hops-to-Registry, so
record route is also tractible, and if we look at the set of meaningfully
distinct statutory or contractual data collection practices, the range of
usefully unique identifiers hardly motivates OIDs or URIs or other junk
in-band.

I wouldn't have made the suggestion if I hadn't already written the dtds,
and morphing the syntax to asn.1 or bnf, or schema is standards overhead,
not operational overhead.

Eric

P.S. Just what exactly does [3] assert as a requirement other than there
     exists a mechanism exists to to distinguish technical from social
     information? When I read it I thought "that doesn't say anything the
     cutting room floor doesn't already say -- data that didn't get into
     the zone file". Delete for lack of distinct meaning.