- From: Paddy Byers <paddy.byers@gmail.com>
- Date: Wed, 23 Jun 2010 00:04:31 +0100
- To: Frederick.Hirsch@nokia.com
- Cc: public-device-apis@w3.org
- Message-ID: <AANLkTimi5gUDxhasQrMbhL9-PF_VbXcqV-kV61RWN5B2@mail.gmail.com>
Hi, I think the two objectives of: - separating definition of trust from definition of policy; and - adoption of XACML; may not be compatible with one another. Specifically, when we talk about separation of trust from policy, what we're envisaging is expressing a policy as two broadly independent parts: - a part that associates a set of subjects, characterised by defined subject attributes, with an identified "trust domain"; - a part that specifies the rights associated with a trust domain, eg as rules involving the defined resource attributes. We imagine that this would translate into two xml schemas, one for a document that is a "trust domain definition", and one for the "rights definition". This is the opposite of what XACML does - the entire polcy definition is in a single document, and constructs within that (eg the target of a policy, or the condition of a rule) can refer to subject and resource attributes equally. We already resolved that we would attempt to separate the two, and I think we should be trying to do this first in the logical model before thinking about specific xml representations. I think that will give us something that is clearly logically separated into the two parts, and each of these logical parts could naturally be represented in XML, but neither would be XACML. I am sure we could define a translation to XACML, but I don't think there would be a general translation in the reverse direction. The model in the BONDI input document is similar to the XACML model, but there are specific restrictions that make it easier to see how the trust domain and rights parts are separable (eg in a target of a policy or policy-set, only subject attributes are allowed, so these targets effectively correspond to the trust domains). Thanks - Paddy
Received on Tuesday, 22 June 2010 23:05:04 UTC