SWIM TI Foundation (v0.

2)
SWIM TI Introduction
The SWIM technical infrastructure (TI) enables the implementation of interfaces between systems,
providing technical capabilities for secure, high performing and reliable exchange of information.

Figure 5.1: SWIM TI Overview

1
The SWIM TI is a collection of software and hardware used to enable the provision of information
services. Applications consume information services via a SWIM TI that enables the exchange of
information over an IP network. Both the service provider (responsible for the information service),
and the service consumer (responsible for the consuming application) are responsible for the
implementation of their own infrastructure.

The SWIM TI enables technical interoperability based on interfaces that use industry standards, the
SWIM TI interface bindings, which specify the protocols used for the exchange of information
between systems. The SWIM TI provides technical capabilities that are adapted to support various
information exchange needs, including different type of communication needs, Ground/Ground or
Air/Ground communication, different type of Message Exchange Patterns, such as Publish/Subscribe
or Request/Reply (cf. Annex 1 - Message Exchange Patterns), and different service levels with
different availability requirements.

SWIM TI Context
From a conformance point of view, a SWIM TI is a technical infrastructure that satisfies the
requirements of a standardised SWIM TI Specification. At the time of this writing:

 The EUROCONTROL SWIM TI YP Specification is the only available SWIM standard for TI in
Europe.

 Additional TI specifications and standardization activities have been identified for 1) specific
common infrastructure components such as the PKI, as well as for 2) specific information
exchange use cases such as ATC to ATC flight information exchange (known as the blue
profile).

EUROCONTROL SWIM TI Yellow Profile Specification

The EUROCONTROL SWIM TI Yellow Profile Specification (YP Spec) is a standard that provides
requirements for general purpose SWIM TI capabilities based on mainstream technologies. It
addresses a wide spectrum of information exchange needs in all the various ATM information
domains (i.e. Aeronautical, Meteorological, Flight and Flow)

SWIM Common Infrastructure Components

SWIM Common Infrastructure Components provide specialised TI capabilities that require a common
or coordinated deployment by all stakeholders. These includes:

 Public Key Infrastructure. It enables the secure exchange of information by enabling the
implementation of public-key encryption and digital signature.

Additional TI Profiles
Being the YP Spec a general-purpose exchange specification, it is acknowledged 1 that other more
specialised use cases will need to be addressed specifically, requiring dedicated specification and
standardization activities:

 Blue TI profile, denominates all TI requirements that are focused on the specific
requirements that enable the exchange of flight information between ATCs.

1As stated in the rolling development plan of the European ATM Standards Coordination Group, and the
deployment program managed by the SESAR Deployment Manager.

2
SWIM TI Decomposition
The SWIM TI is characterized by a set of technical capabilities and interface bindings that together
enable the actual exchange of information between systems.

 SWIM TI capabilities. These are divided in functional and non-functional capabilities.

o SWIM TI functional capabilities are infrastructure functions (e.g. protocol

transformation, encryption), not specific to a particular business area or information
domain, that enable information to be exchanged between systems.

o SWIM TI non-functional capabilities are characteristics of the SWIM TI that contribute

to the quality of services. (E.g. the availability of the SWIM TI has direct impact on
the availability of the service it supports). While the TI functional capabilities are
executable (e.g. encryption), the non-functional capabilities are a consequence of
functional capabilities (e.g. confidentiality) or other contributing elements such as
the deployment architecture (e.g. a redundant deployment contributes to
availability).

 SWIM TI interface bindings. An interface binding is a set of protocols and their configuration
that defines how to interoperate technically with a system. In relation with the SWIM TI
functional capabilities, an interface binding is a type of connectivity used by the messaging
capabilities of the TI to interoperate with another system. Interface bindings play a critical
role in enabling technical interoperability in SWIM, and as such, are highlighted as specific
components of the TI.

SWIM TI Functional Capabilities

The functional capabilities of the SWIM TI can be grouped in three categories:

 Messaging Capabilities: Enable the actual exchange of information using various access
