Commit 763c9098 authored by Rieks Joosten's avatar Rieks Joosten
Browse files

restructuring the high-level doc.

parent 6f3cc945
Pipeline #16237 passed with stage
in 2 minutes and 23 seconds
......@@ -17,7 +17,7 @@ Documentation on these and other header fields can be found [here](https://v2.do
The Terminology Engine plugin of GRNET uses additional header fields. These are (or will be) defined [here](./docs/terminology-contributions).
The `sidebars.js` file contains the basic mechanism for [distributing content among sections](https://v2.docusaurus.io/docs/docs-introduction#sidebar) and is self-explanatory (compare with the sidebar appearing [here](https://essif-lab.pages.grnet.gr/essif-lab/docs/introduction)). Subsections within the `.md` file (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)).
The `sidebars.js` file contains the basic mechanism for [distributing content among sections](https://v2.docusaurus.io/docs/docs-introduction#sidebar) and is self-explanatory (compare with the sidebar appearing [here](https://essif-lab.pages.grnet.gr/essif-lab/docs/project)). Subsections within the `.md` file (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)).
## Inserting Images in docs
<!-- **DEPRECATED** Images must be put inside the directory `static/images` and developers must refer to them using _relative_ urls.
......
......@@ -7,28 +7,18 @@ scopeid: essifLab
import useBaseUrl from '@docusaurus/useBaseUrl';
The purpose of the functional architecture and its views is to
- **provide mental models** that all of its stakeholders interpret in sufficiently the same way, so as to be able to talk, think and discuss about what it is we try to achieve and ways to achieve this;
- help **inventory and subsequently address any (other) concerns and issues** of every one of its stakeholders;
- 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|party%%’ for that) and people and ‘things’ that are capable of acting/doing things (we will use the term ‘%%Actor|actor%%’ for that). All %%Organizations|organization%% are %%Parties|party%%, whereas we consider a person (human being) to be both a %%Party|party%% (in cases where reasoning, decision making and bearing responsibility are in order), and an %%actor|actor%% (in cases where the person is actually doing things). More details backgrounds are given in the %%mental model|mental-model%% '%%Parties, Actors and Actions|pattern-party-actor-action%%' and the documentation of the concepts used therin.
:::note Editor's note
TNO to edit remainder of this section (make it shorter), because users can click on the various terms if they want to know more.
:::
This distinction is necessary because Actors do things that Parties are accountable for. In order to know which Party is accountable for what actions, we need the ability to link Parties and Actors. When an Actor acts and a (single) specific Party is accountable for that, we say that the Actor is an ‘%%Agent|agent%%’ for or of that Party (at that particular point in time). We say that this Actor acts ‘**on behalf of**’ that Party. Note that both humans and (running) applications may serve as Agents (human Agent or digital/electronic Agent respectively). A digital Agent that has one or more of the SSI functionalities we describe further down will be called an '%%SSI-Agent|ssi-agent%%', and we say that the Party on whose behalf it operates is the ‘%%Owner|owner%%’ of that Agent. Also, we use the term '**(digital/electronic or human) Colleague (of an Agent)**' to refer to any other (electronic or human) Agent that acts on behalf of the same Party as this Agent.
Given these definitions, it is obvious that Parties are not necessarily capable of acting. However, we also would like to be able to generically use phrases such as ‘Party X does Y’. To this end we introduce the term '%%Organization|organization%%' as the collection of one specific Party and its Agents. When we say ‘Party X does Y’, this should be understood as that there is an Agent that does Y, where that Agent belongs to the same Organization as the specified Party.
We caution that the notions of being an ‘Agent’, ‘Owner’, ‘Colleague’, and being part of an ‘Organization’ are dynamic; they may frequently change over time and are never self-evident.
Also, to serve the aforementioned purposes, we cannot fix the architecture (and the fact that eSSIF-Lab is an experimentation environment already implies this). We see it is a first attempt to describe an architecture that will be regularly updated as we - i.e. the eSSIF-Lab consortium and all subgrantees and perhaps some others - work together as an ecosystem-in-formation to realize the aforementioned vision.
## Purpose
It is the intention of the eSSIF-Lab project to develop this functional architecture into a generic, and common basis that parties from different backgrounds can use e.g. for:
- thinking and arguing about SSI-related topics and how it contributes to business transactions;
- creating technological components that provide functionalities that fit into the architecture and hence have a great chance to be, or quickly become, interoperable with tech components that other parties have developed;
- discussing and resolving issues related to interfaces and protocols for tech components that provide such functionalities;
- designing and developing technical applications that support businesses, not only as they conduct business transactions, but also as the govern the %%policies|policy%% that are needed to make the technology work as intended by such businesses.
To this end, this document provides an overview of
- the functions (capabilities) that individual %%parties|party%% need in order to electronically support %%busines transactions|business-transaction%%;
- the interactions between these functions that make such business transactions happen;
- the various %%policies|policy%% that parties have to govern, and put in place in order for the technical components that provide these capabilities to function in accordance with their (subjective) %%rules, working-instructions and other guidance|policy%%.
## 2. Functional Architecture Overview
......
---
id: governance
title: eSSIF-Lab Governance
sidebar_label: Governance
scopeid: essifLab
---
import useBaseUrl from '@docusaurus/useBaseUrl';
## Purpose
The [eSSIF-Lab functional architecture](functional-architecture) identifies and describes a variety of generic SSI functions (capabilities), such as %%holder|holder%%, %%verifier|verifier%%, %%issuer|issuer%%, %%wallet|wallet%%, and more. An %%actor|actor%% that can provide such (generic) capabilities can only _actually_ provide them for a %%party|party%% if it knows how to to comply with the %%rules, working-instructions and other guidance|policy%% of that party.
**Governance** is the process by which %%parties|party%% decide how to make decisions, how %%actors|actor%% that work on their behalf are to behave and operate, and ensure this guidance ends up in some document which we will call a %%policy|policy%%.
## Governance processes and Policies
Within the context of eSSIF-lab, pretty much every function/capability that is defined also mentions a corresponding %%(digital) policy|digital-policy%% that is the place where rules, working-instructions and other guidance (e.g. preferences) are expected to be specified for the correct functioning of a technical component that may provide such a capability.
The structure of these %%digital policies|digital-policy%% depends on the design of the technical component, as different kinds of technical components that (still) implement the same capability may have limitations or additional features regarding that capability.
It is the intention of eSSIF-Lab, however, to at least state some minimal requirements for the policies of various functionalities.
\ No newline at end of file
---
id: introduction
title: Introduction
sidebar_label: eSSIF-Lab
id: project
title: The eSSIF-Lab Project
sidebar_label: eSSIF-Lab Project
---
The European Self-Sovereign Identity Lab ([eSSIF-Lab](https://essif-lab.eu/)) views itself as an ecosystem of parties
......@@ -20,7 +20,7 @@ One of the overarching activities in eSSIF-Lab is the design, maintenance and va
- [Vision and purpose](vision-and-purpose)
- [Functional architecture](functional-architecture)
- [Concepts & Terminology](terminology)
- [Terminology](terminology)
For interop purposes, we also maintain a page related to [SSI standards](ssi-standards).
......
......@@ -24,7 +24,7 @@ Please fill in the placeholders in this file as follows:
### Notations
<!-- This (optional) section specifies the notations that are used, or refers to such a specification. -->
## <!-- any number of other sections, as is fit for describing the pattern -->
### <!-- any number of other sections, as is fit for describing the pattern -->
<!-- text as appropriate for such a section -->
<!--
......
......@@ -9,7 +9,7 @@ When people from various backgrounds (and cultures) work together, it is inevita
Within eSSIF-Lab, we would like to provide tools, methods and other means to help minimize the amount of misunderstandings, (i.e. to quickly identify any possible misunderstanding and to reduce the effort of resolving them), perhaps even preventing them.
## Vision
### Vision
[Many cultures](https://en.wikipedia.org/wiki/Tower_of_Babel#Comparable_myths) have stories, similar to that of the [Tower of Babel](https://en.wikipedia.org/wiki/Tower_of_Babel), that observe that the big feats, such as building a "tower, whose top may reach unto heaven", cannot be achieved unless there is linguistic unity. While is generally recognized (the [EU parliament building](https://images-wixmp-ed30a86b8c4ca887773594c2.wixmp.com/f/e3de7793-c11c-4246-81aa-401be9b09384/d5ttx0w-7bcf343b-2114-46cd-8c30-d722a9725ee9.jpg/v1/fill/w_1054,h_758,q_70,strp/european_union_parliament_02__tower_of_babel__by_nixseraph_d5ttx0w-pre.jpg?token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1cm46YXBwOiIsImlzcyI6InVybjphcHA6Iiwib2JqIjpbW3siaGVpZ2h0IjoiPD0xNTk2IiwicGF0aCI6IlwvZlwvZTNkZTc3OTMtYzExYy00MjQ2LTgxYWEtNDAxYmU5YjA5Mzg0XC9kNXR0eDB3LTdiY2YzNDNiLTIxMTQtNDZjZC04YzMwLWQ3MjJhOTcyNWVlOS5qcGciLCJ3aWR0aCI6Ijw9MjIxNyJ9XV0sImF1ZCI6WyJ1cm46c2VydmljZTppbWFnZS5vcGVyYXRpb25zIl19.db-z1OueDUGbAWMhnIbxcDioaFh1zJVlBnUTNAd5y5Y) in Strasbourg [resembles](https://jdreport.com/wp-content/uploads/2014/05/tower-painting-parliament-e14176743284401.jpg.webp) the Tower of Babel as [depicted by the painter Brueghel](https://mattbell.org/wp-content/uploads/Tower-of-Babel-Peter-Breughel.jpg)), one can also observe that the part of the people that care about this and want to achieve a workable 'linguistic unity' lack means and tools that are easy to use.
......@@ -29,17 +29,17 @@ As the corpus is being used, we expect ideas for improvement
[Here](terminology-contributions) is how you may contribute to this terminology effort.
## Terminological Artifacts
### Terminological Artifacts
The terminological artifacts that the eSSIF-Lab Concepts and Terminology effort aims to produce include:
- A set of (documented/defined) terms that are designed to serve the purposes as specified above.
- A [Glossary](./essifLab-glossary) that lists these terms
- A [Glossary](./essifLab-glossary) that lists these terms.
- A set of %%mental models|mental-model%% that provide backgrounds about how specific %%concepts|concept%% relate to one another.
Depending on the needs of stakeholders, additional artifacts may be created/generated.
## Notes:
### Notes:
Here are some characteristics of the tools being supplied:
- When a reader sees a highlighted term (meaning that it is documented), (s)he will see a short description when hovering over the term, and the complete description by clicking onit.
......
......@@ -8,14 +8,39 @@ stage: draft
hoverText: "Business Transaction: the exchange of goods, services, funds, or data between some Parties (called ‘participants’ of the transaction)"
---
import useBaseUrl from '@docusaurus/useBaseUrl';
:::info Editor's note
TNO (or others) to provide the content of this file.
:::
:::info Editor's note
Explanation required about 'commitment decisions' (i.e. 'promise' decisions in DEMO[^1]).
Explanation required about 'commitment decisions' (i.e. 'promise' decisions in [DEMO](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations)).
:::
### Notes
### High Level Example
In its simplest form, this may be envisaged as one party (requestor) that requests another party (provider) to provide some product, e.g. a parking permit, by using his web-browser to navigate to the web-server of the provider (e.g. his municipality) where he is prompted to fill in a form to provide the details of his request (such as name, address, plate number, etc.). When the form is submitted, the provider decides whether or not to service the request (provide the parking permit) based on the data in the form, and take actions accordingly.
In order for this to work, the provider must design the form such that when a requestor submits a completed form, it can actually decide whether or not to service the request. This has two parts: first, the provider must specify the argument (i.e. the way of reasoning) that it uses to reach this decision - i.e. provide the parking permit. Doing so implicitly specifies the kinds of data that the form will ask for. Secondly, the provider must decide for each of the data it receives, whether or not it is valid to be used in that argument - the process of deciding this is called ‘validation’. Common criteria that help to make this distinction include whether or not the data is presented in the expected format, whether or not it is true (not so easy), whether it is not outdated, or whether or not it satisfies validation rules (in the example, the municipality may require that the specified license plate belongs to a car owned by the person that requests the permit). Validation is important, because reasoning with invalid data may result in wrong conclusions and cause damage.
Perhaps the most important contribution that the eSSIF-Lab project aims to make, is to create a ubiquitously used infrastructure for designing, filling in, and validating forms (not just web-forms, but also for ‘forms’ - e.g. JSON objects - in API requests). The benefits this will bring are enormous, but outside the scope of this document to list.
The figure below is a high-level visualization of the filling in and validation parts:
<img
alt="High-level visualization of the filling in and validation of a form."
src={useBaseUrl('images/vision-context.png')}
/>
*Figure 1. High-level visualization of the filling in and validation of a form.*
The transaction that is envisaged here is the issuing of a parking permit. Participants are a person (requestor) that requests such a permit, and an organization (provider) that can issue such a permit. The requestor has one electronic agent, *the Requestor Agent (RA)*, i.e. an SSI-aware app on their mobile phone that can access a secure storage that contains ‘credentials’, i.e. data that is digitally signed by some third party, thus attesting to the truth of that data. The provider has two agents: one is an SSI-aware component *Provider Agent (PA_* that works with the web-server that presents the form, and the other is a person *P* whose task is to validate any data (on behalf of the provider) that is not validated electronically. The form itself contains a means, e.g. a QR-code or a deep-link, that allows *RA* and *PA* to set up a secure communication channel (e.g. SSL, [DIDComm](https://openssi.github.io/peer-did-method-spec/)) and agree on the specific form that needs to be filled in.
After the *RA* and *PA* have established a communication channel and agree on the form to be filled in, *PA* informs *RA* about the information it needs to fill in the form, and the requirements that this information should satisfy[^1]. *RA* then checks its data store to see whether or not such data is available, sends such data to *PA*, which subsequently validates it and uses it to fill in (appropriate parts of) the form. Finally, *P* validates the remaining data, which either results in a ‘clean’ form, i.e. a form that contains valid data that can subsequently be used to decide whether or not to provide the parking permit, or a message to the requester informing him about missing and/or invalid data.
When the transaction has been completed, both participants can issue a credential that attests to the results of the transaction. For example, the provider could issue a credential stating that the requestor has obtained a parking permit for a car with a specific plate number (and other attributes). The requestor can store this credential and from that moment on use it in new electronic transactions.
--------
1. A good mental model for describing and designing business transactions and their participants is provided by [*DEMO*](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations).
\ No newline at end of file
[^1]: Since transactions are symmetric, the requestor could also have a form that the provider needs to fill in so as to provide the requestor with the data it needs to commit to that transaction. We have left that out of this description for the sake of simplicity. However, the [eSSIF-Lab functional architecture](functional-architecture) does take this into account.
\ No newline at end of file
......@@ -8,13 +8,13 @@ stage: draft
hoverText: "Data Collector Policy: a Digital Policy that enables an operational Data Collector component to function according to the rules of its Policy Governor."
---
## Short Description
### Short Description
A **Data Collector Policy** is a %%digital policy|digital-policy%% that enables an operational %%Data Collector component|data-collector%% to function according to the rules of its %%Policy Governor|policy-governor%%.
Such a policy includes e.g. the kinds of data (and meta-data) required to make these kinds of decisions, criteria to distinguish between %%data that is valid|validated-data%% and data that is not, any data conversions that may be needed, etc.
## Purpose
### Purpose
The purpose of a **Data Collector Policy** is to enable the creation of (technical) components that implement the generic %%data collector|data-collector%% functionality that will subsequently use such policies to guide their behaviour.
## Criteria
### Criteria
A **Data Collector Policy** is a %%digital policy|digital-policy%% that enables an operational %%Data Collector component|data-collector%% to function according to the rules, working-instructions and other guidance of its %%Policy Governor|policy-governor%%.
......@@ -8,13 +8,13 @@ stage: draft
hoverText: "Data Collector: a functional component that collects sufficient and Validated Data for deciding whether or not a request (typically for a product or a service) is to be serviced."
---
## Short Description
### Short Description
A **Data Collector** is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that a %%party|party%% may use to collect sufficient and %%validated data|validated-data%% for deciding whether or not a request (typically for a product or a service) is to be serviced.
## Purpose
### Purpose
The purpose of a Data Collector is to collect sufficient and %%validated data|validated-data%% that eneables (an %%agent|agent%% of) its %%principal|principal%% to decide whether or not some request (typically for a product or a service) is to be serviced.
## Functionality
### Functionality
A data collector typically starts to collect data when it receives a request (e.g. to provide a product or service). The reception of such a request triggers the creation of a new %%business transaction|business-transaction%%. The task of the data collector is to collect %%validated data|validated-data%% that is sufficient for making a commitment decision (or, as [DEMO](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations) calls it: a 'promise' or 'quit' decision.)
Starting the data collection for a transaction does NOT imply that the identity of the %%actors|actor%% from whom/which the request originated, is established (or authenticated). It also does NOT imply that the identity of the %%peer party|peer-party%% is established (or authenticated). The data collector simply proceeds to collect a sufficient amount of data such that the associated decision can be made, according to the rules, working-instructions and other guidance provided by its %%principal's|principal%% %%data collector policy|data-collector-policy%%. Such data may include identity data, but it also may not.
......@@ -29,7 +29,7 @@ During the time in which a data collector is collecting data for a specific %%tr
A data collector benefits from generic APIs or (G)UIs that allow it to simply ask for the data that it requires. Specifically for SSI, the data collector uses the %%eSSIF-Glue|essif-glue%% interface to access the %%Verifier|verifier%% functionalities.
## Criteria
### Criteria
A **Data Collector** is a functional component in the [eSSIF-Lab functional architecture](../functional-architecture) that
- services requests by %%digital|digital-agent%% and non-digital %%agents|agent%%, for providing a product or service, thereby starting a %%transaction|business-transaction%%;
- can setup, accept and tear-down communication channels of various kinds, with %%digital|digital-colleague%% and/or non-digital %%colleagues|colleague%% of that %%requesting agent|agent%%,[^peer-agents] as appropriate for the data exchanges that are needed to conduct the transactions;
......@@ -39,7 +39,7 @@ A **Data Collector** is a functional component in the [eSSIF-Lab functional arch
- receive similar requests from its %%peer-party%%, and respond to such requests in compliance with the rules of its %%principal's|principal%% %%Data Collector Policy|data-collector-policy%%;
- has a mechanism to ensure that within a %%transaction|business-transaction%%, it uses the latest (most receent) %%Data Collector Policy|data-collector-policy%% of its %%principal|principal%%.
## Deprecated - TVE Functionality
### Deprecated - TVE Functionality
:::info Editor's note
TNO to revise the text below.
......
......@@ -8,13 +8,13 @@ stage: draft
hoverText: "Data Discloser Policy: a Digital Policy that enables an operational Data Discloser component to function according to the rules of its Policy Governor."
---
## Short Description
### Short Description
A **Data Discloser Policy** is a %%digital policy|digital-policy%% that enables an operational %%Data Discloser component|data-discloser%% to function according to the rules of its %%Policy Governor|policy-governor%%.
Such a policy includes e.g. the kinds of data (and meta-data) that may be disclosed, the conditions that need to be satisfied for actually disclosing such kinds of data, any meta-data (assurances) that maybe added to data being disclosed, etc.
## Purpose
### Purpose
The purpose of a **Data Discloser Policy** is to enable the creation of (technical) components that implement the generic %%data discloser|data-discloser%% functionality that will subsequently use such policies to guide their behaviour.
## Criteria
### Criteria
A **Data Discloser Policy** is a %%digital policy|digital-policy%% that enables an operational %%Data Discloser component|data-discloser%% to function according to the rules, working-instructions and other guidance of its %%Policy Governor|policy-governor%%.
......@@ -8,7 +8,7 @@ stage: draft
hoverText: "Data Discloser: a functional component that is capable of disclosing data."
---
## Short Description
### Short Description
A **Data Discloser** is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that applications (that work for some %%Party|party%%) can call to communicate things such as:
- the results of a business transaction (e.g. statements to confirm that a transaction happened, thereby supplying appropriate details)
- the status of a business transaction (e.g. that an order has been received in good order, that delivery of an order is dealyed or otherwise changed)
......@@ -18,13 +18,13 @@ The Data Discloser uses a %%data-collector-policy|data-collector-policy%% to lea
The Data Discloser uses the %%eSSIF-Glue|essif-glue%% interface to access the %%Wallet|wallet%%, %%Holder|holder%%, %%Issuer|issuer%% and %%Verifier|verifier%% functionalities.
## Purpose
### Purpose
The purpose of the Data Discloser 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.
## Criteria
### Criteria
A **Data Discloser** is a component in the [eSSIF-Lab functional architecture](../functional-architecture) that is capable of stating (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|party%%.
## Functionality
### Functionality
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).
......
---
id: zzz
title: "zzz"
id: documentation-interop
title: "Documentation Interoperability"
scopeid: essifLab
type: concept
typeid: zzz
typeid: documentation-interop
stage: draft
hoverText: "zzz: popuptext remains to be done"
hoverText: "Documentation Interoperability: the property that a documentation system of making its content comprehensible for a variety of people that come from different backgrounds."
---
:::info Editor's note
......
---
id: governance
title: "Governance"
scopeid: essifLab
type: concept
typeid: governance
stage: draft
hoverText: "Governance: the act or process of governing or overseeing the control and direction of something (Merriam-Webster)."
---
### Short Description
**Governance** is the act (executed by, or behalf of some %%party|party%%) or process (of some %%party|party%%) of governing or overseeing the control and direction of something ([Merriam-Webster](https://www.merriam-webster.com/dictionary/governance)). Governance is about establishing the ways in which a party makes its decisions; they are 'meta-decisions': decisions about decision-making.
As parties interact with one another, i.e. conduct %%business transactions|business-transaction%%, they need to decide whether or not to commit to a transaction proposal. Deciding about how to make such a decision is one of the subjects of the governance process of that party: it is establishing the kind of argument that may be used to make this decision.
Within eSSIF-Lab, governance is pretty much limited to the governance of various %%policies|policy%%.
### Purpose
The purpose for a %%party|party%% of having a **governance** process is that it enables him to reflect on the ways that it makes decisions. A typical topic for governance is the maintenance of the set of rules, working-instructions and other guidance that %%actors|actor%% are supposed, or required to use when executing specific %%actions|action%% on behalf of that %%party|party%%.
For %%digital-actors%% such guidance consists of %%digital policies|digital-policies%%. A %%party|party%% whose governance process maintains a %%policy|policy%% will be called the %%governor|policy-governor%% of that policy.
### Background
The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
### Related Concepts
- %%Governance|governance%%
- %%Governor|policy-governor%%
- %%Policy|policy%%
- %%Digital Policy|digital-policy%%
- %%Data Discloser Policy|data-collector-policy%%
- %%Data Collector Policy|data-collector-policy%%
- %%Verifier Policy|verifier-policy%%
- %%Issuer Policy|issuer-policy%%
- %%Holder Policy|holder-policy%%
- %%Wallet Policy|wallet-policy%%
:::info Editor's note
TNO (or others) to provide additional content of this file.
:::
......@@ -8,16 +8,20 @@ stage: draft
hoverText: "Holder (functional component): the capability to handle presentation requests from a Peer Agent, produce the requested data (a presentation) according to its Principal's holder-policy, and send that in response to the request."
---
## Short Description
### Short Description
A **Holder** is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that handles %%Presentation Requests|presentation-request%% that it receives from %%verifier|verifier%% components (of other %%parties|party%%, but also of its own %%owner|owner%%). Typically, this means looking for the requested data in the Owner’s %%wallet|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|issuer%% for the purpose of obtaining the needed credential, which - when obtained - it can subsequently store in the wallet and use in the Presentation.
## Purpose
:::info Editor's note
TNO (or others) to provide additional content of this file.
:::
### Purpose
The purpose of the Holder component is to handle Presentation Requests that it receives from %%verifier|verifier%% components (both of its own %%owner|owner%%, and of other %%parties|party%%), and responding to such requests.
## Criteria
### Criteria
A **Holder** is a component in the [eSSIF-Lab functional architecture](../functional-architecture) whose function is to handle Presentation Requests that it receives from %%verifier|verifier%% components (both of its %%owner|owner%%, and of other %%Parties|party%%).
## Functionality
### Functionality
Typically, a Holder component would access its %%owner|owner%%'s Wallet to check if it has a credential that it can use to construct a Presentation (i.e. response) that satisfies the received request.
......
......@@ -8,17 +8,20 @@ stage: draft
hoverText: "Issuer (functional component): the capability to construct Credentials from data objects, according to the rules of its Principal's issuer-policy (specifically regarding the way in which the Credential is to be digitally signed), and pass it to the Wallet-component of its Principal allowing it to be issued."
---
## Short Description
An **issuer** is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that structures sets of (related) statements/claims (e.g. as produced by the %%Data Discloser|data-discloser%%) in a packate, adds metadata which includes e.g. a timestamp at which this was done, ensures that it is digitally signed on behalf of its %%owner|owner%%, signature by which third Parties can prove its provenance and integrity. Another function 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.
:::info Editor's note
TNO (or others) to provide additional content of this file.
:::
### Short Description
An **issuer** is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that structures sets of (related) statements/claims (e.g. as produced by the %%Data Discloser|data-discloser%%) in a package, adds metadata which includes e.g. a timestamp at which this was done, ensures that it is digitally signed on behalf of its %%owner|owner%% (so that third %%parties|party%% can prove its provenance and integrity). Another function 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.
## Purpose
### Purpose
The purpose of the Issuer function is.
## Criteria
### Criteria
A **Issuer** is a component in the [eSSIF-Lab functional architecture](../functional-architecture) whose function is to ... (tbd).
## Functionality
### Functionality
The purpose of the Issuer component is to issue ‘credentials’, i.e. digital constructs that contain
......
......@@ -25,7 +25,7 @@ Different terms can be used to identify the same concept. Car and Automobile are
### Notations
<!--This (optional) section specifies the notations that are used, or refers to such a specification.-->
## <!-- any number of other sections, as is fit for describing the pattern -->
### <!-- any number of other sections, as is fit for describing the pattern -->
<!--text as appropriate for such a section -->
<!--
......
......@@ -12,7 +12,14 @@ hoverText: "Policy Governor (of a Policy): the Party that is the Owner of the Po
TNO (or others) to provide the content of this file.
:::
### Background
The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
### Related Concepts
- %%Governance|governance%%
- %%Governor|policy-governor%%
- %%Policy|policy%%
- %%Digital Policy|digital-policy%%
- %%Data Discloser Policy|data-collector-policy%%
- %%Data Collector Policy|data-collector-policy%%
......
......@@ -31,4 +31,16 @@ A **policy** is
- is accessable to, and must be complied with by an %%agent|agent%% of that %%policy's governor|policy-governor%% when it executes an action of the kind to which the policy applies.
### Background
The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
\ No newline at end of file
The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
### Related Concepts
- %%Governance|governance%%
- %%Governor|policy-governor%%
- %%Policy|policy%%
- %%Digital Policy|digital-policy%%
- %%Data Discloser Policy|data-collector-policy%%
- %%Data Collector Policy|data-collector-policy%%
- %%Verifier Policy|verifier-policy%%
- %%Issuer Policy|issuer-policy%%
- %%Holder Policy|holder-policy%%
- %%Wallet Policy|wallet-policy%%
\ No newline at end of file
......@@ -8,12 +8,12 @@ stage: draft
hoverText: "Presentation: a (signed) digital message that contains data derived from one or more Verifiable Credentials (that have been issued by Agents of one or more Parties), as a response to a specific Presentation Request of a Verifier component."
---
## Short Description
### Short Description
## Purpose
### Purpose
## Criteria
### Criteria
## References
### References
- W3C has a [definition of verifiable presentation](https://www.w3.org/TR/vc-data-model/#dfn-verifiable-presentations).
\ No newline at end of file
......@@ -8,19 +8,27 @@ stage: draft
hoverText: "Verifier (functional component): the capability to request Peer Agents to present (provide) data from credentials (of a specified kind, issued by specified Parties), and to verify such responses (check structure, signatures, dates), according to its Principal's Verifier Policy."
---
## Short Description
A **Verifier** is is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that
### Short Description
A **Verifier** is is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that supports the %%data collector|data-collector%% as it tries to acquire %%(verifiable) credentials|credential%% from (an %%agent|agent%% of) some other %%party|party%%, for the purpose of negotiating a business transaction.
The **verifier** functionality is to support the Data Collector 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 (or Presentation Definition as it is called in the [draft DIF specfication for Presentation Exchange](https://identity.foundation/presentation-exchange)) 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 Data Collector with verified data.
It does so by:
- creating %%Presentation Requests|presentation-request%% (or Presentation Definition as it is called in the [draft DIF specfication for Presentation Exchange](https://identity.foundation/presentation-exchange)) that ask for such credentials,
- sending them to an %%agent|agent%% of that other %%party|party%% that provides %%holder|holder%% functionality,
- receiving a response from that %%agent|agent%% to the %%presentation-request%% (i.e. a '%%Presentation|presentation%%'),
- verifying that %%presentation|presentation%%, i.e. checking the signature and other proofs of the veracity of both the construction of the presentation and its contents
- returning the data that the %%data collector|data-collector%% requested, optionally with a report about which verification checks succeeded and/or which failed.
:::info Editor's note
TNO (or others) to provide additional content of this file.
:::
## Purpose
### Purpose
The purpose of the Verifier function is.
## Criteria
### Criteria
A **Verifier** is a component in the [eSSIF-Lab functional architecture](../functional-architecture) whose function is to ... (tbd).
## Functionality
### Functionality
The purpose of the Verifier component is to support the Data Collector 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).
......
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