[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Comments for discussion 25 November 2002
Attached is the full Comments file. The unresolved comments for discussion at our meeting on Monday, 25 November 2002 are: - #32a: waiting for text from Tim - #33: were waiting on opinions from Daniel and Polar, which they have now provided - #35-#50: not yet 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.8, 02/11/22 (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/msg00094.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: [Michiharu] 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: [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:
ACTION ITEM: [Polar][Daniel] Provide opinions on this comment.
ACTIONS:
DISCUSSION:
[Daniel] I would second this motion - I suggested it some time
ago, but somehow it got lost.
It is indeed redundant to some extend, but for consistency it
should be done I believe.
Now that we allow function to be a parameter, having a top level
funciton of undefined type really complicates proper extension
API design. But nobody seems to care about extensions at this
point. Well, eventually you will, but it would be too late to
fix it.
[Polar] The map function is polymorphic.
The type of the map function is deduced by the function parameter
and the other argument has to coincide.
The type of map is ( ( a -> b ) -> [a] -> [b] ).
That is, map takes a function that transforms an element of one
type to another, a bag of the first type, and returns a bag of
the resultant type.
What would "integer-map" mean? Would that mean a transformation
of a bag of integers to integers? Somehow, that would defeat the
purpose of the brevity of the specification, especially if you
wanted to convert doubles to integers, or dates to strings, etc.
If you want to define explicit map functions you would have to
use the cross product of types, i.e. *-*-map. You define an awful
lot of functions. Any good type checker can handle this. Also
that would limit the use of the function to just the primitive
types. If you invent another type, you have to define a new
type-*-map and *-type-map functions, (at least for every *type
you you have transformation functions defined. That would defeat
the beauty of higher order functions, reducing the specification
by extracting common functionality.
As far as extension APIs. I whole heartily disagree with
Daniel. I do care about them. I dont have any problem in defining
new types and applying the higher order functions to any well
defined function. Maybe this is just an implemenation issue.
[Seth Proctor]
> The type of the map function is deduced by the function parameter and the
> other argument has to coincide.
This sounds similar to the argument for not including the
DataType attribute in AttributeValues. The whole idea is that we
should be able to look at an attribute, a function, a designator,
etc., and know what type it will be returning. Without that,
there is no strong type-system.
> What would "integer-map" mean? Would that mean a transformation of a bag
> of integers to integers? Somehow, that would defeat the purpose of the
> brevity of the specification, especially if you wanted to convert doubles
> to integers, or dates to strings, etc.
No. The integer-map function would be a function that returns a
bag of integers, and therefore expects a function that also
returns integers. It would mean nothing more. You could still
have a function that converts doubles, strings, etc to
integers. The return type of a function does not limit what it
accepts or works with internally. This would be consistent with
the rest of the sepc, and would require a minimal number of
additional functions.
[Daniel] Let me elaborate a bit on why I agree with Seth.
Since the function name (and therefore type) is a parameter for
the map function, you do not now what type it will return until
you now the value of this parameter. In the current, limited
functionality system we do no the value at the "compile" time.
To provide a uniform extensibility mechanism for these "higher"
order functions, we may need to allow the value of each argument
to be a parameter with a value determined at the runtime. In this
case the functions that take this map output as an argument can
not be verified to accept the correct data type in advance. In
the case that the map type is declared and the function name is a
runtime valued parameter - inappropriate name will result in an
Indeterminate: a condition that we have a clear mechanism to deal
with. For this reason - ALL XACML functions should have
declared, not deduced, type.
[Anne] Maybe we should have asked for opinions from just one of
{Polar, Daniel} :-)
=========================================================================
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: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
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: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
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
“urn:oasis:names:tc:xacml:1.0:subject:subject-category”.
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: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
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: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
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: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
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: Not yet discussed.
RESPONSE:
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: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
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
'Att
ributeAssignmentType'. 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(Un
known 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(Unk
nown Source)
at
org.apache.xerces.impl.xs.traversers.XSDAbstractTraverser.reportSchem
aError(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.handleCo
mplexTypeError(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverse
ComplexTypeDecl(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverse
Global(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDHandler.getGlobalDecl(Unknown
Source)
at
org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseName
dElement(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseGlob
al(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDHandler.traverseSchemas(Unkno
wn Source)
at
org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown S
ource)
at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown
Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.findSchemaGrammar(Unknow
n Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unkno
wn Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Sou
rce)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unkn
own Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.s
canRootElementHook(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent
Dispatcher.dispatch(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un
known 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: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
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: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
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: Not yet discussed.
RESPONSE:
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: ?.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
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: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
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: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
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: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
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: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
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: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC