Minutes 15 October 2020 TC meeting

[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

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.