OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

Minutes 29 February XACML TC meeting - REPOST

  • 1.  Minutes 29 February XACML TC meeting - REPOST

    Posted 03-03-2024 18:32
    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 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
    Vote: Approved unanimously.

    II. Administrivia
    Oasis backend migration
    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.

    Some issues will be applicable to both versions. Do we assume anything in 3.1 would
    be carried forward automatically?

    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
    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.

    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

    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.

    I'd be interested in seeing an example of this, highlighting the "call arguments".

    Steven: Walked through a simple Use Case.

    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 #5
    There is general consensus about proceeding with this proposal.

    Issue #6
    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
    I suggest both JSON and XML schemas in the same Core document.

    I am concerned about the size of the document.

    There is general consensus that the merged version will be attempted and evaluated for

    Issue #9
    Effectively an extension of Issue #4

    Issue #11
    The general consensus is that this is only suited for v4.0.

    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

    My only concern would be the potential for scope leak.

    These would be computed upon each request. I suggest using A URI for naming to reduce

    There was a discussion re: versioning of references. One of the more aggressive changes
    being considered is removing versioning altogether.

    Issue #13
    I have found use cases that suggest the need for a ternary operator, particularly in

    I use XPath for this, but it is just a workaround.

    The general consensus is that this is worthwhile to pursue exploring.

    A Use Case would be very helpful here.

    This would be useful for development in JSON since XPath is not an option.

    meeting adjourned.