Agreed, but not actually an issue. If we have a collection of data in a database that is controlled under the secret#example.com policy we might have an infinite series of permutations and subsets that could be drawn from the database.
We don't need to standardize the expression of the secret#example.com policy or how it relates to the dataset. There might be constraints in there of the form 'fans of Lady Gaga can only download a maximum of 1000 items', there might be propositions that are nondeterministic, even undecidable. All an application ever needs to deal with is the consequences of that policy and those can be reduced to a small number of fixed actions plus 'call back for further instructions'. There will have to be a policy language of course. But the policy language itself does not need to be part of the standard. Its like the .NET specification, the byte code and the APIs are standard, but that infrastructure can support a vast array of languages. What we need in the PLASMA standard is the range of moves used to implement the policy. That is good in two ways, first it is more general and a better architecture, second it avoids the worst thickets of patent trolldom which obsess about the idea of moving the policy itself round with the data being controlled. That is a necessary approach for copyright enforcement which had to support offline devices and physical media once upon a time but not for content management in general. On Tue, Apr 12, 2011 at 6:52 PM, Trevor Freeman < [email protected]> wrote: > *Policy does not distinguish in what form the data is held. So > information persisted in email is subject to the same policy as the same > information persisted in a word document. * > > * * > > *Yes we have to bind data to some set of policies. The semantics for email > and documents are the same. * > > * * > > *Overall the Alice case you cited is too simple. A more realist example is > * > > * * > > *Alice has some data and wants to apply policy X and Y to her data * > > *Bob has some data and wants to apply policy Z to his data* > > * * > > *Policies X, Y and Z each defines a set of authorized recipients.* > > * * > > *Alice and Bob’s data had become comingled so now policies X Y and Z have > to be enforced.* > > * * > > *In an ideal world we would want to identify Alice’s and Bob’s data and > bind it to its respective polices. * > > * * > > *In a less than perfect world we may enforce access at the container level > which is an incremental improvement on what we have today. * > > * * > > * * > > *From:* Phillip Hallam-Baker [mailto:[email protected]] > *Sent:* Tuesday, April 12, 2011 12:31 PM > *To:* Trevor Freeman > *Cc:* Leif Johansson; [email protected] > > *Subject:* Re: [plasma] why not web portal mail? > > > > If we consider the Word, Excel and Diplomatic cables examples, the data is > static and to be controlled under a policy regardless of what channels it > might be transferred or transmitted through. > > > > The protocol requirement here in my view is to enable applications to > determine how to apply the security policy identified as X to the data > object Y. > > > > On Tue, Apr 12, 2011 at 2:41 PM, Trevor Freeman < > [email protected]> wrote: > > If you consider XMPP case it is easier because there is no expectation of > data persistence. It's a synchronous protocol where all parties are online > together exchanging information and that information is not persisted one > the session is ended. > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Leif Johansson > Sent: Tuesday, April 12, 2011 7:21 AM > To: [email protected] > Subject: Re: [plasma] why not web portal mail? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/06/2011 09:33 PM, Trevor Freeman wrote: > > Stephen Farrell asked why not use Web portal mail? Why do we need to > develop plasma? > > Maybe that question is easier to answer if we consider plasma for XMPP and > not just for email. There are important differences between XMPP and email > that make it much more challenging to build web-only versions of the XMPP. > > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk2kX+UACgkQ8Jx8FtbMZndeOwCcC1BQafbUXYLHJZKxsuAcV8eS > 6ukAnA0JGhMsLdmh+WG+GqEUoVMWj7+e > =5lPF > -----END PGP SIGNATURE----- > _______________________________________________ > plasma mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/plasma > _______________________________________________ > plasma mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/plasma > > > > > -- > Website: http://hallambaker.com/ > -- Website: http://hallambaker.com/
_______________________________________________ plasma mailing list [email protected] https://www.ietf.org/mailman/listinfo/plasma
