[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Current list of Change Requests
Appended is a list of current Change Requests. I will send out an updated copy 1 hour before tomorrow's conference call, but this copy may be helpful for those of you who will not be able to print or study that copy in time. 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.9, 02/10/16 (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; these include all
unresolved e-mail between archive messages
http://lists.oasis-open.org/archives/xacml/200210/msg00123.html
and
http://lists.oasis-open.org/archives/xacml/200210/msg00188.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. Vote not required.
HL02: Policy Indexing
STATUS: not yet considered. Modified with Polar's text.
AA03: typo: 2.10.Actions performed in conjunction with enforcement
STATUS: Editorial. Vote not required.
PH01: Clarifications changes on 18c
STATUS: CLOSED. Broken out into PH04-PH10, plus additions to HL02.
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: revised based on comment from Tim.
AA05: editorial: PolicyCombiningAlgId reference
STATUS: Editorial. Vote not required.
AA06: clarify computed <Target>s
STATUS: not yet considered
HL03: Question about Anonymous Access Subject
STATUS: not yet considered.
PH04: 2.3 Combining algorithms, add "Only-one-applicable-policy"
STATUS: not yet considered.
PH05: 5.22 Element <Function>: clarify description
STATUS: not yet considered.
PH06: 5.23 AttributeDesignator selects collection, not set
STATUS: not yet considered.
PH07: 5.29 Clarify <AttributeSelector>
STATUS: not yet considered.
PH08: 5.32 Clarify <Obligation>
STATUS: not yet considered.
PH09: New section 7.4.2 Attributes
STATUS: not yet considered.
PH10: 7.5 Clarify Authorization decision
STATUS: not yet considered.
AA07: point to 7.x Obligations from other places
STATUS: not yet considered.
AA08: specify default XPathVersion
STATUS: Not yet considered.
AA09: editorial: remove 10.3.1 XPathNamespace
STATUS: Editorial. Vote not required.
AA10: editorial: Add reference [IBMSDA] to references
STATUS: Editorial. Vote not required.
AA11: Clarify "MatchId" functions
STATUS: Not yet considered. Bag functions omitted per comment from Polar.
AA12: editorial: move B.5 Environment attributes after B.8Action attributes
STATUS: Editorial. Vote not required.
SteveHanna01: integer-mod takes two arguments
STATUS: Not yet considered.
SatoshiHada01: How many namespaces does XACML define?
STATUS: not yet considered.
AA13: Remove B.11 Identifiers used in conformance tests
STATUS: not yet considered.
AA14: amended: editorial: get Piras' name right
STATUS: Editorial. Vote not required. Revised to add additional location.
AA15: editorial: glossary Policy and PolicySet "componet" to "component"
STATUS: Editorial. Vote not required. AA16 merged in.
AA16: editorial: Glossary Policy set "componet" to "component"
STATUS: CLOSED (replaced by revised AA15)
AA17: editorial: use "Requester", not "Requestor"
STATUS: Editorial. Modified based on comments.
AA18: editorial: change "implementor" to "implementer"
STATUS: Editorial. Revised based on comments.
AA19: editorial: "interdeterminate" to "indeterminate"
STATUS: Editorial. Vote not required.
AA20: editorial: replace "First-Appplicable" with"First-Applicable"
STATUS: Editorial. Vote not required.
AA21: editorial: change "URI os the" to "URI of the"
STATUS: Editorial. Vote not required.
AA22: editorial: fix reference to RFC 2821 in B.4
STATUS: Editorial. Vote not required.
AA23: editorial: change "the URLfrom which" to"the URL from which"
STATUS: Editorial. Vote not required.
AA24: Add references for Haskel
STATUS: Editorial. Vote not required.
AA25: editorial: A.3 add reference to [IBMSDA]"
STATUS: Editorial. Vote not required.
AA26: typo: 10.3.3 "alorithm" to "algorithm"
STATUS: Editorial. Vote not required.
AA27: typo: Sun Microsystems, not Sun Micrososytems
STATUS: Editorial. Vote not required.
AA28: typo: change "adverary" to "adversary"
STATUS: Editorial. Vote not required.
AA29: typo: 7.4.1 Hierarchial resources to Hierarchicalresources
STATUS: Editorial. Vote not required.
AA30: typo: 6.11 replace "retrieveing" with "retrieving"
STATUS: Editorial. Vote not required.
AA31: typo: 6.11 replace "network errrors" with"network errors"
STATUS: Editorial. Vote not required.
AA32: clarify use of "dn"
STATUS: not yet considered.
AA33: typo: xs:complType to xs:complexType
STATUS: Editorial. Vote not required.
AA34: editorial: B.3 XACML functions see Appendix A
STATUS: Editorial. Vote not required. [was 2nd AA11]
AA35: typo: 6.2 "ulitmately" to "ultimately"
STATUS: Editorial. Vote not required.
AA36: typo: 6.1 replace "contextby" with "context by"
STATUS: Editorial. Vote not required.
AA37: typo: 6.1 "<Subject> elements.Each" to"<Subject> elements. Each"
STATUS: Editorial. Vote not required.
AA38: typo: 5.28 "<xacml-contex:" to "<xacml-context:"
STATUS: Editorial. Vote not required.
AA39: typo: 5.7 "context.and" to "context and"
STATUS: Editorial. Vote not required.
AA40: typo: 5.5 "conjuctive" to "conjunctive"
STATUS: Editorial. Vote not required.
AA41: typo: "PolicyIdReferece" to "PolicyIdReference"
STATUS: Editorial. Vote not required.
AA42: typo: change "explicitely" to "explicitly"
STATUS: Editorial. Vote not required.
AA43: use "xs:" or "xsi:"?
STATUS: not yet considered.
AA44: 6.10 change "resource-uri" to "resource-id"
STATUS: Editorial. Vote not required.
SP01: 18c comments. Forwarded message from Seth Proctor.
STATUS: Not yet considered.
AA45: make data-flow diagram consistent with 7.7 Use profile for XACML request
STATUS: not yet considered.
AA46: Make 3.2 XACML context consistent with 7.7 Use profile for XACML request
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:
> 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. Vote not required.
Section 2. Background (Non-mormative), line 309:
Non-mormative --> Non-normative
Section 6.2 Element <Subject>, line 2474
Distingwished --> Distinguished
HL02: Policy Indexing
e-mail sent 11 Oct 2002 12:10:39 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00128.html
STATUS: not yet considered. Modified with Polar's text.
SEE ALSO: AA06, SP01a
TEXT LOCATION: Section 2.8 Policy indexing, p. 14, lines
471-545
TEXT CHANGE: 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: 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 represents a single Policy Set with the "Only
One Applicable Policy" policy combining algorithm.'
RATIONALE: 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)
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
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.
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: 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)
http://lists.oasis-open.org/archives/xacml/200210/msg00135.html
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.
[Bill]that would seem to be consistent with our singular
treatment of PDPs in section 7.
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: revised based on comment from Tim.
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
"It is the responsibility of the PAP to ensure that no two
policies visible to a PDP have the same identifier."
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."
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: not yet considered
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 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.
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: not yet considered.
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.
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: not yet considered.
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.
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: not yet considered.
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
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."
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: not yet considered.
TEXT LOCATION: Section 5.23 Complex type
AttributeDesignatorType, 2nd paragraph, first sentence, p. 55,
line 2292
TEXT CHANGE: replace "Elements of AttributeDesignatorType type
select a set of attribute values from the request
context." with
"Elements of AttributeDesignatorType type select a collection
of attribute values from the request context."
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: not yet considered.
TEXT LOCATION: Section 5.29 Element <AttributeSelector>, first
paragraph, p. 58, lines 2410-2411
TEXT CHANGE: 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, 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."
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: not yet considered.
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."
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: not yet considered.
TEXT LOCATION: Following Section 7.4.1 "Hierarchi[c]al
resources", p. 70, after line 2911.
TEXT CHANGE: 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. Each attribute specifies an
AttributeId and a DataType, and each attribute desigator
specifies an AttributeId and DataType. Attribute Designators
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 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 MAY return an authorization decision of "Indeterminate"
result in evaluating an expression that requires at least one
value to be present from an attribute designator. The
AttributeId and DataType of the attribute MAY be listed in the
result as described in Section Authorization decision. However,
a PDP MAY fail to issue such information due to security
concerns.
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: not yet considered.
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.'
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: not yet considered.
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."
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: Not yet considered.
TEXT LOCATION: Section 5.4 Element <XPathVersion>, p. 45, lines
1896-1900
TEXT CHANGE: Append:
"If the <XPathVersion> element is omitted, then the XPath 1.0
specification is used by default."
RATIONALE: Specify which XPathVersion is used in case the
<XPathVersion> element is not included.
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.
RATIONALE: element no longer exists.
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";;
RATIONALE: referenced from A.1 Introduction, but not included in
11. References.
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: Not yet considered. Bag functions omitted per comment from Polar.
TEXT LOCATION: Section A.11 Matching elements, p. 89, lines
3446-3456.
TEXT CHANGE: 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
RATIONALE: 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.
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.
RATIONALE: Environment attributes follow all the Subject,
Resource, and Action attributes in the Request Context.
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.
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.
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"
RATIONALE: just as for identifiers used in examples, I don't
think we need to spell out the identifiers used in conformance
tests.
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"
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"
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)
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"
RATIONALE: 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]
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".
RATIONALE: Some locations in the document already use
"implementer". We should be consistent. [Bill - Websters
allows for both, but lists "implementer" first]
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"
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"
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."
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".'
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"
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/
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]."
RATIONALE: put the details in one place, the References section.
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"
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"
RATIONALE: might make people think of a certain competitor.
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"
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"
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,"
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"
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"
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>"
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."
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"
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"
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"
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>"
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"
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"
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"/>"
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"
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.
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.'
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?
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.
RATIONALE: Make diagram and steps consistent with respect to
"notional" Request Context and how/when attributes are obtained.
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."
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC