[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Initial set of Change Requests
These are the change requests I culled from recent mailings.
Please review to be sure I have captured all your change requests
accurately.
To make future tracking of changes easier, I propose the
following procedure:
a. All future mailings that request a change MUST have [CR]
in the subject line. The remainder of the subject should
include enough keywords about the change to identify it.
For example, Change Request 0001 below would have been
submitted with a subject line of:
[CR] Add AttributeValue element to support sequence-of values
b. Separate change requests MUST be submitted in separate
mailings.
c. Responses to change requests MUST keep the same subject line
(module Re: [xacml]) so that discussion can be tracked.
d. Change requests MUST begin with the exact text proposed. This
allows a specific change to be voted on.
e. Change requests SHOULD continue with a Rationale explaining
why the change is needed.
f. Try to be succinct.
Anne
Title: Change Requests
Version: 1.1, 02/08/22 (yy/mm/dd)
0001. [Daniel] Add AttributeValue element to support sequence-of values
http://lists.oasis-open.org/archives/xacml/200208/msg00047.html
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>
0002. [Anne] Add mandatory action-id attribute
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
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
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
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
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
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
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:
M indicates mandatory-to-implement.
Function identifier
===========================
M function:integer-add
M function:decimal-add
function:add-yearMonthDuration-to-date
function:add-yearMonthDuration-to-date
function:add-dayTimeDuration-to-time
function:add-yearMonthDuration-to dateTime
function:add-dayTimeDuration-to-dateTime
function:add-yearMonthDurations
function:add-dayTimeDurations
M function:integer-subtract
M function:decimal-subtract
function:date-subtract
function:subtract-yearMonthDuration-from-date
function:subtract-dayTimeDuration-from-date
function:time-subtract
function:subtract-dayTimeDuration-from-time
function:datetime-subtract
function:subtract-yearMonthDuration-from-dateTime
function:subtract-dayTimeDuration-from-dateTime
function:subtract-yearMonthDurations
function:subtract-dayTimeDurations
M function:integer-multiply
M function:decimal-multiply
function:multiply-yearMonthDurations
function:multiply-dayTimeDurations
M function:integer-divide
M function:decimal-divide
function:divide-yearMonthDurations
function:divide-dayTimeDurations
M function:integer-mod
M function:decimal-mod
M function:round
M function:floor
M function:abs
M function:integer
M function:decimal
M function:integer-equal
M function:decimal-equal
M function:boolean-equal
M function:string-equal
M function:rfc822Name-equal
M function:x500Name-equal
M function:date-equal
M function:time-equal
M function:datetime-equal
function:yearMonthDuration-equal
function:dayTimeDuration-equal
M function:gregorian-equal
M function:hex-binary-equal
M function:base64-binary-equal
M function:anyURI-equal
M function:QName-equal
M function:NOTATION-equal
function:numeric-not-equal
function:boolean-not-equal
function:string-not-equal
function:date-not-equal
function:time-not-equal
function:datetime-not-equal
function:yearMonthDuration-not-equal
function:dayTimeDuration-not-equal
function:gregorian-not-equal
function:hex-binary-not-equal
function:base64-binary-not-equal
function:anyURI-not-equal
function:QName-not-equal
function:NOTATION-not-equal
M function:integer-greater-than
M function:decimal-greater-than
M function:string-greater-than
M function:date-greater-than
M function:time-greater-than
M function:datetime-greater-than
function:yearMonthDuration-greater-than
function:dayTimeDuration-greater-than
function:integer-less-than
function:decimal-less-than
function:string-less-than
function:date-less-than
function:time-less-than
function:datetime-less-than
function:yearMonthDuration-less-than
function:dayTimeDuration-less-than
M function:integer-greater-than-or-equal
M function:decimal-greater-than-or-equal
M function:string-greater-than-or-equal
M function:date-greater-than-or-equal
M function:time-greater-than-or-equal
M function:datetime-greater-than-or-equal
function:yearMonthDuration-greater-than-or-equal
function:dayTimeDuration-greater-than-or-equal
function:integer-less-than-or-equal
function:decimal-less-than-or-equal
function:numeric-less-than-or-equal
function:date-less-than-or-equal
function:time-less-than-or-equal
function:datetime-less-than-or-equal
function:yearMonthDuration-less-than-or-equal
function:dayTimeDuration-less-than-or-equal
M function:string-match
M function:rfc822Name-match
M function:x500Name-match
M function:and
M function:ordered-and
M function:or
M function:ordered-or
M function:n-of
M function:not
M function:present
[where X can be any supported data type]
M X-intersection
M X-union
M X-member-of
M X-first
M X-rest
M X-length
0009. [Daniel] Function naming convention
http://lists.oasis-open.org/archives/xacml/200208/msg00071.html
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
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
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
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
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
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
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
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
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.
0018. [Carlisle] C.3 use "First Applicable"
http://lists.oasis-open.org/archives/xacml/200208/msg00099.html
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
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)?
0020. [Michiharu] B.10: Resource Attributes scope value
http://lists.oasis-open.org/archives/xacml/200208/msg00112.html
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'.
0021. [Michiharu] 8.1 Operational Model: PDP description change
http://lists.oasis-open.org/archives/xacml/200208/msg00112.html
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
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/msg00116.html
This change request is a place-holder. I propose that
Daniel and Polar come up with a list of functions,
semantics, and types table that they BOTH agree on. This
will be the Change Request inserted here to be voted on.
CR#8 should be updated based on the final list of functions
to show which are mandatory-to-implement.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC