OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

openc2-lang message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Open-Source Tool for validating OpenC2 Command/Response using JSON-Schema


[Cross-posted to Slack channel, but including mailing list as well]:

 

All,

 

I have created a simple JSON-Schema mapping of the `working` OpenC2 Language Spec and packaged it as a command-line validation tool as well as an automated test suite that can validate good and bad OpenC2 Command and Response `.json` files (in bulk). Itâs written in Kotlin, but that shouldnât matter. If youâd like to submit PRâs to include new `.json` files to the validator, that would be great â the test suite will process them all automatically, so thereâs really no code changes required to add both `good` and `bad` JSON files to the test suite (I really only have a few files in there right now, but over time, we can build it up to be quite an example reference, I believe, with your help!). Also, if you take a look at the included JSON-Schema files for the OpenC2 Command (`command.json`) and the OpenC2 Response (`response.json`) you will note that Iâve added numerous validation rules that JSON-Schema supports (like validating `ipv4`, `ipv6`, and international extensions to `email`, `uri`, and `hostname`, as well as doing a first-pass at some deeper rules, like requiring a Device to include either a `hostname` or a `device_id` to be considered valid. In any case, the JSON-Schema validation language is significantly more robust than what I modeled here (including the ability to match against `regex` values and including complex `if`-`then`-`else` logic), but those can be easily added later if necessary. Also, the nice result of this is that the JSON-Schema validator can be run before a Producer accepts a command and many of the implementations return very nice error messages back to the callers if they do not comply with the standard (see the examples in the README). Anyway, please feel free to fork and enhance the test suite and validation rules in the JSON-Schema, if you have any interest â your contributions are most welcome! The project is here: https://github.com/bberliner/openc2-json-schema

 

I should also point out that the JSON-Schema standard has a built-in support for `import` of the schema definitions objects from external locations (either files or URLâs). So, while I did my modeling based on including all the object definitions in a single file, I certainly could have separated them all out into individual files and JSON-Schema would have imported them for me automatically. Something like this is particularly useful for importing Profile definitions, say. I did, however, model the new approach to OpenC2 `Extensions` which would use the `x-` prefix in proper places for Targets, Args, Actuators, and Responses. That was easy using the JSON-Schema `patternProperties` regular _expression_. If you look at my regular _expression_, I chose to limit them to `x-` followed by alphanumerics only. Since itâs a regex, itâs easy to make it say exactly what our intension would be (and to have rules that limit the length, too, say, which I chose not to model yet). (edited

 

Enjoy,

 

                -Brian

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]