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

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%%.
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