SPIF is a XML schema, that provides a high level representation of a security labelling policy in a generic and open fashion.

An XML document that adheres to this schema can describe a specific security labelling policy which can be transformed into a wide variety of other formats including text formats (using stylesheets) and other, more complex formats (such as SDN.801) using specific tools.

This document can then be used to consistently configure the security labelling policy in each of the products that are being used within the organisation.

This site contains the schema definition, numerous examples representing complex, real-world, security labelling policies, and some example stylesheets that show how the security labelling policy can be transformed. It also contains a list of vendors who have chosen to adopt the schema within their product set, either as an interchange format or natively.


The current version of the schema is 2.1. It is expected that the schema will evolve as it is used to support a wide variety of security labelling policies.

Schema Details

The details of the schema are:

Version 2.0 of the the schema is available at:

Version 1.0 of the the schema is available at:

Simple Policy

With this schema, a very simple policy may look like:

<?xml version="1.0" encoding="UTF-8"?>
<sp:SPIF xmlns:spif=""
creationDate="2005021910000Z" rbacId="2.16.840."
originatorDN="o=smhs ltd,c=gb" privilegeId="2.16.840."
<spif:securityPolicyId id="" name="Simple"/>
<spif:securityClassification name="Unclassified" lacv="1" hierarchy="1"/>
<spif:securityClassification name="Restricted" lacv="2" hierarchy="2"/>
<spif:securityClassification name="Confidential" lacv="3" hierarchy="3"/>
<spif:securityClassification name="Secret" lacv="4" hierarchy="4"/>
<spif:securityClassification name="Top Secret" lacv="5" hierarchy="5"/>

Additions over SDN.801

The core schema is derived from SDN.801, and SDN.801c provides a reference specification for the semantics of the SPIF. The XML definitions are aligned to SDN.801c, and so it is straightforward to understand the core specification.

A number of additions have been made to support both more varied security labelling policies and the ability or vendors to embed their own proprietary information within SPIF. These features include:

  • colour – associating a colour with a classification
  • privacy marks – a valid part of a security label but not used within the access control model of SDN.801 and consequently not within the SPIF
  • extensions – a generic extension element into which vendors can place their own schema elements
  • string category values – commonly used in some policies
  • free-form text entry – again used for category values, e.g. “releasable to ______”

In addition, arbitrary attributes can be associated within any of the standard XMLSPIF schema elements. This allows a vendor to include additional information that is not included in the core schema.

For example, in this extended version of the NATO security labelling policy:

  • an “id” element has been added to selected elements in the SPIF from the standard “xml” namespace, which allows the elements to be uniquely identified
  • some additional vendor extensions have been used to include information as to where and how the security policy should be deployed

Use of these extensions should be clear from the XML schema definition.

A more formal semantic specification of these extensions is desirable.

Future Additions

It is fully expected that the XML schema will be enhanced to support new features required by some security labelling policies, or generally thought useful by the community. Whilst the base schema contains a number of extension mechanisms, vendors using this schema and finding it lacking are strongly recommended to contact this group with details of their requirements before defining their own proprietary extensions. Useful features can then be accommodated into the base schema, with a consequent benefit for the whole community.

These changes will be published as new versions of the schema. Older versions will continue to be published on the site. Changes will only be made where there is consensus to make the changes between the supporters of