I've cc'd our TC's mail list here for broader visibility of your message.

We have recently been working on an OpenC2 Extension for CACAO spec, which is substantially complete and will be up for a CSD vote at next week's OpenC2 TC meeting. As it has developed I've realized it's more of a profile than an actual extension: it extends a couple of CACAO -OVs, proposes an "openc2" action step in place of "openc2-http", and calls for CACAO agents to handle OpenC2 message transfer and certain specific CACAO variables to convey info to the agents. We would certainly welcome review and feedback on our specification from the CACAO community. I was planning to wait until the CSD was published before calling it to your attention but there's no particular reason to do that.

Options to access the content:

• You can download the WD package from OASIS
• You can download the corresponding GitHub release
• Or just pull up the working version to read directly on GitHub.

For the CACAO community: 

OpenC2 is a suite of specifications that enables command and control of cyber defense systems and components. OpenC2 typically uses a request-response paradigm where a Command is encoded by a Producer (managing application) and transferred to a Consumer (managed device or virtualized function) using a secure transfer protocol, and the Consumer can respond with status and any requested information.

OpenC2 allows the application producing the commands to discover the set of capabilities supported by the managed devices. These capabilities permit the managing application to adjust its behavior to take advantage of the features exposed by the managed device. The capability definitions can be easily extended in a noncentralized manner, allowing standard and non-standard capabilities to be defined with semantic and syntactic rigor.

The OpenC2 language is described in the Language Specification using an abstract information model that does not specify any particular message encoding form (i.e., serialization). The most common encoding of OpenC2 messages is in JSON and the OpenC2 family of specifications presents examples in JSON format. Other encodings are permitted and are defined in their respective documents (e.g., a transfer specification). Similarly, OpenC2 messages can be conveyed using a variety of transfer mechanisms, using both point-to-point (e.g., HTTPS) and publish/subscribe (e.g., MQTT) communication models. The selection of message content encoding is determined by a combination of the environment where OpenC2 is being applied and the capabilities and limitations of the chosen transfer specification.

General information about OpenC2 can be found at OpenC2.org and our TC operations GH repo, as well as our TC's page at OASIS.  I recommend reading the OpenC2 Architecture Specification for a thorough overview.

As for the process beyond sharing this content, I'll leave that to the TCs' chairs to work out

I've cc'd our TC's mail list here for broader visibility of your message.

We have recently been working on an OpenC2 Extension for CACAO spec, which is substantially complete and will be up for a CSD vote at next week's OpenC2 TC meeting. As it has developed I've realized it's more of a profile than an actual extension: it extends a couple of CACAO -OVs, proposes an "openc2" action step in place of "openc2-http", and calls for CACAO agents to handle OpenC2 message transfer and certain specific CACAO variables to convey info to the agents. We would certainly welcome review and feedback on our specification from the CACAO community. I was planning to wait until the CSD was published before calling it to your attention but there's no particular reason to do that.

Options to access the content:

• You can download the WD package from OASIS
• You can download the corresponding GitHub release
• Or just pull up the working version to read directly on GitHub.

For the CACAO community: 

OpenC2 is a suite of specifications that enables command and control of cyber defense systems and components. OpenC2 typically uses a request-response paradigm where a Command is encoded by a Producer (managing application) and transferred to a Consumer (managed device or virtualized function) using a secure transfer protocol, and the Consumer can respond with status and any requested information.

OpenC2 allows the application producing the commands to discover the set of capabilities supported by the managed devices. These capabilities permit the managing application to adjust its behavior to take advantage of the features exposed by the managed device. The capability definitions can be easily extended in a noncentralized manner, allowing standard and non-standard capabilities to be defined with semantic and syntactic rigor.

The OpenC2 language is described in the Language Specification using an abstract information model that does not specify any particular message encoding form (i.e., serialization). The most common encoding of OpenC2 messages is in JSON and the OpenC2 family of specifications presents examples in JSON format. Other encodings are permitted and are defined in their respective documents (e.g., a transfer specification). Similarly, OpenC2 messages can be conveyed using a variety of transfer mechanisms, using both point-to-point (e.g., HTTPS) and publish/subscribe (e.g., MQTT) communication models. The selection of message content encoding is determined by a combination of the environment where OpenC2 is being applied and the capabilities and limitations of the chosen transfer specification.

General information about OpenC2 can be found at OpenC2.org and our TC operations GH repo, as well as our TC's page at OASIS.  I recommend reading the OpenC2 Architecture Specification for a thorough overview.

As for the process beyond sharing this content, I'll leave that to the TCs' chairs to work out

I've cc'd our TC's mail list here for broader visibility of your message.

We have recently been working on an OpenC2 Extension for CACAO spec, which is substantially complete and will be up for a CSD vote at next week's OpenC2 TC meeting. As it has developed I've realized it's more of a profile than an actual extension: it extends a couple of CACAO -OVs, proposes an "openc2" action step in place of "openc2-http", and calls for CACAO agents to handle OpenC2 message transfer and certain specific CACAO variables to convey info to the agents. We would certainly welcome review and feedback on our specification from the CACAO community. I was planning to wait until the CSD was published before calling it to your attention but there's no particular reason to do that.

Options to access the content:

• You can download the WD package from OASIS
• You can download the corresponding GitHub release
• Or just pull up the working version to read directly on GitHub.

For the CACAO community: 

OpenC2 is a suite of specifications that enables command and control of cyber defense systems and components. OpenC2 typically uses a request-response paradigm where a Command is encoded by a Producer (managing application) and transferred to a Consumer (managed device or virtualized function) using a secure transfer protocol, and the Consumer can respond with status and any requested information.

OpenC2 allows the application producing the commands to discover the set of capabilities supported by the managed devices. These capabilities permit the managing application to adjust its behavior to take advantage of the features exposed by the managed device. The capability definitions can be easily extended in a noncentralized manner, allowing standard and non-standard capabilities to be defined with semantic and syntactic rigor.

The OpenC2 language is described in the Language Specification using an abstract information model that does not specify any particular message encoding form (i.e., serialization). The most common encoding of OpenC2 messages is in JSON and the OpenC2 family of specifications presents examples in JSON format. Other encodings are permitted and are defined in their respective documents (e.g., a transfer specification). Similarly, OpenC2 messages can be conveyed using a variety of transfer mechanisms, using both point-to-point (e.g., HTTPS) and publish/subscribe (e.g., MQTT) communication models. The selection of message content encoding is determined by a combination of the environment where OpenC2 is being applied and the capabilities and limitations of the chosen transfer specification.

General information about OpenC2 can be found at OpenC2.org and our TC operations GH repo, as well as our TC's page at OASIS.  I recommend reading the OpenC2 Architecture Specification for a thorough overview.

As for the process beyond sharing this content, I'll leave that to the TCs' chairs to work out

I've cc'd our TC's mail list here for broader visibility of your message.

We have recently been working on an OpenC2 Extension for CACAO spec, which is substantially complete and will be up for a CSD vote at next week's OpenC2 TC meeting. As it has developed I've realized it's more of a profile than an actual extension: it extends a couple of CACAO -OVs, proposes an "openc2" action step in place of "openc2-http", and calls for CACAO agents to handle OpenC2 message transfer and certain specific CACAO variables to convey info to the agents. We would certainly welcome review and feedback on our specification from the CACAO community. I was planning to wait until the CSD was published before calling it to your attention but there's no particular reason to do that.

Options to access the content:

• You can download the WD package from OASIS
• You can download the corresponding GitHub release
• Or just pull up the working version to read directly on GitHub.

For the CACAO community: 

OpenC2 is a suite of specifications that enables command and control of cyber defense systems and components. OpenC2 typically uses a request-response paradigm where a Command is encoded by a Producer (managing application) and transferred to a Consumer (managed device or virtualized function) using a secure transfer protocol, and the Consumer can respond with status and any requested information.

OpenC2 allows the application producing the commands to discover the set of capabilities supported by the managed devices. These capabilities permit the managing application to adjust its behavior to take advantage of the features exposed by the managed device. The capability definitions can be easily extended in a noncentralized manner, allowing standard and non-standard capabilities to be defined with semantic and syntactic rigor.

The OpenC2 language is described in the Language Specification using an abstract information model that does not specify any particular message encoding form (i.e., serialization). The most common encoding of OpenC2 messages is in JSON and the OpenC2 family of specifications presents examples in JSON format. Other encodings are permitted and are defined in their respective documents (e.g., a transfer specification). Similarly, OpenC2 messages can be conveyed using a variety of transfer mechanisms, using both point-to-point (e.g., HTTPS) and publish/subscribe (e.g., MQTT) communication models. The selection of message content encoding is determined by a combination of the environment where OpenC2 is being applied and the capabilities and limitations of the chosen transfer specification.

General information about OpenC2 can be found at OpenC2.org and our TC operations GH repo, as well as our TC's page at OASIS.  I recommend reading the OpenC2 Architecture Specification for a thorough overview.

As for the process beyond sharing this content, I'll leave that to the TCs' chairs to work out

I've cc'd our TC's mail list here for broader visibility of your message.

We have recently been working on an OpenC2 Extension for CACAO spec, which is substantially complete and will be up for a CSD vote at next week's OpenC2 TC meeting. As it has developed I've realized it's more of a profile than an actual extension: it extends a couple of CACAO -OVs, proposes an "openc2" action step in place of "openc2-http", and calls for CACAO agents to handle OpenC2 message transfer and certain specific CACAO variables to convey info to the agents. We would certainly welcome review and feedback on our specification from the CACAO community. I was planning to wait until the CSD was published before calling it to your attention but there's no particular reason to do that.

Options to access the content:

• You can download the WD package from OASIS
• You can download the corresponding GitHub release
• Or just pull up the working version to read directly on GitHub.

For the CACAO community: 

OpenC2 is a suite of specifications that enables command and control of cyber defense systems and components. OpenC2 typically uses a request-response paradigm where a Command is encoded by a Producer (managing application) and transferred to a Consumer (managed device or virtualized function) using a secure transfer protocol, and the Consumer can respond with status and any requested information.

OpenC2 allows the application producing the commands to discover the set of capabilities supported by the managed devices. These capabilities permit the managing application to adjust its behavior to take advantage of the features exposed by the managed device. The capability definitions can be easily extended in a noncentralized manner, allowing standard and non-standard capabilities to be defined with semantic and syntactic rigor.

The OpenC2 language is described in the Language Specification using an abstract information model that does not specify any particular message encoding form (i.e., serialization). The most common encoding of OpenC2 messages is in JSON and the OpenC2 family of specifications presents examples in JSON format. Other encodings are permitted and are defined in their respective documents (e.g., a transfer specification). Similarly, OpenC2 messages can be conveyed using a variety of transfer mechanisms, using both point-to-point (e.g., HTTPS) and publish/subscribe (e.g., MQTT) communication models. The selection of message content encoding is determined by a combination of the environment where OpenC2 is being applied and the capabilities and limitations of the chosen transfer specification.

General information about OpenC2 can be found at OpenC2.org and our TC operations GH repo, as well as our TC's page at OASIS.  I recommend reading the OpenC2 Architecture Specification for a thorough overview.

As for the process beyond sharing this content, I'll leave that to the TCs' chairs to work out

I've cc'd our TC's mail list here for broader visibility of your message.

We have recently been working on an OpenC2 Extension for CACAO spec, which is substantially complete and will be up for a CSD vote at next week's OpenC2 TC meeting. As it has developed I've realized it's more of a profile than an actual extension: it extends a couple of CACAO -OVs, proposes an "openc2" action step in place of "openc2-http", and calls for CACAO agents to handle OpenC2 message transfer and certain specific CACAO variables to convey info to the agents. We would certainly welcome review and feedback on our specification from the CACAO community. I was planning to wait until the CSD was published before calling it to your attention but there's no particular reason to do that.

Options to access the content:

• You can download the WD package from OASIS
• You can download the corresponding GitHub release
• Or just pull up the working version to read directly on GitHub.

For the CACAO community: 

OpenC2 is a suite of specifications that enables command and control of cyber defense systems and components. OpenC2 typically uses a request-response paradigm where a Command is encoded by a Producer (managing application) and transferred to a Consumer (managed device or virtualized function) using a secure transfer protocol, and the Consumer can respond with status and any requested information.

OpenC2 allows the application producing the commands to discover the set of capabilities supported by the managed devices. These capabilities permit the managing application to adjust its behavior to take advantage of the features exposed by the managed device. The capability definitions can be easily extended in a noncentralized manner, allowing standard and non-standard capabilities to be defined with semantic and syntactic rigor.

The OpenC2 language is described in the Language Specification using an abstract information model that does not specify any particular message encoding form (i.e., serialization). The most common encoding of OpenC2 messages is in JSON and the OpenC2 family of specifications presents examples in JSON format. Other encodings are permitted and are defined in their respective documents (e.g., a transfer specification). Similarly, OpenC2 messages can be conveyed using a variety of transfer mechanisms, using both point-to-point (e.g., HTTPS) and publish/subscribe (e.g., MQTT) communication models. The selection of message content encoding is determined by a combination of the environment where OpenC2 is being applied and the capabilities and limitations of the chosen transfer specification.

General information about OpenC2 can be found at OpenC2.org and our TC operations GH repo, as well as our TC's page at OASIS.  I recommend reading the OpenC2 Architecture Specification for a thorough overview.

As for the process beyond sharing this content, I'll leave that to the TCs' chairs to work out