This page is an informal collection of e-mail, meeting comments, document links and the like to support discussion in the OASIS XACML Technical Committee on various aspects of how information resources protected by an ABAC access-control system can be prepared for "fine-grained" (data-object level) control of access based on digital access policies (specifically, XACML policies.) Nothing in this collection has any official status as an XACML TC product, recommendation or conclusion. Official TC products, including working drafts, are maintained in the OASIS document repository: https://www.oasis-open.org/apps/org/workgroup/xacml/documents.php?folder_id=0

Issue Categories

  1. Location of access-relevant resource metadata (hereinafter: "resource attributes" or "PRA"s.)
  2. Alternatives for binding of PRAs to protected data objects or various types
    1. XACML TC e-Mail thread: what are common practices in how access-control attributes are bound to resources?

  3. Alternatives for how the ABAC system (whether via PDP, PIP, "context server" or whatever) locates, identifies and retrieves PRAs associated with requested data objects.
  4. Alternatives for determining appropriate PRAs, and the appropriate relationship between digital policies and PRAs
  5. Strategies for maintaining consistent semantics (or mappings) of PRAs (especially across separate organizations)
    1. To enable "federated" ABAC in which a protected resource owner accepts user authorization attributes not provisioned locally, there must be a common understanding between provisioner and consumer of the meaning (semantics) of the attributes. "Common" might mean the same attribute identifier/name and values are understood by provisioner and consumer, or that there is a mapping between different attribute names that both parties have agreed. The scope of the common understandings might be limited to a "community of interest" whose members have regular data-sharing interactions (and likely share common understandings of their industry or other "community" business processes.) However, at a minimum it would seem necessary to avoid attribute "name collisions" as organizations may participate in many different COIs; it also seems unlikely that it will never be necessary (or at least desirable) for COI members to share any data originally subject to that COI's semantic understandings with their customers, partners, regulators, etc. outside the original COI.
    2. Examples of such common semantics include the XACML TC's Export Control and Intellectual Property profiles. Is this profile approach sufficiently scalable to a potentially large number of data exchanges in many industries?
  6. Strategies and tools for adding or updating PRA's associated with protected data objects
  7. Error conditions and responses
    1. Does the fact that a PRA is not referenced (referred to by an active policy rule) by the PDP/PAP managing access to a protected resource present a concern that an expected/required policy evaluation has not been applied? See discussion thread in XACML TC archives here.

  1. US Government, National Strategy for Information Sharing and Safeguarding, Priority Objective #3
    1. The 2012 National Strategy for Information Sharing and Safeguarding (NSISS, “the strategy”) identifies data tagging as Priority Objective Three (PO-3) critical to the ability to both locate information and enable automated access control decisions. This document articulates the minimum functional requirements of data tagging standards needed to facilitate interoperable Query and Discovery, Access Control, Correlation, Audit, and Records Management capabilities across Federal networks and security domains. DATA TAGGING FUNCTIONAL REQUIREMENTS v1

  2. US Government, Department of Defense Data Tagging Strategy Working Group
    1. Internal USG working group, developing resource tagging strategy (all types of resource metadata, including access-control, discovery, records and property management) for US DoD management consideration. No public documents so far. (Note: this group has been briefed on the NSISS PO-3 Functional Requirements document cited above.)
  3. US Government, Treasury Department (?)
  4. US Government, DOD CAPCO
  5. US Government, National Archives and Records Administration, Controlled Unclassified Information (CUI) Program
    1. This program has been moving only very slowly since the May, 2008 Presidential Memorandum first mentioned "CUI", which was to be a consolidation of over 100 data markings then in use by various Government agencies for "sensitive but unclassified" information. Here is a link to the CUI Chronology on the NARA Web site. Here is a link to the current CUI Registry.

DiscussionOnResourceAttributes (last edited 2015-12-16 21:23:06 by MartinFS)