[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Change Request status from 17 Oct TC meeting
The attached Change Requests list shows the status of all Change Requests not reflected in specification version 0.18c as of the close of our TC meeting on 17 Oct 2002. I will issue an updated list of the remaining open, non-editorial issues separately. Please review all the CRs marked "No vote required", as these were accepted without discussion. If you want to object to one, you are free to do so, but don't wait until the last minute! 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.13, 02/10/17 (yy/mm/dd)
Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.ChangeRequests3.txt
This file contains all Change Requests not reflected in the
v0.18c.doc version of the XACML Specification. The STATUS
reflects the status following the 17 Oct TC conference call.
On 10/17 we agreed to accept all "editorial" or "typo" changes,
although TC members are welcome to object to any specific one
prior to the final draft preparation.
LEGEND
======
NQ=no quorum; official vote required
Q=quorum
SUMMARY
=======
0075: [Anne] AA01: Remove Table 4 - Attribute Identifiers from A.13.1
STATUS: APPROVED (10/17 Q).
0076: [Anne] AA02: New section in Appendix A on Structured datatypes
STATUS: Revised text sent to list 17 Oct 2002.
0077: [Hal] HL01: Typos in 18c
STATUS: Editorial. Vote not required.
0078: [Hal] HL02: Policy Indexing
STATUS: APPROVED (10/17 Q).
0079: [Anne] AA03: typo: 2.10.Actions performed in conjunction with enforcement
STATUS: Editorial. Vote not required.
0080: [Polar] PH01: Clarifications changes on 18c
STATUS: CLOSED. Broken out into PH04-PH10, plus additions to HL02.
0081: [Polar] PH02: Review of Obligations Section 5.32
STATUS: APPROVED (10/17 Q)
0082: [Polar] PH03: Section 7.5 Authorization decision
STATUS: APPROVED (10/17 Q)
0083: [Anne] AA04: 5.1 PolicySetId explanation clarification
STATUS: APPROVED (10/17 Q).
0084: [Anne] AA05: editorial: PolicyCombiningAlgId reference
STATUS: Editorial. Vote not required.
0085: [Anne] AA06: clarify computed <Target>s
STATUS: PROVISIONALLY APPROVED (10/17 Q) with different location: 3.3.2.1 Policy target
0086: [Hal] HL03: Question about Anonymous Access Subject
STATUS: REJECTED (10/17 Q). Submit specific proposals if changes needed.
0087: [Polar] PH04: 2.3 Combining algorithms, add "Only-one-applicable-policy"
STATUS: APPROVED (10/17 Q).
0088: [Polar] PH05: 5.22 Element <Function>: clarify description
STATUS: APPROVED (10/17 Q).
0089: [Polar] PH06: 5.23 AttributeDesignator selects collection, not set
STATUS: APPROVED (10/17 Q), but using "bag" rather than "collection".
0090: [Polar] PH07: 5.29 Clarify <AttributeSelector>
STATUS: APPROVED (10/17 Q), with "which is" and "XPath" changes.
0091: [Polar] PH08: 5.32 Clarify <Obligation>
STATUS: APPROVED (10/17 Q).
0092: [Polar] PH09: New section 7.4.2 Attributes
STATUS: APPROVED 7.4.2, 7.4.2.1 (10/17 Q) adding "or selector". 7.4.2.2 revised and OPEN.
0093: [Polar] PH10: 7.5 Clarify Authorization decision
STATUS: APPROVED (10/17 Q).
0094: [Anne] AA07: point to 7.x Obligations from other places
STATUS: APPROVED (10/17 Q).
0095: [Anne] AA08: specify default XPathVersion
STATUS: APPROVED AS MODIFIED (10/17 Q): ELEMENT MUST BE PRESENT.
0096: [Anne] AA09: editorial: remove 10.3.1 XPathNamespace
STATUS: Editorial. Vote not required.
0097: [Anne] AA10: editorial: Add reference [IBMSDA] to references
STATUS: Editorial. Vote not required.
0098: [Anne] AA11: Clarify "MatchId" functions
STATUS: DISCUSSED 10/17. STILL OPEN.
0099: [Anne] AA12: editorial: move B.5 Environment attributes after B.8Action attributes
STATUS: Editorial. Vote not required.
0100: [Steve Hanna] SteveHanna01: integer-mod takes two arguments
STATUS: Not yet considered.
0101: [Satoshi Hada] SatoshiHada01: How many namespaces does XACML define?
STATUS: not yet considered.
0102: [Anne] AA13: Remove B.11 Identifiers used in conformance tests
STATUS: not yet considered.
0103: [Anne] AA14: amended: editorial: get Piras' name right
STATUS: Editorial. Vote not required. Revised to add additional location.
0104: [Anne] AA15: editorial: glossary Policy and PolicySet "componet" to "component"
STATUS: Editorial. Vote not required. AA16 merged in.
0105: [Anne] AA16: editorial: Glossary Policy set "componet" to "component"
STATUS: CLOSED (replaced by revised AA15)
0106: [Anne] AA17: editorial: use "Requester", not "Requestor"
STATUS: Editorial. Modified based on comments.
0107: [Anne] AA18: editorial: change "implementor" to "implementer"
STATUS: Editorial. Revised based on comments.
0108: [Anne] AA19: editorial: "interdeterminate" to "indeterminate"
STATUS: Editorial. Vote not required.
0109: [Anne] AA20: editorial: replace "First-Appplicable" with"First-Applicable"
STATUS: Editorial. Vote not required.
0110: [Anne] AA21: editorial: change "URI os the" to "URI of the"
STATUS: Editorial. Vote not required.
0111: [Anne] AA22: editorial: fix reference to RFC 2821 in B.4
STATUS: Editorial. Vote not required.
0112: [Anne] AA23: editorial: change "the URLfrom which" to"the URL from which"
STATUS: Editorial. Vote not required.
0113: [Anne] AA24: Add references for Haskel
STATUS: Editorial. Vote not required.
0114: [Anne] AA25: editorial: A.3 add reference to [IBMSDA]"
STATUS: Editorial. Vote not required.
0115: [Anne] AA26: typo: 10.3.3 "alorithm" to "algorithm"
STATUS: Editorial. Vote not required.
0116: [Anne] AA27: typo: Sun Microsystems, not Sun Micrososytems
STATUS: Editorial. Vote not required.
0117: [Anne] AA28: typo: change "adverary" to "adversary"
STATUS: Editorial. Vote not required.
0118: [Anne] AA29: typo: 7.4.1 Hierarchial resources to Hierarchicalresources
STATUS: Editorial. Vote not required.
0119: [Anne] AA30: typo: 6.11 replace "retrieveing" with "retrieving"
STATUS: Editorial. Vote not required.
0120: [Anne] AA31: typo: 6.11 replace "network errrors" with"network errors"
STATUS: Editorial. Vote not required.
0121: [Anne] AA32: clarify use of "dn"
STATUS: not yet considered.
0122: [Anne] AA33: typo: xs:complType to xs:complexType
STATUS: Editorial. Vote not required.
0123: [Anne] AA34: editorial: B.3 XACML functions see Appendix A
STATUS: Editorial. Vote not required. [was 2nd AA11]
0124: [Anne] AA35: typo: 6.2 "ulitmately" to "ultimately"
STATUS: Editorial. Vote not required.
0125: [Anne] AA36: typo: 6.1 replace "contextby" with "context by"
STATUS: Editorial. Vote not required.
0126: [Anne] AA37: typo: 6.1 "<Subject> elements.Each" to"<Subject> elements. Each"
STATUS: Editorial. Vote not required.
0127: [Anne] AA38: typo: 5.28 "<xacml-contex:" to "<xacml-context:"
STATUS: Editorial. Vote not required.
0128: [Anne] AA39: typo: 5.7 "context.and" to "context and"
STATUS: Editorial. Vote not required.
0129: [Anne] AA40: typo: 5.5 "conjuctive" to "conjunctive"
STATUS: Editorial. Vote not required.
0130: [Anne] AA41: typo: "PolicyIdReferece" to "PolicyIdReference"
STATUS: Editorial. Vote not required.
0131: [Anne] AA42: typo: change "explicitely" to "explicitly"
STATUS: Editorial. Vote not required.
0132: [Anne] AA43: use "xs:" or "xsi:"?
STATUS: not yet considered.
0133: [Anne] AA44: 6.10 change "resource-uri" to "resource-id"
STATUS: Editorial. Vote not required.
0134: [Seth Proctor] SP01: 18c comments. Forwarded message from Seth Proctor.
STATUS: Not yet considered.
0135: [Anne] AA45: make data-flow diagram consistent with 7.7 Use profile for XACML request
STATUS: not yet considered.
0136: [Anne] AA46: Make 3.2 XACML context consistent with 7.7 Use profile for XACML request
STATUS: not yet considered.
0137: [Steve Hanna] SteveHanna02: xs:decimal string representation
STATUS: not yet considered.
0138: [Steve Hanna] SteveHanna03: Use of decimal math should be justified
STATUS: not yet considered.
0139: [Steve Hanna] SteveHanna04: handling of divide-by-zero
STATUS: not yet considered.
0140: [Michiharu] MK01: DataType and Namespace
STATUS: not yet considered.
DETAILS
=======
0075: [Anne] 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: APPROVED (10/17 Q).
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"
DISCUSSION: 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.
0076: [Anne] 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
http://lists.oasis-open.org/archives/xacml/200210/msg00209.html (revised)
STATUS: Revised text sent to list 17 Oct 2002.
TEXT LOCATION: Section A, following "A.2 Primitive
types" (p. 86, between lines 3345 and 3346 in my copy of 0.18c)
REVISED TEXT CHANGE: Add following new section as follows:
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 several ways for 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
identified and treated as an instance of DataType
<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. This
method requires support by the PDP for the optional XPath
expressions feature.
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
in "Section A.13.13 XPath-based functions". This method
requires support by the PDP for the optional XPath
expressions and XPath functions features.
4) For a given structured data type, a community of XACML
users MAY define new attribute identifiers for each leaf
sub-element of the structured data type that has a type
conformant with one of the XACML-defined primitive
datatypes. Using these new attribute identifiers, the
PEPs or context handlers used by that community of users
can flatten instances of the structured data type into a
sequence of individual <Attribute>s. Each such
<Attribute> can be compared using the XACML-defined
functions. Using this method, the structured data type
itself never appears in an <AttributeValue> element.
5) A community of XACML users MAY define a new function that
can be used to compare a value of the structured datatype
against some other value. This method may only be used by
PDPs that support the new function.
DISCUSSION: this change was originally 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,
but was never discussed.
On 11 October, Daniel Engovatov writes:
> 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>
....
0077: [Hal] 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. Vote not required.
Section 2. Background (Non-mormative), line 309:
Non-mormative --> Non-normative
Section 6.2 Element <Subject>, line 2474
Distingwished --> Distinguished
0078: [Hal] HL02: Policy Indexing
e-mail sent 11 Oct 2002 12:10:39 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00128.html
STATUS: APPROVED (10/17 Q).
SEE ALSO: AA06, SP01a
TEXT LOCATION: Section 2.8 Policy indexing, p. 14, lines
471-545
TEXT CHANGE: [modified with Polar's text] replace existing
numbered paragraphs and the paragraph starting with "In either
case" with following
1. Policy statements may be stored in a database, whose
data-model is congruent with that of the <Target> element.
The PDP should use the contents of the decision request that
it is processing to form the database read command by which
applicable policy statements areretrieved. Nevertheless,
the PDP should still evaluate the <Target> element of the
retrieved policy or policy set statements as defined by the
XACML specification.
2. Alternatively, the PDP may evaluate the <Target> element
from each of the policies or policy sets that it has
available to it, in the context of a particular decision
request, in order to identify the policies and policy sets
that is applicable to that request.
TEXT LOCATION: Section 7.1 "Initial policy", p. 68, lines
2825-2827
TEXT CHANGE: [modified with Polar's text] replace 'A PDP SHALL
represent one Policy, or Policy Set. Should the PDP be dynamic
in nature in retrieving policies based on the request, the PDP
SHALL act as if represents a single Policy Set with the "Only
One Applicable Policy" policy combining algorithm.' with
'A PDP SHALL represent one Policy, or Policy Set. Should the
PDP be dynamic in nature in retrieving policies based on the
request with no explicit policy combining algorithm, the PDP
SHALL act as if it represents a single Policy Set with the
"Only One Applicable Policy" policy combining algorithm.'
DISCUSSION: 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.
0079: [Anne] AA03: typo: 2.10.Actions performed in conjunction with enforcement
e-mail sent 11 Oct 2002 12:37:06 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00129.html
STATUS: Editorial. Vote not required.
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
0080: [Polar] PH01: Clarifications changes on 18c
e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00141.html
STATUS: CLOSED. Broken out into PH04-PH10, plus additions to HL02.
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.
0081: [Polar] PH02: Review of Obligations Section 5.32
e-mail sent 11 Oct 2002 14:05:37 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00134.html
STATUS: APPROVED (10/17 Q)
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 indicate the effect for which
this obligation applies."
FulfillOn [required]
The effect for which this obligation applies.
DISCUSSION: The fulfillment of obligations is taken care of in
the Chapter 7.
0082: [Polar] PH03: Section 7.5 Authorization decision
e-mail sent 11 Oct 2002 14:12:05 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00135.html
STATUS: APPROVED (10/17 Q)
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.
[Bill]that would seem to be consistent with our singular
treatment of PDPs in section 7.
[10/17 concall] Section 7.5 tells how the PDP arrives at its
Authorization Decision, not what the PEP is supposed to do with
it. We don't prohibit a PEP from sending its request to
another PDP, but we don't "imply" or mandate it either. This
spec merely defines the interaction between a PEP and one PDP.
0083: [Anne] AA04: 5.1 PolicySetId explanation clarification
e-mail sent 11 Oct 2002 15:56:51 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00138.html
STATUS: APPROVED (10/17 Q).
TEXT LOCATION: Section 5.1 (PolicySet), explanation of
PolicySetId (p. 44, lines 1845-1848 in my copy of 18c)
TEXT CHANGE: [modified according to Tim's comment] Change "The
party assigning the identifier MUST minimize the potential of
some other party reusing the same identifier." to
"It is the responsibility of the PAP to ensure that no two
policies visible to a PDP have the same identifier."
0084: [Anne] AA05: editorial: PolicyCombiningAlgId reference
e-mail sent 11 Oct 2002 16:01:00 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00139.html
STATUS: Editorial. Vote not required.
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."
0085: [Anne] AA06: clarify computed <Target>s
e-mail sent 11 Oct 2002 16:36:51 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00142.html
STATUS: PROVISIONALLY APPROVED (10/17 Q) with different location: 3.3.2.1 Policy target
SEE ALSO: HL02, SP01a
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 3.3.2.1 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 3.3.2.1 Target for more information about
how a <Target> element may be constructed."
---------------------
TEXT LOCATION: Section "3.3.2.1 Target".
TEXT CHANGE: Tim to merge following text with what is already
in 3.3.2.1.
3.3.2.1 Target
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.
DISCUSSION: 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.
[10/17 concall] This belongs in a non-normative section:
3.3.2.1 Target. We "provisionally" approved it, trusting Tim
to merge the proposed text with the existing text in 3.3.2.1.
Objections may be raised, however, if the merge is not correct.
0086: [Hal] HL03: Question about Anonymous Access Subject
e-mail sent 11 Oct 2002 11:56:37 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00126.html
STATUS: REJECTED (10/17 Q). Submit specific proposals if changes needed.
Is there a cannonical way to represent an anonymous access
subject in the Request Context? This seems to me to be an
extremely common case that should be described in the spec. (My
preference would be to leave out the access subject entirely,
but I see that it is mandatory)
[Anne] Yes, there is a canonical way. The sequence of
Attributes under <Subject> is minOccurs=0, so you can have a
Request Context in which the one <Subject> element has no
Attributes (such as no subject-id).
[Polar] A question that we are wrestling with in our logical
analysis of the security protocols, namely CSIv2, is whether
not having a prncipal is really an anonymous principal.
I think we are finding that there is a "default" principal, of
which you associated a principal with by either configuration
(let's say a request that comes over a VPN).
Also, you can assert an anonymous principal, which actually
states that you really do not know who it is. This principal is
supremely weaker than all other principals.
We might come up with a particular identifier saying
"Anonymous", but should make sure it isn't used for the
"default" case, unless the default case is truly anonymous.
In constrast to the default case, we could have a "default"
principal id, or, we direct the PEP to "fill" the principal in
with the default principal's id.
[Daniel] ..And to write rules on anonymous subject I presume
one has to use <anysubject> for target? Right? Does missed
subject have applicable rules written on <anysubject> ?
[Bill] that was my understanding.
[10/17 concall] Current document does not contain any
references to "anonymous".
If someone thinks we need explicit text on how to deal with
"anonymous" subjects, or if someone thinks we need an explicit
identifier for an "anonymous" subject, then that person needs
to submit a new change request with a use case, specific
locations to change, and specific text to use.
We may want to submit to SAML some specific values for the
"authn-method" attribute, such as: "intentionally anonymous",
"not authenticated", "authenticated by say so", "unknown", etc.
"No subject attributes" is not equivalent to "anonymous".
We agreed that it is permissible to omit all <Attribute>s from
the <Subject> and it is possible to refer to such a <Subject>
by using <AnySubject>. Neither of these requires any changes
to the existing text or schemas.
0087: [Polar] PH04: 2.3 Combining algorithms, add "Only-one-applicable-policy"
e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00141.html
STATUS: APPROVED (10/17 Q).
TEXT LOCATION: Section 2.3 Combining algorithms, p. 12, lines
382-383
TEXT CHANGE: Replace
o Permit-overrides and
o First applicable
with
o Permit-overrides,
o First-applicable and
o Only-one-applicable-policy
TEXT LOCATION: p. 12, line 390, at end of paragraph starting
"In the first case"
TEXT CHANGE: Add
The "Only-one-applicable-policy" combining algorithm only
applies to polcies. The result of this combining algorithm
ensures that only one policy or policy set applies by virtue of
their targets. If no policy or policy set applies, the result
is "NotApplicable", but if more than one policy or policy set
applies, then the result is "Indeterminate". When exactly one
policy or policy set applies, the result of the combining
algorithm is the result of evaluating the applicable policy or
policy set.
0088: [Polar] PH05: 5.22 Element <Function>: clarify description
e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00141.html
STATUS: APPROVED (10/17 Q).
TEXT LOCATION: Section 5.22 Element <Function>, p. 55, lines
2276-2286
TEXT CHANGE: replace "The Function element SHALL be used to
name a function that is applied by the bag functions to every
element of a bag." with
"The Function element SHALL be used to name a function that is
applied by the higher order bag functions to every element of a
bag. The higher order bag functions are described in Appendix
A.13.11 Higher-order bag functions."
TEXT CHANGE: replace description of "FunctionId [Required]":
"The identifier for the function that is applied to the
elements of a bag." with
"The identifier for the function that is applied to the
elements of a bag by the higher order bag functions."
0089: [Polar] PH06: 5.23 AttributeDesignator selects collection, not set
e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00141.html
STATUS: APPROVED (10/17 Q), but using "bag" rather than "collection".
TEXT LOCATION: Section 5.23 Complex type
AttributeDesignatorType, 2nd paragraph, first sentence, p. 55,
line 2292
TEXT CHANGE: [Modified with "bag"] replace "Elements of
AttributeDesignatorType type select a set of attribute values
from the request context." with
"Elements of AttributeDesignatorType type select a bag of
attribute values from the request context."
0090: [Polar] PH07: 5.29 Clarify <AttributeSelector>
e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00141.html
STATUS: APPROVED (10/17 Q), with "which is" and "XPath" changes.
TEXT LOCATION: Section 5.29 Element <AttributeSelector>, first
paragraph, p. 58, lines 2410-2411
TEXT CHANGE: [With "which is" and "XPath changes] Replace "The
AttributeSelector element evaluates to a bag of a single
primitive values that is implied by the type system, i.e. the
function application in which the selector appears." with
"The AttributeSelector element evaluates to a bag of values of
a single primitive type, which is specified by the selector's
DataType. In the case where the XPath expression matches
attributes in the request context by AttributeId, it must also
match the attribute's DataType with the selector's DataType."
0091: [Polar] PH08: 5.32 Clarify <Obligation>
e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00141.html
STATUS: APPROVED (10/17 Q).
TEXT LOCATION: Section 5.32 Element <Obligation>, p. 59, lines
2470-2471
TEXT CHANGE: Replace "The FulfillOn attribute SHALL indicate
the decision value for which this obligation MUST be
fulfilled." with
"The FulfillOn attribute SHALL indicate the effect for which
this obligation applies."
TEXT LOCATION: Section 5.32 Element <Obligation>, p. 59,
description of "FulfillOn [required]" attribute, line 2487.
TEXT CHANGE: Replace "The decision value for which this
obligation MUST be fulfilled." with
"The effect for which this obligation applies."
0092: [Polar] PH09: New section 7.4.2 Attributes
e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00141.html
STATUS: APPROVED 7.4.2, 7.4.2.1 (10/17 Q) adding "or selector". 7.4.2.2 revised and OPEN.
TEXT LOCATION: Following Section 7.4.1 "Hierarchi[c]al
resources", p. 70, after line 2911.
TEXT CHANGE: [modified with "or selector(s)" and with Polar's
revised "7.4.2.2 Missing attributes" text] Add following new
sections:
7.4.2 Attributes
Attributes are specified in the request context and are
referred to in the policy by the subject, resource, action, and
environment attribute designators or selectors. Each attribute
specifies an AttributeId and a DataType, and each attribute
desigator specifies an AttributeId and DataType. Attribute
Designators and Attribute Selectors SHALL match attributes by
using string equality on both the AttributeId and DataType
values.
7.4.2.1 Attribute Retrieval
The PDP SHALL retrieve the values of attributes that match the
particular attribute designator or attribute selector and form
them into a bag of values with the specified DataType. If no
attributes from the request context match, the attribute shall
be considered missing, and an empty bag is said to be
retrieved.
7.4.2.2 Missing Attributes
The PDP SHALL consider an attribute as missing if it evaluates
an expression that requires at least one value to be present
from an attribute designator or selector. In this case, the
expression evaluates to "indeterminate". The PDP may carry the
missing attribute upward in its indeterminate value in
accordance with the XACML evaluation strategy of the
encompassing expressions, rules, policies, and policy sets. If
the PDP evaluates its policy or policy set to Indeterminate
with a missing attribute, the PDP MAY list the AttributeId and
DataType of that attribute in the result as described in
Section 7.5 "Authorization decision". However, the PDP MAY
choose not to issue such information due to security concerns.
0093: [Polar] PH10: 7.5 Clarify Authorization decision
e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00141.html
STATUS: APPROVED (10/17 Q).
TEXT LOCATION: Section 7.5 Authorization decision, paragraph 2,
following first occurrence of the missing-attribute URN.
TEXT CHANGE: Replace "In this case, the <Status> element MAY
list the names of any attributes of the subject and the
resource that are needed by the PDP to refine its decision."
with
"In this case, the <Status> element MAY list the names and data
types of any attributes of the subject and the resource that
are needed by the PDP to refine its decision."
TEXT LOCATION: Section 7.5 Authorization decision, paragraph 2,
following third occurrence of the missing-attribute URN.
TEXT CHANGE: Replace "it MUST NOT list the names of any
attribute of the subject or the resource of the request for
which values were supplied in the request." with
"it MUST NOT list the names and data types of any attribute of
the subject or the resource of the request for which values
were supplied in the request."
TEXT LOCATION: Section 7.5 Authorization decision, paragraph 3.
TEXT CHANGE: Delete the following paragraph:
'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.'
0094: [Anne] AA07: point to 7.x Obligations from other places
e-mail sent 14 Oct 2002 09:23:19 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00147.html
STATUS: APPROVED (10/17 Q).
TEXT LOCATIONS:
1) 5.1 Element <PolicySet>, description of
<Obligations>[Optional], p. 45, lines 1874-1875.
2) 5.17 Element <Policy>, description of <Obligations>[Optional],
p. 52, lines 2179-2181.
3) 5.32 Element <Obligation>, p. 59, lines 2468-2510
4) 6.10 Element <Result>, description of
<xacml:Obligations>[Optional], p. 66, lines 2742-2745
TEXT CHANGE: In each location, add:
"See Section 7.6 Obligations, for a description of how the set
of Obligations to be returned to the PEP are determined."
0095: [Anne] AA08: specify default XPathVersion
e-mail sent 14 Oct 2002 09:26:08 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00148.html
STATUS: APPROVED AS MODIFIED (10/17 Q): ELEMENT MUST BE PRESENT.
TEXT LOCATION: Section 5.4 Element <XPathVersion>, p. 45, lines
1896-1900
TEXT CHANGE: [With modifications from 10/17 meeting] Append:
"If the policy or policy set uses any XPath expressions, then
the <XPathVersion> element MUST be present."
0096: [Anne] AA09: editorial: remove 10.3.1 XPathNamespace
e-mail sent 14 Oct 2002 09:30:40 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00149.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section 10.3.1 Schema elements, entry for
"Xacml:Policy XPathNamespace O", p. 79, table lines between
3238-3239.
TEXT CHANGE: remove the line identifying the XPathNamespace
schema element from this list.
DISCUSSION: element no longer exists.
0097: [Anne] AA10: editorial: Add reference [IBMSDA] to references
e-mail sent 14 Oct 2002 09:33:46 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00150.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section 11. References
TEXT CHANGE: Add following new reference entry
"[IBMSDA] IBM Standard Decimal Arithmetic. Available at
http://www2.hursley.ibm.com/decimal/decarith.html";;
DISCUSSION: referenced from A.1 Introduction, but not included in
11. References.
0098: [Anne] AA11: Clarify "MatchId" functions
e-mail sent 14 Oct 2002 09:48:04 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00151.html
STATUS: DISCUSSED 10/17. STILL OPEN.
TEXT LOCATION: Section A.11 Matching elements, p. 89, lines
3446-3456.
TEXT CHANGE: [Bag functions omitted per comment from Polar]
Replace following paragraph:
"The match elements: <SubjectMatch>, <ResourceMatch> and
<ActionMatch> SHALL use XACML standard functions to perform
the match evaluation. The function used for determinaing a
match is named in the MatchId attribute of these elements.
Each of these elements contains a <AttributeDesignator> or
<AttributeSelector> element and an explicit attribute value.
The restriction on the function is that the MatchId attribute
must name a binary function, such that its result type is
"xs:boolean". Also, each argument to the named function must
match the appropriate primitive types for the
<AttributeDesignator> or <AttributeSelector> element and the
following explicit attribute value, such that the explicit
attribute value is placed as the first argument to the
function, while an element of the bag returned by the
<AttributeDesignator> or <AttributeSelector> element is placed
as the second argument to the function."
with the following:
"The match elements: <SubjectMatch>, <ResourceMatch> and
<ActionMatch> SHALL use functions that match two arguments,
returning a result type of "xs:boolean", to perform the match
evaluation.The function used for determinaing a match is named
in the MatchId attribute of these elements. Each argument to
the named function must match the appropriate primitive types
for the <AttributeDesignator> or <AttributeSelector> element
and the following explicit attribute value, such that the
explicit attribute value is placed as the first argument to
the function, while an element of the bag returned by the
<AttributeDesignator> or <AttributeSelector> element is placed
as the second argument to the function.
The XACML standard functions that may be used as a MatchId
attribute value are:
function:*-equal
function:*-greater-than
function:*-greater-than-or-equal
function:*-less-than
function:*-less-than-or-equal
function:*-match
DISCUSSION: explanation of which functions may be used as MatchId
functions is not clear. Also, function used need not be a
"standard" function as long as it returns a boolean and its
arguments follow the required format.
[10/17 concall] There appear to be three points of view with
respect to <Target>:
1) <Target>/<Condition> is a way to divide the evaluation into
an "easy" part and a "hard" part, so that many potentially
applicable policies can be easily eliminated without having
to evaluate the "hard" part. The policies may be in a
database, or may be explicitly included or referenced from
another policy set. Target is an aid to indexing, but is
not the complete way policies are indexed. [This view is
reflected in this Change Request]
2) <Target> is designed to help search for the initial
applicable policy in a database based on an incoming
request. Any functions of the specified type (return
boolean, take Designator/Selector and explicit
AttributeValue as two args) that are supported by SQL and
LDAP should be permitted.
3) <Target> is designed for searching an index of potential
policies or rules. Only XACML standard *-equal functions
should be permitted in a "MatchId". There was a
Apparently, there was a vote taken on this earlier that
supported 3), and Daniel was apparently strongly in favor of
this. [Anne: I can not find any record of such a vote in our
Change lists.]
Use cases and more discussion are required to resolve this.
0099: [Anne] AA12: editorial: move B.5 Environment attributes after B.8Action attributes
e-mail sent 14 Oct 2002 09:55:37 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00153.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Appendix B
TEXT CHANGE: Move current "B.5 Environment attributes" section to
follow current "B.8 Action attributes" section.
DISCUSSION: Environment attributes follow all the Subject,
Resource, and Action attributes in the Request Context.
0100: [Steve Hanna] SteveHanna01: integer-mod takes two arguments
personal communication to Anne Anderson on 14 Oct 2002
STATUS: Not yet considered.
TEXT LOCATION: Section A.13.2 Arithmetic functions, p. 92,
4569, list of functions that take a single argument.
TEXT CHANGE: Move "integer-mod" up to the list of functions
that take two arguments.
0101: [Satoshi Hada] SatoshiHada01: How many namespaces does XACML define?
e-mail to xacml-comment 15 Oct 2002 13:51:19 +0900
STATUS: not yet considered.
It is unclear to me how many namespaces XACML tries to define.
Appendix B.1 says that the following two namespace URIs are defined.
urn:oasis:names:tc:xacml:1.0:policy
urn:oasis:names:tc:xacml:1.0:context
However, it seems to me that XACML tries to define at least two other
namespaces.
(1) One is for function identifiers, i.e.,
urn:oasis:names:tc:xacml:1.0:function. Indeed, the type of
the "FunctionID" attribute is xs:QName and so I think this
URN should be one of namespace URIs defined in the XACML
specification.
(2) The other is for data types, i.e.,
urn:oasis:names:tc:xacml:1.0:datatype. Currently, the type
of the "DataType" attribute is xs:anyURI.
I think it should be xs:QName and this URN should be one of
namespace URIs defined in the XACML specification.
0102: [Anne] AA13: Remove B.11 Identifiers used in conformance tests
e-mail sent 14 Oct 2002 09:58:56 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00154.html
STATUS: not yet considered.
TEXT LOCATION: Section B.11, p. 111, lines 4325-4328
TEXT CHANGE: remove entire Section "B.11 Identifiers used only
in XACML conformance tests"
DISCUSSION: just as for identifiers used in examples, I don't
think we need to spell out the identifiers used in conformance
tests.
0103: [Anne] AA14: amended: editorial: get Piras' name right
e-mail sent 14 Oct 2002 11:30:20 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00162.html
STATUS: Editorial. Vote not required. Revised to add additional location.
TEXT LOCATIONS:
1) Title page, Contributors, p. 1, line 24
2) Appendix D. Acknowledgments, p. 119, line 4694
TEXT CHANGE: Replace "Piras Vilandai Thiyatarajan, Sun
Microsystems" with "Pirasenna Velandai Thiyagarajan, Sun
Microsystems"
0104: [Anne] AA15: editorial: glossary Policy and PolicySet "componet" to "component"
e-mail sent 14 Oct 2002 11:07:10 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00157.html
STATUS: Editorial. Vote not required. AA16 merged in.
TEXT LOCATION:
1) Section Glossary "1.1.1 Preferred terms", entry for
"Policy", p. 8, line 242
2) Section Glossary "1.1.1 Preferred terms", entry for "Policy
set", p.9, line 252
TEXT CHANGE: replace "componet" with "component"
0105: [Anne] AA16: editorial: Glossary Policy set "componet" to "component"
e-mail 14 Oct 2002 11:09:04 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00158.html
STATUS: CLOSED (replaced by revised AA15)
0106: [Anne] AA17: editorial: use "Requester", not "Requestor"
e-mail sent 14 Oct 2002 11:19:48 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00159.html
STATUS: Editorial. Modified based on comments.
TEXT LOCATIONS:
1) Section 1.1.2 "Related terms", last sentence in section,
p. 9, line 267.
2) Section 4.2.4 "Rule 2", explanation for [48]-[82], p. 35,
line 1372
3) Section 4.2.4 "Rule 2", explanation for [51]-[65], p. 35,
line 1377
4) Section 4.2.4.5 "Example PolicySet", each bullet item,
pp. 41-42, lines 1723-1726
TEXT CHANGE: change spelling from "Requestor" to "Requester"
DISCUSSION: Some locations in the document already use
"requester". We should be consistent. American Heritage
Dictionary spells it this way. [Bill - Websters allows for
both, but lists "requester" first]
0107: [Anne] AA18: editorial: change "implementor" to "implementer"
e-mail sent 14 Oct 2002 11:26:03 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00160.html
STATUS: Editorial. Revised based on comments.
TEXT LOCATIONS:
1) Section 10. Conformance, 10.1 Introduction, item "1.",
p. 78, line 3221
2) Section 10. Conformance, 10.2 Attestation, p. 78, first
sentence.
3) Appendix F. Notices, first paragraph, last sentence, p. 121,
line 4706
TEXT CHANGE: replace "implementor" with "implementer".
DISCUSSION: Some locations in the document already use
"implementer". We should be consistent. [Bill - Websters
allows for both, but lists "implementer" first]
0108: [Anne] AA19: editorial: "interdeterminate" to "indeterminate"
e-mail sent 14 Oct 2002 11:34:58 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00163.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section C.4 Only-one-applicable policy, 2nd
paragraph, final word, p. 118, line 4638
TEXT CHANGE: replace "interdeterminate" with "indeterminate"
0109: [Anne] AA20: editorial: replace "First-Appplicable" with"First-Applicable"
e-mail sent 14 Oct 2002 11:37:56 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00165.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section C.3 First-applicable, following first
pseudo-code block, p. 117, line 4586
TEXT CHANGE: replace "First-Appplicable" with
"First-Applicable"
0110: [Anne] AA21: editorial: change "URI os the" to "URI of the"
e-mail sent 14 Oct 2002 11:42:41 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00166.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section B.6 Subject attributes, last paragraph,
second line, p. 109, line 4270
TEXT CHANGE: Replace "to the URI os the LDAP specification."
with "to the URI of the LDAP specification."
0111: [Anne] AA22: editorial: fix reference to RFC 2821 in B.4
e-mail sent 14 Oct 2002 11:46:14 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00167.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section B.4 "Data types", paragraph starting "An
rfc822Name...", last word, p. 108, line 4220.
TEXT CHANGE: change 'under the term "Mailbox".Numeric' to 'under
the term "Mailbox".'
0112: [Anne] AA23: editorial: change "the URLfrom which" to"the URL from which"
e-mail sent 14 Oct 2002 11:50:26 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00168.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section B.2 Access subject categories, paragraph
starting "This identifier indicates a system entity associated
wiht a local or remove codebase", second sentence, p. 107, line
4200.
TEXT CHANGE: Change "the URLfrom which" to "the URL from which"
0113: [Anne] AA24: Add references for Haskel
e-mail sent 14 Oct 2002 12:29:06 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00169.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: A.13.11 Higher-order bag functions, p.99, line
3850
TEXT CHANGE: add "[Haskell]" after "functional language called
Haskell"
TEXT LOCATION: Section 11. References, p. 84, line 3270
TEXT CHANGE: add new entry as follows:
[Haskell] "Haskell, A Purely Functional Language",
http://www.haskell.org/
0114: [Anne] AA25: editorial: A.3 add reference to [IBMSDA]"
e-mail sent 14 Oct 2002 12:37:38 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00170.html
STATUS: Editorial. Vote not required.
SEE ALSO: AA10
TEXT LOCATION: Section A.3 Representations
TEXT CHANGE: replace "XACML SHALL use the conversions described
in IBM Standard Decimal Arithmetic document at the following URL:
http://www2.hursley.ibm.com/decimal/decarith.html";; with
"XACML SHALL use the conversions described in IBM Standard
Decimal Arithmetic [IBMSDA]."
DISCUSSION: put the details in one place, the References section.
0115: [Anne] AA26: typo: 10.3.3 "alorithm" to "algorithm"
e-mail sent 14 Oct 2002 12:42:05 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00171.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section 10.3.3 Algorithms, entry for
only-one-applicable-policy, p. 80, table between lines 3243 and
3244
TEXT CHANGE: Replace
"urn:oasis:names:tc:xacml:1.0:policy-combining-alorithm:only-one-applicable-policy"
with
"urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:only-one-applicable-policy"
0116: [Anne] AA27: typo: Sun Microsystems, not Sun Micrososytems
e-mail sent 14 Oct 2002 12:46:11 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00172.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section 10.2 Attestation, p. 78, line 3231
TEXT CHANGE: replace "Sun Micrososytems" with "Sun Microsystems"
DISCUSSION: might make people think of a certain competitor.
0117: [Anne] AA28: typo: change "adverary" to "adversary"
e-mail sent 14 Oct 2002 12:48:43 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00173.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: 9.2.3.1 "Communication confidentiality", first
paragraph, 4th line, p. 78, line 3140
TEXT CHANGE: change "for an adverary to know" to "for an
adversary to know"
0118: [Anne] AA29: typo: 7.4.1 Hierarchial resources to Hierarchicalresources
e-mail sent 14 Oct 2002 12:51:27 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00174.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section 7.4.1 Hierarchial resources, section
title, p. 70, line 2890
TEXT CHANGE: change "Hierarchial" with "Hierarchical"
0119: [Anne] AA30: typo: 6.11 replace "retrieveing" with "retrieving"
e-mail sent 14 Oct 2002 12:53:59 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00175.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: 6.11 Element <Decision>, description of
"Indeterminate", p. 66, line 2763
TEXT CHANGE: replace "while retrieveing policies," with "while
retrieving policies,"
0120: [Anne] AA31: typo: 6.11 replace "network errrors" with"network errors"
e-mail sent 14 Oct 2002 12:55:46 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00176.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section 6.11 Element <Decision>, paragraph
describing "Indeterminate", p. 66, line 2763.
TEXT CHANGE: replace "network errrors" with "network errors"
0121: [Anne] AA32: clarify use of "dn"
e-mail sent 14 Oct 2002 12:59:38 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00177.html
STATUS: not yet considered.
TEXT LOCATION: Section 6.7 Element <Attribute>, description of
"Issuer [Optional]", p. 64, line 2685
TEXT CHANGE: replace "This MAY be a dn that binds to a public
key" with "This MAY be an X.500 Distinguished Name that binds
to a public key"
0122: [Anne] AA33: typo: xs:complType to xs:complexType
e-mail sent 14 Oct 2002 13:02:18 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00178.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section 6.4 Element <ResourceContent>, last line
of schema fragment, p. 63, line 2623
TEXT CHANGE: replace "</xs:complType>" with "</xs:complexType>"
0123: [Anne] AA34: editorial: B.3 XACML functions see Appendix A
e-mail sent 14 Oct 2002 09:51:08 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00152.html
STATUS: Editorial. Vote not required. [was 2nd AA11]
TEXT LOCATION: Section B.3 XACML functions, second sentence,
p. 107, line 4208.
TEXT CHANGE: Change "See Section Introduction" to "See Appendix
A. Standard data types, functions and their semantics."
0124: [Anne] AA35: typo: 6.2 "ulitmately" to "ultimately"
e-mail sent 14 Oct 2002 13:04:23 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00179.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section 6.2 Element <Subject>, p. 62, line 3573
TEXT CHANGE: replace "subject is the entity ulitmately
associated" with "subject is the entity ultimately associated"
0125: [Anne] AA36: typo: 6.1 replace "contextby" with "context by"
e-mail sent 14 Oct 2002 13:06:19 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00180.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section 6.1 Element <Request>, explanation of
<Subject>[One to Many], p. 61, line 2536
TEXT CHANGE: replace "Specifies information about a subject of
the request contextby listing" with "Specifies information about
a subject of the request context by listing"
0126: [Anne] AA37: typo: 6.1 "<Subject> elements.Each" to"<Subject> elements. Each"
e-mail sent 14 Oct 2002 13:08:32 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00181.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section 6.1 Element <Request>, 2nd paragraph, 2nd
line at end, p. 60, line 2518
TEXT CHANGE: replace "<Subject> elements.Each" with "<Subject>
elements. Each"
0127: [Anne] AA38: typo: 5.28 "<xacml-contex:" to "<xacml-context:"
e-mail sent 14 Oct 2002 13:11:52 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00182.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section 5.28 Element
<SubjectAttributeDesignatorWhere>, end of first paragraph, p. 57,
line 2374
TEXT CHANGE: replace "<xacml-contex:Request>" with
"<xacml-context:Request>"
0128: [Anne] AA39: typo: 5.7 "context.and" to "context and"
e-mail sent 14 Oct 2002 13:22:07 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00183.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section 5.7 Element <Subject>, explanation of
<SubjectMatch>[One to Many], last paragraph, p. 47, line 1954
TEXT CHANGE: replace "context.and" with "context and"
0129: [Anne] AA40: typo: 5.5 "conjuctive" to "conjunctive"
e-mail sent 14 Oct 2002 13:24:25 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00184.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section 5.5 Element <Target>, 2nd paragraph, first
sentence, p. 46, line 1905
TEXT CHANGE: replace "conjuctive" with "conjunctive"
0130: [Anne] AA41: typo: "PolicyIdReferece" to "PolicyIdReference"
e-mail sent 14 Oct 2002 13:28:11 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00185.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section 5.1 Element <PolicySet>, schema fragment,
p. 44, line 1833
TEXT CHANGE: replace "<xs:element ref="xacml:PolicyIdReferece"/>"
with "<xs:element ref="xacml:PolicyIdReference"/>"
0131: [Anne] AA42: typo: change "explicitely" to "explicitly"
e-mail sent 14 Oct 2002 13:31:38 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00186.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section 4.2.4.5 Example PolicySet, last sentence,
explanation of [43]-[60], p. 43, line 1803
TEXT CHANGE: replace "Policy 2 is explicitely included" with
"Policy 2 is explicitly included"
0132: [Anne] AA43: use "xs:" or "xsi:"?
e-mail sent 14 Oct 2002 13:36:53 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00187.html
STATUS: not yet considered.
In some places we use "xsi:<some datatype>", while in other
places we use "xs:<some datatype>". We should pick one. I
propose "xs:" just because it is shorter.
0133: [Anne] AA44: 6.10 change "resource-uri" to "resource-id"
e-mail sent 14 Oct 2002 13:47:15 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00188.html
STATUS: Editorial. Vote not required.
TEXT LOCATION: Section 6.10 Element <Result>, explanation of
"ResourceId [Optional]", p. 65, line 2735
TEXT CHANGE: replace 'If this attribute is omitted, then the
resource identity is specified by the
"urn:oasis:names:tc:xacml:1.0:resource:resource-uri" resource
attribute in the <Request> element.'
with
'If this attribute is omitted, then the resource identity is
specified by the
"urn:oasis:names:tc:xacml:1.0:resource:resource-id" resource
attribute in the <Request> element.'
0134: [Seth Proctor] SP01: 18c comments. Forwarded message from Seth Proctor.
e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00192.html
STATUS: Not yet considered.
a. 3.3.2.1 (PolicyTarget) still makes it unclear that Policy Target is
computed before arriving at the PDP. I know you're working on new
language, so that may just not have been added yet.
[Anne] A new "Section 7.x Target Construction" is proposed in AA06.
This also affects HL02 "Policy Indexing".
I suggest that all discussion of how Policy and PolicySet targets
are computed be replaced with "See Section 7.x Target
Construction for information about how targets may be
constructed." and with the actual text of such a Section 7.x.
This includes the following locations:
1) Section 2.8 Policy indexing, p. 14-15, lines 470-480,
beginning with "Two approaches are supported" and ending with
"In either case, it is the policy writer's responsiblity to
ensure that only one policy statement applies to a particular
decision request."
2) Section 3.3.2.1 Policy target, p. 20, lines 630-645, beginning
with "The target may be declared by the writer of the
policy,or..." and ending with "In this case, the targets may
be omitted from the ocmponent rules."
3) Section 5.1 Element <PolicySet>, p. 44, lines 1861-1863,
beginning with "The <Target> element MAY be declared..." and
ending with "either as an intersection or as a union."
4) Section 5.5 Element <Target>, p. 46, following line 1908,
just before the schema fragment and after the sentence ending
with "...<Target> element and the corresponding section of the
<xacml-context:Request> element."
5) Section 5.17 Element <Policy>, p. 52, lines 2170-2172,
replacing "The <Target> element MAY be declared by the creator
of the <Policy> element, or it MAY be computed from the
<Target> elements of the referenced <Rule> elements either as
an intersection or as a union."
b. In section 5, when the <Function> tag is explained in Apply, it
should have a pointer to the higher-order bag section so people
understand what it's there for
[Anne] To be more specific, in Section 5.21 Element <Apply>,
explanation of <Function> [Optional], p. 54, line 2260,
following "The name of a function that is applied to the
elements of a bag.", append: "See Section A.13.11
Higher-order bag functions."
c. 10.3.6 (Identifiers) doesn't list the type of any these attributes,
nor does it give the required uses for them that it says
implementors must follow. I realize this is transparent to a lot of
the code, and only one of these is required to support, but it would
still be helpful to know what type they're supposed to be (if there
is a certain expected type). Later in the spec they're explained in
a little more detail, but not enough to make the strong language in
this section about correct implemention make sense.
[Anne] I don't think there is a specified type for these.
You specify the type using the XML Datatype="" attribute.
One user might specify key-info, for example, using a
SubjectKeyInfo from PKIX, while another might use a
ds:KeyInfo structure.
d. A.6 (Element <AttributeValue>) says that an AttributeValue's type is
implied by the function using it, but that's changed now to state
the type explicitly (same for next 2 sections)...actually, this
change is missing in most of the section A examples.
[Anne] Agreed.
e. A.11 (Matching elements) says that the AD/AS used in a Target match
must return a bag, and then has some other language that borders on
describing an API. This is the section we talked about. I think it
should be made clear that if a function expects a single String (eg),
then getting a bag is an error. Also, this section (and the section
later describing bags) should clarify that _any_ type is allowed in
a bag, not just those defined as base types in the spec. If you'd
like, I can work on alternate language.
[Anne] Yes, please propose alternate language.
f. B.9 (Status codes) is still missing some of the codes that we
discussed (like problems choosing the root policy). Maybe a few more
could be added. Maybe I should writeup a few other codes, and include
some proposal for the format of the values to accompany various
Status codes?
[Anne] Yes, please write up the proposed new status codes and
the format for their values. To all: I think we MUST specify
the format for the information provided with every status
code we define. Otherwise, we will have non-interoperable
formats being used.
g. D (Acknowledgments) ... this is a small issue, but since the list of
voting memebers is basically also the contributer list, shouldn't
this section name people who weren't on the TC but helped shape the
standard? This is the way other specs look.
[Anne] We put everyone who has been a member of the TC during
the period of the development of this spec into
"Contributors". The Acknowledgments section will include
only those who were voting members as of the date when we
vote to make this document a "Committee Spec".
h. Should SubjectAttributeDesignatorWhere extend SubjectAD now instead of
just AD? Before it made sense, since all ADs were the same, but I
would think that since there's now a special AD for Subjects, that's
what you would want to extend.
[Simon] if we extend subj-attr-desig <-
subject-attr-desig-where we will inherit subject-category
attribute. Having subject-category in subject-attr-desig is
confusing.
i. There is still no discussion anywhere about treating the Request as a
notional doc and going outside the PDP to get attribute values. The
same text is still throughout the spec suggesting just the opposite,
and the picture at the beginning looks the same. I know you're thinking
about how to change this, but if this is really supposed to be supported,
then the spec _must_ change dramatically to make this clear. One or
two paragraphs added somewhere will not cut it.
[Anne] Some of the "one or two paragraphs added somewhere"
are in a new section proposed in PH09: "7.4.2 Attributes"
that includes subsections on Attribute Retrieval and Missing
Attributes. The rest is already in the document in Section
7.7 Use profile for XACML request.
If more text is needed to make these sections clear, please
propose it.
SEE ALSO: AA45, AA46
j. Related to that, there needs to be some clear examples of how to use an
AD/AS to make this happen. I don't think that AS's should be used for
this functionality (just because it's too hard to support), but that's
a separate issue.
[Anne] Isn't that an implementation issue? The spec should
just specify the desired behavior, not how it is achieved.
k. There should probably be some language added to discuss how Policy[Set] Ids
should be treated. At the very least, and example or some hints about
typical use would make things better, since right now this is entirely
up to the implementor, and as such is guarenteed to be a point where
interoperability of policies fails.
l. There is still no text about how to do resolution in an Apply, and how this
can be short-circuited, etc. Are you working on this change? The
current spec doesn't make it clear that you should be able to do this,
so I think this needs to be added in clear examples & specification,
otherwise not all implementors will get this right.
[Anne] I think this is in 7.7 Use profile for XACML request.
If not, could you be more specific about what is needed?
0135: [Anne] AA45: make data-flow diagram consistent with 7.7 Use profile for XACML request
e-mail sent 16 Oct 2002 14:32:00 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00195.html
STATUS: not yet considered.
SEE ALSO: SP01i
TEXT LOCATION: 3.1 Data-flow model, Figure 1 - Data-flow diagram
TEXT CHANGE: Replace diagram with:
access requester --2. access request----> PEP --13. obligations--> obligations
| ^ service
| |
3. request 12. response
| |
| |
V |
PDP <--4. request notification---- context handler <---8. resource--> resource
content
---5. attribute queries------>
^ <--10. attributes------------
| --11. response context-------->
| | ^ ^
| | | |--9. environment--> environment
| | | attributes
| | |
| 6. attribute 7. attributes
| queries |
1. policy | |
| | |
| V |
PAP PIP
TEXT LOCATION: 3.1 Data-flow model, Steps 1-12
TEXT CHANGE: Replace text for steps as follows:
1. PAPs write policies and make them available to the PDP.
2. The access requester sends a request for access to the PEP.
3. The PEP sends the request for access to the context handler in
its native request format, optionally including additional
attributes of the subjects, resource and action. The
context handler translates the information in the native
request into a form consistent with an XACML Request Context
(see Section 7.7 Use profile for XACML request).
4. The PEP notifies the PDP that a request is available for
evaluation.
5. Based on its initial policy (see Section 7.1 Initial
policy), the PDP issues attribute queries to the context
handler based on the attributes required to evaluate the
initial policy and those policies referenced from it.
Attribute queries are expressed in the form of
AttributeDesignators or AttributeSelectors.
6. The context handler may issue attribute queries to a PIP in
order to resolve attributes not present in the native
request.
7. The PIP returns the requested attributes to the context
handler.
8. The context handler may optionally obtain information from
the resource itself.
9. The context handler may optionally obtain information from
the environment.
10. The context handler makes the requested attributes available
to the PDP "as if" the requested attributes were located in
a Request Context. The PDP evaluates the policy.
11. The PDP returns the response context (including its
decision) to the context handler.
12. The context handler translates the response context to the
native response format of the PEP. The context handler
returns the response to the PEP.
13. The PEP fulfills the obligations
14. (Not shown) if access is permitted, then the PEP permits
access to the resource; otherwise, it denies access.
DISCUSSION: Make diagram and steps consistent with respect to
"notional" Request Context and how/when attributes are obtained.
0136: [Anne] AA46: Make 3.2 XACML context consistent with 7.7 Use profile for XACML request
e-mail sent 16 Oct 2002 14:36:47 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00196.html
STATUS: not yet considered.
TEXT LOCATION: 3.2 XACML context, last paragraph. p. 17, line
560.
TEXT CHANGE: Append: "See Section 7.7 Use profile for XACML
request for more information about how the XACML request context
is handled."
0137: [Steve Hanna] SteveHanna02: xs:decimal string representation
e-mail sent 16 Oct 2002 14:45:39 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00198.html
STATUS: not yet considered.
Section A.3 Representations says:
For integers and decimals, XACML SHALL use the conversions
described in IBM Standard Decimal Arithmetic document at
the following URL:
http://www2.hursley.ibm.com/decimal/decarith.html
This document combines the various standards set forth by
IEEE and ANSI for string representation of numeric values.
The IBM document defines a numeric string syntax that
allows scientific notation, NaNs, and infinities. The XML
schema document that defines the permissible contents of the
xs:decimal data type does not allow any of these.
I suggest that a note be added after the above passage,
saying:
Note that although the IBM document allows exponents,
NaNs, and infinities the XML Schema specification does
not allow these in an xs:integer and xs:decimal value.
Therefore, they MUST NOT be used in such values.
0138: [Steve Hanna] SteveHanna03: Use of decimal math should be justified
e-mail sent 16 Oct 2002 14:45:44 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00199.html
STATUS: not yet considered.
It is unusual to specify the use of decimal math in
a specification like XACML, especially requiring strict
conformance to a detailed specification of decimal
math behavior. Many platforms do not support decimal
math. Binary math is much more common.
I can see why you might want to use decimal math for
this specification. Maybe you're likely to be doing a
lot of financial calculations. Still, I think it's a
bit odd that you require support for exponents, NaNs,
and the like in the implementation but don't provide
any way for a user to access these features. A simpler
approach would have been to leave the arithmetic
loosely specified, like XQuery has done.
At the least, I think you should add a few sentences
to the end of section A.12 Arithmetic evaluation saying
Decimal arithmetic is used in order to provide
results that closely match those expected by the
average user.
0139: [Steve Hanna] SteveHanna04: handling of divide-by-zero
mail sent 16 Oct 2002 14:45:48 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00188.html
STATUS: not yet considered.
Section A.12 Arithmetic evaluation says that trap-enablers
SHALL all be set to 0. I believe that this means that a
division by zero will produce a result of positive or
negative infinity and proceed along happily. That seems
surprising and contradicts sections 6.11 and B.9, which
imply that a division by zero will produce an indeterminate
result.
I suggest that you change section A.12 to say that all
trap-enablers SHALL be set to 0 except division-by-zero,
which SHALL be set to 1. Then you can change the description
of the integer-divide and decimal-divide functions in
section A.13.2 to say that they SHALL produce a result
of indeterminate with a processing-error status if the
divisor is 0.
0140: [Michiharu] MK01: DataType and Namespace
e-mail sent 17 Oct 2002 18:47:58 +0900
http://lists.oasis-open.org/archives/xacml/200210/msg00202.html
STATUS: not yet considered.
We have agreed to specify DataType attribute in both policy and context.
The schema 16j says that DataType attribute is xs:anyURI. I think that the
DataType is written as QName such as "xs:string" and "xs:boolean" like
MatchId attribute. So I request to change DataType attribute from xs:anyURI
to xs:QName. Besides, we should add the following namespace prefix and its
namespace URI in the spec.
Prefix Namespace URI
xacml-function urn:oasis:names:tc:xacml:1.0:function
xacml-datatype urn:oasis:names:tc:xacml:1.0:datatype
*) datatype prefix is used for xacml-datatype:x500Name and
xacml-datatype:rfc822Name. In fact, prefix itself matters only in the
specification document. Policy writers can choose another prefix as they
like.
I think text that refers to ds: prefix (XML Signature namespace) and saml:
prefix no longer exist in the spec. So line 289-290, 303-305 should be
deleted.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC