Minutes 10 December 2020 TC Meeting

[William Parducci <bill@parducci.net>]

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.