Commit 099bcfbc authored by fmerg's avatar fmerg

Resolved conflicts

parents cbcfce40 c932134c
Pipeline #9901 passed with stages
in 1 minute and 36 seconds
......@@ -10,3 +10,4 @@ npm-debug.log*
yarn-debug.log*
yarn-error.log*
start_server.bat
......@@ -19,9 +19,11 @@ among sections and is self-explanatory (compare with the sidebar appearing [here
(that is, tagged with `##`) will appear at the right part of the page
(see for example [here](https://essif-lab.pages.grnet.gr/essif-lab/docs/infrastructure)).
Images must be put inside `static` and referred to with their _absolute_ urls.
Example: ![eSSIF-Lab logo](https://essif-lab.pages.grnet.gr/framework//images/eSSIF-Lab%20logo.png)
(note that the `static` directory is missing, as this links to the DEPLOYED environment.)
Images must be put inside the directory `static/images` and developers must refer to them using _relative_ urls.
Example: ![eSSIF-Lab logo](../images/eSSIF-Lab%20logo.png)
Docusaurus knows that the `../images` directory is inside the `static` directory, and thus process correctly.
The deployment pipe will convert `../images/` in such links to their _*absolute*_ urls.
Of course, if you want to link to images on the web, you can still use absolute urls.
### Installation
......
---
id: functional-architecture
title: Functional Architecture
title: eSSIF-Lab Functional Architecture
---
The purpose of the functional architecture and its views is to
......@@ -102,7 +102,7 @@ The **SSI Tech APIs** interface layer is the union of the interfaces that the co
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](https://essif-lab.pages.grnet.gr/framework//images/functional-architecture-infra.png)
![eSSIF-Lab functional components that are part of the eSSIF-Lab infrastructure](../images/functional-architecture-infra.png)
*Figure 2: eSSIF-Lab infrastructural (functional) components.*
......@@ -158,7 +158,7 @@ As long as data is needed, the TVE can intermittently request the verifier to pr
[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.
[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.
-----
......@@ -304,7 +304,8 @@ This chapter explains at a high level how electronic business transactions are b
### 5.1. Overview
<img src="https://essif-lab.pages.grnet.gr/framework//images/high-level-trx-overview.png" alt="eSSIF-Lab - high level trx overview" style={{"zoom":"40%"}}/>The adjacent figure shows how a transaction is conducted at the highest abstraction level. One party, called the ‘Requester’, sends a request for a product or service to another party (that we will call the ‘Provider’). Then, they start to negotiate a ‘transaction agreement’, which means that they exchange data through various channels for the purpose of establishing the details of the product/service to be provided and the compensation, data needed to mitigate transaction risks, etc., all of which is necessary for the parties to (individually/subjectively) decide whether or not to commit to the transaction. Section 3.2 provides more detail about this phase.
![eSSIF-Lab - high level trx overview](../images/high-level-trx-overview.png)
The adjacent figure shows how a transaction is conducted at the highest abstraction level. One party, called the ‘Requester’, sends a request for a product or service to another party (that we will call the ‘Provider’). Then, they start to negotiate a ‘transaction agreement’, which means that they exchange data through various channels for the purpose of establishing the details of the product/service to be provided and the compensation, data needed to mitigate transaction risks, etc., all of which is necessary for the parties to (individually/subjectively) decide whether or not to commit to the transaction. Section 3.2 provides more detail about this phase.
After commitment, the producer works to provide the product or service, and the requester arranges the compensation. This phase is entirely up to the business, and hence out of scope of this document.
......@@ -318,7 +319,8 @@ Please note that while transactions are symmetrical in nature (i.e. both request
This phase starts by the requester sending a transaction request to the provider, and ends whenever either one of the parties quits, or both parties commit.
<img src="https://essif-lab.pages.grnet.gr/framework//images/high-level-trx-negotiation.png" alt="eSSIF-Lab - high level trx negotiation" style={{"zoom":"40%"}}/>The adjacent figure shows the high-level interactions during this phase. It starts by the requester sending a request for a product or service to the provider. Typically, this would lead to the provider presenting a (web) form the requester must fill in. In the eSSIF-Lab context, the form will also provide a means for setting up a SSI communications channel, i.e. a secure communications channel through which provider and requester can both request and obtain (presentations of) credentials, the contents of which they can use to fill in the form. Then, after the form is ‘clean’, i.e. contains sufficient information for deciding whether or not to commit to the transaction, this phase ends.
![eSSIF-Lab - high level trx negotiation](../images/high-level-trx-negotiation.png)
The adjacent figure shows the high-level interactions during this phase. It starts by the requester sending a request for a product or service to the provider. Typically, this would lead to the provider presenting a (web) form the requester must fill in. In the eSSIF-Lab context, the form will also provide a means for setting up a SSI communications channel, i.e. a secure communications channel through which provider and requester can both request and obtain (presentations of) credentials, the contents of which they can use to fill in the form. Then, after the form is ‘clean’, i.e. contains sufficient information for deciding whether or not to commit to the transaction, this phase ends.
Note that forms may contain fields that are required only in specific circumstances. It may only be possible to assess whether or not such circumstances apply after some (other) fields have been filled in. This means that the phase for requesting credential presentations and responding to such requests may very well consist of multiple requests and associated responses.
......@@ -376,4 +378,3 @@ We assume that the provider has specified the form and the associated validation
[text still needs to be written\]
![Generic Issuing with SSI service](../images/generic-issuing-with-ssi-service.png)
---
id: vision-and-purpose
title: Vision and Purpose
title: eSSIF-Lab Vision and Purpose
---
It is the eSSIF-Lab vision that Self-sovereign Identity (SSI) will *empower European citizens (as well as other individuals, of course)* by providing new means to manage privacy, eliminating logins, and making electronic transactions much faster and much safer, both via the Internet and in real, physical life. SSI will *empower European organisations and governments* by providing new means to speed up, secure and automate transactions with citizens, customers, suppliers and partners, resulting in tens of billions of euros savings annually on administrative costs in Europe. SSI will be *a new business ecosystem paradigm* with thousands of new jobs, many new job categories and new business opportunities for existing and new European companies. And last but certainly not least, SSI fosters *inclusiveness* and supports organizations and citizens to exercise their rights and fulfil their duties under the GDPR.
It is the eSSIF-Lab vision that Self-Sovereign Identity (SSI) will *empower European citizens (as well as other individuals, of course)* by providing new means to manage privacy, eliminating logins, and making electronic transactions much faster and much safer, both via the Internet and in real, physical life. SSI will *empower European organisations and governments* by providing new means to speed up, secure and automate transactions with citizens, customers, suppliers and partners, resulting in tens of billions of euros savings annually on administrative costs in Europe. SSI will be *a new business ecosystem paradigm* with thousands of new jobs, many new job categories and new business opportunities for existing and new European companies. And last but certainly not least, SSI fosters *inclusiveness* and supports organizations and citizens to exercise their rights and fulfil their duties under the GDPR.
The current situation is that (SSI) solutions that are being created and brought to the market, often have specific applications in mind for which they provide a solution (vertical ‘stovepipes’), many have some kind of centralized governance/control, others have privacy issues, and none that we know of are interoperable with other such solutions.
......
......@@ -3,6 +3,25 @@ id: introduction
title: Introduction
---
The European Self-Sovereign Identity Lab ([eSSIF-Lab](https://essif-lab.eu/)) views itself as an ecosystem of parties
that work together to make existing (and new) Self-Sovereign Identity (SSI) technology into
a scalable and interoperable infrastructure that businesses can use very easily
for conducting (business) transactions with other businesses and individuals alike.
Typically, the libraries, code or components for the infrastructure should be open source.
In order to support the use of such an infrastructure by businesses and individuals,
eSSIF-Lab parties also create applications and other tooling to support such actual use
on top of the interoperable infrastructure, which may or may not be open source,
and are expected to be used as/in products of organizations that want to make this their business.
At the start, eSSIF-Lab is one of the European [NGI projects](https://www.ngi.eu/ngi-projects/)
and helps (EU) parties that want to contribute by publishing [open calls](https://essif-lab.eu/?page_id=134)
to which such parties can submit work proposals that eSSIF-Lab will then consider for funding.
## eSSIF-Lab Framework repository
This repo contains the documents that describe the vision, architecture and other
topics that are relevant to the eSSIF-Lab Framework. Currently, it contains:
- [Vision and purpose](vision-and-purpose)
- [Functional architecture](functional-architecture)
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment