International Classification Label for Access and Sharing Standard

Background

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

Your partners do not use the same classification policy or classification tool you do, but you still need to protect their information and documents correctly. This standard sets out a common approach 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 from 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 critically, users would need to understand all N partners' classification schemes or markings. That does not scale, and it is not workable in practice.

The alternative is 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 such as mail gateways, firewalls, and 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 mishandling 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 legally 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.

iCLASS Standard

An 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, such as 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, or 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 is 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 guidance: the storage location and enforcement of the technical property depend on the implementing application. Consult the ClassifyIt guides for Office-specific behaviour.

Short iCLASS

There are cases where the iCLASS representation needs to be extremely short, for instance when representing a paragraph-level marking in a Word document. In this case, iCLASS defines the use of the classification code, as defined in the technical properties, followed by the release marking codes.

Example: (R-BEL,USA) means a RESTRICTED document or paragraph releasable to Belgium and the United States.

As release lists can be quite long, an extended short version is defined which indicates only that a releasability caveat exists. This is represented as (R-REL).