DomiSMP 5.0

Domain realm: The highest level, indicating the network’s business aim, like invoice exchange or health records exchange. Domain admins manage the overall structure, including authentication and authorisation methods (like PKI certificates), Participant Identifier types, and messages formats. In DomiSMP, domain admins are responsible for creating/deleting groups and assigning group admins.

Group realm: This mid-level layer consists of clusters of resources and users. It allows for the organisation of resources and users into manageable segments, particularly useful in large networks. Managed by group administrators, who can create and delete resources, but only the resource admins can edit resource documents. A group admin invites participants to the exchange network and assigns them resources where they can publish their connectivity data.

Resource realm: The most basic layer. It consists of resources and its subresources, both of which are documents describing participant connectivity capabilities. Resources are identified by unique IDs (usually matching the owner identifier) and can include formats like OASIS SMP 1.0, OASIS SMP 2.0 and CPPA3 CPP document. The resource type support is done by the DomiSMP extensions, which will be explained in one of the following user guides.

Each realm has its own set of permissions, determined by the user’s role within that realm. Here’s how permissions work across different realms:

Resource realm permissions: Control over specific documents. While resource admins can modify documents, group admins can invite participants but cannot alter documents directly.

Group realm permissions: Group admins manage resources within their group, including adding or removing resources and inviting new participants.

Domain realm permissions: Domain admins have the authority to create or delete groups within their domain, assign group admins, and set the framework for the network’s operational guidelines.

In essence, the DomiSMP’s structured approach to realms and permissions facilitates a clear and manageable way to organise, access, and administer resources within the network, ensuring secure and efficient data exchange.

In the diagram below, see the DomiSMP realms and the relations between them. DomiSMP is the host to the domains eHealth and Invoice. The groups in each domain are organised by EU Member States: Spain, Belgium, and Sweden organise the eHealth domain, while Belgium, France, Germany, and Austria organise the Invoice domain.

The DomiSMP has two application roles which will be described below. The application roles are used to define the user’s access and control levels in the DomiSMP application.

User: The default role assigned to all new users. Initially, it offers the same permissions as an unauthenticated user. Additional privileges can be granted by assigning further roles relevant to specific realms.

System admin: This role has comprehensive control over the DomiSMP system. A system admin can configure the system settings, register new document types and extensions, and set up authentication methods for different domains.

Memberships define a user’s access level within the various realms of DomiSMP. There are two types of memberships:

Direct membership: Users directly invited to a realm have direct access to it.

Indirect membership: Users gain access through membership in a sub-realm, extending their permissions to the parent realm.

Administrators manage memberships within their respective realms. They can invite new users and assign roles, determining what the user is allowed to do within that realm. The roles and their permissions are specific to the activities within the realms of domains, groups, and resources.

In this example, we demonstrate how to access a specific document from DomiSMP using the wget command. The document in question is an OASIS SMP 1.0 ServiceGroup document for a counterparty identified by urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088:test1234 within the Invoice domain.

To access this document from DomiSMP, whose instance is located at the URL http://localhost:8080/, and assuming invoice-domain is the domain code for the Invoice domain and smp-1 is the code for the OASIS SMP 1.0 ServiceGroup document type, use the following wget command:

However, if invoice-domain is the default domain for the DomiSMP instance and OASIS SMP 1.0 is the default document type within this domain, you can simplify the command by omitting the domain and document type codes:

This simplified command fetches the desired document based on the assumption that the default settings in DomiSMP match the required domain and document type for this retrieval.

Let’s say Party A wants to obtain a specific OASIS SMP 1.0 ServiceMetadata document for Party B. The document’s identifier is busdox-docid-qns::invoice-v01, and Party B’s identifier is urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088:test1234. This operation occurs within the Invoice domain of the DomiSMP, accessible at the URL http://localhost:8080/. For this domain, the SMP instance code is invoice-domain, and the document type code for OASIS SMP 1.0 ServiceGroup documents is smp-1. The subresource code is services.

To retrieve the document, use the following command:

However, if invoice-domain and OASIS SMP 1.0 are the default domain and document type within your DomiSMP instance, you can shorten your request. The shorter version does not require specifying the domain and document type codes:

This simplified command retrieves the same OASIS SMP 1.0 ServiceMetadata document for the specified resource identifier.

To accurately find a resource or subresource, DomiSMP uses location vector coordinates. Here’s how the process works:

DomiSMP begins by breaking down the URL into its path components. If the URL has more than five parameters, DomiSMP returns an error. Parameters are resolved one by one, to determine domain, resource type, etc. If any parameter cannot be resolved, the process halts and an error is thrown.

The process in presented in the diagram below:

DomiSMP provides flexible ways to locate resources and subresources through different HTTP path configurations. Depending on the information available and specific needs, you can use one of the following path options to access the desired document.

The path options accommodate various combinations of domain codes, resource types, resource identifiers and subresource identifiers.

Please note that for options 2, 3 and 4, two variants of the path parameters are possible: if the first path variant does not give results, DomiSMP tries with the second path variant.

Here’s a guide to using these path options.

Variants -SubResourceType mandatory

This section illustrates how to construct URLs for accessing resources in DomiSMP, using OASIS SMP 1.0 and OASIS SMP 2.0 documents as examples.

Note that your DomiSMP setup should have a default domain and resource type that match your intended document type (either OASIS SMP 1.0 or OASIS SMP 2.0) for these examples to apply directly.