Control Mapping Model prototype-mapping-model XML Format Index
The following is a reference for the XML element and attribute types derived from the metaschema for this model.
Short name oscal-mapping
XML namespace http://csrc.nist.gov/ns/oscal/1.0
Remarks
The OSCAL Control mapping format can be used to describe how a collection of security
controls and related control enhancements relate to another collection of controls.
The root of the Control Catalog format is mapping-collection.
description An action applied by a role within a given party to the content.
Constraints (4)
index has key for responsible-partythis value must correspond to a listing in the index index-metadata-role-id using a key constructed of key field(s) @role-id
index has key for responsible-partythis value must correspond to a listing in the index index-metadata-party-uuid using a key constructed of key field(s) party-uuid
allowed value for ./system/@value
The value may be locally defined, or the following:
- http://csrc.nist.gov/ns/oscal: This value identifies action types defined in the NIST OSCAL namespace.
allowed values for ./type[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@value
The value must be one of the following:
- approval: An approval of a document instance's content.
- request-changes: A request from the responisble party or parties to change the content.
Attributes (4):
description A unique identifier that can be used to reference this defined action elsewhere in an OSCAL document. A UUID should be consistently used for a given location across revisions of the document.
description The date and time when the action occurred.
description The type of action documented by the assembly, such as an approval.
description Specifies the action type system used.
Remarks
Provides a means to segment the value space for the type, so that different organizations and individuals can assert control over the allowed
action's type. This allows the semantics associated with a given type to be defined on an organization-by-organization basis.
An organization MUST use a URI that they have control over. e.g., a domain registered to the organization in a URI, a registered uniform resource names (URN) namespace.
Elements (4):
use name prop
Remarks
Properties permit the deployment and management of arbitrary controlled values, within OSCAL objects. A property can be included for any purpose useful to an application or implementation. Typically, properties will be used to sort, filter, select, order, and arrange OSCAL content objects, to relate OSCAL objects to one another, or to associate an OSCAL object to class hierarchies, taxonomies, or external authorities. Thus, the lexical composition of properties may be constrained by external processes to ensure consistency.
Property allows for associated remarks that describe why the specific property value was applied to the containing object, or the significance of the value in the context of the containing object.
Remarks
To provide a cryptographic hash for a remote target resource, a local reference to
a back matter resource is needed. The resource allows one or more hash values to be provided using the rlink/hash object.
The OSCAL link is a roughly based on the HTML link element.
Remarks
A responsible-party requires one or more party-uuid references creating a strong relationship arc between the referenced role-id and the reference parties. This differs in semantics from responsible-role which doesn't require that a party-uuid is referenced.
The scope of use of this object determines if the responsibility has been performed or will be performed in the future. The containing object will describe the intent.
Remarks
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported
by OSCAL.
description A single line of an address.
description A postal address for the location.
Attribute (1):
use name type
Elements (5):
description City, town or geographical region for the mailing address.
description State, province or analogous geographical region for a mailing address.
description Postal or ZIP code for mailing address.
description The ISO 3166-1 alpha-2 country code for the mailing address.
Constraint (1)
matches: a target (value) must match the regular expression '[A-Z]{2}'.
description A collection of resources that may be referenced from within the OSCAL document instance.
Remarks
Provides a collection of identified resource objects that can be referenced by a link with a rel value of "reference" and an href value that is a fragment "#" followed by a reference to a reference's uuid. Other specialized link "rel" values also use this pattern when indicated in that
context of use.
Constraint (1)
index for resource an index index-back-matter-resource shall list values returned by targets resource using keys constructed of key field(s) @uuid
Elements (1):
description A resource associated with content in the containing document instance. A resource may be directly included in the document using base64 encoding or may point to one or more equivalent internet resources.
Remarks
A resource can be used in two ways. 1) it may point to an specific retrievable network
resource using a rlink, or 2) it may be included as an attachment using a base64. A resource may contain multiple rlink and base64 entries that represent alternative download locations (rlink) and attachments (base64)
for the same resource.
Both rlink and base64 allow for a media-type to be specified, which is used to distinguish between different representations of
the same resource (e.g., Microsoft Word, PDF). When multiple rlink and base64 items are included for a given resource, all items must contain equivalent information.
This allows the document consumer to choose a preferred item to process based on a
the selected item's media-type. This is extremely important when the items represent OSCAL content that is represented
in alternate formats (i.e., XML, JSON, YAML), allowing the same OSCAL data to be processed
from any of the available formats indicated by the items.
When a resource includes a citation, then the title and citation properties must both be included.
Constraints (6)
allowed values for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
The value must be one of the following:
- type: Identifies the type of resource represented. The most specific appropriate type value SHOULD be used.
- version: For resources representing a published document, this represents the version number of that document.
- published: For resources representing a published document, this represents the publication date of that document.
matches for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='published']/@value: the target value must match the lexical form of the 'dateTime-with-timezone' data
type.
allowed values for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='type']/@value
The value must be one of the following:
- logo: Indicates the resource is an organization's logo.
- image: Indicates the resource represents an image.
- screen-shot: Indicates the resource represents an image of screen content.
- law: Indicates the resource represents an applicable law.
- regulation: Indicates the resource represents an applicable regulation.
- standard: Indicates the resource represents an applicable standard.
- external-guidance: Indicates the resource represents applicable guidance.
- acronyms: Indicates the resource provides a list of relevant acronyms.
- citation: Indicates the resource cites relevant information.
- policy: Indicates the resource is a policy.
- procedure: Indicates the resource is a procedure.
- system-guide: Indicates the resource is guidance document related to the subject system of an SSP.
- users-guide: Indicates the resource is guidance document a user's guide or administrator's guide.
- administrators-guide: Indicates the resource is guidance document a administrator's guide.
- rules-of-behavior: Indicates the resource represents rules of behavior content.
- plan: Indicates the resource represents a plan.
- artifact: Indicates the resource represents an artifact, such as may be reviewed by an assessor.
- evidence: Indicates the resource represents evidence, such as to support an assessment finding.
- tool-output: Indicates the resource represents output from a tool.
- raw-data: Indicates the resource represents machine data, which may require a tool or analysis for interpretation or presentation.
- interview-notes: Indicates the resource represents notes from an interview, such as may be collected during an assessment.
- questionnaire: Indicates the resource is a set of questions, possibly with responses.
- report: Indicates the resource is a report.
- agreement: Indicates the resource is a formal agreement between two or more parties.
has cardinality for rlink|base64 the cardinality of rlink|base64 is constrained: 1; maximum unbounded.
is unique for rlink: any target value must be unique (i.e., occur only once)
is unique for base64: any target value must be unique (i.e., occur only once)
Attribute (1):
description A unique identifier for a resource.
Elements (8):
description An optional name given to the resource, which may be used by a tool for display and navigation.
description An optional short summary of the resource used to indicate the purpose of the resource.
use name prop
Remarks
Properties permit the deployment and management of arbitrary controlled values, within OSCAL objects. A property can be included for any purpose useful to an application or implementation. Typically, properties will be used to sort, filter, select, order, and arrange OSCAL content objects, to relate OSCAL objects to one another, or to associate an OSCAL object to class hierarchies, taxonomies, or external authorities. Thus, the lexical composition of properties may be constrained by external processes to ensure consistency.
Property allows for associated remarks that describe why the specific property value was applied to the containing object, or the significance of the value in the context of the containing object.
Remarks
A document identifier provides a globally unique identifier with a cross-instance scope that is used for a group of documents that are to be treated as different versions, representations or digital surrogates of the same document.
A document identifier provides an additional data point for identifying a document that can be assigned by a publisher or organization for purposes in a wider system, such as a digital object identifier (DOI) or a local content management system identifier.
Use of a document identifier allows for document creators to associate sets of documents
that are related in some way by the same document-id.
An OSCAL document always has an implicit document identifier provided by the document's
UUID, defined by the uuid on the top-level object. Having a default UUID-based identifier ensures all documents
can be minimally identified when other document identifiers are not provided.
description An optional citation consisting of end note text using structured markup.
Elements (3):
description A line of citation text.
use name prop
Remarks
Properties permit the deployment and management of arbitrary controlled values, within OSCAL objects. A property can be included for any purpose useful to an application or implementation. Typically, properties will be used to sort, filter, select, order, and arrange OSCAL content objects, to relate OSCAL objects to one another, or to associate an OSCAL object to class hierarchies, taxonomies, or external authorities. Thus, the lexical composition of properties may be constrained by external processes to ensure consistency.
Property allows for associated remarks that describe why the specific property value was applied to the containing object, or the significance of the value in the context of the containing object.
Remarks
To provide a cryptographic hash for a remote target resource, a local reference to
a back matter resource is needed. The resource allows one or more hash values to be provided using the rlink/hash object.
The OSCAL link is a roughly based on the HTML link element.
description A URL-based pointer to an external resource with an optional hash for verification and change detection.
Remarks
Multiple rlink objects can be included for a resource. In such a case, all provided rlink items are intended to be equivalent in content, but may differ in structure or format.
A media-type is used to identify the format of a given rlink, and can be used to differentiate
items in a collection of rlinks. The media-type provides a hint to the OSCAL document consumer about the structure of the resource
referenced by the rlink.
Attributes (2):
description A resolvable URL pointing to the referenced resource.
Remarks
This value may be either:
- an absolute URI that points to a network resolvable resource,
- a relative reference pointing to a network resolvable resource whose base URI is the URI of the containing document, or
Remarks
The Internet Assigned Numbers Authority (IANA) Media Types Registry defines a standardized set of media types, which may be used here.
The application/oscal+xml, application/oscal+json or application/oscal+yaml media types SHOULD be used when referencing OSCAL XML, JSON, or YAML resources respectively.
**Note: There is no official media type for YAML at this time.** OSCAL documents should
specify application/yaml for general YAML content, or application/oscal+yaml for YAML-based OSCAL content. This approach aligns with use of a structured name
suffix, per RFC 6838 Section 4.2.8.
Some earlier OSCAL content incorporated the model into the media type. For example:
application/oscal.catalog+xml. This practice SHOULD be avoided, since the OSCAL model can be detected by parsing
the initial content of the referenced resource.
Elements (1):
description A hash of the resource identified by href, which can be used to verify the resource was not changed since it was hashed.
Remarks
The hash value can be used to confirm that the resource referenced by the href is the same resources that was hashed by retrieving the resource, calculating a hash,
and comparing the result to this value.
description A resource encoded using the Base64 alphabet defined by RFC 2045.
Attributes (2):
description Name of the file before it was encoded as Base64 to be embedded in a resource. This is the name that will be assigned to the file when the file is decoded.
Remarks
The Internet Assigned Numbers Authority (IANA) Media Types Registry defines a standardized set of media types, which may be used here.
The application/oscal+xml, application/oscal+json or application/oscal+yaml media types SHOULD be used when referencing OSCAL XML, JSON, or YAML resources respectively.
**Note: There is no official media type for YAML at this time.** OSCAL documents should
specify application/yaml for general YAML content, or application/oscal+yaml for YAML-based OSCAL content. This approach aligns with use of a structured name
suffix, per RFC 6838 Section 4.2.8.
Some earlier OSCAL content incorporated the model into the media type. For example:
application/oscal.catalog+xml. This practice SHOULD be avoided, since the OSCAL model can be detected by parsing
the initial content of the referenced resource.
Remarks
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported
by OSCAL.
description If automation is used, this can record a confidence score, if assigned.
description A document identifier qualified by an identifier scheme.
Remarks
A document identifier provides a globally unique identifier with a cross-instance scope that is used for a group of documents that are to be treated as different versions, representations or digital surrogates of the same document.
A document identifier provides an additional data point for identifying a document that can be assigned by a publisher or organization for purposes in a wider system, such as a digital object identifier (DOI) or a local content management system identifier.
Use of a document identifier allows for document creators to associate sets of documents
that are related in some way by the same document-id.
An OSCAL document always has an implicit document identifier provided by the document's
UUID, defined by the uuid on the top-level object. Having a default UUID-based identifier ensures all documents
can be minimally identified when other document identifiers are not provided.
Attribute (1):
description Qualifies the kind of document identifier using a URI. If the scheme is not provided the value of the element will be interpreted as a string of characters.
Remarks
This value must be an absolute URI that serves as a naming system identifier.
Constraint (1)
allowed value
The value may be locally defined, or the following:
- http://www.doi.org/: A Digital Object Identifier (DOI); use is preferred, since this allows for retrieval of a full bibliographic record.
description An email address as defined by RFC 5322 Section 3.4.1.
description A by-id collection of all controls that were not mapped at all in this mapping-collection. If a control is partially mapped, the parts of the control are unmappable, the gap
and discrepancies should be documented in the relationship-gal.
Attribute (1):
description A machine-oriented, globally unique identifier with cross-instance scope that can be used to reference this mapping gap summary elsewhere in this or other OSCAL instances. The locally defined UUID of the SSP can be used to reference the data item locally or globally (e.g., in an imported
OSCAL instance).This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions
of the document.
Elements (1):
use name unmapped-controls
Remarks
If with-child-controls is yes
on the call to a control, no sibling callelements need to be used to call any controls appearing within it. Since generally,
this is how control enhancements are represented (as controls within controls), this
provides a way to include controls with all their dependent controls (enhancements)
without having to call them individually.
If with-child-controls is yes
on the call to a control, any controls appearing within it (child controls) will
be selected, with no additional call directives required. This flag provides a way to include controls with all their
dependent controls (enhancements) without having to call them individually.
description A representation of a cryptographic digest generated over a resource using a specified hash algorithm.
Constraints (4)
matches for .[@algorithm=('SHA-224','SHA3-224')]: a target (value) must match the regular expression '^[0-9a-fA-F]{28}$'.
matches for .[@algorithm=('SHA-256','SHA3-256')]: a target (value) must match the regular expression '^[0-9a-fA-F]{32}$'.
matches for .[@algorithm=('SHA-384','SHA3-384')]: a target (value) must match the regular expression '^[0-9a-fA-F]{48}$'.
matches for .[@algorithm=('SHA-512','SHA3-512')]: a target (value) must match the regular expression '^[0-9a-fA-F]{64}$'.
Attribute (1):
description The digest method by which a hash is derived.
Remarks
Any other value used MUST be a value defined in the W3C XML Security Algorithm Cross-Reference Digest Methods (W3C, April 2013) or RFC 6931 Section 2.1.5 New SHA Functions.
Constraint (1)
allowed values
The value may be locally defined, or one of the following:
- SHA-224: The SHA-224 algorithm as defined by NIST FIPS 180-4.
- SHA-256: The SHA-256 algorithm as defined by NIST FIPS 180-4.
- SHA-384: The SHA-384 algorithm as defined by NIST FIPS 180-4.
- SHA-512: The SHA-512 algorithm as defined by NIST FIPS 180-4.
- SHA3-224: The SHA3-224 algorithm as defined by NIST FIPS 202.
- SHA3-256: The SHA3-256 algorithm as defined by NIST FIPS 202.
- SHA3-384: The SHA3-384 algorithm as defined by NIST FIPS 202.
- SHA3-512: The SHA3-512 algorithm as defined by NIST FIPS 202.
description The date and time the document was last stored for later retrieval.
Remarks
This value represents the point in time when the OSCAL document was last updated, or at the point of creation the creation date. Typically, this date value will be machine generated at time of creation or modification. Ideally, this field will be managed by the editing tool or service used to make modifications when storing the modified document.
The intent of the last modified timestamp is to distinguish between significant change milestones when the document may be accessed by multiple entities. This allows a given entity to differentiate between mutiple document states at specific points in time. It is possible to make multiple modifications to the document without storing these changes. In such a case, the last modified timestamp might not be updated until the document is finally stored.
In some cases, an OSCAL document may be derived from some source material in a different
format. In such a case, the last-modified value should indicate the last modification time of the OSCAL document instance,
not the source material.
description A reference to a local or remote resource, that has a specific relation to the containing object.
Remarks
To provide a cryptographic hash for a remote target resource, a local reference to
a back matter resource is needed. The resource allows one or more hash values to be provided using the rlink/hash object.
The OSCAL link is a roughly based on the HTML link element.
Constraints (4)
A local reference SHOULD NOT have a media-type. Since both link and back-matter/resource both allow specification of a media-type, the media-type on link may conflict with the any media-type entries on a resource's rlink or base64 objects. This constraint prevents this from occurring.matches for .[@rel=('reference') and starts-with(@href,'#')]/@href: the target value must match the lexical form of the 'uri-reference' data type.
index has key for .[@rel=('reference') and starts-with(@href,'#')]this value must correspond to a listing in the index index-back-matter-resource using a key constructed of key field(s) @href
matches for .[@rel=('reference') and not(starts-with(@href,'#'))]/@href: the target value must match the lexical form of the 'uri' data type.
matches for @resource-fragment: a target (value) must match the regular expression '(?:[0-9a-zA-Z-._~/?!$&'()*+,;=:@]|%[0-9A-F][0-9A-F])+'.
Attributes (4):
description A resolvable URL reference to a resource.
Remarks
This value may be one of:
- an absolute URI that points to a network resolvable resource,
- a relative reference pointing to a network resolvable resource whose base URI is the URI of the containing document, or
- a bare URI fragment (i.e., `#uuid`) pointing to an OSCAL object by the objects identifier (e.g., id, uuid) in this or an imported document (see linking to another OSCAL object). The specific object type will differ based on the link relationship type.
description Describes the type of relationship provided by the link's hypertext reference. This can be an indicator of the link's purpose.
Constraint (1)
allowed value
The value may be locally defined, or the following:
- reference: A generalized reference to a network resource (relative or absolute) or to a back-matter resource by UUID expressed as a bare URI fragment.
Remarks
The Internet Assigned Numbers Authority (IANA) Media Types Registry defines a standardized set of media types, which may be used here.
The application/oscal+xml, application/oscal+json or application/oscal+yaml media types SHOULD be used when referencing OSCAL XML, JSON, or YAML resources respectively.
**Note: There is no official media type for YAML at this time.** OSCAL documents should
specify application/yaml for general YAML content, or application/oscal+yaml for YAML-based OSCAL content. This approach aligns with use of a structured name
suffix, per RFC 6838 Section 4.2.8.
Some earlier OSCAL content incorporated the model into the media type. For example:
application/oscal.catalog+xml. This practice SHOULD be avoided, since the OSCAL model can be detected by parsing
the initial content of the referenced resource.
The media-type provides a hint about the content model of the referenced resource. A valid entry
from the IANA Media Types registry SHOULD be used.
description In case where the href points to a back-matter/resource, this value will indicate the URI fragment to append to any rlink associated with the resource. This value MUST be URI encoded.
Elements (1):
description A textual label to associate with the link, which may be used for presentation in a tool.
description Indicates the type of address.
Constraint (1)
allowed values
The value may be locally defined, or one of the following:
- home: A home address.
- work: A work address.
description Reference to a location by UUID.
Constraint (1)
index has keythis value must correspond to a listing in the index index-metadata-location-uuid using a key constructed of key field(s) .
description Reference to a location by UUID.
Constraint (1)
index has keythis value must correspond to a listing in the index index-metadata-location-uuid using a key constructed of key field(s) .
description A relationship-based mapping between a source and target set consisting of members (i.e., controls, control statements) from the respective source and target.
Attributes (3):
description The unique identifier for the mapping entry.
description A namespace qualifying the relationship's value. This allows different organizations to associate distinct semantics for relationships with the same name.
Remarks
This value must be an absolute URI that serves as a naming system identifier.
When a ns is not provided, its value should be assumed to be http://csrc.nist.gov/ns/oscal and the name should be a name defined by the associated OSCAL model.
Elements (7):
description The relationship type for the mapping entry, which describes the relationship between
the effective requirements of the specified source and target sets in the context
of the matching-rationale method globaly defined in the provenance unless overwritten locally in the map. The relationship type and the matching-rationale must be used together. However, more than one matching-rationale method may apply to a source and target pair.
Remarks
For example, consider the CSF 1.1's PR.AC-1, "Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes", and the Privacy Framework's PR.AC-P1, "Identities and credentials are issued, managed, verified, and devices."
These two requirements have identical wording except for "users” versus “individuals” and the order of the last few words. With a `matching-rationale` of syntactic, the relationship type would beintersects with because the two overlap, but each includes content that the other does not. However, with a rationale of semantic, the relationship type would be equal if “users” and “individuals” have the same meaning in their respective sources, subset if “users” was a subset of “individuals,” and so on.
When establishing relationships, mapping SHOULD be done at the control statement level where possible. This approach allows for a more accurate relationship.
Constraint (1)
allowed values for .[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]
The value must be one of the following:
- equivalent-to: The source and target requirements are similar, although not necessarily identical. The words may differ, but both mapped sets convey similar information with the same effective meaning. This relationship may be reversed, since `A equivalent-to B` also means that `B equivalent-to A`. This relationship is less suitable for a syntactic matching-rationale .
- equal-to: The source and target requirements are the same. Differences in capitalization, spelling, and grammar can be ignored, if these differences do not change the meaning. This relationship may be reversed, since `A equal-to B` also means that `B equal-to A`.
- subset-of: The source requirements are a subset of target requirements. In other words, target contains all sourcerequirements and aditional others. This relationship may be reversed as a `superset-of`, since `A subset-of B` also means that `B superset-of A`.
- superset-of: The source requirements are a superset of target requirements. In other words, source contains all targetrequirements and aditional others. This relationship may be reversed as a `subset-of`, since `A superset-of B` also means that `B subset-of A`.
- intersects-with: The source and target requirements have some overlap, but each includes content that the other does not. This relationship may be reversed, since `A intersects-with B` also means that `B intersects-with A`. A mapping at statement level could result on relationships mapping that allows for more inference than using this relationship type.
- no-relationship: The source and target requirements are not related; their content does not overlap. This relation is introduced not with the intention to support exhaustiv mapping of all requirements and statements that have no overlap, but rather to support edge cases such is the need to tailor a relationship in the context of a component or system to better align with the implementation and configuration of the respective component or system. Also, this relationship is provided in support of the NIST IR 8477.
use name source
use name target
use name qualifier
use name prop
Remarks
Properties permit the deployment and management of arbitrary controlled values, within OSCAL objects. A property can be included for any purpose useful to an application or implementation. Typically, properties will be used to sort, filter, select, order, and arrange OSCAL content objects, to relate OSCAL objects to one another, or to associate an OSCAL object to class hierarchies, taxonomies, or external authorities. Thus, the lexical composition of properties may be constrained by external processes to ensure consistency.
Property allows for associated remarks that describe why the specific property value was applied to the containing object, or the significance of the value in the context of the containing object.
Remarks
To provide a cryptographic hash for a remote target resource, a local reference to
a back matter resource is needed. The resource allows one or more hash values to be provided using the rlink/hash object.
The OSCAL link is a roughly based on the HTML link element.
Remarks
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported
by OSCAL.
description A mapping between two target resources.
Attribute (1):
description A machine-oriented, globally unique identifier with cross-instance scope that can be used to reference this mapping definition elsewhere in this or
other OSCAL instances. The locally defined UUID of the mapping can be used to reference the data item locally or globally (e.g., in an imported
OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same mapping across revisions
of the document.
Elements (3):
use name source-resource
use name target-resource
description A collection of relationship-based control and/or control statement mappings.
root name mapping-collection
Remarks
A mapping collection affirmatively declares the relationships that exist between sets of controls and/or control statements in a source and target. It is expected that inferences can be made based on what is mapped; however, no inferences should be made based on what is not mapped, since it is impossible to quantify how complete or granular a given mapping is.
Attribute (1):
description A globally unique identifier with cross-instance scope for this catalog instance. This UUID should be changed when this document is revised.
Elements (6):
Remarks
All OSCAL documents use the same metadata structure, that provides a consistent way of expressing OSCAL document metadata across all OSCAL models. The metadata section also includes declarations of individual objects (i.e., roles, location, parties) that may be referenced within and across linked OSCAL documents.
The metadata in an OSCAL document has few required fields, representing only the bare minimum data needed to differentiate one instance from another. Tools and users creating OSCAL documents may choose to use any of the optional fields, as well as extension mechanisms (e.g., properties, links) to go beyond this minimum to suit their use cases.
A publisher of OSCAL content can use the published, last-modified, and version fields to establish information about an individual in a sequence of successive revisions
of a given OSCAL-based publication. The metadata for a previous revision can be represented
as a revision within this object. Links may also be provided using the predecessor-version and successor-version link relations to provide for direct access to the related resource. These relations
can be provided as a link child of this object or as link within a given revision.
A responsible-party entry in this context refers to roles and parties that have responsibility relative
to the production, review, publication, and use of the containing document.
use name provenance
use name source-gap-summary
use name target-gap-summary
Remarks
Provides a collection of identified resource objects that can be referenced by a link with a rel value of "reference" and an href value that is a fragment "#" followed by a reference to a reference's uuid. Other specialized link "rel" values also use this pattern when indicated in that
context of use.
Back matter including references and resources.
description A specific edge within a source or target that is the subject of a mapping.
Attributes (2):
description The semantic type of the subject.
Constraint (1)
allowed values
The value must be one of the following:
- control: A control as defined by OSCAL.
- statement: A textual element of a control that defines part of the control's requirements.
description A reference to an identified subject that is of the specified type .
Elements (3):
use name prop
Remarks
Properties permit the deployment and management of arbitrary controlled values, within OSCAL objects. A property can be included for any purpose useful to an application or implementation. Typically, properties will be used to sort, filter, select, order, and arrange OSCAL content objects, to relate OSCAL objects to one another, or to associate an OSCAL object to class hierarchies, taxonomies, or external authorities. Thus, the lexical composition of properties may be constrained by external processes to ensure consistency.
Property allows for associated remarks that describe why the specific property value was applied to the containing object, or the significance of the value in the context of the containing object.
Remarks
To provide a cryptographic hash for a remote target resource, a local reference to
a back matter resource is needed. The resource allows one or more hash values to be provided using the rlink/hash object.
The OSCAL link is a roughly based on the HTML link element.
Remarks
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported
by OSCAL.
description Describes requirements, incompatibilities and gaps that are identified between a target and source in a mapping item.
Attributes (3):
Elements (4):
description Description of the context and intended use of the mapping set.
Remarks
A responsible-party requires one or more party-uuid references creating a strong relationship arc between the referenced role-id and the reference parties. This differs in semantics from responsible-role which doesn't require that a party-uuid is referenced.
The scope of use of this object determines if the responsibility has been performed or will be performed in the future. The containing object will describe the intent.
Remarks
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported
by OSCAL.
description A reference to a resource that is either the source or the target of a mapping.
Attributes (2):
description The semantic type of the resource.
Constraint (1)
allowed values
The value must be one of the following:
- catalog: The mapped resource is a control catalog.
- profile: The mapped resource is a control profile. A resolved profile is also accepted.
description A resolvable URL reference to the base catalog or profile that this profile is tailoring.
Remarks
This value may be one of:
- an absolute URI that points to a network resolvable resource,
- a relative reference pointing to a network resolvable resource whose base URI is the URI of the containing document, or
- a bare URI fragment (i.e., `#uuid`) pointing to a
back-matterresource in this or an imported document (see linking to another OSCAL object).
Elements (3):
use name prop
Remarks
Properties permit the deployment and management of arbitrary controlled values, within OSCAL objects. A property can be included for any purpose useful to an application or implementation. Typically, properties will be used to sort, filter, select, order, and arrange OSCAL content objects, to relate OSCAL objects to one another, or to associate an OSCAL object to class hierarchies, taxonomies, or external authorities. Thus, the lexical composition of properties may be constrained by external processes to ensure consistency.
Property allows for associated remarks that describe why the specific property value was applied to the containing object, or the significance of the value in the context of the containing object.
Remarks
To provide a cryptographic hash for a remote target resource, a local reference to
a back matter resource is needed. The resource allows one or more hash values to be provided using the rlink/hash object.
The OSCAL link is a roughly based on the HTML link element.
Remarks
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported
by OSCAL.
description Selecting a set of controls by matching their IDs with a wildcard pattern.
Attribute (1):
description The method used for relating controls within the mapping. The supported methods are aligned with the NIST Interagency Report (IR) 8477, Section 4.3 Set Theory Relationship Mapping.
Constraint (1)
allowed values
The value must be one of the following:
- syntactic: Syntactic: How similar is the wording that expresses the two concepts. This is a word-for-word analysis of the relationship, not an interpretation of the language.
- semantic: Semantic: How similar are the meanings of the two concepts? This involves some interpretation of each concept’s language.
- functional: Functional: How similar are the results of executing the two concepts? This involves understanding what will happen if the two concepts are implemented, performed, or otherwise executed.
description A label that indicates the nature of a resource, as a data serialization or format.
Remarks
The Internet Assigned Numbers Authority (IANA) Media Types Registry defines a standardized set of media types, which may be used here.
The application/oscal+xml, application/oscal+json or application/oscal+yaml media types SHOULD be used when referencing OSCAL XML, JSON, or YAML resources respectively.
**Note: There is no official media type for YAML at this time.** OSCAL documents should
specify application/yaml for general YAML content, or application/oscal+yaml for YAML-based OSCAL content. This approach aligns with use of a structured name
suffix, per RFC 6838 Section 4.2.8.
Some earlier OSCAL content incorporated the model into the media type. For example:
application/oscal.catalog+xml. This practice SHOULD be avoided, since the OSCAL model can be detected by parsing
the initial content of the referenced resource.
description Provides information about the containing document, and defines concepts that are shared across the document.
Remarks
All OSCAL documents use the same metadata structure, that provides a consistent way of expressing OSCAL document metadata across all OSCAL models. The metadata section also includes declarations of individual objects (i.e., roles, location, parties) that may be referenced within and across linked OSCAL documents.
The metadata in an OSCAL document has few required fields, representing only the bare minimum data needed to differentiate one instance from another. Tools and users creating OSCAL documents may choose to use any of the optional fields, as well as extension mechanisms (e.g., properties, links) to go beyond this minimum to suit their use cases.
A publisher of OSCAL content can use the published, last-modified, and version fields to establish information about an individual in a sequence of successive revisions
of a given OSCAL-based publication. The metadata for a previous revision can be represented
as a revision within this object. Links may also be provided using the predecessor-version and successor-version link relations to provide for direct access to the related resource. These relations
can be provided as a link child of this object or as link within a given revision.
A responsible-party entry in this context refers to roles and parties that have responsibility relative
to the production, review, publication, and use of the containing document.
Constraints (14)
index for role an index index-metadata-role-ids shall list values returned by targets role using keys constructed of key field(s) @id
is unique for document-id: any target value must be unique (i.e., occur only once)
is unique for prop: any target value must be unique (i.e., occur only once)
index for .//prop an index index-metadata-property-uuid shall list values returned by targets .//prop using keys constructed of key field(s) @uuid
is unique for link: any target value must be unique (i.e., occur only once)
index for role an index index-metadata-role-id shall list values returned by targets role using keys constructed of key field(s) @id
index for location an index index-metadata-location-uuid shall list values returned by targets location using keys constructed of key field(s) @uuid
index for party an index index-metadata-party-uuid shall list values returned by targets party using keys constructed of key field(s) @uuid
index for party[@type='organization'] an index index-metadata-party-organizations-uuid shall list values returned by targets party[@type='organization'] using keys constructed of key field(s) @uuid
is unique for responsible-party: any target value must be unique (i.e., occur only once)
allowed values for responsible-party/@role-id
The value may be locally defined, or one of the following:
- creator: Indicates the person or organization that created this content.
- prepared-by: Indicates the person or organization that prepared this content.
- prepared-for: Indicates the person or organization for which this content was created.
- content-approver: Indicates the person or organization responsible for all content represented in the "document".
- contact: Indicates the person or organization to contact for questions or support related to this content.
allowed value for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
The value must be one of the following:
- keywords: The value identifies a comma-seperated listing of keywords associated with this content. These keywords may be used as search terms for indexing and other applications.
allowed values for link/@rel
The value may be locally defined, or one of the following:
- canonical: The link identifies the authoritative location for this resource. Defined by RFC 6596.
- alternate: The link identifies an alternative location or format for this resource. Defined by the HTML Living Standard
- latest-version: This link identifies a resource containing the latest version in the version history. Defined by RFC 5829.
- predecessor-version: This link identifies a resource containing the predecessor version in the version history. Defined by RFC 5829.
- successor-version: This link identifies a resource containing the predecessor version in the version history. Defined by RFC 5829.
is unique for document-id: any target value must be unique (i.e., occur only once)
Elements (15):
description A name given to the document, which may be used by a tool for display and navigation.
Remarks
Typically, this date value will be machine-generated at the time the containing document is published.
In some cases, an OSCAL document may be derived from some source material provided
in a different format. In such a case, the published value should indicate when the OSCAL document instance was last published, not the
source material.
Remarks
This value represents the point in time when the OSCAL document was last updated, or at the point of creation the creation date. Typically, this date value will be machine generated at time of creation or modification. Ideally, this field will be managed by the editing tool or service used to make modifications when storing the modified document.
The intent of the last modified timestamp is to distinguish between significant change milestones when the document may be accessed by multiple entities. This allows a given entity to differentiate between mutiple document states at specific points in time. It is possible to make multiple modifications to the document without storing these changes. In such a case, the last modified timestamp might not be updated until the document is finally stored.
In some cases, an OSCAL document may be derived from some source material in a different
format. In such a case, the last-modified value should indicate the last modification time of the OSCAL document instance,
not the source material.
Remarks
A version may be a release number, sequence number, date, or other identifier sufficient to distinguish between different document revisions.
While not required, it is recommended that OSCAL content authors use Semantic Versioning as the version format. This allows for the easy identification of a version tree consisting of major, minor, and patch numbers.
A version is typically set by the document owner or by the tool used to maintain the content.
Remarks
Indicates the version of the OSCAL model to which the document conforms, for example
1.1.0
or 1.0.0-milestone1
. That can be used as a hint for a tool indicating which version of the OSCAL XML
or JSON schema to use for validation.
The OSCAL version serves a different purpose from the document version and is used to represent a different concept. If both have the same value, this is coincidental.
description An entry in a sequential list of revisions to the containing document, expected to be in reverse chronological order (i.e. latest first).
wrapper element revisions
Remarks
While published, last-modified, and oscal-version are not required, values for these entries should be provided if the information
is known. A link with a rel of source
should be provided if the information is known.
Constraint (1)
allowed values for link/@rel
The value may be locally defined, or one of the following:
- canonical: The link identifies the authoritative location for this resource. Defined by RFC 6596.
- alternate: The link identifies an alternative location or format for this resource. Defined by the HTML Living Standard
- predecessor-version: This link identifies a resource containing the predecessor version in the version history. Defined by RFC 5829.
- successor-version: This link identifies a resource containing the predecessor version in the version history. Defined by RFC 5829.
- version-history: This link identifies a resource containing the version history of this document. Defined by RFC 5829.
Elements (8):
description A name given to the document revision, which may be used by a tool for display and navigation.
Remarks
Typically, this date value will be machine-generated at the time the containing document is published.
In some cases, an OSCAL document may be derived from some source material provided
in a different format. In such a case, the published value should indicate when the OSCAL document instance was last published, not the
source material.
Remarks
This value represents the point in time when the OSCAL document was last updated, or at the point of creation the creation date. Typically, this date value will be machine generated at time of creation or modification. Ideally, this field will be managed by the editing tool or service used to make modifications when storing the modified document.
The intent of the last modified timestamp is to distinguish between significant change milestones when the document may be accessed by multiple entities. This allows a given entity to differentiate between mutiple document states at specific points in time. It is possible to make multiple modifications to the document without storing these changes. In such a case, the last modified timestamp might not be updated until the document is finally stored.
In some cases, an OSCAL document may be derived from some source material in a different
format. In such a case, the last-modified value should indicate the last modification time of the OSCAL document instance,
not the source material.
Remarks
A version may be a release number, sequence number, date, or other identifier sufficient to distinguish between different document revisions.
While not required, it is recommended that OSCAL content authors use Semantic Versioning as the version format. This allows for the easy identification of a version tree consisting of major, minor, and patch numbers.
A version is typically set by the document owner or by the tool used to maintain the content.
Remarks
Indicates the version of the OSCAL model to which the document conforms, for example
1.1.0
or 1.0.0-milestone1
. That can be used as a hint for a tool indicating which version of the OSCAL XML
or JSON schema to use for validation.
The OSCAL version serves a different purpose from the document version and is used to represent a different concept. If both have the same value, this is coincidental.
use name prop
Remarks
Properties permit the deployment and management of arbitrary controlled values, within OSCAL objects. A property can be included for any purpose useful to an application or implementation. Typically, properties will be used to sort, filter, select, order, and arrange OSCAL content objects, to relate OSCAL objects to one another, or to associate an OSCAL object to class hierarchies, taxonomies, or external authorities. Thus, the lexical composition of properties may be constrained by external processes to ensure consistency.
Property allows for associated remarks that describe why the specific property value was applied to the containing object, or the significance of the value in the context of the containing object.
Remarks
To provide a cryptographic hash for a remote target resource, a local reference to
a back matter resource is needed. The resource allows one or more hash values to be provided using the rlink/hash object.
The OSCAL link is a roughly based on the HTML link element.
Remarks
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported
by OSCAL.
Remarks
A document identifier provides a globally unique identifier with a cross-instance scope that is used for a group of documents that are to be treated as different versions, representations or digital surrogates of the same document.
A document identifier provides an additional data point for identifying a document that can be assigned by a publisher or organization for purposes in a wider system, such as a digital object identifier (DOI) or a local content management system identifier.
Use of a document identifier allows for document creators to associate sets of documents
that are related in some way by the same document-id.
An OSCAL document always has an implicit document identifier provided by the document's
UUID, defined by the uuid on the top-level object. Having a default UUID-based identifier ensures all documents
can be minimally identified when other document identifiers are not provided.
use name prop
Remarks
Properties permit the deployment and management of arbitrary controlled values, within OSCAL objects. A property can be included for any purpose useful to an application or implementation. Typically, properties will be used to sort, filter, select, order, and arrange OSCAL content objects, to relate OSCAL objects to one another, or to associate an OSCAL object to class hierarchies, taxonomies, or external authorities. Thus, the lexical composition of properties may be constrained by external processes to ensure consistency.
Property allows for associated remarks that describe why the specific property value was applied to the containing object, or the significance of the value in the context of the containing object.
Remarks
To provide a cryptographic hash for a remote target resource, a local reference to
a back matter resource is needed. The resource allows one or more hash values to be provided using the rlink/hash object.
The OSCAL link is a roughly based on the HTML link element.
description Defines a function, which might be assigned to a party in a specific situation.
Remarks
Permissible values to be determined closer to the application (e.g. by a receiving authority).
OSCAL has defined a set of standardized roles for consistent use in OSCAL documents. This allows tools consuming OSCAL content to infer specific semantics when these roles are used. These roles are documented in the specific contexts of their use (e.g., responsible-party, responsible-role). When using such a role, it is necessary to define these roles in this list, which will then allow such a role to be referenced.
Attribute (1):
description A unique identifier for the role.
Elements (6):
description A name given to the role, which may be used by a tool for display and navigation.
description A short common name, abbreviation, or acronym for the role.
description A summary of the role's purpose and associated responsibilities.
use name prop
Remarks
Properties permit the deployment and management of arbitrary controlled values, within OSCAL objects. A property can be included for any purpose useful to an application or implementation. Typically, properties will be used to sort, filter, select, order, and arrange OSCAL content objects, to relate OSCAL objects to one another, or to associate an OSCAL object to class hierarchies, taxonomies, or external authorities. Thus, the lexical composition of properties may be constrained by external processes to ensure consistency.
Property allows for associated remarks that describe why the specific property value was applied to the containing object, or the significance of the value in the context of the containing object.
Remarks
To provide a cryptographic hash for a remote target resource, a local reference to
a back matter resource is needed. The resource allows one or more hash values to be provided using the rlink/hash object.
The OSCAL link is a roughly based on the HTML link element.
Remarks
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported
by OSCAL.
description A physical point of presence, which may be associated with people, organizations, or other concepts within the current or linked OSCAL document.
Remarks
An address might be sensitive in nature. In such cases a title, mailing address, email-address, and/or phone number may be used instead.
Constraints (5)
allowed value for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
The value must be one of the following:
- type: Characterizes the kind of location.
allowed value for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='type']/@value
The value must be one of the following:
- data-center: A location that contains computing assets. A class can be used to indicate the sub-type of data-center as primary or alternate.
allowed values for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='type' and @value='data-center']/@class
The value must be one of the following:
- primary: The location is a data-center used for normal operations.
- alternate: The location is a data-center used for fail-over or backup operations.
has cardinality for address the cardinality of address is constrained: 1; maximum unbounded.
has cardinality for title|address|email-address|telephone-number the cardinality of title|address|email-address|telephone-number is constrained: 1; maximum unbounded.
Attribute (1):
description A unique ID for the location, for reference.
Elements (8):
description A name given to the location, which may be used by a tool for display and navigation.
Remarks
The physical address of the location, which will provided for physical locations. Virtual locations can omit this data item.
Remarks
A contact email associated with the location.
Remarks
A phone number used to contact the location.
deprecated as of 1.1.0
description The uniform resource locator (URL) for a web site or other resource associated with the location.
Remarks
This data field is deprecated in favor of using a link with an appropriate relationship.
use name prop
Remarks
Properties permit the deployment and management of arbitrary controlled values, within OSCAL objects. A property can be included for any purpose useful to an application or implementation. Typically, properties will be used to sort, filter, select, order, and arrange OSCAL content objects, to relate OSCAL objects to one another, or to associate an OSCAL object to class hierarchies, taxonomies, or external authorities. Thus, the lexical composition of properties may be constrained by external processes to ensure consistency.
Property allows for associated remarks that describe why the specific property value was applied to the containing object, or the significance of the value in the context of the containing object.
Remarks
To provide a cryptographic hash for a remote target resource, a local reference to
a back matter resource is needed. The resource allows one or more hash values to be provided using the rlink/hash object.
The OSCAL link is a roughly based on the HTML link element.
Remarks
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported
by OSCAL.
description An organization or person, which may be associated with roles or other concepts within the current or linked OSCAL document.
Remarks
A party can be optionally associated with either an address or a location. While providing a meaningful location for a party is desired, there are some cases where it might not be possible to provide an exact location or even any location.
Constraint (1)
allowed values for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
The value must be one of the following:
- mail-stop: A mail stop associated with the party.
- office: The name or number of the party's office.
- job-title: The formal job title of a person.
Attributes (2):
description A unique identifier for the party.
description A category describing the kind of party the object describes.
Constraint (1)
allowed values
The value must be one of the following:
- person: A human being regarded as an individual.
- organization: An organized group of one or more person individuals with a specific purpose.
Elements (10):
description The full name of the party. This is typically the legal name associated with the party.
description A short common name, abbreviation, or acronym for the party.
description An identifier for a person or organization using a designated scheme. e.g. an Open Researcher and Contributor ID (ORCID).
Attribute (1):
description Indicates the type of external identifier.
Remarks
This value must be an absolute URI that serves as a naming system identifier.
Constraint (1)
allowed value
The value may be locally defined, or the following:
- http://orcid.org/: The identifier is Open Researcher and Contributor ID (ORCID).
use name prop
Remarks
Properties permit the deployment and management of arbitrary controlled values, within OSCAL objects. A property can be included for any purpose useful to an application or implementation. Typically, properties will be used to sort, filter, select, order, and arrange OSCAL content objects, to relate OSCAL objects to one another, or to associate an OSCAL object to class hierarchies, taxonomies, or external authorities. Thus, the lexical composition of properties may be constrained by external processes to ensure consistency.
Property allows for associated remarks that describe why the specific property value was applied to the containing object, or the significance of the value in the context of the containing object.
Remarks
To provide a cryptographic hash for a remote target resource, a local reference to
a back matter resource is needed. The resource allows one or more hash values to be provided using the rlink/hash object.
The OSCAL link is a roughly based on the HTML link element.
Remarks
This is a contact email associated with the party.
Remarks
A phone number used to contact the party.
description A reference to another party by UUID, typically an organization, that this subject is associated with.
Remarks
Since the reference target of an organizational affiliation must be another party (whether further qualified as person or organization) as inidcated by its uuid. As a machine-oriented identifier with uniqueness across document and trans-document scope, this uuid value is sufficient to reference the data item locally or globally across related
documents, e.g., in an imported OSCAL instance.
Parties of both the person or organization type can be associated with an organization using the member-of-organization.
Constraint (1)
index has keythis value must correspond to a listing in the index index-metadata-party-organizations-uuid using a key constructed of key field(s) .
Remarks
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported
by OSCAL.
Remarks
A responsible-party requires one or more party-uuid references creating a strong relationship arc between the referenced role-id and the reference parties. This differs in semantics from responsible-role which doesn't require that a party-uuid is referenced.
The scope of use of this object determines if the responsibility has been performed or will be performed in the future. The containing object will describe the intent.
Remarks
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported
by OSCAL.
description The method used to complete the overall mapping.
Constraint (1)
allowed values
The value must be one of the following:
- human: Human
- automation: Automation
description The OSCAL model version the document was authored against and will conform to as valid.
Remarks
Indicates the version of the OSCAL model to which the document conforms, for example
1.1.0
or 1.0.0-milestone1
. That can be used as a hint for a tool indicating which version of the OSCAL XML
or JSON schema to use for validation.
The OSCAL version serves a different purpose from the document version and is used to represent a different concept. If both have the same value, this is coincidental.
description Reference to a party by UUID.
Constraint (1)
index has keythis value must correspond to a listing in the index index-metadata-party-uuid using a key constructed of key field(s) .
description A glob expression matching the IDs of one or more controls to be selected.
description An attribute, characteristic, or quality of the containing object expressed as a namespace qualified name/value pair.
use name prop
Remarks
Properties permit the deployment and management of arbitrary controlled values, within OSCAL objects. A property can be included for any purpose useful to an application or implementation. Typically, properties will be used to sort, filter, select, order, and arrange OSCAL content objects, to relate OSCAL objects to one another, or to associate an OSCAL object to class hierarchies, taxonomies, or external authorities. Thus, the lexical composition of properties may be constrained by external processes to ensure consistency.
Property allows for associated remarks that describe why the specific property value was applied to the containing object, or the significance of the value in the context of the containing object.
Constraint (1)
allowed value for .[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
The value must be one of the following:
- marking: A label or descriptor that is tied to a sensitivity or classification marking system. An optional class can be used to define the specific marking system used for the associated value.
Attributes (6):
description A textual label, within a namespace, that identifies a specific attribute, characteristic, or quality of the property's containing object.
description A unique identifier for a property.
description A namespace qualifying the property's name. This allows different organizations to associate distinct semantics with the same name.
Remarks
This value must be an absolute URI that serves as a naming system identifier.
When a ns is not provided, its value should be assumed to be http://csrc.nist.gov/ns/oscal and the name should be a name defined by the associated OSCAL model.
description Indicates the value of the attribute, characteristic, or quality.
description A textual label that provides a sub-type or characterization of the property's name.
Remarks
This can be used to further distinguish or discriminate between the semantics of multiple
properties of the same object with the same name and ns, or to group properties into categories.
A class can be used in validation rules to express extra constraints over named items of
a specific class value. It is available for grouping, but unlike group is not expected specifically to designate any group membership as such.
description An identifier for relating distinct sets of properties.
Remarks
Different sets of properties may relate to separate contexts. Declare a group on a property to associate it with one or more other properties in a given context.
Elements (1):
Remarks
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported
by OSCAL.
description The date and time the document was last made available.
Remarks
Typically, this date value will be machine-generated at the time the containing document is published.
In some cases, an OSCAL document may be derived from some source material provided
in a different format. In such a case, the published value should indicate when the OSCAL document instance was last published, not the
source material.
description Describes requirements, incompatibilities and gaps that are identified between a target and source in a mapping item.
Attributes (3):
description The focus of the qualifier.
Constraint (1)
allowed values
The value must be one of the following:
- source: This qualifier is related to the source in the mapped relationship.
- target: This qualifier is related to the target in the mapped relationship.
- both: This qualifier is related to both the source and target in the mapped relationship.
description The predicate describes how the qualifer applies to the subject.
Constraint (1)
allowed values
The value must be one of the following:
- has-requirement: The subject has a requirement that must be met for the relationship to be satisfied.
- has-incompatibility: The subject has an incompatibility which impacts the relationship.
description The category expresses the resolvable nature of the predicate.
Constraint (1)
allowed values
The value must be one of the following:
- restricted: A restriction exists, and is defined in the description.
- addressable: The qualifier is addressable, and is outlined in the description.
- blocked: The mapping is blocked due to the reason noted in the description.
Elements (2):
description Details that outline what requirements must be met, or cannot be met. If the qualifier identifies a gap, this should idenfity the gap, and any incompatibilities.
Remarks
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported
by OSCAL.
description Additional commentary about the containing object.
Remarks
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported
by OSCAL.
description A reference to a set of persons and/or organizations that have responsibility for performing the referenced role in the context of the containing object.
Remarks
A responsible-party requires one or more party-uuid references creating a strong relationship arc between the referenced role-id and the reference parties. This differs in semantics from responsible-role which doesn't require that a party-uuid is referenced.
The scope of use of this object determines if the responsibility has been performed or will be performed in the future. The containing object will describe the intent.
Constraint (1)
index has keythis value must correspond to a listing in the index index-metadata-role-id using a key constructed of key field(s) @role-id
Attribute (1):
description A reference to a role performed by a party.
Elements (4):
description Specifies one or more parties responsible for performing the associated role.
use name prop
Remarks
Properties permit the deployment and management of arbitrary controlled values, within OSCAL objects. A property can be included for any purpose useful to an application or implementation. Typically, properties will be used to sort, filter, select, order, and arrange OSCAL content objects, to relate OSCAL objects to one another, or to associate an OSCAL object to class hierarchies, taxonomies, or external authorities. Thus, the lexical composition of properties may be constrained by external processes to ensure consistency.
Property allows for associated remarks that describe why the specific property value was applied to the containing object, or the significance of the value in the context of the containing object.
Remarks
To provide a cryptographic hash for a remote target resource, a local reference to
a back matter resource is needed. The resource allows one or more hash values to be provided using the rlink/hash object.
The OSCAL link is a roughly based on the HTML link element.
Remarks
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported
by OSCAL.
description A reference to a role with responsibility for performing a function relative to the containing object, optionally associated with a set of persons and/or organizations that perform that role.
Remarks
A responsible-role allows zero or more party-uuid references, each of which creates a relationship arc between the referenced role-id and the referenced party. This differs in semantics from responsible-party, which requires that at least one party-uuid is referenced.
The scope of use of this object determines if the responsibility has been performed or will be performed in the future. The containing object will describe the intent.
Attribute (1):
description A human-oriented identifier reference to a role performed.
Elements (4):
use name prop
Remarks
Properties permit the deployment and management of arbitrary controlled values, within OSCAL objects. A property can be included for any purpose useful to an application or implementation. Typically, properties will be used to sort, filter, select, order, and arrange OSCAL content objects, to relate OSCAL objects to one another, or to associate an OSCAL object to class hierarchies, taxonomies, or external authorities. Thus, the lexical composition of properties may be constrained by external processes to ensure consistency.
Property allows for associated remarks that describe why the specific property value was applied to the containing object, or the significance of the value in the context of the containing object.
Remarks
To provide a cryptographic hash for a remote target resource, a local reference to
a back matter resource is needed. The resource allows one or more hash values to be provided using the rlink/hash object.
The OSCAL link is a roughly based on the HTML link element.
description Specifies zero or more parties responsible for performing the associated role.
Remarks
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported
by OSCAL.
description Reference to a role by UUID.
Constraint (1)
index has keythis value must correspond to a listing in the index index-metadata-role-id using a key constructed of key field(s) .
description Select a control or controls from an imported control set.
Remarks
If with-child-controls is yes
on the call to a control, no sibling callelements need to be used to call any controls appearing within it. Since generally,
this is how control enhancements are represented (as controls within controls), this
provides a way to include controls with all their dependent controls (enhancements)
without having to call them individually.
Attribute (1):
Elements (2):
description Selecting a control by its ID given as a literal.
description The focus of the qualifier.
Constraint (1)
allowed values
The value must be one of the following:
- complete: Complete
- not-complete: Not Complete
- draft: Draft
- deprecated: Deprecated
- superseded: Superseded
description A telephone service number as defined by ITU-T E.164.
Constraint (1)
matches: a target (value) must match the regular expression '^[0-9]{3}[0-9]{1,12}$'.
Attribute (1):
description Indicates the type of phone number.
Constraint (1)
allowed values
The value may be locally defined, or one of the following:
- home: A home phone number.
- office: An office phone number.
- mobile: A mobile phone number.
description Used to distinguish a specific revision of an OSCAL document from other previous and future versions.
Remarks
A version may be a release number, sequence number, date, or other identifier sufficient to distinguish between different document revisions.
While not required, it is recommended that OSCAL content authors use Semantic Versioning as the version format. This allows for the easy identification of a version tree consisting of major, minor, and patch numbers.
A version is typically set by the document owner or by the tool used to maintain the content.
description When a control is included, whether its child (dependent) controls are also included.
Constraint (1)
allowed values
The value must be one of the following:
- yes: Include child controls with an included control.
- no: When importing a control, only include child controls that are also explicitly called.