Skip to main content

Introduction to the OSCAL Models

OSCAL is organized in a series of layers that each provide a set of models.

A model represents a information structure supporting a specific operational purpose or concept.

Each model is comprised of information structures that form an information model for each OSCAL model. This information model is then bound to multiple serialization formats (i.e., XML, JSON, YAML), which represent a concrete data model. Thus, a data model that defines how to represent an OSCAL information model in a serialized format. While the syntax of each format differs, all formats for a given model represent the same set of information, or information model. OSCAL content expressed in one of the supported formats can be translated into any one of the alternate formats without data loss.

General Model Organization

All OSCAL models share:

  • a common high-level structure; and
  • many common constructs that are reused across the models.

Every OSCAL file must have a minimum set of required fields and assemblies, and must follow the core OSCAL syntax.

Common High-Level Structure

Every OSCAL model includes a required metadata section, optional back-matter section, and model-specific body.

An OSCAL file is organized as follows:

  • Root Element: The root element of the document indicates the type of content within the body of the file. The name of this element is unique to the specific model.

  • UUID: A RFC 4122 Version 4 Universally Unique Identifier (UUID) that identifies a specific document instance. This document-level UUID must be changed every time the content of the document is modified.

  • Metadata: Every OSCAL document must have a metadata section, which must include a title, last-modified timestamp, and OSCAL syntax version. Metadata is also used to define roles, parties (people, teams and organizations), and locations.

  • Model-specific Body: The body of an OSCAL file is different for each model.

  • Back Matter: The back matter syntax is identical in all OSCAL models. It is used for linked and attached resources, which may contain citations. A back matter resource can be used to associate graphics, supporting documentation, etc. with the OSCAL document. Tool developers and content authors are encouraged to associate content here and reference it from within the body of an OSCAL document.

A diagram representing the general layout of any OSCAL document, showing the following information. A root element, a metadata section, a model-specific section, and a back-matter section.

Important Note to Developers

Every time the content of an OSCAL file changes, the following must also change:

  • A new UUID value must be generated and assigned to the root element's uuid.
  • The last-modified field in metadata must be assigned with the date and time at the moment the file is saved with the modified content.

These are two mechanisms by which tools can quickly "know" if a file has changed since it was last encountered. This document level UUID is the only UUID in OSCAL associated with version control.

When converting between formats, such as XML to JSON, these values should remain the same. This enables tools to know the content within the two formats is equivalent.

Identifier Use

Subjects within OSCAL content are singled out using unique identifiers, which are critical to defining relationships between different pieces of OSCAL content.

The only exception to this is the document-level identifier, which is intended for version control.

The OSCAL models make use of two types of identifiers:

  1. Human readable identifiers [id], typical a canonical identifier; and
  2. An RFC-4122 Version 4 Universally Unique Identifiers (UUIDs) [uuid].

Use of Human-Readable Identifiers

Some of the OSCAL models (i.e., catalog, profile) make use of human-readable identifiers. This type of identifier is used in cases where humans need to select and publish data sets that make use of these identifiers. Examples of human-readable identifiers in OSCAL include control, control statement, parameter, and group identifiers used in OSCAL catalogs and profiles; and role identifiers used across all of the OSCAL models.

All human-readable identifiers must be a compliant non-colonized name as defined by XML Schema Part 2: Datatypes Second Edition. This allows these identifiers to be used uniformly across XML, JSON, and YAML formats.

These identifiers are intended to be consistently used to represent the same concept over multiple major and minor revisions of the same document; thus, they should only be changed if the underlying identified subject has changed in a significant way that no longer represents the same identified subject.

Human-readable identifiers tend to be named id and appear where the identifier is declared on the identified subject. Fields that form an association between another subject and the identified subject by referencing a human-readable identifier will end with the suffix -id in OSCAL formats. These identifiers are scoped to their containing documents; therefore, the identifiers are guaranteed to be unique only in the context of the containing document. While these identifiers are document scoped, they can still be referenced by 3rd-parties in OSCAL and related content, by referencing the document source and then the identifier in that context.

Use of Version 4 UUIDs

UUIDs in OSCAL are intended to uniquely identify information and link information between various OSCAL documents that tend to be generated by tools. In such a case it is necessary to use an identification scheme that is:

  1. Easily generated by a tool when the subject is created; and
  2. Guarantees global uniqueness.

The only exception to this is the document-level UUID, which is used for version control.

Version 4 Universally Unique Identifier (UUID) as defined by RFC 4122 are a good fit for this use case and have been selected for use in OSCAL for this purpose.

Fields containing UUIDs tend to be named uuid in OSCAL. When an associated subject is created that has a uuid field, then a tool should automatically generate a UUId for this field.

UUIDs are intended to be consistently used to represent the same concept over multiple major and minor revisions of the same document; thus, they should only be changed if the underlying identified subject has changed in a significant way that no longer represents the same identified subject.

Example #1: If a person's phone number changes, a tool should update the phone number, but leave the party UUID for that person unchanged. Changing the person's phone number does not change their identity, or relationships involving this party in OSCAL content. If the person was replaced by someone new, the original person's party UUID should be retired and a different one used for their replacement.

Example #2: If a component represents a database, and the software version is updated, the UUID for that component should remain the same. If the database is replaced by a competing product from a different vendor, the component UUID should be updated.

Referencing Identifiers

Identifiers may be referenced from other locations within OSCAL content using one of the following:

  1. [name]-id or [name]-uuid, where name is a prefix indicating the type of referenced element or object;
  2. id-ref or uuid-ref, where the referenced element or object is not always the same type; or
  3. Uniform Resource Identifier (URI) Fragment: A value in a flag or field with a URI data type. A URI fragment starts with a hashtag (#) followed by a unique ID value. When used in an OSCAL file, this must be an ID or UUID.

Accepted Values

To facilitate consistent processing, the value for some fields is limited to a list of case-sensitive acceptable values. For some fields, OSCAL defines acceptable values, which are enforced by OSCAL-based syntax validation mechanisms.

Where OSCAL does not strictly limit the acceptable values, organizations are free to allow other values. The following is encouraged:

  • If OSCAL offers recommended values, these should be given preference and used whenever applicable.
  • If the organization defines other acceptable values:
    • these values should be lower case with no spaces and minimal special characters;
    • dashes are encouraged in place of spaces; and
    • the organization should publish a list of acceptable values for each field to ensure tool developers and the user community consistent use the same values.

Model Formats and Schema

For each OSCAL model, the OSCAL project is supporting XML-, JSON-, and YAML-based formats. The following types of schemas are also provided, which support validation of content expressed in a specific model format:

YAML is also supported as an OSCAL format. Since YAML is a superset of JSON and many tools support YAML validation using JSON Schema, no YAML-specific schemas are provided. Thus, the JSON documentation for each model also provides documentation around the structures used in the YAML formats. In the future, we plan to extend our models with mappings to other formats as well. Support for additional formats will be driven based on community feedback.

The OSCAL project is also producing content converters that can convert OSCAL formatted data from one format to other supported formats. Using OSCAL converters, XML documents that are conforming (validate) to an OSCAL XSD can be converted without loss into the corresponding JSON, and vice versa. Many tools commodity tools exist to support converting between JSON and YAML. As a result, the OSCAL project does not provide any OSCAL-specific content converters for this purpose. Using a commodity JSON <-> YAML tool, you can convert XML content to JSON and then to YAML or YAML content to JSON and then to XML.

Design principles for the schemas

The sample schemas have been created with the following design principles in mind:

  • Simplicity and ease of use. Every attempt is being made to use consistent data patterns and structures, and to reuse constructs across all OSCAL models. By establishing a set of "OSCAL-isms", common OSCAL data patterns, the models become more consistent and easier to use. This also helps to reduce the variability in the OSCAL models, keeping them simple.
  • Relevance for typical producers. The design of the OSCAL models incorporates the use of progressive features. A basic set of features can be used that mirror the degree of data currently provided in spreadsheets and documents pertaining to system implementations and assessment artifacts. This supports simple and easy use of OSCAL based on data that is available today. Additional optional features are provided that allow for more granular data, providing a path forward that enables the greater automation of processes.
  • Adaptability and extensibility. The sample schemas are designed to allow users and designers of applications to introduce new constructs and usages to support local requirements. In special cases, new schemas may be constructed to work with schemas already in use.

Modeling Approach

The OSCAL project is modeling each OSCAL layer using a modeling framework, called a Metaschema. As described above, this framework allows the OSCAL project to define each OSCAL model in a given OSCAL layer. The information domain of each model is defined using Metaschema, creating an information model for each OSCAL model. An OSCAL schema represents a data model that defines how to represent an OSCAL information model in a serialized format, such as JSON, YAML, or XML. The OSCAL project uses the Metaschema framework to produce these schemas supporting the XML, JSON, and YAML formats.

This framework is also used to generate converters capable of converting OSCAL content for a given model to another supported format, and to produce the documentation in this section of the website for each OSCAL model as it applies to each format.

In addition to providing improved control over modeling and documentation, the framework also enables OSCAL to serve the needs of developers who use one or many of the OSCAL formats. We hope and expect that developers' experience with different approaches will inform further efforts to unify and consolidate a coherent information model for the OSCAL models.

OSCAL Extensions

OSCAL models are designed to be broadly applicable to a variety of security compliance frameworks and organizational needs. Where an organization has unique modeling needs not supported by the core OSCAL syntax, it is possible to extend the syntax to address these requirements.

Models in OSCAL are organized hierarchically. At each level of this hierarchy, OSCAL syntax provides property (JSON: property / XML: prop) and annotation (annotation) objects. While these are sometimes used for core OSCAL syntax, they can also be assigned an organizational namespace (ns) value, which uniquely identifies the organization creating the extension.

For any property or annotation identified with the organization's namespace, the organization may use any NCName value in the property/annotation's name. This allows the organization to define the containing content as required. Organizations are strongly encouraged to publish these extensions to their community of OSCAL tool developers.


Tools should always check for the ns assignment within properties and annotations. When no ns is provided, the default is, which means the annotation or property is assumed to be part of the core OSCAL syntax.

This is especially important as organizations extending OSCAL may use the same name value, but in a different namespace as compared to core OSCAL.

property[@name='status'][@ns=''] and property[@name='status'] are not the same; however, if a tool is only looking for property[@name='status'], it will inappropriately find the first property as well as the second.

   "properties": [
       "name": "status",
       "ns": "",
       "value": "fedramp-defined-status"
- name: status
  value: fedramp-defined-status

OSCAL Converters

Each publication of the OSCAL models includes the ability to convert OSCAL file between supported formats without content loss. This allows developers to use their preferred format. A tool designed for one format can accept other formats by simply converting to the supported format during import and/or converting to the alternative format during export.

Currently, converters are available to convert XML-based OSCAL files to JSON and JSON-based OSCAL files to XML.

This page was last updated on December 13, 2020.