[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
Hello, Thanks for your feedback. I agree with your comments except on issue below, just because I am not sure I understand your comment. See my reply in line. 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. [DANGERVILLE Cyril] There is no such “source” info in XACML <Attribute>s, so I’m confused. Could you give a concrete example/use case in which the PEP has to repeat the same <Attribute> with same AttributeId and same Issuer within the same <Attributes> (category)? What would be the attribute data in the PEP’s storage like? And what would be the resulting <Attributes> element in the XACML Request like? Thanks. Kind regards, Cyril --- Cyril Dangerville Security Engineer, CISSP Thales
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 Overview: 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. URIs: The prose specification document and related files are available here: - eXtensible Access Control Markup Language (XACML) Version 3.0 Errata 01 Editable source (Authoritative): HTML: PDF: - eXtensible Access Control Markup Language (XACML) Version 3.0 Plus Errata 01 (redlined) Editable source (Authoritative): HTML: PDF: - eXtensible Access Control Markup Language (XACML) Version 3.0 Plus Errata 01 Editable source (Authoritative): HTML: PDF: Schema: 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 --
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]