Issue for tracking current OpenControl schema and mappings and how best to merge OSCAL in to that community.

Initial discussion items below (moved from #68) ... CC @gregelin:

• OpenControl schema to OSCAL schema mappings:

  OSCAL component	OpenControl type
  catalog	standard
  profile	certification
  Implementation Assessment Assessment Results	component

• As of today, the OSCAL "catalog" and "profile" are far more robust than the equivalent OpenControl "standard" and "certification" types

  • OpenControl's "standard" type merely consists of maps of strings to represent a control catalog (e.g. 800-53) -> example
  • OpenControl's "certification" type is just a map of maps whose keys represent each of the controls included within a baseline (e.g. FedRAMP Moderate, etc) and whose values are empty -> example
  • OpenControl's "component" type does already incorporate elements that are assumed to also be defined in the equivalent OSCAL "implementation", "assessment" and "assessment results" once developed

• OpenControl does have the advantage of being strictly YAML-based which offers for pure human readability (vs. JSON and XML whose priorities are not for human readability)

  • What one sacrifices in terms of modeling and domain-driven capabilities of XML, one gains in human readability of YAML

• YAML is a superset of JSON

  • JSON schema can also validate against the YAML features that map to JSON
    • http://www.yaml.org/spec/1.2/spec.html#id2759572
    • https://json-schema-everywhere.github.io/yaml

• Since JSON is merely a subset of YAML, changing the OpenControl schema to utilize equilvalent JSON-formatted OSCAL terminology and tags is very straightforward ... and at that point, replacement of the equivalent OpenControl schema with OSCAL could be feasible

• Where things could get interesting is that we could take advantage of the nature of YAML's human readable format to create "lightweight" OSCAL components where we strip out what doesn't map well from XML/JSON

  • OpenControl could then house the "lightweight" OSCAL and shift its focus towards tooling for the consumption of OSCAL, generation of SSPs, etc ... and become more of a community of practice for authorization, security and audit professionals for ATO best practices, FISMA, etc

• YAML anchors, references and extend types enable re-use and better meshing of elements than what JSON can do ... quick overview of these features here

• Sample OSCAL YAML for comparison can be found in [do not merge] yaml examples #69

• 11/15 OpenControl community discussion highlights:

  • the focus was much less on the existing OpenControl schema and instead how the OpenControl umbrella could be used to address challenges orgs are facing with RMF, authorization processes/boundaries, reciprocity, and defining a common framework for automating compliance
  • At the current time, the OpenControl schema is by no means formalized nor an end-all-be-all, and IMHO can be replaced by OSCAL. With that being said, there are a few vendors that have embraced the OpenControl YAML format and would need to make engineering changes to adopt OSCAL. As such, OSCAL should be easily adoptable in those scenarios