Functional architecture overview
Figure 1 shows the initial functional eSSIF-Lab architecture, and its scope, context and (functional) components each of which is an agent for the same party (meaning that they are all part of the same organization as defined above, and they are all (digital) ‘colleagues’ of one another).
However, the participants of a business transaction are different parties, which means that the negotiation, commitment and execution thereof is done by agents of different parties. Assuming that a single transaction has two participating parties, we will use the term ‘peer party (of a specific party, in the context of a single transaction)’ to refer to the participating party in that transaction that is not the specific party itself.
Every agent that communicates with another actor for the purpose of progressing a transaction, will need to be sufficiently sure (to the extent necessary for the value of the transaction) that the actor that it is communicating with, is in fact an agent of the peer party of its owner. We will use the term ‘peer agent (of a specific agent, in the context of a single transaction)’ to refer to an actor with which the specific agent has a communications session, and for which it has obtained sufficient assurance that it is an agent of the peer party of its owner. Note that establishing whether or not an actor is a peer agent does not necessarily require knowing who the peer party actually is.
Figure 1. eSSIF-Lab Single Party Functional Architecture Overview.
We use the following coloring conventions in this figure: red(dish) is business related, which means that we do not consider this to be part of the SSI Infrastructure. Brown is used for policies, which are defined by (or on behalf) of the Owner of the component that uses them to configure themselves, and/or act according to the Owner’s preferences and policies. Green is used for generic SSI infrastructure related functions, and blue represents functions that may be implemented as ‘plug-ins’ for specific SSI-related technologies.
The remainder of this chapter describes the layers and their components at a high abstraction level.
2.1. Business Transaction Layers
At the top of the figure are two business-related layers. Both are within the scope of the eSSIF-Lab project/architecture, yet they are outside the scope of the eSSIF-Lab infrastructure/architecture - that is because they are too business-specific.
The top layer (in the red rounded rectangle) has the functions of actual business transactions: it starts with a transaction form, the data of which is valid, consistent and complete, from which the (business) decision can be made whether or not to engage in a business transaction, and that has everything necessary to actually execute that business transaction. The (administrative) results of such a business transaction are then stored in business data stores. We have put this layer in the eSSIF-Lab architecture for the single purpose of showing how the components of the bottom layer contribute to conduct business transactions.
The lower business layer contains two functional components, one for initiating transactions and the other for stating transaction results (as per the DEMO method), each of which with an associated business policy that contains business-specific policies/preferences.
The task of the Transaction (Validation) Engine (or TVE) is to handle and initiate requests from/to peer agents to engage in some kind of transaction, by negotiating and exchanging data (through one or more, physical or electronic communication channels), and to produce a transaction form whose contents is complete and valid, enabling an appropriate colleague to decide whether or not to engage in the transaction. Note that negotiating a transaction has two parts: requesting a peer agent to provide data that its owner needs, and providing data on behalf of its owner that a peer agent requests. After all, a business transaction can only start after all parties have decided to commit, which they can only do after each of them has obtained the information it (subjectively) needs to do so. Also note that data that the TVE must ensure that the transaction context is properly maintained if it chooses to exchange data through different communication channels.
The task of the Transaction Result Dispatcher (or TRD) 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. Since such state-data may change, issuing data that supersedes an earlier state implies the revocation of such a state.
Note that both components are within scope of eSSIF-Lab architecture, but NOT in scope of the eSSIF-Lab infrastructure, as they are too business-specific.
2.2. SSI Roles Layer (Issuer, Verifier, Holder and Wallet)
The SSI Roles Layer contains functional components that match the well-known roles of issuer, holder, wallet and verifier. These components are part of the eSSIF-Lab infrastructure.
Apart from each having a specific task, as described below, implementations that are being deployed by one party should be aligned in that they support the same (sub)set(s) of SSI Protocols and Crypto features, as described in the following section.
The task of the Issuer is to issue what we will generically call ‘credentials’, i.e. sets of (related) statements/claims (e.g. as produced by the TRD) that have metadata (e.g. date of issuing) and a digital signature by which third parties can prove its provenance and integrity. Another task of the Issuer is to handle revocation (and (un)suspension) of credentials that it has issued. For such tasks, it relies on functions that are made available by the SSI Protocols and Crypto Layer.
One task of the Wallet is to (securely) store 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. Another task of the Wallet is to (securely) store (private) keys that can be used to sign or seal data on behalf of its owner. Perhaps the most important task of the Wallet is to ensure that credentials and keys can only become available to another component if they have the same (single) owner, and will become available if such other component implements a functionality that needs it.
The task of the Verifier is to support the TVE as it tries to acquire credentials from some other party for the purpose of negotiating a business transaction. It does so by creating Presentation Requests that ask for such credentials, sending them to a Holder component of another party, receiving a response to such a request (which we call a ‘Presentation’), verifying the Presentation, i.e. checking the signature and other proofs of the veracity of both the construction of the Presentation as well as its contents, thus providing the TVE with verified data.
The task of the Holder is to handle Presentation Requests that it receives from Verifier components (both of its owner, and of other parties). Typically, this means looking for the requested data in the owner’s Wallet, and using it to construct a Presentation (=response). However, if the Wallet doesn’t have it, the Holder may negotiate a transaction with a component of the designated issuer for the purpose of obtaining the needed credential, which - when obtained - it can subsequently store in the Wallet and use in the Presentation.
2.3. SSI Protocols and Crypto Layer
While represented as a layer, the SSI Protocols and Crypto Layer can be seen more as a set of libraries that can be used by Wallet, Holder, Issuer and Verifier (WHIV) components for the purpose of actually implementing some/all of the functionality that they need to provide. Each ‘Component’ in this layer implements a specific technology, and any implementation of any of the WHIV components may choose which of these to use. Of course, if one of the WHIV components implements a technology, it would seem that the others would need to do so, too.
Technologies may come as a (proprietary or open source) library, as a service (offered by one or more parties), or both. There are way too many to mention here, but to give you an idea, here is a classification of such underlying/supporting technologies that seems to be useful. While we do mention some technologies explicitly, this should in no way be interpreted as that this would be necessary to support, or that others are not to be considered.
First, we have credential-related technologies, most often in the form of libraries, basically for the creation, (storing,) and verification of specific kinds of credentials such as Verifiable Credentials (VCs), Attribute Based Credentials[ABC] (ABCs), X.509 Attribute Certificates, OIDC tokens, etc. Various projects/implementations can already be used here, such as Hyperledger Aries, IRMA, OpenCerts, BlockCerts, and more.
Then, there are secure communications technologies, for the purposes of (a) ensuring that a technical component owned by a specific party can recognize that another component as one that it has had previous communications with and/or is owned by an identified party, and (b) setting up a secure communications channel, i.e. one that guarantees message confidentiality (encryption) and integrity/authentication. A well-known way to do this is SSL, but new ones are being developed, such as DID Comm(unication), that uses peer DIDs (work in progress).
Another important category is that of crypto (related) technologies, which are used for various purposes, such as creating/verifying digital signatures, zero-knowledge-proofs, etc. Such technologies may come as a library (e.g. Hyperledger/Ursa), or as a service, e.g. an eIDAS[eIDAS] trust service.
We conclude for now by mentioning blockchain/distributed ledger technologies, for secure logging of (e.g. registration) events, where such logs have the property that it is virtually impossible to change the order and/or contents of the logged events, and that the logs are highly available to those that are authorized. Both public and private blockchains are known to be used, and different SSI-solutions may use them for different purposes, e.g. the registration of schema’s, credential definitions, DIDs and associated DID documents, revocation accumulators, etc. Examples include EBSI (European Blockchain Partnership), Hyperledger Indy (Alastria, Findy, Sovrin), Ethereum (OpenCerts, BlockCerts), bitcoin (BlockCerts) and many more.
It is expected that there are already some interfaces out there that may turn out to be useful here (e.g. (unverified) FIWARE, CEF)
[ABC] Its origins lie with the ABC4Trust project. Extensive documentation is available, e.g. an Architecture for Attribute-based Credential Technologies (also one for developers).
[eIDAS5][*"Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC"*](http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.01.0073.01.ENG). EUR-Lex. The European Parliament and the Council of the European Union.
2.4. API Layers (‘ESSIF Glue’ and ‘SSI Tech APIs’)
There are two interface layers in this architecture
The `ESSIF Glue` interface layer consists of a set of API’s between the Transaction (Validation) Engine and Transaction Result Dispatcher on the one hand, and the WHIV components on the other hand. The specification of these API’s can be found in [reference needed]. The purpose of these APIs is to make calling the WHIV functions as simple as possible, given the functions of the Transaction Result Dispatcher and Transaction (Validation) Engine. Ultimately, we would like to see these API’s standardized. Having such APIs allows different parties to create their own version of the WHIV components, supporting the SSI technologies as they see fit, and shrinking or expanding functionalities as they feel appropriate. Parties can then select such WHIV components as they see fit.
The SSI Tech APIs interface layer is the union of the interfaces that the components that are in it provide. Any standardization in there is outside the scope of eSSIF-Lab.