NOTE: This is the second attempt of posting the first set of XACML minutes posted to the new Oasis backend system. I’ve been notified that the address has changed.
Time: 2:30 PM EDT
Zoom:
Zoom Link:
http://tinyurl.com/48n4yrzsMeeting 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.