[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Updated Change Requests
This file reflects the status of all Change Requests following the Subcommittee Meeting on 4 November 2002. This set of Change Requests includes all those against v0.18c.doc that were still open after the 17 Oct 2002 TC conference call. See http://lists.oasis-open.org/archives/xacml/200210/msg00214.html for the changes previously approved to v0.18c.doc. Anne -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
Title: Change Requests Set 4
Author: Anne Anderson
Version: 1.16, 02/11/04 (yy/mm/dd)
Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.ChangeRequests4.txt
This file contains all non-editorial Change Requests not
reflected in the v0.18c.doc version of the XACML Specification
and still open after the 17 Oct 2002 TC conference call.
Includes e-mail up through
http://lists.oasis-open.org/archives/xacml/200211/msg00019.html
See
http://lists.oasis-open.org/archives/xacml/200210/msg00214.html
for the changes previously approved to v0.18c.doc.
=============================================================
CHANGE REQUESTS
1.SUMMARY
=========
1.1 ACTION ITEMS
================
0092: [Text Change] PH09: New section 7.4.2 Attributes
ACTION ITEM: [Polar] Update based on resolution to CR#0146
0143: 6.15 status detail formats. Forwarded message from SethProctor.
ACTION ITEM: [Anne] Write up missing-attribute StatusDetail schema.
0147: Bug in pseudocode for Only One Applicable.
ACTION ITEM: [Polar] Reword, send to Tim.
0149: Environment attributes
ACTION ITEM: [Anne] Reword to fit into Section 7 as a new sub-heading.
1.2 UNRESOLVED
==============
0092: [Polar] [Text Change] PH09: New section 7.4.2 Attributes
STATUS: UNRESOLVED. Waiting for CR#0146(11/4) See RESOLUTION.
0146: [Polar] CR 144: function "present" needs to be fixed.
STATUS: UNRESOLVED (11/4). Need semantics in QualifiedSubjectAttributeDesignator.
0154: [Seth Proctor] [Schema/Text Change] SubjectQualifier/SubjectAttributeDesignatorWhere
STATUS: UNRESOLVED. See partial RESOLUTION and OPEN ISSUE (NQ 11/4)
0156: [Seth Proctor] ObligationType
STATUS: UNRESOLVED
0157: [Steve Hanna] Glitch in moving from decimal to double
STATUS: UNRESOLVED
1.3 RESOLVED IN SUBCOMMITTEE, BUT NEED QUORUM VOTE
==================================================
0134c: [Seth Proctor] Need Datatypes for each defined AttributeId
STATUS: NEEDS QUORUM. RESOLVED (NQ 11/4). See RESOLUTION.
0153: [Polar] Issuer is xs:string in Context/xs:anyURI in policy
STATUS: NEEDS QUORUM. RESOLVED (NQ 11/4). Use xs:string" in both places.
0155: [Seth Proctor] Name for match element inSubjectQualifier/SubjectAttributeDesignatorWhere
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See RESOLUTION.
0158: [Simon] [Schema Change] Redefine <AttributeValueType>
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4)
0159: [Anne] [Text Change] Appendix B: Describe XACML attributes better
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST.
0160: [Anne] [Text Change] Appendix B: Describe XACML attributes better
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST.
0161: [Anne][Schema Change] editorial: "FulfillOn", not "FulfilOn"
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST.
1.4 RESOLVED
============
0076: [Anne] AA02: New section in Appendix A on Structured datatypes
STATUS: APPROVED (Q 10/31). See RESOLUTION.
0086: [Hal] HL03: Question about Anonymous Access Subject
STATUS: REJECTED (Q 10/17): submit specific proposals if explicit "anonymous" support needed.
0098: [Anne] AA11: Clarify "MatchId" functions
STATUS: APPROVED (Q 10/31). See RESOLUTION.
0100: [Steve Hanna] SteveHanna01: integer-mod takes two arguments
STATUS: APPROVED (Q 10/24). See RESOLUTION.
0101: [Satoshi Hada] SatoshiHada01: How many namespaces does XACML define?
STATUS: REJECTED (Q 10/31). We voted 6-3 for RESOLUTION#2.
0102: [Anne] AA13: Remove B.11 Identifiers used in conformance tests
STATUS: APPROVED (Q 10/24). See RESOLUTION.
0121: [Anne] AA32: clarify use of "dn"
STATUS: APPROVED (Q 10/24). See RESOLUTION.
0132: [Anne] AA43: use "xs:" or "xsi:"?
STATUS: APPROVED (Q 10/24). See RESOLUTION.
0134a: [Seth Proctor] Policy Target computed before arriving at PDP
STATUS: REJECTED (Q 10/31). No change.
0134b: [Seth Proctor] Add pointer to higher-order bag function to Apply
STATUS: APPROVED (Q 10/24). See RESOLUTION.
0134c: [Seth Proctor] Need Datatypes for each defined AttributeId
0134d: [Seth Proctor] Fix examples in Section A to include DataType
STATUS: APPROVED (Q 10/24). Fix all examples in A to include DataType.
0134e: [Seth Proctor] Bag input to single param function error; bags of any type
STATUS: APPROVED 1) (Q 10/24). See RESOLUTION.
STATUS: REJECTED 2) (Q 10/24). See RESOLUTION.
0134f: [Seth Proctor] Missing status codes
STATUS: RESOLVED (Q 10/30). Seth says new codes no longer needed.
0134g: [Seth Proctor] Acknowledgments/Contributions
STATUS: APPROVED (Q 10/24). See RESOLUTION.
0134h: [Seth Proctor] Should SubjectADWhere extend SubjectAD?
STATUS: REJECTED (Q 10/24). See Simon's comment.
0134i: [Seth Proctor] Treating Request as notional document
STATUS: REJECTED (Q 10/24). Provide specific wording if still needed.
0134j: [Seth Proctor] Examples for using AD/AS with "notional" Request
STATUS: REJECTED (Q 10/24). Provide specific wording if still needed.
0134k: [Seth Proctor] Describe how Policy[Set]Ids should be treated
STATUS: REJECTED (Q 10/24). Out of scope. See RESOLUTION.
0134l: [Seth Proctor] How to do resolution in an Apply
STATUS: REJECTED (Q 10/24). Already specified. See RESOLUTION.
0135: [Anne] AA45: make data-flow diagram consistent with 7.7 Use profile for XACML request
STATUS: REJECTED except for one change (Q 10/24). See RESOLUTION
0136: [Anne] AA46: Make 3.2 XACML context consistent with 7.7 Use profile for XACML request
STATUS: APPROVED (Q 10/24). See RESOLUTION.
0137: [Steve Hanna] SteveHanna02: xsi:decimal string representation
STATUS: REJECTED (Q 10/24). Stated in schema definition.
0138: [Steve Hanna] SteveHanna03: Use of decimal math should be justified
STATUS: APPROVED (Q 10/24): Replace "decimal" with "double".
0139: [Steve Hanna] SteveHanna04: handling of divide-by-zero
STATUS: APPROVED (Q 10/24). See RESOLUTION.
0140: [Michiharu] MK01: DataType and Namespace
STATUS: REJECTED (Q 10/31). Use URI for everything. See #101
0141: [Simon] SG[??]: data type uri's
STATUS: APPROVED (Q 10/31). See RESOLUTION.
0142: [Seth Proctor] bags and targets. Forwarded message from Seth Proctor.
STATUS: APPROVED Schema changes 1. and 2. (Q 10/31). See RESOLUTION.
STATUS: RESOLVED 3. and 4. (Q 10/31). Merge with CR#0146.
0143: [Seth Proctor] 6.15 status detail formats. Forwarded message from SethProctor.
STATUS: APPROVED (Q 10/31). See RESOLUTION
0144: [Polar] harmful to interoperability
STATUS: APPROVED (Q 10/31). See RESOLUTION.
0145: [Seth Proctor] Multi-valued attributes in Request.
STATUS: APPROVED (Q 10/31) Change to maxOccurs=1 in Context:AttributeType
0147: [Seth Proctor] Bug in pseudocode for Only One Applicable.
STATUS: APPROVED (Q 10/28). Polar will reword.
0148a: [Yassir Elley] Example two rules not applicable to request
STATUS: APPROVED (Q 10/31)
0148b: [Yassir Elley] Include target-namespace in Request Context?
STATUS: APPROVED (Q 10/31)
0148c: [Yassir Elley] Syntax of RequestContextPath not consistent
STATUS: APPROVED (Q 10/31)
0148d: [Yassir Elley] Move "disjunctive sequence" up to higher element description
STATUS: APPROVED (Q 10/31)
0148e: [Yassir Elley] Editorial comments
STATUS: Editorial. No vote required.
0149: [Seth Proctor] Environment attributes
STATUS: APPROVED (Q 10/31).
0150: [Seth Proctor] Types of pre-defined attributes
STATUS: RESOLVED (Q 10/24). Superseded by 0134c.
0151: [Seth Proctor] editorial: 10.3.6 extraneous paragraph
STATUS: Editorial. No vote required.
0152: [Tim Moses] Trivial Matter
STATUS: APPROVED (Q 10/31). See RESOLUTION.
=========================================================================
2. DETAILS
=========================================================================
0076: [Anne] AA02: New section in Appendix A on Structured datatypes
e-mail sent 11 Oct 2002 10:27:09 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00124.html
http://lists.oasis-open.org/archives/xacml/200210/msg00209.html (revised)
STATUS: APPROVED (Q 10/31). See RESOLUTION.
RESOLUTION: 10/21 meeting reached tentative resolution, but it
involves enough of a change that members need to see the
RESOLUTION SPECIFIC TEXT before voting.
RESOLUTION SPECIFIC TEXT:
TEXT LOCATION: Section A, following "A.2 Primitive
types" (p. 86, between lines 3345 and 3346 in my copy of 0.18c)
TEXT CHANGE: Add following new section as follows:
A.3 Structured types
An XACML <AttributeValue> MAY contain an instance of a
structured xml data type, for example <ds:KeyInfo>.
Structured data types MAY be structured XML data or MAY use
other encodings, such as DER-encoded ASN.1. XACML 1.0
supports several ways for comparing such <AttributeValue>s.
1) In some cases, such an <AttributeValue> MAY be compared
using one of the XACML-defined functions,such as
regexp-string-match or hexBinary-equal, described below.
In this case, the structured data, including its tags and
attributes, SHALL use the DataType corresponding to the
function to be used, both in the Policy
AttributeDesignators and Selectors and in the Request
Attribute.
In general, this method will not be adequate unless the
structured data type is quite simple.
2) An <AttributeSelector> element MAY be used to select the value
of a leaf sub-element of an XML structured data type.
That value MAY then be compared using one of the supported
XACML functions appropriate for its primitive data type.
This method requires support by the PDP for the optional
XPath expressions feature.
3) An <AttributeSelector> element MAY be used to select the value
of any node in an XML structured type. This node MAY then
be compared using one of the XPath-based functions
described in "Section A.13.13 XPath-based functions".
This method requires support by the PDP for the optional
XPath expressions and XPath functions features.
See Section 8. XACML extensibility points for further ways in
which structured data types may be handled.
TEXT LOCATION: 8. XACML extensibility points
TEXT CHANGE: Add following new section:
8.3 Structured data types
Section "A.3 Structured types" describes normative ways of
dealing with structured data types. XACML extensibility
points may be used to deal with such types in two additional
ways.
1) For a given structured data type, a new attribute
identifier MAY be defined for various leaf sub-elements of
the structured data type. The structured data is
presented to the PDP in the Request Context as a sequence
of <Attribute>s that use the new identifiers. Each such
<Attribute> MAY be compared using the XACML-defined
functions.
This method requires support by the PEP or Context Handler
for flattening the structured data type into the sequence
of individual <Attribute>s using the new attribute
identifiers. Using this method, the structured data type
itself never appears in an <AttributeValue> element.
2) A new function MAY be defined for comparing a value of the
structured datatype against some other value.
This method requires support by the PDP for the new
function.
==================================================================
0086: [Hal] HL03: Question about Anonymous Access Subject
e-mail sent 11 Oct 2002 11:56:37 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00126.html
STATUS: REJECTED (Q 10/17): submit specific proposals if explicit "anonymous" support needed.
CHANGE REQUEST:
Is there a cannonical way to represent an anonymous access
subject in the Request Context? This seems to me to be an
extremely common case that should be described in the spec. (My
preference would be to leave out the access subject entirely,
but I see that it is mandatory)
DISCUSSION:
[Anne] Yes, there is a canonical way. The sequence of
Attributes under <Subject> is minOccurs=0, so you can have a
Request Context in which the one <Subject> element has no
Attributes (such as no subject-id).
[Polar] A question that we are wrestling with in our logical
analysis of the security protocols, namely CSIv2, is whether
not having a prncipal is really an anonymous principal.
I think we are finding that there is a "default" principal, of
which you associated a principal with by either configuration
(let's say a request that comes over a VPN).
Also, you can assert an anonymous principal, which actually
states that you really do not know who it is. This principal is
supremely weaker than all other principals.
We might come up with a particular identifier saying
"Anonymous", but should make sure it isn't used for the
"default" case, unless the default case is truly anonymous.
In constrast to the default case, we could have a "default"
principal id, or, we direct the PEP to "fill" the principal in
with the default principal's id.
[Daniel] ..And to write rules on anonymous subject I presume
one has to use <anysubject> for target? Right? Does missed
subject have applicable rules written on <anysubject> ?
[Bill] that was my understanding.
[10/17 concall] Current document does not contain any
references to "anonymous".
If someone thinks we need explicit text on how to deal with
"anonymous" subjects, or if someone thinks we need an explicit
identifier for an "anonymous" subject, then that person needs
to submit a new change request with a use case, specific
locations to change, and specific text to use.
We may want to submit to SAML some specific values for the
"authn-method" attribute, such as: "intentionally anonymous",
"not authenticated", "authenticated by say so", "unknown", etc.
"No subject attributes" is not equivalent to "anonymous".
We agreed that it is permissible to omit all <Attribute>s from
the <Subject> and it is possible to refer to such a <Subject>
by using <AnySubject>. Neither of these requires any changes
to the existing text or schemas.
==================================================================
0092: [Polar] [Text Change] PH09: New section 7.4.2 Attributes
e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00141.html
http://lists.oasis-open.org/archives/xacml/200210/msg00207.html (revised 7.4.2.2)
http://lists.oasis-open.org/archives/xacml/200210/msg00291.html (new comment)
ACTION ITEM: [Polar] Update based on resolution to CR#0146
STATUS: UNRESOLVED. Waiting for CR#0146(11/4) See RESOLUTION.
SEE ALSO: CR#0146
RESOLUTION:
This is just a draft resolution that does not include:
- Impact of MustBePresent XML attribute
- Impact of missing attributes in a given <Subject> block in
evaluating QualifiedSubjectAttributeDesignator.
TEXT LOCATION: Following Section 7.4.1 "Hierarchi[c]al
resources", p. 70, after line 2911, and following the approved
sections "7.4.2 Attributes" and "7.4.2.1 Attribute Retrieval"
shown in DISCUSSION section below.
TEXT CHANGE: Add following new section:
7.4.2 Attributes
Attributes are specified in the request context and are
referred to in the policy by the subject, resource, action,
and environment attribute designators or selectors. Each
attribute specifies an AttributeId and a DataType, and each
attribute desigator specifies an AttributeId and
DataType. Attribute Designators and Attribute Selectors SHALL
match attributes by using string equality on both the
AttributeId and DataType values.
[RESOLUTION 7.4.2.1 #1]: ACCEPTED IN GENERAL (Q 10/31)
7.4.2.1 Attribute Retrieval
The PDP SHALL retrieve the values of attributes that match
the particular attribute designator or attribute selector and
form them into a bag of values with the specified
DataType. If no attributes from the request context match,
the attribute shall be considered missing, and an empty bag
is said to be retrieved.
[RESOLUTION 7.4.2.1 #2]: REJECTED. Use anyOf.
7.4.2.1 Attribute Retrieval
The PDP SHALL retrieve the values of attributes that match
the particular attribute designator or attribute selector
and form them into a bag of values with the specified
DataType. A bag containing one value is treated as
semantically equivalent to a single value of the specified
bag type. If no attributes from the request context match,
the attribute shall be considered missing, and an empty bag
is said to be retrieved.
7.4.2.2 Missing Attributes
The PDP SHALL consider an attribute as missing if it
evaluates an expression that requires at least one value to
be present from an attribute designator or selector. In this
case, the expression evaluates to "indeterminate". The PDP
may carry the missing attribute upward in its indeterminate
value in accordance with the XACML evaluation strategy of the
encompassing expressions, rules, policies, and policy
sets. If the PDP evaluates its policy or policy set to
Indeterminate with a missing attribute, the PDP MAY list the
AttributeId and DataType of that attribute in the result as
described in Section 7.5 "Authorization decision". However,
the PDP MAY choose not to issue such information due to
security concerns.
DISCUSSION:
[Seth, explaining RESOLUTION 7.4.2.1 #2]
Given the original text quoted above, an AD/AS will always
return a bag, which is always an error to most of the standard
functions, unless a bag with only one element is considered to
be the same as a single instance of just the element inside the
bag. The text change clarifies this.
Long discussion questioning rejection of resolution#2. Simon
clarified intent of the TC as follows:
1) Must wrap an AttributeDesignator with *-one-and-only
function to convert a bag into a single value, or else must
use AnyOf higher-order function.
2) Yes, the TC considered the "simplicity" of "implicit" type
conversion, but felt type consistency was more important.
There may be a performance overhead, but implementations
must deal with this.
3) if new type is defined every type-* function must be
defined as well
Polar provided following example of use "anyOf":
<Apply FunctionId="function:AnyOf">
<Function FunctionId="function:string-equal">
<AttributeValue Datatype="....#string">Hello World</AttributeValue>
<AttributeDesignator ....../>
</Apply>
This structure explictly states that if indeed the
AttributeDesignator returns more than one value, it is your
*explicit intent* that the boolean is true for any of the
returned values.
[Polar, responding to Daniel]
> In this particular example, *-is-in can be used as well.
The any-of must take a function that has the type: (a -> a ->
Boolean)
The type of *-is-in is ( a -> [a] -> Boolean), where a is a
primitive type, such as the type of function:string-is-in is:
(String -> [String] -> Boolean).
An application of string-is-in would be:
<Apply FunctionId="function:string-is-in">
<AttributeValue DataType="....#string">Hello World<AttributeValue>
<AttributeDesignator ....../>
</Apply>
[Polar, responding to Simon]
> functions that do not take attribute bags as arguments do not
> care about empty bags.
Untrue. An or function, for instance, is supposed to go through
a list of inputs until it finds a true value. If one of those
inputs fails to find any values, and the MustBePresent
attribute is false, then an empty bag is returned. This is done
precisely so that the function may skip over that input and
continue on (whereas it might choose to do something different
in an error case). Functions that do not take attribute bags as
arguments may still need to recognize the special case of an
empty bag.
[Seth, responding to Polar] Yes, I understand how anyOf is
used, but it means that you can't nest Apply blocks that have
functions that expect single values. Ie, in the example you
give
> <Apply FunctionId="function:AnyOf">
> <Function FunctionId="function:string-equal">
> <AttributeValue Datatype="....#string">Hello World</AttributeValue>
> <AttributeDesignator ....../>
> </Apply>
I know that there was one match to the value "Hello World" but
I don't get back that value, I get a boolean value instead. If
I have an add function that is inside of a floor function (for
instance), I can't use anyOf to somehow make sure that bags
with only one value get handled correctly by the functions,
since I want to need to have the add function return a number,
not a boolean. The comment in the change request was that anyOf
can somehow be used to solve this, and my point is that it
cannot.
[Polar, responding to Seth] For the capability you ellude to
below you use the map function;
<Apply FunctionId="function:map">
<Function FunctionId="function:double-floor">
<AttributeDesignator DataType="....#double" ....../>
</Apply>
==================================================================
0098: [Anne] AA11: Clarify "MatchId" functions
e-mail sent 14 Oct 2002 09:48:04 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00151.html
STATUS: APPROVED (Q 10/31). See RESOLUTION.
RESOLUTION:
TEXT LOCATION: Section A.11 Matching elements, p. 89, lines
3446-3456.
TEXT CHANGE: [Bag functions omitted per comment from Polar]
Replace following paragraph:
"The match elements: <SubjectMatch>, <ResourceMatch> and
<ActionMatch> SHALL use XACML standard functions to perform
the match evaluation. The function used for determining a
match is named in the MatchId attribute of these elements.
Each of these elements contains a <AttributeDesignator> or
<AttributeSelector> element and an explicit attribute value.
The restriction on the function is that the MatchId attribute
must name a binary function, such that its result type is
"xs:boolean". Also, each argument to the named function must
match the appropriate primitive types for the
<AttributeDesignator> or <AttributeSelector> element and the
following explicit attribute value, such that the explicit
attribute value is placed as the first argument to the
function, while an element of the bag returned by the
<AttributeDesignator> or <AttributeSelector> element is placed
as the second argument to the function."
with the following:
"The match elements: <SubjectMatch>, <ResourceMatch> and
<ActionMatch> SHALL use functions that match two arguments,
returning a result type of "xs:boolean", to perform the match
evaluation.The function used for determinaing a match is named
in the MatchId attribute of these elements. Each argument to
the named function must match the appropriate primitive types
for the <AttributeDesignator> or <AttributeSelector> element
and the following explicit attribute value, such that the
explicit attribute value is placed as the first argument to
the function, while an element of the bag returned by the
<AttributeDesignator> or <AttributeSelector> element is placed
as the second argument to the function.
The XACML standard functions that may be used as a MatchId
attribute value are:
function:*-equal
function:*-greater-than
function:*-greater-than-or-equal
function:*-less-than
function:*-less-than-or-equal
function:*-match
DISCUSSION:
Summarized as:
a) Using functions other than the standard XACML *-equal
functions will make indexing Targets difficult, inefficient,
or impossible for some systems.
b) Using functions other than those implying a hierarchy of
target matches (*-equal or *-match) functions will make
indexing Targets difficult, inefficient, or impossible on
some systems.
c) Not allowing arbitrary boolean functions will not allow use
of Target to perform more efficient evaluations on some
systems.
d) PAPs in some cases will know the structure of the repository
and indexing system, so can allow only functions that can be
indexed. If a Policy's Target uses a function that is not
supported by the indexing scheme of the repository used by
the PDP, then that Policy's Target will need to be evaluated
against every Request.
==================================================================
0100: [Steve Hanna] SteveHanna01: integer-mod takes two arguments
personal communication to Anne Anderson on 14 Oct 2002
STATUS: APPROVED (Q 10/24). See RESOLUTION.
RESOLUTION:
TEXT LOCATION: Section A.13.2 Arithmetic functions, p. 92,
4569, list of functions that take a single argument.
TEXT CHANGE: Move "integer-mod" up to the list of functions
that take two arguments.
==================================================================
0101: [Satoshi Hada] SatoshiHada01: How many namespaces does XACML define?
e-mail to xacml-comment 15 Oct 2002 13:51:19 +0900
STATUS: REJECTED (Q 10/31). We voted 6-3 for RESOLUTION#2.
SEE ALSO: CR#0140,0141
RESOLUTION#1: QName for DataType, URI for everything else.
QName is <namespace string>:<local-name string>
Use QName for DataType, but URI for everything else.
Will have to specify an xmlns= for each namespace used.
Will have to define an xmlns= for the XACML-defined types.
Use pair-comparison for QName matching: QNames must be expanded.
Will have to define QName matching. In favor: Michiharu,
Simon, Bill
RESOLUTION#2: URI for everything
We specify the URI for every XACML-defined DataType.
Specify use of # between prefix and datatype name, where
datatype name is a schema fragment.
Easier to compare as strings, since already expanded. In
favor: Ken, Hal, Carlisle, Tim, Polar, Anne
CHANGE REQUEST:
Use QName for DataType, URI for everything else.
Changes required:
1) Define new namespace for XACML datatype in B.1:
urn:oasis:names:tc:xacml:1.0:datatype
2) In schemas, define DataType attribute type as a QName.
3) Statement like: We recommend use of the following QName
xmlns prefixes. [To make policies easier to read]
xsi: <XML Schema Instance namespace>
xs: <XML Schema namespace>
ds: <XML Digital Signature namespace>
?: urn:oasis:names:tc:xacml:1.0:datatype
?: urn:oasis:names:tc:xacml:1.0:context (used by XPath expression)
DISCUSSION:
It is unclear to me how many namespaces XACML tries to define.
Appendix B.1 says that the following two namespace URIs are defined.
urn:oasis:names:tc:xacml:1.0:policy
urn:oasis:names:tc:xacml:1.0:context
However, it seems to me that XACML tries to define at least two other
namespaces.
(1) One is for function identifiers, i.e.,
urn:oasis:names:tc:xacml:1.0:function. Indeed, the type of
the "FunctionID" attribute is xs:QName and so I think this
URN should be one of namespace URIs defined in the XACML
specification.
(2) The other is for data types, i.e.,
urn:oasis:names:tc:xacml:1.0:datatype. Currently, the type
of the "DataType" attribute is xs:anyURI.
I think it should be xs:QName and this URN should be one of
namespace URIs defined in the XACML specification.
[10/24/02 con call]
[Anne] Should we also define namespaces for attribute
categories, status codes, subject-categories?
[Simon] No. Use QNames for datatypes, since xsi:string,
etc. are commonly used.
[Tim] Aren't QNames are used for names taken from schemas?
[Simon] No. It is just a syntactic structure with no semantics
behind it. Used for value of an attribute. It is an XML
datatype.
[Hal] A QName is a macro-expansion facility. Used in lots of
schemas and specifications.
[Tim] WSS uses QName for encoding type. Just an identifier.
[Polar] Type needs to be either a QName or a URI, can't be
both.
[Satoshi Hada] So the tentative resolution says that we should
write a condition by using URI rather than QName to specify
function identifiers. Please correct me if I'm wrong. [See
http://lists.oasis-open.org/archives/xacml/200210/msg00278.html
for two examples]
[Simon, responding to Satoshi Hada] That is correct
[Anne, asking general questions about QNames]
1. If an xml attribute is defined as Type="xs:QName", then do XML
parsers like SAX and DOM do the resolution of those names?
Example: Assume AttributeDesignatorType is defined as follows:
<xs:complexType name="AttributeDesignatorType">
<xs:attribute name="AttributeId" type="xs:QName" use="required"/>
<xs:attribute name="DataType" type="xs:anyURI" use="required"/>
<xs:attribute name="Issuer" type="xs:anyURI" use="optional"/>
</xs:complexType>
Then, if my Policy says
<Policy xmlns="urn:oasis:names:tc:xacml:1.0:policy"
xmlns:sun-attrs="urn:sun:names:attribute-ids"
...
<SubjectAttributeDesignator AttributeId="sun-attrs:attr1"
.../>
And a Request says
<Request xmlns="urn:oasis:names:tc:xacml:1.0:context"
xmlns:sun-stuff="urn:sun:names:attribute-ids"
...
<Subject>
<Attribute AttributeId="sun-stuff:attr1">
...
Will the tools themselves resolve these, or do I have to
expand the names and then perform a string match myself?
Simon> By looking at the sax api it does not seem that
Simon> anything is done with attribute values of qname type.
Simon> My guess is that an application is responsible for
Simon> expanding qname. Problem is that expanded name is a
Simon> pair: (URI, local_name) and there is no standard that
Simon> says how this 2 elements should be combined to form one
Simon> value. Some suggest URI+local_name, others
Simon> URIlocal_name, and so on.
Simon> My preference would be not to use qnames for attribute
Simon> values at all, and use URI's instead.
Anne> But then what do we do about DataType values such as
Anne> xsi:string that are already defined as QNames?
2. Does anyone have a reference from W3C on whether QNames MAY be
used as "aliases" for any URI or whether they are ONLY for use
in referring to URI's that represent schemas?
I.e. are the uses of QNames for use in identifiers as in #1
and in our current schemas even allowed (or recommended)?
3. Is there a way to define aliases for shortcut names other than
QNames? I.e. can I define an alias to be equal to some
initial prefix of a long URI, and then have that expanded by
XML parsing tools?
==================================================================
0102: [Anne] AA13: Remove B.11 Identifiers used in conformance tests
e-mail sent 14 Oct 2002 09:58:56 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00154.html
STATUS: APPROVED (Q 10/24). See RESOLUTION.
RESOLUTION:
TEXT LOCATION: Section B.11, p. 111, lines 4325-4328
TEXT CHANGE: remove entire Section "B.11 Identifiers used only
in XACML conformance tests"
DISCUSSION: just as for identifiers used in examples, I don't
think we need to spell out the identifiers used in conformance
tests.
==================================================================
0121: [Anne] AA32: clarify use of "dn"
e-mail sent 14 Oct 2002 12:59:38 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00177.html
STATUS: APPROVED (Q 10/24). See RESOLUTION.
RESOLUTION:
TEXT LOCATION: Section 6.7 Element <Attribute>, description of
"Issuer [Optional]", p. 64, line 2685
TEXT CHANGE: replace "This MAY be a dn that binds to a public
key" with "This attribute value MAY be an X.500 Distinguished
Name that binds to a public key"
==================================================================
0132: [Anne] AA43: use "xs:" or "xsi:"?
e-mail sent 14 Oct 2002 13:36:53 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00187.html
STATUS: APPROVED (Q 10/24). See RESOLUTION.
SEE ALSO: CR#0101,0140,0141
RESOLUTION: Use xsi:string, etc. for XML Schema-defined
datatypes in examples. Use xs:any, etc. in schema
definitions.
CHANGE REQUEST:
In some places we use "xsi:<some datatype>", while
in other places we use "xs:<some datatype>". We should pick
one. I propose "xs:" just because it is shorter.
DISCUSSION:
[Tim] Example: p. 64 <Decision> is restriction on xs:string.
xsi only used in examples.
==================================================================
0134a: [Seth Proctor] Policy Target computed before arriving at PDP
e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00192.html
STATUS: REJECTED (Q 10/31). No change.
RESOLUTION: Current version is clear. Offending text changed
between time request was made and time it was considered.
CHANGE REQUEST:
3.3.2.1 (PolicyTarget) still makes it unclear that Policy
Target is computed before arriving at the PDP.
=================================================================
0134b: [Seth Proctor] Add pointer to higher-order bag function to Apply
e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00192.html
STATUS: APPROVED (Q 10/24). See RESOLUTION.
RESOLUTION:
In Section 5.21 Element <Apply>, explanation of <Function>
[Optional], p. 54, line 2260, following "The name of a function
that is applied to the elements of a bag.", append: "See
Section A.13.11 Higher-order bag functions."
DISCUSSION:
In section 5, when the <Function> tag is explained in Apply, it
should have a pointer to the higher-order bag section so people
understand what it's there for
===================================================================
0134c: [Seth Proctor] Need Datatypes for each defined AttributeId
e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00192.html
STATUS: NEEDS QUORUM. RESOLVED (NQ 11/4). See RESOLUTION.
SEE ALSO: CR#0150
RESOLUTION: Each "standard attribute" should have a "standard
datatype", since we proposed them for interoperability in the
first place. See
http://lists.oasis-open.org/archives/xacml/200210/msg00290.html
for attachment containing XACML_identifiers.doc, which is
Simon's proposed list. Simon has revised this to reflect all
e-mail comments received, and sent the revised version to Tim
for inclusion in v0.18f.doc
CHANGE REQUEST:
10.3.6 (Identifiers) doesn't list the type of any these
attributes, nor does it give the required uses for them that it
says implementors must follow. I realize this is transparent to
a lot of the code, and only one of these is required to
support, but it would still be helpful to know what type
they're supposed to be (if there is a certain expected
type). Later in the spec they're explained in a little more
detail, but not enough to make the strong language in this
section about correct implemention make sense.
DISCUSSION:
[Anne] I don't think there is a specified type for these. You
specify the type using the XML Datatype="" attribute. One user
might specify key-info, for example, using a SubjectKeyInfo
from PKIX, while another might use a ds:KeyInfo structure.
[0141]. data type uri's. Is DataType attribute QName or URI?
I've been advocating URI up to now (even on today's schema
call) but I've changed my mind to QName. QName evaluates into
expanded name which is a pair: (URI, local_name). Expanded
name MUST be used in all operations involving DataType
attribute of the xacml:AttributeDesignator,
xacml:AttributeSelector, xacml:AttributeValue, and
xacml-context:Attribute.
Eg: <Attribute AttributeId="..." DataType="xsi:string"/>
Expanded name: http://www.w3c.org/2001/XMLSchema, string
If expanded name is used, we do not have to specify how to form
URI out of this pair.
For those who care: I was advocationg URI for the DataType
because I thought that expanded qname must be somehow
concatenated into one value. URI is already one value. But many
times we have to invent this URI by using the same
concatenation. If we compare expanded names as pairs we do not
have this problem.
[Anne]
Comments on Simon's proposed DataTypes:
- subject-category:codebase: this should be anyURI (it is usually a URL)
- subject-category:requesting-machine
o we should have two requesting machine categories:
requesting-machine-ip-address
requesting-machine-dns-name
o then both can be xsi:string
- subject:subject-id: we can't say the "default is xsi:string" since
DataType is required.
- subject:subject-category: should be anyURI (see list in B.2 - they are
all URNs)
- subject:subject-id-qualifier: SAML says type not specified. I suggest
we let DataType specify the type or else say anyURI
- subject:authentication-method: SAML uses anyURI, I suggest same
- resource:resource-id: description says "This identifier
indicates the entire URI of the resource." I believe this
should say "This identifier indicates the name of the
resource." I think we need to let DataType determine the type
(it might be a string, it might be a URL, it might be a URN,
etc.)
- action:actionNamespace: should be anyURI to fit with SAML's use
=================================================================
0134d: [Seth Proctor] Fix examples in Section A to include DataType
e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00192.html
STATUS: APPROVED (Q 10/24). Fix all examples in A to include DataType.
CHANGE REQUEST:
A.6 (Element <AttributeValue>) says that an AttributeValue's
type is implied by the function using it, but that's changed
now to state the type explicitly (same for next 2
sections)...actually, this change is missing in most of the
section A examples.
===================================================================
0134e: [Seth Proctor] Bag input to single param function error; bags of any type
e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00192.html
STATUS: APPROVED 1) (Q 10/24). See RESOLUTION.
STATUS: REJECTED 2) (Q 10/24). See RESOLUTION.
RESOLUTION:
1) APPROVED: Any type allowed in a bag (i.e. user-defined types
as well as XACML-defined types). Wording in A.11 and A.13.9
should be changed to reflect this.
2) REJECTED: Already specified.
A.14.1 Equality predicates,
example: boolean-equal: "This function SHALL take two
arguments of xs:boolean".
A.14.2 Arithmetic functions
Starts with "All of the following functions SHALL take
two elements of the specified type, integer or decimal."
A.14.3 String conversion functions
example: string-normalize-space: "This function SHALL
take one argument of type 'xsi:string'..."
etc.
CHANGE REQUEST:
1) A.11 (Matching elements) says that the AD/AS used in a Target
match must return a bag, and then has some other language
that borders on describing an API. I think it should be made
clear that if a function expects a single String (eg), then
getting a bag is an error.
2) Also, this section (and the section later describing bags)
should clarify that _any_ type is allowed in a bag, not just
those defined as base types in the spec. If you'd like, I
can work on alternate language.
=================================================================
0134f: [Seth Proctor] Missing status codes
e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00192.html
STATUS: RESOLVED (Q 10/30). Seth says new codes no longer needed.
SEE ALSO: CR#0143, which proposes formats.
CHANGE REQUEST:
B.9 (Status codes) is still missing some of the codes that we
discussed (like problems choosing the root policy). Maybe a few more
could be added. Maybe I should writeup a few other codes, and include
some proposal for the format of the values to accompany various
Status codes?
=================================================================
0134g: [Seth Proctor] Acknowledgments/Contributions
e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00192.html
STATUS: APPROVED (Q 10/24). See RESOLUTION.
RESOLUTION: Include Seth, Pierangela, Ernesto, etc. on front
page "Contributors" (everyone who made substantial
contributions during development of sepcification). Appendix
D will include only voting members at the time of approval for
Committee Spec.
CHANGE REQUEST:
D (Acknowledgments) ... this is a small issue, but since the
list of voting memebers is basically also the contributer list,
shouldn't this section name people who weren't on the TC but
helped shape the standard? This is the way other specs look.
=================================================================
0134h: [Seth Proctor] Should SubjectADWhere extend SubjectAD?
e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00192.html
STATUS: REJECTED (Q 10/24). See Simon's comment.
CHANGE REQUEST:
Should SubjectAttributeDesignatorWhere extend SubjectAD now instead of
just AD? Before it made sense, since all ADs were the same, but I
would think that since there's now a special AD for Subjects, that's
what you would want to extend.
DISCUSSION:
[Simon] if we extend subj-attr-desig <-
subject-attr-desig-where we will inherit subject-category
attribute. Having subject-category in subject-attr-desig is
confusing.
=================================================================
0134i: [Seth Proctor] Treating Request as notional document
e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00192.html
STATUS: REJECTED (Q 10/24). Provide specific wording if still needed.
SEE ALSO: CR#0135, CR#0136
CHANGE REQUEST:
There is still no discussion anywhere about treating the Request as a
notional doc and going outside the PDP to get attribute values. The
same text is still throughout the spec suggesting just the opposite,
and the picture at the beginning looks the same. I know you're thinking
about how to change this, but if this is really supposed to be supported,
then the spec _must_ change dramatically to make this clear. One or
two paragraphs added somewhere will not cut it.
DISCUSSION:
[Anne] Some of the "one or two paragraphs added somewhere"
are in a new section proposed in CR#092: "7.4.2 Attributes"
that includes subsections on Attribute Retrieval and Missing
Attributes. The rest is already in the document in Section
7.7 Use profile for XACML request.
If more text is needed to make these sections clear, please
propose it.
=================================================================
0134j: [Seth Proctor] Examples for using AD/AS with "notional" Request
e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00192.html
STATUS: REJECTED (Q 10/24). Provide specific wording if still needed.
CHANGE REQUEST:
There needs to be some clear examples of how to use an AD/AS to
make [treating Request as notional document] happen. I don't
think that AS's should be used for this functionality (just
because it's too hard to support), but that's a separate issue.
DISCUSSION:
[Anne] Isn't that an implementation issue? The spec should
just specify the desired behavior, not how it is achieved.
=================================================================
0134k: [Seth Proctor] Describe how Policy[Set]Ids should be treated
e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00192.html
STATUS: REJECTED (Q 10/24). Out of scope. See RESOLUTION.
RESOLUTION: Out of scope. Id MUST be a URI, but we don't force
URN or URL. Anne is thinking of writing another specification
for an extension or wrapper for an XACML policy that specified
via URLs where to find things like: policy ids, executable code
for functions, attributes, PAP's, AA's. Basically a schema for
mapping various IDs in various contexts to URLs.
CHANGE REQUEST:
There should probably be some language added to discuss how
Policy[Set] Ids should be treated. At the very least, and
example or some hints about typical use would make things
better, since right now this is entirely up to the implementor,
and as such is guarenteed to be a point where interoperability
of policies fails.
=================================================================
0134l: [Seth Proctor] How to do resolution in an Apply
e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00192.html
STATUS: REJECTED (Q 10/24). Already specified. See RESOLUTION.
RESOLUTION: Already clearly laid out in A.13.5 for logical
functions. Bag functions refer to these. Laid out in first
paragraph of A.13.2 for Arithmetic functions (if any argument
is missing, then expression is "indeterminate". Laid out at
beginning of description of each other type of function.
CHANGE REQUEST:
There is still no text about how to do resolution in an Apply,
and how this can be short-circuited, etc. The current spec
doesn't make it clear that you should be able to do this, so I
think this needs to be added in clear examples & specification,
otherwise not all implementors will get this right.
==================================================================
0135: [Anne] AA45: make data-flow diagram consistent with 7.7 Use profile for XACML request
e-mail sent 16 Oct 2002 14:32:00 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00195.html
STATUS: REJECTED except for one change (Q 10/24). See RESOLUTION
SEE ALSO: CR#0134i
RESOLUTION: Don't touch diagram. However, 8 should say
"Context Handler supplies information about the Request Context
to the PDP."
CHANGE REQUEST:
TEXT LOCATION: 3.1 Data-flow model, Figure 1 - Data-flow diagram
TEXT CHANGE: Replace diagram with:
access requester --2. access request----> PEP --13. obligations--> obligations
| ^ service
| |
3. request 12. response
| |
| |
V |
PDP <--4. request notification---- context handler <---8. resource--> resource
content
---5. attribute queries------>
^ <--10. attributes------------
| --11. response context-------->
| | ^ ^
| | | |--9. environment--> environment
| | | attributes
| | |
| 6. attribute 7. attributes
| queries |
1. policy | |
| | |
| V |
PAP PIP
TEXT LOCATION: 3.1 Data-flow model, Steps 1-12
TEXT CHANGE: Replace text for steps as follows:
1. PAPs write policies and make them available to the PDP.
2. The access requester sends a request for access to the PEP.
3. The PEP sends the request for access to the context handler in
its native request format, optionally including additional
attributes of the subjects, resource and action. The
context handler translates the information in the native
request into a form consistent with an XACML Request Context
(see Section 7.7 Use profile for XACML request).
4. The PEP notifies the PDP that a request is available for
evaluation.
5. Based on its initial policy (see Section 7.1 Initial
policy), the PDP issues attribute queries to the context
handler based on the attributes required to evaluate the
initial policy and those policies referenced from it.
Attribute queries are expressed in the form of
AttributeDesignators or AttributeSelectors.
6. The context handler may issue attribute queries to a PIP in
order to resolve attributes not present in the native
request.
7. The PIP returns the requested attributes to the context
handler.
8. The context handler may optionally obtain information from
the resource itself.
9. The context handler may optionally obtain information from
the environment.
10. The context handler makes the requested attributes available
to the PDP "as if" the requested attributes were located in
a Request Context. The PDP evaluates the policy.
11. The PDP returns the response context (including its
decision) to the context handler.
12. The context handler translates the response context to the
native response format of the PEP. The context handler
returns the response to the PEP.
13. The PEP fulfills the obligations
14. (Not shown) if access is permitted, then the PEP permits
access to the resource; otherwise, it denies access.
DISCUSSION: Make diagram and steps consistent with respect to
"notional" Request Context and how/when attributes are obtained.
==================================================================
0136: [Anne] AA46: Make 3.2 XACML context consistent with 7.7 Use profile for XACML request
e-mail sent 16 Oct 2002 14:36:47 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00196.html
STATUS: APPROVED (Q 10/24). See RESOLUTION.
RESOLUTION:
TEXT LOCATION: 3.2 XACML context, last paragraph. p. 17, line
560.
TEXT CHANGE: Append: "See Section 7.7 Use profile for XACML
request for more information about how the XACML request context
is handled."
==================================================================
0137: [Steve Hanna] SteveHanna02: xsi:decimal string representation
e-mail sent 16 Oct 2002 14:45:39 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00198.html
STATUS: REJECTED (Q 10/24). Stated in schema definition.
CHANGE REQUEST:
Section A.3 Representations says:
For integers and decimals, XACML SHALL use the conversions
described in IBM Standard Decimal Arithmetic document at
the following URL:
http://www2.hursley.ibm.com/decimal/decarith.html
This document combines the various standards set forth by
IEEE and ANSI for string representation of numeric values.
The IBM document defines a numeric string syntax that
allows scientific notation, NaNs, and infinities. The XML
schema document that defines the permissible contents of the
xs:decimal data type does not allow any of these.
I suggest that a note be added after the above passage,
saying:
Note that although the IBM document allows exponents,
NaNs, and infinities the XML Schema specification does
not allow these in an xs:integer and xs:decimal value.
Therefore, they MUST NOT be used in such values.
==================================================================
0138: [Steve Hanna] SteveHanna03: Use of decimal math should be justified
e-mail sent 16 Oct 2002 14:45:44 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00199.html
STATUS: APPROVED (Q 10/24): Replace "decimal" with "double".
CHANGE REQUEST:
It is unusual to specify the use of decimal math in
a specification like XACML, especially requiring strict
conformance to a detailed specification of decimal
math behavior. Many platforms do not support decimal
math. Binary math is much more common.
I can see why you might want to use decimal math for
this specification. Maybe you're likely to be doing a
lot of financial calculations. Still, I think it's a
bit odd that you require support for exponents, NaNs,
and the like in the implementation but don't provide
any way for a user to access these features. A simpler
approach would have been to leave the arithmetic
loosely specified, like XQuery has done.
At the least, I think you should add a few sentences
to the end of section A.12 Arithmetic evaluation saying
Decimal arithmetic is used in order to provide
results that closely match those expected by the
average user.
==================================================================
0139: [Steve Hanna] SteveHanna04: handling of divide-by-zero
mail sent 16 Oct 2002 14:45:48 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00188.html
STATUS: APPROVED (Q 10/24). See RESOLUTION.
RESOLUTION:
I suggest that you change section A.12 to say that all
trap-enablers SHALL be set to 0 except division-by-zero,
which SHALL be set to 1. Then you can change the description
of the integer-divide and decimal-divide functions in
section A.13.2 to say that they SHALL produce a result
of indeterminate with a processing-error status if the
divisor is 0.
CHANGE REQUEST:
Section A.12 Arithmetic evaluation says that trap-enablers
SHALL all be set to 0. I believe that this means that a
division by zero will produce a result of positive or
negative infinity and proceed along happily. That seems
surprising and contradicts sections 6.11 and B.9, which
imply that a division by zero will produce an indeterminate
result.
==================================================================
0140: [Michiharu] MK01: DataType and Namespace
e-mail sent 17 Oct 2002 18:47:58 +0900
http://lists.oasis-open.org/archives/xacml/200210/msg00202.html
STATUS: REJECTED (Q 10/31). Use URI for everything. See #101
SEE ALSO: CR#0101,0132,0141
CHANGE REQUEST:
We have agreed to specify DataType attribute in both policy and
context. The schema 16j says that DataType attribute is
xs:anyURI. I think that the DataType is written as QName such
as "xs:string" and "xs:boolean" like MatchId attribute. So I
request to change DataType attribute from xs:anyURI to
xs:QName. Besides, we should add the following namespace prefix
and its namespace URI in the spec.
Prefix Namespace URI
xacml-function urn:oasis:names:tc:xacml:1.0:function
xacml-datatype urn:oasis:names:tc:xacml:1.0:datatype
*) datatype prefix is used for xacml-datatype:x500Name and
xacml-datatype:rfc822Name. In fact, prefix itself matters only
in the specification document. Policy writers can choose
another prefix as they like.
I think text that refers to ds: prefix (XML Signature
namespace) and saml: prefix no longer exist in the spec. So
line 289-290, 303-305 should be deleted.
DISCUSSION:
[Satoshi Hada] I found an inconsistent use of the "DataType"
attribute.
----------------------------------------------------
<Attribute DataType="xs:string"....>
In this case, it seems to me that the attribute type is xs:QName.
----------------------------------------------------
<Attribute DataType="urn:oasis:names:tc:xacml:1.0.datatype:x500name"...>
In this case, it seems to me that the attribute type is xs:anyURI.
----------------------------------------------------
As Kudo-san is requesting, I'd request to change the type from
xs:anyURI to xs:QName.
==================================================================
0141: [Simon] SG[??]: data type uri's
e-mail sent 17 Oct 2002 09:50:15 -0700
http://lists.oasis-open.org/archives/xacml/200210/msg00208.html
STATUS: APPROVED (Q 10/31). See RESOLUTION.
SEE ALSO: CR#0101,0132,0140
RESOLUTION: We like the list of data types and agree they
should not be QNames, but are unresolved as to whether we use
URL or URN for datatypes. If URL, then we need a way to
specify the two xacml-defined DataTypes as URLs.
RESOLUTION SPECIFIC TEXT:
XML-schema datatype namespace:
http://www.w3.org/2001/XMLSchema-datatypes
Xml data types:
http://www.w3.org/2001/XMLSchema#string
http://www.w3.org/2001/XMLSchema#boolean
http://www.w3.org/2001/XMLSchema#integer
http://www.w3.org/2001/XMLSchema#decimal
http://www.w3.org/2001/XMLSchema#date
http://www.w3.org/2001/XMLSchema#dateTime
http://www.w3.org/2001/XMLSchema#anyURI
http://www.w3.org/2001/XMLSchema#hexBinary
http://www.w3.org/2001/XMLSchema#base64Binary
Xquery operators datatype namespace:
http://www.w3.org/TR/xquery-operators
Xquery data types:
http://www.w3.org/TR/xquery-operators#dayTimeDuration
http://www.w3.org/TR/xquery-operators#yearMonthDuration
Xacml datatype namespace:
urn:oasis:names:tc:xacml:1.0:datatype
Xacml data types:
urn:oasis:names:tc:xacml:1.0:datatype:x500Name
urn:oasis:names:tc:xacml:1.0:datatype:rfc822Name
Changes:
A2. Primitive types.
replace datatype list with the above list.
B4. Data types
replace data-type identifiers with the above list
==================================================================
0142: [Seth Proctor] bags and targets. Forwarded message from Seth Proctor.
e-mail sent 17 Oct 2002 16:43:04 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00216.html
STATUS: APPROVED Schema changes 1. and 2. (Q 10/31). See RESOLUTION.
STATUS: RESOLVED 3. and 4. (Q 10/31). Merge with CR#0146.
SEE ALSO: CR#0146
RESOLUTION: Overview: Create a new XML attribute on Designators
and Selectors to indicate "Must be present". This new
attribute is optional, and may be used in either Target or
Condition. Behavior of indeterminate results in Target where
AND or especially OR is being done (e.g. in multiple subjects
where only one needs to match) needs to be spelled out, but it
should follow behavior of current "and" and "or" functions.
RESOLUTION SPECIFIC TEXT (aligned with CR#0146):
1. In policy schema: Change
<xs:complexType name="AttributeSelectorType">
<xs:attribute name="RequestContextPath" type="xs:string" use="required"/>
<xs:attribute name="DataType" type="xs:anyURI" use="required"/>
</xs:complexType>
To:
<xs:complexType name="AttributeSelectorType">
<xs:attribute name="RequestContextPath" type="xs:string" use="required"/>
<xs:attribute name="DataType" type="xs:anyURI" use="required"/>
<xs:attribute name="MustBePresent" type="xs:boolean" use="optional"
default="false"/>
</xs:complexType>
2. In policy schema, Change
<xs:complexType name="AttributeDesignatorType">
<xs:attribute name="AttributeId" type="xs:anyURI" use="required"/>
<xs:attribute name="DataType" type="xs:anyURI" use="required"/>
<xs:attribute name="Issuer" type="xs:anyURI" use="optional"/>
</xs:complexType>
To:
<xs:complexType name="AttributeDesignatorType">
<xs:attribute name="AttributeId" type="xs:anyURI" use="required"/>
<xs:attribute name="DataType" type="xs:anyURI" use="required"/>
<xs:attribute name="Issuer" type="xs:anyURI" use="optional"/>
<xs:attribute name="MustBePresent" type="xs:boolean" use="optional"
default="false"/>
</xs:complexType>
3. Section 5.23 Complex type AttributeDesignatorType, append
following to the very end of this section (after Issuer
[Optional] description):
MustBePresent [Optional]
The MustBePresent attribute governs whether the
AttributeDesignator element returns an empty bag or
indeterminate in the case of finding no value for the
named attribute in the request context. [Insert text from
CR#0146 here]
The default value for the MustBePresent attribute is false.
4. Section 5.29 Element <AttributeSelector>, append following to
the very end of this section (after DataType [Required]
description):
The MustBePresent attribute governs whether the
AttributeSelector element returns an empty bag or
indeterminate in the case of finding no value for the
named attribute in the request context. [Insert text
from CR#0146 here]
The default value for the MustBePresent attribute is false.
CHANGE REQUEST:
TEXT LOCATION: Section A.11, Paragraph 3, lines3459-3461: 'If
the <AttributeDesignator> or <AttributeSelector> element
evaluates to an empty bag, then the result of the expression
SHALL be "False".'
It seems to me that an empty bag only happens if you can't
resolve a value for the attribute in question...could this
actually mean something else? The only thing I could think of
is an Attribute in the Request that matched but had no
AttributeValues in it (this strikes me as a wierd case, but
since it's allowed, this is possible). If this is the case
being described, then this should be explained so it's
clear. If this is not the case, then isn't an empty bag really
an Indterminate case? There isn't much discussion elsewhere
about what exactly AD/AS objects are expected to return, so
maybe more text in section 5 would help clarify this situation.
I'm also a little uneasy about the language because it borders
on defining programming interfaces, but I don't want to propose
alternate language until I understand what's really being
described here. What does this sentence mean?
DISCUSSION:
Summarized as: Some people think returning false when a match
compares to a missing attribute is a security problem. Other
people think returning indeterminate when a match compares to a
missing attribute is an efficiency and scalability problem,
making it hard to index on targets.
See archives for details.
We compromised by allowing the policy writer to control the
behavior: introduce an optional XML attribute
MustBePresent="<xs:boolean>" (with default false) in all
elements derived from AttributeDesignator and
AttributeSelector, including the new elements in CR#0146.
Agreed text for resolution of CR#0146 and this one should be
aligned. RESOLUTION above does this.
==================================================================
0143: [Seth Proctor] 6.15 status detail formats. Forwarded message from SethProctor.
e-mail sent 17 Oct 2002 16:56:44 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00217.html
ACTION ITEM: [Anne] Write up missing-attribute StatusDetail schema.
STATUS: APPROVED (Q 10/31). See RESOLUTION
RESOLUTION: Accept proposed text for all status codes
except for "missing-attribute". That one will use:
o <complexType>
sequence of <xacml-policy:*AttributeDesignator> 0-unbounded
or sequence of <xacml-policy:AttributeSelector>
RESOLUTION SPECIFIC TEXT:
TEXT LOCATION: Following last sentence of Section "6.15 Element
<StatusDetail>", p. 68, line 2820.
TEXT CHANGE: Append following:
Inclusion of a <StatusDetail> element is always optional.
However, if a PDP returns one of the following XACML-defined
<StatusCode> values AND returns a <StatusDetail> element,
then the format of the <StatusDetail> element MUST be as
follows:
urn:oasis:names:tc:xacml:1.0:status:ok
The PDP MUST return no <StatusDetail> element in conjunction
with this status value.
urn:oasis:names:tc:xacml:1.0:status:missing-attribute
sequence of <Attribute>
A PDP MAY choose not to return any <StatusDetail>
information or MAY choose to return a <StatusDetail>
message containing one or more <xacml-context:Attribute>
elements.
If AttributeValues are included in an Attribute, then the
PDP is specifying one or more acceptable values for that
Attribute. If no AttributeValues are included, then PDP is
simply naming attributes that it failed to resolve during
its evaluation.
The list of Attributes may be partial or complete. There
is no guarantee by the PDP that supplying the missing
values or attributes will be sufficient to satisfy the
policy.
urn:oasis:names:tc:xacml:1.0:status:syntax-error
A PDP MUST return no <StatusDetail> element in conjunction
with this status value.
A syntax error is either a problem with the policy being
used or with the Request document submitted. The PDP MAY
return a <StatusMessage> describing the problem.
urn:oasis:names:tc:xacml:1.0:status:processing-error
A PDP MUST return no <StatusDetail> element in conjunction
with this status value.
This status code indicates an internal problem in the PDP.
For security reasons, the PDP MAY choose to return no
further information to the PEP. In the case of a
divide-by-zero error or other computational error, the PDP
MAY return a <StatusMessage> describing the nature of the
error.
DISCUSSION:
When status data is returned from the PDP, it may be as
result of any number of things, four of which are defined in
the specification. For these standard cases, the PEP (or some
other entity) will need to be able to handle any extra data
that is returned in the status. But the format of status data
associated with the four standard status codes is not
defined, which is a problem. Here, therefore, is a very
simple proposal for what the formats should like.
There are undoubtedly more complex solutions, but this seems
like the most straightforward approach, and will let
different implementions act in similar ways.
==================================================================
0144: [Polar] harmful to interoperability
e-mail sent 21 Oct 2002 08:50:03 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00239.html
STATUS: APPROVED (Q 10/31). See RESOLUTION.
RESOLUTION: Don't talk about harmful anything.
Section 2.3 Combining Algorithms, last paragraph
Change the entire paragraph to:
As one of the XACML extensibility points, XACML may be extended
with alternate rule and policy combining algorithms.
CHANGE REQUEST:
"Users of the standard may, if necessary, defined their own
combining algorithms. However this approach is harmful to
interoperability..."
How is this harmful to interoperability?
Don't you mean "portability" of policies from one XACML
evaluation engine, e.g. a PDP, to another?
Also, saying that "users should specify how the combined result
is to be derived from separate evaluation of the individual
<Rule> or <Policy> statements", is not needed. It's like
telling somebody that they *should* document their
code. Although it is a notably good practice and should be
encouraged, it is kind of insulting to XACML spec readers that
would or already do so.
I would be in favor of a statement that is more focused on the
standard and not its "user" in this regard. I think what we are
after here, is just a statement that rule and policy combining
algorithms are an XACML extensibility point.
I request to change the entire paragraph to:
As one of the XACML extensibility points, XACML may be extended
with alternate rule and policy combining algorithms.
==================================================================
0145: [Seth Proctor] Multi-valued attributes in Request.
e-mail sent 22 Oct 2002 07:48:21 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00243.html
STATUS: APPROVED (Q 10/31) Change to maxOccurs=1 in Context:AttributeType
CHANGE REQUEST:
I'm looking for a clarification on the use of multiple
AttribueValue entries in an Attribute type in the Request. If I
have an Attribute with multiple AttributeValue entries, am I
supposed to treat each of these as being (effectively) separate
Attributes with the same values for their meta-data? This
seems like the logical approach, but nothing in the spec
defines the right behavior. Following from this, is it an error
if the Subject Category (for instance) Attribute has multiple
AttributeValue entries, since the spec says that there must be
one and only one value for this attribute?
DISCUSSION:
[Polar] We have multiple <AttributeValue> in attributes? You
mean in the Request Context?
That really shouldn't be.
Being that the request context is a "notational" structure,
there really insn't any need for "economy", such as it is with
XML, on these things. Also, since the <Attribute> has the
DataType attribute, and has the <AttributeValue> element which
must conform to the DataType, I really see no reason to have
such things. Why complicate matters?
The request context is "notational" and using the language of
XML schema should just say that each attribute shall have an
attribute id, a datatype, and a value for that datatype, and
may have and issuer and issue instant.
I suggest we clear this up by changing the schema to make the
attribute value occurance to minOccurs=1 maxOccurs=1.
==================================================================
0146: [Polar] CR 144: function "present" needs to be fixed.
e-mail sent 22 Oct 2002 12:25:52 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00247.html
STATUS: UNRESOLVED (11/4). Need semantics in QualifiedSubjectAttributeDesignator.
SEE ALSO: CR#0092,CR#0154
RESOLUTION: Make new XML elements in schema. Remove them from
Appendix A, put them in text description. New proposal removes
all the -must-be-present functions, since new XML attribute on
attribute designator can do that.
SPECIFIC RESOLUTION: See revised text in
http://lists.oasis-open.org/archives/xacml/200210/msg00313.html
(MSWord) or
http://lists.oasis-open.org/archives/xacml/200210/msg00314.html
(pdf)
CHANGE REQUEST:
The function "present" as we discussed yesterday in spec 18d is
vague in whether it returns "false" or raises an
"indeterminate" if the attribute is not present.
DISCUSSION:
.... (outdated discussion removed)
My conclusion: Since attributes are retrieved by different
schema elements, it seems most logical to make their
"is-present" counterparts schema elements as well, using much
of the same machinery already in place. It would be easy to add
these as element of the AttributeDeignator/Selector/Type
complex types we ALREADY have defined:
So, I think a better approach would be to add the following
elements to the schema with the semantics I proposed in the
previous iterations.
These elements would be element instances of the
<AttributeDesignatorType>:
ActionAttributeIsPresent ActionAttributeMustBePresent
ResourceAttributeIsPresent ResourceAttributeMustBePresent
EnvironmentAttributeIsPresent EnvironmentAttributeMustBePresent
These elements would be element instances of the
<SubjectAttributeDesignatorType>:
SubjectAttributeIsPresent SubjectAttributeMustBePresent
These elements would be element instances of the
<SubjectAttributeDesignatorWhereType>:
These elements can be element instances of the
<AttributeSelectorType>:
AttributeIsPresent AttributeMustBePresent
[Simon] I think that <AttributeDesignator> and
<AttributeSelector> elements with mustBePresent attribute will
cover all cases:
[Polar, responding to Simon]
No, it won't. Thas is because I will not be able to write
predicates about their presence, and only be able to get an
"indeterminate" on requesting one.
And also, again, in the Target, where these things appear, that
attribute's semantics would complicate the idexing and
retriveal of policies and rules etc etc etc.
==================================================================
0147: [Seth Proctor] Bug in pseudocode for Only One Applicable.
e-mail sent 22 Oct 2002 13:56:29 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00249.html
ACTION ITEM: [Polar] Reword, send to Tim.
STATUS: APPROVED (Q 10/28). Polar will reword.
CHANGE REQUEST:
I think there is a bug in the pseudocode for the Only One
Applicable Policy combining algorithm. The spec reads
"If an error occurs while evaluating the target of a policy
... then the policy set SHALL evaluate to 'Indeterminate'."
I think this is correct, but it's not expressed in the
pseudocode. The code calls isApplicable() on the policy to see
if the target matches, but there is no code to check if this
call resulted in an error. Small issue, but I thought I'd
mention it, since all the other combining algs can be
implemented verbatim from the given pseudocode.
==================================================================
0148a: [Yassir Elley] Example two rules not applicable to request
e-mail sent 22 Oct 2002 15:10:25 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00251.html
STATUS: APPROVED (Q 10/31)
RESOLUTION: Use
http://lists.oasis-open.org/archives/xacml/200210/msg00301.html
CHANGE REQUEST:
Example two specifies four separate rules, as well as a
request context "to which the example rules are intended to be
applicable." Unfortunately, none of the example rules are
applicable to the request context that is specified. This
should probably be fixed.
==================================================================
0148b: [Yassir Elley] Include target-namespace in Request Context?
e-mail sent 22 Oct 2002 15:10:25 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00251.html
STATUS: APPROVED (Q 10/31)
RESOLUTION: Use
http://lists.oasis-open.org/archives/xacml/200210/msg00301.html
CHANGE REQUEST:
As part of the Target, each of the rules includes a
<ResourceMatch> of <ResourceAttributeDesignator
AttributeId="urn:...:target-namespace" ...> Since
"target-namespace" is not included as a Resource Attribute in
the request context, none of the rules will ever match. Perhaps
"target-namespace" should be included as a Resource Attribute
in the request context.
==================================================================
0148c: [Yassir Elley] Syntax of RequestContextPath not consistent
e-mail sent 22 Oct 2002 15:10:25 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00251.html
STATUS: APPROVED (Q 10/31)
RESOLUTION: Use
http://lists.oasis-open.org/archives/xacml/200210/msg00301.html
CHANGE REQUEST:
Rules 1, 2, and 3 make use of an AttributeSelector as part of a
Condition. The AttribueSelector has an XML attribute named
RequestContextPath (RCP). The syntax of the RCP is inconsistent
among the rules and should be made consistent. For example:
Rule 1: RCP="//ctx:ResourceContent/md:record/" Rule 2:
RCP="/ctx:Request//ctx:ResourceContent/md:record/" Rule 3:
RCP="/ctx:Request/ctx:Resource/ctx:ResourceContent/md:record/"
==================================================================
0148d: [Yassir Elley] Move "disjunctive sequence" up to higher element description
e-mail sent 22 Oct 2002 15:10:25 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00251.html
STATUS: APPROVED (Q 10/31)
RESOLUTION: Use
http://lists.oasis-open.org/archives/xacml/200210/msg00301.html
CHANGE REQUEST:
In Section 5.6 (line 1951), it is somewhat strange that the
explanatory text for <Subject> reads "A disjunctive sequence of
<Subject> elements." This seems more appropriate for the
<Subjects> element. This same pattern occurs with the
explanatory text for <Resource> (line 2015) and <Action> (line
2078)
==================================================================
0148e: [Yassir Elley] Editorial comments
e-mail sent 22 Oct 2002 15:10:25 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00251.html
STATUS: Editorial. No vote required.
CHANGE REQUEST:
1041: insert "//" (i.e. "http://www.medico.com";;)
1049: insert "//" (i.e. "http://www.medico.com";;)
1069: replace "[14]-[72]" with "[15]-[22]"
1085: Rule 1 states "A person may read any record for which he or
she is the designated patient." In Example 4.2.4.1, however,
the policy-number in the medical record is compared with
the policy-number attribute of the subject. This is slightly
confusing.
1107: replace "scheams" with "schemas"
1131: replace "xpath-match" with "xpath-node-match"
1184: replace "authorization decision request such, that the value" with
"authorization decision request, such that the value"
1201: insert "the" before "explicit value"
1296: replace "xpath-match" with "xpath-node-match"
1346: "md:parentGuardianId" doesn't exist in example medical record.
It should be added.
1541: "md:physicianId" doesn't exist in example medical record. There is
however a "registrationId". These should be made consistent.
1600: replace "exampes:attributes:group" with "example:attribute:role"
1604: replace "read" with "write"
1675: replace "xpath-match" with "xpath-node-match"
1726: replace ""read"" with ""read" or "write""
1933: remove duplicate "for the"
2225: insert ",action," after "resource"
2280: <SubjectAttributeDesignator> is missing
2333: replace "Shall" with "SHALL"
2384: replace "contains following attributes" with "contains the
following attribute"
2434: insert "in" after "resulting"
2599: replace "Distingwished" with "Distinguished"
2704: replace "dn" with "DN"
3286: resource:resource-id is marked as Optional. Earlier, the spec
specifies that "the <Resource> element MUST contain one
and only one <Attribute> with AttributeId "urn:...:resource-id".
This should probably be marked Mandatory, not Optional.
3920: replace "second" with "third"
4696: replace "CombinginAlogrithm" with "CombiningAlgorithm"
==================================================================
0149: [Seth Proctor] Environment attributes
e-mail sent 23 Oct 2002 12:22:39 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00253.html
http://lists.oasis-open.org/archives/xacml/200210/msg00292.html (specific resolution)
ACTION ITEM: [Anne] Reword to fit into Section 7 as a new sub-heading.
STATUS: APPROVED (Q 10/31).
RESOLUTION: ContextHandler MUST supply a value for these
attributes.
SPECIFIC RESOLUTION:
TEXT LOCATION: 10.3.5 Attributes, following "...their semantics
are not transparent to the PDP implementation."
TEXT CHANGE: Append:
If a value for one of these attributes is supplied in the
original Request, then the PDP SHALL use that value.
Otherwise, the PDP SHALL supply a value. For the date and
time attributes, the supplied value SHALL have the semantics
of "date and time that apply to the Request". For the
subject-category attribute, the supplied value is the default
value of
"urn:oasis:names:tc:xacml:1.0:subject-category:access-subject".
TEXT LOCATION: 10.3.5 Attributes, at end of table of attribute
identifiers, following ...current-dateTime M.
TEXT CHANGE: Append:
urn:oasis:names:tc:xacml:1.0:subject:subject-category M
TEXT LOCATION: 10.3.6 Identifiers, first paragraph, following
"...since the semantics of the attributes are transparent to
the PDP."
TEXT CHANGE: Delete the following sentence:
The attribute
"urn:oasis:names:tc:xacml:1.0:subject:subject-category" MUST be
supported, since it is implicit with a value of
"urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
if no other subject-category attribute value is specified.
CHANGE REQUEST:
In section 10.3.5 of 18d, the spec calls out three attribute
identifiers that the PDP must be able to handle specially
(these are current-time, current-date, and
current-dateTime). Is the idea that these would appear in an AD
in a policy, and the PDP is supposed to know to resolve these
values itself rather than looking in the Request? I think
that's the idea, but it's not spelled out explicitly in the
text.
DISCUSSION:
Summarized. See thread in archives for details.
a) Sometimes the PEP wants to know what the decision would be
if access were to be requested at a particular date/time.
This might also be useful for debugging and testing. For
example:
Can Joe get into the building at 8am tomorrow?
Was John allowed in the building at 6pm yesterday?
b) Only way to get a consistent response to a given request is
to have the date/time supplied by the PEP: PDP clock may be
skewed with respect to PEP clock, PDP may take a long time
to evaluate the request, etc. [time-zone differences can be
handled by using universal time]
c) Many policies will not depend on time, so why do we force
the PEP to supply it in every case?
d) Auditing at the PDP will want to know when the PDP made the
decision, not what value the PEP supplied.
e) Timestamp used on PDP audit records need not depend on some
time/date value used in evaluating the request.
==================================================================
0150: [Seth Proctor] Types of pre-defined attributes
e-mail sent 23 Oct 2002 12:22:39 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00253.html
STATUS: RESOLVED (Q 10/24). Superseded by 0134c.
CHANGE REQUEST:
...these go on that list I started earlier of attributes that
should be defined to always be of a particular type:
subject-category string or URI
resource-id string or URI
scope string
current-time ???
current-date date
current-dateTime dateTime
Since each of these identifiers must be special-cased by the
PDP, they must always be of a known type. There may be others
that should be on this list, but most of the other identifiers
are not treated in any special way by the PDP, so the type
information is transparent to the PDP.
==================================================================
0151: [Seth Proctor] editorial: 10.3.6 extraneous paragraph
e-mail sent 23 Oct 2002 14:38:32 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00254.html
STATUS: Editorial. No vote required.
CHANGE REQUEST:
In section 10.3.6, the 2nd paragraph isn't needed, since it's
the same as the first two sentences of the 1st paragraph.
==================================================================
0152: [Tim Moses] Trivial Matter
e-mail sent 28 Oct 2002 09:31:24 -0500
http://lists.oasis-open.org/archives/xacml/200210/msg00285.html
STATUS: APPROVED (Q 10/31). See RESOLUTION.
SEE ALSO: CR#0154
RESOLUTION: Change name of <AttributeDesignatorWhere> (...Type)
to <QualifiedSubjectAttributeDesignator>.
CHANGE REQUEST:
We should call the <SubjectAttributeDesignatorWhere> element
<SubjectQualifier>.
DISCUSSION:
I recognize at least two styles for naming elements,
attributes, etc.: the "descriptive" style and the "literate"
style. In the "descriptive" style, the name is chosen in an
attempt to reflect the semantics of the element. In the
"literate" style, the name is chosen in an attempt to make the
"source" "read". I contend that we have almost exclusively
chosen the descriptive style. Consider the XML attribute
"FunctionId". If we had been following the literate style, we
would have chosen the name "Function". Then the Apply element
would read ...
<Apply Function ...
instead of ...
<Apply FunctionId ...
I think either style would be acceptable (although both Polar
and I have declared that we never want to read an XACML policy
in its native form). But, I would like us to be consistent in
our application of a single style.
Therefore, I propose that we use the descriptive style of
naming and that we choose <SubjectQualifier> instead of
<SubjectAttributeDesignatorWhere>. It has the additional
benefit of being half the size.
I also considered <SubjectSelector>, but thought that was too
similar to <SubjecAttributeSelector>.
=================================================================
0153: [Polar] Issuer is xs:string in Context/xs:anyURI in policy
e-mail sent 29 Oct 2002 13:26:55 -0500 (EST)
http://lists.oasis-open.org/archives/xacml/200210/msg00293.html
STATUS: NEEDS QUORUM. RESOLVED (NQ 11/4). Use xs:string" in both places.
CHANGE REQUEST:
The Issuer is an "xs:string" in the context, and "xs:anyURI" in
the policy. (I am looking at 16j)
=================================================================
0154: [Seth Proctor] [Schema/Text Change] SubjectQualifier/SubjectAttributeDesignatorWhere
e-mail sent 30 Oct 2002 15:22:32 -0500 (EST)
http://lists.oasis-open.org/archives/xacml/200210/msg00305.html
STATUS: UNRESOLVED. See partial RESOLUTION and OPEN ISSUE (NQ 11/4)
SEE ALSO: CR#0092, CR#0146, CR#0152
OPEN ISSUE:
1) How to deal with missing attributes when evaluating
a QualifiedSubjectAttributeDesignator. If
MustBePresent="true" on SubjectAttributeDesignator inside
the new <SubjectQualifier> element, does this mean that
every single <Subject> MUST contain an instance of that
Attribute or else the QualifiedSubjectAttributeDesignator
returns Indeterminate? This is the same issue being
addressed in CR#0092.
2) If multiple <Subject> blocks match the
QualifiedSubjectAttributeDesignator, then how does Policy
know which returned attributes go with which <Subject>?
RESOLUTION:
On 11/4, we agreed on the following changes to
address the original Change Request.
1) Replace all existing policy schema references to
"SubjectAttributeDesignator" with "CategorizedSubjectAttributeDesignator"
2) After doing 1), add the following fragment to the policy
schema:
<xs:element name="SubjectAttributeDesignator"
type="xacml:AttributeDesignatorType"/>
3) After doing 2), replace following policy schema fragment:
<xs:element name="SubjectAttributeDesignatorWhere" type="xacml:SubjectAttributeDesignatorWhereType"/>
<xs:complexType name="SubjectAttributeDesignatorWhereType">
<xs:complexContent>
<xs:extension base="xacml:AttributeDesignatorType">
<xs:sequence>
<xs:element ref="xacml:SubjectMatch" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
with
<xs:element name="QualifiedSubjectAttributeDesignator"
type="xacml:QualifiedSubjectAttributeDesignatorType"/>
<xs:complexType name="QualifiedSubjectAttributeDesignatorType">
<xs:complexContent>
<xs:extension base="xacml:AttributeDesignatorType">
<xs:sequence>
<xs:element ref="xacml:SubjectQualifier"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="SubjectQualifier
type="xacml:SubjectQualifierType"/>
<xs:complexType name="SubjectQualifierType">
<xs:sequence>
<xs:choice>
<xs:element ref="xacml:SubjectAttributeDesignator"/>
<xs:element ref="xacml:AttributeSelector"/>
<xs:choice>
<xs:element ref="xacml:AttributeValue"/>
</xs:sequence>
<xs:attribute name="MatchId" type="xs:QName" use="required"/>
</xs:complexType>
CHANGE REQUEST:
I think there's a problem with the schema involving the
SubjectAttributeDesignatorWhere (or the proposed name
SubjectQualifier, which I like more). It used to extend
SubjectAttributeDesignatorType, but with the addition of the
category element, it now only extends
AttributeDesignatorType. It still contains, however, a list of
SubjectMatchType, which in turn use
SubjectAttributeDesignatorType as their designator.
Shouldn't the match elements also extend
AttributeDesignatorType and not SubjectAttributeDesignatorType
in the SubjectQualifier? I think this needs a new match type
that uses AttributeDesignator but is specified in the spec to
look in the subject section of the request for all attributes.
DISCUSSION:
[Polar] In writing the stuff for the subjects, I've encountered
a problem for the QualifiedSubjectAttributeDesignator. I think
Seth was onto something in 0154 and 0155, but perhaps missed it
a bit.
The SubjectAttributeDesignator takes AttributeId, DataType,
MustBePresent, and SubjectCategory. It restricts the lookup of
the named subject attributes to the <Subject> matching the
SubjectCategory.
The QualifiedSubjectAttributeDesignator performs no such
category restriction. It just takes AttributeId, DataType,
MustBePresent, plus a bunch of <SubjectMatch>. The
<SubjectMatch>s are supposed to be restricted to one subject.
The only problem is that each SubjectMatch has an
SubjectAttributeDesignator in it, which *ALREADY* restricts the
look up to a particular subject matching the subject category.
So, as a result, a QualifiedSubjectAttributeDesignator must
have SubjectMatches all with the SAME subject category, or it
wont retrieve anything. Also, having one SubjectMatch restricts
it already to one Subject just by virtue of the category, which
I think is not the case we want.
[Polar] I suggest that we change the current
SubjectAttributeDesignatorType to
CategorizedSubjectAttributeDesignatorType
and have
CategorizedSubjectAttributeDesignator
and keep the SubjectAttributeDesignator a simple instantiation
of AttributeDesignatorType as it was before we added the
SubjectCategory attribute.
[Seth, responding to Polar] Is the intent to add a new AD type
to those allowed in an Apply, and therefore also create a new
MatchType? This might be overkill, though it could be useful.
=================================================================
0155: [Seth Proctor] Name for match element inSubjectQualifier/SubjectAttributeDesignatorWhere
e-mail sent 30 Oct 2002 15:28:10 -0500 (EST)
http://lists.oasis-open.org/archives/xacml/200210/msg00306.html
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See RESOLUTION.
SEE ALSO: CR#0154
RESOLUTION: See #0154. The name of the sequence of elements
inside the
QualifiedSubjectAttributeDesignator/SubjectAttributeDesignatorWhere
is changed from SubjectMatch to SubjectQualifier.
CHANGE REQUEST:
This is a followup to my last email on Match types in the
SubjectQualifier ([xacml] Problem in
SubjectQualifier/SubjectAttributeDesignatorWhere). If I'm
right, and that structure needs to change, I would like to
request that it not have the same name as the other match
objects (ie, it should not be called something that looks like
SubjectMatchType). While it is similar in structure to the
other match types, the "match" elements used in the qualifer
are symantically an entirely different thing, and should
therefore be logically separated by using a different name, and
should not be covered by the same explanitory text in the spec.
=============================================================================
0156: [Seth Proctor] ObligationType
e-mail sent 31 Oct 2002 10:15:16 -0500 (EST)
http://lists.oasis-open.org/archives/xacml/200210/msg00312.html
STATUS: UNRESOLVED
CHANGE REQUEST:
The ObligationType used to have a choice between an AttributeAssignment
or an AttributeDesignator, but now you can only have the AA. As such, the
xs:choice should probably be changed to xs:sequence, just to stay consistent
with schema language.
=================================================================
0157: [Steve Hanna] Glitch in moving from decimal to double
e-mail sent 31 Oct 2002 13:08:08 -0500 (EST)
http://lists.oasis-open.org/archives/xacml/200210/msg00315.html
STATUS: UNRESOLVED
CHANGE REQUEST:
I see that v18e reflects the TC's decision to move from
xsi:decimal to xsi:double. I'm pleased with this decision,
but I noticed a problem:
The document cited as defining the arithmetic functions
([IBMSDA]) does not exist. Or at least the URL given in
the document (http://www2.hursley.ibm.com/double/decarith.html)
does not work. I suspect that this is the result of a
global search and replace operation, changing decimal
to double.
I suggest that this reference be replaced with IEEE 754,
which defines binary floating point arithmetic and is
cited by XML Schema for that purpose.
=================================================================
0158: [Simon] [Schema Change] Redefine <AttributeValueType>
raised during Subcommittee call on 11/4/02
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4)
RESOLUTION:
1) In the context schema, replace following:
<xs:element name="AttributeValue" type="xs:anyType"/>
with:
<xs:element name="AttributeValue"
type="xacml-context:AttributeValueType"/>
<xs:complexType name="AttributeValueType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
2) In the policy schema, replace following:
<xs:complexType name="AttributeValueType">
<xs:complexContent>
<xs:extension base="xs:anyType">
<xs:attribute name="DataType" type="xs:anyURI" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
with:
<xs:complexType name="AttributeValueType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="DataType" type="xs:anyURI" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
CHANGE REQUEST: Define <AttributeValueType> in both the
policy and the context schemas in the same way that
context:ResourceContent is now specified.
RATIONALE: Validating parsers are happier with this way of
specifying an "any" type>
=================================================================
0159: [Anne] [Text Change] Appendix B: Describe XACML attributes better
e-mail sent 01 Nov 2002 11:56:332 -0500 (EST)
http://lists.oasis-open.org/archives/xacml/200211/msg00000.html
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST.
CHANGE REQUEST:
1. B.5 Subject attributes: Change initial paragraph from:
"These identifiers indicate attributes of a subject. At most
one of each of these attributes is associated with each
subject. Each attribute associated with authentication
relates to the same authentication event.
To:
"These identifiers indicate attributes of a subject. When
used, they SHALL appear within a <Subject> element of the
Request Context. They SHALL be accessed via a
SubjectAttributeDesignator, a
QualifiedSubjectAttributeDesignator, or an AttributeSelector
pointing into a <Subject> element of the Request Context.
At most one of each of these attributes is associated with
each subject. Each attribute associated with authentication
included within a single <Subject> element relates to the
same authentication event.
2. B.6 Resource attributes: Add introductory sentence saying:
"These identifiers indicate attributes of the resource being
accessed. When used, they SHALL appear within the <Resource>
element of the Request Context. They SHALL be accessed via a
ResourceAttributeDesignator or an AttributeSelector pointing
into the <Resource> element of the Request Context."
3. B.7 Action attributes: Add introductory sentence saying:
"These indentifiers indicate attributes of the resource being
accessed. When used, they SHALL appear within the <Action>
element of the Request Context. They SHALL be accessed via a
ActionAttributeDesignator or an AttributeSelector pointing
into the <Action> element of the Request Context."
4. B.8 Environment attributes: Add introductory sentence saying:
"These identifiers indicate attributes of the environment
within which the request is to be evaluated. When used, they
SHALL appear within the <Resource> element of the Request
Context. They SHALL be accessed via an
EnvironmentAttributeDesignator or an AttributeSelector
pointing into the <Environment> element of the Request
Context."
RATIONALE: the way in which these attributes are to be used is
not explicitly stated anywhere. While the names imply a usage,
it would be more clear to implementors if the usage were more
explicit.
=================================================================
0160: [Anne] [Text Change] Appendix B: Describe XACML attributes better
e-mail sent 01 Nov 2002 12:45:10 -0500 (EST)
http://lists.oasis-open.org/archives/xacml/200211/msg00001.html
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST.
CHANGE REQUEST: (Example revised per Polar e-mail and 11/4 discussion)
In Section A.3 Structured types, item 1., paragraph starting
with "1, change second sentence from:
"This requires the structured data, including its tags and
attributes, to be identified and treated as an instance of
the data-type xsi:string."
To:
"This requires the structured data <AttributeValue> to be
given the DataType="xsi:string". For example, a structured
data type that is actually a ds:KeyInfo/KeyName would appear
in the Context as:
<AttributeValue
DataType="DataType="http://www.w3.org/2001/XMLSchema-instance#string";><ds:KeyName>jhibbert-key</ds:KeyName></AttributeValue>
RATIONALE: Way#1 could be read as implying that the structured
data type is automatically cast or converted to the type
required by the function that references it. We should be very
clear that this does NOT occur.
DISCUSSION:
[Anne, responding to Polar]
> Now, if you do not regard the data as a string, and you actually give
> it a data type, i.e. extension to standard XACML, I wonder what happens
> for the following problem.
>
> Does the data within the attribute value have to be completely contained?
>
> For example, if you have <ds:KeyName>jhibberi-key</ds:KeyName> where is
> the "ds:" name space defined? (In the begining of the context? of which it
> cannot be guarranteed to be there) Or in the attribute value?
The ds: name space must be defined in the beginning of the
context if "ds:" is used in an XML fragment. If it is not
defined there, then there will be an error parsing the XML
context.
=================================================================
0161: [Anne][Schema Change] editorial: "FulfillOn", not "FulfilOn"
e-mail sent 01 Nov 2002 12:52:45 -0500 (EST)
http://lists.oasis-open.org/archives/xacml/200211/msg00002.html
STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST.
CHANGE REQUEST:
In policy schema, <xs:complexType name="ObligationType">,
change <xs:attribute name="FulfilOn" to <xs:attribute
name="FulfillOn"
RATIONALE: Spec uses "FulfillOn", and we decided in a TC
meeting to use that spelling. Schema just has not been brought
into agreement yet.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC