Time: 2:30 PM EST
Zoom Link:
http://tinyurl.com/48n4yrzsMeeting ID: 850 9753 8468
Minutes for 3 April 2025 TC Meeting
I. Roll Call & Minutes
Voting members
Hal Lockhart (Co-Chair)
Bill Parducci (Co-Chair)
Steven Legg
Cyril Dangerville
Voting Members: 4 of 4 (100% - quorum)
Approve Minutes for 6 March 2025 TC meeting
https://groups.oasis-open.org/discussion/minutes-for-6-march-2025-xacml-tc-meetingII. Administrivia
Oasis backend update
Bill:
Oasis continues to work on scoping out the next iteration of the backend process.
Summary Doc
Steven:
It would be helpful to get the message of what we are doing with v4.
Bill took on an Action Item to talk to Oasis about how best to do this.
v4 Standard Name
Hal took an action Item to collect proposed names for v4 in the next few weeks.
Meeting Adjustment
The next meeting will be held on 24 April, 2025 to accomodate the French national
holiday on May 1.
III. Issues
Global entities
There was a discusion about how "shorties" would be used and the nature of
implementations.
Steven:
I would prefer "mandatory to support but not mandatory to use" as the guidance for
using "shorties".
The conversation covered the differences between Policy readability and request/response
semantics and efficiencies. There was general consensus that "shorties" be mandatory to
support, but not use in Policies.
With respect to "shorties" in the request/response transaction, the conversation spanned
elements of compression, clarity, etc. as well as the acknowledgement that the JSON
profile already has efficiencies at the protocol level. It is generally agreed that this
compaction has value, but Steven suggest that we explore a more generalized approach
that encompasses JSON, XML and YAML consistently.
Cyril raised the question of how request/response "shorty" definitions would be stored/
managed. Steven proposed that it would be in a similar fashion to the proposal for
storing global entities for Policies: A universal shorty collection that is defined in a
"wrapper" via a URI and that allows for an "extended" collection for local definitions.
Cryil suggested that a concrete example would be great in the git Hub Issue. Steven
agreed to extend his proposed solution in the Issue. Overall, there was general
agreement that this approach has merit.
URI datatype be allowed to have shorties as well?
Steven asked for input on using "shorties" in/with/as a replacement of URI definitions.
He proposed proposed using "{}" to denote a "shorty" that is part of a compound string
(similar to how python f-strings work).
There was general agreement to replace anyURI with new datatype the is [functionally]
essentially the same, and that allows shorties in the values and carries over all the
current functions, etc.
Defining datatype at Attribute level
Cyril reviewed issue #46, described his idea for a more efficient datatype definition.
Steven suggested functions may declare that a specific value must have a defined
datatype. There was general consensus on how this will be enacted and will be captured
in the Issue online.
meeting adjourned.