-
Notifications
You must be signed in to change notification settings - Fork 8
Architectural Overview
Core architectural decisions are recorded in the Github repository as "Architectural Decision Records" (ADRs).
Releases are published via Github Releases and versioned with "Spock versioning."
Project followed GSA TTS Recommendations for GitHub team organization
Collection of usage metrics is performed by the Digital Analytics Program, and previously, Google Forms.
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.
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.
To augment the limited functionality of Schematron, XSLT is directly utilized.
The decision was made to initially focus on shell-based XSLT pipelines. Subsequently, examples for validating documents in several programming languages were created.
Ultimately the level of effort required was deemed outside the scope of the project and likely to interfere with FedRAMP validation development.
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.
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.
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.
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.
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).
Consider switching from the current Schematron implementation to SchXSLT.
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.
The current guide documents are difficult to maintain and update due to being PDF-based. A web-based guide would enable hyperlinks between pages, as well as enable a collaborative git-based workflow. A git-based workflow would support community contributions via pull-requests, as well as revision history.