[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]