Assertion Operational Infrastructure Capability

We have previously introduced the ABA’s Assertion Operational Infrastructure Capability (AOIC) here. To summarize again, the AOIC is intended to enable ISE participants to take advantage of machine-readable assertions, machine-readable trust policies, and cryptographic bindings of assertions to system and application endpoints, to enable automated partner discovery and automated trust policy enforcement within the ISE, thereby increasing agility and speed of ISE participants. We cover the AOIC in greater detail on this page, including the following topics.

AOIC High-Level Functional Goals

The AOIC seeks to fulfill the following specific functional goals:

  1. Enable the attachment, or “binding”, of issued digital assertions to structured metadata documents about operational systems, using cryptographically verifiable binding techniques, so that an ISE participant agency’s prospective information sharing partners can precisely identify which assertions are associated with a given system belonging to that agency.
  2. Enable the publication and registration of structured metadata about operational systems’ protocol endpoints within a well-known Service Endpoint and Assertion Registry (SEAR) for a variety of protocols that have value within the ISE community. Example protocol endpoint types include Security Assertion Markup Language (SAML) Identity Provider (IDP) and SAML Relying Party (RP) service endpoints, OpenID Connect (OIDC) IDP and OIDC Client/RP endpoints, RESTful Web Services service and client endpoints, and others. This function serves as the basis for a variety of value-added AOIC “trust time” and “run time” functions, as we discuss below.
  3. Enable the creation of a scalable SEAR Registrar Ecosystem, through which multiple registrars can make updates to the SEAR on behalf of ISE participants. This multi-registrar model allows for distributed registry management, in which various ISE sub-communities can designate a specific entity to serve as their SEAR registrar based on their community organizational and political structures. The multi-registrar model also helps to avoid scalability issues associated with a single registrar or authority.
  4. Enable a robust search-and-discovery capability across all registered operational system endpoints and the assertions bound to those endpoints, so that ISE stakeholders can rapidly identify candidate information sharing partner agencies and specific systems of potential value based on specific search criteria derived from details about their operational missions.
  5. Enable a robust automated requirements gap analysis capability across all registered operational system endpoints, so that ISE stakeholders can rapidly assess the differences between one organization’s or community’s specified set of trust requirements (in the form of one or more APs) and another organization’s ability to satisfy the specified requirements (in the form of a set of assertions). Understanding this gap with a high degree of precision can provide agencies with useful data points that can serve as inputs into real-time or near-real-time decisions about trust and risk for specific operational missions. For example, “Agency 123 does not fully satisfy our community’s identity assurance requirements for granting its users access to our criminal investigative resource database. Ordinarily, in a non-emergency situation, we would deny access, but in the present case of emergency XYZ, we will allow users from Agency 123 to access the data, because the potential rewards outweigh the risks.”
  6. Enable a robust publish/subscribe capability across all registered system endpoints, so that ISE stakeholders that have made assertion-based trust decisions about specific information sharing partners and specific information systems can monitor those agencies and endpoints for changes in the assertions bound to them. This capability can provide agencies with real-time or near-real-time information about changes in the trustworthiness of their information sharing partners (e.g., through notifications about revoked or expired assertions), and the information provided can serve as an input for real-time or near-real-time decisions about whether to cease information-sharing relationships with certain partners that may have been trusted previously.
  7. Enable the integration of assertion-based “trust decision intelligence” into system endpoint software operated by ISE stakeholder agencies through the development of assertion-aware and registry-aware software libraries and tools, so that ISE stakeholders can leverage the other capabilities listed herein and work towards fully automated assertion-based trust policy enforcement within their information sharing systems.

The following section discusses each of the AOIC components that enable the AOIC to fulfill these functional goals.

AOIC Components

To fulfill the goals discussed above, the AOIC includes the following components.

  1. Technical Specifications for Protocol Endpoint Metadata and Assertion-to-Endpoint Bindings – To enable the use of assertions for trust decisions within ISE agencies’ IT systems, those systems must be able to process and understand metadata structures about their peer systems. As a first step towards enabling this capability, the AOIC identifies existing standard schemas for endpoint metadata, or develop new standard schemas, for the various protocol standards that are of value to the ISE community. For example, the SAML standard is an important legacy protocol for federated identity, and SAML already has such a schema as defined by the SAML 2.0 Metadata Specification. In contrast, OpenID Connect (OIDC) currently has no such standard for a metadata schema; however, the Kantara OTTO Working Group is in the process of developing a metadata structure for OIDC endpoints and other OAuth-based service endpoints. In addition to identifying (or developing when necessary) the base schema specifications, the AOIC also defines an appropriate technical mechanism for binding assertions to each schema.
  2. Service Endpoint and Assertion Registry (SEAR) – The SEAR is a cloud-based software tool that stores assertions made about ISE participants, trust policies (APs) published by ISE participants, and bindings of those assertions and trust policies to system and application endpoints owned by those ISE participants. It offers various value-added functions, as discussed in many of the following items in this list, but one of its core functions is the ability to serve endpoint metadata documents for various ISE participant agencies’ system endpoints upon request, in a format that conforms to the technical specifications discussed in the previous item.
  3. SEAR Registration Policy – The SEAR Registration Policy governs the registration of service endpoints and assertions within the SEAR. This policy addresses topics such as which endpoints and assertions are eligible for inclusion in the registry, which entities are permitted to act as registrars and insert/modify/delete items within the registry as well as publish cryptographic binding data between assertions and system endpoints.
  4. SEAR Registrar Toolkit – The SEAR Registrar Toolkit includes software tools and instructions that will enable approved SEAR Registrars to make appropriate changes to the contents of the SEAR, e.g., inserting/modifying/deleting system endpoint metadata objects, cryptographically binding assertions to those objects, etc.
  5. SEAR Registrar Onboarding Program – The SEAR is a security-critical resource that must be trusted by the ISE community for proper operation of the ABA, in much the same way that DNS and root-level PKI Certificate Authority (CA) certificates must be trusted for proper operation of many Internet functions. The purpose of the SEAR Registrar Onboarding Program is to help ensure that the SEAR remains a trustworthy source of endpoint metadata and assertion binding data, through basic education, training, and vetting of would-be SEAR Registrars.
  6. SEAR Query Tool – The purpose of the SEAR Query Tool is to support a variety of search, discovery, and matching use cases based on data within the SEAR. Example use cases supported by this tool include the following:
    1. “Which systems operated by agencies within New Jersey and New York conform to trust policy X?”
    2. “List all agencies in Texas that have a published trust policy that my organization (or system) can satisfy through its current set of assertions.”
  7. SEAR Gap Analysis Tool – The purpose of the SEAR Gap Analysis Tool is to support a variety of “gap analysis” use cases based on data within the SEAR. A “gap analysis” use case involves calculating the precise “gap” or difference between the set of assertions currently held by a specific agency or bound to a specific system and the set of assertions that would be required to satisfy a specific policy imposed by another agency or system.
  8. SEAR Pub/Sub Tool – The purpose of the SEAR Pub/Sub Tool is to support a publish/subscribe model for monitoring changes to systems and the assertions bound those systems, and/or the assertions issued to agencies. For example, an agency could subscribe to be notified if any assertions bound to System X become revoked or expired.
  9. SEAR Assertion Relying Party Guide (SEAR ARPG) – The SEAR ARPG provides instructions for using the SEAR as an Assertion Relying Party (ARP) and guidance for relying on assertions properly (e.g., how to properly validate an assertion’s digital signature, how to validate that the assertion is not revoked, how to ensure that the assertion is bound to the right subject, etc.), and also describes in detail how to use the AOIC to establish assertion-based trust relationships within the ISE. It is essentially a user’s manual for agencies that want to make use of assertions for operational trust decisions.
  10. SEAR Assertion Relying Party Implementer Toolkit (SEAR ARPIT) – The SEAR ARPIT is a set of software libraries, tools, and APIs that implementers can use for parsing, using, and relying upon assertions at “trust time” and “run time.” These software components simplify the process of “ABA Enablement” for both new and legacy systems and applications, making the implementation process easier for all ISE participants. The SEAR ARPIT provides two substantial benefits to software implementers. First, it provides API “wrappers” for SEAR functionality (e.g., pub/sub, gap analysis, etc.), and second, it provides a set of local ARP convenience APIs that vendors and other developers can use to “ABA-enable” their products and solutions, i.e., to make them compatible with the ABA’s assertion-based trust model.