[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Update open Change Requests list
The attached Change Requests lists includes all those requests
that are still unresolved against v0.18c.doc. It reflects all
e-mail up to and including
http://lists.oasis-open.org/archives/xacml/200210/msg00229.html
Subject: RE: [xacml] bags and targets. Forwarded message from Seth Proctor .
* From: Polar Humenn <polar@syr.edu>
* To: Anne Anderson <Anne.Anderson@Sun.com>
* Date: Fri, 18 Oct 2002 14:28:50 -0400 (EDT)
This will be the basis for our Monday discussion, although
additional items will certainly arrive by e-mail after I mail
this out :-)
The most difficult issues seem to be:
0076: [Anne] AA02: New section in Appendix A on Structured datatypes
0098: [Anne] AA11: Clarify "MatchId" functions
0135: [Anne] AA45: make data-flow diagram consistent with 7.7 Use profile for XACML request
0142: [Seth Proctor] bags and targets. Forwarded message from Seth Proctor.
Please try to read through at least these.
This is not to imply that other open issues are not important,
but I think most of them are either
a) fairly clear, or
b) are technical issues on how XML should be used for particular
things (for resolution among our XML experts), or
c) are technical issues related to implementation problems
(requiring discussion and consensus among actual
implementers).
So scan the rest for those issues that you may be able to
contribute to.
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.6, 02/10/18 (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.
See
http://lists.oasis-open.org/archives/xacml/200210/msg00214.html
for the changes previously approved to v0.18c.doc.
The most difficult issues seem to be:
0076: [Anne] AA02: New section in Appendix A on Structured datatypes
0098: [Anne] AA11: Clarify "MatchId" functions
0135: [Anne] AA45: make data-flow diagram consistent with 7.7 Use profile for XACML request
0142: [Seth Proctor] bags and targets. Forwarded message from Seth Proctor.
LEGEND
======
NQ=no quorum; official vote required
Q=quorum
SUMMARY
=======
0076: [Anne] AA02: New section in Appendix A on Structured datatypes
STATUS: OPEN. Revised text sent to list 17 Oct 2002.
0086: [Hal] HL03: Question about Anonymous Access Subject
STATUS: REJECTED (10/17 Q). Submit specific proposals if changes needed.
0092: [Polar] PH09: New section 7.4.2 Attributes
STATUS: OPEN. 7.4.2.2 revised.
0098: [Anne] AA11: Clarify "MatchId" functions
STATUS: DISCUSSED 10/17. STILL OPEN.
0100: [Steve Hanna] SteveHanna01: integer-mod takes two arguments
STATUS: Not yet considered.
0101: [Satoshi Hada] SatoshiHada01: How many namespaces does XACML define?
STATUS: not yet considered.
0102: [Anne] AA13: Remove B.11 Identifiers used in conformance tests
STATUS: not yet considered.
0121: [Anne] AA32: clarify use of "dn"
STATUS: not yet considered.
0132: [Anne] AA43: use "xs:" or "xsi:"?
STATUS: not yet considered.
0134: [Seth Proctor] SP01: 18c comments. Forwarded message from Seth Proctor.
STATUS: Not yet considered.
0135: [Anne] AA45: make data-flow diagram consistent with 7.7 Use profile for XACML request
STATUS: not yet considered.
0136: [Anne] AA46: Make 3.2 XACML context consistent with 7.7 Use profile for XACML request
STATUS: not yet considered.
0137: [Steve Hanna] SteveHanna02: xs:decimal string representation
STATUS: not yet considered.
0138: [Steve Hanna] SteveHanna03: Use of decimal math should be justified
STATUS: not yet considered.
0139: [Steve Hanna] SteveHanna04: handling of divide-by-zero
STATUS: not yet considered.
0140: [Michiharu] MK01: DataType and Namespace
STATUS: not yet considered.
0141: [Simon] SG[??]: data type uri's
STATUS: not yet considered.
0142: [Seth Proctor] bags and targets. Forwarded message from Seth Proctor.
STATUS: not yet considered.
0143: [Seth Proctor] 6.15 status detail formats. Forwarded message from SethProctor.
STATUS: not yet considered.
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: OPEN. Revised text sent to list 17 Oct 2002.
TEXT LOCATION: Section A, following "A.2 Primitive
types" (p. 86, between lines 3345 and 3346 in my copy of 0.18c)
REVISED TEXT CHANGE: Add following new section as follows:
A.3 Structured types
An XACML <AttributeValue> MAY contain an instance of a
structured xml data type, for example <ds:KeyInfo>. XACML
1.0 supports several ways for comparing such <AttributeValue>s.
1) In some cases, such an <AttributeValue> MAY be compared
using one of the XACML string functions, such as
regexp-string-match, described below. This requires the
structured data, including its tags and attributes, to be
identified and treated as an instance of DataType
<xs:string>. In general, this method will not be adequate
unless the structured data type is quite simple.
2) An <AttributeSelector> element MAY be used to select the value
of a leaf sub-element of the structured data type. That value
MAY then be compared using one of the supported XACML
functions appropriate for its primitive data type. This
method requires support by the PDP for the optional XPath
expressions feature.
3) An <AttributeSelector> element MAY be used to select the value
of any node in the structured type. This node MAY then be
compared using one of the XPath-based functions described
in "Section A.13.13 XPath-based functions". This method
requires support by the PDP for the optional XPath
expressions and XPath functions features.
4) For a given structured data type, a community of XACML
users MAY define new attribute identifiers for each leaf
sub-element of the structured data type that has a type
conformant with one of the XACML-defined primitive
datatypes. Using these new attribute identifiers, the
PEPs or context handlers used by that community of users
can flatten instances of the structured data type into a
sequence of individual <Attribute>s. Each such
<Attribute> can be compared using the XACML-defined
functions. Using this method, the structured data type
itself never appears in an <AttributeValue> element.
5) A community of XACML users MAY define a new function that
can be used to compare a value of the structured datatype
against some other value. This method may only be used by
PDPs that support the new function.
DISCUSSION:
[Polar] I don't really like all of this.
1) I don't mind this as long as the DataType is specified in
the Attribute in the Context, not as a "ds:KeyInfo" but as
"xs:string".
2) This is fine.
3) This is fine as well.
> 4) For a given structured data type, a community of XACML
> users MAY define new attribute identifiers for each leaf
> sub-element of the structured data type that has a type
> conformant with one of the XACML-defined primitive
> datatypes. Using these new attribute identifiers, the
> PEPs or context handlers used by that community of users
> can flatten instances of the structured data type into a
> sequence of individual <Attribute>s. Each such
> <Attribute> can be compared using the XACML-defined
> functions. Using this method, the structured data type
> itself never appears in an <AttributeValue> element.
Anne,
I'm starting to understand what your getting at, but I'm really
puzzled why we need this functionality in simple Attribute
Designators.
How does this work? Do you have a specific example? This seems
like new functionality to me. Before we had attribute
identifiers that simply indexed out of the particular Subject,
Action or Resource section.
Do we now have to understand a attribute identifier syntax that
indexes into the datatype? How can that be general and simple
enough given the complexity of XPath on this issue?
Also, between 4-5, I don't know what a "community of XACML
users" is.
I think it would be better to state just that XACML may be
extended with alternate datatypes and the functions that
operate on them. However, that is covered by Appendix A.13.14
Extension functions and primitive types.
You just may want to say that the contents of the attribute may
be an XML structure.
I think I would feel more comfortable that if you are going to
extend XACML, you should go the whole way in extending XACML by
also creating "selector" functions for the structured type that
select primitive types out of the structured datatype, such as:
<Apply FunctionId="ext:get-public-key">
<Apply FunctionId="ext:keyInfo-one-and-only">
<SubectAttributeDesignatorWhere AttributeId="urn:....:key-info">
<SubjectMatch MatchId="function:string-equals">
<SubjectAttributeDesignator
AttributeId="urn:...subject-category"
DataType="xs:QName"
/>
<AttributeValue DataType="xsQName">urn:....:access-subject</AttributeValue>
</SubjectMatch>
</SubjectAttributeDesignatorWhere>
</Apply>
</Apply>
where ext:keyInfo-one-and-only takes a bag of ds:KeyInfo and
returns a ds:KeyInfo if and only if there is only one element
in the bag, indeterminate otherwise.
[Anne, responding to Polar] On 17 October, Polar Humenn writes:
> > 1) In some cases, such an <AttributeValue> MAY be compared
> > using one of the XACML string functions, such as
> > regexp-string-match, described below. This requires the
> > structured data, including its tags and attributes, to be
> > identified and treated as an instance of DataType
> > <xs:string>. In general, this method will not be adequate
> > unless the structured data type is quite simple.
>
> I don't mind this as long as the DataType is specified in the
> Attribute in the Context, not as a "ds:KeyInfo" but as "xs:string".
As it says, "This requires the structured data, including its
tags and attributes, to be identified and treated as an
instance of DataType <xs:string>."
> > 4) For a given structured data type, a community of XACML
> > users MAY define new attribute identifiers for each leaf
> > sub-element of the structured data type that has a type
> > conformant with one of the XACML-defined primitive
> > datatypes. Using these new attribute identifiers, the
> > PEPs or context handlers used by that community of users
> > can flatten instances of the structured data type into a
> > sequence of individual <Attribute>s. Each such
> > <Attribute> can be compared using the XACML-defined
> > functions. Using this method, the structured data type
> > itself never appears in an <AttributeValue> element.
> How does this work? Do you have a specific example? This seems like new
> functionality to me. Before we had attribute identifiers that simply
> indexed out of the particular Subject, Action or Resource section.
Just as we defined specific attributes for the components of a
SAML SubjectStatement -- subject-id, subject-id-qualifier,
key-info, authentication-time, authentication-method,
authn-locality:ip-address, authn-locality:dns-name -- another
industry consortium etc. ("community of users") could define
specific attributes for the components of some other structured
data type of interest to them.
> Do we now have to understand a attribute identifier syntax that indexes
> into the datatype? How can that be general and simple enough given the
> complexity of XPath on this issue?
No, I was very clear that it is the PEP or the context handler
that would have to understand how to do this indexing/mapping,
just as they have to do the work of translating a SAML
SubjectStatement into our individual attributes.
> Also, between 4-5, I don't know what a "community of XACML users" is.
An industry consortium, some standards body, etc. Any group of
users that want to agree on some attributes for
interoperability between themselves about values of use within
their community.
> I think it would be better to state just that XACML may be extended with
> alternate datatypes and the functions that operate on them. However, that
> is covered by Appendix A.13.14 Extension functions and primitive types.
But I'm trying to explain how this extensibility can be applied
in the specific case of addressing a structured data type. I
can point to A.13.14 for more information, but A.13.14 by
itself will not be an obvious solution to people trying to deal
with a structured XML data type that XACML has not already
defined individual attribute ids for.
> You just may want to say that the contents of the attribute may be an XML
> structure.
That is case 2), 3), or 5). In this case, 4), the PDP will
never see the XML structure because the PEP or the context
handler will have broken it down before it appears in the
Request Context.
> I think I would feel more comfortable that if you are going to extend
> XACML, you should go the whole way in extending XACML by also creating
> "selector" functions for the structured type that select primitive types
> out of the structured datatype, such as:
>
> <Apply FunctionId="ext:get-public-key">
> <SubectAttributeDesignatorWhere AttributeId="urn:....:key-info">
> <SubjectMatch MatchId="function:string-equals">
> <SubjectAttributeDesignator
> AttributeId="urn:...subject-category"
> DataType="xs:QName"
> />
> <AttributeValue DataType="xsQName">urn:....:access-subject</AttributeValue>
> </SubjectMatch>
> </SubjectAttributeDesignatorWhere>
> </Apply>
>
> where ext:get-public-key
> takes a ds:keyInfo and returns an xs:base64Binary, which is the public key
> from the <whatever> element of a ds:KeyInfo type.
But we have XPath for that. I don't want to define yet another
"selector" mechanism. Cases 2) and 3) cover using XPath for
that. I have described 4) and 5) for people who don't want to
use XPath (for the same reasons we don't just use XPath for
XACML SubjectStatement elements).
0086: [Hal] HL03: Question about Anonymous Access Subject
e-mail sent 11 Oct 2002 11:56:37 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00126.html
STATUS: REJECTED (10/17 Q). Submit specific proposals if changes needed.
Is there a cannonical way to represent an anonymous access
subject in the Request Context? This seems to me to be an
extremely common case that should be described in the spec. (My
preference would be to leave out the access subject entirely,
but I see that it is mandatory)
[Anne] Yes, there is a canonical way. The sequence of
Attributes under <Subject> is minOccurs=0, so you can have a
Request Context in which the one <Subject> element has no
Attributes (such as no subject-id).
[Polar] A question that we are wrestling with in our logical
analysis of the security protocols, namely CSIv2, is whether
not having a prncipal is really an anonymous principal.
I think we are finding that there is a "default" principal, of
which you associated a principal with by either configuration
(let's say a request that comes over a VPN).
Also, you can assert an anonymous principal, which actually
states that you really do not know who it is. This principal is
supremely weaker than all other principals.
We might come up with a particular identifier saying
"Anonymous", but should make sure it isn't used for the
"default" case, unless the default case is truly anonymous.
In constrast to the default case, we could have a "default"
principal id, or, we direct the PEP to "fill" the principal in
with the default principal's id.
[Daniel] ..And to write rules on anonymous subject I presume
one has to use <anysubject> for target? Right? Does missed
subject have applicable rules written on <anysubject> ?
[Bill] that was my understanding.
[10/17 concall] Current document does not contain any
references to "anonymous".
If someone thinks we need explicit text on how to deal with
"anonymous" subjects, or if someone thinks we need an explicit
identifier for an "anonymous" subject, then that person needs
to submit a new change request with a use case, specific
locations to change, and specific text to use.
We may want to submit to SAML some specific values for the
"authn-method" attribute, such as: "intentionally anonymous",
"not authenticated", "authenticated by say so", "unknown", etc.
"No subject attributes" is not equivalent to "anonymous".
We agreed that it is permissible to omit all <Attribute>s from
the <Subject> and it is possible to refer to such a <Subject>
by using <AnySubject>. Neither of these requires any changes
to the existing text or schemas.
0092: [Polar] PH09: New section 7.4.2 Attributes
e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00141.html
http://lists.oasis-open.org/archives/xacml/200210/msg00207.html (revised 7.4.2.2)
STATUS: OPEN. 7.4.2.2 revised.
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.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: On 17 Oct 2002, we approved the following sections.
Polar was asked to revise the "Missing Attributes" section that
followed, and that is what is shown above.
7.4.2 Attributes
Attributes are specified in the request context and are
referred to in the policy by the subject, resource, action,
and environment attribute designators or selectors. Each
attribute specifies an AttributeId and a DataType, and each
attribute desigator specifies an AttributeId and
DataType. Attribute Designators and Attribute Selectors SHALL
match attributes by using string equality on both the
AttributeId and DataType values.
7.4.2.1 Attribute Retrieval
The PDP SHALL retrieve the values of attributes that match
the particular attribute designator or attribute selector and
form them into a bag of values with the specified
DataType. If no attributes from the request context match,
the attribute shall be considered missing, and an empty bag
is said to be retrieved.
0098: [Anne] AA11: Clarify "MatchId" functions
e-mail sent 14 Oct 2002 09:48:04 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00151.html
STATUS: DISCUSSED 10/17. STILL OPEN.
TEXT LOCATION: Section A.11 Matching elements, p. 89, lines
3446-3456.
TEXT CHANGE: [Bag functions omitted per comment from Polar]
Replace following paragraph:
"The match elements: <SubjectMatch>, <ResourceMatch> and
<ActionMatch> SHALL use XACML standard functions to perform
the match evaluation. The function used for determinaing a
match is named in the MatchId attribute of these elements.
Each of these elements contains a <AttributeDesignator> or
<AttributeSelector> element and an explicit attribute value.
The restriction on the function is that the MatchId attribute
must name a binary function, such that its result type is
"xs:boolean". Also, each argument to the named function must
match the appropriate primitive types for the
<AttributeDesignator> or <AttributeSelector> element and the
following explicit attribute value, such that the explicit
attribute value is placed as the first argument to the
function, while an element of the bag returned by the
<AttributeDesignator> or <AttributeSelector> element is placed
as the second argument to the function."
with the following:
"The match elements: <SubjectMatch>, <ResourceMatch> and
<ActionMatch> SHALL use functions that match two arguments,
returning a result type of "xs:boolean", to perform the match
evaluation.The function used for determinaing a match is named
in the MatchId attribute of these elements. Each argument to
the named function must match the appropriate primitive types
for the <AttributeDesignator> or <AttributeSelector> element
and the following explicit attribute value, such that the
explicit attribute value is placed as the first argument to
the function, while an element of the bag returned by the
<AttributeDesignator> or <AttributeSelector> element is placed
as the second argument to the function.
The XACML standard functions that may be used as a MatchId
attribute value are:
function:*-equal
function:*-greater-than
function:*-greater-than-or-equal
function:*-less-than
function:*-less-than-or-equal
function:*-match
DISCUSSION: explanation of which functions may be used as MatchId
functions is not clear. Also, function used need not be a
"standard" function as long as it returns a boolean and its
arguments follow the required format.
[10/17 concall] There appear to be three points of view with
respect to <Target>:
1) <Target>/<Condition> is a way to divide the evaluation into
an "easy" part and a "hard" part, so that many potentially
applicable policies can be easily eliminated without having
to evaluate the "hard" part. The policies may be in a
database, or may be explicitly included or referenced from
another policy set. Target is an aid to indexing, but is
not the complete way policies are indexed. [This view is
reflected in this Change Request]
2) <Target> is designed to help search for the initial
applicable policy in a database based on an incoming
request. Any functions of the specified type (return
boolean, take Designator/Selector and explicit
AttributeValue as two args) that are supported by SQL and
LDAP should be permitted.
3) <Target> is designed for searching an index of potential
policies or rules. Only XACML standard *-equal functions
should be permitted in a "MatchId". There was a
Apparently, there was a vote taken on this earlier that
supported 3), and Daniel was apparently strongly in favor of
this. [Anne: I can not find any record of such a vote in our
Change lists.]
Use cases and more discussion are required to resolve this.
0100: [Steve Hanna] SteveHanna01: integer-mod takes two arguments
personal communication to Anne Anderson on 14 Oct 2002
STATUS: Not yet considered.
TEXT LOCATION: Section A.13.2 Arithmetic functions, p. 92,
4569, list of functions that take a single argument.
TEXT CHANGE: Move "integer-mod" up to the list of functions
that take two arguments.
0101: [Satoshi Hada] SatoshiHada01: How many namespaces does XACML define?
e-mail to xacml-comment 15 Oct 2002 13:51:19 +0900
STATUS: not yet considered.
It is unclear to me how many namespaces XACML tries to define.
Appendix B.1 says that the following two namespace URIs are defined.
urn:oasis:names:tc:xacml:1.0:policy
urn:oasis:names:tc:xacml:1.0:context
However, it seems to me that XACML tries to define at least two other
namespaces.
(1) One is for function identifiers, i.e.,
urn:oasis:names:tc:xacml:1.0:function. Indeed, the type of
the "FunctionID" attribute is xs:QName and so I think this
URN should be one of namespace URIs defined in the XACML
specification.
(2) The other is for data types, i.e.,
urn:oasis:names:tc:xacml:1.0:datatype. Currently, the type
of the "DataType" attribute is xs:anyURI.
I think it should be xs:QName and this URN should be one of
namespace URIs defined in the XACML specification.
0102: [Anne] AA13: Remove B.11 Identifiers used in conformance tests
e-mail sent 14 Oct 2002 09:58:56 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00154.html
STATUS: not yet considered.
TEXT LOCATION: Section B.11, p. 111, lines 4325-4328
TEXT CHANGE: remove entire Section "B.11 Identifiers used only
in XACML conformance tests"
DISCUSSION: just as for identifiers used in examples, I don't
think we need to spell out the identifiers used in conformance
tests.
0121: [Anne] AA32: clarify use of "dn"
e-mail sent 14 Oct 2002 12:59:38 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00177.html
STATUS: not yet considered.
TEXT LOCATION: Section 6.7 Element <Attribute>, description of
"Issuer [Optional]", p. 64, line 2685
TEXT CHANGE: replace "This MAY be a dn that binds to a public
key" with "This MAY be an X.500 Distinguished Name that binds
to a public key"
0132: [Anne] AA43: use "xs:" or "xsi:"?
e-mail sent 14 Oct 2002 13:36:53 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00187.html
STATUS: not yet considered.
In some places we use "xsi:<some datatype>", while in other
places we use "xs:<some datatype>". We should pick one. I
propose "xs:" just because it is shorter.
0134: [Seth Proctor] SP01: 18c comments. Forwarded message from Seth Proctor.
e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00192.html
STATUS: Not yet considered.
a. 3.3.2.1 (PolicyTarget) still makes it unclear that Policy Target is
computed before arriving at the PDP. I know you're working on new
language, so that may just not have been added yet.
[Anne] A new "Section 7.x Target Construction" is proposed in AA06.
This also affects HL02 "Policy Indexing".
I suggest that all discussion of how Policy and PolicySet targets
are computed be replaced with "See Section 7.x Target
Construction for information about how targets may be
constructed." and with the actual text of such a Section 7.x.
This includes the following locations:
1) Section 2.8 Policy indexing, p. 14-15, lines 470-480,
beginning with "Two approaches are supported" and ending with
"In either case, it is the policy writer's responsiblity to
ensure that only one policy statement applies to a particular
decision request."
2) Section 3.3.2.1 Policy target, p. 20, lines 630-645, beginning
with "The target may be declared by the writer of the
policy,or..." and ending with "In this case, the targets may
be omitted from the ocmponent rules."
3) Section 5.1 Element <PolicySet>, p. 44, lines 1861-1863,
beginning with "The <Target> element MAY be declared..." and
ending with "either as an intersection or as a union."
4) Section 5.5 Element <Target>, p. 46, following line 1908,
just before the schema fragment and after the sentence ending
with "...<Target> element and the corresponding section of the
<xacml-context:Request> element."
5) Section 5.17 Element <Policy>, p. 52, lines 2170-2172,
replacing "The <Target> element MAY be declared by the creator
of the <Policy> element, or it MAY be computed from the
<Target> elements of the referenced <Rule> elements either as
an intersection or as a union."
b. In section 5, when the <Function> tag is explained in Apply, it
should have a pointer to the higher-order bag section so people
understand what it's there for
[Anne] To be more specific, in Section 5.21 Element <Apply>,
explanation of <Function> [Optional], p. 54, line 2260,
following "The name of a function that is applied to the
elements of a bag.", append: "See Section A.13.11
Higher-order bag functions."
c. 10.3.6 (Identifiers) doesn't list the type of any these attributes,
nor does it give the required uses for them that it says
implementors must follow. I realize this is transparent to a lot of
the code, and only one of these is required to support, but it would
still be helpful to know what type they're supposed to be (if there
is a certain expected type). Later in the spec they're explained in
a little more detail, but not enough to make the strong language in
this section about correct implemention make sense.
[Anne] I don't think there is a specified type for these.
You specify the type using the XML Datatype="" attribute.
One user might specify key-info, for example, using a
SubjectKeyInfo from PKIX, while another might use a
ds:KeyInfo structure.
d. A.6 (Element <AttributeValue>) says that an AttributeValue's type is
implied by the function using it, but that's changed now to state
the type explicitly (same for next 2 sections)...actually, this
change is missing in most of the section A examples.
[Anne] Agreed.
e. A.11 (Matching elements) says that the AD/AS used in a Target match
must return a bag, and then has some other language that borders on
describing an API. This is the section we talked about. I think it
should be made clear that if a function expects a single String (eg),
then getting a bag is an error. Also, this section (and the section
later describing bags) should clarify that _any_ type is allowed in
a bag, not just those defined as base types in the spec. If you'd
like, I can work on alternate language.
[Anne] Yes, please propose alternate language.
f. B.9 (Status codes) is still missing some of the codes that we
discussed (like problems choosing the root policy). Maybe a few more
could be added. Maybe I should writeup a few other codes, and include
some proposal for the format of the values to accompany various
Status codes?
[Anne] Yes, please write up the proposed new status codes and
the format for their values. To all: I think we MUST specify
the format for the information provided with every status
code we define. Otherwise, we will have non-interoperable
formats being used.
g. D (Acknowledgments) ... this is a small issue, but since the list of
voting memebers is basically also the contributer list, shouldn't
this section name people who weren't on the TC but helped shape the
standard? This is the way other specs look.
[Anne] We put everyone who has been a member of the TC during
the period of the development of this spec into
"Contributors". The Acknowledgments section will include
only those who were voting members as of the date when we
vote to make this document a "Committee Spec".
h. Should SubjectAttributeDesignatorWhere extend SubjectAD now instead of
just AD? Before it made sense, since all ADs were the same, but I
would think that since there's now a special AD for Subjects, that's
what you would want to extend.
[Simon] if we extend subj-attr-desig <-
subject-attr-desig-where we will inherit subject-category
attribute. Having subject-category in subject-attr-desig is
confusing.
i. There is still no discussion anywhere about treating the Request as a
notional doc and going outside the PDP to get attribute values. The
same text is still throughout the spec suggesting just the opposite,
and the picture at the beginning looks the same. I know you're thinking
about how to change this, but if this is really supposed to be supported,
then the spec _must_ change dramatically to make this clear. One or
two paragraphs added somewhere will not cut it.
[Anne] Some of the "one or two paragraphs added somewhere"
are in a new section proposed in PH09: "7.4.2 Attributes"
that includes subsections on Attribute Retrieval and Missing
Attributes. The rest is already in the document in Section
7.7 Use profile for XACML request.
If more text is needed to make these sections clear, please
propose it.
SEE ALSO: AA45, AA46
j. Related to that, there needs to be some clear examples of how to use an
AD/AS to make this happen. I don't think that AS's should be used for
this functionality (just because it's too hard to support), but that's
a separate issue.
[Anne] Isn't that an implementation issue? The spec should
just specify the desired behavior, not how it is achieved.
k. There should probably be some language added to discuss how Policy[Set] Ids
should be treated. At the very least, and example or some hints about
typical use would make things better, since right now this is entirely
up to the implementor, and as such is guarenteed to be a point where
interoperability of policies fails.
l. There is still no text about how to do resolution in an Apply, and how this
can be short-circuited, etc. Are you working on this change? The
current spec doesn't make it clear that you should be able to do this,
so I think this needs to be added in clear examples & specification,
otherwise not all implementors will get this right.
[Anne] I think this is in 7.7 Use profile for XACML request.
If not, could you be more specific about what is needed?
0135: [Anne] AA45: make data-flow diagram consistent with 7.7 Use profile for XACML request
e-mail sent 16 Oct 2002 14:32:00 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00195.html
STATUS: not yet considered.
SEE ALSO: SP01i
TEXT LOCATION: 3.1 Data-flow model, Figure 1 - Data-flow diagram
TEXT CHANGE: Replace diagram with:
access requester --2. access request----> PEP --13. obligations--> obligations
| ^ service
| |
3. request 12. response
| |
| |
V |
PDP <--4. request notification---- context handler <---8. resource--> resource
content
---5. attribute queries------>
^ <--10. attributes------------
| --11. response context-------->
| | ^ ^
| | | |--9. environment--> environment
| | | attributes
| | |
| 6. attribute 7. attributes
| queries |
1. policy | |
| | |
| V |
PAP PIP
TEXT LOCATION: 3.1 Data-flow model, Steps 1-12
TEXT CHANGE: Replace text for steps as follows:
1. PAPs write policies and make them available to the PDP.
2. The access requester sends a request for access to the PEP.
3. The PEP sends the request for access to the context handler in
its native request format, optionally including additional
attributes of the subjects, resource and action. The
context handler translates the information in the native
request into a form consistent with an XACML Request Context
(see Section 7.7 Use profile for XACML request).
4. The PEP notifies the PDP that a request is available for
evaluation.
5. Based on its initial policy (see Section 7.1 Initial
policy), the PDP issues attribute queries to the context
handler based on the attributes required to evaluate the
initial policy and those policies referenced from it.
Attribute queries are expressed in the form of
AttributeDesignators or AttributeSelectors.
6. The context handler may issue attribute queries to a PIP in
order to resolve attributes not present in the native
request.
7. The PIP returns the requested attributes to the context
handler.
8. The context handler may optionally obtain information from
the resource itself.
9. The context handler may optionally obtain information from
the environment.
10. The context handler makes the requested attributes available
to the PDP "as if" the requested attributes were located in
a Request Context. The PDP evaluates the policy.
11. The PDP returns the response context (including its
decision) to the context handler.
12. The context handler translates the response context to the
native response format of the PEP. The context handler
returns the response to the PEP.
13. The PEP fulfills the obligations
14. (Not shown) if access is permitted, then the PEP permits
access to the resource; otherwise, it denies access.
DISCUSSION: Make diagram and steps consistent with respect to
"notional" Request Context and how/when attributes are obtained.
0136: [Anne] AA46: Make 3.2 XACML context consistent with 7.7 Use profile for XACML request
e-mail sent 16 Oct 2002 14:36:47 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00196.html
STATUS: not yet considered.
TEXT LOCATION: 3.2 XACML context, last paragraph. p. 17, line
560.
TEXT CHANGE: Append: "See Section 7.7 Use profile for XACML
request for more information about how the XACML request context
is handled."
0137: [Steve Hanna] SteveHanna02: xs:decimal string representation
e-mail sent 16 Oct 2002 14:45:39 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00198.html
STATUS: not yet considered.
Section A.3 Representations says:
For integers and decimals, XACML SHALL use the conversions
described in IBM Standard Decimal Arithmetic document at
the following URL:
http://www2.hursley.ibm.com/decimal/decarith.html
This document combines the various standards set forth by
IEEE and ANSI for string representation of numeric values.
The IBM document defines a numeric string syntax that
allows scientific notation, NaNs, and infinities. The XML
schema document that defines the permissible contents of the
xs:decimal data type does not allow any of these.
I suggest that a note be added after the above passage,
saying:
Note that although the IBM document allows exponents,
NaNs, and infinities the XML Schema specification does
not allow these in an xs:integer and xs:decimal value.
Therefore, they MUST NOT be used in such values.
0138: [Steve Hanna] SteveHanna03: Use of decimal math should be justified
e-mail sent 16 Oct 2002 14:45:44 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00199.html
STATUS: not yet considered.
It is unusual to specify the use of decimal math in
a specification like XACML, especially requiring strict
conformance to a detailed specification of decimal
math behavior. Many platforms do not support decimal
math. Binary math is much more common.
I can see why you might want to use decimal math for
this specification. Maybe you're likely to be doing a
lot of financial calculations. Still, I think it's a
bit odd that you require support for exponents, NaNs,
and the like in the implementation but don't provide
any way for a user to access these features. A simpler
approach would have been to leave the arithmetic
loosely specified, like XQuery has done.
At the least, I think you should add a few sentences
to the end of section A.12 Arithmetic evaluation saying
Decimal arithmetic is used in order to provide
results that closely match those expected by the
average user.
0139: [Steve Hanna] SteveHanna04: handling of divide-by-zero
mail sent 16 Oct 2002 14:45:48 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00188.html
STATUS: not yet considered.
Section A.12 Arithmetic evaluation says that trap-enablers
SHALL all be set to 0. I believe that this means that a
division by zero will produce a result of positive or
negative infinity and proceed along happily. That seems
surprising and contradicts sections 6.11 and B.9, which
imply that a division by zero will produce an indeterminate
result.
I suggest that you change section A.12 to say that all
trap-enablers SHALL be set to 0 except division-by-zero,
which SHALL be set to 1. Then you can change the description
of the integer-divide and decimal-divide functions in
section A.13.2 to say that they SHALL produce a result
of indeterminate with a processing-error status if the
divisor is 0.
0140: [Michiharu] MK01: DataType and Namespace
e-mail sent 17 Oct 2002 18:47:58 +0900
http://lists.oasis-open.org/archives/xacml/200210/msg00202.html
STATUS: not yet considered.
We have agreed to specify DataType attribute in both policy and context.
The schema 16j says that DataType attribute is xs:anyURI. I think that the
DataType is written as QName such as "xs:string" and "xs:boolean" like
MatchId attribute. So I request to change DataType attribute from xs:anyURI
to xs:QName. Besides, we should add the following namespace prefix and its
namespace URI in the spec.
Prefix Namespace URI
xacml-function urn:oasis:names:tc:xacml:1.0:function
xacml-datatype urn:oasis:names:tc:xacml:1.0:datatype
*) datatype prefix is used for xacml-datatype:x500Name and
xacml-datatype:rfc822Name. In fact, prefix itself matters only in the
specification document. Policy writers can choose another prefix as they
like.
I think text that refers to ds: prefix (XML Signature namespace) and saml:
prefix no longer exist in the spec. So line 289-290, 303-305 should be
deleted.
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: not yet considered.
XML-schema datatype namespace:
http://www.w3.org/2001/XMLSchema-datatypes
Xml data types:
http://www.w3.org/2001/XMLSchema-datatypes#string
http://www.w3.org/2001/XMLSchema-datatypes#boolean
http://www.w3.org/2001/XMLSchema-datatypes#integer
http://www.w3.org/2001/XMLSchema-datatypes#decimal
http://www.w3.org/2001/XMLSchema-datatypes#date
http://www.w3.org/2001/XMLSchema-datatypes#dateTime
http://www.w3.org/2001/XMLSchema-datatypes#anyURI
http://www.w3.org/2001/XMLSchema-datatypes#hexBinary
http://www.w3.org/2001/XMLSchema-datatypes#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: not yet considered.
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?
[Polar] This sentence means exactly what it says. If the the
selector or designator evalutates to an empty bag, then there
is no match, i.e. the match "predicate" is False.
The match predicate is akin to asking, "Do you have one or more
of any subject ids that match "john.*". If you have none, then
False, if you have at least one, then True.
This is a composition of three functions: an Attribute
Designator i.e. "Get me all subject ids", a match filter,
i.e. "that match 'john.*', and a length predicate "length > 0".
Regardless of the match filter, if you have zero elements to
start with, you will end up with zero elements after you apply
the match filter, and therefore, vacuously, you don't have a
match.
[Seth] Yes, I understand that. What I don't understand is how
the bag could be empty and not have that be an Indeterminate
case. This is the only question I was asking.
[Polar] If I ask you whether or not you have any bills in your
wallet that have a picture of Ulysses S. Grant on them. What
will you tell me?
[Anne, responding to Polar] On 17 October, Polar Humenn writes:
> This sentence means exactly what it says. If the the selector or
> designator evalutates to an empty bag, then there is no match, i.e. the
> match "predicate" is False.
>
> The match predicate is akin to asking, "Do you have one or more of any
> subject ids that match "john.*". If you have none, then False, if you have
> at least one, then True.
Are you saying that the result will be "False", rather than
"Indeterminate", when an not-found attribute is compared to a
value?
If so, I think this is wrong. If we can't find an attribute
value in the Request Context, for whatever reason, then the
result should be "Indeterminate", because there MAY be such a
value available somewhere and we simply weren't able to get it.
If your application needs to know for sure that something is
not available (e.g. "Is this person a convicted felon?"), then
the application needs to use a positive attribute like "Is not
a convicted felon", where a trusted authority makes a positive
assertion that such information is missing, rather than
depending on a missing "Is a convicted felon" attribute.
We really need to pin this down. Daniel, I think, says that
only some sort of operational error in talking to the PIP or
repository would result in "Indeterminate". But we can't
guarantee that an error would be detected or that the PDP
wasn't querying the wrong PIP or repository. A classic
security breach is to make something silently unavailable
(unplug a relay, re-route a message, etc.), and use that to
access systems that assume something that is not available is
false.
If an attribute is not present, then the PDP doesn't know what
its value is, and the result should be "Indeterminate" - which
means "the PDP is unable to determine the result".
[Polar] A *Match does not return indeterminate, unless
something is wrong operationally. The predicate is there an
attribute that matches? If there is no attributes of that name,
then the information isn't there.
If you really want an indeterminate, you may wrap the attribute
designator in an apply of "*-one-and-only". This forces an
Indeterminate error if there isn't one attribute. Simiarly, you
can write "*-greater-than" on the "*-length", etc.
I strongly suggest that policy writers should not be relying on
"Indeterminate" for evaluations. It is an error condition, not
a valid access decision.
Writers (or should I say their tools) should be using "present"
in boolean expressions that lead to the desired effect.
[Anne, responding to Polar] On 17 October, Polar Humenn writes:
> This sentence means exactly what it says. If the the selector or
> designator evalutates to an empty bag, then there is no match, i.e. the
> match "predicate" is False.
Isn't this in direct contradiction to your proposed text for
"7.4.2.2 Missing Attributes":
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.
[Polar, responding to Anne] No,
This says if the PDP "evaluates an expression that requires at
least one value to be present"
Such an example would be
<Apply FunctionId="string-one-and-only">
<AttributeDesignator
AttributeId="urn:...:name"
DataType="xs:string"/>
</Apply>
[Anne, responding to Polar] You can't use "present" or
"*-one-and-only" or "*-length" in a <Target>. This means any
policy where you really care about whether an attribute is
present or not will have to use an <Any*> Target, and thus will
always need to be evaluated (can't eliminate by indexing).
I strongly suggest that policy writers should not be relying on
absence of an attribute for evaluations. It is indeterminate,
not a valid access decision. :-)
Note that there are numerous places in the spec that will need
to be re-written or clarified to conform with your
interpretation of attribute retrieval.
I think this is something that has not been clearly understood
by all the TC members, but it is critical to the semantics of
XACML. I can live with Polar's interpretation, although I
think it is wrong and dangerous to security. If we accept his
interpretation, however, we need to be very clear in spelling
out how his interpretation applies to policy evaluation. That
is not currently the case, as witnessed by this entire
disagreement.
[Daniel, responding to Anne]
>We really need to pin this down. Daniel, I think, says that
>only some sort of operational error in talking to the PIP or
>repository would result in "Indeterminate". But we can't
>guarantee that an error would be detected or that the PDP
>wasn't querying the wrong PIP or repository. A classic
>security breach is to make something silently unavailable
>(unplug a relay, re-route a message, etc.), and use that to
>access systems that assume something that is not available is
>false.
Not only an operational error - value out of the permissible
value space for the particular data type, or inability of an
underlying computational procedure to produce a result when the
value is returned by an another function application also
results in Indeterminate.
What you are suggesting is that PDP should have some sort of an
internal knowledge of what information must be available in the
context and signal any discrepancy via Indeterminate result. I
do not think it is a workable operational requirement,
especially given that we do not specify much about the
internals of our virtual context (and I do not think we
should). Such intrusion detection is probably the job of the
PIP service, and yes - it can pass Indeterminate value to the
PDP if, for example, some SHA signature is off etc. But that
is not the job of the PDP, and an empty bag is a critically
useful abstraction to use.
If you want to write your policy in the way, that prohibits
access if something is missing - you can. Polar suggested
several different approaches to this - using present,
*-one-and-only will achieve the same effect.
I do not remember whether we agreed or even discussed my
proposal to treat designator supplied as an argument to a
function requiring a single value attribute as an implicitly
wrapped in *-one-and-only type transformation (but at least
several examples used around do treat it that way). Explicitly
stating such an assumption will probably answer your concern -
it does produce Indeterminate on missing attribute, when
applied to a function requiring a singleton..
[Anne, responding to Daniel] I believe it is your
interpretation that suggests that the PDP has some sort of
internal knowledge about what information must be available in
the context. I am being very clear in saying that the PDP does
NOT have that knowledge, and if it is unable to find an
attribute that is referenced by an AttributeDesignator, for
whatever reason, it will ALWAYS return "Indeterminate" as the
result.
> If you want to write your policy in the way, that prohibits
> access if something is missing - you can. Polar suggested
> several different approaches to this - using present,
> *-one-and-only will achieve the same effect.
a) I can't use those in the Target
b) If I try to use an attribute whose retrieval could fail in a
Target, then the Target will evaluate to NotApplicable.
This will happen even if a temporary network glitch was the
cause for the attribute retrieval failure, and even if the
policy has a "Deny" effect and would have caused me to deny
access had the attribute been available.
> I do not remember whether we agreed or even discussed my
> proposal to treat designator supplied as an argument to a
> function requiring a single value attribute as an implicitly
> wrapped in *-one-and-only type transformation (but at least
> several examples used around do treat it that way).
> Explicitly stating such an assumption will probably answer
> your concern - it does produce Indeterminate on missing
> attribute, when applied to a function requiring a
> singleton..
That would answer only one concern. I agree, however, that if
we accept your interpretation, we must spell this out.
[Polar, responding to Anne] Requiring an attribute to be there
for a match in a target, requires you to evaluate targets
against your request context for your missing attributes, which
precludes doing easy target indexing on the > request in the
first place.
The process of target indexing is actually the other way
around. You have a context with attributes, then you ask "Which
policyies match these attributes?".
You evaluate the request context against the targets. You
evaluate the conditions against the request context.
That functionality can be expressed in the condition with an
appropriate target that doesnn't match on your particular
attribute.
But like I said, you shouldn't be writing policies based on
"Indeterminate". It is a bad error condition.
You should write expressions in the condition that yield the
desired effect for an access decision if such needed
information is missing.
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
STATUS: not yet considered.
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
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC