Commit 96eeb127 authored by Rieks Joosten's avatar Rieks Joosten

added glossaryTexts

parent 74608db1
Pipeline #17123 failed with stage
in 2 minutes and 24 seconds
......@@ -3,10 +3,6 @@ id: ssi-standards
title: SSI Standards
---
<!-- **KEEP THIS LINE HERE - RIEKS NEEDS IT!!**
^(---\s*\nid:(?:[^%]*\n|(?:glossarytext):.*\n){1,10}[^%]*)%%([^\|]*)\|(?:[^%]*)%%(?=(?:.*[\n\r]){1,10}---)
-->
The purpose of this document is to provide an overview of standards activities for self-sovereign identity (SSI) and their relevance to eSSIF-Lab.
## 1. Introduction
......
......@@ -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
......
This diff is collapsed.
......@@ -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."
---
### Short Description
......
......@@ -6,7 +6,7 @@ type: concept
typeid: guardianship
stage: draft
hoverText: "Guardianship (of a Party over an Entity in a Jurisdiction): the rights and duties of that Party, defined and enforced in that Jurisdiction, for the purpose of caring for and/or protecting/guarding/defending that Entity."
glossaryText: "the rights and duties of that %Party%, defined and enforced in that %Jurisdiction%, for the purpose of caring for and/or protecting/guarding/defending that %Entity%."
glossaryText: "the rights and duties of that %%party|party%%, defined and enforced in that %%jurisdiction|jurisdiction%%, for the purpose of caring for and/or protecting/guarding/defending that %%entity|entity%%."
---
:::info Editor's Note
......@@ -18,7 +18,7 @@ TNO to revise all below texts.
in which one of these %%entities|entity%% (called the %%owner|owner%%) is entitled to enjoy, dispose of, and control the other %%entity|entity%% in an pretty much absolute (sovereign) fashion. Any guardianship relationship is grounded in ((the rules of) the %%legal system|legal-system%% of) a specific %%jurisdiction|jurisdiction%%, that maintains and enforces these rules, and that has means to resolve any disputes arising from that. To do this, both %%entities|entity%% must be %%legal entities|legal-entity%% in that %%jurisdiction|jurisdiction%%.
We may use the phrase %%natural guardianship%% to refer to an guardianship relation that exists in the %%jurisdiction|jurisdiction%% 'Nature' (see the notes of %%jurisdiction|jurisdiction%%). This enables us to talk about things as 'the (natural) guardianship of an %%assertion|assertion%%'.
We may use the phrase %%natural guardianship|natural-guardianship%% to refer to an guardianship relation that exists in the %%jurisdiction|jurisdiction%% 'Nature' (see the notes of %%jurisdiction|jurisdiction%%). This enables us to talk about things as 'the (natural) guardianship of an %%assertion|assertion%%'.
The %%Guardianship pattern|pattern-guardianship%% provides an overview of how this concept fits in with related concepts.
......
......@@ -6,7 +6,7 @@ type: concept
typeid: holder-policy
stage: draft
hoverText: "Holder Policy: a Digital Policy that enables an operational Holder component to function according to the rules of its Policy Governor."
glossaryText: "a %Digital Policy% that enables an operational %Holder% component to function according to the rules of its %Policy Governor%."
glossaryText: "a %%digital policy|digital-policy%% that enables an operational %%holder|holder%% component to function according to the rules of its %%policy governor|policy-governor%%."
---
:::info Editor's note
......
......@@ -6,11 +6,11 @@ type: concept
typeid: holder
stage: draft
hoverText: "Holder (functional component): the capability to handle presentation requests from a Peer Agent, produce the requested data (a presentation) according to its Principal's holder-policy, and send that in response to the request."
glossaryText: "the capability to handle presentation requests from a %Peer Agent%, produce the requested data (a presentation) according to its %Principal%'s holder-policy, and send that in response to the request."
glossaryText: "the capability to handle presentation requests from a %%peer agent|peer-agent%%, produce the requested data (a presentation) according to its %%principal|principal%%'s holder-policy, and send that in response to the request."
---
### Short Description
A **Holder** is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that handles %%Presentation Requests|presentation-request%% that it receives from %%verifier|verifier%% components (of other %%parties|party%%, but also of its own %%owner|owner%%). Typically, this means looking for the requested data in the Principal’s %%wallet|wallet%%, and using it to construct a Presentation (=response). However, if the Wallet doesn’t have it, the Holder may negotiate a transaction with a component of the designated %%issuer|issuer%% for the purpose of obtaining the needed credential, which - when obtained - it can subsequently store in the wallet and use in the Presentation.
A **Holder** is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that handles %%Presentation Requests|presentation-request%% that it receives from %%verifier|verifier%% components (of other %%parties|party%%, but also of its own %%owner|owner%%). Typically, this means looking for the requested data in the Principal's %%wallet|wallet%%, and using it to construct a Presentation (=response). However, if the Wallet doesn't have it, the Holder may negotiate a transaction with a component of the designated %%issuer|issuer%% for the purpose of obtaining the needed credential, which - when obtained - it can subsequently store in the wallet and use in the Presentation.
:::info Editor's note
TNO (or others) to provide additional content of this file.
......@@ -26,12 +26,12 @@ 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 Principal’s Transaction Data Collector to initiate a new transaction that will get the credential from that issuer, for which a clean transaction form would then consist of one that contains said credential. The Holder would then store it in its Principal’s Wallet, and then proceed to service the presentation request as if it had obtained that credential from its Principal’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 Principal's Transaction Data Collector to initiate a new transaction that will get the credential from that issuer, for which a clean transaction form would then consist of one that contains said credential. The Holder would then store it in its Principal's Wallet, and then proceed to service the presentation request as if it had obtained that credential from its Principal'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.
In order to make the Holder component work, a Holder Policy/Preferences object is created by, or on behalf of its Principal, which specifies e.g.: