Registrant Access (Data Protection/Privacy)

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

In a note sent to both the provreg and whois lists earlier this year,
Patrik Faltstrom mentioned registrant access in the context of data
protection. More recently, Sheer noted that while specific requirements
are "local", e.g., specific "data-access" functional requirements, the
abstract form is of general interest.

Here is a fragment (draft forthcomming, RSN!!!) on access policy and its
expression in ABNF (grammer representation of XML syntax) and in XSD.

Modified from http://www.w3.org/TR/P3P/#ACCESS [1]

The <ACCESS> element is defined as the ability of registrant to view
registrant originated data and address questions or concerns to the
registration service provider.  Registration service providers MUST
disclose one value for the access attribute.  The method of access is
not specified. (Note this has _nothing_ to do with whois:43 or whois:xx
"access", which is outside the scope of a provisioning protocol.)

The ACCESS element must contain one of the following elements:

	<social/>	access is provided to all social data only
	<technical/>	access is provided to all technical data only
	<all/>		access is provided to all technical and social data
	<noaccess/>	registrant data exists but access is not provided
	<null/>		registrant data is not persistent


The (P3P-consistent) ABNF for this is:

	access			=	"<ACCESS>"
					access_disclosure
					*extension
					"<ACCESS>"

	access_disclosure	=	"<social/>"	| ; socal data only
					"<technical/>"	| ; technical data only
					"<all/>"	| ; all data
					"<noaccess/>"	| ; access not provided
					"<null/>"	| ; data not persistent

This ends the modification of Section 3.2.5 of the current (CR'ed) P3P Spec
for a Registrar-Registry provisioning protocol, using XML element-attribute
formalism to deliver a provreg (work-in-progress) vocabulary.

At this point there are three issues to resolve:

	1. Does the set of access_disclosure attributes cover the R* problem
	   space discussed in the provreg WG list?
and
	2. Is the XML consistent with our current usage cases for XML encoding
	   of R* entity policy and registrANT data?
and
	3. Is "The method of access is not specified" adequate for this WG?


The first and third items are up to the R* implementors and observing protocol
and policy wonks to discuss.

The second item is partially addressed by the following xml schema fragment,
which does not (yet) have a general "POLICY" element within which to hang an
"ACCESS" element, or other elements, e.g., "PURPOSE" (also previously discussed
in this working group mailing list), "RECIPIENT", etc. I've used "abc" below,
it could just as well be "epp" or "xrp" or "abc".

<!--
Access element, modification of www.w3.org/TR/P3P/#ACCESS
-->
   <element name='ACCESS'>
      <complexType name="access-value">
         <sequence>
            <choice>
               <element name='social' type='abc:access-value'/>
               <element name='technical' type='abc:access-value'/>
               <element name='all' type='abc:access-value'/>
               <element name='noaccess' type='abc:access-value'/>
               <element name='null' type='abc:access-value'/>
            </choice>
            <element ref='abc:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
         </sequence>
      </complexType>
   </element>

Comments and corrections please.

Eric

References:

[1] The Platform for Privacy Preferences 1.0 (P3P1.0) Specification
W3C Candidate Recommendation 15 December 2000, Section 3.2.5 
http://www.w3.org/TR/2000/CR-P3P-20001215