From: Phillip Hallam-Baker [mailto:[email protected]] Sent: Tuesday, April 12, 2011 5:50 PM To: Trevor Freeman Cc: Leif Johansson; [email protected] Subject: Re: [plasma] why not web portal mail?
Agreed, but not actually an issue. If we have a collection of data in a database that is controlled under the secret#example.com<http://example.com> policy we might have an infinite series of permutations and subsets that could be drawn from the database. [TF] I do think we need to store the logic tree of how the policies are expected to be combined. I have come across scenarios where the policies are a logical AND as well as scenarios where the policies are a logical OR. That needs to be persisted with the data. We don't need to standardize the expression of the secret#example.com<http://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. [TF] Agreed. The point of Plasma is that process is opaque to the client. All the client should get is a series of references from the server of polices the user can assert which amounts to a list of stings. We need a machine readable sting and a sting for the user. 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'. [TF] Yes I think we only need define a few standard actions such as sign the thing. We also need to define obligations on policy binding for derivative data. In some cases you can change it or remove it, other you can append to it, etc. 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. [TF] Defiantly don't need to standardize the policy language in Plasma. We only need to standardize the reference to the policy itself. We may want to standardize discovery of keys. The round trip to the plasma server is time consuming which is not a problem for the client but is for a server. If I want to preauthorize access to the email e.g. an AV scanning service for the domain, then we need to find their keys before we send the email. What we need in the PLASMA standard is the range of moves used to implement the policy. [TF] If by that you mean how to I interact with the policy server and what does it expect me to do, yes. 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. [TF] Embedding the policy with the data is a bad idea became it presents an unsolvable maintenance problem. Data has a habit of getting copied and moved to all sorts of locations. If the policy changed then you cannot track down every copy. On Tue, Apr 12, 2011 at 6:52 PM, Trevor Freeman <[email protected]<mailto:[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]<mailto:[email protected]>] Sent: Tuesday, April 12, 2011 12:31 PM To: Trevor Freeman Cc: Leif Johansson; [email protected]<mailto:[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]<mailto:[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]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Leif Johansson Sent: Tuesday, April 12, 2011 7:21 AM To: [email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/plasma _______________________________________________ plasma mailing list [email protected]<mailto:[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
