RFC: New OSCAL Model - Reference Taxonomy for Classification Schemes

[ivproduced]

OSCAL Reference Taxonomy Model Proposal

Date: February 13, 2026
Proposed By: euCann Development Team (IVProduced)
Target: Future OSCAL release (major or minor)
Current OSCAL Version: 1.2.0 (December 2025)

TL;DR

OSCAL lacks a standardized way to represent classification schemes like NIST SP 800-60 information types, MITRE ATT&CK techniques, and CWE weaknesses—forcing organizations to use workarounds that break interoperability. This proposal introduces a new Reference Taxonomy model that provides machine-readable representations of these classification systems, enabling consistent references across SSPs, assessment results, and component definitions without requiring schema changes to existing

Note on Examples: The code examples in this proposal use oscal-version: 1.2.0 to demonstrate compatibility with current OSCAL tooling and validators. This allows the metadata, properties, links, and other standard OSCAL elements to be validated against existing schemas. The reference-taxonomy model itself is proposed and does not yet exist in OSCAL 1.2.0—it would be added in a future OSCAL release.

Executive Summary

This proposal introduces a new OSCAL model type: Reference Taxonomy, designed to provide machine-readable representations of classification schemes, taxonomies, and reference data that are frequently cited in security and compliance documentation but do not fit the existing action-oriented OSCAL models (Catalog, Profile, SSP, Assessment, POA&M).

Demonstration Files

Complete, valid OSCAL-formatted example files accompany this proposal:

1. reference-taxonomy-sp800-60-example.xml - Complete SP 800-60 reference taxonomy in XML format (7 representative information types with full metadata, FIPS 199 impact levels, and classification dimensions)
   reference-taxonomy-sp800-60-example.xml

2. reference-taxonomy-sp800-60-example.json - Same content in JSON format, demonstrating format interoperability
   reference-taxonomy-sp800-60-example.json

3. reference-taxonomy-ssp-integration-example.xml - SSP example showing how to reference taxonomy items using existing OSCAL patterns (categorization, prop, back-matter resources)
   reference-taxonomy-ssp-integration-example.xml

These files follow OSCAL conventions for metadata, linking, parties, and back-matter. While the reference-taxonomy model is proposed and not yet part of the official OSCAL specification, these files demonstrate how it would integrate with existing OSCAL structures and tools.

Problem Statement

Current Gap in OSCAL

OSCAL currently provides excellent models for representing:

• Catalog - Control catalogs (what to implement)
• Profile - Control baselines (tailored control sets)
• Component Definition - Component-level control implementations
• System Security Plan (SSP) - System implementations (how controls are met)
• Assessment Plan (AP) - Assessment procedures
• Assessment Results (AR) - Assessment findings (how implementations are evaluated)
• POA&M - Remediation tracking (how to fix deficiencies)
• Control Mapping - Control relationships (new in OSCAL 1.2.0)

However, OSCAL lacks a standardized model for representing classification reference data that:

• Does not prescribe actions or controls
• Provides taxonomies for categorizing assets, data, threats, or risks
• Needs to be referenced consistently across multiple OSCAL documents
• Should be machine-readable for automated tooling

Current Workarounds and Limitations

Organizations currently resort to:

1. Forcing taxonomies into Catalog format

   • Semantically incorrect (classification items are not controls)
   • Loses specialized metadata (impact levels, categorization dimensions)
   • Example: Representing SP 800-60 information types as "controls"

2. Embedding in SSP system-information

   • Cannot be shared across systems
   • Not reusable as standalone reference
   • Awkward for data that isn't system-specific

3. Custom extensions or proprietary formats

   • Breaks interoperability
   • Requires custom tooling
   • No validation or standardization

4. External reference links only

   • Loses machine-readability
   • Cannot be validated or processed by OSCAL tools
   • No structured metadata

Use Cases

Priority Use Case: NIST SP 800-60 Information Types

Current Challenge: SP 800-60 Vol 2 Rev 1 defines 171 information types with FIPS 199 impact levels (Confidentiality, Integrity, Availability). Organizations must reference these when:

• Categorizing system data in SSPs
• Determining overall system impact levels
• Documenting data flows in system diagrams
• Mapping to FedRAMP requirements

Problem: No standard OSCAL way to represent this taxonomy

Example Information Type:

• ID: C.2.4.1
• Title: Budgeting
• Description: Activities related to budget formulation and planning
• Confidentiality Impact: Low
• Integrity Impact: Low
• Availability Impact: Low
• Rationale: Detailed justifications for each impact rating

Additional High-Value Use Cases

1. MITRE ATT&CK Framework

• What: 14 tactics, 193 techniques, 400+ sub-techniques
• Why: Threat modeling, incident response, security testing
• Current Problem: Organizations create custom mappings
• OSCAL Benefit: Standardized threat taxonomy referenceable in assessments

2. Common Weakness Enumeration (CWE)

• What: 900+ software/hardware weakness types
• Why: Vulnerability classification, secure development
• Current Problem: Referenced as plain text or URLs
• OSCAL Benefit: Machine-readable weakness taxonomy for POA&M items

3. CAPEC (Common Attack Pattern Enumeration)

• What: 500+ attack patterns with detailed metadata
• Why: Threat modeling, penetration testing, security architecture
• Current Problem: No structured reference in OSCAL
• OSCAL Benefit: Linkable attack patterns in assessment findings

4. Data Sensitivity Classifications

• What: Organization-specific or regulatory data classification schemes
• Examples: Public, Internal, Confidential, Restricted; GDPR categories; HIPAA PHI types
• Why: Data governance, access control, compliance mapping
• Current Problem: Inconsistent representation across organizations
• OSCAL Benefit: Standardized taxonomy format for custom classification schemes

5. Asset Criticality Tiers

• What: Critical, High, Medium, Low asset classifications
• Why: Risk assessment, prioritization, resource allocation
• Current Problem: Embedded in tool-specific formats
• OSCAL Benefit: Consistent asset classification across OSCAL documents

6. Compliance Jurisdiction Mapping

• What: Regulatory frameworks and their applicability scopes
• Examples: GDPR (EU residents), HIPAA (healthcare), PCI-DSS (payment data)
• Why: Multi-compliance environments, scope definition
• Current Problem: Manual documentation with risk of inconsistency
• OSCAL Benefit: Reusable jurisdiction taxonomy

Proposed Model Structure

Design Principle: Reuse OSCAL Common Patterns

This model deliberately reuses OSCAL's existing prop, part, and link assemblies rather than introducing custom structures. Classification metadata is expressed through typed properties, and rationale or narrative content uses part elements, consistent with how catalogs represent control metadata.

Core Element: <reference-taxonomy>

<?xml version="1.0" encoding="UTF-8"?>
<reference-taxonomy xmlns="http://csrc.nist.gov/ns/oscal/1.0" 
                    uuid="[uuid]">
  <metadata>
    <title>Taxonomy Title</title>
    <published>[datetime]</published>
    <last-modified>[datetime]</last-modified>
    <version>[version]</version>
    <oscal-version>1.2.0</oscal-version>
    
    <!-- Taxonomy-specific metadata -->
    <prop name="taxonomy-type" value="[type]"/>
    <prop name="source-document" value="[source]"/>
    <prop name="authority" value="[authority]"/>
    
    <link rel="source" href="[original-specification-url]"/>
    <link rel="related" href="[related-taxonomy-uuid]"/>
  </metadata>

  <!-- Optional hierarchical grouping -->
  <taxonomy-group id="[group-id]">
    <title>Group Title</title>
    <prop name="category" value="[category]"/>
    
    <!-- Taxonomy items -->
    <taxonomy-item id="[item-id]">
      <title>Item Title</title>
      <description>
        <p>Detailed description of the taxonomy item</p>
      </description>
      
      <!-- Classification values as props (reuses OSCAL prop pattern) -->
      <prop name="confidentiality" value="fips-199-low" class="impact-level"/>
      <prop name="integrity" value="fips-199-low" class="impact-level"/>
      <prop name="availability" value="fips-199-low" class="impact-level"/>
      
      <!-- Rationale as parts (reuses OSCAL part pattern) -->
      <part name="confidentiality-rationale">
        <p>Justification for the confidentiality impact level.</p>
      </part>
      <part name="integrity-rationale">
        <p>Justification for the integrity impact level.</p>
      </part>
      <part name="availability-rationale">
        <p>Justification for the availability impact level.</p>
      </part>
      
      <!-- Additional properties -->
      <prop name="[property-name]" value="[property-value]"/>
      
      <!-- Links to related items or external references -->
      <link rel="related" href="#[related-item-id]"/>
      <link rel="reference" href="[external-reference]"/>
      
      <!-- Additional structured content -->
      <part name="[part-name]" id="[part-id]">
        <p>Additional structured content</p>
      </part>
    </taxonomy-item>
    
    <!-- Nested groups for hierarchies -->
    <taxonomy-group id="[subgroup-id]">
      <title>Subgroup Title</title>
      <!-- More taxonomy-items -->
    </taxonomy-group>
  </taxonomy-group>
  
  <back-matter>
    <resource uuid="[resource-uuid]">
      <title>Source Document</title>
      <rlink href="[url]" media-type="application/pdf"/>
    </resource>
  </back-matter>
</reference-taxonomy>

JSON Structure

{
  "reference-taxonomy": {
    "uuid": "[uuid]",
    "metadata": {
      "title": "Taxonomy Title",
      "published": "[datetime]",
      "last-modified": "[datetime]",
      "version": "[version]",
      "oscal-version": "1.2.0",
      "props": [
        { "name": "taxonomy-type", "value": "[type]" },
        { "name": "source-document", "value": "[source]" },
        { "name": "authority", "value": "[authority]" }
      ],
      "links": [
        { "rel": "source", "href": "[original-specification-url]" }
      ]
    },
    "groups": [
      {
        "id": "[group-id]",
        "title": "Group Title",
        "taxonomy-items": [
          {
            "id": "[item-id]",
            "title": "Item Title",
            "description": "Detailed description",
            "props": [
              { "name": "confidentiality", "value": "fips-199-low", "class": "impact-level" },
              { "name": "integrity", "value": "fips-199-low", "class": "impact-level" },
              { "name": "availability", "value": "fips-199-low", "class": "impact-level" }
            ],
            "parts": [
              { "name": "confidentiality-rationale", "prose": "Justification text." },
              { "name": "integrity-rationale", "prose": "Justification text." },
              { "name": "availability-rationale", "prose": "Justification text." }
            ],
            "links": [
              { "rel": "reference", "href": "https://doi.org/10.6028/FIPS.199" }
            ]
          }
        ]
      }
    ],
    "back-matter": {
      "resources": [
        {
          "uuid": "[resource-uuid]",
          "title": "Source Document",
          "rlinks": [
            { "href": "[url]", "media-type": "application/pdf" }
          ]
        }
      ]
    }
  }
}

Concrete Example: SP 800-60 Information Type

XML Example

