1.  Introduction

 

2.  Functional Specification Template Building Blocks

2.1.                 Front matter

 

2.2.                 Introduction

This building block is about the registration of entities that are relevant to a Data Space, such as participants, connectors, and more. The building block has three layers:

1. Identity Provisioning. In this layer, identity registrations can be queried, e.g., to learn who/what someone or something is, what characteristics (attributes) are associated with it, etc. This is the operational (runtime) layer.

2. Identity Management. In this layer, identity registrations are filled and updated. For example, whenever a party becomes a participant (onboarding), it will get an entry (record) in the appropriate registration, and its characteristics (e.g., its LEI, its legal name, etc.) are being recorded. The updating of such records, the archiving and/or deleting thereof (offboarding), as necessary, is also part of this layer.

3. Identity Governance. In this layer, decisions will be made (and appropriately published) regarding which kinds of entities will be registered, what characteristics will be registered (an in which formats), and what the conditions are for creating, reading, updating, and archiving/deleting such records. Also, decisions are made regarding the (qualifications of) parties that will be assigned the rights and/or duties to perform management and/or provisioning activities, whether (or not) they must or should be participants to the data space, etc. And decisions regarding the technical and non-technical components, protocols etc. that are to be used in the management and provisioning contexts, respectively. Typically, the Identity Governance is performed by, or on behalf of, the Data Space Governance Authority.

[Illustrative image or figure describing the building block]

Interrelationships: An overview of how the building block relates to other building blocks in the OpenDEI DSSC framework. This should include any dependencies, shared functionalities, and potential conflicts with other building blocks.

2.3.                 Purpose of the Building Block

This section should provide an introduction to the technical specification of the data space building block. A technical specification is a detailed and comprehensive document that describes all technical produces related to the building block. The introduction should explains its purpose, use cases, and intended functionalities. In addition, the introduction of the document should also contain a summary of the problem, including the context, suggested solution and the key stakeholder.

A very brief introduction (max 5 sentences): Provide an introduction of the technical specification for a technical data space building block by explaining the context in which the building block will be used.

Purpose and problem: Explain the purpose of the building block and how it relates to the specific problem or need that it is intended to address.

Use cases: Describe the potential use cases of the building block. It involves identifying and explain the various ways in which the building block can be used to solve specific problems or achieve certain goals.

Suggested solution: Provide a suggested solution or approach to address the problem. It is important to be clear and concise, and to provide enough details to allow key stakeholders to understand how the approach of the solution will address the problem.

Key stakeholders: Identify all stakeholders involved in the development, implementation, and usage of the building block to ensure their needs and expectations are taken into account.

When to use the building block? When not?

2.4.                 Definitions and Vocabulary

In this section, all terms and vocabulary used throughout the technical specification are defined and explained, which is a subset of the DSSC Glossary and thus fully aligned with the content of the DSSC Glossary.  

For terms that are included in the DSSC Glossary, please refer to that section for their definitions. If new terms are introduced, they should be provided with a criterion as its description. The idea is that different people (in the context of DSSC and data space initiatives) will make the same judgments when they use criteria in some (relevant) context - i.e. they would agree on whether or not something is (not) an instance (example) of the term. By following this process, it is also possible to propose generic terms to the DSSC Glossary that were not initially included. The DSSC Glossary team will analize and approve/reject the proposed terms.

2.5.                 Conceptual Models

This section should provide a high-level conceptual model of the data space building block, including all the concepts and relations between them. A conceptual model can be used to clarify and communicate these technical specifications. It establishes a shared understanding among key stakeholders. The conceptual model can be seen as a highlighted subset of the DSSC conceptual model, optionally enriched with BB-specific concepts. It may function as input for the conceptual model expert group.

A conceptual model represents (a part of) a single mental model, and typically consists of specifications for:

• concepts, i.e. (named) classes of entities that have similar properties, e.g. 'data space', 'party', 'person', etc.

• properties, i.e. (named) characteristics that can be attributed a value to every instance of a specific concept. For example, the concept 'person' can have a property named 'gender', with values such as 'M' (for male) or 'F' (female).

• relations between such concepts, i.e. meaningful (characteristic) links that can exist between (instances of) these concepts, e.g. '[party] is the governance authority of [data space]' or '[person] is the mother of [person]'.

• constraints, i.e. logical expressions composed of concepts, their properties and/or relations, that are expected to be (made) true. For example:

o   every person has precisely one other person as its mother, and that person has gender 'F' (this is always true);

o   every data space must have precisely one party that is its governance authority (if this is not true, it must be made true).

Figure : the Concepts and Relations within a Conceptual Model

To define a concept, its properties, or a relation between concepts, a criterion should be provided as a description in the glossary table.

**[Illustrative image or figure describing the Conceptual Model]** 

2.6.                 Functionality

This section should provide a detailed description of the functions that the data space building block should acquire, including its intended features and capabilities. It must clearly describe what the building block is expected to do and its anticipated input/output interactions with other building blocks.

To ensure that different components can work together seamlessly, it is important to clearly define any assumptions being made about the interactions with other building blocks. These assumptions should be documented and clearly communicated to all stakeholders involved in the development and implementation of both building blocks. Interactions with other building blocks can be thought of as synchronization points, where data or functionality is exchanged between components of a data space.

In this section, a table is used to define the details of each function within a data space building block. Each row of the table represents a single function, and the columns represent various aspects of the function, such as its description, interactions with other building blocks, constraints or limitations, and dependencies.

 

 

2.6.1. Identity Governance Functionalities

Identity Governance functionalities pertain to a single identity registry (i.e. a registry that contains identity records of entities of a particular kind, e.g. people, organizations (including legal entities), IT component (such as connectors), etc.

2.6.1.1. Governance Functionalities for the Data Space Governance Authority

The governance authority of a data space decides for which kinds of entities a registry will need to be maintained, and for each such registry it also determines:

1. the purpose that the registry serves, which includes a specification of what it means for an entity to (not) be registered therein.

2. the specific kind of entities for which identity records will be created and maintained in that registry.

3. any (high-level) constraints that may apply, or rules that must be followed e.g., for compliance reasons, and that designated identity governors must take into account when creating and maintaining process specifications for the identity management and identity provisioning processes.

Typically, a registry will be kept for members of the data space:

1. the purpose of which is for parties to learn which (other) parties are a member, so that they can rely on their commitments associated with being a member;

2. the specific kinds of entities that are registered will be, e.g., legal entities that have signed a membership contract with the data space governance authority, and

3. access to which is constrained to parties that are member of the data space, as well as parties that are designated to perform the identity manager role.

Note that a data space governance authority may decide to also maintain registries for other kinds of entities, e.g., data space connectors, or member registries that provide many more details about a member than the member registry itself does. It is important that a data space governance authority not only provides a proper name for the kind of entities in a registry, but also the criteria that distinguishes between entities that are, and are not, of that kind.

We say that a party that performs Identity Governance functionalities for a particular identity registry does so in the role of Identity Governor. Parties can be an Identity Governor for multiple identity registries, and can perform other roles in a data space as well.

For every identity registry in a data space, the data space governance authority determines which party gets to perform the role of identity governor. This role (for a particular registry) shall be assigned to a single party so that it is clear where the accountability and responsibility for the governance of that registry lies. The data space governance authority may assign this role to itself.

2.6.1.2. Governance Functionalities for Identity Governors

The functionalities that an Identity Governor is expected to perform on its designated identity registry include:

1. determining, in such a way that the data in the identity records suffice to serve the purposes for which the registry is maintained, and the constraints/rules are properly considered:

   1. the characteristics of such entities that are required to be registered, as well as the characteristics that may optionally be registered;

   2. the syntax (and semantics) of attributes that represent such characteristics;

   3. the (syntax of the) unique identifiers that will be used to refer to the individual records within that registry and and consequently also to represent the entity that the record contains a registration of;

   4. where the registries will be located, as well as any requirements that their implementations need to satisfy;

   5. how such registries can be accessed (manually and/or electronically), including a specification of required and/or forbidden protocols;

2. determining the process specifications for the management and provisioning processes, by providing, for each such process:

   1. its pre-conditions, i.e., the set of logical statements (combined with AND and OR operators) that must be fulfilled at the moment a process instance is started (created, triggered);

   2. its peri-conditions, i.e., the set of logical statements (combined with AND and OR operators) that must be fulfilled at any moment in which actual work is being done within a process instance;

   3. its post-conditions, i.e., the set of logical statements (combined with AND and OR operators) that the work in a process instance aims to fulfill, and that terminate the process instance when that is the case.

3. determining what qualifications parties and IT must have in order to manage and/or provide identity records in the registry, such that the peri-conditions of the processes that they are expected to work on can be satisfied.

4. delegating the management and provisioning of identity records to appropriate parties (which then become the identity managers and identity providers respectively);

5. regularly reviewing the process specifications allows the identity governor to adapt to changes, improve efficiency, maintain compliance, leverage new technologies, and align with stakeholders. It helps ensure that the specifications remain accurate, relevant, and effective in supporting the data space objectives.

6. regularly reviewing the parties fulfill the roles of identity manager and/or identity provider for the various registries, for the purposes of maintaining control over the quality, efficiency, and cost-effectiveness of the identity management and identity provisioning processes, and helping to foster a strong partnership, mitigate risks, and ensure alignment with the data space objectives.

2.6.2. Identity Management Functionalities

Identity Management functionalities pertain to a single identity registry. The governance authority of a data space, or the identity governor associated with that registry decide about criteria/constraints that the identity management processes must satisfy. Also, they determine the party (or parties) that get the rights and duties assigned to execute the identity management process for that registry.

We say that a party that performs Identity Management functionalities for a particular identity registry does so in the role of Identity Manager. Parties can be an Identity Manager for multiple identity registries, and can perform other roles in the data space as well. The data space governance authority or the identity governor may assign this role to themselves if they so choose.

The functionalities that an Identity Manager is expected to perform on its designated identity registry include:

1. creating identity records, i.e., the registration of an entity of the kind for which the registry holds records.

2. keeping identity records up-to-date, e.g., when characteristics that are registered have changed;

3. (un)suspending identity records, i.e., marking an identity record such that its contents can no longer be accessed through the Identity Provider functionalities (but remain available for Identity Management)

4. archiving and/or deleting identity records.

Note that the identity governor of the registry has created the process specifications for these processes, that provide the constraints (and freedom) that identity managers have to comply with.

Identity Managers can help their Identity Governor by providing transparent reporting, adhering to SLAs, maintaining proactive communication, actively participating in performance improvement initiatives, offering feedback and suggestions, ensuring compliance and risk management, and collaborating in problem-solving. Such actions contribute to a successful review process, foster trust, and enhance the overall partnership between the parties performing these roles.

2.6.3. Identity Provisioning (Operational) Functionalities

Identity Provisioning functionalities pertain to a single identity registry. The governance authority of a data space, or the identity governor associated with that registry decide about criteria/constraints that the identity provisioning processes must satisfy. Also, they determine the party (or parties) that get the rights and duties assigned to execute the identity provisioning process for that registry.

We say that a party that performs Identity Provisioning functionalities for a particular identity registry does so in the role of Identity Provider. Parties can be an Identity Provider for multiple identity registries, and can perform other roles in the data space as well. The data space governance authority or the identity governor may assign this role to themselves if they so choose.

The main function of an Identity Provider is to execute the following processes (using the process specifications of the Identity Governor):

• receive requests for identity data in one of the designated communications channels;

• decide whether or not to service such a request (per the access control policy for identity data as specified by the identity governor);

• get the requested identity data from the designated record(s) from the registry;

• package the requested identity data in a format that is appropriate for the request and the return communications channel (possibly associating it with a usage policy for that data, as per the specifications of this process by the Identity Governor), and

• send it to the designated recipient through the designated return (communications) channel.

However, in order to do all that, the Identity Provider must also deploy an operational system that contains the identity records that hold such identity data, configure it, maintain it, accommodate for any changes as may be required by the Identity Governor of that registry, make regular backups (and test these), and provide logging facilities that facilitate e.g., dispute resolution, policy reviews, etc.

2.6.4. Identification and Authentication

Identification (of an entity by some party) can mean two things:

1. the party has an identifier, and it wants to learn which entity the identifier refers to. We call this ‘identification of the entity’, and also ‘dereferencing the identifier’. This is what is typically done with URIs, which are usually associated with a particular method (http, ftp, did:method, …) that you can apply to the identifier so as to dereference it.

2. the entity produces an identifier, implicitly or explicitly asserts that (s)he is the one that the identifier refers to, and the party has to subsequently establish whether this assertion is true or false. There are various ways of doing this, e.g.,

   1. to dereference the identifier, and check if this produces the entity that made the assertion. However, that is not always possible.

   2. to add some data to the identifier that serves as an assurance (sometimes called a ‘proof’) of the assertion. The party can verify the assurance, i.e. perform (often cryptographic) checks that prove that the data has not been tampered with and comes from a specific source that the party relies on (trusts) - that’s why the party is often called the ‘relying party’. The relying party itself may provide such assurances (which are easy for itself to rely on), but it may also rely on other parties (in the role of Identity Provider) to provide them. Asking for and subsequently verifying these assurances so as to create certainty that the entity that presents the identifier (and assurance) is actually represented by the identifier, is called ‘authentication’. We use the term ‘identity token’ to refer to the data that the relying party needs to perform such authentication. Here are some examples:

      1. the entity provides a username (as identifier), and provides a password (as proof), the combination of both serves as identity token.

      2. a person shows a passport, that contains its name(s) etc., and a picture and other data that serve as the proof. These names, the picture, and the security features of a passport serve as identity token.

      3. an application that allows a user to login with, say, its Google account, will get Google’s userid of that person, and further cryptographic data that it can verify to ensure the user associated with that Google-id that the person actually logged in.

What is missing in these narratives is the role of the party that controls (authors) the identifier. Identifiers such as URIs are typically authored and controlled by the party that has claimed the domain name that is embedded in the URI, and the party may decide to use one of the (many) standardized methods for dereferencing it, such as http, ftp, did:<method>, etc. Note, however, that it is not a law of nature that URIs (or other identifiers for that matter) can always be dereferenced this easily, or even that its author is the one that has registered the associated domain name. While it would certainly be very odd, it is perfectly possible for a party to refer to its pet dog with ‘localhost’. The lesson here is that one can only identify an entity from an identifier that is authored by some party, if one knows how that party (implicitly or explicitly) dereferences that identifier.

Similarly, authentication (assessing whether or not the identifier that an entity produces refers to that entity) can only be done if one knows what kinds of proof the author of the identifier has issued, and that there are sufficient assurances that the proof cannot be tampered with.

It is common practice for parties that run an application, to associate them with a registry that contains records of the entities that can use the application in one or another capacity (role).

2.6.5. Single Sign-On

Single Sign-On (SSO), is a mechanism that reduces the number of times that a person has to login, i.e. provide a username and password, or similar. The idea is that (a) this person operates a (digital) user agent, such as a web browser, that does the actual logging in on its behalf, and (b) there is a set of applications (services) that accept an ‘identity token’ that is provided by a specific IdP component, that it can cryptographically verify, and if that checks out, serves to identify and authenticate the person. The user agent can obtain such a token from the IdP by having the person login with a username and password, or similar, upon which the IdP will send the token for the user agent to store and use (until it expires). Obviously, SSO only works within the set of applications, which must all rely on identity tokens of the same IdP.

SSO makes life easier for users as they can seamlessly access various applications without the need to re-authenticate. This not only enhances user experience by reducing login friction but also improves security by centralizing authentication and reducing the need for multiple passwords.

A data space can facilitate the use of SSO by having the IdPs provide such identity tokens. Obviously, such IdPs would need to provide identity data for entities (such as people, or digital agents) that applications would see as users that can login. The governance on the registries from which such data is provided should provide the guidelines and conditions to make this happen.

2.6.6. Centralized, Federated and Decentralized Identity

In practice, people use the terms Centralized, Federated, and Decentralized identity management to refer to specific constructs in which identity governance, management and provisioning take place, and where the identity registry has data about people (users). In all cases, the provisioning is not just about user identification and authentication, but may extend to the provisioning of user attributes.

In the centralized view, only one single registry for users is considered (perceived as a ‘central database’), and it is typical that the roles of identity governor, identity manager and identity provider are performed by a single party. As a consequence, the identity governor of that registry gets to decide what data of users is stored, and basically ‘owns’ and controls that data (the ‘user identities’). This ‘central authority’ is responsible for authenticating users and providing identity tokens and/or user attributes. Identity providers that are typically characterized as being centralized include Google, Microsoft, AppleID, LinkedIn, but also eIDAS or FICAM.

It is rather subjective whether or not something is considered as being ‘centralized’. Applications that enable their users to select one out of several of such ‘centralized’ identity providers (e.g. GoDaddy) show that while each provider still governs, manages and provides its own identity data, it becomes increasingly difficult to maintain that they actually control all identity data of a particular user (that would have accounts with several of such providers). Individual parties can autonomously decide which identity providers it allows its users to use for authentication (and attribute sharing) purposes, provided there is an API that their applications can use to connect to the corresponding identity provider components. For an application to connect to such an identity provider component, it is typical that no more is needed than to obtain some access token from a website that the identity provider has.

The federated view extends this to identity providers that by default cannot be accessed by such applications. What is needed is an agreement between the parties that provide the identities, and the parties that consume them (for authenticating their users). This agreement implies the technical enabling the querying and provisioning of user-related data in both identity provisioning components and application components, not just for technical interoperability, but also to accommodate for other provisions in the agreement (e.g. identity attributes being exchanged, the related technical formats/syntax, etc.). The set of parties that have committed to the agreement is called an identity federation.

In this view, users will typically register at one of the identity providers, and can use this to log into arbitrary applications of participating parties, and such parties may request and obtain more identity data than just the user(name). This setup becomes even more effective and user-friendly by also applying SSO mechanism. A typical example of federation is in the educational realm, where different universities and other research institutes agree to ‘federate’, i.e., allow users registered at one such party to use its credentials when accessing an application (or network) at another party’s premises. Typical identity protocols that are used include SAML, and OpenID-Connect.

The decentralized view isn’t just one view - there are various ones. , it is assumed that

1. Decentralized Identity Management:

   • Decentralized identity management gives users more control over their identities by eliminating the need for a central authority.

   • Users have self-sovereign identities that are stored on personal devices or in distributed systems like blockchain.

   • Users can selectively disclose identity attributes without revealing the entire identity.

   • It allows for greater privacy and user autonomy.

   • Examples include blockchain-based identity systems like Sovrin or uPort.

It's important to note that the specific implementations and architectures can vary within each approach, and there may be hybrid models that combine elements of centralized, federated, and decentralized identity management.

2.6.6. Identity Federation

Federation is a trust domain in which parties (organizations) have their own IdP services, and users (individuals) typically belong to one such party (their 'home'). The governance/trust framework within a federation arranges what is usual for a trust domain, as well as that it ensures that users that belong to one party can access services of other parties, by logging in with their 'home' credentials.

TO BE FURTHER ELABORATED

2.6.7. Identity Federation

Federation is a trust domain in which parties (organizations) have their own IdP services, and users (individuals) typically belong to one such party (their 'home'). The governance/trust framework within a federation arranges what is usual for a trust domain, as well as that it ensures that users that belong to one party can access services of other parties, by logging in with their 'home' credentials.

 

2.6.7. Authorization

The right or duty that a party has to perform some act can come from any of the following sources:

1. it is specified in an applicable law, regulation, policy, or other text that is authoritative in the data space.

2. it is mandated by a party (the mandator) that already has that right or duty. The mandatee can exercise the right or duty, while the mandator remains responsible for acts executed under that mandate. The mandator can change or revoke the mandate at any time. A mandate typically comes with instructions or other guidance that the mandatee is expected to follow.

3. it is delegated by a part (the delegator) that already has that right or duty. The delegatee that exercises that right or duty is responsible (accountable) for acts executed under that delegate. When a right or duty is delegated, the delegator no longer has that right or duty. It can, however, revoke the delegate, after which it has the right or duty again.

As Hohfeld (see, e.g., Legal Rights in the Stanford Encyclopedia of Philosophy) noted, rights and duties are a relationship between one party that has the right or duty, and another one that has a corresponding duty or right. For example, if I have the right to transfer money out of a bank account, that is a right I have towards the bank that manages that account. This right has a corresponding duty for the bank towards me, which is to enable me transferring money out of that account.

The relevance of this for data spaces is that rights or duties cannot be simply assigned or transferred by one party towards another; the ‘third party’, i.e. the party towards whom the rights or duties can be exercised, must also be included in the equation.

Authorization is the act of granting a right or duty to some party for the execution of some action, such as accessing a resource. Authorization must include the enablement of the grant, which consists of making sure the right or duty can be exercised. It is what the DSGA does when it creates and maintains policies for its members, and what the DSGA and the members can do with the rights or duties that they have, and that are mandatable or delegatable.

Identity Registries can facilitate this by having the DSGA or appropriate Identity Governors determine:

• how to register such rights and duties (mandates, and delegates) in a record of an entity that has such rights or duties, and

• what policies identity managers need to follow as they register and maintain the various rights and duties of entities in their registries, and ensure each right or duty comes with the corresponding duty or right (as per the Hohfeld model.

• how parties that have (mandatable or delegatable) rights and/or duties, can mandate or delegate them to others, such that the parties towards which these rights and/or duties are exercised, become aware of these mandates/delegates.

2.7.                 Open Challenges – Future Roadmap

This section highlights any open challenges or future directions for the data space building block, including potential improvements. Potential challenges for a building block may arise in its interactions with other building blocks, making compliance a crucial consideration. This section should provide an overview of potential challenges and opportunities for future development of the building block.

2.8.                 Conclusions

Short statements about the current state-of-the-art, how this matches with the defined requirements and functionality (gap analysis), and some final remarks.