More comments on Aaron's notes from the IM. Specific to mention of P3P
in the requirements portion of the IM notes. Inline, with elipses (...)
> Issue 9
> -------
> Trusted vs. untrusted data flows.
...
> Does this affect the design of the object?
...
> The idea behind this distinction is to "thin" the policies that
> need to be written, and thus reduces the emphasis that is placed
> on privacy NOTICES (see P3P discussion below).
Meta-comment: The P3P discussion in a subsequent section of the IM
notes seemed odd. Perhaps this is my problem, one of over-familiarity.
Perhaps this is a problem of the note taker, one of reducing to writing
a complex oral narrative. In any event, p3p is a mechanism for the
announcement (not negociation, not enforcement, not ...) of data collection
practices, with a vocabulary that appears to afford a mechanism to express
the three major dc policies (EU, OEDC, US), that isn't restricted to http{s},
and has an XML syntactic representation, and a similar compact representation.
It does not address the problem space of onward-transport, which the CPEX
(non-W3C) standard attempts, and which is mentioned obliquely in the SOAP
and XML discussion.
Someone asked me earlier why I mentioned APPEL as potentially relevent to
this WG. I mentioned APPEL because that is where expression of user
preferences for subsets of all possible data collection practice policy
statements finds any of several "default" values.
Compare: Eric's (or Randy's) default _disclosure_ rules (APPEL),
and DoubleClick's (or USG's) default _collection_ policies (P3P).
End Meta-comment.
...
> Aside:
> ------
> This raises a NEW QUESTION about the design of the protocol:
>
> How is this information about trust being conveyed? Does
> the object carry the policy?
This was the point of adding Section 4 to the P3P Specification.
As an implmentation issue, the evaluation of a policy provided by
other means that is necessary to determine if the data collection
practices associated with a cookie are non-trivial. Self-policied
objects are simpler to evaluate.
As a protocol design issue, forcing arbitrary evaluation and policy
fetch by some other means precludes scaling policy to high-volume
non-trivially policed objects (English: kills cookies, may have the
same effect on other species of pastry).
> This is an open question. There is a sense that there should
> be some policy in the object, but this is not a consensus.
Well, this is better than a consensus that no policy may be carried
on a geo-blob.
> Concern about the footprint of attaching policy to the object --
> both bandwidth and processing power may limit how fully rules
> can be expressed.
The controlling issue here is syntax. In draft-jaye-http-trust-state-mgt
we figured we could easily shove all the policy bits remotely applicable
to cookies into 8 bits, but the PILC constraint for wireline browsers is
hardly this limiting, particularly when you look at the other junk that
is beinging sent to the browser.
I thought I raised the issue earlier, but I could be mistaken and this
really is a NEW QUESTION.
> Issue 17
> --------
> Is it out of scope to specify a policy language for geopriv?
>
> Analogies to presence work. This may be inadequate -- geopriv
> would like to have at least some pieces of policy traveling
> with the object to control disposition after initial
> access authorization.
>
> Presence does allow watcher info (SIP-specific) -- a list of
> identities that can be updated or will update a user upon
> change in presence.
>
> An outstanding question:
> -----------------------
> Is there an existing system that can be reused for this purpose?
> SIP, IMPP are logical protocol options. Is P3P or a subset
> thereof suited to the task?
Ignoring for the moment the syntactic form of a P3P 1.0 data collection
policy statement (XML pasted on URIs, with exceptions), or the semantic
problem of evaluation (within a DOM tree, with exceptions) --
what part of the vocabulary (purpose, recipient, retention, ...)
are applicable?
what part are not?
> Geopriv should have the simplest possible relationship
> to the internal maintenance of policy servers, policy retention, etc.
Heads Up (which everyone is free to ignore)
The temporal properties of policies (duration, renewal, expiry, non-uniqueness)
are more complex than they appear.
Thanks for the IM notes.
Cheers,
Eric
Received on Tue Jun 25 11:48:03 2002
This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:23 EST