[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Updated Comments list for 12/02/02 meeting
This is late, but it may be helpful to some people. I certainly need it to keep track of things! Anyway, an updated Comments list is attached, containing all comments to date. Comments still needing resolution: - 32a The description of a rule seems to be inadequately motivated. [Tim to provide wording] - 33 map function [Use "<type>-map" functions or current "map" function] - 39 subject-category as attribute, rather than <Attribute> - 40 Section 6.2 [same as 39] - 43 A comment on Section 7.3 [Re-wording of 7.3 proposed and posted to XAMCL list. There has been some discussion] - 44 There is no Section describing<SubjectAttributeDesignator> [Simon to provide wording] - 48 Resource types [Re-wording A.12 to loosen restriction to XACML standard functions in MatchId; posted to list. There has been some discussion.] - 52a-d 5.31 Element <AttributeSelector> [We wanted Michiharu's expert XPath opinon on these] - I still need to submit a comment proposing changing the Match element order to (AttributeValue, AttributeDesignator). Won't have time before Monday. - 59-62 have not yet been discussed. 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: Comments on XACML 1.0 Committee Specification
Maintainer: Anne Anderson
Version: 1.14, 02/12/02 (yy/mm/dd)
Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.Comments.txt
This file contains a link to every comment received on the
xacml-comment@lists.oasis-open.org mailing list reporting any
kind of problem with the specification since the public review
was announced on November 8, 2002. Each comment is broken down
into specific sub-comments, and the response to each is
described, along with any actions to be taken by the TC.
This version of the file contains e-mail up through
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00153.html
CATEGORIES
----------
Editorial: Formatting error or formatting inconsistency.
Inconsistent: Specification says one thing in one place and
another thing in another place.
Incomplete: Specification omits information required for full
specification of a feature.
Incorrect: Specification describes functionality that will not
work due to external or internal constraints.
Unclear: Description of feature is not clear or is ambiguous.
Undesirable: Feature is not desirable.
Alternative: Proposed alternative to a feature
======================================================================
COMMENTS
======================================================================
0001. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00003.html
Subject: An editorial comment on the XACML 1.0 document
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Sat, 09 Nov 2002 02:16:43 +0900
Appendix B.1 says that two namespaces are defined, but there are
three URIs there. The URI for XACML datatypes should be removed?
CATEGORY: Inconsistent.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: Remove B.1 lines 4332-4333 describing the
urn:oasis:names:tc:xacml:1.0:data-type identifier from the specification.
=============================================================================
0002. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00004.html
Subject: xs:time
From: Seth Proctor <seth.proctor@sun.com>
Date: Fri, 08 Nov 2002 12:33:59 -0500
Sections A.2 (Primative types) and B.4 (Data types) include date
and dateTime, but not time. The time type is used by many
functions and at least one standard attribute, and should be on
those list.
CATEGORY: Inconsistent.
SEE ALSO: 0004
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: Add http://www.w3.org/2001/XMLSchema#time to Sections
10.3.7, A.2, and B.4.
======================================================================
0003. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00005.html
Subject: resubmission: v_1.0 - niggling editorial nuggets
From: bill parducci <bill.parducci@overxeer.com>
Date: Fri, 08 Nov 2002 10:01:51 -0800
---------------------------------------------------------------------------
0003a. line 520:
'...element from each of the policies or policy'
the word 'policy' is *half* bold.
CATEGORY: Editorial.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: Line 520, make word 'policy' all bold.
---------------------------------------------------------------------------
0003b. line 793:
'[c01] <?xml version="1.0" encoding="UTF-8"?>'
inconsistent font (times)
actually, upon further inspection, the document seems to use
proportionally spaced, sans serif fonts (e.g. 'arial') in the
listings and example code starting at line 641 and continuing to
line 826, at which point it uses the correct font, non
proportional serif font (courier).
CATEGORY: Editorial.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: On lines 641-826, use non-proportional serif fonts.
---------------------------------------------------------------------------
0003c. line 1039:
starting with line 1039 the examples are color encoded. the
snippets prior to this are not. given the darkened background i
think that the color makes it harder to read (and print), but
either way i think that it should be consistent (sections 5 & 6
go back and forth twixt the two). this continues thorough
[portions] of the primer.
CATEGORY: Editorial.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: Remove all color-encoding from XML fragments in the
document.
---------------------------------------------------------------------------
0003d. line 3278:
'xacml:Policy:PolicySet'
there seems to be an extraneous border line above the row in the
table
CATEGORY: Editorial.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: Remove border line above xacml:Policy:PolicySet in the
table following line 3278.
---------------------------------------------------------------------------
0003e. line 3291:
'Urn:oasis:names:tc:xacml:1.0:environment'
there seems to be extraneous border lines above each of the rows
in this table
CATEGORY: Editorial.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: Remove border lines between urns in table following
line 3291.
---------------------------------------------------------------------------
0003f. line 3385:
'<AttributeValue'
snippet font (should be 'courier')
CATEGORY: Editorial.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: Use courier font in schema fragment following line 3385.
---------------------------------------------------------------------------
0003g. line 3399:
'[IBMDSA]'
i thought that the IBMDSA reference was replaced with an IEEE spec throughout the doc, or was this only in a specific instance?
CATEGORY: Editorial.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: In A.4, lines 3398-3399, change reference from "IBM
Standard Decimal Arithmetic [IBMDSA]" to "IEEE Standard for
Binary Floating-Point Arithmetic [IEEE754]".
---------------------------------------------------------------------------
0003h. line 4277:
'first argument of Anderson@sun.com?'
question mark should be quotation mark
CATEGORY: Editorial.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: On line 4277, change 'Anderson@sun.com?' to
'Anderson@sun.com"'
---------------------------------------------------------------------------
0003i. line 4434:
' urn:oasis:names:tc:xacml:1.0:resource:scope'
leading spaces or indentation (should be left margin aligned)
CATEGORY: Editorial.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: On line 4434, align
"urn:oasis:names:tc:xacml:1.0:resource:scope" with the left margin.
---------------------------------------------------------------------------
0003j. finally, there seems to be some squooshing going on with
lines 2618, 2742, 2778 in the pdf. can others confirm?
CATEGORY: Editorial.
STATUS: Resolved 14 November 2002.
RESPONSE: "squooshing" confirmed.
ACTIONS: Unsquoosh lines 2618, 2742, 2778.
======================================================================
0004. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00006.html
Subject: followup to xs:time comment
From: Seth Proctor <seth.proctor@sun.com>
Date: Fri, 08 Nov 2002 14:51:42 -0500
all of the functions defined as type-* (like the
type-one-and-only function) need to have a time-* version added
in 10.3.8 (and maybe elsewhere, though I don't think so)
CATEGORY: Inconsistent.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: Add function:time-one-and-only, function:time-bag-size,
function:time-is-in, function:time-bag functions as
mandatory-to-implement in the table in Section 10.3.8
"Functions".
======================================================================
0005. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00007.html
Subject: Inconsistent specification of <*Match> elements and-match functions
From: Anne Anderson <Anne.Anderson@Sun.com>
Date: Mon, 11 Nov 2002 14:28:14 -0500 (EST)
Problem: MatchId functions used in a target take one
AttributeDesignator or AttributeSelector argument, and one
literal AttributeValue argument. The order of the two
arguments is specified differently in different parts of the
specification. Also, the *-match functions can only be used
in a Target if the order of their arguments (template,
specific value) agree with the order of arguments in a MatchId
function (the AttributeDesignator or AttributeSelector, and
the literal value).
Recommendation:
Option 1:
Specify that the first argument to each *-match function is
the specific value to be compared to the template, and the
second argument is the template. To be consistent, rename
"regexp-string-match" to "string-regexp-match". This requires
the least change to the specification.
Option 2:
Specify that the first argument to a MatchId function is a
literal AttributeValue and the second argument is the
AttributeDesignator or AttributeSelector.
Text locations where references occur:
1 must change if Option 1 selected
2 must change if Option 2 selected
2 - Every occurrence of <SubjectMatch, <ResourceMatch, or
<ActionMatch except as called out below: Change order of
AttributeSelector or AttributeDesignator argument and
AttributeValue argument
2 - Section A.12 lines 3491-3493: reword as follows:
"Each argument to the named function MUST match the
appropriate primitive types for the explict attribute value and
the following <AttributeDesignator> or <AttributeSelector>
element, ...
1 - Section A.12, lines 3493-3496: reword as follows:
"... such that an element of the bag returned by the
<AttributeDesignator> or <AttributeSelector> element is placed
as the first argument to the function, and the explicit
attribute value is placed as the second argument to the
function."
1 - Section A.14.12, lines 4250-4281: reverse order of arguments
in the specifications for the -match functions, such that the
first argument is the full value to be compared to the template
or dominating value, and the second argument is the template or
dominating (higher in the tree of values) value.
2 - Section A.14.13, lines 4306-4313: the specification of the
xpath-node-match function probably needs to change to be
consistent with the above if xpath-node-match is to be allowed
in a Target expression. Note that several examples use
xpath-node-match as MatchId functions, and line 3503 implies
that this is permissable, but lines 3535-3540 indicate that
xpath-node-match is NOT permissable in a MatchId function.
CATEGORY: Inconsistent.
STATUS: Resolved 14 November 2002.
RESPONSE: Rejected. While the wording of Appendix A.12 needs
improvement to be more clear, and while it is confusing to have
the order of function arguments mean one thing in a Target and
another thing in an Apply, the specification and semantics are
consistent. Since several implementations are already
successfully handling the varying argument order, we feel it is
better to leave the argument order as currently specified. We
encourage you to submit a proposed re-wording of Appendix A.12
that would make the current semantics more clear, however.
ACTIONS: None.
======================================================================
0006. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00008.html
Subject: present function
From: Seth Proctor <seth.proctor@sun.com>
Date: Tue, 12 Nov 2002 11:00:52 -0500
Section A14.5 still lists a present function. I think the decision was to
remove this functionality entirely for the time being.
CATEGORY: Inconsistent.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: Remove lines 3730-3738, describing the "present"
function, from the specification.
======================================================================
0007. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00009.html
Subject: a few typos
From: Seth Proctor <seth.proctor@sun.com>
Date: Tue, 12 Nov 2002 11:08:13 -0500
---------------------------------------------------------------------------
0007a. 10.3.7: dayTime and yearMonth durations should read
"xquery-operators" not "xquey-operaqtors"
CATEGORY: Editorial.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: In Section 10.3.7, change two instances of
"xquey-operaqtors" to "xquery-operators".
---------------------------------------------------------------------------
0007b. 10.3.8: function:rfc822Name-equal is listed as
rfc822name-equal (lower case 'n' in 'name')
CATEGORY: Editorial.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: In Section 10.3.8, change "function:rfc822name-equal"
to "function:rfc822Name-equal"
======================================================================
0008. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00010.html
Subject: ...IsPresent and Qualified...
From: John Merrells <merrells@jiffysoftware.com>
Date: Tue, 12 Nov 2002 16:40:59 -0800
---------------------------------------------------------------------------
0008a. In draft 18f section 5.30, 5.31, and 5.32 documents the
AttributeIsPresent elements,
but the 18f schema doesn't contain these.
CATEGORY: Inconsistent.
STATUS: Resolved 14 November 2002.
RESPONSE: Rejected. The *AttributeIsPresent" elements were
removed from the specification in XACML 1.0, which is the version
being reviewed.
ACTIONS: None.
---------------------------------------------------------------------------
0008b. Also, the 18f schema contains the
QualifiedSubjectAttributeDesignator element, but this isn't
described in the 18f draft, it first appears in the conformance
tables 10.3.1
CATEGORY: Inconsistent.
STATUS: Resolved 14 November 2002.
RESPONSE: Rejected. The "QualifiedSubjectAttributeDesignator"
element is named "SubjectAttributeDesignator" in the XACML 1.0
version of the specification, which is the version being reviewed.
ACTIONS: None.
======================================================================
0009. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00010.html
Subject: Urn versus urn
From: Seth Proctor <seth.proctor@sun.com>
Date: Tue, 12 Nov 2002 11:03:53 -0500
in a number of sections in 10.3 (10.3.2, 10.3.4, 10.3.5, 10.3.6,
10.3.7) the 'u' in 'urn' has become a 'U'
CATEGORY: Editorial.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: Change "Urn:" to "urn:" in Sections 10.3.2, 10.3.4,
10.3.5, 10.3.6, and 10.3.7 (two types at the end of the table).
======================================================================
0010. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00012.html
Subject: missing functions in 10.3.8
From: Seth Proctor <seth.proctor@sun.com>
Date: Wed, 13 Nov 2002 17:52:46 -0500
Section 10.3.8 is missing the regexp-string-match function as well as all
of the Set functions
CATEGORY: Inconsistent.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: To Section 10.3.8, as mandatory-to-implement, add the
following functions:
function:regexp-string-match
<type>-intersection
<type>-at-least-one-member-of
<type>-union
<type>-subset
<type>-set-equals
where <type> is "string", "boolean", "integer", "double", "date",
"time", "dateTime", "anyURI", "hexBinary", "base64Binary",
"dayTimeDuration", "yearMonthDuration", "x500Name", and
"rfc822Name".
======================================================================
0011. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00013.html
Subject: The namespace URI for XACML data types
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Thu, 14 Nov 2002 14:11:15 +0900
Section 1.3 mentions a namespace URI for XACML data types. It should be
removed.
CATEGORY: Editorial.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: In Section 1.3 "Schema organization and namespaces",
remove lines 320-321 that describe the
urn:oasis:names:tc:xacml:1.0:data-type namespace.
======================================================================
0011. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00014.html
Subject: The footnote 1 in Appendix A.4
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Thu, 14 Nov 2002 14:17:39 +0900
There is a footnote in Appendix A.4.
An earlier RFC, RFC 1779 "A String Representation of Distinguished Names",
is less restrictive,
so xacml:x500Name uses the syntax in RFC 2253 for better interoperability
xacml:x500Name should be replaced with the correct identifier.
CATEGORY: Inconsistent.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
ACTIONS: In footnote "1" under Section A.1, change
"xacml:x500Name" to
"urn:oasis:names:tc:xacml:1.0:data-type:x500Name".
======================================================================
0012. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00015.htm
Subject: Section A12
From: John Merrells <merrells@jiffysoftware.com>
Date: Thu, 14 Nov 2002 01:03:04 -0800
I'm finding section A12 difficult to understand. I think the information
could
be more clearly presented.
1) It introduces the Target element and its immediate child elements, and
then the standard functions that can be used for a MatchID. But then a
couple of paragraphs later it says that the only functions that can appear
in a MatchID of a Target child are a different bunch of functions. This is
confusing.
2) <i>type</i>-match appears as a standard function. (And does not appear
in the conformance tables.) The subsequent paragraph starts "The evaluation
semantics for a match is as follows...' But is this referring to the
standard
match functions as a whole, or just the behaviour of the <i>type</i>-match
function itself. If not then where's the definition of <i>type</i>-match ?
3) The text and the examples refer to the special match functions before
they've actually been defined.
I think a reorg of section A12 would improve the legibility quite a bit.
And followup in
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00016.html:
> 2) <i>type</i>-match appears as a standard function. (And does not appear
> in the conformance tables.) The subsequent paragraph starts "The
> evaluation
> semantics for a match is as follows...' But is this referring to the
> standard
> match functions as a whole, or just the behaviour of the
> <i>type</i>-match
> function itself. If not then where's the definition of
> <i>type</i>-match ?
I think I've worked out that the <i>type</i> place holder in the list of the
standard match functions is not meant to stand in for all the types
recognized
by xacml, but is meant as a kind of wildcard to refer to the functions
actually
specified. So <i>type</i>-match doesn't mean integer-match, double-match,
etc, but actually just rfc822Name-match and x500Name-match.I think other
readers might be confused by this too.
CATEGORY: Unclear.
STATUS: Resolved 11/21/02.
RESPONSE: Approved. We agreed that this section is unclear and
needs to be re-worded. We agreed to keep the existing difference
in argument order between MatchId functions and FunctionId
functions, despite agreeing that this is very confusing and
error-prone. The changes required to the specification
(including most examples), implementations, and conformance tests
are too pervasive to change at this point for a feature that is
not actually broken. If the XACML specification is not submitted
to OASIS for standardization on 15 December 2002, however, we
agreed that the argument order should be made consistent before
the specification is re-submitted.
ACTIONS: Replace Appendix A.12 "Matching elements" with the
revised text attached to e-mail message
http://lists.oasis-open.org/archives/xacml/200211/msg00157.html.
=========================================================================
0013. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00032.html
Subject: The PolicySet Schema (Line 1759--1762)
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Mon, 18 Nov 2002 15:02:24 +0900
A minor comment on Line 1759--1762.
I found the type of two attributes (PolicySetId and
PolicyCombiningAlgId) specified by a long URI
http://www.w3.org/2001/XMLSchema#anyURI
I'm not sure this is wrong, but I can say it's strange in the
sense that the qname xs:anyURI is used in other schema
descriptions (e.g., Line 1819, 1889).
I think it's better to replace the long URI with the (short) qname.
CATEGORY: Inconsistent.
STATUS: Resolved 11/21/02.
RESPONSE: Approved. Change to use qnames, since this is a
fragment from the schema, not from an instance.
ACTIONS: Change document lines 1759 and 1762 such that xs: is
used instead of "http://www.w3.org/2001/XMLSchema#";.
=========================================================================
0014. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00033.html
Subject: No description about the PolicyDefaults element
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Mon, 18 Nov 2002 15:48:16 +0900
The <PolicySetDefaults> element is described in Section 5.3, but
I could find no section describing the <PolicyDefaults> element.
As a result, no syntax is defined for it in the specification
document. Is this okay?
CATEGORY: Incomplete.
STATUS: Resolved 11/21/02.
RESPONSE: Approved adding PolicyDefaults description.
ACTIONS: Add PolicyDefaults section as new 5.21 as follows:
5.21 Element <PolicyDefaults>
The <PolicyDefaults> element SHALL specify default values that
apply to the <Policy> element.
<xs:element name="PolicyDefaults" type="xacml:DefaultsType"/>
<xs:complexType name="DefaultsType">
<xs:sequence>
<xs:choice>
<xs:element ref="xacml:XPathVersion" minOccurs="0"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
<PolicyDefaults> element is of DefaultsType complex type.
<XPathVersion> [Optional]
Default XPath version.
ACTION ITEM: #14. [Michiharu Kudo] submit following as new
comment:
COMMENT: In Section 5.20 Element <Policy>, under <Description>
description, say "See 5.2 Element <Description>". In Section 5.2
Element <Description>, add <Rule> to the list from which this
applies.
=========================================================================
0015. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00034.html
Subject: conformance tests (NotApplicatble or Not-Applicabale)
From: John Merrells <merrells@jiffysoftware.com>
Date: Sun, 17 Nov 2002 23:32:46 -0800
The spec says 'Not-Applicable', but the tests
(eg. IIB003Response.xml) say 'NotApplicable'.
CATEGORY: Inconsistent.
SEE ALSO: #16
STATUS: Resolved 11/21/02.
RESPONSE: Approved changing specification text to
"NotApplicable".
ACTIONS: Change specification text throughout to use
"NotApplicable" rather than "Not-Applicable".
=========================================================================
0016. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00035.html
Subject: NotApplicable From: Seth Proctor <seth.proctor@sun.com>
Date: Mon, 18 Nov 2002 10:07:50 -0500
The schema uses "NotApplicable" in a Decision, but the spec says
that it's "Not-applicable" ... I'm pretty sure the schema is
correct here, right?
CATEGORY: Inconsistent.
SEE ALSO: #15
STATUS: Resolved 11/21/02.
RESPONSE: Approved changing specification text to
"NotApplicable".
ACTIONS: Change specification text throughout to use
"NotApplicable" rather than "Not-Applicable".
=========================================================================
0017. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00036.html
Subject: Another A.12 comment
From: Seth Proctor <seth.proctor@sun.com>
Date: Mon, 18 Nov 2002 10:09:47 -0500
Section A.12 (which I know Anne is re-working) makes several
mentions of the EnvironmentMatch type ... there is no such type,
so this should probably be removed from A.12
CATEGORY: Inconsistent.
STATUS: Resolved 11/21/02.
RESPONSE: Remove EnvironmentMatch type.
ACTIONS: Replace Section A.12 with the text supplied in e-mail
message
http://lists.oasis-open.org/archives/xacml/200211/msg00157.html.
=========================================================================
0018. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00039.html
Subject: xacml:Policy:XpathVersion mandatory-to-implement?
From: Anne Anderson <Anne.Anderson@Sun.com>
Date: Mon, 18 Nov 2002 11:45:24 -0500 (EST)
In Section 10.3.1, "xacml:Policy:XpathVersion" is listed as
mandatory-to-implement.
------------------------------------------------------------------------
0018a. This should be spelled "XPathVersion"
CATEGORY: Inconsistent.
STATUS: Resolved 11/21/02.
RESPONSE: Approved. Spelling should be "XPathVersion".
ACTIONS: Change 10.3.1 to use "XPathVersion" spelling.
------------------------------------------------------------------------
0018b. This should not be mandatory-to-implement, since support for
XPath functionality and the containing PolicyDefaults are not
mandatory-to-implement.
CATEGORY: Inconsistent.
STATUS: Resolved 11/21/02.
RESPONSE: Approved. XPathVersion is not mandatory-to-implement.
ACTIONS: Change 10.3.1 M/O column for "xacml:Policy:XPathVersion"
to "O".
------------------------------------------------------------------------
0018c. 10.3.1 should contain "xacml:Policy:PolicyDefaults", and it
should be marked not mandatory-to-implement
CATEGORY: Inconsistent.
STATUS: Resolved 11/21/02.
RESPONSE: Approved. Add an entry for PolicyDefaults marked not
mandatory-to-implement.
ACTIONS: Add to 10.3.1 an entry for
"xacml:Policy:PolicyDefaults", marked "O" (optional).
=========================================================================
0019. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00040.html
Subject: Incomplete: behavior if <Obligations> present but notsupported
From: Anne Anderson <Anne.Anderson@Sun.com>
Date: Mon, 18 Nov 2002 13:25:13 -0500 (EST)
The behavior of a PDP that does not support the optional
<Obligations> element when presented with a Policy containing
<Obligations> is not specified.
Possible behavior: if a Policy or PolicySet is Applicable to a
Request and the Policy or PolicySet contains <Obligations>, but
the PDP does not support <Obligations>, that the PDP MUST return
"Deny".
CATEGORY: Incomplete.
SEE ALSO: #20
STATUS: Resolved 11/21/02.
RESPONSE: Approved specifying behavior. Behavior SHALL be to
return "Indeterminate".
ACTIONS: Add new Section 7.12 "Unsupported functionality" as
follows:
7.12 Unsupported functionality
If the PDP attempts to evaluate a PolicySet or Policy that
contains an element type or feature that the PDP does not
support, then the PDP SHALL return a response of "Indeterminate".
If a StatusCode is also returned, the PDP SHALL return a
StatusCode value of
"urn:oasis:names:tc:xacml:1.0:status:syntax-error" for an
unsupported element type error , and
"urn:oasis:names:tc:xacml:1.0:status:processing-error" for an
unsupported feature error.
=========================================================================
0020. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00041.html
Subject: INCOMPLETE: behavior when XPath encountered,but not supported
From: Anne Anderson <Anne.Anderson@Sun.com>
Date: Mon, 18 Nov 2002 13:37:35 -0500 (EST)
The behavior of a PDP that does not support the optional XPath
*Defaults, selectors, functions, etc. when presented with a
policy containing such elements is not specified.
In some cases, the XPath elements may appear in a <Target>
element, making it impossible to determine whether or not a
PolicySet, Policy, or Rule is applicable.
In other cases, the <Target> element may not require any XPath
functionality, and a PolicySet, Policy, or Rule may be
applicable, but evaluating the <Condition> in the Rule may
require XPath functionality.
Possible behavior: If, during evaluation of a Request, any
unsupported element is encountered, then the PDP MUST return a
result of Indeterminate.
CATEGORY: Incomplete.
SEE ALSO: #19
STATUS: Resolved 11/21/02.
RESPONSE: Approved specifying behavior. Behavior SHALL be to
return "Indeterminate".
ACTIONS: Add new Section 7.12 "Unsupported functionality" as
follows:
7.12 Unsupported functionality
If the PDP attempts to evaluate a PolicySet or Policy that
contains an element type or feature that the PDP does not
support, then the PDP SHALL return a response of "Indeterminate".
If a StatusCode is also returned, the PDP SHALL return a
StatusCode value of
"urn:oasis:names:tc:xacml:1.0:status:syntax-error" for an
unsupported element type error , and
"urn:oasis:names:tc:xacml:1.0:status:processing-error" for an
unsupported feature error.
=========================================================================
0021. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00042.html
Subject: C.3 First-Applicable policy-combining alg inconsistent
From: Anne Anderson <Anne.Anderson@Sun.com>
Date: Mon, 18 Nov 2002 16:29:27 -0500 (EST)
In the description of the policy-combining algorithm for
FirstApplicable, lines 4752-4754 say: if error occurs while
evaluating a policy, then evaluation shall continue looking for
an applicable policy, returning Indeterminate only if no
applicable policy found.
But lines 4755-4758 say: if error occurs while evaluation a
policy, then evaluation shall halt and policy set shall evaluate
to "Indeterminate".
Lines 4752-4754 should be deleted. That would be consistent with
the pseudo-code and with the "safety" of not allowing any
"Permit" if there is an Indeterminate that should have returned a
Deny.
CATEGORY: Inconsistent.
STATUS: Resolved 11/21/02.
RESPONSE: Approved deleting pdf:4752-4754. This removes the
first, incorrect description of how the PDP behaves in the face
of an error and retains the second, correct description.
ACTIONS: Delete lines pdf:4752-4754
=========================================================================
0022. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00044.html
Subject: Section 5.24
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Tue, 19 Nov 2002 14:31:14 +0900
There is no description about the child element
<xacml:SubjectAttributeDesignator> in Section 5.24.
Some description should be added between Lines 2162 and 2163.
CATEGORY: Incomplete.
STATUS: Resolved 11/21/02.
RESPONSE: Approved adding a description of
SubjectAttributeDesignator.
ACTIONS: Add the following before line pdf:2168:
<SubjectAttributeDesignator> [Optional]
A subject attribute argument.
=========================================================================
0023. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00045.html
Subject: Line 308: The SAML prefix
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Tue, 19 Nov 2002 14:41:02 +0900
In Line 308, the SAML prefix (saml:) is mentioned, but it never
appears anywhere in the document. The line should be removed.
CATEGORY: Inconsistent.
STATUS: Resolved 11/21/02.
RESPONSE: Approved removing line pdf:308
ACTIONS: Remove line pdf:308
=========================================================================
0024. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00046.html
Subject: Comments on the prefix xf
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Tue, 19 Nov 2002 14:56:39 +0900
In Line 1295, the QName xf:yearMonthDuration should be replaced by the
correct URI.
In Line 1345, the QName xf:yearMonthDuration should be replaced by the
correct URI.
Appendix A14.7:
In Lines 3759, 3766, 3773, 3782, 3790, 3796,
the QName xf:yearMonthDuration should be replaced by the correct URI.
CATEGORY: Inconsistent.
STATUS: Resolved 11/21/02.
RESPONSE: Approved using full uri.
ACTIONS: In lines 1295 and 1345, use
"http://www.w3.org/TR/xquery-operators#yearMonthDuration"; instead
of "xf:yearMonthDuration"
=========================================================================
0025. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00047.html
Subject: Line numbering is inconsistent
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Tue, 19 Nov 2002 15:08:56 +0900
Line numbering is inconsistent between the PDF file and the Word
file.
I have downloaded them from:
http://www.oasis-open.org/committees/xacml/repository/cs-xacml-core-01.doc
http://www.oasis-open.org/committees/xacml/repository/cs-xacml-core-01.pdf
An example:
In the PDF file Line 43 is a blank line.
In the Word file Line 43 is about the copyright.
CATEGORY: Inconsistent.
STATUS: Resolved 11/21/02.
RESPONSE: Commenters should specify which version is being used.
Accept comments from either version. In the future, Bill
Parducci will generate both versions before we
post either so that we can verify that numbers match.
ACTIONS: None for now.
=========================================================================
0026. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00048.html
Subject:The type of the RequestContextPath attribute
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Tue, 19 Nov 2002 15:34:25 +0900
The current type of the RequestContextPath attribute is
xs:anyURI. (Section 5.31) I don't think that a valid XPath
expression is always a valid URI (according to RFC2396). So I
think the type should be xs:string rather than xs:anyURI. Please
correct me if I'm wrong.
In the XML-Signature specification, the type of XPath expressions
is xs:string.
Follow-on:
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00068.html
Date: Thu, 21 Nov 2002 15:36:40 +0900
For example, /xml[2] is not a valid URI.
CATEGORY: Incorrect.
STATUS: Resolved 11/21/02.
RESPONSE: Approved changing DataType in line 2421 to xs:string.
ACTIONS: Change line 2421 DataType from xs:anyURI to xs:string.
=========================================================================
0027. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00049.html
Subject: Function Identifiers in Section 10.3.8
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Tue, 19 Nov 2002 21:11:44 +0900
Section 10.3.8 uses QName as function identifiers.
Don't use the namespace prefix "function" and replace all the qnames with
the corresponding URIs.
Remove line 3302 (xmlns:function="urn:oasis:names:tc:xacml:1.0:function").
CATEGORY: Inconsistent.
SEE ALSO: #29,30
STATUS: Resolved 11/21/02.
RESPONSE: Approved. Use full urn; remove xmlns:function line.
ACTIONS: Use full "urn:oasis:names:tc:xacml:1.0:function:"
throughout the specification rather than just "function:".
Remove line 3302 that describes the xmlns:function.
=========================================================================
0028. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00050.html
Subject: equality & set/bag functions
From: Seth Proctor <seth.proctor@sun.com>
Date: Tue, 19 Nov 2002 17:34:32 -0500
The set and bag functions (along with others), are defined as
type-[name] where this is expanded to include one function for
each standard type. Presumably this includes the two duration
attribute types. One of the bag functions and several of the set
functions also specify that their definitions are based on using
the type-equal function for the coresponding type. The equality
functions, however, are defined individually for each type, and
no equal functions are defined for the two duration types.
So, the question: should there be equality functions defined for
the two duration types, or should certain type-[name] functions
not be able to handle the two duration types? It seems like one
of those two must change to make this work.
CATEGORY: Incomplete.
STATUS: Resolved 11/21/02.
RESPONSE: Approved. Add dayTimeDuration-equal and
yearMonthDuration-equal functions. Use XQuery semantics.
ACTIONS: Add following text at end of Section A.14.1, following
line pdf:3639:
o dayTimeDuration-equal
This function SHALL take two arguments of type
"http://www.w3.org/TR/xquery-operators#dayTimeDuration"; and
SHALL return an "http://www.w3.org/2001/XMLSchema#boolean";.
This function shall perform its evaluation according to the
"op:dayTimeDuration-equal" function [XQO Section 8.3.5]. Note
that the lexical representation of each argument is converted
to a value expressed in fractional seconds [XQO Section
8.2.2].
o yearMonthDuration-equal
This function SHALL take two arguments of type
"http://www.w3.org/TR/xquery-operators#yearMonthDuration"; and
SHALL return an "http://www.w3.org/2001/XMLSchema#boolean";.
This function shall perform its evaluation according to the
"op:yearMonthDuration-equal" function [XQO Section 8.3.2].
Note that the lexical representation of each argument is
converted to a value expressed in integer months [XQO Section
8.2.1].
=========================================================================
0029. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00053.html
Subject: The prefix "function:" is used in Section 4 Examples
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Wed, 20 Nov 2002 12:34:21 +0900
The namespace prefix "function:" is used in the explanation for
the examples in Section 4. There are too many places where it is
used and so I cannot list all here. All should be replaced with
the correct URIs.
E.g.,
function:string-equal
Function:string-equal (Capital F is used)
function:and
function:string-one-and-only
function:date-less-or-equal
function:date-one-and-only
CATEGORY: Inconsistent.
SEE ALSO: #27,30
STATUS: Resolved 11/21/02.
RESPONSE: Approved using full urn.
ACTIONS: Use full "urn:oasis:names:tc:xacml:1.0:function:"
throughout the specification rather than just "function:".
=========================================================================
0030. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00054.html
Subject: The prefix "function:" is used in Appendix A
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Wed, 20 Nov 2002 12:39:38 +0900
The namespace prefix "function:" is used in Appendix A.
There are too many places where it is used and so I cannot list all here.
All should be replaced with the correct URIs.
CATEGORY: Inconsistent.
SEE ALSO: #27,29
STATUS: Resolved 11/21/02.
RESPONSE: Approved using full urn.
ACTIONS: Use full "urn:oasis:names:tc:xacml:1.0:function:"
throughout the specification rather than just "function:".
=========================================================================
0031. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00055.html
Subject: The default value of the MustBePresent attribute(Section 5.26)
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Wed, 20 Nov 2002 16:08:50 +0900
The default value "false" of the MustBePresent attribute is NOT specified in
the schema in Section 5.26.
It should be added.
CATEGORY: Inconsistent.
STATUS: Resolved 11/21/02.
RESPONSE: Approved adding default="false". This is correct in
the schema.
ACTIONS: Add default="false" to line pdf:2203
=========================================================================
0032. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00058.html
Subject: Problems understanding XACML spec
From: Graham Klyne <GK@NineByNine.org>
Date: Wed, 20 Nov 2002 13:40:25 +0000
I'm having a really hard time understanding what you're trying to
say in the XACML spec:
http://www.oasis-open.org/committees/xacml/repository/draft-xacml-schema-policy-18d.doc
ACTIONS: Anne Anderson sent Graham Klyne a message explaining
that the public review is being held with respect to XACML 1.0,
and not draft 18d.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00060.html
Comments may still apply, since they are fairly general, so I
have listed them below.
------------------------------------------------------------------------
0032a. The description of a rule seems to be inadequately motivated.
The description in section 2 (background) says "The <Rule>
element contains a boolean expression that can be evaluated in
isolation..." which doesn't do anything to prepare me for the
description I find in section 3.3.1. I'm finding it particularly
hard to see
(a) what this Boolean expression is evaluated over (it seems to
have something to do with the rule target), and
(b) how the Boolean result relates to the evaluation of the rule.
I can see that a Boolean true results in Permit or Deny
depending on the value of the rule's effect field, but what
happens if the Boolean value is false?
As far as I can tell, understanding this is crucial to
understanding all the other stuff about combining rules and
policies.
CATEGORY: Unclear.
STATUS: Discussed 11/21/02.
RESPONSE: Approved in general. It is unclear.
ACTION ITEM: #32a. [Tim Moses] propose an introductory paragraph for
3.3.1 motivating Rule.
ACTIONS:
------------------------------------------------------------------------
0032b. Under what circumstances is a rule found to be
"NotApplicable"?
CATEGORY: Unclear.
STATUS: Resolved 11/21/02.
RESPONSE: We believe this is specified clearly in Section 7.5 of
XACML 1.0.
ACTIONS: No change.
------------------------------------------------------------------------
0032c. I also find the reference to the fact that a rule may
"inherit" target information from a policy is particularly
obscure.
It seems to me that the idea of a rule is fundamental to
understanding this specification, but that vital idea is not
adequately explained.
It may be that the information is present somewhere in this document, but
it is a big and complicated document and I can't tell what's
important.
CATEGORY: Unclear.
STATUS: Resolved 11/21/02.
RESPONSE: Approved. This is not clear.
ACTIONS: Lines 631-632. Change wording to say "Rule uses the
<Target> of its parent Policy element."
------------------------------------------------------------------------
0032d. I think more attention needs to be paid to the order in
which concepts are introduced. I would expect section 2 to deal
with this, but it seems some important ideas are not being
adequately explained.
CATEGORY: Unclear.
STATUS: Resolved 11/21/02.
RESPONSE: Please submit any specific important ideas that are not
being adequately explained or are in the wrong order in Section
2 in the XACML 1.0 specification. Note that Section 2 only
covers key concepts, with full detail in later sections.
ACTIONS: None.
------------------------------------------------------------------------
0032f. I also think there's an over-dependence in the text on
abbreviations that are introduced in the glossary. There are
many special terms, and ordinary words used with special
meaning, and it's not reasonable to assume that someone not
familiar with them to absorb them on one pass through the
glossary.
CATEGORY: Unclear.
STATUS: Resolved 11/21/02.
RESPONSE: We believe this has been improved in XACML 1.0: terms
from the glossary are bolded in XACML
1.0 to indicate they have special meaning. This is a specialist
area, and we expect people to refer to the glossary until they
are acquainted with the terms. Please submit any specific places
that are not clear in the 1.0 version.
ACTIONS: None.
=========================================================================
0033. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00061.html
Subject: map function
From: Seth Proctor <seth.proctor@sun.com>
Date: Wed, 20 Nov 2002 16:22:32 -0500
I'm a little concerned with the definition of the map
function. Every other function and attribute in the spec has a
well defined type associated with it, but the map function does
not. Even things like the bag functions are defined as type-* so
that each of the bag functions returns a well defined type (ie,
there is a uniquely named function for each bag function that
returns each attribute type). The map function, however, is
simply defined as returning a bag of some type.
For consistency, and to make sure that the strong typing present
in the rest of the spec exists here too, I would suggest that the
map function be redefined as type-map, such that there is a named
map function for each type in the spec. I think the functionality
being provided by map makes sense, I just think it should be
clear what types of bags the map function returns.
CATEGORY: Alternative.
STATUS: Discussed 11/21/02.
RESPONSE:
ACTIONS:
DISCUSSION:
[Polar Humenn] My vote is for "map".
Rationale:
The primitive functions, i.e. integer-equal, are named with their
arguments' particular type, not their resultant type. If you
named functions for their resultant type, as is suggested with
"integer-map" returning a bag of integers regardless of what its
argument type is, then to be consistent with that naming
convention would mean the "equals" function between integers
would be called really be called "boolean-equal" because equal
returns a boolean. And that would lead to inconsistent, not to
mention, nonsensical naming.
The functionality of "map" is independent of the primitive type
of the its arguments, where as "integer-equal" is not,
"integer-equals" requires two integers as arguments. The function
"map" only requires the supplied function and the supplied bag to
agree on types, no matter what the type happens to be. It is
truly polymorphic.
I think naming "integer-map" is really confusing as it only
states half the type story, the rest is left in the air. If you
were to fully specify the type in the name, you'd have to say
something like "integer-float-map" for functions that map bags of
integers to floats (or visa versa depending on how you want
it". That would cause an explosion of type names, which is
unnecessary, because the <Function> argument really specifies the
type.
Also, for extension types, the function "map" can easily and with
formal integrity, be used for any extension type and any other
extension functions that do conversions or selections of that
type.
Furthermore, this "map" function didn't come out of nowhere, it
is the most popular polymorphic function on the planet. :)
[Daniel Engovatov] My vote is for <type>-map. I have explained
some of my rational for this in a previous e-mail.
Most important are - consistency and ease of expandability - for
the cases when the function name is supplied as an argument that
has its value determined during the evaluation time. Not
specifying the return type of the enclosing "higher" order
function would make it extremely cumbersome to define a
consistent and optimized interface.
[Seth Proctor] I think there's been too much emphasis in this
conversation on comparing map and type-equal. The better
comparison is between map and things like type-one-and-only. The
one-and-only functions could have been defined like the map
function, operating on any type and returning a single value of
the same type, just like map is now defined [1]. Instead, it
works on pre-defined types [2]. This is useful because we know
specifically what type is being returned by the function, and
what type we expect to work with inside the function. There are
other type-* functions that are in the same position (think Bag
and Set functions), which is why Daniel and I are talking about
consistency.
Arguably, it could be useful to change all of the type-*
functions to be defined like map, so that the generic
functionality could be used by any type, but it would require an
overhaul of the entire spec, and therefore is inappropriate for
now (maybe a 1.1 or 2.0 version)
[1] In the map function the type it operates on is the return type of the
function, and that is indeed the same type it returns.
[2] It is relatively easy for an implementation to let new types be used in
this system, so it's not hard to extend.
[Polar Humenn, responding to Daniel Engovatov]
> My vote is for <type>-map.
> I have explained some of my rational for this in a previous e-mail.
>
> Most important are - consistency
The proposed naming convention is NOT consistent with the other
functions.
The current function names contain the type of their arguments,
whereas the proposed <type>-map names the resultant type.
> and ease of expandability
I really don't know what you mean by "expandability".
> - for the cases when the function name is supplied as an argument that
> has its value determined during the evaluation time.
The function name is supplied EXPLICITLY in the FunctionId
attribute of the <Function> element. It's value is already
determined at compile time. That was the specific reason for the
<Function> element.
Now, of course, you can take any IMPLEMENTATION route you chose,
such as using the "interpreter" approach where you might not know
its value until evaluation time, but that is certainly not FORCED
by the specification.
[Polar Humenn, responding to Seth Proctor]
> I think there's been too much emphasis in this conversation on
> comparing map and type-equal. The better comparison is between
> map and things like type-one-and-only. The one-and-only
> functions could have been defined like the map function,
> operating on any type and returning a single value of the same
> type, just like map is now defined [1].
That is true. One-and-only can be polymorphic, and I certainly
would NOT complain if it were. However, the name is consistent
with the other naming convention is that the <type> in the name,
names its argument. It is only coincidence that it also names its
return type as well.
> Instead, it works on pre-defined types [2]. This is useful because we
> know specifically what type is being returned by the function, and what
> type we expect to work with inside the function. There are other type-*
> functions that are in the same position (think Bag and Set functions),
> which is why Daniel and I are talking about consistency.
The other functions, especially the set functions use an implicit
"type-equal" function in the reduction of the set. That is why
the set functions contain the type name.
As for the "type-bag", "type-one-and-only", "type-bag-size"
functions, I would be very happy if they were polymorphic as
well. The type is pretty meaningless to their
functionality. However, the function "type-is-in" calls an
implicit function "type-equal" to handle the membership
determination. So, it can be said that it is needed.
> Arguably, it could be useful to change all of the type-*
> functions to be defined like map, so that the generic
> functionality could be used by any type, but it would require
> an overhaul of the entire spec, and therefore is inappropriate
> for now (maybe a 1.1 or 2.0 version)
Arguably, we could eliminate most of the "typing" information
because it could be deduced by the type system, especially since
every attribute value and designator has a required DataType XML
attribute, but we've already been down that route.
> [1] In the map function the type it operates on is the return type of the
> function, and that is indeed the same type it returns.
Not so. In the map function, the "type" it "operates on" is the
argument type of the given function not the resultant type.
The given function takes an arguement of type "a" and returns an
item of type "b". The map function converts every memeber of a
bag of type "a" to a bag of type "b". It is only a coincidence if
the resultant type is the same type as the argument type, i.e. a
= b.
> [2] It is relatively easy for an implementation to let new types be used in
> this system, so it's not hard to extend.
That is an implementation issue. I have a system for which "map"
can operate on any type, old or newly introduced. I don't have to
create a new map function for the new type.
[Polar Humenn, responding to Daniel Engovatov]
> >As for the "type-bag", "type-one-and-only", "type-bag-size" functions, I
> >would be very happy if they were polymorphic as well. The type is pretty
> >meaningless to their functionality. However, the function "type-is-in"
> >calls an implicit function "type-equal" to handle the membership
> >determination. So, it can be said that it is needed.
>
> Why would you be happy? Would it make for a simpler, faster and more
> efficient implementation for a variety of languages and architectures?
That depends on the capability of the implementors, and the
languages and architectures chosen.
> What is the reason for introducing polymorphic functions beyond it being a
> "cool" feature? Use case? Sample implementation that we can see, how it
> useful?
I don't know what "cool" is.
Use case:
If I introduce a new type, say "FingerPrint", and I use an
AttributeDesignator to retrieve attributes of that type, I don't
have to create a new function "FingerPrint-bag-size" to find out
how many I have when I do retrieve them, I can just use the same
old function "bag-size". Likewise, if I create a function called
"FignerPrint-to-Characteristic" I don't have to create a new
function "FignerPrint-map" (or would it be "Characteristic-map"?)
to convert a bag of FingerPrint values to a bag of Characteristic
values. I would just use the same old "map".
Now, how you implement it, is up to you. You certainly wouldn't
be precluded from creating "FingerPrint-bag-size". or
FingerPrint-map (or Characteristic-map?).
Sample implementation:
I've already gone over how you can do most of this with Java
interfaces, of which you can do the analogous thing with C++.
=========================================================================
0034. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00062.html
Subject: XCAML Spec version 1.0 - Example 2, Rule 1
From: Jahan Moreh <jmoreh@sigaba.com>
Date: Wed, 20 Nov 2002 14:09:54 -0800
Section 4.2.3. Rule 1, line 1027 states that: "A person may read
any record for which he or she is the designated patient".
Section 4.2.4.1., Line 1036 starts the XACML rule instance for
rule 1, which I assumed is the rule expressed in English in line
1027.
Line 1095-1111 (the condition) defines a condition for matching
the policy-number attribute from the <Subject> with the
policy-number in the patient record.
This condition does not match the English statement (A person may
read any record for which he or she is the designated patient)
stated earlier.
Am I missing something or is this an inconsistency?
CATEGORY: Inconsistent.
STATUS: Resolved 11/21/02.
RESPONSE: In Rule 1, "person" in the text descriptions is
referred to by "policy-number" in the <Condition>.
"policy-number" is used as the patient ID. We agree this is
unclear, since "policy" has other meanings.
ACTIONS: Use "patient-number" as the attribute name rather than
"policy-number" in the examples. Also in 1027 Rule 1, say "A
person, identified by patient number, may ....". Also, augment
line 1166-1168 to describe that the person is being described by
the person's patient-number.
=========================================================================
0035. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00063.html
Subject: The identifiers are wrong in Appendix A.2 and B.4
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Thu, 21 Nov 2002 11:46:26 +0900
In A.2 the separation char is #. E.g.,
http://www.w3.org/TR/xquery-operators#dayTimeDuration
In B.4 the separation char is :. E.g.,
http://www.w3.org/TR/xquery-operators:dayTimeDuration
Is this an inconsistency?
CATEGORY: Inconsistent.
STATUS: Resolved 11/25/02.
RESPONSE: Use # as the separation char in both places.
ACTIONS: B.4 replace : with # in datatypes. Search for similar
problems throughout spec.
=========================================================================
0036. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00064.html
Subject: Primitive type identifiers in B.4.
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Thu, 21 Nov 2002 12:49:14 +0900
Appendix B.4 says that several identifiers are defined in XML
Schema and XQuery.
I know that XML-schema identifiers (like
http://www.w3.org/2001/XMLSchema#string) are explicitly defined
in Section 3 of the XML-Schema specification:
http://www.w3.org/TR/xmlschema-2/#built-in-datatypes
How about the two XQuery-related identifiers?
http://www.w3.org/TR/xquery-operators#dayTimeDuration
http://www.w3.org/TR/xquery-operators#yearMonthDuration Are these
URIs defined in the XQuery specification?
http://www.w3.org/TR/xquery-operators/
If yes, tell me which part of which section defines them? If no,
it should be explicitly said that the XACML specification defines
these two identifiers by itself.
CATEGORY: Incomplete.
STATUS: Resolved 11/25/02.
RESPONSE: Define the two XQuery-related identifiers in XACML
Specification.
ACTIONS: In Appendix B.4, Change "The following data type
identifiers are defined by XML Schema and XQuery" to "The following data type
identifiers are defined by XML Schema.
[follow this with the list of datatypes from #string to
#base64Binary].
The following data type identifiers correspond to the
dayTimeDuration and yearMonthDuration data types defined in the
XQuery specification [XQO Sections 8.2.2 and 8.2.1,
respectively].
http://www.w3.org/2002/08/xquery-function#dayTimeDuration
http://www.w3.org/2002/08/xquery-function#yearMonthDuration
=========================================================================
0037. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00065.html
Subject: About subject category attributes
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Thu, 21 Nov 2002 14:28:55 +0900
Section 6.2. says that:
No more than one <Subject> element may contain an <Attribute>
with the given value for AttributeId
$B!H(Burn:oasis:names:tc:xacml:1.0:subject:subject-category$B!I(B.
What does this mean?
How is this related to the following description in Section
5.30???
If there are multiple subjects with the same subject category
attribute, then they SHALL be treated as if they were one
categorized subject.
CATEGORY: Inconsistent.
STATUS: Resolved 11/25/02.
RESPONSE: Change 6.2 to agree with 5.30.
ACTIONS: Section 5.30: "Multiple <Subject> elements may contain
an <Attribute> with a given value for AttributeId
"urn:oasis:names:tc:xacml:1.0:subject:subject-category". For a
SubjectAttributeDesignator, all <Subject> elements with the same
value for AttributeId
"urn:oasis:names:tc:xacml:1.0:subject:subject-category" are
treated as if they were a single <Subject> element.
=========================================================================
0038. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00066.html
Subject: A wrong URI in Section 5.30
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Thu, 21 Nov 2002 14:32:42 +0900
Replace
http://www.w3.org/2001/XML-Schema-instance#string
with
http://www.w3.org/2001/XMLSchema#string
CATEGORY: Inconsistent.
STATUS: Resolved 11/25/02.
RESPONSE: Accepted. Change to XMLSchema#string.
ACTIONS: Change pdf:2362-2363 to use
"http://www.w3.org/2001/XMLSchema#string";
=========================================================================
0039. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00067.html
Subject: subject-category as attribute, rather than <Attribute>
From: John Merrells <merrells@jiffysoftware.com>
Date: Wed, 20 Nov 2002 22:24:12 -0800
I can see why the subject-category attribute has been modelled
the way that it has, as an <Attribute> of the <Subject>
element. But how about modelling it as an XML attribute of the
<Subject> element instead?
<Subject Category='...:access-subject'>...</Subject>
This would enforce the constraint that there be only one subject-
category attribute in the XML Schema. This would also make
implementing a request processor a little simpler. And, I think
would make understanding this feature of the standard simpler.
CATEGORY: Alternative.
STATUS: Discussed 11/25/02. Bring this up on the XACML list
for more discussion. Would require a schema change, but would be
more consistent and possibly more efficient to search.
SEE ALSO: #40
RESPONSE:
ACTIONS:
DISCUSSION:
[Seth Proctor] I think that having the category as an XML
attribute makes some sense, and since it's a required element
(albeit with a default value) it wouldn't really impact
anything. On the other hand, if you want to treat the
subject-category as just another attribute that you can look for
and manipulate like all attribute values, then it makes sense to
leave it as it is. Ultimately, I feel that it makes things a
little clearer to have it as an XML attribute, but I'm easy on
this one.
=========================================================================
0040. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00069.html
Subject: Section 6.2
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Thu, 21 Nov 2002 16:26:00 +0900
Section 6.2 says that every <Subject> element MUST contain one
and only one <Attribute> with AttributeId
"urn:oasis:names:tc:xacml:1.0:subject:subject-category".
I'm wondering if this contradicts another sentence, which starts
with "If this attribute is not present in a given <Subject>
element"
The former means that there must be a single attribute
representing the subject category. On the other hand, the latter
means that it's optional.
Is this okay?
CATEGORY: Inconsistent.
STATUS: Discussed 11/25/02. Bring this to the XACML list for
further discussion.
SEE ALSO: #39
RESPONSE:
DISCUSSION (11/25/02): Two options
1) Change "MUST contain one and only one" to "MUST contain no
more than one" in Section 6.2 pdf:2553.
2) Make subject-category attribute required in the Request
context schema (see f. below). Make following associated
changes in the specification:
a. 2.4 Multiple subjects, pdf:419-420
An XML attribute called "SubjectCategory" is used to differentiate
between subjects acting in different capacities. Some standard
values for this XML attribute are specified, and users may define
additional ones.
b. 4.2.2 Example request context, pdf:924: change
[05] <Subject>
to:
[05] <Subject SubjectCategory="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
c. 4.2.2 Example request context, delete lines pdf:929-937,
[06]-[14] that currently specify the subject-category
attribute.
d. 4.2.2 Example request context, change pdf:1005-1009 from:
05]-[37] Subject attributes are placed in the Subject section of
the Request. Each attribute consists of the attribute
meta-data and the attribute value.
[06]-[14] Each Subject section must have one and only one
subject-category attribute. The value of this attribute
describes the role that the subject plays in making the
decision request. The value of "access-subject" denotes the
identity for which the request was issued.
to:
05]-[37] Subject attributes are placed in the Subject section
of the Request. Each XACML attribute consists of the attribute
meta-data and the attribute value. Each Subject element has an
associated "SubjectCategory" XML attribute. The value of this
attribute describes the role that the subject plays in making
the decision request. The value of "access-subject" denotes the
identity for which the request was issued.
e. Change 5.30 Complex type SubjectAttributeDesignatorType,
pdf:2354-2364, to:
5.30.Complex type SubjectAttributeDesignatorType
The SubjectAttributeDesignatorType complex type extends the
AttributeDesignatorType complex type. It is the base type for
elements and extensions that refer to named categorized subject
attributes. A named categorized subject attribute is defined
as follows:
A subject is represented by a <Subject> element of the
<Subjects> element in the <xacml-context:Request> element.
The <Subject> element contains a SubjectCategory XML
attribute with a default value of
"urn:oasis:tc:xacml:1.0:subject-category:access-subject".
A categorized subject is a subject that is identified by its
particular subject category XML attribute.
f. Section 6.2 Element <Subject>. Insert following into schema
fragment just before pdf:2549:
<xs:attribute name="SubjectCategory" type="xs:anyURI"
use="optional"
default="urn:oasis:tc:xacml:1.0:subject-category:access-subject"/>
g. Section 6.2 Element <Subject>. Insert following between
pdf:2550 and pdf:2551:
SubjectCategory [Optional]
This attribute SHALL specify the subject category of the
associated <Subject> element. This attribute indicates a role
that the <Subject> entity plays in making the access request.
If SubjectCategory is not supplied, then its default value
SHALL be
"urn:oasis:tc:xacml:1.0:subject-category:access-subject",
indicating that the subject is the entity ultimately
associated with initiating the access request.
h. Section 6.2 Element <Subject>, delete pdf:2553-2558. Change
pdf:2559 to:
Typically, a <Subject> element will contain an
i. Section 6.2 Element <Subject>, delete pdf:2562-2563 ("No more
than one..."
j. Delete Section 13.9.4 Subject Attributes
k. Add "SubjectCategory" to Section 8.1 Extensible XML attribute
types. Delete Section 8.2 Extensible XACML attribute types.
l. Remove "Urn:oasis:names:tc:xacml:1.0:subject:subject-category
M" line from 10.3.5 Attribute
m. Remove the four ":subject-category:" attribute identifiers
from the table in 10.3.6 Identifiers.
n. Add new Section
10.3.7 XML Attribute Values
The implementation MUST use the following identifiers as
values for the <Subject> SubjectCategory XML attribute as
specified by XACML. This requirement pertains primarily to
implementations of a PAP or PEP that use XACML, since the
semantics of this attribute are transparent to the PDP.
urn:oasis:names:tc:xacml:1.0:subject-category:access-subject M
urn:oasis:names:tc:xacml:1.0:subject-category:codebase O
urn:oasis:names:tc:xacml:1.0:subject-category:intermediary-subject O
urn:oasis:names:tc:xacml:1.0:subject-category:recipient-subject O
urn:oasis:names:tc:xacml:1.0:subject-category:requesting-machine O
o. Change B.2 Access subject categories, pdf:4388 from "If
subject category is not specified, then this is the default
value." to "If SubjectCategory is not specified, then this is
the default value".
p. B.5 Subject attributes, delete pdf:4390-4391:
This identifier indicates the subject category.
"access-subject" is the
default. urn:oasis:names:tc:xacml:1.0:subject:subject-category
ACTIONS:
=========================================================================
0041. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00077.html
Subject: Schema file names are inconsistent
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Fri, 22 Nov 2002 14:49:19 +0900
At the home page http://www.oasis-open.org/committees/xacml/,
the schema file names are:
Policy Schema (cs-xacml-schema-policy-01.xsd)
Context Schema (cs-xacml-schema-context-01.xsd)
Note that the version number? is 01.
However, in the context schema a different file name is used for the policy
schema:
cs-xacml-schema-policy-1.0.xsd
This time, the version number is 1.0.
They should be consistent.
CATEGORY: Inconsistent.
STATUS: Resolved 11/25/02.
RESPONSE: Use "01". Michiharu has already made this change to
the name of the file on the home page.
ACTIONS: No further action needed.
=========================================================================
0042. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00078.html
Subject: A schema bug?
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Fri, 22 Nov 2002 14:54:57 +0900
I got a schema validation error when I used Xerces 2.0.1 and 2.2.0.
I can resolve this by adding mixed="true" to <xs:complexType name
="AttributeAssignmentType">.
Is this a schema bug or Xerces's bug?
org.xml.sax.SAXParseException: cos-ct-extends.1.4.2.2.2.2.1: Error for type
'AttributeAssignmentType'. The content type of a derived type and that of its
base must both be mixed or element-only.
at
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
at
org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDAbstractTraverser.reportSchemaError(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.handleComplexTypeError(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverseComplexTypeDecl(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverseGlobal(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDHandler.getGlobalDecl(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseNamedElement(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseGlobal(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDHandler.traverseSchemas(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown Source)
at
org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.findSchemaGrammar(Unknown Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at
javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:134)
CATEGORY: Inconsistent.
STATUS: Resolved 11/25/02.
RESPONSE: Accepted. Add mixed="true" in schema and spec.
ACTIONS: Add mixed="true" to <xs:complexType name="AttributeAssignmentType">.
Make this change in the XACML schema. Search specification for
schema fragments that also need to be changed to be consistent:
5.35 at least needs to change.
=========================================================================
0043. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00080.html
Subject: A comment on Section 7.3
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Fri, 22 Nov 2002 15:47:49 +0900
Section 7.3 says that
The target value SHALL be "Match" if the subjects, resource and action
specified in the request
context are all present in (i.e., within the scope of) the target.
This sentence is unclear to me because the meaning of "present" is unclear
to me.
Why doesn't Section 7.3 mention MatchId?
I think Section 7.3 should reference A.12, where I can find the detailed
semantics of MatchId.
It seems to me that the term "present" is used in three places (ignoring
the "present" function),
1) Section 3.3.1.1 Rule target
The meaning of "present" used here is also unclear to me, but I can accept
this situation
because Section 3 is non-normative.
2)Section 5.27, 5.28, 5.29 (Resource, Action, Environment Attr Designator)
There is clear definitions of "present" from the attribute designator
perspective.
(I think these definitions have nothing to do with MatchId attributes used
in <Target>)
3)Section 7.3
Is the term "present" used in Section 7.3 the same as the ones defined in
Section 5.27, 5.28, 5.29???
CATEGORY: Unclear.
STATUS: Discussed 11/25/02. Post proposed change below to the
XACML list for further discussion.
RESPONSE:
ACTIONS: Change 7.3 Target Evaluation to say
The target value SHALL be "Match" if the subject, resource and
action elements specified in the target all match values in the
request context. The target value SHALL be "No-match" if the
subject, resource, and action elements specified in the target do
not match values in the request context. The value of a Match
element where a referenced attribute value can not be obtained
depends on the value of the "MustBePresent" attribute of the
AttributeDesignator. If the "MustBePresent" attribute is "true",
then the result of the Match element is "Indeterminate" when the
AttributeDesignator value can not be obtained. If the
"MustBePresent" attribute is "false" or missing, then the result
of the Match element is "False" when the AttributeDesignator
value can not be obtained.
DISCUSSION:
[Polar Humenn] I think we should just stop at your re-wording at
> The target value SHALL be "Match" if the subject, resource and
> action elements specified in the target all match values in the
> request context. The target value SHALL be "No-match" if the
> subject, resource, and action elements specified in the target
> do not match values in the request context.
Here, as you did catch the mix-up between the target and the
request context in the spec.
However, the evaluation to Indeterminate is based upon the
evaluation of the contained Match Elements of which they all
contain their own Indeterminate semantics. So, I think let's
leave it there.
I think we are describing the evaluation of the Target expression
with respect to its elements, not about what its elements
do. That functionality is defined elsewhere, so we don't need to
redefine it here.
How about:
The target value SHALL be "Match" if the subject, resource and
action elements specified in the target result in "true". The
target value SHALL be "No-match" if one of the subject, resource,
or action elements specified in the target results in
"false". The target value ShALL be "Indeterminate" if any of the
subject, resource, or action elements results in "Indeterminate."
Simiarly I think the sentence at the end of Section 7.4
Conditons,
If any attribute value referenced in the condition cannot be
obtained, then the condition SHALL evaluate to "Indeterminate".
should be removed, as this semantics and how it is handled is
defined for every element that retrieves attribute values.
[Anne Anderson, responding to Polar] [approve, agreed]
=========================================================================
0044. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00081.html
Subject: There is no Section describing<SubjectAttributeDesignator>
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Fri, 22 Nov 2002 15:48:16 +0900
There is no section describing <SubjectAttributeDesignator>.
As a result, although the term "present" is defined for other attribute
designators (action, resource, environment),
there is no definition of "present" for subject attribute designator.
Is this okay?
CATEGORY: Incomplete.
SEE ALSO: #22
STATUS: Discussed 11/25/02.
RESPONSE: Rename 5.30 "Complex type
SubjectAttributeDesignatorType" to "Element
<SubjectAttributeDesignator>". Re-word this section so that
it provides information in a format consistent with the
descriptions of ResourceAttributeDesignator,
ActionAttributeDesignator, and EnvironmentAttributeDesignator.
ACTION ITEM: #44. [Simon Godik] compare 5.30 with 5.27-29 and propose
consistent wording.
ACTIONS:
=========================================================================
0045. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00082.html
Subject: "type" in Line 3503 in the pdf file is broken
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Fri, 22 Nov 2002 16:04:03 +0900
"type" in Line 3503 in the pdf file is broken:
http://www.oasis-open.org/committees/xacml/repository/cs-xacml-core-01.pdf
CATEGORY: Editorial.
STATUS: Resolved 11/25/02.
RESPONSE: Accepted.
ACTIONS: Bill should fix pdf:3503 in the next release of the spec.
=========================================================================
0046. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00084.html
Subject: "Not Match" or "No-match" (Tables 1, 2, and 3)
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Fri, 22 Nov 2002 18:21:35 +0900
"Not Match" should be "No-match" in Table 1, 2, and 3.
CATEGORY: Inconsistent.
STATUS: Resolved 11/25/02.
RESPONSE: Accepted. Change "Not Match" to "No-match" in Tables
1, 2, and 3.
ACTIONS: Change "not match" and 'not "match"' in Tables 1,2 and
3 of sections 7.5, 7.6, 7.7 to say "No-match"
=========================================================================
0047. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00085.html
Subject: policy and rule ordering
From: Paul Andrews <paandrew@cisco.com>
Date: Fri, 22 Nov 2002 10:09:29 -0500
I have an observation to make regarding the order of evaluation
of policies and rules within a policy set:
The order is only defined for one rule combining algorithm,
however if individual policies within a policy set had
obligations associated with them it is possible (likely even)
that the obligations should be executed in a specific order.
CATEGORY: Incorrect.
STATUS: Resolved 11/25/02.
RESPONSE: This is as intended. There is a trade-off between
consistency of obligations and efficiency of handling distributed
policies. For example, you may have cached the 5th policy in the
PolicySet, so it is faster to evaluate than the 2nd policy. An
application that wishes to specify the order of evaluation is
free to define a new combining algorithm using the XACML
extensibility mechanisms.
ACTIONS: No change.
=========================================================================
0048. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00086.html
Subject: Resource types
From: Paul Andrews <paandrew@cisco.com>
Date: Fri, 22 Nov 2002 10:28:59 -0500
I note that the set of types allowed in a 'resource' element is
restricted, as is the match criteria. Given the nature of my
employers business I would like to be able to use types and match
criteria that have not been defined. My reading of the
spec. shows that the accepted answer to that is to move the
resource specification to a 'condition' element instead, but that
simply begs the question of why a 'resource' element exists in
the first place if a 'condition' element can achieve the exact
same thing (or conversely, if a condition element can be
extended, then why not a 'resource' element).
I understand the desire to facilitate indexing, however moving a
resource match to a condition makes it difficult, i fnot
impossible, to deduce the role played by the arguments to the
condition. This in turn makes it hard to automatically translate
the XACML representation of a policy into a different
representation (as might be necessary if the actual access
control were being performed by a legacy system).
CATEGORY: Alternative.
STATUS: Discussed 11/25/02.
RESPONSE: Accepted in general. Change A.12 [again] to allow
non-standard functions and datatypes, so long as they return
boolean and accept AttributeDesignator as first arg and
AttributeValue as second.
ACTION ITEM: [Anne] reword. DONE:
http://lists.oasis-open.org/archives/xacml/200211/msg00170.html
ACTIONS:
DISCUSSION:
[Anne Anderson responding to Polar Humenn]
> First of all of the text need not be changed. I find it troublying that
> many things got changed here. Furthermore, there are no change bars, so
> I'm having difficulty seeing all that was changed in your proposed text.
>
> I think the only thing that is sought after here to address this issue is
> the relaxation of the functions that can be used for MatchId, which would
> mean merely removing the restrictions. That can easily be done by removing
> the following lines:
>
> 3497-3503 starting with "The XACML standard functions ...."
>
> And removing the last paragraphs after the last example in that section,
> lines:
>
> 3531-3542 starting with "For the match elements...".
My guess is that you are comparing this rewording to the current
text in the 1.0 specification. We had already agreed to change
the wording in response to Comments#5 and #12. That wording is
attached to
http://lists.oasis-open.org/archives/xacml/200211/msg00157.html
The changes I to that already approved re-wording are only:
1. Removed "standard XACML" from following sentence:
The MatchId attribute SHALL specify a function that compares two
^removed: standard XACML
2. Changed paragraph following the list of XACML standard
functions that may be used from:
Functions that are strictly within an extension to XACML SHALL
NOT appear as a value for the MatchId attribute. Restricting the
MatchId attribute to XACML standard functions facilitates the use
of indexing to find the applicable policy for a particular
authorization request.
Changed to:
Functions that are strictly within an extension to XACML MAY
appear as a value for the MatchId attribute, and those functions
MAY use data types that are also extensions. The function used
as the value for the MatchId attribute SHOULD be easily
indexable. Use of non-indexable or complex functions may prevent
efficient evaluation of authorization decision requests.
3. Added to the very end of the section, in response to your
comment yesterday that you did not want the example of how to
state a Match function as an equivalent Apply function to be
taken as normative:
This expression of the semantics is NOT normative.
Do you still have objections?
[Polar Humenn] I guess my only objection is that the paragraph
stating what a Matching element actually is, has been removed
completely, and replaced with an anontomical description of its
structure. The other thing that puzzles me is the term
"authorization request attribute".
I would like the following sentence put back (modified for
erudicating "EnvironmentMatch") underneath the bulleted list:
These elements represent boolean expressions over attributes of
the subject, resource, action, respectively.
Then tack the anatomical description onto that, but fix it to
mention the value so we have:
These matching elements represent boolean expressions over attributes of
the subject, resource, action, respectively. A matching element contains a
MatchId attribute that specifies the fucntion to be used in pergorming the
match evaluation, an <AttributeDesignator> or <AttributeSelector> elements
that specifies an authorization request attribute, and an attribute value
that SHALL match the value of the specified authorization request
^^^^^ ^^^^^^^^^^^^
attribute.
Q: Do we have "authorization request attribute" defined?
Also, if are now allowing *any* binary boolean function to be
used, we should probably get rid of the paragraph that lists the
XACML standard functions that may be used an a MatchId attribute
value.
=========================================================================
0049. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00093.html
Subject: C.4 "Only-one-applicable" inconsistent with B.10"only-one-applicable-policy"
From: Anne Anderson <Anne.Anderson@Sun.com>
Date: Fri, 22 Nov 2002 13:57:45 -0500 (EST)
Appendix C.4 describes the "Only-one-applicable" policy combining
algorithm. Section B.10 uses the identifier
"urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:only-one-applicable-policy"
This is confusing, if not inconsistent.
I recommend that the identifier be changed to
"urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:only-one-applicable"
since the "policy-combining-algorithm" portion of the name
indicates that it applies to policies.
CATEGORY: Inconsistent.
STATUS: Resolved 11/25/02.
RESPONSE: Accepted.
ACTIONS: Change B.10 to use the identifier
"urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:only-one-applicable"
=========================================================================
0050. http://lists.oasis-open.org/archives/xacml/200211/msg00156.html
Subject: error conditions
From: bill parducci <bill.parducci@overxeer.com>
Date: Fri, 22 Nov 2002 10:37:15 -0800
I think that there is some inconsistency with error condition
responses of the PDP as communicated to the PEP.
In some cases a decision of INDETERMINATE is returned without an
accompanying status code (pdf:4502, 4605, 4664, 4799), while in
others a status code is required (pdf:4715, 4755).
I think that it is important that error conditions REQUIRE a
status code in all circumstances so that the PEP is aware that
the decision is a result of an error and not insufficient
inputs. In practical terms this would allow the PEP to decide if
retrying the request has merit, as well as provide important
operational information. This requires that status codes be
required in all cases (at least that seems like it would be the
case).
Under that assumption, here are the changes I think are necessary
to accomplish this:
Add the text from line pdf:4176, "...shall evaluate to
"Indeterminate", with the appropriate error status," to lines
pdf:4502, 4605, 4664 and 4799s.
Change pdf:2696 (and schema) to read: "<xs:element
ref="xacml-context:Status" minOccurs="1"/>"
Change pdf:2696 (and schema) to read: "<xs:element
ref="xacml-context:Status" minOccurs="0"/>"
Change pdf:2709 to read: "<Status> [Required]"
Change pdf:2760 to read: "<xs:element
ref="xacml-context:StatusCode" minOccurs="1"/>"
Change pdf:2760 to read: "xacml:Context:Status M"
Change pdf:2760 to read: "xacml:Context:StatusCode M"
I would like to propose that this be adopted by the spec. If the
group doesn't agree then lines pdf:4715 and 4755 need to be
updated to reflect this.
CATEGORY: Inconsistent.
STATUS: Resolved 11/25/02.
RESPONSE: Accepted.
ACTIONS: Make changes suggested except
change pdf:2696 (and schema) to read: "<xs:element
ref="xacml-context:Status" minOccurs="1"/>"
=========================================================================
0051. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00096.html
Subject: C003 and matching in targets and conditions
From: John Merrells <merrells@jiffysoftware.com>
Date: Fri, 22 Nov 2002 18:35:34 -0800
It's suddenly dawned on me that the signature of the match functions
is supposed to differ between targets and conditions. In a condition
it's (primitive, primitive) and in a target it's (primitive,
bag<primitive>).
Is this intentional? It seems like a mistake to me. It'd be much simpler
for everyone if the signature wasn't dependent upon the
context...
CATEGORY: Inconsistent.
STATUS: Resolved 11/25/02.
RESPONSE: This works as intended. A.12 specifies this behavior.
The intention is to make Targets simpler. Actual function signatures
do not differ: <Target> elements are not passed directly to the funtions.
ACTIONS: None.
Polar Humenn responded on 25 Nov 2002 to John Merrells and to
xacml-comment as follows:
It is not a mistake. The *Match constructs take the match
function and apply it between each element in the bag and the
explicit value.
Currently, the equivalent expression to a Match element that
would appear in the condition as:
( any-of matchId-function primitive bag<primitive> ).
==========================================================================
0052. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00097.html
Subject: 5.31 Element <AttributeSelector>
From: John Merrells <merrells@jiffysoftware.com>
Date: Sun, 24 Nov 2002 17:54:08 -0800
------------------------------------------------------------------------
0052a. "The AttributeSelector element's RequestContextPath XML
attribute SHALL contain a legal XPath expression over the
<xacml-context:Request> element."
The phrase 'over the' made me think for a while. This could be
made clearer by using the 'context node' term from the XPath
specification. XPath evaluation occurs with respect to a context
node, the context node for this XPath expression is the
<xacml-context:Request> element.
CATEGORY: Unclear.
STATUS: Discussed 11/25/02.
RESPONSE:
ACTION ITEM: 52a. [Michiharu Kudo] Need Michiharu's opinion as an
XPath expert.
ACTIONS:
------------------------------------------------------------------------
0052b. "In the case where the XPath expression matches attributes in
the request context by AttributeId, it must also match the
attribute's data-type with the selector's DataType."
Does the 'it' above mean the XPath expression? So, it's saying
that if you write an xpath expression to select an attribute from
the context, and the expression includes a predicate for matching
with an AttributeID, then that expression MUST also include a
predicate that matches the selectors data type with the data type
of the selected attribute...?
CATEGORY: Unclear.
STATUS: Discussed 11/25/02.
RESPONSE:
ACTION ITEM: 52b. [Michiharu Kudo] Need Michiharu's opinion as an
XPath expert.
ACTIONS:
------------------------------------------------------------------------
0052c. "In the case of using XPath 1.0, the value of the XPath
expression is either a node-set, string value, numeric value, or
boolean value."
This may seem a quibble, and it probably is, but even though the
XPath specification says that the result of an expression can be
a primitive... I do not believe there's any way to form an
expression that actually returns one. In my experience all XPath
1.0 expressions return a node-set. (I'd be very interested to be
corrected on this point. I just looked in the o'reilly xpath book
and it has some examples that are plain literal values like,
2002, or "hello", but if you follow the grammar of the language
they're just not valid expressions.)
CATEGORY: Unclear.
STATUS: Discussed 11/25/02.
RESPONSE:
ACTION ITEM: 52c. [Michiharu Kudo] Need Michiharu's opinion as an
XPath expert.
ACTIONS:
------------------------------------------------------------------------
0052d. "If the XPath 1.0 expression evaluates to a node-set, then
each node may consist of a string, numeric or boolean value, or a
child node (i.e. structured node). In this case, each node is
logically converted to string data by applying the "string"
function defined in the XPath 1.0 specification, resulting in a
sequence of string data."
This is correct in spirit, but not actually correct.
In XPath 1.0 an expression evaluates to a node-set. There are
seven kinds of node (root, element, text, attribute, namespace,
processing instruction, and comment). The XPath specification
describes a way of determining a <b>string-value</b> for each
type of node.
CATEGORY: Unclear.
STATUS: Discussed 11/25/02.
RESPONSE:
ACTION ITEM: 52d. [Michiharu Kudo] Need Michiharu's opinion as an
XPath expert.
ACTIONS:
==========================================================================
0053. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00099.html
Subject: XQO
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Mon, 25 Nov 2002 13:22:24 +0900
[XQO] is used in several places. E.g., see the description of
"anyURI-equal" in Appendix A.14.1. I think this is a reference.
If yes, it should be added to Section 11.
CATEGORY: Incomplete.
STATUS: Resolved 11/25/02.
RESPONSE: Accepted.
ACTIONS: Add to references in Section 11 the following:
[XQO] XQuery 1.0 and XPath 2.0 Functions and Operators, W3C
Working Draft 15 November 2002,
http://www.w3.org/TR/2002/WD-xquery-operators-20021115/
==========================================================================
0054. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00100.html
Subject: The URI prefix for subject categories
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Mon, 25 Nov 2002 15:50:58 +0900
Two comments on the URI prefix for subject categories.
------------------------------------------------------------------------
0054a. Section 4.2.2 uses a wrong prefix
urn:oasis:names:tc:xacml:1.0:subject:category
CATEGORY: Incorrect.
STATUS: Resolved 11/25/02
RESPONSE: Accepted.
ACTIONS: In Section 4.2.2, change
"urn:oasis:names:tc:xacml:1.0:subject:category" to
"urn:oasis:names:tc:xacml:1.0:subject:subject-category". This
change may be moot if #39 is accepted, however.
------------------------------------------------------------------------
0054b. I wonder if the URI prefix is added to Section 10.3.2.
CATEGORY: Incomplete.
STATUS: Resolved 11/25/02.
RESPONSE: Accepted
ACTIONS: Add "urn:oasis:names:tc:xacml:1.0:subject" to Identifier
Prefixes defined in table in 10.3.2. This change may be moot if
#39 is accepted, however.
==========================================================================
0055. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00101.html
Subject: Conventional XML namespace prefixes
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Mon, 25 Nov 2002 16:26:29 +0900
Section 1.2 summarizes the conventional XML namespace prefixes.
The two prefixes "xacml" and "xacml-context" should be added to
the convention.
These two prefixes are used many times, but it seems to me no
definition is given in the specification document. Of course,
they are defined in the (complete) schema files. However, it's
better to add them to Section 1.2 for readability.
Also, xmlns:xacml=... can be removed from the request context
example in Section 4.2.2 because the "xacml" prefix is not used
in it.
CATEGORY: Unclear.
STATUS: Resolved 11/25/02
RESPONSE: Accepted.
ACTIONS:
Add the following lines to the namespaces listed in 1.2 Notation:
o The prefix "xacml" stands for the XACML policy namespace.
o The prefix "xacml-context" stands for the XACML context
namespace.
Remove xmlns:xacml= line from Section 4.2.2 Example request
context, example line [03], pdf:926.
==========================================================================
0056. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00102.html
Subject: Section 10.3.1
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Mon, 25 Nov 2002 16:28:15 +0900
A comment on the table in Sect. 10.3.1.
The notational convention of element names is not standard (probably the
syntax is not defined anywhere).
How about using the qnames?
For example,
xacml:Context:Action can be xacml-context:Action.
xacml:Policy:Policy can be xacml:Policy
CATEGORY: Alternative.
STATUS: Resolved 11/25/02.
RESPONSE: Accepted. Use QNames in Section 10.3.1.
ACTIONS: In the table in Section 10.3.1, change "xacml:Context:"
to "xacml-context:". Change "xacml:Policy:" to "xacml:".
==========================================================================
0057. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00104.html
Subject: Making MatchId and FunctionId argument order the same
From: Anne Anderson <Anne.Anderson@Sun.com>
Date: Mon, 25 Nov 2002 09:16:35 -0500 (EST)
I have identified the exact changes required in order for us to
make the arguments to a MatchId function appear in the same order
as the arguments to a FunctionId function. I believe they are
not nearly so extensive as we thought, and that we should make
this change. Otherwise, we will have to live with this major,
confusing inconsistency forever.
In general:
a. Redefine the -match functions such that the template is the
second argument and the explicit value is the first argument.
a. rfc822Name-match
b. x500Name-match
c. regexp-string-match [rename to string-regexp match]
d. xpath-node-match
b. Specify that Match element arguments are passed to the MatchId
function in the same order in which they appear in the Match
element.
c. NO changes are required in the schema.
d. NO changes are required in the examples, as -match functions
appear only in example <Target> elements, where they are
already in the new, correct order.
Specific changes required:
A.12.Matching elements
1. Change pdf:3538-3543 (but from new A.12 Matching elements
version) from:
The attribute value specified in the matching element SHALL be
supplied to the MatchId function as its first argument. An
element of the bag returned by the <AttributeDesignator> or
<AttributeSelector> element SHALL be supplied to the MatchId
function as its second argument1. The datatype of the
<AttributeDesignator> or <AttributeSelector> element SHALL
match the datatype of the second argument expected by the
MatchId function. The datatype of the attribute value SHALL
match the datatype of the first argument expected by the
MatchId function.
to:
An element of the bag returned by the <AttributeDesignator> or
<AttributeSelector> element SHALL be supplied to the MatchId
function as its first argument1. The attribute value
specified in the matching element SHALL be supplied to the
MatchId function as its second argument. The datatype of the
<AttributeDesignator> or <AttributeSelector> element SHALL
match the datatype of the first argument expected by the
MatchId function. The datatype of the attribute value SHALL
match the datatype of the secondy argument expected by the
MatchId function.
2. Change pdf:3508-3510 (but in new Appendix A.12 version) from:
Otherwise, the MatchId function SHALL be applied between the
explicit attribute value and each element of the bag returned
from the <AttributeDesignator> or <AttributeSelector> element.
to:
Otherwise, the MatchId function SHALL be applied between each
element of the bag returned yfrom the <AttributeDesignator> or
<AttributeSelector> element and the explicit attribute value.
3. Remove footnote from new version of Appendix A.12
4. Replace pdf:3526-3529 (but in new Appendix A.12 version) from:
<Function
FunctionId="urn:oasis:names:tc:xacml:1.0:function:regexp-string-match"/>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string";;>John.*</AttributeValue>
<SubjectAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string"/>
to:
<Function
FunctionId="urn:oasis:names:tc:xacml:1.0:function:regexp-string-match"/>
<SubjectAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string"/>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string";;>John.*</AttributeValue>
A.14.12 Special match functions
5. Redefine regexp-string-match: Change pdf:4250-4253 from
The first argument SHALL be a regular expression and the
second argument SHALL be a general string. The function
specification SHALL be that of the "xf:match" function with
the arguments reversed [XF Section 6.3.15.1].
to:
The first argument SHALL be a general string and the
second argument SHALL be a regular expression. The function
specification SHALL be that of the "xf:match" function [XF
Section 6.3.15.1].
6. Redefine x500Name-match: Change pdf:4256-4258 from:
It shall return "True" if and only if some terminal sequence
of RDNs from the first argument matches the second argument
when compared using x500Name-equal.
7. Redefine rfc822Name-match: Change pdf:4260-4282 to:
This function SHALL evaluate to "True" if the first argument
matches the second argument according to the following
specification.
An RFC822 name consists of a local-part followed by "@"
followed by domain-part. The local-part is case-sensitive,
while the domain-part (which is usually a DNS name) is not
case-sensitive.1
This function SHALL take two arguments, the first is of type
"urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name" and the
second is of type "http://www.w3.org/2001/XMLSchema#string";;
and SHALL return an
"http://www.w3.org/2001/XMLSchema#boolean";;. The first
argument contains a complete rfc822Name. The second argument
is a complete or partial rfc822Name used to select appropriate
values in the first argument as follows.
In order to match a particular mailbox in the first argument,
the second argument must specify the complete mail address to
be matched. For example, if the second argument is
"Anderson@sun.com", this matches a value in the first argument
of "Anderson@sun.com" and "Anderson@SUN.COM", but not
"Anne.Anderson@sun.com", "anderson@sun.com" or
"Anderson@east.sun.com".
In order to match any mail address at a particular domain in
the first argument, the second argument must specify only a
domain name (usually a DNS name). For example, if the second
argument is "sun.com", this matches a value in the first
argument of "Anderson@sun.com? or "Baxter@SUN.COM", but not
"Anderson@east.sun.com".
In order to match any mail address in a particular domain in
the first argument, the second argument must specify the
desired domain-part with a leading ".". For example, if the
second argument is ".east.sun.com", this matches a value in
the first argument of "Anderson@east.sun.com" and
"anne.anderson@ISRG.EAST.SUN.COM" but not "Anderson@sun.com".
8. Change A.14.13 pdf:4303-4313 from:
xpath-node-match
This function SHALL take two
"http://www.w3.org/2001/XMLSchema#string";; arguments, which
SHALL be interpreted as XPath expressions and SHALL return an
"http://www.w3.org/2001/XMLSchema#boolean";;. This function
SHALL first extend the first argument to match an XML document
in a hierarchical fashion. If a is an XPath expression and it
is specified as the first argument, it SHALL be interpreted to
mean match the set of nodes specified by the enhanced XPath
expression "a | a//* | a//@*". In other words, the expression
a SHALL match all elements and attributes below the element
specified by a. This function SHALL evaluate to "True" if any
XML node that matches the enhanced XPath expression is equal
according to "op:node-equal" [XQO] to any XML node from the
node-set matched by the second argument.
to:
xpath-node-match
This function SHALL take two
"http://www.w3.org/2001/XMLSchema#string";; arguments, which
SHALL be interpreted as XPath expressions and SHALL return an
"http://www.w3.org/2001/XMLSchema#boolean";;. This function
SHALL first extend the second argument to match an XML document
in a hierarchical fashion. If 'a' is an XPath expression and it
is specified as the second argument, it SHALL be interpreted to
mean match the set of nodes specified by the enhanced XPath
expression "a | a//* | a//@*". In other words, the expression
a SHALL match all elements and attributes below the element
specified by 'a'. This function SHALL evaluate to "True" if any
XML node that matches the enhanced XPath expression is equal
according to "op:node-equal" [XQO] to any XML node from the
node-set matched by the first argument.
9. Throughout the specification, change "regexp-string-match" to
"string-regexp-match"
10. Many conformance tests will need to be changed, as they often
use -match functions in Apply elements. I can make these in
one day, however, and I believe the effort is justified.
CATEGORY: Unclear.
STATUS: Resolved 11/25/02.
RESPONSE: Rejected. Please re-submit this comment with a proposal
to change the order of the elements in a <Target> Match.
ACTIONS: None.
DISCUSSION:
[Polar]If we change order of functions in match, then breaks
any-of, all-of, etc. For example, any-of takes
function
value - explicit
bag of values
If instead of changing order of args for a -match function, we
change Target element order so that explicit value comes first,
then everything works.
This also flows better: function is asking for a match of the
explicit value against one of the bag values.
With this approach, however, more examples will have to change.
With this approach, schema change is required.
The group agreed that this approach was better than Anne's
suggested approached if a change is to be made.
This needs a vote soon, since it affects implementations.
==========================================================================
0057. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00096.html
Subject: Making MatchId and FunctionId arg order the same
From: John Merrells <merrells@jiffysoftware.com>
Date: Mon, 25 Nov 2002 14:46:29 -0800
[I am creating this new comment to represent the still-open issue
of whether XACML will change the specification to make the
MatchId and FunctionId argument order the same, or otherwise
change the specification to make the difference in order less
confusing. -Anne Anderson]
CATEGORY: Unclear.
STATUS: Initial change proposal in #0056 rejected.
SEE ALSO: #51,56
RESPONSE:
ACTIONS:
DISCUSSION:
[John Merrells] Firstly, this [current differing order] needs to
be very clearly pointed ont in the specification. I've read the
spec maybe six times in the past three months and I only just
noticed that the signatures differed in the specifications. [I
was probably blinded by the natural assumption that the signature
would not depend upon the context of the expression. I can't
think of another language that does this.]
Secondly, this is definitely going to catch users out who have to
write this stuff. They'll happily cut an expression from a
condition and paste it into a target, or vis-versa, and get
upset. They'll be screwed unless they hack out, or in, the calls
to 'only-one-of'.
Wouldn't it be simpler for everyone to just make the signature
the same in both places?
You've got polymorphism based on the context of the call. How
about adopting the more usual approach of basing the polymorphism
on the type of the arguments? If I pass a primitive and a bag it
does the match thing, if I pass a primitive and a primitive it
compares them.
Or, how about using two different names to reflect the fact there
are two different behaviours... string-equal, string-match,
double-match, double-equal, ...
I think that polymorphism on argument type is the best approach,
then changing the condition signature to be the same as the
target signature, and then finally having different names for the
behaviours.
[Polar Humenn] I agree that in Section A.12 Match Elements we can
put a _non-normative_ statement that says that the equivalent
expression of a match element in the terms of higher order
functions and reference that section. I say _non-normative
because I want to preclude this definition as being the
implemenation of the particular match element. For example, when
the match element appears in the target it may be a specification
of some complicated indexing function over possibly predetermined
values of a specific attribute type.
> I've read the spec maybe six times in the past three months and I only
> just noticed that the signatures differed in the specifications. [I was
> probably blinded by the natural assumption that the signature would not
> depend upon the context of the expression. I can't think of another
> language that does this.]
I don't know what you mean here. The signature of the Match
element is not the same as the signature of the function USED
WITHIN the element.
As for the signature depending on the type of the context of the
expression, is standard type theory. Lots of languages as far
back as C, Fortran, take advantage of such things. For example,
the function, "+" in almost any language can be "integer-add" or
"double-add", or even "boolean-or", depending on the type of the
variables or constants used in the expression.
> Secondly, this is definitely going to catch users out who have
> to write this stuff. They'll happily cut an expression from a
> condition and paste it into a target, or vis-versa, and get
> upset. They'll be screwed unless they hack out, or in, the
> calls to 'only-one-of'.
>
> Wouldn't it be simpler for everyone to just make the signature
> the same in both places?
True, and I think we are going to rearrange the schema so that
the explicit value comes first and the designator second. That
will give some consistency between "any-of" and the match
elements. However, it is not an easy cut-paste job, as "any-of"
appears in a <Apply> statement with <Function> and the Match
element almost stands on its owwn.
Also, you can use the Match Elements in both the Condition and
the Target.
> You've got polymorphism based on the context of the call. How
> about adopting the more usual approach of basing the
> polymorphism on the type of the arguments? If I pass a
> primitive and a bag it does the match thing, if I pass a
> primitive and a primitive it compares them.
That is not true. The polymorphism is based on the types of the
arguments, not the context of the call. The Designator or
arguments all have explicit data types, and that instantiates the
type signature of the Match element or the application of the
"any-of" function.
What you are asking for is a type generalization in an ad-hoc
manner, which requires a runtime check to see what the type of
the argument is at evaluation time. Having it the way we have it,
you force the expression to be type correct, which precludes the
need for a runtime check of the argument's type. That it one of
the major benefits of type checking.
> Or, how about using two different names to reflect the fact
> there are two different behaviours... string-equal,
> string-match, double-match, double-equal, ...
I'm missing something in this comment. Two different names for
different behaviors? You mean for the match elements?
> I think that polymorphism on argument type is the best
> approach, then changing the condition signature to be the same
> as the target signature, and then finally having different
> names for the behaviours.
Forgive me, I am definitely missing something here. The Match
element signature should be the same in both the Target and the
Condition. We just make a statement that if the Match element
ends up in the Target that it was restricted to those functions
that are easily used for indexing, (but I think we are going to
relax that condition).
[John Merrells] I think I must have missed something basic here
then. This is my reading of the spec...
A12 says that type-equal is a match function, and that the
arguments of a match function are <T,bag<T>> : Boolean. A14.1
then says that the arguments for the type-equal functions are
<T,T> : Boolean.
I took this to mean that within a <XxxxMatch> element that the
signature was to be enforced as the former type, and everywhere
else, ie within a condition, that it was to be enforced as the
later. Is this a correct interpretation.
>As for the signature depending on the type of the context of the
>expression, is standard type theory. Lots of languages as far
>back as C, Fortran, take advantage of such things. For example,
>the function, "+" in almost any language can be "integer-add" or
>"double-add", or even "boolean-or", depending on the type of the
>variables or constants used in the expression.
>
I'm saying the same thing. This is how I'd like xacml to work. My
reading suggests that the signature is not based on the types
passed but on the identity of the call site. In C, or whatever,
this would be like saying there's a function foo that can be
called from either functions bar or baz, but when calling from
baz you have to pass an int and when calling from baz you have to
pass a double, and if you try to call the wrong one that's a
compile time type error.
>What you are asking for is a type generalization in an ad-hoc
>manner, which requires a runtime check to see what the type of
>the argument is at evaluation time. Having it the way we have
>it, you force the expression to be type correct, which precludes
>the need for a runtime check of the argument's type. That it one
>of the major benefits of type checking.
>
Nope, I'm glad xacml expressions are strongly typed.
==========================================================================
0058. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00122.html
Subject: syntactic errors in XACML schemas
* From: "DuCharme, Bob (LNG-EWR)" <bob.ducharme@lexisnexis.com>
* To: "'xacml-comment@lists.oasis-open.org'" <xacml-comment@lists.oasis-open.org>
* Date: Tue, 26 Nov 2002 13:54:28 -0500
Each of the two schemas available on
http://www.oasis-open.org/committees/xacml/ has an error that prevents it
being parsed.
cs-xacml-schema-policy-01.xsd: the Xerces Java error message shows that
because the AttributeAssignmentType complex type is a derived type, it must
be declared as mixed or element-only, depending on whether its base type is
mixed or element-only. Because AttributeValueType, the base type, has
mixed="true" in its declaration, I added this to the declaration for
AttributeAssignmentType and Xerces now parses it without a problem. Is this
the fix that people should assume is in place when actually using XACML?
cs-xacml-schema-context-01.xsd just has a typo: the "-1.0" in the import
statement near the beginning should read "-01" if it's going to read the
cs-xacml-schema-policy-01.xsd file mentioned above, which it needs to do.
CATEGORY: Incorrect.
STATUS: Duplicates
SEE ALSO: Same as #41 and #42
RESPONSE: Use "mixed" in schema; use -01 in import statement.
ACTIONS: See #41 and #42
==========================================================================
0059. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00129.html
Subject: XACML questions ...
From: Gene Thurston [mailto:gthurston@amberpoint.com]
Sent: Wednesday, November 20, 2002 8:21 PM
I was working with the latest XACML draft, and I had a few
questions, mostly around the optional XPath capability outlined
in it:
------------------------------------------------------------------------
0059a. Why is there no <EnvironmentMatch>, similar to
<SubjectMatch>, <ResourceMatch>, and <ActionMatch>?
CATEGORY: Inconsistent
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
------------------------------------------------------------------------
0059b. When used inside a <SubjectMatch> element, is the XPath
expression found in the <AttributeSelector> evaluated over the
entire context document, or just over the <Subjects> sub-tree?
CATEGORY: Unclear.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
------------------------------------------------------------------------
0059c. Same question for <ResourceMatch> and <ActionMatch>?
CATEGORY: Unclear.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
------------------------------------------------------------------------
0059d. If the answer to the above is that the XPath expressions
are always evaluated over the entire context document, then what
are the semantics if such an expression inside, say, a
<SubjectMatch> element evaluates to something outside the
<Subjects> sub-tree? Is this just, "OK" (as I suspect), or is
there supposed to be something special about the fact that it was
inside a <SubjectMatch> so we shouldn?t match anything outside
the subject?s attributes?
CATEGORY: Unclear.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
------------------------------------------------------------------------
0059e. If it is "OK", then there is no difference between
<SubjectMatch>, <ResourceMatch>, or <ActionMatch>, and perhaps
there should be a generic <AttributeSelectorMatch> or something
similar?
CATEGORY: Inconsistent
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
DISCUSSION:
[Tim Moses, responding to Gene directly] I'll pass your questions
on to the XACML comment list, in order to ensure that they get
recorded and addressed, and that any lack of clarity is
corrected.
Basically, attributes of subjects, resources and actions (but not
environment) may appear in a policy's target. A policy is
applicable to a request if at least one of its subject matches is
true AND at least one of its resource matches is true AND at
least on of its action matches is true. AttributeSelector may be
used in any of these match types. In the case of a subject
match, for instance, the "context" node for the XPath expression
is xacml-context/Subject. And similarly for the other types. On
the other hand, AttributeSelector may also be used in an Apply
element to define an argument to an expression. In this case,
the "context" node for the XPath expression is the whole
xacml:context. So, it can select any attribute of any entity
(subject, resource, action or environment), but it has to
explicitly indicate which type of entity is intended.
[John Merrells, responding to Tim Moses]
> AttributeSelector may be used in any of these match types. In the
> case of a subject match, for instance, the "context" node for the
> XPath expression is xacml-context/Subject. And similarly for the
> other types.
Whoa... the spec doesn't say that. The spec says that for an
AttributeSelector the context
node for the evaluation of the XPath expression is the Request
element... !?!
==========================================================================
0060. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00138.html
Subject: A002
From: John Merrells <merrells@jiffysoftware.com>
Date: Tue, 26 Nov 2002 19:58:52 -0800
Which part of the specification is this test testing? I read 7.9.2, but it
says that if the PDP can't find an attribute in the context then it's to
return Indeterminate. Also, in Figure 1 the PDP is shown reading
policies from a PAP and returning responces to the context handler,
but not retrieving attributes from anywhere.
CATEGORY: Unclear.
STATUS: Not yet discussed.
SEE ALSO:
RESPONSE:
ACTIONS:
DISCUSSION:
[Anne Anderson]
[For those not running the Conformance Tests, test A002 requires the
system to retrieve an attribute value that is not supplied in the
original XACML Request from the PEP. The instructions for the test are
deliberately places no requirements on which attribute it is, where it
is retrieved from, how it is retrieved, etc.]
The intent of test A002 is to exercise one of the primary advantages of
XACML: the ability to have the PDP side of the system obtain attributes
that are not necessarily supplied by the PEP. Section 7.9.2 covers this,
although we were so careful not to specify a particular implementation
that perhaps we were not specific enough.
It is the "context handler" that is responsible for supplying attribute
values, and it is the existence of a context handler that is independent
of any physical XML Request document that is being tested in A002. If
we do not have a test of this kind, implementors can limit their
capabilities to parsing an XML Request document using standard XML tools
and retrieving attributes from that. We have specifically stated that
the Context is NOT to be considered as a physical XML document (although
it is certainly based on some sort of document received from the PDP),
and that attribute values are obtained from the context handler.
I am posting this to the XACML list for discussion. Do we want to require
the functionality required by Conformance Test A002?
[John Merrells, responding to Anne Anderson]
The test special instructions state that it is the PDP that is
responsible for fetching the attribute, but your comments above
suggests that it is the responsibiliy of the context handler to
fetch the attribute and supply it to the PDP.
But, how does a context handler know which attributes are going
to be needed by the PDP... it'd have to either send everything it
has access to in the PIP... or do what the PDP would do in order
to find out what the PDP is going to need.
So, therefore only the PDP knows which attributes are not
available to it within the request context, so it must issue the
request for the attribute, but the spec (7.9.2) specifically says
that in this case the PDP returns Indeterminate.
Does anyone have a PDP that passes A002?
[Anne Anderson, responding to John Merrells]
>The test special instructions state that it is the PDP that is
>responsible for fetching the attribute, but your comments above
>suggests that it is the responsibiliy of the context handler to
>fetch the attribute and supply it to the PDP.
I should be more precise in my test special instructions. I was
treating the "PDP" as the entire "PDP side" of the access control
system, including the Context Handler.
In 7.9.2, the PDP is the XACML Evaluation Engine. The "PDP side"
of an access control system will necessarily have other
functional components:
o for receiving, possibly translating, and parsing requests from the PEP,
o for fetching policies from repositories,
o for fetching attributes from the Request Context and from repositories,
o for constructing and possibly translating a Response into the PEP's format,
o for transmitting the Response back to the PEP
o for logging actions
o ...
We have not named the functional component that retrieves
policies from external repositories or on-line PAPs, but such a
component is implied by the semantics of the PolicyIdReference
and PolicySetIdReference elements.
In our model, the Context Handler is the functional component
that handles any translation between the PEP's request format and
an internal representation consistent with a Request Context,
fetches attributes from the Request Context (or from an internal
representation consistent with a Request Context) and from
repositories, and handles any translation of the Response into
the PEP's expected format.
The "signature" of the interface between the PDP and the Context
Handler module has two inputs: an AttributeDescriptor or
AttributeSelector, and a Boolean "MustBePresent" value. The
output from the Context Handler to the PDP is either a bag of
values or "Indeterminate" (in the case where an empty bag
resulted, but "MustBePresent" is true). "Indeterminate" would
also be returned if there were a network error in attempting to
contact a configured repository, or some other system error.
As the XACML PDP evaluates a policy, it will encounter various
AttributeDescriptors and AttributeSelectors. Each time the PDP
encounters one, it passes the information in that descriptor or
selector to the Context Handler. The Context Handler searches
for a match among the attribute objects it has parsed out of the
Request Context received from the PEP. If the requested
attribute is not there, then the Context Handler queries its
configured attribute sources (LDAP directory, SAML attribute
assertion repository, file of attributes, on-line AA, etc.) for a
matching attribute, passing the AttributeId, Issuer, etc., and
the values of any corresponding subject-id, resource-id, or
action-id attributes (as appropriate to the type of descriptor).
If there is no attribute available from the configured attribute
sources, then the Context Handler returns either an empty bag or
"Indeterminate" to the XACML PDP, depending on the value of the
"MustBePresent" input. If the "MustBePresent" value is true,
then the Context Handler returns "Indeterminate". If the
"MustBePresent" attribute is false, then the Context Handler
returns an empty bag.
In the context of a Condition, the XACML PDP passes the returned
value to the enclosing function. Most, if not all, standard
XACML functions return "Indeterminate" if one of the inputs is
"Indeterminate", but extension functions might not. It is up to
the definition of the function. Similarly, if the resulting
function does not take a bag as its input, but a bag is passed to
it, then standard functions return "Indeterminate", but extension
functions might not.
In the context of a Target, the XACML PDP either passes the
"Indeterminate" result to the enclosing function, or else passes
one element at a time from the bag result to the enclosing
function. Again, the result depends on the definition of the
enclosing MatchId function.
>But, how does a context handler know which attributes are going
>to be needed by the PDP... it'd have to either send everything
>it has access to in the PIP... or do what the PDP would do in
>order to find out what the PDP is going to need.
The XACML PDP queries the Context Handler for an attribute each
time it needs one in the process of evaluating a policy.
>So, therefore only the PDP knows which attributes are not
>available to it within the request context, so it must issue the
>request for the attribute, but the spec (7.9.2) specifically
>says that in this case the PDP returns Indeterminate.
It does not say this. It says the value of the "MustBePresent"
attribute determines whether the result of not finding a
requested attribute is an empty bag of "Indeterminate". The
default is to return an empty bag.
>Does anyone have a PDP that passes A002?
I expect that A002 and the two E tests (which require fetching
policies and policy sets from external sources) will probably be
the most difficult to implement, but the functionality is very
important to achieving the goals of XACML. We wanted Policy
writers to be able to write policies without worrying about who
supplies which attributes, when, and from where. Some attributes
may be supplied by the PEP, but others may need to be retrieved
from external sources by the PDP side of the access control
system. In some systems, attributes will be stored as X.509
Attribute Certificates; in other systems, attributes will be
stored as SAML attribute assertions. In some systems, attributes
will be stored in an LDAP directory; in other systems, attributes
may be stored in a database. In some systems, a PEP is capable
of retrieving attributes, but in others the PEP is a relatively
dumb beast. A given policy should work with all these types of
systems, assuming the Context Handler has been configured
appropriately.
[John Merrells, responding to Anne Anderson]
Thanks for the detailed explanation Anne. This is much clearer to
me now. I'll try to describe below why I was unable to glean
this meaning from the specification.
Anne Anderson - Sun Microsystems wrote:
>In our model, the Context Handler is the functional component
>that handles any translation between the PEP's request format
>and an internal representation consistent with a Request
>Context, fetches attributes from the Request Context (or from an
>internal representation consistent with a Request Context) and
>from repositories, and handles any translation of the Response
>into the PEP's expected format.
This was clear to me. Figure 1 and its description show this well.
>The "signature" of the interface between the PDP and the Context
>Handler module has two inputs: an AttributeDescriptor or
>AttributeSelector,
This was not clear to me. Firstly, figure 1, which I admit is
non-normative, does not show this. It shows the request context
going in (arrow 8) and the response context coming out (arrow
9). It does not show a bunch of calls from the PDP to the CH
requesting attributes.
Reading 7.9.2 again I see that it is actually saying this, I just
didn't get it:
"The PDP SHALL request the values of attributes in the request
context from the context handler."
I took 'request context' to mean the thing that is passed from
the CH to the PDP... in other words the Request element. Perhaps
'request context' should be explictly defined in the document to
be all attributes within the system, whether within or outside
the Request? 'context handler' could also be capitalized.
eg. "The PDP SHALL request attribute values from the Context
Handler."
The following assertion in 7.9.2 also caused me problems...
"The PDP SHALL reference the attributes as if they were in a
physical request context document, but the context handler is
responsible for obtaining and supplying the requested values."
What does that mean? The phrase 'the attributes' should probably
be 'attributes', and the 'but' clause is a repeat of the previous
assertion, so we're left with...
"The PDP SHALL reference attributes as if they were in a physical
request context document."
I don't get it. Why 'as if''? Does 'reference' mean request? So
the PDP will request all attribute values in the same way, and
not have different ways of requesting different attributes?
>As the XACML PDP evaluates a policy, it will encounter various
>AttributeDescriptors and AttributeSelectors. Each time the PDP
>encounters one, it passes the information in that descriptor or
>selector to the Context Handler. The Context Handler searches
>for a match among the attribute objects it has parsed out of the
>Request Context received from the PEP. If the requested
>attribute is not there, then the Context Handler queries its
>configured attribute sources (LDAP directory, SAML attribute
>assertion repository, file of attributes, on-line AA, etc.) for
>a matching attribute, passing the AttributeId, Issuer, etc., and
>the values of any corresponding subject-id, resource-id, or
>action-id attributes (as appropriate to the type of descriptor).
>If there is no attribute available from the configured attribute
>sources, then the Context Handler returns either an empty bag or
>"Indeterminate" to the XACML PDP, depending on the value of the
>"MustBePresent" input. If the "MustBePresent" value is true,
>then the Context Handler returns "Indeterminate". If the
>"MustBePresent" attribute is false, then the Context Handler
>returns an empty bag.
>
>In the context of a Condition, the XACML PDP passes the returned
>value to the enclosing function. Most, if not all, standard
>XACML functions return "Indeterminate" if one of the inputs is
>"Indeterminate", but extension functions might not. It is up to
>the definition of the function. Similarly, if the resulting
>function does not take a bag as its input, but a bag is passed
>to it, then standard functions return "Indeterminate", but
>extension functions might not.
>
>In the context of a Target, the XACML PDP either passes the
>"Indeterminate" result to the enclosing function, or else passes
>one element at a time from the bag result to the enclosing
>function. Again, the result depends on the definition of the
>enclosing MatchId function.
Yeah, I'm fine with all this, thanks for walking through the
processing, I just didn't see that the PDP was supposed to ask
the CH for the value of attributes that were referenced in a
policy, but didn't exist with the request document.
>I expect that A002 and the two E tests (which require fetching
>policies and policy sets from external sources) will probably be
>the most difficult to implement,
I didn't actually have any problem with policy references... 5.18
and 5.19 are clear enough.
==========================================================================
0061. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00139.html
Subject: no rules or policies
From: Seth Proctor <seth.proctor@sun.com>
Date: Wed, 27 Nov 2002 11:13:57 -0500
Sections 7.6 and 7.7 contain, respectively, the only text in the
spec that says what to do when a Policy has no Rules or a
PolicySet has no policies. Unfortunately, the language is a
little muddled (and looks like it might be left over from a
previous version). Section 7.6 says
"A Rules value of 'At-least-one-applicable' SHALL be used if the <Rule>
element is absent..."
Section 7.7 says
"A policies value of 'At-least-one-applicable' SHALL be used if there are
no contained or referenced policies or policy sets..."
Is this supposed to imply that if the rule/policy[set] is
missing, then the result should always be the result of the
at-least-one-applicable combining algorithm, ie NotApplicable? If
that's the case, I'd like to request that the text be clarified
so that it's more obvious (since the above text doesn't really
mean anything). If that's not the case, these sections need to be
expanded to explain what to return in these conditions.
As a side note, I don't really understand what the value is of
having a Policy with no Rule, since it will always return the
same thing (probably N/A), so why bother going through the effort
of evaluating it? In other words, what is the reason for the
schema defining PolicyType to have
<xs:element ref="xacml:Rule" minOccurs="0" ...
CATEGORY: Incomplete.
STATUS: Not yet discussed.
SEE ALSO:
RESPONSE:
ACTIONS:
DISCUSSION:
[Polar Humenn]
I agree on this. But this whole section doesn't really make sense
to me at all. Neither do the tables. What is trying to be said
here? Furthermore, these sections are riddled with mistakes like
Not "Match" instead of "No-match" and "None-applicable" instead
of "Not-applicable".
These sections should say nothing more than the policy body is
evaluated according to its rule combining algorithm and the
evaluation of its rules, which is specified elsewhere. The
"truth" tables are wrong according to any kind of policy
combining algorithm. All of the combining algorithms handle the
case when there are no rules or policies.
So, I suggest the following rewording of both sections and remove
the tables.
7.6 Policy Evaluation
The value of a policy SHALL be determined only by its contents
against the access decision request. A policy's value SHALL be
determined by the evaluation of the policy's target and the
evaluation of its rules according to the specified rule combining
algorithm.
The policy's target is evaluated to determine the applicability
of the policy. If the target evaluates to "Match" then value of
the policy SHALL be determined by evaluation of the policy's
rules according to the specified combining algorithm. If the
target evaluates to "No-Match", then the value of the policy
shall be "Not-Applicable". If evaluation of the target raises an
"Indeterminate" the value of the policy SHALL be "Indeterminate".
7.6 Policy Set Evaluation
The value of a policy set SHALL be determined by its contents
against the access decision request. A policy set's value is
determined by the evaluation of the policy set's target and the
evaluation of its policies and policy sets according to the
specified policy combining algorithm.
The policy set's target is evaluated to determine the
applicability of the policy set. If the target evaluates to
"Match" then value of the policy set SHALL be determined by
evaluation of the policy's policies and policy sets according to
the specified policy combining algorithm. If the target
evaluates to "No-Match", then the value of the policy set shall
be "Not-Applicable". If evaluation of the target raises an
"Indeterminate" the value of the policy set SHALL be
"Indeterminate".
> As a side note, I don't really understand what the value is of having a Policy
> with no Rule, since it will always return the same thing (probably N/A), so
> why bother going through the effort of evaluating it? In other words, what
> is the reason for the schema defining PolicyType to have
>
> <xs:element ref="xacml:Rule" minOccurs="0" ...
The reason is that XACML (in the long run) will most likely be
generated by tools. I can't see anybody that would want to really
write such copious verbage at the keyboard. When generating from
other laguages or GUIs it is quite easy to end up with policies
with no rules, conjunctives or disjunctives with no elements,
etc. For logical completeness, these cases should be allowed and
handled in a logically sound manner.
Also, if the minimum administrative element for a PDP is the
policy. One use case, Let's say that you will dynamically add
rules, so to start you have no rules, but you still have to
configure your PDP with a policy there. So you shouldn't force
people to have rules where they don't have any.
==========================================================================
0062. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00151.html
Subject: Two different URIs for access-subject
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Thu, 28 Nov 2002 16:30:42 +0900
INCONSISTENT
In the specification document,
Two different URIs for access-subject are used.
urn:oasis:names:tc:xacml:1.0:subject-category:access-subject
urn:oasis:names:tc:xacml:1.0:subject:subject-category:access-subject
FYI:
Testcases are inconsitent, too, for the same reason.
In the schema,
urn:oasis:names:tc:xacml:1.0:subject-category:access-subject is
used.
In the test policies,
urn:oasis:names:tc:xacml:1.0:subject:subject-category:access-subject
is used.
CATEGORY: Inconsistent.
STATUS: Not yet discussed.
SEE ALSO:
RESPONSE:
ACTIONS:
==========================================================================
0063. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00152.html
Subject: Environment attributes
From: tony wilson <tony.wilson@inmezzo.com>
Date: Thu, 28 Nov 2002 15:07:23 +0000
I'm unclear about the use of the time based context attributes,
namely
Urn:oasis:names:tc:xacml:1.0:environment:current-time
Urn:oasis:names:tc:xacml:1.0:environment:current-date, and
Urn:oasis:names:tc:xacml:1.0:environment:current-dateTime
Section 10.3.5 of the specification states that 'The value for
these attributes MUST be provided by the PDP', wheras Appendix B8
states that 'When used, they SHALL appear within the <Resource>
element of the request context.'
Looking at tests AAA016-IIA021, it appears that the expected
usage is that the values may or may not be present in the request
context, but if they are not present then values must be supplied
by the PDP. Also, when values are being provided in the context
requests of these tests, they are appearing in the <Environment>
element, not the <Resource> element.
Which, if any, of these is correct?
CATEGORY: Unclear.
STATUS: Not yet discussed.
SEE ALSO:
RESPONSE:
ACTIONS:
DISCUSSION:
>Appendix B8 states that
>'When used, they SHALL appear within the <Resource> element of the
>request context.'
Sounds like a bug in the spec.
>Which, if any, of these is correct?
My interpretation is...
If provided within a Request these attributes shall appear within
the Environment. If not provided within a Request the PDP shall
provide them within the Environment.
==========================================================================
0063.
Subject:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC