As a user of the OSCAL Viewer, I want to see the Authorization Boundary of a System Security Plan (example) including any specified inline images so that I can understand the scope of the ATO.

Acceptance Criteria

• A Authorization Boundary section is displayed in System Characteristics if present in the OSCAL SSP
• The Authorization Boundarydescription field is displayed
• The Authorization Boundary remarks is displayed
• Any Authorization Boundary diagram images are displayed with any defined caption

Implementation Notes

• We're likely to develop a Diagram component that can be re-used across Authorization Boundary, Network Architecture, and Data Flow components
• We could potentially modify the existing oscal-rest-service test SSP to include an authorization boundary section pointing to an actual image, but any example SSP with that data will suffice

Subtasks

• Add OSCALDiagram component
• Add display of OSCALDiagram authz boundary to SSP
• Add authz boundary segment and diagram to test data in REST service
• EasyDynamics/oscal-rest-service#49

As a user of the OSCAL Viewer, I want to be able to specify the URL to load for an object viewer as a URL parameter so that I can create links that others can view without having to navigate, then paste a URL to load, then click reload.

Acceptance Criteria

Passing in a url=... URL parameter to any viewer type (Catalog, Profile, Component, SSP) replaces the default URL in the loading form and immediately loads that URL

When the production build of the example OSCAL Viewer is served on localhost, refreshing any page, or navigating to any url besides localhost:port, (eg. localhost:5000/catalog) will cause a 404 response that shows an error page instead of the desired page.

Steps to Reproduce

1. build the production build with npm run build in the example directory
2. serve the production build to localhost
3. view the viewer in a browser
4. refresh the page

Acceptance Criteria

Pressing refresh when viewing the production build of the OSCAL Viewer refreshes the page instead of taking the user to an error page.
Navigating to any url in the production build of the Viewer acts as it would in the live demo.

Currently the Control display only checks that a property name of status exists to determine whether or not to render the title as strikethrough but should instead also check for a value of withdrawn.

See comment on #67 for reference.

Currently the Profile Resolver just grabs the first rlink from a back-matter resource, but there could be multiple rlinks, one representing a human-readable document for example.

The resolver should instead look for the specific rlink that contains application/oscal.catalog+json, of which there should only be 1.

