[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Open Issues in Profiles, Version 1.4
The updated list of issues pertaining to the Profiles that we expect or hope to progress to OASIS Standard along with XACML 2.0 is appended. This list includes the decisions made in today's (5 August 2004) XACML TC meeting. Anne -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
Title: Open Issues in Profiles Version: 1.4 Updated: 04/08/05 (yy/mm/dd) Author: Anne Anderson <Anne.Anderson@sun.com> 1. XACML XML DSig Profile a. Canonicalization There is no satisfactory standard canonicalization algorithm to be used on an XML document that is to be signed. This is not an XACML-specific problem, but applies to all XML documents. SAML recommends use of the "Exclusive Canonicalization" algorithm, but from what I have read, that does not cover all the processing needed to ensure that an XML schema instance will have the same canonical form after processing by different entities (this is what is required for digital signatures to work). "OASIS Schema Centric XML Canonicalization Version 1.0" seems to be the most appropriate, but is a Committee Draft of the OASIS UDDI Spec TC, but has not advanced. It is not widely implemented as far as I can tell. PROPOSAL: I propose that we rewrite the XACML XML DSig Profile to say "XACML RECOMMENDS encapsulating XACML schema instances in SAML Queries and Assertions as described in the XACML Profile for SAML 2.0, and signing the SAML instance according to the SAML digital signature mechanisms." and then listing various canonicalization issues that SHOULD be addressed (taken from the Committee Draft above), but not make any recommendation about how to resolve them. XACML TC 05 Aug 04: APPROVED. b. Signatures on referenced PolicySets and Policies In some cases, an Issuer wants to ensure that only a particular version of a referenced policy or policy set will be used. We had said this could be solved by using a manifest with a digital signature. But SAML requires use of enveloped signatures, which (as I recall) does not allow use of a manifest of external documents. PROPOSAL: [kind of late in the game, but maybe small enough] Go back to the proposal to allow an optional Name="Hash" Type="xml:hexBinary"? xml attribute in a <PolicyIdReference> or <PolicySetIdReference>. We would specify that it be SHA1 (or some other specific algorithm) for interoperability. Also have to specify canonicalization, so not as simple. XACML TC 05 Aug 04: REJECTED. Depend on Version. If signed, and source is trusted, then it is secure. 2. XACML Profile for Role Based Access Control (RBAC), Version 2.0 a. Separation of Duty The mechanism for handling RBAC described in the current draft of the profile handles basic RBAC and hierarchical RBAC, but does not handle dynamic Separation of Duty. Aleksey Studnev (Exigen Group) proposed the elements of a workable solution but I need to do some literature searching and expert consultant checking (NIST RBAC team) to be sure the solution is unencumbered before proceeding. PROPOSAL: I will try to finish my search and update the Profile promptly, but the XACML 2.0 standards bundle should not be delayed for this item. 3. XACML Profile for Request for Multiple Resources No known issues. Please read current draft and comment. 4. XACML Profile for Hierarchical Resources a. URI for support for resource-ancestor, resource-parent Daniel has proposed that we have a URI defined for use in indicating support for these Attributes as a hierarchical resource mechanism. This is strictly a Context Handler issue, since the PDP evaluation is exactly the same for these Attributes as for any other. Note also that support for these Attributes would be resource-specific: a Context Handler might support the values for some resources but not for others. PROPOSAL: I propose that the XACML Profile for Hierarchical Resources not define a special URI for this mechanism. If an implementation needs an identifier to indicate that it supports these Attributes, then the URIs of the Attributes themselves could be used for this purpose. XACML TC 05 Aug 04: Use the AttributeId of the attribute if needed. Any future conformance advertisement mechanism can use these URIs plus further information such the identities of resources for which this is supported. Same for URI representation of identities of hierarchical resources. b. Normalization of URI representation Do we need to specify normalization of %20, etc. characters in the URI representation of a hierarchical resource? XACML TC 05 Aug 04: ACTION: Anne to send issue to list. c. 2 ways of referring. 5. Privacy policy profile of XACML No known issues. Please read current draft and comment. 6. XACML Profile for SAML 2.0 a. Populating SAML Response/Status/StatusCode/Value PROPOSAL: The following are the only permitted values, as specified by SAML. I propose they be used as described. o urn:oasis:names:tc:SAML:2.0:status:Success The request succeeded [a Statement is encapsulated]. or valid empty. o urn:oasis:names:tc:SAML:2.0:status:Requester The request could not be performed due to an error on the part of the requester. o urn:oasis:names:tc:SAML:2.0:status:Responder The request could not be performed due to an error on the part of the SAML responder or SAML authority. o urn:oasis:names:tc:SAML:2.0:status:VersionMismatch The SAML responder could not process the request because the version of the request message was incorrect. XACML TC 05 Aug 04: Need to map each of our error status cases to one of these. Or "as long as there is an XACML <result>, then it is Success". Anne to list with proposed mappings. b. Populating SAML Assertion/Conditions and Assertion/Advice PROPOSAL: I propose that our Profiles not specify any values for these except for Conditions/NotBefore and NotOnOrAfter, but say a Requester and Responder MAY agree to add other Conditions or Advice appropriate for their environment and protocol agreements. XACML TC 05 Aug 04: APPROVED. c. Require Issuer match signature? XACML TC 05 Aug 04: No. Need to allow for 3rd party signatures. d. SHOULD or SHALL require validity period match to "current-dateTime"? Cases covered by profile: if Policy retrieved, then Policy SHALL be valid by "current-dateTime". Case: policies very volatile. Suppose in order to test the features, want to test it on weekends and weekdays. XACML TC 05 Aug 04: Decision validity period SHALL be consistent with validity periods of inputs to the decision. Remaining constraints not needed.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]