# OSCAL REST API Meeting 20220414

- Topics on the backlog (not to discuss today):
- When, how, and why UUIDs change for certain OSCAL data?
- What use cases do we prioritize and how those influence the API?
- What are the minimally required model properties and required semantics across documents?
- Topics on the agenda to discuss today:
- How do we collect use cases?
- JH: From a lifecycle perspective, considerations for use case scenarios:
- Choices of platforms
- Types of API design for existing vendor solutions
- Capture top-down and bottom-up approaches for APIs and the strategy and integration
- Use of existing protocols and data format (SCAP) or greenfield?
- Adjacent community efforts for modern security data projects in the ecosystem
- MI: Perhaps we should consider "consumer" perspective: what is unique about FedRAMP and how that derives use cases?
- DW: How much work should we do with use cases before we are satsified we collected enough?
- BR: Allow enough time and resources until we get enough and see different stakeholders and groups.
- DW: Makes sense, also want to be agile and flexible
- BR: Without digging into specifics of a use case discussion, like the OSCAL Extensions mechanism, we can facilitate that flexibility at a technical level like done before
- AJ: Allow a way for community to give input and vote up most interesting or important use cases focus on them, adapt accordingly.
- WP: Can we capture top-down approaches in additional to use cases, perhaps with a whitepaper?
- BR: Keep in mind many vendors, in early OSCAL development, did not want to publicly disclose public use cases, how do we facilitate their input and feedback?
- DW: In other contexts, we do have public and private communication channels (GitHub and Gitter versus emailing at [e-mail]), but for this initiative NIST staff has less bandwidth so private communications use up bandwith from the NIST staff useful within this initiative and elsewhere.
- What the minimum criteria required to consider a solution?
- DW: Re minimum criteria, the EasyDynamics staff had a tangible, actionable draft spec to consume and constructively critique. That kind of approach is desirable, from our perspective, to make review and feedback focused and actionable. But important for community-driven proposals must come with sufficient detail and documentation.
- AJ, FL, JH, LB, MP support the use of OpenAPI.
- GZ: One of my concerns is the OpenAPI or another specification, people will force developers to use specific architecture by default to implement that API. Minimum criteria for an implementation that is actually used can bridge this gap and mitigate such risks around "just an OpenAPI specification."
- DW: I see the concerns, my experience in IETF is that two implementations exercising a standard are important to consider a standard interoperable.
- WP: There is also a problem between implementing all the features and implementing a feature set, and it is important through efforts like this to facilitate the former.
- DA: Language-level bindings, separate of the API, are important to this work and these potential risks.
- DW: We are working on a Java and soon C# language bindings, we continue to work on them. There are also a growing number of community efforts.
- AJ: What will we do with XML data in a REST API?
- DW: We should table for now but no immediate answers.
- WP: We will definite what is complete? That will drive if JSON is good enough, or whether we must or optionally support other formats?
- AJ: Do we need to handle the "capabilities of 1 or more systems that support X or Y because of OSCAL models they implement and/or support?" or we table that?
- DW: Later enumeration of use cases can help us suss that out.
- JH: What about conformance tests?
- DW: AJ, add this to the backlog for future discussion topics.
- Where do we use this work?
- GZ: GitHub is the common way to share code, I support it.
- MI: Reiterate Dave's question, should NIST host the repo?
- JH: Current status quo is EasyDynamics, should we move it?
- FL and DA: We would like it hosted and/or migrated to NIST GitHub.
- AJ: Do we need to migrate the EasyDynamics work?
- DW: Worth considering, but not important to decide right now.
- MP: Are there any producitivity concerns with NIST hosting it?
- DW: We can find a way to work that if the community agrees and wants it, seems like they do?
- MP: Can users that are not NIST staff part of the usnistgov organization become admins and review & merge PRs?
- GZ: is this a community-managed or community-supported initiative? That should dictate the mechanics of the implementation.
- Other representatives of other organizations volunteered to host a repo on GitHub in an organization. Others recommended additional organizations.
- DW: Re AJ's clarifying question, what defines the project will be community participation, that is how you continue to have a stake in managing the project (NIST or otherwise).
- GZ: Can we have a GitHub issue to determine the best hosting organization?
- DW: AJ, please open a GitHub discussion to track a best choice of hosting an organization.
- How and why will we meet?
- BR: In the FedRAMP space, there is an advisory board of cloud service providers to faciliate security automation. Another group has paid membership for board membership for long-term staking a role in adoption of their security dataset.
- JH: GitHub issues and async communication seem to be good enough for now.
- GZ: We have a lot of useful tools with GH and its features, we should only use have meetings to discuss strategic approach and operational work will be done through GH.
- DW, LB and many others agree.