[XACML] Privacy & Security

[JMaclean@affinitex.com]

Title: [XACML] Privacy & Security

The following attempts to summarize where we are at with privacy and security issues.  We seem to have consensus on the first three items.

1 - Authentication
Authentication betweens parties and systems is non-normative.  Clients will mostly authenticate their PDPs and also PDPs should authenticate their clients and each make its own trust decisions on what sensitive data gets sent, and whether confidentiality should be taken into account during communication.  Authentication may happen in many ways, co-located code, private network, VPN, DSIG, etc.  It is up to the implementers to determine the appropriate level and method of authentications.

2 - Transmitting XACML Policy & Assertions
Any security concerns or requirements related to transmitting or exchanging XACML statements are outside the scope of the XACML standard.  While it is often import to ensure that integrity and confidentiality of XACML is maintained when they are exchanged between two parties, it is left to the implementers to determine the appropriate mechanisms for their environment.

3 - Anonymity
The SAML Privacy and Security document went into a lot of detail on the issues around anonymity of the person making SAML requests.  Theses issues are not with in the scope of XACML and we will remain silent on these issues.

These next issues are stilling being debated.

4 - Integrity of Policy
It is important to ensure that the policy statement have not altered since they were originally prepared by the PAP.  In the many cases, this can be achieved by ensuring the integrity of the systems and implementing session level techniques to secure the communication between.

However, when policy is distributed between organizations to be acted a pone at a later or when the policy travels with data, it is necessary to have some meta about the policy statements such as who authored the policy and when it was written.  In these cases, it will be useful to have digital signature of the policy included with the meta data about the policy.   

5 - Confidentiality of Policy
The scenario is same as issue 4. In these cases, in may be important to encrypt parts or all of the policy statements.  As an option, do we want to support elements that can contain encrypted version of the <policySetStatment> and the <ruleSet> elements?

6 - Elements included by reference
There is a risk that references and extensions contained with in a policy statement may have altered since the policy was originally created and thus changing the intent of the policy statement.  For instance if a <policystatement> includes a rule by reference, there is no guarantee that rule has not been changed.  In the case of a rule a <ruledigest> element may be used to unique identify the rule.  The <ruledigest> element contains a hash of the original rule.  In other cases, a digital signature of the source item could be included with the reference. This technique will allow the PDP to ensure that rule or extension had not been altered.  

James