Commit d085016a authored by Rieks Joosten's avatar Rieks Joosten

Renamed images, adjusted images links

parent 5880f473
Pipeline #8949 failed with stage
in 60 minutes
......@@ -20,7 +20,8 @@ among sections and is self-explanatory (compare with the sidebar appearing [here
(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.)
### Installation
......
......@@ -10,7 +10,6 @@ The purpose of the functional architecture and its views is to
- help **achieve interoperability** both at the technical and at the business levels.
## 1. Basic Terminology
In order to serve such purposes, we have found out that it is necessary that to make a strict and consequent distinction between people and organizations that are capable of making decisions and bearing responsibility/accountability (we will use the term ‘**party**’ for that) and people and ‘things’ that are capable of acting/doing things (we will use the term ‘**actor**’ for that). This means that an organization is always a party, whereas we consider a person to be a party at one time and an actor at another time, and computers/robots (and SSI components) are always an actor.
......@@ -31,7 +30,7 @@ However, the participants of a business transaction are different parties, which
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.
![eSSIF-Lab Single Party Functional Architecture Overview](@site/static/images/eSSIF-Lab-architecture.png)
![eSSIF-Lab Single Party Functional Architecture Overview](https://essif-lab.pages.grnet.gr/framework/images/functional-architecture.png)
*Figure 1. eSSIF-Lab Single Party Functional Architecture Overview.*
......@@ -103,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](.\images\eSSIF-Lab-architecture-infra-components.png)
![eSSIF-Lab functional components that are part of the eSSIF-Lab infrastructure](https://essif-lab.pages.grnet.gr/framework/images/functional-architecture-infra.png)
*Figure 2: eSSIF-Lab infrastructural (functional) components.*
......@@ -305,7 +304,7 @@ This chapter explains at a high level how electronic business transactions are b
### 5.1. Overview
<img src=".\images\eSSIF-Lab - 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.
<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.
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.
......@@ -319,7 +318,7 @@ 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="C:\Ampersand\Git\ssi-lab\essif-lab\images\eSSIF-Lab - 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.
<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.
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.
......@@ -366,7 +365,7 @@ It is a task of the TVE to orchestrate the inputs: different parts of the form m
Because of this orchestration, the interface to the verifier component can be quite simple; it is shown in the image below:
![Generic Verification with SSI service](.\images\Generic Verification with SSI service.png)
![Generic Verification with SSI service](https://essif-lab.pages.grnet.gr/framework/images/generic-verification-with-ssi-service.png)
The request identifier is included in messages between the TVE and verifier so as to allow them to handle different transactions at the same time.
......@@ -376,5 +375,5 @@ 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)
![Generic Issuing with SSI service](https://essif-lab.pages.grnet.gr/framework/images/generic-issuing-with-ssi-service.png)
......@@ -9,9 +9,9 @@ The current situation is that (SSI) solutions that are being created and brought
The situation we would like to see is one in which we have SSI-enabled, interoperable and scalable technologies, that form an infrastructure that every application in any vertical can use in a very easy manner, for the exchange of verified (personal and non-personal) data. In that situation people, businesses and governments think more about the information they need and/or provide as they conduct business transactions. They no longer need to be concerned about the SSI technologies that have empowered them to make this happen.
| The **purpose of the eSSIF-Lab** ... |
| ------------------------------------------------------------ |
| ... is to specify, develop and validate technological and non-technological means that support people, businesses and governments to think about, design and operate their (information) processes and (electronically) conduct business transactions with one another. |
:::tip **The purpose of the eSSIF-Lab...**
... is to specify, develop and validate technological and non-technological means that support people, businesses and governments to think about, design and operate their (information) processes and (electronically) conduct business transactions with one another.
:::
The context of the eSSIF-Lab vision can be found in articles 8-10 of the [*European Convention on Human Rights (ECHR)*](https://www.echr.coe.int/Pages/home.aspx?p=basictexts/convention), that state the rights of individuals regarding their privacy, and their freedoms to collect, process, store, and express information in a self-sovereign fashion, i.e. in a way that they can decide for themselves. This is without prejudice to Member States’ laws that exist to protect their national security, public safety, the economic well-being of the country, health or morals or the rights and freedoms of others, or to prevent disorder or crime. The eSSIF-Lab vision extends these rights and freedoms - within the limits of the law - to public and private organizations. Thus, we say that individuals as well as public and private organizations (that we collectively refer to as ‘parties’) are self-sovereign<sup>[1]</sup>.
......@@ -29,7 +29,7 @@ Perhaps the most important contribution that the eSSIF-Lab project aims to make,
The figure below is a high-level visualization of the filling in and validation parts:
![eSSIF-Lab - vision context](localhost:3000/static/images/eSSIF-Lab-vision-context.png)
![eSSIF-Lab - vision context](https://essif-lab.pages.grnet.gr/framework/images/eSSIF-Lab-vision-context.png)
*Figure 1. High-level visualization of the filling in and validation of a form.*
......
......@@ -3,6 +3,6 @@ id: introduction
title: Introduction
---
- [vision](vision-and-purpose)
- [functional architecture](functional-architecture)
- [Vision and purpose](vision-and-purpose)
- [Functional architecture](functional-architecture)
......@@ -13,7 +13,7 @@ module.exports = {
src: 'images/eSSIF-Lab logo.png',
},
links: [
{to: 'docs/essif-lab-vision-and-purpose', label: 'Vision', position: 'left'},
{to: 'docs/vision-and-purpose', label: 'Vision', position: 'left'},
{to: 'docs/introduction', label: 'Quick intro', position: 'left'},
{
href: 'https://gitlab.grnet.gr/essif-lab/framework',
......
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