Commit 1ba919ca authored by Rieks Joosten's avatar Rieks Joosten

wip

parent 34f4fbd4
Pipeline #16047 passed with stage
in 3 minutes and 3 seconds
This diff is collapsed.
......@@ -39,9 +39,9 @@ The figure below is a high-level visualization of the filling in and validation
*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 communications 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.
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 communications 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[^3]. *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.
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[^3]. *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.
......
......@@ -5,11 +5,11 @@ scopeid: essifLab
type: concept
typeid: action
stage: draft
hoverText: "Action: something that is actually done/executed by a single Actor (as a single operation) for some Party within a specific context."
hoverText: "Action: something that is actually done/executed (by a single Actor, as a single operation, for a given Party within a specific context)."
---
### Short Description
An **Action** is something that is actually done/executed by a %%actor|actor%% in some context (i.e. in a specific place, at a specific time). During the time interval in which the action is executed, the actor may still execute other actions in other execution-contexts (multi-tasking). An action is executed for, or on behalf of, a specific %%party|party%%, which means that the primary guidance for executing the action, e.g. how to execute it, boundary conditions within which the execution must take place, etc., comes from the %%knowledge|knowledge%% of that party. The actor is assumed to have appropriate access to the knowledge of that party. In order to properly execute the action, the executing actor may also use additional knowledge(s) to which it has access.
An **Action** is something that is actually done/executed by a %%actor|actor%% in some context (i.e. in a specific place, at a specific time). During the time interval in which the action is executed, the actor may still execute other actions in other execution-contexts (multi-tasking). An action is executed for, or on behalf of, a specific %%party|party%%, which means that the primary guidance for executing the action, e.g. how to execute it, boundary conditions within which the execution must take place, etc., comes from a %%policy|policy%% that this party has established for actions of that kind. The actor is assumed to have appropriate access to that policy.
### Purpose
The ability to distinguish between (non)actions allows one to determine which (kinds of) %%actors|actor%% are capable of executing actions (e.g. by establishing that they have the competences required by the party), and as a consequence may be permitted and/or required to execute them. Also, this ability enables parties to determine the execution-policy, i.e. the set of rules and other guidance that actors should obey or comply with when exeucting an action on its behalf.
......@@ -24,6 +24,8 @@ An **Action** is something that is done by an actor, can be considered a single
### Related Concepts
<!--Link to any concepts that are similar but distinct, with a note about the relationship.-->
- OED defines Action as the fact or process of doing something, typically to achieve an aim ([OED](https://www.lexico.com/definition/action)), which is too generic for our purposes.
- %%actor|actor%%
- %%agent|agent%%
### 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
......@@ -24,5 +24,11 @@ Entity that is capable of actually executing %%actions|action%% (acting, doing t
- Software applications qualify, provided they are actually running on hardware. An app that is just sitting e.g. on a mobile phone but isn't executed does not qualify.
- Enterprises, governments, and other %%organizations|organization%% do not qualify.
### Related concepts
- %%digital actor|digital-actor%%
- %%peer actor|peer-actor%%
- %%agent|agent%%
- %%principal|principal%%
### Background
The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
......@@ -5,18 +5,18 @@ scopeid: essifLab
type: concept
typeid: agent
stage: draft
hoverText: "Agent (of a Party): an Actor that is (at that point in time) executing an Action for, or on behalf of a Party (the Principal of that Actor)."
hoverText: "Agent (of a Party): an Actor that is (at that point in time) executing an Action for, or on behalf of a Party (called the Principal of that Actor)."
---
### Short Description
%%Actors|actor%% execute %%actions|action%% for, or on behalf of some %%party|party%% (the %%principal|principal%% of that agent), because parties are not considered to be capable of acting. Agents must act in accordance with their %%principal|principal%%, which means that for every kind of action, the principal must provide the proper guidance for their agents, e.g. in terms of policies (rules), working instructions, programs etc. We use the term %%digital agent|digital-agent%% to refer to agents that operate in a digital domain.
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.
### Purpose
The ability to distinguish between (non)agents is relevant in many situations, including:
- electronic communication: the agent
### Criterion
a property that is attributed to an %%Actor|actor%% whenever it is executing an action for, or on behalf of some %%party|party%% (its %%principal|principal%%).
An **Agent** is a role that an %%actor|actor%% fulfills with respect to some %%party|party%% when that actor is executing some %%action|action%% for, or on behalf of that party.
### Examples
......
......@@ -9,9 +9,12 @@ hoverText: "Business Transaction: the electronic exchange of goods, services, fu
---
:::info Editor's note
TNO to provide the content of this file.
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]).
:::
### Notes
......
......@@ -9,6 +9,6 @@ hoverText: "Colleague (of an Agent): any other Agent that has the same Principal
---
:::info Editor's note
TNO to provide the content of this file.
TNO (or others) to provide the content of this file.
:::
---
id: communication-channel
title: "Communication Channel"
scopeid: essifLab
type: concept
typeid: communication-channel
stage: draft
hoverText: "Communication Channel: a (digital or non-digital) means by which two Actors can exchange messages with one another"
---
:::info Editor's note
TNO (or others) to provide further content of this file.
:::
### Notes
A %%Communication Channel|communication-channel%% is said to be **digital** if it uses a digital means to exchange (digital) messages between two %%digital actors|digital-actor%%.
A %%Communication Channel|communication-channel%% is said to be **secure** if it provides the following guarantees:
- every of its endpoint is being used by precisely one %%actor|actor%%;
- during its entire lifetime, each endpoint will only be used by this %%actor|actor%% (endpoint authentication; note that identification of the %%actor|actor%% that uses an endpoint, or its %%principal|principal%% is NOT required);
- only the %%actors|actor%% that use an endpoint are capable of transmitting and reading messages through that channel (message secrecy - typically obtained by encrypting the messages);
- the receiver of a message can determine whether or not the message has been received as it was transmitted (message integrity).
### Related Concepts
- %%Communication Session|communication-session%%
---
id: communication-session
title: "Communication Session"
scopeid: essifLab
type: concept
typeid: communication-session
stage: draft
hoverText: "Communication Session: the time interval during which two Actors have an established Communication Channel."
---
:::info Editor's note
TNO (or others) to provide the content of this file.
:::
......@@ -9,5 +9,5 @@ hoverText: "Corpus (of Terminology): the documentation that describes the Knowle
---
:::info Editor's note
TNO to provide the content of this file.
TNO (or others) to provide the content of this file.
:::
......@@ -5,11 +5,11 @@ scopeid: essifLab
type: concept
typeid: credential
stage: draft
hoverText: "Credential: data, representing a set of statements made by one Party (the author of the credential)."
hoverText: "Credential: data, representing a set of statements (claims) made by one Party (the author of the credential)."
---
:::info Editor's note
TNO to provide the content of this file.
TNO (or others) to provide the content of this file.
:::
### Related Concepts
......@@ -17,3 +17,7 @@ TNO to provide the content of this file.
- %%verified data|verified-data%%
- %%validated data|validated-data%%
### References:
- W3C VC [definition of 'credential'](https://www.w3.org/TR/vc-data-model/#dfn-credential)
- [W3C Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model/)
---
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%%.
This diff is collapsed.
---
id: transaction-result-dispatcher
title: "Transaction Result Dispatcher"
id: data-discloser
title: "Data Discloser"
scopeid: essifLab
type: concept
typeid: transaction-result-dispatcher
typeid: data-discloser
stage: draft
hoverText: "Transaction Result Dispatcher (TRD): a functional component that is capable of stating (various, sometimes intermediary) results of Business 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."
hoverText: "Data Discloser: a functional component that is capable of disclosing data."
---
## Short Description
A **Transaction Result Dispatcher (TRD)** 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 **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 TRD uses a %%TRD-policy|trd-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 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 TRD uses the %%eSSIF-Glue|essif-glue%% interface to access the %%Wallet|wallet%%, %%Holder|holder%%, %%Issuer|issuer%% and %%Verifier|verifier%% functionalities.
The 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 TRD 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 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 **Transaction Result Dispatcher (TRD)** 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 **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 TRD 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 Data Discloser to construct data objects that conform to this information schema, and present it to the Issuer component for actual issuing.
The TRD Issuing Policy specifies the kinds of (linked-)data-objects that credentials may be created for. This allows the TRD 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 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.
You can think of the TRD 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 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 TRD 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 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: 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%%.
---
id: digital-communication-channel
title: "Digital Communication Channel"
scopeid: essifLab
type: concept
typeid: digital-communication-channel
stage: draft
hoverText: "Digital Communication Channel: a digital means by which two Digital Actors can exchange messages with one another"
---
:::info Editor's note
TNO (or others) to provide the content of this file.
:::
See: %%Communication Channel|communication-channel%%.
### Related Concepts
- %%Communication Session|communication-session%%
\ No newline at end of file
......@@ -9,7 +9,7 @@ hoverText: "Employee (of a Party): an Actor for whom/which it is realistic that
---
:::info Editor's note
TNO to provide the content of this file.
TNO (or others) to provide the content of this file.
:::
### Background
......
......@@ -9,7 +9,7 @@ hoverText: "Employer (of an Actor): a Party on whose behalf this Actor might exe
---
:::info Editor's note
TNO to provide the content of this file.
TNO (or others) to provide the content of this file.
:::
### Background
......
......@@ -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 %%jurisdiction 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 TVE and/or TRD functionality to use the Wallet, Holder, Issuer and Verifier functionalities."
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."
---
### Short Description
The **eSSIF-Glue** is an interface layer that consists of a documented set of APIs between the %%TVE|tve%% and %%TRD|trd%% 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 %%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.
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 %%TVE|tve%% and %%TRD|trd%%
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%%
### Criterion
The set of API's described at https://gitlab.grnet.gr/essif-lab/tno-ssi-service/developer-docs.
......@@ -9,7 +9,7 @@ hoverText: "Holder Policy: a Digital Policy that enables an operational Holder c
---
:::info Editor's note
TNO to provide the content of this file.
TNO (or others) to provide the content of this file.
:::
### Related Concepts
......
......@@ -21,7 +21,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 TVE 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 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.
......
......@@ -9,7 +9,7 @@ hoverText: "Issuer Policy: a Digital Policy that enables an operational Issuer c
---
:::info Editor's note
TNO to provide the content of this file.
TNO (or others) to provide the content of this file.
:::
### Related Concepts
......
......@@ -9,7 +9,7 @@ hoverText: "Issuer (functional component): the capability to construct Credentia
---
## 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 %%TRD|trd%%) 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.
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.
## Purpose
......@@ -22,7 +22,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 TRD)
- sets of (related) statements or claims (e.g. as produced by the 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.
......
......@@ -27,7 +27,7 @@ the composition of one %%scope|scope%%, one %%legal system|legal-system%% and on
### Background
<!--Mention and link to the patterns in which this concept plays a (significant) role (possibly explaining the reason/purpose if appropriate), e.g.: -->
The %%jurisdiction pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts.
The %%Jurisdictions pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts.
### Notes
<!--This (optional) section is the place to put anything for which there is no other good place to put it.-->
......
......@@ -27,4 +27,4 @@ A **Legal Entity** is an %%entity|entity%% that is known by and recognized to ex
### Background
<!--Mention and link to the patterns in which this concept plays a (significant) role (possibly explaining the reason/purpose if appropriate), e.g.: -->
The %%jurisdiction pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts.
The %%Jurisdictions pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts.
......@@ -15,4 +15,4 @@ We need the term **legal jurisdiction** because it is common practice for people
### Background
<!--Mention and link to the patterns in which this concept plays a (significant) role (possibly explaining the reason/purpose if appropriate), e.g.: -->
The %%jurisdiction pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts.
The %%Jurisdictions pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts.
......@@ -30,4 +30,4 @@ A system in which rules are defined ([legislature](https://en.wikipedia.org/wiki
### Background
<!--Mention and link to the patterns in which this concept plays a (significant) role (possibly explaining the reason/purpose if appropriate), e.g.: -->
The %%jurisdiction pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts.
\ No newline at end of file
The %%Jurisdictions pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts.
\ No newline at end of file
......@@ -10,7 +10,7 @@ hoverText: "Mental Model: a casual and formal description (Pattern) of a set of
---
:::info Editor's note
TNO to provide the content of this file.
TNO (or others) to provide the content of this file.
:::
See also: %%pattern|pattern%%.
\ No newline at end of file
......@@ -23,9 +23,9 @@ to be elaborated
### Background
<!--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, suc as:
- The %%party-actor-action|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
- the %%jurisdiction 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 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.
---
[^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.
......
......@@ -8,6 +8,8 @@ stage: draft
hoverText: "Pattern-file: a file that defines/specifies a Pattern."
---
import useBaseUrl from '@docusaurus/useBaseUrl';
### Short Description
A **pattern-file** is a file that describes a %%pattern|pattern%%. To faciliate authors, a self-explanatory [template file](/terminology-engine-v1-templates/pattern-file.md) is available.
......
......@@ -11,6 +11,6 @@ hoverText: "The Mandates, Delegation and Hiring pattern (which remains to be doc
import useBaseUrl from '@docusaurus/useBaseUrl';
:::info Editor's note
TNO to provide the content of this file.
TNO (or others) to provide the content of this file.
:::
......@@ -8,6 +8,8 @@ stage: draft
hoverText: "The Mental Mmodels pattern captures the foundational Concepts and relations that we need for creating, maintaining and using (decentralized) Vocabularies (Terminologies) that groups of people can use for the specific purposes they pursue."
---
import useBaseUrl from '@docusaurus/useBaseUrl';
### Purpose
<!--Concisely describe what can you do with the pattern that is (at least) harder if you didn't have it.-->
This pattern captures the foundational concepts and relations that we need for creating, maintaining and using vocabularies (terminologies) that groups of people can use for the specific purposes they pursue. Alternatively, we need these concepts to allow people to use 'decentralized vocabularies' that %%parties|party%% may create, maintain and use in a self-sovereign fashion - which means that each of them decides for itself what terms to use in what meaning, yet be able to communicate with other such %%parties|party%% in such a way that a correct understanding of what the other means, can more or less be guaranteed.
......
......@@ -11,5 +11,5 @@ hoverText: "The eSSIF-Lab Terminology Pattern describes the relations between Te
import useBaseUrl from '@docusaurus/useBaseUrl';
:::info Editor's note
TNO to provide the content of this file.
TNO (or others) to provide the content of this file.
:::
---
id: peer-actor
title: "Peer Actor"
scopeid: essifLab
type: term
typeid: peer-actor
conceptref: essifLab:Actor
stage: draft
hoverText: "Peer Actor (of some other Actor in a Communication Session): the Actor with whom/which this other Actor is communicating in that Communications Session."
---
:::info Editors' note
TNO (or others) to revise the contents of this file.
:::
### Short Description
The **peer actor** of some other %%actor|actor%% in a %%communication session|communication-session%% is the actor with whom/which this other actor is communicating in that session. In other words: it is the actor 'at the other side' of the %%communication channel|communication-channel%% that these actors use to exchange messages in.
### Purpose
From the perspective of an %%actor|actor%% that has a %%communication session|communication-session%% with antother actor, we need a term to refer to this other actor that is being communicated with.
......@@ -6,9 +6,13 @@ type: term
typeid: peer-agent
conceptref: essifLab:Agent
stage: draft
hoverText: "Peer Agent (of another Agent): the Agent with whom this other Agent is communicating in the context of a Business Transaction."
hoverText: "Peer Agent (of some other Agent in a Communication Session): the Agent with whom/which this other Agent is communicating in that Communications Session."
---
:::info Editors' note
TNO (or others) to revise the contents of this file.
:::
### Purpose
<!--State the purpose(s) for which it is necessary (or at least: desirable) to define <New Term>.-->
%%Parties|party%% that participate in a (business) transaction may use %%Agents|agent%%, e.g. for conducting communications, exchanging information, etc. We need a term that can be used in the context of an Agent of such a Party to refer to an Actor with which that Agent communicates, and of which it has been established that it is actually an Agent of a %%Peer Party|peer-party%% of the Party for which it is communicating.
......
......@@ -6,7 +6,7 @@ type: term
typeid: peer-party
conceptref: essifLab:party
stage: draft
hoverText: "Peer Party (of some other Party): the Party that is a participant in a Business Transaction of that other Party."
hoverText: "Peer Party (of some other Party that is a participant in a Business Transaction): the Party that also participates in that Business Transaction."
---
### Purpose
......
......@@ -9,13 +9,13 @@ hoverText: "Policy Governor (of a Policy): the Party that is the Owner of the Po
---
:::info Editor's note
TNO to provide the content of this file.
TNO (or others) to provide the content of this file.
:::
### Related Concepts
- %%Digital Policy|digital-policy%%
- %%TRD Policy|trd-policy%%
- %%TVE Policy|tve-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%%
......
......@@ -29,3 +29,6 @@ A **policy** is
- is authored by a single %%Party|party%% (the author or %%owner|owner%% of the policy);
- may have multiple representations of the rules, working instructions and/or other guidance, which are derived from the policy itself, in such a way that that any %%actor|actor%% that has a right or duty to execute an %%action|action%% on behalf of the policy's author can do so according to its intentions;
- is accessable to, and must be complied with by an %%agent|agent%% of that policy's author 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
......@@ -9,5 +9,5 @@ hoverText: "Presentation Request: a (signed) digital message that a Verifier com
---
:::info Editor's note
TNO to provide the content of this file.
TNO (or others) to provide the content of this file.
:::
......@@ -5,7 +5,7 @@ scopeid: essifLab
type: concept
typeid: principal
stage: draft
hoverText: "Principal (of an Actor): A Party for whom, or on behalf of whom, the Actor works (the latter is then an Agent for that Party)."
hoverText: "Principal (of an Actor): A Party for whom, or on behalf of whom, the Actor works (this Actor is then called an Agent of that Party)."
---
### Short Description
......
......@@ -9,7 +9,7 @@ hoverText: "Risk: the deviation of the expected realization (e.g. results) of an
---
:::info Editor's note
TNO to provide the content of this file.
TNO (or others) to provide the content of this file.
:::
### References
......
This diff is collapsed.
---
id: trd-policy
title: "TRD Policy"
scopeid: essifLab
type: concept
typeid: trd-policy
stage: draft
hoverText: "TRD Policy: a Digital Policy that enables an operational TRD component to function according to the rules of its Policy Governor."
---
## Short Description
A **Transaction (Validation) Engine** or **TRD** is a functional component that provides business applications with forms that users have filled in, and where the content of such forms is valid for making decision(s) by this application. The TRD uses a machine readable TRD-policy
## Purpose
The purpose of the Transaction (Validation) Engine (TRD) is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an %%agent|agent%% of) its %%owner|owner%% to decide whether or not to engage in a (new) transaction of the specified type.
## Criteria
A **Transaction (Validation) Engine** or **TRD** is a component in the [eSSIF-Lab functional architecture](../functional-architecture) whos function is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an %%agent|agent%% of) its %%owner|owner%% to decide whether or not to engage in a (new) transaction of the specified type.
## Functionality
Typically, the TRD would start a transaction either
- when it receives a request from some Agent of another Party for engaging in a transaction of a specific kind.
- when it is instructed by, or on behalf of its Owner, to request a specific kind of transaction to some Agent of another Party.[^1]
In either case, a transaction form (object, context) has to be created that matches the kind of transaction, and a ‘**transaction-id**’ must be generated that identifies this form/object/context. It will be used for binding incoming or outgoing messages to this transaction, enabling communications to remain congruent, not only with the Agent that requested the transaction, but also with other Agents from the same Owner and/or using different communications channels.
Handling/managing the various communications channels through which data can be exchanged is also a task of the TRD[^2]. One reason for this is that negotiating a transaction not only requires data to be acquired, but also to be provided to the peer participant. Another reason is that the peer participant may use multiple Agents to provide such data, e.g. human Agents (that might use web-browsers, social-media apps, phones, or physical visits), SSI Agents (that use the SSI infrastructure), or other electronic Agents (e.g. services that can provide data when appropriate permissions are submitted - e.g. user consent tokens).
Thus, the TRD is generally considered capable of obtaining data through different communications channels. However, the technical tracks of eSSIF-Lab will exclusively focus on the communications channel through which credentials can be requested and obtained. Any extensions or business productization of TRD designs may be considered in the business tracks of eSSIF-Lab. The latter is not considered any further in this section.
In order to acquire data through SSI mechanisms for filling in a form for a specific kind of transaction, the TRD needs to know what kinds of credentials it should ask for, which Parties its Owner trusts to issue such credentials, what kinds of verification proofs for such credentials must hold and which may be disregarded.[^3] Also, when the TRD gets a credential that satisfies the necessary verification proofs, it needs a way to map the contents of that credential to the structure of the transaction context that is used internally by (other systems of) its Owner.[^4] Also, as the TRD gets more and more data - which it may get through multiple, different channels - it needs to determine whether or not the resulting set is sufficiently consistent and coherent.[^5]