[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] New Change Requests
I have started a second set of Change Requests for those against v17. Attached. -- 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 2
Author: Anne Anderson
Version: 1.3, 02/09/27 (yy/mm/dd)
Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.ChangeRequests2.txt
This version contains all Change Requests not reflected in v17.0
of the specification (i.e. received after the TC meeting on 26
Sept 2002. For earlier Change Requests (all disposed of by 26
Sept 2002) see the following e-mail in the archive:
http://lists.oasis-open.org/archives/xacml/200209/msg00185.html
or reference the mail titled "[xacml] Updated Change Request
list", from Anne Anderson, 26 Sep 2002.
Contains all e-mail up to and including archive msg msg00203.html
ACTION ITEMS
============
None
LEGEND
======
NQ=no quorum; official vote required
Q=quorum
SUMMARY
=======
0064. [Michiharu] <AttributeSelector> Text change request
STATUS: APPROVED (Q 9/26); but discussion continued. Revisit?
0065. [Anne] x500Name-equal and X500Name-match errors in Functions v13
STATUS: e-mail dated 26 Sept 2002
0066. [Simon] change request: namespaces in xpath expressions
STATUS: e-mail dated 26 Sept 2002
0067. [Simon] change request: resource content
STATUS: e-mail dated 26 Sept 2002
0068. [Simon] change request: subject-attribute-designator and subjectcategory
STATUS: e-mail dated 26 Sept 2002
0069. [Simon] change request: xacml context attributes and data types
STATUS: e-mail dated 26 Sept 2002
DETAILS
=======
0064. [Michiharu] <AttributeSelector> Text change request
http://lists.oasis-open.org/archives/xacml/200209/msg00179.html
STATUS: APPROVED (Q 9/26); but discussion continued. Revisit?
AttributeSelector, Page 49
<AttributeSelector> [required]
MAY be used to identify one or more values in the <Subject>
element of <xacml-context:Request> element. It MUST contain
a legal xpath expression over the <Subject> element of the
<xacml-context:Request> element.
==>
<AttributeSelector> [optional]
Attribute selector using XPath expression. It MUST contain a
legal xpath expression over the <xacml-context:Request>
element. This operator returns a bag of string data or a
single primitive value. In case of XPath 1.0, an evaluation
value of the XPath expression is either a node set, string
value, numeric value, and boolean value. When node set is
returned, each node may consist of children nodes (structured
node). Then each node is converted into a string data by
applying a string function defined in XPath 1.0
specification. Then this operator returns a bag of string
values. When either string, numeric or boolean value is
returned, this operator returns a single primitive value of
xs:string, xs:decimal, and xs:boolean type,
respectively. When this element is specified, the policy MUST
define the version of the XPath specification using
<XPathVersion> element. When an xpath expression has one or
more namespace prefix, they are resolved using XPath
namespace and prefix information specified in the
<XPathNamespace> element below this operator. If no such
element is specified, then an <XPathNamespace> element in
<PolicyDefaults> element in the parent <Policy> (or
<PolicySet>) element is used.
[Polar] <AttributeSelector>
AttributeSelector using an XPATH expression.
The AttributeSelector's "RequestContextPath" XML attribute
shall contain a legal XPATH expression over the
<xacml-context:Request> element. The selector element
evaluates to a bag of a single primitive value that is
implied by the type system, i.e. the function application in
which the selector appears.
In case of using XPATH 1.0, the value of the XPATH expression
is either a node-set, string value, numeric value, or boolean
value. If the XPATH 1.0 expression evaluates to a node-set,
each node may consist of a string, numeric, boolean value, or
a child node (ie. structured node). In this case, each node
is logically converted to string data by applying the
"string" function defined in XPATH 1.0 specification
resulting a sequence of string data. In the single string,
numeric, or boolean value case, the value is converted to
string data by applying the string function defined in XPATH
1.0 specification resulting in a sequence of one string data
element. In XPATH 2.0, the result of the XPATH expression is
always a sequence of nodes. In this case, each node is
logically converted to a string using the aforementioned
string function resulting in a sequence of string data. The
resulting sequence of string data is converted to a bag of
primitive values that is implied by the type system.
[Polar, quoting Michiharu]
> The sentence you provide is basically fine.
>
> [1]
> in XPATH 1.0 specification resulting in a sequence of one
> string data element.
> ==>
> in XPATH 1.0 specification resulting in a bag of one string
> data element.
Actually, I used "sequence" to unify both the XPATH 1.0 and
2.0 descriptions. Then logically convert the "sequence of
string data" to a bag of primitive values.
>
> [2]
> Since XPath 2.0 returns either a sequence or the error
> value, we should say that "the result of the XPATH
> expression is a sequence of items (item is an atomic value
> or a node) or the error value. When the error value is
> returned, the PDP SHOULD return Indeterminate."
OKay.
[Michiharu] OK.
In case of XPath 2.0, "xf:string accessor" is better than
"aforementioned string function".
0065. [Anne] x500Name-equal and X500Name-match errors in Functions v13
http://lists.oasis-open.org/archives/xacml/200209/msg00186.html
STATUS: e-mail dated 26 Sept 2002
The descriptions for the functions x500Name-equal and
x500Name-match in XACML_Functions.doc v13 are mixed up. In
particular, the "x500Name-match" description is actually the
"x500Name-equal" description.
Here are the correct descriptions:
o x500Name-equal
This function shall take two arguments of "xacml:x500Name" and
shall return an "xs:boolean". It shall return true if and only
if each Relative Distinguished Name (RDN) in the two arguments
matches. Two RDNs match if and only if the result of the
following operations is true.[3]
First, normalize the two arguments according to IETF RFC 2253
"Lightweight Directory Access Protocol (v3): UTF-8 String
Representation of Distinguished Names".
Second, if any RDN contains multiple attributeTypeAndValue
pairs, re-order the Attribute ValuePairs in that RDN in
ascending order when compared as octet strings (described in
ITU-T Rec. X.690 (1997 E) Section 11.6 "Set-of components").
Finally, compare RDNs using the rules in IETF RFC 3280
"Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) PRofile", Section 4.2.1.4
"Issuer".
o x500Name-match
This function shall take two arguments of "xacml:x500Name" and
shall return an "xs:boolean". It shall return true if and only
the first argument matches some terminal sequence of RDNs from
the second argument when compared using x500Name-equal.
0066. [Simon] change request: namespaces in xpath expressions
http://lists.oasis-open.org/archives/xacml/200209/msg00190.html
STATUS: e-mail dated 26 Sept 2002
There are several instances in the policy schema where we
pass xpath expressions as arguments.
1. In the case of <xacml:AttributeSelector> element
RequestContextPath attribute contains xpath expression
that selects xacml attribute value from the context.
2. When xpath functions are used in the target, the value to
match again is xpath expression.
3. When xpath functions are used in conditions they take
xpath expressions as arguments.
All examples are from section 4.2
For the attribute-selector we use XPathNamespace element that
maps namespace uri to namespace prefix (essentially
duplicating standard xml namespace declaration)
AttributeSelector:
<AttributeSelector RequestContextPath=
"//ctx:RequestContext/md:record/md:patient/md:policyNumber">
<XPathNamespace NamespaceURI="urn:names:tc:xacml:1.0:context" Prefix="ctx"/>
<XPathNamespace NamespaceURI="http://www.medico.com/schemas/record.xsd"; Prefix="md"/>
</AttributeSelector>
For other uses of xpath functions we do not have special
provisions for namespace mapping. Here is how xpath
expression is used in the target to match request:
<ResourceMatch matchId="function:xpath-match">
<ResourceAttributeDesignator AttributeId=
"urn:oasis:names:tc:xacml:1.0:resource:xpath"/>
<AttributeValue>/md:record</AttributeValue>
</ResourceMatch>
In this case we rely on standard xml namespace declaration
for the md prefix.
To summarise: we use two methods to deal with the same
problem: one is standard and one is not.
Proposal:
1. Use standard xml namespace declarations mechanism in both
cases and drop <XPathNamespace> element.
2. Change RequestContextType attribute of AttributeSelector
to xs:string (it is currently xs:anyURI).
[Michiharu] I understand your intention but I am not sure
whether or not using standard XML namespace (your first
proposal) is really good for our case.
My opinion is that standard XML namespace (you mean xmlns:md
="http://www.... record.xsd", right?) should primarily mean
the namespace for element name of the policy itself. In other
words, XACML policy may include other namespace (currently
seems not but actually we had when SAML schema fragment was
used in our policy). I think xmlns should be used for that
case. Since we need to determine the namespace for the value
of the policy (not element name nor attribute name), it seems
reasonable to use application-specific namespace designator
(XPathNamespace) currently we have. How do you think?
[Simon] You are correct, xmlns decl is used for elements and
we have data. Our first problem is that we do not cover all
cases with XPathNamespace element. Also, declaring
XPathNamespace in the PolicyDefaults is equivalent in my
opinion to declare namespace prefix on the Policy itself. So
I'd like to use xmlns decl, although it's usage is applied to
data.
0067. [Simon] change request: resource content
http://lists.oasis-open.org/archives/xacml/200209/msg00191.html
STATUS: e-mail dated 26 Sept 2002
<xacml-context:Resource> element has
<xacml-context:ResourceContent> child. If resource content
is relevant in access decision it is placed as a child of
<ResourceContent> element.
Currently, the only way to access <ResourceContent> and it's
children elements is with <xacml:AttributeSelector>, support
for which is optional.
There is no way to access this data with
<xacml:ResourceAttributeDesignator>.
Proposal 1: Introduce resource attribute identifier:
"urn:oasis:names:tc:xacml:1.0:resource:resource-content" that
will address <ResourceContent> element. In this case, both
<ResourceContent> and identifier refer to the same entity. No
schema change required.
Proposal 2: Drop <ResourceContent> element and introduce
resource identifier as above. The xpath expressions in the
<xacml:AttributeSelector> will be taken over this resource
attribute:
<AttributeSelector RequestContextPath=
"//ctx:Request/ctx:Resource/
ctx:Attribute[@AttributeId='urn:oasis:names:tc:xacml:1.0:resource:resource-content']/*"/>
In both cases (1) and (2) we can access content with
resource-attribute-designator: <ResourceAttributeDesignator
AttributeId="urn:oasis:names:xacml:1.0:resource:resource-content"/>
[Michiharu] I am ok with your first proposal but I am not
clear on the second one. The intention of having a
ResourceContent element in XACML Request Context is that it
must allow any arbitrary XML fragment below ResourceContent
element. That's why the schema allows any structure. If you
remove the ResourceContent and place the arbitrary XML
fragment below Attribute element instead, you will need
another changes on schema, for example to allow any elements
below Attribute element or to introduce a new elements like
ResourceContent.
[Simon] Ok, than we can declare an attribute identifier that
will point to the content (alt 1).
0068. [Simon] change request: subject-attribute-designator and subjectcategory
http://lists.oasis-open.org/archives/xacml/200209/msg00192.html
STATUS: e-mail dated 26 Sept 2002
xacml request context supports multiple
<xacml-context:Subject> elements. Each
<xacml-context:Subject> element is tagged with the
subject-category, such as: access-subject, codesource,
etc. Subject category name is unique, ie there is no two
<xacml-context:Subject> elements in the request context with
the same value of subject-category attribute.
<xacml:Subject> element in the policy allows us to specify
multiple subject matches at the same time: sm1 'and' sm2
'and' sm3 etc. Syntactically, context subject attribute is
selected with <xacml:SubjectAttributeDesignator> element that
names attribute-id and issuer.
Very often all subject attributes must be selected from the
same subject block.
Proposal: Extend <xacml:SubjectAttributeDesignator> with
optional SubjectCategory attribute:
<xs:complexType name="SubjectAttributeDesignatorType">
<xs:attribute name="AttributeId" type="xs:anyURI" use="required"/>
<xs:attribute name="Issuer" type="xs:anyURI" use="optional"/>
<xs:attribute name="SubjectCategory" type="xs:string" use="optional"/> <-- new attribute
</xs:complexType>
[Polar] I thought the purpose of the
SubjectAttributeDesignatorWhere was to get all matches from
the same subject, of which subject-category was one of the
attributes you match on.
I think we worked this out quite well, and cuts down on the
machinery needed to just select mere attributes from a
subject.
0069. [Simon] change request: xacml context attributes and data types
http://lists.oasis-open.org/archives/xacml/200209/msg00193.html
STATUS: e-mail dated 26 Sept 2002
Currently <xacml-context:Attribute> element allows DataType
attribute.
Rationale for keeping DataType attribute in the
<xacml-context:Attribute> element was that it can sometimes
be helpful, such as specifiying subject-id format, like
subject-id="cn=simon", data-type="x500-name"
But this information is redundant, because subject-id
attribute will be passed to the specific function that
expects arguments of certain type. For example, if subject-id
is passed to the x500Name-equal function it expects it's
arguments to be in x500 name format.
So data type does not add value here.
Another problem is that we can not access DataType attribute
with AttributeDesignator.
Proposal: remove DataType attribute from the
<xacml-context:Attribute>.
[Anne] But, as discussed on yesterday's call, a <Subject> may
have more than one subject-id attribute. For example, one
may give the rfc822Name under which the subject
authenticated, and another may give the x500Name.
The datatype is required to allow the AttributeDesignator to
select the instance of the attribute that has the correct
datatype for the function in which the designator occurs.
[Polar] I agree with removing the dataType attribute from the
xacml-context:Attribute.
However, the implications are this:
If you have an Attribute of "subject-id" and its value is:
<AttributeValue>CN=Simon Godik, O=OverXeer, OU=Research</AttributeValue>
What does the designator:
<SubjectMatch MatchId="function:rfc822Name-equal">
<SubjectAttributeDesignator AttributeId="subject-id"/>
<AttributeValue>simon@godik.com</AttributeValue>
</SubjectMatch>
evaluate to?
Does it evaluate to "indeterminate" because the formal type
of rfc822Name-equal is
xacml:rfc822Name -> xacml:rfc822Name -> Bool
and the attribute value is an invalid representation of an
rfc822Name.
Or does it evaluate to "false"?
The question in the context of its application, the
<SubjectAttributeDesignator Attribute="subject-id">
shall return a bag of "rfc822Name", which means that every
"subject-id" attribute must have a parseable rfc822Name
representation as a value.
So, does the designator return "indeterminate" because not
*all* values under "subject-id" are valid string
representations of rfc822Name?
Or does it return a bag of rfc822Names of *only* the values
under "subject-id" that do have valid string representations
of rfc822Names? In the example above for the latter case,
this designator would return an empty bag.
[Polar, responding to Anne] Right, if the dataType attribute
exists, if you are looking for attributes of a particular
datatype, of which our XACML strong type system will infer,
you can pick them out of the context by the dataType
attribute.
It can be optional, however, as I pointed out in my last
email, you have to decide on what to do with the designator
if the AttributeValue isn't a valid parseable representation
of the data type named in the dataType attribute.
[Bill] i suggest that this has to evaluate to FALSE.
INDETERMINATE implies that the value is out of scope of the
data set. while it may be argued that this is true at the
philosophical level, i don't think it is consistent with how
we are handling similar issues--what happens if a PEP
requests to 'toad the wet sprocket' (resource unknown, action
unknown)?
this is consistent with my current assumptions that these
values will be evaluated as [right-to-left] string
comparisons. if that isn't the case, then i would like to
hear the reasoning for requiring the logic necessary to
differentiate between the two at evaluation time (explicit
vs. implicit run-time type validation)
[Simon, responding to Anne] If this is the case we should
extend attribute designator to specify data type of the
attribute to be selected.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC