DOME Technical Architecture

• 1: Overview
• 2: Data Model
• 3: Catalog Replication
• 4: BFT Event Bus
• 5: Digital Identity
• 5.1: The LEARCredential
• 5.2: Authentication
• 5.3: Powers
• 5.4: Access Control
• 6: Service Certification
• 7: Company registration
• 7.1: Overview
• 7.2: LEARCredential (digital process)
• 7.3: LEARCredential (manual process)
• 7.4: Powers of Representation

1 - Overview

The DOME ecosystem consists of a set of federated marketplaces, replicating the catalogue data among them in a secure way.

The diagram below provides an overview of the core components of DOME.

In July 4th 2024, DOME entered into production with a single marketplace instance operated by the DOME Consortium (the dotted rectangle on the left). In the coming months it is expected that other instances of marketplaces, operated by different entities, will start integrating and federating among them to create the DOME ecosystem (one of those federated instances is shown on the right of the diagram).

The replication of catalog data is implemented with a layered architecture:

Marketplace Business layer

Even though the different instances may use natively different data models, they have to agree on a common data model and semantics. DOME uses the standard TM Forum’s Open APIs and associated data model.

TM Forum Open APIs have been widely adopted by the industry as a standard interoperability method, with more than 640,000 downloads by 39,000 software developers from 2,500 organizations.

Over 70+ REST-based, Event driven and Domain Specific Open APIs have been collaboratively developed by TM Forum members working within the Open API project. This team creates a full set of Open API assets for members to implement Open APIs - from guidelines (REST API Design Guidelines), to specification, to usable code, through to the compliance test kits - see the Open API directory for more details.

Catalog Replication layer

This is where the actual replication of the data happens. All instances have a store with the relevant catalog data in the standard TM Forum format. The replication logic in each instance talk to each other with the help of a byzantine fault tolerant Publish/Subscribe event bus implemented by the lower layer.

Trusted Publish/Subscribe layer

This layer implements a Publish/Subscribe event bus, where the lifecycle events of the relevant catalog objects are managed. For example, when a new product offering is published in one of the instances of the marketplaces, an event is published in the bus. All other instances which are subscribed to that type of event will receive the event and if the necessary conditions are met, the replication logic in that instance will retrieve the associated data from the origin instance.

The Publish/Subscribe event bus is Byzantine Fault Tolerant (BFT), which means that is continues working even in the presence of malicious actors who control one or more servers in the infrastructure (up to a given threshold given by the actual properties of the infrastructure).

2 - Data Model

In a decentralised federated ecosystem like DOME, interoperability is a key requirement because we need the different marketplace instances in the DOME ecosystem to exchange catalog data and use the information for their users.

To achieve that, it is useful to think of interoperability at different layers:

• Trust and digital identities level. A prerequisite for the exchange of data in DOME is that all participants trust to each other with a given level of assurance, and that they use a common digital identity system so they know who is who.

• Data model and semantic level. If the participants do not share a common semantic data model, it is extremely difficult to engage in automated and efficient data exchanges.

• Technical communications mechanisms level. Eventually, data must be echanged via common communication mechanisms, and the parties must agree on the standards used on this level to be able to connect and exchange the data.

We are interested in this section on the data model and semantic level, as the following figure describes.

In the DOME ecosystem, each marketplace instance uses most probably a different data model, depending on the actual implementation of the marketplace software. Trying to force all marketplace operators to use a single software for their marketplace instances is not reasonable.

There are many implementations of marketplaces out there, some of them Open Source. Of course, each implementation has its own data model, with varying degrees of sophistication. However, we have found that trying to use the data model defined by one of those implementations is also not reasonable.

In DOME we have chosen to focus on the data model, not on the software implementations of marketplaces. Instead of inventing the wheel, we wanted an existing data model:

• designed by a community as large as possible, with proper governance model
• suited for marketplace catalog data
• focused on open data models and open APIs for interoperability across complex heterogeneous ecosystems
• as mature as possible, and as widely adopted as possible, with as many different implementations by different entities as possible

We chose the TM Forum’s Open API project, which complies with all those requirements, and there is a big community around the data model and related APIs. See for example the dashboard for July 2024 in the figure below.

For the replication of catalog data, we use in DOME a subset of the whole set of TM Forum APIs, specifically the ones related to the Product APIs, as described below.

The following diagram provides a simplified description of the main entities involved in the actual data model used. The model has provisions for extensions, and in DOME we have made use of that extensibility to implement things related to Verifiable Credentials and trusted replication, for example.

3 - Catalog Replication

4 - BFT Event Bus

5 - Digital Identity

5.1 - The LEARCredential

The LEARCredential is a machine-readable legal document representing an electonic Mandate (known also as Company Authorization Letter). In this context, the term Mandate is used to describe the concept of delegating specific permissions and powers to an employee of an organisation, enabling that employee to act on behalf of the company in a specific set of matters or tasks. We explicitly focus on the business environment and do not cover natural persons acting as citizens.

Instead of inefficient and insecure paper or PDFs, in DOME we use Verifiable Credentials to represent an eMandate. Given that we are in the EU, in DOME we use eIDAS electronic signatures or seals to make the credential a legal document with higher legal certainty than using other types of digital signatures (for example, a qualified electronic signature has in the EU the same legal validity as a handwritten signature).

In DOME, the specific powers being delegated are related to the interaction of an employee of an organisation with DOME, for example to authorise the employee perform onboarding or creating a Product Offering in the marketplace.

The LEARCredential (Legal Entity Authorised Representative Credential):

• is a Verifiable Credential that a legal entity (an organisation) issues to an employee (or subcontractor),
• includes the list of specific powers (or authorisations) that are delegated to an employee, so the employee can act on behalf of the legal entity
• can be used also as an authentication mechanism, eliminating the need for passwords or complex identity management systems
• the receiver of the credential can perform access control using the powers that are included inside the credential.

The figure below describes a high-level view of the LEARCredential.

The data model of the LEARCredential is based in the RPaM-Ontology, which is a project started in 2018 by the Directorate-General for Informatics (DG-DIGIT) of the European Commission, funded by the ISA Programme, to organise and support the development of an ontology about the Representation of Powers and Mandates, from now on the RPaM Ontology.

We adapt the results of that project, with simplifications and specialisations, to the concrete environment where we use the LEARCredential. To facilitate the job of the reader of this document, in some sections we copy literal sentences from the RPaM Ontology project, and adapt the texts to our requirements. However, the reader is encouraged to access the original documents for more details and understand the original approach, including the RPaM Ontology Glossary.

The Trust Framework for the LEARCredential

The LEARCredential is based on the existing eIDAS (electronic Identification, Authentication and Trust Services).

The eIDAS Regulation established the framework to ensure that electronic interactions between businesses are safer, faster and more efficient, no matter the European country they take place in. It is a European Regulation that created one single framework for electronic identification (eID) and trust services, making it more straightforward to deliver services across the European Union.¹

The main eIDAS trust services that DOME relies on are the Electronic signature (eSignature) and the Electronic seal (eSeal). An eSignature is the expression in an electronic format of a person’s agreement to the content of a document or set of data. Qualified eSignatures have the same legal effect as hand written signatures. An eSeal is similar in its function to the traditional business stamp. It can be applied to an electronic document to guarantee the origin and integrity of a document.

In DOME we accept both for the creation of a LEARCredential. For the rest of the document we will use the term electronic signature to refer to both, except when the difference is important for the objectives of the explanation.

The figure below describes at a high level how an organisation can create a LEARCredential in a self-service way, when the legal representative of the company has an eIDAS certificate. The process is essentially the same as when electronically signing a PDF. Instead of using a computer program that can sign PDFs (e.g., Acrobat Reader), the legal representative uses a program that can generate and sign Verifieble Credentials. In DOME we provide such a program, just in case an organisation dees not yet have its own. In addition, for organisations that are lagging in digitalisation and do not still have an eIDAS certificate (can not use electronic signatures), DOME also provides a third-party creation and signature process that can be used in the meantime.

The Mandate

According to the RPaM Glossary, a “mandate is a record that describes the terms under which a mandator grants a representation power to a mandatee”.

In DOME, the mandate is composed of three related objects: mandator, mandatee, power and signer. The mandate object is signed or sealed with an advanced or qualified signature or seal using an eIDAS certificate.

Mandator

The object mandator identifies the employee of the company who is delegating a subset of her powers on the mandatee.

The mandator is either:

• a legal representative of the company, according to the official records associated to the incorporation of the organisation (e.g., the business registry of the country of incorporation); or

• an employee who is a mandatee in another mandate where the mandator is a legal representative of the company. We do not support more than two levels of delegation.

Mandatee

The mandatee is the person granted with the power to represent (and act as) the company in some specific actions with third-parties. The powers granted to the mandatee must be a subset of the powers of the mandator. For example, an employee (the mandatee) can be empowered by the legal representative of the company (the mandator) to perform the onboarding process in DOME.

The object mandatee identifies the employee on whom a subset of powers is delegated. The mandatee object contains:

• A set of attributes of the employee which are required by the specific use case where the LEAR Credential will be used, for example to onboard in the DOME ecosystem and for creating a ProductOffering in the marketplace. Those attributes can be considered equivalent to the fields that would be filled in a form when a “classical” PDF document would be used to authorise an employee.

• A public key associated to the employee and where the employee is the sole controler of the associated private key. This is required to enable the use of the LEARCredential containing the mandate as an efficient, scalable and secure authentication and authorisation mechanism.

The private key controlled by the employee is used to prove to Relying parties receiving the LEARCredential that the holder and presenter of the credential is the same person identified in the mandatee object. We support two mechanisms for the public key in the mandatee object:

• Using a did:key where the employee controls the private key associated to the did:key.
• Using an eIDAS certificate owned by the employee.

Signer

The Signer is either the Mandator or a third-party that attests that the Mandator really delegated the powers to the Mandatee. The Signer is the entity that performs an advanced or qualified signature or seal using an eIDAS certificate.

The Signer is the entity that has to be trusted by the receiver of the LEARCredential.

Power

This object is a list of each specific power that is delegated from the mandator to the mandatee. The powers must be concrete and as constrained as possible, and must follow a taxonomy with the semantics well specified.

In DOME, we have specified a power taxonomy targeted at the interactions with the DOME Federated Marketplace. This means that the actions are well defined, homogeneous and standardised for the ecosystem. We are basically replacing the current mechanisms for Mandates (e.g., paper or PDF) with a more efficient, machine-processable representation in the form of a Verifiable Credential.

Our Power Taxonomy could be generalised to other actions involving private sector companies, but it is out of scope of this version of the document.

This object is an array where each element is a power that is delegated from the Mandator to the Mandatee. The fields of each power object are:

• id: REQUIRED. The identifier of the power, which must be unique in the context of the Credential where it is included. It can be used as a reference when performing access control, for example in the audit records to identify the specific power that was used to grant access to some protected resource.

• powerSource: OPTIONAL. The Mandator draws the power from one (or more) sources of power, e.g., 1) a concrete Legislation; 2) a piece of evidence (as another Mandate, in which case the mandator was a mandatee in that other mandate) and/or 3) a Natural Person with a specific profession that invest him/her with the authority to order to a mandator with a specific role the creation of a mandate, e.g. a judge authorising a civil servant (a Mandator that is a Natural Person with the appropriate role) to create a mandate for a relative to represent an incapacitated person).

  In DOME, there are three cases with specific sources of power:

  • When the Mandator is a legal representative of the company, and the LEARCredential is signed with the eIDAS certificate of representation of the legal representative. In this case, the powerSource claim can be ommitted as it is implicit in the eIDAS signature. Alternatively, the powerSource claim is an object with the following fields:

    • type, with value eulaw.
    • evidence, with value “https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32014R0910”.

  • When the Mandator is a natural person who is the Mandatee in another LEARCredential. The powerSource claim is an object with the following fields:

    • type, with value LEARCredential.
    • format, with the value jwt_vc_json.
    • evidence, with the LEARCredential where the Mandator is a Mandatee, in jwt_vc_json format.

  • When the Mandator is a legal representative of the company, but does not have an eIDAS certificate of representation, the Mandator can not sign the LEARCredential. In this case, there must be a trusted third-party which attests that the Mandator is effectively a legal representative of the company. This trusted third-party must perform the required due diligence to confirm the relationship, and then sign the credential with its eIDAS certificate.

    In DOME, one of the trusted third-parties (trusted by DOME) is the DOME Operator itself, where the employees dedicated to the onboarding of participants perform the manual checks on the documentation provided by the Mandator/Mandatee, and then create and sign the LEARCredential.

    In this case, the powerSource claim is an object with the following fields:

    • type, with value attestation.
    • evidence, with value the eIDAS certificate of the attester.

    In this case, the mandate object must contain an additional object called attester, identifying the entity that makes the attestation and with the same fields as the mandator object in the case where the Mandator signs the LEARCredential with an eIDAS certificate.

• tmf_type: The type of power, which in DOME may be:

  • Domain: The mandatee has access to the services provided by one or more organisations where the services have been classified as belonging to that domain. Access to the services is subject to the restrictions defined by action and function below. The classification of services is arbitrary and is defined by the service providers. A typical scenario is when some service providers agree on a classification of the services that they provide collaboratively in the context of an ecosystem (like DOME), and the possible domains are made public, including the mapping to a given set of services in each provider.

  • Organization: The mandatee has access only to the services provided by one or more organizations, identified specifically in the power.

  Other types of powers can be defined, making the system extensible.

• tmf_domain: Required when the tmf_type claim has the value Domain or Organization. It is an array with the names of the Domains or Organisations where the Mandatee is authorised to interact with this Mandate.

  The names must be unique (e.g. via a namespace) to avoid potential clashes in different ecosystems.

  In DOME, for the powers of onboarding in DOME and for creating a ProductOffering, the tmf_domain claim must be an array with a single item with the value DOME.

• tmf_function: A string specifying the name of the function that the Mandatee can perform. The definition of the possible functions is done by the Verifier (the entity with which the Mandatee will interact with the LEAR Credential).

  In DOME, two essential functions for Cloud Service Providers (CSP) accessing the marketplace are Onboarding and ProductOffering, which enable the Mandatee to use the services provided by DOME to onboard organisations in the ecosystem and (if it is onboarded previously) to create a ProductOffering, respectively.

• tmf_action: An array with the concrete actions belonging to the function that the Mandatee is allowed to execute.

  In DOME, the possible actions for CSPs accessing the marketplace are:

  • Execute when tmf_function is Onboarding.
  • Any combination of Create, Update and Delete when tmf_function is ProductOffering.

5.2 - Authentication

DOME uses Verifiable Credentials for authentication and access control of the users interacting with the DOME services.

In this document we describe how you can integrate the DOME authentication mechanism in your own applications. It is very easy.

You do not need to know the underlying technical details to use it, but if you are interested you can look here.

There are two types of users that can authenticate to DOME services:

• Employees of companies using DOME services. We call this the Human-to-Machine (M2M) flows.
• Applications or machines owned or operated by an organisation, accessing the DOME services. We call this the Machine-to-Machine (M2M) flows.

We first explain the H2M flow: how your application can authenticate employees of companies (including your own company, of course). Later we describe the M2M flow.

Human-to-Machine (H2M) authentication flow

DOME provides a component called the VCVerifier which makes very easy for applications to integrate authentication with Verifiable Credentials. If the application programmer knows how to use Social Login, then she already knows who to integrate authentication with Verifiable Credentials.

For the Application, the VCVerifier is just an OpenID Provider (OP), connecting to it using the standard OpenID Connect protocol.

The Application does not need any knowledge about how to talk to the Wallet to receive the Verifiable Credential from the user. This complexity is hidden from the application by the VCVerifier. The Application never talks to the Wallet, only to the VCVerifier.

Once the VCVerifier has received the Verifiable Credential from her Wallet and performed a set of verifications (according to a defined policy), it sends to the Application both the Verifiable Credential and an Access Token that the Application can use to access protected resources as in any other OpenID Connect flow.

Parameters of the VCVerifier

You have to tell your Application some things before it can talk to the VCVerifier.

When talking to the VCVerifier, your Application MUST use the OIDC Authorization Code Flow. No other OIDC flows are supported.

Your Application must use the following endpoints of the VCVerifier during the flow:

• Authorization Endpoint: https://verifier.dome-marketplace-prd.org/auth
• Token Endpoint: https://verifier.dome-marketplace-prd.org/token
• UserInfo Endpoint: https://verifier.dome-marketplace-prd.org/userinfo

Starting the Authentication Request

Before any authentication can take place, your Application has to be registered with the VCVerifier. This is done during the onboarding process in DOME, or at any time later, contacting the onboarding team.

As part of the registration, you will receive a Client Identifier and a Client Secret, that your Application must use according to the OIDC standard.

Typically, you will display to the user a Login button, and when the user clicks the button, your Application will redirect the user to the VCVerifier, passing some parameters as per the OIDC specifications. This is called an Authentication Request.

The following is an example HTTP 302 redirect response by the Application, which triggers the browser of the user to make an Authentication Request to the Authorization Endpoint of the VCVerifier (with line wraps within values for display purposes only).

HTTP/1.1 302 Found
Location: https://verifier.dome-marketplace.org/auth?
    response_type=code
    &client_id=did:key:wejkdew87fwhef9833f4
    &request_uri=https%3A%2F%2Fdome-marketplace.org%2Fapi%2Fv1%2Frequest.jwt
    %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
    &state=af0ifjsldkj&nonce=n-0S6_WzA2Mj
    &scope=openid%20learcred

Note the following:

• The Authentication Request MUST use the Authorization Code Flow, by specifying response_type=code. This means that all tokens (including the claims of the Verifiable Credential) are returned from the Token Endpoint.

• The client_id is the one assigned to your Application when registered in the VCVerifier.

• The Authentication Request MUST include the scope learcred, which tells the VCVerifier that the Application is requesting a LEARCredential (the one used in DOME for authentication). This scope is added to the OIDC compulsory scope openid.

• The Authorization Request MUST use the request_uri parameter which enables the request to be passed by reference, as described in section 6.2. Passing a Request Object by Reference of the OpenID Connect spec.

• state is used by your Application to match this request with the future reply, in order to support multiple users at the same time.

Receiving the Verifiable Credential in your Application

After the execution of the Authorization Code Flow, your Application can receive the Verifiable Credential in two ways:

• As an additional claim in the Access Token from the VCVerifier Token Endpoint. When your Application calls the Token Endpoint, it receives a normal access token which includes the claim verifiableCredential, which is the LEARCredential in JSON format.

• As an additional claim in the response from the Userinfo endpoint. The claim name is the same as in the access token: verifiableCredential.

The contents of the LEARCredential can be used by the Application to perform not only authentication but also authorization (access control). For example, using the Powers of the User which are included in the LEARCredential.

Machine-to-Machine (M2M) authentication flow

The VCVerifier component of DOME support also the M2M flows. The figure above shows a server application using the VCVerifier to exchange a Verifiable Credential for an Access Token, and then using the token to access protected resources. The M2M (machine-to-machine) flow for authentication is simpler than the one for H2M, because there is no user authentication involved.

The credential used by the Application for authenticating to the VCVerifier is the LEARCredential that was generated for the Application when registering it to the VCVerifier (the same process as in the H2M flow).

The M2M flow uses the Client Credentials Grant, following the OAuth 2.1 IETF draft (12 July 2024), which among other things takes into account the OAuth 2.0 Security Best Current Practice and consolidates several new RFCs that are relevant for our use case.

Authenticating and receiving an Access Code

The M2M flow uses a Token Endpoint specifically for M2M:

• M2M Token Endpoint: https://verifier.dome-marketplace-prd.org/token_m2m

This is an example request to the M2M Token Endpoint:

POST /token_m2m HTTP/1.1
Host: verifier.dome-marketplace.org
Content-Type: application/x-www-form-urlencoded

    grant_type=client_credentials&
    client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
    client_assertion=eyJhbGciOiJS[...omitted for brevity...]cC4hiUPo

The M2M flow MUST use the Client Credentials Grant (grant_type=client_credentials), because there is no user involved.

For authentication, the Application MUST use the private_key_jwt method, as described in section 9. Client Authentication of the OIDC standard.

The value of the client_assertion_type parameter MUST be urn:ietf:params:oauth:client-assertion-type:jwt-bearer, and the authentication token MUST be sent as the value of the client_assertion parameter.

The authentication token is created by the Application using the LEARCredential. The JWT in the client_assertion contains:

• iss: REQUIRED. This MUST contain the client_id of the OAuth Client, which is the did assigned to the machine in the LEARCredential of the machine. For example did:key:wejkdew87fwhef9833f4

• sub: REQUIRED. This MUST contain the same value as the iss claim.

• aud: REQUIRED. The aud (audience) claim MUST contain the URL of the VCVerifier’s M2M Token Endpoint (https://verifier.dome-marketplace-prd.org/token_m2m). The value shall be sent as a string, not as an item in an array.

• jti: REQUIRED. JWT ID. A unique identifier for the token, which can be used to prevent reuse of the token. Ideally, these tokens are used once. Given the very low value of the expiration time of the JWT (see below), the cache of already used jti claims can be held in memory, because an expired JWT MUST not be accepted even if the jti has not been seen before.

• exp: REQUIRED. Expiration time on or after which the JWT MUST NOT be accepted for processing. In a M2M flow, this JWT is used only once and the client generates the JWT immediately before using it to call the token endpoint of the VCVerifier, with no human intervention or intermediate complex processes. The expiration time MUST be set as low as possible while allowing network delays, the major component that may affect this parameter. For example, 10 seconds, which is more than enough in most situations. In case of bad network conditions, the authentication can be retried with a new JWT. This is important for Replay protection, while simplifying management of unique jti claims in VC Verifier.

• iat: OPTIONAL. Time at which the JWT was issued.

• verifiableCredential: REQUIRED. This MUST contain the LEARCredential in JWT format.

The authentication token MUST be signed with the private key associated to the did:key uniquely associated to the machine/application calling the M2M Token Endpoint, which MUST be the same as the did:key inside the LEARCredential in the verifiableCredential claim of the authentication token.

If the VCVerifier authenticates correctly the Application, it answers with an Access Token as described in section 3.1.3.3. Successful Token Response of the OIDC specification.

5.3 - Powers

5.4 - Access Control

6 - Service Certification

Verifiable Certifications are required for trusted decentralised replication

Verifiable Certifications and Gaia-X

The process for obtaining a Verifiable Certification

The future is all digital

But the present includes manual processes

7 - Company registration

Before your company can create a Product Offering in the DOME Marketplace, it has to be registered as a Participant in the DOME ecosystem. The process of registering the company in a trusted way is called onboarding.

The onboarding process must be performed by a natural person, normally an employee of the company acting on behalf of the company.

A common problem in decentralised ecosystems is how organisations can onboard the ecosystem in a trusted and automated way, avoiding manual paperwork. DOME implements an efficient and secure mechanism to onboard companies which are in the digital age, by leveraging the powers of standard eIDAS certificates.

For companies which can not digitally sign electronic transactions according to the eIDAS framework, DOME provides the manual processes (slower and more cumbersome) that enable those companies to onboard DOME.

7.1 - Overview

7.2 - LEARCredential (digital process)

Go to the DOME Issuer portal

The DOME Issuer portal is located at https://dome.mycredential.eu/ and below is an image of the screen.

The site is intended for Legal Representatives of companies who want to issue one or more LEARCredentials to one or more employees of the company. A LEARCredential is a type of Verifiable Credential which enables an employee, nominated by a legal representative, to act on behalf of an organisation with restricted powers with respect to third-parties.

The issuer (the creator) of the LEARCredential must be a legal representative of the company. The legal representative will sign the LEARCredential with an eIDAS digital certificate, which can be either a personal one or a certificate of representation.

The receiver of the LEARCredential (both the subject and holder of the credential) can be any employee (or contractor) of the company. The legal representative will delegate a restricted set of powers to that person. Those restricted powers are included inside the credential and can be verified by any Relying party to whom the holder presents the LEARCredential.

If you are a legal representative of the company and you have an eIDAS certificate installed in your PC, click on the yellow button to start the process:

Select the eIDAS certificate to use

Once you click the button, you will be directed to the page of the DOME Issuer to start creating LEARCredentials.

The browser will request that you select the certificate to use, with a screen like the following:

Register for the service

The first time you enter, you must register and verify your company email, using the following screen.

Enter your email address and click the button “Register (if this is the first time)”.

You will receive an email requesting confirmation, which is needed before you can logon in the system.

If you do not receive the email (from support@mycredential.eu), please check in spam just in case your email client has automatically classified it as spam.

Once you have verified your email you can logon in the system using the same screen as above.

List of LEARCredentials

After logging in for the first time, you will see an empty screen like the following. Click on the button to create a new LEARCredential.

LEARCredentialForm

A form to fill the data of the LEARCredential appears, like the following:

The form has the following sections:

Mandator

The Mandator is the person delegating a restricted set of powers onto an employee (the Mandatee). This part of the form is pre-filled with information coming from the eIDAS certificate that was used to enter into the application, plus the email address that was registered and verified.

You do not have to enter anything else in this section.

Mandatee

The Mandatee is the employee (or subcontractor) who receives a restricted set of powers to act on behalf of the company with third-parties. In our case, the employee will be empowered to perform the Onboarding process in DOME, and maybe to create Product Offerings in the Marketplace.

You have to fill the data corresponding to the employee that you want to nominate to perform the Onboarding process. After creating the LEARCredential, the employee will receive a notification in the email address that you entered in the form.

Powers

These are the specific powers that the Mandator (you) is delegating on the Mandatee (the employee).

The LEARCredential is a general purpose electronic Mandate, but in our case we need only two powers:

• Execute the Onboarding process in DOME
• Create/Update/Delete one or more Product Offerings in the DOME Marketplace

You can assign each power to a different employee (with one LEARCredential for each employee), or both powers to the same employee (with one LEARCredential including both powers). You can even generate more than one LEARCredential with the same or different powers to one or more employees. This is up to you and how you want to distribute the powers among your employees.

The Mandate in the form of a Verifiable Credential bechaves like its paper counterpart with regards to these properties.

For Onboarding, make sure that the employee receives at least the Onboarding power:

Create a first version of the LEARCredential

Press the “Create” button at the bottom of the form. This will take you to a screen with the machine-readable representation of the new LEARCredential. Do not worry, you do not have to understand this, but if you do (or somebody in your company) it is a good way to see the actual contents that will go inside the LEARCredential, before sending it to the employee.

Click the button at the bottom of the screen to save the draft version of the credential and send a notification to the target employee via email.

List of created LEARCredentials

You are taken back to the list of LEARCredentials that you have created. If this is the first time that you have created a credential, thee screen looks like the following.

The button “View” at the left of every item allows you to review the credential, and also to send a reminder email to the target employee, in case the employee has not yet retrieved the credential.

LEARCredentials have three states:

• offered: A draft version of the credential has been created with all required information about Mandator, Mandatee and the Powers of Representation. A notification via email has been sent to the employee who will receive the powers. The name offered denotes that the employee has to accept the credential and load it to the Wallet of th eemployee.
• tobesigned: The employee has accepted the LEARCredential, after reviewing the information contained in it. This step is necessary because the LEARCredential contains cryptographic material which will allow the employee to authenticate to DOME, and that cryptographic material can only be generated by the Wallet of the employee, to ensure the solo control of the private key.
• signed: After the employee accepts the credential, you have to sign it with your eIDAS certificate. After your signature, the credential is signed and ready to be loaded by the employee in her Wallet and use it.

The employee reviews and confirms the LEARCredential

The employee receives an email notification like the one below.

When clicking on the button, the employee is directed to the DOME Issuer portal to review and (possibly) confirm the LEARCredential.

The screen that the employee sees is similar to the one below.

7.3 - LEARCredential (manual process)

7.4 - Powers of Representation