Commit 6e06004c authored by Rieks Joosten's avatar Rieks Joosten

Merge branch 'terminology-rieks' into TEv1-glossary-enhancements

parents 8ce48f40 96eeb127
......@@ -174,16 +174,17 @@ with "vocabulary"
// CLEANING UP UNINTENDED CHANGES
// Remove all `%%showtext|reftext%%` in docusaurus header.
replace-regex "^(---\s*\nid:(?:[^%]*\n|(?:glossaryText):.*\n){1,10}[^%]*)%%([^\|]*)\|(?:[^%]*)%%(?=(?:.*[\n\r]){1,10}---)"
with "$1$2"
replace-regex "^(---\s*\nid:(?:[^%]*\n|(?:glossaryText):.*\n){1,10}[^%]*)%%([^\|]*)\|(?:[^%]*)%%(?=(?:.*[\n\r]){1,10}---)"
with "$1$2"
replace-regex "^(---\s*\nid:(?:[^%]*\n|(?:glossaryText):.*\n){1,10}[^%]*)%%([^\|]*)\|(?:[^%]*)%%(?=(?:.*[\n\r]){1,10}---)"
with "$1$2"
replace-regex "^(---\s*\nid:(?:[^%]*\n|(?:glossaryText):.*\n){1,10}[^%]*)%%([^\|]*)\|(?:[^%]*)%%(?=(?:.*[\n\r]){1,10}---)"
with "$1$2"
replace-regex "^(---\s*\nid:(?:[^%]*\n|(?:glossaryText):.*\n){1,10}[^%]*)%%([^\|]*)\|(?:[^%]*)%%(?=(?:.*[\n\r]){1,10}---)"
with "$1$2"
// This has been commented out because for one reason or another, it doesn't work and sometimes makes the script not terminate.
// replace-regex "^(---\s*\nid:(?:[^%]*\n|(?:glossaryText):.*\n){1,10}[^%]*)%%([^\|]*)\|(?:[^%]*)%%(?=(?:.*[\n\r]){1,10}---)"
// with "$1$2"
// replace-regex "^(---\s*\nid:(?:[^%]*\n|(?:glossaryText):.*\n){1,10}[^%]*)%%([^\|]*)\|(?:[^%]*)%%(?=(?:.*[\n\r]){1,10}---)"
// with "$1$2"
// replace-regex "^(---\s*\nid:(?:[^%]*\n|(?:glossaryText):.*\n){1,10}[^%]*)%%([^\|]*)\|(?:[^%]*)%%(?=(?:.*[\n\r]){1,10}---)"
// with "$1$2"
// replace-regex "^(---\s*\nid:(?:[^%]*\n|(?:glossaryText):.*\n){1,10}[^%]*)%%([^\|]*)\|(?:[^%]*)%%(?=(?:.*[\n\r]){1,10}---)"
// with "$1$2"
// replace-regex "^(---\s*\nid:(?:[^%]*\n|(?:glossaryText):.*\n){1,10}[^%]*)%%([^\|]*)\|(?:[^%]*)%%(?=(?:.*[\n\r]){1,10}---)"
// with "$1$2"
// Remove all `%%showtext|reftext%%` occurrences in markdown headers
replace-regex "(^#+\s+.*?)%%([^\|]*)\|([^%]*)%%(.*$)"
......
......@@ -5,8 +5,8 @@ scopeid: essifLab
type: concept
typeid: action-type
stage: draft
hoverText: "Action Type/Class: the specification of properties and characteristics that that Actions must have to qualify as instance of that class; also: the set of Actions that actually have these properties and characteristics."
glossaryText: "the specification of properties and characteristics that that %Actions% must have to qualify as instance of that class; also: the set of %Actions% that actually have these properties and characteristics."
hoverText: "Action Type/Class: the specification of properties and characteristics that such Actions must have in order to qualify as instance of that class, or the set of Actions that actually have these properties and characteristics."
glossaryText: "the specification of properties and characteristics that that %%actions|action%% must have in order to qualify as instance of that class, or the set of %%actions|action%% that actually have these properties and characteristics."
---
:::info Editor's note
......
......@@ -6,7 +6,7 @@ type: concept
typeid: action
stage: draft
hoverText: "Action: something that is actually done/executed - by a single Actor (on behalf of a given Party), as a single operation in a specific context."
glossaryText: "something that is actually done/executed - by a single %Actor% (on behalf of a given %Party%), as a single operation in a specific context."
glossaryText: "something that is actually done/executed - by a single %%actor|actor%% (on behalf of a given %%party|party%%), as a single operation in a specific context."
---
### Short Description
......
......@@ -6,7 +6,7 @@ type: concept
typeid: actor
stage: draft
hoverText: "Actor: Entity that can act (do things), e.g. people, machines, but not Organizations."
glossaryText: "Entity that can act (do things), e.g. people, machines, but not %Organizations%."
glossaryText: "Entity that can act (do things), e.g. people, machines, but not %%organizations|organization%%."
---
### Short Description
......
......@@ -6,7 +6,7 @@ type: concept
typeid: agent
stage: draft
hoverText: "Agent (of a Party): an Actor that is executing an Action on behalf of a Party (called the Principal of that Actor)."
glossaryText: "an %Actor% that is executing an %Action% on behalf of a %Party% (called the %Principal% of that %Actor%)."
glossaryText: "an %%actor|actor%% that is executing an %%action|action%% on behalf of a %%party|party%% (called the %%principal|principal%% of that %%actor|actor%%)."
---
### Short Description
......
......@@ -6,7 +6,7 @@ type: concept
typeid: assertion
stage: draft
hoverText: "Assertion: a declaration/statement, made by a specific Party, that something is the case."
glossaryText: "a declaration/statement, made by a specific %Party%, that something is the case."
glossaryText: "a declaration/statement, made by a specific %%party|party%%, that something is the case."
---
:::info Editor's note
......
......@@ -6,7 +6,7 @@ type: concept
typeid: author
stage: draft
hoverText: "Author (of data/document/file/...): a Party, on whose behalf that data/document/file/... has been created and/or updated."
glossaryText: "a %Party%, on whose behalf that data/document/file/... has been created and/or updated."
glossaryText: "a %%party|party%%, on whose behalf that data/document/file/... has been created and/or updated."
---
:::info Editor's note
......
......@@ -6,7 +6,7 @@ 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)."
glossaryText: "the exchange of goods, services, funds, or data between some %Parties% (called %Participants% of the %Transaction%)."
glossaryText: "the exchange of goods, services, funds, or data between some %%parties|party%% (called %%participants|participant%% of the %%transaction|business-transaction%%)."
---
import useBaseUrl from '@docusaurus/useBaseUrl'
......@@ -26,9 +26,9 @@ Explanation required about '%%commitment decision|commitment-decision%%' (i.e. '
In its simplest form, this may be envisaged as one %%party|party%% (requestor) that requests another %%party|party%% (provider) to provide some product, e.g. a parking permit, by using his web-browser to navigate to the web-server of the provider (e.g. his municipality) where he is prompted to fill in a form to provide the details of his request (such as name, address, plate number, etc.). When the form is submitted, the provider decides whether or not to service the request (provide the parking permit) based on the data in the form, and take actions accordingly.
In order for this to work, the provider must design the form such that when a requestor submits a completed form, it can actually decide whether or not to service the request. This has two parts: first, the provider must specify the argument (i.e. the way of reasoning) that it uses to reach this decision - i.e. provide the parking permit. Doing so implicitly specifies the kinds of data that the form will ask for. Secondly, the provider must decide for each of the data it receives, whether or not it is valid to be used in that argument - the process of deciding this is called validation. Common criteria that help to make this distinction include whether or not the data is presented in the expected format, whether or not it is true (not so easy), whether it is not outdated, or whether or not it satisfies validation rules (in the example, the municipality may require that the specified license plate belongs to a car owned by the person that requests the permit). Validation is important, because reasoning with invalid data may result in wrong conclusions and cause damage.
In order for this to work, the provider must design the form such that when a requestor submits a completed form, it can actually decide whether or not to service the request. This has two parts: first, the provider must specify the argument (i.e. the way of reasoning) that it uses to reach this decision - i.e. provide the parking permit. Doing so implicitly specifies the kinds of data that the form will ask for. Secondly, the provider must decide for each of the data it receives, whether or not it is valid to be used in that argument - the process of deciding this is called 'validation'. Common criteria that help to make this distinction include whether or not the data is presented in the expected format, whether or not it is true (not so easy), whether it is not outdated, or whether or not it satisfies validation rules (in the example, the municipality may require that the specified license plate belongs to a car owned by the person that requests the permit). Validation is important, because reasoning with invalid data may result in wrong conclusions and cause damage.
Perhaps the most important contribution that the eSSIF-Lab project aims to make, is to create a ubiquitously used infrastructure for designing, filling in, and validating forms (not just web-forms, but also for forms - e.g. JSON objects - in API requests). The benefits this will bring are enormous, but outside the scope of this document to list.
Perhaps the most important contribution that the eSSIF-Lab project aims to make, is to create a ubiquitously used infrastructure for designing, filling in, and validating forms (not just web-forms, but also for 'forms' - e.g. JSON objects - in API requests). The benefits this will bring are enormous, but outside the scope of this document to list.
The figure below is a high-level visualization of the filling in and validation parts:
......@@ -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|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|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.
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|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|communication-channel%% (e.g. SSL, [DIDComm](https://openssi.github.io/peer-did-method-spec/)) and agree on the specific form that needs to be filled in.
After the *RA* and *PA* have established a %%communication channel|communication-channel%% and agree on the form to be filled in, *PA* informs *RA* about the information it needs to fill in the form, and the requirements that this information should satisfy[^1]. *RA* then checks its data store to see whether or not such data is available, sends such data to *PA*, which subsequently validates it and uses it to fill in (appropriate parts of) the form. Finally, *P* validates the remaining data, which either results in a clean form, i.e. a form that contains valid data that can subsequently be used to decide whether or not to provide the parking permit, or a message to the requester informing him about missing and/or invalid data.
After the *RA* and *PA* have established a %%communication channel|communication-channel%% and agree on the form to be filled in, *PA* informs *RA* about the information it needs to fill in the form, and the requirements that this information should satisfy[^1]. *RA* then checks its data store to see whether or not such data is available, sends such data to *PA*, which subsequently validates it and uses it to fill in (appropriate parts of) the form. Finally, *P* validates the remaining data, which either results in a 'clean' form, i.e. a form that contains valid data that can subsequently be used to decide whether or not to provide the parking permit, or a message to the requester informing him about missing and/or invalid data.
When the transaction has been completed, both participants can issue a credential that attests to the results of the transaction. For example, the provider could issue a credential stating that the requestor has obtained a parking permit for a car with a specific plate number (and other attributes). The requestor can store this credential and from that moment on use it in new electronic transactions.
......
......@@ -6,7 +6,7 @@ type: concept
typeid: colleague
stage: draft
hoverText: "Colleagues: two or more (digital or non-digital) Agents that have the same Principal (i.e. Party on whose behalf they exeucte Actions)."
glossaryText: "two or more (digital or non-digital) %Agents% that have the same %Principal% (i.e. %Party% on whose behalf they exeucte %Actions%)."
glossaryText: "two or more (digital or non-digital) %%agents|agent%% that have the same %%principal|principal%% (i.e. %%party|party%% on whose behalf they exeucte %%actions|action%%)."
---
:::info Editor's note
......
......@@ -6,7 +6,7 @@ type: concept
typeid: commitment-decision
stage: draft
hoverText: "Commitment Decision (of a Party in a Business Transaction): the decision of that Party whether or not to commit to that Business Transaction, i.e. (promise) to fulfill the obligations that the associated Business Transaction Agreement Proposal would impose on that Party once it were signed."
glossaryText: "the decision of that %Party% whether or not to commit to that %Business Transaction%, i.e. (promise) to fulfill the obligations that the associated %Business Transaction Agreement Proposal% would impose on that %Party% once it were signed."
glossaryText: "the decision of that %%party|party%% whether or not to commit to that %%business transaction|business-transaction%%, i.e. (promise) to fulfill the obligations that the associated %%business transaction agreement proposal|business-transaction-agreement-proposal%% would impose on that %%party|party%% once it were signed."
---
:::info Editor's note
......
......@@ -6,7 +6,7 @@ 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."
glossaryText: "a (digital or non-digital) means by which two %Actors% can exchange messages with one another."
glossaryText: "a (digital or non-digital) means by which two %%actors|actor%% can exchange messages with one another."
---
:::info Editor's note
......
......@@ -6,7 +6,7 @@ type: concept
typeid: communication-session
stage: draft
hoverText: "Communication Session: a time interval during which two Actors have an established Communication Channel that does not exist outside of that time interval."
glossaryText: "a time interval during which two %Actors% have an established %Communication Channel% that does not exist outside of that time interval."
glossaryText: "a time interval during which two %%actors|actor%% have an established %%communication channel|communication-channel%% that does not exist outside of that time interval."
---
:::info Editor's note
......
......@@ -6,7 +6,7 @@ type: concept
typeid: concept-file
stage: draft
hoverText: "Concept-file: a file whose contents defines/specifies a Concept."
glossaryText: "a file whose contents defines/specifies a %Concept%."
glossaryText: "a file whose contents defines/specifies a %%concept|concept%%."
---
### Short Description
......
......@@ -6,7 +6,7 @@ type: concept
typeid: concept
stage: draft
hoverText: "Concept: the ideas/thoughts behind a classification of Entities (what makes Entities in that class 'the same')."
glossaryText: "the ideas/thoughts behind a classification of %Entities% (what makes %Entities% in that class 'the same')."
glossaryText: "the ideas/thoughts behind a classification of %%entities|entity%% (what makes %%entities|entity%% in that class 'the same')."
---
### Short Description
......
......@@ -6,7 +6,7 @@ type: concept
typeid: corpus
stage: draft
hoverText: "Corpus (of Terminology): the documentation that describes the Knowledge around a set of Terms and Concepts."
glossaryText: "the documentation that describes the %Knowledge% around a set of %Terms% and %Concepts%."
glossaryText: "the documentation that describes the %%knowledge|knowledge%% around a set of %%terms|term%% and %%concepts|concept%%."
---
:::info Editor's note
......
......@@ -6,7 +6,7 @@ type: concept
typeid: credential-catalogue
stage: draft
hoverText: "Credential Catalogue (functional component): the capability to register and advertise the information about Credential Types that their respective Governing Parties have decided to disclose so as to enable other Parties to decide whether or not it is beneficial for them to use Credentials of such types."
glossaryText: "the capability to register and advertise the information about %Credential Types% that their respective %Governing Parties% have decided to disclose so as to enable other %Parties% to decide whether or not it is beneficial for them to use %Credentials% of such types."
glossaryText: "the capability to register and advertise the information about %%credential types|credential-type%% that their respective %%governing parties|governing-parties%% have decided to disclose so as to enable other %%parties|party%% to decide whether or not it is beneficial for them to use %%credentials|credential%% of such types."
---
:::info Editor's note
......
......@@ -6,12 +6,12 @@ type: concept
typeid: credential-type
stage: draft
hoverText: "Credential Type: the specification of the contents, properties, constraints etc. that Credentials of this type must have/comply with."
glossaryText: "the specification of the contents, properties, constraints etc. that %Credentials% of this type must have/comply with."
glossaryText: "the specification of the contents, properties, constraints etc. that %%credentials|credential%% of this type must have/comply with."
---
### Short Description
A **credential-type** is a specification that states
- the contents that %credentials of that kind must or may have; this includes of which kinds of %%assertions (claims, statements)|assertion%% as well as meta-data.
- the contents that %%credentials|credential%% of that kind must or may have; this includes of which kinds of %%assertions (claims, statements)|assertion%% as well as meta-data.
- properties Typically, %%parties|party%% that issue %%credentials|credential%% of some %%kind|credential-type%% will advertise the %%credential types|credential-type%% of the %%credentials|credential%% that it may issue.
### Purpose
......
......@@ -6,7 +6,7 @@ type: concept
typeid: credential
stage: draft
hoverText: "Credential: data, representing a set of Assertions (claims, statements), authored and signed by, or on behalf of, a specific Party."
glossaryText: "data, representing a set of %Assertions% (claims, statements), authored and signed by, or on behalf of, a specific %Party%."
glossaryText: "data, representing a set of %%assertions|assertion%% (claims, statements), authored and signed by, or on behalf of, a specific %%party|party%%."
---
### Short Description
......@@ -16,7 +16,7 @@ In physical credentials, such as drivers licenses and passports, proofs of integ
In digital credentials, such as (digital) certificates or %%verifiable credentials|verifiable-credential%%, the basic proofs (of provenance and integrity) usually consist of a digital signature of some kind. It therefor only 'works' for as long as the associated private/secret key actually remains a secret of the issuing %%party|party%%.
Credentials whose %%assertions|assertion%% refer to some %%entity|entity%%, e.g. a person, an organization, an animal, a shipment, etc. In such cases, it must be possible for arbitrary %%parties|party%% to identify that %%entity|entity%%, and/or verify an %%assertion|assertion%% by some other %%party|party%% that identifies that %%entity%%. To this end, credentials may contain %%assertions|assertion%% about characteristics of that %%entity|entity%%, the idea being that if a %%party|party%% establishes that some %%entity|entity%% has (a sufficient number of) these characteristics, that %%entity|entity%% is the one bound to the credential. Attributes typically include one or more names, various dates, a photograph, etc. Other attributes might include biometrics, RFID-codes, bar-codes, etc.
Credentials whose %%assertions|assertion%% refer to some %%entity|entity%%, e.g. a person, an organization, an animal, a shipment, etc. In such cases, it must be possible for arbitrary %%parties|party%% to identify that %%entity|entity%%, and/or verify an %%assertion|assertion%% by some other %%party|party%% that identifies that %%entity|entity%%. To this end, credentials may contain %%assertions|assertion%% about characteristics of that %%entity|entity%%, the idea being that if a %%party|party%% establishes that some %%entity|entity%% has (a sufficient number of) these characteristics, that %%entity|entity%% is the one bound to the credential. Attributes typically include one or more names, various dates, a photograph, etc. Other attributes might include biometrics, RFID-codes, bar-codes, etc.
The signature on a credential may have other meanings. For example, a %%party|party%% may choose to only sign the credential data if it is convinced of the truth of the statements, in which case the credential 'payload' can be seen as an excerpt of the %%knowledge|knowledge%% of that %%party|party%%.
......
......@@ -6,7 +6,7 @@ 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."
glossaryText: "a %Digital Policy% that enables an operational %Data Collector% component to function according to the rules of its %Policy Governor%."
glossaryText: "a %%digital policy|digital-policy%% that enables an operational %%data collector|data-collector%% component to function according to the rules of its %%policy governor|policy-governor%%."
---
### Short Description
......
......@@ -6,7 +6,7 @@ type: concept
typeid: data-collector
stage: draft
hoverText: "Data Collector: a functional component that is capable of collecting data from various Parties in the context of some Business Transaction, and Validating this data for the purpose of making one (or more) decision(s)."
glossaryText: "a functional component that is capable of collecting data from various %Parties% in the context of some %Business Transaction%, and %Validating% this data for the purpose of making one (or more) decision(s)."
glossaryText: "a functional component that is capable of collecting data from various %%parties|party%% in the context of some %%business transaction|business-transaction%%, and %%validating|validating%% this data for the purpose of making one (or more) decision(s)."
---
### Short Description
......@@ -37,7 +37,7 @@ A **Data Collector** is a functional component in the [eSSIF-Lab functional arch
- can use any appropriate communication channel with a %%peer-agent|peer-agent%% to:
- request for data that, according to the %%Data Collector Policy|data-collector-policy%% is needed to decide whether or not to commit to the transaction;
- process the responses to such requests, in an orchestrated way, thereby complying with the rules of its %%principal's|principal%% %%Data Collector Policy|data-collector-policy%%, the result of which (in the end) is a set of %%validated data|validated-data%% that can serve the purpose of deciding whether or not to commit to the transaction;
- receive similar requests from its %%peer-party%%, and respond to such requests in compliance with the rules of its %%principal's|principal%% %%Data Collector Policy|data-collector-policy%%;
- receive similar requests from its %%peer-party|peer-party%%, and respond to such requests in compliance with the rules of its %%principal's|principal%% %%Data Collector Policy|data-collector-policy%%;
- has a mechanism to ensure that within a %%transaction|business-transaction%%, it uses the latest (most receent) %%Data Collector Policy|data-collector-policy%% of its %%principal|principal%%.
### Deprecated - TVE Functionality
......@@ -53,7 +53,7 @@ Typically, the Data Collector 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 Principal, to request a specific kind of transaction to some Agent of another Party.[^one]
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 Principal and/or using different communication channels.
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 Principal and/or using different communication channels.
Handling/managing the various communication channels through which data can be exchanged is also a task of the Data Collector[^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).
......@@ -66,7 +66,7 @@ In order to make the Data Collector work, a Validation Policy (or Data Collector
- the kinds of transactions the Principal is willing to (electronically) engage in, from both the requester and the provider perspectives;
- for each such transaction type:
- the criteria (business rules) that should be used to determine that the form is clean, i.e. that the necessary and sufficient data have been obtained and that they are consistent, coherent, and suitable for making a transaction commitment decision.
- the criteria (business rules) that should be used to determine that the form is 'clean', i.e. that the necessary and sufficient data have been obtained and that they are consistent, coherent, and suitable for making a transaction commitment decision.
- the kinds of credentials and issuers that the Principal is willing to accept as sources for valid data; (optionally?), the endpoint URI at which issuing Parties do the actual credential issuing may be specified[^6].
......@@ -78,9 +78,9 @@ The Policy must be designed in such a way that it is extendable as new features
The ability to create new transaction contexts and the availability of the Data Collector Policy enable the Data Collector to request the Verifier component of its Principal to obtain credentials of the types that it can use to fill in the transaction form when they satisfy the verification and validation requirements of its Principal.[^7]
When the Verifier returns such data (which comes with a list of proofs that the Verifier has checked), the Data Collector must then validate that data, i.e. determine whether or not it is valid for the specific transaction it is assembling the data for. The validation rules are Party-specific and hence come from the Data Collector policy. For simple cases, validation can simply consist of checking whether or not all verification proofs succeeded. At the other end of the validation spectrum, the Data Collector itself must make validation decisions, either electronically (according to the Data Collector policy) or by outsourcing such decisions to human Agents of its Principal by providing an appropriate validation user interface.
When the Verifier returns such data (which comes with a list of proofs that the Verifier has checked), the Data Collector must then validate that data, i.e. determine whether or not it is valid for the specific transaction it is assembling the data for. The validation rules are Party-specific and hence come from the Data Collector policy. For simple cases, validation can simply consist of checking whether or not all verification proofs succeeded. At the other end of the validation spectrum, the Data Collector itself must make validation decisions, either electronically (according to the Data Collector policy) or by 'outsourcing' such decisions to human Agents of its Principal by providing an appropriate validation user interface.
As long as data is needed, the Data Collector can intermittently request the verifier to produce it (or it can use other communication channels, which is outside scope for now). It does so until it times out, or the form has become clean.
As long as data is needed, the Data Collector can intermittently request the verifier to produce it (or it can use other communication channels, which is outside scope for now). It does so until it times out, or the form has become 'clean'.
-----
### Notes:
......@@ -89,7 +89,7 @@ As long as data is needed, the Data Collector can intermittently request the ver
TNO to revise the footnote markers
:::
[^1x]: In the same way that the data collector needs to collect data in order to be able to decide whether or not to commit, %%agents|agent%% of the %%peer party|peer-party%% need to collect data for making a similar commitment decision. Requests for such data are to be processed by the %%data discloser component|data-discloser%% under guidance of its %%data-discloser-policy%%.
[^1x]: In the same way that the data collector needs to collect data in order to be able to decide whether or not to commit, %%agents|agent%% of the %%peer party|peer-party%% need to collect data for making a similar commitment decision. Requests for such data are to be processed by the %%data discloser component|data-discloser%% under guidance of its %%data-discloser-policy|data-discloser-policy%%.
[^1a]: If the %%data collector policy|data-collector-policy%% specifies that data is to be collected for other purposes, the %%data collector|data-collector%% should then be provided a means to inform its %%peer party|peer-party%% of such purposes, and the policy should not specify that such data is required to make the commitment decision.
......@@ -101,9 +101,9 @@ TNO to revise the footnote markers
[^3]: For high-value transactions, verification proofs are more important than for low-value transactions. This is to be decided by the Principal of the Data Collector. An example from the physical world: in order to obtain a visa for China, it is required that your passport (credential) remains valid for 3 months after the end of your visit. But in order to identify yourself at the reception desk of a hotel, your passport may have expired several years.
[^4]: For example, a credential that contains an address uses a specific schema to specify addresses, e.g. the PostalAddress as defined by schema.org. This schema differs quite a bit from that of Dutch addresses as [*defined*](https://bag.basisregistraties.overheid.nl/def/bag) by the official (authentic) Dutch Registration of Addresses and Buildings (BAG). It may also well differ from the structure of addresses that databases of the Principal have implemented. Mapping allows such cases to be accommodated for.
[^4]: For example, a credential that contains an address uses a specific schema to specify addresses, e.g. the 'PostalAddress' as defined by schema.org. This schema differs quite a bit from that of Dutch addresses as [*defined*](https://bag.basisregistraties.overheid.nl/def/bag) by the official (authentic) Dutch Registration of Addresses and Buildings (BAG). It may also well differ from the structure of addresses that databases of the Principal have implemented. Mapping allows such cases to be accommodated for.
[^5]: Inconsistent or incoherent data is necessary for various purposes. First, it allows for correct further processing of the transaction. A non-existent postal code, or one that doesnt match the delivery address, may hinder a fluent transaction processing, resulting in additional costs and processing times. Another purpose is the early warning or detection of possible fraud/abuse. Remember that part of the data is being asked for reducing transaction risk, and checking consistency/coherence of such data is part of the risk mitigation process.
[^5]: Inconsistent or incoherent data is necessary for various purposes. First, it allows for correct further processing of the transaction. A non-existent postal code, or one that doesn't match the delivery address, may hinder a fluent transaction processing, resulting in additional costs and processing times. Another purpose is the early warning or detection of possible fraud/abuse. Remember that part of the data is being asked for reducing transaction risk, and checking consistency/coherence of such data is part of the risk mitigation process.
[^6]: This enables the Data Collector to pass the endpoint URI on to the Verifier when it requests for such a credential, which in turn can send it to the holder of other Parties enabling them to obtain the credential from that issuer endpoint if that other Party does not have that credential in its wallet. The endpoint URI can in fact be put in the policy, because the (human) Agent that creates/maintains the policy would need to know that the issuing Party is actually issuing such credentials, what their contents means, etc., and hence is capable of tracking down the URI where that Party issues the credentials.
......
......@@ -6,7 +6,7 @@ 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."
glossaryText: "a %Digital Policy% that enables an operational %Data Discloser% component to function according to the rules of its %Policy Governor%."
glossaryText: "a %%digital policy|digital-policy%% that enables an operational %%data discloser|data-discloser%% component to function according to the rules of its %%policy governor|policy-governor%%."
---
### Short Description
......
......@@ -6,7 +6,7 @@ type: concept
typeid: data-discloser
stage: draft
hoverText: "Data Discloser: a functional component that is capable of disclosing data to (Agents of) other Parties, e.g. in the form of Credentials."
glossaryText: "a functional component that is capable of disclosing data to (Agents of) other %Parties%, e.g. in the form of %Credentials%."
glossaryText: "a functional component that is capable of disclosing data to (Agents of) other %%parties|party%%, e.g. in the form of %%credentials|credential%%."
---
### Short Description
......@@ -26,9 +26,9 @@ The purpose of the Data Discloser component is to state the (various, sometimes
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.
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).
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.
......
......@@ -6,7 +6,7 @@ type: concept
typeid: definition
stage: draft
hoverText: "Definition: a text that helps Parties to understand the meaning of (and Concepts behind) a Term, ideally in such a way that these Parties can determine whether or not they make the same distinction."
glossaryText: "a text that helps %Parties% to understand the meaning of (and %Concepts% behind) a %Term%, ideally in such a way that these %Parties% can determine whether or not they make the same distinction."
glossaryText: "a text that helps %%parties|party%% to understand the meaning of (and %%concepts|concept%% behind) a %%term|term%%, ideally in such a way that these %%parties|party%% can determine whether or not they make the same distinction."
---
### Short Description
......
......@@ -6,7 +6,7 @@ type: concept
typeid: dependent
stage: draft
hoverText: "Dependent (of an Party in a Jurisdiction): the Entity for the caring for and/or protecting/guarding/defending of which a Guardianship Relationship has been established with that Entity within that Jurisdiction."
glossaryText: "the %Entity% for the caring for and/or protecting/guarding/defending of which a %Guardianship Relationship% has been established with that %Entity% within that %Jurisdiction%."
glossaryText: "the %%entity|entity%% for the caring for and/or protecting/guarding/defending of which a %%guardianship relationship|guardianship%% has been established with that %%entity|entity%% within that %%jurisdiction|jurisdiction%%."
---
:::info Editor's Note
......
......@@ -6,7 +6,7 @@ type: dictionary
typeid: dictionary-file
stage: draft
hoverText: "Dictionary-file: a file whose contents specifies the contents of a Dictionary."
glossaryText: "a file whose contents specifies the contents of a %Dictionary%."
glossaryText: "a file whose contents specifies the contents of a %%dictionary|dictionary%%."
---
### Short Description
......
......@@ -6,7 +6,7 @@ type: concept
typeid: dictionary
stage: draft
hoverText: "Dictionary: an alphabetically sorted list of Terms with various meanings they may have in different contexts."
glossaryText: "an alphabetically sorted list of %Terms% with various meanings they may have in different contexts."
glossaryText: "an alphabetically sorted list of %%terms|term%% with various meanings they may have in different contexts."
---
### Short Description
......
......@@ -7,7 +7,7 @@ typeid: digital-actor
conceptref: ":Actor"
stage: draft
hoverText: "Digital Actor: an Actor in the digital world (e.g. a running app, or a web-server)."
glossaryText: "an %Actor% in the digital world (e.g. a running app, or a web-server)."
glossaryText: "an %%actor|actor%% in the digital world (e.g. a running app, or a web-server)."
---
### Purpose
......
......@@ -7,7 +7,7 @@ typeid: digital-agent
conceptref: ":Agent"
stage: draft
hoverText: "Digital Agent: an Agent in the digital world (e.g. a running app, or a web-server that is executing an Action for a specific Party (its Principal))."
glossaryText: "an %Agent% in the digital world (e.g. a running app, or a web-server that is executing an %Action% for a specific %Party% (its %Principal%))."
glossaryText: "an %%agent|agent%% in the digital world (e.g. a running app, or a web-server that is executing an %%action|action%% for a specific %%party|party%% (its %%principal|principal%%))."
---
### Purpose
......
......@@ -7,7 +7,7 @@ typeid: digital-colleague
conceptref: ":Colleague"
stage: draft
hoverText: "Digital Colleagues: two or more Digital Agents that all have the same Principal (i.e. Party on whose behalf they exeucte Actions)."
glossaryText: "two or more %Digital Agents% that all have the same %Principal% (i.e. %Party% on whose behalf they exeucte %Actions%)."
glossaryText: "two or more %%digital agents|digital-agent%% that all have the same %%principal|principal%% (i.e. %%party|party%% on whose behalf they exeucte %%actions|action%%)."
---
### Purpose
......
......@@ -6,7 +6,7 @@ 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"
glossaryText: "a digital means by which two %Digital Actors% can exchange messages with one another"
glossaryText: "a digital means by which two %%digital actors|digital-actor%% can exchange messages with one another"
---
:::info Editor's note
......
......@@ -7,7 +7,7 @@ typeid: digital-policy
conceptref: ":Policy"
stage: draft
hoverText: "Digital Policy (of a Party, for Action types): a machine-readable Policy that enables Digital Agents whose Principal is the Policy's Governor, to execute Actions of such types in compliance with that Policy (i.e.: according to the rules, working-instructions, preferences and other guidance specified therein)."
glossaryText: "a machine-readable %Policy% that enables %Digital Agents% whose %Principal% is the %Policy%'s %Governor%, to execute %Actions% of such types in compliance with that %Policy% (i.e.: according to the rules, working-instructions, preferences and other guidance specified therein)."
glossaryText: "a machine-readable %%policy|policy%% that enables %%digital agents|digital-agent%% whose %%principal|principal%% is the %%policy|policy%%'s %%governor|governance%%, to execute %%actions|action%% of such types in compliance with that %%policy|policy%% (i.e.: according to the rules, working-instructions, preferences and other guidance specified therein)."
---
:::info Editor's note
......
......@@ -6,7 +6,7 @@ type: concept
typeid: employee
stage: draft
hoverText: "Employee (of a Party): an Actor for whom/which it is realistic that it might execute Actions on behalf of that Party (called the Employer of that Actor)."
glossaryText: "an %Actor% for whom/which it is realistic that it might execute %Actions% on behalf of that %Party% (called the %Employer% of that %Actor%)."
glossaryText: "an %%actor|actor%% for whom/which it is realistic that it might execute %%actions|action%% on behalf of that %%party|party%% (called the %%employer|employer%% of that %%actor|actor%%)."
---
:::info Editor's note
......
......@@ -6,7 +6,7 @@ type: concept
typeid: employer
stage: draft
hoverText: "Employer (of an Actor): a Party on whose behalf this Actor (called an Employee of that Party) might execute Actions."
glossaryText: "a %Party% on whose behalf this %Actor% (called an %Employee% of that %Party%) might execute %Actions%."
glossaryText: "a %%party|party%% on whose behalf this %%actor|actor%% (called an %%employee|employee%% of that %%party|party%%) might execute %%actions|action%%."
---
:::info Editor's note
......
......@@ -6,7 +6,7 @@ type: concept
typeid: essif-glue
stage: draft
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."
glossaryText: "interface layer that allows components with %Transaction Data Collector% and/or %Transaction Data Discloser% functionality to use the %Wallet%, %Holder%, %Issuer% and %Verifier% functionalities."
glossaryText: "interface layer that allows components with %%transaction data collector|transaction-data-collector%% and/or %%transaction data discloser|transaction-data-discloser%% functionality to use the %%wallet|wallet%%, %%holder|holder%%, %%issuer|issuer%% and %%verifier|verifier%% functionalities."
---
### Short Description
......
......@@ -6,7 +6,7 @@ type: glossary
typeid: glossary-file
stage: draft
hoverText: "Glossary-file: a file whose contents defines/specifies a Glossary."
glossaryText: "a file whose contents defines/specifies a %Glossary%."
glossaryText: "a file whose contents defines/specifies a %%glossary|glossary%%."
---
### Short Description
......
......@@ -6,7 +6,7 @@ type: concept
typeid: glossary
stage: draft
hoverText: "Glossary: an alphabetically sorted list of Terms with the (single) meaning it has in (at least) one context."
glossaryText: "an alphabetically sorted list of %Terms% with the (single) meaning it has in (at least) one context."
glossaryText: "an alphabetically sorted list of %%terms|term%% with the (single) meaning it has in (at least) one context."
---
### Short Description
......
......@@ -6,7 +6,7 @@ type: concept
typeid: governor
stage: draft
hoverText: "Governor: the role that a Party assumes as it is governing or overseeing the control and direction of something."
glossaryText: "the role that a %Party% assumes as it is governing or overseeing the control and direction of something."
glossaryText: "the role that a %%party|party%% assumes as it is governing or overseeing the control and direction of something."
---
### Short Description
......
......@@ -6,7 +6,7 @@ type: concept
typeid: guardian
stage: draft
hoverText: "Guardian (of an Entity in a Jurisdiction): the Party that is tasked to care for and/or protect/guard/defend that Entity, for the purpose of which a Guardianship Relationship has been established within that Jurisdiction."
glossaryText: "the %Party% that is tasked to care for and/or protect/guard/defend that %Entity%, for the purpose of which a %Guardianship Relationship% has been established within that %Jurisdiction%."
glossaryText: "the %%party|party%% that is tasked to care for and/or protect/guard/defend that %%entity|entity%%, for the purpose of which a %%guardianship relationship|guardianship%% has been established within that %%jurisdiction|jurisdiction%%."
---
:::info Editor's Note
......
......@@ -6,7 +6,7 @@ type: concept
typeid: guardianship-type
stage: draft
hoverText: "Guardianship-type (in a Jurisdiction): a class of Guardianships (relationships) within the Jurisdiction that has defined it."
glossaryText: "a class of %Guardianships% (relationships) within the %Jurisdiction% that has defined it."
glossaryText: "a class of %%guardianships|guardianship%% (relationships) within the %%jurisdiction|jurisdiction%% that has defined it."
---