[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Updated list of Change Requests
Updated list below (also available as attachment). Please send
corrections to the list, and I will pick them up if no
objections.
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: Change Requests
Author: Anne Anderson
Version: 1.8, 02/09/19 (yy/mm/dd)
Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.ChangeRequests.txt
ACTION ITEMS
============
0008. [Anne] Resubmit list of mandatory/non-mandatory functions.
0017. [Carlisle] Hold vote on Anne's draft text.
0019. [Carlisle] Hold vote on Polar's draft text.
0047. [Michiharu] Provide DOM-equal specification.
LEGEND
======
NQ=no quorum; official vote required
Q=quorum
SUMMARY
=======
0001. [Daniel] Add AttributeValue element to support sequence-of values
STATUS: REJECTED (NQ 9/9;Q 9/12) Use sequence-* functions instead.
0002. [Anne] Add mandatory action-id attribute
STATUS: APPROVED (Q 8/29)
0003. [Anne] Add optional action-namespace attribute
STATUS: APPROVED (Q 8/29)
0004. [Anne] Add optional action:implied-action identifier
STATUS: APPROVED (Q 8/29)
0005. [Anne] Change <Result> ResourceURI xml attribute to ResourceId
STATUS: APPROVED (Q 8/29)
0006. [Anne] Add missing-attribute identifier for StatusCode
STATUS: APPROVED (Q 8/29)
0007. [Anne] Make context Resource Attribute minoccurs=1
STATUS: REJECTED (NQ 9/5;Q 9/12)
0008. [Anne] list mandatory vs. non-mandatory functions
STATUS: POSTPONED (9/5) Anne to resubmit when #23 resolved.
0009. [Daniel] Function naming convention
STATUS: REJECTED (Q 8/29)
0010. [Anne] allow more than two arguments to "add"
STATUS: APPROVED (Q 8/29)
0011. [Carlisle] state *Match is matched against AttributeValue
STATUS: APPROVED (Q 8/29)
0012. [Carlisle] <AttributeSelector> in <SubjectMatch> should be [optional]
STATUS: APPROVED (Q 8/29)
0013. [Carlisle] <SubjectMatch> in <SubjectAttributeDesignatorWhere> min/max
STATUS: APPROVED (NQ 9/5;Q 9/12) maxOccurs="unbounded", but minOccurs="0"
0014. [Carlisle] 10. "Security and Privacy Considerations"
STATUS: APPROVED (NQ 9/5;Q 9/12)
0015. [Carlisle] 10. "Statement Level Confidentiality": rules/policies
STATUS: APPROVED (NQ 9/9;Q 9/12) Editorial, so vote not required.
0016. [Carlisle] 10. "Policy Integrity": rule => policy
STATUS: APPROVED (NQ 9/9;Q 9/12) Editorial, so vote not required.
0017. [Carlisle] 10. "Resource Matching": NotApplicable treated as Permit
STATUS: POSTPONED (9/9) Anne to draft "open world/closed world" text [below].
0018. [Carlisle] C.3 use "First Applicable"
STATUS: APPROVED (NQ 9/9;Q 9/12) Editorial, so vote not required.
0019. [Carlisle] C. consistent error behavior
STATUS: POSTPONED (9/9) Polar has reviewed, recommends change below.
0020. [Michiharu] B.10: Resource Attributes scope value
STATUS: APPROVED (NQ 9/9;Q 9/12) Add new attribute identifier below.
0021. [Michiharu] 8.1 Operational Model: PDP description change
STATUS: APPROVED (NQ 9/9;Q 9/12)
0022. [Michiharu] 8.1 Operational Model: New sections
STATUS: REJECTED (NQ 9/9;Q 9/12) But to be included in Primer.
0023. [Daniel, Polar] function names, types, semantics
STATUS: APPROVED (Q 9/19) V0.11 + target limits plus not-* plus *<,*<=.
0024. [Anne] Make "gregorian" functions non-mandatory
STATUS: APPROVED (NQ 9/9;Q 9/12)
0025. [Anne] remove NOTATION from supported types; remove assoc. functions
STATUS: APPROVED (NQ 9/9 Q 9/12)
0026. [Michiharu] Add XPath functions as non-mandatory
STATUS: WITHDRAWN (9/19) Replaced by #47.
0027. [Michiharu] Change resource-uri to resource-id
STATUS: APPROVED (NQ 9/9;Q 9/12)
0028. [Michiharu] Add identifier for resource:syntax
STATUS: REJECTED (NQ 9/9;Q 9/12) Use DataType="<syntax>" instead.
0029. [Michiharu] Add identifier for resource:scope
STATUS: CLOSED (NQ 9/9;Q 9/12) Duplicate of #20.
0030. [Michiharu] Add identifier for resource:target-namespace
STATUS: APPROVED (NQ 9/9;Q 9/12)
0031. [Michiharu] Type of XPathVersion element from string=>anyURI
STATUS: WITHDRAWN (9/12)
0032. [Michiharu] Schema change of AttributeSelector
STATUS: ACCEPTED (Q 9/12)
0033. [Michiharu] Example two to separate document
STATUS: REJECTED (NQ 9/9;Q 9/12) But add "this is a complex example" to intro.
0034. [Polar] Target Match Semantics Section 4 & 5
STATUS: APPROVED (NQ 9/9;Q 9/12)
0035. [Michiharu] AttributeSelectorIndirect
STATUS: WITHDRAWN (9/19) Replaced by #47.
0036. [Michiharu] DataType attribute required?
STATUS: APPROVED (NQ 9/9;Q 9/12) Remove DataType in Policy; keep in Context.
0037. [Michiharu] Add normalized-string-match function
STATUS: APPROVED (NQ 9/9;Q 9/12)
0038. [Simon] Extending XACML semantics with subject-class
STATUS: WITHDRAWN (9/9)
0039. [Michiharu] Remove XPathVersion attribute from AttributeSelector
STATUS: ACCEPTED (Q 9/12)
0040. [Michiharu,Simon] Semantics of sequences
STATUS: WITHDRAWN. REPLACED BY #42-#46.
0041. [Polar] Target Match Truth Table
STATUS: APPROVED (Q 9/19)
0042. [Michiharu] XACML supports consistent specification between MatchId function and Apply function
STATUS: APPROVED (NQ 9/16)
0043. [Michiharu] XACML supports unordered set that is called a "bag"
STATUS: APPROVED (NQ 9/16)
0044. [Michiharu] XACML distinguishes singleton data from bag type
STATUS: APPROVED (NQ 9/16)
0045. [Michiharu] XACML supports higher-order bag functions
STATUS: APPROVED (NQ 9/16)
0046. [Michiharu] XACML supports operators for computing on bag types.
STATUS: APPROVED (NQ 9/16)
0047. [Michiharu] Function specification for XPath handler
STATUS: POSTPONED (9/19) Michiharu to provide DOM-equal specification.
DETAILS
=======
0001. [Daniel] Add AttributeValue element to support sequence-of values
http://lists.oasis-open.org/archives/xacml/200208/msg00047.html
http://lists.oasis-open.org/archives/xacml/200208/msg00140.html
STATUS: REJECTED (NQ 9/9;Q 9/12) Use sequence-* functions instead.
Currently <attributeValue> element is an extension of
anyType, with specified DataType. XACML functions arguments
are, in general, a sequence of typed elements - as it can be
returned by a designator from context. While most accept
only single values (sequence of size 1), some set operation
functions have an arbitrary length sequence as an argument.
We need to provide syntax to express a sequence of values as
a literal argument in set operations (like union, member_of,
intersection..)
I propose adding element Value, of anyType, and defining
<AttributeValueType> as sequence of <Value>, with DataType
attribute, applicable to all elements in the sequence. It
supports 0 size of the sequence, to support empty set in
operations
<xs:element name="Value" type="xs:anyType"/>
<xs:element name="AttributeValue"/>
<xs:complexType name="AttributeValueType">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Value"/>
</xs:sequence>
<xs:attribute name="name" type="xs:anyURI" use="required"/>
</xs:complexType>
-------------------------------------
>2. Adding a separate construct to XACML policy schema to represent
>sequences of attribute values, such that you cannot create sequeences of
>sequences.
As an alternative to my proposal to modify schema element <attributevalue>,
I propose to define standard core function collection
<type>-sequence
of undefined arity, that takes arguments of singleton <type> kind and return
a sequence<type> value, a sequence of its argument values.
In this case, when a literal sequence definition is needed, this funciton
can be used. No schema modification is needed.
The drawback is that it can not be used to specify an argument of
sequence<type> kind for predicate functions that can be used in <Match>
elements.
0002. [Anne] Add mandatory action-id attribute
STATUS: APPROVED (Q 8/29)
Create a reserved attribute identifier
"urn:oasis:names:tc:xacml:1.0:action:action-id". Make
inclusion of an <Attribute> with AttributeId of this
identifier mandatory under the <Action> element of the
<Request> context. Change minOccurs for <Attribute> under
<Action> 1.
Rationale:
We had previously decided that <Action> would have a single
string value that would be the action id. Now we need a
specific AttributeId for this.
This is consistent with the way resource-id is handled. It
provides a consistent, interoperable way of specifying the
action. The <DataType> of the <Attribute> can specify
whether the action value is a string or URI.
0003. [Anne] Add optional action-namespace attribute
STATUS: APPROVED (Q 8/29)
Create a reserved attribute identifier
"urn:oasis:names:tc:xacml:1.0:action:action-namespace". Make
inclusion of an <Attribute> with AttributeId of this
identifier optional under the <Action> element of the
<Request> context.
Rationale:
We previously decided that an <Action> value might be
associated with a specific namespace, and that an XML
attribute was needed to express this.
0004. [Anne] Add optional action:implied-action identifier
STATUS: APPROVED (Q 8/29)
Create a reserved identifier
"urn:oasis:names:tc:xacml:1.0:action:implied-action" to
represent the value of an action that is implied by the
<Resource>
Rationale:
We have agreed to this concept, but have not reserved an
identifier for it.
0005. [Anne] Change <Result> ResourceURI xml attribute to ResourceId
STATUS: APPROVED (Q 8/29)
Rationale:
Since the Request <Resource> identifier is now called
resource-id, and can be of any data type, the <Result> should
be consistent.
0006. [Anne] Add missing-attribute identifier for StatusCode
STATUS: APPROVED (Q 8/29)
Rationale:
We have values for ok, processing-error, and syntax-error.
Although we discussed the use case for missing attributes
extensively, we have not defined a standard identifier for this
status.
0007. [Anne] Make context Resource Attribute minoccurs=1
STATUS: REJECTED (NQ 9/5;Q 9/12)
Current value is minOccurs=0 maxOccurs=unbounded. Change this
to minOccurs=1 maxOccurs=unbounded.
Rationale:
Since Resource MUST contain a resource-id attribute, minimum
value should be 1.
0008. [Anne] list mandatory vs. non-mandatory functions
http://lists.oasis-open.org/archives/xacml/200208/msg00069.html
STATUS: POSTPONED (9/5) Anne to resubmit when #23 resolved.
Add a list of all functions, with an indicator as to
whether the function is mandatory to implement, to the
Conformance Section.
This list should be updated based on the final resolution
of CR#23.
Rationale:
I forgot to include these when I created the original list.
Text to be inserted:
[complete list of functions in e-mail]
0009. [Daniel] Function naming convention
http://lists.oasis-open.org/archives/xacml/200208/msg00071.html
STATUS: REJECTED (Q 8/29)
Change function names to blah_blah
Rationale:
Dashes are not always supported.
0010. [Anne] allow more than two arguments to "add"
http://lists.oasis-open.org/archives/xacml/200208/msg00090.html
STATUS: APPROVED (Q 8/29)
Allow function:integer-add and function:decimal-add to take
more than two arguments.
Rationale:
This saves having to write nested statements for these simple
operations.
0011. [Carlisle] state *Match is matched against AttributeValue
http://lists.oasis-open.org/archives/xacml/200208/msg00094.html
STATUS: APPROVED (Q 8/29)
In section 5.7 (Element <SubjectMatch>), I think we need to
specify that whatever is returned by
SubjectAttributeDesignator or AttributeSelector is matched
against the value carried in AttributeValue. The same is
true for <ResourceMatch> and <ActionMatch> (sections 5.10 and
5.13).
Rationale:
This behaviour is not spelled out anywhere. (In fact,
AttributeValue is not even described in the "list of elements
contained in <SubjectMatch>" discussion; it only appears in
the schema fragment.)
0012. [Carlisle] <AttributeSelector> in <SubjectMatch> should be [optional]
http://lists.oasis-open.org/archives/xacml/200208/msg00094.html
STATUS: APPROVED (Q 8/29)
Make <AttributeSelector> in <SubjectMatch> [optional] rather
than [required].
Rationale:
Also, in the "list of elements contained in <SubjectMatch>"
discussion, why is <AttributeSelector> described as
[required]? I thought it was optional.
0013. [Carlisle] <SubjectMatch> in <SubjectAttributeDesignatorWhere> min/max
http://lists.oasis-open.org/archives/xacml/200208/msg00094.html
STATUS: APPROVED (NQ 9/5;Q 9/12) maxOccurs="unbounded", but minOccurs="0"
Make minOccurs="1" and maxOccurs="unbounded" for
<SubjectMatch> in <SubjectAttributeDesignatorWhere>.
Rationale:
In section 5.26 (Element <SubjectAttributeDesignatorWhere>),
why does the element <SubjectMatch> have minOccurs="0"? If
this element was omitted, you wouldn't use
SubjectAttributeDesignatorWhere; you would just use
SubjectAttributeDesignator. In any case, the verbal
description says that SubjectMatch has [Any Number], so I
suspect that minOccurs="0" in the schema should be changed to
maxOccurs="unbounded".
0014. [Carlisle] 10. "Security and Privacy Considerations"
http://lists.oasis-open.org/archives/xacml/200208/msg00096.html
STATUS: APPROVED (NQ 9/5;Q 9/12)
Change title of Section 10 to "Security and Privacy
Considerations".
Rationale:
Should this be called "Security and Privacy Considerations"
instead of just "Security and Privacy"?
0015. [Carlisle] 10. "Statement Level Confidentiality": rules/policies
http://lists.oasis-open.org/archives/xacml/200208/msg00096.html
STATUS: APPROVED (NQ 9/9;Q 9/12) Editorial, so vote not required.
In the 10. "Statement Level Confidentiality" section, 1st
paragraph, say "... a PRP only needs access to the target
elements in order to find the appropriate policies".
Rationale:
Currently says: "... a PRP only needs access to the target
elements in order to find the appropriate rules". Should
this say "rules/policies", or just "policies", instead of
"rules"?
0016. [Carlisle] 10. "Policy Integrity": rule => policy
http://lists.oasis-open.org/archives/xacml/200208/msg00096.html
STATUS: APPROVED (NQ 9/9;Q 9/12) Editorial, so vote not required.
In the 10. "Policy Integrity" section, 4th paragraph, say
"The PDP SHOULD NOT request a policy based on who signed the
policy...".
Rationale:
In the "Policy Integrity" section, 4th paragraph, it
currently says "The PDP SHOULD NOT request a rule based on
who signed the rule...". Should both occurrences of "rule"
be "policy"?
0017. [Carlisle] 10. "Resource Matching": NotApplicable treated as Permit
http://lists.oasis-open.org/archives/xacml/200208/msg00096.html
STATUS: POSTPONED (9/9) Anne to draft "open world/closed world" text [below].
In 10. "Resource Matching" section, say, 'although the
policy result of "Not Applicable" is treated as equivalent
to "Permit" by many web servers, this behavior is not
recommended.'
Rationale:
In the "Resource Matching" section, 1st paragraph, it says
"... the policy result of "Not Applicable" is treated as
equivalent to "Permit" as is common in many web servers".
I'm a bit surprised that this is true (although I probably
shouldn't be!). In any case, we probably don't want to
encourage this behaviour. Should we simply not mention
this, or should we at least say that this behaviour is not
recommended?
Hal's rejoinder:
First of all, this is intended as a cautionary
example. However, this is a real world problem that affects
my product, and all of our compeitors. I can show you
security holes posted to BUGTRAQ, for example, where this
occurred. We have struggled with it for years. The Not
Applicable == Permit behavior is not only standard for web
servers, it is embedded in the Java Servlet and JSP
specifications.
The logic is that only a small portion of the resources on
a public web server are protected, so people want to only
specify rules for those that are. If the namespace is not
conveniencely laid out (as most are not) it may require a
number of rules just to specify all the pages that are not
protected.
[Anne draft of "Open World/Closed World" considerations]
Draft change to "Security and Privacy Considerations"
"Resource Matching" section:
1. Change title to "NotApplicable Results"
A result of "NotApplicable" means that the PDP did not have a
Policy whose Target matched the information in the Request.
In some security models, such as is common in many Web
Servers, a result of "NotApplicable" is treated as equivalent
to "Permit".
If "NotApplicable" is to be treated as "Permit", is it vital
that the matching algorithms used by the Policy to match
elements in the Request are closely aligned with the data
syntax used by the applications that will be making the
Request. A failure to match will be treated as "Permit", so
an unintended failure may allow unintended access.
A common example of this is a Web Server. Commercial http
responders permit a variety of syntaxes to be treated
equivalently. The "%" can be used to represent characters by
hex value. In the URL path "/../" provides multiple ways of
specifying the same value. Multiple character sets may be
permitted and, in some cases, the same printed character can
be represented by different binary values. Unless the
matching algorithm used by the Policy is sophisticated enough
to catch these variations, unintended access may be allowed.
It is safe to treat "NotApplicable" as "Permit" ONLY in a
closed environment where all applications that formulate a
Request are closely aligned with the Policies used by the
PDP. In a more open environment, where Requests may be
received from applications that are not necessarily closely
aligned with the Policies used by the PDP, it is HIGHLY
RECOMMENDED that "NotApplicable" NOT be treated as "Permit"
unless matching rules have been very carefully designed to
match ALL possible applicable inputs, regardless of syntax or
type variations.
0018. [Carlisle] C.3 use "First Applicable"
http://lists.oasis-open.org/archives/xacml/200208/msg00099.html
STATUS: APPROVED (NQ 9/9;Q 9/12) Editorial, so vote not required.
Call Section C.3, "First Applicable" rather than "First
Applicable Rule Combining Algorithm".
In first sentence of C.3, change "First Determinate"
rule-combining algorithm to "First Applicable".
Rationale:
Section C.3, should this be called "First Applicable"
rather than "First Applicable Rule Combining Algorithm"?
This would be more consistent with both C.1 and C.2, and
would also be more consistent with the fact that C.3
contains both a rule combining algorithm and a policy
combining algorithm.
The first sentence of C.3 calls it the "First Determinate"
rule-combining algorithm; this should be changed to "First
Applicable".
0019. [Carlisle] C. consistent error behavior
http://lists.oasis-open.org/archives/xacml/200208/msg00099.html
STATUS: POSTPONED (9/9) Polar has reviewed, recommends change below.
Policy combiner should halt and return Indeterminate when
an error is encountered.
Rationale:
The behaviour specified in the policy-combining algorithm
when an error is encountered is different from the
behaviour specified in the rule-combining algorithm when an
error is encountered (the rule combiner says halt and
return Indeterminate, whereas the policy combiner says to
keep looking for an applicable policy). Is this what we
wanted?
More importantly, might the policy combiner behaviour not
lead to different answers for the same inputs? For
example, say there are two policies that are to be combined
using this algorithm. Given a particular set of input
values, the first policy would return a decision of
"Permit" and the second policy would return a decision of
"Deny". Now we give all the inputs to two different PDPs.
The first PDP retrieves the first policy, gets an answer of
"Permit", and returns this to the PEP. The second PDP has
trouble retrieving the first policy for whatever reason
and, according to the combining algorithm, retrieves the
second policy; it then returns a "Deny" to the PEP. Isn't
this the sort of result we want to avoid? Wouldn't the
behaviour specified in the rule combining algorithm be
preferable (that way, the first PDP would return "Permit"
and the second would return "Indeterminate", which seems
fine to me)?
[Polar] I agree with Carlisle that the problem he states
needs to be reckoned with CR 19. The current algorithm breaks
monotonicity in the evaluation of the First Applicable Policy
Combining algorithm, as he points out. It should model the
rule combinging algorithm.
We should modify the current document by replacing the
following paragraph:
If there is any error evaluating the target or the policy, or
a reference to a policy is considered invalid, then the
evaluation shall continue looking for an applicable policy,
if no applicable policy is found, then the result of the
combination is "Indeterminate".
with:
If there is any error evaluating the target, or while
evaluating a specific policy, the reference to the policy is
considered invalid, or the policy itself evaluates to
"Indeterminate", then the evaluation of the combining
algorithm shall halt, and the result shall be "Indeterminate"
with an appropriate error status.
The pseudo code should say:
Decision firstApplicableEffectPolicyCombiningAlgorithm(Policy policy[])
{
for( i = 0 ; i < lengthOf(policy) ; i++ )
{
Decision decision = evaluate(policy[i]);
if(decision == Deny)
{
return Deny;
}
if(decision == Permit)
{
return Permit;
}
if (decision == NotApplicable)
{
continue;
}
if (decision == Indeterminate)
{
return Indeterminate;
}
}
return NotApplicable;
}
0020. [Michiharu] B.10: Resource Attributes scope value
http://lists.oasis-open.org/archives/xacml/200208/msg00112.html
STATUS: APPROVED (NQ 9/9;Q 9/12) Add new attribute identifier below.
In B.10, the identifier indicates the scope of the request
with regard to the resource. When this Attribute is
specified in the request, the value MUST be either
'Immediate', 'Children', or 'Descendant'.
New identifier is: urn:oasis:names:tc:xacml:1.0:resource:scope
0021. [Michiharu] 8.1 Operational Model: PDP description change
http://lists.oasis-open.org/archives/xacml/200208/msg00112.html
STATUS: APPROVED (NQ 9/9;Q 9/12)
8.1 Policy Decision Point (PDP)
Given a valid XACML "Policy" or a "PolicySet", a compliant XACML PDP MUST
evaluate that statement in accordance to the semantics specified in Section
4,5, and 6 when applied to a specific input context. The PDP MUST return an
output context, with one value of "Permit", "Deny", "Indeterminate", or
"NotApplicable".
If a permit is returned, the PEP permit access to the requested resource.
If a denial is returned, the PEP denies access to the requested resource.
If a permit with one or more obligations is returned, the PEP permits
access provided that every obligations are fulfilled successfully. If a
denial with one or more obligations is returned, the PEP denies access but
still fulfills the obligations. In each case, when fulfilling obligations
failed, the PEP SHOULD raise an error. How the error is raised is out of
the scope of XACML. In any case, the PDP can return additional information
in the status code element in the response context. For 'Permit' decision,
it MAY specify which rules are used in decision making.
If an indeterminate is returned, it means that the PDP could not make
decision due to some reason. The PDP MAY return decision of "indeterminate"
with a status code of "urn:oasis:names:tc:xacml:1.0:missing-attribute",
signifying that more information is needed. In this case, the decision MAY
list the names of any attributes of the subject and the resource that are
needed by the PDP to refine its decision. A PEP MAY resubmit a refined
request context in response to a decision of "indeterminate" with a status
code of "missing-attribute" by adding attribute values for the attribute
names that are listed in the response. When the PDP returns an decision of
"indeterminate", with a status code of "missing-attribute", a PDP MUST NOT
list the names of any attribute of the subject or the resource of the
request for which values were already supplied in the request. Note, this
requirement forces the PDP to eventually return a decision of "permit",
"deny", or "indeterminate" with some other reason, in response to
successively-refined requests.
If not applicable is returned, it means that the PDP's policy does not
cover the request, implying that the PEP should ask another PDP.
XACML does not assume how top-level XACML policies should be configured.
For example, a top-level policy might be a 'Policy' element containing a
target element that matches every request, or it might be a 'Policy'
element containing a target element that matches only a specific subject.
0022. [Michiharu] 8.1 Operational Model: New sections
http://lists.oasis-open.org/archives/xacml/200208/msg00112.html
STATUS: REJECTED (NQ 9/9;Q 9/12) But to be included in Primer.
8.2 Hierarchical Resource
It is often the case that a target resource is organized as a hierarchy
(e.g. file system, XML document). Some applications may require access to
an entire subtree of the resource. XACML allows the PEP (or Context
Handler) to specify whether the access is just for a single resource or for
a subtree below the specified resource. The latter is equivalent to
repeating a single request for the entire subtree. When a request context
contains a resource attribute of
'urn:oasis:names:tc:xacml:1.0:resource:scope' with a value of 'Immediate',
or does not contain that attribute in the context, then it means that the
access is just for a single resource specified by 'ResourceId' attribute.
When 'urn:oasis:names:tc:xacml:1.0:resource:scope' attribute specifies a
value of 'Children', it means that the access is for both a specified
resource and its children resources. When
'urn:oasis:names:tc:xacml:1.0:resource:scope' attribute specifies a value
of 'Descendant', it means that the access is for both a specified resource
and all the descendant resources. In the case of 'Children' and
'Descendant', the access decision may include multiple results for the
multiple resources. XACML response can contain multiple result elements. In
such case, the status element SHOULD be included only in the first result
element (the remaining result elements SHOULD NOT include the status
element). Note that the method how PDP finds out whether the resource is
hierarchically organized or not is out of the scope of the XACML.
8.3 Propagation through Data Hierarchy
When the resource is hierarchically organized, it is often the case that an
access control rule associated to a certain node propagates down to the
descendant nodes. The XACML core rule combining algorithm does not support
such propagation with regard to access control rules. Policy writers who
need propagation MUST implement their own local algorithm and specify that
algorithm ID in RuleCombiningAlgId in policy element.
0023. [Daniel, Polar] function names, types, semantics
http://lists.oasis-open.org/archives/xacml/200208/msg00181.html
http://lists.oasis-open.org/archives/xacml/200209/msg00134.html (V0.11)
STATUS: APPROVED (Q 9/19) V0.11 + target limits plus not-* plus *<,*<=.
Daniel and Polar have developed a list of functions and
their semantics, attached to the above
e-mail.
0024. [Anne] Make "gregorian" functions non-mandatory
http://lists.oasis-open.org/archives/xacml/200208/msg00137.html
STATUS: APPROVED (NQ 9/9;Q 9/12)
Text Changes:
Section 11.1.4(?) [Conformance] Functions
Remove "M" from left column of
urn:oasis:names:tc:xacml:1.0:function:gregorian-equal
Rationale:
We already support xs:date, so support for Gregorian is icing
on the cake. Also, I haven't found a standard for "gregorian",
so it is hard to develop tests for it.
0025. [Anne] remove NOTATION from supported types; remove assoc. functions
http://lists.oasis-open.org/archives/xacml/200208/msg00138.html
STATUS: APPROVED (NQ 9/9 Q 9/12)
Text Changes:
Section 11. Conformance, DataTypes, remove:
line listing "xs:NOTATION"
Appendix A.1. Functions, remove:
function:NOTATION-equal
function:NOTATION-not-equal
Rationale:
XML Schema says
"It is an error for NOTATION to be used directly
in a schema. Only datatypes that are derived from NOTATION by
specifying a value for enumeration can be used in a schema.
For compatibility NOTATION should be used only on attributes."
Also, QName-equal and QName-not-equal can be used to compare
such data types if necessary.
I'm on thin ground here, since I don't know enough about XML
Schema to be sure I am interpreting the impact of this
correctly.
0026. [Michiharu] Add XPath functions as non-mandatory
http://lists.oasis-open.org/archives/xacml/200208/msg00142.html
STATUS: WITHDRAWN (9/19) Replaced by #47.
[See referenced e-mail for function definitions]
I propose to include the following functions (all relevant to XPath) in the
spec as non-mandatory to implement functions. The original proposal (a
little different from this proposal) was posted on 29th July and it
described more in detail.
http://lists.oasis-open.org/archives/xacml/200207/msg00162.html
function:general-string-equal xs:boolean object(*1) object A
= B
function:node-boolean xs:boolean object
function:node-match xs:boolean object object
========================
(*1) "object" type is defined in Introduction section of [2] as:
"... object, which has one of the following four basic types:
node-set (an unordered collection of nodes without duplicates)
boolean (true or false)
number (a floating-point number)
string (a sequence of UCS characters)"
[1] XQuery 1.0 and XPath 2.0 Data Model,
http://www.w3.org/TR/xquery-operators/
[2] XPath 1.0, http://www.w3.org/TR/xpath
0027. [Michiharu] Change resource-uri to resource-id
http://lists.oasis-open.org/archives/xacml/200208/msg00143.html (A1)
STATUS: APPROVED (NQ 9/9;Q 9/12)
urn:oasis:names:tc:xacml:1.0:resource:resource-uri
==>
urn:oasis:names:tc:xacml:1.0:resource:resource-id
0028. [Michiharu] Add identifier for resource:syntax
http://lists.oasis-open.org/archives/xacml/200208/msg00143.html (B1)
STATUS: REJECTED (NQ 9/9;Q 9/12) Use DataType="<syntax>" instead.
urn:oasis:names:tc:xacml:1.0:resource:syntax
This identifier indicates the syntax of the resource-id
(urn:oasis:names:tc:xacml:1.0:resource:resource-id). The valid values are
either 'String', 'URI' or 'XPointer'. If this attribute is omitted,
'String' syntax is assumed. 'URI' indicates that the syntax of the
resource-id is URI format. 'XPointer' indicates that the syntax of the
resource-id is XPointer format proposed in
http://www.w3.org/TR/2001/CR-xptr-20010911/.
0029. [Michiharu] Add identifier for resource:scope
http://lists.oasis-open.org/archives/xacml/200208/msg00143.html (B2)
STATUS: CLOSED (NQ 9/9;Q 9/12) Duplicate of #20.
urn:oasis:names:tc:xacml:1.0:resource:scope
This identifier indicates the scope of the resource. The valid values are
either 'Immediate', 'Children', or 'Descendant'. When 'Immediate', it
indicates that the scope of the resource is a target value specified by
urn:oasis:names:tc:xacml:1.0:resource:resource-id attribute. When
'Children', it indicates that the scope of the resource is a target value
specified by urn:oasis:names:tc:xacml:1.0:resource:resource-id attribute
and its children resource. When 'Descendant', it indicates that the scope
of the resource is a target value specified by
urn:oasis:names:tc:xacml:1.0:resource:resource-id attribute and all the
descendant resources.
0030. [Michiharu] Add identifier for resource:target-namespace
http://lists.oasis-open.org/archives/xacml/200208/msg00143.html (B3)
STATUS: APPROVED (NQ 9/9;Q 9/12)
urn:oasis:names:tc:xacml:1.0:resource:target-namespace
This identifier indicates the target-namespace of the requested XML
document, that is a namespace URI associated with the root element of the
XML document.
0031. [Michiharu] Type of XPathVersion element from string=>anyURI
http://lists.oasis-open.org/archives/xacml/200208/msg00144.html
STATUS: WITHDRAWN (9/12)
Schema change request
<xs:element name="XPathVersion" type="xs:string" substitutionGroup
="xacml:AbstractDefaults"/>
==>
<xs:element name="XPathVersion" type="xs:anyURI" substitutionGroup
="xacml:AbstractDefaults"/>
[Simon] this would require type of AbstractDefaults to be
changed to anyURI. Possibly OK, but need to evaluate impact.
0032. [Michiharu] Schema change of AttributeSelector
http://lists.oasis-open.org/archives/xacml/200209/msg00078.html
STATUS: ACCEPTED (Q 9/12)
I propose to change the AttributeSelector element.
<xs:complexType name="AttributeSelectorType">
<xs:attribute name="RequestContextPath" type="xs:anyURI" use="required"/>
<xs:attribute name="DataType" type="xs:anyURI" use="required"/>
<xs:attribute name="XPathVersion" type="xs:anyURI" use="optional" default
="http://www.w3.org/TR/1999/Rec-xpath-19991116"/>
</xs:complexType>
==>
<xs:complexType name="AttributeSelectorType">
<xs:element ref="xacml:XPathNamespace" minOccurs="0" maxOccurs
="unbounded"/>
<xs:attribute name="RequestContextPath" type="xs:anyURI" use
="optional"/>
<xs:attribute name="DataType" type="xs:anyURI" use="optional"/>
</xs:complexType>
<xs:element name="XPathNamespace" type="xacml:XPathNamespaceType"
substitutionGroup="xacml:AbstractDefaults"/>
<xs:complexType name="XPathNamespaceType">
<xs:attribute name="NamespaceURI" type="xs:anyURI"/>
<xs:attribute name="Prefix" type="xs:string" use="optional"/>
</xs:complexType>
Scope of the XPathNamespace for AttributeSelector element:
1. AttributeSelector element that includes XPathNamespace
element, XPathNamespace elements in PolicyDefaults or
PolicySetDefaults elements that include the
AttributeSelector element.
For the precedence,
1. XPathNamespace elements in AttributeSelector take
precedence over XPathNamespace elements in PolicyDefaults
in Policy element..
2. XPathNamespace elements in PolicyDefaults in Policy take
precedence over XPathNamespace elements in
PolicySetDefaults in PolicySet element..
3. If there are two or more identical prefixes are specified
under an AttributeSelector, a PolicyDefaults or a
PolicySetDefaults elements, the last prefix takes
precedence over the previous prefixes.
Others:
1. Global xmlns attribute is not used for resolving
namespace-prefix pair specified in XPath expression.
2. If no XPathNamespace element is found in valid scope, it
means no namespace-prefix pair is defined.
3. If Prefix attribute is missing, it means that default
namespace is defined.
Text change request
In Section 5.3, Element <PolicySetDefaults>, line 1487-1489,
<AbstractDefaults>[Any Number]
This is the head of substitution group to specify default parameters. The
elements in this substitution group defined at this time is
<XPathNamespace>
element.
0033. [Michiharu] Example two to separate document
http://lists.oasis-open.org/archives/xacml/200208/msg00147.html
STATUS: REJECTED (NQ 9/9;Q 9/12) But add "this is a complex example" to intro.
After looking at line 589-1102, I think that Section 3.2
policy specification in Example two is too complicated for
average readers. While my preference is to hold this example
in the spec, most readers would feel that XACML is difficult
to read and understand when they try to go through this
example. Besides, this example requires expertise about XPath
syntax and its data model that is basically different from
this specification. Honestly speaking, it is a little
difficult even for me... :-). So my suggestion is to move
this section to a separate document (say Primer document or
Use Case document).
[We decided to keep the example, but revise the introduction
slightly to make it clear that this is a very complex example
intended to illustrate various features of the XACML
language. The functions also need to be updated. Polar will
do that.]
0034. [Polar] Target Match Semantics Section 4 & 5
http://lists.oasis-open.org/archives/xacml/200208/msg00188.html
[long set of specific text changes included in e-mail]
http://lists.oasis-open.org/archives/xacml/200208/msg00189.html (correction)
STATUS: APPROVED (NQ 9/9;Q 9/12)
The semantics for the Target need to be updated. It doesn't seem to
describe how "Match" or "No-Match" are derived at. The document mentions
logical-AND and logical-OR, and they are not defined for Match and
No-Match. Also, we need to resolve the discovery and issue of the
inconsistency between the evaluation of Target and Condition with respect
to Indeterminate and NotApplicable, now that we are making progress on the
"functions" document.
I feel that if we refer to the Target evaluations with the same semantics
as Condition, we can leverage the use of True, False, and Indeterminate
that we have already defined, and then we can use the notions of
conjunctive sequence and disjunctive sequence as combinators of our
boolean values (true, false, indeterminate) with the normative
specifications of our functions "function:and" and "function:or" for the
combining rules. This will take care of the normative handling of error
conditions in the evaluation logic.
When the XACML Data Types, Functions, and Semantics gets put in the
document, I suggest making the following changes. Some changes are
editorial.
Note: There is some issue about <Target> and <Condition> of where they say
that they possible to be "empty", but I'm not sure if that means "omitted"
(i.e. minOccurs="0"), or <Target/>, or <Condition/>.
0035. [Michiharu] AttributeSelectorIndirect
http://lists.oasis-open.org/archives/xacml/200208/msg00190.html
http://lists.oasis-open.org/archives/xacml/200208/msg00201.html (followup)
http://lists.oasis-open.org/archives/xacml/200209/msg00016.html (more)
http://lists.oasis-open.org/archives/xacml/200209/msg00024.html (Polar)
http://lists.oasis-open.org/archives/xacml/200209/msg00030.html (Michiharu)
http://lists.oasis-open.org/archives/xacml/200209/msg00031.html (Polar)
http://lists.oasis-open.org/archives/xacml/200209/msg00035.html (Daniel)
http://lists.oasis-open.org/archives/xacml/200209/msg00036.html (Daniel)
http://lists.oasis-open.org/archives/xacml/200209/msg00040.html (Polar)
http://lists.oasis-open.org/archives/xacml/200209/msg00042.html (Daniel)
STATUS: WITHDRAWN (9/19) Replaced by #47.
Based on the discussion on Monday call, Simon and I agreed to changing the
schema to support an AttributeSelectorIndirect element to retrieve a XPath
expression from the context.
0036. [Michiharu] DataType attribute required?
http://lists.oasis-open.org/archives/xacml/200208/msg00192.html
STATUS: APPROVED (NQ 9/9;Q 9/12) Remove DataType in Policy; keep in Context.
DataType attribute in AttributeDesignatorType is 'required'. But in most
cases, AttributeDesignator is used below the matching function (e.g.
string-match) and that function is type-specific. So I think "DataType"
attribute is not required. I propose to change it to "optional".
<xs:complexType name="AttributeDesignatorType">
<xs:attribute name="AttributeId" type="xs:anyURI" use="required"/>
<xs:attribute name="DataType" type="xs:anyURI" use="required"/>
<xs:attribute name="Issuer" type="xs:anyURI" use="optional"/>
</xs:complexType>
[should be]
<xs:complexType name="AttributeDesignatorType">
<xs:attribute name="AttributeId" type="xs:anyURI" use="required"/>
<xs:attribute name="DataType" type="xs:anyURI" use="optional"/>
<xs:attribute name="Issuer" type="xs:anyURI" use="optional"/>
</xs:complexType>
0037. [Michiharu] Add normalized-string-match function
http://lists.oasis-open.org/archives/xacml/200209/msg00056.html
STATUS: APPROVED (NQ 9/9;Q 9/12)
- Handling whitespace
XPath 1.0 (and 2.0) has a function called normalize-space() that strips
leading and trailing whitespace and replacing sequences of whitespace
characters by a single space. Some people suggests to use this function
whenever string equality is checked on a XML document. That hides subtle
issues like how to handle whitespace in XML. However, some applications may
need non-normlized string comparison.
So my suggestion is to support two kinds of string-equal functions:
string-equal and normalized-string-equal. The string-equal does not
normalize the string and the normalized-string-equal works as if it invokes
normalize-space() function internally before comparison is made. The
normalized-string-equal function is necessary if a user need to specify
this function in MatchId attribute. When string-equal is used, any
whitespace handling specifier "xml:space" attribute on XACML Request
Context will be ignored except for the element inside the ResourceContent
element.
- Semantics of the string comparison
XPath 2.0 defines xf:compare function instead of defining xf:string-equal
function. The xf:compare has an optional argument called "collation" that
specifies Unicode collation algorithm. The draft says, if it is omitted,
the default collation is used (but its rule is TBD). Then, if we assume
that there is a default collation for XACML, the function:string-equal is
defined as "it returns true depending on the value of the first string is
equal to the value of the second string according to the rules of the
collation that is used. Otherwise, false is returned". We may add "if
either argument is the empty sequence, it returns false". Default collation
in XACML would be "comparison on each character of the string using
integer-equal".
0038. [Simon] Extending XACML semantics with subject-class
http://lists.oasis-open.org/archives/xacml/200209/msg00052.html
STATUS: WITHDRAWN (9/9)
0039. [Michiharu] Remove XPathVersion attribute from AttributeSelector
http://lists.oasis-open.org/archives/xacml/200209/msg00078.html
STATUS: ACCEPTED (Q 9/12)
I request to remove "XPathVersion" attribute from
AttributeSelector element. The reason is that we already
allow a default value of XPathVersion in Policy and PolicySet
elements. Since the minimum unit of the policy rules are
Policy element, I think it is sufficient to specify XPath
version information at a policy level, not at each
AttributeSelector level. Policy writer who uses
AttributeSelector must specify the xpath version in
PolicyDefaults or PolicySetDefaults element. The value of
XPath 1.0 version is
"http://www.w3.org/TR/1999/Rec-xpath-19991116";.
0040. [Michiharu,Simon] Semantics of sequences
http://lists.oasis-open.org/archives/xacml/200209/msg00071.html
STATUS: WITHDRAWN. REPLACED BY #42-#46.
As far as I understand, the model for comparing two sequences
in function draft 0.8 seems not sufficient for comparison
(matching) framework. I am assuming that our data model
supports a sequence as a base type. For example,
type-member-of function supports only equality comparison but
not other kinds of comparison such as string-greater-than
etc. My opinion is that we need to specify two things: how to
compare two sequences and how to compare each element.
Draft documents and more of the proposal included in the
e-mail.
0041. [Polar] Target Match Truth Table
http://lists.oasis-open.org/archives/xacml/200208/msg00188.html
http://lists.oasis-open.org/archives/xacml/200208/msg00189.html (correction)
STATUS: APPROVED (Q 9/19)
Text change:
4.3.1.4 Rule evaluation
A rule has a value that can be calculated by evaluating its contents.
Rule evaluation involves separate evaluation of the rule's target and
condition. The result of rule's target and condition are evaluated as if
the "function:and" were applied to both results.
The rule truth table is shown in Table 1.
Target Condition Rule
True True Effect
True False Not Applicable
True Indeterminate Indeterminate
False True Not Applicable
False False Not Applicable
False Indeterminate Not Applicable
Indeterminate True Indeterminate
Indeterminate False Indeterminate
Indeterminate Indeterminate Indeterminate
Table 1 - Rule truth table
[The subsequent 2 paragraphs after the table are no longer true, and
should be removed.]
0042. [Michiharu] XACML supports consistent specification between MatchId function and Apply function
http://lists.oasis-open.org/archives/xacml/200209/msg00098.html
STATUS: APPROVED (NQ 9/16)
In ver 0.8 function draft, string comparison (set against a
value) is differently specified in MatchId from
Apply. Suppose attribute selector returns a sequence
(e.g. "aaa" and "bbb"). In ResourceMatch,
function:string-equal is used while in Apply,
function:string-member-of is used:
<ResourceMatch MatchId="function:string-equal">
<AttributeSelector RequestContextPath="/a/b/c/text()">
<AttributeValue>bbb</AttributeValue>
</ResourceMatch>
|<Apply FunctionId="function:string-member-of">
<AttributeValue>bbb</AttributeValue>
<AttributeSelector RequestContextPath="/a/b/c/text()">
</Apply>
We fix the above problem by using the higher-order bag
function specified in 0.9 function draft:
<ResourceMatch MatchId="function:string-equal">
<AttributeDesignator AttributeId="role1"/>
<AttributeValue>bbb</AttributeValue>
</ResourceMatch>
<Apply FunctionId="function:any-of-each">
<Function FunctionId="function:string-equal"/>
<AttributeDesignator AttributeId="role1"/>
<AttributeValue>bbb</AttributeValue>
</Apply>
When we specify policy for MatchId, function:any-of-each is
implicitly used for specifying the semantics of the
comparison on bags.
0043. [Michiharu] XACML supports unordered set that is called a "bag"
http://lists.oasis-open.org/archives/xacml/200209/msg00098.html
STATUS: APPROVED (NQ 9/16)
XACML supports an unordered set type and does not support a
sequence type because there is few requirement that needs
sequence dependent policy specification (e.g. sequence-equal
function (or point-wise comparison) in XPath 2.0 draft is one
of such requirement but TC members decided that is a lower
priority). We rename it from "sequence (unordered set)" to
"bag".
0044. [Michiharu] XACML distinguishes singleton data from bag type
http://lists.oasis-open.org/archives/xacml/200209/msg00098.html
STATUS: APPROVED (NQ 9/16)
XACML has two kinds of functions: a function that defines
semantics on singleton data (e.g. function:string-equal), and
a function that defines the semantics on bags
(e.g. function:any-of-each). This means that XACML
distinguishes singleton data from bag type. We don't
distinguish them by local name or its prefix. The
specification lists function names as text.
0045. [Michiharu] XACML supports higher-order bag functions
http://lists.oasis-open.org/archives/xacml/200209/msg00098.html
STATUS: APPROVED (NQ 9/16)
XACML supports higher-order bag functions as 0.9 draft
describes.
0046. [Michiharu] XACML supports operators for computing on bag types.
http://lists.oasis-open.org/archives/xacml/200209/msg00098.html
STATUS: APPROVED (NQ 9/16)
Comparison among bag types (e.g. any-of-each) is defined by
higher-order bag functions as 0.9 draft describes.
0047. [Michiharu] Function specification for XPath handler
http://lists.oasis-open.org/archives/xacml/200209/msg00143.html
STATUS: POSTPONED (9/19) Michiharu to provide DOM-equal specification.
I propose to add the following two functions. Both are XPath
related functions. I attached modified policy specification
of Example 1 and 2 (might have mistakes). This proposal has
been also agreed by Simon.
[A] Request of function additions:
- function:xpath-equal comparison on two DOM nodes
- function:xpath-match hierarchical comparison on two DOM
nodes
[B] Function description:
- function:xpath-node-equal
This function takes two arguments, the first of "xs:string"
and the second of "xs:string" and returns an
"xs:boolean". Both arguments are valid XPath expressions
defined in XPath 1.0 specification [1]. This functions
returns true if a set of DOM nodes obtained by applying the
first XPath expression on the XACML Request Context includes
at least one DOM node that is also obtained by applying the
second XPath expression on the XACML Request Context. If the
first XPath or the second XPath do not return DOM node set,
this function returns false. When XPath expression includes
one or more namespace prefix, then it is resolved using
XPathNamespace element specified in corresponding Policy
element or PolicySet element.
For example, the following expression shall return true:
<Apply FunctionId="function:xpath-equal">
<AttributeValue>/Request/Subject/Attribute[@AttributeId
="role"]/AttributeValue</AttributeValue>
<AttributeValue>/Request/Subject/Attribute[@AttributeId
="role"]/AttributeValue</AttributeValue>
</Apply>
- function:xpath-node-match:
This function takes two arguments, the first of "xs:string"
and the second of "xs:string" and returns an
"xs:boolean". Both arguments are valid XPath expressions
defined in XPath 1.0 specification [1]. This function first
extends the first argument to support pseudo hierarchical
access control on XML document structure. If "a" is an
element node and it is specified as the first argument, the
function replace it with "a | a//* | a//@*" meaning that all
the element and attributes below the specified element
"a". If "a" is an attribute node, then the function does not
modify the first argument. Then this function internally
calls xpath-equal function and return the identical return
value.
For example, the following expression shall return true when
"urn:...:xpath" attribute returns a md:patient element that
is below a md:record element:
<Apply FunctionId="function:xpath-match">
<AttributeValue>//md:record</AttributeValue>
<Apply FunctionId="function:string-one-and-only>
<ResourceAttributeDesignator AttributeId="urn:...:xpath"/>
</Apply>
</Apply>
The above function is internally replaced by:
<Apply FunctionId="function:xpath-equal">
<AttributeValue>//md:record | //md:record//* |
//md:record//@*</AttributeValue>
<Apply FunctionId="function:string-one-and-only>
<ResourceAttributeDesignator AttributeId="urn:...:xpath"/>
</Apply>
</Apply>
[C] Modified policy examples:
(Besides this proposal, I removed DataType attribute and
inserted string-one-and-only function in several places)
(See attached file: XACML-SimplePolicy.txt)(See attached file:
XACML-Rule2.txt)(See attached file: XACML-Rule3.txt)(See attached file:
XACML-rule4.txt)(See attached file: XACML-Rule1.txt)
[1] XPath 1.0, http://www.w3.org/TR/xpath
Title: Change Requests
Author: Anne Anderson
Version: 1.8, 02/09/19 (yy/mm/dd)
Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.ChangeRequests.txt
ACTION ITEMS
============
0008. [Anne] Resubmit list of mandatory/non-mandatory functions.
0017. [Carlisle] Hold vote on Anne's draft text.
0019. [Carlisle] Hold vote on Polar's draft text.
0047. [Michiharu] Provide DOM-equal specification.
LEGEND
======
NQ=no quorum; official vote required
Q=quorum
SUMMARY
=======
0001. [Daniel] Add AttributeValue element to support sequence-of values
STATUS: REJECTED (NQ 9/9;Q 9/12) Use sequence-* functions instead.
0002. [Anne] Add mandatory action-id attribute
STATUS: APPROVED (Q 8/29)
0003. [Anne] Add optional action-namespace attribute
STATUS: APPROVED (Q 8/29)
0004. [Anne] Add optional action:implied-action identifier
STATUS: APPROVED (Q 8/29)
0005. [Anne] Change <Result> ResourceURI xml attribute to ResourceId
STATUS: APPROVED (Q 8/29)
0006. [Anne] Add missing-attribute identifier for StatusCode
STATUS: APPROVED (Q 8/29)
0007. [Anne] Make context Resource Attribute minoccurs=1
STATUS: REJECTED (NQ 9/5;Q 9/12)
0008. [Anne] list mandatory vs. non-mandatory functions
STATUS: POSTPONED (9/5) Anne to resubmit when #23 resolved.
0009. [Daniel] Function naming convention
STATUS: REJECTED (Q 8/29)
0010. [Anne] allow more than two arguments to "add"
STATUS: APPROVED (Q 8/29)
0011. [Carlisle] state *Match is matched against AttributeValue
STATUS: APPROVED (Q 8/29)
0012. [Carlisle] <AttributeSelector> in <SubjectMatch> should be [optional]
STATUS: APPROVED (Q 8/29)
0013. [Carlisle] <SubjectMatch> in <SubjectAttributeDesignatorWhere> min/max
STATUS: APPROVED (NQ 9/5;Q 9/12) maxOccurs="unbounded", but minOccurs="0"
0014. [Carlisle] 10. "Security and Privacy Considerations"
STATUS: APPROVED (NQ 9/5;Q 9/12)
0015. [Carlisle] 10. "Statement Level Confidentiality": rules/policies
STATUS: APPROVED (NQ 9/9;Q 9/12) Editorial, so vote not required.
0016. [Carlisle] 10. "Policy Integrity": rule => policy
STATUS: APPROVED (NQ 9/9;Q 9/12) Editorial, so vote not required.
0017. [Carlisle] 10. "Resource Matching": NotApplicable treated as Permit
STATUS: POSTPONED (9/9) Anne to draft "open world/closed world" text [below].
0018. [Carlisle] C.3 use "First Applicable"
STATUS: APPROVED (NQ 9/9;Q 9/12) Editorial, so vote not required.
0019. [Carlisle] C. consistent error behavior
STATUS: POSTPONED (9/9) Polar has reviewed, recommends change below.
0020. [Michiharu] B.10: Resource Attributes scope value
STATUS: APPROVED (NQ 9/9;Q 9/12) Add new attribute identifier below.
0021. [Michiharu] 8.1 Operational Model: PDP description change
STATUS: APPROVED (NQ 9/9;Q 9/12)
0022. [Michiharu] 8.1 Operational Model: New sections
STATUS: REJECTED (NQ 9/9;Q 9/12) But to be included in Primer.
0023. [Daniel, Polar] function names, types, semantics
STATUS: APPROVED (Q 9/19) V0.11 + target limits plus not-* plus *<,*<=.
0024. [Anne] Make "gregorian" functions non-mandatory
STATUS: APPROVED (NQ 9/9;Q 9/12)
0025. [Anne] remove NOTATION from supported types; remove assoc. functions
STATUS: APPROVED (NQ 9/9 Q 9/12)
0026. [Michiharu] Add XPath functions as non-mandatory
STATUS: WITHDRAWN (9/19) Replaced by #47.
0027. [Michiharu] Change resource-uri to resource-id
STATUS: APPROVED (NQ 9/9;Q 9/12)
0028. [Michiharu] Add identifier for resource:syntax
STATUS: REJECTED (NQ 9/9;Q 9/12) Use DataType="<syntax>" instead.
0029. [Michiharu] Add identifier for resource:scope
STATUS: CLOSED (NQ 9/9;Q 9/12) Duplicate of #20.
0030. [Michiharu] Add identifier for resource:target-namespace
STATUS: APPROVED (NQ 9/9;Q 9/12)
0031. [Michiharu] Type of XPathVersion element from string=>anyURI
STATUS: WITHDRAWN (9/12)
0032. [Michiharu] Schema change of AttributeSelector
STATUS: ACCEPTED (Q 9/12)
0033. [Michiharu] Example two to separate document
STATUS: REJECTED (NQ 9/9;Q 9/12) But add "this is a complex example" to intro.
0034. [Polar] Target Match Semantics Section 4 & 5
STATUS: APPROVED (NQ 9/9;Q 9/12)
0035. [Michiharu] AttributeSelectorIndirect
STATUS: WITHDRAWN (9/19) Replaced by #47.
0036. [Michiharu] DataType attribute required?
STATUS: APPROVED (NQ 9/9;Q 9/12) Remove DataType in Policy; keep in Context.
0037. [Michiharu] Add normalized-string-match function
STATUS: APPROVED (NQ 9/9;Q 9/12)
0038. [Simon] Extending XACML semantics with subject-class
STATUS: WITHDRAWN (9/9)
0039. [Michiharu] Remove XPathVersion attribute from AttributeSelector
STATUS: ACCEPTED (Q 9/12)
0040. [Michiharu,Simon] Semantics of sequences
STATUS: WITHDRAWN. REPLACED BY #42-#46.
0041. [Polar] Target Match Truth Table
STATUS: APPROVED (Q 9/19)
0042. [Michiharu] XACML supports consistent specification between MatchId function and Apply function
STATUS: APPROVED (NQ 9/16)
0043. [Michiharu] XACML supports unordered set that is called a "bag"
STATUS: APPROVED (NQ 9/16)
0044. [Michiharu] XACML distinguishes singleton data from bag type
STATUS: APPROVED (NQ 9/16)
0045. [Michiharu] XACML supports higher-order bag functions
STATUS: APPROVED (NQ 9/16)
0046. [Michiharu] XACML supports operators for computing on bag types.
STATUS: APPROVED (NQ 9/16)
0047. [Michiharu] Function specification for XPath handler
STATUS: POSTPONED (9/19) Michiharu to provide DOM-equal specification.
DETAILS
=======
0001. [Daniel] Add AttributeValue element to support sequence-of values
http://lists.oasis-open.org/archives/xacml/200208/msg00047.html
http://lists.oasis-open.org/archives/xacml/200208/msg00140.html
STATUS: REJECTED (NQ 9/9;Q 9/12) Use sequence-* functions instead.
Currently <attributeValue> element is an extension of
anyType, with specified DataType. XACML functions arguments
are, in general, a sequence of typed elements - as it can be
returned by a designator from context. While most accept
only single values (sequence of size 1), some set operation
functions have an arbitrary length sequence as an argument.
We need to provide syntax to express a sequence of values as
a literal argument in set operations (like union, member_of,
intersection..)
I propose adding element Value, of anyType, and defining
<AttributeValueType> as sequence of <Value>, with DataType
attribute, applicable to all elements in the sequence. It
supports 0 size of the sequence, to support empty set in
operations
<xs:element name="Value" type="xs:anyType"/>
<xs:element name="AttributeValue"/>
<xs:complexType name="AttributeValueType">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Value"/>
</xs:sequence>
<xs:attribute name="name" type="xs:anyURI" use="required"/>
</xs:complexType>
-------------------------------------
>2. Adding a separate construct to XACML policy schema to represent
>sequences of attribute values, such that you cannot create sequeences of
>sequences.
As an alternative to my proposal to modify schema element <attributevalue>,
I propose to define standard core function collection
<type>-sequence
of undefined arity, that takes arguments of singleton <type> kind and return
a sequence<type> value, a sequence of its argument values.
In this case, when a literal sequence definition is needed, this funciton
can be used. No schema modification is needed.
The drawback is that it can not be used to specify an argument of
sequence<type> kind for predicate functions that can be used in <Match>
elements.
0002. [Anne] Add mandatory action-id attribute
STATUS: APPROVED (Q 8/29)
Create a reserved attribute identifier
"urn:oasis:names:tc:xacml:1.0:action:action-id". Make
inclusion of an <Attribute> with AttributeId of this
identifier mandatory under the <Action> element of the
<Request> context. Change minOccurs for <Attribute> under
<Action> 1.
Rationale:
We had previously decided that <Action> would have a single
string value that would be the action id. Now we need a
specific AttributeId for this.
This is consistent with the way resource-id is handled. It
provides a consistent, interoperable way of specifying the
action. The <DataType> of the <Attribute> can specify
whether the action value is a string or URI.
0003. [Anne] Add optional action-namespace attribute
STATUS: APPROVED (Q 8/29)
Create a reserved attribute identifier
"urn:oasis:names:tc:xacml:1.0:action:action-namespace". Make
inclusion of an <Attribute> with AttributeId of this
identifier optional under the <Action> element of the
<Request> context.
Rationale:
We previously decided that an <Action> value might be
associated with a specific namespace, and that an XML
attribute was needed to express this.
0004. [Anne] Add optional action:implied-action identifier
STATUS: APPROVED (Q 8/29)
Create a reserved identifier
"urn:oasis:names:tc:xacml:1.0:action:implied-action" to
represent the value of an action that is implied by the
<Resource>
Rationale:
We have agreed to this concept, but have not reserved an
identifier for it.
0005. [Anne] Change <Result> ResourceURI xml attribute to ResourceId
STATUS: APPROVED (Q 8/29)
Rationale:
Since the Request <Resource> identifier is now called
resource-id, and can be of any data type, the <Result> should
be consistent.
0006. [Anne] Add missing-attribute identifier for StatusCode
STATUS: APPROVED (Q 8/29)
Rationale:
We have values for ok, processing-error, and syntax-error.
Although we discussed the use case for missing attributes
extensively, we have not defined a standard identifier for this
status.
0007. [Anne] Make context Resource Attribute minoccurs=1
STATUS: REJECTED (NQ 9/5;Q 9/12)
Current value is minOccurs=0 maxOccurs=unbounded. Change this
to minOccurs=1 maxOccurs=unbounded.
Rationale:
Since Resource MUST contain a resource-id attribute, minimum
value should be 1.
0008. [Anne] list mandatory vs. non-mandatory functions
http://lists.oasis-open.org/archives/xacml/200208/msg00069.html
STATUS: POSTPONED (9/5) Anne to resubmit when #23 resolved.
Add a list of all functions, with an indicator as to
whether the function is mandatory to implement, to the
Conformance Section.
This list should be updated based on the final resolution
of CR#23.
Rationale:
I forgot to include these when I created the original list.
Text to be inserted:
[complete list of functions in e-mail]
0009. [Daniel] Function naming convention
http://lists.oasis-open.org/archives/xacml/200208/msg00071.html
STATUS: REJECTED (Q 8/29)
Change function names to blah_blah
Rationale:
Dashes are not always supported.
0010. [Anne] allow more than two arguments to "add"
http://lists.oasis-open.org/archives/xacml/200208/msg00090.html
STATUS: APPROVED (Q 8/29)
Allow function:integer-add and function:decimal-add to take
more than two arguments.
Rationale:
This saves having to write nested statements for these simple
operations.
0011. [Carlisle] state *Match is matched against AttributeValue
http://lists.oasis-open.org/archives/xacml/200208/msg00094.html
STATUS: APPROVED (Q 8/29)
In section 5.7 (Element <SubjectMatch>), I think we need to
specify that whatever is returned by
SubjectAttributeDesignator or AttributeSelector is matched
against the value carried in AttributeValue. The same is
true for <ResourceMatch> and <ActionMatch> (sections 5.10 and
5.13).
Rationale:
This behaviour is not spelled out anywhere. (In fact,
AttributeValue is not even described in the "list of elements
contained in <SubjectMatch>" discussion; it only appears in
the schema fragment.)
0012. [Carlisle] <AttributeSelector> in <SubjectMatch> should be [optional]
http://lists.oasis-open.org/archives/xacml/200208/msg00094.html
STATUS: APPROVED (Q 8/29)
Make <AttributeSelector> in <SubjectMatch> [optional] rather
than [required].
Rationale:
Also, in the "list of elements contained in <SubjectMatch>"
discussion, why is <AttributeSelector> described as
[required]? I thought it was optional.
0013. [Carlisle] <SubjectMatch> in <SubjectAttributeDesignatorWhere> min/max
http://lists.oasis-open.org/archives/xacml/200208/msg00094.html
STATUS: APPROVED (NQ 9/5;Q 9/12) maxOccurs="unbounded", but minOccurs="0"
Make minOccurs="1" and maxOccurs="unbounded" for
<SubjectMatch> in <SubjectAttributeDesignatorWhere>.
Rationale:
In section 5.26 (Element <SubjectAttributeDesignatorWhere>),
why does the element <SubjectMatch> have minOccurs="0"? If
this element was omitted, you wouldn't use
SubjectAttributeDesignatorWhere; you would just use
SubjectAttributeDesignator. In any case, the verbal
description says that SubjectMatch has [Any Number], so I
suspect that minOccurs="0" in the schema should be changed to
maxOccurs="unbounded".
0014. [Carlisle] 10. "Security and Privacy Considerations"
http://lists.oasis-open.org/archives/xacml/200208/msg00096.html
STATUS: APPROVED (NQ 9/5;Q 9/12)
Change title of Section 10 to "Security and Privacy
Considerations".
Rationale:
Should this be called "Security and Privacy Considerations"
instead of just "Security and Privacy"?
0015. [Carlisle] 10. "Statement Level Confidentiality": rules/policies
http://lists.oasis-open.org/archives/xacml/200208/msg00096.html
STATUS: APPROVED (NQ 9/9;Q 9/12) Editorial, so vote not required.
In the 10. "Statement Level Confidentiality" section, 1st
paragraph, say "... a PRP only needs access to the target
elements in order to find the appropriate policies".
Rationale:
Currently says: "... a PRP only needs access to the target
elements in order to find the appropriate rules". Should
this say "rules/policies", or just "policies", instead of
"rules"?
0016. [Carlisle] 10. "Policy Integrity": rule => policy
http://lists.oasis-open.org/archives/xacml/200208/msg00096.html
STATUS: APPROVED (NQ 9/9;Q 9/12) Editorial, so vote not required.
In the 10. "Policy Integrity" section, 4th paragraph, say
"The PDP SHOULD NOT request a policy based on who signed the
policy...".
Rationale:
In the "Policy Integrity" section, 4th paragraph, it
currently says "The PDP SHOULD NOT request a rule based on
who signed the rule...". Should both occurrences of "rule"
be "policy"?
0017. [Carlisle] 10. "Resource Matching": NotApplicable treated as Permit
http://lists.oasis-open.org/archives/xacml/200208/msg00096.html
STATUS: POSTPONED (9/9) Anne to draft "open world/closed world" text [below].
In 10. "Resource Matching" section, say, 'although the
policy result of "Not Applicable" is treated as equivalent
to "Permit" by many web servers, this behavior is not
recommended.'
Rationale:
In the "Resource Matching" section, 1st paragraph, it says
"... the policy result of "Not Applicable" is treated as
equivalent to "Permit" as is common in many web servers".
I'm a bit surprised that this is true (although I probably
shouldn't be!). In any case, we probably don't want to
encourage this behaviour. Should we simply not mention
this, or should we at least say that this behaviour is not
recommended?
Hal's rejoinder:
First of all, this is intended as a cautionary
example. However, this is a real world problem that affects
my product, and all of our compeitors. I can show you
security holes posted to BUGTRAQ, for example, where this
occurred. We have struggled with it for years. The Not
Applicable == Permit behavior is not only standard for web
servers, it is embedded in the Java Servlet and JSP
specifications.
The logic is that only a small portion of the resources on
a public web server are protected, so people want to only
specify rules for those that are. If the namespace is not
conveniencely laid out (as most are not) it may require a
number of rules just to specify all the pages that are not
protected.
[Anne draft of "Open World/Closed World" considerations]
Draft change to "Security and Privacy Considerations"
"Resource Matching" section:
1. Change title to "NotApplicable Results"
A result of "NotApplicable" means that the PDP did not have a
Policy whose Target matched the information in the Request.
In some security models, such as is common in many Web
Servers, a result of "NotApplicable" is treated as equivalent
to "Permit".
If "NotApplicable" is to be treated as "Permit", is it vital
that the matching algorithms used by the Policy to match
elements in the Request are closely aligned with the data
syntax used by the applications that will be making the
Request. A failure to match will be treated as "Permit", so
an unintended failure may allow unintended access.
A common example of this is a Web Server. Commercial http
responders permit a variety of syntaxes to be treated
equivalently. The "%" can be used to represent characters by
hex value. In the URL path "/../" provides multiple ways of
specifying the same value. Multiple character sets may be
permitted and, in some cases, the same printed character can
be represented by different binary values. Unless the
matching algorithm used by the Policy is sophisticated enough
to catch these variations, unintended access may be allowed.
It is safe to treat "NotApplicable" as "Permit" ONLY in a
closed environment where all applications that formulate a
Request are closely aligned with the Policies used by the
PDP. In a more open environment, where Requests may be
received from applications that are not necessarily closely
aligned with the Policies used by the PDP, it is HIGHLY
RECOMMENDED that "NotApplicable" NOT be treated as "Permit"
unless matching rules have been very carefully designed to
match ALL possible applicable inputs, regardless of syntax or
type variations.
0018. [Carlisle] C.3 use "First Applicable"
http://lists.oasis-open.org/archives/xacml/200208/msg00099.html
STATUS: APPROVED (NQ 9/9;Q 9/12) Editorial, so vote not required.
Call Section C.3, "First Applicable" rather than "First
Applicable Rule Combining Algorithm".
In first sentence of C.3, change "First Determinate"
rule-combining algorithm to "First Applicable".
Rationale:
Section C.3, should this be called "First Applicable"
rather than "First Applicable Rule Combining Algorithm"?
This would be more consistent with both C.1 and C.2, and
would also be more consistent with the fact that C.3
contains both a rule combining algorithm and a policy
combining algorithm.
The first sentence of C.3 calls it the "First Determinate"
rule-combining algorithm; this should be changed to "First
Applicable".
0019. [Carlisle] C. consistent error behavior
http://lists.oasis-open.org/archives/xacml/200208/msg00099.html
STATUS: POSTPONED (9/9) Polar has reviewed, recommends change below.
Policy combiner should halt and return Indeterminate when
an error is encountered.
Rationale:
The behaviour specified in the policy-combining algorithm
when an error is encountered is different from the
behaviour specified in the rule-combining algorithm when an
error is encountered (the rule combiner says halt and
return Indeterminate, whereas the policy combiner says to
keep looking for an applicable policy). Is this what we
wanted?
More importantly, might the policy combiner behaviour not
lead to different answers for the same inputs? For
example, say there are two policies that are to be combined
using this algorithm. Given a particular set of input
values, the first policy would return a decision of
"Permit" and the second policy would return a decision of
"Deny". Now we give all the inputs to two different PDPs.
The first PDP retrieves the first policy, gets an answer of
"Permit", and returns this to the PEP. The second PDP has
trouble retrieving the first policy for whatever reason
and, according to the combining algorithm, retrieves the
second policy; it then returns a "Deny" to the PEP. Isn't
this the sort of result we want to avoid? Wouldn't the
behaviour specified in the rule combining algorithm be
preferable (that way, the first PDP would return "Permit"
and the second would return "Indeterminate", which seems
fine to me)?
[Polar] I agree with Carlisle that the problem he states
needs to be reckoned with CR 19. The current algorithm breaks
monotonicity in the evaluation of the First Applicable Policy
Combining algorithm, as he points out. It should model the
rule combinging algorithm.
We should modify the current document by replacing the
following paragraph:
If there is any error evaluating the target or the policy, or
a reference to a policy is considered invalid, then the
evaluation shall continue looking for an applicable policy,
if no applicable policy is found, then the result of the
combination is "Indeterminate".
with:
If there is any error evaluating the target, or while
evaluating a specific policy, the reference to the policy is
considered invalid, or the policy itself evaluates to
"Indeterminate", then the evaluation of the combining
algorithm shall halt, and the result shall be "Indeterminate"
with an appropriate error status.
The pseudo code should say:
Decision firstApplicableEffectPolicyCombiningAlgorithm(Policy policy[])
{
for( i = 0 ; i < lengthOf(policy) ; i++ )
{
Decision decision = evaluate(policy[i]);
if(decision == Deny)
{
return Deny;
}
if(decision == Permit)
{
return Permit;
}
if (decision == NotApplicable)
{
continue;
}
if (decision == Indeterminate)
{
return Indeterminate;
}
}
return NotApplicable;
}
0020. [Michiharu] B.10: Resource Attributes scope value
http://lists.oasis-open.org/archives/xacml/200208/msg00112.html
STATUS: APPROVED (NQ 9/9;Q 9/12) Add new attribute identifier below.
In B.10, the identifier indicates the scope of the request
with regard to the resource. When this Attribute is
specified in the request, the value MUST be either
'Immediate', 'Children', or 'Descendant'.
New identifier is: urn:oasis:names:tc:xacml:1.0:resource:scope
0021. [Michiharu] 8.1 Operational Model: PDP description change
http://lists.oasis-open.org/archives/xacml/200208/msg00112.html
STATUS: APPROVED (NQ 9/9;Q 9/12)
8.1 Policy Decision Point (PDP)
Given a valid XACML "Policy" or a "PolicySet", a compliant XACML PDP MUST
evaluate that statement in accordance to the semantics specified in Section
4,5, and 6 when applied to a specific input context. The PDP MUST return an
output context, with one value of "Permit", "Deny", "Indeterminate", or
"NotApplicable".
If a permit is returned, the PEP permit access to the requested resource.
If a denial is returned, the PEP denies access to the requested resource.
If a permit with one or more obligations is returned, the PEP permits
access provided that every obligations are fulfilled successfully. If a
denial with one or more obligations is returned, the PEP denies access but
still fulfills the obligations. In each case, when fulfilling obligations
failed, the PEP SHOULD raise an error. How the error is raised is out of
the scope of XACML. In any case, the PDP can return additional information
in the status code element in the response context. For 'Permit' decision,
it MAY specify which rules are used in decision making.
If an indeterminate is returned, it means that the PDP could not make
decision due to some reason. The PDP MAY return decision of "indeterminate"
with a status code of "urn:oasis:names:tc:xacml:1.0:missing-attribute",
signifying that more information is needed. In this case, the decision MAY
list the names of any attributes of the subject and the resource that are
needed by the PDP to refine its decision. A PEP MAY resubmit a refined
request context in response to a decision of "indeterminate" with a status
code of "missing-attribute" by adding attribute values for the attribute
names that are listed in the response. When the PDP returns an decision of
"indeterminate", with a status code of "missing-attribute", a PDP MUST NOT
list the names of any attribute of the subject or the resource of the
request for which values were already supplied in the request. Note, this
requirement forces the PDP to eventually return a decision of "permit",
"deny", or "indeterminate" with some other reason, in response to
successively-refined requests.
If not applicable is returned, it means that the PDP's policy does not
cover the request, implying that the PEP should ask another PDP.
XACML does not assume how top-level XACML policies should be configured.
For example, a top-level policy might be a 'Policy' element containing a
target element that matches every request, or it might be a 'Policy'
element containing a target element that matches only a specific subject.
0022. [Michiharu] 8.1 Operational Model: New sections
http://lists.oasis-open.org/archives/xacml/200208/msg00112.html
STATUS: REJECTED (NQ 9/9;Q 9/12) But to be included in Primer.
8.2 Hierarchical Resource
It is often the case that a target resource is organized as a hierarchy
(e.g. file system, XML document). Some applications may require access to
an entire subtree of the resource. XACML allows the PEP (or Context
Handler) to specify whether the access is just for a single resource or for
a subtree below the specified resource. The latter is equivalent to
repeating a single request for the entire subtree. When a request context
contains a resource attribute of
'urn:oasis:names:tc:xacml:1.0:resource:scope' with a value of 'Immediate',
or does not contain that attribute in the context, then it means that the
access is just for a single resource specified by 'ResourceId' attribute.
When 'urn:oasis:names:tc:xacml:1.0:resource:scope' attribute specifies a
value of 'Children', it means that the access is for both a specified
resource and its children resources. When
'urn:oasis:names:tc:xacml:1.0:resource:scope' attribute specifies a value
of 'Descendant', it means that the access is for both a specified resource
and all the descendant resources. In the case of 'Children' and
'Descendant', the access decision may include multiple results for the
multiple resources. XACML response can contain multiple result elements. In
such case, the status element SHOULD be included only in the first result
element (the remaining result elements SHOULD NOT include the status
element). Note that the method how PDP finds out whether the resource is
hierarchically organized or not is out of the scope of the XACML.
8.3 Propagation through Data Hierarchy
When the resource is hierarchically organized, it is often the case that an
access control rule associated to a certain node propagates down to the
descendant nodes. The XACML core rule combining algorithm does not support
such propagation with regard to access control rules. Policy writers who
need propagation MUST implement their own local algorithm and specify that
algorithm ID in RuleCombiningAlgId in policy element.
0023. [Daniel, Polar] function names, types, semantics
http://lists.oasis-open.org/archives/xacml/200208/msg00181.html
http://lists.oasis-open.org/archives/xacml/200209/msg00134.html (V0.11)
STATUS: APPROVED (Q 9/19) V0.11 + target limits plus not-* plus *<,*<=.
Daniel and Polar have developed a list of functions and
their semantics, attached to the above
e-mail.
0024. [Anne] Make "gregorian" functions non-mandatory
http://lists.oasis-open.org/archives/xacml/200208/msg00137.html
STATUS: APPROVED (NQ 9/9;Q 9/12)
Text Changes:
Section 11.1.4(?) [Conformance] Functions
Remove "M" from left column of
urn:oasis:names:tc:xacml:1.0:function:gregorian-equal
Rationale:
We already support xs:date, so support for Gregorian is icing
on the cake. Also, I haven't found a standard for "gregorian",
so it is hard to develop tests for it.
0025. [Anne] remove NOTATION from supported types; remove assoc. functions
http://lists.oasis-open.org/archives/xacml/200208/msg00138.html
STATUS: APPROVED (NQ 9/9 Q 9/12)
Text Changes:
Section 11. Conformance, DataTypes, remove:
line listing "xs:NOTATION"
Appendix A.1. Functions, remove:
function:NOTATION-equal
function:NOTATION-not-equal
Rationale:
XML Schema says
"It is an error for NOTATION to be used directly
in a schema. Only datatypes that are derived from NOTATION by
specifying a value for enumeration can be used in a schema.
For compatibility NOTATION should be used only on attributes."
Also, QName-equal and QName-not-equal can be used to compare
such data types if necessary.
I'm on thin ground here, since I don't know enough about XML
Schema to be sure I am interpreting the impact of this
correctly.
0026. [Michiharu] Add XPath functions as non-mandatory
http://lists.oasis-open.org/archives/xacml/200208/msg00142.html
STATUS: WITHDRAWN (9/19) Replaced by #47.
[See referenced e-mail for function definitions]
I propose to include the following functions (all relevant to XPath) in the
spec as non-mandatory to implement functions. The original proposal (a
little different from this proposal) was posted on 29th July and it
described more in detail.
http://lists.oasis-open.org/archives/xacml/200207/msg00162.html
function:general-string-equal xs:boolean object(*1) object A
= B
function:node-boolean xs:boolean object
function:node-match xs:boolean object object
========================
(*1) "object" type is defined in Introduction section of [2] as:
"... object, which has one of the following four basic types:
node-set (an unordered collection of nodes without duplicates)
boolean (true or false)
number (a floating-point number)
string (a sequence of UCS characters)"
[1] XQuery 1.0 and XPath 2.0 Data Model,
http://www.w3.org/TR/xquery-operators/
[2] XPath 1.0, http://www.w3.org/TR/xpath
0027. [Michiharu] Change resource-uri to resource-id
http://lists.oasis-open.org/archives/xacml/200208/msg00143.html (A1)
STATUS: APPROVED (NQ 9/9;Q 9/12)
urn:oasis:names:tc:xacml:1.0:resource:resource-uri
==>
urn:oasis:names:tc:xacml:1.0:resource:resource-id
0028. [Michiharu] Add identifier for resource:syntax
http://lists.oasis-open.org/archives/xacml/200208/msg00143.html (B1)
STATUS: REJECTED (NQ 9/9;Q 9/12) Use DataType="<syntax>" instead.
urn:oasis:names:tc:xacml:1.0:resource:syntax
This identifier indicates the syntax of the resource-id
(urn:oasis:names:tc:xacml:1.0:resource:resource-id). The valid values are
either 'String', 'URI' or 'XPointer'. If this attribute is omitted,
'String' syntax is assumed. 'URI' indicates that the syntax of the
resource-id is URI format. 'XPointer' indicates that the syntax of the
resource-id is XPointer format proposed in
http://www.w3.org/TR/2001/CR-xptr-20010911/.
0029. [Michiharu] Add identifier for resource:scope
http://lists.oasis-open.org/archives/xacml/200208/msg00143.html (B2)
STATUS: CLOSED (NQ 9/9;Q 9/12) Duplicate of #20.
urn:oasis:names:tc:xacml:1.0:resource:scope
This identifier indicates the scope of the resource. The valid values are
either 'Immediate', 'Children', or 'Descendant'. When 'Immediate', it
indicates that the scope of the resource is a target value specified by
urn:oasis:names:tc:xacml:1.0:resource:resource-id attribute. When
'Children', it indicates that the scope of the resource is a target value
specified by urn:oasis:names:tc:xacml:1.0:resource:resource-id attribute
and its children resource. When 'Descendant', it indicates that the scope
of the resource is a target value specified by
urn:oasis:names:tc:xacml:1.0:resource:resource-id attribute and all the
descendant resources.
0030. [Michiharu] Add identifier for resource:target-namespace
http://lists.oasis-open.org/archives/xacml/200208/msg00143.html (B3)
STATUS: APPROVED (NQ 9/9;Q 9/12)
urn:oasis:names:tc:xacml:1.0:resource:target-namespace
This identifier indicates the target-namespace of the requested XML
document, that is a namespace URI associated with the root element of the
XML document.
0031. [Michiharu] Type of XPathVersion element from string=>anyURI
http://lists.oasis-open.org/archives/xacml/200208/msg00144.html
STATUS: WITHDRAWN (9/12)
Schema change request
<xs:element name="XPathVersion" type="xs:string" substitutionGroup
="xacml:AbstractDefaults"/>
==>
<xs:element name="XPathVersion" type="xs:anyURI" substitutionGroup
="xacml:AbstractDefaults"/>
[Simon] this would require type of AbstractDefaults to be
changed to anyURI. Possibly OK, but need to evaluate impact.
0032. [Michiharu] Schema change of AttributeSelector
http://lists.oasis-open.org/archives/xacml/200209/msg00078.html
STATUS: ACCEPTED (Q 9/12)
I propose to change the AttributeSelector element.
<xs:complexType name="AttributeSelectorType">
<xs:attribute name="RequestContextPath" type="xs:anyURI" use="required"/>
<xs:attribute name="DataType" type="xs:anyURI" use="required"/>
<xs:attribute name="XPathVersion" type="xs:anyURI" use="optional" default
="http://www.w3.org/TR/1999/Rec-xpath-19991116"/>
</xs:complexType>
==>
<xs:complexType name="AttributeSelectorType">
<xs:element ref="xacml:XPathNamespace" minOccurs="0" maxOccurs
="unbounded"/>
<xs:attribute name="RequestContextPath" type="xs:anyURI" use
="optional"/>
<xs:attribute name="DataType" type="xs:anyURI" use="optional"/>
</xs:complexType>
<xs:element name="XPathNamespace" type="xacml:XPathNamespaceType"
substitutionGroup="xacml:AbstractDefaults"/>
<xs:complexType name="XPathNamespaceType">
<xs:attribute name="NamespaceURI" type="xs:anyURI"/>
<xs:attribute name="Prefix" type="xs:string" use="optional"/>
</xs:complexType>
Scope of the XPathNamespace for AttributeSelector element:
1. AttributeSelector element that includes XPathNamespace
element, XPathNamespace elements in PolicyDefaults or
PolicySetDefaults elements that include the
AttributeSelector element.
For the precedence,
1. XPathNamespace elements in AttributeSelector take
precedence over XPathNamespace elements in PolicyDefaults
in Policy element..
2. XPathNamespace elements in PolicyDefaults in Policy take
precedence over XPathNamespace elements in
PolicySetDefaults in PolicySet element..
3. If there are two or more identical prefixes are specified
under an AttributeSelector, a PolicyDefaults or a
PolicySetDefaults elements, the last prefix takes
precedence over the previous prefixes.
Others:
1. Global xmlns attribute is not used for resolving
namespace-prefix pair specified in XPath expression.
2. If no XPathNamespace element is found in valid scope, it
means no namespace-prefix pair is defined.
3. If Prefix attribute is missing, it means that default
namespace is defined.
Text change request
In Section 5.3, Element <PolicySetDefaults>, line 1487-1489,
<AbstractDefaults>[Any Number]
This is the head of substitution group to specify default parameters. The
elements in this substitution group defined at this time is
<XPathNamespace>
element.
0033. [Michiharu] Example two to separate document
http://lists.oasis-open.org/archives/xacml/200208/msg00147.html
STATUS: REJECTED (NQ 9/9;Q 9/12) But add "this is a complex example" to intro.
After looking at line 589-1102, I think that Section 3.2
policy specification in Example two is too complicated for
average readers. While my preference is to hold this example
in the spec, most readers would feel that XACML is difficult
to read and understand when they try to go through this
example. Besides, this example requires expertise about XPath
syntax and its data model that is basically different from
this specification. Honestly speaking, it is a little
difficult even for me... :-). So my suggestion is to move
this section to a separate document (say Primer document or
Use Case document).
[We decided to keep the example, but revise the introduction
slightly to make it clear that this is a very complex example
intended to illustrate various features of the XACML
language. The functions also need to be updated. Polar will
do that.]
0034. [Polar] Target Match Semantics Section 4 & 5
http://lists.oasis-open.org/archives/xacml/200208/msg00188.html
[long set of specific text changes included in e-mail]
http://lists.oasis-open.org/archives/xacml/200208/msg00189.html (correction)
STATUS: APPROVED (NQ 9/9;Q 9/12)
The semantics for the Target need to be updated. It doesn't seem to
describe how "Match" or "No-Match" are derived at. The document mentions
logical-AND and logical-OR, and they are not defined for Match and
No-Match. Also, we need to resolve the discovery and issue of the
inconsistency between the evaluation of Target and Condition with respect
to Indeterminate and NotApplicable, now that we are making progress on the
"functions" document.
I feel that if we refer to the Target evaluations with the same semantics
as Condition, we can leverage the use of True, False, and Indeterminate
that we have already defined, and then we can use the notions of
conjunctive sequence and disjunctive sequence as combinators of our
boolean values (true, false, indeterminate) with the normative
specifications of our functions "function:and" and "function:or" for the
combining rules. This will take care of the normative handling of error
conditions in the evaluation logic.
When the XACML Data Types, Functions, and Semantics gets put in the
document, I suggest making the following changes. Some changes are
editorial.
Note: There is some issue about <Target> and <Condition> of where they say
that they possible to be "empty", but I'm not sure if that means "omitted"
(i.e. minOccurs="0"), or <Target/>, or <Condition/>.
0035. [Michiharu] AttributeSelectorIndirect
http://lists.oasis-open.org/archives/xacml/200208/msg00190.html
http://lists.oasis-open.org/archives/xacml/200208/msg00201.html (followup)
http://lists.oasis-open.org/archives/xacml/200209/msg00016.html (more)
http://lists.oasis-open.org/archives/xacml/200209/msg00024.html (Polar)
http://lists.oasis-open.org/archives/xacml/200209/msg00030.html (Michiharu)
http://lists.oasis-open.org/archives/xacml/200209/msg00031.html (Polar)
http://lists.oasis-open.org/archives/xacml/200209/msg00035.html (Daniel)
http://lists.oasis-open.org/archives/xacml/200209/msg00036.html (Daniel)
http://lists.oasis-open.org/archives/xacml/200209/msg00040.html (Polar)
http://lists.oasis-open.org/archives/xacml/200209/msg00042.html (Daniel)
STATUS: WITHDRAWN (9/19) Replaced by #47.
Based on the discussion on Monday call, Simon and I agreed to changing the
schema to support an AttributeSelectorIndirect element to retrieve a XPath
expression from the context.
0036. [Michiharu] DataType attribute required?
http://lists.oasis-open.org/archives/xacml/200208/msg00192.html
STATUS: APPROVED (NQ 9/9;Q 9/12) Remove DataType in Policy; keep in Context.
DataType attribute in AttributeDesignatorType is 'required'. But in most
cases, AttributeDesignator is used below the matching function (e.g.
string-match) and that function is type-specific. So I think "DataType"
attribute is not required. I propose to change it to "optional".
<xs:complexType name="AttributeDesignatorType">
<xs:attribute name="AttributeId" type="xs:anyURI" use="required"/>
<xs:attribute name="DataType" type="xs:anyURI" use="required"/>
<xs:attribute name="Issuer" type="xs:anyURI" use="optional"/>
</xs:complexType>
[should be]
<xs:complexType name="AttributeDesignatorType">
<xs:attribute name="AttributeId" type="xs:anyURI" use="required"/>
<xs:attribute name="DataType" type="xs:anyURI" use="optional"/>
<xs:attribute name="Issuer" type="xs:anyURI" use="optional"/>
</xs:complexType>
0037. [Michiharu] Add normalized-string-match function
http://lists.oasis-open.org/archives/xacml/200209/msg00056.html
STATUS: APPROVED (NQ 9/9;Q 9/12)
- Handling whitespace
XPath 1.0 (and 2.0) has a function called normalize-space() that strips
leading and trailing whitespace and replacing sequences of whitespace
characters by a single space. Some people suggests to use this function
whenever string equality is checked on a XML document. That hides subtle
issues like how to handle whitespace in XML. However, some applications may
need non-normlized string comparison.
So my suggestion is to support two kinds of string-equal functions:
string-equal and normalized-string-equal. The string-equal does not
normalize the string and the normalized-string-equal works as if it invokes
normalize-space() function internally before comparison is made. The
normalized-string-equal function is necessary if a user need to specify
this function in MatchId attribute. When string-equal is used, any
whitespace handling specifier "xml:space" attribute on XACML Request
Context will be ignored except for the element inside the ResourceContent
element.
- Semantics of the string comparison
XPath 2.0 defines xf:compare function instead of defining xf:string-equal
function. The xf:compare has an optional argument called "collation" that
specifies Unicode collation algorithm. The draft says, if it is omitted,
the default collation is used (but its rule is TBD). Then, if we assume
that there is a default collation for XACML, the function:string-equal is
defined as "it returns true depending on the value of the first string is
equal to the value of the second string according to the rules of the
collation that is used. Otherwise, false is returned". We may add "if
either argument is the empty sequence, it returns false". Default collation
in XACML would be "comparison on each character of the string using
integer-equal".
0038. [Simon] Extending XACML semantics with subject-class
http://lists.oasis-open.org/archives/xacml/200209/msg00052.html
STATUS: WITHDRAWN (9/9)
0039. [Michiharu] Remove XPathVersion attribute from AttributeSelector
http://lists.oasis-open.org/archives/xacml/200209/msg00078.html
STATUS: ACCEPTED (Q 9/12)
I request to remove "XPathVersion" attribute from
AttributeSelector element. The reason is that we already
allow a default value of XPathVersion in Policy and PolicySet
elements. Since the minimum unit of the policy rules are
Policy element, I think it is sufficient to specify XPath
version information at a policy level, not at each
AttributeSelector level. Policy writer who uses
AttributeSelector must specify the xpath version in
PolicyDefaults or PolicySetDefaults element. The value of
XPath 1.0 version is
"http://www.w3.org/TR/1999/Rec-xpath-19991116";.
0040. [Michiharu,Simon] Semantics of sequences
http://lists.oasis-open.org/archives/xacml/200209/msg00071.html
STATUS: WITHDRAWN. REPLACED BY #42-#46.
As far as I understand, the model for comparing two sequences
in function draft 0.8 seems not sufficient for comparison
(matching) framework. I am assuming that our data model
supports a sequence as a base type. For example,
type-member-of function supports only equality comparison but
not other kinds of comparison such as string-greater-than
etc. My opinion is that we need to specify two things: how to
compare two sequences and how to compare each element.
Draft documents and more of the proposal included in the
e-mail.
0041. [Polar] Target Match Truth Table
http://lists.oasis-open.org/archives/xacml/200208/msg00188.html
http://lists.oasis-open.org/archives/xacml/200208/msg00189.html (correction)
STATUS: APPROVED (Q 9/19)
Text change:
4.3.1.4 Rule evaluation
A rule has a value that can be calculated by evaluating its contents.
Rule evaluation involves separate evaluation of the rule's target and
condition. The result of rule's target and condition are evaluated as if
the "function:and" were applied to both results.
The rule truth table is shown in Table 1.
Target Condition Rule
True True Effect
True False Not Applicable
True Indeterminate Indeterminate
False True Not Applicable
False False Not Applicable
False Indeterminate Not Applicable
Indeterminate True Indeterminate
Indeterminate False Indeterminate
Indeterminate Indeterminate Indeterminate
Table 1 - Rule truth table
[The subsequent 2 paragraphs after the table are no longer true, and
should be removed.]
0042. [Michiharu] XACML supports consistent specification between MatchId function and Apply function
http://lists.oasis-open.org/archives/xacml/200209/msg00098.html
STATUS: APPROVED (NQ 9/16)
In ver 0.8 function draft, string comparison (set against a
value) is differently specified in MatchId from
Apply. Suppose attribute selector returns a sequence
(e.g. "aaa" and "bbb"). In ResourceMatch,
function:string-equal is used while in Apply,
function:string-member-of is used:
<ResourceMatch MatchId="function:string-equal">
<AttributeSelector RequestContextPath="/a/b/c/text()">
<AttributeValue>bbb</AttributeValue>
</ResourceMatch>
|<Apply FunctionId="function:string-member-of">
<AttributeValue>bbb</AttributeValue>
<AttributeSelector RequestContextPath="/a/b/c/text()">
</Apply>
We fix the above problem by using the higher-order bag
function specified in 0.9 function draft:
<ResourceMatch MatchId="function:string-equal">
<AttributeDesignator AttributeId="role1"/>
<AttributeValue>bbb</AttributeValue>
</ResourceMatch>
<Apply FunctionId="function:any-of-each">
<Function FunctionId="function:string-equal"/>
<AttributeDesignator AttributeId="role1"/>
<AttributeValue>bbb</AttributeValue>
</Apply>
When we specify policy for MatchId, function:any-of-each is
implicitly used for specifying the semantics of the
comparison on bags.
0043. [Michiharu] XACML supports unordered set that is called a "bag"
http://lists.oasis-open.org/archives/xacml/200209/msg00098.html
STATUS: APPROVED (NQ 9/16)
XACML supports an unordered set type and does not support a
sequence type because there is few requirement that needs
sequence dependent policy specification (e.g. sequence-equal
function (or point-wise comparison) in XPath 2.0 draft is one
of such requirement but TC members decided that is a lower
priority). We rename it from "sequence (unordered set)" to
"bag".
0044. [Michiharu] XACML distinguishes singleton data from bag type
http://lists.oasis-open.org/archives/xacml/200209/msg00098.html
STATUS: APPROVED (NQ 9/16)
XACML has two kinds of functions: a function that defines
semantics on singleton data (e.g. function:string-equal), and
a function that defines the semantics on bags
(e.g. function:any-of-each). This means that XACML
distinguishes singleton data from bag type. We don't
distinguish them by local name or its prefix. The
specification lists function names as text.
0045. [Michiharu] XACML supports higher-order bag functions
http://lists.oasis-open.org/archives/xacml/200209/msg00098.html
STATUS: APPROVED (NQ 9/16)
XACML supports higher-order bag functions as 0.9 draft
describes.
0046. [Michiharu] XACML supports operators for computing on bag types.
http://lists.oasis-open.org/archives/xacml/200209/msg00098.html
STATUS: APPROVED (NQ 9/16)
Comparison among bag types (e.g. any-of-each) is defined by
higher-order bag functions as 0.9 draft describes.
0047. [Michiharu] Function specification for XPath handler
http://lists.oasis-open.org/archives/xacml/200209/msg00143.html
STATUS: POSTPONED (9/19) Michiharu to provide DOM-equal specification.
I propose to add the following two functions. Both are XPath
related functions. I attached modified policy specification
of Example 1 and 2 (might have mistakes). This proposal has
been also agreed by Simon.
[A] Request of function additions:
- function:xpath-equal comparison on two DOM nodes
- function:xpath-match hierarchical comparison on two DOM
nodes
[B] Function description:
- function:xpath-node-equal
This function takes two arguments, the first of "xs:string"
and the second of "xs:string" and returns an
"xs:boolean". Both arguments are valid XPath expressions
defined in XPath 1.0 specification [1]. This functions
returns true if a set of DOM nodes obtained by applying the
first XPath expression on the XACML Request Context includes
at least one DOM node that is also obtained by applying the
second XPath expression on the XACML Request Context. If the
first XPath or the second XPath do not return DOM node set,
this function returns false. When XPath expression includes
one or more namespace prefix, then it is resolved using
XPathNamespace element specified in corresponding Policy
element or PolicySet element.
For example, the following expression shall return true:
<Apply FunctionId="function:xpath-equal">
<AttributeValue>/Request/Subject/Attribute[@AttributeId
="role"]/AttributeValue</AttributeValue>
<AttributeValue>/Request/Subject/Attribute[@AttributeId
="role"]/AttributeValue</AttributeValue>
</Apply>
- function:xpath-node-match:
This function takes two arguments, the first of "xs:string"
and the second of "xs:string" and returns an
"xs:boolean". Both arguments are valid XPath expressions
defined in XPath 1.0 specification [1]. This function first
extends the first argument to support pseudo hierarchical
access control on XML document structure. If "a" is an
element node and it is specified as the first argument, the
function replace it with "a | a//* | a//@*" meaning that all
the element and attributes below the specified element
"a". If "a" is an attribute node, then the function does not
modify the first argument. Then this function internally
calls xpath-equal function and return the identical return
value.
For example, the following expression shall return true when
"urn:...:xpath" attribute returns a md:patient element that
is below a md:record element:
<Apply FunctionId="function:xpath-match">
<AttributeValue>//md:record</AttributeValue>
<Apply FunctionId="function:string-one-and-only>
<ResourceAttributeDesignator AttributeId="urn:...:xpath"/>
</Apply>
</Apply>
The above function is internally replaced by:
<Apply FunctionId="function:xpath-equal">
<AttributeValue>//md:record | //md:record//* |
//md:record//@*</AttributeValue>
<Apply FunctionId="function:string-one-and-only>
<ResourceAttributeDesignator AttributeId="urn:...:xpath"/>
</Apply>
</Apply>
[C] Modified policy examples:
(Besides this proposal, I removed DataType attribute and
inserted string-one-and-only function in several places)
(See attached file: XACML-SimplePolicy.txt)(See attached file:
XACML-Rule2.txt)(See attached file: XACML-Rule3.txt)(See attached file:
XACML-rule4.txt)(See attached file: XACML-Rule1.txt)
[1] XPath 1.0, http://www.w3.org/TR/xpath
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC