[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes 29 February XACML TC meeting
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]