eSSIF-Lab Infrastructure Functional Components

This section details the functional specifications of the components that are in scope of the eSSIF-Lab infrastructure, i.e. in the green (rounded) rectangle as shown in the figure below:

eSSIF-Lab functional components that are part of the eSSIF-Lab infrastructure

Figure 2: eSSIF-Lab infrastructural (functional) components.

3.1. Transaction (Validation) Engine and Validation Policy

The purpose of the Transaction (Validation) Engine (TVE) is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an agent of) its owner to decide whether or not to engage in a (new) transaction of the specified type.

Typically, the TVE would start a transaction either

  • when it receives a request from some agent of another party for engaging in a transaction of a specific kind.
  • when it is instructed by, or on behalf of its owner, to request a specific kind of transaction to some agent of another party.[TVE.1]

In either case, a transaction form (object, context) has to be created that matches the kind of transaction, and a ‘transaction-id’ must be generated that identifies this form/object/context. It will be used for binding incoming or outgoing messages to this transaction, enabling communications to remain congruent, not only with the agent that requested the transaction, but also with other agents from the same owner and/or using different communications channels.

Handling/managing the various communications channels through which data can be exchanged is also a task of the TVE[TVE.2]. One reason for this is that negotiating a transaction not only requires data to be acquired, but also to be provided to the peer participant. Another reason is that the peer participant may use multiple agents to provide such data, e.g. human agents (that might use web-browsers, social-media apps, phones, or physical visits), SSI agents (that use the SSI infrastructure), or other electronic agents (e.g. services that can provide data when appropriate permissions are submitted - e.g. user consent tokens).

Thus, the TVE is generally considered capable of obtaining data through different communications channels. However, the technical tracks of eSSIF-Lab will exclusively focus on the communications channel through which credentials can be requested and obtained. Any extensions or business productization of TVE designs may be considered in the business tracks of eSSIF-Lab. The latter is not considered any further in this section.

In order to acquire data through SSI mechanisms for filling in a form for a specific kind of transaction, the TVE needs to know what kinds of credentials it should ask for, which parties its owner trusts to issue such credentials, what kinds of verification proofs for such credentials must hold and which may be disregarded.[TVE.3] Also, when the TVE gets a credential that satisfies the necessary verification proofs, it needs a way to map the contents of that credential to the structure of the transaction context that is used internally by (other systems of) its owner.[TVE.4] Also, as the TVE gets more and more data - which it may get through multiple, different channels - it needs to determine whether or not the resulting set is sufficiently consistent and coherent.[TVE.5]

In order to make the TVE work, a Validation Policy (or TVE Policy) is created by, or on behalf of the owner, which specifies at least:

  • the kinds of transactions the owner is willing to (electronically) engage in, from both the requester and the provider perspectives;

  • for each such transaction type:

    • the criteria (business rules) that should be used to determine that the form is ‘clean’, i.e. that the necessary and sufficient data have been obtained and that they are consistent, coherent, and suitable for making a transaction commitment decision.

    • the kinds of credentials and issuers that the owner is willing to accept as sources for valid data; (optionally?), the endpoint URI at which issuing parties do the actual credential issuing may be specified[TVE.6].

    • for each kind of credential: the verification proofs that must hold to be accepted as a source for valid data.

    • the mapping between fields in such credentials and fields in the form to be filled in.

  • (anything else?)

The Policy must be designed in such a way that it is extendable as new features will be called for in the future.

The ability to create new transaction contexts and the availability of the TVE Policy enable the TVE to request the Verifier component of its owner to obtain credentials of the types that it can use to fill in the transaction form when they satisfy the verification and validation requirements of its owner. The specification of such requests is given in [reference needed].

When the Verifier returns such data (which comes with a list of proofs that the Verifier has checked), the TVE must then validate that data, i.e. determine whether or not it is valid for the specific transaction it is assembling the data for. The validation rules are party-specific and hence come from the TVE policy. For simple cases, validation can simply consist of checking whether or not all verification proofs succeeded. At the other end of the validation spectrum, the TVE itself must make validation decisions, either electronically (according to the TVE policy) or by ‘outsourcing’ such decisions to human agents of its owner by providing an appropriate validation user interface.

As long as data is needed, the TVE can intermittently request the verifier to produce it (or it can use other communications channels, which is outside scope for now). It does so until it times out, or the form has become ‘clean’.


[TVE.1] This feature ensures that the transaction is really two-way, and both parties can request credentials from the other. For example, a web-shop can then ask for a (delivery)address credential, and the customer can ask for a credential issued e.g. by the chamber of commerce that the web-shop is a legitimate company (and not some maffia website).

[TVE.2] It may well be that this functionality can somehow be split off in the (near) future.

[TVE.3] For high-value transactions, verification proofs are more important than for low-value transactions. This is to be decided by the owner of the TVE. An example from the physical world: in order to obtain a visa for China, it is required that your passport (credential) remains valid for 3 months after the end of your visit. But in order to identify yourself at the reception desk of a hotel, your passport may have expired several years.

[TVE.4] For example, a credential that contains an address uses a specific schema to specify addresses, e.g. the ‘PostalAddress’ as defined by schema.org. This schema differs quite a bit from that of Dutch addresses as defined by the official (authentic) Dutch Registration of Addresses and Buildings (BAG). It may also well differ from the structure of addresses that databases of the Owner have implemented. Mapping allows such cases to be accommodated for.

[TVE.5] Inconsistent or incoherent data is necessary for various purposes. First, it allows for correct further processing of the transaction. A non-existent postal code, or one that doesn’t match the delivery address, may hinder a fluent transaction processing, resulting in additional costs and processing times. Another purpose is the early warning or detection of possible fraud/abuse. Remember that part of the data is being asked for reducing transaction risk, and checking consistency/coherence of such data is part of the risk mitigation process.

[TVE.6] This enables the TVE to pass the endpoint URI on to the Verifier when it requests for such a credential, which in turn can send it to the holder of other parties enabling them to obtain the credential from that issuer endpoint if that other party does not have that credential in its wallet. The endpoint URI can in fact be put in the policy, because the (human) agent that creates/maintains the policy would need to know that the issuing party is actually issuing such credentials, what their contents means, etc., and hence is capable of tracking down the URI where that party issues the credentials.


3.2. Verifier Component, and its Policy/Preferences

The purpose of the Verifier component is to support the Transaction (Validation) Engine by providing it with a single, simple API that it can use to request and obtain data that it needs to produce a clean transaction form, as well as the results of checking verification proofs (this is also why it is called the ‘verifier’ component).

Typically, the TVE would ask the Verifier to provide a credential that it can use to fill in a (coherent set of) field(s) in the transaction form. It is realistic to think that credentials from different issuers - trusted by the Verifier’s owner - can be used for this purpose. However, it is also realistic that such credentials will not use the same credential definition - they might well use different schemes to provide such data. Therefore, the TVE should specify a list of pairs (credential-type, issuer) instances of which could all be used to provide the data it needs - which it can obtain from the TVE policy.

Then, the Verifier needs to know the address and protocol that it can use to reach a Holder component owned by the party that its owner is trying to negotiate the transaction with. The TVE specifies this as part of the request - and it can do so because it has received the original request, and does all communications channel handling.

Verifiers are not expected to handle every kind of credential (e.g. VC’s, ABC’s, etc.) that exists, but rather a specific subset. For (at least one of) the credential types, the Verifier can construct a so-called presentation request, i.e. a message that is specific for the credential type and/or associated protocol, which it can then send to the Holder’s address.

This request message should contain at least

  • the transaction-id, so that when it is copied into the associated response message, the latter can be associated to the transaction it belongs to. Also, it should contain the
  • the (credential type, issuer) pairs that may satisfy the request, and to each of these additional data, e.g. the URI of the endpoint where the issuer issues such credentials, the maximum age of the credential, etc.
  • meta-data that may be useful for the holder (or its owner), e.g. texts stating the purpose(s) for which the data will be used (GDPR Art. 5.1.b), or requesting consent (GDPR Art. 7.2) “in an intelligible and easily accessible form, using clear and plain language”.
  • a signature of the Verifiers owner, for the purpose of showing compliance with the GDPR (e.g. Art 28.3.h), and enabling the Holder’s owner to obtain proof that the Verifiers owner has violated the GDPR’s minimization principle asked for data for a particular purpose, which can be used in an argument in disputes about data minimization (GDPR Art. 5.1.c).
  • (anything else?)

The request message must be designed in such a way that it is extendable as new features will be called for in the future.

In order to make the Verifier component work, a Verifier Policy/Preferences object is created by, or on behalf of the owner, which specifies at least: [to be elaborated]

A response to this request (called a Presentation) will be obtained from a Holder component of the peer party. This response will contain a reference to the request, allowing the Verifier to combine them. The Verifier will then check that the data in the response is a credential that it has asked for (correct type/issuer), verify the proofs that are provided (predominantly the digital signature), and do some additional checks (e.g. whether or not the credential has expired, is revoked, and such).

Then, the verifier will send a message to the TVE, containing the transaction-id, the data it has received, and the results of the various checks.

3.3. Holder Component, and its Policy/Preferences

The purpose of the Holder component is to handle Presentation Requests that it receives from Verifier components (both of its own owner, and of other parties), and responding to such requests.

Typically, a Holder component would access its owners Wallet to check if it has a credential that it can use to construct a Presentation (=response) that satisfies the received request.

It may happen that the Wallet does not have such a credential. However, for every (credential, issuer) pair, the request should specify the URI that is capable of issuing such a credential. If or when the Holder Policy/Preferences permits this, the Holder then requests its owner’s TVE to initiate a new transaction that will get the credential from that issuer, for which a clean transaction form would then consist of one that contains said credential. The Holder would then store it in its owner’s Wallet, and then proceed to service the presentation request as if it had obtained that credential from its owner’s Wallet.

It may also happen that the Wallet has multiple credentials that satisfy the request, in which case the Holder must choose the one to use for constructing the presentation. Again, the Holder Policy/Preferences will specify how this choice needs to be made, and whether or not this can be done automatically by the Holder. If not, the Holder will need to provide for an interaction with a human colleague that will make such decisions.

In order to make the Holder component work, a Holder Policy/Preferences object is created by, or on behalf of the owner, which specifies e.g.:

  • whether or not credentials may be collected ‘on the fly’;
  • how to choose between credentials that all satisfy a presentation request (and whether the Holder can make such choices by itself, or whether or not human interaction is required);
  • the kinds of events and data to write to a holder-audit-log.
  • (anything else?)

3.4. Transaction Result Dispatcher and Issuing Policy

The purpose of the TRD component is to state the (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other parties. A special kind of result is the (provisioning of) a credential that its Owner already has created.

Typically, and at any point in time, parties are capable of expressing statements about entities that they know to exist. They could express statements about individuals, about themselves, the state of transactions, and so on. We will use the term ‘subject (of a statement of a party)’ to refer to the entity that this party knows to exist, and about whom/which the statement has been made.

We will use the term ‘subject-id (of a statement of a party)’ to refer to the representation that this party has chosen to use for referring to the subject in said statement. A subject-id must have the property of being an identifier within every administrative context that this party uses. It need not be humanly interpretable (and preferably is not).

Parties need to specify the kinds of credentials they are willing to issue, the class of entities (e.g. people, cars, organizations) for which it will issue them, and the information schema (structure) that it will use in credentials of such kinds.[TRD.1] This allows the TRD to construct data objects that conform to this information schema, and present it to the Issuer component for actual issuing.

The TRD Issuing Policy specifies the kinds of (linked-)data-objects that credentials may be created for. This allows the TRD to construct such a (linked-)data-objects for every subject-id that identifies a subject of the class for which a credential can be issued, which can subsequently be sent to the Issuer component that can turn it into a credential of a specific sort.

You can think of the TRD as the component that pulls all data together that can be put in a credential (e.g. in a passport), and the Issuer as the component that puts the data in an (empty) passport, and signing it so as to create the actual credential.

The TRD may either push credential data to the Issuer component, so that the Issuer always has up-to-date credentials, or it can wait until the Issuer requests credential data for the creation of a credential of a specific type for a specific subject.


[TRD.1] We assume/stipulate that the party maintains a credential catalogue that contains this, and other information about every kind of credential that it issues, and that such catalogues are available to other parties that want or need to use such credentials.


3.5. Issuer Component, and its Policy/Preferences

The purpose of the Issuer component is to issue ‘credentials’, i.e. digital constructs that contain

  • sets of (related) statements or claims (e.g. as produced by the TRD)
  • metadata (e.g. type of credential, date of issuing and expiration, endpoints, e.g. for revocation checking, credential definition, credential advertisements, credential enforcement policy, etc.)
  • proofs (e.g. a digital signature by which third parties can prove its provenance and integrity.

Another purpose that an Issuer might serve is to provide a means that allows any other agent that somehow has obtained a copy or presentation of a credential, to verify whether or not the data therein is conformant to the business administration of its owner. We will use the term ‘revocation service’ to refer to such means. Whether or not an Issuer provides such a service, and what kind of revocation service is provided (e.g. a revocation list, an online revocation status protocol, etc.), is a decision that its owner should make, and specify in the Issuer Policies/Preferences.

An Issuer component may issue credentials in various formats, e.g. as a Verifiable Credential (VC), an Attribute-Based Credential (ABC), an OpenID Connect/JWT token, etc. The issuing party must specify credential-types in such a way that if the same credential is issued in different formats, it is possible for an arbitrary Verifier to determine whether or not two credentials that have different formats, are in fact the same. One way of doing this is that the Issuer generates an identifier for every credential that it constructs (before expressing it in a specific format).

After the issuer has created a credential (in one or more formats), it checks the wallet to see if it contains a credential of the same type for the same subject. If (one or more formats) are there, and their contents are the same as the newly created credential, the existing ones are revoked, deleted and/or archived/tombstoned.[Issuer.1] Then, the newly created credential is added to the wallet (in one or more formats). Thus, at any point in time, the wallet will contain an actual set of all credentials that have been issued.[Issuer.2]


[Issuer.1] Tombstoning is a mechanism that is used e.g. in (distributed) ledgers that do not allow for actual deletion, such as blockchains, by marking entries in the ledger as ‘being deleted’ (i.e. adding a ‘tombstone’ to such entries).

[Issuer.2] This allows e.g. individuals, that have an Issuer component in their SSI app, to issue self-signed credentials and provide them to verifiers that request them as usual for non-self-signed credentials.


3.6. Wallet Component, and its Policy/Preferences

The primary purpose of the Wallet Component is to (securely) store data, and in particular:

  • credentials - both those that have been issued by the issuer (i.e. self-signed credentials) and those that have been obtained from issuers of other parties, and
  • (private) keys e.g. for signing/sealing data on behalf of its owner.
  • [anything else?]

Other kinds of data may be stored by a wallet as well - we will have to see what is practical and makes sense.

By ‘securely storing data’ we mean that such data

  • remains available until a request is received from an electronic colleague that is entitled to request deletion of such data;

  • remains unchanged during the time in which it is stored;

  • can only become available to electronic colleagues that implement a functionality that requires such access (e.g. a colleague Holder component);

  • can only be stored by electronic colleagues that implement a functionality that require such data to be stored (e.g. a colleague Holder or Issuer component).

It is expected that components other than the Holder and Issuer will (arise and) need access. One example could be a component that is capable of securely signing data on behalf of the owner. Another example could be a component that implements some kind of credential revocation functionality.

Human Beings cannot directly access any Wallet component, not even the ones they own. They need an electronic agent that is capable of authenticating them as (an agent of) the party that owns the Wallet component, and upon successful authentication provides a User Interface through which the Human Being can instruct this electronic agent to manage the Wallet’s contents.

In order to make the Wallet component work, a Wallet Policy/Preferences object is created by, or on behalf of the owner, the contents of which remains to be specified.