ClassifyIt

Case Study · originally published 2017, revised 2026

Interoperability of Classification Markings: The international Classification Label for Access and Sharing Standard (iCLASS)

Your partners do not use the same classification policy nor classification tool you do — but you need to protect the information and documents from partners correctly. This case study sets out a standard to make classification markings interoperable between organisations, countries, and tools, without forcing anyone to change their internal policy. This is iCLASS, the international Classification Label for Access and Sharing Standard.

Objective

To provide guidance on achieving interoperability between entities that use different classification markings — whether those markings come from different national policies, different organisations, or different tools (or no tool at all, just a manual procedure).

The Problem

The problem is twofold:

• Different entities use different classification markings for equivalent levels of sensitivity.
• Different entities use different tools, or manual procedures, to apply those markings.

For background on how varied these national and organisational schemes are, see classified information systems on Wikipedia.

Considerations

Exchanging classified documents between entities requires an agreement on how information originating in one entity will be handled and protected by the other entity. Taken to its logical end, an entity exchanging classified documents with up to N partner entities would need N separate agreements AND, more critical, users must understand all N partners' classification schemes or markings. That doesn't scale, and it isn't workable in practice.

The alternative: one agreement, binding every entity's own classification marking to a single, shared, global protection profile. Each entity's local marking is linked to a global standardised classification label, which must be:

• Human-readable — so users can see, read, and understand the classification of a document at a glance, regardless of their organisation.
• In a common, well-understood language — English is the de-facto choice for this purpose.
• Machine-readable — so that classification assessment and protection devices (mail gateways, firewalls, DLP systems) can act on it automatically, not just show it to a human.

Marking vs. label — an important distinction: a classification marking is the legally and policy binding statement that a document is classified, with real handling procedures and mis-handling penalties applied to it. A label is purely a representation of that marking — a translation layer, not a new legal statement.

For example: Albania's marking "I Kufizuar" and Argentina's marking "Reservado" are both national markings for a RESTRICTED-level document. Neither marking changes; what changes is that both can now be represented by the same shared label: RESTRICTED.

Two further points follow from this:

• Entities with an existing classification marking and protection policy will, realistically, keep that marking. Interoperability is achieved by adding a label alongside it — not by replacing it. The label identifies both the originator and the classification of the document.
• Classification tools have two jobs here: enforcing the legal and policy binding correct classification format and spelling, and consistently generating the additional, standardised label — in both human-readable and technical (machine-readable) form, so that gateway and DLP infrastructure services can act on it automatically.

Conclusion: The international Classification Label for Access and Sharing Standard (iCLASS)

A international Classification Label for Access and Sharing Standard is an effective way to implement interoperability and mutual understanding of classification markings across entities. It is added to a classified document in both human-readable and technical form, as a name/value pair representing the classification level.

Human-readable syntax:

iCLASS// + Originator + //Value//

where Originator is a short code identifying the entity that classified the document — for example, a national ISO 3166 alpha-3 country code, or an organisation's own short identifier, such as EU, UNO or NATO.

The human-readable label is added to the classified document as a new line following the existing classification marking. The technical label is added as a document property named iCLASS, carrying the same value, so that it can be read automatically by mail gateways, firewalls, and other DLP infrastructure.

Examples — Human-Readable iCLASS Labels

Note: these are illustrative national-to-iCLASS mappings intended to demonstrate the labelling syntax, not an authoritative or legally binding equivalency table. Organisations implementing iCLASS in practice should confirm exact equivalencies against the relevant bilateral or multilateral security agreement (e.g. a NATO security agreement or national Information Security Management System policy) before relying on them operationally.

Extending iCLASS: Adding Releasability (REL)

A classification label on its own only answers "how sensitive is this document?" — it does not answer "who is this document allowed to be shared with?" For that, iCLASS can be extended with a releasability caveat, using the same short-code convention already established for the Originator field:

iCLASS// + Originator + //Value//REL: + Country1, Country2//

For example, a Belgian SECRET-level document releasable to Germany and the United States would carry the label:

iCLASS//BEL//SECRET//REL: DEU, USA//

This mirrors a releasability convention already in wide use by nations and organisations. iCLASS keeps the label familiar to anyone already used to reading classification banners, rather than introducing a new convention to learn.

A few implementation notes:

• The REL: field lists recipient entities using the same short-code system as the Originator field (ISO 3166 alpha-3 country codes, or organisational codes such as NATO, EU, UNO).
• Multiple recipients are comma-separated within the same REL: block, as shown above.
• A label with no REL: field present should be treated as releasable only within the originating entity by default — the absence of a releasability caveat is itself meaningful, not a gap to be interpreted permissively.

Technical Properties: The iCLASS JSON Structure

Alongside the human-readable label line, the iCLASS standard defines a corresponding machine-readable technical property, so that mail gateways, DLP systems, and other automated infrastructure can act on the classification without needing to parse the human-readable text. Under the property name iCLASS, a JSON object with org, class, and rel is represented as a minimum. For the example above, that property looks like this:

{
  "iCLASS": {
    "org": "BEL",
    "class": "S",
    "rel": ["DEU", "USA"]
  }
}

The classification field uses a short code rather than the full word, keeping the technical property compact:

This structure carries the same three elements as the human-readable label — originator, classification, and releasability — in a form that's trivial for infrastructure to parse and enforce automatically, without relying on OCR or text-matching against a visible marking. Implementations may add further fields beyond this minimum set as needed.

Implementation note: the property name, exact field names, and storage location (custom document property vs. a dedicated email header, for instance) shown above are illustrative. Please confirm and adjust these against ClassifyIt's actual technical implementation before publishing, so the article accurately reflects what the tool produces.

From iCLASS to ZTDF and ACP-240: upcoming improvements

When this case study was first written, a single standardised label solved the immediate problem: making one classification and release marking understandable to a partner using a different one. That problem hasn't gone away — but the surrounding technology has moved on.

Today, the same interoperability challenge is being addressed one level deeper: not just a human-and-machine-readable label attached to a document, but a structured set of attributes bound cryptographically to the data itself, as in the Zero Trust Data Format (ZTDF) and related work such as ACP-240. Where iCLASS proposed one name/value pair plus a releasability extension, ZTDF-style manifests support a fuller attribute set — releasability, originator, handling caveats, and more — enforced through attribute-based access control (ABAC) rather than relying solely on a human, or a gateway, reading a label correctly.

ZTDF, ACP-240 and ABAC are strong frameworks on paper, but still short on practical, real-world deployment experience. Planned next steps reflect that gap: a cryptographic integrity mechanism for the iCLASS JSON structure itself, and closer alignment with ZTDF/ACP-240 — with ABAC-style attribution as a core consideration to work through as these standards mature.