diff --git a/.gitignore b/.gitignore
index e093ec31fa4442efa166ffbc919e187deeda78a7..a5da0c1e28503b7f1b96bd362a895a7b54d975d4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,3 +15,4 @@ start_server.bat
 *.lnk
 docs/vscode-%%-batch-replacer.txt
 **/zzz-*
+docs/test.md
diff --git a/docs/functional-architecture.md b/docs/functional-architecture.md
index 062ce986a61c0f013d06eeae10361596bc8f1b57..27b116dc0999460506c3acedddf5c1d846b33ebf 100644
--- a/docs/functional-architecture.md
+++ b/docs/functional-architecture.md
@@ -7,28 +7,28 @@ scopeid: essifLab
 
 import useBaseUrl from '@docusaurus/useBaseUrl'
 
-## Purpose
+## 1. Purpose
 
-It is the intention of the eSSIF-Lab project to develop this functional architecture into a generic, and common basis that parties from different backgrounds can use e.g. for:
-- thinking and arguing about SSI-related topics and how it contributes to business transactions;
-- creating technological components that provide functionalities that fit into the architecture and hence have a great chance to be, or quickly become, interoperable with tech components that other parties have developed;
+It is the intention of the eSSIF-Lab project to develop this functional architecture into a generic, and common basis that %%parties|party%% from different backgrounds can use e.g. for:
+- thinking and arguing about SSI-related topics and how it contributes to %%business transactions|business-transaction%%;
+- creating technological components that provide functionalities that fit into the architecture and hence have a great chance to be, or quickly become, interoperable with tech components that other %%parties|party%% have developed;
 - discussing and resolving issues related to interfaces and protocols for tech components that provide such functionalities;
-- designing and developing technical applications that support businesses, not only as they conduct business transactions, but also as the govern the policies that are needed to make the technology work as intended by such businesses.
+- designing and developing technical applications that support businesses, not only as they conduct %%business transactions|business-transaction%%, but also as the govern the %%policies|policy%% that are needed to make the technology work as intended by such businesses.
 
 To this end, this document provides an overview of 
-- the functions (capabilities) that individual parties need in order to electronically support busines transactions;
-- the interactions between these functions that make such business transactions happen;
-- the various policies that parties have to govern, and put in place in order for the technical components that provide these capabilities to function in accordance with their (subjective) rules, working-instructions and other guidance.
+- the functions (capabilities) that individual %%parties|party%% need in order to electronically support %%business transactions|business-transaction%%;
+- the interactions between these functions that make such %%business transactions|business-transaction%% happen;
+- the various %%policies|policy%% that %%parties|party%% have to govern, and put in place in order for the technical components that provide these capabilities to function in accordance with their (subjective) rules, working-instructions and other guidance.
 
-## 2.  Functional Architecture Overview
+## 2. Functional Architecture Overview
 
-Figure 1 shows the initial *functional* eSSIF-Lab architecture, and its scope, context and *functional* components each of which is a (*functional*) agent for the same party (meaning that they are all part of the same organization as defined above, and they are all (digital) ‘Colleagues’ of one another).
+Figure 1 shows the initial *functional* eSSIF-Lab architecture, and its scope, context and *functional* components each of which is a (*functional*) %%agent|agent%% for the same party (meaning that they are all part of the same organization as defined above, and they are all (digital) 'Colleagues' of one another).
 
-Please be aware that *functional* capabilities, components, agents, etc. do not necessarily coincide with *technical* capabilities, components, agents, etc. The technical components can be deployed (downloaded, installed, run), whereas a functional component is a provider of a specified set of capabilities/functionalities an implementation of which can be made part of a technical component. So it is conceivable that a technical component contains an implementation of issuer, wallet, holder and verifier functional components as well as other functionalities that are not described here, e.g. related to UX, setting preferences, and more. In this functional architecture, the default type of components, agents etc. are *functional*.
+Please be aware that *functional* capabilities, components, %%agents|agent%%, etc. do not necessarily coincide with *technical* capabilities, components, %%agents|agent%%, etc. The technical components can be deployed (downloaded, installed, run), whereas a functional component is a provider of a specified set of capabilities/functionalities an implementation of which can be made part of a technical component. So it is conceivable that a technical component contains an implementation of %%issuer|issuer%%, %%wallet|wallet%%, %%holder|holder%% and %%verifier|verifier%% functional components as well as other functionalities that are not described here, e.g. related to UX, setting %%preferences|policy%%, and more. In this functional architecture, the default type of components, %%agents|agent%% etc. are *functional*.
 
-Since the participants of a business transaction are different parties, the negotiation, commitment and execution of that transaction will be done by agents of these different parties. Assuming that a single transaction has two such parties, we will use the term ‘Peer Party (of a specific Party, in the context of a single transaction)’ to refer to the participating party in that transaction that is not the specific %%party|party%% itself.
+Since the %%participants|participant%% of a %%business transaction|business-transaction%% are different %%parties|party%%, the negotiation, commitment and execution of that %%transaction|business-transaction%% will be done by %%agents|agent%% of these %%parties|party%%. Assuming that a single %%transaction|business-transaction%% has two such %%parties|party%%, we will use the term '%%Peer Party|peer-party%% (of a specific %%party|party%%, in the context of a single %transaction)' to refer to the participating %%party|party%% in that %%transaction|business-transaction%% that is not the specific %%party|party%% itself.
 
-When an %%agent|agent%% is involved in such a transaction, it will be communicating with a component that it assumes to be an %%agent|agent%% of the %%Peer Party|peer-party%% of its %%principal|principal%% (the %%agent|agent%% may obtain further assurances for that, but that's outside the scope for now). We will use the term ‘%%Peer Agent (of a specific Agent, in the context of a single transaction)|peer-agent%%’ to refer to an %%actor|actor%% with which the specific %%agent|agent%% has a %%communication session|communication-session%%. Note that establishing whether or not an %%actor|actor%% is a %%Peer Agent|peer-agent%% does not necessarily require knowing who the %%Peer Party|peer-party%% actually is.
+When an %%agent|agent%% is involved in such a %%transaction|business-transaction%%, it will be communicating with a component that it assumes to be an %%agent|agent%% of the %%peer party|peer-party%% of its %%principal|principal%% (the %%agent|agent%% may obtain further assurances for that, but that's outside the scope for now). We will use the term '%%peer agent|peer-agent%% (of a specific %%agent|agent%%, in the context of a single %%transaction|business-transaction%%)' to refer to an %%actor|actor%% with which the specific %%agent|agent%% has a communication session. Note that establishing whether or not an %%actor|actor%% is a %%Peer Agent|peer-agent%% does not necessarily require knowing who the %%peer party|peer-party%% actually is.
 
 The figure below is an overview of the most important *functional* components that any %%party|party%% needs to conduct electronic %%business transactions|business-transaction%%.
 
@@ -39,7 +39,7 @@ The figure below is an overview of the most important *functional* components th
 
 *Figure 1. eSSIF-Lab Single Party Functional Architecture Overview.*
 
-We use the following coloring conventions in this figure: red is business related, which means that we do not consider this to be part of the SSI Infrastructure. Brown is used for policies, which are defined by (or on behalf) of the principal of the component that uses them to configure themselves, and/or act according to the %principal’s preferences and policies. Green is used for generic SSI infrastructure related functions, and blue represents functions that may be implemented as ‘plug-ins’ for specific SSI-related technologies.
+We use the following coloring conventions in this figure: red is business related, which means that we do not consider this to be part of the SSI Infrastructure. Brown is used for policies, which are defined by (or on behalf) of the principal of the component that uses them to configure themselves, and/or act according to the %%principal's|principal%% preferences and %%policies|policy%%. Green is used for generic SSI infrastructure related functions, and blue represents functions that may be implemented as 'plug-ins' for specific SSI-related technologies.
 
 The remainder of this chapter describes the layers and their components at a high abstraction level. <!--Further details on components, such as design decisions, can be found in \[reference\].-->
 
@@ -47,35 +47,35 @@ The remainder of this chapter describes the layers and their components at a hig
 
 At the top of the figure are two business-related layers. Both are within the scope of the eSSIF-Lab project/architecture, yet they are outside the scope of the eSSIF-Lab infrastructure/architecture - that is because they are too business-specific.
 
-The top layer (in the red rounded rectangle) has the functions of actual business transactions: it starts with a transaction form, the data of which is valid, consistent and complete, from which the (business) decision can be made whether or not to engage in a business transaction, and that has everything necessary to actually execute that business transaction. The (administrative) results of such a business transaction are then stored in business data stores. We have put this layer in the eSSIF-Lab architecture for the single purpose of showing how the components of the bottom layer contribute to conduct business transactions.
+The top layer (in the red rounded rectangle) has the functions of actual %%business transactions|business-transaction%%: it starts with a %%transaction form|transaction-form%%, the data of which is valid, consistent and complete, from which the (business) decision can be made whether or not to engage in a %%business transaction|business-transaction%%, and that has everything necessary to actually execute that %%business transaction|business-transaction%%. The (administrative) results of such a %%business transaction|business-transaction%% are then stored in business data stores. We have put this layer in the eSSIF-Lab architecture for the single purpose of showing how the components of the bottom layer contribute to conduct %%business transactions|business-transaction%%.
 
-The lower business layer contains two functional components, one for initiating transactions and the other for stating transaction results (as per the [*DEMO*](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations) method), each of which with an associated business policy that contains business-specific policies/preferences.
+The lower business layer contains two functional components, one for initiating %%transactions|business-transaction%% and the other for stating %%transaction|business-transaction%% results (as per the [*DEMO*](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations) method), each of which with an associated business %%policy|policy%% that contains business-specific %%policies|policy%%.
 
-The task of the Data Collector (or Data Collector) is to handle and initiate requests from/to peer agents to engage in some kind of transaction, by negotiating and exchanging data (through one or more, physical or electronic communication channels%), and to produce a transaction form whose contents are complete and valid, enabling an appropriate Colleague to decide whether or not to engage in the transaction. Note that negotiating a transaction has two parts: requesting a peer agent to provide data that its principal needs, and providing data on behalf of its principal that a peer agent requests. After all, a business transaction can only start after all %%parties|party%% have decided to commit, which they can only do after each of them has obtained the information it (subjectively) needs to do so. Also note that data that the %%data collector|data-collector%% must ensure that the transaction context is properly maintained if it chooses to exchange data through different %%communication channels|communication-channel%%.
+The task of the Data Collector (or Data Collector) is to handle and initiate requests from/to %%peer agents|peer-agent%% to engage in some kind of %%transaction|business-transaction%%, by negotiating and exchanging data (through one or more, physical or electronic communication channels), and to produce a %%transaction|business-transaction%% form whose contents are complete and valid, enabling an appropriate Colleague to decide whether or not to engage in the %%transaction|business-transaction%%. Note that negotiating a %%transaction|business-transaction%% has two parts: requesting a %%peer agent|peer-agent%% to provide data that its %%principal|principal%% needs, and providing data on behalf of its %%principal|principal%% that a %%peer agent|peer-agent%% requests. After all, a %%business transaction|business-transaction%% can only start after all %%parties|party%% have decided to commit, which they can only do after each of them has obtained the information it (subjectively) needs to do so. Also note that data that the data collector must ensure that the %%transaction|business-transaction%% context is properly maintained if it chooses to exchange data through different communication channels.
 
-The task of the %%data discloser|data-discloser%% (or %%data discloser|data-discloser%%) is to state the (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other %%parties|party%%. Since such state-data may change, issuing data that supersedes an earlier state implies the revocation of such a state.
+The task of the data discloser (or data discloser) is to state the (various, sometimes intermediary) results of %%transactions|business-transaction%%, 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%%. Since such state-data may change, issuing data that supersedes an earlier state implies the revocation of such a state.
 
 Note that both components are within scope of eSSIF-Lab architecture, but NOT in scope of the eSSIF-Lab infrastructure, as they are too business-specific.
 
 ### 2.2.  SSI Roles Layer (Issuer, Verifier, Holder and Wallet)
 
-The SSI Roles Layer contains functional components that provide the functionality associated with the well-known roles of %%issuer|issuer%%, %%holder|holder%%, %%wallet|wallet%% and %%verifier|verifier%%. Technical components that provide such functionalities are part of the eSSIF-Lab (technical) infrastructure.
+The SSI Roles Layer contains functional components that provide the functionality associated with the well-known roles of issuer, holder, wallet and verifier. Technical components that provide such functionalities are part of the eSSIF-Lab (technical) infrastructure.
 
-Apart from each having a specific task, as described below, implementations that are being deployed by one %%party|party%% should be aligned in that they support the same (sub)set(s) of SSI Protocols and Crypto features, as described in the following section.
+Apart from each having a specific task, as described below, implementations that are being deployed by one party should be aligned in that they support the same (sub)set(s) of SSI Protocols and Crypto features, as described in the following section.
 
-The **issuer** functionality includes the issuing of what we will generically call '%%credentials|credential%%', i.e. sets of (related) statements/claims (e.g. as produced by the %%data discloser|data-discloser%%) that have metadata (e.g. date of issuing) and a digital signature by which third %%parties|party%% can prove its provenance and integrity. Another function of the %%issuer|issuer%% is to handle revocation (and (un)suspension) of %%credentials|credential%% that it has issued. For such tasks, it relies on functions that are made available by the SSI Protocols and Crypto Layer.
+The **issuer** functionality includes the issuing of what we will generically call 'credentials', i.e. sets of (related) statements/claims (e.g. as produced by the data discloser) that have metadata (e.g. date of issuing) and a digital signature by which third %%parties|party%% can prove its provenance and integrity. Another function of the issuer is to handle revocation (and (un)suspension) of credentials that it has issued. For such tasks, it relies on functions that are made available by the SSI Protocols and Crypto Layer.
 
-The **wallet** functionality includes the (secure) storage of %%credentials|credential%% - both those that have been issued by the %%issuer|issuer%% (i.e. self-signed %credentials) and those that have been obtained from %%issuers|issuer%% of other %%parties|party%%. Another task of the %%wallet|wallet%% is to (securely) store (private) keys that can be used to sign or seal data on behalf of its %%principal|principal%%. Perhaps the most important task of the %%wallet|wallet%% is to ensure that %%credentials|credential%% and keys can only become available to another component if they have the same (single) %%principal|principal%%, and will become available if such other component implements a functionality that needs it.
+The **wallet** functionality includes the (secure) storage of credentials - both those that have been issued by the issuer (i.e. self-signed credentials) and those that have been obtained from issuers of other %%parties|party%%. Another task of the wallet is to (securely) store (private) keys that can be used to sign or seal data on behalf of its %%principal|principal%%. Perhaps the most important task of the wallet is to ensure that credentials and keys can only become available to another component if they have the same (single) %%principal|principal%%, and will become available if such other component implements a functionality that needs it.
 
-The **verifier** functionality is to support the %%data collector|data-collector%% as it tries to acquire %%credentials|credential%% from some other %%party|party%% for the purpose of negotiating a business transaction. It does so by creating %%Presentation Requests|presentation-request%% (or Presentation Definition as it is called in the [draft DIF specfication for Presentation Exchange](https://identity.foundation/presentation-exchange)) that ask for such %%credentials|credential%%, sending them to a %%holder|holder%% component of another %%party|party%%, receiving a response to such a request (which we call a ‘%Presentation’), verifying the %%Presentation|presentation%%, i.e. checking the signature and other proofs of the veracity of both the construction of the %%Presentation|presentation%% as well as its contents, thus providing the %%Data Collector|data-collector%% with verified data.
+The **verifier** functionality is to support the data collector as it tries to acquire credentials from some other party for the purpose of negotiating a %%business transaction|business-transaction%%. It does so by creating %%presentation requests|presentation-request%% (or Presentation Definition as it is called in the [draft DIF specfication for Presentation Exchange](https://identity.foundation/presentation-exchange)) that ask for such credentials, sending them to a holder component of another party, receiving a response to such a request (which we call a '%%presentation|presentation%%'), verifying the %%presentation|presentation%%, i.e. checking the signature and other proofs of the veracity of both the construction of the %%presentation|presentation%% as well as its contents, thus providing the Data Collector with verified data.
 
-The task of the **holder** is to handle %%Presentation|presentation%% Requests that it receives from %%verifier|verifier%% components (both of its %%principal|principal%%, and of other %parties). Typically, this means looking for the requested data in the %principal’s %%wallet|wallet%%, and using it to construct a %%Presentation|presentation%% (=response). However, if the %%wallet|wallet%% doesn’t have it, the %%holder|holder%% may negotiate a transaction with a component of the designated %%issuer|issuer%% for the purpose of obtaining the needed %%credential|credential%%, which - when obtained - it can subsequently store in the %%wallet|wallet%% and use in the %%presentation|presentation%%.
+The task of the **holder** is to handle %%presentation requests|presentation-request%% that it receives from verifier components (both of its %%principal|principal%%, and of other %%parties|party%%). Typically, this means looking for the requested data in the %%principal's|principal%% wallet, and using it to construct a %%presentation|presentation%% (=response). However, if the wallet doesn't have it, the holder may negotiate a %%transaction|business-transaction%% with a component of the designated issuer for the purpose of obtaining the needed credential, which - when obtained - it can subsequently store in the wallet and use in the %%presentation|presentation%%.
 
 ### 2.3.  SSI Protocols and Crypto Layer
 
-While represented as a layer, the SSI Protocols and Crypto Layer can be seen more as a set of libraries that can be used by %%wallet|wallet%%, %%holder|holder%%, %%issuer|issuer%% and %%verifier|verifier%% (WHIV) components for the purpose of actually implementing some/all of the functionality that they need to provide. Each ‘Component’ in this layer implements a specific technology, and any implementation of any of the WHIV components may choose which of these to use. Of course, if one of the WHIV components implements a technology, it would seem that the others would need to do so, too.
+While represented as a layer, the SSI Protocols and Crypto Layer can be seen more as a set of libraries that can be used by wallet, holder, issuer and %%verifier|verifier%% (WHIV) components for the purpose of actually implementing some/all of the functionality that they need to provide. Each 'Component' in this layer implements a specific technology, and any implementation of any of the WHIV components may choose which of these to use. Of course, if one of the WHIV components implements a technology, it would seem that the others would need to do so, too.
 
-Technologies may come as a (proprietary or open source) library, as a service (offered by one or more Parties), or both. There are way too many to mention here, but to give you an idea, here is a classification of such underlying/supporting technologies that seems to be useful. While we do mention some technologies explicitly, this should in no way be interpreted as that this would be necessary to support, or that others are not to be considered.
+Technologies may come as a (proprietary or open source) library, as a service (offered by one or more %%parties|party%%), or both. There are way too many to mention here, but to give you an idea, here is a classification of such underlying/supporting technologies that seems to be useful. While we do mention some technologies explicitly, this should in no way be interpreted as that this would be necessary to support, or that others are not to be considered.
 
 First, we have **credential-related technologies**, most often in the form of libraries, basically for the creation, (storing,) and verification of specific kinds of %%credentials|credential%% such as [*Verifiable Credentials*](https://www.w3.org/TR/vc-data-model/) (VCs), [*Attribute Based Credentials*](https://abc4trust.eu/index.php/pub)<sup>[ABC]</sup> (ABCs), [*X.509 Attribute Certificates*](https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.509-201210-S!!PDF-E), [*OIDC*](https://openid.net/developers/specs/) tokens, etc. Various projects/implementations can already be used here, such as [*Hyperledger Aries*](https://www.hyperledger.org/projects/aries), [*IRMA*](https://privacybydesign.foundation/irma-en/), [*OpenCerts*](https://opencerts.io/), [*BlockCerts*](https://www.blockcerts.org/), and more.
 
@@ -83,7 +83,7 @@ Then, there are **secure communications technologies**, for the purposes of (a)
 
 Another important category is that of **crypto (related) technologies**, which are used for various purposes, such as creating/verifying digital signatures, zero-knowledge-proofs, etc. Such technologies may come as a library (e.g. [*Hyperledger/Ursa*](https://www.hyperledger.org/projects/hyperledger-ursa)), or as a service, e.g. an [*eIDAS*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32014R0910&from=EN)<sup>[eIDAS]</sup> trust service.
 
-We conclude for now by mentioning **blockchain/distributed ledger technologies**, for secure logging of (e.g. registration) events, where such logs have the property that it is virtually impossible to change the order and/or contents of the logged events, and that the logs are highly available to those that are authorized. Both public and private blockchains are known to be used, and different SSI-solutions may use them for different purposes, e.g. the registration of schema’s, %%credential types|credential-type%%, DIDs and associated DID documents, revocation accumulators, etc. Examples include [*EBSI*](https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/ebsi) ([*European Blockchain Partnership*](https://ec.europa.eu/digital-single-market/en/blockchain-technologies)), [*Hyperledger Indy*](https://www.hyperledger.org/projects/hyperledger-indy) (Alastria, Findy, Sovrin), Ethereum ([*OpenCerts*](https://opencerts.io/), [*BlockCerts*](https://www.blockcerts.org/)), bitcoin ([*BlockCerts*](https://www.blockcerts.org/)) and many more.
+We conclude for now by mentioning **blockchain/distributed ledger technologies**, for secure logging of (e.g. registration) events, where such logs have the property that it is virtually impossible to change the order and/or contents of the logged events, and that the logs are highly available to those that are authorized. Both public and private blockchains are known to be used, and different SSI-solutions may use them for different purposes, e.g. the registration of schema's, %%credential types|credential-type%%, DIDs and associated DID documents, revocation accumulators, etc. Examples include [*EBSI*](https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/ebsi) ([*European Blockchain Partnership*](https://ec.europa.eu/digital-single-market/en/blockchain-technologies)), [*Hyperledger Indy*](https://www.hyperledger.org/projects/hyperledger-indy) (Alastria, Findy, Sovrin), Ethereum ([*OpenCerts*](https://opencerts.io/), [*BlockCerts*](https://www.blockcerts.org/)), bitcoin ([*BlockCerts*](https://www.blockcerts.org/)) and many more.
 
 It is expected that there are already some interfaces out there that may turn out to be useful here (e.g. (unverified) [*FIWARE*](https://fiware-idm.readthedocs.io/en/7.4.0/eidas/), CEF)
 
@@ -91,21 +91,21 @@ It is expected that there are already some interfaces out there that may turn ou
 
 [ABC] Its origins lie with the [*ABC4Trust project*](https://abc4trust.eu/). Extensive [*documentation*](https://abc4trust.eu/index.php/pub) is available, e.g. an [*Architecture for Attribute-based Credential Technologies*](https://abc4trust.eu/download/Deliverable_D2.2.pdf) (also one [*for developers*](https://abc4trust.eu/download/ABC4Trust-H2.2_ABC4Trust_Architecture_for_Developers.pdf)).
 
-[eIDAS5] [*"Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC"*](http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.01.0073.01.ENG). *EUR-Lex*. The European Parliament and the Council of the European Union.
+[eIDAS5] [*"Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic %%transactions|business-transaction%% in the internal market and repealing Directive 1999/93/EC"*](http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.01.0073.01.ENG). *EUR-Lex*. The European Parliament and the Council of the European Union.
 
 ------
 
-### 2.4.  API Layers (‘ESSIF Glue’ and ‘SSI Tech APIs’)
+### 2.4.  API Layers ('ESSIF Glue' and 'SSI Tech APIs')
 
 There are two interface layers in this architecture
 
-The '**ESSIF Glue**' interface layer consists of a [documented set of APIs](https://gitlab.grnet.gr/essif-lab/tno-ssi-service/developer-docs) between the %%Data Collector|data-collector%% and %%data discloser|data-discloser%% on the one hand, and the WHIV components on the other hand. The purpose of these APIs is to make calling the WHIV functions as simple as possible, given the functions of the %%data discloser|data-discloser%% and %%Data Collector|data-collector%%. Ultimately, we would like to see these APIs standardized. Having such APIs allows different %%parties|party%% to create their own version of the WHIV components, supporting the SSI technologies as they see fit, and shrinking or expanding functionalities as they feel appropriate. Parties can then select such WHIV components as they see fit.
+The '**ESSIF Glue**' interface layer consists of a [documented set of APIs](https://gitlab.grnet.gr/essif-lab/tno-ssi-service/developer-docs) between the %%data collector|data-collector%% and %%data discloser|data-discloser%% on the one hand, and the WHIV components on the other hand. The purpose of these APIs is to make calling the WHIV functions as simple as possible, given the functions of the %%data discloser|data-discloser%% and %%data collector|data-collector%%. Ultimately, we would like to see these APIs standardized. Having such APIs allows different %%parties|party%% to create their own version of the WHIV components, supporting the SSI technologies as they see fit, and shrinking or expanding functionalities as they feel appropriate. %%Parties|party%% can then select such WHIV components as they see fit.
 
 The **SSI Tech APIs** interface layer is the union of the interfaces of the components within it. Any standardization in there is outside the scope of eSSIF-Lab.
 
 -------
 
-## 3.  eSSIF-Lab Infrastructure Functional Components
+## 3. eSSIF-Lab Infrastructure Functional Components
 
 This section details the functional specifications of the components that are in scope of the eSSIF-Lab infrastructure, i.e. in the green (rounded) rectangle as shown in the figure below:
 
@@ -118,53 +118,53 @@ This section details the functional specifications of the components that are in
 
 ### 3.1.  Data Collector and Validation Policy
 
-The purpose of the %%data collector|data-collector%% is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an %%agent|agent%% of) its %%principal|principal%% to decide whether or not to engage in a (new) transaction of the specified type.
+The purpose of the %%data collector|data-collector%% is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an %%agent|agent%% of) its %%principal|principal%% to decide whether or not to engage in a (new) %%transaction|business-transaction%% of the specified type.
 
-Typically, the %%data collector|data-collector%% would start a transaction either
+Typically, the %%data collector|data-collector%% would start a %%transaction|business-transaction%% either
 
--   when it receives a request from some %%agent|agent%% of another %%party|party%% for engaging in a transaction of a specific kind.
--   when it is instructed by, or on behalf of its %%principal|principal%%, to request a specific kind of transaction to some %%agent|agent%% of another %party.[^DC.1]
+-   when it receives a request from some %%agent|agent%% of another %%party|party%% for engaging in a %%transaction|business-transaction%% of a specific kind.
+-   when it is instructed by, or on behalf of its %%principal|principal%%, to request a specific kind of %%transaction|business-transaction%% to some %%agent|agent%% of another %%party|party%%.[^DC.1]
 
-In either case, a transaction form (object, context) has to be created that matches the kind of transaction, and a ‘**transaction-id**’ must be generated that identifies this form/object/context. It will be used for binding incoming or outgoing messages to this transaction, enabling communications to remain congruent, not only with the %%agent|agent%% that requested the transaction, but also with other %%agents|agent%% from the same %%principal|principal%% and/or using different %%communication channels|communication-channel%%.
+In either case, a %%transaction|business-transaction%% form (object, context) has to be created that matches the kind of %%transaction|business-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|business-transaction%%, enabling communications to remain congruent, not only with the %%agent|agent%% that requested the %%transaction|business-transaction%%, but also with other %%agents|agent%% from the same %%principal|principal%% and/or using different %%communication channels|communication-channel%%.
 
-Handling/managing the various %%communication channels|communication-channel%% through which data can be exchanged is also a task of the Data Collector[^DC.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 party|peer-party%%. Another reason is that the %%peer party|peer-party%% may use multiple %%agents|agent%% to provide such data, e.g. human %%agents|agent%% (that might use web-browsers, social-media apps, phones, or physical visits), %%SSI-agents|ssi-agent%% (that use the SSI infrastructure), or other %%electronic agents|digital-agent%% (e.g. services that can provide data when appropriate permissions are submitted - e.g. user consent tokens).
+Handling/managing the various %%communication channels|communication-channel%% through which data can be exchanged is also a task of the Data Collector[^DC.2]. One reason for this is that negotiating a %%transaction|business-transaction%% not only requires data to be acquired, but also to be provided to the %%peer party|peer-party%%. Another reason is that the %%peer party|peer-party%% may use multiple %%agents|agent%% to provide such data, e.g. human %%agents|agent%% (that might use web-browsers, social-media apps, phones, or physical visits), %%SSI-agents|ssi-agent%% (that use the SSI infrastructure), or other %%electronic agents|digital-agent%% (e.g. services that can provide data when appropriate permissions are submitted - e.g. user consent tokens).
 
-Thus, the %%Data Collector|data-collector%% is generally considered capable of obtaining data through different %%communication channels|communication-channel%%. However, the technical tracks of eSSIF-Lab will exclusively focus on the %%communication channel|communication-channel%% through which %%credentials|credential%% can be requested and obtained. Any extensions or business productization of %%Data Collector|data-collector%% designs may be considered in the business tracks of eSSIF-Lab. The latter is not considered any further in this section.
+Thus, the %%data collector|data-collector%% is generally considered capable of obtaining data through different %%communication channels|communication-channel%%. However, the technical tracks of eSSIF-Lab will exclusively focus on the %%communication channel|communication-channel%% through which %%credentials|credential%% can be requested and obtained. Any extensions or business productization of %%data collector|data-collector%% designs may be considered in the business tracks of eSSIF-Lab. The latter is not considered any further in this section.
 
-In order to acquire data through SSI mechanisms for filling in a form for a specific kind of transaction, the %%data collector|data-collector%% needs to know what kinds of %%credentials|credential%% it should ask for, which %%parties|party%% its %%principal|principal%% trusts to issue such %%credentials|credential%%, what kinds of verification proofs for such %%credentials|credential%% must hold and which may be disregarded.[^DC.3] Also, when the %%data collector|data-collector%% gets a %%credential|credential%% that satisfies the necessary verification proofs, it needs a way to map the contents of that %%credential|credential%% to the structure of the transaction context that is used internally by (other systems of) its %principal.[^DC.4] Also, as the %%data collector|data-collector%% gets more and more data - which it may get through multiple, different channels - it needs to determine whether or not the resulting set is sufficiently consistent and coherent.[^DC.5]
+In order to acquire data through SSI mechanisms for filling in a form for a specific kind of %%transaction|business-transaction%%, the %%data collector|data-collector%% needs to know what kinds of %%credentials|credential%% it should ask for, which %%parties|party%% its %%principal|principal%% trusts to issue such %%credentials|credential%%, what kinds of verification proofs for such %%credentials|credential%% must hold and which may be disregarded.[^DC.3] Also, when the %%data collector|data-collector%% gets a %%credential|credential%% that satisfies the necessary verification proofs, it needs a way to map the contents of that %%credential|credential%% to the structure of the %%transaction|business-transaction%% context that is used internally by (other systems of) its %%principal|principal%%.[^DC.4] Also, as the %%data collector|data-collector%% gets more and more data - which it may get through multiple, different channels - it needs to determine whether or not the resulting set is sufficiently consistent and coherent.[^DC.5]
 
-In order to make the %%data collector|data-collector%% work, a %%Validation Policy|validation-policy%% (or %%data collector policy|data-collector-policy%%) is created by, or on behalf of the %%principal|principal%%, which specifies at least:
+In order to make the %%data collector|data-collector%% work, a %%validation policy|validation-policy%% (or %%data collector policy|data-collector-policy%%) is created by, or on behalf of the %%principal|principal%%, which specifies at least:
 
--   the kinds of transactions the %%principal|principal%% is willing to (electronically) engage in, from both the requester and the provider perspectives;
--   for each such transaction type:
+-   the kinds of %%transactions|business-transaction%% the %%principal|principal%% is willing to (electronically) engage in, from both the requester and the provider perspectives;
+-   for each such %%transaction type|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|business-transaction%% commitment decision.
 
     -   the kinds of %%credentials|credential%% and %%issuers|issuer%% that the %%principal|principal%% is willing to accept as sources for valid data; (optionally?), the endpoint URI at which issuing %%parties|party%% do the actual %%credential|credential%% issuing may be specified[^DC.6].
 
-    -   for each kind of %credential: the verification proofs that must hold to be accepted as a source for valid data.
+    -   for each kind of %%credential|credential%%: the verification proofs that must hold to be accepted as a source for valid data.
 
     -   the mapping between fields in such %%credentials|credential%% and fields in the form to be filled in.
 
 The %%policy|policy%% must be designed in such a way that it is extendable as new features will be called for in the future.
 
-The ability to create new transaction contexts and the availability of the %%data collector policy|data-collector-policy%% enable the %%data collector|data-collector%% to request the %%verifier|verifier%% component of its %%principal|principal%% to obtain %%credentials|credential%% of the types that it can use to fill in the transaction form when they satisfy the verification and validation requirements of its %principal.[^DC.7]
+The ability to create new %%transaction|business-transaction%% contexts and the availability of the %%data collector policy|data-collector-policy%% enable the %%data collector|data-collector%% to request the %%verifier|verifier%% component of its %%principal|principal%% to obtain %%credentials|credential%% of the types that it can use to fill in the %%transaction form|transaction-form%% when they satisfy the verification and validation requirements of its %%principal|principal%%.[^DC.7]
 
-When the %%verifier|verifier%% returns such data (which comes with a list of proofs that the %%verifier|verifier%% has checked), the %%data collector|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|party%%-specific and hence come from the %%data collector policy|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|data-collector%% itself must make validation decisions, either electronically (according to the%%data collector policy|data-collector-policy%%) or by ‘outsourcing’ such decisions to human %%agents|agent%% of its %%principal|principal%% by providing an appropriate validation user interface.
+When the %%verifier|verifier%% returns such data (which comes with a list of proofs that the %%verifier|verifier%% has checked), the %%data collector|data-collector%% must then validate that data, i.e. determine whether or not it is valid for the specific %%transaction|business-transaction%% it is assembling the data for. The validation rules are %%party|party%%-specific and hence come from the %%data collector policy|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|data-collector%% itself must make validation decisions, either electronically (according to the %%data collector policy|data-collector-policy%%) or by 'outsourcing' such decisions to human %%agents|agent%% of its %%principal|principal%% by providing an appropriate validation user interface.
 
-As long as data is needed, the %%data collector|data-collector%% can intermittently request the %%verifier|verifier%% to produce it (or it can use other %%communication channels|communication-channel%%, 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|data-collector%% can intermittently request the %%verifier|verifier%% to produce it (or it can use other %%communication channels|communication-channel%%, which is outside scope for now). It does so until it times out, or the form has become 'clean'.
 
 -----
 
-[^DC.1]: This feature ensures that the transaction is really two-way, and both %%parties|party%% can request %%credentials|credential%% from the other. For example, a web-shop can then ask for a (delivery) address %%credential|credential%%, and the customer can ask for a %%credential|credential%% issued e.g. by the chamber of commerce that the web-shop is a legitimate company (and not some maffia website).
+[^DC.1]: This feature ensures that the %%transaction|business-transaction%% is really two-way, and both %%parties|party%% can request %%credentials|credential%% from the other. For example, a web-shop can then ask for a (delivery) address %%credential|credential%%, and the customer can ask for a %%credential|credential%% issued e.g. by the chamber of commerce that the web-shop is a legitimate company (and not some maffia website).
 
 [^DC.2]: It may well be that this functionality can somehow be split off in the (near) future.
 
-[^DC.3]: For high-value transactions, verification proofs are more important than for low-value transactions. This is to be decided by the %%principal|principal%% of the %%data collector|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.
+[^DC.3]: For high-value %%transactions|business-transaction%%, verification proofs are more important than for low-value %%transactions|business-transaction%%. This is to be decided by the %%principal|principal%% of the %%data collector|data-collector%%. An example from the physical world: in order to obtain a visa for China, it is required that your passport (%%credential|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.
 
-[^DC.4]: For example, a %%credential|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|principal%% have implemented. Mapping allows such cases to be accommodated for.
+[^DC.4]: For example, a %%credential|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|principal%% have implemented. Mapping allows such cases to be accommodated for.
 
-[^DC.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.
+[^DC.5]: Inconsistent or incoherent data is necessary for various purposes. First, it allows for correct further processing of the %%transaction|business-transaction%%. A non-existent postal code, or one that doesn't match the delivery address, may hinder a fluent %%transaction|business-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|business-transaction%% %%risk|risk%%, and checking consistency/coherence of such data is part of the risk mitigation process.
 
 [^DC.6]: This enables the %%data collector|data-collector%% to pass the endpoint URI on to the %%verifier|verifier%% when it requests for such a %%credential|credential%%, which in turn can send it to the %%holder|holder%% of other %%parties|party%% enabling them to obtain the %%credential|credential%% from that %%issuer|issuer%% endpoint if that other %%party|party%% does not have that %%credential|credential%% in its %%wallet|wallet%%. The endpoint URI can in fact be put in the %%policy|policy%%, because the (human) %%agent|agent%% that creates/maintains the %%policy|policy%% would need to know that the issuing %%party|party%% is actually issuing such %%credentials|credential%%, what their contents means, etc., and hence is capable of tracking down the URI where that %%party|party%% issues the %%credentials|credential%%.
 
@@ -174,42 +174,42 @@ As long as data is needed, the %%data collector|data-collector%% can intermitten
 
 ### 3.2.   Verifier Component, and its Policy/Preferences
 
-The purpose of the %%verifier|verifier%% component is to support the %%data collector|data-collector%% by providing it with a single, simple API that it can use to request and obtain data that it needs to produce a clean transaction form, as well as the results of checking verification proofs (this is also why it is called the ‘%verifier’ component).
+The purpose of the %%verifier|verifier%% component is to support the %%data collector|data-collector%% by providing it with a single, simple API that it can use to request and obtain data that it needs to produce a clean %%transaction form|transaction-form%%, as well as the results of checking verification proofs (this is also why it is called the '%%verifier|verifier%%' component).
 
-Typically, the %%data collector|data-collector%% would ask the %%verifier|verifier%% to provide a %%credential|credential%% that it can use to fill in a (coherent set of) field(s) in the transaction form. It is realistic to think that %%credentials|credential%% from different %%issuers|issuer%% - trusted by the %verifier’s %%principal|principal%% - can be used for this purpose. However, it is also realistic that such %%credentials|credential%% will not use the same %%credential type|credential-type%% - they might well use different schemes to provide such data. Therefore, the %%data collector|data-collector%% should specify a list of pairs (%credential-type%, %issuer) instances of which could all be used to provide the data it needs - which it can obtain from the %%data collector policy|data-collector-policy%%.
+Typically, the %%data collector|data-collector%% would ask the %%verifier|verifier%% to provide a %%credential|credential%% that it can use to fill in a (coherent set of) field(s) in the %%transaction form|transaction-form%%. It is realistic to think that %%credentials|credential%% from different %%issuers|issuer%% - trusted by the %%verifier's|verifier%% %%principal|principal%% - can be used for this purpose. However, it is also realistic that such %%credentials|credential%% will not use the same %%credential type|credential-type%% - they might well use different schemes to provide such data. Therefore, the %%data collector|data-collector%% should specify a list of pairs (%%credential-type|credential-type%%, %%issuer|issuer%%) instances of which could all be used to provide the data it needs - which it can obtain from the %%data collector policy|data-collector-policy%%.
 
-Then, the %%verifier|verifier%% needs to know the address and protocol that it can use to reach a %%holder|holder%% component owned by the %%party|party%% that its %%principal|principal%% is trying to negotiate the transaction with. The %%data collector|data-collector%% specifies this as part of the request - and it can do so because it has received the original request, and does all %%communication channel|communication-channel%% handling.
+Then, the %%verifier|verifier%% needs to know the address and protocol that it can use to reach a %%holder|holder%% component owned by the %%party|party%% that its %%principal|principal%% is trying to negotiate the %%transaction|business-transaction%% with. The %%data collector|data-collector%% specifies this as part of the request - and it can do so because it has received the original request, and does all %%communication channel|communication-channel%% handling.
 
-%%verifiers|verifier%% are not expected to handle every kind of %%credential|credential%% (e.g. VC’s, ABC’s, etc.) that exists, but rather a specific subset. For (at least one of) the %%credential types|credential-type%%, the %%verifier|verifier%% can construct a so-called %%presentation request|presentation-request%%, i.e. a message that is specific for the %%credential type|credential-type%% and/or associated protocol, which it can then send to the %holder’s address.
+%%verifiers|verifier%% are not expected to handle every kind of %%credential|credential%% (e.g. VC's, ABC's, etc.) that exists, but rather a specific subset. For (at least one of) the %%credential types|credential-type%%, the %%verifier|verifier%% can construct a so-called %%presentation request|presentation-request%%, i.e. a message that is specific for the %%credential type|credential-type%% and/or associated protocol, which it can then send to the %%holder's|holder%% address.
 
 This request message should contain at least
 
--   the transaction-id, so that when it is copied into the associated response message, the latter can be associated to the transaction it belongs to. Also, it should contain the
--   the (%credential type%, %issuer) pairs that may satisfy the request, and to each of these additional data, e.g. the URI of the endpoint where the %%issuer|issuer%% issues such %%credentials|credential%%, the maximum age of the %%credential|credential%%, etc.
--   meta-data that may be useful for the %%holder|holder%% (or its %principal), e.g. texts stating the purpose(s) for which the data will be used ([*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) Art. 5.1.b), or requesting consent ([*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) Art. 7.2) “in an intelligible and easily accessible form, using clear and plain language”.
--   a signature of the %%verifiers|verifier%% %%principal|principal%%, for the purpose of showing compliance with the [*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) (e.g. Art 28.3.h), and enabling the %holder’s %%principal|principal%% to obtain proof that the %%verifiers|verifier%% %%principal|principal%% has violated the [*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN)’s minimization principle asked for data for a particular purpose, which can be used in an argument in disputes about data minimization ([*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) Art. 5.1.c).
+-   the %%transaction-id|transaction-id%%, so that when it is copied into the associated response message, the latter can be associated to the %%transaction|business-transaction%% it belongs to. Also, it should contain the
+-   the (%%credential type|credential-type%%, %%issuer|issuer%%) pairs that may satisfy the request, and to each of these additional data, e.g. the URI of the endpoint where the %%issuer|issuer%% issues such %%credentials|credential%%, the maximum age of the %%credential|credential%%, etc.
+-   meta-data that may be useful for the %%holder|holder%% (or its %%principal|principal%%), e.g. texts stating the purpose(s) for which the data will be used ([*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) Art. 5.1.b), or requesting consent ([*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) Art. 7.2) “in an intelligible and easily accessible form, using clear and plain language”.
+-   a signature of the %%verifiers|verifier%% %%principal|principal%%, for the purpose of showing compliance with the [*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) (e.g. Art 28.3.h), and enabling the %%holder's|holder%% %%principal|principal%% to obtain proof that the %%verifiers|verifier%% %%principal|principal%% has violated the [*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN)'s minimization principle asked for data for a particular purpose, which can be used in an argument in disputes about data minimization ([*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) Art. 5.1.c).
 
 The request message must be designed in such a way that it is extendable as new features will be called for in the future.
 
-In order to make the %%verifier|verifier%% component work, a %%Verifier|verifier%% Policy%/Preferences object is created by, or on behalf of the %%principal|principal%%, which specifies at least: \[to be elaborated\]
+In order to make the %%verifier|verifier%% component work, a %%verifier policy|verifier-policy%% object is created by, or on behalf of the %%principal|principal%%, which specifies at least: \[to be elaborated\]
 
-A response to this request (called a %presentation) will be obtained from a %%holder|holder%% component of the %%peer party|peer-party%%. This response will contain a reference to the request, allowing the %%verifier|verifier%% to combine them. The %%verifier|verifier%% will then check that the data in the response is a %%credential|credential%% that it has asked for (correct type/%issuer), verify the proofs that are provided (predominantly the digital signature), and do some additional checks (e.g. whether or not the %%credential|credential%% has expired, is revoked, and such).
+A response to this request (called a %%presentation|presentation%%) will be obtained from a %%holder|holder%% component of the %%peer party|peer-party%%. This response will contain a reference to the request, allowing the %%verifier|verifier%% to combine them. The %%verifier|verifier%% will then check that the data in the response is a %%credential|credential%% that it has asked for (correct type/%issuer%), verify the proofs that are provided (predominantly the digital signature), and do some additional checks (e.g. whether or not the %%credential|credential%% has expired, is revoked, and such).
 
-Then, the %%verifier|verifier%% will send a message to the %%data collector|data-collector%%, containing the transaction-id, the data it has received, and the results of the various checks.
+Then, the %%verifier|verifier%% will send a message to the %%data collector|data-collector%%, containing the %%transaction-id|transaction-id%%, the data it has received, and the results of the various checks.
 
 ### 3.3.   Holder Component, and its Policy/Preferences
 
-The purpose of the %%holder|holder%% component is to handle %%Presentation Requests|presentation-request%% that it receives from %%verifier|verifier%% components (both of its own %%principal|principal%%, and of other %parties), and responding to such requests.
+The purpose of the %%holder|holder%% component is to handle %%presentation requests|presentation-request%% that it receives from %%verifier|verifier%% components (both of its own %%principal|principal%%, and of other %%parties|party%%), and responding to such requests.
 
 Typically, a %%holder|holder%% component would access its %%principal's|principal%% %%wallet|wallet%% to check if it has a %%credential|credential%% that it can use to construct a %%presentation|presentation%% (i.e. response) that satisfies the received request.
 
-It may happen that the %%wallet|wallet%% does not have such a %%credential|credential%%. However, for every (%credential, %issuer) pair, the request should specify the URI that is capable of issuing such a %%credential|credential%%. If or when the %%Holder|holder%% Policy%/Preferences permit this, the %%holder|holder%% then requests its %principal’s %%data collector|data-collector%% to initiate a new transaction that will get the %%credential|credential%% from that %%issuer|issuer%%, for which a clean transaction form would then consist of one that contains said %%credential|credential%%. The %%holder|holder%% would then store it in its %principal’s %%wallet|wallet%%, and then proceed to service the %%presentation|presentation%% request as if it had obtained that %%credential|credential%% from its %principal’s %%wallet|wallet%%.
+It may happen that the %%wallet|wallet%% does not have such a %%credential|credential%%. However, for every (%%credential|credential%%, %%issuer|issuer%%) pair, the request should specify the URI that is capable of issuing such a %%credential|credential%%. If or when the %%holder policy|holder-policy%% permit this, the %%holder|holder%% then requests its %%principal's|principal%% %%data collector|data-collector%% to initiate a new %%transaction|business-transaction%% that will get the %%credential|credential%% from that %%issuer|issuer%%, for which a clean %%transaction form|transaction-form%% would then consist of one that contains said %%credential|credential%%. The %%holder|holder%% would then store it in its %%principal's|principal%% %%wallet|wallet%%, and then proceed to service the %%presentation|presentation%% request as if it had obtained that %%credential|credential%% from its %%principal's|principal%% %%wallet|wallet%%.
 
-It may also happen that the %%wallet|wallet%% has multiple %%credentials|credential%% that satisfy the request, in which case the %%holder|holder%% must choose the one to use for constructing the %%presentation|presentation%%. Again, the %%Holder|holder%% Policy%/Preferences will specify how this choice needs to be made, and whether or not this can be done automatically by the %%holder|holder%%. If not, the %%holder|holder%% will need to provide for an interaction with a human Colleague that will make such decisions.
+It may also happen that the %%wallet|wallet%% has multiple %%credentials|credential%% that satisfy the request, in which case the %%holder|holder%% must choose the one to use for constructing the %%presentation|presentation%%. Again, the %%holder policy|holder-policy%% will specify how this choice needs to be made, and whether or not this can be done automatically by the %%holder|holder%%. If not, the %%holder|holder%% will need to provide for an interaction with a human Colleague that will make such decisions.
 
-In order to make the %%holder|holder%% component work, a %%Holder|holder%% Policy%/Preferences object is created by, or on behalf of the %%principal|principal%%, which specifies e.g.:
+In order to make the %%holder|holder%% component work, a %%holder policy|holder-policy%% object is created by, or on behalf of the %%principal|principal%%, which specifies e.g.:
 
--   whether or not %%credentials|credential%% may be collected ‘on the fly’;
+-   whether or not %%credentials|credential%% may be collected 'on the fly';
 -   how to choose between %%credentials|credential%% that all satisfy a %%presentation request|presentation-request%% (and whether the %%holder|holder%% can make such choices by itself, or whether or not human interaction is required);
 -   the kinds of events and data to write to a %%holder|holder%%-audit-log.
 
@@ -217,11 +217,11 @@ In order to make the %%holder|holder%% component work, a %%Holder|holder%% Polic
 
 The purpose of the %%data discloser|data-discloser%% component is to state the (various, sometimes intermediary) results of %%transactions|business-transaction%%, by collecting data from the Business Data Stores, and creating a set of (related) %%statements/claims|assertion%% that can subsequently be issued to other %%parties|party%%. A special kind of result is the (provisioning of) a %%credential|credential%% that its %%principal|principal%% already has created.
 
-Typically, and at any point in time, %%parties|party%% are capable of expressing %%statements|assertion%% about %%entities|entity%% that they know to exist. They could express %%statements|assertion%% about individuals, about themselves, the state of transactions, and so on. We will use the term ‘**subject (of a %%statement|assertion%% of a %party)**’ to refer to the %%entity|entity%% that this %%party|party%% knows to exist, and about whom/which the %%statement|assertion%% has been made.
+Typically, and at any point in time, %%parties|party%% are capable of expressing %%statements|assertion%% about %%entities|entity%% that they know to exist. They could express %%statements|assertion%% about individuals, about themselves, the state of %%transactions|business-transaction%%, and so on. We will use the term '**subject (of a %%statement|assertion%% of a %%party|party%%)**' to refer to the %%entity|entity%% that this %%party|party%% knows to exist, and about whom/which the %%statement|assertion%% has been made.
 
-We will use the term ‘**subject-id (of a %%statement|assertion%% of a %party)**’ to refer to the representation that this %%party|party%% has chosen to use for referring to the subject in said %%statement|assertion%%. A subject-id must have the property of being an %%identifier|identifier%% within every administrative context that this %%party|party%% uses. It need not be humanly interpretable (and preferably is not).
+We will use the term '**subject-id (of a %%statement|assertion%% of a %%party|party%%)**' to refer to the representation that this %%party|party%% has chosen to use for referring to the subject in said %%statement|assertion%%. A subject-id must have the property of being an %%identifier|identifier%% within every administrative context that this %%party|party%% uses. It need not be humanly interpretable (and preferably is not).
 
-%%parties|party%% need to specify the kinds of %%credentials|credential%% they are willing to issue, the class of %%entities|entity%% (e.g. people, cars, %organizations) for which it will issue them, and the information schema (structure) that it will use in %%credentials|credential%% of such kinds.<sup>[Data Discloser.1]</sup> This allows the %%data discloser|data-discloser%% to construct data objects that conform to this information schema, and present it to the %%issuer|issuer%% component for actual issuing.
+%%parties|party%% need to specify the kinds of %%credentials|credential%% they are willing to issue, the class of %%entities|entity%% (e.g. people, cars, %%organizations|organization%%) for which it will issue them, and the information schema (structure) that it will use in %%credentials|credential%% of such kinds.<sup>[Data Discloser.1]</sup> This allows the %%data discloser|data-discloser%% to construct data objects that conform to this information schema, and present it to the %%issuer|issuer%% component for actual issuing.
 
 The %%data discloser policy|data-discloser-policy%% specifies the kinds of (linked-)data-objects that %%credentials|credential%% may be created for. This allows the %%data discloser|data-discloser%% to construct such a (linked-)data-objects for every subject-id that identifies a subject of the class for which a %%credential|credential%% can be issued, which can subsequently be sent to the %%issuer|issuer%% component that can turn it into a %%credential|credential%% of a specific sort.
 
@@ -238,13 +238,13 @@ The %%data discloser|data-discloser%% may either push %%credential|credential%%
 
 ### 3.5.  Issuer Component, and its Policy/Preferences
 
-The purpose of the %%issuer|issuer%% component is to issue ‘%credentials’, i.e. digital constructs that contain
+The purpose of the %%issuer|issuer%% component is to issue '%%credentials|credential%%', i.e. digital constructs that contain
 
 -   sets of (related) %%statements/claims|assertion%% (e.g. as produced by the %%data discloser|data-discloser%%)
--   metadata (e.g. type of %%credential|credential%%, date of issuing and expiration, endpoints, e.g. for revocation checking, %%credential type|credential-type%%, credential advertisements, credential enforcement policy, etc.)
+-   metadata (e.g. type of %%credential|credential%%, date of issuing and expiration, endpoints, e.g. for revocation checking, %%credential type|credential-type%%, credential advertisements, credential enforcement %%policy|policy%%, etc.)
 -   proofs (e.g. a digital signature by which third %%parties|party%% can prove its provenance and integrity.
 
-Another purpose that an %%issuer|issuer%% might serve is to provide a means that allows any other %%agent|agent%% that somehow has obtained a copy or %%presentation|presentation%% of a %%credential|credential%%, to verify whether or not the data therein is conformant to the business administration of its %%principal|principal%%. We will use the term ‘revocation service’ to refer to such means. Whether or not an %%issuer|issuer%% provides such a service, and what kind of revocation service is provided (e.g. a revocation list, an online revocation status protocol, etc.), is a decision that its %%principal|principal%% should make, and specify in the %%issuer|issuer%% policies%/Preferences.
+Another purpose that an %%issuer|issuer%% might serve is to provide a means that allows any other %%agent|agent%% that somehow has obtained a copy or %%presentation|presentation%% of a %%credential|credential%%, to verify whether or not the data therein is conformant to the business administration of its %%principal|principal%%. We will use the term 'revocation service' to refer to such means. Whether or not an %%issuer|issuer%% provides such a service, and what kind of revocation service is provided (e.g. a revocation list, an online revocation status protocol, etc.), is a decision that its %%principal|principal%% should make, and specify in the %%issuer  policy|issuer-policy%%.
 
 An %%issuer|issuer%% component may issue %%credentials|credential%% in various formats, e.g. as a Verifiable Credential (VC), an Attribute-Based Credential (ABC), an OpenID Connect/JWT token, etc. The issuing %%party|party%% must specify %%credential types|credential-type%% in such a way that if the same %%credential|credential%% is issued in different formats, it is possible for an arbitrary %%verifier|verifier%% to determine whether or not two %%credentials|credential%% that have different formats, are in fact the same. One way of doing this is that the %%issuer|issuer%% generates an %%identifier|identifier%% for every %%credential|credential%% that it constructs (before expressing it in a specific format).
 
@@ -252,7 +252,7 @@ After the %%issuer|issuer%% has created a %%credential|credential%% (in one or m
 
 -----
 
-[Issuer.1] Tombstoning is a mechanism that is used e.g. in (distributed) ledgers that do not allow for actual deletion, such as blockchains, by marking entries in the ledger as ‘being deleted’ (i.e. adding a ‘tombstone’ to such entries).
+[Issuer.1] Tombstoning is a mechanism that is used e.g. in (distributed) ledgers that do not allow for actual deletion, such as blockchains, by marking entries in the ledger as 'being deleted' (i.e. adding a 'tombstone' to such entries).
 
 [Issuer.2] This allows e.g. individuals, that have an %%issuer|issuer%% component in their SSI app, to issue self-signed %%credentials|credential%% and provide them to %%verifiers|verifier%% that request them as usual for non-self-signed %%credentials|credential%%.
 
@@ -263,12 +263,12 @@ After the %%issuer|issuer%% has created a %%credential|credential%% (in one or m
 
 The primary purpose of the %%wallet|wallet%% Component is to (securely) store data, and in particular:
 
--   %%credentials|credential%% - both those that have been issued by the %%issuer|issuer%% (i.e. self-signed %credentials) and those that have been obtained from %%issuers|issuer%% of other %%parties|party%%, and
+-   %%credentials|credential%% - both those that have been issued by the %%issuer|issuer%% (i.e. self-signed %%credentials|credential%%) and those that have been obtained from %%issuers|issuer%% of other %%parties|party%%, and
 -   (private) keys e.g. for signing/sealing data on behalf of its %%principal|principal%%.
 
 Other kinds of data may be stored by a %%wallet|wallet%% as well - we will have to see what is practical and makes sense.
 
-By ‘securely storing data’ we mean that such data
+By 'securely storing data' we mean that such data
 
 -   remains available until a request is received from an %%digital colleague|digital-colleague%% that is entitled to request deletion of such data;
 -   remains unchanged during the time in which it is stored;
@@ -278,40 +278,40 @@ By ‘securely storing data’ we mean that such data
 
 It is expected that components other than the %%holder|holder%% and %%issuer|issuer%% will (arise and) need access. One example could be a component that is capable of securely signing data on behalf of the %%principal|principal%%. Another example could be a component that implements some kind of credential revocation functionality.
 
-Human beings cannot directly access any %%wallet|wallet%% component, not even the ones they own. They need an %%electronic agent|digital-agent%% that is capable of authenticating them as (an %%agent|agent%% of) the %%party|party%% that owns the %%wallet|wallet%% component, and upon successful authentication provides a User Interface through which the Human Being can instruct this %%electronic agent|digital-agent%% to manage the %wallet’s contents.
+Human beings cannot directly access any %%wallet|wallet%% component, not even the ones they own. They need an %%electronic agent|digital-agent%% that is capable of authenticating them as (an %%agent|agent%% of) the %%party|party%% that owns the %%wallet|wallet%% component, and upon successful authentication provides a User Interface through which the Human Being can instruct this %%electronic agent|digital-agent%% to manage the %%wallet's|wallet%% contents.
 
-In order to make the %%wallet|wallet%% component work, a %%wallet|wallet%% policy%/Preferences object is created by, or on behalf of the %%principal|principal%%, the contents of which remains to be specified.
+In order to make the %%wallet|wallet%% component work, a %%wallet policy|wallet-policy%% object is created by, or on behalf of the %%principal|principal%%, the contents of which remains to be specified.
 
-## 4.  Initial SSI-Agent Network Architecture
+## 4. Initial SSI-Agent Network Architecture
 
 :::info Editor's note
 *The eSSIF-Lab functional architecture is not final. This chapter is an example of how work that is currently being done may already be documented for the purpose of furthering discussions and providing inspiration to readers.*
 :::
 
-%%parties|party%% need to deploy (technical) components that act as their %%agents|agent%%. Individuals would typically have a mobile app whose user interface allows them to fulfill any or all of the roles of %%holder|holder%%, %%verifier|verifier%% and %%issuer|issuer%%. Wallet functionality may be included in this app, but it might equally well live in the cloud, as a second %(digital) agent%. An individual might also have (cloud) servers that %%agents|agent%% of other %%parties|party%% may contact for conducting transactions without the need for the individual itself to do something. All of this holds equally well for larger %%organizations|organization%%.
+%%parties|party%% need to deploy (technical) components that act as their %%agents|agent%%. Individuals would typically have a mobile app whose user interface allows them to fulfill any or all of the roles of %%holder|holder%%, %%verifier|verifier%% and %%issuer|issuer%%. Wallet functionality may be included in this app, but it might equally well live in the cloud, as a second %%(digital) agent|digital-agent%%. An individual might also have (cloud) servers that %%agents|agent%% of other %%parties|party%% may contact for conducting %%transactions|business-transaction%% without the need for the individual itself to do something. All of this holds equally well for larger %%organizations|organization%%.
 
-It is conceivable that the set of SSI functions is spread over multiple %(digital) agents%, in which case there is going to be a need for such %%agents|agent%% to contact one another, and conduct transactions in a way that may differ from doing that with %%agents|agent%% of other %%parties|party%%. Basically, this can be seen as %%colleagues|colleague%% interacting with one another to get things done within one %%organization|organization%%. Seen from the outside, it looks like every %%organization|organization%% has a (smaller or larger) network of %%agents|agent%%. This chapter provides more details on this topic.
+It is conceivable that the set of SSI functions is spread over multiple %%(digital) agents|digital-agent%%, in which case there is going to be a need for such %%agents|agent%% to contact one another, and conduct %%transactions|business-transaction%% in a way that may differ from doing that with %%agents|agent%% of other %%parties|party%%. Basically, this can be seen as %%colleagues|colleague%% interacting with one another to get things done within one %%organization|organization%%. Seen from the outside, it looks like every %%organization|organization%% has a (smaller or larger) network of %%agents|agent%%. This chapter provides more details on this topic.
 
 The SSI-Agent Network Architecture has two viewpoints:
 
-1.  the **intra-%party or single-%party SSI viewpoint**, which focuses on the set of (human and/or electronic) %%agents|agent%% of a single, specific %%party|party%%.
-2.  the **inter-%party or multi-%party SSI viewpoint**, which is about specific functional components (e.g. %%verifier|verifier%%, %%holder|holder%%, etc.) that typically belong to different %%parties|party%%.
+1.  the **intra-party or single-party SSI viewpoint**, which focuses on the set of (human and/or electronic) %%agents|agent%% of a single, specific %%party|party%%.
+2.  the **inter-party or multi-party SSI viewpoint**, which is about specific functional components (e.g. %%verifier|verifier%%, %%holder|holder%%, etc.) that typically belong to different %%parties|party%%.
 
-An individual %%party|party%% may use the single-%party SSI viewpoint to come to grips with concerns related to the creation and maintenance of its network of its %%electronic agent|digital-agent%%. The set of concerns would include:
+An individual %%party|party%% may use the single-%%party|party%% SSI viewpoint to come to grips with concerns related to the creation and maintenance of its network of its %%electronic agent|digital-agent%%. The set of concerns would include:
 
--   How can electronic components be onboarded as an %%agents|agent%% of this %party?
--   How can the integrity of such %%electronic agent|digital-agent%% be stated in a trustworthy manner (do such components need some kind of accreditation certificate, do we need to come up with a service that can remotely test the integrity of a component and have it issue ephemeral integrity-certificates/%credentials, …)?
+-   How can electronic components be onboarded as an %%agents|agent%% of this %%party|party%%?
+-   How can the integrity of such %%electronic agent|digital-agent%% be stated in a trustworthy manner (do such components need some kind of accreditation certificate, do we need to come up with a service that can remotely test the integrity of a component and have it issue ephemeral integrity-certificates/%credentials%, …)?
 -   How can the %%party|party%% specify which of its %%agents|agent%% may talk with which other %%agents|agent%%, and for what purposes?
--   How should a %%party|party%% specify the policies for the various SSI functionalities - what kind of support would be useful here?
+-   How should a %%party|party%% specify the %%policies|policy%% for the various SSI functionalities - what kind of support would be useful here?
 -   …
 
-%%parties|party%% that want (their %agents) to interact with one another may use the multi-%party SSI viewpoint to come to grips with concerns related to the interoperability of the functionalities that their components implement. The set of concerns would include:
+%%parties|party%% that want (their %%agents|agent%%) to interact with one another may use the multi-%%party|party%% SSI viewpoint to come to grips with concerns related to the interoperability of the functionalities that their components implement. The set of concerns would include:
 
 -   How can %%parties|party%% interact with one another at the information level (this includes decentralized semantic interoperability issues, advertising %%credentials|credential%%, how a %%party|party%% can find other %%parties|party%% that issue %%credentials|credential%% that are useful to him, etc.)
 -   What kinds of underlying technologies must %%agents|agent%% of a %%party|party%% support so as to be(come) interoperable with %%parties|party%% that it wants to interact with?
 -   …
 
-## 5.  High Level Transaction Flows
+## 5. High Level Transaction Flows
 
 This chapter explains at a high level how electronic %%business transactions|business-transaction%% are being conducted. This is prerequisite to the explanations in chapter 4, that describe how the eSSIF-Lab architectural components are used in such %%transactions|business-transaction%%. For illustrative purposes, we stick to the example of getting a parking permit that we introduced in section 1.1.
 
@@ -326,7 +326,7 @@ This chapter explains at a high level how electronic %%business transactions|bus
 
 *Figure 3: High-level transaction overview.*
 
-The adjacent figure shows how a transaction is conducted at the highest abstraction level. One %%party|party%%, called the ‘Requester’, sends a request for a product or service to another %%party|party%% (that we will call the ‘Provider’). Then, they start to negotiate a ‘transaction agreement’, which means that they exchange data through various channels for the purpose of establishing the details of the product/service to be provided and the compensation, data needed to mitigate transaction risks, etc., all of which is necessary for the %%parties|party%% to (individually/subjectively) decide whether or not to commit to the transaction. Section 3.2 provides more detail about this phase.
+The adjacent figure shows how a %%transaction|business-transaction%% is conducted at the highest abstraction level. One %%party|party%%, called the 'Requester', sends a request for a product or service to another %%party|party%% (that we will call the 'Provider'). Then, they start to negotiate a 'transaction agreement', which means that they exchange data through various channels for the purpose of establishing the details of the product/service to be provided and the compensation, data needed to mitigate %%transaction|business-transaction%% %%risks|risk%%, etc., all of which is necessary for the %%parties|party%% to (individually/subjectively) decide whether or not to commit to the %%transaction|business-transaction%%. Section 3.2 provides more detail about this phase.
 
 After commitment, the producer works to provide the product or service, and the requester arranges the compensation. This phase is entirely up to the business, and hence out of scope of this document.
 
@@ -334,11 +334,11 @@ When all is done, %%parties|party%% may issue a (signed) %%statement|assertion%%
 
 In the example of the parking permit, a citizen (requester) sends a request to its municipality (provider) for obtaining a parking permit (the product/service). Then, the citizen fills in an online form (and uploads necessary PDFs) to enable the municipality to decide whether or not to produce the requested permit. The eSSIF-lab architecture adds a secondary, %%electronic communication channel|digital-communication-channel%% that allows citizens to fill in the forms by using e.g. an SSI app on their phone. When the form is complete, the municipality decides whether or not to produce and issue the permit, which it can do as usual. It can also issue a %%credential|credential%% that states the result of the %%transaction|business-transaction%%, i.e. contains the details of the parking permit.
 
-Please note that while %%transactions|business-transaction%% are symmetrical in nature (i.e. both requester and provider need data from the other so as to decide whether or not to commit to the transaction), there is an implicit asymmetry in that activities that %%parties|party%% perform are ordered in time, which implies e.g. that the commitment decisions of both %%parties|party%% cannot be done at the same time. Also, in practice, it often happens that a %%party|party%% requires the other %%party|party%% to have executed (and stated) its part of the transaction before it actually commits to the transaction. For example, a provider may require the requester to have paid for the product before it is being shipped out. Consequently, the protocols for exchanging data/%credentials will need to support such ‘asynchronous’ ways of working.
+Please note that while %%transactions|business-transaction%% are symmetrical in nature (i.e. both requester and provider need data from the other so as to decide whether or not to commit to the %%transaction|business-transaction%%), there is an implicit asymmetry in that activities that %%parties|party%% perform are ordered in time, which implies e.g. that the commitment decisions of both %%parties|party%% cannot be done at the same time. Also, in practice, it often happens that a %%party|party%% requires the other %%party|party%% to have executed (and stated) its part of the %%transaction|business-transaction%% before it actually commits to the %%transaction|business-transaction%%. For example, a provider may require the requester to have paid for the product before it is being shipped out. Consequently, the protocols for exchanging data/%credentials% will need to support such 'asynchronous' ways of working.
 
 ### 5.2.  Transaction Negotiation Phase
 
-This phase starts by the requester sending a transaction request to the provider, and ends whenever either one of the %%parties|party%% quits, or both %%parties|party%% commit.
+This phase starts by the requester sending a %%transaction request|transaction-request%% to the provider, and ends whenever either one of the %%parties|party%% quits, or both %%parties|party%% commit.
 
 <img
   alt="High-level transaction negotiation"
@@ -347,7 +347,7 @@ This phase starts by the requester sending a transaction request to the provider
 
 *Figure 4: High-level transaction negotiation.*
 
-This figure shows the high-level interactions during this phase. It starts by the requester sending a request for a product or service to the provider. Typically, this would lead to the provider presenting a (web) form the requester must fill in. In the eSSIF-Lab context, the form will also provide a means for setting up a SSI %%communication channel|communication-channel%%, i.e. a secure %%communication channel|communication-channel%% through which provider and requester can both request and obtain (%presentations of) %%credentials|credential%%, the contents of which they can use to fill in the form. Then, after the form is ‘clean’, i.e. contains sufficient information for deciding whether or not to commit to the transaction, this phase ends.
+This figure shows the high-level interactions during this phase. It starts by the requester sending a request for a product or service to the provider. Typically, this would lead to the provider presenting a (web) form the requester must fill in. In the eSSIF-Lab context, the form will also provide a means for setting up a SSI %%communication channel|communication-channel%%, i.e. a secure %%communication channel|communication-channel%% through which provider and requester can both request and obtain (%%presentations|presentation%% of) %%credentials|credential%%, the contents of which they can use to fill in the form. Then, after the form is 'clean', i.e. contains sufficient information for deciding whether or not to commit to the %%transaction|business-transaction%%, this phase ends.
 
 Note that forms may contain fields that are required only in specific circumstances. It may only be possible to assess whether or not such circumstances apply after some (other) fields have been filled in. This means that the phase for requesting %%presentations|presentation%% and responding to such requests may very well consist of multiple requests and associated responses.
 
@@ -359,16 +359,16 @@ Conversely, the citizen might request the (alleged) municipality to provide %%cr
 
 ### 5.3.  Stating Transactions - Issuing Credentials
 
-In the eSSIF-Lab context, we take ‘%credential’ to mean any (set of coherent) %statement(s) about any (one or more) subject(s) that a single %%party|party%% has issued with proof of provenance (i.e. anyone else can determine the identity of that %issuer) and a proof of integrity (i.e. anyone can determine whether or not the content of the %%credential|credential%% has been changed/tampered with since it was issued). From this, it follows that any %%party|party%% can issue any kind of %%credential|credential%% for any %%entity|entity%% that it knows to exist. A %%credential|credential%% does not need to be about a person or an %%organization|organization%%, but it can also refer to an order, a delivery, a seat-reservation, a prescription, etc.
+In the eSSIF-Lab context, we take '%%credential|credential%%' to mean any (set of coherent) %%statement(s)|assertion%% about any (one or more) subject(s) that a single %%party|party%% has issued with proof of provenance (i.e. anyone else can determine the identity of that %%issuer|issuer%%) and a proof of integrity (i.e. anyone can determine whether or not the content of the %%credential|credential%% has been changed/tampered with since it was issued). From this, it follows that any %%party|party%% can issue any kind of %%credential|credential%% for any %%entity|entity%% that it knows to exist. A %%credential|credential%% does not need to be about a person or an %%organization|organization%%, but it can also refer to an order, a delivery, a seat-reservation, a prescription, etc.
 
 We foresee two ways in which %%credentials|credential%% can be issued:
 
 1.  both the requester and provider may issue %%credentials|credential%% to the other %%party|party%% in the process flow that they are in. They can do so for the purpose of stating any (lack of) progress and/or results of the administrative process flow they are in.
-    In the example of the parking permit, the municipality may need some time to do some manual checks before it can issue the permit; in this case, it could issue a %%credential|credential%% that states that the citizen has requested the parking permit and any other details that might be appropriate. Also, if it can issue the parking permit straight away, it can issue a %%credential|credential%% that contains the details of that permit. The requester may issue a %%credential|credential%% to the municipality stating the date/time and kind of transaction, judgements or comments about the service that the municipality has provided.
-2.  any %%party|party%% may issue a %%credential|credential%% upon request. Basically, this means that a %%party|party%% (in the role of requester) issues a request to that other %%party|party%% (in the role of provider) asking for the particular %%credential|credential%%. This is just another case of doing transactions, that can be handled just as any other kind of transaction.
+    In the example of the parking permit, the municipality may need some time to do some manual checks before it can issue the permit; in this case, it could issue a %%credential|credential%% that states that the citizen has requested the parking permit and any other details that might be appropriate. Also, if it can issue the parking permit straight away, it can issue a %%credential|credential%% that contains the details of that permit. The requester may issue a %%credential|credential%% to the municipality stating the date/time and kind of %%transaction|business-transaction%%, judgements or comments about the service that the municipality has provided.
+2.  any %%party|party%% may issue a %%credential|credential%% upon request. Basically, this means that a %%party|party%% (in the role of requester) issues a request to that other %%party|party%% (in the role of provider) asking for the particular %%credential|credential%%. This is just another case of doing %%transactions|business-transaction%%, that can be handled just as any other kind of %%transaction|business-transaction%%.
     In the example of the parking permit, when a citizen requests a permit, the provider might look for an existing permit prior to issuing a new one (it would have to do such a check during the process anyway), and depending on its business logic it would be providing the %%credential|credential%% without further ado, or start the process of issuing a new one.
 
-## 6.  Detailed Transaction Flows
+## 6. Detailed Transaction Flows
 
 :::info Editor's note
 *The eSSIF-Lab functional architecture is not final. This chapter is an example of how work that is currently being done may already be documented for the purpose of furthering discussions and providing inspiration to readers.*
@@ -376,7 +376,7 @@ We foresee two ways in which %%credentials|credential%% can be issued:
 
 This chapter explains the details of how electronic %%business transactions|business-transaction%% are being conducted using the eSSIF-Lab architectural components as described in chapter 2. We keep on using the parking permit example that we introduced in section 1.1. for illustrative purposes.
 
-Note that both %%parties|party%%, requester and provider, each have components as described in chapter 2. Also note that whenever we introduce another %%party|party%%, it too has such components. Thus, every %%party|party%% can play any of the traditional SSI roles ‘%verifier’, ‘%holder’ and ‘%issuer’, and each has its own ‘%wallet’ functionality. Also, they all have %%data collector|data-collector%% and %%data discloser|data-discloser%% functionality that connect these aforementioned infrastructural components with the business applications.
+Note that both %%parties|party%%, requester and provider, each have components as described in chapter 2. Also note that whenever we introduce another %%party|party%%, it too has such components. Thus, every %%party|party%% can play any of the traditional SSI roles '%%verifier|verifier%%', '%%holder|holder%%' and '%%issuer|issuer%%', and each has its own '%%wallet|wallet%%' functionality. Also, they all have %%data collector|data-collector%% and %%data discloser|data-discloser%% functionality that connect these aforementioned infrastructural components with the business applications.
 
 When reading the next sections, please be aware that when a component of one of these %%parties|party%% communicates with another component, this other component may be of the same %%party|party%%, as well as of the other %%party|party%%. Figure 2 only shows components that belong to a single %%party|party%%.
 
@@ -386,15 +386,15 @@ When reading the next sections, please be aware that when a component of one of
 *The eSSIF-Lab functional architecture is not final. This section is an example of how work that is currently being done may already be documented for the purpose of furthering discussions and providing inspiration to readers.*
 :::
 
-The requester starts the transaction by pointing his web-browser to a web-page of the provider that (a) explains how to get a parking permit, and (b) provides a parking-permit application form that needs to be filled in. Technically, this means that the browser does a GET request to an endpoint that is serviced by the providers %%data collector|data-collector%% component.
+The requester starts the %%transaction|business-transaction%% by pointing his web-browser to a web-page of the provider that (a) explains how to get a parking permit, and (b) provides a parking-permit application form that needs to be filled in. Technically, this means that the browser does a GET request to an endpoint that is serviced by the providers %%data collector|data-collector%% component.
 
-The %%data collector|data-collector%% services this request by creating an empty form of a type appropriate for the request. Then, it continues with requesting data to fill in the form (and providing data as requested by the other Party). It starts this by providing a web page that includes the form to be filled in, as well as a deep-link, QR-code or something similar that allows the requester’s browser (plug-in) or SSI-app to contact the provider-endpoint and set up a secure %%communication channel|communication-channel%% through which both can communicate electronically. From then on there are two channels between the requester and the provider: one is a traditional (manual) web-browser - web-server channel, the other is one within which the %%SSI-Agents|ssi-agent%% of various %%parties|party%% will be communicating.
+The %%data collector|data-collector%% services this request by creating an empty form of a type appropriate for the request. Then, it continues with requesting data to fill in the form (and providing data as requested by the other Party). It starts this by providing a web page that includes the form to be filled in, as well as a deep-link, QR-code or something similar that allows the requester's browser (plug-in) or SSI-app to contact the provider-endpoint and set up a secure %%communication channel|communication-channel%% through which both can communicate electronically. From then on there are two channels between the requester and the provider: one is a traditional (manual) web-browser - web-server channel, the other is one within which the %%SSI-Agents|ssi-agent%% of various %%parties|party%% will be communicating.
 
 It is a task of the %%data collector|data-collector%% to orchestrate the inputs: different parts of the form may be filled in and subsequently changed in different ways. Some parts
 
 -   are required only after a certain condition is met (which is to be evaluated whenever the data that is entered into the form is changed)
 -   must or may initially be filled in manually (i.e.: through the browser);
--   must or may initially be filled in with data from a %credential;
+-   must or may initially be filled in with data from a %%credential|credential%%;
 -   may be changed manually;
 -   may be changed with data from a newly supplied %%credential|credential%%.
 
@@ -407,9 +407,9 @@ Because of this orchestration, the interface to the %%verifier|verifier%% compon
 
 *Figure 5: Generic Verification with SSI service.*
 
-The request %%identifier|identifier%% is included in messages between the %%data collector|data-collector%% and %%verifier|verifier%% so as to allow them to handle different transactions at the same time.
+The request %%identifier|identifier%% is included in messages between the %%data collector|data-collector%% and %%verifier|verifier%% so as to allow them to handle different %%transactions|business-transaction%% at the same time.
 
-We assume that the provider has specified the form and the associated validation- and issuing policies that make the following description work. We refer the reader to section \[tbd\] for an explanation of how the provider can do this.
+We assume that the provider has specified the form and the associated validation- and issuing %%policies|policy%% that make the following description work. We refer the reader to section \[tbd\] for an explanation of how the provider can do this.
 
 ### 6.2.  Stating a Transaction
 
diff --git a/docs/terminology-maintenance-script.rieks b/docs/terminology-maintenance-script.rieks
index c7ed67d6df2aea2fd1a511398021b063598e8e73..93d6d15507a0758a20b47ee5551a8e09e2221c7d 100644
--- a/docs/terminology-maintenance-script.rieks
+++ b/docs/terminology-maintenance-script.rieks
@@ -17,6 +17,7 @@
 beg = "(?<=\W%%)"
 mid = "(?<=\|)"
 end = "(?=%%\W)"
+ss = "(?:['’]?s|\(s\))?"
 
 dutyright = "(?:dut(?:y|ies)|rights?)"
 dutyright = "%{dutyright}(?:-*(?:/|and|or|and/or)-*%{dutyright})?"
@@ -29,25 +30,34 @@ dutyrighttype = "%{dutyright}-types?"
 // `filter "*.txt"`                  - any .txt file in the root folder
 // `filter "**/*.txt"`               - any .txt file
 
-filter "docs/terms/credential-type.md"
+filter "docs/functional-architecture.md"
 
 // PREPROCESSING: convert single-%-notations into %%-notations.
 
+// Convert quotes so that only two types remain: ' an "For starte
+replace-regex "[‘’]"
+with "'"
+
 // We might want to 'undo' %%...|...%% markers in case some 'show text' needs to be associated wiht another 'reftext'
-// replace-regex "(\W%)%([^\|\n\r]+)\|[^%\n\r]+%(%\W)"
-// with "$1$2$3"
+// replace-regex "(?<=\W)%%([^\|\n\r]+)\|[^%\n\r]+%%(?=\W)"
+// with "%$1%"
 
 // First, convert %show text% into %%show text%%
-replace-regex "(?<=\s%)(([\w/-]|'|\s)*)(?=%([,.]?\s|-\w))"
+// Test set: none may match: %verif%er, %verif"ier%, "%verifier%", `%verifier%`
+// Test set: all must match:  %my verifier%, ('%verifiers%'), %verifier's%, %verifier’s%, (%(ver)/ifier%):., %(our) (vfyr)%, %verifier's%. %verifier’s%... single-%party%), '**subject (of a %party%)**' to 
+// replace-regex "(?<=\s\(?%)(\w|\s|\(|\)|[/-’'"])+(?=%([)":,.!?]*\s|-\w))"
+replace-regex "(?<=[-\s]\(?'?%)([^%]+)(?=%(([*_):;,.'!?]|\[[^\]]*\]){0,5}\s|-\w))"
 with "%$1%"
 
 // Only thereafter can we convert %showtext (words without trailing `%`-char) into %%showtext%%
-replace-regex "(?<=\s%)(([\w/-]|')*)(?=[,.]?\s)"
+// Test set: none may match: %verif%er, %(our) (verifier)%,
+// Test set: all must match: %verifier %verifiers, '%verifier'), %verifier's, %verifier’s, %verifier:, (%verifiers), %verifier's..... %verifier’s,?.!?  its %principal.[^DC.4] Also a %party)'
+replace-regex "(?<=(?:\s\(?'?|/)%)((\w+((/|-|’|')\w)?)+)(?='?\)?[:;,.!?]*(\[[^\]]*\])?\s)"
 with "%$1%%"
 
 // Then, we can expand %%show text%% into %%show text|show text%%
-replace-regex "(?<=\W%%)([^\|]*?)(?=%%\W)"
-with "$1|$1"
+replace-regex "(?<=\W)%%([^\|]*?)%%(?=\W)"
+with "%%$1|$1%%"
 
 // Next, we convert the latter part into lowercase
 replace-regex "(?<=\|)([^A-Z%]*?[A-Z].*?)(?=%%)"
@@ -68,25 +78,25 @@ with "$1-$2"
 // ACTUAL PROCESSING: now we need to convert well-known `lowercase-show-text`s to appropriate `reftexts`
 
 // [A]
-replace-regex "%{mid}(action|actor|agent|assertion|author)'?s%{end}"
+replace-regex "%{mid}(action|actor|agent|assertion|author)%{ss}%{end}"
 with "$1"
 
 // [B]
-replace-regex "%{mid}(business-transaction)'?s?%{end}"
+replace-regex "%{mid}(business-transaction)%{ss}?%{end}"
 with "$1"
 
 // [C]
 // for 'claim', see 'statement'
-replace-regex "%{mid}(colleague|concept|credential(-type)?|commitment-decision)'?s?%{end}"
+replace-regex "%{mid}(colleague|concept|credential(-type)?|commitment-decision)%{ss}?%{end}"
 with "$1"
 
-replace-regex "%{mid}communications?-(channel|session)'?s?%{end}"
+replace-regex "%{mid}communications?-(channel|session)%{ss}?%{end}"
 with "communication-$1"
 
 // [D]
-replace-regex "%{mid}(definition|dependent|dictionary-file|dictionary|documentation-interop)'?s?%{end}"
+replace-regex "%{mid}(definition|dependent|dictionary-file|dictionary|documentation-interop)%{ss}?%{end}"
 with "$1"
-replace-regex "%{mid}(?:electronic-|digital-)(actor|agent|colleague|communication-channel|policy)'?s%{end}"
+replace-regex "%{mid}\(?(?:electronic|digital)\)?-(actor|agent|colleague|communication-channel|policy)%{ss}%{end}"
 with "digital-$1"
 
 replace-regex "%{mid}(%{dutyrighttype}|%{dutyright})%{end}"
@@ -94,17 +104,17 @@ with "pattern-duties-and-rights"
 
 replace-regex "%{mid}data-(collector|discloser)-polic(y's|ies)%{end}"
 with "data-$1-policy"
-replace-regex "%{mid}data-(collector|discloser)'?s?%{end}"
+replace-regex "%{mid}data-(collector|discloser)%{ss}?%{end}"
 with "data-$1"
 
 // [E]
-replace-regex "%{mid}(employee|employer)'?s%{end}"
+replace-regex "%{mid}(employee|employer)%{ss}%{end}"
 with "$1"
 replace-regex "%{mid}(legal-)?entit(y's|ies)%{end}"
 with "$1entity"
 
 // [G]
-replace-regex "%{mid}(glossary-file|guardian(ship)?(-relationship)?(-type)?)'?s%{end}"
+replace-regex "%{mid}(glossary-file|guardian(ship)?(-relationship)?(-type)?)%{ss}%{end}"
 with "$1"
 replace-regex "%{mid}glossar(y's|ies)%{end}"
 with "glossary"
@@ -117,20 +127,20 @@ with "governance"
 
 // [H-I-J-K] (all holder, issuer, verifier and wallet stuff, too)
 // for associated policies, see [P]
-replace-regex "%{mid}(holder|issuer|verifier|wallet|identifier|jurisdiction(-governor)?|knowledge(-governor)?)'?s%{end}"
+replace-regex "%{mid}(holder|issuer|verifier|wallet|identifier|jurisdiction(-governor)?|knowledge(-governor)?)%{ss}%{end}"
 with "$1"
 
 // [L-M]
-replace-regex "%{mid}(legal-jurisdiction|legal-system|mental-model)'?s%{end}"
+replace-regex "%{mid}(legal-jurisdiction|legal-system|mental-model)%{ss}%{end}"
 with "$1"
 // for 'legal entities', see 'entities'
 
 // [O]
-replace-regex "%{mid}(objective|organization|owned|owner|ownership)'?s%{end}"
+replace-regex "%{mid}(objective|organization|owned|owner|ownership)%{ss}%{end}"
 with "$1"
 
 // [P]
-replace-regex "%{mid}(participant|pattern-file|pattern|(peer-)(actor|agent)|policy-governor|presentation-request|presentation|principal)'?s%{end}"
+replace-regex "%{mid}(participant|pattern-file|pattern|(peer-)(actor|agent)|policy-governor|presentation-request|presentation|principal)%{ss}%{end}"
 with "$1"
 replace-regex "%{mid}(|peer-)part(y's|ies)%{end}"
 with "$1party"
@@ -139,21 +149,21 @@ with "$1policy"
 
 // [R-S]
 // For 'rights', see [D]uties
-replace-regex "%{mid}(risk|scope-file|scope|ssi-agent)'?s%{end}"
+replace-regex "%{mid}(risk|scope-file|scope|ssi-agent)%{ss}%{end}"
 with "$1"
-replace-regex "%{mid}(statement|claim)'?s%{end}"
+replace-regex "%{mid}(statement|claim|statement%{ss}/claim)%{ss}%{end}"
 with "assertion"
 
 // [T]
 // for transaction data collector/discloers policies, see [P]
-replace-regex "%{mid}(term-file|term|transaction-(agreement|data-(collector|discloser)|form|proposal))'?s%{end}"
+replace-regex "%{mid}(term-file|term|transaction-(agreement|data-(collector|discloser)|form|proposal))%{ss}%{end}"
 with "$1"
-replace-regex "%{mid}transaction'?s?%{end}"
+replace-regex "%{mid}transaction%{ss}?%{end}"
 with "business-transaction"
 
 // [V]
 // for verifier stuff - see holder
-replace-regex "%{mid}(verifiable-credential|verifier)'?s%{end}"
+replace-regex "%{mid}(verifiable-credential|verifier)%{ss}%{end}"
 with "$1"
 replace-regex "%{mid}vocabular(y's|ies)%{end}"
 with "vocabulary"
@@ -164,15 +174,15 @@ with "vocabulary"
 // CLEANING UP UNINTENDED CHANGES
 
 // Remove all `%%showtext|reftext%%` in docusaurus header.
-replace-regex "(^---\s*\nid:(?:.|[\n\r])*?)%%([^\|]*)\|([^%]*)%%((?:.|[\n\r])*\n---)"
+replace-regex "(^---\s*\nid:(?:[^%]*[\n\r]){0,8})[^%]*%%([^\|]*)\|([^%]*)%%(?:[^%]*[\n\r]){0,8}---"
 with "$1$2$4"
-replace-regex "(^---\s*\nid:(?:.|[\n\r])*?)%%([^\|]*)\|([^%]*)%%((?:.|[\n\r])*\n---)"
+replace-regex "(^---\s*\nid:(?:[^%]*[\n\r]){0,8})[^%]*%%([^\|]*)\|([^%]*)%%(?:[^%]*[\n\r]){0,8}---"
 with "$1$2$4"
-replace-regex "(^---\s*\nid:(?:.|[\n\r])*?)%%([^\|]*)\|([^%]*)%%((?:.|[\n\r])*\n---)"
+replace-regex "(^---\s*\nid:(?:[^%]*[\n\r]){0,8})[^%]*%%([^\|]*)\|([^%]*)%%(?:[^%]*[\n\r]){0,8}---"
 with "$1$2$4"
-replace-regex "(^---\s*\nid:(?:.|[\n\r])*?)%%([^\|]*)\|([^%]*)%%((?:.|[\n\r])*\n---)"
+replace-regex "(^---\s*\nid:(?:[^%]*[\n\r]){0,8})[^%]*%%([^\|]*)\|([^%]*)%%(?:[^%]*[\n\r]){0,8}---"
 with "$1$2$4"
-replace-regex "(^---\s*\nid:(?:.|[\n\r])*?)%%([^\|]*)\|([^%]*)%%((?:.|[\n\r])*\n---)"
+replace-regex "(^---\s*\nid:(?:[^%]*[\n\r]){0,8})[^%]*%%([^\|]*)\|([^%]*)%%(?:[^%]*[\n\r]){0,8}---"
 with "$1$2$4"
 
 // Remove all `%%showtext|reftext%%` occurrences in markdown headers
diff --git a/docs/terms/action-type.md b/docs/terms/action-type.md
new file mode 100644
index 0000000000000000000000000000000000000000..a818c4d7d00e3915979463cb93a80f07012ed624
--- /dev/null
+++ b/docs/terms/action-type.md
@@ -0,0 +1,13 @@
+---
+id: action-type
+title: "Action Type"
+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."
+---
+
+:::info Editor's note
+TNO (or others) to provide further content of this file.
+:::
diff --git a/docs/terms/action.md b/docs/terms/action.md
index cebf688741f56fc6921f10fbe8a593c9767da0b6..936065898f74de40fc5909ea7a42dead851f1bcb 100644
--- a/docs/terms/action.md
+++ b/docs/terms/action.md
@@ -5,11 +5,13 @@ scopeid: essifLab
 type: concept
 typeid: action
 stage: draft
-hoverText: "Action: something that is actually done/executed - by a single Actor, as a single operation, for a given party within a specific context."
+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."
 ---
 
 ### Short Description
-An **Action** is something that is actually done/executed by a %%actor|actor%% in some context (i.e. in a specific place, at a specific time). During the time interval in which the action is executed, the actor may still execute other actions in other execution-contexts (multi-tasking). An action is executed for, or on behalf of, a specific %%party|party%%, which means that the primary guidance for executing the action, e.g. how to execute it, boundary conditions within which the execution must take place, etc., comes from a %%policy|policy%% that this %%party|party%% has established for actions of that kind. The actor is assumed to have appropriate access to that policy.
+An **Action** is something that is actually done/executed by a %%actor|actor%% in some context (i.e. in a specific place, at a specific time). During the time interval in which the action is executed, the actor may still execute other actions in other execution-contexts (multi-tasking). An action is executed on behalf of a specific %%party|party%%, which means that the primary guidance for executing the action, e.g. how to execute it, boundary conditions within which the execution must take place, etc., comes from a %%policy|policy%% that this %%party|party%% has established for actions of that kind. The actor is assumed to have appropriate access to that policy.
+
+The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
 
 ### Purpose
 The ability to distinguish between (non)actions allows one to determine which (kinds of) %%actors|actor%% are capable of executing actions (e.g. by establishing that they have the competences required by the %%party|party%%), and as a consequence may be permitted and/or required to execute them. Also, this ability enables %%parties|party%% to determine the execution-policy, i.e. the set of rules, working-instructions, preferences and other guidance that actors should obey or comply with when exeucting an action on its behalf.
@@ -27,5 +29,3 @@ An **Action** is something that is done by an actor, can be considered a single
 - %%actor|actor%%
 - %%agent|agent%%
 
-### Background
-The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
\ No newline at end of file
diff --git a/docs/terms/actor.md b/docs/terms/actor.md
index 39569a0c93545e803cd88467366388d0f075dd3d..5715657e831ff7bd546158d2993e764063c1f036 100644
--- a/docs/terms/actor.md
+++ b/docs/terms/actor.md
@@ -11,6 +11,8 @@ hoverText: "Actor: Entity that can act (do things), e.g. people, machines, but n
 ### Short Description
 An **Actor** is someone or something that can actually do things, such as people or machines. Actors will generally do things, i.e. execute %%actions|action%% in different ways, depending on the context, or the %%party|party%% for whom they do this.
 
+The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
+
 ### Purpose
 The ability to distinguish between (non)actors allows one to determine which (kinds of) actors are capable of executing which (kinds of) %%actions|action%%, specifically since %%organizations|organization%% do not qualify as an actor (they need actors to get things done).
 
@@ -29,6 +31,3 @@ Entity that is capable of actually executing %%actions|action%% (acting, doing t
 - %%peer actor|peer-actor%%
 - %%agent|agent%%
 - %%principal|principal%%
-
-### Background
-The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
diff --git a/docs/terms/agent.md b/docs/terms/agent.md
index 5a6a8f531dae291ce0a2cbbaa6ede8d37cd850eb..63898d3f4291014e7fa296d726301bababb10d64 100644
--- a/docs/terms/agent.md
+++ b/docs/terms/agent.md
@@ -5,18 +5,20 @@ scopeid: essifLab
 type: concept
 typeid: agent
 stage: draft
-hoverText: "Agent (of a Party): an Actor that is executing an Action for, or on behalf of a Party (called the Principal of that Actor)."
+hoverText: "Agent (of a Party): an Actor that is executing an Action on behalf of a Party (called the Principal of that Actor)."
 ---
 
 ### Short Description
-An **Agent** is an %%actor|actor%% that is executing an action %%action|action%% for, or on behalf of some %%party|party%% (which we call the %%principal|principal%% of that agent). During the time interval in which the action is executed, the actor may execute other actions in other execution-contexts, on behalf of the same or another %%party|party%%. However, for the execution of a single %%action|action%%, the actor is an agent for precisely one principal. It is assumed that the principal provides its agents with the %%policies|policy%% that provide the agents with the rules, working-instructions, preferences and other guidance that they need to comply with when exeucting the action.
+An **Agent** is an %%actor|actor%% that is executing an action %%action|action%% on behalf of some %%party|party%% (which we call the %%principal|principal%% of that agent). During the time interval in which the action is executed, the actor may execute other actions in other execution-contexts, on behalf of the same or another %%party|party%%. However, for the execution of a single %%action|action%%, the actor is an agent for precisely one principal. It is assumed that the principal provides its agents with the %%policies|policy%% that provide the agents with the rules, working-instructions, preferences and other guidance that they need to comply with when exeucting the action.
+
+The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
 
 ### Purpose
 The ability to distinguish between (non)agents is relevant in many situations, including:
 - electronic communication: the agent 
 
 ### Criterion
-An **Agent** is a role that an %%actor|actor%% fulfills with respect to some %%party|party%% when that actor is executing some %%action|action%% for, or on behalf of that %%party|party%%.
+An **Agent** is a role that an %%actor|actor%% fulfills with respect to some %%party|party%% when that actor is executing some %%action|action%% on behalf of that %%party|party%%.
 
 ### Examples
 
@@ -27,6 +29,3 @@ An **Agent** is a role that an %%actor|actor%% fulfills with respect to some %%p
 - A company that makes cars may use robots that weld parts of a car together; these robots acts as Agents for that company.
 - A (running) webserver that accepts product orders for a retailer acts as a (digital) Agent for that retailer.
 - A wallet app that runs on a phone and that is exclusively used by a single person acts as a (digital) Agent for that person.
-
-### Background
-The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
diff --git a/docs/terms/author.md b/docs/terms/author.md
index 99e08ebec13252402e3da4f4a6070121b6fb7ca8..363b6d568f76e0a4e5c5e2f6b894fa12aa3c07ba 100644
--- a/docs/terms/author.md
+++ b/docs/terms/author.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: author
 stage: draft
-hoverText: "Author (of data/document/file/...): the Party, on whose behalf that data/document/file/... has been created or updated."
+hoverText: "Author (of data/document/file/...): a Party, on whose behalf that data/document/file/... has been created and/or updated."
 ---
 
 :::info Editor's note
diff --git a/docs/terms/business-transaction.md b/docs/terms/business-transaction.md
index d25c3c4bcce38bc6ec4fbf43ffb402b61d80da88..6825258a748732baabb66bdca77fbcda358cf943 100644
--- a/docs/terms/business-transaction.md
+++ b/docs/terms/business-transaction.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: business-transaction
 stage: draft
-hoverText: "Business Transaction: the exchange of goods, services, funds, or data between some Parties (called ‘participants’ of the transaction)."
+hoverText: "Business Transaction: the exchange of goods, services, funds, or data between some Parties (called Participants of the Transaction)."
 ---
 
 import useBaseUrl from '@docusaurus/useBaseUrl'
diff --git a/docs/terms/colleague.md b/docs/terms/colleague.md
index e4a668774bc337a50040509f9c13b59fe62fbf0d..8b73d14649df574cb3fbd26501466ea16b70dae3 100644
--- a/docs/terms/colleague.md
+++ b/docs/terms/colleague.md
@@ -5,10 +5,14 @@ scopeid: essifLab
 type: concept
 typeid: colleague
 stage: draft
-hoverText: "Colleagues: two or more Digital Agents that all have the same Principal (i.e. Party on whose behalf they exeucte Actions)."
+hoverText: "Colleagues: two or more (digital or non-digital) Agents that have the same Principal (i.e. Party on whose behalf they exeucte Actions)."
 ---
 
 :::info Editor's note
 TNO (or others) to provide the content of this file.
 :::
 
+### Purpose
+The ability to distinguish between (non) colleagues allows us to reason and communicate about the set of (digital and non-digital) %%actors|actor%% that are %%agents|agent%% for a **principal|principal%%. This is relevant in situations where different %%agents|agent%% excute %%actions|action%% in a single %%business transaction|business-transaction%% on behalf of the same %%principal|principal%%
+
+See also: %%digital colleague|digital-colleague%%.
diff --git a/docs/terms/commitment-decision.md b/docs/terms/commitment-decision.md
index 885e8d6a3d6cc7a0780195ba1266de236b87757c..46dc70b049bd179241bc7a06d08e7211d3f8fa41 100644
--- a/docs/terms/commitment-decision.md
+++ b/docs/terms/commitment-decision.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: commitment-decision
 stage: draft
-hoverText: "Commitment Decision (of a Party regarding a Business Transaction): the decision of that Party regarding whether or not to commit to that Business Transaction, i.e. (promise) to fulfill the obligations that the associated Business Transaction Agreement assigns to that Party."
+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."
 ---
 
 :::info Editor's note
diff --git a/docs/terms/communication-session.md b/docs/terms/communication-session.md
index 12ba1366a5bfd033a82513f47c08dc2578db8b43..5956be034cd8f829cf94ee0b8e30a179cb4cf156 100644
--- a/docs/terms/communication-session.md
+++ b/docs/terms/communication-session.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: communication-session
 stage: draft
-hoverText: "Communication Session: the time interval during which two Actors have an established Communication Channel."
+hoverText: "Communication Session: a time interval during which two Actors have an established Communication Channel that does not exist outside of that time interval."
 ---
 
 :::info Editor's note
diff --git a/docs/terms/concept-file.md b/docs/terms/concept-file.md
index 4c6917d715d28e53f896641185ff8743c9132b6d..a947744e7687bb947cf7288b00c78eb5c06e0f1d 100644
--- a/docs/terms/concept-file.md
+++ b/docs/terms/concept-file.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: concept-file
 stage: draft
-hoverText: "Concept-file: a file that defines/specifies a Concept."
+hoverText: "Concept-file: a file whose contents defines/specifies a Concept."
 ---
 
 ### Short Description
diff --git a/docs/terms/concept.md b/docs/terms/concept.md
index 97f89f8d3c556af840fd975edabb4b20ce8b9a99..737b199c13c1003c657bf83a6385b2178174ce53 100644
--- a/docs/terms/concept.md
+++ b/docs/terms/concept.md
@@ -12,6 +12,8 @@ hoverText: "Concept: the ideas/thoughts behind a classification of Entities (wha
 <!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
 A Concept tries to capture the idea behind a classification of entities[^1], allowing us to reason about everything in the class as if it were one thing. For example, the ideas ([mental representations](https://en.wikipedia.org/wiki/Mental_representation)) you have when processing the sentences "I can drink beer from a beer glass' and 'I can drink beer from a coffee mug' shows that the concepts that are behind 'beer glass' and 'coffee mug' differ. Note that in order to communicate about this idea, we also need a word or phrase (i.e.: a termat we can use to refer to (instances of) this idea.
 
+The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
+
 ### Purpose
 <!--Describe why the concept is needed. What purposes does it serve? What can you do with it that you cannot do (as well) without it? What objectives does it help realize? Why is this conceptevant within its scope of definition?-->
 Working together is easier when you and your peers share the same ideas. We need a way to test and ensure, that you and your peers _actually_ have the same understanding, for the purpose of making cooperation easier. Doing so is expected to not only reduce the number of terminological discussions, but also improve the efficiency and effectiveness of the remaining discussions.
@@ -31,9 +33,6 @@ A (description/specification of a) Concept MUST be [intensionally defined](https
 
 * %%Mental(or Conceptual) Model|pattern%% is a collection of concepts, relations between such concepts, and constraint rules that (elements of) such concepts and relations must satisfy. Such [models](https://en.wikipedia.org/wiki/Conceptual_model) are used to help people know, understand, or simulate a subject the model represents.
 
-### Background
-The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
-
 ### Domains
 <!--In which general knowledge ecosystems or mental model families does this concepty a role?-->
 * essifLab
diff --git a/docs/terms/credential-catalogue.md b/docs/terms/credential-catalogue.md
index 69d6ff63c6681438cf6e8359c919144fac9ecc08..c6bae59e4e673d85a125b42254e774bc0457044c 100644
--- a/docs/terms/credential-catalogue.md
+++ b/docs/terms/credential-catalogue.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: credential-catalogue
 stage: draft
-hoverText: "Credential Catalogue (functional component): the capability to register and advertise Credential Types and any related information that its governing Party decides to disclose for enabling other Parties to decide whether or not it is beneficial for them to request Credentials of such type for some kind(s) of decisions of theirs."
+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."
 ---
 
 :::info Editor's note
diff --git a/docs/terms/credential-type.md b/docs/terms/credential-type.md
index d9037e3397b1db7ef370612d768202eb1b3929b6..3a2a1ad9b88cd3879de6e01ce57c83aaf290d6fb 100644
--- a/docs/terms/credential-type.md
+++ b/docs/terms/credential-type.md
@@ -5,11 +5,13 @@ scopeid: essifLab
 type: concept
 typeid: credential-type
 stage: draft
-hoverText: "Credential Type: a specification of the kinds of Assertions (claims, statements) that must, or may be, included in Credentials of that type."
+hoverText: "Credential Type: the specification of the contents, properties, constraints etc. that Credentials of this type must have/comply with."
 ---
 
 ### Short Description
-A **credential-type** is a specification that states which kinds of %%assertions (claims, statements)|assertion%% can or may be found in any %%credential|credential%% of that kind. 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. 
+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.
+- 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
 %%Parties|party%% advertise %%credential types|credential-type%% for credentials that they issue for the purpose of enabling other %%parties|party%% to determine whether or not they should be asking for such %%credentials|credential%% of this issuing %party.
\ No newline at end of file
diff --git a/docs/terms/credential.md b/docs/terms/credential.md
index 45d49fa45588059d77c6bc10d620de6cd603b94c..c594e82ba26cde661635b68b75a5e64f8f32796d 100644
--- a/docs/terms/credential.md
+++ b/docs/terms/credential.md
@@ -9,7 +9,7 @@ hoverText: "Credential: data, representing a set of Assertions (claims, statemen
 ---
 
 ### Short Description
-A **credential** is a set of (related) %%assertions|assertion%% (also referred to as claims, or statements), to which metadata is added (e.g. date of issuing), and a number of proofs, which typically include a  proof of provenance (i.e. proof that it was created by, or on behalf of, a specific %%party|party%%), and a proof of integrity (i.e. proof that the data hasn't changed since it was issued). 
+A **credential** is a set of (related) %%assertions|assertion%% (also referred to as claims, or statements), to which metadata is added (e.g. date of issuing), and a number of proofs, which typically include a  proof of provenance (i.e. proof that it was created on behalf of a specific %%party|party%%), and a proof of integrity (i.e. proof that the data hasn't changed since it was issued). 
 
 In physical credentials, such as drivers licenses and passports, proofs of integrity usually apply to the physical document itself. They come in a variety of forms, such as the structure of the paper, holograms, watermarks, or (embedded) chips. The proof of provenance usually consists of the form-format of the credential and %%assertions|assertion%% about the document issuer.
 
diff --git a/docs/terms/data-collector.md b/docs/terms/data-collector.md
index 7bc1f06d2994462746f4c75eff48ef1917bf98d6..6b7650bfbfd3fa56ac094aaaf37524acf9a429ea 100644
--- a/docs/terms/data-collector.md
+++ b/docs/terms/data-collector.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: data-collector
 stage: draft
-hoverText: "Data Collector: a functional component that collects sufficient and Validated Data for deciding whether or not a request (typically for a product or a service) is to be serviced."
+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)."
 ---
 
 ### Short Description
@@ -50,24 +50,24 @@ It will be deleted in the (near?) future.
 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 Owner, to request a specific kind of transaction to some Agent of another Party.[^one]
+-   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 Owner 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).
 
 Thus, the Data Collector is generally considered capable of obtaining data through different communication channels. However, the technical tracks of eSSIF-Lab will exclusively focus on the communication channel through which credentials can be requested and obtained. Any extensions or business productization of Data Collector designs may be considered in the business tracks of eSSIF-Lab. The latter is not considered any further in this section.
 
-In order to acquire data through SSI mechanisms for filling in a form for a specific kind of transaction, the Data Collector needs to know what kinds of credentials it should ask for, which Parties its Owner trusts to issue such credentials, what kinds of verification proofs for such credentials must hold and which may be disregarded.[^3] Also, when the Data Collector gets a credential that satisfies the necessary verification proofs, it needs a way to map the contents of that credential to the structure of the transaction context that is used internally by (other systems of) its Owner.[^4] Also, as the Data Collector gets more and more data - which it may get through multiple, different channels - it needs to determine whether or not the resulting set is sufficiently consistent and coherent.[^5]
+In order to acquire data through SSI mechanisms for filling in a form for a specific kind of transaction, the Data Collector needs to know what kinds of credentials it should ask for, which Parties its Principal trusts to issue such credentials, what kinds of verification proofs for such credentials must hold and which may be disregarded.[^3] Also, when the Data Collector gets a credential that satisfies the necessary verification proofs, it needs a way to map the contents of that credential to the structure of the transaction context that is used internally by (other systems of) its Principal.[^4] Also, as the Data Collector gets more and more data - which it may get through multiple, different channels - it needs to determine whether or not the resulting set is sufficiently consistent and coherent.[^5]
 
-In order to make the Data Collector work, a Validation Policy (or Data Collector Policy) is created by, or on behalf of the Owner, which specifies at least:
+In order to make the Data Collector work, a Validation Policy (or Data Collector Policy) is created by, or on behalf of its Principal, which specifies at least:
 
--   the kinds of transactions the Owner is willing to (electronically) engage in, from both the requester and the provider perspectives;
+-   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 kinds of credentials and issuers that the Owner 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].
+    -   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].
 
     -   for each kind of credential: the verification proofs that must hold to be accepted as a source for valid data.
 
@@ -75,9 +75,9 @@ In order to make the Data Collector work, a Validation Policy (or Data Collector
 
 The Policy must be designed in such a way that it is extendable as new features will be called for in the future.
 
-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 Owner 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 Owner.[^7]
+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 Owner 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’.
 
@@ -98,9 +98,9 @@ TNO to revise the footnote markers
 
 [^2]: It may well be that this functionality can somehow be split off in the (near) future.
 
-[^3]: For high-value transactions, verification proofs are more important than for low-value transactions. This is to be decided by the Owner 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.
+[^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 Owner 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 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.
 
diff --git a/docs/terms/data-discloser.md b/docs/terms/data-discloser.md
index 39eee09ef037c278c686e88605af23110578883f..a24c00defe14a1ea57ef59ff055e034bd3146c86 100644
--- a/docs/terms/data-discloser.md
+++ b/docs/terms/data-discloser.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: data-discloser
 stage: draft
-hoverText: "Data Discloser: a functional component that is capable of disclosing data."
+hoverText: "Data Discloser: a functional component that is capable of disclosing data to (Agents of) other Parties, e.g. in the form of Credentials."
 ---
 
 ### Short Description
@@ -19,7 +19,7 @@ The Data Discloser uses a %%data-collector-policy|data-collector-policy%% to lea
 The Data Discloser uses the %%eSSIF-Glue|essif-glue%% interface to access the %%Wallet|wallet%%, %%Holder|holder%%, %%Issuer|issuer%% and %%Verifier|verifier%% functionalities.
 
 ### Purpose
-The purpose of the Data Discloser component is to state the (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other Parties. A special kind of result is the (provisioning of) a credential that its Owner already has created.
+The purpose of the Data Discloser component is to state the (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other Parties. A special kind of result is the (provisioning of) a credential that its Principal already has created.
 
 ### Criteria
 A **Data Discloser** is a component in the [eSSIF-Lab functional architecture](../functional-architecture) that is capable of stating (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other %%Parties|party%%.
diff --git a/docs/terms/definition.md b/docs/terms/definition.md
index f49c33ce955e0fc56a144bc7c3609a94417f0849..26e604600ac359183a1803925c0b659ec5848bf9 100644
--- a/docs/terms/definition.md
+++ b/docs/terms/definition.md
@@ -5,13 +5,15 @@ scopeid: essifLabTerminology
 type: concept
 typeid: definition
 stage: draft
-hoverText: "Definition: a text that helps Parties deeply/truly understand the meaning of, or Concepts behind, a Term."
+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."
 ---
 
 ### Short Description
 <!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
 A **Definition** is a text that helps %%parties|party%% truly understand the meaning of a %%term|term%% as it is used in a communication. Because [terms are scoped](terminology), this 'truly understanding' of one another isn't trivial. Therefore, we insist that the explanatory text be a criterion that %%parties|party%% are expected to use in the same way in some %%scope(s)|scope%%, allowing them to establish whether or not they make the same determination as to whether or not something qualifies to be refered to by that term in a way that is independent of whether or not the (alledged) meaning is relevant for the purposes they pursue within that scope.
 
+The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
+
 ### Purpose
 <!--Describe why the concept is needed. What purposes does it serve? What can you do with it that you cannot do (as well) without it? What objectives does it help realize? Why is this conceptevant within its scope of definition?-->
 Working together is easier when you and your peers share the same ideas. We need a way to test and ensure, that you and your peers _actually_ have the same understanding, for the purpose of making cooperation easier. Doing so is expected to not only reduce the number of terminological discussions, but also improve the efficiency and effectiveness of the remaining discussions.
@@ -37,9 +39,6 @@ Entity that comprises at a minimum:
 
 * %%Mental(or Conceptual) Model|pattern%% is a collection of concepts, relations between such concepts, and constraint rules that (elements of) such concepts and relations must satisfy. Such [models](https://en.wikipedia.org/wiki/Conceptual_model) are used to help people know, understand, or simulate a subject the model represents.
 
-### Background
-The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
-
 ### Use-cases
 <!--This (optional) section specifies an (optional) introductory paragraph, and a level-3 (i.e. `###`) subsection for every use case it describes. Every such use-case SHOULD
 - describe the situation/context of the use-case;
diff --git a/docs/terms/dependent.md b/docs/terms/dependent.md
index 0717c181100eea57c852c476ea5024e602c19ce7..2aa5cd94d6c2fb25b34ed22270ab32481b70d123 100644
--- a/docs/terms/dependent.md
+++ b/docs/terms/dependent.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 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."
+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."
 ---
 
 :::info Editor's Note
@@ -14,9 +14,8 @@ TNO to revise all below texts.
 
 ### Short Description
 
+The %%Guardianship pattern|pattern-guardianship%% provides an overview of how this concept fits in with related concepts.
+
 ### Purpose
 
 ### Criteria
-
-### Background
-The %%Guardianship pattern|pattern-guardianship%% provides an overview of how this concept fits in with related concepts.
\ No newline at end of file
diff --git a/docs/terms/dictionary-file.md b/docs/terms/dictionary-file.md
index 00c5c96cf915651e29ec2953c2e9927a1999bba2..a2064b7af3ab5d2022d93bc76348d4cc572300be 100644
--- a/docs/terms/dictionary-file.md
+++ b/docs/terms/dictionary-file.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 type: dictionary
 typeid: dictionary-file
 stage: draft
-hoverText: "Dictionary-file: a file that specifies the contents of a Dictionary."
+hoverText: "Dictionary-file: a file whose contents specifies the contents of a Dictionary."
 ---
 
 ### Short Description
diff --git a/docs/terms/dictionary.md b/docs/terms/dictionary.md
index 0a2cc2a81a6435a2f48933c2b17b241f9fd1fb4b..23aa5ed1d3cffc6c958fa912fbdb0607b62f134e 100644
--- a/docs/terms/dictionary.md
+++ b/docs/terms/dictionary.md
@@ -12,6 +12,8 @@ hoverText: "Dictionary: an alphabetically sorted list of Terms with various mean
 <!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
 A Dictionary is an alphabetically sorted list of terms and explanations. Each term may have multiple such explanations, which come from different %%scopes/contexts|scope%%. 
 
+The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
+
 ### Purpose
 <!--Describe why the concept is needed. What purposes does it serve? What can you do with it that you cannot do (as well) without it? What objectives does it help realize? Why is this conceptevant within its scope of definition?-->
 A dictionary helps people to get introduced in the domain for which the dictionary is created. Usually, this is a larger domain e.g. of some language, or about computer security.
@@ -29,9 +31,6 @@ Examples include the [NIST Computer Security Resource Center](https://csrc.nist.
 - %%Glossary|glossary%% - this is a list of words with a single meaning, that serves more specific purposes than a dictionary.
 - [Vocabulary](https://en.wikipedia.org/wiki/Vocabulary) - this is a set of familiar words witin a particular/persons's language or field of expertise. A Dictionary can provide the various meanings of each such words.
 
-### Background
-The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
-
 ### Notes
 <!--This (optional) section is the place to put anything for which there is no other good place to put it.-->
 
diff --git a/docs/terms/digital-policy.md b/docs/terms/digital-policy.md
index 3b8134ec1107b925acac56995e2022f6a065a82f..4a176501891fa20bbb253ce3534d7f215845b2a4 100644
--- a/docs/terms/digital-policy.md
+++ b/docs/terms/digital-policy.md
@@ -6,9 +6,13 @@ type: concept
 typeid: digital-policy
 conceptref: ":Policy"
 stage: draft
-hoverText: "Digital Policy: a machine-readable Policy (i.e. a file that contains rules, working-instructions, preferences and other guidance for Agents that can interpret such documents, so as to enable them to execute Actions on behalf of the Policy's Governor)."
+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)."
 ---
 
+:::info Editor's note
+TNO (or others) to provide further content of this file.
+:::
+
 ### Short Description
 A **digital policy** is an artifact that is derived from, and represents, a %%policy|policy%% for the purpose of being useable in the digital realm.
 
diff --git a/docs/terms/eSSIFLab-scope.md b/docs/terms/eSSIFLab-scope.md
index d06c08c802f6b823dbb234ac58d9fa81f57b3bba..6b5d8cce372a91559dfcf1a87e3d119f26c63509 100644
--- a/docs/terms/eSSIFLab-scope.md
+++ b/docs/terms/eSSIFLab-scope.md
@@ -28,19 +28,3 @@ The Concepts and Terminology part of eSSIF-Lab aims helps eSSIF-Lab community pa
 
 ### Background
 The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
-
-### Notes
-<!--Anything els that's worth mentioning.-->
-
-### Tags
-<!--Add hash tags here that allow us to group concepts in useful ways.-->
-
-<!--
----
-### Footnotes
-
-[//]: # This (optional) section contains any footnotes that may have been specified in the text above.
-
-[^1]: the text for footnote [^1] goes here.
-
--->
diff --git a/docs/terms/employee.md b/docs/terms/employee.md
index 902f97c6fa09b049bda6fbcdd0131d7d1808b939..e0be130de895463852c7adbd9d47f3c1f3826087 100644
--- a/docs/terms/employee.md
+++ b/docs/terms/employee.md
@@ -12,7 +12,10 @@ hoverText: "Employee (of a Party): an Actor for whom/which it is realistic that
 TNO (or others) to provide the content of this file.
 :::
 
-### Background
+### Short Description
+
 The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
 
-### Related Concepts
+### Purpose
+
+### Criteria
diff --git a/docs/terms/employer.md b/docs/terms/employer.md
index e86dd9d96f2f47db6f393067b06b9dfb33d86ba7..e06937b52f7ca160d440ca878534c1884141f381 100644
--- a/docs/terms/employer.md
+++ b/docs/terms/employer.md
@@ -5,14 +5,17 @@ scopeid: essifLab
 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 Ations."
+hoverText: "Employer (of an Actor): a Party on whose behalf this Actor (called an Employee of that Party) might execute Actions."
 ---
 
 :::info Editor's note
 TNO (or others) to provide the content of this file.
 :::
 
-### Background
+### Short Description
+
 The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
 
-### Related Concepts
+### Purpose
+
+### Criteria
diff --git a/docs/terms/entity.md b/docs/terms/entity.md
index 6e5dd3c68d24dbf4697a338cf9a7aa068bef8bc1..ef44162b0498cf0a681ddac26b02763a9149151f 100644
--- a/docs/terms/entity.md
+++ b/docs/terms/entity.md
@@ -11,6 +11,8 @@ hoverText: "Entity: something that is known to exist."
 ### Short Description
 Whenever you know that somethings exists, be it another person, yourself, some computer, an extinct animal, a thought, an idea, a JSON-object, ..., _anything_ you can think of, is what the term **Entity** refers to.
 
+The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
+
 ### Purpose
 This term enables us to refer to anything, or to postulate the existence of something, without further specifying what it is, or how it might be named. 
 
@@ -19,6 +21,3 @@ Something, anything, that some %%party|party%% knows to exist
 
 ### Related Concepts
 - a %%legal entity|legal-entity%% is an entity that is known by (i.e. registered in the %%knowledge|knowledge%% of) a %%party|party%% that operates the %%legal system|legal-system%% of a %%jurisdiction|jurisdiction%%. (Details are in the %%Jurisdictions pattern|pattern-jurisdiction%%)
-
-### Background
-The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
diff --git a/docs/terms/glossary-file.md b/docs/terms/glossary-file.md
index 3fde8a92911523808262a0d9fc3c377391c6109f..24ee10ba18c04d54c137edec9250dc73872dc920 100644
--- a/docs/terms/glossary-file.md
+++ b/docs/terms/glossary-file.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 type: glossary
 typeid: glossary-file
 stage: draft
-hoverText: "Glossary-file: a file that defines/specifies a Glossary."
+hoverText: "Glossary-file: a file whose contents defines/specifies a Glossary."
 ---
 
 ### Short Description
diff --git a/docs/terms/glossary.md b/docs/terms/glossary.md
index 10384815940b61220539305294c53c2a1ddd5500..c28430eaefcdc1040acc4e6c9d33d58d7e7a4877 100644
--- a/docs/terms/glossary.md
+++ b/docs/terms/glossary.md
@@ -9,39 +9,22 @@ hoverText: "Glossary: an alphabetically sorted list of Terms with the (single) m
 ---
 
 ### Short Description
-<!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
 A **glossary** is an alphabetically sorted list of %%terms|term%% with explanations, usually aimed to help people understand texts around a certain (set of) topic(s) in (at least) one context. A glossary may also be created for the purpose of being included in other glossaries (as a construction aid to such glossaries), or for still other purposes.
 
+The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
+
 ### Purpose
-<!--Describe why the concept is needed. What purposes does it serve? What can you do with it that you cannot do (as well) without it? What objectives does it help realize? Why is this conceptevant within its scope of definition?-->
 A glossary may serve various purposes, the most important one of which would be to help people understand texts around a certain (set of) topic(s) in some context(s).
 
 ### Criteria
-<!--REQUIRED--How is this concept different from related ideas? What are essential characteristics that must be true? This is where you specify the [intensional definition](https://en.wikipedia.org/wiki/Extensional_and_intensional_definitions) of the concept, i.e. the necessary and sufficient conditions for when the term should be used. This makes that the conceptomes crystal clear. In the case of nouns, this is equivalent to specifying the properties that an object needs to have in order to be counted as a referent of the term.-->
 A **glossary** is an alphabetical list of words or phrases with (short) explanations, that exists for the purpose of helping people to get a first understanding of the meaning of each word in the scope/context for which the glossary is created.
 
 ### Examples
-<!--This (optional) section contains examples, both of what satisfies the definition (and hence qualifies as an instance of Glossary), ans what does not. If you can think of examples for which the criterion may not (always) work, then describe them, too, and inform the reader why this hasn't affected the definition (yet) - e.g. because such cases are irrelevant to the scope within which the term is defined.-->
 Examples include the [eSSIF-Lab Glossary](../essifLab-glossary), the [Sovrin Glossary](https://sovrin.org/library/glossary/), the [Glossary of Internet Terms](https://www.internetsociety.org/internet/glossary-internet-terms/), and glossaries for Legal Terms, e.g. of the [US](https://www.uscourts.gov/glossary), [Singapore](https://www.supremecourt.gov.sg/services/self-help-services/glossary-of-terms), the [UK](https://www.copfs.gov.uk/involved-in-a-case/glossary-of-legal-terms).
 
 ### Related Concepts
-<!--This (optional) section lists words/phrases that are encountered in other contexts that have the same or a sufficiently similar meaning as Glossary. In this section you may point out the (subtle) differences between Glossary and this related terminology. This helps readers better/deeper understand Glossary, and how it may be used to relate to existing texts. Ideally, such references are accompanied with links to (preferredly authoritative) sources.-->
 - %%Dictionary|dictionary%% - this is more extensive; it usually includes multiple meanings of words, and may include additional information e.g. on pronunciation, etymology, usage, example sentences,synonyms, etc. See [askdifference.com](https://www.askdifference.com/dictionary-vs-glossary/)
 - [Vocabulary](https://en.wikipedia.org/wiki/Vocabulary) - this is a set of familiar words witin a particular/persons's language or field of expertise. A Dictionary can provide the various meanings of each such words.
 
-### Background
-The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
-
 ### Notes
-<!--This (optional) section is the place to put anything for which there is no other good place to put it.-->
-The [eSSIF-Lab Glossary](../essifLab-glossary) contains the words that are defined within the scope of the [eSSIF-Lab framework](../project).
-
-<!--
----
-### Footnotes
-
-[//]: # This (optional) section contains any footnotes that may have been specified in the text above.
-
-[^1]: the text for footnote [^1] goes here.
-
--->
\ No newline at end of file
+The [eSSIF-Lab Glossary](../essifLab-glossary) contains the words that are defined within the scope of the [eSSIF-Lab framework](../project).
\ No newline at end of file
diff --git a/docs/terms/governance.md b/docs/terms/governance.md
index 209a02f7920539277d32273a1a7afd794cc017e2..f82ed11367ef8090561e3968b3d479ad03d42da3 100644
--- a/docs/terms/governance.md
+++ b/docs/terms/governance.md
@@ -15,14 +15,13 @@ As %%parties|party%% interact with one another, i.e. conduct %%business transact
 
 Within eSSIF-Lab, governance is pretty much limited to the governance of various %%policies|policy%%.
 
+The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
+
 ### Purpose
 The purpose for a %%party|party%% of having a **governance** process is that it enables him to reflect on the ways that it makes decisions. A typical topic for governance is the maintenance of the set of rules, working-instructions, preferences and other guidance that %%actors|actor%% are supposed, or required to use when executing specific %%actions|action%% on behalf of that %%party|party%%. 
 
 For %%digital-actors|digital-actor%% such guidance consists of %%digital policies|digital-policy%%. A %%party|party%% whose governance process maintains a %%policy|policy%% will be called the %%governor|policy-governor%% of that policy.
 
-### Background
-The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
-
 ### Related Concepts
 - %%Governance|governance%%
 - %%Governor|policy-governor%%
diff --git a/docs/terms/governor.md b/docs/terms/governor.md
new file mode 100644
index 0000000000000000000000000000000000000000..c5b8a4f7a7751fd2e004ff660cb6a6fbf58c710b
--- /dev/null
+++ b/docs/terms/governor.md
@@ -0,0 +1,14 @@
+---
+id: governor
+title: "Governor"
+scopeid: essifLab
+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."
+---
+
+### Short Description
+A **Governor** is a name used to refer to a Party that is governing or overseeing the control and direction of something. 
+
+See %%governance|governance%%
\ No newline at end of file
diff --git a/docs/terms/guardian.md b/docs/terms/guardian.md
index 1f31731d60de499c5a7743ebe51a8a6fec4b2ff5..8f3731a666a5ae2e9e9303c82460baedd92a9a38 100644
--- a/docs/terms/guardian.md
+++ b/docs/terms/guardian.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 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."
+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."
 ---
 
 :::info Editor's Note
@@ -14,9 +14,8 @@ TNO to revise all below texts.
 
 ### Short Description
 
+The %%Guardianship pattern|pattern-guardianship%% provides an overview of how this concept fits in with related concepts.
+
 ### Purpose
 
 ### Criteria
-
-### Background
-The %%Guardianship pattern|pattern-guardianship%% provides an overview of how this concept fits in with related concepts.
\ No newline at end of file
diff --git a/docs/terms/guardianship-type.md b/docs/terms/guardianship-type.md
index 74b2f0380490dea26d123245aa28b6d298761a62..8833643a314ac7bdf03074bf67eda80a79f620ec 100644
--- a/docs/terms/guardianship-type.md
+++ b/docs/terms/guardianship-type.md
@@ -13,11 +13,10 @@ A **Guardianship-type** is a class of %%guardianship relationships|guardianship%
 
 A good way to think abouat a %%guardianship-type|guardianship-type%% is to see it as a template from which instances - i.e. actual %%guardianship relationships|guardianship%% can be derived.
 
+The %%Guardianship pattern|pattern-guardianship%% provides an overview of how this concept fits in with related concepts.
+
 ### Purpose
 A **Guardianship-type** serves as a template from which instances - i.e. actual %%guardianship relationships|guardianship%% can be derived. It allows the %%jurisdiction|jurisdiction%% within which it is defined to specify generic %%duties and rights|pattern-duties-and-rights%%, both for the %%guardian|guardian%% and the %%dependent|dependent%% in (instantiated) %%guardianship relationships|guardianship%%, without knowing which %%entities|entity%% will be(come) the %%guardian|guardian%% or the %%dependent|dependent%%.
 
 ### Criteria
 An **guardianship-type** is a class of %%guardianship-relationships|guardianship%% that comprises a (non-empty) set of %%duty/right types|pattern-duties-and-rights%% for at least the %%guardian|guardian%% and/or the %%dependent|dependent%% (and perhaps other roles), the semantics of which are defined by the %%jurisdiction|jurisdiction%%.
-
-### Background
-The %%Guardianship pattern|pattern-guardianship%% provides an overview of how this concept fits in with related concepts.
\ No newline at end of file
diff --git a/docs/terms/guardianship.md b/docs/terms/guardianship.md
index b295780cef37f3e2ae215e7b2d1fa12acc97e3c8..5d19403d2589647ce156f75a8b947a26a17bb3d3 100644
--- a/docs/terms/guardianship.md
+++ b/docs/terms/guardianship.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: guardianship
 stage: draft
-hoverText: "Guardianship (of a one 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."
+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."
 ---
 
 :::info Editor's Note
@@ -19,6 +19,8 @@ in which one of these %%entities|entity%% (called the %%owner|owner%%) is entitl
 
 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%%'.
 
+The %%Guardianship pattern|pattern-guardianship%% provides an overview of how this concept fits in with related concepts.
+
 ### Purpose
 **Guardianship** is a means by which %%jurisdictions|jurisdiction%% provide assurances to %%parties|party%% (within its scope) that they can enjoy, dispose of and control in pretty much any way they like. The %%legal system|legal-system%% of the %%jurisdiction|jurisdiction%% specifies these rights, and provides ways in which the %%owner|owner%% can exercize them (that provides the assurance).
 
@@ -30,7 +32,4 @@ An **guardianship** is a relationship between two %%legal entities|legal-entity%
 - %%Owned|owned%%
 
 ### Notes
-- Owning something does not imply posessing it (and vice versa). For example, if you find a coin that doesn't belong to you, you possess it but do not own it. Also, its rightful owner obviously owns it, but doesn't possess it at that point in time.
-
-### Background
-The %%Guardianship pattern|pattern-guardianship%% provides an overview of how this concept fits in with related concepts.
\ No newline at end of file
+- Owning something does not imply posessing it (and vice versa). For example, if you find a coin that doesn't belong to you, you possess it but do not own it. Also, its rightful owner obviously owns it, but doesn't possess it at that point in time.
\ No newline at end of file
diff --git a/docs/terms/holder.md b/docs/terms/holder.md
index 03bb436f2b0fb8cf2a4ade5afd0bc3d1c5bf3d6b..ad51cecafc3ba6ca745165cb05aeba2acd7ede2c 100644
--- a/docs/terms/holder.md
+++ b/docs/terms/holder.md
@@ -9,7 +9,7 @@ hoverText: "Holder (functional component): the capability to handle presentation
 ---
 
 ### 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 Owner’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.
@@ -25,11 +25,11 @@ A **Holder** is a component in the [eSSIF-Lab functional architecture](../functi
 
 Typically, a Holder component would access its %%owner|owner%%'s Wallet to check if it has a credential that it can use to construct a Presentation (i.e. response) that satisfies the received request.
 
-It may happen that the Wallet does not have such a credential. However, for every (credential, issuer) pair, the request should specify the URI that is capable of issuing such a credential. If or when the Holder Policy/Preferences permit this, the Holder then requests its Owner’s Transaction Data Collector to initiate a new transaction that will get the credential from that issuer, for which a clean transaction form would then consist of one that contains said credential. The Holder would then store it in its Owner’s Wallet, and then proceed to service the presentation request as if it had obtained that credential from its Owner’s Wallet.
+It may 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 the Owner, which specifies e.g.:
+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.:
 
 -   whether or not credentials may be collected ‘on the fly’;
 -   how to choose between credentials that all satisfy a presentation request (and whether the Holder can make such choices by itself, or whether or not human interaction is required);
diff --git a/docs/terms/identifier.md b/docs/terms/identifier.md
index 5098a7239664a5df27d872a3aefb25d120cae994..0d69e2009fad8880153fa18c99d4edfb3ec9e9ff 100644
--- a/docs/terms/identifier.md
+++ b/docs/terms/identifier.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: identifier
 stage: draft
-hoverText: "Identifier: a character string that is being used for identification purposes (yet may refer to 0, 1, or more Entities, depending on the context within which it is being used)."
+hoverText: "Identifier: a character string that is being used for the identification of some Entity (yet may refer to 0, 1, or more Entities, depending on the context within which it is being used)."
 ---
 
 ### Short Description
diff --git a/docs/terms/issuer.md b/docs/terms/issuer.md
index da04476406791880ec0f514cdcbbe277abff17ff..fe9c87872f3c863c255ef24c4e577282b960e38f 100644
--- a/docs/terms/issuer.md
+++ b/docs/terms/issuer.md
@@ -29,7 +29,7 @@ The purpose of the Issuer component is to issue ‘credentials’, i.e. digital
 -   metadata (e.g. type of credential, date of issuing and expiration, endpoints, e.g. for revocation checking, credential definition, credential advertisements, credential enforcement policy, etc.)
 -   proofs (e.g. a digital signature by which third %%parties|party%% can prove its provenance and integrity.
 
-Another purpose that an Issuer might serve is to provide a means that allows any other Agent that somehow has obtained a copy or presentation of a credential, to verify whether or not the data therein is conformant to the business administration of its Owner. We will use the term ‘revocation service’ to refer to such means. Whether or not an Issuer provides such a service, and what kind of revocation service is provided (e.g. a revocation list, an online revocation status protocol, etc.), is a decision that its Owner should make, and specify in the Issuer Policies/Preferences.
+Another purpose that an Issuer might serve is to provide a means that allows any other Agent that somehow has obtained a copy or presentation of a credential, to verify whether or not the data therein is conformant to the business administration of its Principal. We will use the term ‘revocation service’ to refer to such means. Whether or not an Issuer provides such a service, and what kind of revocation service is provided (e.g. a revocation list, an online revocation status protocol, etc.), is a decision that its Principal should make, and specify in the Issuer Policies/Preferences.
 
 An Issuer component may issue credentials in various formats, e.g. as a Verifiable Credential (VC), an Attribute-Based Credential (ABC), an OpenID Connect/JWT token, etc. The issuing %%party|party%% must specify credential-types in such a way that if the same credential is issued in different formats, it is possible for an arbitrary %%verifier|verifier%% to determine whether or not two credentials that have different formats, are in fact the same. One way of doing this is that the Issuer generates an identifier for every credential that it constructs (before expressing it in a specific format).
 
diff --git a/docs/terms/jurisdiction.md b/docs/terms/jurisdiction.md
index 893183e66e97746ba3b66a0dafe8d696b2714c69..26f188702ed870621989ec3af40f65c06fb7e32a 100644
--- a/docs/terms/jurisdiction.md
+++ b/docs/terms/jurisdiction.md
@@ -5,39 +5,19 @@ scopeid: essifLab
 type: concept
 typeid: jurisdiction
 stage: draft
-hoverText: "Jurisdiction: a Legal System (legislation, enforcement thereof, and conflict resolution) that is governed by a Party in a certain Scope."
+hoverText: "Jurisdiction: the composition of a Legal System (legislation, enforcement thereof, and conflict resolution), a Party that governs that Legal System, a scope within which that Legal System is operational, and one or more Objectives for the purpose of which the Legal System is operated."
 ---
 
 ### Short Description
-<!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
-A **Jurisdiction** is the composition of one %%scope|scope%%, one %%legal system|legal-system%% and one %%party|party%% (called the %%Governor of the Jurisdiction|jurisdiction-governor%%) that operates the legal system within that scope. While most people are familiar with what we call %%legal jurisdictions|legal-jurisdiction%%, please observe that %%organizations|organization%% habitually will have rules (business policies) in place, enforce them (to some extent), and have ways of resolving conflicts, and therefore qualify as a jurisdiction. Specifically, multi-national organizations are known to govern multiple jurisdictions, aliging the scopes with the scopes of other (often legal) jurisdictions for the purpose of preventing situations in which conflicting rules apply, which would lead to many effort-intensive conflict-resolution cases.
+A **Jurisdiction** is the composition of a (non-empty) set of %%objectives|objective%%, one %%scope|scope%%, one %%legal system|legal-system%% and one %%party|party%% (called the %%Governor of the Jurisdiction|jurisdiction-governor%%) that operates the legal system within that scope. While most people are familiar with what we call %%legal jurisdictions|legal-jurisdiction%%, please observe that %%organizations|organization%% habitually will have rules (business policies) in place, enforce them (to some extent), and have ways of resolving conflicts, and therefore qualify as a jurisdiction. Specifically, multi-national organizations are known to govern multiple jurisdictions, aliging the scopes with the scopes of other (often legal) jurisdictions for the purpose of preventing situations in which conflicting rules apply, which would lead to many effort-intensive conflict-resolution cases.
+
+The %%Jurisdictions pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts.
 
 ### Purpose
-<!--Describe why the concept is needed. What purposes does it serve? What can you do with it that you cannot do (as well) without it? What objectives does it help realize? Why is this concept relevant within its scope of definition?-->
 The ability to distinguish between (non)jurisdictions is a very generic enabler for us to tell which rules (laws, policies, guidelines, etc.) will apply in which situations, which %%party|party%% governs and enforces these rules, and where we should look to resolve any conflicts.
 
 ### Criteria
 the composition of one %%scope|scope%%, one %%legal system|legal-system%% and one %%party|party%% that operates the legal system within that scope.
 
-### Examples
-<!--Provide a few sentences in which you give examples that obviously qualify as instances of `<New Term>`, and that do NOT obviously qualify. Also, provide examples that are not (so) obvious, but help users to better understand its intension.-->
-
-### Related Concepts
-<!--Link to any concepts that are similar but distinct, with a note about the relationship.-->
-
-### Background
-<!--Mention and link to the patterns in which this concept plays a (significant) role (possibly explaining the reason/purpose if appropriate), e.g.: -->
-The %%Jurisdictions pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts.
-
 ### Notes
 The case can be made for Nature to qualify as a jurisdiction, postulating that this jurisdiction has a universal scope, its %%party|party%% would be 'Nature' itself (which can be argued to qualify as a %%party|party%%), and the %%legal system|legal-system%% that Nature operates are the 'laws of nature' (which Nature defines, enforces and settles disputes in). If one adopts this view, then people become (natural) %%owners|owner%% of e.g. %%assertions|assertion%%, their %%knowledge|knowledge%% etc. Also, natural resources (e.g. rivers) would be %%legal entities|legal-entity%% in that jurisdiction, since they are 'known, and recognized to exist' by Nature.
-
-<!--
----
-### Footnotes
-
-[//]: # This (optional) section contains any footnotes that may have been specified in the text above.
-
-[^1]: the text for footnote [^1] goes here.
-
--->
diff --git a/docs/terms/legal-entity.md b/docs/terms/legal-entity.md
index eb3090041b5d81216575d4bdafa92403d2589633..dc21ca10b854b193c4155b59dc4304635cdc2d57 100644
--- a/docs/terms/legal-entity.md
+++ b/docs/terms/legal-entity.md
@@ -5,13 +5,15 @@ scopeid: essifLab
 type: term
 typeid: legal-entity
 stage: draft
-hoverText: "Legal-entity: an Entity that is known by and recognized to exist in a Jurisdiction."
+hoverText: "Legal Entity (of a Jurisdiction): an Entity that is known by, recognized to exist, and registered in that Jurisdiction."
 ---
 
 ### Short Description
 <!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
 A **Legal Entity** is an %%entity|entity%% that is known by and recognized to exist in a %%jurisdiction|jurisdiction%%. For %%legal jurisdictions|legal-jurisdiction%%, this usually means that the entity is registered. Legal jurisdictions usually have a registration for its citizens, foreigners, enterprises, fellonies, etc. Non-legal jurisdictions (e.g. a soccer club) register their members, donators, staff, properties, etc., either on the record, or off the record.
 
+The %%Jurisdictions pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts.
+
 ### Purpose
 <!--Describe why the concept is needed. What purposes does it serve? What can you do with it that you cannot do (as well) without it? What objectives does it help realize? Why is this concept relevant within its scope of definition?-->
 It is important to recognize that the term 'legal entity' does not refer to something that has an existence of its own, but that it is a property of en %%entity|entity%% that is linked to a %%jurisdiction|jurisdiction%%. This enables us to query for the applicable jurisdiction when someone uses the term, and get the right understanding of what (s)he means.
@@ -24,7 +26,3 @@ A **Legal Entity** is an %%entity|entity%% that is known by and recognized to ex
 - citizens (organizations, etc.) that are registered in the citizens registration of some government, are legal entities in its jurisdiction.
 - a refugee that is screaming before a civil servant person (i.e. (s)he is alive and kicking, and really exists), yet is not registered in the governmental administration, does not exist for that administration, i.e. is not a legal entity in that jurisdiction.
 - whether or not some special stone qualifies as legal entity depends on whether or not it is known to exist in some jurisdiction.
-
-### Background
-<!--Mention and link to the patterns in which this concept plays a (significant) role (possibly explaining the reason/purpose if appropriate), e.g.: -->
-The %%Jurisdictions pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts.
diff --git a/docs/terms/legal-jurisdiction.md b/docs/terms/legal-jurisdiction.md
index 027dcd8ebe27b43c91db3c8a3af44db21e21c1ae..300af1418d867b2169aff22741dd18eefb6399e5 100644
--- a/docs/terms/legal-jurisdiction.md
+++ b/docs/terms/legal-jurisdiction.md
@@ -9,10 +9,14 @@ stage: draft
 hoverText: "Legal Jurisdiction: a Jurisdiction that is governed/operated by a governmental body."
 ---
 
-### Purpose
-<!--Describe why the concept is needed. What purposes does it serve? What can you do with it that you cannot do (as well) without it? What objectives does it help realize? Why is this concept relevant within its scope of definition?-->
-We need the term **legal jurisdiction** because it is common practice for people and organizations to explicitly want to comply with applicable laws and regulations, where it is explicitly implied that these are the rules of a legal system that is governed by a governmental body. Introducing this term allows us to both generically reason about %%jurisdictions|jurisdiction%% (which is helpful to design e.g. SSI infrastructure) and also communicate about jurisdictions that have a governmental (legal) status.
+### Short Description
+
+::: Editor's note
+TNO to provide further context
+:::
 
-### Background
-<!--Mention and link to the patterns in which this concept plays a (significant) role (possibly explaining the reason/purpose if appropriate), e.g.: -->
 The %%Jurisdictions pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts.
+
+### Purpose
+<!--Describe why the concept is needed. What purposes does it serve? What can you do with it that you cannot do (as well) without it? What objectives does it help realize? Why is this concept relevant within its scope of definition?-->
+We need the term **legal jurisdiction** because it is common practice for people and organizations to explicitly want to comply with applicable laws and regulations, where it is explicitly implied that these are the rules of a legal system that is governed by a governmental body. Introducing this term allows us to both generically reason about %%jurisdictions|jurisdiction%% (which is helpful to design e.g. SSI infrastructure) and also communicate about jurisdictions that have a governmental (legal) status.
\ No newline at end of file
diff --git a/docs/terms/legal-system.md b/docs/terms/legal-system.md
index dd662b624f004cdaedfdf2a288a2f4f2ab8a52b9..53ba59ce92875505e6662748367bd847a2f4a737 100644
--- a/docs/terms/legal-system.md
+++ b/docs/terms/legal-system.md
@@ -9,25 +9,20 @@ hoverText: "Legal-system: a system in which rules are defined, and mechanisms fo
 ---
 
 ### Short Description
-<!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
 A **Legal System** is a system in which rules are defined ([legislature](https://en.wikipedia.org/wiki/Legislature)) and a mechanism for their enforcement is implicitly or explicitly defined ([executive](https://en.wikipedia.org/wiki/Executive_(government))), as well as a mechanism for conflict resolution ([judiciary](https://en.wikipedia.org/wiki/Judiciary)). A legal system is designed and governed by a single %%party|party%%. A legal system can be operationalized by assigning it a scope within which enforcement and conflict resolution are implemented. The associated operational tasks may be mandated or delegated to other %%parties|party%%. Depending on the individual legal system, ‘rules’ may be called ‘laws’, ‘regulations’, ‘directives’, ‘policies’, ‘working instructions’, etc. Other terms exist for specializations of these terms, e.g. ‘order’, ‘mandate’, and others.
 
+The %%Jurisdictions pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts.
+
 ### Purpose
-<!--Describe why the concept is needed. What purposes does it serve? What can you do with it that you cannot do (as well) without it? What objectives does it help realize? Why is this concept relevant within its scope of definition?-->
 The ability to distinguish between (non)legal-systems is a very generic enabler to tell which rules (laws, policies, guidelines, etc.) will apply within its %%scope|scope%%, as well as to evaluate the risks that we run when not complying with the rules. Conversely, the %%party|party%% that operates a legal system may provide additional rules to help mitigate such risks.
 
 ### Criteria
 A system in which rules are defined ([legislature](https://en.wikipedia.org/wiki/Legislature)), can be enforced ([executive](https://en.wikipedia.org/wiki/Executive_(government))), and a mechanism is defined to resolve conflicts ([judiciary](https://en.wikipedia.org/wiki/Judiciary)).
 
 ### Examples
-<!--Provide a few sentences in which you give examples that obviously qualify as instances of `<New Term>`, and that do NOT obviously qualify. Also, provide examples that are not (so) obvious, but help users to better understand its intension.-->
 - many nations have their own legal system (see e.g. [WikiPedia](https://en.wikipedia.org/wiki/List_of_national_legal_systems))
 - enterprises typically have at least one legal system, with policies or working instructions as their rules.
 - multi-nationals, NGO's etc. typically have multiple legal systems that are to be operated in different %%scopes|jurisdiction%% where such operations are subject to other, often %%legal jurisdictions|jurisdiction%%.
 - all sorts of associations, societies, clubs, unions would qualify as a jurisdiction.
 - families have a legal system, where the rules may or may not change regularly, enforcement may not always be consistent, and conflict resolution may be ad-hoc.
 - individual people can be said to have a legal system of their own, containing e.g. rules for ethics and morals.
-
-### Background
-<!--Mention and link to the patterns in which this concept plays a (significant) role (possibly explaining the reason/purpose if appropriate), e.g.: -->
-The %%Jurisdictions pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts.
\ No newline at end of file
diff --git a/docs/terms/owned.md b/docs/terms/owned.md
index 1f5ac0a024227a7f141949b5f1b1f2787be88aa8..1f583cb9cb078daff7ea951e5f4919422e07ad02 100644
--- a/docs/terms/owned.md
+++ b/docs/terms/owned.md
@@ -5,11 +5,13 @@ scopeid: essifLab
 type: concept
 typeid: owned
 stage: draft
-hoverText: "Owned (by an Owner, in some Jurisdiction): an Entity over which another Entity (its Owner) has the power to enjoy it, dispose of it and control it; the power is limited to (the scope of) that Jurisdiction."
+hoverText: "Owned (by an Owner, in some Jurisdiction): an Entity over which another Entity (its Owner) has the power (duty, right) to enjoy it, dispose of it and control it; that power is limited to (the scope of) that Jurisdiction, and by its rules."
 ---
 
 see: %%ownership|ownership%%
 
+Explain that the fact that the description does not preclude arbitrary Entities to be owners doesn't mean that arbitrary Entities can in fact be owners; that is up to (the Legal System of) the Jurisdiction to provide guidance for.
+
 ### Related Concepts
 - %%Ownership relation|ownership%%
 - %%Owner|owner%%
\ No newline at end of file
diff --git a/docs/terms/party.md b/docs/terms/party.md
index c0c3458529bf20c6c5ecf123901223218d93cb1a..828584226bc61968b174759e8434555becc3aeb3 100644
--- a/docs/terms/party.md
+++ b/docs/terms/party.md
@@ -5,12 +5,16 @@ scopeid: essifLab
 type: concept
 typeid: Party
 stage: draft
-hoverText: "Party: an Entity that has Objectives, Knowledge about what exists, rules that (should) apply, and some capability that allows it to reason, make decisions, generate and maintain Knowledge etc. in a Self-Sovereign fashion."
+hoverText: "Party: an Entity that has Objectives, Knowledge about what exists, rules that (should) apply, and some capability that allows it to reason, make decisions, generate and maintain Knowledge etc. in a Self-Sovereign fashion; Humans and Organizations ar the typical examples."
 ---
 
 ### Short Description
 A **party** is an %%entity|entity%% that pursues %%objectives|objective%%, and has his own, subjective, 'Self-Sovereign' %%knowledge|knowledge%% to help it realize these objectives. Perhaps one might also say: that have a mind of their own. Typical examples are individual people and %%organizations|organization%%. Their minds (subjective knowledge) are what distinguishes one %%party|party%% from another, so every %%party|party%% is 1-1 related to its knowledge (mind).
 
+The concept we know as 'party' serves a central role, and therefore occurs in various patterns, such as:
+- The %%Parties, Actors and Actions pattern|pattern-party-actor-action%%, which provides an overview of how this concept fits in with related concepts.
+- the %%Jurisdictions pattern|pattern-jurisdiction%%, which shows that a %%party|party%% can operate the %%legal system|legal-system%% of a %%jurisdiction|jurisdiction%%, enforcing the rules in some scopes to the %%(legal) entities|legal-entity%% that it knows to exist and to which these rules apply.
+
 ### Purpose
 It is in one's mind - with one's knowledge - that objectives are being set, strategies are being devised, decisions are being made and so on. Specifically, conducting %%business transactions|business-transaction%% requires making numerous decisions, each of which is based on a subjective argument. The evaluation of such an argument requires the acquisition and processing of data, which implies additional decisions (that provide assurances that evaluation will arrive at the right conclusion), such as establishing:
 - which data is required,
@@ -25,13 +29,12 @@ etcetera. For all of this, it is beneficial to introduce a concept that captures
 People obviously qualify. Enterprises, governments, and other organizations also qualify as they can be seen as having their own knowledge (e.g. in their registrations, databases etc.), ways to reason with that knowledge (business rules, exercised by their employees or IT systems), and making decision.
 
 Stones, pictures, ideas, etc. do not qualify. Also, electronic components do not qualify[^3].
-to be elaborated
 
-### Background
-<!--Mention and link to the patterns in which this concept plays a (significant) role (possibly explaining the reason/purpose if appropriate), e.g.: -->
-The concept we know as 'party' serves a central role, and therefore occurs in various patterns, such as:
-- The %%Parties, Actors and Actions pattern|pattern-party-actor-action%%, which provides an overview of how this concept fits in with related concepts.
-- the %%Jurisdictions pattern|pattern-jurisdiction%%, which shows that a %%party|party%% can operate the %%legal system|legal-system%% of a %%jurisdiction|jurisdiction%%, enforcing the rules in some scopes to the %%(legal) entities|legal-entity%% that it knows to exist and to which these rules apply.
+### Related Terms
+The term '[Identity Owner](https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit#heading=h.2e5lma3u6c9g)' (from the [Sovrin Glossary](https://sovrin.org/library/glossary/)) is quite similar for this term, as becomes apparent from its [Taxonomy of Entities](https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit#heading=h.mq7pzglc1j96). However, there it is defined as "_the subclassifications of Sovrin Entity that may be held legally accountable_", which does not fit in our model because:
+- it is a subclass of Sovrin Entity, and Parties need not necessarily be Sovrin Entities;
+- legal accountability can only be meaningful for %%legal entities|legal-entity%% within a %%jurisdiction|jurisdiction%% that has established criteria for determining which of their %%legal entities|legal-entity%% can be accountable for what.
+- The Sovrin definition does not associate an Identity Owner with %%knowledge|knowledge%%. 
 
 ---
 [^1]: Reasoning means: inferring conclusions from data, regardless of the kind of logic that is being used, or whether the reasoning is coherent, or consistent.
diff --git a/docs/terms/pattern-file.md b/docs/terms/pattern-file.md
index 233dd297e2e44aba22f7336f535fa21b630e9a36..c96aac2523aa625d524e024f5154bfb301194c4a 100644
--- a/docs/terms/pattern-file.md
+++ b/docs/terms/pattern-file.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 type: pattern
 typeid: pattern-file
 stage: draft
-hoverText: "Pattern-file: a file that defines/specifies a Pattern."
+hoverText: "Pattern-file: a file whose contents describes/documents a Pattern."
 ---
 
 ### Short Description
diff --git a/docs/terms/pattern-guardianship.md b/docs/terms/pattern-guardianship.md
index 65a0cff49472dab18e16732c3106b732b1291072..5e80877d700eaa48ec32b1c0f3f461a892240df6 100644
--- a/docs/terms/pattern-guardianship.md
+++ b/docs/terms/pattern-guardianship.md
@@ -25,7 +25,7 @@ The term ‘%%guardianship|guardianship%%’ has many definitions/descriptions.
 - “One who has the care of the person or property of another” or “One that guards” (both from [Merriam-Webster](https://www.merriam-webster.com/dictionary/%%guardianship|guardianship%%)),
 - “The state or duty of being a guardian”, where ‘guardian’ is defined as “A person who has the legal right and responsibility of taking care of someone who cannot take care of himself or herself” or “Someone who protects something” ([Cambridge Dictionary](https://dictionary.cambridge.org/dictionary/english/)), or
 - “The status of being a protector, advocate, or proxy for a person” ([Sovrin %%Guardianship|guardianship%% Task Force whitepaper](https://sovrin.org/wp-content/uploads/%%Guardianship|guardianship%%-Whitepaper.pdf)), which defines ‘guardian’ as “An organization or person protecting another person and possibly their property”.
-- “The legal, social, or organizational responsibility of serving as a Guardian” ([Sovrin Glossary](https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit)), which also defines ‘guardian’ as  “An Id%%entity|entity%% Owner who administers Id%%entity|entity%% Data, Wallets, and/or Agents on behalf of a %%Dependent|dependent%%”.
+- “The legal, social, or organizational responsibility of serving as a Guardian” ([Sovrin Glossary](https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit)), which also defines ‘guardian’ as  “An Identity Owner who administers identity Data, Wallets, and/or Agents on behalf of a %%Dependent|dependent%%”.
 
 So, it seems that most people will acknowledge that '%%guardianship|guardianship%%' is a relation between
 
diff --git a/docs/terms/pattern.md b/docs/terms/pattern.md
index 7f430759aec29b67e1bca96a1f664fabe8d82b13..024d02bb49444a0cc2a7212a6d2179c3a7e7030c 100644
--- a/docs/terms/pattern.md
+++ b/docs/terms/pattern.md
@@ -9,11 +9,11 @@ hoverText: "Pattern: A limited set of Concepts (ideas), relations between them,
 ---
 
 ### Short Description
-<!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
 A **pattern** (also called **mental model** or **conceptual model**) captures a limited set of %%concepts|concept%% (ideas), relations between them, and constraints, such that together they form a coherent and consistent whole. Patterns use (tangible) %%terms|term%% to refer to these (intangible) concepts and relations, so in order to be consistent, a pattern must reside in the scope that defines these concepts and relations. A pattern may also 'connect' concepts of different scopes (preferably no more than two), which you might call an 'interconnection pattern' between these scopes. 
 
+The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
+
 ### Purpose
-<!--Describe why the concept is needed. What purposes does it serve? What can you do with it that you cannot do (as well) without it? What objectives does it help realize? Why is this conceptevant within its scope of definition?-->
 A (good) pattern can be used
 - to facilitate one's thinking and reasoning about a specific subject/topic, and/or deepen one's understanding of it.
 - to effectively explain backgrounds of one's reasoning/understanding of the pattern's subject.
@@ -21,11 +21,9 @@ A (good) pattern can be used
 - to write texts using precisely defined language.
 
 ### Criteria
-<!--REQUIRED--How is this concept different from related ideas? What are essential characteristics that must be true? This is where you specify the [intensional definition](https://en.wikipedia.org/wiki/Extensional_and_intensional_definitions) of the concept, i.e. the necessary and sufficient conditions for when the term should be used. This makes that the conceptomes crystal clear. In the case of nouns, this is equivalent to specifying the properties that an object needs to have in order to be counted as a referent of the term.-->
 a limited set of %%concepts|concept%% (preferably not exceeding 7+/-2)[^1], relations between such concepts, and constraints, such that together they form a coherent and consistent whole that can be used to explain one's thinking about a specific topic within a specific %%scope|scope%%.
 
 ### Notes
-
 The first purpose of a pattern is to help us think and reason about a certain topic or issue.
 One signal that indicates the need of such a model is when we’re running circles in our thoughts, and we have this feeling of not understanding, of the topic being (too) complex. Often, we are thinking in terms of concepts that are not fit for the objectives we pursue.
 
@@ -36,16 +34,3 @@ The careful construction is comparable to a quest: it takes time, multiple versi
 This careful construction must ensure that the mental model gets different properties. For starters, the pattern must be able to reason in (all) static situations, where things do not change, and the so-called ‘invariant’ rules/constraints must  hold. Also, the model must be able to cope with time-dependencies and changes, for which other kinds of rules apply.
 
 In the end, the pattern needs to be expressed in several, different ways, depending on whom we want to convey the ideas behind it to. Business people generally need simple models that allow them to (roughly) grasp its gist. Software architects need models with precise definitions that allow them to use its elements in (formal) reasonings. Software engineers (programmers) need all the details that allow them to create applications and databases that work according to the model’s intent. So the level of detail that an expression of the model provides, makes it useful or useless to different audiences.
-
-### Background
-The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
-
-<!--
----
-### Footnotes
-
-[//]: # This (optional) section contains any footnotes that may have been specified in the text above.
-
-[^1]: the text for footnote [^1] goes here.
-
--->
\ No newline at end of file
diff --git a/docs/terms/policy-governor.md b/docs/terms/policy-governor.md
index 75c703f669524a5cbe0618d4cea02ecd9cdd16e9..29156ab322f447ba708d325bfcfef3fccbe97404 100644
--- a/docs/terms/policy-governor.md
+++ b/docs/terms/policy-governor.md
@@ -12,10 +12,14 @@ hoverText: "Policy Governor (of a Policy): the Party that is the Owner of the Po
 TNO (or others) to provide the content of this file.
 :::
 
+### Short Description
 
-### Background
 The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
 
+### Purpose
+
+### Criteria
+
 ### Related Concepts
 - %%Governance|governance%%
 - %%Governor|policy-governor%%
diff --git a/docs/terms/policy.md b/docs/terms/policy.md
index 7cb5e0d47c8c2053ac3bcf2e4fa64861d7d55619..63bcfaab5507a8ade721b4de058d418ee5fb565c 100644
--- a/docs/terms/policy.md
+++ b/docs/terms/policy.md
@@ -20,6 +20,8 @@ It should be part of the %%principal's|principal%% governance processes
 - to publish such artifacts such that at least every of its %%agents|agent%% that may need to access them, can find and access them as needed.
 - to inform its %%agents|agent%% whenever updates have been made that they need to be aware of (specifically if agents are allowed to keep local copies of such artifacts).
 
+The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
+
 ### Purpose
 The purpose of **policies** is to enable %%parties|party%% to provide its %%agents|agent%% with the rules and other guidance that they need to execute %%actions|action%% that comply with such rules. 
 
@@ -30,9 +32,6 @@ A **policy** is
 - may have multiple representations of the rules, working-instructions, preferences and other guidance, which are derived from the policy itself, in such a way that that any %%actor|actor%% that has a right or duty to execute an %%action|action%% on behalf of the  %%policy's governor|policy-governor%% can do so according to its intentions; 
 - is accessable to, and must be complied with by an %%agent|agent%% of that %%policy's governor|policy-governor%% when it executes an action of the kind to which the policy applies.
 
-### Background
-The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
-
 ### Related Concepts
 - %%Governance|governance%%
 - %%Governor|policy-governor%%
diff --git a/docs/terms/presentation.md b/docs/terms/presentation.md
index c0f69b7cfb8bf3cfebf58be3c753714f5b78d726..5663e67e07c76936ee9a35970be9ba22efd9d525 100644
--- a/docs/terms/presentation.md
+++ b/docs/terms/presentation.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: presentation
 stage: draft
-hoverText: "Presentation: a (signed) digital message that contains data derived from one or more Verifiable Credentials (that have been issued by Agents of one or more Parties), as a response to a specific Presentation Request of a Verifier component."
+hoverText: "Presentation: a (signed) digital message that a Holder component may send to a Verifier component that contains data derived from one or more Verifiable Credentials (that (a Colleague component of) the Holder component has received from Issuer components of one or more Parties), as a response to a specific Presentation Request of a Verifier component."
 ---
 
 ### Short Description
diff --git a/docs/terms/principal.md b/docs/terms/principal.md
index f3773b71d2df2f26852a65aad5e9b6f43edb183f..4e90ca7bea99c5cdec3131c85f753b4471675888 100644
--- a/docs/terms/principal.md
+++ b/docs/terms/principal.md
@@ -5,11 +5,17 @@ scopeid: essifLab
 type: concept
 typeid: principal
 stage: draft
-hoverText: "Principal (of an Actor): A Party for whom, or on behalf of whom, the Actor works (this Actor is then called an Agent of that Party)."
+hoverText: "Principal (of an Actor): the Party for whom, or on behalf of whom, the Actor is executing an Action (this Actor is then called an Agent of that Party)."
 ---
 
+:::info Editor's noet
+TNO to revise this text
+:::
+
 ### Short Description
-A **principal** is the term we use to refer to the %%party|party%% for which (on whose behalf) an %%agent|agent%% is acting. The Agent-Principal relation is an %%Actor|actor%%-%%party|party%% relation where the actor is executing an action on behalf of that %%party|party%%, and for the execution of which the principle has established rules, working-instructions, preferences and other guidance that the agent must (or may follow (and hence have access to). For %%digital agents|digital-agent%%, 
+A **principal** is the term we use to refer to the %%party|party%% for which (on whose behalf) an %%agent|agent%% is executing an %%action|action%%. The Agent-Principal relation is an %%actor|actor%%-%%party|party%% relation where the %actor|actor% is executing an %%action|action%% on behalf of that %%party|party%%, and for the execution of which that %%party|party%% has established a %%policy|policy%% that the %%agent|agent%% must (or may) follow, and hence must have access to). For %%digital agents|digital-agent%%, 
+
+The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
 
 ### Purpose
 The ability to distinguish between (non)principals is relevant in many situations, including:
@@ -22,6 +28,3 @@ The **principal** (of an %%actor|actor%%) is the %%party|party%% for whom the ac
 
 - A person that is 'doing its own things' is the Principal for himself (as an Actor); the person is also an Agent for himself (as a %%party|party%%).
 - When a person is doing things for his employer, the latter is his Principal.
-
-### Background
-The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
diff --git a/docs/terms/scope-file.md b/docs/terms/scope-file.md
index 1d890fe8c83290a705a3a570b362b8814d9aff59..a5efb639aa960fe4a7751e6c32c5906057772bc2 100644
--- a/docs/terms/scope-file.md
+++ b/docs/terms/scope-file.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: scope-file
 stage: draft
-hoverText: "Scope-file: a file that defines/specifies a Scope."
+hoverText: "Scope-file: a file whose contents defines/specifies a Scope."
 ---
 
 ### Short Description
diff --git a/docs/terms/scope.md b/docs/terms/scope.md
index 3a1477064684b9a8bff98b37ac9e3bd32bbe9a3e..6cd9395f0cf20d48ad9c893ba32ea45d8b06e003 100644
--- a/docs/terms/scope.md
+++ b/docs/terms/scope.md
@@ -9,43 +9,15 @@ hoverText: "Scope: the extent of the area or subject matter (which we use to def
 ---
 
 ### Short Description
-<!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
 A **scope** (in the eSSIFLab context) is the extent of the area or subject matter (as in [OED](https://www.lexico.com/definition/scope). We use it to define patterns, concepts, terms and glossaries in, but a scope may serve other (additional) purposes. Scopes may overlap, or be nested. It is comparable to [Namespeces](https://en.wikipedia.org/wiki/Namespace), were it not that entities other than names (signs that are used to identify/refer to objects of various kinds) can reside in a scope as it is defined here.
 
+The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
+
 ### Purpose
-<!--Describe why the concept is needed. What purposes does it serve? What can you do with it that you cannot do (as well) without it? What objectives does it help realize? Why is this concept relevant within its scope of definition?-->
 This allows each %%term|term%% (words, phrases) to be used in a limited scope, for specific purposes. The fact that terms are 'scoped' implies that a term may have _different_ meanings, depending on the scope within which it is used. Also, it allows us to author documentation in a 'scoped' fashion, allowing different groups of people to author, use and disseminate their documentation (including documentation about their ideas (%%patterns|pattern%%), %%concepts|concept%%, and %%terms|term%%.)
 
 ### Criteria
-<!--REQUIRED--How is this concept different from related ideas? What are essential characteristics that must be true? This is where you specify the [intensional definition](https://en.wikipedia.org/wiki/Extensional_and_intensional_definitions) of the concept, i.e. the necessary and sufficient conditions for when the term should be used. This makes that the concept becomes crystal clear. In the case of nouns, this is equivalent to specifying the properties that an object needs to have in order to be counted as a referent of the term.-->
 a (virtual) demarcation that serves particular purposes.
 
-### Examples
-<!--Provide a few sentences in which you give examples that obviously qualify as instances of `Scope`, and that do NOT obviously qualify. Also, provide examples that are not (so) obvious, but help users to better understand its intension.-->
-
-### Related Concepts
-<!--Link to any concepts that are similar but distinct, with a note about the relationship.-->
-
-### Background
-<!--Mention and link to the patterns in which this concept plays a (significant) role (possibly explaining the reason/purpose if appropriate), e.g.: -->
-The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
-
-### Use-cases
-<!--This (optional) section specifies an (optional) introductory paragraph, and a level-3 (i.e. `###`) subsection for every use case it describes. Every such use-case SHOULD
-- describe the situation/context of the use-case;
-- show how to apply `Scope` to/in that situation;
-- shows the relevance of having `Scope` for the use-case as opposed to not having it.-->
-
 ### Notes
-<!--This (optional) section is the place to put anything for which there is no other good place to put it.-->
 - Scopes within which a certain %%concept|concept%% is known, may still use different terms to refer to the concept. That's the reason for having %%definitions|definition%% that specify criteria for determining whether or not something qualifies as (an instance of) some concept: we cannot rely on different scopes necessarily using the same terms for that.
-
-<!--
----
-### Footnotes
-
-[//]: # This (optional) section contains any footnotes that may have been specified in the text above.
-
-[^1]: the text for footnote [^1] goes here.
-
--->
\ No newline at end of file
diff --git a/docs/terms/semantics.md b/docs/terms/semantics.md
index e42ac8efb8fc0cc8bb94ec45fcf4e3f82338eef6..546e504e59639eabb56704e1fe195df440fa19d0 100644
--- a/docs/terms/semantics.md
+++ b/docs/terms/semantics.md
@@ -1,6 +1,6 @@
 ---
 id: semantics
-title: "Concept"
+title: "Semantics"
 scopeid: essifLabTerminology
 type: concept
 typeid: semantics
diff --git a/docs/terms/term-file.md b/docs/terms/term-file.md
index 5bcee45aa2c3f660a3683448e1e7e70f3682d9b2..cd823fcebf28dc5d00b845de10f76a32ffc9048d 100644
--- a/docs/terms/term-file.md
+++ b/docs/terms/term-file.md
@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: term-file
 stage: draft
-hoverText: "Term-file: a file that defines/specifies a Term."
+hoverText: "Term-file: a file whose contents defines/specifies a Term."
 ---
 
 ### Short Description
diff --git a/docs/terms/term.md b/docs/terms/term.md
index 68027d9186796ce7e008a63da823f9af4dcccad5..9291e098c0d3db69124705d28eb538199409549a 100644
--- a/docs/terms/term.md
+++ b/docs/terms/term.md
@@ -9,28 +9,18 @@ hoverText: "Term: a word or phrase that is used in at least one Scope/context to
 ---
 
 ### Short Description
-<!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
 A Term is a word or phrase that is used in at least one context (and/or for specific purposes) to refer to a specific %%concept|concept%%. As a concequence:
 - the meaning of a Term may vary across contexts. For example, in the context of a buty-salon, the term 'nail' has a different meaning than in the context of constructing buildings.
 - different terms (in different contexts) may refer to the same concept ([synonymity](https://en.wikipedia.org/wiki/Synonym)).
 
+The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
+
 ### Purpose
-<!--Describe why the concept is needed. What purposes does it serve? What can you do with it that you cannot do (as well) without it? What objectives does it help realize? Why is this conceptevant within its scope of definition?-->
 Understanding words or phrases uttered by others requires that we are able to 'translate' them terms into terms that we habitually use. While this is mostly an automatism, and it often is not necessary to be all that precise, this may be different when they relate to stuff we find important. The ability to refer to a specific %%concept|concept%% with a specific text or phrase, where this 'linking' is limited to a specific (or several) context(s) helps us to better interpret the intentsion of what others convey in spoken or written language.
 
 ### Criteria
-<!--How is this concept different from related ideas? What are essential characteristics that must be true? This is where you specify the [intensional definition](https://en.wikipedia.org/wiki/Extensional_and_intensional_definitions) of the concept, i.e. the necessary and sufficient conditions for when the term should be used. This makes that the conceptomes crystal clear. In the case of nouns, this is equivalent to specifying the properties that an object needs to have in order to be counted as a referent of the term.-->
 A Term MUST be a word or phrase that is linked to at least one %%context|scope%% and refers to precisely one %%concept|concept%%. 
 
-### Examples
-<!--Provide a few sentences in which you give examples that obviously qualify as instances of `Term`, and that do NOT obviously qualify. Also, provide examples that are not (so) obvious, but help users to better understand its intension.-->
-
-### Related Concepts
-<!--Link to any %%concepts|concept%% that are similar but distinct, with a note about the relationship.-->
-
-### Background
-The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.
-
 ### Domains
 <!--In which general knowledge ecosystems or mental model families does this concepty a role?-->
 * eSSIF-Lab
@@ -44,14 +34,7 @@ The %%terminology pattern|pattern-terminology%% provides an overview of how this
 <!--Add hash tags here that allow us to group concepts in useful ways.-->
 * Terminology
 
-### Use-cases
-<!--This (optional) section specifies an (optional) introductory paragraph, and a level-3 (i.e. `###`) subsection for every use case it describes. Every such use-case SHOULD
-- describe the situation/context of the use-case;
-- show how to apply ``Term`` to/in that situation;
-- shows the relevance of having ``Term`` for the use-case as opposed to not having it.-->
-
 ### Notes
-<!--This (optional) section is the place to put anything for which there is no other good place to put it.-->
 There is an important [distinction](https://simple.wikipedia.org/wiki/Concept) between concepts and the (multitude of) terms (names, labels) that we need to be able to talk and reason (argue) about them. Please consider that
 
 * different terms are used in different contexts for the same concept
@@ -60,7 +43,6 @@ There is an important [distinction](https://simple.wikipedia.org/wiki/Concept) b
 
 ---
 ### Footnotes
-<!--This (optional) section contains any footnotes that may have been specified in the text above.-->
 
 [^1]: WikiPedia has a concise [explanation of concepts](https://en.wikipedia.org/wiki/Concept). We use the term 'concept' as a [mental representation](https://en.wikipedia.org/wiki/Mental_representation).
 
diff --git a/docs/terms/transaction-data-collector.md b/docs/terms/transaction-data-collector.md
index 4fb33e93f32dc74a47499fc48bb27f1bea55797b..89b457be42399492d3f207f94e1b01ccabc22582 100644
--- a/docs/terms/transaction-data-collector.md
+++ b/docs/terms/transaction-data-collector.md
@@ -50,24 +50,24 @@ It will be deleted in the (near?) future.
 Typically, the Transaction Data Collector would start a transaction either
 
 -   when it receives a request from some Agent of another %%party|party%% for engaging in a transaction of a specific kind.
--   when it is instructed by, or on behalf of its Owner, to request a specific kind of transaction to some Agent of another %%party|party%%.[^one]
+-   when it is instructed by, or on behalf of its Principal, to request a specific kind of transaction to some Agent of another %%party|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 Owner and/or using different %%communication channels|communication-channel%%.
+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|communication-channel%%.
 
 Handling/managing the various %%communication channels|communication-channel%% through which data can be exchanged is also a task of the Transaction 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).
 
 Thus, the Transaction Data Collector is generally considered capable of obtaining data through different %%communication channels|communication-channel%%. However, the technical tracks of eSSIF-Lab will exclusively focus on the %%communication channel|communication-channel%% through which credentials can be requested and obtained. Any extensions or business productization of Transaction Data Collector designs may be considered in the business tracks of eSSIF-Lab. The latter is not considered any further in this section.
 
-In order to acquire data through SSI mechanisms for filling in a form for a specific kind of transaction, the Transaction Data Collector needs to know what kinds of credentials it should ask for, which %%parties|party%% its Owner trusts to issue such credentials, what kinds of verification proofs for such credentials must hold and which may be disregarded.[^3] Also, when the Transaction Data Collector gets a credential that satisfies the necessary verification proofs, it needs a way to map the contents of that credential to the structure of the transaction context that is used internally by (other systems of) its Owner.[^4] Also, as the Transaction Data Collector gets more and more data - which it may get through multiple, different channels - it needs to determine whether or not the resulting set is sufficiently consistent and coherent.[^5]
+In order to acquire data through SSI mechanisms for filling in a form for a specific kind of transaction, the Transaction Data Collector needs to know what kinds of credentials it should ask for, which %%parties|party%% its Principal trusts to issue such credentials, what kinds of verification proofs for such credentials must hold and which may be disregarded.[^3] Also, when the Transaction Data Collector gets a credential that satisfies the necessary verification proofs, it needs a way to map the contents of that credential to the structure of the transaction context that is used internally by (other systems of) its Principal.[^4] Also, as the Transaction Data Collector gets more and more data - which it may get through multiple, different channels - it needs to determine whether or not the resulting set is sufficiently consistent and coherent.[^5]
 
-In order to make the Transaction Data Collector work, a Validation Policy (or Transaction Data Collector Policy) is created by, or on behalf of the Owner, which specifies at least:
+In order to make the Transaction Data Collector work, a Validation Policy (or Transaction Data Collector Policy) is created by, or on behalf of the Principal, which specifies at least:
 
--   the kinds of transactions the Owner is willing to (electronically) engage in, from both the requester and the provider perspectives;
+-   the kinds of transactions its 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|commitment-decision%%.
 
-    -   the kinds of credentials and issuers that the Owner is willing to accept as sources for valid data; (optionally?), the endpoint URI at which issuing %%parties|party%% do the actual credential issuing may be specified[^6].
+    -   the kinds of credentials and issuers that its Principal is willing to accept as sources for valid data; (optionally?), the endpoint URI at which issuing %%parties|party%% do the actual credential issuing may be specified[^6].
 
     -   for each kind of credential: the verification proofs that must hold to be accepted as a source for valid data.
 
@@ -75,9 +75,9 @@ In order to make the Transaction Data Collector work, a Validation Policy (or Tr
 
 The Policy must be designed in such a way that it is extendable as new features will be called for in the future.
 
-The ability to create new transaction contexts and the availability of the Transaction Data Collector Policy enable the Transaction Data Collector to request the Verifier component of its Owner 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 Owner.[^7]
+The ability to create new transaction contexts and the availability of the Transaction Data Collector Policy enable the Transaction 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 Transaction 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|party%%-specific and hence come from the Transaction 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 Transaction Data Collector itself must make validation decisions, either electronically (according to the Transaction Data Collector policy) or by ‘outsourcing’ such decisions to human Agents of its Owner 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 Transaction 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|party%%-specific and hence come from the Transaction 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 Transaction Data Collector itself must make validation decisions, either electronically (according to the Transaction 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 Transaction Data Collector can intermittently request the verifier to produce it (or it can use other %%communication channels|communication-channel%%, which is outside scope for now). It does so until it times out, or the form has become ‘clean’.
 
@@ -98,9 +98,9 @@ TNO to revise the footnote markers
 
 [^2]: It may well be that this functionality can somehow be split off in the (near) future.
 
-[^3]: For high-value transactions, verification proofs are more important than for low-value transactions. This is to be decided by the Owner of the Transaction 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.
+[^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 Transaction 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 Owner 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 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.
 
diff --git a/docs/terms/transaction-data-discloser.md b/docs/terms/transaction-data-discloser.md
index 152e9ba0f1839f0961e67789f29b96618620c884..c58f5d5b09f7339258b21c8db69ca46fa7932fef 100644
--- a/docs/terms/transaction-data-discloser.md
+++ b/docs/terms/transaction-data-discloser.md
@@ -19,7 +19,7 @@ The Transaction Data Discloser uses a %%Transaction Data Discloser policy|transa
 The Transaction Data Discloser uses the %%eSSIF-Glue|essif-glue%% interface to access the %%Wallet|wallet%%, %%Holder|holder%%, %%Issuer|issuer%% and %%Verifier|verifier%% functionalities.
 
 ### Purpose
-The purpose of the Transaction Data Discloser component is to state the (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other %%parties|party%%. A special kind of result is the (provisioning of) a credential that its Owner already has created.
+The purpose of the Transaction Data Discloser component is to state the (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other %%parties|party%%. A special kind of result is the (provisioning of) a credential that its Principal already has created.
 
 ### Criteria
 A **Transaction Data Discloser** is a component in the [eSSIF-Lab functional architecture](../functional-architecture) that is capable of stating (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other %%Parties|party%%.
diff --git a/docs/terms/transaction-id.md b/docs/terms/transaction-id.md
new file mode 100644
index 0000000000000000000000000000000000000000..2d0a69c0f2b49bf2a4c89155be33e11b08261488
--- /dev/null
+++ b/docs/terms/transaction-id.md
@@ -0,0 +1,18 @@
+---
+id: transaction-id
+title: "Transaction Id"
+scopeid: essifLab
+type: concept
+typeid: transaction-id
+stage: draft
+hoverText: "Transaction Id (for a specific Business Transaction and a Participant): character string that this Participant uses to identify, and refer to, that Business Transaction."
+---
+
+:::info Editor's note
+TNO (or others) to provide the content of this file.
+:::
+
+Explain that different %%transaction|business-transaction%% %%participants|participant%% are each likely to use their own %%identifiers|identifier%% for identifying, and referring to, the various %%transactions|business-transaction%% that they participate in. A %%participant|participant%% should communicate its %%transaction id|transaction-id%% to another %%participant|participant%% if it expects that other %%participant|participant%% to refer to the %%transaction|business-transaction%% in a way that it can dereference (i.e.: can use to identify the %%transaction|business-transaction%% with.
+
+### Related Concepts
+- %%Identifier|identifier%%
diff --git a/docs/terms/transaction-request.md b/docs/terms/transaction-request.md
new file mode 100644
index 0000000000000000000000000000000000000000..a0b1b0866b44fe37ac68ce8b41374ec470cbcd91
--- /dev/null
+++ b/docs/terms/transaction-request.md
@@ -0,0 +1,17 @@
+---
+id: transaction-request
+title: "Transaction Request"
+scopeid: essifLab
+type: concept
+typeid: transaction-request
+stage: draft
+hoverText: "Transaction Request: a message, send by a requesting Party to a providing Party, that initiates the negotiation of a new Transaction Agreement between these Parties for the provisioning of a specific product or service."
+---
+
+:::info Editor's note
+TNO (or others) to provide the content of this file.
+:::
+
+### Related Concepts
+- %%Transaction Agreement|transaction-agreement%%
+- %%Transaction Form|transaction-form%%
\ No newline at end of file
diff --git a/docs/terms/transaction-type.md b/docs/terms/transaction-type.md
new file mode 100644
index 0000000000000000000000000000000000000000..edecd795a00f59a872faaba8734107b65162e3cf
--- /dev/null
+++ b/docs/terms/transaction-type.md
@@ -0,0 +1,14 @@
+---
+id: transaction-type
+title: "Transaction Type"
+scopeid: essifLab
+type: concept
+typeid: transaction-type
+stage: draft
+hoverText: "Transaction Type (of some kind of Business Transaction and some Party): the Policy, Governed by that Party, and other necessary artifacts (e.g. a Transaction Form) that provide an Actor with all necessary means to conduct a Transaction of this type on behalf of that Party."
+---
+
+:::info Editor's note
+TNO (or others) to provide the content of this file.
+:::
+
diff --git a/docs/terms/verifier.md b/docs/terms/verifier.md
index f8ece61074b48651aa83d6345345f4663dd1c314..6c8a83d20c44a252bd5deda82cf87287ffbdc3d3 100644
--- a/docs/terms/verifier.md
+++ b/docs/terms/verifier.md
@@ -32,9 +32,9 @@ A **Verifier** is a component in the [eSSIF-Lab functional architecture](../func
 
 The purpose of the Verifier component is to support the Transaction Data Collector by providing it with a single, simple API that it can use to request and obtain data that it needs to produce a clean transaction form, as well as the results of checking verification proofs (this is also why it is called the ‘verifier’ component).
 
-Typically, the Transaction Data Collector would ask the Verifier to provide a credential that it can use to fill in a (coherent set of) field(s) in the transaction form. It is realistic to think that credentials from different issuers - trusted by the Verifier’s Owner - can be used for this purpose. However, it is also realistic that such credentials will not use the same credential definition - they might well use different schemes to provide such data. Therefore, the Transaction Data Collector should specify a list of pairs (credential-type, issuer) instances of which could all be used to provide the data it needs - which it can obtain from the Transaction Data Collector policy.
+Typically, the Transaction Data Collector would ask the Verifier to provide a credential that it can use to fill in a (coherent set of) field(s) in the transaction form. It is realistic to think that credentials from different issuers - trusted by the Verifier’s Principal - can be used for this purpose. However, it is also realistic that such credentials will not use the same credential definition - they might well use different schemes to provide such data. Therefore, the Transaction Data Collector should specify a list of pairs (credential-type, issuer) instances of which could all be used to provide the data it needs - which it can obtain from the Transaction Data Collector policy.
 
-Then, the Verifier needs to know the address and protocol that it can use to reach a Holder component owned by the %%party|party%% that its Owner is trying to negotiate the transaction with. The Transaction Data Collector specifies this as part of the request - and it can do so because it has received the original request, and does all %%communication channel|communication-channel%% handling.
+Then, the Verifier needs to know the address and protocol that it can use to reach a Holder component owned by the %%party|party%% that its Principal is trying to negotiate the transaction with. The Transaction Data Collector specifies this as part of the request - and it can do so because it has received the original request, and does all %%communication channel|communication-channel%% handling.
 
 Verifiers are not expected to handle every kind of credential (e.g. VC’s, ABC’s, etc.) that exists, but rather a specific subset. For (at least one of) the credential types, the Verifier can construct a so-called presentation request, i.e. a message that is specific for the credential type and/or associated protocol, which it can then send to the Holder’s address.
 
@@ -42,12 +42,12 @@ This request message should contain at least
 
 -   the transaction-id, so that when it is copied into the associated response message, the latter can be associated to the transaction it belongs to. Also, it should contain the
 -   the (credential type, issuer) pairs that may satisfy the request, and to each of these additional data, e.g. the URI of the endpoint where the issuer issues such credentials, the maximum age of the credential, etc.
--   meta-data that may be useful for the holder (or its Owner), e.g. texts stating the purpose(s) for which the data will be used ([*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) Art. 5.1.b), or requesting consent ([*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) Art. 7.2) “in an intelligible and easily accessible form, using clear and plain language”.
--   a signature of the Verifiers Owner, for the purpose of showing compliance with the [*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) (e.g. Art 28.3.h), and enabling the Holder’s Owner to obtain proof that the Verifiers Owner has violated the [*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN)’s minimization principle asked for data for a particular purpose, which can be used in an argument in disputes about data minimization ([*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) Art. 5.1.c).
+-   meta-data that may be useful for the holder (or its Principal), e.g. texts stating the purpose(s) for which the data will be used ([*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) Art. 5.1.b), or requesting consent ([*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) Art. 7.2) “in an intelligible and easily accessible form, using clear and plain language”.
+-   a signature of the Verifiers Principal, for the purpose of showing compliance with the [*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) (e.g. Art 28.3.h), and enabling the Holder’s Principal to obtain proof that the Verifiers Principal has violated the [*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN)’s minimization principle asked for data for a particular purpose, which can be used in an argument in disputes about data minimization ([*GDPR*](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN) Art. 5.1.c).
 
 The request message must be designed in such a way that it is extendable as new features will be called for in the future.
 
-In order to make the Verifier component work, a Verifier Policy/Preferences object is created by, or on behalf of the Owner, which specifies at least: \[to be elaborated\]
+In order to make the Verifier component work, a Verifier Policy/Preferences object is created by, or on behalf of the Principal, which specifies at least: \[to be elaborated\]
 
 A response to this request (called a Presentation) will be obtained from a Holder component of the Peer %%party|party%%. This response will contain a reference to the request, allowing the Verifier to combine them. The Verifier will then check that the data in the response is a credential that it has asked for (correct type/issuer), verify the proofs that are provided (predominantly the digital signature), and do some additional checks (e.g. whether or not the credential has expired, is revoked, and such).
 
diff --git a/docs/terms/wallet.md b/docs/terms/wallet.md
index 532741cc86de1153cd25b7a8d81f9b26cc76a27b..36a1bbfc20126fa93d5c420fbcf5a4e9021b792f 100644
--- a/docs/terms/wallet.md
+++ b/docs/terms/wallet.md
@@ -9,7 +9,7 @@ hoverText: "Wallet (functional component): the capability to securely store data
 ---
 
 ### Short Description
-A **Wallet** is is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that provides (secure) storage of credentials - regardless of the %%party|party%% that has issued them (i.e. so-called self-signed credentials may be stored there, too). Another task of the wallet is to (securely) store (private) keys that can be used to sign or seal data on behalf of its Owner. Perhaps the most important task of the Wallet is to ensure that credentials and keys can only become available to another component if they have the same (single) Owner, and will become available if such other component implements a functionality that needs it.
+A **Wallet** is is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that provides (secure) storage of credentials - regardless of the %%party|party%% that has issued them (i.e. so-called self-signed credentials may be stored there, too). Another task of the wallet is to (securely) store (private) keys that can be used to sign or seal data on behalf of its Principal. Perhaps the most important task of the Wallet is to ensure that credentials and keys can only become available to another component if they have the same (single) Principal, and will become available if such other component implements a functionality that needs it.
 
 :::info Editor's note
 TNO (or others) to provide additional content of this file.
@@ -26,7 +26,7 @@ A **Wallet** is a component in the [eSSIF-Lab functional architecture](../functi
 The primary purpose of the Wallet Component is to (securely) store data, and in particular:
 
 -   credentials - both those that have been issued by the issuer (i.e. self-signed credentials) and those that have been obtained from issuers of other %%parties|party%%, and
--   (private) keys e.g. for signing/sealing data on behalf of its Owner.
+-   (private) keys e.g. for signing/sealing data on behalf of its Principal.
 
 Other kinds of data may be stored by a wallet as well - we will have to see what is practical and makes sense.
 
@@ -38,9 +38,9 @@ By ‘securely storing data’ we mean that such data
 -   can only become available to electronic Colleagues that implement a functionality that requires such access (e.g. a Colleague Holder component);
 -   can only be stored by electronic Colleagues that implement a functionality that require such data to be stored (e.g. a Colleague Holder or Issuer component).
 
-It is expected that components other than the Holder and Issuer will (arise and) need access. One example could be a component that is capable of securely signing data on behalf of the Owner. Another example could be a component that implements some kind of credential revocation functionality.
+It is expected that components other than the Holder and Issuer will (arise and) need access. One example could be a component that is capable of securely signing data on behalf of the Principal. Another example could be a component that implements some kind of credential revocation functionality.
 
 Human beings cannot directly access any Wallet component, not even the ones they own. They need an electronic Agent that is capable of authenticating them as (an Agent of) the %%party|party%% that owns the Wallet component, and upon successful authentication provides a User Interface through which the Human Being can instruct this electronic Agent to manage the Wallet’s contents.
 
-In order to make the Wallet component work, a Wallet Policy/Preferences object is created by, or on behalf of the Owner, the contents of which remains to be specified.
+In order to make the Wallet component work, a Wallet Policy/Preferences object is created by, or on behalf of the Principal, the contents of which remains to be specified.