Hello,
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.
Kind regards,
Cyril
---
Cyril Dangerville
Security Engineer, CISSP
Thales
Hello,
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".
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.
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:sequence>
<xs:element ref="xacml:AttributeValue" maxOccurs="unbounded"/>
</xs:sequence>
<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"/>
</xs:complexType>
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.
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.
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”.
Kind regards,
Cyril
---
Cyril Dangerville
Security Engineer, CISSP
Thales
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
This document specifies Errata to the XACML Core discovered between its publication and the publication of this document.
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
--
/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.org
Primary: +1 973-996-2298
Mobile: +1 201-341-1393