RE: Registrant Access (Data Protection/Privacy)

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

Thanks for taking this on and offering this up as a proposal, Eric.

My question: how should "not persistent" be interpreted in the context of
associating social information with other objects?  I looked at the P3P
ACCESS element definition (1) for clues, and saw nothing that helped me
understand.

(1) http://www.w3.org/TR/2000/CR-P3P-20001215/#ACCESS

<Scott/>

>-----Original Message-----
>From: Eric Brunner-Williams in Portland Maine
>[mailto:brunner@nic-naa.net]
>Sent: Monday, April 09, 2001 1:41 PM
>To: ietf-provreg@cafax.se
>Subject: Registrant Access (Data Protection/Privacy)
>
>
>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 
>