[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes 10 December 2020 TC Meeting
Time: 2:30 PM EST Tel: 1-712-775-7031 Access Code: 620-103-760 Minutes for 10 December 2020 TC Meeting I. Roll Call & Minutes Voting members Steven Legg Hal Lockhart (Co-Chair) Bill Parducci (Co-Chair) Voting Members: 3 of 3 (100%) (used for quorum calculation) Bill: we have quorum Approve Minutes 15 October 2020 Approved Unanimously II. Administrivia XACML v3.0 Related and Nested Entities Profile Version 1.0 https://issues.oasis-open.org/browse/TCADMIN-3814 STATUS: Public Review Complete Hal: The PR is complete. VOTE: Steven: I move that the XACML TC approve the Chair requesting that TC Administration hold a Special Majority Ballot to approve "XACML v3.0 Related and Nested Entities Profile Version 1.0, Committee Specification Draft 02, dated 20 August 2020 as a Committee Specification and designate the .docx version of the file herein as authoritative: https://www.oasis-open.org/apps/org/workgroup/xacml/download.php/67631/xacml-3.0-related-entities-v1.0-wd05.zip Bill: I second the motion. Hal: Is there any further discussion? VOTE: Approved unanimously. III. Issues Dynamic Attribute Authority Profile Steven: I chose to write up the Dynamic Attribute Authority before other ideas because I already have an implementation and it is related in some ways to the Obligations and Advice Authority Profile I published a while back. I can adapt text from that earlier profile The motivation was to develop a better way to do role enablement. The version in early drafts of the RBAC Profile required iteration over the entire set of known roles to learn which roles a user had enabled. It also couldn't enable roles based on the original action or resource. The goal here is to extend and optimize the process and expand the scope beyond the subject-role attribute to any attribute. Steven: The DAA is a separate PDP and the rules for generating attributes are XACML permit rules with Obligation expressions. The request context for the DAA is the request context received by the context handler from the PEP. The DAA rules are applicable, or not, according to their conditions, and when triggered either add an obligation to include certain attribute values or an obligation to exclude certain attribute values. The response from the DAA is a permit result (or not applicable) with a collection of these obligations. The context handler processes these obligations to arrive at a set of attributes and values to add to the original request context, which is then forwarded to the "base" PDP for normal processing. Hal: Are the attribute values generated by the DAA stored anywhere? Steven: The generated attribute values are reflected in the obligations returned by the DAA to the context handler. Those values are not cached. Each request from a PEP results in a new request to the DAA. Hal: This may be more of a Decision Point because it doesn't persist data. Steven: I'm not wedded to the terminology. We can assess the appropriateness once there is a first draft for everyone to look at. Bill: What is the relationship between DAA policies and PDP policies? Steven: There is a persisted set of policies that are unique and independent of the "base" XACML policies. The attributes and values must align however. Steven: The DAA policies will follow a consistent pattern and use only a subset of the capabilities of XACML policies so there is the possibility of condensing the storage representation of DAA policies and streamlining the DAA PAP. Bill: This brings up some interesting "ETL" implications. Steven: One possible use case for the DAA is to transform one set of attributes, or attribute values, from domain one domain to another. For example in an acquisition scenario the DAA could be used to transform the roles used by one company into the equivalent roles used by the other company. Hal: What is the effect of the obligations returned by the DAA on the original request? Steven: These Obligations are processed by the context handler only to add additional attributes and values to the original request context before it is forwarded to the "base" PDP. The DAA obligations have no effect otherwise and are not seen by the PEP. Hal: I look forward to seeing how this all manifests in the document. meeting adjourned.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]