The identity registry needs to be structured in accordance with actor characteristics. The role of a certain actors in the Sea Traffic Management ecosystem forms the basis of such characterization (as e.g. port, port actor, etc.) and then further appropriate specialisations.

The possibility to connect the Identity registry to existing catalogue services providing actor registries (such as managed by IMPA, FONASBA, IHMA etc.).

The identity registry constitute one of the core enablers in the information sharing environment. High accessability is therefore required enabled by a good technical infrastructure.

The identity registry need to be kept up-to-date and have such a status that it becomes used. This requires services for provisioning and consuming actor identities. To identify and qualify a certain actor as an identity in the identity registry existing registries, as managed by diverse associations, forms an important basis.

The establishment of SeaSWIM has to address the creation of an appropriate organisational structure for the implementation and operation of SeaSWIM function. Careful consideration must be given regarding the SeaSWIM organisation’s mission, actions, structure and performance. All the indicated aspects are important for the organisation to be viewed as trustworthy and reliable, which contribute to it being accorded legitimacy for it to be trusted by businesses and authority.

The specification of SeaSWIM services, core and STM-compliant services, builds upon a standardized service specification language. The language constitutes the ontology of how to describe a service.

In order to allow changes of the service specification language and keep the language up-to-date, there has to be processes/procedures for how to change the service specification language

Services constitute the core of the service-oriented-architecture applied in SeaSWIM allowing possible [peer-to-peer] interactions between information providers and information consumers. In order to allow for the provisioning and consumption of services, as carriers of the information being exchanged/shared, processes/procedures of how to publish and discover services need to be defined (as e.g. how does the process look for including a service in the service registry and for discovering a particular service).

The establishment of an implementation framework supporting maritime actors to integrate to the Maritime Service infrastructure for provisioning and/or consuming data leveraged by SeaSWIM.

In order to drive continual quality development and continuous improvement of services there will be tools associated with STM that allow for validating/assessing the used services. This both concern the possibility for �letting the crowd� give their remarks on used services as well as statistics for usage. The result of the validation is an important input for the process of improving existing services (service lifecycle management) by the service provider.

The description of any SeaSwim governed information service, covering technical, logical, description of requirements, service level and other delimiting characteristics.

The commonly accepted information model describing all used information objects of STM, the parts of which the object consists, and the elements specified in those parts. A logical model, not a technical.

A generic functionality in SeaSwim enabling the discovery of a service as the carrier of the information that is requested. E.g a port will be able through its SeaSwim connector, subscribe for VoyageID�s with planned destination to the port, without knowing anything about logical or physical address where the information can be retrieved. That information is provided by the service discovery mechanism.

An univeseral service registry provides a list of all services possible to access when certain criteria are met � such as e.g. geographical region.

In order to access information services there is a need for SeaSWIM connectors. The allowance of accessing these do however need to be done by (electronically) ask the information provider whether the information service is allowed to be accessed by checking the nomination schema. For each connector such access verification module need to be implemented according to the standards for access management.