Architectural Overview

Project Architecture

General Project Architectural Decisions

• Architectural Decisions were recorded
• Release and versioning strategy - Releases are published via Github Releases and versioned with "Spock versioning."
• Team permissions management - Project followed GSA TTS Recommendations for GitHub team organization
• Usage metrics data collection - Collection of usage metrics is performed by the Digital Analytics Program, and previously, Google Forms.

Code-Specific Architectural Decisions

• XML and Schematron - XML was originally chosen as the basis for validations due to the usage of XML technologies in OSCAL. This was continued throughout the project, which allowed easier integration with the NIST toolchain.
• XSLT Library - The choice of Schematron for validation required the usage of an XSLT processor. Several processors were evaluated, with the Saxon suite chosen as the only viable XSLT 3.0 option.
• XSLT integration within Schematron - To augment the limited functionality of Schematron, XSLT is directly utilized.
• Shell-based validation pipeline - The decision was made to initially focus on shell-based XSLT pipelines. Subsequently, examples for validating documents in several programming languages were created.
• XProc pipelining was investigated - Ultimately the level of effort required was deemed outside the scope of the project and likely to interfere with FedRAMP validation development.
• Client-side validation web interface - Initially intended for internal testing, as a proof-of-concept, and as a readable report to review validation results - the web interface evolved into a tool used by vendors, Cloud Service Providers (CSPs), and third-party assessment organizations (3PAO) for validation of OSCAL documents.
• Attachment Validation Approach - Due to the complexity of inputs and a considerable number of possible filetypes, attachment validation was primarily left to (as yet undefined) post-validation processes and, as is current practice, manual review by FedRAMP reviewers.
• Multi-document Validation Rules - A manner of writing cross-document rules was considered. Due to technical challenges, cross-document rules were not implemented. A proposal to define a FedRAMP submission package manifest file, described in this ADR, remains unresolved.
• Remote Resources - Some Schematron assertions require access to documents other than the one being validated. Since these may rely on the network to function, such use should be optional. The decision was made to utilize an XSLT parameter to enable remote resource validations.
• DNS Validation - Some validations require DNS queries to be performed from within Schematron. There are public DNS services which provide DNS over HTTPS (DoH) with responses in JSON format. The decision was made to use Google Public DNS via its JSON API for DNS over HTTPS (DoH).

Future Suggestions

• SchXSLT - Consider switching from the current Schematron implementation to SchXSLT. See https://github.com/18F/fedramp-automation/issues/529 for additional details.
• Implement XML schema validation - The web validation does not currently validate the XML schema, due to the lack of a suitable client-side option. A server-side validation, provided for instance via Saxon-EE, could be considered.