P3P comments on XForms 1.0 last call

Gentlepeople,
this is the official review by the P3P Specification Working Group of the XForms 1.0 Working
Draft (http://www.w3.org/TR/2002/WD-xforms-20020118/ ), currently in Last Call.

The P3P Specification Working Group, after analyzing the XForms specification, has identified 
two major issues ("P3P-HOOK" and "P3P-DATATYPES"), explained below, and feels that both 
issues should be appropriately tackled before XForms can advance.
Other minor comments follow.

Best regards,
-Massimo
 on behalf of the P3P Specification Working Group



--------------------------------

ISSUE "P3P-HOOK" :

XForms (optionally) associates a form to a P3P policy reference file, via the "privacy" element. 
P3P is mentioned in two parts of the document:
- in Section 3.7 (Privacy):
> Element privacy is used to associate a P3P [P3P 1.0] policy reference with a particular form.
- in 4.2.2. (default processing for the xforms:modelInitialize event):
> 2. If applicable, P3P has been initialized. [P3P 1.0]"

This is a rather short description, and what this actually means is not extremely clear.
Trying to interprete, the intended behaviour should be that the privacy element allows to 
reference a policy reference file, that in all likelihood pertains to the form: so, this 
covers that portion of the URI-space where XForms' submitInfo lies (including "action", 
but also "method"). Note en passant that interaction between XForm's "method" and P3P's "METHOD"
should be further clarified, as they are different. And maybe, a requirement that the policy reference 
file SHOULD pertain to the pointed action-method (however defined) is in order here too.
Moreover, confusion with the P3P's policy concerning the URI where the xforms lies could arise
(incidentally, note that P3P now supports XHTML as well, so this could be profitably mentioned).
So, all this should be stated with a more detailed and precise description, and already some
possible troubles come up.

But, just trying to be more formal and precise, another problem creeps in here, and it's part 
of the more general problem of other applications trying to define hooks to P3P.
Think again of the inteded behaviour stated above: now, what's the behaviour
where that same part of URI space is covered eg by a P3P header, referring 
to a different policy reference file? What are the precedence rules for a P3P agent?
The point is that XForms' "privacy" element is introducing another way for an application
to locate a P3P policy reference file, but it is unclear how a conforming P3P agent should behave
in this case (since this method is not in the P3P spec). 
Different solutions are possible, each with its pro's and con's: the P3P Specification working group 
feels therefore that this important issue should be a matter of further discussion and coordination 
between the working groups, until a satisfactory solution is found.

--------------------------------

ISSUE "P3P-DATATYPES" :

XForms now allows to associate some meta-information to each piece of data it collects. This includes
structural information (using XML Schema). But, alas, it doesn't include semantical information,
that can be made readily available using P3P's dataschemas.
XForms could seamlessly provide this kind of information by adding an (optional) attribute (e.g., 
to <caption>) where one can attach to the datum a P3P semantic datatype (that is referenceable
by using a URI). This is the route already followed by, for example, CC/PP.
This would have many benefits, as intelligent UI's and agents could then have much more 
meaningful information on what fields are collected, and act appropriately. For example, part
of an xform could be evaluated wrt a privacy policy with a finer level of granularity.
Also, *automatic fill-in* of form fields could be possible, eg interacting with e-wallets.
Even, this could simplify writing and maintaining P3P policies when dealing with many complex and 
time-changing xforms: one could just write a generic "catch-all-data" P3P policy for xforms 
and be more precise on what data is collected not in the P3P policy, but in the specific xforms. 
Therefore, the P3P Specification WG strongly encourages introduction in XForms of P3P semantic datatype
information.

--------------------------------

Other minor comments:
(note these comments refer to the current version of the XForms spec; dealing with the "P3P-HOOK" issue
could in fact make some of these minor remarks just not applicable).

+ The xlink:href attribute of xform's <privacy> is optional: it probably makes more sense to make it 
  mandatory (since <privacy> itself is optional).
+ Multiple "privacy" elements are possible, but this can only be derived from the XForms schema, and 
  it not mentioned anywhere else in the specification (in any case, behaviour in presence of multiple 
  policy elements should be explained).
+ The P3P ref in the bibliography, eventually, should be updated. 
+ The P3P ref should be put in the normative references, and not left in the informative ones.

Received on Thursday, 21 February 2002 18:57:06 UTC