ParIS
IDS Participant Information Service (IDS-ParIS)
Shortcut:
IDS-ParIS
Document History
Authors
Goals and Scope of the Document
This document describes minimum requested requirements to be met by the IDS Participant Information Service. The ParIS, technically similar to the IDS MetaData Broker, provides the interaction mechanisms to publish and query for attributes of IDS Participants. Similar to the IDS MetaData Broker, the ParIS is also an IDS Connector and therefore must also comply to all of its certification criteria.
Purpose of the Document
The document contains the technical specification of the IDS Participant Information Service. It thereby constitutes the basis of the certification criteria that every ParIS instance must fulfill.
Related Documents
The following public documents are related to this document and should be considered as important:
IDS-RAM 4.0
IDS Certification Criteria
Introduction
One of the most important value propositions of the IDS is the enablement of business interactions between previously unrelated Participants. That aims in particular at companies that have not met before in the digital or non-digital world but now start business agreements solely relying on the IDS. The therefore necessary trust in the opposite party is technically achieved by a verifiable identity management process through the Identity Provisioning Service and the DAPS. Both components equip each Participant with the necessary attributes and cryptographic proofs for the IDS handshakes. The establishment of a secure and uncompromised communication channel is however only the necessary requirement for a business interaction. In addition, the respective Participants need to understand their opposite’s state in regards of business workflows. For instance, every business actor needs to know its customers tax identification or VAT number to create correct invoices. Furthermore, the registered address is critical to understand the responsible jurisdiction for the unfortunate cases when only courts can solve conflicts.
IDS ParIS in Relation to IDS-RAM Layers
The Participant Information Service fits, as any other component in an IDS ecosystem, into the IDS Reference Architecture. The following sections describes its aspects and characteristics in the context of the relevant layers of the IDS Reference Architecture Model.
Business Layer
The IDS ParIS is part of the IDS Identity Provider, together with the CA and the DAPS. It contains attributes about the Participants as business entities and collects and provides the necessary information in a consistent and uniform manner. Other Participants can query for a business partner's VAT, legal representatives or organizational structure.
Such information is provided and maintained by the Support Organization in an IDS, the legal entity that administers the ecosystem. The Support Organization introduces a new Participant by creating its digital identity and at the same time registers security-critical at the DAPS and business-relevant attributes at the ParIS. The ParIS provides access to these attributes to the other IDS Participants and components and connects the unique Participant identifier – a URI – with additional metadata. Usually, each IDS ecosystem operates only a small number of ParIS instances, usually only one. IDS Participants therefore know the location where to ask for more information about a potential business partner and can decide whether to start a data exchange.
Different to other IDS components, the trustworthiness of ParIS’ provisioned information is not grounded on technical measures, like for instance signatures or certificates, but on the administrative process controlled by the Support Organization. A direct consequence of this process is the necessity that each change request is manually verified before added to the ParIS database.
Functional Layer
The IDS ParIS enables the Ecosystem of Data (IDS Functional Requirement #3) by bridging the technical infrastructure of an IDS, mainly the administrative capabilities of the supporting organization, with the Connector communication. As such, the ParIS is the enabler for the necessary Standardized Interoperability (IDS Functional Requirement #4) to give access to business-critical information and legal aspects. This creates the basis for Data Markets (IDS Functional Requirement #6).
Process Layer
In order to fulfill the outline tasks from the Business and Functional Layer, several interaction processes are defined that all ParIS instances need to support. Further interactions depend on the support through the ParIS operators and are in principle allowed, as long as they are properly documented and do not represent any kind of conflict with the following operations.
The following UML sequence diagram shows the potential interactions between the different roles in an IDS ecosystem and the ParIS.
Figure 1: Exemplary interactions to populate a ParIS entry.
Figure 2: Exemplary interactions to interact with a ParIS.
Information Layer
The Information Layer affects two aspects of the ParIS. First, it defines the attributes and values that can be used in a Participant Self-Description and therefore appear at the ParIS. Second, the Information Model also defines the component itself - using the class ids:ParIS - and the interaction methods, in particular the applicable IDS Message Types. The details of the applicable IDS messages are further explained in the Section about the System Layer.
Data Model, Participant and Participant Attributes
The attributes provided by the ParIS are in general not critical for the security aspects of the IDS but highly relevant for every business interaction. While for instance IDS handshakes can be executed without knowing the physical location of the opposite party, business processes need to know about the respective country and tax regulations, or which is the complete, legally valid name to create a proper invoice. Other information however is critical to evaluate the identity of the opposite party. These attributes, for instance ids:referringConnector that give the identity of the Connector and thereby an - indirect - link to the Participant Identifier through the Connector's Self-Description. The Participant Identifier is always an URI, preferably pointing also to a Self-Description document for this participant entity. In any case, the description of the Participant should be available at the ParIS, giving Connectors the technical means to resolve a Participant URI. Table 1 contains the currently defined properties of an IDS Participant that can be used to model the metadata for a ParIS. The described properties represent the minimal set of attributes each ParIS implementation must accept. Nevertheless, specialized implementations may also accept and provide additional properties, dependent on the domain-specific requirements or its technical capabilities.
Table 1: Attributes of an IDS Participant instance
System Layer
The internal architecture of the ParIS is in the responsibility of its operator and is not further regulated. Nevertheless, as also the ParIS appears as an IDS Connector, all requirements applicable to a Connector also apply to a ParIS. It is furthermore relevant to note, that more than one ParIS instance can be active in any IDS ecosystem. Even if that is the case, the single ParIS instances are not obliged to synchronize their content nor to announce the existence of the other instances to incoming requests.
Technical Workflow and IDS interactions
The initial population of a Participant entry is conducted directly after the certification and identity creation process is finished. The Support Organization is informed about the successful steps and provided with the corresponding metadata about the new entity (cf. Tab. 1). The provisioning of this information is not part of the IDS interactions yet and must be managed through traditional communication measures. The Support Organization verifies the correctness of the claims, verifies the information, and – together with other additional steps – equips the dedicated ParIS with the new IDS Participant instance. It is further recommended that each Participant also hosts this self-description on a publicly accessible HTTP server of its choice. Preferably the locator of this self-description document, a HTTP URL, is identical with the used Participant URI. This best practice enables the lookup or dereferencing of the Participant Identifier through every HTTP client and thereby eases the discovery of relevant information. Nevertheless, in case the own supplied Participant self-description and the metadata at the ParIS deviate, the latter is more trusted as its claims have been verified through the Support Organization beforehand. Requests to the ParIS itself follow the IDS Message Model and are described, among others, in the IDS Communication Guide and the IDS Information Model. The most common call, the request for a description of an identified IDS Participant, is executed using the ids:DescriptionRequestMessage with the Participant Identifier at the ids:requestedElement attribute. The response message contains a JSON-LD representation of the Participant instance or returns an error message in case the requested identifier is not known to the server.
Table 2: ParIS Operations and their respective IDS Messages.
Protocol Bindings
Every ParIS must support at least one of the defined IDS protocols, for instance Multipart, IDS-REST or IDSCP2. Every supported protocol binding must be announced in the Self-Description of the ParIS, which is published in the common IDS manners.
Future Developments
The IDS ParIS is an infrastructure component in the IDS general architecture with a similar functionality as the IDS Metadata Broker. While the latter indexes Data Resources and Connectors, the ParIS makes Participant information available. Further extensions of its specification may include a more fain-grained access and update model. That can contain the ability for each Participant to update non-critical attributes of its own description, for instance the corporate email address or the member persons. Other attributes, like for instance the VAT number or the legal name, will still require a verification process through the Support Organization. Realizing such options will enable a faster and more accurate provisioning of descriptive metadata while the trust level for critical attributes stays the same. The IDSA Working Group Architecture structures these activities and prepares the further development of the ParIS specification.
Normative References
Namespace Prefixes
Non-normative References
Last updated
