Assertion Authoring & Publishing Capability


We have previously introduced the ABA’s Assertion Authoring and Publishing Capability (AAPC) here. To summarize again, the AAPC enables IS&S stakeholder organizations and communities to manage all activities associated with the development, componentization, harmonization, aggregation, publication, and lifecycle management of assertion definitions (ADs) and assertion profiles (APs). The following topics are covered herein.

AAPC Key Features and Characteristics

The AAPC has the following features and characteristics:

  1. Private Stakeholder Group Workspaces: The AAPC provides private stakeholder group workspaces in which various IS&S stakeholder groups can develop, publish, vet, govern, and refine their own assertion definition (AD) and assertion profile (AP) artifacts, as well as formally adopt ADs and APs from other workspaces by reference. The AAPC enables each stakeholder group to customize its workspace with appropriate logos and/or other branding, as well as DNS domain aliasing, thereby enabling each stakeholder group to manage its work under its own brand and on its own web domain. Each stakeholder group can set up user accounts for various individuals to take actions within the workspace on behalf of the group. The governance structure for managing activities within a workspace can be defined and implemented externally by the stakeholder group that owns the workspace.
  2. Flexible Input Interfaces for AD and AP Development: The AAPC supports a variety of input formats for AD and AP authoring, including basic web form input and bulk/batch input via upload of structured, Microsoft Excel-based documents. This UI flexibility enables each stakeholder group to tailor its usage of the capability to its needs and preferences for AD and AP development.
  3. Flexible Support for Publication and Vetting of ADs and APs Within Stakeholder Groups: The AAPC enables each IS&S stakeholder group to publish its AD and AP artifacts in a “sandbox” or “staging” environment at any point during the artifact development process, and make that content available to reviewers as appropriate for feedback and vetting. For example, a stakeholder group could publish ADs and APs privately (e.g., requiring account-level access to the capability to see the artifacts), semi-privately (e.g., requiring knowledge of a publicly accessible but hard-to-guess URL to see the artifacts), or publicly (e.g., at a well-known or widely disseminated URL).
  4. Flexible Support for Adoption of Externally Developed Artifacts by Reference: As we have discussed previously, the ABA is intended to foster reuse of artifacts where possible. This pertains to reuse of ADs in particular, but the principle also applies to APs. Accordingly, the AAPC supports mechanisms whereby one stakeholder group can identify AD and AP artifacts published by another stakeholder group, and formally adopt them by reference for reuse.
  5. Governance-Agnostic Workspace Interface Design: Many IS&S stakeholder groups already have existing governance structures and cultures, and accordingly, the AAPC does not try to impose any unnecessary governance structures or processes on the stakeholder groups that use it. The AAPC assumes that each stakeholder group uses externally defined decision-making processes regarding AD and AP development, AD and AP vetting and lifecycle management, adoption of externally developed ADs and APs, etc. In essence, the AAPC aims to provide simple, lightweight facilities for enabling the technical steps required to accomplish these tasks, without imposing any specific processes around the technical steps.

Details on Specific Workspaces and Stakeholder Groups

Each workspace within the AAPC is governed and operated independently by the appropriate stakeholder group, and stakeholder groups interact with each other as peers, in a non-hierarchical manner. Within the AAPC, each stakeholder group workspace includes the following components:

  1. Protected access to the AD and AP development interfaces;
  2. A “staging” or “sandbox” area for vetting ADs and APs developed internally within the stakeholder group;
  3. An “approved” area for publishing ADs and APs that have been developed within the stakeholder group; and
  4. A “references” area for managing references to external ADs and APs that have been adopted or endorsed by the stakeholder group.

As noted above, we expect stakeholder group governance to exist externally to the capability.

Initially, we anticipate the following stakeholder group workspaces to exist within the AAPC:

  1. Core AD Workspace: There are some trust requirements that are fundamental, appearing again and again in policy guidance both within and beyond the ISE communities, regardless of the specific application domain or use case. To highlight and encourage broad reuse of these core, fundamental trust primitives, we have designated a Core AD Workspace for the purpose of developing and lifecycle-managing these core requirements and promoting their adoption by various stakeholders within other workspaces. The Core AD Workspace manages only ADs, as ADs are intended to represent generic trust primitive concepts that transcend communities and use cases.
  2. Core Library Workspace: The purpose of the Core Library Workspace is to develop and lifecycle-manage ADs and APs that pertain to requirements from specific communities, which are not generic enough to belong in the Core AD Workspace. For example, APs for NIST SP 800-53, NIST SP 800-63, the FBI CJIS Security Policy, and other prominent national policies and programs are governed under this workspace. If the authoritative entity wants to take on the governance responsibilities for APs that derive from its publications (e.g., FBI for the CJIS policy, NIST for 800-53 and 800-63, etc.), these APs can be moved into a separate workspace directly managed by that entity. But in the absence of such an authoritative governing entity, the appropriate ADs and APs can exist in this Core Library Workspace. In addition to developing and lifecycle-managing certain community-specific ADs and APs, the Core Library Workspace also provides a mechanism through which to formally endorse ADs and APs developed and managed within other workspaces, by other stakeholder groups, provided that those ADs and APs meet certain requirements related to quality, harmonization, non-overlap, etc.
  3. ICIF Workspace: The ICIF Workspace is overseen by the ISE communities and governed as appropriate by the Standards Coordinating Council (SCC) or its designees. We expect that activity within the ICIF Workspace would mostly comprise adoption and endorsement of externally managed ADs and APs, with relatively little AD or AP development occurring within this workspace.
  4. Geospatial Workspace: The Geospatial Workspace is overseen and governed by the Open Geospatial Consortium (OGC) and others as appropriate within the geospatial community. This workspace is used to develop ADs and APs related to the use of OGC-approved geospatial standards.

Other workspaces would be created as needed based on stakeholder group interest.

The diagram below illustrates the assertion authoring and publishing capability architecture that we have discussed. Note that, in addition to the features described previously, the capability would also support APIs and Web Browser UIs for browsing, search, and discovery of ADs and APs developed within all workspaces.

Assertion Authoring and Publishing Capability
Assertion Authoring and Publishing Capability