Minutes 28 AprIl 2022 TC meeting

[William Parducci <bill@parducci.net>]

Time: 5:30 PM EDT
Tel: 267-807-9601

Minutes for 28 April 2022 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 of 3 March 2022 TC Meeting
  Approved Unanimously

II. Administrivia
  XACML v3.0 Dynamic Attribute Authority 
   Noted that TC Admin has published Committee Specification CS01
   https://docs.oasis-open.org/xacml/xacml-3.0-dyn-attr/v1.0/cs01/xacml-3.0-dyn-attr-v1.0-cs01.html

III. Issues
  Separation of Duty Constraints Profile
  Steven:
    I'd like to discuss pursuing a new Profile regarding Separation of Duty Constraints.
   
    I have two main concerns with the NIST RBAC standard (https://www.oit.va.gov/Services/TRM/StandardPage.aspx?tid=9530)
  
    Firstly, the SoD constraints are enforced through role assignments. The
    goal is to support SoD constraints in XACML, but we don't want to have to restrict ourselves to
    only using RBAC to give permissions to users. Secondly, the more secure Dynamic SoD requires roles
    to be requested and assigned within sessions. For this to work the "session" has to encompass all
    the potentially conflicting actions on a resource, which may extend over days or weeks, so this
    isn't what we normally consider to be a session. XACML is stateless and there isn't an inherent
    concept of a session of any sort, let alone one that persists for weeks.

    For SoD in XACML I propose we go back to first principles. We aren't actually interested in
    preventing a user having conflicting roles. Roles are a proxy for conflicting actions. What we
    are really interested in doing is preventing a user from performing conflicting actions. We can
    achieve this using Obligations and the entities profile.

    We can define an Obligation that requires a PEP to save a description of a permitted action
    performed on a resource by a user and to provide that description in every subsequent
    authorization request involving that resource and user. We can represent the description as an
    entity. At a minimum this entity would have the identifier of the resource, the identifier of the
    user and the identifier of the action, but other useful details can be added as additional
    attributes. The XACML policies would be written to test for conflicts with previously recorded
    actions and to emit Obligations to record new successful actions.

    A PEP is chosen to save the history of actions on a resource because it is generally closest to
    the already persistent resource. In practice we could have an intermediary between the PEP and
    PDP that takes care of satisfying the Obligations by persisting and appending the history so
    that the PEPs don't need to.

    Another Obligation would be defined to indicate when a sequence of potentially conflicting
    actions has been completed so that the history of actions can be discarded. To cover the
    possibility that the sequence is never completed we can define time limits in the action history
    entities.
  
  [General discussion]
  
  Steven:
    I will not be able to have a Draft by the next meeting but will begin working through this in
    the coming weeks.
    
meeting adjourned.

Next meeting scheduled for 23 June, 2022.