methods (e.g., publish/subscribe, request/reply).

 Security Capabilities: Enable the secured exchange of information, including, but not limited
to identity access management, digital certificates, encryption, etc.

 TI Management Capabilities: Enable to monitor the technical infrastructure for fault and
performance, ensuring reliable and high performing execution of the information exchanges.

The functional capabilities (i.e. functions) described in this section are common features widely
supported by mainstream commercial of the shelf (COTS) systems and services.

Messaging Functionality
A ‘message’2 is the unit of exchange between providers and consumers. Messaging is therefore the
most important capability of the SWIM TI, as it enables the actual exchange of information between
systems. It includes:

2The term message is used in this document in relation to a unit of exchange between systems that
communicate via information services. Although there are similarities, no direct comparison should be made
with the term message used in other ICAO documents (e.g. CPDLC message, AMHS Message).

3
  Connectivity: Enabling the exchange of messages over the network according to well-defined
protocols. This function instantiates interface binding specifications (set of protocols) into
what is commonly known as adaptors or connectors, in order to exchange information with
other systems. Connectivity to a system is performed via a system endpoint that is an
addressable system resource.

 Message Distribution: Enabling the asynchronous processing of messages. This function uses
information exchange resources (i.e. queues, topics) to decouple the various TI functions
involved in the processing of messages (connectivity, validation...) based on configurable
distribution rules (e.g. content/context based routing). The components that provide this
kind of functionality are commonly referred as message brokers.

 Validation: Enabling the validation of messages to ensure they are syntactically well formed,
and according to predefined schemas.

 Policy Enforcement: Enforcing the application of messaging policies (e.g. routing and filtering
policies, reliability policy)

 Data Transformation: Enabling the transformation from one data formats another.

 Orchestration: Enabling the coordination or integration of several services, and exposing

them as a single service.

Security Functionality
As supporting functions to messaging, the security capabilities of the SWIM TI are of high importance
as they enable a trusted exchange of information. These capabilities are:

 Identity Management: Enabling the management of identities (e.g. identity creation, identity
validation, federated identity retrieval).

 Authentication: Enabling the verification of the validity of credentials and their

correspondence with an identity.

 Authorization: Enabling the management of permissions associated to identities and based

on these the enforcement of access control to the TI services and resources.

 Cryptography: Providing secure functions for encryption, decryption and hashing.

 Key Management: Enabling the secure management of cryptographic keys.

 Audit: Recording contextual information related to security events.

 Security Monitoring: Enabling monitoring, event handling and reporting of security related
events.

 Policy Enforcement: Enforcing the application of security policies.

4
  Boundary Protection: Providing capabilities to ensure the protection of the infrastructure
against external threats (e.g. firewall, rate limit management).

TI Management Functionality
As supporting functions to messaging, the TI management capabilities ensure the reliable and
performant exchange of information. These capabilities are:

 Resource Monitoring: Enabling the monitoring of the TI resources (e.g. processors,

memory).

 Service Monitoring: Enabling the monitoring of the TI services provided (e.g. status, uptime,
and response times).

 Alerting: Enabling management alerts related to the monitoring of infrastructure related

events (e.g. threshold management).

 Logging: Enabling the recording of system events with the relevant contextual information.

 Replication: Enabling the management of system and data replication, enabling different
degrees of fault tolerance and failover.

 Persistence: Enabling the management of data persistence in the TI.

 Load Balancing: Enabling the management of load distribution across the TI resources,
enabling horizontal scaling and high availability.

SWIM TI Non-Functional Capabilities

These are qualities of the SWIM TI that directly contribute to the quality of SWIM Services that use
the SWIM TI. While the TI functional capabilities are executable (e.g. encryption), the SWIM TI non-
functional capabilities addressed in this section are a consequence of using functional capabilities
(e.g. confidentiality is the result of using encryption). The non-functional capabilities of the SWIM TI
are based on ISO 25010 and include:

Performance efficiency Qualities

These are characteristics of the SWIM TI related to its performance. They include:

 Time behaviour, including response time and latency can be directly correlated to the
execution time of any of the functional capabilities of the TI. The deployment architecture
can also influence time behaviour as well as the SWIM TI replication and load balancing
functionalities.

 Capacity (e.g. messages per second) is also directly correlated to the execution time of any of
the functional capabilities of the TI. The deployment architecture can also influence capacity
as well as the SWIM TI replication and load balancing functionalities.

Security Non-Functional Qualities

These are characteristics of the SWIM TI related to security. They include:

5
  Confidentiality ensures that data is accessible only to those authorized to have access, and it
can be achieved as a combination of functional capabilities such as authentication,
authorization, or cryptography.

 Integrity prevents unauthorized access to, or modification of data, and it can be achieved as
a combination of functional capabilities such as authentication, authorization, or
cryptography.

 Non-repudiation ensures actions or events can be proven to have taken place, so that the
events or actions cannot be repudiated later and it can be achieved as a combination of
functional capabilities such as logging.

 Accountability ensures actions of an entity can be traced uniquely to the entity and it can be
achieved as a combination of functional capabilities such as logging, authentication, and
cryptography.

 Authenticity ensures the identity of a subject or resource can be proved to be the one
claimed and it can be achieved as a combination of functional capabilities such as
authentication, cryptography.

Reliability Qualities
These are characteristics of the SWIM TI related to reliability. They include:

 Availability enables the SWIM TI to remain operational and accessible when required for use.
The deployment architecture is of high importance to ensure availability as well as the SWIM
TI replication and load balancing functionalities.

 Recoverability enables the SWIM TI to recover the data directly affected by an interruption or
a failure and re-establish the desired state of the system. The deployment architecture is of
high importance to ensure availability as well as the SWIM TI persistence and replication
functionalities.

 Fault tolerance enables the SWIM TI to operate as intended despite the presence of
hardware or software faults. The deployment architecture is of high importance to ensure
fault tolerance as well as the SWIM TI persistence, load balancing and replication
functionalities.

SWIM TI Interface Bindings

Technical interoperability in SWIM is enabled by the TI, and more specifically by the SWIM TI
interface bindings. A binding is a consistent, self-contained grouping of interface requirements that
specify the protocols and configuration options to be used for the exchange of information between
systems.

There are two types of interface bindings to be distinguished based on their position in the TCP/IP
protocol suite3:

3The TCP/IP protocol suite is the conceptual model and set of communications protocols used on the Internet
and similar computer networks.

6
  Service Bindings. Specifying the technical interoperability of a service interface, including
protocols to interface with the applications. It corresponds with the application layer of the
TCP/IP protocol suite.

 Network Bindings. Specifying the protocols used by the SWIM TI to interface with the
network. SWIM relies on an IP network that is considered outside the scope of SWIM.
However, there are multiple protocols that can be used to interface with an IP network, and
those have a dependency with the service binding protocols. It is for that reason that the
interface with the network has to be described and agreed with the SWIM implementations
stating the concrete protocols that are used to interface with the network (network
bindings). The network bindings include protocols from the transport and network layers of
the TCP/IP protocol suite, equivalent to the scope of protocols considered in ICAO Doc 9896,
which identifies protocols for implementation of an ATN Network.

Figure 5.2.2: SWIM TI Interface Bindings

The number of potential technologies used for interface bindings and the number of information
flows to be realized create a risk of lacking uniformity which may negatively impact the cost of SWIM.
Furthermore, consuming from SWIM based on interface bindings selected by service providers, may
also trigger costs related to the implementation of consuming clients. For these reasons it is good
practice to consolidate the interface bindings around mainstream standards. This will then enable
cost benefits and other synergies among the SWIM stakeholders.

Figure 5.2.2: SWIM TI Interface Bindings Consolidation

7
SWIM TI Principles
The SWIM TI contributes to achieving the benefits of SWIM as described in ICAO Doc 20039 Vol I. To
do so, the SWIM TI respects certain principles:

 Managed technical diversity. Technological diversity is managed to minimize significant costs

