Minutes 15 October 2020 TC meeting - UPDATED

[William Parducci <bill@parducci.net>]

Time: 4:30 PM EST (-0400 GMT)
Tel: 1-712-775-7031
Access Code: 620-103-760

Minutes for 15 October 2020 TC Meeting

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

 Voting Members: 3 of 3 (100%) (used for quorum calculation)
  Bill: we have quorum

 Approve Minutes 20 August 2020 
  Approved Unanimously

II. Administrivia
  XACML v3.0 Related and Nested Entities Profile Version 1.0 
   https://issues.oasis-open.org/browse/TCADMIN-3814
   STATUS: OPEN

| The next meeting will be held at the 2:30EST 

III. Issues

[ General discussion on topics for future investigation. ]

Steven:
  I have some ideas on future work:

   (1) ROLE ENABLEMENT / DYNAMIC ATTRIBUTE AUTHORITY
   The way role enablement was defined before it was stripped out of the final XACML
   RBAC profile was conceptually inefficient. It required the client of the role
   enablement authority to send a request for each role that effectively asked the
   question "is this role enabled for this access subject?" The client would also
   need a complete list of roles to ask about. If there were 1,000 roles then there
   would be 1,000 role enablement requests.

   What we really want to ask is "what roles are enabled for the access subject?"
   and to do so with a single request. I know a way to do that with a pair of
   obligations that carry a list of role values. One obligation specifies roles that
   are enabled (inclusions) and the other obligation specifies exclusions that
   override the first obligation. The policies mostly contain permit rules that,
   if applicable, return either a list of roles to include or a list of roles to
   exclude. The client unions the role lists of the inclusion obligations and
   subtracts the role lists of the exclusion obligations to get the final list
   of enabled roles for the subject-role attribute.

   The technique could be applied to any XACML attribute, in which case we are
   talking about a generic rules engine (call it a Dynamic Attribute Authority) that
   takes a bunch of attributes in a request context and runs through its rules to
   generate a collection of attribute values for one or more attribute types.

   (2) SEPARATION OF DUTIES CONSTRAINTS
   Separation of Duties constraints are typically defined in the context of RBAC.
   We could create an SoD profile as an adjunct to the XACML RBAC profile and it
   would work as long as all user permissions were obtained only via roles. However,
   XACML is much more than RBAC and SoD constraints don't go away just because we
   decide to use ABAC. For SoD in ABAC we aren't actually interested in preventing
   a user having conflicting roles. Roles are a proxy for actions. What we are really
   interested in doing is preventing a user from performing conflicting actions. We
   don't care how a user came by permission to perform any action, we only care what
   actions they previously performed on a resource so that we can check that the
   current action isn't an SoD violation. We can express the checks for SoD
   violations as XACML policies that have the effect of denying access if there is a
   violation.

   https://www.oasis-open.org/apps/org/workgroup/xacml/email/archives/201509/msg00000.html

meeting adjourned.