Guide To OSCAL-based FedRAMP Content Rev5
Guide To OSCAL-based FedRAMP Content Rev5
FedRAMP® Content
User Implementation Guide
Fedramp2.0.0-oscal1.0.x
June 30, 2023
How to contact us
For questions about FedRAMP, or for questions about this document including how to use it,
contact [email protected].
fedramp.gov 1
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
TABLE OF CONTENTS
1. Overview ...................................................................................................................................4
1.1. Who Should Use This Document? ..................................................................................4
1.2. Related Documents .........................................................................................................4
1.3. Basic Terminology ...........................................................................................................4
6.1. XML and JSON Formats..................................................................................................5
6.2. OSCAL-based FedRAMP Templates ..............................................................................5
6.3. XML and JSON Technology Standards ..........................................................................6
6.3.1. NIST OSCAL Syntax Validation Mechanisms .......................................................... 6
6.3.2. NIST OSCAL Format Conversion Mechanisms ....................................................... 6
6.4. XPath Queries and References .......................................................................................7
7. Working with OSCAL Files .....................................................................................................8
7.1. File Content Concepts .....................................................................................................8
7.1.1. Resolved Profile Catalogs ...................................................................................... 10
7.2. Hierarchy and Sequence .............................................................................................. 11
7.2.1. Typical OSCAL Assembly Structure ....................................................................... 12
7.3. Multiple Layers of Validation ......................................................................................... 13
7.4. OSCAL’s Minimum File Requirements ......................................................................... 15
7.4.1. UTF-8 Character Encoding ..................................................................................... 17
7.4.2. OSCAL Syntax Version .......................................................................................... 17
7.4.3. Content Change Requirements .............................................................................. 19
7.4.4. Cryptographic Integrity (Future) .............................................................................. 19
7.4.5. Useful XPath Queries for Document Changes and OSCAL Syntax ...................... 19
7.4.6. OSCAL Syntax Versions......................................................................................... 20
7.5. Assigning Identifiers ...................................................................................................... 21
7.5.1. Uniqueness of Identifiers ........................................................................................ 21
7.5.2. Searching for Information by ID or UUID Values ................................................... 23
7.6. Handling of OSCAL Data Types ................................................................................... 25
7.6.1. Date and Time in OSCAL Files .............................................................................. 25
7.6.2. UUID Datatypes ...................................................................................................... 26
7.6.3. ID Datatypes ........................................................................................................... 27
fedramp.gov 2
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
fedramp.gov 3
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
1. Overview
It provides guidance and examples for an organization producing and using OSCAL-based,
FedRAMP-compliant files. Our goal is to enable your organization to develop tools that will
seamlessly ensure these standards are met so your security practitioners can focus on content
and accuracy rather than formatting and presentation.
TERM MEANING
must Indicates a required action.
should Indicates a recommended action, but not necessarily required.
may Indicates an optional action.
3.
You may submit your SSP, SAP, SAR, and POA&M to FedRAMP using either XML or JSON. If
necessary, FedRAMP's tools will convert the files for processing.
For more information on converting OSCAL files between XML and JSON, see Section
1.6.2, NIST OSCAL Format Conversion Mechanisms.
NOTE: NIST partially supports YAML (YAML) as an offshoot of JSON. FedRAMP will evaluate
the use of YAML for FedRAMP deliverables once NIST offers the same level of support for
YAML syntax validation and format conversion.
fedramp.gov 5
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
• https://github.com/GSA/fedramp-automation/tree/master/dist/content/rev5/templates
While not mandatory, organizations adopting OSCAL are strongly encouraged to use the NIST-
published validation and translation mechanisms. The validation mechanism ensures XML and
JSON files are using OSCAL-compliant syntax, while the translation mechanism converts
OSCAL content from either format to the other. NIST has an automated governance process,
which ensures these mechanisms remain aligned with the latest OSCAL syntax.
TIP: There are comments in the XML versions of the FedRAMP Templates. Unfortunately,
JSON does not formally support comments. JSON users may wish to review the
comments in the equivalent sections of the XML files.
Validating XML-based OSCAL files using the NIST-published schema validation requires:
XML Schema Definition Language (XSD) 1.1
[https://www.w3.org/TR/xmlschema11-1/]
Validating JSON-based OSCAL files using the NIST-published schema validation requires:
JSON Schema, draft-07
[https://json-schema.org/specification-links.html#draft-7]
There are several open-source and commercial tools that will process XSD 1.1 or JSON Schema, draft-07,
either as stand-alone capabilities or as programming libraries.
FedRAMP and NIST are unable to endorse specific products.
fedramp.gov 6
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
For more information on converting OSCAL files between supported formats, please see the
information at the following links:
• OSCAL Converters
• Converting OSCAL XML Content to JSON
• Converting OSCAL JSON Content to XML
Except where noted, all XPath queries in this document are based on XPath 2.0. Most modern
programming languages make XPath 1.0 available by default. XPath 2.0 can typically be added
with third-party libraries or calls to external command-line utilities.
JSON Users: There are several JSON query technologies available, such as JSONPath
[https://restfulapi.net/json-jsonpath/]; however, no one technology has emerged as a clear
standard as of this publication.
Most XPath queries in this document are absolute paths from the root of the document. In other
words, it is clear from the XPath query which of the major file sections described in Section 2.3
is being referenced, and where the field is located within the section.
Database Users: Some tool developers prefer to manage OSCAL data by first importing
it into a database, which is a perfectly acceptable approach. Any OSCAL file generated
from the database must still follow the OSCAL syntax. If the file is intended for delivery to
FedRAMP, it must also follow the guidance in these guides.
There are also database-like XML servers, such as the open-source tool BaseX
[http://www.basex.org/], which allow OSCAL files to remain in their native format yet be
queried more like a traditional database. These XML databases typically optimize queries
for better performance. Some will handle both XML and JSON files.
fedramp.gov 7
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
Security Security
FedRAMP
NIST SP 800-53 System Security Assessment Plan Assessment Report
Baseline
(OSCAL Catalog) Plan (OSCAL Assessment (OSCAL Assessment
(OSCAL Profile)
Plan) Results)
fedramp.gov 8
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
NIST SP 800-53 FedRAMP Baseline System Security Security Security Plan of Action and
(OSCAL Catalog) (OSCAL Profile) Plan Assessment Plan Assessment Report Milestones
(OSCAL Assessment (OSCAL Assessment (POA&M)
Plan) Results)
Controls in this
Baseline Planned In-Scope
Control Definitions CSP s Control Actual In-Scope
Controls for
FedRAMP Implementation Controls Assessed
Assessment
Modifications
NIST SP 800-53A Empty Test Case Empty Test Case Populated Test Case POA&M Entries
Assessment Workbook Workbook Workbook
Objectives (With Adjustments) Assessment Actions
(by Control) FedRAMP Required Planned In-Scope and Findings
NIST SP 800-53A Assessment Actions Assessment Findings for Each
Assessment Actions for Each Objective Objectives and Objective
(by Control) Actions
SSP Discrepancies
TEST, INSPECT,
Found
INTERVIEW
Risk Exposure POA&M Entries
Table
Deviations: Deviations:
FP, OR, RA FP, OR, RA
System Description
and Architecture
Users
Planned In-Scope Assessed System Basic System
System Components System Details Details Information
& Inventory
Locations
The SAP also inherits the SSP's pointer to the appropriate OSCAL-based FedRAMP Baseline.
Through that linkage, the SAP references the assessment objectives and actions typically
identified in the FedRAMP TCW.
The only reason to include this content in the SAP is when the assessor documents a deviation
from the SSP, Baseline, or TCW.
fedramp.gov 9
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
Where available, tool developers have the option of following the links from the profile to the
catalog as described above or using the resolved profile catalog.
Developers should be aware that at this time catalogs and profiles remain relatively static. As
OSCAL gains wider adoption, there is a risk that profiles and catalogs will become more
dynamic, and a resolved profile catalog becomes more likely to be out of date. Early adopters
may wish to start with the resolved profile catalog now, and plan to add functionality later for the
separate profile and catalog handling later in their product roadmap.
Security Security
FedRAMP
System Security Assessment Plan Assessment Report
Baseline
Plan (OSCAL Assessment (OSCAL Assessment
(OSCAL Resolved Profile Catalog)
Plan) Results)
The Resolved Profile Catalog for each FedRAMP Baseline reduce tool processing
For more information about resolved profile catalogs, see Appendix C, Profile Resolution.
fedramp.gov 10
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
The same field name is interpreted differently in different assemblies. For example, the title
field under metadata is the document title, while the title field under role gives a human-
friendly name to that role.
For XML, the sequence of fields and assemblies (elements) is also important. JSON typically
does not require a specific sequence fields and assemblies (objects). Where sequence is
important, OSCAL uses array objects in JSON.
For example, within the metadata assembly, XML must find title, published, last-
modified, version, and oscal-version in exactly that order. The published field is
optional and may be omitted, but if present, it must be in that position relative to the other fields.
When using JSON, these fields are allowed in any order within the metadata assembly.
Tools must ensure this sequence is maintained when creating or modifying XML-based OSCAL
files. NIST’s XML documentation presents the fields and assemblies in the correct sequence.
• SSP: https://pages.nist.gov/OSCAL/reference/latest/system-security-plan/xml-outline/
• SAP: https://pages.nist.gov/OSCAL/reference/latest/assessment-plan/xml-outline/
• SAR: https://pages.nist.gov/OSCAL/reference/latest/assessment-results/xml-outline/
• POA&M: https://pages.nist.gov/OSCAL/reference/latest/plan-of-action-and-milestones/xml-
outline/
fedramp.gov 11
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
• title (field): Typically only one title is allowed. Sometimes it is optional. This is a
markup-line datatype.
• description (field): Typically only one description field is allowed. Sometimes it is
optional. This is a markup-multiline datatype.
• prop (fields): There may be many prop fields. The name flag identifies the specific
annotation. The value flag is a string datatype and holds the intended value. The prop
field includes an optional uuid flag to give a globally unique identifier, an optional ns
field to allow for namespacing the prop and indicate it is optional information that is not
of core OSCAL syntax and a class flag to sub-class one or more instances of the prop
into specific sub-groups.
• link (fields): There may be many link fields. The href flag allows a uniform resource
identifier (URI) or URI fragment to a related item. Often, href fields point to a resource
in back matter using its UUID value in the form of href="#[uuid-value]".
• assembly-specific fields
• remarks (field): Typically only one remarks field is allowed. It is always optional. This
is a markup-multiline datatype.
While this is not universal in OSCAL, when any of these fields are present, they follow this
pattern.
The prop field is present to allow OSCAL extensions within each assembly. See Section 3,
FedRAMP Extensions and Accepted Values for more information on FedRAMP's use of OSCAL
extensions.
fedramp.gov 12
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
LAYER DESCRIPTION
Well-Formed The XML or JSON file follows the rules defined for that format.
Any tool that processes the format will recognize it as “well-formed,” which
means the tool can proceed with processing the XML or JSON.
XML: https://www.w3.org/TR/REC-xml/
JSON: https://json.org/
OSCAL Syntax The XML or JSON file only uses names and values defined by NIST for
OSCAL.
NIST publishes schema validation tools to verify syntax compliance based
on the following standards:
XML Syntax Validation: XML Schema Definition Language (XSD) 1.1
JSON Syntax Validation: JSON Schema, draft 07
OSCAL Content For certain OSCAL fields, the NIST syntax validation tools also enforce
content - allowing only a pre-defined set of values to be used in certain
fields.
For example, Within the SSP model, impact levels within the information
type assemblies only allow the following values: fips-199-low, fips-
199-moderate, and fips-199-high. Any other value will cause an
error when validating the file.
In the core OSCAL syntax, the ns flag is never used. Where FedRAMP
extends OSCAL, the value for ns is always:
https://fedramp.gov/ns/oscal (case sensitive).
fedramp.gov 13
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
fedramp.gov 14
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
• The root element of the file indicates the Universally Unique Identifier (UUID)
type of content within the body of the file.
The recognized OSCAL root element Metadata
types are as follows: Must be at the start of every OSCAL file.
Syntax is the same, regardless of root element.
– catalog: Contains a catalog of
control definitions, control objectives,
and assessment activities, such as • Title, Modified Date, OSCAL Syntax Version
NIST SP 800-53 and 800-53A. • Document Date and Version
• Roles, People, Organizations, Locations
– profile: Contains a control baseline,
such as FedRAMP Moderate
Body
– component: Contains information Syntax is different for each root element.
about a product, service, or other
security capability, such as the
Back Matter
controls it can satisfy.
May be at the end of any OSCAL file.
– system-security-plan: Describes a Syntax is the same, regardless of root element.
system and its security capabilities,
including its authorization boundary • External Links and Citations
and a description of how each control • Attachments and Embedded Images
is satisfied.
– assessment-plan: Describes the
plan for assessing a specific system.
Anatomy of an OSCAL file
– assessment-results: Describes the
actual activities performed in the
assessment of a specific system, as well as the results of those activities.
– plan-of-action-and-milestones: Describes and tracks known risks to a system, as well
as the plan for remediation.
• The Universally Unique ID (UUID) at the root must be changed every time the content of the
file is modified.
fedramp.gov 15
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
• Every OSCAL file must have a metadata section and include a title, last-modified timestamp,
and OSCAL syntax version.
• The body of an OSCAL file is different for each model.
• Back matter syntax is identical in all OSCAL models. It is used for attachments, citations,
and embedded content such as graphics. Tool developers and content authors are
encouraged to attach content here and reference it from within the body of an OSCAL file.
fedramp.gov 16
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
The table below shows an empty OSCAL file, based purely on the NIST syntax; however,
FedRAMP requires much more in a minimum file. The latest OSCAL-based FedRAMP template
files can be found here in JSON and XML formats:
https://github.com/GSA/fedramp-automation/tree/master/dist/content/rev5/templates
<back-matter />
</OSCAL-root-element>
In XML, the first line in the example above ensures UTF-8 encoding is used. Other encoding
options will create unpredictable results.
Tools designed to read an OSCAL file must verify the oscal-version field to determine which
published syntax is used.
Tools designed to create or manipulate an OSCAL file must specify the syntax version of
OSCAL used in the file in the oscal-version field.
NIST ensures backward compatibility of syntax where practical; however, this is not always
possible. Some syntax changes between milestone releases leading up to OSCAL version 1.0
are unavoidable. NIST intends to keep all formally published schema validation files available,
which keeps validation and conversion tools available for older versions of OSCAL. See Section
2.4.6 OSCAL Syntax Versions for more information. FedRAMP releases indicate, in its trailing
half, the earliest version of OSCAL supported by baselines, templates, documentation, and
fedramp.gov 17
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
ancillary utilities. See the OSCAL Support and Deprecation Policy in the FedRAMP Automation
Github repository for further details.
fedramp.gov 18
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
• update the file's uuid flag (/*/@uuid) with a new UUID; and
• update the last-modified field (/*/metadata/last-modified) with the current
date and time. (Using the OSCAL date/time format, as described in Section 2.6.1 Date
and Time in OSCAL Files)
Tools that open or import OSCAL files should rely on the UUID value provided by the uuid flag,
and last-modified field as easy methods of knowing the file has changed.
NIST intends to add a cryptographic hash feature to OSCAL during calendar year 2021. Once
available, NIST will publish details here: https://pages.nist.gov/OSCAL/concepts/layer/
While tool developers are encouraged to perform their own integrity checking, it is important to
note cryptographic hash algorithms will produce a different result for inconsequential file
differences, such as different indentation or a change in the sequence of flags.
4.4.5. Useful XPath Queries for Document Changes and OSCAL Syntax
Below are a few important queries, which enable a tool to obtain critical information about any
OSCAL file.
XPath Queries
OSCAL syntax version used in this file:
/*/metadata/oscal-version
Last Modified Date/Time:
/*/metadata/last-modified
Unique Document ID:
/*/@uuid
Document Title:
/*/metadata/title
fedramp.gov 19
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
NIST always makes the latest version of syntax validation and format conversion files
available in the main OSCAL repository, including any changes since the last formal release.
To ensure stable resources, use a formal OSCAL release. NIST publishes formal OSCAL
releases here:
https://github.com/usnistgov/OSCAL/releases
To access OSCAL resources based on a particular release, click the tag to the left of the
release title.
fedramp.gov 20
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
NIST provides some standard identifiers. Where appropriate, FedRAMP has adopted those and
defined additional identifiers as needed. To ensure consistent processing, FedRAMP encourage
content creators to use the NIST and FedRAMP-defined identifiers to the greatest degree
practical. Deviation is likely to result in processing errors.
fedramp.gov 21
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
Some role ID values are prescribed by NIST, and others by FedRAMP. These are "reserved"
and must not be assigned to other roles for other reasons. The scope of this requirement goes
beyond the current OSCAL file to all files in the OSCAL stack as a result of import statements,
as described in Section 2.1, File Content Concepts.
For UUID fields, if using a tool that properly generates version 4 UUID values, no two will be
alike; however, buggy tools have been known to create unexpected duplicate values. In an
abundance of caution, tool developers are encouraged to check for unintended duplicates
whenever generating a new UUID values. At least during the testing phase of your development
lifecycle.
fedramp.gov 22
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
For example, a UUID reference in an OSCAL-based FedRAMP SAR could refer to a field or
assembly in the SAR, SAP, or SSP. XPath and similar standards only search the current file.
This requires OSCAL tools to search the current file first. If the ID or UUID is not found, the tool
should follow the file's import statement and search the next file the same way. This must be
repeated until either the ID/UUID is found, or all files in the stack have been processed. Of
course, tools may limit
In general, it is very simple to query for an ID or UUID value within an XML file. Simply use the
following XPath query:
//*[@id='id-value']
-OR-
//*[@uuid='uuid-value']
Of course, the tool must replace 'id-value' or 'uuid-value' above with the appropriate
reference.
Often flags that reference OSCAL information using its ID or UUID will have a name and context
that clarifies the expected target. For example, a flag may appear as follows:
<field-name component-uuid='1c23ddee-7001-4512-9de1-e062faa69c0a' />
To ensure this UUID value points to a component, use the following XPath query:
boolean(//*[@uuid='1c23ddee-7001-4512-9de1-e062faa69c0a']/name()='component')
If the above expression returns true, the UUID points to a component as intended.
Another approach is to limit the search only to fields or flags with a specific name.
The following will only find the UUID value if it is associated with a component. It would work in
the SSP, SAP, SAR and POA&M.
//component[@uuid='1c23ddee-7001-4512-9de1-e062faa69c0a']
fedramp.gov 23
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
The following will only find the UUID value if it is associated with a component in the system-
implementation assembly of the SSP. If the UUID value is
/*/system-implementation/component[@uuid='1c23ddee-7001-4512-9de1-
e062faa69c0a']
fedramp.gov 24
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
The following sections describe special handling considerations for data types that directly
impact FedRAMP content in OSCAL.
https://pages.nist.gov/OSCAL/reference/datatypes/#datetime-with-timezone
This means all dates and times must be represented in the OSCAL file using following format,
unless otherwise noted:
For example, a publication date of 5:30 pm EST, January 10, 2020 must appear as
2020-01-10T17:30:00.00-05:00
This includes:
• A capital letter Z to indicate the time is expressed in Coordinated Universal Time (UTC)
fedramp.gov 25
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
OR:
Tool developers are encouraged to present dates as they have historically appeared in
FedRAMP documents. In other words, tools should convert "2020-03-04T00:00:00.00-
05:00" to "March 4, 2020" when presenting the publication date to the user.
Please use the appropriate UTC offset in your region. If you are storing a date and padding the
time with zeros, you may also pad the UTC offset with zeros.
Any place a UUID flag or UUID reference exits, NIST requires UUID version 4, as defined by
RFC-4122. See here for more information:
https://pages.nist.gov/OSCAL/reference/datatypes/#uuid
Version 4 UUIDs are 128-bit numbers, represented as 32 hexadecimal (base-16) digits in the
pattern:
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
All alphabetic characters (a-f) representing hexadecimal values must be lower case.
Strictly following the RFC ensures the probability of generating an unintended duplicate UUID
value is so close to zero it may be ignored. As calculated on Wikipedia, after generating 103
trillion version 4 UUIDs, there is a one in a billion chance of a duplicate.
There are several open-source algorithms and built-in functions for generating UUID. It is
important to use one that is known to be fully compliant. Unintended duplicate UUIDs become
more likely when using non-compliant or erroneous algorithms.
For more information about the use of UUIDs in OSCAL, see Section 2.5, Assigning
Identifiers.
fedramp.gov 26
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
4.6.3. ID Datatypes
NIST typically uses ID flags in OSCAL where the identifier is intended to be canonical, such as
the identifiers for role IDs or NIST SP 800-53 controls.
Any place an ID flag or ID reference exits, the datatype is token. It is similar to the NCName as
defined by the World Wide Web Consortium (W3C), but does not allow spaces. The allowable
values of an NCName are limited as follows:
A tool developer may wish to assign UUID values to ID flags. UUIDs may start with a numeric
character, which is invalid for NCName. To ensure a valid datatype when using a UUID value in
an ID field, consider prepending "uuid-" to the UUID value.
For more information about the use of IDs in OSCAL, see Section 2.5, Assigning
Identifiers.
fedramp.gov 27
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
Absolute Paths: When using an absolute path within a FedRAMP OSCAL file, the path must
be publicly accessible from any location on the Internet, to ensure agency and FedRAMP
reviewers can reach the information.
Tool developers are encouraged to validate paths before storing or using them in OSCAL files
and raise issues to users if paths are not reachable.
Relative Paths: All relative paths are assumed to be based on the location of the OSCAL file,
unless tools are explicit as to other handling. Sensitive external documents should travel with
the OSCAL file and be linked using a relative path.
Internal Locations: These URI fragments appear as just a hashtag (#) followed by a name,
such as #a3e9f988-2db7-4a14-9859-0a0f5b0eebee. This notation points to a location
internal to the OSCAL content. Typically, this references to a resource assembly, but may
reference to any field or assembly with a unique ID or UUID.
If only a URI fragment (internal location) is present, the OSCAL tool must strip the hashtag (#)
and treat the remaining string as a UUID reference to a resource. The resource may exist in the
current OSCAL file, or one of the imported OSCAL files in the stack as described in Section 2.1,
File Content Concepts.
For example, the following OSCAL content contains a href flag with a URI fragment:
When a tool processes the above example, it should look inside the document for a field or
assembly with a UUID of "a3e9f988-2db7-4a14-9859-0a0f5b0eebee". This can be
accomplished with the following XPath query:
//*[@uuid="a3e9f988-2db7-4a14-9859-0a0f5b0eebee"]
fedramp.gov 28
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
If this is found to point to a resource assembly, see the Attachments and Embedded Content in
OSCAL Files section for additional handling.
The name of the field or assembly referenced by the above URI fragment can be determined
using the following XPath 2.0 query:
//*[@uuid="uri-fragment" | @id="uri-fragment"]/name()
name(//*[@uuid="uri-fragment" | @id="uri-fragment"])
The above query will return "resource", if the URI Fragment references the UUID of a
resource assembly.
NIST has implemented only a subset of formatting tags from these standards. This is to
ensure formatted content converts completely and consistently between XML and JSON in
either direction.
fedramp.gov 29
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
fedramp.gov 30
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
The example below is a common misuse of markup-multiline. The description contains text, but the
text is not enclosed in one of the required tags. This will produce an error when checked with the
OSCAL schema.
The simplest way to correct the error is to enclose the text in <p></p> tags, within the
description field.
The example below demonstrates a correct use of markup-multiline in XML. Please note, the
inclusion of a <p /> tag on a line by itself inserts an empty paragraph. Within XML and HTML,
this is treated as a shortcut, and is interpreted as "<p></p>"
fedramp.gov 31
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
<td>Cell B2</td>
</tr>
</table>
<h1>Big Header</h1>
<p>More detail</p>
<p><img alt="alt text" src="url" title="title text"/></p>
</description>
</system-characteristics>
Each resource may be referenced from anywhere in the OSCAL file, using its resource UUID.
<back-matter>
<resource uuid="3df7eeea-421b-459d-98cf-3d972bec610a">
<title>Attachment or Document Title</title>
<desc>An optional description of the attachment.</desc>
<rlink href="./relative/path/doc.pdf" media-type="application/pdf" />
<rlink href="/absolute/path/doc.pdf" media-type="application/pdf" />
<base64 filename="doc.pdf" media-type="application/pdf">
00000000
</base64>
</resource>
</back-matter>
fedramp.gov 32
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
The media-type flag should be present and must be set to an Internet Assigned Numbers
Authority (IANA) Media Type.
4.7.1. Citations
Citations are for reference. The content is not included with the authorization package.
Citations use an rlink field with an absolute path to content that is accessible by FedRAMP
and Agency reviewers from government systems.
Examples include links to publicly available laws such as FISMA, and applicable standards,
such NIST SP 800 series documents.
fedramp.gov 33
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
4.7.2. Attachments
Unlike citations, attachments are included with the authorization package when submitted.
Tools may either embed an attachment using the base64 field, or point to an attachment using
an rlink field. If no base64 embedded content is present, at least one rlink field must exist with
either an absolute path to content that is accessible by FedRAMP and Agency reviewers from
government systems, or a relative path.
If a relative path is used, the attachment must be delivered with the OSCAL file and packaged
such that the attachment exists in the correct relative location.
Examples include the logo for the CSP or 3PAO, authorization boundary diagrams, policies,
process, plans, raw scanner output, assessment evidence, and POA&M deviation request
evidence.
Tools should embed (base64) or link to (rlink) an attachment once as a resource in back-
matter, then use URI fragments to reference the attachment anyplace it is needed within the
body of the OSCAL file, as described in Section 2.5, Assigning Identifiers or Section 2.6.2,
Working With href Flags.
For example, a policy document that satisfies several control families is attached as a
resource in the back-matter, with a UUID of "3df7eeea-421b-459d-98cf-
3d972bec610a". Each control satisfied by that policy, links to the policy using a URI fragment
as follows:
<link href="#3df7eeea-421b-459d-98cf-3d972bec610a" rel="policy" />
As described in Section 2.6.2, Working With href Flags, when a tool identifies a URI fragment in
an href value, the leading hashtag (#) must be dropped and the remaining value is expected to
reference an OSCAL addressable ID or UUID. This ID/UUID may be either within the OSCAL
file itself, or within other OSCAL documents linked via the import field.
The policy's title, version, publication date and other details are defined once in the resource
and are displayed anyplace the policy is referenced. If a newer policy is published, only the one
resource in needs to be updated.
If the policy's location is identified as ="./policies/doc.pdf", the OSCAL file and the
doc.pdf file should be delivered together and packaged such that the folder containing the
OSCAL file includes a sub-folder named "policies", which contains the "doc.pdf" file.
fedramp.gov 34
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
When using attachments with relative paths, consider using a technology such as a ZIP archive
to package and deliver attachments while maintaining their relative position to the OSCAL file.
fedramp.gov 35
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
• Multiple Locations: Multiple rlink fields allow an OSCAL tool to include one rlink
field with an absolute path to the authoritative location of a policy document within the
CSP's intranet. The same resource could have a second rlink field with a relative
path to the same policy document. Having both allows the CSP to maintain the link to
authoritative location of the policy when working with the OSCAL file internally, while
allowing a cached, local copy to travel with the OSCAL file when delivered to FedRAMP
for review.
• Multiple Quality Levels: Multiple rlink or base64 fields allow both low-resolution and
high-resolution versions of the same image, which is sometimes used to boost the
performance of web-based applications.
• Multiple Formats: Multiple rlink or base64 fields allow a portable network graphic
(PNG) version of an image may be provided for presentation by a web application, and a
more detailed portable document format (PDF) version of the same image for download
by users.
fedramp.gov 36
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
This section describes FedRAMP's processing of multiple rlink and base64 fields, which will
be used by default unless a compelling circumstance requires otherwise.
FedRAMP accepts both base64 and rlink option content for diagrams and graphics.
FedRAMP prefers documents, such as policies and plans, are attached using rlink fields and
relative paths.
If the tool is designed to work interactively with a user, the tool developer should consider
designing the tool to make intelligent choices based on context and circumstances where
practical. The tool could also present valid choices to the user where the correct choice is
ambiguous to the tool.
When more than one rlink and/or base64 field is present in a resource, FedRAMP's automated
processing tools will attempt to find valid content using the following priority, unless specified
otherwise:
fedramp.gov 37
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
For policies, plans, user guides, and other documents, FedRAMP requires the document's title,
version, and publication date.
The following example demonstrates the inclusion of this content within a resource.
<back-matter>
<resource uuid="3df7eeea-421b-459d-98cf-3d972bec610a">
<title>Attachment or Document Title</title>
<prop name="type" value="policy"/>
<prop name="version" value="2.1"/>
<prop name="published" value="2018-11-11T00:00:00Z"/>
<base64>0000000</base64>
<rlink href="./rel/path/doc.pdf" media-type="application/pdf" />
<rlink href="/absolute/path/doc.pdf" media-type="application/pdf" />
</resource>
</back-matter>
The following represents an example linking a policy directly to the control it satisfies. (Legacy
approach)
<control-implementation>
<implemented-requirement control-id='ac-1' uuid="[uuid-value]">
<statement>
<link href="#090ab379-2089-4830-b9fd-26d0729e22e9"
rel="policy" />
</statement>
</implemented-requirement>
</control-implementation>
<back-matter>
<resource uuid="090ab379-2089-4830-b9fd-26d0729e22e9">
<title>Access Control and Identity Management Policy</title>
<description>
fedramp.gov 38
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
<p>Policy Document.</p>
</description>
<prop name="type" value="policy"/>
<base64 filename="./documents/policies/sample_policy.pdf">
0000
</base64>
</resource>
</back-matter>
The following represents an example linking a policy to the control it satisfies via the preferred
component-based approach.
<system-implementation>
<component uuid="f25e84bf-3e57-48c3-ac0b-7a567b3af79e" type="policy">
<title>[EXAMPLE]Access Control and Identity Management
Policy</title>
<description>
<p>[EXAMPLE]An example component representing a policy.</p>
</description>
<link href="#090ab379-2089-4830-b9fd-26d0729e22e9" rel="policy" />
<status state="operational"/>
</component>
</system-implementation>
<control-implementation>
<implemented-requirement control-id="ac-1" uuid="[uuid-value]">
<statement statement-id="ac-1_smt.a"
uuid="fb4d039a-dc4f-46f5-9c1f-f6343eaf69bc">
<by-component
component-uuid="f25e84bf-3e57-48c3-ac0b-7a567b3af79e">
<description>
<p>Describe how statement a is satisfied by this
policy.</p>
</description>
</by-component>
</statement>
</implemented-requirement>
</control-implementation>
<back-matter>
<resource uuid="090ab379-2089-4830-b9fd-26d0729e22e9">
<title>Access Control and Identity Management Policy</title>
<description>
<p>Policy Document.</p>
</description>
<prop name="type">policy</prop>
<base64
filename="./documents/policies/sample_policy.pdf">0000</base64>
fedramp.gov 39
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
</resource>
</back-matter>
NIST allows organizations to extend OSCAL anyplace prop fields or part assemblies exist in
the core syntax. (Please note, there are currently no part assemblies in the SSP, SAP, SAR,
or POA&M.) There are two fundamental requirements for extending OSCAL:
fedramp.gov 40
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
• The organization is responsible for defining, managing, and communicating all names
(name="scan-type") defined and tagged with the above name space identifier.
NIST's core OSCAL prop assemblies have no ns flag. If an ns flag is present, it is an
organization-defined extension. This allows each industry standards body or organization to
create their own extensions in their own name space without concern for overlapping names.
The above approach ensures two different organizations can create their own extensions
without concern for reusing the same name values. At some point in the future, NIST may
provide a registry for organizational extensions. For now, FedRAMP is publishing its own
registry to document its extensions.
For example, if the core OSCAL syntax has a status field, but both FedRAMP and the payment
card industry (PCI) require their own framework-specific status field, each may define an
extension with the name="status" and assign their own ns flag. This results in three possible
status fields as follows:
XPath Query
//prop[@name="user"][not(@ns)]
When searching an OSCAL file for a prop or prop extensions that is part of the core
OSCAL syntax, developers must filter out any with an ns flag using the syntax above.
XPath Query
//prop[@name="status"][@ns="https://fedramp.gov/ns/oscal"]
fedramp.gov 41
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
XPath Query
//prop[@name="user"][@ns="https://pcisecuritystandards.org/ns/oscal"]
Tool developers must always refer to extensions using both the name and ns flags as a pair.
NOTE: The catalog and profile OSCAL models also allow the part assembly to be used for
extensions. This is not currently the case for the OSCAL SSP, SAP, SAR, or POA&M.
FedRAMP extensions are cited in relevant portions of this document and summarized in
the FedRAMP OSCAL Registry.
• XML Version
• JSON Version
• HTML Version
fedramp.gov 42
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
Any remaining defined identifiers or accepted values are enumerated in the FedRAMP OSCAL
registry as allowed values.
Any remaining defined identifiers or accepted values are enumerated in the FedRAMP OSCAL
registry as allowed values.
In some cases, FedRAMP defines or adds allowed values specific to FedRAMP ATO
processing. Where defined, only these values are recognized by FedRAMP processing tools.
For example, every control requires an implementation status. FedRAMP only accepts one of
five possible responses for this status, which must be provided using one of the specified
choices.
FedRAMP allowed values are cited in relevant portions of each guidebook and
summarized in the FedRAMP OSCAL Registry.
fedramp.gov 43
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
• Document Basics:
– Document Title
– Document Publication Date
– Document Version
– Document Sensitivity & Ownership Markings
– Prepared By
– Prepared For
– Document Revision History
• OSCAL-Additional Document Basics:
– Last Modified Date
– OSCAL Syntax Version
• Logos:
– FedRAMP Logo
– CSP Logo
– Assessor Logo
– Consulting 3PAO Logo
• Attachments:
– FedRAMP Acronyms
– FedRAMP Citations (Laws, Regulations, Standards, and Guidance)
The following pages are formatted for tabloid (11" x 17") paper in landscape orientation.
fedramp.gov 44
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
As with any href value, this can include a relative or absolute URI external to the OSCAL file, or it XPath Queries
can contain a URI fragment, pointing to a resource inside the OSCAL file itself (or other OSCAL Document Title:
files in the stack). /*/metadata/title
Document Published Version #:
If the above returns an href value beginning with a hashtag (#), the rest of the value is the UUID /*/metadata/version
value for the resource containing the logo. Drop the hashtag and use the remaining value to locate
Document Published Date (will need to convert data for presentation):
the resource as follows: /*/metadata/published
/*/back-matter/resource[@uuid='[UUID-value-returned-above]']/rlink/@href FedRAMP's Logo:
/*/metadata/party[@uuid=../responsible-party[@role-id='fedramp-pmo']/party-
uuid]/link[@rel='logo']/@href
OR
Document Sensitivity Label (If more than one, tools should present all):
/*/back-matter/resource[@uuid='[UUID-value-returned-above]']/base64 /*/metadata/prop[@name="marking"]
45
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
NOTES:
• There may be more than one Document Sensitivity Label (marking) if needed.
– Tools should display and/or notify the user of all sensitivity markings.
• The logos on older FedRAMP Templates are not necessary. This includes the NIST Logo, as well as the three
Joint Authorization Board (JAB) Agency Logos.
46
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
Representation
<metadata>
<role id="prepared-by">
<title>Prepared By</title> NIST Allowed Value
<description><p>Description</p></description> Required Role ID:
</role>
<!-- cut: other role assemblies--> • prepared-by
<!-- cut: location assemblies-->
<party uuid="f84d8edc-d83e-440d-96c9-09b28c395ad5">
<name>Name of Consulting Org</name>
<short-name>Acronym/Short Name</short-name>
<address type="work">
<!-- address lines cut here for space -->
</address>
</party>
<!-- cut: other party assemblies -->
<responsible-party role-id="prepared-by">
<party-id>f84d8edc-d83e-440d-96c9-09b28c395ad5</party-id>
</responsible-party>
</metadata>
See Section 6.4 for "Prepared for" <!-- OSCAL File Body -->
<back-matter>
<resource id="1507f5e0-635c-4e23-a5f3-93f368f8e022">
<description><p>Peparer Logo</p></description>
<prop name="type" value="logo" />
<!-- Use rlink and/or base64 -->
<rlink href="./party-1-logo.png" media-type="image/png" />
<base64>00000000</base64>
</resource>
</back-matter>
XPath Queries
Preparer Organization's Name and Address:
/*/metadata/party[@id=[/*/metadata/responsible-party[@role-id='prepared-by']/party-
id]]/org/org-name
NOTE: Replace "org-name" with "address/addr-line", "address/city", "address/state", or
"address/zip" as needed. There may be more than one addr-line.
NOTES:
• The responsible-party assembly connects the role to the party and is required for compliance.
• If the content was prepared by an organization other than the CSP, their logo should also appear in back-
matter.
47
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
Representation
<metadata>
<role id="prepared-by">
<title>Prepared By</title> NIST Allowed Value
<description><p>Description</p></description> Required Role ID:
</role>
<!-- cut: location assemblies--> • prepared-by
<party id="2e0db7cf-08f5-472e-9360-fb3a9698476d">
<name>Cloud Service Provider (CSP) Name</name>
<short-name>CSP Acronym/Short Name</short-name>
<location-uuid>[uuid-value-of-location]</location-uuid>
</party>
<responsible-party role-id="prepared-by">
<party-id>c2e0db7cf-08f5-472e-9360-fb3a9698476dsp</party-id>
</responsible-party>
</metadata>
<back-matter>
<resource id="74a61c36-ad18-4ee3-8bc4-6e2f917b0ce8">
<description><p>CSP Logo</p></description>
<prop name="type" value="logo" />
See Section 6.4 for "Prepared for" <!-- Use rlink and/or base64 -->
<rlink href="./logo.png" media-type="image/png" />
<base64>00000000</base64>
</resource>
</back-matter>
XPath Queries
Preparer Organization's Name and Address:
/*/metadata/party[@id=[/*/metadata/responsible-party[@role-id='prepared-by']/party-
id]]/org/org-name
NOTE: Replace "org-name" with "address/addr-line", "address/city", "address/state", or
"address/zip" as needed. There may be more than one addr-line.
NOTES:
• The responsible-party assembly connects the role to the party and is required for compliance.
48
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
Representation
<metadata>
<!-- prop -->
See Sections 6.2 and 6.3 for "Prepared by" <role id="prepared-for">
<title>Prepared For</title>
<description><p>The CSP for FedRAMP SSP, SAP, SAR, and POA&M.</p></description>
</role>
<role id="cloud-service-provider">
<title>Cloud Service Provider</title>
<short-name>CSP</short-name>
</role>
<!-- cut: location assemblies-->
<party id="2e0db7cf-08f5-472e-9360-fb3a9698476d">
<name>Cloud Service Provider (CSP) Name</name>
<short-name>CSP Acronym/Short Name</short-name>
<location-uuid>[uuid-value-of-location]</location-uuid>
</party>
<!-- cut: other party assemblies -->
<responsible-party role-id="prepared-for">
<party-id>2e0db7cf-08f5-472e-9360-fb3a9698476d</party-id>
</responsible-party>
</metadata>
<!-- OSCAL File Body -->
<back-matter>
<resource id="74a61c36-ad18-4ee3-8bc4-6e2f917b0ce8">
<description><p>CSP Logo</p></description>
<prop name='type'>logo</prop>
<!-- Use rlink and/or base64 -->
<rlink href="./logo.png" media-type="image/png" />
<base64>00000000</base64>
</resource>
</back-matter>
XPath Queries
Prepared For (CSP) Details:
/*/metadata/party[@id=[/*/metadata/responsible-party[@role-id='prepared-for']/party-
id]]/org/org-name
Prepared For Details:
/*/metadata/party[@id=[/*/metadata/responsible-party[@role-id='prepared-for']/party-
id]]/org/org-name
NOTE: Replace "org-name" with "address/addr-line", "address/city", "address/state", or
"address/zip" as needed. There may be more than one addr-line.
49
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
Representation
<metadata>
<!-- title, published, last-modified, version, oscal-version -->
<revisions>
<revision>
<published>2022-06-01T00:00:00.000Z</published>
<version>1.0</version>
<oscal-version>1.0.4</oscal-version>
<prop name="party-uuid" ns="https://fedramp.gov/ns/oscal"
value="f84d8edc-d83e-440d-96c9-09b28c395ad5"/>
<remarks><p>Initial publication.</p></remarks>
</revision>
<revision>
<published>2022-06-01T00:00:00.000Z</published>
<version>2.0</version>
<oscal-version>1.0.4</oscal-version>
<prop name="party-uuid" ns="https://fedramp.gov/ns/oscal"
value="2e0db7cf-08f5-472e-9360-fb3a9698476d"/>
<remarks><p>Updated for annual assessment.</p></remarks>
</revision>
<!-- Additional revision assemblies as needed. -->
</revisions>
<!-- doc-id, prop, link, role -->
</metadata> FedRAMP Extension (Author)
prop
(ns="https://fedramp.gov/ns/oscal"):
XPath Queries
• name="party-uuid"
Number of Revision Entries:
count(/*/metadata/revision-history/revision)
Revision Date for Individual Entry:
/*/metadata/revision-history/revision[1]/published
Description for Individual Entry:
/*/metadata/revision-history/revision[1]/remarks/string()
Version for Individual Entry:
The remarks field is Markup multiline, which enables the text to be formatted. This requires /*/metadata/revision-history/revision[1]/version
special handling. See Section 2.5.3 Markup-line and Markup-multiline Fields in OSCAL, or visit: Author for Individual Entry:
https://pages.nist.gov/OSCAL/documentation/schema/datatypes/#markup-multiline /*/metadata/party[@uuid=/*/metadata/revision-history/revision[1]/prop [@name='party-
uuid'][@ns='https://fedramp.gov/ns/oscal']]/org/short-name
• The Revision History's Author field is addressed using a FedRAMP extension, which points to a metadata
party.
50
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
51
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
There must be a role defined in the file with the ID value set to "fedramp-pmo". There must be a party defined
with FedRAMP's details, and there must be a responsible-party defined, linking the "fedramp-pmo" role-id
to the FedRAMP party uuid.
Representation
<metadata>
<role id="fedramp-pmo">
<title>FedRAMP Program Management Office</title>
</role>
<responsible-party role-id="fedramp-pmo">
<party-uuid>77e0e2c8-2560-4fe9-ac78-c3ff4ffc9f6d</party-uuid>
</responsible-party>
XPath Queries
FedRAMP Email Address:
/*/metadata/party[@uuid=/*/metadata/responsible-party[@role-id='fedramp-pmo']
/party-uuid]/email
FedRAMP Web Site Address:
/*/metadata/party[@uuid=/*/metadata/responsible-party[@role-id='fedramp-pmo']
/party-uuid]/link/@href
52
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
Representation
<metadata>
<!-- title, published ... prop, link -->
<role id="content-approver">
<title>[SSP, SAP, or SAR] Approval</title>
<desc>The executive(s)accountable for the accuracy of this content.</desc>
</role>
<role id="cloud-service-provider">
<title>Cloud Service Provider</title>
<short-name>CSP</short-name> Defined Identifiers
</role>
<party uuid="uuid-of-csp" type="organization"> Required Role IDs:
<name>Cloud Service Provider (CSP) Name</name> • content-approver
<short-name>CSP Acronym/Short Name</short-name>
• cloud-service-provider
</party>
<party uuid="uuid-of-person-1" type="person">
<name>[SAMPLE]Person Name 1</name>
<prop name="title" ns="https://fedramp.gov/ns/oscal">Individual's Title</prop>
<member-of-organization>uuid-of-csp-party</member-of-organization>
</party>
<party uuid="uuid-of-person-2" type="person">
<name>[SAMPLE]Person Name 2</name>
<prop name="title" ns="https://fedramp.gov/ns/oscal">Individual's Title</prop>
<member-of-organization>uuid-of-csp</member-of-organization>
</party>
<responsible-party role-id="cloud-service-provider">
<party-uuid>uuid-of-csp</party-uuid>
</responsible-party> FedRAMP Extension (Person's Title)
<responsible-party role-id="content-approver">
<party-uuid>uuid-of-person-1</party-uuid> prop
<party-uuid>uuid-of-person-2</party-uuid> (ns="https://fedramp.gov/ns/oscal"):
</responsible-party> • name="title"
</metadata>
XPath Queries
Approver’s Name:
(/*/metadata/party[@uuid=[/*/metadata/responsible-party[@role-id='content-
approver']/party-uuid]]/party-name)[1]
Approver’s Title:
(/*/metadata/party[@uuid=[/*/metadata/responsible-party[@role-id='content-approver']
/party-uuid]]/prop[@name='title'][@ns='https://fedramp.gov/ns/oscal'])[1]
NOTE: For each additional approver, replace the "[1]" with "[2]", "[3]", and so on.
CSP Name:
/*/metadata/party[@uuid=[/*/metadata/responsible-party[@role-id='cloud-service-
provider']/party-uuid]]/party-name
53
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
NOTES:
The code above is an SSP example For SAP and SAR, a similar approach is used for the assessor, using the
"assessor" role ID instead of the "cloud-service-provider" role ID.
54
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
These are already included in the OSCAL-based FedRAMP templates as resources. The resource linking to the
FedRAMP citations file is identified with links from the property type, "fedramp-citations". The resource linking
to the FedRAMP acronyms file is identified with the property type, "fedramp-acronyms".
Representation
<metadata>
<!-- cut -->
<party uuid="77e0e2c8-2560-4fe9-ac78-c3ff4ffc9f6d" type="organization">
<name>FedRAMP: Program Management Office</name>
<short-name>FedRAMP PMO</short-name>
<link href="#985475ee-d4d6-4581-8fdf-d84d3d8caa48" rel="reference" />
<link href="#1a23a771-d481-4594-9a1a-71d584fa4123" rel="reference" />
</party>
</metadata>
<back-matter>
<resource uuid="985475ee-d4d6-4581-8fdf-d84d3d8caa48">
<title>FedRAMP Applicable Laws and Regulations</title>
<prop ns="https://fedramp.gov/ns/oscal" name="type" value="fedramp-citations"/>
<rlink href="https://-cut-/SSP-A12-FedRAMP-Laws-and-Regulations-Template.xlsx"/>
</resource>
<resource uuid="1a23a771-d481-4594-9a1a-71d584fa4123">
<title>FedRAMP Master Acronym and Glossary</title>
<prop ns="https://fedramp.gov/ns/oscal" name="type" value="fedramp-acronyms"/>
<rlink href="https://-cut-/FedRAMP_Master_Acronym_and_Glossary.pdf" />
</resource>
</back-matter>
XPath Queries
Link to FedRAMP Applicable Laws and Regulations:
/*/back-matter/resource/prop[@name='type']
[string(.)='fedramp-citations']/../rlink/@href
Link to FedRAMP Acronyms and Glossary:
/*/back-matter/resource/prop[@name='type']
[string(.)='fedramp-acronyms']/../rlink/@href
55
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
Each must have a type defined. The value of the type filed must be set to "law", "regulation", "standard", or "guidance"
as appropriate. There may be more than one type defined. FedRAMP tools use the type property to differentiate
these resource assemblies from others.
Representation
<back-matter>
<resource uuid="d45612a9-cf25-4ef6-b2dd-69e38ba2967a">
<title>[SAMPLE]Name or Title of Cited Law</title>
<prop name="type" value="law"/>
<prop name="publication" value="Document Date"/>
<prop name="version" value="Document Version"/>
<doc-id type="doi">Identification Number</doc-id>
<rlink href="https://domain.example/path/to/document.pdf" />
</resource>
<resource uuid="a8a0cc81-800f-479f-93d3-8b8743d9b98d">
<title>[SAMPLE]Name or Title of Cited Regulation</title>
<prop name="type" value="regulation"/>
<prop name="publication" value="Document Date"/>
<prop name="version" value="Document Version"/>
<doc-id type="doi">Identification Number</doc-id>
<rlink href="https://domain.example/path/to/document.pdf" />
</resource>
<!-- repeat citation assembly for each law, regulation, standard or guidance -->
<!-- resource -->
</back-matter>
XPath Queries
Replace "[1]" with "[2]", "[3]", etc.
Number of Laws and Regulations (integer):
count(/*/back-matter/resource/prop[@name="type"]
[(string(.) = "law") or (string(.)="regulation")])
Laws and Regulations - Identification Number:
(/*/back-matter/resource/prop[@name="type"]
[(string(.) = "law") or (string(.)="regulation")])[1]/../doc-id
Laws and Regulations - Title:
(/*/back-matter/resource/prop[@name="type"]
[(string(.) = "law") or (string(.)="regulation")])[1]/../title
Laws and Regulations - Date:
(/*/back-matter/resource/prop[@name="type"][(string(.) = "law") or
(string(.)="regulation")])[1]/../prop[@name="publication"]
Laws and Regulations - Link:
(/*/back-matter/resource/prop[@name="type"][(string(.) = "law") or
(string(.)="regulation")])[1]/../rlink/@href
NOTE: For Standards and Guidance replace "law" with "standard" and "regulation" with
"guidance" in the above queries to generate the Standards and Guidance tables.
56
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
Attachment Representation
<resource id="diag-boundary-1">
<description>
<p>The primary authorization boundary diagram.</p>
</description>
<!-- Add rlink with relative path or embed with base64 encoding -->
<rlink media-type="image/png" href="./boundary.png" />
<base64 media-type="image/png" filename="boundary.png">00000000</base64>
<remarks><p>Set system-characteristics/authorization-boundary/diagram/link/@href =
"#diag-boundary-1"</p></remarks>
</resource> Replace "policy" with "plan", "rob",
</back-matter> etc. for each attachment type.
XPath Queries
PIA Attachment (Embedded Base64 encoded):
/*/back-matter/resource/prop[@name='type']
[string(.)='privacy-impact-assessment']/.. /base64
PIA Attachment (Relative Link):
/*/back-matter/resource/prop[@name=type]
[string(.)='privacy-impact-assessment']/.. /rlink/@href
Publication Date of PIA:
/*/back-matter/resource/prop[@name=type]
[string(.)='privacy-impact-assessment']/../prop[@name="publication"]
57
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
Tools creating OSCAL content should include a media-type for all rlink and base64 fields, as well as a
filename for all base64 fields.
Tools should process rlink and base64 content with or without these fields. Where present they should be used
when validating or rendering the linked or embedded content.
58
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
APPENDICES
Appendix A. OSCAL-Based FedRAMP Baselines
NIST designed OSCAL catalogs as the primary source of control definition information from a
framework publisher. Catalogs are typically only published by organizations such as NIST for
NIST SP 800-53, or ISO/IEC for standards such as their 27000 series. If an organization has
unique control definitions that fall outside an applicable framework, the organization must create
a catalog containing those unique control definitions.
NIST designed profiles as the primary means of defining a baseline of controls. An OSCAL
profile may identify and even modify controls from one or more catalogs and even from other
profiles. This approach ensures control additions, modifications, or removal are fully traceable
back to the source of the modification.
OSCAL CATALOG
FedRAMP
FedRAMP Control Definition FedRAMP Control Selection
FedRAMP's baselines are represented as OSCAL profiles. The correct profile must be selected
from the SSP based on the system's identified security categorization level. This can be
checked using the XPath syntax below.
fedramp.gov 59
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
This determines which URL should be entered for the import-profile field in an OSCAL-
based FedRAMP SSP.
Baseline Representation
<!-- metadata -->
<!-- This must point to the appropriate FedRAMP Baseline -->
<import-profile href="https://path/to/FedRAMP_MODERATE-baseline_profile.xml"/>
<!-- system-characteristics -->
fedramp.gov 60
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
FedRAMP validation tools will compare the identified security categorization level to the actual
FedRAMP baseline specified in the SSP and raise a warning if a different baseline was used.
High (Rev 5)
XML Version:
https://raw.githubusercontent.com/GSA/fedramp-
automation/master/dist/content/rev5/baselines/xml/FedRAMP_rev5_HIGH-
baseline_profile.xml
JSON Version:
https://raw.githubusercontent.com/GSA/fedramp-
automation/master/dist/content/rev5/baselines/json/FedRAMP_rev5_HIGH-
baseline_profile.json
Moderate (Rev 5)
XML Version:
https://raw.githubusercontent.com/GSA/fedramp-
automation/master/dist/content/rev5/baselines/xml/FedRAMP_rev5_MODERATE-
baseline_profile.xml
JSON Version:
https://raw.githubusercontent.com/GSA/fedramp-
automation/master/dist/content/rev5/baselines/json/FedRAMP_rev5_MODERATE-
baseline_profile.json
Low (Rev 5)
XML Version:
https://raw.githubusercontent.com/GSA/fedramp-
automation/master/dist/content/rev5/baselines/xml/FedRAMP_rev5_LOW-
baseline_profile.xml
JSON Version:
https://raw.githubusercontent.com/GSA/fedramp-
automation/master/dist/content/rev5/baselines/json/FedRAMP_rev5_LOW-
baseline_profile.json
Do not copy and modify the FedRAMP baseline. FedRAMP will use the original, published
file for validation, ignoring any modified copies.
If you require a modification to the FedRAMP baselines, such as may be required when directed
to do so by an authorizing official, first contact FedRAMP to coordinate the modification, then
follow the instructions in Appendix B.
When FedRAMP publishes baselines for NIST SP 800-53 Revision 5, they will be located here:
https://github.com/GSA/fedramp-automation/tree/master/dist/content/rev5/baselines
fedramp.gov 61
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
FedRAMP Tailored
FedRAMP Tailored for Low Impact – Software as a Service (LI-SaaS) Appendix B merges SSP,
SAP, and SAR information into a single document. The SSP portions of that document may be
represented using the same OSCAL conventions described in this document with only a few
minor differences.
Specific OSCAL-based FedRAMP Tailored guidance will be published at a later date; however,
fully representing Appendix B in OSCAL requires the SSP, SAP, and SAR syntax, used the
same way as they are explained for FedRAMP Low, Moderate, and High baselines.
For your convenience, FedRAMP has made the FedRAMP Tailored for LI-SaaS baseline
available now in both XML and JSON formats as follows:
JSON Version:
https://raw.githubusercontent.com/GSA/fedramp-
automation/master/dist/content/rev5/baselines/json/FedRAMP_rev5_LI-SaaS-
baseline_profile.json
fedramp.gov 62
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
fedramp.gov 63
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
For more information on working with profiles, please visit the NIST OSCAL site at:
https://pages.nist.gov/OSCAL
fedramp.gov 64
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
</alter>
</modify>
</profile>
fedramp.gov 65
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
While this ensures traceability of selected controls and modified content, it can also be resource
intensive. Profile resolution flattens or merges a profile and its imported catalog(s) and profiles
into a single OSCAL file using the catalog syntax.
PROFILE RESOLUTION
SP 800-53 Control Definition SP 800-53 Control Selection SP 800-53 Control Selection SP 800-53 Control Definition
with FedRAMP Modifications
FedRAMP Control Modifications
SP 800-53 Control Definition SP 800-53 Control Selection SP 800-53 Control Selection SP 800-53 Control Definition
OSCAL CATALOG
FedRAMP
FedRAMP Control Definition FedRAMP Control Selection FedRAMP Control Definition
This single file is essentially a pre-processed result of the profile import and modification
content. A resolved profile catalog is useful for the FedRAMP baselines given their static nature.
Any tool that would normally open an OSCAL-based FedRAMP profile and process it against
the NIST SP 800-53 catalog can instead simply use the resolved-profile catalog.
Each FedRAMP XML and JSON baseline profile has a resolved profile catalog in the same
location as the pre-processed profile. Where available, these may be used by tools to save
processing time.
The merge assembly within an OSCAL profile offers a profile resolver control over how the final
file is organized. To maintain the same organization as within the catalog, simply use the as-is
field and set it to "yes."
fedramp.gov 66
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
https://pages.nist.gov/OSCAL/concepts/layer/control/profile/
fedramp.gov 67
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
https://github.com/usnistgov/OSCAL/tree/main/src/specifications/profile-resolution
https://github.com/usnistgov/OSCAL/tree/main/src/utils/util/resolver-pipeline
Currently the tool requires the profile and all imported catalogs and profiles to be in XML format.
For now, JSON content must be converted to XML before using this tool.
The tool requires an XSLT 3.1 processor, which is the same requirement for XML to JSON and
JSON to XML conversions.
All XSL files provided at the link above must be in the same directory. Only oscal-profile-
RESOLVE.xsl must be identified to the XSLT processor. All other files are called by this file as
part of processing.
It is also possible to run the scripts directly from the NIST OSCAL repository by supplying the
following URL directly to the XSLT processor:
https://raw.githubusercontent.com/usnistgov/OSCAL/main/src/utils/util/resolver-pipeline/oscal-
profile-RESOLVE.xsl
This is a new capability provided by NIST and leveraged by FedRAMP. Please report bugs or
provide feedback related to this tool directly to NIST at [email protected] or by submitting an issue
here:
https://github.com/usnistgov/OSCAL/issues
• role: A role ID and role title are required. Other content, such as a short-name,
description, or remarks are optional.
• location: Locations, such as corporate offices and data center addresses, are defined
as location assemblies
• party: People and organizations are defined as party assemblies. An organization is
any collection of people, and can represent a company, agency, department, or team.
fedramp.gov 68
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
• responsible-party: Links roles to parties. The same role can have more than one
party assigned to it. Also a party can be assigned to more than one role.
FedRAMP Defined Party Identifiers
FedRAMP has eliminated the use of FedRAMP-Defined Party Identifiers.
With the transition from ID to UUID for party identifiers this is no longer possible. Further, this
helps ensure OSCAL remains compatible with multiple compliance frameworks.
To ensure consistent processing, FedRAMP has defined a specific set of roles that must exist
with a FedRAMP SSP, SAP, SAR, or POA&M. Most are pre-populated in the OSCAL-based
FedRAMP Templates. They vary by template.
OSCAL-based FedRAMP tools must ensure these roles, titles, and descriptions exist using the
prescribed role IDs within an OSCAL-based FedRAMP file. Additional roles may be added,
provided these roles remain.
fedramp.gov 69
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
Some locations are required. For example, the SSP must contain the at least one location
assembly with the primary business address of the CSP. The SAP and SAR must contain at
least one location assembly with the primary business address of the assessor.
OSCAL allows the title field to be optional. FedRAMP strongly encourages its use. If the
country field is missing, FedRAMP tools will assume the address is within the United States of
America.
<metadata>
<!-- role -->
<location uuid="uuid-of-hq-location">
<title>CSP HQ</title>
<address type="work">
<addr-line>1234 Some Street</addr-line>
<city>Haven</city>
<state>ME</state>
<postal-code>00000</postal-code>
<country>us</country>
</address>
<prop name="type" class="primary" value="data-center"/>
</location>
<!-- party -->
</metadata>
Some locations require type properties to ensure FedRAMP tools can accurately identify
required content. For example, the location assembly for a data center must include a type
property with a value of "data-center". The class may be used to indicate whether the data
center is "primary" or "alternate".
fedramp.gov 70
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
Contact details, such as an individual's email address and phone number, or a business web
site, may be included and are often required within FedRAMP artifacts. A short-name filed
provides an ability to define an organization's acronym or desired abbreviation. This is required
for the CSP, assessor, and any Agency.
<metadata>
<!-- role -->
<party uuid="uuid-of-csp" type="organization">
<name>Cloud Service Provider (CSP) Name</name>
<short-name>CSP Acronym</short-name>
<link href="https://www.csp.com" />
</party>
FedRAMP extensions are cited in relevant portions of each guide, and summarized in the
FedRAMP OSCAL Registry.
fedramp.gov 71
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
fedramp.gov 72
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
Preferred Approach: When multiple parties share the same address, such as multiple staff
members at a company HQ, define the address once as a location assembly, then use the
location-uuid field within each party assembly to identify the location of that individual or
team.
Alternate Approach: If the address is unique to this individual, it may be included in the party
assembly itself.
A tool developer may elect to always create a location assembly, even when only used once;
however, tools must recognize and handle all of the approaches above when processing
OSCAL files.
<metadata>
<!-- cut -->
<location uuid="uuid-of-hq-location">
<title>CSP HQ</title>
<address type="work">
<addr-line>1234 Some Street</addr-line>
<city>Haven</city>
<state>ME</state>
<postal-code>00000</postal-code>
</address>
</location>
fedramp.gov 73
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023
For example, an OSCAL-based SSP must have a role defined for the System Owner using the
role ID value "system-owner". The responsible-party assembly links this required role to the
individual (party). FedRAMP tools follow this linkage to verify that a system owner was identified
in the SSP, and to display that information to reviewers.
<metadata>
<!-- party -->
<responsible-party role-id="system-owner">
<party-uuid>uuid-of-person-1</party-uuid>
</responsible-party>
</metadata>
fedramp.gov 74