related to the maintenance, expertise and integration between several different processing
environments, while allowing flexibility to accommodate new technologies and to select the
technologies that best meet the needs of the intended ATM businesses. This is the primary focus
of the SWIM TI Bindings.

 Standards Based Technical Interoperability. The SWIM TI is based on open standards that
promote technical interoperability.

 Established technology standards. The SWIM TI is based on widely deployed and widely
supported technology standards that enable economical and efficient implementation and
operation of information services.

 Modularity. The SWIM TI is modular, enabling the progressive deployment of different SWIM TI
functional capabilities and bindings, which will allow a fit for purpose, flexible and agile
implementation and evolution.

 Platform Independent interfaces. Interfaces between systems do not create dependencies

imposed by implementation platforms, such as operating system or programming language.

 SWIM TI Functional Capabilities supported by COTS. The SWIM TI functional capabilities are
common features of established COTS.

Annex 1 - Message Exchange Patterns

MEP Introduction
A message exchange pattern (MEP) identifies a repeatable sequence of messages exchanged
between two systems, specifying the order, direction and cardinality of these messages (e.g.
Request/Reply, Publish/Subscribe)

MEPs can only be understood in relation to a particular level of abstraction. Concretely, at TI protocol
level the MEPs are rather basic, however, more sophisticated MEPs can be to constructed based
these to enable the MEPs required at application level.

 Primitive MEPs are those that are directly related to the capability of the lower level
protocols of the SWIM TI. These protocols integrate the SWIM TI Service Interface Bindings.
(i.e. HTTP, AMQP). The primitive MEPs provided by the SWIM TI are:

o Fire and Forget

o Synchronous Request/Reply

 Application MEPs. These are the MEPs that describe the information interactions at
application level and that are implemented based on SWIM TI primitive MEPS. They include:

o Fire and Forget

8
 o Synchronous Request/Reply

o Asynchronous Request/Reply

o Fan-out

o Publish/Subscribe Push

o Publish/Subscribe Pull

MEP Definition
As defined by the W3C, a message exchange pattern (MEP) is a template, devoid of application
semantics, that describes a generic pattern for the exchange of messages between agents. It
describes relationships (e.g. temporal, causal, sequential, etc.) of multiple messages exchanged in
conformance with the pattern, as well as the normal and abnormal termination of any message
exchange conforming to the pattern.

MEP Characteristics
Message Exchange Patterns can be classified4 according to certain characteristics of the message
exchanges and the interaction between the systems’ involved.

Cardinality
Cardinality describes the number of systems participating in the exchange of messages. We
distinguish three classes of MEPs according to their cardinality:

 1-1: The Message Exchange Pattern involves the exchange of messages between two
systems.

 1-many: The Message Exchange Pattern involves the exchange of messages of one system
with one or more systems.

 Many-many: The Message Exchange Pattern involves the exchange of messages of multiple
systems with multiple systems.

Decoupling
Space
Space decoupling describes a MEP where the systems participating in a message exchange do not
need the knowledge of the network address of the other parts.
Time
Time decoupling characteristic describes a MEP where the systems participating in a message
exchange do not have to be simultaneously active for the message exchange to proceed.

4This classification and the resulting taxonomy are not unique and additional or different criteria can be used
to create a different taxonomy of MEPs.

9
Synchronisation5
Synchronisation decoupling characteristic describes a MEP where the systems participating in the
exchange are blocked while a message exchange occurs. According to this characteristic MEPs are
classified in two classes:

 Synchronous: The systems participating in the exchange of messages stay blocked while the
exchange occurs.

 Asynchronous: The systems participating in the exchange of messages do not stay blocked
while the exchange occurs.

Symmetry
Symmetry characteristic classifies MEPs taking into account the separation of roles placed into the
systems and the reversibility of the MEP:

 Asymmetric: In asymmetric MEPs the systems participating in the message exchange have
differentiated roles which cannot be exchanged. Asymmetric MEPs are most often used in
Client-Server architectures.

 Symmetric: Symmetric MEPs do not enforce a strict separation of roles on the systems
participating in the message exchange.

MEP Catalogue
This section provides a detailed view to the most common MEPs in the scope of the SWIM-TI, either
as primitive MEPs directly supported by the SWIM TI protocols, or compositions on top of these to
enable application MEPs.

Primitive MEPs (SWIM TI MEPs)

Primitive Message Exchange Patterns are defined in relation to the information exchange behaviour
of the protocols that compose the service interface bindings. These MEPs are used as basic building
blocks to build more sophisticated application MEPs. This MEPs are also referred in the document as
the SWIM TI MEPs for correlating directly to the protocols that are part of the SWIM TI.
Fire-and-Forget
Other names: “1-way”.

Definition:

Figure 1: Fire-and-Forget

5Synchronisation characteristic can be understood as a soft form of time decoupling.

10
 1. A message is sent from SWIM-TI A to SWIM-TI B.

Classification:

Cardinality 1-1
Space Decoupling NO
Time Decoupling NO
Synchronicity Asynchronous
Symmetry Symmetric

Synchronous Request/Reply
Other names: “Synchronous Request/Response”, “Request/Reply”, “Request/Response”.

Definition:

Figure 2: Request/Reply
1. A message (request) is sent from SWIM-TI B (Client) to SWIM-TI A (Server).

2. SWIM-TI B remains blocked awaiting for a response, SWIM-TI A remains blocked processing
the response.

3. A message (reply) is sent from SWIM-TI A to SWIM-TI B.

Classification:

Cardinality 1-1
Space Decoupling NO
Time Decoupling NO
Synchronicity Synchronous
Symmetry Asymmetric

Application MEPs
Application message exchange patterns are defined in relation to the information exchange
behaviour perceived at application level. These patterns relate to the message exchanges between
an application and an information service. These MEPs include and are using the primitive MEPs.

11
Fire-and-Forget
Definition:

1. A SWIM-TI Fire-and-Forget is sent from SWIM Enabled Application A to SWIM Enabled

Application B.

Classification:

Cardinality 1-1
Space Decoupling NO
Time Decoupling NO
Synchronicity Asynchronous
Symmetry Symmetric

Synchronous Request/Reply
Definition:

12
 Figure 3: Synchronous Request/Reply
A SWIM Enabled Application Synchronous Request/Reply can be implemented in two ways using
different SWIM-TI Primitive MEPs.

Alternative 1 (using SWIM-TI Synchronous Request/Reply):

1. A SWIM-TI Request is sent from SWIM Enabled Application B (Client) to SWIM-TI Enabled
Application A (Server).

2. SWIM-TI Enabled Application B remains blocked awaiting for a response, SWIM-TI Enabled
Application A remains blocked processing the response.

3. A SWIM-TI Reply is sent from SWIM-TI Enabled Application A to SWIM-TI Enabled Application
B.

Alternative 2 (using SWIM-TI Fire-and-Forget):

1. A SWIM-TI Fire-and-Forget is sent from SWIM Enabled Application B (Client) to SWIM-TI

Enabled Application A (Server).

2. SWIM-TI Enabled Application B remains blocked awaiting for a response, SWIM-TI Enabled
Application A remains blocked processing the response.

3. A SWIM-TI Fire-and-Forget is sent from SWIM-TI Enabled Application A to SWIM-TI Enabled

Application B.

Classification:

13
Cardinality 1-1
Space Decoupling NO
Time Decoupling NO
Synchronicity Synchronous
Symmetry Asymmetric

Asynchronous Request/Reply
Other names: “Asynchronous Request/Response”.

Definition:

Figure 4: Asynchronous Request/Reply

1. A Fire-and-Forget (request) is sent from SWIM Enabled Application B (Client) to SWIM
Enabled Application A (Server).

2. A Fire-and-Forget (reply) is sent from SWIM Enabled Application A to SWIM Enabled

Application B.

Classification:

Cardinality 1-1
Space Decoupling NO
Time Decoupling NO
Synchronicity Asynchronous
Symmetry Asymmetric

14
Fan-Out

Figure 5: Fan-Out
1. A Fire-and-Forget is delivered sequentially to multiple SWIM Enabled Applications.

Classification:

Cardinality 1-many
Space Decoupling NO
Time Decoupling NO
Synchronicity Asynchronous/Synchronous
Symmetry Asymmetric

Publish/Subscribe Push
Definition:

Figure 6: Publish/Subscribe Push

15
 1. A SWIM-TI Request/Reply is performed by one or more systems to declare interest in the
publications (subscribe) of System A. The SWIM-TI Request/Reply can be either Synchronous
or Asynchronous.

2. A SWIM-TI Fire-and-Forget6 is sent to each subscribed system when a new publication is

available containing the publication.

3. Step 2 is repeated whenever there are new publications available.

Classification:

Cardinality 1-many
Space Decoupling NO
Time Decoupling NO
Synchronicity Asynchronous
Symmetry Asymmetric

Publish/Subscribe Pull
Definition:

Figure 7: Publish/Subscribe Pull

6The Publication can also be implemented with a SWIM-TI Request/Reply MEP.

16
 1. A Request/Reply is performed by one or more systems to declare interest in the publications
of System A. The Request/Reply can be either Synchronous or Asynchronous.

2. A Fire-and-Forget7 is sent to each subscribed system when a new publication is available to

notify the subscribers of the existence of new publications.

3. Subscribed systems can perform a Request/Reply at their convenience to retrieve the

publication.

4. Steps 2 and 3 are repeated whenever new publications are available.

Cardinality 1-many
Space Decoupling NO
Time Decoupling NO
Synchronicity Synchronous/Asynchronous8
Symmetry Asymmetric

MEP Traceability to SWIM-TI YP Service Bindings

The following table summarizes the MEPs supported by the different SWIM-TI Yellow Profile Service
Bindings, based either o primitive MEPs or application MEPs.

Traceability of primitive MEPs

Fire-and-Forget Synchronous R/R

WS Light NO YES

WS SOAP NO YES

WS SOAP with Basic Message NO YES

Security
WS SOAP with Message NO YES
Security
WS SOAP with Federated NO YES
Security
AMQP Messaging YES NO

Traceability of application MEPs

Fire- Synchronous Asynchronous Fan- Publish/Subscribe Publish/Subscribe
and- R/R R/R Out Push Pull
Forget
WS Light NO YES NO NO NO YES

WS SOAP NO YES NO NO NO NO

WS SOAP NO YES NO NO NO NO
with Basic

7The notification can also be implemented using a Request/Reply MEP.

8Both implementations are possible.

17
Message
Security
WS SOAP NO YES NO NO NO NO
with
Message
Security
WS SOAP NO YES NO NO NO NO
with
Federated
Security
WS-N NO NO NO NO YES YES
SOAP
WS-N NO NO NO NO YES YES
SOAP with
Basic
Message
Security
WS-N NO NO NO NO YES YES
SOAP with
Message
Security
WS-N NO NO NO NO YES YES
SOAP with
Federated
Security
AMQP YES YES YES YES YES YES
Messagin
g

18
Annex 2 - SWIM TI YP Spec Traceability to Functional
Capabilities

Identifier Title Functional Block Function

SWIM-TIYP-0004 TCP Messaging Connectivity
SWIM-TIYP-0005 IPSec Messaging Connectivity
SWIM-TIYP-0006 IPv4 Messaging Connectivity
SWIM-TIYP-0007 IPv6 Messaging Connectivity
SWIM-TIYP-0008 TLS Messaging Connectivity
SWIM-TIYP-0009 HTTP Messaging Connectivity
SWIM-TIYP-0010 HTTP over TLS Messaging Connectivity
SWIM-TIYP-0011 SOAP 1.1 Messaging Connectivity
SWIM-TIYP-0012 SOAP 1.2 Messaging Connectivity
SWIM-TIYP-0013 MTOM Messaging Connectivity
SWIM-TIYP-0014 WSDL 1.1 Messaging Validation
SWIM-TIYP-0015 WSDL 2.0 Messaging Validation
SWIM-TIYP-0016 WS-I Messaging Validation
SWIM-TIYP-0017 WS-I Security Messaging Validation
SWIM-TIYP-0018 WS Notification Messaging Connectivity
IPv6 Node Connectivity
Messaging
SWIM-TIYP-0019 Requirements
SWIM-TIYP-0020 RFC 1122 Messaging Connectivity
SWIM-TIYP-0021 ICMP Messaging Connectivity
SWIM-TIYP-0022 RFC950 Messaging Connectivity
SWIM-TIYP-0023 WS Policy Messaging Policy Enforcement
WS Secure Authentication
Security
SWIM-TIYP-0024 Conversation
SWIM-TIYP-0025 WS Trust Security Identity Management
SWIM-TIYP-0026 WS Addressing Messaging Routing
SOAP Message Cryptography
Security
SWIM-TIYP-0027 Security
XML Message Cryptography
Security
SWIM-TIYP-0028 Encryption
SWIM-TIYP-0029 XML Messaging Mediation
WS Security Identity Management
Security
SWIM-TIYP-0030 Username Token
WS Security Identity Management
Security
SWIM-TIYP-0031 X509
XML Schema Validation
Messaging
SWIM-TIYP-0032 Validation
HTTP Content Mediation
Messaging
SWIM-TIYP-0033 Type Header
SWIM-TIYP-0034 WS Federation Security Identity Management
WS Reliable Connectivity
Messaging
SWIM-TIYP-0035 Messaging
SWIM-TIYP-0036 AMQP Messaging Connectivity

19
 Identifier Title Functional Block Function
AMQP Transport Authentication
Security Security
SWIM-TIYP-0037 Authentication
HTTP Mediation
Compression
Messaging
and Content
SWIM-TIYP-0038 Encoding Header
HTTP Header Mediation
Transfer Messaging
SWIM-TIYP-0039 Encoding
XML Digital Cryptography
Messaging
SWIM-TIYP-0040 Signature
Data Mediation
Messaging
SWIM-TIYP-0041 Compression
TLS Authentication
Security
SWIM-TIYP-0042 Authentication
HTTP Status Connectivity
Messaging
SWIM-TIYP-0043 Code Header
HTTP Reason Connectivity
Messaging
SWIM-TIYP-0044 Phrase Header
SWIM-TIYP-0045 HTTP POST Messaging Connectivity
SOAP Message Cryptography
Security
SWIM-TIYP-0046 Encryption
WS Security Identity Management
Security
SWIM-TIYP-0047 Token Profiles
AMQP Content Mediation
Messaging
SWIM-TIYP-0048 Type Header
AMQP Content Mediation
Messaging
SWIM-TIYP-0049 Encoding Header
TLS Authentication
Authentication Security
SWIM-TIYP-0050 Mechanisms
SWIM-TIYP-0051 SASL Security Authentication
SWIM-TIYP-0052 AMQP over TLS Messaging Connectivity
Common Time Authentication
Security
SWIM-TIYP-0053 Reference
Overload Boundary Protection
Security
SWIM-TIYP-0054 Protection
Encrypted Boundary Protection
Connections for
Remote Security
Administrative
SWIM-TIYP-0055 Access
Obscure Boundary Protection
Security
SWIM-TIYP-0056 Password Typing
Least Privileged Authorization
Security
SWIM-TIYP-0057 Principle Access
Automatic Boundary Protection
Sessions Security
SWIM-TIYP-0058 termination

20
 Identifier Title Functional Block Function
SWIM-TIYP-0059 Trusted Software Operation Procedure
Verification of Cryptography
Signed Messages Security
SWIM-TIYP-0060 Integrity
Message Validation
Protocol Messaging
SWIM-TIYP-0061 Validation
Message Payload Validation
Messaging
SWIM-TIYP-0062 Validation
Retrieval of Identity Management
X.509 Security
SWIM-TIYP-0063 Certificates
Validation of Identity Management
X.509 Security
SWIM-TIYP-0064 Certificates
Cryptographic Key Management
Security
SWIM-TIYP-0065 Algorithms
Strong Key Management
Security
SWIM-TIYP-0066 Passwords
Mandatory Authorization
Security
SWIM-TIYP-0067 Access Control
Detection of Security Monitoring
Failed
Security
Authentication
SWIM-TIYP-0068 Requests
Access Control Boundary Protection
Security
SWIM-TIYP-0069 Restriction
Satisfactory Authorization
Security
SWIM-TIYP-0070 Authorization
Cryptographic Key Management
Key Life-cycle Security
SWIM-TIYP-0071 Management
Inactive Session Boundary Protection
Security
SWIM-TIYP-0072 Termination
Non-recoverable Key Management
Password Security
SWIM-TIYP-0073 Storage
SWIM-TIYP-0074 Security Patching Operation Procedure
Vulnerability
Operation Procedure
SWIM-TIYP-0075 Assessment
Audit Data Audit
Security
SWIM-TIYP-0076 Reporting
Audit of identity Security Monitoring
Security
SWIM-TIYP-0077 validity events
Protection of Cryptography
information at Security
SWIM-TIYP-0078 rest
Protection of Audit
Audit Security
SWIM-TIYP-0079 Information

21
 Identifier Title Functional Block Function
Audit Data Audit
Security
SWIM-TIYP-0080 Remote Storage
Audit Data Audit
Management Security
SWIM-TIYP-0081 Reporting
Audit of Access Security Monitoring
Security
SWIM-TIYP-0082 Requests
Audit of Security Monitoring
Authentication Security
SWIM-TIYP-0083 Requests
Audit of Security Monitoring
Authorization Security
SWIM-TIYP-0084 Requests
Safe Mode Boundary Protection
Security
SWIM-TIYP-0085 Operation
Safe Mode Policy Enforcement
Security
SWIM-TIYP-0086 Description
CAVP approved Cryptography
Cryptographic Security
SWIM-TIYP-0087 Modules
Audit of Audit
Cryptographic Security
SWIM-TIYP-0088 Events
Configurable Authentication
Security
SWIM-TIYP-0089 Authentication
Audit of Audit
federated Security
SWIM-TIYP-0090 identity events
Security
Operation Procedure
SWIM-TIYP-0091 Assessment
Denial of Service Boundary Protection
Security
SWIM-TIYP-0092 Protection
Identity Validity Identity Management
Information Security
SWIM-TIYP-0093 Exchange
Role Based Authorization
Security
SWIM-TIYP-0094 Access Control
Attribute Based Authorization
Security
SWIM-TIYP-0095 Access Control
SWIM-TIYP-0096 Hardware Tokens Security Authentication
Content Based Message Distribution
Messaging
SWIM-TIYP-0097 Routing
Subject Based Message Distribution
Messaging
SWIM-TIYP-0098 Routing
Context Based Message Distribution
Messaging
SWIM-TIYP-0099 Routing
Automatic Message Distribution
Messaging
SWIM-TIYP-0100 Retries
Configurable Message Distribution
Messaging
SWIM-TIYP-0101 Routing

22
 Identifier Title Functional Block Function
Traffic Boundary Protection
Security
SWIM-TIYP-0102 Prioritisation
Hardware Resource Monitoring
TI Management
SWIM-TIYP-0103 Monitoring
Monitoring Alerting
TI Management
SWIM-TIYP-0104 Alerts
Service Service Monitoring
TI Management
SWIM-TIYP-0105 Monitoring
Persistent Persistence
Storage TI Management
SWIM-TIYP-0106 Recording
SWIM-TIYP-0107 Log Retention TI Management Persistence
Replication Replication
TI Management
SWIM-TIYP-0108 Transparency
Failure Replication
TI Management
SWIM-TIYP-0109 Transparency
Subscription Persistence
TI Management
SWIM-TIYP-0110 Persistency
Message Persistence
TI Management
SWIM-TIYP-0111 Persistency

23