Open Command and Control (OpenC2) Language Specification Version 1.0

Committee Specification Draft 08 /
Public Review Draft 02

04 April 2019

This version:

https://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd02/oc2ls-v1.0-csprd02.md (Authoritative)
https://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd02/oc2ls-v1.0-csprd02.html
https://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd02/oc2ls-v1.0-csprd02.pdf

Previous version:

http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/oc2ls-v1.0-csprd01.md (Authoritative)
http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/oc2ls-v1.0-csprd01.html
http://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd01/oc2ls-v1.0-csprd01.pdf

Latest version:

https://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.md (Authoritative)
https://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.html
https://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.pdf

Technical Committee:

OASIS Open Command and Control (OpenC2) TC

Chairs:

Joe Brule (jmbrule@nsa.gov), National Security Agency
Sounil Yu (sounil.yu@bankofamerica.com), Bank of America

Editors:

Jason Romano (jdroman@nsa.gov), National Security Agency
Duncan Sparrell (duncan@sfractal.com), sFractal Consulting LLC

Abstract:

Cyberattacks are increasingly sophisticated, less expensive to execute, dynamic and automated. The provision of cyber defense via statically configured products operating in isolation is untenable. Standardized interfaces, protocols and data models will facilitate the integration of the functional blocks within a system and between systems. Open Command and Control (OpenC2) is a concise and extensible language to enable machine-to-machine communications for purposes of command and control of cyber defense components, subsystems and/or systems in a manner that is agnostic of the underlying products, technologies, transport mechanisms or other aspects of the implementation. It should be understood that a language such as OpenC2 is necessary but insufficient to enable coordinated cyber responses that occur within cyber relevant time. Other aspects of coordinated cyber response such as sensing, analytics, and selecting appropriate courses of action are beyond the scope of OpenC2.

Status:

This document was last revised or approved by the OASIS Open Command and Control (OpenC2) TC on the above date. The level of approval is also listed above. Check the "Latest version" location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=openc2#technical.

TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at https://www.oasis-open.org/committees/openc2/.

This specification is provided under the Non-Assertion Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC's web page (https://www.oasis-open.org/committees/openc2/ipr.php).

Note that any machine-readable content (Computer Language Definitions) declared Normative for this Work Product is provided in separate plain text files. In the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails.

Citation format:

When referencing this specification the following citation format should be used:

[OpenC2-Lang-v1.0]

Open Command and Control (OpenC2) Language Specification Version 1.0. Edited by Jason Romano and Duncan Sparrell. 04 April 2019. OASIS Committee Specification Draft 08 / Public Review Draft 02. https://docs.oasis-open.org/openc2/oc2ls/v1.0/csprd02/oc2ls-v1.0-csprd02.html. Latest version: https://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.html.

Notices

Copyright © OASIS Open 2019. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark for above guidance.

Table of Contents

• 1 Introduction
  • 1.1 IPR Policy
  • 1.2 Terminology
  • 1.3 Normative References
  • 1.4 Non-Normative References
  • 1.5 Document Conventions
    • 1.5.1 Naming Conventions
    • 1.5.2 Font Colors and Style
  • 1.6 Overview
  • 1.7 Goal
  • 1.8 Purpose and Scope
• 2 OpenC2 Language Description
  • 2.1 OpenC2 Command
  • 2.2 OpenC2 Response
• 3 OpenC2 Language Definition
  • 3.1 Base Components and Structures
    • 3.1.1 Data Types
    • 3.1.2 Semantic Value Constraints
    • 3.1.3 Multiplicity
    • 3.1.4 Derived Enumerations
    • 3.1.5 Extensions
    • 3.1.6 Serialization
      • 3.1.6.1 ID and Name Serialization
      • 3.1.6.2 Integer Serialization
  • 3.2 Message
  • 3.3 Content
    • 3.3.1 OpenC2 Command
      • 3.3.1.1 Action
      • 3.3.1.2 Target
      • 3.3.1.3 Actuator
      • 3.3.1.4 Command Arguments
    • 3.3.2 OpenC2 Response
      • 3.3.2.1 Response Status Code
  • 3.4 Type Definitions
    • 3.4.1 Target Types
      • 3.4.1.1 Artifact
      • 3.4.1.2 Device
      • 3.4.1.3 Domain Name
      • 3.4.1.4 Email Address
      • 3.4.1.5 Features
      • 3.4.1.6 File
      • 3.4.1.7 IPv4 Address Range
      • 3.4.1.8 IPv4 Connection
      • 3.4.1.9 IPv6 Address Range
      • 3.4.1.10 IPv6 Connection
      • 3.4.1.11 MAC Address
      • 3.4.1.12 Process
      • 3.4.1.13 Properties
      • 3.4.1.14 URI
    • 3.4.2 Data Types
      • 3.4.2.1 Action-Targets
      • 3.4.2.2 Date-Time
      • 3.4.2.3 Duration
      • 3.4.2.4 Feature
      • 3.4.2.5 Hashes
      • 3.4.2.6 Hostname
      • 3.4.2.7 IPv4 Address
      • 3.4.2.8 IPv6 Address
      • 3.4.2.9 L4 Protocol
      • 3.4.2.10 Namespace Identifier
      • 3.4.2.11 Payload
      • 3.4.2.12 Port
      • 3.4.2.13 Response-Type
      • 3.4.2.14 Version
• 4 Mandatory Commands/Responses
  • 4.1 Implementation of 'query features' Command
  • 4.2 Examples of 'query features' Commands and Responses
