pubhist.html

---
layout: page
title: Publication History
pageHeading: Publication History
permalink: /pubhist.html
---


<main id="main">
  <section>
    <div class="container" id="introduction">
      <div>
        <div class="section-title">
          <h2>Overview</h2>
        </div>
        <p>
          This page provides the publication history of OpenC2 TC work products,
          with links to the most recent “approved” version as well as the
          current work-in-progress for the product. An entry is provided for
          each work product. For each document the reference includes the full
          title, a brief descriptions, and a table with dates and links for the
          approved versions. with information for “approved” versions. Table
          contents are ordered in reverse chronological order, newest version
          first. An explanation of the table details can be found <a
          href="#table-details">at the end of the page</a>
        </p>
        <p>
          The following documents histories are provided on this page. For
          information regarding TC work products that have not yet reached the
          Committee Specification Draft (CSD) level, consult the list of GitHub
          repositories on the <a href="{{ site.baseurl }}/specifications.html">Specifications</a> page.
        </p>
        <table>
          <thead>
            <tr>
              <th><strong>Overarching Documents</strong></th>
              <th><strong>Actuator Profiles</strong></th>
              <th><strong>Transfer Specifications</strong></th>
              <th><strong>Informative Work</strong></th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td><a href="#arch-spec">Architecture Specification</a></td>
              <td><a href="#slpf-AP">Stateless Packet Filtering</a></td>
              <td><a href="#mqtt-ts">MQTT</a></td>
              <td><a href="#jadn-im">Information Modeling with JADN CN</a></td>
            </tr>
            <tr>
              <td><a href="#lang-spec">Language Specification</a></td>
              <td><a href="#PF-AP">Packet Filtering AP</a></td>
              <td><a href="#https-ts">HTTPS</a></td>
              <td><a href="#cn-apdev">Actuator Profile Development Process CN</a></td>
            </tr>
            <tr>
              <td><a href="#jadn-spec">JSON Abstract Data Notation (JADN)</a></td>
              <td><a href="#TH-AP">Threat Hunting AP</a></td>
              <td></td>
              <td></td>
            </tr>
          </tbody>
          </table>
          <br><br>
      </div>
    </div>


<!--- Tables are imported from external Markdown files to simplify maintenance -->
<!--- Tables use HTML links to force opening in new tabs / windows  -->

<!--- Section for the Architecture Specification -->

<div class="container" id="arch-spec">
  <div class="section-title">
    <h2>OpenC2 Architecture Specification</h2>
    <p class="section-subtitle">
      <i>Cyber attacks 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. The Architecture
      Specification describes the abstract architecture of OpenC2
      to define a common understanding of the messages and
      interactions for all bindings and serializations.
      </i>
    </p>
  </div>

  {% capture t1 %}{% include_relative pub-histories/arch-hist-table.md %}{% endcapture %}{{ t1 | markdownify }}  

  <br><br>
</div>



<!--- Section for the Language Specification -->

    <div class="container" id="lang-spec">
      <div class="section-title">
        <h2>Open Command and Control (OpenC2) Language Specification</h2>
        <p class="section-subtitle">
          <i
            >The Language Specification is an overarching OpenC2 document, which
            defines the basic conventions of the language, the set of available
            actions, and the base set of targets to which actions can be
            applied. This 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.
          </i>
        </p>
      </div>

      {% capture t2 %}{% include_relative pub-histories/lang-hist-table.md %}{% endcapture %}{{ t2 | markdownify }}  

      <br><br>
    </div>



<!--- Section for the JADN Specification -->

<div class="container" id="jadn-spec">
      <div class="section-title">
        <h2>Specification for JSON Abstract Data Notation (JADN)</h2>
        <p class="section-subtitle">
          <i>JSON Abstract Data Notation (JADN) is a UML-based
          information modeling language that defines data
          structure independently of data format. Information
          models are used to define and generate physical data
          models, validate information instances, and enable
          lossless translation across data formats. A JADN
          specification consists of two parts: type definitions
          that comprise the information model, and serialization
          rules that define how information instances are
          represented as data. The information model is itself an
          information instance that can be serialized and
          transferred between applications. The model is
          documented using a compact and expressive interface
          definition language, property tables, or entity
          relationship diagrams, easing integration with existing
          design processes and architecture tools.
          </i>
        </p>
      </div>

      {% capture t9 %}{% include_relative pub-histories/jadn-hist-table.md %}{% endcapture %}{{ t9 | markdownify }}  

      <br><br>
    </div>


<!--- Section for the Stateless Packet Filtering (SLPF) AP -->

    <div class="container" id="slpf-AP">
      <div id="splf-ap-title" class="section-title">
        <h2>OpenC2 Actuator Profile for Stateless Packet Filtering (SLPF)</h2>
        <p class="section-subtitle">
          <i
            >OpenC2 Actuator Profiles specify the subset of the OpenC2 language
            relevant in the context of specific actuator functions. This
            actuator profile specifies the set of actions, targets, specifiers,
            and command arguments that integrates Stateless Packet Filtering
            functionality with the OpenC2 command set.
          </i>
        </p>
      </div>

      {% capture t3 %}{% include_relative pub-histories/slpf-hist-table.md %}{% endcapture %}{{ t3 | markdownify }}  

      <br><br>
    </div>


<!--- Section for the Packet Filter AP -->

    <div class="container" id='PF-AP'>
      <div class="section-title">
        <h2>OpenC2 Actuator Profile for Packet Filtering (PF)</h2>
        <p class="section-subtitle">
          <i >OpenC2 Actuator Profiles specify the subset of the
          OpenC2 language relevant in the context of specific
          actuator functions. Packet filtering is a cyber defense
          mechanism that denies or allows traffic based on static
          or dynamic properties of the traffic, such as address,
          port, protocol, etc. This profile defines the Actions,
          Targets, Specifiers and Options that are consistent
          with the Version 1.0 of the OpenC2 Language
          Specification in the context of packet filtering (PF).
          </i>
        </p>
      </div>

      {% capture t4 %}{% include_relative pub-histories/pf-hist-table.md %}{% endcapture %}{{ t4 | markdownify }}  

      <br><br>
    </div>


<!--- Section for the Threat Hunting AP -->

<div class="container" id='TH-AP'>
  <div class="section-title">
    <h2>OpenC2 Actuator Profile for Threat Hunting (TH)</h2>
    <p class="section-subtitle">
      <i >OpenC2 Actuator Profiles specify the subset of the OpenC2 language
      relevant in the context of specific actuator functions. This specification
      defines an actuator profile to automate management of cyber threat hunting
      activities using OpenC2. Threat hunting is the process of proactively and
      iteratively searching through networks and on endpoints to detect and
      isolate cyber observables that may indicate threats that evade existing
      security solutions. This actuator profile defines the OpenC2 Actions,
      Targets, Arguments, and Specifiers along with conformance clauses to
      enable the operation of OpenC2 Producers and Consumers in the context of
      cyber threat hunting. It covers the identification and invocation of
      stored hunting processes (e.g., “hunt flows”), passing of hunt parameters,
      and the expected type(s) and format(s) of information returned by hunting
      processes.</i>
    </p>
  </div>

  {% capture tTH %}{% include_relative pub-histories/th-hist-table.md %}{% endcapture %}{{ tTH | markdownify }}  

  <br><br>
</div>


<!--- Section for the MQTT Transfer Specification -->

<div class="container" id="mqtt-ts">
  <div class="section-title">
    <h2>Specification for Transfer of OpenC2 Messages via MQTT</h2>
    <p class="section-subtitle">
      <i >OpenC2 transfer specifications utilize existing
      protocols and standards to implement OpenC2 in specific
      environments. Message Queuing Telemetry Transport
      (MQTT) is a widely-used publish / subscribe (pub/sub)
      transfer protocol. This specification describes the use
      of MQTT Version 5.0 as a transfer mechanism for OpenC2
      messages.
      </i>
    </p>
  </div>

  {% capture t8 %}{% include_relative pub-histories/mqtt-hist-table.md %}{% endcapture %}{{ t8 | markdownify }}  

  <br><br>
</div>



<!--- Section for the HTTPS Transfer Specification -->

    <div class="container" id="https-ts">
      <div class="section-title">
        <h2>Specification for Transfer of OpenC2 Messages via HTTPS</h2>
        <p class="section-subtitle">
          <i
            >OpenC2 transfer specifications utilize existing protocols and
            standards to implement OpenC2 in specific environments. This
            specification describes the use of HTTP over TLS as a transfer
            mechanism for OpenC2 messages.
          </i>
        </p>
      </div>

      {% capture t7 %}{% include_relative pub-histories/https-hist-table.md %}{% endcapture %}{{ t7 | markdownify }}  

      <br><br>
    </div>



<!--- Section for the JADN Information Modeling CN -->

<div class="container" id="jadn-im">
      <div class="section-title">
        <h2>Information Modeling With JADN</h2>
        <p class="section-subtitle">
          <i>Information models (IMs) are used to define and
          generate physical data models, validate information
          instances, and enable lossless translation across
          data formats. JSON Abstract Data Notation (JADN) is a
          UML-based information modeling language that defines
          data structure independently of data format. This
          Committee Note describes the use of IMs, explains how
          to construct IMs using JADN, and contrasts IMs with
          other modeling approaches, such as
          Entity-Relationship models for databases, and
          knowledge models / ontologies.
          </i>
        </p>
      </div>

      {% capture t10 %}{% include_relative pub-histories/jadn-im-cn-hist-table.md %}{% endcapture %}{{ t10 | markdownify }}  

      <br><br>
    </div>


<!--- Section for the Actuator Profile Development CN -->

<div class="container" id='cn-apdev'>
  <div class="section-title">
    <h2>OpenC2 Actuator Profile Development Process Version 1.0</h2>
    <p class="section-subtitle">
      <i> OpenC2 Actuator Profiles (APs) specify the subset
      of the OpenC2 language relevant in the context of specific actuator
      functions. A profile refines the meaning of language elements used to
      perform the actuator function, and often defines additional elements that
      are relevant and/or unique to that function. This Committee Note describes
      the TC’s process for using the JSON Abstract Data Notation (JADN)
      information modeling language in the development of APs, resulting in a
      rigorous schema for an AP properly integrated with the base OpenC2
      language.
      </i>
    </p>
  </div>

  {% capture t6 %}{% include_relative pub-histories/ap-dev-cn-hist-table.md %}{% endcapture %}{{ t6 | markdownify }}  

  <br><br>
</div>




    <div class="container" id="table-details">
      <div class="section-title">
        <h2>Explanation of History Table Details</h2>
      </div>
        <ul>
          <li>
            <b>Version</b>
          </li>
          <li><b>Approval Level</b> -- A link to a specific
          version of the document. The first row in each table is
          a link to the current working version on GitHub,
          reflecting either the latest change to in-progress
          content, or the starting point for future changes,
          depending on the document's current development status.
          Subsequent rows are identified by approval level, which
          is one of:
            <ul>
              <li>
                <em>OASIS Standard</em> (OS) -- an official OASIS publication
                approved by the OASIS membership (none of the TC’s work products
                have yet reached this level).
              </li>
              <li>
                <em>Committee Specification</em> (CS) -- an official OASIS
                publication approved by a special majority vote of the TC as a
                complete and usable document.
              </li>
              <li>
                <em>Committee Specification Draft</em> (CSD) -- an official OASIS
                publication approved by a majority vote of the TC, a mostly-stable
                and usable but unfinished specification.
              </li>
              <li>
                <em>Committee Specification</em> / Public Review Draft (CS/PRD) --
                an official OASIS publication approved by a majority vote of the
                TC and specified for release for public review (this terminology
                only applies to the TC’s original three specifications).
              </li>
              <li>
                <em>Working Draft (WD)</em> -- a snapshot version of a
                work-in-progress document posted to OASIS by the work product
                editors NOTE: for OS-, CS-, and CSD-level documents this item will
                be a link to the published HTML version of the work product; for
                WD-level documents the public link to the WD package in the TC’s
                document repository will be used.
              </li>
            </ul>
          </li>
          <li>
            <b>Publication Date</b> -- the date when this version / approval
            level document was published. For an OS, CS, or CSD this will be the
            date contained in the published HTML version of the document.
            Unapproved WDs will instead have the date the WD package was
            uploaded to OASIS.
          </li>
        </ul>
    </div>
  </section>
</main>

<script>

  // experiment to compensate for page header when jumping to anchors
  // code from https://www.geeksforgeeks.org/offsetting-an-anchor-to-adjust-for-fixed-header/?ref=gcse_ind
  // this is their option 2 for addressing this visual glitch
  
    // Get the header element
    let header = document.querySelector('header');
  
    // Get the height of the header
    let headerHeight = header.offsetHeight;
    document.querySelectorAll('a[href^="#"]')
    .forEach(function (anchor) {
        anchor.addEventListener('click', 
        function (event) {
            event.preventDefault();
  
            // Get the target element that 
            // the anchor link points to
            let target = document.querySelector(
                this.getAttribute('href')
            );
            
            let targetPosition = target
                .getBoundingClientRect().top - headerHeight;
  
            window.scrollTo({
                top: targetPosition + window.pageYOffset,
                behavior: 'smooth'
            });
        });
    });
  </script>