[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Change Requests list
This list is unfortunately not complete. I did not have time to include all the change requests submitted. -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 Set 3
Author: Anne Anderson
Version: 1.4, 02/10/14 (yy/mm/dd)
Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.ChangeRequests3.txt
This version contains all Change Requests not reflected in
the v0.18c.doc version of the XACML Specification. This file
reflects all unresolved e-mail between archive msg00.html and msg msg00203.html
ACTION ITEMS
============
None
LEGEND
======
NQ=no quorum; official vote required
Q=quorum
SUMMARY
=======
AA01: Remove Table 4 - Attribute Identifiers from A.13.1
STATUS: not yet considered
AA02: New section in Appendix A on Structured datatypes
STATUS: not yet considered
HL01: Typos in 18c
STATUS: editorial
HL02: Policy Indexing
STATUS: not yet considered.
AA03: typo: 2.10.Actions performed in conjunction with enforcement
STATUS: editorial.
PH01: Clarifications changes on 18c
STATUS: not yet considered
PH02: Review of Obligations Section 5.32
STATUS: not yet considered.
PH03: Section 7.5
STATUS: not yet considered.
AA04: 5.1 PolicySetId explanation clarification
STATUS: not yet considered.
AA05: editorial: PolicyCombiningAlgId reference
STATUS: editorial.
AA06: clarify computed <Target>s
STATUS: not yet considered.
DETAILS
=======
AA01: Remove Table 4 - Attribute Identifiers from A.13.1
e-mail sent 11 Oct 2002 09:53:48 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00123.html
STATUS: not yet considered
Text location: Section A.13.1, following x500Name-equal function
description (p.191, line 3527 in my copy of 18c :-)
Text change: Remove "Table 4 - Attribute identifiers"
Rationale: This table is no longer part of the normalization step
for x500Name types and is no longer referenced. The description
of normalization now simply refers to IETF RFC2253.
AA02: New section in Appendix A on Structured datatypes
e-mail sent 11 Oct 2002 10:27:09 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00124.html
STATUS: not yet considered
Text location: Section A, following "A.2 Primitive
types" (p. 86, between lines 3345 and 3346 in my copy of 18c :-)
Text change: Add following new section
A.3 Structured types
An XACML <AttributeValue> MAY contain an instance of a structured
xml data type, for example <ds:KeyInfo>. XACML 1.0 supports
three ways of comparing such <AttributeValue>s.
1) In some cases, such an <AttributeValue> may be compared
using one of the XACML string functions, such as
regexp-string-match, described below. This requires the
structured data, including its tags and attributes, to be
treated as an <xs:string>. In general, this method will not
be adequate unless the structured data type is quite simple.
2) An <AttributeSelector> element may be used to select the value
of a leaf sub-element of the structured data type. That value
may then be compared using one of the supported XACML
functions appropriate for its primitive data type.
3) An <AttributeSelector> element may be used to select the value
of any node in the structured type. This node may then be
compared using one of the XPath-based functions described
below.
Methods 2) and 3) require support for optional XACML features
(XPath expressions and XPath functions) by the PDP.
A fourth alternative is for a community of XACML users to define
separate attribute identifiers for each leaf sub-element of a
given structured data type. Using these identifiers, the Context
Handlers used by that community of users can flatten instances of
the structured data type into a sequence of <Attribute>s. Each
such <Attribute> will have an <AttributeValue> that is and
instance of one of the XACML-supported primitive Datatypes, and
thus can be compared using the XACML-supported functions.
Rationale: this change was proposed in "[xacml] Proposed text for
new section in Appendix A on Structureddatatypes", 03 Oct 2002
14:16:09 -0400(EDT),
http://lists.oasis-open.org/archives/xacml/200210/msg00017.html
On 11 October, Daniel Engovatov writes: RE: [xacml] AA02: New section in Appendix A on Structured datatypes
> How can <AttributeValue dataType="ds:KeyInfo"> with required attribute used
> as an xs:string? Is not it a type error? Would be the syntax for such
> <apply>?
Declare the DataType as xs:string, not ds:KeyInfo. This is not
very workable, since there must be an EXACT string equality, or
else a very complex regular expression, used in the Policy. But,
as I said, in some cases this might work.
Example:
Request:
<Subject>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:key-info"
DataType="xs:string">
<AttributeValue><ds:KeyName>jhibbert-key</ds:KeyName></AttributeValue>
</Attribute>
</Subject>
Policy:
<Target>
<Subjects>
<Subject>
<SubjectMatch
MatchId="function:string-match">
<SubjectAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:key-info"
DataType="xs:string"/>
<AttributeValue
DataType="xs:string"><ds:KeyName>jhibbert-key</ds:KeyName></AttributeValue>
</SubjectMatch>
</Subject>
</Subjects>
....
HL01: Typos in 18c
e-mail sent 11 Oct 2002 11:17:52 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00125.html
STATUS: editorial
Line 309 Non-mormative --> Non-normative
Line 2474 Distingwished --> Distinguished
HL02: Policy Indexing
e-mail sent 11 Oct 2002 12:10:39 -0400
STATUS: not yet considered.
Section 2.8 describes two policy indexing strategies. This
seems like a reasonable discussion to motivate the use of
target, but I have a couple of concerns.
1. My most important concern is that it states that "only one
policy statement applies". This is contrary to my understanding
(or what are combining algorithms for?) and it appears to
contradict section 2.2 specifically.
2. I really don't see that strong a distinction between the two
cases and I suspect that they are not the only possibilities
either. It seems to me that the general case is basically that
you have a bunch of policies stored someplace and you need to
find the ones (hopefully using some efficient technique) who's
Targets match the corresponding fields in the Request
Context. Period.
Am I missing some subtleties here? If there is general
agreement, I would be willing to draft some text, but I don't
want to do so until there is consensus.
[Tim] Hal - I have no objection to your redrafting that
section. Remember, though, that separate policies applicable
to the same request do not identify an algorithm for combining
them, unless they are encapsulated in a policy set containing
an identifier for a combining algorithm. That policy set
becomes the single policy applicable to the request. I am open
to the idea that the current explanation may be confusing.
But, by my understanding, we cannot present a PDP with multiple
policies for a request, because it won't know how to combine
them.
[Polar] I agree. I drafted a One-applicable-policy combining
algorithm to handle this case. In conjunction, in Section 7.1,
it states that a PDP shall represent One Policy or Policy Set.
That should take care of it.
However, the next sentence in 7.1. may be worrysome, which says
"Should the PDP be dynamic in nature in retrivin policies based
on the request, the PDP ShALL act as if it represents a single
policy set with the "Only One APplicable Policy" policy
combining algorithm."
So, what I think this is saying is that if you do not explicity
configure your PDP with a single Policy or Policy Set, it
specifies a default behavior of finding the "only" policy that
should apply.
I think we should really get rid of the text that stipulates
that only one policy applies in Section 2.8, and leave it to
the 7.1 section.
AA03: typo: 2.10.Actions performed in conjunction with enforcement
e-mail sent 11 Oct 2002 12:37:06 -0400 (EDT)
STATUS: editorial.
Text location: Section 2.10, 4th line down (p. 15, line 510 in my
copy of 18c :-)
Text change: replace
evalution in the <Obligations> element. which idea was described
^^^^^
with
evaluation in the <Obligations> element. This idea was described
PH01: Clarifications changes on 18c
e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
I've just attached a copy of 18c with some editorial changes. I've put
the change bars on so you can see what they are, and Simon or Tim can
merge them into their version of the document.
I've changed only a few things that are manly clarifications based on our
agreements on Thursday. I think I address to Hal's concerns about the
policy indexing and the attribute things, as well as some other concerns
about attributes and datatypes.
Currently I see change bars in:
Section 2 header (non-morative)
Section 2.3 Added Only-one-applicable combining algorithm and description
Section 2.8 Policy indexing clarifications
Section 5.22 Function clarification with cross references
Section 5.29 Attribute Selector clarifications
Section 5.32 Obligation clarifications
Section 7.1 Initial Policy clarification
Section 7.4.2 Added Attribute Section
Section 7.5 Authorization Decision about listing datatypes with missing
attribute ids.
PH02: Review of Obligations Section 5.32
e-mail sent 11 Oct 2002 14:05:37 -0400 (EDT)
STATUS: not yet considered.
I think we should take out the "semantic" definitions on the fulfillment
of Section 5.32 Obligations in this element definition. (i.e. in this
section).
Text change: change the sentence "The FulfillOn attribute SHALL indicated the
decision value for which this obligation MUST be fulfilled." to
The FulfillOn attribute SHALL indicated the effect for which
this obligation applies.
FulfillOn [required]
The effect for which this obligation applies.
Rationale: The fulfillment of obligations is taken care of in
the Chapter 7.
PH03: Section 7.5
e-mail sent 11 Oct 2002 14:12:05 -0400 (EDT)
STATUS: not yet considered.
The second to last paragraph in Section 7.5 says "If a decision value of
"NotApplicable" is returned, it means that the PDP's policy is not
applicable to the request, implying that the PEP should send its request
to another PDP.
I think we should get rid of "implying that the PEP should send its
request to another PDP" which contradicts the later sections.
AA04: 5.1 PolicySetId explanation clarification
e-mail sent 11 Oct 2002 15:56:51 -0400 (EDT)
STATUS: not yet considered.
Text location: Section 5.1 (PolicySet), explanation of
PolicySetId (p. 44, lines 1845-1848 in my copy of 18c)
Text change: Change "The party assigning the identifier MUST
minimize the potential of some other party reusing the same
identifier." to "The party assigning the identifier MUST
minimize the potential of some other party re-using the same
identifier within the scope of the PDPs that may use or reference
that identifier."
Rationale: "How unique does it have to be, Anne?" "As unique as
necessary, Joe."
[Tim] Anne - I was definitely uncomfortable with the original
wording. But, even your improvement leaves unnecessary room
for misunderstanding. Why not clearly state that it is the
PAP's responsibility to ensure that no two policies visible to
a PDP have the same identifier? So, instead of "minimize the
potential", why not say "eliminate the possibility"?
In practice, PDPs SHALL only accept policies from PAPs that
agree to conform to a disjoint identifier assignment scheme and
PAPs MUST adhere to their declared scheme. Yes/No?
[Anne] This is fine with me.
AA05: editorial: PolicyCombiningAlgId reference
e-mail sent 11 Oct 2002 16:01:00 -0400 (EDT)
STATUS: editorial.
Text location: Section 5.1 (PolicySet), explanation of
PolicyCombiningAlgId (p. 44, lines 1852-1853 in my copy of 18c).
Text change: Change "Standard policy-combining algorithm
identifiers are listed in Section Combining Algorithms." to
"Standard policy-combining algorithm identifiers are listed in
Appendix B.10 Combining Algorithms."
Rationale: word processor mis-reference.
AA06: clarify computed <Target>s
e-mail sent 11 Oct 2002 16:36:51 -0400 (EDT)
Text locations:
1) Section 5.1 (PolicySet), explanation of <Target>
element (p. 44, lines 1661-1863 in my copy of 18c).
2) Section 5.17 (Policy), explanation of <Target> element (p. 52,
lines 2170-2172).
Text change: In both locations above, replace
"The <Target> element MAY be declared by the creator of the
[<PolicySet>|<Policy>] or it MAY be computed from the <Target>
elements of the referenced [<PolicySet> and <Policy>|<Rule>]
elements, either as an intersection or as a union."
with
"See Section 5.5 Target for more information about the <Target>
element."
---------------------
Text location: In Section 5.5 Element <Target>, just before the
schema fragment (p. 46, after line 1908 in 18c).
Text change: Add
"See Section 7.4 Target construction for more information about
how a <Target> element may be constructed."
---------------------
Text location: following Section "7.3 Policy evaluation".
Text change: Add new section as follows:
7.4 Target construction
An XACML <PolicySet>, <Policy>, or <Rule> has a <Target>
element that specifies the set of Subjects, Resources, and
Actions to which the <PolicySet>, <Policy>, or <Rule> applies.
The <Target> of a <PolicySet> or <Policy> may be declared by
the creator of the <PolicySet> or <Policy>, or may be
constructed prior to evaluation of the <PolicySet> or <Policy>
from the <Target> elements of the referenced <PolicySet>s,
<Policy>s, and <Rule>s.
The component that might construct a <Target> dynamically is
outside the scope of XACML, but there are two logical methods
that might be utilized. In one method, the <Target> of the
outer <PolicySet> or <Policy> (the "outer component") is
constructed as the union of all the <Target>s of the referenced
<PolicySet>s, <Policy>s, or <Rule>s (the "inner components").
In another method, the <Target> of the outer component is
constructed as the intersection of all the <Target>s of the
inner components. The results of evaluation will be very
different depending on which method is chosen: in the first
case, the <Target> of the outer component makes it applicable
to any Request that matches the <Target> of at least one inner
component; in the second case, the <Target> of the outer
component makes it applicable only to Requests that match the
<Target> of every inner component. Note that computing the
intersection of a set of <Target>s is not necessarily easy. It
is also not possible to compute a perfect intersection in every
case.
In cases where the <Target> of a <Policy> is specified by the
<Policy> creator, any component <Rule>s in the <Policy> that
have the same <Target> may omit the <Target> element. Such
<Rule>s inherit the <Target> of the <Policy> in which they are
contained.
Rationale: How it is constructed should be completely transparent
to the XACML policy evaluator, but how it is constructed will
affect the results of the policy.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC