Commit 4850de20 authored by Rieks Joosten's avatar Rieks Joosten

wip

parent b9dc134b
Pipeline #16369 passed with stage
in 2 minutes and 37 seconds
This diff is collapsed.
......@@ -8,12 +8,12 @@ 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.
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 , preferences 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.
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 , preferences 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.
......
......@@ -115,4 +115,4 @@ mentioned above, will be populated in the `glossary.md` page.
When the project is up and running, you can visit the glossary on the `/docs/essifLab-glossary` page:
<img alt="glossary-page" src={useBaseUrl('images/glossary-page.png')}/>
<img alt="glossary-page" src={useBaseUrl('docs/essifLab-glossary.md')}/>
......@@ -9,7 +9,7 @@ hoverText: "Agent (of a Party): an Actor that is executing an Action for, or on
---
### Short Description
An **Agent** is an %%actor|actor%% that is executing an action %%action|action%% for, or on behalf of some %%party|party%% (which we call the %%principal|principal%% of that agent). During the time interval in which the action is executed, the actor may execute other actions in other execution-contexts, on behalf of the same or another party. However, for the execution of a single %%action|action%%, the actor is an agent for precisely one principal. It is assumed that the principal provides its agents with the %%policies|policy%% that provide the agents with the rules, working-instructions and/or other guidance that they need to comply with when exeucting the action.
An **Agent** is an %%actor|actor%% that is executing an action %%action|action%% for, or on behalf of some %%party|party%% (which we call the %%principal|principal%% of that agent). During the time interval in which the action is executed, the actor may execute other actions in other execution-contexts, on behalf of the same or another party. However, for the execution of a single %%action|action%%, the actor is an agent for precisely one principal. It is assumed that the principal provides its agents with the %%policies|policy%% that provide the agents with the rules, working-instructions , preferences and/or other guidance that they need to comply with when exeucting the action.
### Purpose
The ability to distinguish between (non)agents is relevant in many situations, including:
......
......@@ -5,17 +5,20 @@ scopeid: essifLab
type: concept
typeid: business-transaction
stage: draft
hoverText: "Business Transaction: the exchange of goods, services, funds, or data between some Parties (called ‘participants’ of the transaction)"
hoverText: "Business Transaction: the exchange of goods, services, funds, or data between some Parties (called ‘participants’ of the transaction)."
---
import useBaseUrl from '@docusaurus/useBaseUrl';
### Short Description
A **business transaction** is an exchange of goods, services, funds, or data between some %%parties|party%%. These parties are called the %%participants of the transaction|participant%%. A typical business transaction consists of three phases. In the first phase, a %%transaction agreement|transaction-agreement%% is negotiated between the participants. That phase ends when either participant quits the negotiation, or all participants commit to the transaction, which basically is a promise to the other participants that it will keep up its end of the %%transaction agreement%%. In the second phase, the participants work to fulfill their promise. That phase ends when they deliver the results, and inform their peers of that they're done. In the final phase, participants check whether or not they have received what was promised, and that it conforms the criteria in the transaction agreement. This may lead to some discussion and possible rectifications. The final phase ends either when one of the participants escalates (e.g. goes to court), or all results are accepted. This way of looking at business transactions has been described extensively in the [DEMO](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations) transaction model.
:::info Editor's note
TNO (or others) to provide the content of this file.
TNO (or others) to provide further content/revisions.
:::
:::info Editor's note
Explanation required about 'commitment decisions' (i.e. 'promise' decisions in [DEMO](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations)).
Explanation required about '%%commitment decision|commitment-decision%%' (i.e. 'promise' decisions in [DEMO](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations)).
:::
### High Level Example
......
---
id: commitment-decision
title: "Commitment Decision"
scopeid: essifLab
type: concept
typeid: commitment-decision
stage: draft
hoverText: "Commitment Decision (of a Party regarding a Business Transaction): the decision of that Party regarding whether or not to commit to that Business Transaction, i.e. (promise) to fulfill the obligations that the associated Business Transaction Agreement assigns to that Party."
---
import useBaseUrl from '@docusaurus/useBaseUrl';
:::info Editor's note
TNO (or others) to provide the content of this file.
:::
###
---
id: data-collector-policy
title: "Data Collector Policy"
scopeid: essifLab
type: concept
typeid: data-collector-policy
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
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
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
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%%.
---
id: data-discloser-policy
title: "Data Discloser Policy"
scopeid: essifLab
type: concept
typeid: data-discloser-policy
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
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
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
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%%.
......@@ -18,7 +18,7 @@ This term enables us to refer to anything, or to postulate the existence of some
Something, anything, that some %%party|party%% knows to exist
### Related Concepts
- a %%legal entity|legal-entity%% is an entity that is known by (i.e. registered in the %%knowledge|knowledge%% of) a %%party|party%% that operates the %%legal-system|legal-system%% of a %%jurisdiction|jurisdiction%%. (Details are in the %%Jurisdictions pattern|pattern-jurisdiction%%)
- a %%legal entity|legal-entity%% is an entity that is known by (i.e. registered in the %%knowledge|knowledge%% of) a %%party|party%% that operates the %%legal system|legal-system%% of a %%jurisdiction|jurisdiction%%. (Details are in the %%Jurisdictions pattern|pattern-jurisdiction%%)
### Background
The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
......@@ -5,16 +5,16 @@ scopeid: essifLab
type: concept
typeid: essif-glue
stage: draft
hoverText: "eSSIF-Glue: interface layer that allows components with Data Collector and/or Data Discloser functionality to use the Wallet, Holder, Issuer and Verifier functionalities."
hoverText: "eSSIF-Glue: interface layer that allows components with Transaction Data Collector and/or Transaction Data Discloser functionality to use the Wallet, Holder, Issuer and Verifier functionalities."
---
### Short Description
The **eSSIF-Glue** is an interface layer that consists of a documented set of APIs between the %%Data Collectordata-collector%% and %%Data Discloser|data-discloser%% on the one hand, and the Wallet, Holder, Issuer and Verifier (WHIV) components on the other hand.
The **eSSIF-Glue** is an interface layer that consists of a documented set of APIs between the %%Transaction Data Collectortransaction-data-collector%% and %%Transaction Data Discloser|transaction-data-discloser%% on the one hand, and the Wallet, Holder, Issuer and Verifier (WHIV) components on the other hand.
Ultimately, we would like to see these APIs 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.
### Purpose
The purpose of the essif-Glue APIs is to make calling the WHIV functions as simple as possible, given the functions of the %%Data Collectordata-collector%% and %%Data Discloser|data-discloser%%
The purpose of the essif-Glue APIs is to make calling the WHIV functions as simple as possible, given the functions of the %%Transaction Data Collectortransaction-data-collector%% and %%Transaction Data Discloser|transaction-data-discloser%%
### Criterion
The set of API's described at https://gitlab.grnet.gr/essif-lab/tno-ssi-service/developer-docs.
......@@ -16,7 +16,7 @@ As parties interact with one another, i.e. conduct %%business transactions|busin
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%%.
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 , preferences 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-policy%%. A %%party|party%% whose governance process maintains a %%policy|policy%% will be called the %%governor|policy-governor%% of that policy.
......@@ -28,8 +28,8 @@ The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides
- %%Governor|policy-governor%%
- %%Policy|policy%%
- %%Digital Policy|digital-policy%%
- %%Data Discloser Policy|data-collector-policy%%
- %%Data Collector Policy|data-collector-policy%%
- %%Transaction Data Discloser Policy|transaction-data-collector-policy%%
- %%Transaction Data Collector Policy|transaction-data-collector-policy%%
- %%Verifier Policy|verifier-policy%%
- %%Issuer Policy|issuer-policy%%
- %%Holder Policy|holder-policy%%
......
......@@ -25,7 +25,7 @@ A **Holder** is a component in the [eSSIF-Lab functional architecture](../functi
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.
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 permit this, the Holder then requests its Owner’s Data Collector 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 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 permit this, the Holder then requests its Owner’s Transaction Data Collector 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.
......
......@@ -13,7 +13,7 @@ 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.
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 %%Transaction Data Discloser|transaction-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
The purpose of the Issuer function is.
......@@ -25,7 +25,7 @@ A **Issuer** is a component in the [eSSIF-Lab functional architecture](../functi
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 Data Discloser)
- sets of (related) statements or claims (e.g. as produced by the Transaction Data Discloser)
- 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.
......
---
id: participant
title: "Participant"
scopeid: essifLab
type: term
typeid: participant
conceptref: essifLab:party
stage: draft
hoverText: "Participant (in/of a Business Transaction): a Party is negotiating (or has negotiated) a Business Transaction Agreement."
---
### Purpose
<!--State the purpose(s) for which it is necessary (or at least: desirable) to define <New Term>.-->
Within the context of a %%(business) transaction|business-transaction%%, at least two %%Parties|party%% participate. From the perspective of such a transaction, we need the ability to refer to any such party.
### Notes
<!--Usually, the meaning of a term will not be _exactly_ the same as that of the concept to which it refers. Often, there are slight differences in meaning, or the term may emphasize specific characteristics of the concept, so as to accommodate specific needs of the scope in which it is defined. Please describe such deviations/emphasized characteristics in this section, and which needs that helps accommodate.-->
The term 'participant' is specifically used in the context of a (business) transaction.
### Related Terms
- %%Peer Party|peer-party%%
\ No newline at end of file
......@@ -31,7 +31,7 @@ to be elaborated
<!--Mention and link to the patterns in which this concept plays a (significant) role (possibly explaining the reason/purpose if appropriate), e.g.: -->
The concept we know as 'party' serves a central role, and therefore occurs in various patterns, such as:
- The %%Parties, Actors and Actions pattern|pattern-party-actor-action%%, which provides an overview of how this concept fits in with related concepts.
- the %%Jurisdictions pattern|pattern-jurisdiction%%, which shows that a party can operate the %%legal-system|legal-system%% of a %%jurisdiction|jurisdiction%%, enforcing the rules in some scopes to the %%(legal) entities|legal-entity%% that it knows to exist and to which these rules apply.
- the %%Jurisdictions pattern|pattern-jurisdiction%%, which shows that a party can operate the %%legal system|legal-system%% of a %%jurisdiction|jurisdiction%%, enforcing the rules in some scopes to the %%(legal) entities|legal-entity%% that it knows to exist and to which these rules apply.
---
[^1]: Reasoning means: inferring conclusions from data, regardless of the kind of logic that is being used, or whether the reasoning is coherent, or consistent.
......
......@@ -6,13 +6,16 @@ type: term
typeid: peer-party
conceptref: essifLab:party
stage: draft
hoverText: "Peer Party (of some other Party that is a participant in a Business Transaction): the Party that also participates in that Business Transaction."
hoverText: "Peer Party (of another Party that is a participant in a Business Transaction): a Party that also participates in that Business Transaction."
---
### Purpose
<!--State the purpose(s) for which it is necessary (or at least: desirable) to define <New Term>.-->
Within the context of a (business) transaction, at least two %%Parties|party%% participate. From the perspective of any such party, we need the ability to refer to (any of) the other party/parties.
Within the context of a %%(business) transaction|business-transaction%%, at least two %%parties|party%% participate. From the perspective of any such party, we need the ability to refer to (any of) the other party/parties.
### Notes
<!--Usually, the meaning of a term will not be _exactly_ the same as that of the concept to which it refers. Often, there are slight differences in meaning, or the term may emphasize specific characteristics of the concept, so as to accommodate specific needs of the scope in which it is defined. Please describe such deviations/emphasized characteristics in this section, and which needs that helps accommodate.-->
The term 'peer party' is specifically used in the context of a (business) transaction.
### Related Terms
- %%Participant (of a Business Transaction)|participant%%
......@@ -21,8 +21,8 @@ The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides
- %%Governor|policy-governor%%
- %%Policy|policy%%
- %%Digital Policy|digital-policy%%
- %%Data Discloser Policy|data-collector-policy%%
- %%Data Collector Policy|data-collector-policy%%
- %%Transaction Data Discloser Policy|transaction-data-collector-policy%%
- %%Transaction Data Collector Policy|transaction-data-collector-policy%%
- %%Verifier Policy|verifier-policy%%
- %%Issuer Policy|issuer-policy%%
- %%Holder Policy|holder-policy%%
......
......@@ -16,7 +16,7 @@ An %%agent|agent%% must have access to the policy that its %%principal|principal
It should be part of the %%principal's|principal%% governance processes
- to establish, maintain and evaluate policies for every kind of action that its agents may execute,
- to derive artifacts from such policies that are useable by the various %%agents|agent%% (digital, human, or otherwise) that have a right or duty to execute actions for the %%principal|principal%% to which such policies apply. So, machine-readable policies should be derived for %%digital-agents|digital-agent%%, and human-readable policies (in different languages if that is appropriate) for non-digital agents.
- to derive artifacts from such policies that are useable by the various %%agents|agent%% (digital, human, or otherwise) that have a right or duty to execute actions for the %%principal|principal%% to which such policies apply. So, machine-readable policies should be derived for %%digital agents|digital-agent%%, and human-readable policies (in different languages if that is appropriate) for non-digital agents.
- to publish such artifacts such that at least every of its %%agents|agent%% that may need to access them, can find and access them as needed.
- to inform its %%agents|agent%% whenever updates have been made that they need to be aware of (specifically if agents are allowed to keep local copies of such artifacts).
......@@ -38,8 +38,8 @@ The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides
- %%Governor|policy-governor%%
- %%Policy|policy%%
- %%Digital Policy|digital-policy%%
- %%Data Discloser Policy|data-collector-policy%%
- %%Data Collector Policy|data-collector-policy%%
- %%Transaction Data Discloser Policy|transaction-data-collector-policy%%
- %%Transaction Data Collector Policy|transaction-data-collector-policy%%
- %%Verifier Policy|verifier-policy%%
- %%Issuer Policy|issuer-policy%%
- %%Holder Policy|holder-policy%%
......
---
id: transaction-agreement
title: "Transaction Agreement"
scopeid: essifLab
type: concept
typeid: transaction-agreement
stage: draft
hoverText: "Transaction Agreement (for a specific Business Transaction): the set of rules that specify the rights (expectations) and duties (obligations) of Participants towards one another in the context of a specific Business Transaction."
---
import useBaseUrl from '@docusaurus/useBaseUrl';
:::info Editor's note
TNO (or others) to provide the content of this file.
:::
###
---
id: transaction-data-collector-policy
title: "Transaction Data Collector Policy"
scopeid: essifLab
type: concept
typeid: transaction-data-collector-policy
stage: draft
hoverText: "Transaction Data Collector Policy: a Digital Policy that enables an operational Transaction Data Collector component to function according to the rules of its Policy Governor."
---
### Short Description
A **Transaction Data Collector Policy** is a %%digital policy|digital-policy%% that enables an operational %%Transaction Data Collector component|transaction-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
The purpose of a **Transaction Data Collector Policy** is to enable the creation of (technical) components that implement the generic %%Transaction Data Collector|transaction-data-collector%% functionality that will subsequently use such policies to guide their behaviour.
### Criteria
A **Transaction Data Collector Policy** is a %%digital policy|digital-policy%% that enables an operational %%Transaction Data Collector component|transaction-data-collector%% to function according to the rules, working-instructions , preferences and other guidance of its %%Policy Governor|policy-governor%%.
---
id: transaction-data-discloser-policy
title: "Transaction Data Discloser Policy"
scopeid: essifLab
type: concept
typeid: transaction-data-discloser-policy
stage: draft
hoverText: "Transaction Data Discloser Policy: a Digital Policy that enables an operational Transaction Data Discloser component to function according to the rules of its Policy Governor."
---
### Short Description
A **Transaction Data Discloser Policy** is a %%digital policy|digital-policy%% that enables an operational %%Transaction Data Discloser component|transaction-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
The purpose of a **Transaction Data Discloser Policy** is to enable the creation of (technical) components that implement the generic %%Transaction Data Discloser|transaction-data-discloser%% functionality that will subsequently use such policies to guide their behaviour.
### Criteria
A **Transaction Data Discloser Policy** is a %%digital policy|digital-policy%% that enables an operational %%Transaction Data Discloser component|transaction-data-discloser%% to function according to the rules, working-instructions , preferences and other guidance of its %%Policy Governor|policy-governor%%.
---
id: data-discloser
title: "Data Discloser"
id: transaction-data-discloser
title: "Transaction Data Discloser"
scopeid: essifLab
type: concept
typeid: data-discloser
typeid: transaction-data-discloser
stage: draft
hoverText: "Data Discloser: a functional component that is capable of disclosing data."
hoverText: "Transaction Data Discloser: a functional component that is capable of disclosing data."
---
### 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:
A **Transaction 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)
- knowledge (including judgements) that this Party has about %%Entities|entity%% (people, organizations, things, orders, deliveries, etc.)
The Data Discloser uses a %%data-collector-policy|data-collector-policy%% to learn about the applicable (business) rules of its %%principal|principal%%. Such a policy may specify e.g. which types of credentials its principal is willing to (have) issue(d), to whom such credentials may be issued and the kinds of assurances that must be obtained before doing so, etcetera.
The Transaction Data Discloser uses a %%Transaction Data Discloser policy|transaction-data-discloser-policy%% to learn about the applicable (business) rules of its %%principal|principal%%. Such a policy may specify e.g. which types of credentials its principal is willing to (have) issue(d), to whom such credentials may be issued and the kinds of assurances that must be obtained before doing so, etcetera.
The Data Discloser uses the %%eSSIF-Glue|essif-glue%% interface to access the %%Wallet|wallet%%, %%Holder|holder%%, %%Issuer|issuer%% and %%Verifier|verifier%% functionalities.
The Transaction Data Discloser uses the %%eSSIF-Glue|essif-glue%% interface to access the %%Wallet|wallet%%, %%Holder|holder%%, %%Issuer|issuer%% and %%Verifier|verifier%% functionalities.
### 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.
The purpose of the Transaction 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
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%%.
A **Transaction 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
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.[^1] This allows the Data Discloser to construct data objects that conform to this information schema, and present it to the Issuer component for actual issuing.
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.[^1] This allows the Transaction Data Discloser to construct data objects that conform to this information schema, and present it to the Issuer component for actual issuing.
The Data Discloser Issuing Policy specifies the kinds of (linked-)data-objects that credentials may be created for. This allows the Data Discloser 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.
The Transaction Data Discloser Issuing Policy specifies the kinds of (linked-)data-objects that credentials may be created for. This allows the Transaction Data Discloser 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 Data Discloser 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.
You can think of the Transaction Data Discloser 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 Data Discloser 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.
The Transaction Data Discloser 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.
-----
......
---
id: transaction-form
title: "Transaction Form"
scopeid: essifLab
type: concept
typeid: transaction-form
stage: draft
hoverText: "Transaction Form (for some kind of Business Transaction and some Party): the specification of the set of data that this Party needs to (a) commit to a (proposed) Business Transaction of that kind, (b) fulfill its duties/obligations and (c) escalate if necessary."
---
import useBaseUrl from '@docusaurus/useBaseUrl';
:::info Editor's note
TNO (or others) to provide the content of this file.
:::
###
......@@ -9,14 +9,14 @@ hoverText: "Verifier (functional component): the capability to request Peer Agen
---
### 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.
A **Verifier** is is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that supports the %%Transaction Data Collector|transaction-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.
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.
- returning the data that the %%Transaction Data Collector|transaction-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.
......@@ -30,11 +30,11 @@ A **Verifier** is a component in the [eSSIF-Lab functional architecture](../func
### 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).
The purpose of the Verifier component is to support the Transaction 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).
Typically, the Data Collector 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 Data Collector 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 Data Collector policy.
Typically, the Transaction Data Collector 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 Transaction Data Collector 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 Transaction Data Collector 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 Data Collector 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.
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 Transaction Data Collector 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.
......@@ -51,4 +51,4 @@ In order to make the Verifier component work, a Verifier Policy/Preferences obje
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 Data Collector, containing the transaction-id, the data it has received, and the results of the various checks.
\ No newline at end of file
Then, the verifier will send a message to the Transaction Data Collector, containing the transaction-id, the data it has received, and the results of the various checks.
\ No newline at end of file
......@@ -6,7 +6,7 @@ sidebar_label: Vision and Purpose
import useBaseUrl from '@docusaurus/useBaseUrl';
# Vision
## Vision
The eSSIF-Lab vision is that Self-sovereign Identity (SSI) will *empower European and other citizens* by providing new means to manage privacy by eliminating logins and making electronic transactions fast and safe both in the Internet and in 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.
......@@ -14,13 +14,13 @@ The current situation is that SSI solutions that are being created and brought t
The situation we would like to see is one in which we have SSI-enabled, interoperable, scalable and business/information agnostic technologies, that form an infrastructure that every application for every party can use to serve its own objectives. This infrastructure, that enables the electronic exchange of verified (personal and non-personal) data, must be so easy to access and use for such parties that they will no longer need to be concerned about actual (SSI) technologies that have empowered them to make this happen. Rather, they will only need to think about, and decide which kinds of information they want to obtain for conducting specific business transactions and which parties they trust for providing such information. Also, they will need to think about, and decide which kinds of information they themselves are willing to provide to others in this new SSI world.
# Purpose
## Purpose
:::tip **The purpose of the eSSIF-Lab...**
... is to specify, develop and validate technological and non-technological (e.g. governance) means that support people, businesses and governments to think about, design and operate their (information) processes and conduct business transactions with one another that are electronically supported using SSI technology.
:::
# Context
## Context
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[^1].
......@@ -28,7 +28,7 @@ In the context of these rights and freedoms, we seek to electronically support %
Supporting such transactions requires each participant to have one or more %%electronic (digital) agents|digital-agent%%, i.e. equipment (e.g. an app on a mobile phone, a webserver, a browser, …) that provides such support and that (provably) acts on behalf of that participant.
# Work-In-Progress: Where We Want To Go
## Work-In-Progress: Where We Want To Go
This functional architecture is a work-in-progress that is currently being conducted by parties that are funded by the [eSSIF-Lab project](https://essif-lab.eu/). Working with parties that have different backgrounds presents the challenge of resolving the issues that arise from such differences e.g. as technical interoperability or semantic interoperability. The eSSIF-Lab project adds '%%documentation interoperability|documentation-interop%%' to this.
......
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