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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

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

Subject: RE: [xacml-comment] 15-day public review for XACML v3.0 Errata 01 - ends March 9th

Thank you for your suggestions.


Comments in line.


From: DANGERVILLE Cyril [mailto:cyril.dangerville@thalesgroup.com]
Sent: Wednesday, March 15, 2017 7:39 AM
To: Chet Ensign
Cc: xacml-comment@lists.oasis-open.org
Subject: RE: [xacml-comment] 15-day public review for XACML v3.0 Errata 01 - ends March 9th


I sent the comment below to the xacml-comment mailing list on March 2nd about the errata (https://lists.oasis-open.org/archives/xacml-comment/201703/msg00000.html). Is there any feedback from the TC on that?


Also, if the review process is still open, I would like to report another issue:

the standard identifiers urn:oasis:names:tc:xacml:2.0:resource:target-namespace  and urn:oasis:names:tc:xacml:1.0:action:action-namespace  mentioned in annex B.5 and B.6 are not mentioned in the table of standard identifiers in section 10.2.6.


This will be added to the errata.

Kind regards,



Cyril Dangerville

Security Engineer, CISSP



From: DANGERVILLE Cyril [mailto:cyril.dangerville@thalesgroup.com]
Sent: jeudi 2 mars 2017 15:56
To: xacml-comment@lists.oasis-open.org
Subject: RE: [xacml-comment] 15-day public review for XACML v3.0 Errata 01 - ends March 9th



Thank you for this opportunity. I would like to report a few issues (I’m using the redlined version as reference):

1)     Section 5.14, line 2143: typos: “byt the PDP. The corresponsding obligations”

2)     Section 5.16, line 2171: typos: "occurrence of the <CombinberParameters>”

3)     Section 5.18, line 2211: typo: "<RuleCombinberParameters>"

4)     Section 5.19, line 2237: typo: "<PolicyCombinberParameters>

5)     Section 5.20, line 2266: typo: "<PolicySetCombinberParameters>

6)     Section 5.21, line 2321: typos:  …"byt the PDP. The corresponsding obligations"…

7)     Section 5.36, line 2643: typo: "obligation. expressions"

8)     Section 5.48, line 2981: "policies which were found to be fully applicable, whether or not the <Effect> was the same or different from the <Decision>". This sentence seems wrong since policies do not have an <Effect> element.

9)     Section 5.48, line 2983: typo: "policies"

10) Section 8.1, line 3743: the attribute 'SubjectCategory' is mentioned although it does not exist anymore in XACML 3.0, so should be removed from the list. Already reported and confirmed: http://markmail.org/thread/zvnupclj5ngbys6x

11) Section 10.2.9, line 4038: typo: "policies".

These will be added to the errata.


Also, I take the opportunity to suggest a few improvements, although I would understand that the TC considers this too much for an errata. Still, I think the sooner it is discussed/addressed, the better:

1)     Section 1.1.1, line 14: the definition of Applicable Policy is so high-level that it is interpreted in different ways by implementers (as far as I can see from discussions on the xacml-dev mailing list). Yet, it is used in many places of the specification, so I think there should be a more formal/explicit definition. In addition to the existing definition, I propose to add this refinement:

A policy or policy set P is considered "applicable" to a decision request R if and only if all the conditions below are true:
1) P’s decision in the context of R is not "NotApplicable".
2) If P is included in an enclosing policy set P', P' is also "applicable" to R

Note that this is a recursive definition.

Ignoring non-normative sections and examples, the term applicable policies seems only to occur in relation to <PolicyIdentifierList> which is described in section 5.48. In particular, the evaluation of XACML policies is correctly defined in section 7, in conjunction with the combining algorithms. The text of section 5.48 has been modified in this errata to clarify the definition of Applicable Policies. Not that it is more inclusive than your proposal.

2)     Section 5.36, line 2645: for consistency, I propose to change the definition of AttributeAssignmentType to allow multi-valued AttributeAssignments like <Attribute>, i.e. without repeating <AttributeAssignment> with same AttributeId:

<xs:complexType name="AttributeAssignmentType" mixed="true">
        <xs:element ref="xacml:AttributeValue" maxOccurs="unbounded"/>
    <xs:attribute name="AttributeId" type="xs:anyURI" use="required"/>
    <xs:attribute name="Category" type="xs:anyURI" use="optional"/>
    <xs:attribute name="Issuer" type="xs:string" use="optional"/>

It simplifies multi-valued AttributeAssignments (i.e. more optimal from a parser’s standpoint)  and makes it more consistent with the definition <Attribute>, compared to the other option which consists to have as many <AttributeAssignment>s with the same AttributeId as there are values.

This clearly goes beyond errata.

3)     Section 5.44, line 2879: I propose to add a statement saying that an <Attribute>’s (AttributeId, Issuer) couple must be unique within an <Attributes> element. In other words, consider that it is not allowed to have multiple <Attribute>s with same AttributeId and same (or undefined) Issuer within a <Attributes>. Reason: if we don’t have such uniqueness, PEPs may be tempted to send multi-valued attributes in another way by repeating the same <Attribute> with same AttributeId/Issuer for each <AttributeValue> (like it is currently the case for AttributeAssignments, cf. my previous point). This is counterintuitive from a logical standpoint since we would expect that an (AttributeId,Issuer) is unique within an Attribute category (i.e. <Attributes>); and this results in extra parsing complexity on the PDP side that we could avoid.

Section 7.3.3 defines the two forms of representing multivalued attributes to be the same. In general the philosophy of XACML recognizes that Attribute values may be represented and stored in many different ways in different environments. XACML tries to make it as convenient as possible for a PEP by allowing attributes to be represented in the most convenient way, given the local storage format. The PDP is given the responsibility to process the values however there are represented. Further, the “source” of an attribute and the “issuer” may not have a one-to-one relationship. The issuer is the authoritative party which is responsible for the correctness of the values. The issuer may make the same attribute values available from multiple sources for convenience or added reliability.

4)     Section 5.48, line 2981: After the phrase "policies which were found to be applicable", we can just make a reference to the definition proposed in 1). I removed "fully" in "fully applicable" intentionally since it suggests that there are different levels of "applicable" and these are undefined in the current spec, therefore it may be confusing for the reader. Or define what “fully applicable” means, compared to “applicable” or something like “partly applicable”.

As noted above, this point is addressed in the currently proposed errata in section 2.6 of the errata which modifies section 5.48 of core.

Kind regards,




Cyril Dangerville

Security Engineer, CISSP



From: Chet Ensign <chet.ensign@oasis-open.org>
Date: 2017-02-22 21:20 GMT+01:00
Subject: [xacml-comment] 15-day public review for XACML v3.0 Errata 01 - ends March 9th
To: tc-announce@lists.oasis-open.org, members@lists.oasis-open.org, "xacml@lists.oasis-open.org" <xacml@lists.oasis-open.org>, xacml-comment@lists.oasis-open.org

OASIS members and other interested parties, 


The OASIS eXtensible Access Control Markup Language (XACML) TC [1] members have recently approved a Committee Specification Draft (CSD) and submitted it for 15-day public review:


eXtensible Access Control Markup Language (XACML) Version 3.0 Errata 01

Committee Specification Draft 01 / Public Review Draft 01

16 February 2017




This document specifies Errata to the XACML Core discovered between its publication and the publication of this document. 


Public Review Period:


The public review starts 23 February 2017 at 00:00 UTC and ends 09 March 2017 at 23:59 UTC. 


This is an open invitation to comment. OASIS solicits feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work.




The prose specification document and related files are available here:


- eXtensible Access Control Markup Language (XACML) Version 3.0 Errata 01


Editable source (Authoritative):






- eXtensible Access Control Markup Language (XACML) Version 3.0 Plus Errata 01 (redlined)


Editable source (Authoritative):






- eXtensible Access Control Markup Language (XACML) Version 3.0 Plus Errata 01


Editable source (Authoritative):








ZIP distribution file (complete):


For your convenience, OASIS provides a complete package of the prose document and related files in a ZIP distribution file. You can download the ZIP file here:



Additional information about the specification and the XACML can be found at the TC's public home page:



Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be used by following the instructions on the TC's "Send A Comment" page, or directly at:



Comments submitted by TC non-members for this work and for other work of this TC are publicly archived and can be viewed at:



All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with this public review of "eXtensible Access Control Markup Language (XACML) Version 3.0 Errata 01", we call your attention to the OASIS IPR Policy [2] applicable especially [3] to the work of this technical committee. All members of the TC should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification. 


OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work.


========== Additional references:


[1] OASIS eXtensible Access Control Markup Language (XACML) TC



RF on Limited Terms Mode



Chet Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society

Primary: +1 973-996-2298
Mobile: +1 201-341-1393 


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