Jens Jakob Andersen wrote, > Having thought over the XACML issue, and the connected areas, > mixed with my > experience in consulting for implementation of Profile Based > User Rights > Adminstration Systems , as well as being practical, I jump to > some issues: > > 1. How will XACML information be provided ? > - Initially (LDAP ?) and for later use (Kerberos tickets ?) I am not sure what you are asking. If you are asking where does the policy come from that goes into XACML documents? the answer is anywhere you like, LDAP is one logical choice. If you are asking how do you get you hands on an XACML document? this is exactly the point I raised which caused us to rethink the draft charter. > 2. If XACML is added as a header to the XML document it is > meant to protect, > this will only work with XACML aware software. E.g Notepad or > VI will just > read the text document, and reveal all of it to the reader. XACML presumes a trusted container of some sort that can enforce the access controls specified. This cannot be software alone. (Bruce Schneier explains why here:
http://www.infosecuritymag.com/articles/august00/columns2_cryptorhythms.shtm l) It has to be some kind of server or secure container like an ATM. > 3. This one is ouch, and I hope that we all will say NO: > Should XACML be > coupled together with encryption of document content ? Just as you need a secure container, you also need a trusted communications channel if you expect to actually enforce the policies expressed in XACML. However, I don't think we should hold up XACML if XML encrytion is not complete. Other alternatives, such as SSL/TLS are available in specific environments. Hal