Steps to Reproduce (we don't need to actually do this)

1. Add another rlink before the application/oscal.catalog+json rlink within the same back matter resource but a different media type such as application/xml

Expected Behavior

2. The catalog can be resolved

Actual Behavior

2. The catalog resolution fails

As a user viewing the FedRAMP SSP template, I want the sections to render in a visually pleasing manner so that I can more easily read and comprehend the example.

Acceptance Criteria

• The System Characteristics properties width is increased to fill white space and not word wrap
• The System Implementation Component Title width is increased slightly to lessen word wrap
• The System Implementation Component Properties width is decreased slightly to lessen word wrap of other component fields
• The controls can be resolved even though the import-profile references an XML URL

Implementation Notes

• The existing fixJsonUrls function can likely be used for profile resolution

As user of the OSCAL Viewer or another app consuming the OSCAL React components, I want to be able to see the profile control modifications in the SSP’s implemented requirements and Component Definition’s control implementations so that I can fully understand the compliance requirements and how an SSP or Component Definition satisfies them.

Acceptance Criteria

• The Component Definition view displays the control modifications from imported profiles
  • The example component definition brings in the FedRAMP High profile so should display that profile's AC-2.3 constraints and additions for that particular control implementation
• The SSP view displays the control modifications from imported profiles
  • The example SSP brings in the 800-53 rev4 Moderate profile so should display that profile's AU-1 additions.
• The same acceptance criteria from #74 will apply here

Implementation Notes

• We should be able to leverage the work/components previously created for the Profile VIew

Child Issues

• Display Modifications in SSP
• Display Modifications in Component Definition

The command npm install will modify package-lock.json in some scenarios. This is a potential problem in the CI pipeline since there are scenarios where a change may modify package-lock.json itself. This means we are not properly testing the changes the users submit. And since the pipeline itself performs a git checkout at certain points, can result in unexpected pipeline failures, as seen on this Dependabot PR.

At the moment, this issue is primarily impacting Dependabot; however, we want to avoid this from surfacing with an actual (non-bot) contributor.

Doing this means that as contributors, we'll need to be a little more careful about making sure that when we add new dependencies or update them that we have the package-lock.json committed and in-sync but it feels incorrect for the lock file to be out of sync within the project repository anyway.

As a user involved in the governance, risk, and compliance of systems and components, I want to any date/time timestamps current displayed that are strongly typed in the OSCAL model to be presented in the proper locale format so that I can more easily interpret their values.

Acceptance Criteria

• All date/time timestamps that are specified as such in the OSCAL data model are locale formatted
  • A default locale of EN/US would be sufficient for this iteration, future implementations may grab the locale configured in the browser.

When clicking the “Reload” button repeatedly during the time the page loads, the Viewer crashes.

As a user of the OSCAL React components and/or example viewer, I want to be able to see a legend of what the color-coding of parameters within controls and control implementations means so that I can quickly understand the context of parameter placeholders vs parameter values.

Acceptance Criteria

• A legend is displayed that indicates the color coding of parameter placeholders vs parameter values.
• react-testing-library tests are in place

Implementation Notes

• This could likely just be two rounded color squares of orange and blue with lightly colored text indicating Placeholder vs Value in the top-right corner of the control.

Subtasks

• #427
• #428

Description

As a developer of the OSCAL Viewer, I would like styles to be declared at a global level for easy reusability among components.

Acceptance Criteria

• A strategy is proposed for reusable styles at a global scale
• An implementation of styles at a global scale is made follow the proposed strategy
  • This is only to the degree of styles defined in the style guide today

Proposed Solution

A top-level folder is created to contain styles at a global scale for components to reuse.

Additional Notes

No response

Implementation

• I can (or plan to) submit a pull request to implement this
• Implementing this may result in a breaking change

Currently Control Part Modifications of Adds Alters are not being displayed in OCSCALProfile, more specifically OSCALControlModification. Parts may contain [0, 1] parts or [0, 1] props.

Current Behavior

When loading the Profile https://raw.githubusercontent.com/GSA/fedramp-automation/master/baselines/rev4/json/FedRAMP_rev4_MODERATE-baseline_profile.json, Control part RA-5.a says there are 2 modifications but only lists 1.

Expected Behavior

Parts are displayed. For the image below, it would be more valuable to show are the title and prose than the individual props

Helpful Resources

Outline of adds:

This has been discussed and attempted to fix at #53.

As a user of the OSCAL Viewer app I want to understand if there will be any usability issues with SSPs based on the latest FedRAMP template and latest viewer code, so that I can be sure there are no limitations in leveraging the viewer for my SSP.

Acceptance Criteria

• Any limitations of the current viewer app are documented here
• Any UX improvement ideas not already present in the backlog are documented here

When the viewer is in REST mode and the GET find all requests for objects fails the viewer breaks with a blank screen.

Steps to Reproduce

1. Configure the REST service with a bad/missing path to an object type folder such as catalogs
2. Attempt to view catalogs with the viewer configured for REST mode to that service

Expected Behavior

3. The page is rendered with an error message

Actual Behavior

3. An empty page is displayed

As a developer consuming or contributing to the OSCAL React Library, I want that library to use the latest version of the Material-UI dependency so that I can minimize vulnerabilities, conflicting transient dependencies in my project, and more easily incorporate the Material-UI example source into OSCAL React Components.

Acceptance Criteria

• The @material-ui dependency has been upgraded to the latest @mui/material dependency (5.4.1 at the time of writing)
• All component imports have been updated

Implementation Notes

• See MUI's Blog Post on v5 Release
• See MUI's Migrating from v4 to v5
  • Includes 'codemods' that should do some of the work
• Not sure on the impact of styling moving to emotion

As a user of the OSCAL Viewer, I want to see the Data Flow of a System Security Plan (example) including any specified inline images so that I can understand how data moves in and out of the system boundaries.

Acceptance Criteria

• A Data Flow section is displayed in System Characteristics if present in the OSCAL SSP
• The Data Flow description field is displayed
• The Data Flow remarks is displayed
• Any Data Flow diagram images are displayed with any defined caption

Implementation Notes

• For sizing purposes, we will assume #225 has already been completed
• We're likely to develop a Diagram component that can be re-used across Authorization Boundary, Network Architecture, and Data Flow components
• We could potentially modify the existing oscal-rest-service test SSP to include an authorization boundary section pointing to an actual image, but any example SSP with that data will suffice

The Profile display control test in fails intermittently, particularly in local environments. The tests should consistently pass in all environments.

Steps to Reproduce

1. Run npm test locally on all tests, potentially several times to trigger the failure

Expected Results

2. The tests pass consistently

Actual Results

2. The test sometimes fails.

Implementation Notes

It seems as though the test is run without waiting for control resolution to complete. It could be that the OSCALProfile component returns a render complete while it's still resolving controls, triggering the test to evaluate before resolution is complete.

As a developer consuming the OSCAL React components, I want to see documentation for each component and how to use it so that I can more easily understand how to incorporate them into my application.

Acceptance Criteria

• Documentation on each React component is available
  • Required and Optional Props
  • Examples of use

Implementation Notes

• We’ll likely want to generate the documentation from JSDoc annotations/comments in source code of the components to be displayed using something like React Styleguidist or Storybook
• Ideally the documentation source will then be generated and published as part of the CI/CD pipeline

See:

• usnistgov/oscal-content#59

We should remove the workarounds when those issues have been fixed.

The viewer app in the sandbox environment currently shows an error when switching from catalog to SSP.

Steps to Reproduce

1. Navigate to the sandbox environment viewer
2. Click the nav menu and click System Security Plan Viewer

Expected Behavior

3. The default SSP renders

Actual Behavior

3. An error is shown:

Yikes! Something went wrong loading the OSCAL data. Sorry, we'll look into it. (Unexpected token < in JSON at position 0)

Implementation Notes

• We should be sure the behavior is fixed for all 'root' OSCAL objects, not just SSPs.

The viewer app currently breaks when trying to view the example basic-catalog.json.

Steps to Reproduce

1. Navigate to the Catalog Viewer page
2. Paste in the raw link for the basic-catalog
3. Click Reload

Expected Behavior

4. The catalog renders

Actual Behavior

5. A blank page is returned (and the browser console shows errors)

When using the following example component file,

https://raw.githubusercontent.com/EasyDynamics/oscal-content/manual-fix-of-component-paths/examples/component-definition/json/example-component-min.json,

we get the following error:

Yikes! Something went wrong loading the OSCAL data. Sorry, we'll look into it. (Unexpected token : in JSON at position 3).

Steps to reproduce

1. Go to component viewer
2. Enter the above component file in the component url box
3. Click on the reload button

Acceptance Criteria

• The above error does not occur in the example-component-min file or in any of the other example files

As a user of the OSCAL Viewer, I want to see the Network Architecture of a System Security Plan (example) including any specified inline images so that I can understand the top-level networking components of the system.

Acceptance Criteria

• A Network Architecture section is displayed in System Characteristics if present in the OSCAL SSP
• The Network Architecturedescription field is displayed
• The Network Architecture remarks is displayed
• Any Network Architecture diagram images are displayed with any defined caption

Implementation Notes

• For sizing purposes, we will assume #225 has already been completed
• We're likely to develop a Diagram component that can be re-used across Authorization Boundary, Network Architecture, and Data Flow components
• We could potentially modify the existing oscal-rest-service test SSP to include an authorization boundary section pointing to an actual image, but any example SSP with that data will suffice

When running npm run test a console error occurs:

 Warning: Each child in a list should have a unique "key" prop.

       119 |       <CardContent>
       120 |         <div className={classes.tabsContainer}>
     > 121 |           <Tabs
       122 |             orientation="vertical"
       123 |             variant="scrollable"
       124 |             value={value}

Acceptance Criteria

• Running npm run test no longer has console error

When OSCALControl calls OSCALControlPart, it should pass in a controlId prop.
Currently, this prop is missing, so any Control Parts called from OSCALControl will not render any modifications.

Acceptance Criteria

All Control Parts render any modifications that apply to them.

As a user involved in the governance, risk, and compliance of systems and components exploring controls, I want the prose of control statements, guidance, and other components that may use the markup type to be in a neat and human-readable format.

Acceptance Criteria

• Instances of markdown appearing in areas specified below are handled in a reasonably clean and readable way:
  • Emphasized text is bolded or italicized, or the * characters are simply removed.
  • Hyperlinks are implemented, or the parentheses/brackets characters are removed
  • If any other instances of markdown are identified eg. quoted, subscripted, or superscripted text they are handled in a clean and readable way.
• The following fields should support markdown:
  • Prose statements
  • Metadata Title
  • System Implementation remarks
  • Control Implementation descriptions (SSP and Component Definition)
• A (lightweight) architectural decision record (see examples) has been created that describes our choice of Markdown renderer and specifically talks to the security aspects of that library

Implementation Notes

Some examples of markdown appearing as plain text in the 800-53 rev5 catalog:

Markdown also appears in the prose of several of the guidance buttons:

Subtasks:

As a user of the OSCAL Viewer, I want to be able to not have the viewer crash when I load an incorrect component.

Steps to reproduce

1. Go to a component viewer.
2. Load another type of component.

For example, loading https://raw.githubusercontent.com/usnistgov/oscal-content/master/examples/ssp/json/ssp-example.json into a catalog viewer causes the viewer to crash.

Acceptance Criteria

• Loading an incorrect component does not cause an outright crash
• An error message appears
• User has ability to reload another component after using incorrect one

Currently the viewer app crashes when loading a URL with the wrong OSCAL object type, i.e. reloading an SSP URL in the Catalog Viewer

Steps to Reproduce

1. Navigate to the sandbox viewer environment
2. Paste an SSP URL into the URL input and click Reload

Expected Behavior

3. An error is shown (standard red bar with 'Yikes') that indicates the URL response could not be parsed

Actual Behavior

3. The page crashes (white page with no error is shown)

Implementation Notes

• We want to be sure this is fixed for all 'root' OSCAL objects, not just catalogs.
• We'll want an automated end-to-end (Cypress) test to confirm behavior

As a user of the OSCAL Viewer, I want to see the Inventory Items of a System Security Plan (example) so that I can understand the managed inventory instances of the system.

Acceptance Criteria

• An Inventory Items table with one row per Inventory Item is displayed in System Implementation if present in the OSCAL SSP
• The known prop names are displayed as columns in a form similar to the FedRAMP Inventory Workbook
  • In this iteration it would be sufficient if unknown/custom props were not displayed
• Any Responsible Parties defined are displayed in the table
• Any Implemented Components are displayed in the table
• Any remarks are displayed in the table
• It is not necessary to display links in this iteration

Implementation Notes

The inventory-items array can be quite large, so some type of scroll or dropdown UI element should be used so that not all of them take up too much real estate at one time.

As a user involved in the governance, risk, and compliance of systems and components, I want to browse an OSCAL Profile in a user interface and see its removed control elements so that I can better understand the control modifications within it.

Acceptance Criteria

• The Profile viewer shows the removal of control elements of an OSCAL Profile

Implementation Notes

• This may require a deeper investigation of the current Profile resolution guidance from NIST
• Perhaps a simple strikethrough font variant of the control element removed would be a sufficient visual indicator

Would you all be interested in a contribution of a Dockerfile based on Platform One Iron Bank standards that could be used to easily run this example app locally or in a kubernetes cluster?

See:

• usnistgov/oscal-content#58
• usnistgov/oscal-content#60
• usnistgov/oscal-content#69
• usnistgov/OSCAL#914
• GSA/fedramp-automation#103

We should remove the workarounds when those issues have been fixed.

Due to updates in GSA/fedramp-automation#137, the default OSCAL Component URL in the Component Viewer no longer loads.

Steps to Reproduce

Navigate to https://oscal-viewer.msd.easydynamics.com/component-definition

Expected Behavior

The Component URL will render a component with the OSCAL Viewer

Actual Behavior

As a user involved in the governance, risk, and compliance of systems and components, I want the navigation between control implementation by components of System Security Plans to be obvious with a focus on controls first, then components, so that I can easily understand how controls are addressed by each component.

Acceptance Criteria

• The component control implementation component tab navigation should be right-aligned
  • Hector originally suggested left-align but given the red highlight of the currently selected item is to the right it may make more sense to right-align
  • Review the result with Hector
• An iteration of implemented control ids/names/titles is available as primary navigation (rather than scrolling the entire page)
• An iteration of component names/titles is available as a secondary navigation to see the details of how a specific component addresses a specific control

Implementation Notes

• We should consider #88 in conjunction with (or before) this issue as that form of navigation will be applicable here
• This could be implemented as two 'nested' left tab navigations (or potentially a tree structure)

As a consumer of the OSCAL React library, I want to be sure I'm not adding vulnerabilities through transitive dependencies highlighted by GitHub to my project so that I can remain secure and compliant.

Acceptance Criteria

• There are no GitHub security alerts on the repository
• Ideally the Dependabot PRs have been merged

As a user involved in the governance, risk, and compliance of systems and components, I want to browse an OSCAL Profile in a user interface and see the proper set of controls if include-all or exclude-controls has been defined for a catalog import so that I can better understand the control modifications within it.

Acceptance Criteria

• Any profile using include-all in a catalog import renders all controls in that catalog. unless excluded
• Any profile using exclude-controls in a catalog import should not render those excluded controls

Implementation Notes

• This will likely require a close examination of the processing guidance defined by NIST.

As a user involved in the governance, risk, and compliance of systems and components exploring controls, I want the method of accessing the content of a control's guidance clearly displayed and have that information strongly linked to the control so that I can more easily consume guidance across many different controls.

Acceptance Criteria

• The Guidance button has been renamed to Read Guidance
  

  oscal-react-library/src/components/OSCALControlGuidance.js

  Lines 40 to 46 in a3db4a7

  	<OSCALControlGuidanceButton
  	variant="outlined"
  	size="small"
  	onClick={handleClick}
  	>
  	Guidance
  	</OSCALControlGuidanceButton>

• The Guidance modal title includes the control ID and title
  

  oscal-react-library/src/components/OSCALControlGuidance.js

  Line 54 in a3db4a7

  <DialogTitle id="scroll-dialog-title">Guidance</DialogTitle>

  
  

  oscal-react-library/src/components/OSCALControlPart.js

  Lines 34 to 36 in a3db4a7

  	if (props.part.name === "guidance") {
  	return <OSCALControlGuidance prose={props.part.prose} />;
  	}

As a user involved in the governance, risk, and compliance of systems and components exploring controls, I want to be able to easily view the basic elements available on a desktop browser using a mobile browser so that I can quickly understand the current state when I don’t have access to a desktop device.

Acceptance Criteria

• Metadata on all OSCAL models displays in a readable manner
  • When viewing the OSCAL Viewer on a mobile device, the version and modified date detail renders poorly with overlapping text.
• Control Implementations render in a reasonable manner
• SSP System Characteristics render in a reasonable manner

When a URL is entered that leads to a failed fetch or other error during loading, the reload button stays greyed out, preventing the user from entering a new URL:

Steps to Reproduce

1. Enter an invalid url into any of the four URL bars.
2. Press reload.

OR navigate to a link with an invalid url such as:
https://oscal-viewer.msd.easydynamics.com/catalog?url=goofy

Acceptance Criteria

The reload button is still enabled even when the error message is displayed.

Implementation

This likely has to do with the isLoaded or isResolutionComplete state variables in OSCALLoader.js

Currently the getControlOrSubControl in OSCALControlResolver only supports a single level depth of controls when searching for controls but that depth is unbounded in the OSCAL specification, which we should support.

We may consider this a lower priority until we see catalogs in use with controls of greater depth.

See the comment on #67 for reference.

As a user of the OSCAL Viewer/Editor, I want to be able to quickly navigate to sections of OSCAL documents, including specific controls and control implementations, using anchor links so that I don't have to scroll through often large pages and can bookmark/share specific sections.

Implementation Notes (and Original Submission)

Within the Catalog Viewer, it would be really helpful if I could link directly to a control within the catalog; for example, if navigating to https://oscal-viewer.msd.easydynamics.com/catalog?url=https://raw.githubusercontent.com/usnistgov/oscal-content/master/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json#SI-3 were to automatically result in "System and Information Integrity" expanded with "SI-3 Malicious Code Protection" focused in the viewport. Perhaps each control could also have a way to copy a link to it (for example, the way that you can do so for headings on the Microsoft Docs).

The link should use the #/fragment in the URL rather than a querystring parameter for determining where in the page to navigate to, in order to support browsers' native capabilities to do so. This could either be handled by adding an id attribute to the headings or placing an <a> tag with a name directly above the <hX> tags.

I am not sure whether this feature request cleanly maps to the other viewer types.

As a user of the OSCAL viewer or underlying React components, I want to see the indicator of modifications displayed in a way that reflects the position value that has been defined for them so that I can understand how they apply to the control.

Acceptance Criteria

• The visual indicator of modifications is displayed in a position relative to the control or id-ref that reflects the defined position value for that modification

As a user involved in the governance, risk, and compliance of systems and components, I want to be able to easily navigate different control groups and the controls within them in a catalog so that I can quickly get to and understand the details of those controls.

Acceptance Criteria

• The control groups in a catalog can be accessed in a left-hand navigation index
• Clicking on a control group displays that group's controls
• Individual controls are displayed in collapsible panel, initially closed

Implementation Notes

• The Drawer Component may be a good solution to displaying the navigation. We will need to make sure the naming is distinct to the what is currently called DrawerSelector.

Mockup:

As a user involved in the governance, risk, and compliance of systems and components, I want to see the tree of Profile/Catalog inheritance for any OSCAL objects that reference/import Profiles so that I can understand how controls are being resolved.

Acceptance Criteria

• SSPs show the expanded tree of referenced Profiles/Catalogs titles after the metadata section
• Profiles show the expanded tree of referenced Profiles/Catalogs titles after the metadata section
• Component Definitions show the expanded tree of referenced Profiles/Catalogs titles after the metadata section
• The display of information should distinguish between Profiles and Catalogs in some way

Implementation Notes

• We can likely use the same React component across SSPs, Profiles, and Component Definitions
• We can likely use the Material-UI TreeView component as shown below for the example SSP
• We could consider icons for distinguishing between Profiles and Catalogs, or simply use a prefix, i.e. "Profile: "
• We could consider "Profiles/Catalog Inheritance" as the header name for this section
• We are not displaying profile resolution details at this time
• In the future we will address the resolution path of individual controls, but not in this iteration

As a user involved in the governance, risk, and compliance of systems and components, I want it to be obvious which links in the OSCAL viewer are external so that I can better determine whether to explore that link during my workflow at that time.

Acceptance Criteria

• All external links display the OpenInNew material-ui icon
• All external links open in a new browser tab

As a member of the community, it would be useful to start and participate in discussions for the project outside of the typical issue format.

I do not know if we have looked into this much before but it could be something to consider. https://docs.github.com/en/discussions/quickstart has documentation on it. This could be a good way to start and maintain discussions on the project with the community.

As a user of the OSCAL viewer app or underlying React components, I want Profiles to be resolved and displayed in a timely manner so that my workflow is not disturbed by waiting for the page to load.

Acceptance Criteria

• The Profile viewer loads the FedRAMP moderate profile in 2 seconds or less in the live sandbox environment
• If the complete rendering takes longer than 0.5 seconds a loading indicator should be displayed for any area taking time to render

Implementation Notes

• The Material-UI Skeleton component should be considered
• Note that we’ll address any loading indicator additions to other viewers in a future issue

As a user involved in the governance, risk, and compliance of systems and components exploring controls, I want the media type of the back matter resources to be displayed in a human readable format when possible.

Acceptance Criteria

• Back matter media types have human-readable names for the common types (OSCAL documents, PDFs, HTML document, etc)
• If the media type doesn't match to something well-known, the exact value from the media-type field is displayed
• If the media type isn't specified, whichever heuristic is used to determine a media type results in a human readable name (such as using the file extension)
• Product Owner agrees with the list of recognized types.

Implementation Notes

• Per the specification, this is supposed to be an IANA registered media type; however, it seems that some things don't comply with this
  • Our default catalog seems to not specify media-type for many documents; however we seem to detect many of them as PDFs or "Unknown"
  • Some of the media types, such as application/oscal.content+json is not formally registered as an IANA media type