• 5 Conformance
  • 5.1 Conformance Clause 1: Command
  • 5.2 Conformance Clause 2: Response
  • 5.3 Conformance Clause 3: Producer
  • 5.4 Conformance Clause 4: Consumer
• Annex A. Examples
  • A.1 Example 1
    • A.1.1 Example 1: Command
    • A.1.2 Example 1: Response
  • A.2 Example 2
    • A.2.1 Example 2: Command
    • A.2.2 Example 2: Response
  • A.3 Example 3
    • A.3.1 Example 3: Command
    • A.3.2 Example 3: Response
• Annex B. Acronyms
• Annex C. Revision History
• Annex D. Acknowledgments

1 Introduction

The content in this section is non-normative, except where it is marked normative.

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.

1.1 IPR Policy

This specification is provided under the Non-Assertion Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC's web page (https://www.oasis-open.org/committees/openc2/ipr.php).

1.2 Terminology

This section is normative.

• Action: The task or activity to be performed (e.g., 'deny').
• Actuator: The function performed by the Consumer that executes the Command (e.g., 'Stateless Packet Filtering').
• Argument: A property of a Command that provides additional information on how to perform the Command, such as date/time, periodicity, duration, etc.
• Command: A Message defined by an Action-Target pair that is sent from a Producer and received by a Consumer.
• Consumer: A managed device / application that receives Commands. Note that a single device / application can have both Consumer and Producer capabilities.
• Message: A content- and transport-independent set of elements conveyed between Consumers and Producers
• Producer: A manager application that sends Commands.
• Response: A Message from a Consumer to a Producer acknowledging a Command or returning the requested resources or status to a previously received request.
• Specifier: A property or field that identifies a Target or Actuator to some level of precision.
• Target: The object of the Action, i.e., the Action is performed on the Target (e.g., IP Address).

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.3 Normative References

[OpenC2-HTTPS-v1.0]

Specification for Transfer of OpenC2 Messages via HTTPS Version 1.0. Edited by David Lemire. Latest version: http://docs.oasis-open.org/openc2/open-impl-https/v1.0/open-impl-https-v1.0.html

[OpenC2-SLPF-v1.0]

Open Command and Control (OpenC2) Profile for Stateless Packet Filtering Version 1.0. Edited by Joe Brule, Duncan Sparrell, and Alex Everett. Latest version: http://docs.oasis-open.org/openc2/oc2slpf/v1.0/oc2slpf-v1.0.html

[RFC0768]

Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, https://www.rfc-editor.org/info/rfc768.

[RFC0791]

Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, https://www.rfc-editor.org/info/rfc791.

[RFC0792]

Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, https://www.rfc-editor.org/info/rfc792.

[RFC0793]

Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, https://www.rfc-editor.org/info/rfc793.

[RFC1034]

Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, https://www.rfc-editor.org/info/rfc1034.

[RFC1123]

Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, https://www.rfc-editor.org/info/rfc1123.

[RFC1321]

Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, https://www.rfc-editor.org/info/rfc1321.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC2673]

Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999, https://tools.ietf.org/html/rfc2673

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, https://www.rfc-editor.org/info/rfc3986.

[RFC4122]

Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, https://www.rfc-editor.org/info/rfc4122.

[RFC4291]

Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, https://www.rfc-editor.org/info/rfc4291.

[RFC4632]

Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, https://www.rfc-editor.org/info/rfc4632.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, https://www.rfc-editor.org/info/rfc4648.

[RFC4960]

Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, https://www.rfc-editor.org/info/rfc4960.

[RFC5237]

Arkko, J. and S. Bradner, "IANA Allocation Guidelines for the Protocol Field", BCP 37, RFC 5237, DOI 10.17487/RFC5237, February 2008, https://www.rfc-editor.org/info/rfc5237.

[RFC5322]

Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, https://www.rfc-editor.org/info/rfc5322.

[RFC5952]

Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, https://www.rfc-editor.org/info/rfc5952.

[RFC6234]

Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, https://www.rfc-editor.org/info/rfc6234.

[RFC6335]

Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, https://www.rfc-editor.org/info/rfc6335.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, https://www.rfc-editor.org/info/rfc6838.

[RFC7493]

Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, https://www.rfc-editor.org/info/rfc7493.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

[RFC8200]

Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, https://www.rfc-editor.org/info/rfc8200.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, https://www.rfc-editor.org/info/rfc8259.

[EUI]

"IEEE Registration Authority Guidelines for use of EUI, OUI, and CID", IEEE, August 2017, https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/tutorials/eui.pdf

1.4 Non-Normative References

[IACD]

M. J. Herring, K. D. Willett, "Active Cyber Defense: A Vision for Real-Time Cyber Defense", Journal of Information Warfare, vol. 13, Issue 2, p. 80, April 2014.
Willett, Keith D., "Integrated Adaptive Cyberspace Defense: Secure Orchestration", International Command and Control Research and Technology Symposium, June 2015.

[UML]

"UML Multiplicity and Collections", https://www.uml-diagrams.org/multiplicity.html

1.5 Document Conventions

1.5.1 Naming Conventions

• [RFC2119]/[RFC8174] key words (see Section 1.2) are in all uppercase.
• All property names and literals are in lowercase, except when referencing canonical names defined in another standard (e.g., literal values from an IANA registry).
• Words in property names are separated with an underscore (_), while words in string enumerations and type names are separated with a hyphen (-).
• The term "hyphen" used here refers to the ASCII hyphen or minus character, which in Unicode is "hyphen-minus", U+002D.

1.5.2 Font Colors and Style

The following color, font and font style conventions are used in this document:

• A fixed width font is used for all type names, property names, and literals.
• Property names are in bold style – 'created_at'.
• All examples in this document are expressed in JSON. They are in fixed width font, with straight quotes, black text and a light shaded background, and 4-space indentation. JSON examples in this document are representations of JSON Objects. They should not be interpreted as string literals. The ordering of object keys is insignificant. Whitespace before or after JSON structural characters in the examples are insignificant [RFC8259].
• Parts of the example may be omitted for conciseness and clarity. These omitted parts are denoted with the ellipses (...).

Example:

{
    "action": "contain",
    "target": {
        "user_account": {
            "user_id": "fjbloggs",
            "account_type": "windows-local"
        }
    }
}

1.6 Overview

In general, there are two types of participants involved in the exchange of OpenC2 Messages, as depicted in Figure 1-1:

1. Producers: A Producer is an entity that creates Commands to provide instruction to one or more systems to act in accordance with the content of the Command. A Producer may receive and process Responses in conjunction with a Command.
2. Consumers: A Consumer is an entity that receives and may act upon a Command. A Consumer may create Responses that provide any information captured or necessary to send back to the Producer.

Figure 1-1. OpenC2 Message Exchange

OpenC2 is a suite of specifications for Producers and Consumers to command and execute cyber defense functions. These specifications include the OpenC2 Language Specification, Actuator Profiles, and Transfer Specifications. The OpenC2 Language Specification and Actuator Profile specifications focus on the language content and meaning at the Producer and Consumer of the Command and Response while the transfer specifications focus on the protocols for their exchange.

• The OpenC2 Language Specification provides the semantics for the essential elements of the language, the structure for Commands and Responses, and the schema that defines the proper syntax for the language elements that represents the Command or Response.
• OpenC2 Actuator Profiles specify the subset of the OpenC2 language relevant in the context of specific Actuator functions. Cyber defense components, devices, systems and/or instances may (in fact are likely to) implement multiple Actuator profiles. Actuator profiles extend the language by defining Specifiers that identify the Actuator to the required level of precision. Actuator Profiles may define Command Arguments and Targets that are relevant and/or unique to those Actuator functions.
• OpenC2 Transfer Specifications utilize existing protocols and standards to implement OpenC2 in specific environments. These standards are used for communications and security functions beyond the scope of the language, such as message transfer encoding, authentication, and end-to-end transport of OpenC2 messages.

The OpenC2 Language Specification defines a language used to compose Messages for command and control of cyber defense systems and components. A Message consists of a header and a payload (defined as a Message body in the OpenC2 Language Specification Version 1.0 and specified in one or more Actuator profiles). The language defines two payload structures:

1. Command: An instruction from one system known as the Producer, to one or more systems, the Consumer(s), to act on the content of the Command.
2. Response: Any information sent back to the Producer as a result of the Command.

OpenC2 implementations integrate the related OpenC2 specifications described above with related industry specifications, protocols, and standards. Figure 1-2 depicts the relationships among OpenC2 specifications, and their relationships to other industry standards and environment-specific implementations of OpenC2. Note that the layering of implementation aspects in the diagram is notional, and not intended to preclude any particular approach to implementing the needed functionality (for example, the use of an application-layer message signature function to provide message source authentication and integrity).

Figure 1-2. OpenC2 Documentation and Layering Model

OpenC2 is conceptually partitioned into four layers as shown in Table 1-1.

Table 1-1. OpenC2 Protocol Layers

• The Secure Transfer layer provides a communication path between the Producer and the Consumer. OpenC2 can be layered over any standard transfer protocol.
• The Message layer provides a transfer- and content-independent mechanism for conveying requests, responses, and notifications. A transfer specification maps transfer-specific protocol elements to a transfer-independent set of message elements consisting of content and associated metadata.
• The Common Content layer defines the structure of Commands and Responses and a set of common language elements used to construct them.
• The Function-specific Content layer defines the language elements used to support a particular cyber defense function. An Actuator profile defines the implementation conformance requirements for that function. Producers and Consumers will support one or more profiles.

The components of a Command are an Action (what is to be done), a Target (what is being acted upon), an optional Actuator (what is performing the command), and Command Arguments, which influence how the Command is to be performed. An Action coupled with a Target is sufficient to describe a complete Command. Though optional, the inclusion of an Actuator and/or Command Arguments provides additional precision to a Command.

The components of a Response are a numerical status code, an optional status text string, and optional results. The format of the results, if included, depend on the type of Response being transferred.

1.7 Goal

The goal of the OpenC2 Language Specification is to provide a language for interoperating between functional elements of cyber defense systems. This language used in conjunction with OpenC2 Actuator Profiles and OpenC2 Transfer Specifications allows for vendor-agnostic cybertime response to attacks.

The Integrated Adaptive Cyber Defense (IACD) framework defines a collection of activities, based on the traditional OODA (Observe–Orient–Decide–Act) Loop [IACD]:

• Sensing: gathering of data regarding system activities
• Sense Making: evaluating data using analytics to understand what's happening
• Decision Making: determining a course-of-action to respond to system events
• Acting: Executing the course-of-action

The goal of OpenC2 is to enable coordinated defense in cyber-relevant time between decoupled blocks that perform cyber defense functions. OpenC2 focuses on the Acting portion of the IACD framework; the assumption that underlies the design of OpenC2 is that the sensing/analytics have been provisioned and the decision to act has been made. This goal and these assumptions guide the design of OpenC2:

