Minutes 29 February XACML TC meeting

[William Parducci <bill@parducci.net>]

NOTE: This is the first set of minutes posted to the new Oasis backend system

Time: 2:30 PM EDT
Zoom:
 Zoom Link: http://tinyurl.com/48n4yrzs
 Meeting ID: 850 9753 8468

Minutes for 29 February 2024 TC Meeting

I. Roll Call & Minutes
 Voting members
  Hal Lockhart (Co-Chair)
  Bill Parducci (Co-Chair)
  Steven Legg
  Cyril Dangerville

  Voting Companies: 3 of 4 (75% - quorum)

 Approve Minutes 4 January, 2024 TC Meeting
 https://lists.oasis-open.org/archives/xacml/202401/msg00012.html
  Vote: Approved unanimously.

II. Administrivia
  Oasis backend migration
   Hal:
    Update on state of Oasis migration. Bill will upload minutes once Oasis email 
    back online.

  The next meeting will be at 4:40 Eastern Daylight Time.

III. Issues
  XACML Core Roadmap
   Cyril discussed his draft roadmap on github based upon current issues and topics. It's
   broken in backward compatible (3.1) and non-backward compatible (4.0) versions. Each
   list will incorporate the benefits, complexity ramifications, etc. 
   
   Steven:
     Some issues will be applicable to both versions. Do we assume anything in 3.1 would 
     be carried forward automatically?
   
   Cyril:
    Some new XML types in 3.1 that may not be carried forward because they are unneeded, 
    but the functionality will be addressed.
    
   The general consensus is that this is a good approach.
  
  Issue #2
   Steven:
    The use of Target is superfluous in most situations. I Advocate for removing it in v4.0.
 
   There was a discussion on "only-one-applicable", the only place a Target is 
   specifically required.
   
   The alternative to extending Target with an expression in 3.1 is to replace Target with
   Condition in 4.0 in PolicyType/PolicySetType and remove it from RuleType, which already
   has a Condition.

  Cyril:
   In v3.1 we would need to amend the Target type.
   
  There was an initial discussion about the merits of developing v3.1 vs moving directly
  to v4.0
  
  Steven:
   I will take ownership of this issue.
   
  Issue #3
   The general consensus is that this be address in v4.0 only. 
  
  Issue #4
   Cyril reviewed the issue, noting that a v3.1 version would need to be more complex than
   a solution in v4.0.
   
   Hal:
    I'd be interested in seeing an example of this, highlighting the "call arguments".

   Steven: Walked through a simple Use Case.
   
   Cyril:
    There are times when complex computations must be made for a decision. By passing the 
    computed arguments for reuse it could be very efficient. I will take ownership of this
    issue.
    
  Issue #5
   There is general consensus about proceeding with this proposal.
   
  Issue #6
   Steven:
    We need to decide what to call this merged type. I suggest "Notice" would work. We 
    need to decide that to do with AppliesTo. I suggest we make it optional. There is 
    general consensus that this be the approach with context of usage being explanatory in
    the spec.
    
  Issue #7
    Steven:
     I suggest both JSON and XML schemas in the same Core document.
    
    Hal:
     I am concerned about the size of the document.
    
    There is general consensus that the merged version will be attempted and evaluated for
    readability. 
   
  Issue #9
   Effectively an extension of Issue #4
    
  Issue #11
   The general consensus is that this is only suited for v4.0.
   
   Steven:
    I will use the term "RuleSet" for the new Rule container with the intent to move it
    to Policy once we're ready to incorporate into the spec. This will allow for clear
    communication of what is being referred to during development.
  
   The general consensus is that "flattening" the Policy hierarchy makes sense for v4.0.
  
  Issue #12
   Steven reviewed scenarios where global variables would be accessible by multiple 
   policies.
    
   Hal:
    My only concern would be the potential for scope leak.
    
  Steven:
   These would be computed upon each request. I suggest using A URI for naming to reduce
   conflicts. 
   
  There was a discussion re: versioning of references. One of the more aggressive changes
  being considered is removing versioning altogether.
  
  Issue #13
   Steven:
    I have found use cases that suggest the need for a ternary operator, particularly in
    transformations.
  
   Cyril:
    I use XPath for this, but it is just a workaround.
    
   The general consensus is that this is worthwhile to pursue exploring.
   
   Hal:
    A Use Case would be very helpful here.
    
   Bil:
    This would be useful for development in JSON since XPath is not an option.
    
meeting adjourned.