<?xml version="1.0" encoding="UTF-8"?>
<reference-taxonomy xmlns="http://csrc.nist.gov/ns/oscal/1.0" 
                    uuid="98af4f8d-2cd4-4de7-a176-32e4f2e0e0f1">
  <metadata>
    <title>NIST SP 800-60 Volume II Revision 1 Information Types</title>
    <published>2008-08-01T00:00:00Z</published>
    <last-modified>2026-02-12T00:00:00Z</last-modified>
    <version>Revision 1</version>
    <oscal-version>1.2.0</oscal-version>
    
    <prop name="taxonomy-type" value="information-classification"/>
    <prop name="source-document" value="NIST.SP.800-60v2r1"/>
    <prop name="authority" value="NIST"/>
    
    <link rel="source" href="https://doi.org/10.6028/NIST.SP.800-60v2r1"/>
    <link rel="canonical" href="https://csrc.nist.gov/publications/detail/sp/800-60/vol-2-rev-1/final"/>
    <link rel="related" href="https://doi.org/10.6028/FIPS.199"/>
    
    <role id="authoritative-source">
      <title>Original Document Authority</title>
    </role>
    
    <party uuid="8238c306-4ee0-4321-a4fb-503adda3d8c1" type="organization">
      <name>National Institute of Standards and Technology</name>
      <short-name>NIST</short-name>
      <link rel="website" href="https://www.nist.gov"/>
    </party>
    
    <responsible-party role-id="authoritative-source">
      <party-uuid>8238c306-4ee0-4321-a4fb-503adda3d8c1</party-uuid>
    </responsible-party>
  </metadata>

  <taxonomy-group id="C.2-management-of-government-resources">
    <title>C.2 Management of Government Resources</title>
    <prop name="category" value="mission-area"/>
    
    <taxonomy-group id="C.2.1-controls-and-oversight">
      <title>C.2.1 Controls and Oversight</title>
      <prop name="subcategory" value="function"/>
      
      <taxonomy-item id="C.2.1.1">
        <title>Corrective Action</title>
        <description>
          <p>Corrective Action involves the enforcement functions necessary to remedy 
          programs that have been found non-compliant with a given law, regulation, 
          or policy.</p>
        </description>
        
        <prop name="confidentiality" value="fips-199-low" class="impact-level"/>
        <prop name="integrity" value="fips-199-low" class="impact-level"/>
        <prop name="availability" value="fips-199-low" class="impact-level"/>
        <prop name="categorization-system" 
              value="http://doi.org/10.6028/NIST.SP.800-60v2r1"/>
        
        <part name="confidentiality-rationale">
          <p>The confidentiality impact level is the effect of unauthorized 
          disclosure of corrective action information on the ability of responsible 
          agencies to remedy internal or external programs that have been found 
          non-compliant with a given law, regulation, or policy. Unauthorized 
          disclosure of most corrective action information should have only a 
          limited adverse effect on agency operations, assets, or individuals.</p>
        </part>
        
        <part name="integrity-rationale">
          <p>The consequences of undetected unauthorized modification or destruction 
          of corrective action information can conceivably compromise the 
          effectiveness of compliance enforcement actions. Unauthorized modification 
          or destruction of most corrective action information should have only a 
          limited adverse effect on agency operations, assets, or individuals.</p>
        </part>
        
        <part name="availability-rationale">
          <p>The availability impact level is based on the specific mission and 
          the data supporting that mission. In most cases, disruption of access 
          to corrective action information can be expected to have only a limited 
          adverse effect on agency operations, agency assets, or individuals.</p>
        </part>
        
        <link rel="reference" href="https://doi.org/10.6028/FIPS.199">
          <text>FIPS 199 Impact Levels</text>
        </link>
      </taxonomy-item>
      
      <taxonomy-item id="C.2.1.2">
        <title>Program Evaluation</title>
        <description>
          <p>Program Evaluation involves the analysis of internal and external program 
          effectiveness and the determination of corrective actions as appropriate.</p>
        </description>
        
        <prop name="confidentiality" value="fips-199-low" class="impact-level"/>
        <prop name="integrity" value="fips-199-low" class="impact-level"/>
        <prop name="availability" value="fips-199-low" class="impact-level"/>
        <prop name="categorization-system" 
              value="http://doi.org/10.6028/NIST.SP.800-60v2r1"/>
        
        <part name="confidentiality-rationale">
          <p>The confidentiality impact level is the effect of unauthorized disclosure 
          of program evaluation information. Once the evaluation has been reported, 
          most program evaluation information is in the public domain. However, 
          premature unauthorized disclosure can alert personnel associated with 
          programs under evaluation.</p>
          <p>Special Factors: Where major programs or human safety is at stake, the 
          confidentiality impact may be high.</p>
        </part>
        
        <part name="integrity-rationale">
          <p>The consequences of undetected unauthorized modification or destruction 
          of program evaluation information can compromise the effectiveness of an 
          evaluation program.</p>
        </part>
        
        <part name="availability-rationale">
          <p>Most program evaluation processes are tolerant of reasonable delays. 
          In most cases, disruption of access can be expected to have only a limited 
          adverse effect.</p>
        </part>
      </taxonomy-item>
      
      <!-- Additional taxonomy-items... -->
    </taxonomy-group>
    
    <taxonomy-group id="C.2.4-fiscal-management">
      <title>C.2.4 Fiscal Management</title>
      
      <taxonomy-item id="C.2.4.1">
        <title>Budgeting</title>
        <description>
          <p>Budgeting involves activities related to the formulation, justification, 
          and execution of budgets.</p>
        </description>
        
        <prop name="confidentiality" value="fips-199-low" class="impact-level"/>
        <prop name="integrity" value="fips-199-low" class="impact-level"/>
        <prop name="availability" value="fips-199-low" class="impact-level"/>
        <prop name="categorization-system" 
              value="http://doi.org/10.6028/NIST.SP.800-60v2r1"/>
        
        <part name="confidentiality-rationale">
          <p>Unauthorized disclosure of budgeting information can provide a limited 
          competitive advantage but generally has limited adverse effects.</p>
        </part>
        
        <part name="integrity-rationale">
          <p>Unauthorized modification of budgeting information may compromise 
          financial planning but typically has limited adverse effects.</p>
        </part>
        
        <part name="availability-rationale">
          <p>Most budgeting processes are tolerant of delays. Disruption typically 
          has limited adverse effects.</p>
        </part>
      </taxonomy-item>
    </taxonomy-group>
  </taxonomy-group>
  
  <back-matter>
    <resource uuid="f5b38e5f-0e4d-4c57-8d7a-1b2c3d4e5f6a">
      <title>NIST SP 800-60 Volume II Revision 1</title>
      <rlink href="https://doi.org/10.6028/NIST.SP.800-60v2r1" media-type="application/pdf"/>
    </resource>
    <resource uuid="a1b2c3d4-e5f6-4890-abcd-ef1234567890">
      <title>FIPS Publication 199</title>
      <rlink href="https://doi.org/10.6028/FIPS.199" media-type="application/pdf"/>
    </resource>
  </back-matter>
</reference-taxonomy>

JSON Example

{
  "reference-taxonomy": {
    "uuid": "98af4f8d-2cd4-4de7-a176-32e4f2e0e0f1",
    "metadata": {
      "title": "NIST SP 800-60 Volume II Revision 1 Information Types",
      "published": "2008-08-01T00:00:00Z",
      "last-modified": "2026-02-12T00:00:00Z",
      "version": "Revision 1",
      "oscal-version": "1.2.0",
      "props": [
        { "name": "taxonomy-type", "value": "information-classification" },
        { "name": "source-document", "value": "NIST.SP.800-60v2r1" },
        { "name": "authority", "value": "NIST" }
      ],
      "links": [
        { "rel": "source", "href": "https://doi.org/10.6028/NIST.SP.800-60v2r1" },
        { "rel": "canonical", "href": "https://csrc.nist.gov/publications/detail/sp/800-60/vol-2-rev-1/final" },
        { "rel": "related", "href": "https://doi.org/10.6028/FIPS.199" }
      ],
      "roles": [
        { "id": "authoritative-source", "title": "Original Document Authority" }
      ],
      "parties": [
        {
          "uuid": "8238c306-4ee0-4321-a4fb-503adda3d8c1",
          "type": "organization",
          "name": "National Institute of Standards and Technology",
          "short-name": "NIST",
          "links": [
            { "rel": "website", "href": "https://www.nist.gov" }
          ]
        }
      ],
      "responsible-parties": [
        {
          "role-id": "authoritative-source",
          "party-uuids": ["8238c306-4ee0-4321-a4fb-503adda3d8c1"]
        }
      ]
    },
    "groups": [
      {
        "id": "C.2-management-of-government-resources",
        "title": "C.2 Management of Government Resources",
        "props": [
          { "name": "category", "value": "mission-area" }
        ],
        "groups": [
          {
            "id": "C.2.1-controls-and-oversight",
            "title": "C.2.1 Controls and Oversight",
            "props": [
              { "name": "subcategory", "value": "function" }
            ],
            "taxonomy-items": [
              {
                "id": "C.2.1.1",
                "title": "Corrective Action",
                "description": "Corrective Action involves the enforcement functions necessary to remedy programs that have been found non-compliant with a given law, regulation, or policy.",
                "props": [
                  { "name": "confidentiality", "value": "fips-199-low", "class": "impact-level" },
                  { "name": "integrity", "value": "fips-199-low", "class": "impact-level" },
                  { "name": "availability", "value": "fips-199-low", "class": "impact-level" },
                  { "name": "categorization-system", "value": "http://doi.org/10.6028/NIST.SP.800-60v2r1" }
                ],
                "parts": [
                  {
                    "name": "confidentiality-rationale",
                    "prose": "The confidentiality impact level is the effect of unauthorized disclosure of corrective action information on the ability of responsible agencies to remedy internal or external programs that have been found non-compliant. Unauthorized disclosure of most corrective action information should have only a limited adverse effect on agency operations, assets, or individuals."
                  },
                  {
                    "name": "integrity-rationale",
                    "prose": "The consequences of undetected unauthorized modification or destruction of corrective action information can conceivably compromise the effectiveness of compliance enforcement actions. Unauthorized modification or destruction of most corrective action information should have only a limited adverse effect."
                  },
                  {
                    "name": "availability-rationale",
                    "prose": "The availability impact level is based on the specific mission and the data supporting that mission. In most cases, disruption of access to corrective action information can be expected to have only a limited adverse effect."
                  }
                ],
                "links": [
                  { "rel": "reference", "href": "https://doi.org/10.6028/FIPS.199", "text": "FIPS 199 Impact Levels" }
                ]
              }
            ]
          }
        ]
      }
    ],
    "back-matter": {
      "resources": [
        {
          "uuid": "f5b38e5f-0e4d-4c57-8d7a-1b2c3d4e5f6a",
          "title": "NIST SP 800-60 Volume II Revision 1",
          "rlinks": [
            { "href": "https://doi.org/10.6028/NIST.SP.800-60v2r1", "media-type": "application/pdf" }
          ]
        },
        {
          "uuid": "a1b2c3d4-e5f6-4890-abcd-ef1234567890",
          "title": "FIPS Publication 199",
          "rlinks": [
            { "href": "https://doi.org/10.6028/FIPS.199", "media-type": "application/pdf" }
          ]
        }
      ]
    }
  }
}

Note: Complete, working examples of these formats are provided as demonstration files:

• reference-taxonomy-sp800-60-example.xml - Full XML format with 7 representative information types
• reference-taxonomy-sp800-60-example.json - Same content in JSON format
• reference-taxonomy-ssp-integration-example.xml - SSP showing taxonomy integration

These files follow proper OSCAL conventions for metadata, UUIDs, links, parties, and back-matter references.

Referencing Taxonomies in Other OSCAL Models

The reference-taxonomy is designed to be consumed by existing OSCAL models using existing linking patterns already available in OSCAL—primarily link, prop, and back-matter resources. No schema changes to existing models are required for basic integration.

In SSP (System Security Plan)

SSP already supports information-type with categorization referencing SP 800-60. The taxonomy provides the machine-readable source:

Note: The following integration snippets show only the relevant elements. Required structural elements (metadata, etc.) are omitted for brevity. Complete, validating examples are provided in the attached demonstration files.

<!-- Partial snippet: shows information-type integration pattern only -->
<system-security-plan>
  <system-characteristics>
    <system-information>
      <information-type uuid="a1b2c3d4-5678-40ab-8def-1234567890ab">
        <title>Budget Management System Data</title>
        <description>
          <p>This system processes budgeting information as defined in SP 800-60.</p>
        </description>
        
        <!-- Existing OSCAL categorization pattern -->
        <categorization system="http://doi.org/10.6028/NIST.SP.800-60v2r1">
          <information-type-id>C.2.4.1</information-type-id>
        </categorization>
        
        <!-- Link to the reference-taxonomy for machine-readable detail -->
        <prop name="taxonomy-source"
              value="98af4f8d-2cd4-4de7-a176-32e4f2e0e0f1"
              class="reference-taxonomy"/>
        
        <!-- Override base impact levels with justification -->
        <confidentiality-impact>
          <base>fips-199-moderate</base>
          <selected>fips-199-moderate</selected>
          <adjustment-justification>
            <p>Elevated from base SP 800-60 level due to strategic budget data.</p>
          </adjustment-justification>
        </confidentiality-impact>
        <integrity-impact>
          <base>fips-199-low</base>
        </integrity-impact>
        <availability-impact>
          <base>fips-199-low</base>
        </availability-impact>
      </information-type>
    </system-information>
  </system-characteristics>
  
  <back-matter>
    <!-- Reference-taxonomy as a resolvable resource -->
    <resource uuid="d4e5f6a7-8901-4345-bcde-f67890123456">
      <title>NIST SP 800-60 Vol 2 Rev 1 Reference Taxonomy</title>
      <prop name="type" value="reference-taxonomy"/>
      <rlink href="nist-sp800-60-taxonomy.xml" 
             media-type="application/xml"/>
    </resource>
  </back-matter>
</system-security-plan>

Key design decisions:

• Uses existing categorization element (no schema change to SSP)
• Links to taxonomy via prop with class="reference-taxonomy" and back-matter resource
• The back-matter resource pattern is how OSCAL already references external documents (see import-profile and leveraged-authorization patterns)
• Impact levels use existing confidentiality-impact/integrity-impact/availability-impact assemblies with base, selected, and adjustment-justification

In Assessment Results

Findings can reference taxonomy items using existing prop and link patterns. In the observation or finding assemblies:

<!-- Partial snippet: shows finding-level taxonomy integration only -->
<assessment-results>
  <!-- metadata omitted for brevity -->
  <result uuid="...">
    <finding uuid="...">
      <title>SQL Injection Vulnerability</title>
      <description>
        <p>SQL Injection vulnerability identified in login form.</p>
      </description>
      
      <!-- Reference CWE via prop (existing pattern) -->
      <prop name="cwe-id" value="CWE-89" 
            ns="https://cwe.mitre.org"
            class="weakness-taxonomy"/>
      
      <!-- Reference CAPEC via prop -->
      <prop name="capec-id" value="CAPEC-66" 
            ns="https://capec.mitre.org"
            class="attack-pattern"/>
      
      <!-- Link to machine-readable taxonomy for lookup -->
      <link rel="reference" href="#b7c4e9d2-8a3f-4e1b-9c5d-6f7e8a9b0c1d">
        <text>CWE-89: SQL Injection</text>
      </link>
      
      <!-- Existing target/subject-reference structure -->
      <target type="objective-id" target-id="ra-5.a">
        <status>not-satisfied</status>
      </target>
    </finding>
  </result>
  
  <!-- back-matter is a child of assessment-results, not result -->
  <back-matter>
    <resource uuid="b7c4e9d2-8a3f-4e1b-9c5d-6f7e8a9b0c1d">
      <title>CWE Reference Taxonomy</title>
      <prop name="type" value="reference-taxonomy"/>
      <rlink href="cwe-taxonomy.xml" media-type="application/xml"/>
    </resource>
  </back-matter>
</assessment-results>

Key design decisions:

• Uses existing prop with ns attribute for namespace-qualified identifiers
• Uses existing link with rel="reference" pattern
• Taxonomy document resolved via back-matter resource at the assessment-results root level (per OSCAL AR schema)
• No changes to the assessment-results schema required

In Component Definition

<!-- Partial snippet: shows component-level taxonomy integration only -->
<component-definition>
  <!-- metadata omitted for brevity -->
  <component uuid="..." type="software">
    <title>Web Application Firewall</title>
    
    <!-- Reference threat coverage using props -->
    <prop name="mitigates" value="T1190" 
          ns="https://attack.mitre.org"
          class="threat-taxonomy"/>
    <prop name="mitigates" value="T1059" 
          ns="https://attack.mitre.org"
          class="threat-taxonomy"/>
    
    <!-- Link to reference-taxonomy for full detail -->
    <link rel="reference" href="#c8d5f0e3-9b4a-4f2c-ad6e-7a8f9b0c1d2e">
      <text>MITRE ATT&amp;CK Coverage</text>
    </link>
  </component>
  
  <back-matter>
    <resource uuid="c8d5f0e3-9b4a-4f2c-ad6e-7a8f9b0c1d2e">
      <title>MITRE ATT&amp;CK Reference Taxonomy</title>
      <prop name="type" value="reference-taxonomy"/>
      <rlink href="attck-taxonomy.xml" media-type="application/xml"/>
    </resource>
  </back-matter>
</component-definition>

Key design decisions:

• Multiple prop entries with ns allow referencing multiple taxonomy items
• Same back-matter resource pattern for taxonomy resolution
• No changes to the component-definition schema required

Implementation Considerations

Schema Changes Required

1. New metaschema module: oscal_reference-taxonomy_metaschema.xml

   • Imports: oscal_metadata_metaschema.xml, oscal_control-common_metaschema.xml
   • Defines: reference-taxonomy (root), taxonomy-item assembly
   • Reuses: metadata, back-matter, taxonomy-group (recursive, analogous to catalog group), prop, link, part

2. No changes required to existing OSCAL models:

   • SSP integration uses existing categorization, prop, link, and back-matter patterns
   • AR/CD integration uses existing prop (with ns and class), link, and back-matter
   • The reference-taxonomy is consumed as an external resource, not embedded

3. Generated artifacts:

   • XML Schema (XSD)
   • JSON Schema
   • YAML support
   • Schematron validation rules

Validation Requirements

• Taxonomy-item ID uniqueness: Each taxonomy-item/@id must be unique within the taxonomy (enforced via <is-unique> constraint)
• Allowed impact values: Constrained via <allowed-values> for known value sets (e.g., fips-199-low, fips-199-moderate, fips-199-high)
• Link integrity: back-matter resource references validated via <index-has-key> (existing OSCAL pattern)
• Circular reference prevention: <index> constraints on link[@rel='related'] ensure referenced items exist within the same taxonomy; cross-taxonomy links use back-matter resources which are resolved externally and do not create circular dependencies within the document

Versioning and Taxonomy Evolution

A critical concern for long-lived documents:

Problem: An SSP references SP 800-60 Rev 1, item C.2.4.1 (Low/Low/Low). If SP 800-60 Rev 2 changes it to (Moderate/Low/Low), what happens to the SSP reference?

Solution: This is handled using patterns already established in OSCAL:

1. Version pinning: Each reference-taxonomy has a version field in metadata. SSPs reference a specific taxonomy by UUID (which is version-specific, per OSCAL identifier guidance)
2. New versions = new UUIDs: When SP 800-60 Rev 2 is published as a reference-taxonomy, it gets a new UUID. Existing SSP references to the Rev 1 UUID remain valid
3. Migration via link: The new taxonomy can include a <link rel="predecessor-version"/> pointing to a back-matter resource that contains an rlink to the previous version's document. This avoids misuse of # fragment identifiers (which resolve within the same document) and is consistent with how OSCAL references external documents
4. Override documentation: SSPs already support adjustment-justification on impact levels, which documents any deviation from base taxonomy values regardless of version

Concrete predecessor-version example — the new taxonomy references its predecessor via back-matter, not via # (which would imply an intra-document fragment):

<!-- In SP 800-60 Rev 2 taxonomy (new UUID) -->
<reference-taxonomy uuid="NEW-REV2-UUID" xmlns="http://csrc.nist.gov/ns/oscal/1.0">
  <metadata>
    <title>SP 800-60 Volume II Rev 2</title>
    <!-- ... -->
    <!-- Link to predecessor via back-matter resource -->
    <link rel="predecessor-version" href="#d9e6a1f4-0c5b-4a3d-8e7f-8b9c0d1e2f3a"/>
  </metadata>
  <!-- taxonomy-groups and taxonomy-items ... -->
  <back-matter>
    <resource uuid="d9e6a1f4-0c5b-4a3d-8e7f-8b9c0d1e2f3a">
      <title>SP 800-60 Volume II Rev 1</title>
      <prop name="type" value="reference-taxonomy"/>
      <rlink href="./sp800-60-rev1-taxonomy.xml" media-type="application/xml"/>
    </resource>
  </back-matter>
</reference-taxonomy>

Here, href="#d9e6a1f4-0c5b-4a3d-8e7f-8b9c0d1e2f3a" correctly uses a # fragment to reference a resource defined in the same document's back-matter. That resource's rlink then resolves to the external predecessor document. This is a standard OSCAL pattern.

This mirrors how OSCAL handles profile-to-catalog version relationships today.

Backward Compatibility

• No breaking changes: New model, existing models unchanged
• Optional references: Existing OSCAL documents don't need taxonomy references
• Migration path: Organizations can gradually adopt taxonomy references

Tooling Impact

OSCAL Java Library

• New ReferenceTaxonomy class
• TaxonomyReference binding classes
• Validation extensions

OSCAL Python Tools

• Add reference_taxonomy.py model
• Update validation framework
• CLI support for taxonomy operations

OSCAL CLI

• oscal-cli taxonomy validate
• oscal-cli taxonomy convert
• oscal-cli taxonomy merge

Benefits and Impact

For OSCAL Adopters

1. Consistency: Standardized way to reference classification schemes
2. Interoperability: Share taxonomies across organizations and tools
3. Automation: Machine-readable taxonomies enable automated categorization
4. Validation: Tools can validate references to authoritative taxonomies
5. Traceability: Clear lineage from source documents to OSCAL representations

For Tool Vendors

1. Feature enhancement: Built-in taxonomy support without proprietary extensions
2. Integration: Standard format for importing external classification schemes
3. Validation: Leverage OSCAL validation tools for taxonomy references
4. Marketplace: Ecosystem for sharing/selling taxonomy datasets

For the OSCAL Community

1. Completeness: Fills a significant gap in OSCAL coverage
2. Growth: Opens OSCAL to new use cases beyond security controls
3. Adoption: Removes barrier for organizations with taxonomy-heavy workflows
4. Standards alignment: Better integration with MITRE, CWE, CVE, etc.

Proposed Taxonomy Types (Non-Exhaustive)

Type	Example	Properties (via prop class)
information-classification	SP 800-60	confidentiality, integrity, availability
threat-taxonomy	MITRE ATT&CK	tactic, technique, platform
weakness-taxonomy	CWE	weakness-type, severity, likelihood
attack-pattern	CAPEC	attack-type, prerequisites, consequences
data-sensitivity	Custom schemes	sensitivity-level, handling-requirements
asset-criticality	Tiering models	criticality-tier, recovery-priority
compliance-scope	Regulatory frameworks	jurisdiction, applicability, requirements
risk-factors	SP 800-30	threat-source, vulnerability, impact

Alternative Approaches Considered

Option 1: Extend Catalog Model

Rejected because:

• Semantically incorrect (taxonomy items are not controls)
• Loses classification-specific metadata
• Confuses control-based vs. reference-based content

Option 2: Extend SSP Information Types

Rejected because:

• Limited to SSP context only
• Not reusable across OSCAL models
• Designed for system-specific, not reference, data

Option 3: Use Back-Matter References Only

Rejected because:

• Lacks structure and validation
• Not machine-processable
• No standardization across organizations

Option 4: External Non-OSCAL Format

Rejected because:

• Breaks OSCAL ecosystem integration
• Requires custom tools outside OSCAL toolchain
• No validation or interoperability guarantees

Open Questions for Community Discussion

1. Naming: Is reference-taxonomy the best term? Alternatives:

   • classification-scheme
   • taxonomy-catalog
   • reference-library

2. Property flexibility: Should impact-level and classification properties be free-form or constrained to known vocabularies via allowed-values?

3. Subset/profile: Should there be a "taxonomy profile" to select subsets of large taxonomies?

4. Mappings: Should the model support built-in cross-taxonomy mappings (e.g., CWE→CAPEC), or should the existing Control Mapping model (new in OSCAL 1.2.0) be used for this purpose?

5. Localization: How should multi-language taxonomies be represented?

6. Extensions: Should organizations be able to extend authoritative taxonomies with custom taxonomy-items while preserving the original?

Implementation Roadmap

Phase 1: Specification (3 months)

• Finalize metaschema definition
• Community review and feedback
• Define validation constraints
• Publish draft specification

Phase 2: Core Implementation (6 months)

• Update OSCAL metaschema
• Generate schemas (XSD, JSON Schema)
• Update OSCAL Java library
• Update OSCAL Python tools
• CLI support

Phase 3: Reference Taxonomies (6 months)

• Convert SP 800-60 to new model
• Convert MITRE ATT&CK framework
• Convert CWE top 25
• Convert CAPEC patterns
• Publish reference implementations

Phase 4: Documentation & Adoption (3 months)

• Tutorial documentation
• Migration guides
• Tool vendor outreach
• Community training

References

OSCAL Resources

• OSCAL Website
• OSCAL GitHub Repository
• OSCAL Metaschema

Source Taxonomies

• NIST SP 800-60
• MITRE ATT&CK
• Common Weakness Enumeration (CWE)
• Common Attack Pattern Enumeration (CAPEC)
• FIPS 199

Related Standards

• ISO/IEC 27005:2022 (Risk Management)
• ISO/IEC 27002:2022 (Information Security Controls)
• NIST Risk Management Framework (SP 800-37)

Conclusion

The Reference Taxonomy model addresses a critical gap in OSCAL's coverage by providing a standardized, machine-readable format for classification schemes and reference data. This enhancement will:

• Expand OSCAL's applicability to broader security and compliance use cases
• Enable automation of categorization and risk assessment processes
• Improve interoperability between organizations and tools
• Strengthen the OSCAL ecosystem by supporting integration with existing standards

We believe this proposal aligns with OSCAL's goals of standardization, automation, and interoperability, and we look forward to community feedback and collaboration on refining this model.

---

Contact Information

Submitting Organization: euCann Development Team
Primary Contact: Tevin Harris
GitHub: IVProduced
Discussion Forum: OSCAL Discussion Board

Appendix A: Complete SP 800-60 XML Sample

See attached file: reference-taxonomy-sp800-60-example.xml

Appendix B: MITRE ATT&CK Taxonomy Sample

<?xml version="1.0" encoding="UTF-8"?>
<reference-taxonomy xmlns="http://csrc.nist.gov/ns/oscal/1.0" 
                    uuid="f8e9c7d5-3a2b-4e1f-9d8c-7b6a5e4f3d2c">
  <metadata>
    <title>MITRE ATT&CK Framework v14.1</title>
    <published>2024-10-29T00:00:00Z</published>
    <last-modified>2026-02-12T00:00:00Z</last-modified>
    <version>14.1</version>
    <oscal-version>1.2.0</oscal-version>
    
    <prop name="taxonomy-type" value="threat-taxonomy"/>
    <prop name="source-document" value="MITRE ATT&CK"/>
    <prop name="authority" value="MITRE Corporation"/>
    
    <link rel="source" href="https://attack.mitre.org/"/>
  </metadata>

  <taxonomy-group id="TA0001">
    <title>Initial Access</title>
    <prop name="tactic" value="initial-access"/>
    
    <taxonomy-item id="T1190">
      <title>Exploit Public-Facing Application</title>
      <description>
        <p>Adversaries may attempt to take advantage of a weakness in an Internet-facing 
        computer or program using software, data, or commands in order to cause unintended 
        or unanticipated behavior.</p>
      </description>
      
      <prop name="tactic" value="initial-access" class="attck-tactic"/>
      <prop name="tactic" value="execution" class="attck-tactic"/>
      <prop name="platform" value="Linux" class="attck-platform"/>
      <prop name="platform" value="Windows" class="attck-platform"/>
      <prop name="platform" value="macOS" class="attck-platform"/>
      <prop name="platform" value="Network" class="attck-platform"/>
      <prop name="platform" value="Containers" class="attck-platform"/>
      <prop name="data-source" value="Application Log" class="attck-data-source"/>
      <prop name="data-source" value="Network Traffic" class="attck-data-source"/>
      <prop name="sub-techniques" value="none"/>
      
      <link rel="canonical" href="https://attack.mitre.org/techniques/T1190/"/>
      <link rel="related" href="#T1133"/>
      <link rel="related" href="#T1210"/>
      
      <part name="detection" id="T1190_detection">
        <p>Monitor application logs for abnormal behavior and error messages. 
        Use network intrusion detection systems for exploit attempts.</p>
      </part>
      
      <part name="mitigation" id="T1190_mitigation">
        <p>Regularly update and patch applications. Implement web application 
        firewalls and input validation.</p>
      </part>
    </taxonomy-item>
    
    <taxonomy-item id="T1133">
      <title>External Remote Services</title>
      <description>
        <p>Adversaries may leverage external-facing remote services to gain initial 
        access to systems in a network.</p>
      </description>
      
      <prop name="tactic" value="initial-access" class="attck-tactic"/>
      <prop name="tactic" value="persistence" class="attck-tactic"/>
      <prop name="platform" value="Linux" class="attck-platform"/>
      <prop name="platform" value="Windows" class="attck-platform"/>
      <prop name="platform" value="macOS" class="attck-platform"/>
      
      <link rel="canonical" href="https://attack.mitre.org/techniques/T1133/"/>
    </taxonomy-item>
  </taxonomy-group>
  
  <taxonomy-group id="TA0008">
    <title>Lateral Movement</title>
    <prop name="tactic" value="lateral-movement"/>
    
    <taxonomy-item id="T1210">
      <title>Exploitation of Remote Services</title>
      <description>
        <p>Adversaries may exploit remote services to gain unauthorized access 
        to internal systems once inside of a network.</p>
      </description>
      
      <prop name="tactic" value="lateral-movement" class="attck-tactic"/>
      <prop name="platform" value="Linux" class="attck-platform"/>
      <prop name="platform" value="Windows" class="attck-platform"/>
      <prop name="platform" value="macOS" class="attck-platform"/>
      
      <link rel="canonical" href="https://attack.mitre.org/techniques/T1210/"/>
      <link rel="related" href="#T1190"/>
    </taxonomy-item>
  </taxonomy-group>
</reference-taxonomy>

Appendix C: Metaschema Definition Draft

<?xml version="1.0" encoding="UTF-8"?>
<METASCHEMA xmlns="http://csrc.nist.gov/ns/oscal/metaschema/1.0">
  <schema-name>OSCAL Reference Taxonomy Model</schema-name>
  <schema-version>1.3.0</schema-version>
  <short-name>oscal-reference-taxonomy</short-name>
  <remarks>
    <p>This metaschema defines the Reference Taxonomy model proposed for 
    addition to OSCAL. The schema-version represents a hypothetical future 
    OSCAL version that would include this model.</p>
    <p>This module reuses metadata, back-matter, property, link, and part 
    assemblies from existing OSCAL shared modules. No custom classification 
    or dimension assemblies are introduced—taxonomy metadata is expressed 
    using the existing prop and part patterns.</p>
  </remarks>
  <namespace>http://csrc.nist.gov/ns/oscal/1.0</namespace>
  <json-base-uri>http://csrc.nist.gov/ns/oscal</json-base-uri>

  <!-- Import shared OSCAL modules (same pattern as catalog/SSP metaschemas) -->
  <import href="oscal_metadata_metaschema.xml"/>
  <import href="oscal_control-common_metaschema.xml"/>

  <define-assembly name="reference-taxonomy">
    <formal-name>Reference Taxonomy</formal-name>
    <description>A structured taxonomy or classification scheme for 
    reference purposes. Provides machine-readable representations of 
    classification data (e.g., SP 800-60 information types, MITRE ATT&amp;CK 
    techniques) that can be referenced by other OSCAL documents.</description>
    <root-name>reference-taxonomy</root-name>
    
    <define-flag name="uuid" as-type="uuid" required="yes">
      <formal-name>Taxonomy Universally Unique Identifier</formal-name>
      <description>Provides a globally unique means to identify this 
      taxonomy instance. A new UUID should be generated for each new 
      version of the taxonomy.</description>
    </define-flag>
    
    <model>
      <assembly ref="metadata" min-occurs="1" max-occurs="1"/>
      <assembly ref="taxonomy-group" min-occurs="0" max-occurs="unbounded">
        <group-as name="groups" in-json="ARRAY"/>
      </assembly>
      <assembly ref="taxonomy-item" min-occurs="0" max-occurs="unbounded">
        <group-as name="taxonomy-items" in-json="ARRAY"/>
      </assembly>
      <assembly ref="back-matter" min-occurs="0" max-occurs="1"/>
    </model>
    
    <constraint>
      <is-unique id="unique-taxonomy-item-id" target=".//taxonomy-item">
        <formal-name>Unique Taxonomy Item ID</formal-name>
        <description>Ensures every taxonomy-item/@id is unique within 
        the taxonomy.</description>
        <key-field target="@id"/>
      </is-unique>
      
      <is-unique id="unique-taxonomy-group-id" target=".//taxonomy-group">
        <formal-name>Unique Taxonomy Group ID</formal-name>
        <description>Ensures every taxonomy-group/@id is unique within 
        the taxonomy.</description>
        <key-field target="@id"/>
      </is-unique>
      
      <index id="index-taxonomy-item-by-id" name="taxonomy-items-by-id" 
             target=".//taxonomy-item">
        <formal-name>Index of Taxonomy Items by ID</formal-name>
        <description>Indexes all taxonomy-item elements by their @id, 
        enabling validation that intra-document link references 
        (e.g., link[@rel='related']) resolve to defined items.</description>
        <key-field target="@id"/>
      </index>
      
      <index-has-key id="validate-related-links" name="taxonomy-items-by-id"
                     target=".//link[@rel='related']">
        <formal-name>Validate Related Links</formal-name>
        <description>Ensures that every link with rel='related' whose 
        href starts with '#' resolves to a taxonomy-item defined in 
        this taxonomy. Applies to both taxonomy-item and taxonomy-group 
        related links.</description>
        <key-field target="@href" pattern="#(.+)"/>
      </index-has-key>
      
      <allowed-values id="allowed-impact-level-values" 
                      target=".//taxonomy-item/prop[@class='impact-level']/@value"
                      allow-other="yes">
        <formal-name>FIPS 199 Impact Level Values</formal-name>
        <description>Constrains recognized impact level values to 
        FIPS 199 categories. The allow-other='yes' attribute permits 
        taxonomy-specific extensions.</description>
        <enum value="fips-199-low">Low impact (FIPS 199)</enum>
        <enum value="fips-199-moderate">Moderate impact (FIPS 199)</enum>
        <enum value="fips-199-high">High impact (FIPS 199)</enum>
      </allowed-values>
      
      <index id="index-back-matter-resources" name="back-matter-resource-index"
             target="back-matter/resource">
        <formal-name>Index of Back-Matter Resources</formal-name>
        <description>Indexes all back-matter resources by their @uuid, 
        enabling validation that fragment identifier references resolve 
        to defined resources.</description>
        <key-field target="@uuid"/>
      </index>
      
      <index-has-key id="validate-back-matter-refs" name="back-matter-resource-index"
                     target=".//link[starts-with(@href, '#') and not(@rel='related')]">
        <formal-name>Validate Back-Matter Resource References</formal-name>
        <description>Ensures that fragment identifier references in 
        link/@href (excluding rel='related' which reference taxonomy-items) 
        resolve to a resource defined in this document's back-matter.</description>
        <key-field target="@href" pattern="#(.+)"/>
      </index-has-key>
    </constraint>
  </define-assembly>

  <define-assembly name="taxonomy-group">
    <formal-name>Taxonomy Group</formal-name>
    <description>A hierarchical grouping of taxonomy items, analogous 
    to the group assembly in the catalog model.</description>
    
    <define-flag name="id" as-type="token" required="yes">
      <formal-name>Group Identifier</formal-name>
      <description>Unique identifier for this group within the 
      taxonomy.</description>
    </define-flag>
    
    <model>
      <field ref="title" min-occurs="1" max-occurs="1"/>
      <assembly ref="prop" min-occurs="0" max-occurs="unbounded">
        <group-as name="props" in-json="ARRAY"/>
      </assembly>
      <assembly ref="link" min-occurs="0" max-occurs="unbounded">
        <group-as name="links" in-json="ARRAY"/>
      </assembly>
      <assembly ref="taxonomy-item" min-occurs="0" max-occurs="unbounded">
        <group-as name="taxonomy-items" in-json="ARRAY"/>
      </assembly>
      <assembly ref="taxonomy-group" min-occurs="0" max-occurs="unbounded">
        <group-as name="groups" in-json="ARRAY"/>
      </assembly>
      <field ref="remarks" in-xml="WITH_WRAPPER"/>
    </model>
  </define-assembly>

  <define-assembly name="taxonomy-item">
    <formal-name>Taxonomy Item</formal-name>
    <description>An individual item within a taxonomy. Classification 
    metadata (impact levels, threat categories, etc.) is expressed using 
    prop elements. Rationale text is expressed using part elements. This 
    follows the same extensibility pattern used by control in the catalog 
    model.</description>
    
    <define-flag name="id" as-type="token" required="yes">
      <formal-name>Taxonomy Item Identifier</formal-name>
      <description>Unique identifier for this taxonomy item (e.g., 
      'C.2.4.1' for SP 800-60 or 'T1190' for ATT&amp;CK). This is the 
      identifier used by other OSCAL documents to reference this 
      item.</description>
    </define-flag>
    
    <model>
      <field ref="title" min-occurs="1" max-occurs="1"/>
      <field ref="description" in-xml="WITH_WRAPPER"/>
      <assembly ref="prop" min-occurs="0" max-occurs="unbounded">
        <group-as name="props" in-json="ARRAY"/>
      </assembly>
      <assembly ref="link" min-occurs="0" max-occurs="unbounded">
        <group-as name="links" in-json="ARRAY"/>
      </assembly>
      <assembly ref="part" min-occurs="0" max-occurs="unbounded">
        <group-as name="parts" in-json="ARRAY"/>
      </assembly>
      <field ref="remarks" in-xml="WITH_WRAPPER"/>
    </model>
  </define-assembly>
</METASCHEMA>

Design notes on the metaschema:

• <import> statements follow the same pattern used in oscal_catalog_metaschema.xml and oscal_ssp_metaschema.xml. This gives taxonomy-item access to prop, link, part, metadata, and back-matter without redefining them.
• No classification or classification-dimension assemblies are defined. Classification metadata is expressed via prop elements with name, value, and class attributes—the same mechanism OSCAL uses throughout its existing models.
• No taxonomy-reference assembly is defined. Other OSCAL models reference taxonomy items using existing prop (with ns/class), link (with rel="reference"), and back-matter resource patterns. No schema changes to existing models are required.
• taxonomy-group mirrors the recursive group pattern from the catalog model, supporting nested hierarchies. The element name is <taxonomy-group> (not <group>) to avoid collision with the catalog model's group assembly; in JSON, it serializes as the "groups" key per its group-as attribute.
• Constraints ensure structural integrity: <is-unique> enforces uniqueness of both taxonomy-item/@id and taxonomy-group/@id. An <index> on taxonomy-item IDs enables <index-has-key> validation that link[@rel='related'] fragment references resolve to defined items. A separate index on back-matter/resource validates other # hrefs (excluding rel='related' to prevent conflict). <allowed-values> constrains recognized FIPS 199 impact levels while allow-other="yes" permits taxonomy-specific extensions.

[iMichaela]

@ivproduced - Thank you for your submission. I hope the community will provide their perspective. Our NIST team will also carefully review the proposal and will promote the RFC to engage the community's members.