• Technology Agnostic: The OpenC2 language defines a set of abstract atomic cyber defense actions in a platform and implementation agnostic manner
• Concise: A Command is intended to convey only the essential information required to describe the action required and can be represented in a very compact form for communications-constrained environments
• Abstract: Commands and Responses are defined abstractly and can be encoded and transferred via multiple schemes as dictated by the needs of different implementation environments
• Extensible: While OpenC2 defines a core set of Actions and Targets for cyber defense, the language is expected to evolve with cyber defense technologies, and permits extensions to accommodate new cyber defense technologies.

1.8 Purpose and Scope

The OpenC2 Language Specification defines the set of components to assemble a complete command and control Message and provides a framework so that the language can be extended. To achieve this purpose, the scope of this specification includes:

1. the set of Actions and options that may be used in Commands
2. the set of Targets and Target Specifiers
3. a syntax that defines the structure of Commands and Responses
4. a JSON serialization of Commands and Responses
5. the procedures for extending the language

The OpenC2 language assumes that the event has been detected, a decision to act has been made, the act is warranted, and the initiator and recipient of the Commands are authenticated and authorized. The OpenC2 language was designed to be agnostic of the other aspects of cyber defense implementations that realize these assumptions. The following items are beyond the scope of this specification:

1. Language elements applicable to some Actuators, which may be defined in individual Actuator profiles.
2. Alternate serializations of Commands and Responses.
3. The enumeration of the protocols required for transport, information assurance, sensing, analytics and other external dependencies.

2 OpenC2 Language Description

The content in this section is non-normative.

The OpenC2 language has two distinct content types: Command and Response. The Command is sent from a Producer to a Consumer and describes an Action to be performed by an Actuator on a Target. The Response is sent from a Consumer, usually back to the Producer, and is a means to provide information (such as acknowledgment, status, etc.) as a result of a Command.

2.1 OpenC2 Command

The Command describes an Action to be performed on a Target and may include information identifying the Actuator or Actuators that are to execute the Command.

A Command has four main components, two required and two optional. The required components are the Action and the Target. The optional components are Command Arguments and the Actuator. A Command can also contain an optional Command identifier, if necessary. Section 3.3.1 defines the syntax of an OpenC2 Command.

The following list summarizes the main four components of a Command.

• Action (required): The task or activity to be performed.
• Target (required): The object of the action. The Action is performed on the Target. Properties of the Target, called Target Specifiers, further identify the Target to some level of precision, such as a specific Target, a list of Targets, or a class of Targets.
• Arguments (optional): Provide additional information on how the command is to be performed, such as date/time, periodicity, duration, etc.
• Actuator (optional): The Actuator executes the Command. The Actuator will be defined within the context of an Actuator Profile. Properties of the Actuator, called Actuator Specifiers, further identify the Actuator to some level of precision, such as a specific Actuator, a list of Actuators, or a group of Actuators.

The Action and Target components are required and are populated by one of the Actions in Section 3.3.1.1 and the Targets in Section 3.3.1.2. A particular Target may be further refined by the Target type definitions in Section 3.4.1. Procedures to extend the Targets are described in Section 3.1.5.

Command Arguments, if present, influence the Command by providing information such as timing, periodicity, duration, or other details on what is to be executed. They can also be used to convey the need for acknowledgment or additional status information about the execution of a Command. The valid Arguments defined in this specification are in Section 3.3.1.4. Procedures to extend Arguments are described in Section 3.1.5.

An Actuator is an implementation of a cyber defense function that executes the Command. An Actuator Profile is a specification that identifies the subset of Actions, Targets and other aspects of this language specification that are required or optional in the context of a particular Actuator. An Actuator Profile may extend the language by defining additional Targets, Arguments, and Actuator Specifiers that are meaningful and possibly unique to the Actuator.

The Actuator may be omitted from a Command and typically will not be included in implementations where the identities of the endpoints are unambiguous or when a high-level effects-based Command is desired and the tactical decisions on how the effect is achieved is left to the recipient.

2.2 OpenC2 Response

The Response is a Message sent from the recipient of a Command. Response messages provide acknowledgment, status, results from a query, or other information. At a minimum, a Response will contain a status code to indicate the result of performing the Command. Additional status text and response fields optionally provide more detailed information that is specific to or requested by the Command. Section 3.3.2 defines the syntax of an OpenC2 Response.

3 OpenC2 Language Definition

The content in this section is normative.

3.1 Base Components and Structures

3.1.1 Data Types

OpenC2 data types are defined using an abstract notation that is independent of both their representation within applications ("API" values) and their format for transmission between applications ("serialized" values). The data types used in OpenC2 messages are:

• API values do not affect interoperabilty, and although they must exhibit the characteristics specified above, their representation within applications is unspecified. A Python application might represent the Map type as a dict variable, a javascript application might represent it as an object literal or an ES6 Map type, and a C# application might represent it as a Dictionary or a Hashtable.

• Serialized values are critical to interoperability, and this document defines a set of serialization rules that unambiguously define how each of the above types are serialized using a human-friendly JSON format. Other serialization rules, such as for XML, machine-optimized JSON, and CBOR formats, exist but are out of scope for this document. Both the format-specific serialization rules in Section 3.1.6 and the format-agnostic type definitions in Section 3.4 are Normative.

Types defined with an ".ID" suffix (Choice.ID, Enumerated.ID, Map.ID) are equivalent to the non-suffixed types except:

1. Field definitions and API values are identified only by ID. The non-normative description may include a suggested name.
2. Serialized values of Enumerated types and keys of Choice/Map types are IDs regardless of serialization format.

OpenC2 type definitions are presented in table format. All table columns except Description are Normative. The Description column is always Non-normative.

For types without individual field definitions (Primitive types and ArrayOf), the type definition includes the name of the type being defined and the definition of that type. This table defines a type called Email-Addr that is a String that has a semantic value constraint of email:

For Structure types, the definition includes the name of the type being defined, the built-in type on which it is based, and options applicable to the type as a whole. This is followed by a table defining each of the fields in the structure. This table defines a type called Args that is a Map containing at least one field. Each of the fields has an integer Tag/ID, a Name, and a Type. Each field in this definition is optional (Multiplicity = 0..1), but per the type definition at least one must be present.

Type: Args (Map) [1..*]

The field columns present in a structure definition depends on the base type:

The ID column of Array and Record types contains the ordinal position of the field, numbered sequentially starting at 1. The ID column of Choice, Enumerated, and Map types contains tags with arbitrary integer values. IDs and Names are unique within each type definition.

3.1.2 Semantic Value Constraints

Structural validation alone may be insufficient to validate that an instance meets all the requirements of an application. Semantic validation keywords specify value constraints for which an authoritative definition exists.

3.1.3 Multiplicity

Property tables for types based on Array, Choice, Map and Record include a multiplicity column (#) that specifies the minimum and maximum cardinality (number of elements) of a field. As used in the Unified Modeling Language ([UML]), typical examples of multiplicity are:

When used with a Type, multiplicity is enclosed in square brackets, e.g.,:

A multiplicity of 0..1 denotes a single optional value of the specified type. A multiplicity of 0..n denotes a field that is either omitted or is an array containing one or more values of the specified type.

An array containing zero or more values of a specified type cannot be created implicitly using multiplicity, it must be defined explicitly as a named ArrayOf type. The named type can then be used as the type of a required field (multiplicity 1). Results are unspecified if an optional field (multiplicity 0..1) is a named ArrayOf type with a minimum length of zero.

3.1.4 Derived Enumerations

It is sometimes useful to reference the fields of a structure definition, for example to list fields that are usable in a particular context, or to read or update the value of a specific field. An instance of a reference can be validated against the set of valid references using either an explicit or a derived Enumerated type. A derived enumeration is created by appending ".Enum" to the type being referenced, and it results in an Enumerated type containing the ID and Name columns of the referenced type.

This example includes a type representing the value of a single picture element ("pixel") in an image, and an operation "SetValue" to set one of the color values of a pixel. It would be possible validate a SetValue operation against an explicit enumeration of the Pixel fields:

Type: Pixel (Map)

Type: SetValue (Record)

Type: Channel (Enumerated)

Example SetValue operation:

{"channel": "green", "value": 95}

But it is both easier and more reliable to use a derived enumeration to validate the reference directly against the type being referenced:

Type: SetValue (Record)

3.1.5 Extensions

One of the main design goals of OpenC2 was extensibility. Actuator profiles define the language extensions that are meaningful and possibly unique to the Actuator.

Each Actuator profile has a unique name used to identify the profile document and a short reference called a namespace identifier (NSID). The NSID is used to separate extensions from the core language defined in this specification.

All extension names MUST begin with a namespace identifier followed by a colon (":").

For example, the OASIS standard Stateless Packet Filtering actuator profile has:

• Unique Name: http://docs.oasis-open.org/openc2/oc2slpf/v1.0/oc2slpf-v1.0.md
• NSID: slpf

The namespace identifier for non-standard extensions MUST be prefixed with "x-".

For example, the fictional, non-standard Superwidget actuator profile has:

• Unique Name: http://www.acme.com/openc2/superwidget-v1.0.html
• NSID: x-acme

The list of Actions in Section 3.3.1.1 SHALL NOT be extended.

The Targets defined in Section 3.3.1.2 MAY be extended.

Example: In this example Command, the extended Target, rule_number, is defined within the Stateless Packet Filtering Profile with the namespace identifier slpf.

{
    "action": "delete",
    "target": {
        "slpf:rule_number": 1234
    }
}

The Arguments defined in Section 3.3.1.4 MAY be extended.

Example: In this example Command, the extended Argument, direction, is defined within the Stateless Packet Filtering Profile with the namespace identifier slpf.

{
    "action": "deny",
    "target": {
        "ipv6_net": {...}
    },
    "args": {
        "slpf:direction": "ingress"
    }
}

The Actuator property of a Command defined in Section 3.3.1.3 MUST be extended using the namespace identifier as the Actuator name, called an extended Actuator namespace. Actuator Specifiers MUST be defined within the extended Actuator namespace.

Example: In this example Command, the Actuator Specifier asset_id is defined within the Stateless Packet Filtering Profile namespace slpf.

{
    "action": "deny",
    "target": {
        "ipv4_connection": {...}
    },
    "actuator": {
        "slpf": {
            "asset_id": "30"
        }
    }
}

The properties of a Response defined in Section 3.3.2 MAY be extended using the namespace identifier as the results name, called an extended results namespace. One or more extended result types MUST be defined with the extended results namespace.

Example: In this example Response, the Response property, rule_number, is defined within the Stateless Packet Filtering Profile with the namespace identifier slpf.

{
    "status": 200,
    "slpf:rule_number": 1234
}

3.1.6 Serialization

OpenC2 is agnostic of any particular serialization; however, implementations MUST support JSON serialization in accordance with [RFC7493] and additional requirements specified in the following table.

JSON Serialization Requirements:

3.1.6.1 ID and Name Serialization

Instances of Enumerated types and keys for Choice and Map types are serialized as ID values except when using serialization formats intended for human consumption, where Name strings are used instead. Defining a type using ".ID" appended to the base type (e.g., Enumerated.ID, Map.ID) indicates that:

1. Type definitions and application values use only the ID. There is no corresponding name except as an optional part of the description.
2. Instances of Enumerated values and Choice/Map keys are serialized as IDs regardless of serialization format.

3.1.6.2 Integer Serialization

For machine-to-machine serialization formats, integers are represented as binary data, e.g., 32 bits, 128 bits. But for human-readable serialization formats (XML and JSON), integers are converted to strings.

Example: The JSON "number" type represents integers and real numbers as decimal strings without quotes.

{ "height": 68.2 }

As noted in [RFC7493], Section 2.2, a sender cannot expect a receiver to treat an integer with an absolute value greater than 2^^53 as an exact value.

The default representation of Integer types in text serializations is the native integer type for that format, e.g., "number" for JSON. Integer fields with a range larger than the IEEE 754 exact range (e.g., 64, 128, 2048 bit values) are indicated by appending "." or "." to the type, e.g. Integer.64 or Integer.. All serializations ensure that large Integer types are transferred exactly, for example in the same manner as Binary types. Integer values support arithmetic operations; Binary values are not intended for that purpose.

3.2 Message

This language specification and one or more Actuator profiles define the content of Commands and Responses, while transfer specifications define the on-the-wire format of a Message over specific secure transport protocols. Transfer specifications are agnostic with regard to content, and content is agnostic with regard to transfer protocol. This decoupling is accomplished by defining a standard message interface used to transfer any type of content over any transfer protocol.

A message is a content- and transport-independent set of elements conveyed between producers and consumers. To ensure interoperability all transfer specifications must unambiguously define how the message elements in Table 3-1 are represented within the secure transport protocol. This does not imply that all message elements must be used in all messages. Content, content_type, and msg_type are required in all messages. Other message elements are not required by this specification but may be required by other specifications.

Table 3-1. Common Message Elements

Note:

Implementations may use environment variables, private APIs, data structures, class instances, pointers, or other mechanisms to represent messages within the local environment. However the internal representation of a Message does not affect interoperability and is therefore beyond the scope of OpenC2. This means that the Message content is a data structure in whatever form is used within an implementation, not a serialized representation of that structure. Content is the input provided to a serializer or the output of a de-serializer. Msg_type is a three-element enumeration whose protocol representation is defined in each transfer spec, for example as a string, an integer, or a two-bit field. The internal form of enumerations, like content, does not affect interoperability and is therefore unspecified.

Usage Requirements:

• A producer MUST include a request_id in a request message if it expects a response to that request. Absence of a request_id signals consumers that no response is expected.
• The request_id of a request message SHOULD be a Version 4 UUID as specified in [RFC4122], Section 4.4.
• A consumer MUST copy the request_id from a request message into each response to that request.

3.3 Content

The purpose of this specification is to define the Action and Target portions of a Command and the common portions of a Response. The properties of the Command are defined in Section 3.3.1 and the properties of the Response are defined in Section 3.3.2.

In addition to the Action and Target, a Command has an optional Actuator. Other than identification of namespace identifier, the semantics associated with the Actuator Specifiers are defined in Actuator Profiles. The Actuators and Actuator-specific results contained in a Response are specified in 'Actuator Profile Specifications' such as StateLess Packet Filtering Profile, Routing Profile etc.

3.3.1 OpenC2 Command

The Command defines an Action to be performed on a Target.

Type: OpenC2-Command (Record)

Usage Requirements:

• A Consumer receiving a command with command_id absent and request_id present MUST use the value of request_id as the command_id.
• If present, the args property MUST contain at least one element defined in Section 3.3.1.4.

3.3.1.1 Action

Type: Action (Enumerated)

Usage Requirements:

• Each Command MUST contain exactly one Action defined in Section 3.3.1.1.

3.3.1.2 Target

Type: Target (Choice)

Usage Requirements:

• The target field in a Command MUST contain exactly one type of Target (e.g., ipv4_net).

3.3.1.3 Actuator

Type: Actuator (Choice)

3.3.1.4 Command Arguments

Type: Args (Map)

Usage Requirements:

• start_time, end_time, duration:
  • If none are specified, then start_time is now, end_time is never, and duration is infinity.
  • Only two of the three are allowed on any given Command and the third is derived from the equation end_time = start_time + duration.
  • If only start_time is specified then end_time is never and duration is infinity.
  • If only end_time is specified then start_time is now and duration is derived.
  • If only duration is specified then start_time is now and end-time is derived.
• response_requested:
  • If response_requested is specified as none then the Consumer SHOULD NOT send a Response.
  • If response_requested is specified as ack then the Consumer SHOULD send a Response acknowledging receipt of the Command: {"status": 102}.
  • If response_requested is specified as status then the Consumer SHOULD send a Response containing the current status of Command execution.
  • If response_requested is specified as complete then the Consumer SHOULD send a Response containing the status or results upon completion of Command execution.
  • If response_requested is not explicitly specified then the Consumer SHOULD respond as if complete was specified.

3.3.2 OpenC2 Response

Type: OpenC2-Response (Record)

Example:

{
    "status": 200,
    "status_text": "All endpoints successfully updated",
    "strings": ["wd-394", "sx-2497"]
}

Usage Requirements:

• All Responses MUST contain a status.

3.3.2.1 Response Status Code

Type: Status-Code (Enumerated.ID)

3.4 Type Definitions

3.4.1 Target Types

3.4.1.1 Artifact

Type: Artifact (Record)

3.4.1.2 Device

Type: Device (Map)

3.4.1.3 Domain Name

3.4.1.4 Email Address

3.4.1.5 Features

Usage Requirements:

• A Producer MUST NOT send a list containing more than one instance of any Feature.
• A Consumer receiving a list containing more than one instance of any Feature SHOULD behave as if the duplicate(s) were not present.

Usage Notes:

• A Producer may send a query command containing an empty list of features to determine if a Consumer is responding to commands (a heartbeat command), or to generate idle traffic to keep a connection to a Consumer from being closed due to inactivity (a keep-alive command). An active Consumer will return an empty response to this command, minimizing the amount of traffic used to perform heartbeat / keep-alive functions.

3.4.1.6 File

Type: File (Map)

3.4.1.7 IPv4 Address Range

An IPv4 address range is a CIDR block per "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan" [RFC4632] and consists of two values, an IPv4 address and a prefix.

For example, "192.168.17.0/24" is range of IP addresses with a prefix of 24 (i.e. 192.168.17.0 - 192.168.17.255).

JSON serialization of an IPv4 address range SHALL use the 'dotted/slash' textual representation of [RFC4632].

CBOR serialization of an IPv4 address range SHALL use a binary representation of the IP address and the prefix, each in their own field.

Type: IPv4-Net (Array /ipv4-net)

3.4.1.8 IPv4 Connection

Type: IPv4-Connection (Record)

3.4.1.9 IPv6 Address Range

Type: IPv6-Net (Array /ipv6-net)

3.4.1.10 IPv6 Connection

Type: IPv6-Connection (Record)

Editor's Note: Renumber

3.4.1.11 MAC Address

3.4.1.12 Process

Type: Process (Map)

3.4.1.13 Properties

3.4.1.14 URI

3.4.2 Data Types

3.4.2.1 Action-Targets

3.4.2.2 Date-Time

Usage Requirements:

• Value is the number of milliseconds since 00:00:00 UTC, 1 January 1970

3.4.2.3 Duration

Usage Requirements:

• Value is a number of milliseconds

3.4.2.4 Feature

Specifies the results to be returned from a query features Command.

Type: Feature (Enumerated)

3.4.2.5 Hashes

Type: Hashes (Map)

3.4.2.6 Hostname

3.4.2.7 IPv4 Address

3.4.2.8 IPv6 Address

3.4.2.9 L4 Protocol

Value of the protocol (IPv4) or next header (IPv6) field in an IP packet. Any IANA value, [RFC5237]

Type: L4-Protocol (Enumerated)

3.4.2.10 Namespace Identifier

3.4.2.11 Payload

Type: Payload (Choice)

3.4.2.12 Port

3.4.2.13 Response-Type

Type: Response-Type (Enumerated)

3.4.2.14 Version

4 Mandatory Commands/Responses

The content in this section is normative, except where it is marked non-normative.

A Command consists of an Action/Target pair and associated Specifiers and Arguments. This section enumerates the allowed Commands, identifies which are required or optional to implement, and presents the associated responses.

4.1 Implementation of 'query features' Command

The 'query features' Command is REQUIRED for all Producers and Consumers implementing OpenC2. This section defines the REQUIRED and OPTIONAL aspects of the 'query features' Command and associated response for Producers and Consumers.

The 'query features' Command is REQUIRED for all Producers. The 'query features' Command MAY include one or more Features as defined in Section 3.4.2.4. The 'query features' Command MAY include the "response_type": "complete" Argument. The 'query features' Command MUST NOT include any other Argument.

The 'query features' Command is REQUIRED for all Consumers. Consumers that receive and parse the 'query features':

• With any Argument other than "response_type": "complete"
  • MUST NOT respond with OK/200.
  • SHOULD respond with Bad Request/400.
  • MAY respond with the 500 status code.
• With no Target specifiers MUST respond with response code 200.
• With the "versions" Target specifier MUST respond with status 200 and populate the versions field with a list of the OpenC2 Language Versions supported by the consumer.
• With the "profiles" Target specifier MUST respond with status 200 and populate the profiles field with a list of profiles supported by the consumer.
• With the "pairs" Target specifier MUST respond with status 200 and populate the pairs field with a list of action target pairs that define valid commands supported by the consumer.
• With the "rate_limit" Target specifier populated:
  • SHOULD respond with status 200 and populate the rate_limit field with the maximum number of Commands per minute that the Consumer may support.
  • MAY respond with status 200 and with the rate_limit field unpopulated.

4.2 Examples of 'query features' Commands and Responses

This section is non-normative.

This sub-section provides examples of 'query features' Commands and Responses. The examples provided in this section are for illustrative purposes only and are not to be interpreted as operational examples for actual systems.

4.2.1 Sample 1

There are no features specified in the 'query features' Command. A simple "OK" Response message is returned.

Command:

{
    "action": "query",
    "target": {
        "features": []
    }
}

Response:

{
    "status": 200
}

4.2.2 Sample 2

There are several features requested in the 'query features' Command. All requested features can be returned in a single Response message.

Command:

{
    "action": "query",
    "target": {
        "features": ["versions", "profiles", "rate_limit"]
    }
}

Response:

{
    "status": 200,
    "versions": ["1.0"],
    "profiles": ["slpf", "x-lock"],
    "rate_limit": 30
}

5 Conformance

This content in this section is normative.

5.1 Conformance Clause 1: Command

A conformant Command

• 5.1-1 MUST be structured in accordance with Section 3.3.1.
• 5.1-2 MUST include exactly one action property defined in accordance with Section 3.3.1.1.
• 5.1-3 MUST include exactly one target property defined in accordance with Section 3.3.1.2 or exactly one imported target property defined in accordance with Section 3.1.5.
• 5.1-4 MUST include zero or one actuator property defined in accordance with Section 3.3.1.3 or zero or one imported actuator property defined in accordance with Section 3.1.5.
• 5.1-5 MUST include zero or one args property defined in accordance with Section 3.3.1.4 or zero or one imported args property defined in accordance with Section 3.1.5.

5.2 Conformance Clause 2: Response

A conformant Response

• 5.2-1 MUST be structured in accordance with Section 3.3.2.
• 5.2-2 MUST include exactly one status property defined in accordance with Section 3.3.2.1.

5.3 Conformance Clause 3: Producer

A conformant Producer

• 5.3-1 MUST issue Commands and process Responses in accordance with Section 4.
• 5.3-2 MUST implement JSON serialization of generated Commands in accordance with [RFC7493].

5.4 Conformance Clause 4: Consumer

A conformant Consumer

• 5.4-1 MUST process Commands and issue Responses in accordance with Section 4.
• 5.4-2 MUST implement JSON serialization of generated Responses in accordance with [RFC7493].

Annex A. Examples

The content in this section is non-normative.

A.1 Example 1

This example shows the elements of an OpenC2 Message containing an OpenC2 Command. The content of the Message is the de-serialized Command structure in whatever format is used by the implementation, independent of the transfer protocol and serialization format used to transport the Message.

The request_id in this example is a 64 bit binary value which can be displayed in many ways, including hex: 'd937 fca9 2b64 4e71', base64url: '2Tf8qStkTnE', and Python byte string - ASCII characters with hex escapes (\xNN) for non-ASCII bytes: b'\xd97\xfc\xa9+dNq'. If Producers generate numeric or alphanumeric request_ids, they are still binary values and are limited to 128 bits, e.g.,: hex: '6670 2d31 3932 352d 3337 3632 3864 3663', base64url: 'ZnAtMTkyNS0zNzYyOGQ2Yw', byte string: b'fp-1925-37628d6c'.

The created element is a Date-Time value of milliseconds since the epoch. The example 1539355895215 may be displayed as '12 October 2018 14:51:35 UTC'.

This example, illustrating an internal representation of a Message, is non-normative. Other programming languages (e.g., Java, Javascript, C, Erlang) have different representations of literal values. There are no interoperability considerations or conformance requirements for how Message elements are represented internally within an implementation. Only the serialized values of the Message elements embedded within a protocol is relevant to interoperability.

A.1.1 Example 1: Command

content-type: 'application/openc2'
msg_type: 'request'
request_id: b'\xd97\xfc\xa9+dNq'
from: 'nocc-3497'
to: ['#filter-devices']
created: 1539355895215
content: {'action': 'query', 'target': {'features': ['versions', 'profiles']}}

A.1.2 Example 1: Response

The Response Message contains a status code, a content-type that is normally the same as the request content type, a msg_type of 'response', and the Response content. The request_id from the Command Message, if present, is returned unchanged in the Response Message. The "to" element of the Response normally echoes the "from" element of the Command Message, but the "from" element of the Response is the Actuator's identifier regardless of whether the Command was sent to an individual actuator or a group. The "created" element, if present, contains the creation time of the Response.

A responder could potentially return non-openc2 content, such as a PDF report or an HTML document, in response to a Command. No Actuator profiles currently define response content types other than openc2.

status: 200
content-type: 'application/openc2'
msg_type: 'response'
request_id: b'\xd97\xfc\xa9+dNq'
from: 'pf72394'
to: ['nocc-3497']
created: 1539355898000
content: {'status': 200, 'versions': ['1.3'], 'profiles': ['slpf']}

A.2 Example 2

This example is for a transport where the header information is outside the JSON (e.g., HTTPS API) and only body is in JSON.

A.2.1 Example 2: Command

{
    "action": "query",
    "target": {
        "properties": ["battery"]
    },
    "actuator": {
        "x-esm": {
            "asset_id": "TGEadsasd"
        }
    }
}

A.2.2 Example 2: Response

{
    "status": 200,
    "results": {
        "battery": {
            "capacity": 0.577216,
            "charged_at": 1547506988,
            "status": 12,
            "mode": {
                "output": high",
                "supported": [ "high", "trickle" ]
            }
            "visible_on_display": true
        },
        "asset_id": "TGEadsasd"
    }
}

A.3 Example 3

A.3.1 Example 3: Command

{
    "action": "query",
    "target": {
        "features": ["versions", "profiles"]
    }
}

A.3.2 Example 3: Response

{
    "status_text": "ACME Corp Internet Toaster",
    "versions": ["1.0"],
    "profiles": ["slpf", "x-acme"]
}

Annex B. Acronyms

Annex C. Revision History

The content in this section is non-normative.

Annex D. Acknowledgments

The content in this section is non-normative.

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

OpenC2 TC Members: