OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xacml] XPath Subset


This is just an initial proposal of the XPath subset definition for XACML
policy specification. Since XACML policy specification needs predicate
expressions, it is obvious that the selector XPath subset used in the XML
Schema is not sufficient.

Michiharu

=======================================================
Proposal of XPath Subset Definitions for XACML policy specification

1) Overview of XPath subset

List of supported features:
1. Node test and step qualifier that refers to element and attribute
2. Abbreviated syntax
3. Namespace
4. Axes of child, descendant, parent, self and attribute
5. Minimum set for operators, and, equality and inequality
6. Wildcard
7. Literal and number

List of unsupported features (not complete list)
1. Function
2. Unabbreviated syntax
3. Position
4. Variables
5. Mathematical operators such as plus, minus...
6. Logical operators such as or
7. Comment and processing instructions

2) EBNF Notation
(this is subject to change)

LocationPath         ::= RelativeLocationPath
                       | AbsoluteLocationPath
AbsoluteLocationPath ::= '/' RelativeLocationPath?
                       | '//' RelativeLocationPath
RelativeLocationPath ::= Step
                       | RelativeLocationPath '/' Step
                       | RelativeLocationPath '//' Step
Step                 ::= AxisSpecifier NodeTest Predicate*
                       | AbbreviatedStep
AbbreviatedStep      ::= '.' | '..'
AxisSpecifier        ::= '@'?

NodeTest             ::= NameTest | NodeType '(' ')'
NameTest             ::= '*' | NCName ':' '*' | QName
NodeType             ::= 'text' | 'node'

Predicate            ::= '[' PredicateExpr ']'
PredicateExpr        ::= Expr

Expr                 ::= AndExpr
AndExpr              ::= RelationalExpr
                       | AndExpr 'and' RelationalExpr
RelationalExpr       ::= LocationPath Operator LocationPath
                       | LocationPath Operator PrimaryExpr
Operator             ::= '=' | '!='
PrimaryExpr          ::= Literal | Number
Literal              ::= '"' [^"]* '"'
                       | "'" [^']* "'"
Number               ::= Digits ('.' Digits?)?
                       | '.' Digits
Digits               ::= [0-9]+

(*) For NCName and QName, refer to http://www.w3.org/TR/REC-xml-names/

3) Example XPath expressions

a) Examples without namespace
1. /Request/Subjects/SubjectId[@Format='SerialNumber']
2. /Request/Resources/ResourceSpecifier/@ResourceURI
3. /Request/Resources/ResourceAttribute/AttributeMetaData[@Name
='Root']/../AttributeValue
4. /Request/Action[@Namespace='XMLAccessControl']

b) Examples with namespace prefix without fixing namespace URI
1. /xctx:Request/xctx:Subjects/xctx:SubjectId[@Format='SerialNumber']
2. /xctx:Request/xctx:Resources/xctx:ResourceSpecifier/@ResourceURI
3.
/xctx:Request/xctx:Resources/xctx:ResourceAttribute/xctx:AttributeMetaData
[@Name='Root']/../xctx:AttributeValue
4. /xctx:Request/xctx:Action[@Namespace='XMLAccessControl']

4) Issues
4.1 Namespace: strict or simpler
XPath specification of b) is not a strict way to specify XPath with
namespaces. The strict XPath expression is to use two functions
(namespace-uri() and local-name()) so that we don't have to worry about
consistent prefix definitions in the XACML request context. If we choose
the strict syntax, we have to add function call in addition to the above
subset definition. The following show the strict syntax:

b') Examples with namespace URI
1. /*[namespace-uri()="urn:oasis:names:tc:xacml:0.15h:context" and
local-name()='Request']/*[namespace-uri()
="urn:oasis:names:tc:xacml:0.15h:context" local-name()
='Subjects']/*[namespace-uri()="urn:oasis:names:tc:xacml:0.15h:context" and
local-name()='SubjectId' and @Format='SerialNumber']
2. /*[namespace-uri()="urn:oasis:names:tc:xacml:0.15h:context" local-name()
='Request']/*[namespace-uri()="urn:oasis:names:tc:xacml:0.15h:context"
local-name()='Resources']/*[namespace-uri()
="urn:oasis:names:tc:xacml:0.15h:context"and local-name()
='ResourceSpecifier']/@ResourceURI
3. /*[namespace-uri()="urn:oasis:names:tc:xacml:0.15h:context" and
local-name()='Request']/*[namespace-uri()
="urn:oasis:names:tc:xacml:0.15h:context"  and local-name()
='Resources']/*[local-name()='ResourceAttribute']/*[namespace-uri()
="urn:oasis:names:tc:xacml:0.15h:context"  and local-name
='AttributeMetaData' and @Name='Root']/../*[local-name()='AttributeValue']
4. /*[namespace-uri()="urn:oasis:names:tc:xacml:0.15h:context" and
local-name()='Request']/*[namespace-uri()
="urn:oasis:names:tc:xacml:0.15h:context" and local-name()='Action' and
@Namespace='XMLAccessControl']

4.2 Difference between XPath 1.0 and 2.0
To indicate the version number, we need to specify that information in the
policy. An issue is where to write, at each XPath specification or at a
bigger portion of the policy (e.g. Rule and PolicyStatement).

4.3 Difference between XPath 1.0 operator and XACML operator
The semantics of the equality operator in XPath 1.0 is a little different
from the equality operator that is currently proposed to XACML because
XACML operators aim to be in line with the XPath 2.0 semantics. Is this
acceptable?




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC