1 Introduction

The declarative representation of the IDS-IM [1] is a vocabulary for the graph-based RDF data model, provided as a lightweight ontology in a GitHub repositoryFootnote 1 under an open license. It serves as the data schema for the Information Layer of the IDS, connecting the conceptual functionalities, roles, and processes with the implementations in the Connector interfaces and endpoints. Figure 7.1 illustrates its structure and the addressed topics grouped into six major concerns.

Fig. 7.1
figure 1

The six concerns defined by the IDS-IM [2] (©2019, International Data Spaces Association)

Full size image

This chapter focuses on the Community of Trust concern. While the IDS regards the digital sovereignty of its participants as its main priority, the latest developments in cloud computing and recent specifications on the decidability of formal usage restriction statements have led to a new understanding how resources are identified and how detailed, machine-readable contracts need to be formalized and embedded into the IDS infrastructure. These evolutionary enhancements of the IDS-IM are introduced in the following.

Section 7.2 explains the extensions of the IDS Resource concept toward the principles of Self-Sovereign Identity (SSI), which is realized by adopting the Decentralized Identifier (DID) and Verifiable Credential (VC) standards. Section 7.3 further describes the formal specifications for the sovereign data exchange in the IDS by presenting the latest concepts of the IDS Usage Contract Language, one core building block of the Community of Trust concern. The therefore necessary infrastructure, in particular the so-called Policy Information Point (PIP), is further specified in Sect. 7.4, followed by the Participant Information Service (ParIS) as the dedicated PIP for business-critical metadata in Sect. 7.5. Finally, we conclude in Sect. 7.6.

2 Evolving Trust in the IDS Toward Self-Sovereign Identity

Participants in an IDS-driven data space describe themselves, the infrastructure components they operate, and the Resources they provide. Other Participants, e.g., data consumers, derive their trust into these self-descriptions from their trust into the participant that provides them. In version 3 of the IDS Reference Architecture Model [2], trust-related attributes, such as security status or certification for compliance with certain criteria, are assigned to an IDS Connector, the key interface every Participant has to operate to exchange data, in a dynamic manner by a central Dynamic Attribute Provisioning Service (DAPS), a part of the IDS Identity Provider component.

More recently, there is a push toward decentralized identity and trust management in the sense of Self-Sovereign Identity (SSI). The development toward SSI in IDS is most strongly influenced by its discussion in the scope of the Gaia-X federated data infrastructure [3], which builds on many IDS principles [4]. The Gaia-X Identity and Access Management Framework supports an SSI approach based on Decentralized Identifier (DID [5]) and Verifiable Credential (VC [6]). A DID is a special case of a URI and thus compatible with the identifiers used in the IDS. The additional indirection provided by the mechanism of resolving a DID to obtain information about the subject it identifies facilitates privacy and enables verification of identities by cryptographic proofs such as digital signatures. DID resolution may be implemented in a trusted way using, e.g., distributed ledgers.

The information that participants in an SSI setting provide about themselves can be made tamper-evident and more trustworthy by wrapping it into VCs. VCs state claims about a subject and carry cryptographic proofs, such as digital signatures. For example, a credential stating that a Participant has been certified to comply with a certain standard might be signed by an evaluation facility. In Gaia-X, the self-descriptions of Participants and anything they provide are comprised of such VCs, i.e., the proofs of any claim about a subject reside decentrally with the subjects themselves, like physical ID cards residing in a person’s wallet. Once, after successful verification, one Participant Alice decides to trust another Participant Bob’s credentials, Alice may continue to operate on the raw claims Bob or other trusted parties made about himself, by extracting them from Bob’s credentials and merging all of them into a single, easy-to-query metadata graph, which has the same structure as a plain, untrusted self-description.

Thus, SSI can be realized on top of the IDS-IM in a backward compatible way, which we are planning to pursue in the course of co-evolving IDS and Gaia-X in an aligned way [4].

3 Definition of Contract Clauses: The IDS Usage Contract Language and Its Core Concepts

The IDS-IM provides the means to describe and exchange datasets and services. In particular, it combines several prominent standards, for instance the Data Catalogue Vocabulary (DCAT) and the Open Digital Rights Language (ODRL), and further specifies them toward unambiguous definitions of its meaning and implications. The IDS Usage Contract Language, a part of the Community of Trust concern, allows the expression of usage restrictions in the form of machine-interpretable data objects. It thus bridges the gap between textual, human-readable contracts and decidable logical statements.

A similar approach is conducted with the Solid framework and its access control model. Both define the restrictions in RDF resources, and both use semantic expressions to indicate allowed operations and to prohibit unintended requests. Still, the two differ significantly in their scope and also the expressiveness of their supplied concepts. These differences are explained in the following and form the basis for the later outlined extensions of the conceptual foundations of the IDS Usage Contract Language and its regarded dimensions and operators.

3.1 The Solid Access Control Model vs. IDS Usage Contract Language

The IDS Usage Control Language comprises the necessary concepts and attributes to describe rich usage permissions and how to enforce them. These concepts follow the holistic scope of an overall usage control perspective. Solid, the approach for a decentralized social network of self-controlled data pods, aims at giving human users the sovereignty of their personal data. The data protection solution promoted by Solid—the Web Access Control (WAC [7]) language—differs slightly from the IDS concepts. First, its scope is restricted to pure access control. The expressiveness of the protection rules, an Access Control List (ACL) or acl:Authorization, ends as soon as the data resource is requested by the consumer. Subsequent usage activities and even the further distribution of the resource are not reflected.

Nevertheless, both approaches follow the same identification pattern. The data resources and the Authorization (Usage Contract) related to them follow the URI schema, usually as http URIs. While ACLs in general are used also in many other environments and are open to any—also non-URI—identifier scheme, the special usage of WAC in Solid requires compliance with the Linked Data Platform (LDP) specification. acl:Authorizations determine the permitted RESTful operations on the (LDP) target resource and can also be accessed as own LDP Resources. As such, one can even think about acl:Authorizations managing the access to other acl:Authorizations, something that is not possible for IDS Usage Contracts.

WAC does not allow the specification of a resource owner. This is the same approach as in the IDS model. The authorized entity that has the technical ability to control the resource itself and define its usage permissions is implicitly assumed to be the sovereign of this resource—whereas, for example, Verifiable Credentials held by one entity (e.g., a parent) may make claims about another entity (e.g., their child). The WAC procedure addresses the challenge of ownership by relying on the technical capabilities of users or user agents. One has to note that such indirect proceedings are necessary as an ownership concept—like for physical goods—is not possible or applicable for digital data. The thereby created implication is that the Data Sovereign is the one who has the technical capability and permission to manage the access to a resource, and that the access permissions and control rights are granted to the Data Sovereign. This logical circle requires more in-depth examination.

One further challenge is the definition of user groups. The range starts with a group of the size one, which is equivalent with an individual user. In an WAC statement, this user is identified by its WebID, i.e., a URI. On the other end of the possible descriptions is the group including everyone, which is expressed by the class foaf:Agent. As everyone, either human or nonhuman, organization or individual, is by definition an instance of foaf:Agent, a permission assigned to this class applies also to everyone.

Between these trivial cases are the more relevant defined groups, for instance the members of a certain organization or company. The best practice for encoding such groups is to use URLs. The Web resource of the group URL shall provide a list of its members. The access management service therefore needs to dereference the group identifier, and thereby receives all required information to accept or decline the access request. The IDS handles such groupings differently. Its business-to-business focus leads to the view of all users or organizations as instances of the generic ids:Participant class. Recursive declarations then enable the description of membership. A department is modeled as a Participant, which is part of the bigger company, which is also an IDS Participant.

The core challenge for both approaches is the clarification of whether a user is a valid member of a group or organization. In the terminology of XACML [8], a Policy Information Point for this type of information is needed. The WAC specifications solve it by using the identifier also as the reference to the PIP interface—the group URI is also the pointer to the Web resource containing its members. That is not possible in the IDS where membership information requires the highest protection level and must not be open to arbitrary Web requests and does not reflect group members. The respective PIPs in an IDS ecosystem are therefore globally known components such as the Participant Information Service or company-specific like an LDAP system.

The WAC scope is limited to describing the following access operations: read, write, append, and control. The IDS Usage Control language must also express activities after the granted request, for instance to not distribute, log, notify about usages, or even delete the resource from the receiving system. Obviously, such obligations cannot be ensured by the providing server but require a trusted system at the receiving party. While the IDS includes specifications and guarantees to achieve such usage policy enforcement, it is not in the scope of Solid or the WAC language.

An additional difference can be found in the inheritance regime of the WAC and the IDS Usage Control language. Solid ACL files are interpreted relative to their location in LDP Containers. That means that the same permissions apply for the contained container and resources. As the IDS does not follow a strict container model, such passing of rules is not possible. Each ids:Resource needs its own assigned usage policy. Nevertheless, the IDS follows a similar concept when it comes to the concrete appearances of a data asset. By default, policies specified for the ids:Resource are propagated through the related ids:Representations in particular formats to the final ids:Artifacts, i.e., their materialized instances. Solid misses this differentiation and consequently has only one way to describe the target data asset.

Another significant difference lies in the embedding into HTTP headers for the runtime discovery of ACL files. As the IDS supports several protocol bindings, the limitation to RESTful discovery operations (GET, HEAD) is not sufficient. Potential consumers therefore need to use infrastructure services, in particular the IDS Metadata Broker, or directly the resource self-description at the hosting connector to find the applying Usage Policies. As the Solid interactions are only enabled through the LDP operations, the discovery mechanism using Link headers are sufficient and no third-party component is required.

3.2 Usage Control Dimensions

The general syntax of Usage Control contracts as proposed in the section before enables systems to form expectations about the order and relations of their clauses and parts. The formulation in RDF further defines serialization formats and allows their exchange via messages. Nevertheless, the involved systems also need to understand their content, their implications, as well as the limitations of their own capabilities. A pure syntactic or data-oriented view on the contracts directly leads to situations, in which undesired clauses are acknowledged.

Table 7.1 presents the sorted list of feature dimensions agreed throughout the IDS community. Higher-ranked features are assumed to be more relevant, or more commonly used, than lower-ranked ones. For instance, nearly every Usage Control use case requires basic logical statements (something is true or false), while geospatial relations are less important. In addition, higher-ranked features tend to be better understood and have more mature definitions than lower-ranked ones. Due to their wider usage, more research works have treated them and examined their implications. This assumption is further supported by the observation that, while the “Network Space” and “Events” are crucial for many IDS use cases, still no widely accepted modeling scheme or data format for them can be found in the literature. The Question marks in the table indicate where the specification is still work in progress.

Table 7.1 Building blocks for feature dimensions (incomplete list)
Full size table

The varying complexity of the different features is a further gap in the literature. To the best of our knowledge, no recent work aims to examine the different requirements on an abstract level. It is important to understand the different kind of input requirements for each dimension. For instance, basic temporal comparisons like X is before Y or X is after Y are, given that Y is a known and fixed value, dependent on the one free variable X. Questions like X is in the three-months testing period, however, require not only the given period length but also its starting date. Consequently, two input factors need to be known before the statement can be evaluated. The column Degree of Freedom (Degr.) contains the analysis for each feature dimension and thereby poses requirements to the actually usable contract clauses.

Definition

A degree of freedom is the minimal number of differing input parameters that are necessary to unambiguously define a statement of the respective feature of interest.

That is important to understand why certain contract clauses, in particular Constraints in this work, are complete and others not. Continuing the example of a testing period, a clause like use only for three months is not sufficiently defined (start date of the period is missing) and must be rejected by every enforcement system. Understanding such requirements, and linking them to the defined features of interest, is the only way to prevent unsolvable situations at the evaluation time of a contract.

Similar important to the Degrees of Freedom are the anchors of each scale. An intuitive example is the xsd:dateTime datatype defined by XML Schema 1.1. The anchor is the Coordinated Universal Time (UTC) based on the Gregorian calendar. While this is a universal, worldwide identical anchor, this is not necessarily the case for other features. Organizational relations, most importantly the role of an employee in the organizational hierarchy, are different in every company. It is therefore impossible to define such anchors at the design time of a system, and the related information needs to be supplied at the evaluation time. Somehow in between are clauses about geolocations. While there is a widely used coordinate system (WGS 84) based on the GRS 80 reference ellipsoid, other coordinate systems such as ETRS89 can have deviations and need to be mapped beforehand. That implies that—even though coordinates are syntactically valid, and the evaluations on top can be calculated—also the anchors must be the same to gain the same results.

The last column of Table 7.1 contains the specified datatypes for simple types and the used reference for complex ones. Whenever possible, RDF recommendations have been used. Where necessary, well-defined reference ontologies provide the clauses, for instance the ORG ontology [9] for relations and roles between organizations—which ids:Participant is also derived from. The table, of course, only represents a first common basis that will certainly need extensions in the future.

3.3 Operators for Usage Control Rules

The presented feature dimensions from the previous section define the space in which the Usage Contracts can be applied. The individual clauses in this space are built using operators to create meaningful statements. These operators are limited to two input parameters per clause. While certainly more parameters are possible without affecting the applicability of the operators in general, this limitation reduces the implementation load for applications and has been proven as a suitable trade-off between expressiveness and implementation complexity.

Definition

A Usage Control Operator ◊ is a binary operator identified by a URI, deriving a Boolean value from exactly two input parameter sets A and B:

$$ \lozenge :A\times B\to \left\{\mathrm{true},\mathrm{false}\right\} $$

An operator is therefore defined on the input dimensions A and B and its derivation function. The identifier, a character sequence forming a valid URI, is required for the reference in the rules. As far as the IDS use cases are affected, URIs in the HTTP scheme have proven their applicability and are the preferred pattern.

Table 7.1 aligns the operators with their corresponding feature dimension. The previously mentioned clause—X is before Y—can be modeled using the ◊BEFORE operatorFootnote 2 and X and Y as time instances. Using graph patterns, we can write:

$$ x{\lozenge}_{\mathrm{BEFORE}}\kern0.5em \mathrm{y}\to \left\{\mathrm{true},\mathrm{false}\right\},\kern0.5em x,\mathrm{y}\in \mathrm{TemporalInstance} $$

We can assign a definite value using a date-time stamp for y, for instance "2020-12-31T23:59:59+01:00"^^xsd:dateTimeStamp or any other unambiguous reference to a temporal instant. Reflecting its position in the statement and according to the ODRL terminology, we call y a RightOperand. The LeftOperand, x, may also have a fixed dateTimeStamp, for instance "2021-01-01T00:00:00+01:00"^^xsd:dateTimeStamp. In that case however, the clause is trivial and therefore uninteresting, as it always evaluates to true. More relevant for real-world use cases are references to the current point in time, for instance to express that a now must be before a certain time instance, as the contract shall limit the usage time. It is therefore necessary to define a set of references, which the Usage Control system is aware of and can use to evaluate the applicability of the contracts.

This demand is reflected by the list of LeftOperands. Now is represented by the POLICY_EVALUATION_TIME instance. Additional instances, like PAY_AMOUNT, allow the description of usage fees or make references to certified security characteristics (SECURITY_LEVEL) of the regarded application. Combining all these parts allows the data sovereign to state its intentions and gives the downstream consuming systems the information how they need to handle the incoming data. The according behavior of their applications can be certified and proven to remote parties using trustworthy tokens. The IDS promoted Dynamic Attribute Tokens (DAT) contain such claims, combining the results of certification processes with cryptographic signatures; in Sect. 7.2, we have explained how to further decentralize this approach to Self-Sovereign Identities. The result is an ecosystem where usage intentions can be expressed, exchanged, and implemented on a technical level (Table 7.2).

Table 7.2 Binary operators for Usage Control constraints
Full size table

The outlined definitions to merge Usage Control and Data Sovereignty with decidable constructs show a way of how to create an interoperable and at the same time protected ecosystem for data. The provided assumptions and statements are intended as starting points for further discussions. We believe that a consolidation of the thereby affected approaches and concepts is necessary, and a trade-off between formalization and expressed details on the one hand and adoption on the other is indispensable.

Still, the demand for more and more autonomously acting systems enforces overhead in terms of data models and implementations. IDS Usage Contracts show how the different specifications can be combined to a comprehensive interpretation. We have observed that similar ideas and pattern appear in the different domains. The integrated approach can therefore also serve as a bridge between the communities. The result however has the potential to disrupt the way we treat digital information and how trustworthy systems can technically enforce the initial restrictions.

4 The Policy Information Point

The concept of Policy Information Points, or PIPs, depicts one of several roles in a decision system as shown in Fig. 7.2. Similar to the other policy points, a PIP is an abstract role assignment rather than a concrete software asset. That means that a single application can serve, for instance, as a PIP, a Policy Decision Point (PDP), and a Policy Execution Point (PEP) at the same time. Still, the separation of the different terms helps to define the different capabilities and responsibilities in a decision workflow and to describe which tasks are executed by which component.

Fig. 7.2
figure 2

The PIP in the workflow between the different policy points (illustration from [10]) (©2021, International Data Spaces Association)

Full size image

In the IDS, the PIP provides the capabilities to provide the information that is necessary to evaluate whether the conditions of a formal contract are met or not. For instance, if the usage is restricted to a certain duration, the PIP supplies the elapsed usage time. It is important to note that the PIP itself does not derive any decision itself. It only provides the interface to, in this example, a time service without any further indication.

Obviously, PIPs can appear in many different realizations in an IDS ecosystem. As explained, one appearance can be an API to Connector-internal functionalities. A second option is the realization as a stand-alone application in the network, serving required information for several Connectors and their usage enforcement systems. A further distinction can be made by the operation mode of a PIP component. While for the former use case the PIP is part of the functional architecture of the Connector itself, or operated close to it, the provisioning of reliable and accurate information can as well present a business model that justifies a certain fee. Such PIPs are operated as independent components of an IDS infrastructure, and their integration depends on the configurations of a usage contract. Therefore, the communication is initiated at the runtime of the consuming connectors, which implies the usage of standardized interfaces and defined data objects both for the incoming request and for the returned response. The following explanations discuss these features and present the latest state of the community discussion.

Definition

An External PIP is an IDS Connector that supplies at least one attribute of interest for the evaluation of Usage Contracts. It must outline its role in its self-description together with the path to the endpoints where the provided attributes can be accessed through IDS-specified communication channels.

In particular, the applied definition demands that PIPs operate valid DATs and are capable of communication in at least one supported IDS message protocol. This especially does not enforce the support for all protocols. For instance, one PIP may only have one endpoint for the IDS Communication Protocol (IDS-CP), while another also supports the IDS REST binding. A requesting Connector cannot, for now, expect that its protocol of choice is possible without further lookups in the PIP self-description.

Furthermore, a PIP is not obliged to answer an incoming request. Possible rejection reasons could be an expired or otherwise invalid DAT of the requesting Connector, or open fees that need to be paid beforehand. In any case, the PIP must—as every other Connector—respond with an according rejection message indicating the issue.

The information request can happen in different ways, for instance in a message-oriented way using an ids:RequestMessage. The currently recommended pattern, however, uses the IDS REST binding that models the PIP as a Linked Data Platform server with so-called container resources. A container in that sense serves both as an endpoint for incoming requests but also as the destination for lookups. It provides descriptions about its functionality, the required input and output parameters, and indicates its capabilities using the IDS-IM.

An IDS Connector discovering a PIP can therefore traverse through its descriptions and recognize endpoints and the information offers supplied therein on the fly. This is especially relevant as in a common scenario, the data provider demands the usage of a certain PIP to evaluate the applicability of a Usage Contract. The consuming Connector usually is not aware of the existence of this specific PIP and consequently needs to integrate its endpoint during its runtime. The execution of a sequence of read requests is at that point significantly easier for the consuming Connector than the on-the-fly integration of a message endpoint.

An External PIP as regarded by the IDS strictly distinguishes between the provisioning of information and its meaning and implications at the time of the evaluation of a contract. The PIP therefore must not anticipate the effects of an information request and act as a neutral and unbiased source. As such, it combines the conceptual role from the usage control perspective, which requires a standardized entity for attribute queries, with the communication interfaces of a Connector.

The PIP obviously needs to also implement the features required of any Connector, in particular the provisioning of a self-description conforming to the IDS-IM but also a valid and verifiable DAT, which also relies on IDS-IM attributes. PIPs however easily go beyond the expressiveness of the Information Model, for instance when domain-specific data attributes are supplied. Such information must be integrated with the technology stack of the IDS, in particular the usage of RDF. Nevertheless, the proper selection of the data format alone is not sufficient. To ensure the possible incorporation of the provided attributes, their semantic meaning also needs to be specified. Open catalogues like ECLASS or from the Linked Open Data Cloud contain the required terms and concepts and often provide lookup facilities. A client connector using a PIP can thereby not only automatically traverse the PIP itself and discover its provisioning on the fly but also understand the external concepts used by applying the same operations. This significantly simplifies the integration efforts on the developer side and paves the way for a broad adoption of the IDS PIP concept.

5 The Participant Information Service (ParIS)

One of the most important value propositions of the IDS is the enablement of business interactions between previously unrelated Participants. That aims 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 regard to 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.

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 attributes at the DAPS and business-relevant attributes at another technical component: the Participant Information Service (ParIS), a PIP for Participant attributes. 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, most often just 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 from other IDS components, the trustworthiness of ParIS’ provisioned information is not grounded on technical measures such as 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 being added to the ParIS database.

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. Table 7.3). 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, one of the “Linked Data” principles, enables the lookup or dereferencing of the Participant Identifier through every HTTP client and thus 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.

Table 7.3 Attributes of a Participant as provided by a ParIS
Full size table

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 as the value of 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.

The attributes provided by the ParIS (see Table 7.3) 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. Table 7.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.

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 fine-grained access and update model. This could include the ability for each Participant to update noncritical attributes of its own description, for instance the corporate email address or the member persons. Other attributes, such as 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 Architecture Working Group structures these activities and prepares the further development of the ParIS specification.

6 Conclusion: The IDS-IM as the Bridge Between Expressions, Infrastructure, and Enforcement

This chapter presents several aspects of the IDS Information Model. It explains the new state of discussions to combine decentralized identification provisioning methods with the rich expressiveness of the already elaborated vocabulary. The IDS-IM is supplied as an RDF ontology conforming to the conventions and best practices of open data resources and maintained in a transparent process. One of the activities therein is the integration of defined logical statements to formally express the intentions of usage restrictions in machine-interpretable data objects. Different from previous approaches, the IDS-IM not only extends the descriptive representations to access decision, like the WAC vocabulary, but faces the significantly more complex challenge of enforcements in the data usage phase.

This is only possible with defined infrastructure components that provide reliable and standardized attributes in IDS-compliant manners. The IDS interpretation of the PIP fulfills this role and enhances the reference architecture with the capabilities to execute applicable usage enforcement into data ecosystems. In particular, the ParIS further specifies the PIP functionality for Participant attributes and provides all Connectors with the necessary standardized interfaces to retrieve business-critical information from the IDS Identity Provider components.

As such, the latest development of the IDS-IM incorporates the requirements of state-of-the-art cloud computing with the expressiveness needed to implement true data sovereignty. Its next evolvements include the implementation in cloud-native environments.