[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
Typically XACML Subject Attributes come from an repository accessed via LDAP or SQL or perhaps SCIM. In a large organization they may have multiple repositories which contain some of the same attribute values in the different instances. The organizer make act as the single issuer or it may define distinct issuers within the organization. In any event, it is possible that not all attribute values are available from any one repository, while (perhaps for historical reasons) several repositories may contain the same attribute from the same issuer. Attribute values may arrive at the PEP directly via LDAP, SQL or SCIM or indirectly via SAML or OIDC. Attributes can be represented in different ways. For the sake of concreteness let us say the Subject Attribute called “Group” is represented as a multi-valued attribute called Group-List where each value is a Group that the Subject is a member of. Suppose that PEP obtains values from two different repositories in order to be sure that all the Subjects Groups are represented. From Repository 1 the Group-List contains Groups A, B & C and from Repository 2 the Group-List contains Group B, D & E. Because of the way XACML is specified, the PEP is not required to sort thru these values, determine which are from same or different issuers, which ones are exact duplicates or which ones have conflicting values (which requires knowing the semantics of that particular Attribute). Instead the PEP can simply include the groups in the Request Context as is and let the PDP sort things out. Possibly the values will not even be used for this particular decision. If they are, the PDP can, for example, use the Higher-order bag function “any-of” to determine if the user is a member of the Admin Group, i.e. if the value “Admin” appears anywhere in the bag. In short the idea was to assign the processing complexity to the PDP rather than the PEP. Hal From: DANGERVILLE Cyril [mailto:cyril.dangerville@thalesgroup.com] 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]