From bc70a51b485290090db9ba66161ea15f8df98229 Mon Sep 17 00:00:00 2001 From: RieksJ Date: Sat, 10 Oct 2020 15:13:21 +0200 Subject: [PATCH 01/26] remove the docs/terminology directory as we do not use/need its contents --- docs/terminology/README.md | 30 -------- docs/terminology/essifLab-concept-party.mdx | 25 ------- docs/terminology/essifLab-glossary.mdx | 35 ---------- .../essifLabTerminology-concept-glossary.mdx | 43 ------------ .../essifLabTerminology-concept-term.mdx | 65 ----------------- ...sifLabTerminology-pattern-mental-model.mdx | 36 ---------- .../terminology/essifLabTerminology-scope.mdx | 38 ---------- .../templates/template-concept-proposal.mdx | 70 ------------------- 8 files changed, 342 deletions(-) delete mode 100644 docs/terminology/README.md delete mode 100644 docs/terminology/essifLab-concept-party.mdx delete mode 100644 docs/terminology/essifLab-glossary.mdx delete mode 100644 docs/terminology/essifLabTerminology-concept-glossary.mdx delete mode 100644 docs/terminology/essifLabTerminology-concept-term.mdx delete mode 100644 docs/terminology/essifLabTerminology-pattern-mental-model.mdx delete mode 100644 docs/terminology/essifLabTerminology-scope.mdx delete mode 100644 docs/terminology/templates/template-concept-proposal.mdx diff --git a/docs/terminology/README.md b/docs/terminology/README.md deleted file mode 100644 index 0cfa69b..0000000 --- a/docs/terminology/README.md +++ /dev/null @@ -1,30 +0,0 @@ -# README for terminology-related files. - -:::info -under construction -::: - -This document states the requirements for files in this directory, such that they can properly processed into useful and usable Docusaurus documentation. - -## Filenames - -All file MUST have the structure: `--.mdx`, where - -- `` is the (all lowercase) identifier of an existing scope, i.e. the file `-1-scope.mdx` must exist. -- `` MUST be any of the following: - - `scope` - - `pattern` - - `concept` - - `term` - - `glossary` -- `` MUST be a lowercase identifier that only uses characters `a`-`z` and `-`. - -## Templates - -The `terminology/templates` directory contains templates for each of the types. A template file has comments that hold, amongst others, requirements for the contents of instances of that template. - -## Referring to terms in documentation files - -Any term can be referred to in any documentation file, using the syntax `%%%%`, where `` is either the `` of a concept - -- `` is a text that will be displayed as if it were a term diff --git a/docs/terminology/essifLab-concept-party.mdx b/docs/terminology/essifLab-concept-party.mdx deleted file mode 100644 index 5c61ca3..0000000 --- a/docs/terminology/essifLab-concept-party.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -id: essifLab-concept-party -title: "Concept: Party (Scope: eSSIF-Lab)" -scopeid: essifLab -termid: party -hoverText: "Entity that has knowledge about what exists, ways to reason with that knowledge, and ways for making decisions in a Self-Sovereign fashion." ---- - -## Criterion: -Entity that has knowledge about what exists, ways to reason[^1] with that knowledge, and ways for making decisions in a Self-Sovereign[^2] fashion. - -## Examples: -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]. - -### xxx: -to be elaborated - ---- -[^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. - -[^2]: This means that the party can do this all by itself. For humans, the rights for this are laid down e.g. in the [ECHR](https://www.echr.coe.int "European Convention of Human Rights") ([ECHR articles 9-11](https://www.echr.coe.int/Documents/Convention_ENG.pdf)) - -[^3]: While the case can be made that (some) electronic components can reason, they do not do so in a self-sovereign fashion as intended by this definition. We do not want to discuss AI-equipment here. diff --git a/docs/terminology/essifLab-glossary.mdx b/docs/terminology/essifLab-glossary.mdx deleted file mode 100644 index f6b5407..0000000 --- a/docs/terminology/essifLab-glossary.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -id: glossary-essiflab -title: Glossary eSSIF-Lab (Scope essiflab) ---- - - -## Purpose - -This glossary lists the basic concepts that are needed by the various stakeholders within the eSSIF-Lab project, ranging from governance, business, process, technology etc. The idea is that it defines at least the set of concepts that are often used in these varied domains, allowing a reader with a specific background to learn how the concept is used from other (valid) perspectives that may be alien to him/her. - -## Sources - - -### Include - -* eSSIF-Lab - -### Terms - - -### Patterns - - -### Concepts - - - diff --git a/docs/terminology/essifLabTerminology-concept-glossary.mdx b/docs/terminology/essifLabTerminology-concept-glossary.mdx deleted file mode 100644 index 60555a7..0000000 --- a/docs/terminology/essifLabTerminology-concept-glossary.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -id: glossary -title: "Glossary (Concept)" -scopeid: essifLabTerminology -type: concept -typeid: glossary -hoverText: "an alphabetically sorted list of terms explanations, usually aimed to help people understand texts around a certain (set of) topic(s) in some context(s)." ---- - -## Short Description - -A glossary is an alphabetically sorted list of terms and explanations, usually aimed to help people understand texts around a certain (set of) topic(s) in some context(s). However, 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. - -## Purpose - -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 - -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 - -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 - -- 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 - this is a body of words used in a particular language or field of expertise. A Glossary can provide the meaning of each word for use within the scope(s) for which the Glossary is created. - -## Notes - -The [eSSIF-Lab Glossary](essifLab-glossary) contains the words that are defined within the scope of the [eSSIF-Lab framework](introduction). - - diff --git a/docs/terminology/essifLabTerminology-concept-term.mdx b/docs/terminology/essifLabTerminology-concept-term.mdx deleted file mode 100644 index 79016b3..0000000 --- a/docs/terminology/essifLabTerminology-concept-term.mdx +++ /dev/null @@ -1,65 +0,0 @@ ---- -id: term -title: "Term (Scope: essifLabTerminology)" -scopeid: essifLabTerminology -type: concept -typeid: term -hoverText: "a word or phrase that is used in at least one scope/context to refer to a specific concept." ---- - -## Short Description - -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)). - -## Purpose - -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 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 - -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 - - -## Related Concepts - - - -## Domains - -* eSSIF-Lab -* ToIP -* Sovrin -* DIF -* NIST -* ... - -## Tags - -* Terminology - -## Use-cases - - -## Notes - -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 -* in different contexts, a single term may refer to different concepts -* to resolve terminological disputes, which usually are about the 'correct' meaning of a term, try to establish the criteria that the different participants use for the concept behind the term. That helps participants understand each others (different) positions, and provides a better basis for resolving the conflict. - ---- -## Footnotes - - -[^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). - -[^2]: For the difference between 'Concept' and 'Term', see https://simple.wikipedia.org/wiki/Concept. diff --git a/docs/terminology/essifLabTerminology-pattern-mental-model.mdx b/docs/terminology/essifLabTerminology-pattern-mental-model.mdx deleted file mode 100644 index 6415965..0000000 --- a/docs/terminology/essifLabTerminology-pattern-mental-model.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -id: pattern-mental-model -title: "Pattern: Mental Models (Scope: essifLabTerminology)" -scopeid: essifLabTerminology -type: pattern -typeid: mental-model -hoverText: "This pattern captures the foundational concepts and relations that we need for creating, maintaining and using (decentralized) vocabularies (terminologies) that groups of people can use for the specific purposes they pursue." ---- - -## Purpose - -This pattern captures the foundational concepts and relations that we need for creating, maintaining and using vocabularies (terminologies) that groups of people can use for the specific purposes they pursue. Alternatively, we need these concepts to allow people to use 'decentralized vocabularies' that %%parties|party%% may create, maintain and use in a self-sovereign fashion - which means that each of them decides for itself what terms to use in what meaning, yet be able to communicate with other such %%parties|party%% in such a way that a correct understanding of what the other means, can more or less be guaranteed. - -## Introduction - -TL;DR: . - -A concept is an idea that is applied to all objects in a group. It is the way people see and understand something. The name used to identify a concept (the concept's label) is a "term". For example, the word "Dog" is the term to identify the concept of what a dog is. Everything that a person knows about a dog is the concept of the term dog. - -Different terms can be used to identify the same concept. Car and Automobile are synonyms for the same concept. Different languages have different terms for the same concept. This is what makes translation possible. The terms may be different in each language, but the concept is the same. The concept of jumping is the same to a person from England and a person from Italy, but one person uses the term "Jump" to mean the concept and the other person uses "Salto". - -## Notations - - -## - - - diff --git a/docs/terminology/essifLabTerminology-scope.mdx b/docs/terminology/essifLabTerminology-scope.mdx deleted file mode 100644 index 72cb932..0000000 --- a/docs/terminology/essifLabTerminology-scope.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -id: scope-essifLabTerminology -title: Scope eSSIF-Lab Terminology ---- - -## Governance - -The [eSSIF-Lab project](https://essif-lab.eu/) governs the terminology within this scope, according to the procedures mentioned in the [eSSIF-Lab Framework](https://essif-lab.pages.grnet.gr/framework/docs/terminology/). - -## Objectives/Issues - -Contributors to and users of eSSIF-Lab come from various backgrounds. Their culture may not be Western. English may not be their native tongue. They may be experts in non-technological topics. Working with one another presumes a setting where participants have some level of shared understanding. Often, sharing one's understanding at a superficial level suffices. Other situations require that underlying concepts are shared in a more in-depth fashion. It's like cars: people buying, selling, or driving cars do not need in-depth shared knowledge about cars, whereas (maintenance or construction) engineers or liability lawyers need to share a deeper knowledge of how cars do (or do not) work. - -We expect to see situations of "language confusion", i.e. in which people use words or phrases, the intension (not: intention) of which differs from the interpretation of some listeners/readers. Sometimes a casual glance at a dictionary or glossary is the solution. In other cases, deeper understanding matters, e.g. in when drafting specifications or contracts. Then we need more than a set of definitions. - -The Concepts and Terminology part of eSSIF-Lab aims helps eSSIF-Lab community participants understand one another at whatever level of precision they need. - -## Scope URI - - -## Inclusions - - -## Notes - - -## Tags - - - diff --git a/docs/terminology/templates/template-concept-proposal.mdx b/docs/terminology/templates/template-concept-proposal.mdx deleted file mode 100644 index f5b4648..0000000 --- a/docs/terminology/templates/template-concept-proposal.mdx +++ /dev/null @@ -1,70 +0,0 @@ ---- -id: ExistingScopeID-conceptproposal-NewTermID -title: "Concept proposal for: (Scope: )" -scopeid: -term: -hoverText: "" ---- - - -## One-line Summary -A single sentence that describe the concept to a layperson with reasonable accuracy. This line may be used to explain `Concept` in a glossary, or as a popover text when it is referred to in other documentation. - -For example: "A warm-blooded animal, often having fur or hair, that produces milk to feed its young." - -## Short Description -in 1-3 sentences that describe the concept to a layperson with reasonable accuracy. - -For example, the concept of a "mammal" in biology might be described as: "A warm-blooded animal, often having fur or hair, that produces milk to feed its young. Examples include rats, whales, and bats." A diagram could be included, if appropriate. The goal here is not perfect clarity; that's the focus of the 'Criteria' section. - -## 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? - -## 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 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 vertibrate that has mammary glands, a neocortex in the brain and 3 middle ear bones. - -## Examples -Provide a few sentences in which you give examples that obviously qualify as instances of NewTerm, and that do NOT obviously qualify. Also, provide examples that are not (so) obvious, but help users to better understand its intension. - -Primates (humans, monkeys), rodents (mice, rats), bats, and others qualify. Birds and reptiles do not (they lack mammary glands). [Platypus](https://en.wikipedia.org/wiki/Platypus)[^1] is also a mammal, even though it lays eggs. - -## Related Concepts -Link to any concepts that are similar but distinct, with a note about the relationship. For example: - -* offspring (of a mammal) is the set of mammals that are born from that mammal. -* mate (of a mammal) is any mammal of the same species with which the mammal has created ofspring. - -## Domains -In which general knowledge ecosystems or mental model families does this concept play a role? For example: - -* Biology - -## Tags -Add hash tags here that allow us to group concepts in useful ways. - -## Use-cases - - -## Notes - - - -- GitLab From 51ee69d9fc86e360faac3bd93bb27b3f85a804ea Mon Sep 17 00:00:00 2001 From: RieksJ Date: Mon, 12 Oct 2020 10:26:45 +0200 Subject: [PATCH 02/26] Work in progress (suitable to be merged) --- README.md | 34 ++++++++++---- docs/essif-lab-functional-architecture.md | 8 +++- docs/essif-lab-vision-and-purpose.md | 28 ++++++----- docs/glossary.md | 2 +- docs/pattern-list.md | 2 +- docs/terms/business-transaction.md | 18 ++++++++ docs/terms/colleague.md | 14 ++++++ docs/terms/corpus.md | 4 ++ docs/terms/credential.md | 19 ++++++++ docs/terms/digital-colleague.md | 16 +++++++ docs/terms/digital-policy.md | 21 +++------ docs/terms/holder.md | 4 +- docs/terms/issuer.md | 4 +- docs/terms/mental-model.md | 6 ++- .../pattern-mandates-delegation-hiring.md | 5 +- docs/terms/pattern-terminology.md | 24 ++-------- docs/terms/policy.md | 31 +++++++++++++ docs/terms/presentation-request.md | 13 ++++++ docs/terms/risk.md | 10 +--- docs/terms/ssi-agent.md | 11 +++-- docs/terms/transaction-result-dispatcher.md | 10 ++-- docs/terms/transaction-validation-engine.md | 46 +++++++++++++------ docs/terms/trd-policy.md | 26 +++++------ docs/terms/trd.md | 2 +- docs/terms/tve-policy.md | 32 ++++++------- docs/terms/tve.md | 2 +- docs/terms/validated-data.md | 14 ++++++ docs/terms/verifiable-credential.md | 19 ++++++++ docs/terms/verified-data.md | 14 ++++++ docs/terms/verifier.md | 4 +- docs/terms/wallet.md | 4 +- 31 files changed, 311 insertions(+), 136 deletions(-) create mode 100644 docs/terms/business-transaction.md create mode 100644 docs/terms/colleague.md create mode 100644 docs/terms/credential.md create mode 100644 docs/terms/digital-colleague.md create mode 100644 docs/terms/policy.md create mode 100644 docs/terms/presentation-request.md create mode 100644 docs/terms/validated-data.md create mode 100644 docs/terms/verifiable-credential.md create mode 100644 docs/terms/verified-data.md diff --git a/README.md b/README.md index 81130d2..622d646 100644 --- a/README.md +++ b/README.md @@ -1,28 +1,42 @@ # eSSIF-Lab Framework -This repo contains the source documents of the [eSSIF-Lab framework](https://essif-lab.pages.grnet.gr/framework/), such as its vision, architecture and other relevant topics. +This repo contains files that are used to generate the the [eSSIF-Lab framework](https://essif-lab.pages.grnet.gr/framework/) website, which includes the eSSIF-Lab vision, functional architecture, terminology and other relevant topics. -## Writing docs +This website is generated using [Docusaurus 2](https://v2.docusaurus.io/) (and a custom plugin developed by [GRNET](https://grnet.gr/en/) for handling terminology). -This website is built using [Docusaurus 2](https://v2.docusaurus.io/). +## Writing Docusaurus Documents -Documentation content must appear in `.md` files inside the `docs` folder. +Docusaurs requires documentation content to appear in `.md` files inside the `docs` folder. Each file defines the following attributes at its very beginning: - `id`, by which the file is referred to across the project - `title`, appearing at the top of the file's display - `sidebar_label`, the file's name appearing in the sidebar -The `sidebars.js` file contains the basic mechanism for distributing content -among sections and is self-explanatory (compare with the sidebar appearing [here](https://essif-lab.pages.grnet.gr/essif-lab/docs/introduction)). Subsections within the `.md` file -(that is, tagged with `##`) will appear at the right part of the page -(see for example [here](https://essif-lab.pages.grnet.gr/essif-lab/docs/infrastructure)). +Documentation on these and other header fields can be found [here](https://v2.docusaurus.io/docs/markdown-features#markdown-headers). -Images must be put inside the directory `static/images` and developers must refer to them using _relative_ urls. +The Terminology Engine plugin of GRNET uses additional header fields. These are (or will be) defined [here](./docs/terminology-contributions). + +The `sidebars.js` file contains the basic mechanism for [distributing content among sections](https://v2.docusaurus.io/docs/docs-introduction#sidebar) and is self-explanatory (compare with the sidebar appearing [here](https://essif-lab.pages.grnet.gr/essif-lab/docs/introduction)). Subsections within the `.md` file (that is, tagged with `##`) will appear at the right part of the page (see for example [here](https://essif-lab.pages.grnet.gr/essif-lab/docs/infrastructure)). + +## Inserting Images in docs + + +If you want to add an image, say `example.png`, here is what you do: +- first, add the image to the `/static/images` directory (or `/static/images/subdir-path/`) +- then, in your document, add a line behind the docusaurus header that says: `import useBaseUrl from '@docusaurus/useBaseUrl';` +- next, in your document, at the place where you want the image to be presented, insert the following snippet: +```html +text-that-shows-if-the-image-cannot-be-found +``` +(or `src={useBaseUrl('images/subdir-path/example.png')}` if you added the image file there). ### Installation diff --git a/docs/essif-lab-functional-architecture.md b/docs/essif-lab-functional-architecture.md index 3106481..bd9036e 100644 --- a/docs/essif-lab-functional-architecture.md +++ b/docs/essif-lab-functional-architecture.md @@ -14,7 +14,11 @@ The purpose of the functional architecture and its views is to ## 1. Basic Terminology -In order to serve such purposes, we have found out that it is necessary that to make a strict and consequent distinction between people and Organizations that are capable of making decisions and bearing responsibility/accountability (we will use the term ‘%%Party|party%%’ for that) and people and ‘things’ that are capable of acting/doing things (we will use the term ‘%%Actor|actor%%’ for that). This means that an Organization is always a Party, whereas we consider a person to be a Party at one time and an Actor at another time, and computers/robots (and SSI components) are always an Actor. +In order to serve such purposes, we have found out that it is necessary that to make a strict and consequent distinction between people and Organizations that are capable of making decisions and bearing responsibility/accountability (we will use the term ‘%%Party|party%%’ for that) and people and ‘things’ that are capable of acting/doing things (we will use the term ‘%%Actor|actor%%’ for that). All %%Organizations|organization%% are %%Parties|party%%, whereas we consider a person (human being) to be both a %%Party|party%% (in cases where reasoning, decision making and bearing responsibility are in order), and an %%actor|actor%% (in cases where the person is actually doing things). More details backgrounds are given in the %%mental model|mental-model%% '%%Parties, Actors and Actions|pattern-party-actor-action%%' and the documentation of the concepts used therin. + +:::note Editor's note +TNO to edit remainder of this section (make it shorter), because users can click on the various terms if they want to know more. +::: This distinction is necessary because Actors do things that Parties are accountable for. In order to know which Party is accountable for what actions, we need the ability to link Parties and Actors. When an Actor acts and a (single) specific Party is accountable for that, we say that the Actor is an ‘%%Agent|agent%%’ for or of that Party (at that particular point in time). We say that this Actor acts ‘**on behalf of**’ that Party. Note that both humans and (running) applications may serve as Agents (human Agent or digital/electronic Agent respectively). A digital Agent that has one or more of the SSI functionalities we describe further down will be called an '%%SSI-Agent|ssi-agent%%', and we say that the Party on whose behalf it operates is the ‘%%Owner|owner%%’ of that Agent. Also, we use the term '**(digital/electronic or human) Colleague (of an Agent)**' to refer to any other (electronic or human) Agent that acts on behalf of the same Party as this Agent. @@ -26,7 +30,7 @@ Also, to serve the aforementioned purposes, we cannot fix the architecture (and ## 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|party%% (meaning that they are all part of the same %%organization|organization%% as defined above, and they are all %%(digital) ‘Colleagues’|digital-colleague%% 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 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*. diff --git a/docs/essif-lab-vision-and-purpose.md b/docs/essif-lab-vision-and-purpose.md index a526770..c7cbb6d 100644 --- a/docs/essif-lab-vision-and-purpose.md +++ b/docs/essif-lab-vision-and-purpose.md @@ -4,24 +4,23 @@ title: eSSIF-Lab Vision and Purpose sidebar_label: Vision and Purpose --- +import useBaseUrl from '@docusaurus/useBaseUrl'; + The eSSIF-Lab vision is that Self-sovereign Identity (SSI) will *empower European and other citizens* by providing new means to manage privacy by eliminating logins and making electronic transactions fast and safe both in the Internet and in physical life. SSI will *empower European organisations and governments* by providing new means to speed up, secure and automate transactions with citizens, customers, suppliers and partners, resulting in tens of billions of euros savings annually on administrative costs in Europe. SSI will be *a new business ecosystem paradigm* with thousands of new jobs, many new job categories and new business opportunities for existing and new European companies. And last, but certainly not least, SSI fosters *inclusiveness* and supports organizations and citizens to exercise their rights and fulfil their duties under the GDPR. The current situation is that SSI solutions that are being created and brought to the market either target specific applications for which they provide a vertical solution (‘stovepipes’), many need some kind of centralized governance/control, others have privacy issues, and none that we know of are interoperable with other such solutions. -The situation we would like to see is one in which we have SSI-enabled, interoperable and scalable technologies, that form an infrastructure that every application in any vertical can use in a very easy manner, for the exchange of verified (personal and non-personal) data. In that situation people, businesses and governments think more about the information they need and/or provide as they conduct business transactions. They no longer need to be concerned about the SSI technologies that have empowered them to make this happen. +The situation we would like to see is one in which we have SSI-enabled, interoperable, scalable and business/information agnostic technologies, that form an infrastructure that every application for every party can use to serve its own objectives. This infrastructure, that enables the electronic exchange of verified (personal and non-personal) data, must be so easy to access and use for such parties that they will no longer need to be concerned about actual (SSI) technologies that have empowered them to make this happen. Rather, they will only need to think about, and decide which kinds of information they want to obtain for conducting specific business transactions and which parties they trust for providing such information. Also, they will need to think about, and decide which kinds of information they themselves are willing to provide to others in this new SSI world. :::tip **The purpose of the eSSIF-Lab...** ... is to specify, develop and validate technological and non-technological means that support people, businesses and governments to think about, design and operate their (information) processes and (electronically) conduct business transactions with one another. ::: -The context of the eSSIF-Lab vision can be found in articles 8-10 of the [*European Convention on Human Rights (ECHR)*](https://www.echr.coe.int/Pages/home.aspx?p=basictexts/convention), that state the rights of individuals regarding their privacy, and their freedoms to collect, process, store, and express information in a self-sovereign fashion, i.e. in a way that they can decide for themselves. This is without prejudice to Member States’ laws that exist to protect their national security, public safety, the economic well-being of the country, health or morals or the rights and freedoms of others, or to prevent disorder or crime. The eSSIF-Lab vision extends these rights and freedoms - within the limits of the law - to public and private organizations. Thus, we say that individuals as well as public and private organizations (that we collectively refer to as ‘parties’) are self-sovereign[1]. - -In the context of these rights and freedoms, we seek to support electronic business transactions, i.e. the electronic exchange of goods, services, funds, or data between parties, which we call ‘participants’ to the transaction[2]. +The context of the eSSIF-Lab vision can be found in articles 8-10 of the [*European Convention on Human Rights (ECHR)*](https://www.echr.coe.int/Pages/home.aspx?p=basictexts/convention), that state the rights of individuals regarding their privacy, and their freedoms to collect, process, store, and express information in a self-sovereign fashion, i.e. in a way that they can decide for themselves. This is without prejudice to Member States’ laws that exist to protect their national security, public safety, the economic well-being of the country, health or morals or the rights and freedoms of others, or to prevent disorder or crime. The eSSIF-Lab vision extends these rights and freedoms - within the limits of the law - to public and private organizations. Thus, we say that individuals as well as public and private organizations (that we collectively refer to as ‘parties’) are self-sovereign[^1]. -An electronic business transaction is a business transaction that requires each participant to have (at least one) electronic agent, i.e. equipment (e.g. an app on a mobile phone, a webserver, a browser, …) that acts on behalf of its owner in the transaction. - -An electronic business transaction is a business transaction that requires each participant to have (at least one) electronic agent, i.e. equipment (e.g. an app on a mobile phone, a web server, a browser, …) that acts on behalf of its owner in the transaction. +In the context of these rights and freedoms, we seek to support %%electronic business transactions|business-transaction%%, i.e. the electronic exchange of goods, services, funds, or data between parties, which we call ‘participants’ to the transaction[^2]. +An electronic business transaction is a business transaction that requires each participant to have (at least one) electronic %%(digital) agent|digital-agent%%, i.e. equipment (e.g. an app on a mobile phone, a webserver, a browser, …) that acts on behalf of its owner in the transaction. ## High-Level Example of a Business Transaction @@ -33,18 +32,23 @@ Perhaps the most important contribution that the eSSIF-Lab project aims to make, The figure below is a high-level visualization of the filling in and validation parts: -![eSSIF-Lab - vision context](https://essif-lab.pages.grnet.gr/framework//images/vision-context.png) *Figure 1. High-level visualization of the filling in and validation of a form.* +High-level visualization of the filling in and validation of a form. + +*Figure 1. High-level visualization of the filling in and validation of a form.* The transaction that is envisaged here is the issuing of a parking permit. Participants are a person (requestor) that requests such a permit, and an organization (provider) that can issue such a permit. The requestor has one electronic agent, *the Requestor Agent (RA)*, i.e. an SSI-aware app on their mobile phone that can access a secure storage that contains ‘credentials’, i.e. data that is digitally signed by some third party, thus attesting to the truth of that data. The provider has two agents: one is an SSI-aware component *Provider Agent (PA_* that works with the web-server that presents the form, and the other is a person *P* whose task is to validate any data (on behalf of the provider) that is not validated electronically. The form itself contains a means, e.g. a QR-code or a deep-link, that allows *RA* and *PA* to set up a secure communications channel (e.g. SSL, [DIDComm](https://openssi.github.io/peer-did-method-spec/)) and agree on the specific form that needs to be filled in. -After the *RA* and *PA* have established a communications channel and agree on the form to be filled in, *PA* informs *RA* about the information it needs to fill in the form, and the requirements that this information should satisfy[3]. *RA* then checks its data store to see whether or not such data is available, sends such data to *PA*, which subsequently validates it and uses it to fill in (appropriate parts of) the form. Finally, *P* validates the remaining data, which either results in a ‘clean’ form, i.e. a form that contains valid data that can subsequently be used to decide whether or not to provide the parking permit, or a message to the requester informing him about missing and/or invalid data. +After the *RA* and *PA* have established a communications channel and agree on the form to be filled in, *PA* informs *RA* about the information it needs to fill in the form, and the requirements that this information should satisfy[^3]. *RA* then checks its data store to see whether or not such data is available, sends such data to *PA*, which subsequently validates it and uses it to fill in (appropriate parts of) the form. Finally, *P* validates the remaining data, which either results in a ‘clean’ form, i.e. a form that contains valid data that can subsequently be used to decide whether or not to provide the parking permit, or a message to the requester informing him about missing and/or invalid data. When the transaction has been completed, both participants can issue a credential that attests to the results of the transaction. For example, the provider could issue a credential stating that the requestor has obtained a parking permit for a car with a specific plate number (and other attributes). The requestor can store this credential and from that moment on use it in new electronic transactions. -------- -[1] We realize that by doing this we have a different definition of what self-sovereignty entails than many others. We are open to suggestions for a better phrase. +[^1]: We realize that by doing this we have a different definition of what self-sovereignty entails than many others. We are open to suggestions for a better phrase. -[2] A good mental model for describing and designing transactions and their participants is provided by [*DEMO*](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations). +[^2]: A good mental model for describing and designing transactions and their participants is provided by [*DEMO*](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations). -[3] Since transactions are symmetric, the requestor could also have a form that the provider needs to fill in so as to provide the requestor with the data it needs to commit to that transaction. We have left that out of this description for the sake of simplicity. +[^3]: Since transactions are symmetric, the requestor could also have a form that the provider needs to fill in so as to provide the requestor with the data it needs to commit to that transaction. We have left that out of this description for the sake of simplicity. diff --git a/docs/glossary.md b/docs/glossary.md index f6f8795..769dced 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -4,7 +4,7 @@ title: "eSSIF-Lab Glossary" sidebar_label: Glossary --- -:::note Editor's note +:::info Editor's note TNO to write the introduction paragraph Remainder of file to be generated (GRNET plugin/extension) ::: diff --git a/docs/pattern-list.md b/docs/pattern-list.md index 729dda1..6bcc69e 100644 --- a/docs/pattern-list.md +++ b/docs/pattern-list.md @@ -4,7 +4,7 @@ title: "eSSIF-Lab List of Patterns" sidebar_label: Mental Models --- -:::note Editor's note +:::info Editor's note TNO to write the introduction paragraph Remainder of file to be generated (GRNET plugin/extension) ::: diff --git a/docs/terms/business-transaction.md b/docs/terms/business-transaction.md new file mode 100644 index 0000000..452f4fc --- /dev/null +++ b/docs/terms/business-transaction.md @@ -0,0 +1,18 @@ +--- +id: business-transaction +title: "Business Transaction" +scopeid: essifLab +type: concept +typeid: business-transaction +stage: draft +hoverText: "Business Transaction: the electronic exchange of goods, services, funds, or data between parties (called‘participants’ to the transaction)" +--- + +:::info Editor's note +TNO to provide the content of this file. +::: + + +### Notes + +1. A good mental model for describing and designing business transactions and their participants is provided by [*DEMO*](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations). \ No newline at end of file diff --git a/docs/terms/colleague.md b/docs/terms/colleague.md new file mode 100644 index 0000000..a492963 --- /dev/null +++ b/docs/terms/colleague.md @@ -0,0 +1,14 @@ +--- +id: colleague +title: "Colleague" +scopeid: essifLab +type: concept +typeid: colleague +stage: draft +hoverText: "Colleague (of an Agent): An actor that is an Agent for the same Principal." +--- + +:::info Editor's note +TNO to provide the content of this file. +::: + diff --git a/docs/terms/corpus.md b/docs/terms/corpus.md index e657f6a..b89c192 100644 --- a/docs/terms/corpus.md +++ b/docs/terms/corpus.md @@ -7,3 +7,7 @@ typeid: corpus stage: draft hoverText: "Corpus (of Terminology): the documentation that describes the knowledge around a set of terms and concepts." --- + +:::info Editor's note +TNO to provide the content of this file. +::: diff --git a/docs/terms/credential.md b/docs/terms/credential.md new file mode 100644 index 0000000..53f8776 --- /dev/null +++ b/docs/terms/credential.md @@ -0,0 +1,19 @@ +--- +id: credential +title: "Credential" +scopeid: essifLab +type: concept +typeid: credential +stage: draft +hoverText: "Credential: data, representing a set of statements made by one party (the author of the credential)." +--- + +:::info Editor's note +TNO to provide the content of this file. +::: + +### Related Concepts +- %%verifiable credential|verifiable-credential%% +- %%verified data|verified-data%% +- %%validated data|validated-data%% + diff --git a/docs/terms/digital-colleague.md b/docs/terms/digital-colleague.md new file mode 100644 index 0000000..80b36a1 --- /dev/null +++ b/docs/terms/digital-colleague.md @@ -0,0 +1,16 @@ +--- +id: digital-colleague +title: "Digital Colleague" +scopeid: essifLab +type: term +typeid: digital-colleague +conceptref: ":Colleague" +stage: draft +hoverText: "Digital Colleague (of an Agent): a digital actor that is an agent of the same principal." +--- + +### Purpose + +The ability to distinguish between (non)digital colleagues allows us to reason and communicate about the set of %%digital actors|digital-actor%% that are %%agents|agent%% for a single **principal|principal%%. + +See also: %%colleague|colleague%%. diff --git a/docs/terms/digital-policy.md b/docs/terms/digital-policy.md index 94fa17b..9aedb1c 100644 --- a/docs/terms/digital-policy.md +++ b/docs/terms/digital-policy.md @@ -2,27 +2,18 @@ id: digital-policy title: "Digital Policy" scopeid: essifLab -type: term +type: concept typeid: digital-policy conceptref: ":Policy" stage: draft -hoverText: "Digital Policy: a (set of) machine readable rules, working instructions or other guidance for the execution of one or more kinds of actions, that digital agents have access to and must use when executing such actions." +hoverText: "Digital Policy: a machine-readable document that contains rules, working instructions or other guidance for digital agents so as to enable them to execute actions on behalf of the author of that policy." --- ### Short Description -A **digital policy** is a (set of) machine readable rules, working instructions or other guidance for the execution of one or more kinds of %%actions|action%%. A %%digital agent|digital-agent%% must have access to the digital policy that its %%principal|principal%% has established for the kind of action that the agent is executing on the principal's behalf. - -It should be part of the principal's governance processes to establish, maintain and evaluate digital policies for every kind of action that its agents may execute. - -The principal must ensure that its %%digital actors|digital-actor%% can access the appropriate policies when needed. +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. ### Purpose -The purpose of **digital policies** is to enable %%parties|party%% to provide its %%digial agents|digital-agent%% with the rules and other guidance that they need to automaticallly execute %%actions|action%% that comply with such rules. - -### Criterion -A **digital policy** is -- a (set of) machine readable rules, working instructions or other guidance for the execution of one or more kinds of %%actions|action%%; -- is authored by a single %%Party|party%% (the author or %%owner|owner%% of the digital policy); -- is accessable to, and must be complied with by a %%digital agent|digital-agent%% of that policy's author when it executes an action of the kind to which the digital policy applies. - + +The ability to distinguish between (non)digital policies allows us to exclusively talk about machine-readable policies, i.e. policies that are to be used by harsoftware/hardware %%actors|actor%%. +See also: %%Policy|policy%%. \ No newline at end of file diff --git a/docs/terms/holder.md b/docs/terms/holder.md index 13055bb..c21ec92 100644 --- a/docs/terms/holder.md +++ b/docs/terms/holder.md @@ -9,13 +9,13 @@ hoverText: "Holder: a functional component that is capable of " --- ## Short Description -A **Holder** is an (architectural) function that handles Presentation Requests that it receives from %%verifier|verifier%% components (both of its %%owner|owner%%, and of other %%parties|party%%). 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 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. ## Purpose The purpose of the Holder component is to handle Presentation Requests that it receives from %%verifier|verifier%% components (both of its own %%owner|owner%%, and of other %%parties|party%%), and responding to such requests. ## Criteria -A **Holder** is a component in the [eSSIF-Lab functional architecture](..\functional-architecture\) whose function is to handle Presentation Requests that it receives from %%verifier|verifier%% components (both of its %%owner|owner%%, and of other %%Parties|party%%). +A **Holder** is a component in the [eSSIF-Lab functional architecture](../functional-architecture) whose function is to handle Presentation Requests that it receives from %%verifier|verifier%% components (both of its %%owner|owner%%, and of other %%Parties|party%%). ## Functionality diff --git a/docs/terms/issuer.md b/docs/terms/issuer.md index ffd67ff..0e6ac68 100644 --- a/docs/terms/issuer.md +++ b/docs/terms/issuer.md @@ -9,14 +9,14 @@ hoverText: "Issuer: a functional component that is capable of " --- ## Short Description -The **issuer** is an (architectural) function that structures sets of (related) statements/claims (e.g. as produced by the %%TRD|trd%%) in a packate, adds metadata which includes e.g. a timestamp at which this was done, ensures that it is digitally signed on behalf of its %%owner|owner%%, signature by which third Parties can prove its provenance and integrity. Another function of the issuer is to handle revocation (and (un)suspension) of credentials that it has issued. For such tasks, it relies on functions that are made available by the SSI Protocols and Crypto Layer. +An **issuer** is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that structures sets of (related) statements/claims (e.g. as produced by the %%TRD|trd%%) in a packate, adds metadata which includes e.g. a timestamp at which this was done, ensures that it is digitally signed on behalf of its %%owner|owner%%, signature by which third Parties can prove its provenance and integrity. Another function of the issuer is to handle revocation (and (un)suspension) of credentials that it has issued. For such tasks, it relies on functions that are made available by the SSI Protocols and Crypto Layer. ## Purpose The purpose of the Issuer function is. ## Criteria -A **Issuer** is a component in the [eSSIF-Lab functional architecture](..\functional-architecture\) whose function is to ... (tbd). +A **Issuer** is a component in the [eSSIF-Lab functional architecture](../functional-architecture) whose function is to ... (tbd). ## Functionality diff --git a/docs/terms/mental-model.md b/docs/terms/mental-model.md index 54eb40e..ac790ea 100644 --- a/docs/terms/mental-model.md +++ b/docs/terms/mental-model.md @@ -9,4 +9,8 @@ stage: draft hoverText: "Mental Model: a casual and formal description (pattern) of a set of concepts, relations between them, and constraints, that provide a specific 'viewpoint', or 'way of thinking' about a certain topic." --- -see: %%pattern|pattern%%. \ No newline at end of file +:::info Editor's note +TNO to provide the content of this file. +::: + +See also: %%pattern|pattern%%. \ No newline at end of file diff --git a/docs/terms/pattern-mandates-delegation-hiring.md b/docs/terms/pattern-mandates-delegation-hiring.md index 7c46b20..af00d4b 100644 --- a/docs/terms/pattern-mandates-delegation-hiring.md +++ b/docs/terms/pattern-mandates-delegation-hiring.md @@ -10,6 +10,7 @@ hoverText: "The Mandates, Delegation and Hiring pattern (which remains to be doc import useBaseUrl from '@docusaurus/useBaseUrl'; -:::info Editors Note -TNO is expected to produce the first draft of this document +:::info Editor's note +TNO to provide the content of this file. ::: + diff --git a/docs/terms/pattern-terminology.md b/docs/terms/pattern-terminology.md index 00df4e8..83a66ae 100644 --- a/docs/terms/pattern-terminology.md +++ b/docs/terms/pattern-terminology.md @@ -10,24 +10,6 @@ hoverText: "The eSSIF-Lab Terminology Pattern describes the relations between te import useBaseUrl from '@docusaurus/useBaseUrl'; -### Purpose - - -### Introduction - - -### Notations - - -## - - - \ No newline at end of file +:::info Editor's note +TNO to provide the content of this file. +::: diff --git a/docs/terms/policy.md b/docs/terms/policy.md new file mode 100644 index 0000000..162d089 --- /dev/null +++ b/docs/terms/policy.md @@ -0,0 +1,31 @@ +--- +id: policy +title: "Policy" +scopeid: essifLab +type: concept +typeid: policy +stage: draft +hoverText: "Policy: a (set of) rules, working instructions or other guidance for the execution of one or more kinds of actions, that agents (a) have access to, (b) can interpret as intended by their principal (i.e. policy owner) and (c) must use when executing such actions." +--- + +### Short Description +A **policy** is a (set of) rules, working instructions and/or other guidance for the execution of one or more kinds of %%actions|action%%. that agents (a) have access to, (b) can interpret as intended by their principal (i.e. policy owner) and (c) must use when executing such actions. + +An %%agent|agent%% must have access to the policy that its %%principal|principal%% has established for the kind of action(s) that the agent is executing for its principal. This requires that the policy be readable by the agent, and that the agent is capable of interpreting it as intended by its principal. + +It should be part of the %%principal's|principal%% governance processes + +- to establish, maintain and evaluate policies for every kind of action that its agents may execute, +- to derive artifacts from such policies that are useable by the various %%agents|agent%% (digital, human, or otherwise) that have a right or duty to execute actions for the %%principal|principal%% to which such policies apply. So, machine-readable policies should be derived for %%digital-agents|digital-agent%%, and human-readable policies (in different languages if that is appropriate) for non-digital agents. +- to 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). + +### 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. + +### Criterion +A **policy** is +- a (set of) rules, working instructions and/or other guidance for the execution of one or more kinds of %%actions|action%%; +- is authored by a single %%Party|party%% (the author or %%owner|owner%% of the policy); +- may have multiple representations of the rules, working instructions and/or other guidance, which are derived from the policy itself, in such a way that that any %%actor|actor%% that has a right or duty to execute an %%action|action%% on behalf of the policy's author can do so according to its intentions; +- is accessable to, and must be complied with by an %%agent|agent%% of that policy's author when it executes an action of the kind to which the policy applies. diff --git a/docs/terms/presentation-request.md b/docs/terms/presentation-request.md new file mode 100644 index 0000000..954e741 --- /dev/null +++ b/docs/terms/presentation-request.md @@ -0,0 +1,13 @@ +--- +id: presentation-request +title: "Presentation Request" +scopeid: essifLab +type: concept +typeid: presentation-request +stage: draft +hoverText: "Presentation Request: a (signed) digital message that a verifier component sends to a holder component asking for data from one or more verifiable credentials." +--- + +:::info Editor's note +TNO to provide the content of this file. +::: diff --git a/docs/terms/risk.md b/docs/terms/risk.md index cb82e2b..aac3995 100644 --- a/docs/terms/risk.md +++ b/docs/terms/risk.md @@ -8,16 +8,10 @@ stage: draft hoverText: "Risk: the deviation of the expected realization (e.g. results) of an objective of a party." --- -:::info Editors Note -TNO is expected to produce the first draft of this document +:::info Editor's note +TNO to provide the content of this file. ::: -### Short Description - -### Purpose - -### Criterion - ### References [1]: NRM, [ISO 27000:2016](https://www.iso.org/obp/ui#iso:std:iso-iec:27000:ed-4:v1:en) \ No newline at end of file diff --git a/docs/terms/ssi-agent.md b/docs/terms/ssi-agent.md index e68b4a1..83597c4 100644 --- a/docs/terms/ssi-agent.md +++ b/docs/terms/ssi-agent.md @@ -6,13 +6,14 @@ type: term typeid: ssi-agent conceptref: essifLab:Agent stage: draft -hoverText: "SSI-Agent: an agent that provides SSI services." +hoverText: "SSI-Agent: a digital agent that provides one or more of the SSI functionalities (issuer, holder, verifier, wallet) to its principal." --- +### Short Description +An **SSI-agent** is a %%digital agent|digital-agent%% that provides one or more of the SSI functionalities (i.e. %%issuer|issuer%%, %%holder|holder%%, %%verifier|verifier%%, %%wallet|wallet%%) to its %%principal|principal%%. + ### Purpose +The ability to distinguish between (non)SSI agents allows us to exclusively talk about agents that provide some or all of the SSI functionalities (i.e. %%issuer|issuer%%, %%holder|holder%%, %%verifier|verifier%%, %%wallet|wallet%%). - -### Notes - - +See also: %%digital agent|digital-agent%%, and %%agent|agent%%. diff --git a/docs/terms/transaction-result-dispatcher.md b/docs/terms/transaction-result-dispatcher.md index 761fd1f..d112d36 100644 --- a/docs/terms/transaction-result-dispatcher.md +++ b/docs/terms/transaction-result-dispatcher.md @@ -9,12 +9,12 @@ hoverText: "Transaction Result Dispatcher (TRD): a functional component that is --- ## Short Description -A **Transaction Result Dispatcher (TRD)** is a functional component that applications (that work for some %%Party%%) can call to communicate things such as: +A **Transaction Result Dispatcher (TRD)** is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that applications (that work for some %%Party|party%%) can call to communicate things such as: - the results of a business transaction (e.g. statements to confirm that a transaction happened, thereby supplying appropriate details) - the status of a business transaction (e.g. that an order has been received in good order, that delivery of an order is dealyed or otherwise changed) - knowledge (including judgements) that this Party has about %%Entities|entity%% (people, organizations, things, orders, deliveries, etc.) -The TRD uses a %%TRD-policy|trd-policy%% to learn about the applicable (business) rules of the %%Party%% on whose behalf it works. +The TRD uses a %%TRD-policy|trd-policy%% to learn about the applicable (business) rules of its %%principal|principal%%. Such a policy may specify e.g. which types of credentials its principal is willing to (have) issue(d), to whom such credentials may be issued and the kinds of assurances that must be obtained before doing so, etcetera. The TRD uses the %%eSSIF-Glue|essif-glue%% interface to access the %%Wallet|wallet%%, %%Holder|holder%%, %%Issuer|issuer%% and %%Verifier|verifier%% functionalities. @@ -22,14 +22,14 @@ The TRD uses the %%eSSIF-Glue|essif-glue%% interface to access the %%Wallet|wall The purpose of the TRD component is to state the (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other Parties. A special kind of result is the (provisioning of) a credential that its Owner already has created. ## Criteria -A **Transaction Result Dispatcher (TRD)** is a component in the [eSSIF-Lab functional architecture](..\functional-architecture\) that is capable of stating (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other %%Parties|Party%%. +A **Transaction Result Dispatcher (TRD)** is a component in the [eSSIF-Lab functional architecture](../functional-architecture) that is capable of stating (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other %%Parties|party%%. ## Functionality Typically, and at any point in time, Parties are capable of expressing statements about entities that they know to exist. They could express statements about individuals, about themselves, the state of transactions, and so on. We will use the term ‘**subject (of a statement of a Party)**’ to refer to the entity that this Party knows to exist, and about whom/which the statement has been made. We will use the term ‘**subject-id (of a statement of a Party)**’ to refer to the representation that this Party has chosen to use for referring to the subject in said statement. A subject-id must have the property of being an identifier within every administrative context that this Party uses. It need not be humanly interpretable (and preferably is not). -Parties need to specify the kinds of credentials they are willing to issue, the class of entities (e.g. people, cars, Organizations) for which it will issue them, and the information schema (structure) that it will use in credentials of such kinds.[TRD.1] This allows the TRD to construct data objects that conform to this information schema, and present it to the Issuer component for actual issuing. +Parties need to specify the kinds of credentials they are willing to issue, the class of entities (e.g. people, cars, Organizations) for which it will issue them, and the information schema (structure) that it will use in credentials of such kinds.[^1] This allows the TRD to construct data objects that conform to this information schema, and present it to the Issuer component for actual issuing. The TRD Issuing Policy specifies the kinds of (linked-)data-objects that credentials may be created for. This allows the TRD to construct such a (linked-)data-objects for every subject-id that identifies a subject of the class for which a credential can be issued, which can subsequently be sent to the Issuer component that can turn it into a credential of a specific sort. @@ -39,4 +39,4 @@ The TRD may either push credential data to the Issuer component, so that the Iss ----- -[TRD.1] We assume/stipulate that the Party maintains a credential catalogue that contains this, and other information about every kind of credential that it issues, and that such catalogues are available to other Parties that want or need to use such credentials. +[^1]: We assume/stipulate that the Party maintains a credential catalogue that contains this, and other information about every kind of credential that it issues, and that such catalogues are available to other Parties that want or need to use such credentials. diff --git a/docs/terms/transaction-validation-engine.md b/docs/terms/transaction-validation-engine.md index 145de6f..3abd7f0 100644 --- a/docs/terms/transaction-validation-engine.md +++ b/docs/terms/transaction-validation-engine.md @@ -9,28 +9,43 @@ hoverText: "Transaction Validation Engine (TVE): a functional component that pro --- ## Short Description -A **Transaction Validation Engine (TVE)** is a functional component that provides business applications with forms that users have filled in, and where the content of such forms is valid for making decision(s) by this application. The TVE uses a %%TVE-policy|tve-policy%% to learn about the applicable (business) rules of the %%Party%% on whose behalf the TVE works. The TVE uses the %%eSSIF-Glue|essif-glue%% interface to access the %%Wallet|wallet%%, %%Holder|holder%%, %%Issuer|issuer%% and %%Verifier|verifier%% functionalities. +A **Transaction Validation Engine (TVE)** is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that provides business applications with forms that users have filled in, and where the content of such forms is valid for making decision(s) by this application. The TVE uses a %%TVE-policy|tve-policy%% to learn about the applicable (business) rules of the %%Party|party%% on whose behalf the TVE works. + +The TVE uses a %%TVE-policy|tve-policy%% to learn about the applicable (business) rules of its %%principal|principal%%. Such policy may specify which parties can be trusted to issue credentials of a specific kind, how the contents of such credentials map onto data elements as the %%principal|principal%% needs them, etcetera. + +The TVE 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 Validation Engine (TVE) is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an %%agent|agent%% of) its %%owner|owner%% to decide whether or not to engage in a (new) transaction of the specified type. ## Criteria -A **Transaction Validation Engine (TVE)** is a component in the [eSSIF-Lab functional architecture](..\functional-architecture\) whose function is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an %%agent|agent%% of) its %%owner|owner%% to decide whether or not to engage in a (new) transaction of the specified type. +A **Transaction Validation Engine (TVE)** is a functional component in the [eSSIF-Lab functional architecture](../functional-architecture) that +- services requests by %%digital|digital-agent%% and non-digital %%agents|agent%%, for providing a product or service, thereby starting a %%transaction|business-transaction%%; +- can set-up and tear-down communications channels of various kinds, with %%digital|digital-colleague%% and/or non-digital %%colleagues|colleague%% of that %%requesting agent|agent%%,[^peer-agents] as appropriate for the data exchanges that are needed to conduct the transactions; +- can use any appropriate communications channel with a %%peer-agent|peer-agent%% to: + - request for data that, according to the %%tve-policy|tve-policy%% is needed to decide whether or not to commit to the transaction; + - process the responses to such requests, in an orchestrated way, thereby complying with the rules of its %%principal's|principal%% %%tve-policy|tve-policy%%, the result of which (in the end) is a set of %%validated data|validated-data%% that can serve the purpose of deciding whether or not to commit to the transaction; + - receive similar requests from its %%peer-party%%, and respond to such requests in compliance with the rules of its %%principal's|principal%% %%tve-policy|tve-policy%%; +- has a mechanism to ensure that within a %%transaction|business-transaction%%, it uses the latest (most receent) %%tve-policy|tve-policy%% of its %%principal|principal%%. ## Functionality +:::info Editor's note +TNO to revise the text below. +::: + Typically, the TVE 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.[TVE.1] +- 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] In either case, a transaction form (object, context) has to be created that matches the kind of transaction, and a ‘**transaction-id**’ must be generated that identifies this form/object/context. It will be used for binding incoming or outgoing messages to this transaction, enabling communications to remain congruent, not only with the Agent that requested the transaction, but also with other Agents from the same Owner and/or using different communications channels. -Handling/managing the various communications channels through which data can be exchanged is also a task of the TVE[TVE.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). +Handling/managing the various communications channels through which data can be exchanged is also a task of the TVE[^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 TVE is generally considered capable of obtaining data through different communications channels. However, the technical tracks of eSSIF-Lab will exclusively focus on the communications channel through which credentials can be requested and obtained. Any extensions or business productization of TVE 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 TVE 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.[TVE.3] Also, when the TVE 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.[TVE.4] Also, as the TVE 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.[TVE.5] +In order to acquire data through SSI mechanisms for filling in a form for a specific kind of transaction, the TVE 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 TVE 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 TVE 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 TVE work, a Validation Policy (or TVE Policy) is created by, or on behalf of the Owner, which specifies at least: @@ -39,7 +54,7 @@ In order to make the TVE work, a Validation Policy (or TVE Policy) is created by - 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[TVE.6]. + - 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]. - for each kind of credential: the verification proofs that must hold to be accepted as a source for valid data. @@ -47,24 +62,27 @@ In order to make the TVE work, a Validation Policy (or TVE Policy) is created by 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 TVE Policy enable the TVE 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.[TVE.7] +The ability to create new transaction contexts and the availability of the TVE Policy enable the TVE 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] When the Verifier returns such data (which comes with a list of proofs that the Verifier has checked), the TVE 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 TVE 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 TVE itself must make validation decisions, either electronically (according to the TVE policy) or by ‘outsourcing’ such decisions to human Agents of its Owner by providing an appropriate validation user interface. As long as data is needed, the TVE can intermittently request the verifier to produce it (or it can use other communications channels, which is outside scope for now). It does so until it times out, or the form has become ‘clean’. ----- +### Notes: + +[^1 (peer-agents)]: Note that such agents have then become so-called %%peer-agents|peer-agent%% (of the TVE) for that specific transaction. Also, the (single!) %%principal|principal%% of these %%peer-agents|peer-agent%% is the %%peer-party|peer-party%% of the %%principal|principal%% of the TVE (again, for that specific transaction). -[TVE.1] This feature ensures that the transaction is really two-way, and both Parties can request credentials from the other. For example, a web-shop can then ask for a (delivery) address credential, and the customer can ask for a credential issued e.g. by the chamber of commerce that the web-shop is a legitimate company (and not some maffia website). +[^1]: This feature ensures that the transaction is really two-way, and both Parties can request credentials from the other. For example, a web-shop can then ask for a (delivery) address credential, and the customer can ask for a credential issued e.g. by the chamber of commerce that the web-shop is a legitimate company (and not some maffia website). -[TVE.2] It may well be that this functionality can somehow be split off in the (near) future. +[^2]: It may well be that this functionality can somehow be split off in the (near) future. -[TVE.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 TVE. 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 Owner of the TVE. 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. -[TVE.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 Owner have implemented. Mapping allows such cases to be accommodated for. -[TVE.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. +[^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. -[TVE.6] This enables the TVE to pass the endpoint URI on to the Verifier when it requests for such a credential, which in turn can send it to the holder of other Parties enabling them to obtain the credential from that issuer endpoint if that other Party does not have that credential in its wallet. The endpoint URI can in fact be put in the policy, because the (human) Agent that creates/maintains the policy would need to know that the issuing Party is actually issuing such credentials, what their contents means, etc., and hence is capable of tracking down the URI where that Party issues the credentials. +[^6]: This enables the TVE to pass the endpoint URI on to the Verifier when it requests for such a credential, which in turn can send it to the holder of other Parties enabling them to obtain the credential from that issuer endpoint if that other Party does not have that credential in its wallet. The endpoint URI can in fact be put in the policy, because the (human) Agent that creates/maintains the policy would need to know that the issuing Party is actually issuing such credentials, what their contents means, etc., and hence is capable of tracking down the URI where that Party issues the credentials. -[TVE.7] A reference to this specification will be added when it becomes available (draft or otherwise). +[^7]: A reference to this specification will be added when it becomes available (draft or otherwise). diff --git a/docs/terms/trd-policy.md b/docs/terms/trd-policy.md index 978cfbf..1a2818c 100644 --- a/docs/terms/trd-policy.md +++ b/docs/terms/trd-policy.md @@ -15,22 +15,22 @@ A **Transaction (Validation) Engine** or **TRD** is a functional component that The purpose of the Transaction (Validation) Engine (TRD) is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an %%agent|agent%% of) its %%owner|owner%% to decide whether or not to engage in a (new) transaction of the specified type. ## Criteria -A **Transaction (Validation) Engine** or **TRD** is a component in the [eSSIF-Lab functional architecture](..\functional-architecture\) whos function is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an %%agent|agent%% of) its %%owner|owner%% to decide whether or not to engage in a (new) transaction of the specified type. +A **Transaction (Validation) Engine** or **TRD** is a component in the [eSSIF-Lab functional architecture](../functional-architecture) whos function is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an %%agent|agent%% of) its %%owner|owner%% to decide whether or not to engage in a (new) transaction of the specified type. ## Functionality Typically, the TRD would start a transaction either - when it receives a request from some Agent of another Party for engaging in a transaction of a specific kind. -- when it is instructed by, or on behalf of its Owner, to request a specific kind of transaction to some Agent of another Party.[TRD.1] +- when it is instructed by, or on behalf of its Owner, to request a specific kind of transaction to some Agent of another Party.[^1] In either case, a transaction form (object, context) has to be created that matches the kind of transaction, and a ‘**transaction-id**’ must be generated that identifies this form/object/context. It will be used for binding incoming or outgoing messages to this transaction, enabling communications to remain congruent, not only with the Agent that requested the transaction, but also with other Agents from the same Owner and/or using different communications channels. -Handling/managing the various communications channels through which data can be exchanged is also a task of the TRD[TRD.2]. One reason for this is that negotiating a transaction not only requires data to be acquired, but also to be provided to the peer participant. Another reason is that the peer participant may use multiple Agents to provide such data, e.g. human Agents (that might use web-browsers, social-media apps, phones, or physical visits), SSI Agents (that use the SSI infrastructure), or other electronic Agents (e.g. services that can provide data when appropriate permissions are submitted - e.g. user consent tokens). +Handling/managing the various communications channels through which data can be exchanged is also a task of the TRD[^2]. One reason for this is that negotiating a transaction not only requires data to be acquired, but also to be provided to the peer participant. Another reason is that the peer participant may use multiple Agents to provide such data, e.g. human Agents (that might use web-browsers, social-media apps, phones, or physical visits), SSI Agents (that use the SSI infrastructure), or other electronic Agents (e.g. services that can provide data when appropriate permissions are submitted - e.g. user consent tokens). Thus, the TRD is generally considered capable of obtaining data through different communications channels. However, the technical tracks of eSSIF-Lab will exclusively focus on the communications channel through which credentials can be requested and obtained. Any extensions or business productization of TRD designs may be considered in the business tracks of eSSIF-Lab. The latter is not considered any further in this section. -In order to acquire data through SSI mechanisms for filling in a form for a specific kind of transaction, the TRD needs to know what kinds of credentials it should ask for, which Parties its Owner trusts to issue such credentials, what kinds of verification proofs for such credentials must hold and which may be disregarded.[TRD.3] Also, when the TRD gets a credential that satisfies the necessary verification proofs, it needs a way to map the contents of that credential to the structure of the transaction context that is used internally by (other systems of) its Owner.[TRD.4] Also, as the TRD gets more and more data - which it may get through multiple, different channels - it needs to determine whether or not the resulting set is sufficiently consistent and coherent.[TRD.5] +In order to acquire data through SSI mechanisms for filling in a form for a specific kind of transaction, the TRD needs to know what kinds of credentials it should ask for, which Parties its Owner trusts to issue such credentials, what kinds of verification proofs for such credentials must hold and which may be disregarded.[^3] Also, when the TRD gets a credential that satisfies the necessary verification proofs, it needs a way to map the contents of that credential to the structure of the transaction context that is used internally by (other systems of) its Owner.[^4] Also, as the TRD gets more and more data - which it may get through multiple, different channels - it needs to determine whether or not the resulting set is sufficiently consistent and coherent.[^5] In order to make the TRD work, a Validation Policy (or TRD Policy) is created by, or on behalf of the Owner, which specifies at least: @@ -39,7 +39,7 @@ In order to make the TRD work, a Validation Policy (or TRD Policy) is created by - 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[TRD.6]. + - 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]. - for each kind of credential: the verification proofs that must hold to be accepted as a source for valid data. @@ -47,7 +47,7 @@ In order to make the TRD work, a Validation Policy (or TRD Policy) is created by 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 TRD Policy enable the TRD 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.[TRD.7] +The ability to create new transaction contexts and the availability of the TRD Policy enable the TRD 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] When the Verifier returns such data (which comes with a list of proofs that the Verifier has checked), the TRD 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 TRD 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 TRD itself must make validation decisions, either electronically (according to the TRD policy) or by ‘outsourcing’ such decisions to human Agents of its Owner by providing an appropriate validation user interface. @@ -55,16 +55,16 @@ As long as data is needed, the TRD can intermittently request the verifier to pr ----- -[TRD.1] This feature ensures that the transaction is really two-way, and both Parties can request credentials from the other. For example, a web-shop can then ask for a (delivery) address credential, and the customer can ask for a credential issued e.g. by the chamber of commerce that the web-shop is a legitimate company (and not some maffia website). +[^1]: This feature ensures that the transaction is really two-way, and both Parties can request credentials from the other. For example, a web-shop can then ask for a (delivery) address credential, and the customer can ask for a credential issued e.g. by the chamber of commerce that the web-shop is a legitimate company (and not some maffia website). -[TRD.2] It may well be that this functionality can somehow be split off in the (near) future. +[^2]: It may well be that this functionality can somehow be split off in the (near) future. -[TRD.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 TRD. 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 Owner of the TRD. 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. -[TRD.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 Owner have implemented. Mapping allows such cases to be accommodated for. -[TRD.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. +[^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. -[TRD.6] This enables the TRD to pass the endpoint URI on to the Verifier when it requests for such a credential, which in turn can send it to the holder of other Parties enabling them to obtain the credential from that issuer endpoint if that other Party does not have that credential in its wallet. The endpoint URI can in fact be put in the policy, because the (human) Agent that creates/maintains the policy would need to know that the issuing Party is actually issuing such credentials, what their contents means, etc., and hence is capable of tracking down the URI where that Party issues the credentials. +[^6]: This enables the TRD to pass the endpoint URI on to the Verifier when it requests for such a credential, which in turn can send it to the holder of other Parties enabling them to obtain the credential from that issuer endpoint if that other Party does not have that credential in its wallet. The endpoint URI can in fact be put in the policy, because the (human) Agent that creates/maintains the policy would need to know that the issuing Party is actually issuing such credentials, what their contents means, etc., and hence is capable of tracking down the URI where that Party issues the credentials. -[TRD.7] A reference to this specification will be added when it becomes available (draft or otherwise). +[^7]: A reference to this specification will be added when it becomes available (draft or otherwise). diff --git a/docs/terms/trd.md b/docs/terms/trd.md index 9e0781e..6196193 100644 --- a/docs/terms/trd.md +++ b/docs/terms/trd.md @@ -1,6 +1,6 @@ --- id: trd -title: "TRD - Transaction Result Dispatcher" +title: "TRD" scopeid: essifLab type: concept typeid: trd diff --git a/docs/terms/tve-policy.md b/docs/terms/tve-policy.md index b22900e..1dfc1a4 100644 --- a/docs/terms/tve-policy.md +++ b/docs/terms/tve-policy.md @@ -5,32 +5,32 @@ scopeid: essifLab type: concept typeid: tve-policy stage: draft -hoverText: "TVE Policy: a machine readable policy that enables an operational TVE component to function according to the rules of the party on whose behalf this component acts." +hoverText: "TVE Policy: a machine readable policy that enables an operational TVE component to function according to the rules of its principal." --- ## Short Description -A **Transaction (Validation) Engine** or **TVE** is a functional component that provides business applications with forms that users have filled in, and where the content of such forms is valid for making decision(s) by this application. The TVE uses a machine readable TVE-policy +A **Transaction Validation Engine (TVE)** is a functional component that provides business applications with forms that users have filled in, and where the content of such forms is valid for making decision(s) by this application. The TVE uses a machine readable TVE-policy ## Purpose -The purpose of the Transaction (Validation) Engine (TVE) is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an %%agent|agent%% of) its %%owner|owner%% to decide whether or not to engage in a (new) transaction of the specified type. +The purpose of the Transaction Validation Engine (TVE) is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an %%agent|agent%% of) its %%owner|owner%% to decide whether or not to engage in a (new) transaction of the specified type. ## Criteria -A **Transaction (Validation) Engine** or **TVE** is a component in the [eSSIF-Lab functional architecture](..\functional-architecture\) whos function is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an %%agent|agent%% of) its %%owner|owner%% to decide whether or not to engage in a (new) transaction of the specified type. +A **Transaction Validation Engine (TVE)** is a component in the [eSSIF-Lab functional architecture](../functional-architecture) whos function is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an %%agent|agent%% of) its %%owner|owner%% to decide whether or not to engage in a (new) transaction of the specified type. ## Functionality Typically, the TVE 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.[TVE.1] +- when it is instructed by, or on behalf of its Owner, to request a specific kind of transaction to some Agent of another Party.[^1] In either case, a transaction form (object, context) has to be created that matches the kind of transaction, and a ‘**transaction-id**’ must be generated that identifies this form/object/context. It will be used for binding incoming or outgoing messages to this transaction, enabling communications to remain congruent, not only with the Agent that requested the transaction, but also with other Agents from the same Owner and/or using different communications channels. -Handling/managing the various communications channels through which data can be exchanged is also a task of the TVE[TVE.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). +Handling/managing the various communications channels through which data can be exchanged is also a task of the TVE[^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 TVE is generally considered capable of obtaining data through different communications channels. However, the technical tracks of eSSIF-Lab will exclusively focus on the communications channel through which credentials can be requested and obtained. Any extensions or business productization of TVE 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 TVE 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.[TVE.3] Also, when the TVE 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.[TVE.4] Also, as the TVE 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.[TVE.5] +In order to acquire data through SSI mechanisms for filling in a form for a specific kind of transaction, the TVE 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 TVE 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 TVE 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 TVE work, a Validation Policy (or TVE Policy) is created by, or on behalf of the Owner, which specifies at least: @@ -39,7 +39,7 @@ In order to make the TVE work, a Validation Policy (or TVE Policy) is created by - 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[TVE.6]. + - 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]. - for each kind of credential: the verification proofs that must hold to be accepted as a source for valid data. @@ -47,7 +47,7 @@ In order to make the TVE work, a Validation Policy (or TVE Policy) is created by 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 TVE Policy enable the TVE 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.[TVE.7] +The ability to create new transaction contexts and the availability of the TVE Policy enable the TVE 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] When the Verifier returns such data (which comes with a list of proofs that the Verifier has checked), the TVE 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 TVE 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 TVE itself must make validation decisions, either electronically (according to the TVE policy) or by ‘outsourcing’ such decisions to human Agents of its Owner by providing an appropriate validation user interface. @@ -55,16 +55,16 @@ As long as data is needed, the TVE can intermittently request the verifier to pr ----- -[TVE.1] This feature ensures that the transaction is really two-way, and both Parties can request credentials from the other. For example, a web-shop can then ask for a (delivery) address credential, and the customer can ask for a credential issued e.g. by the chamber of commerce that the web-shop is a legitimate company (and not some maffia website). +[^1]: This feature ensures that the transaction is really two-way, and both Parties can request credentials from the other. For example, a web-shop can then ask for a (delivery) address credential, and the customer can ask for a credential issued e.g. by the chamber of commerce that the web-shop is a legitimate company (and not some maffia website). -[TVE.2] It may well be that this functionality can somehow be split off in the (near) future. +[^2]: It may well be that this functionality can somehow be split off in the (near) future. -[TVE.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 TVE. 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 Owner of the TVE. 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. -[TVE.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 Owner have implemented. Mapping allows such cases to be accommodated for. -[TVE.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. +[^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. -[TVE.6] This enables the TVE to pass the endpoint URI on to the Verifier when it requests for such a credential, which in turn can send it to the holder of other Parties enabling them to obtain the credential from that issuer endpoint if that other Party does not have that credential in its wallet. The endpoint URI can in fact be put in the policy, because the (human) Agent that creates/maintains the policy would need to know that the issuing Party is actually issuing such credentials, what their contents means, etc., and hence is capable of tracking down the URI where that Party issues the credentials. +[^6]: This enables the TVE to pass the endpoint URI on to the Verifier when it requests for such a credential, which in turn can send it to the holder of other Parties enabling them to obtain the credential from that issuer endpoint if that other Party does not have that credential in its wallet. The endpoint URI can in fact be put in the policy, because the (human) Agent that creates/maintains the policy would need to know that the issuing Party is actually issuing such credentials, what their contents means, etc., and hence is capable of tracking down the URI where that Party issues the credentials. -[TVE.7] A reference to this specification will be added when it becomes available (draft or otherwise). +[^7]: A reference to this specification will be added when it becomes available (draft or otherwise). diff --git a/docs/terms/tve.md b/docs/terms/tve.md index 0eb5d0f..6362baa 100644 --- a/docs/terms/tve.md +++ b/docs/terms/tve.md @@ -1,6 +1,6 @@ --- id: tve -title: "TVE - Transaction Validation Engine" +title: "TVE" scopeid: essifLab type: concept typeid: tve diff --git a/docs/terms/validated-data.md b/docs/terms/validated-data.md new file mode 100644 index 0000000..596624e --- /dev/null +++ b/docs/terms/validated-data.md @@ -0,0 +1,14 @@ +--- +id: validated-data +title: "Validated Data" +scopeid: essifLab +type: concept +typeid: validated-data +stage: draft +hoverText: "Validated Data: data of which some party has established that it is valid, and hence can be used, for some specific purpose(s)." +--- + +:::info Editor's note +TNO to provide the content of this file. +::: + diff --git a/docs/terms/verifiable-credential.md b/docs/terms/verifiable-credential.md new file mode 100644 index 0000000..d29dc59 --- /dev/null +++ b/docs/terms/verifiable-credential.md @@ -0,0 +1,19 @@ +--- +id: verifiable-credential +title: "Verifiable Credential" +scopeid: essifLab +type: concept +typeid: verifiable-credential +stage: draft +hoverText: "Verifiable Credential: credential that comes with assurances regarding its provenance (the party that issued it) and its integrity (the property that the credential is the same as it was when issued)." +--- + +:::info Editor's note +TNO to provide the content of this file. +::: + +### Related Concepts +- %%credential|credential%% +- %%verified data|verified-data%% +- %%validated data|validated-data%% + diff --git a/docs/terms/verified-data.md b/docs/terms/verified-data.md new file mode 100644 index 0000000..16e72be --- /dev/null +++ b/docs/terms/verified-data.md @@ -0,0 +1,14 @@ +--- +id: verified-data +title: "Verified Data" +scopeid: essifLab +type: concept +typeid: verified-data +stage: draft +hoverText: "Verified Data: data of which some party has established that it is a truthful representation of what its author intended it to mean when the data was created." +--- + +:::info Editor's note +TNO to provide the content of this file. +::: + diff --git a/docs/terms/verifier.md b/docs/terms/verifier.md index e158646..97ffe27 100644 --- a/docs/terms/verifier.md +++ b/docs/terms/verifier.md @@ -9,7 +9,7 @@ hoverText: "Verifier: a functional component that is capable of " --- ## Short Description -A **Verifier** is +A **Verifier** is is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that The **verifier** functionality is to support the TVE as it tries to acquire credentials from some other Party for the purpose of negotiating a business transaction. It does so by creating Presentation Requests (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’), verifying the Presentation, i.e. checking the signature and other proofs of the veracity of both the construction of the Presentation as well as its contents, thus providing the TVE with verified data. @@ -18,7 +18,7 @@ The **verifier** functionality is to support the TVE as it tries to acquire cred The purpose of the Verifier function is. ## Criteria -A **Verifier** is a component in the [eSSIF-Lab functional architecture](..\functional-architecture\) whose function is to ... (tbd). +A **Verifier** is a component in the [eSSIF-Lab functional architecture](../functional-architecture) whose function is to ... (tbd). ## Functionality diff --git a/docs/terms/wallet.md b/docs/terms/wallet.md index 41000e9..e958b53 100644 --- a/docs/terms/wallet.md +++ b/docs/terms/wallet.md @@ -9,7 +9,7 @@ hoverText: "Wallet: a functional component that is capable of " --- ## Short Description -A **Wallet** is +A **Wallet** is is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that 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. 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. @@ -20,7 +20,7 @@ The **wallet** functionality includes the (secure) storage of credentials - both The purpose of the Wallet function is. ## Criteria -A **Wallet** is a component in the [eSSIF-Lab functional architecture](..\functional-architecture\) whose function is to ... (tbd). +A **Wallet** is a component in the [eSSIF-Lab functional architecture](../functional-architecture) whose function is to ... (tbd). ## Functionality -- GitLab From 50eb0613187d59def22e19ff725b298e13824a38 Mon Sep 17 00:00:00 2001 From: RieksJ Date: Mon, 12 Oct 2020 10:59:06 +0200 Subject: [PATCH 03/26] updates of popover texts for specific SSI-capabilities --- docs/terms/holder.md | 2 +- docs/terms/issuer.md | 2 +- docs/terms/verifier.md | 2 +- docs/terms/wallet.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/terms/holder.md b/docs/terms/holder.md index c21ec92..f4173c3 100644 --- a/docs/terms/holder.md +++ b/docs/terms/holder.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: holder stage: draft -hoverText: "Holder: a functional component that is capable of " +hoverText: "Holder (functional component): the capability to handle presentation requests from a peer-agent, produce the requested data (a presentation) according to its principal's holder-policy, and send that in response to the request." --- ## Short Description diff --git a/docs/terms/issuer.md b/docs/terms/issuer.md index 0e6ac68..33eb4d0 100644 --- a/docs/terms/issuer.md +++ b/docs/terms/issuer.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: issuer stage: draft -hoverText: "Issuer: a functional component that is capable of " +hoverText: "Issuer (functional component): the capability to construct credentials from data objects, according to the rules of its principal's issuer-policy (specifically regarding the way in which the credential is to be digitally signed), and pass it to the wallet-component of its principal allowing it to be issued." --- ## Short Description diff --git a/docs/terms/verifier.md b/docs/terms/verifier.md index 97ffe27..16b231e 100644 --- a/docs/terms/verifier.md +++ b/docs/terms/verifier.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: verifier stage: draft -hoverText: "Verifier: a functional component that is capable of " +hoverText: "Verifier (functional component): the capability to request peer-agents to present (provide) data from credentials (of a specified kind, issued by specified parties), and to verify such responses (check structure, signatures, dates), according to its principal's verifier-policy." --- ## Short Description diff --git a/docs/terms/wallet.md b/docs/terms/wallet.md index e958b53..6a8d54f 100644 --- a/docs/terms/wallet.md +++ b/docs/terms/wallet.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: wallet stage: draft -hoverText: "Wallet: a functional component that is capable of " +hoverText: "Wallet (functional component): the capability to securely store data as requested by colleague-agents, and to provide stored data to colleague-agents or peer-agents, all in compliance with the rules of the wallet-policy of its principal." --- ## Short Description -- GitLab From 4b29c49fab995f58d061dcdeacdf9b627cc4bf87 Mon Sep 17 00:00:00 2001 From: RieksJ Date: Mon, 12 Oct 2020 11:24:55 +0200 Subject: [PATCH 04/26] remove doc-sources stuff that isn't used yet causes problems --- .../essif-lab-functional-architecture.md | 402 ------------------ doc-sources/essif-lab-vision-and-purpose.md | 49 --- .../essif-lab-functional-architecture.md | 401 ----------------- .../functional-architecture-overview.md | 382 ----------------- doc-sources/glossary.md | 8 - doc-sources/introduction.md | 32 -- doc-sources/notations-and-conventions.md | 26 -- doc-sources/pattern-list.md | 8 - doc-sources/ssi-standards.md | 91 ---- .../terminology-plugin-instructions.md | 119 ------ doc-sources/terminology.md | 76 ---- doc-sources/terminology/README.md | 29 -- doc-sources/terminology/essifLab/action.md | 29 -- doc-sources/terminology/essifLab/actor.md | 28 -- doc-sources/terminology/essifLab/agent.md | 32 -- .../terminology/essifLab/digital-agent.md | 14 - doc-sources/terminology/essifLab/eSSIFGlue.md | 20 - doc-sources/terminology/essifLab/entity.md | 24 -- .../concept-dictionary.mdx | 43 -- .../essifLabTerminology/concept-file.md | 21 - .../essifLab/essifLabTerminology/concept.md | 70 --- .../essifLabTerminology/definition.md | 54 --- .../essifLabTerminology/dictionary-file.md | 18 - .../essifLabTerminology/dictionary.md | 47 -- .../essifLab/essifLabTerminology/entity.md | 24 -- .../essifLabTerminology/glossary-file.md | 18 - .../glossary-terminology.md | 39 -- .../essifLab/essifLabTerminology/glossary.md | 47 -- .../essifLabTerminology/pattern-file.md | 18 - .../pattern-mental-model.md | 37 -- .../pattern-terminology.md | 33 -- .../essifLab/essifLabTerminology/pattern.md | 44 -- .../essifLabTerminology/scope-file.md | 22 - .../essifLabTerminology/scope-terminology.md | 43 -- .../essifLab/essifLabTerminology/scope.md | 51 --- .../essifLab/essifLabTerminology/semantics.md | 21 - .../essifLab/essifLabTerminology/term-file.md | 18 - .../essifLab/essifLabTerminology/term.md | 67 --- .../terminology/essifLab/glossary-essifLab.md | 40 -- .../terminology/essifLab/jurisdiction.md | 43 -- doc-sources/terminology/essifLab/knowledge.md | 23 - .../terminology/essifLab/legal-entity.md | 30 -- .../essifLab/legal-jurisdiction.md | 18 - .../terminology/essifLab/legal-system.md | 33 -- doc-sources/terminology/essifLab/objective.md | 24 -- .../terminology/essifLab/organization.md | 30 -- doc-sources/terminology/essifLab/owner.md | 51 --- doc-sources/terminology/essifLab/party.md | 35 -- .../essifLab/pattern-jurisdiction.md | 41 -- .../pattern-mandates-delegation-hiring.md | 15 - .../essifLab/pattern-mental-model.md | 37 -- .../essifLab/pattern-party-actor-action.md | 45 -- .../essifLab/pattern-terminology.md | 38 -- .../terminology/essifLab/peer-agent.md | 18 - .../terminology/essifLab/peer-party.md | 18 - doc-sources/terminology/essifLab/risk.md | 23 - .../terminology/essifLab/scope-essifLab.md | 44 -- doc-sources/terminology/essifLab/ssi-agent.md | 18 - .../essifLab/transaction-result-dispatcher.md | 17 - .../essifLab/transaction-validation-engine.md | 17 - doc-sources/terminology/essifLab/trd.md | 49 --- doc-sources/terminology/essifLab/tve.md | 49 --- .../readme-generator-extensions.md | 13 - .../readme-making-contributions.md | 58 --- .../terminology/scope-registration.json | 11 - .../terminology/templates/concept-file.md | 59 --- .../terminology/templates/dictionary-file.md | 18 - .../terminology/templates/glossary-file.md | 43 -- .../terminology/templates/pattern-file.md | 38 -- .../terminology/templates/scope-file.md | 43 -- .../terminology/templates/template-file.md | 15 - .../terminology/templates/term-file.md | 35 -- .../terminology/terminology - backup.mdx | 110 ----- doc-sources/terminology/terminology.mdx | 146 ------- 74 files changed, 3850 deletions(-) delete mode 100644 doc-sources/essif-lab-functional-architecture.md delete mode 100644 doc-sources/essif-lab-vision-and-purpose.md delete mode 100644 doc-sources/func-arch/essif-lab-functional-architecture.md delete mode 100644 doc-sources/func-arch/functional-architecture-overview.md delete mode 100644 doc-sources/glossary.md delete mode 100644 doc-sources/introduction.md delete mode 100644 doc-sources/notations-and-conventions.md delete mode 100644 doc-sources/pattern-list.md delete mode 100644 doc-sources/ssi-standards.md delete mode 100644 doc-sources/terminology-plugin-instructions.md delete mode 100644 doc-sources/terminology.md delete mode 100644 doc-sources/terminology/README.md delete mode 100644 doc-sources/terminology/essifLab/action.md delete mode 100644 doc-sources/terminology/essifLab/actor.md delete mode 100644 doc-sources/terminology/essifLab/agent.md delete mode 100644 doc-sources/terminology/essifLab/digital-agent.md delete mode 100644 doc-sources/terminology/essifLab/eSSIFGlue.md delete mode 100644 doc-sources/terminology/essifLab/entity.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/concept-dictionary.mdx delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/concept-file.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/concept.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/definition.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/dictionary-file.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/dictionary.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/entity.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/glossary-file.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/glossary-terminology.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/glossary.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/pattern-file.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/pattern-mental-model.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/pattern-terminology.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/pattern.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/scope-file.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/scope-terminology.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/scope.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/semantics.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/term-file.md delete mode 100644 doc-sources/terminology/essifLab/essifLabTerminology/term.md delete mode 100644 doc-sources/terminology/essifLab/glossary-essifLab.md delete mode 100644 doc-sources/terminology/essifLab/jurisdiction.md delete mode 100644 doc-sources/terminology/essifLab/knowledge.md delete mode 100644 doc-sources/terminology/essifLab/legal-entity.md delete mode 100644 doc-sources/terminology/essifLab/legal-jurisdiction.md delete mode 100644 doc-sources/terminology/essifLab/legal-system.md delete mode 100644 doc-sources/terminology/essifLab/objective.md delete mode 100644 doc-sources/terminology/essifLab/organization.md delete mode 100644 doc-sources/terminology/essifLab/owner.md delete mode 100644 doc-sources/terminology/essifLab/party.md delete mode 100644 doc-sources/terminology/essifLab/pattern-jurisdiction.md delete mode 100644 doc-sources/terminology/essifLab/pattern-mandates-delegation-hiring.md delete mode 100644 doc-sources/terminology/essifLab/pattern-mental-model.md delete mode 100644 doc-sources/terminology/essifLab/pattern-party-actor-action.md delete mode 100644 doc-sources/terminology/essifLab/pattern-terminology.md delete mode 100644 doc-sources/terminology/essifLab/peer-agent.md delete mode 100644 doc-sources/terminology/essifLab/peer-party.md delete mode 100644 doc-sources/terminology/essifLab/risk.md delete mode 100644 doc-sources/terminology/essifLab/scope-essifLab.md delete mode 100644 doc-sources/terminology/essifLab/ssi-agent.md delete mode 100644 doc-sources/terminology/essifLab/transaction-result-dispatcher.md delete mode 100644 doc-sources/terminology/essifLab/transaction-validation-engine.md delete mode 100644 doc-sources/terminology/essifLab/trd.md delete mode 100644 doc-sources/terminology/essifLab/tve.md delete mode 100644 doc-sources/terminology/readme-generator-extensions.md delete mode 100644 doc-sources/terminology/readme-making-contributions.md delete mode 100644 doc-sources/terminology/scope-registration.json delete mode 100644 doc-sources/terminology/templates/concept-file.md delete mode 100644 doc-sources/terminology/templates/dictionary-file.md delete mode 100644 doc-sources/terminology/templates/glossary-file.md delete mode 100644 doc-sources/terminology/templates/pattern-file.md delete mode 100644 doc-sources/terminology/templates/scope-file.md delete mode 100644 doc-sources/terminology/templates/template-file.md delete mode 100644 doc-sources/terminology/templates/term-file.md delete mode 100644 doc-sources/terminology/terminology - backup.mdx delete mode 100644 doc-sources/terminology/terminology.mdx diff --git a/doc-sources/essif-lab-functional-architecture.md b/doc-sources/essif-lab-functional-architecture.md deleted file mode 100644 index df1fca2..0000000 --- a/doc-sources/essif-lab-functional-architecture.md +++ /dev/null @@ -1,402 +0,0 @@ ---- -id: functional-architecture -title: eSSIF-Lab Functional Architecture -scopeid: essifLab ---- - -The purpose of the functional architecture and its views is to - -- **provide mental models** that all of its stakeholders interpret in sufficiently the same way, so as to be able to talk, think and discuss about what it is we try to achieve and ways to achieve this; -- help **inventory and subsequently address any (other) concerns and issues** of every one of its stakeholders; -- help **achieve interoperability** both at the technical and at the business levels. - - -## 1. Basic Terminology - -In order to serve such purposes, we have found out that it is necessary that to make a strict and consequent distinction between people and Organizations that are capable of making decisions and bearing responsibility/accountability (we will use the term ‘%%Party|party%%’ for that) and people and ‘things’ that are capable of acting/doing things (we will use the term ‘%%Actor|actor%%’ for that). This means that an Organization is always a Party, whereas we consider a person to be a Party at one time and an Actor at another time, and computers/robots (and SSI components) are always an Actor. - -This distinction is necessary because Actors do things that Parties are accountable for. In order to know which Party is accountable for what actions, we need the ability to link Parties and Actors. When an Actor acts and a (single) specific Party is accountable for that, we say that the Actor is an ‘%%Agent|agent%%’ for or of that Party (at that particular point in time). We say that this Actor acts ‘**on behalf of**’ that Party. Note that both humans and (running) applications may serve as Agents (human Agent or digital/electronic Agent respectively). A digital Agent that has one or more of the SSI functionalities we describe further down will be called an \`%%SSI-Agent|ssi-agent%%\`, and we say that the Party on whose behalf it operates is the ‘%%Owner|owner%%’ of that Agent. Also, we use the term \`**(digital/electronic or human) Colleague (of an Agent)**\` to refer to any other (electronic or human) Agent that acts on behalf of the same Party as this Agent. - -Given these definitions, it is obvious that Parties are not necessarily capable of acting. However, we also would like to be able to generically use phrases such as ‘Party X does Y’. To this end we introduce the term \`%%Organization|organization%%\` as the collection of one specific Party and its Agents. When we say ‘Party X does Y’, this should be understood as that there is an Agent that does Y, where that Agent belongs to the same Organization as the specified Party. - -We caution that the notions of being an ‘Agent’, ‘Owner’, ‘Colleague’, and being part of an ‘Organization’ are dynamic; they may frequently change over time and are never self-evident. - -Also, to serve the aforementioned purposes, we cannot fix the architecture (and the fact that eSSIF-Lab is an experimentation environment already implies this). We see it is a first attempt to describe an architecture that will be regularly updated as we - i.e. the eSSIF-Lab consortium and all subgrantees and perhaps some others - work together as an ecosystem-in-formation to realize the aforementioned vision. - -## 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). - -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 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*. - -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)|peer-party%%’ to refer to the participating Party in that transaction that is not the specific Party itself. - -When an Agent is involved in such a transaction, it will be communicating with a component that it assumes to be an Agent of the Peer Party of its Owner (the 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 with which the specific Agent has a communications session. Note that establishing whether or not an Actor is a Peer Agent does not necessarily require knowing who the Peer Party actually is. - -The figure below is an overview of the most important *functional* components that any Party needs to conduct electronic business transactions. - -![eSSIF-Lab Single Party Functional Architecture Overview](https://essif-lab.pages.grnet.gr/framework//images/functional-architecture.png) - -*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 Owner of the component that uses them to configure themselves, and/or act according to the Owner’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. - -The remainder of this chapter describes the layers and their components at a high abstraction level. - -### 2.1. Business Transaction Layers - -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 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 task of the %%Transaction (Validation) Engine|transaction-validation-engine%% (or %%TVE|tve%%) 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 Owner needs, and providing data on behalf of its Owner that a Peer Agent requests. After all, a business transaction can only start after all Parties 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 TVE must ensure that the transaction context is properly maintained if it chooses to exchange data through different communication channels. - -The task of the %%Transaction Result Dispatcher|transaction-result-dispatcher%% (or %%TRD|trd%%) 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. 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, 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 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’, i.e. sets of (related) statements/claims (e.g. as produced by the TRD) that have metadata (e.g. date of issuing) and a digital signature by which third Parties can prove its provenance and integrity. Another function of the issuer is to handle revocation (and (un)suspension) of credentials that it has issued. For such tasks, it relies on functions that are made available by the SSI Protocols and Crypto Layer. - -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. 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. - -The **verifier** functionality is to support the TVE as it tries to acquire credentials from some other Party for the purpose of negotiating a business transaction. It does so by creating Presentation Requests (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’), verifying the Presentation, i.e. checking the signature and other proofs of the veracity of both the construction of the Presentation as well as its contents, thus providing the TVE with verified data. - -The task of the **holder** is to handle Presentation Requests that it receives from Verifier components (both of its Owner, and of other Parties). Typically, this means looking for the requested data in the Owner’s 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 for the purpose of obtaining the needed credential, which - when obtained - it can subsequently store in the wallet and use in the 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, Holder, Issuer and 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. - -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 such as [*Verifiable Credentials*](https://www.w3.org/TR/vc-data-model/) (VCs), [*Attribute Based Credentials*](https://abc4trust.eu/index.php/pub)[ABC] (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. - -Then, there are **secure communications technologies**, for the purposes of (a) ensuring that a technical component owned by a specific Party can recognize that another component as one that it has had previous communications with and/or is owned by an identified Party, and (b) setting up a secure communications channel, i.e. one that guarantees message confidentiality (encryption) and integrity/authentication. A well-known way to do this is SSL, but new ones are being developed, such as [*DID Comm(unication)*](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0005-didcomm), that uses [*peer DIDs*](https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/draft-documents/peer-DID-method-spec-report.md) (work in progress). - -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)[eIDAS] 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 definitions, 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) - ------- - -[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. - ------- - -### 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 TVE and TRD 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 Transaction Result Dispatcher and Transaction (Validation) Engine. Ultimately, we would like to see these APIs standardized. Having such APIs allows different Parties to create their own version of the WHIV components, supporting the SSI technologies as they see fit, and shrinking or expanding functionalities as they feel appropriate. Parties can then select such WHIV components as they see fit. - -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 - -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: - -![eSSIF-Lab functional components that are part of the eSSIF-Lab infrastructure](https://essif-lab.pages.grnet.gr/framework//images/functional-architecture-infra.png) - -*Figure 2: eSSIF-Lab infrastructural (functional) components.* - -### 3.1. Transaction (Validation) Engine and Validation Policy - -The purpose of the Transaction (Validation) Engine (TVE) is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an Agent of) its Owner to decide whether or not to engage in a (new) transaction of the specified type. - -Typically, the TVE 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.[TVE.1] - -In either case, a transaction form (object, context) has to be created that matches the kind of transaction, and a ‘**transaction-id**’ must be generated that identifies this form/object/context. It will be used for binding incoming or outgoing messages to this transaction, enabling communications to remain congruent, not only with the Agent that requested the transaction, but also with other Agents from the same Owner and/or using different communications channels. - -Handling/managing the various communications channels through which data can be exchanged is also a task of the TVE[TVE.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 TVE is generally considered capable of obtaining data through different communications channels. However, the technical tracks of eSSIF-Lab will exclusively focus on the communications channel through which credentials can be requested and obtained. Any extensions or business productization of TVE 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 TVE 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.[TVE.3] Also, when the TVE 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.[TVE.4] Also, as the TVE 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.[TVE.5] - -In order to make the TVE work, a Validation Policy (or TVE Policy) is created by, or on behalf of the Owner, which specifies at least: - -- the kinds of transactions the Owner 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[TVE.6]. - - - for each kind of credential: the verification proofs that must hold to be accepted as a source for valid data. - - - the mapping between fields in such credentials and fields in the form to be filled in. - -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 TVE Policy enable the TVE 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.[TVE.7] - -When the Verifier returns such data (which comes with a list of proofs that the Verifier has checked), the TVE 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 TVE 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 TVE itself must make validation decisions, either electronically (according to the TVE policy) or by ‘outsourcing’ such decisions to human Agents of its Owner by providing an appropriate validation user interface. - -As long as data is needed, the TVE can intermittently request the verifier to produce it (or it can use other communications channels, which is outside scope for now). It does so until it times out, or the form has become ‘clean’. - ------ - -[TVE.1] This feature ensures that the transaction is really two-way, and both Parties can request credentials from the other. For example, a web-shop can then ask for a (delivery) address credential, and the customer can ask for a credential issued e.g. by the chamber of commerce that the web-shop is a legitimate company (and not some maffia website). - -[TVE.2] It may well be that this functionality can somehow be split off in the (near) future. - -[TVE.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 TVE. 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. - -[TVE.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. - -[TVE.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. - -[TVE.6] This enables the TVE to pass the endpoint URI on to the Verifier when it requests for such a credential, which in turn can send it to the holder of other Parties enabling them to obtain the credential from that issuer endpoint if that other Party does not have that credential in its wallet. The endpoint URI can in fact be put in the policy, because the (human) Agent that creates/maintains the policy would need to know that the issuing Party is actually issuing such credentials, what their contents means, etc., and hence is capable of tracking down the URI where that Party issues the credentials. - -[TVE.7] A reference to this specification will be added when it becomes available (draft or otherwise). - ------ - -### 3.2. Verifier Component, and its Policy/Preferences - -The purpose of the Verifier component is to support the Transaction (Validation) Engine 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 TVE 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 TVE 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 TVE policy. - -Then, the Verifier needs to know the address and protocol that it can use to reach a Holder component owned by the Party that its Owner is trying to negotiate the transaction with. The TVE specifies this as part of the request - and it can do so because it has received the original request, and does all communications 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. - -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). - -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\] - -A response to this request (called a Presentation) will be obtained from a Holder component of the Peer 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). - -Then, the verifier will send a message to the TVE, containing the 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 component is to handle Presentation Requests that it receives from Verifier components (both of its own Owner, and of other Parties), and responding to such requests. - -Typically, a Holder component would access its Owner's Wallet to check if it has a credential that it can use to construct a Presentation (i.e. response) that satisfies the received request. - -It may happen that the Wallet does not have such a credential. However, for every (credential, issuer) pair, the request should specify the URI that is capable of issuing such a credential. If or when the Holder Policy/Preferences permit this, the Holder then requests its Owner’s TVE to initiate a new transaction that will get the credential from that issuer, for which a clean transaction form would then consist of one that contains said credential. The Holder would then store it in its Owner’s Wallet, and then proceed to service the presentation request as if it had obtained that credential from its Owner’s Wallet. - -It may 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.: - -- 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); -- the kinds of events and data to write to a holder-audit-log. - -### 3.4. Transaction Result Dispatcher and Issuing Policy - -The purpose of the TRD component is to state the (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other Parties. A special kind of result is the (provisioning of) a credential that its Owner already has created. - -Typically, and at any point in time, Parties are capable of expressing statements about entities that they know to exist. They could express statements about individuals, about themselves, the state of transactions, and so on. We will use the term ‘**subject (of a statement of a Party)**’ to refer to the entity that this Party knows to exist, and about whom/which the statement has been made. - -We will use the term ‘**subject-id (of a statement of a Party)**’ to refer to the representation that this Party has chosen to use for referring to the subject in said statement. A subject-id must have the property of being an identifier within every administrative context that this Party uses. It need not be humanly interpretable (and preferably is not). - -Parties need to specify the kinds of credentials they are willing to issue, the class of entities (e.g. people, cars, Organizations) for which it will issue them, and the information schema (structure) that it will use in credentials of such kinds.[TRD.1] This allows the TRD to construct data objects that conform to this information schema, and present it to the Issuer component for actual issuing. - -The TRD Issuing Policy specifies the kinds of (linked-)data-objects that credentials may be created for. This allows the TRD to construct such a (linked-)data-objects for every subject-id that identifies a subject of the class for which a credential can be issued, which can subsequently be sent to the Issuer component that can turn it into a credential of a specific sort. - -You can think of the TRD as the component that pulls all data together that can be put in a credential (e.g. in a passport), and the Issuer as the component that puts the data in an (empty) passport, and signing it so as to create the actual credential. - -The TRD may either push credential data to the Issuer component, so that the Issuer always has up-to-date credentials, or it can wait until the Issuer requests credential data for the creation of a credential of a specific type for a specific subject. - ------ - -[TRD.1] We assume/stipulate that the Party maintains a credential catalogue that contains this, and other information about every kind of credential that it issues, and that such catalogues are available to other Parties that want or need to use such credentials. - ------ - - - -### 3.5. Issuer Component, and its Policy/Preferences - -The purpose of the Issuer component is to issue ‘credentials’, i.e. digital constructs that contain - -- sets of (related) statements or claims (e.g. as produced by the TRD) -- metadata (e.g. type of credential, date of issuing and expiration, endpoints, e.g. for revocation checking, credential definition, credential advertisements, credential enforcement policy, etc.) -- proofs (e.g. a digital signature by which third Parties can prove its provenance and integrity. - -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. - -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 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 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). - -After the issuer has created a credential (in one or more formats), it checks the wallet to see if it contains a credential of the same type for the same subject. If (one or more formats) are there, and their contents are the same as the newly created credential, the existing ones are revoked, deleted and/or archived/tombstoned.[Issuer.1] Then, the newly created credential is added to the wallet (in one or more formats). Thus, at any point in time, the wallet will contain an actual set of all credentials that have been issued.[Issuer.2] - ------ - -[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 component in their SSI app, to issue self-signed credentials and provide them to verifiers that request them as usual for non-self-signed credentials. - ------ - - -### 3.6. Wallet Component, and its Policy/Preferences - -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, and -- (private) keys e.g. for signing/sealing data on behalf of its Owner. - -Other kinds of data may be stored by a wallet as well - we will have to see what is practical and makes sense. - -By ‘securely storing data’ we mean that such data - -- remains available until a request is received from an electronic Colleague that is entitled to request deletion of such data; -- remains unchanged during the time in which it is stored; - -- 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. - -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 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. - -## 4. Initial SSI-Agent Network Architecture - -:::info -*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 need to deploy (technical) components that act as their Agents. Individuals would typically have a mobile app whose user interface allows them to fulfill any or all of the roles of holder, verifier and issuer. Wallet functionality may be included in this app, but it might equally well live in the cloud, as a second (technical) Agent. An individual might also have (cloud) servers that Agents of other parties may contact for conducting transactions without the need for the individual itself to do something. All of this holds equally well for larger Organizations. - -It is conceivable that the set of SSI functions is spread over multiple (technical) Agents, in which case there is going to be a need for such Agents to contact one another, and conduct transactions in a way that may differ from doing that with Agents of other Parties. Basically, this can be seen as Colleagues interacting with one another to get things done within one Organization. Seen from the outside, it looks like every Organization has a (smaller or larger) network of Agents. 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 of a single, specific Party. -2. the **inter-Party or multi-Party SSI viewpoint**, which is about specific functional components (e.g. Verifier, Holder, etc.) that typically belong to different Parties. - -An individual 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 Agents. The set of concerns would include: - -- How can electronic components be onboarded as an Agents of this Party? -- How can the integrity of such electronic Agents 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 specify which of its Agents may talk with which other Agents, and for what purposes? -- How should a Party specify the policies for the various SSI functionalities - what kind of support would be useful here? -- … - -Parties 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: - -- How can Parties interact with one another at the information level (this includes decentralized semantic interoperability issues, advertising credentials, how a Party can find other Parties that issue credentials that are useful to him, etc.) -- What kinds of underlying technologies must Agents of a Party support so as to be(come) interoperable with Parties that it wants to interact with? -- … - -## 5. High Level Transaction Flows - -This chapter explains at a high level how electronic business transactions 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. For illustrative purposes, we stick to the example of getting a parking permit that we introduced in section 1.1. - -### 5.1. Overview - -
- -![eSSIF-Lab - high level trx overview](https://essif-lab.pages.grnet.gr/framework//images/high-level-trx-overview.png) - -The adjacent figure shows how a transaction is conducted at the highest abstraction level. One Party, called the ‘Requester’, sends a request for a product or service to another 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 to (individually/subjectively) decide whether or not to commit to the 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. - -When all is done, Parties may issue a (signed) statement that specifies the results. Section 3.3. provides some more details about this phase. - -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 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 that states the result of the transaction, i.e. contains the details of the parking permit. - -Please note that while transactions 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 perform are ordered in time, which implies e.g. that the commitment decisions of both Parties cannot be done at the same time. Also, in practice, it often happens that a Party requires the other 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. - -### 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 quits, or both Parties commit. - -![eSSIF-Lab - high level trx negotiation](https://essif-lab.pages.grnet.gr/framework//images/high-level-trx-negotiation.png) -The adjacent 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 communications channel, i.e. a secure communications channel through which provider and requester can both request and obtain (presentations of) credentials, 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. - -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 credential presentations and responding to such requests may very well consist of multiple requests and associated responses. - -In the example of the parking permit, the municipality might ask for a credential that proves the requester is a citizen that is a registered inhabitant of said municipality, a credential stating its residential address, a credential stating the make and license plate of the vehicle for which a parking permit is requested, etc. All this is subject to the policy that the municipality has established for issuing such permits, and hence, it must be expected to differ between municipalities. - -An example of conditionally required fields would be when the requester wants the municipality to customize the parking lot, e.g. because the requester has disabilities. Assessing such circumstances depends on the (optional) field where the requester must state any disabilities they have, and when that is the case, the requester may be asked to fill in fields such as whether or not a parking lot has to be customized (painted blue, with a sign stating that it is reserved for the provided license-place, or the kind of charging device if they have an electric vehicle). - -Conversely, the citizen might request the (alleged) municipality to provide credentials, e.g. to prove that it is actually an official municipality of the country it is part of. This would provide assurance to the citizen that it would actually be paying the fees to that municipality rather than to e.g. a rogue Organization that might have spoofed the website of the municipality. - -### 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 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 has been changed/tampered with since it was issued). From this, it follows that any Party can issue any kind of credential for any entity that it knows to exist. A credential does not need to be about a person or an Organization, but it can also refer to an order, a delivery, a seat-reservation, a prescription, etc. - -We foresee two ways in which credentials can be issued: - -1. both the requester and provider may issue credentials to the other 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 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 that contains the details of that permit. The requester may issue a 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 may issue a credential upon request. Basically, this means that a Party (in the role of requester) issues a request to that other Party (in the role of provider) asking for the particular 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, 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 without further ado, or start the process of issuing a new one. - -## 6. Detailed Transaction Flows - -:::info -*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.* -::: - -This chapter explains the details of how electronic business transactions 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, requester and provider, each have components as described in chapter 2. Also note that whenever we introduce another Party, it too has such components. Thus, every Party can play any of the traditional SSI roles ‘verifier’, ‘holder’ and ‘issuer’, and each has its own ‘wallet’ functionality. Also, they all have TVE and TRD 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 communicates with another component, this other component may be of the same Party, as well as of the other Party. Figure 2 only shows components that belong to a single Party. - -### 6.1. Starting a Transaction - -:::info -*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 TVE component. - -The TVE 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 communications 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 of various Parties will be communicating. - -It is a task of the TVE 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; -- may be changed manually; -- may be changed with data from a newly supplied credential. - -Because of this orchestration, the interface to the verifier component can be quite simple; it is shown in the image below: - -![Generic Verification with SSI service](https://essif-lab.pages.grnet.gr/framework//images/generic-verification-with-ssi-service.png) - -The request identifier is included in messages between the TVE and verifier so as to allow them to handle different transactions 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. - -### 6.2. Stating a Transaction - -:::info -*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.* -::: - -![Generic Issuing with SSI service](https://essif-lab.pages.grnet.gr/framework//images/generic-issuing-with-ssi-service.png) diff --git a/doc-sources/essif-lab-vision-and-purpose.md b/doc-sources/essif-lab-vision-and-purpose.md deleted file mode 100644 index 561e9b9..0000000 --- a/doc-sources/essif-lab-vision-and-purpose.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -id: vision-and-purpose -title: eSSIF-Lab Vision and Purpose ---- - -The eSSIF-Lab vision is that Self-sovereign Identity (SSI) will *empower European and other citizens* by providing new means to manage privacy by eliminating logins and making electronic transactions fast and safe both in the Internet and in physical life. SSI will *empower European organisations and governments* by providing new means to speed up, secure and automate transactions with citizens, customers, suppliers and partners, resulting in tens of billions of euros savings annually on administrative costs in Europe. SSI will be *a new business ecosystem paradigm* with thousands of new jobs, many new job categories and new business opportunities for existing and new European companies. And last, but certainly not least, SSI fosters *inclusiveness* and supports organizations and citizens to exercise their rights and fulfil their duties under the GDPR. - -The current situation is that SSI solutions that are being created and brought to the market either target specific applications for which they provide a vertical solution (‘stovepipes’), many need some kind of centralized governance/control, others have privacy issues, and none that we know of are interoperable with other such solutions. - -The situation we would like to see is one in which we have SSI-enabled, interoperable and scalable technologies, that form an infrastructure that every application in any vertical can use in a very easy manner, for the exchange of verified (personal and non-personal) data. In that situation people, businesses and governments think more about the information they need and/or provide as they conduct business transactions. They no longer need to be concerned about the SSI technologies that have empowered them to make this happen. - -:::tip **The purpose of the eSSIF-Lab...** -... is to specify, develop and validate technological and non-technological means that support people, businesses and governments to think about, design and operate their (information) processes and (electronically) conduct business transactions with one another. -::: - -The context of the eSSIF-Lab vision can be found in articles 8-10 of the [*European Convention on Human Rights (ECHR)*](https://www.echr.coe.int/Pages/home.aspx?p=basictexts/convention), that state the rights of individuals regarding their privacy, and their freedoms to collect, process, store, and express information in a self-sovereign fashion, i.e. in a way that they can decide for themselves. This is without prejudice to Member States’ laws that exist to protect their national security, public safety, the economic well-being of the country, health or morals or the rights and freedoms of others, or to prevent disorder or crime. The eSSIF-Lab vision extends these rights and freedoms - within the limits of the law - to public and private organizations. Thus, we say that individuals as well as public and private organizations (that we collectively refer to as ‘parties’) are self-sovereign[1]. - -In the context of these rights and freedoms, we seek to support electronic business transactions, i.e. the electronic exchange of goods, services, funds, or data between parties, which we call ‘participants’ to the transaction[2]. - -An electronic business transaction is a business transaction that requires each participant to have (at least one) electronic agent, i.e. equipment (e.g. an app on a mobile phone, a webserver, a browser, …) that acts on behalf of its owner in the transaction. - -An electronic business transaction is a business transaction that requires each participant to have (at least one) electronic agent, i.e. equipment (e.g. an app on a mobile phone, a web server, a browser, …) that acts on behalf of its owner in the transaction. - - -## High-Level Example of a Business Transaction - -In its simplest form, this may be envisaged as one party (requestor) that requests another party (provider) to provide some product, e.g. a parking permit, by using his web-browser to navigate to the web-server of the provider (e.g. his municipality) where he is prompted to fill in a form to provide the details of his request (such as name, address, plate number, etc.). When the form is submitted, the provider decides whether or not to service the request (provide the parking permit) based on the data in the form, and take actions accordingly. - -In order for this to work, the provider must design the form such that when a requestor submits a completed form, it can actually decide whether or not to service the request. This has two parts: first, the provider must specify the argument (i.e. the way of reasoning) that it uses to reach this decision - i.e. provide the parking permit. Doing so implicitly specifies the kinds of data that the form will ask for. Secondly, the provider must decide for each of the data it receives, whether or not it is valid to be used in that argument - the process of deciding this is called ‘validation’. Common criteria that help to make this distinction include whether or not the data is presented in the expected format, whether or not it is true (not so easy), whether it is not outdated, or whether or not it satisfies validation rules (in the example, the municipality may require that the specified license plate belongs to a car owned by the person that requests the permit). Validation is important, because reasoning with invalid data may result in wrong conclusions and cause damage. - -Perhaps the most important contribution that the eSSIF-Lab project aims to make, is to create a ubiquitously used infrastructure for designing, filling in, and validating forms (not just web-forms, but also for ‘forms’ - e.g. JSON objects - in API requests). The benefits this will bring are enormous, but outside the scope of this document to list. - -The figure below is a high-level visualization of the filling in and validation parts: - -![eSSIF-Lab - vision context](https://essif-lab.pages.grnet.gr/framework//images/vision-context.png) *Figure 1. High-level visualization of the filling in and validation of a form.* - -The transaction that is envisaged here is the issuing of a parking permit. Participants are a person (requestor) that requests such a permit, and an organization (provider) that can issue such a permit. The requestor has one electronic agent, *the Requestor Agent (RA)*, i.e. an SSI-aware app on their mobile phone that can access a secure storage that contains ‘credentials’, i.e. data that is digitally signed by some third party, thus attesting to the truth of that data. The provider has two agents: one is an SSI-aware component *Provider Agent (PA_* that works with the web-server that presents the form, and the other is a person *P* whose task is to validate any data (on behalf of the provider) that is not validated electronically. The form itself contains a means, e.g. a QR-code or a deep-link, that allows *RA* and *PA* to set up a secure communications channel (e.g. SSL, [DIDComm](https://openssi.github.io/peer-did-method-spec/)) and agree on the specific form that needs to be filled in. - -After the *RA* and *PA* have established a communications channel and agree on the form to be filled in, *PA* informs *RA* about the information it needs to fill in the form, and the requirements that this information should satisfy[3]. *RA* then checks its data store to see whether or not such data is available, sends such data to *PA*, which subsequently validates it and uses it to fill in (appropriate parts of) the form. Finally, *P* validates the remaining data, which either results in a ‘clean’ form, i.e. a form that contains valid data that can subsequently be used to decide whether or not to provide the parking permit, or a message to the requester informing him about missing and/or invalid data. - -When the transaction has been completed, both participants can issue a credential that attests to the results of the transaction. For example, the provider could issue a credential stating that the requestor has obtained a parking permit for a car with a specific plate number (and other attributes). The requestor can store this credential and from that moment on use it in new electronic transactions. - --------- - -[1] We realize that by doing this we have a different definition of what self-sovereignty entails than many others. We are open to suggestions for a better phrase. - -[2] A good mental model for describing and designing transactions and their participants is provided by [*DEMO*](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations). - -[3] Since transactions are symmetric, the requestor could also have a form that the provider needs to fill in so as to provide the requestor with the data it needs to commit to that transaction. We have left that out of this description for the sake of simplicity. diff --git a/doc-sources/func-arch/essif-lab-functional-architecture.md b/doc-sources/func-arch/essif-lab-functional-architecture.md deleted file mode 100644 index b6f5d87..0000000 --- a/doc-sources/func-arch/essif-lab-functional-architecture.md +++ /dev/null @@ -1,401 +0,0 @@ ---- -id: functional-architecture -title: eSSIF-Lab Functional Architecture -scopeid: essifLab ---- - -The purpose of the functional architecture and its views is to - -- **provide mental models** that all of its stakeholders interpret in sufficiently the same way, so as to be able to talk, think and discuss about what it is we try to achieve and ways to achieve this; -- help **inventory and subsequently address any (other) concerns and issues** of every one of its stakeholders; -- help **achieve interoperability** both at the technical and at the business levels. - -## 1. Basic Terminology - -In order to serve such purposes, we have found out that it is necessary that to make a strict and consequent distinction between people and Organizations that are capable of making decisions and bearing responsibility/accountability (we will use the term ‘%%_Party_|party%%’ for that) and people and ‘things’ that are capable of acting/doing things (we will use the term ‘%%_Actor_|actor%%’ for that). This means that an Organization is always a Party, whereas we consider a person to be a Party at one time and an Actor at another time, and computers/robots (and SSI components) are always an Actor. - -This distinction is necessary because Actors do things that Parties are accountable for. In order to know which Party is accountable for what actions, we need the ability to link Parties and Actors. When an Actor acts and a (single) specific Party is accountable for that, we say that the Actor is an ‘%%_Agent_|agent%%’ for or of that Party (at that particular point in time). We say that this Actor acts ‘**on behalf of**’ that Party. Note that both humans and (running) applications may serve as Agents (human Agent or digital/electronic Agent respectively). A digital Agent that has one or more of the SSI functionalities we describe further down will be called an \`%%_SSI-Agent_|ssi-agent%%\`, and we say that the Party on whose behalf it operates is the ‘%%_Owner_|owner%%’ of that Agent. Also, we use the term \`**(digital/electronic or human) Colleague (of an Agent)**\` to refer to any other (electronic or human) Agent that acts on behalf of the same Party as this Agent. - -Given these definitions, it is obvious that Parties are not necessarily capable of acting. However, we also would like to be able to generically use phrases such as ‘Party X does Y’. To this end we introduce the term \`%%_Organization_|organization%%\` as the collection of one specific Party and its Agents. When we say ‘Party X does Y’, this should be understood as that there is an Agent that does Y, where that Agent belongs to the same Organization as the specified Party. - -We caution that the notions of being an ‘Agent’, ‘Owner’, ‘Colleague’, and being part of an ‘Organization’ are dynamic; they may frequently change over time and are never self-evident. - -Also, to serve the aforementioned purposes, we cannot fix the architecture (and the fact that eSSIF-Lab is an experimentation environment already implies this). We see it is a first attempt to describe an architecture that will be regularly updated as we - i.e. the eSSIF-Lab consortium and all subgrantees and perhaps some others - work together as an ecosystem-in-formation to realize the aforementioned vision. - -## 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). - -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 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*. - -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)_|peer-party%%’ to refer to the participating Party in that transaction that is not the specific Party itself. - -When an Agent is involved in such a transaction, it will be communicating with a component that it assumes to be an Agent of the Peer Party of its Owner (the 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 with which the specific Agent has a communications session. Note that establishing whether or not an Actor is a Peer Agent does not necessarily require knowing who the Peer Party actually is. - -The figure below is an overview of the most important *functional* components that any Party needs to conduct electronic business transactions. - -![eSSIF-Lab Single Party Functional Architecture Overview](https://essif-lab.pages.grnet.gr/framework//images/functional-architecture.png) - -*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 Owner of the component that uses them to configure themselves, and/or act according to the Owner’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. - -The remainder of this chapter describes the layers and their components at a high abstraction level. - -### 2.1. Business Transaction Layers - -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 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 task of the %%_Transaction Validation Engine_|transaction-validation-engine%% (or %%_TVE_|tve%%) 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 Owner needs, and providing data on behalf of its Owner that a Peer Agent requests. After all, a business transaction can only start after all Parties 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 TVE must ensure that the transaction context is properly maintained if it chooses to exchange data through different communication channels. - -The task of the %%_Transaction Result Dispatcher_|transaction-result-dispatcher%% (or %%_TRD_|trd%%) 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. 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, 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 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’, i.e. sets of (related) statements/claims (e.g. as produced by the TRD) that have metadata (e.g. date of issuing) and a digital signature by which third Parties can prove its provenance and integrity. Another function of the issuer is to handle revocation (and (un)suspension) of credentials that it has issued. For such tasks, it relies on functions that are made available by the SSI Protocols and Crypto Layer. - -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. 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. - -The **verifier** functionality is to support the TVE as it tries to acquire credentials from some other Party for the purpose of negotiating a business transaction. It does so by creating Presentation Requests (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’), verifying the Presentation, i.e. checking the signature and other proofs of the veracity of both the construction of the Presentation as well as its contents, thus providing the TVE with verified data. - -The task of the **holder** is to handle Presentation Requests that it receives from Verifier components (both of its Owner, and of other Parties). Typically, this means looking for the requested data in the Owner’s 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 for the purpose of obtaining the needed credential, which - when obtained - it can subsequently store in the wallet and use in the 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, Holder, Issuer and 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. - -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 such as [*Verifiable Credentials*](https://www.w3.org/TR/vc-data-model/) (VCs), [*Attribute Based Credentials*](https://abc4trust.eu/index.php/pub)[ABC] (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. - -Then, there are **secure communications technologies**, for the purposes of (a) ensuring that a technical component owned by a specific Party can recognize that another component as one that it has had previous communications with and/or is owned by an identified Party, and (b) setting up a secure communications channel, i.e. one that guarantees message confidentiality (encryption) and integrity/authentication. A well-known way to do this is SSL, but new ones are being developed, such as [*DID Comm(unication)*](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0005-didcomm), that uses [*peer DIDs*](https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/draft-documents/peer-DID-method-spec-report.md) (work in progress). - -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)[eIDAS] 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 definitions, 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) - ------- - -[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. - ------- - -### 2.4. API Layers (‘ESSIF Glue’ and ‘SSI Tech APIs’) - -There are two interface layers in this architecture - -The \`%%_ESSIF Glue_|eSSIFGlue%%\` interface layer consists of a [documented set of APIs](https://gitlab.grnet.gr/essif-lab/tno-ssi-service/developer-docs) between the TVE and TRD 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 Transaction Result Dispatcher and Transaction (Validation) Engine. Ultimately, we would like to see these APIs standardized. Having such APIs allows different Parties to create their own version of the WHIV components, supporting the SSI technologies as they see fit, and shrinking or expanding functionalities as they feel appropriate. Parties can then select such WHIV components as they see fit. - -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 - -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: - -![eSSIF-Lab functional components that are part of the eSSIF-Lab infrastructure](https://essif-lab.pages.grnet.gr/framework//images/functional-architecture-infra.png) - -*Figure 2: eSSIF-Lab infrastructural (functional) components.* - -### 3.1. Transaction (Validation) Engine and Validation Policy - -The purpose of the Transaction (Validation) Engine (TVE) is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an Agent of) its Owner to decide whether or not to engage in a (new) transaction of the specified type. - -Typically, the TVE 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.[TVE.1] - -In either case, a transaction form (object, context) has to be created that matches the kind of transaction, and a ‘**transaction-id**’ must be generated that identifies this form/object/context. It will be used for binding incoming or outgoing messages to this transaction, enabling communications to remain congruent, not only with the Agent that requested the transaction, but also with other Agents from the same Owner and/or using different communications channels. - -Handling/managing the various communications channels through which data can be exchanged is also a task of the TVE[TVE.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 TVE is generally considered capable of obtaining data through different communications channels. However, the technical tracks of eSSIF-Lab will exclusively focus on the communications channel through which credentials can be requested and obtained. Any extensions or business productization of TVE 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 TVE 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.[TVE.3] Also, when the TVE 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.[TVE.4] Also, as the TVE 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.[TVE.5] - -In order to make the TVE work, a Validation Policy (or TVE Policy) is created by, or on behalf of the Owner, which specifies at least: - -- the kinds of transactions the Owner 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[TVE.6]. - - - for each kind of credential: the verification proofs that must hold to be accepted as a source for valid data. - - - the mapping between fields in such credentials and fields in the form to be filled in. - -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 TVE Policy enable the TVE 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.[TVE.7] - -When the Verifier returns such data (which comes with a list of proofs that the Verifier has checked), the TVE 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 TVE 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 TVE itself must make validation decisions, either electronically (according to the TVE policy) or by ‘outsourcing’ such decisions to human Agents of its Owner by providing an appropriate validation user interface. - -As long as data is needed, the TVE can intermittently request the verifier to produce it (or it can use other communications channels, which is outside scope for now). It does so until it times out, or the form has become ‘clean’. - ------ - -[TVE.1] This feature ensures that the transaction is really two-way, and both Parties can request credentials from the other. For example, a web-shop can then ask for a (delivery) address credential, and the customer can ask for a credential issued e.g. by the chamber of commerce that the web-shop is a legitimate company (and not some maffia website). - -[TVE.2] It may well be that this functionality can somehow be split off in the (near) future. - -[TVE.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 TVE. 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. - -[TVE.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. - -[TVE.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. - -[TVE.6] This enables the TVE to pass the endpoint URI on to the Verifier when it requests for such a credential, which in turn can send it to the holder of other Parties enabling them to obtain the credential from that issuer endpoint if that other Party does not have that credential in its wallet. The endpoint URI can in fact be put in the policy, because the (human) Agent that creates/maintains the policy would need to know that the issuing Party is actually issuing such credentials, what their contents means, etc., and hence is capable of tracking down the URI where that Party issues the credentials. - -[TVE.7] A reference to this specification will be added when it becomes available (draft or otherwise). - ------ - -### 3.2. Verifier Component, and its Policy/Preferences - -The purpose of the Verifier component is to support the Transaction (Validation) Engine 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 TVE 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 TVE 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 TVE policy. - -Then, the Verifier needs to know the address and protocol that it can use to reach a Holder component owned by the Party that its Owner is trying to negotiate the transaction with. The TVE specifies this as part of the request - and it can do so because it has received the original request, and does all communications 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. - -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). - -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\] - -A response to this request (called a Presentation) will be obtained from a Holder component of the Peer 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). - -Then, the verifier will send a message to the TVE, containing the 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 component is to handle Presentation Requests that it receives from Verifier components (both of its own Owner, and of other Parties), and responding to such requests. - -Typically, a Holder component would access its Owner's Wallet to check if it has a credential that it can use to construct a Presentation (i.e. response) that satisfies the received request. - -It may happen that the Wallet does not have such a credential. However, for every (credential, issuer) pair, the request should specify the URI that is capable of issuing such a credential. If or when the Holder Policy/Preferences permit this, the Holder then requests its Owner’s TVE to initiate a new transaction that will get the credential from that issuer, for which a clean transaction form would then consist of one that contains said credential. The Holder would then store it in its Owner’s Wallet, and then proceed to service the presentation request as if it had obtained that credential from its Owner’s Wallet. - -It may 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.: - -- 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); -- the kinds of events and data to write to a holder-audit-log. - -### 3.4. Transaction Result Dispatcher and Issuing Policy - -The purpose of the TRD component is to state the (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other Parties. A special kind of result is the (provisioning of) a credential that its Owner already has created. - -Typically, and at any point in time, Parties are capable of expressing statements about entities that they know to exist. They could express statements about individuals, about themselves, the state of transactions, and so on. We will use the term ‘**subject (of a statement of a Party)**’ to refer to the entity that this Party knows to exist, and about whom/which the statement has been made. - -We will use the term ‘**subject-id (of a statement of a Party)**’ to refer to the representation that this Party has chosen to use for referring to the subject in said statement. A subject-id must have the property of being an identifier within every administrative context that this Party uses. It need not be humanly interpretable (and preferably is not). - -Parties need to specify the kinds of credentials they are willing to issue, the class of entities (e.g. people, cars, Organizations) for which it will issue them, and the information schema (structure) that it will use in credentials of such kinds.[TRD.1] This allows the TRD to construct data objects that conform to this information schema, and present it to the Issuer component for actual issuing. - -The TRD Issuing Policy specifies the kinds of (linked-)data-objects that credentials may be created for. This allows the TRD to construct such a (linked-)data-objects for every subject-id that identifies a subject of the class for which a credential can be issued, which can subsequently be sent to the Issuer component that can turn it into a credential of a specific sort. - -You can think of the TRD as the component that pulls all data together that can be put in a credential (e.g. in a passport), and the Issuer as the component that puts the data in an (empty) passport, and signing it so as to create the actual credential. - -The TRD may either push credential data to the Issuer component, so that the Issuer always has up-to-date credentials, or it can wait until the Issuer requests credential data for the creation of a credential of a specific type for a specific subject. - ------ - -[TRD.1] We assume/stipulate that the Party maintains a credential catalogue that contains this, and other information about every kind of credential that it issues, and that such catalogues are available to other Parties that want or need to use such credentials. - ------ - - - -### 3.5. Issuer Component, and its Policy/Preferences - -The purpose of the Issuer component is to issue ‘credentials’, i.e. digital constructs that contain - -- sets of (related) statements or claims (e.g. as produced by the TRD) -- metadata (e.g. type of credential, date of issuing and expiration, endpoints, e.g. for revocation checking, credential definition, credential advertisements, credential enforcement policy, etc.) -- proofs (e.g. a digital signature by which third Parties can prove its provenance and integrity. - -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. - -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 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 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). - -After the issuer has created a credential (in one or more formats), it checks the wallet to see if it contains a credential of the same type for the same subject. If (one or more formats) are there, and their contents are the same as the newly created credential, the existing ones are revoked, deleted and/or archived/tombstoned.[Issuer.1] Then, the newly created credential is added to the wallet (in one or more formats). Thus, at any point in time, the wallet will contain an actual set of all credentials that have been issued.[Issuer.2] - ------ - -[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 component in their SSI app, to issue self-signed credentials and provide them to verifiers that request them as usual for non-self-signed credentials. - ------ - - -### 3.6. Wallet Component, and its Policy/Preferences - -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, and -- (private) keys e.g. for signing/sealing data on behalf of its Owner. - -Other kinds of data may be stored by a wallet as well - we will have to see what is practical and makes sense. - -By ‘securely storing data’ we mean that such data - -- remains available until a request is received from an electronic Colleague that is entitled to request deletion of such data; -- remains unchanged during the time in which it is stored; - -- 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. - -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 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. - -## 4. Initial SSI-Agent Network Architecture - -:::info -*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 need to deploy (technical) components that act as their Agents. Individuals would typically have a mobile app whose user interface allows them to fulfill any or all of the roles of holder, verifier and issuer. Wallet functionality may be included in this app, but it might equally well live in the cloud, as a second (technical) Agent. An individual might also have (cloud) servers that Agents of other parties may contact for conducting transactions without the need for the individual itself to do something. All of this holds equally well for larger Organizations. - -It is conceivable that the set of SSI functions is spread over multiple (technical) Agents, in which case there is going to be a need for such Agents to contact one another, and conduct transactions in a way that may differ from doing that with Agents of other Parties. Basically, this can be seen as Colleagues interacting with one another to get things done within one Organization. Seen from the outside, it looks like every Organization has a (smaller or larger) network of Agents. 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 of a single, specific Party. -2. the **inter-Party or multi-Party SSI viewpoint**, which is about specific functional components (e.g. Verifier, Holder, etc.) that typically belong to different Parties. - -An individual 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 Agents. The set of concerns would include: - -- How can electronic components be onboarded as an Agents of this Party? -- How can the integrity of such electronic Agents 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 specify which of its Agents may talk with which other Agents, and for what purposes? -- How should a Party specify the policies for the various SSI functionalities - what kind of support would be useful here? -- … - -Parties 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: - -- How can Parties interact with one another at the information level (this includes decentralized semantic interoperability issues, advertising credentials, how a Party can find other Parties that issue credentials that are useful to him, etc.) -- What kinds of underlying technologies must Agents of a Party support so as to be(come) interoperable with Parties that it wants to interact with? -- … - -## 5. High Level Transaction Flows - -This chapter explains at a high level how electronic business transactions 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. For illustrative purposes, we stick to the example of getting a parking permit that we introduced in section 1.1. - -### 5.1. Overview - -
- -![eSSIF-Lab - high level trx overview](https://essif-lab.pages.grnet.gr/framework//images/high-level-trx-overview.png) - -The adjacent figure shows how a transaction is conducted at the highest abstraction level. One Party, called the ‘Requester’, sends a request for a product or service to another 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 to (individually/subjectively) decide whether or not to commit to the transaction. Section 3.2 provides more detail about this phase. - -After commitment, the producer works to provide the %%product|essiflab-concept-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. - -When all is done, Parties may issue a (signed) statement that specifies the results. Section 3.3. provides some more details about this phase. - -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 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 that states the result of the transaction, i.e. contains the details of the parking permit. - -Please note that while transactions 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 perform are ordered in time, which implies e.g. that the commitment decisions of both Parties cannot be done at the same time. Also, in practice, it often happens that a Party requires the other 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. - -### 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 quits, or both Parties commit. - -![eSSIF-Lab - high level trx negotiation](https://essif-lab.pages.grnet.gr/framework//images/high-level-trx-negotiation.png) -The adjacent 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 communications channel, i.e. a secure communications channel through which provider and requester can both request and obtain (presentations of) credentials, 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. - -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 credential presentations and responding to such requests may very well consist of multiple requests and associated responses. - -In the example of the parking permit, the municipality might ask for a credential that proves the requester is a citizen that is a registered inhabitant of said municipality, a credential stating its residential address, a credential stating the make and license plate of the vehicle for which a parking permit is requested, etc. All this is subject to the policy that the municipality has established for issuing such permits, and hence, it must be expected to differ between municipalities. - -An example of conditionally required fields would be when the requester wants the municipality to customize the parking lot, e.g. because the requester has disabilities. Assessing such circumstances depends on the (optional) field where the requester must state any disabilities they have, and when that is the case, the requester may be asked to fill in fields such as whether or not a parking lot has to be customized (painted blue, with a sign stating that it is reserved for the provided license-place, or the kind of charging device if they have an electric vehicle). - -Conversely, the citizen might request the (alleged) municipality to provide credentials, e.g. to prove that it is actually an official municipality of the country it is part of. This would provide assurance to the citizen that it would actually be paying the fees to that municipality rather than to e.g. a rogue Organization that might have spoofed the website of the municipality. - -### 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 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 has been changed/tampered with since it was issued). From this, it follows that any Party can issue any kind of credential for any entity that it knows to exist. A credential does not need to be about a person or an Organization, but it can also refer to an order, a delivery, a seat-reservation, a prescription, etc. - -We foresee two ways in which credentials can be issued: - -1. both the requester and provider may issue credentials to the other 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 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 that contains the details of that permit. The requester may issue a 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 may issue a credential upon request. Basically, this means that a Party (in the role of requester) issues a request to that other Party (in the role of provider) asking for the particular 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, 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 without further ado, or start the process of issuing a new one. - -## 6. Detailed Transaction Flows - -:::info -*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.* -::: - -This chapter explains the details of how electronic business transactions 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, requester and provider, each have components as described in chapter 2. Also note that whenever we introduce another Party, it too has such components. Thus, every Party can play any of the traditional SSI roles ‘verifier’, ‘holder’ and ‘issuer’, and each has its own ‘wallet’ functionality. Also, they all have TVE and TRD 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 communicates with another component, this other component may be of the same Party, as well as of the other Party. Figure 2 only shows components that belong to a single Party. - -### 6.1. Starting a Transaction - -:::info -*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 TVE component. - -The TVE 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 communications 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 of various Parties will be communicating. - -It is a task of the TVE 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; -- may be changed manually; -- may be changed with data from a newly supplied credential. - -Because of this orchestration, the interface to the verifier component can be quite simple; it is shown in the image below: - -![Generic Verification with SSI service](https://essif-lab.pages.grnet.gr/framework//images/generic-verification-with-ssi-service.png) - -The request identifier is included in messages between the TVE and verifier so as to allow them to handle different transactions 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. - -### 6.2. Stating a Transaction - -:::info -*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.* -::: - -![Generic Issuing with SSI service](https://essif-lab.pages.grnet.gr/framework//images/generic-issuing-with-ssi-service.png) diff --git a/doc-sources/func-arch/functional-architecture-overview.md b/doc-sources/func-arch/functional-architecture-overview.md deleted file mode 100644 index 7c6bbbc..0000000 --- a/doc-sources/func-arch/functional-architecture-overview.md +++ /dev/null @@ -1,382 +0,0 @@ ---- -id: functional-architecture-overview -title: eSSIF-Lab Functional Architecture Overview ---- - -The primary purpose of the eSSIF-Lab Functional Architecture is to provide an overview and detailed specifications of the various functions/capabilities that are needed to allow %%parties|party%% to (electronically) conduct %%business transactions|business-transaction%% with one another. The functional architecture also shows how such capabilities work together to achieve this. - -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). - -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 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*. - -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)_|peer-party%%’ to refer to the participating Party in that transaction that is not the specific Party itself. - -When an Agent is involved in such a transaction, it will be communicating with a component that it assumes to be an Agent of the Peer Party of its Owner (the 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 with which the specific Agent has a communications session. Note that establishing whether or not an Actor is a Peer Agent does not necessarily require knowing who the Peer Party actually is. - -The figure below is an overview of the most important *functional* components that any Party needs to conduct electronic business transactions. - -![eSSIF-Lab Single Party Functional Architecture Overview](https://essif-lab.pages.grnet.gr/framework//images/functional-architecture.png) - -*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 Owner of the component that uses them to configure themselves, and/or act according to the Owner’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. - -The remainder of this chapter describes the layers and their components at a high abstraction level. - -### 2.1. Business Transaction Layers - -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 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 task of the %%_Transaction Validation Engine_|transaction-validation-engine%% (or %%_TVE_|tve%%) 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 Owner needs, and providing data on behalf of its Owner that a Peer Agent requests. After all, a business transaction can only start after all Parties 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 TVE must ensure that the transaction context is properly maintained if it chooses to exchange data through different communication channels. - -The task of the %%_Transaction Result Dispatcher_|transaction-result-dispatcher%% (or %%_TRD_|trd%%) 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. 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, 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 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’, i.e. sets of (related) statements/claims (e.g. as produced by the TRD) that have metadata (e.g. date of issuing) and a digital signature by which third Parties can prove its provenance and integrity. Another function of the issuer is to handle revocation (and (un)suspension) of credentials that it has issued. For such tasks, it relies on functions that are made available by the SSI Protocols and Crypto Layer. - -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. 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. - -The **verifier** functionality is to support the TVE as it tries to acquire credentials from some other Party for the purpose of negotiating a business transaction. It does so by creating Presentation Requests (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’), verifying the Presentation, i.e. checking the signature and other proofs of the veracity of both the construction of the Presentation as well as its contents, thus providing the TVE with verified data. - -The task of the **holder** is to handle Presentation Requests that it receives from Verifier components (both of its Owner, and of other Parties). Typically, this means looking for the requested data in the Owner’s 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 for the purpose of obtaining the needed credential, which - when obtained - it can subsequently store in the wallet and use in the 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, Holder, Issuer and 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. - -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 such as [*Verifiable Credentials*](https://www.w3.org/TR/vc-data-model/) (VCs), [*Attribute Based Credentials*](https://abc4trust.eu/index.php/pub)[ABC] (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. - -Then, there are **secure communications technologies**, for the purposes of (a) ensuring that a technical component owned by a specific Party can recognize that another component as one that it has had previous communications with and/or is owned by an identified Party, and (b) setting up a secure communications channel, i.e. one that guarantees message confidentiality (encryption) and integrity/authentication. A well-known way to do this is SSL, but new ones are being developed, such as [*DID Comm(unication)*](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0005-didcomm), that uses [*peer DIDs*](https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/draft-documents/peer-DID-method-spec-report.md) (work in progress). - -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)[eIDAS] 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 definitions, 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) - ------- - -[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. - ------- - -### 2.4. API Layers (‘ESSIF Glue’ and ‘SSI Tech APIs’) - -There are two interface layers in this architecture - -The \`%%_ESSIF Glue_|eSSIF Glue%%\` interface layer consists of a [documented set of APIs](https://gitlab.grnet.gr/essif-lab/tno-ssi-service/developer-docs) between the TVE and TRD 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 Transaction Result Dispatcher and Transaction (Validation) Engine. Ultimately, we would like to see these APIs standardized. Having such APIs allows different Parties to create their own version of the WHIV components, supporting the SSI technologies as they see fit, and shrinking or expanding functionalities as they feel appropriate. Parties can then select such WHIV components as they see fit. - -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 - -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: - -![eSSIF-Lab functional components that are part of the eSSIF-Lab infrastructure](https://essif-lab.pages.grnet.gr/framework//images/functional-architecture-infra.png) - -*Figure 2: eSSIF-Lab infrastructural (functional) components.* - -### 3.1. Transaction (Validation) Engine and Validation Policy - -The purpose of the Transaction (Validation) Engine (TVE) is to produce (transaction-type specific) data structures or forms, each of which contains the necessary and sufficient data that allows (an Agent of) its Owner to decide whether or not to engage in a (new) transaction of the specified type. - -Typically, the TVE 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.[TVE.1] - -In either case, a transaction form (object, context) has to be created that matches the kind of transaction, and a ‘**transaction-id**’ must be generated that identifies this form/object/context. It will be used for binding incoming or outgoing messages to this transaction, enabling communications to remain congruent, not only with the Agent that requested the transaction, but also with other Agents from the same Owner and/or using different communications channels. - -Handling/managing the various communications channels through which data can be exchanged is also a task of the TVE[TVE.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 TVE is generally considered capable of obtaining data through different communications channels. However, the technical tracks of eSSIF-Lab will exclusively focus on the communications channel through which credentials can be requested and obtained. Any extensions or business productization of TVE 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 TVE 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.[TVE.3] Also, when the TVE 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.[TVE.4] Also, as the TVE 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.[TVE.5] - -In order to make the TVE work, a Validation Policy (or TVE Policy) is created by, or on behalf of the Owner, which specifies at least: - -- the kinds of transactions the Owner 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[TVE.6]. - - - for each kind of credential: the verification proofs that must hold to be accepted as a source for valid data. - - - the mapping between fields in such credentials and fields in the form to be filled in. - -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 TVE Policy enable the TVE 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.[TVE.7] - -When the Verifier returns such data (which comes with a list of proofs that the Verifier has checked), the TVE 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 TVE 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 TVE itself must make validation decisions, either electronically (according to the TVE policy) or by ‘outsourcing’ such decisions to human Agents of its Owner by providing an appropriate validation user interface. - -As long as data is needed, the TVE can intermittently request the verifier to produce it (or it can use other communications channels, which is outside scope for now). It does so until it times out, or the form has become ‘clean’. - ------ - -[TVE.1] This feature ensures that the transaction is really two-way, and both Parties can request credentials from the other. For example, a web-shop can then ask for a (delivery) address credential, and the customer can ask for a credential issued e.g. by the chamber of commerce that the web-shop is a legitimate company (and not some maffia website). - -[TVE.2] It may well be that this functionality can somehow be split off in the (near) future. - -[TVE.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 TVE. 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. - -[TVE.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. - -[TVE.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. - -[TVE.6] This enables the TVE to pass the endpoint URI on to the Verifier when it requests for such a credential, which in turn can send it to the holder of other Parties enabling them to obtain the credential from that issuer endpoint if that other Party does not have that credential in its wallet. The endpoint URI can in fact be put in the policy, because the (human) Agent that creates/maintains the policy would need to know that the issuing Party is actually issuing such credentials, what their contents means, etc., and hence is capable of tracking down the URI where that Party issues the credentials. - -[TVE.7] A reference to this specification will be added when it becomes available (draft or otherwise). - ------ - -### 3.2. Verifier Component, and its Policy/Preferences - -The purpose of the Verifier component is to support the Transaction (Validation) Engine 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 TVE 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 TVE 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 TVE policy. - -Then, the Verifier needs to know the address and protocol that it can use to reach a Holder component owned by the Party that its Owner is trying to negotiate the transaction with. The TVE specifies this as part of the request - and it can do so because it has received the original request, and does all communications 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. - -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). - -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\] - -A response to this request (called a Presentation) will be obtained from a Holder component of the Peer 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). - -Then, the verifier will send a message to the TVE, containing the 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 component is to handle Presentation Requests that it receives from Verifier components (both of its own Owner, and of other Parties), and responding to such requests. - -Typically, a Holder component would access its Owner's Wallet to check if it has a credential that it can use to construct a Presentation (i.e. response) that satisfies the received request. - -It may happen that the Wallet does not have such a credential. However, for every (credential, issuer) pair, the request should specify the URI that is capable of issuing such a credential. If or when the Holder Policy/Preferences permit this, the Holder then requests its Owner’s TVE to initiate a new transaction that will get the credential from that issuer, for which a clean transaction form would then consist of one that contains said credential. The Holder would then store it in its Owner’s Wallet, and then proceed to service the presentation request as if it had obtained that credential from its Owner’s Wallet. - -It may 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.: - -- 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); -- the kinds of events and data to write to a holder-audit-log. - -### 3.4. Transaction Result Dispatcher and Issuing Policy - -The purpose of the TRD component is to state the (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other Parties. A special kind of result is the (provisioning of) a credential that its Owner already has created. - -Typically, and at any point in time, Parties are capable of expressing statements about entities that they know to exist. They could express statements about individuals, about themselves, the state of transactions, and so on. We will use the term ‘**subject (of a statement of a Party)**’ to refer to the entity that this Party knows to exist, and about whom/which the statement has been made. - -We will use the term ‘**subject-id (of a statement of a Party)**’ to refer to the representation that this Party has chosen to use for referring to the subject in said statement. A subject-id must have the property of being an identifier within every administrative context that this Party uses. It need not be humanly interpretable (and preferably is not). - -Parties need to specify the kinds of credentials they are willing to issue, the class of entities (e.g. people, cars, Organizations) for which it will issue them, and the information schema (structure) that it will use in credentials of such kinds.[TRD.1] This allows the TRD to construct data objects that conform to this information schema, and present it to the Issuer component for actual issuing. - -The TRD Issuing Policy specifies the kinds of (linked-)data-objects that credentials may be created for. This allows the TRD to construct such a (linked-)data-objects for every subject-id that identifies a subject of the class for which a credential can be issued, which can subsequently be sent to the Issuer component that can turn it into a credential of a specific sort. - -You can think of the TRD as the component that pulls all data together that can be put in a credential (e.g. in a passport), and the Issuer as the component that puts the data in an (empty) passport, and signing it so as to create the actual credential. - -The TRD may either push credential data to the Issuer component, so that the Issuer always has up-to-date credentials, or it can wait until the Issuer requests credential data for the creation of a credential of a specific type for a specific subject. - ------ - -[TRD.1] We assume/stipulate that the Party maintains a credential catalogue that contains this, and other information about every kind of credential that it issues, and that such catalogues are available to other Parties that want or need to use such credentials. - ------ - - - -### 3.5. Issuer Component, and its Policy/Preferences - -The purpose of the Issuer component is to issue ‘credentials’, i.e. digital constructs that contain - -- sets of (related) statements or claims (e.g. as produced by the TRD) -- metadata (e.g. type of credential, date of issuing and expiration, endpoints, e.g. for revocation checking, credential definition, credential advertisements, credential enforcement policy, etc.) -- proofs (e.g. a digital signature by which third Parties can prove its provenance and integrity. - -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. - -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 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 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). - -After the issuer has created a credential (in one or more formats), it checks the wallet to see if it contains a credential of the same type for the same subject. If (one or more formats) are there, and their contents are the same as the newly created credential, the existing ones are revoked, deleted and/or archived/tombstoned.[Issuer.1] Then, the newly created credential is added to the wallet (in one or more formats). Thus, at any point in time, the wallet will contain an actual set of all credentials that have been issued.[Issuer.2] - ------ - -[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 component in their SSI app, to issue self-signed credentials and provide them to verifiers that request them as usual for non-self-signed credentials. - ------ - - -### 3.6. Wallet Component, and its Policy/Preferences - -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, and -- (private) keys e.g. for signing/sealing data on behalf of its Owner. - -Other kinds of data may be stored by a wallet as well - we will have to see what is practical and makes sense. - -By ‘securely storing data’ we mean that such data - -- remains available until a request is received from an electronic Colleague that is entitled to request deletion of such data; -- remains unchanged during the time in which it is stored; - -- 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. - -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 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. - -## 4. Initial SSI-Agent Network Architecture - -:::info -*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 need to deploy (technical) components that act as their Agents. Individuals would typically have a mobile app whose user interface allows them to fulfill any or all of the roles of holder, verifier and issuer. Wallet functionality may be included in this app, but it might equally well live in the cloud, as a second (technical) Agent. An individual might also have (cloud) servers that Agents of other parties may contact for conducting transactions without the need for the individual itself to do something. All of this holds equally well for larger Organizations. - -It is conceivable that the set of SSI functions is spread over multiple (technical) Agents, in which case there is going to be a need for such Agents to contact one another, and conduct transactions in a way that may differ from doing that with Agents of other Parties. Basically, this can be seen as Colleagues interacting with one another to get things done within one Organization. Seen from the outside, it looks like every Organization has a (smaller or larger) network of Agents. 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 of a single, specific Party. -2. the **inter-Party or multi-Party SSI viewpoint**, which is about specific functional components (e.g. Verifier, Holder, etc.) that typically belong to different Parties. - -An individual 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 Agents. The set of concerns would include: - -- How can electronic components be onboarded as an Agents of this Party? -- How can the integrity of such electronic Agents 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 specify which of its Agents may talk with which other Agents, and for what purposes? -- How should a Party specify the policies for the various SSI functionalities - what kind of support would be useful here? -- … - -Parties 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: - -- How can Parties interact with one another at the information level (this includes decentralized semantic interoperability issues, advertising credentials, how a Party can find other Parties that issue credentials that are useful to him, etc.) -- What kinds of underlying technologies must Agents of a Party support so as to be(come) interoperable with Parties that it wants to interact with? -- … - -## 5. High Level Transaction Flows - -This chapter explains at a high level how electronic business transactions 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. For illustrative purposes, we stick to the example of getting a parking permit that we introduced in section 1.1. - -### 5.1. Overview - -
- -![eSSIF-Lab - high level trx overview](https://essif-lab.pages.grnet.gr/framework//images/high-level-trx-overview.png) - -The adjacent figure shows how a transaction is conducted at the highest abstraction level. One Party, called the ‘Requester’, sends a request for a product or service to another 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 to (individually/subjectively) decide whether or not to commit to the transaction. Section 3.2 provides more detail about this phase. - -After commitment, the producer works to provide the %%product|essiflab-concept-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. - -When all is done, Parties may issue a (signed) statement that specifies the results. Section 3.3. provides some more details about this phase. - -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 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 that states the result of the transaction, i.e. contains the details of the parking permit. - -Please note that while transactions 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 perform are ordered in time, which implies e.g. that the commitment decisions of both Parties cannot be done at the same time. Also, in practice, it often happens that a Party requires the other 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. - -### 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 quits, or both Parties commit. - -![eSSIF-Lab - high level trx negotiation](https://essif-lab.pages.grnet.gr/framework//images/high-level-trx-negotiation.png) -The adjacent 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 communications channel, i.e. a secure communications channel through which provider and requester can both request and obtain (presentations of) credentials, 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. - -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 credential presentations and responding to such requests may very well consist of multiple requests and associated responses. - -In the example of the parking permit, the municipality might ask for a credential that proves the requester is a citizen that is a registered inhabitant of said municipality, a credential stating its residential address, a credential stating the make and license plate of the vehicle for which a parking permit is requested, etc. All this is subject to the policy that the municipality has established for issuing such permits, and hence, it must be expected to differ between municipalities. - -An example of conditionally required fields would be when the requester wants the municipality to customize the parking lot, e.g. because the requester has disabilities. Assessing such circumstances depends on the (optional) field where the requester must state any disabilities they have, and when that is the case, the requester may be asked to fill in fields such as whether or not a parking lot has to be customized (painted blue, with a sign stating that it is reserved for the provided license-place, or the kind of charging device if they have an electric vehicle). - -Conversely, the citizen might request the (alleged) municipality to provide credentials, e.g. to prove that it is actually an official municipality of the country it is part of. This would provide assurance to the citizen that it would actually be paying the fees to that municipality rather than to e.g. a rogue Organization that might have spoofed the website of the municipality. - -### 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 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 has been changed/tampered with since it was issued). From this, it follows that any Party can issue any kind of credential for any entity that it knows to exist. A credential does not need to be about a person or an Organization, but it can also refer to an order, a delivery, a seat-reservation, a prescription, etc. - -We foresee two ways in which credentials can be issued: - -1. both the requester and provider may issue credentials to the other 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 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 that contains the details of that permit. The requester may issue a 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 may issue a credential upon request. Basically, this means that a Party (in the role of requester) issues a request to that other Party (in the role of provider) asking for the particular 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, 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 without further ado, or start the process of issuing a new one. - -## 6. Detailed Transaction Flows - -:::info -*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.* -::: - -This chapter explains the details of how electronic business transactions 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, requester and provider, each have components as described in chapter 2. Also note that whenever we introduce another Party, it too has such components. Thus, every Party can play any of the traditional SSI roles ‘verifier’, ‘holder’ and ‘issuer’, and each has its own ‘wallet’ functionality. Also, they all have TVE and TRD 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 communicates with another component, this other component may be of the same Party, as well as of the other Party. Figure 2 only shows components that belong to a single Party. - -### 6.1. Starting a Transaction - -:::info -*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 TVE component. - -The TVE 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 communications 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 of various Parties will be communicating. - -It is a task of the TVE 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; -- may be changed manually; -- may be changed with data from a newly supplied credential. - -Because of this orchestration, the interface to the verifier component can be quite simple; it is shown in the image below: - -![Generic Verification with SSI service](https://essif-lab.pages.grnet.gr/framework//images/generic-verification-with-ssi-service.png) - -The request identifier is included in messages between the TVE and verifier so as to allow them to handle different transactions 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. - -### 6.2. Stating a Transaction - -:::info -*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.* -::: - -![Generic Issuing with SSI service](https://essif-lab.pages.grnet.gr/framework//images/generic-issuing-with-ssi-service.png) diff --git a/doc-sources/glossary.md b/doc-sources/glossary.md deleted file mode 100644 index 986d4b1..0000000 --- a/doc-sources/glossary.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -id: essifLab-glossary -title: "eSSIF-Lab Glossary" ---- - -:::note Editor's note -TNO to write the introduction paragraph -::: diff --git a/doc-sources/introduction.md b/doc-sources/introduction.md deleted file mode 100644 index 5931781..0000000 --- a/doc-sources/introduction.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -id: introduction -title: Introduction ---- - -The European Self-Sovereign Identity Lab ([eSSIF-Lab](https://essif-lab.eu/)) views itself as an ecosystem of parties -that work together to make existing (and new) Self-Sovereign Identity (SSI) technology into -a scalable and interoperable infrastructure that businesses can use very easily -for conducting (business) transactions with other businesses and individuals alike. -Typically, the libraries, code or components for the infrastructure should be open source. - -In order to support the use of such an infrastructure by businesses and individuals, -eSSIF-Lab parties also create applications and other tooling to support such actual use -on top of the interoperable infrastructure, which may or may not be open source, -and are expected to be used as/in products of organizations that want to make this their business. - -At the start, eSSIF-Lab is one of the European [NGI projects](https://www.ngi.eu/ngi-projects/) -and helps (EU) parties that want to contribute by publishing [open calls](https://essif-lab.eu/?page_id=134) -to which such parties can submit work proposals that eSSIF-Lab will then consider for funding. - -## eSSIF-Lab Framework Repository - -This repo contains the documents that describe the vision, architecture and other -topics that are relevant to the eSSIF-Lab Framework. Currently, it contains: - -- [Vision and purpose](vision-and-purpose) -- [Functional architecture](functional-architecture) -- [SSI standards](ssi-standards) - -## Acknowledgement - -This site is part of the eSSIF-Lab project that has received funding from the [European Union’s Horizon 2020 Research and Innovation Programme] under grant agreement Nº 871932. \ No newline at end of file diff --git a/doc-sources/notations-and-conventions.md b/doc-sources/notations-and-conventions.md deleted file mode 100644 index ba956ed..0000000 --- a/doc-sources/notations-and-conventions.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -id: notations-and-conventions -title: Notations and Conventions Used in this Documentation ---- - -Here, we provide an overview of the notations and conventions being used within eSSIF-Lab. - - -## RFC 2119 -We shall use keywords such as “shall”, “should”, “may” etc. as defined by [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). - -## Capitalization of words in mid-sentence -Also, we capitalize words in mid-sentence whenever it is used in the meaning as provided by a corresponding Definition. This allows us to also use the more colloquial meanings of words (by not capitalizing them). We appreciate any feedback regarding our (im)proper use of this kind of capitalization of words. - -We are working towards deprecating this convention, as we now have better ways to refer to %%definitions|definition%%. - -## Pattern diagram notations - -%%Pattern|pattern%% diagrams will be visualized in this document using a UML-like notation, as follows: - -- a **rectangle** represents a (named) concept. Concepts serve as entity-classes. Their (operational) extensions, i.e. the respective sets of (runtime) instances, are disjunct. -- a **solid line with a closed arrowhead** represent a (named) relation/association between the two concepts it connects. The concept at the arrowhead is called the ‘target concept’ (TGT) for that relation. The concept at the other end is called the ‘source concept’ (SRC) for that relation. Names are chosen such that ` ` is a phrase that suggests the intension(al definition) of that relation. -- a **dashed line** signifies that its intension is created by combination the intensions of other relations (it is a ‘shorthand’ for a path of other relations). -- an **open-ended arrow** is an ‘ISA’ relation, which can be read as ` ISA `. It means that SRC is a specialization of TGT (which is a generalization of SRC). Thus, SRC must satisfy all constraints that TGT must satisfy, and has all attributes (including properties) that TGT has. -- **Multiplicities** use the [n..m] notation. When a multiplicity is omitted, [0..n] is intended. -- A **concept that is coloured red(dish)** represents a notion that is commonly used ‘in the wild’ (and hence needs not be defined here), relates to one or more concepts we need for the pattern, yet is not the same. We include such ‘red concepts’ to help readers identify and subsequently bridge gaps between commonly held thoughts and the (sometimes subtly) different meanings we need in our model. \ No newline at end of file diff --git a/doc-sources/pattern-list.md b/doc-sources/pattern-list.md deleted file mode 100644 index 54a3aa9..0000000 --- a/doc-sources/pattern-list.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -id: essifLab-pattern-list -title: "eSSIF-Lab List of Patterns" ---- - -:::note Editor's note -TNO to write the introduction paragraph -::: diff --git a/doc-sources/ssi-standards.md b/doc-sources/ssi-standards.md deleted file mode 100644 index ab28404..0000000 --- a/doc-sources/ssi-standards.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -id: ssi-standards -title: SSI Standards ---- - -The purpose of this document is to provide an overview of standards activities for self-sovereign identity (SSI) and their relevance to eSSIF-Lab. - -## 1. Introduction - -Self-sovereign identity (SSI) is work in progress, which includes the work on standards for SSI. Such standards include frameworks, schemas, data models, protocols, APIs, open-source code and more. The present document provides an overview on those standards and work-in-progress. Most pieces of text have been directly copied from the referenced websites. - -## 2. W3C CCG: Credentials Community Group - -The [W3C Credentials Community Group](https://www.w3.org/community/credentials/) explores the creation, storage, presentation, verification, and user control of credentials. It focuses on a verifiable credential (a set of claims) created by an issuer about a subject—a person, group, or thing—and seek solutions inclusive of approaches such as: self-sovereign identity; presentation of proofs by the bearer; data minimization; and centralized, federated, and decentralized registry and identity systems. Its tasks include drafting and incubating Internet specifications for further standardization and prototyping and testing reference implementations. - -W3C CCG has published a first version of [Verifiable Claims Data Model and Representations 1.0](https://www.w3.org/2017/05/vc-data-model/CGFR/2017-05-01/) in May 2017. That specification introduces verifiable claims as follows. - -A self-sovereign architecture for verifiable claims is one where the holder of a verifiable claim is in complete control of their identifier, where their verifiable claims are stored, and how they are used. There is currently no widely used self-sovereign, privacy-enhancing standard for expressing and transacting verifiable claims (aka: credentials, attestations) via the Web. This specification describes a data model for a digital [identity profile](https://www.w3.org/2017/05/vc-data-model/CGFR/2017-05-01/#dfn-identity-profile) and a collection of digital [entity credentials](https://www.w3.org/2017/05/vc-data-model/CGFR/2017-05-01/#dfn-entity-credential) that assert verifiable [claims](https://www.w3.org/2017/05/vc-data-model/CGFR/2017-05-01/#dfn-claim) about that [identity profile](https://www.w3.org/2017/05/vc-data-model/CGFR/2017-05-01/#dfn-identity-profile). It also describes how to express that data model in JSON, JSON-LD, and WebIDL. - -## 3. W3C DID: Decentralized Identifier - -The [W3C DID Working Group](https://www.w3.org/2019/did-wg/) standardizes the DID URI scheme, the data model and syntax of DID Documents, which contain information related to DIDs that enable the aforementioned initial use cases, and the requirements for DID Method specifications. - -W3C DID is working on [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/). The June 2020 version of the working document introduces DIDs as follows. - -Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID identifies any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) that the controller of the DID decides that it identifies. These new identifiers are designed to enable the controller of a DID to prove control over it and to be implemented independently of any centralized registry, identity provider, or certificate authority. DIDs are URLs that associate a DID subject with a DID document allowing trustable interactions associated with that subject. Each DID document can express cryptographic material, verification methods, or service endpoints, which provide a set of mechanisms enabling a DID controller to prove control of the DID. Service endpoints enable trusted interactions associated with the DID subject. A DID document might contain semantics about the subject that it identifies. A DID document might contain the DID -subject itself (e.g. a data model). - -## 4. Hyperledger Indy: distributed ledger software - -[Hyperledger Indy](https://www.hyperledger.org/use/hyperledger-indy) provides tools, libraries, and reusable components for providing digital identities rooted on blockchains or other distributed ledgers so that they are interoperable across administrative domains, applications, and any other silo. Indy is interoperable with other blockchains or can be used standalone powering the decentralization of identity. The Indy repository can be found [here](https://wiki.hyperledger.org/display/indy/Hyperledger+Indy). - -## 5. Hyperledger Aries: protocols for communication of VC and DID - -[Hyperledger Aries](https://www.hyperledger.org/use/aries) provides a shared, reusable, interoperable tool kit designed for initiatives and solutions focused on creating, transmitting and storing digital verifiable credentials (VCs). It is infrastructure for blockchain-rooted, peer-to-peer interactions. The project consumes the cryptographic support provided by Hyperledger Ursa, to provide secure secret management and decentralized key management functionality. - -Hyperledger Aries allows trusted online peer-to-peer interactions based on decentralized identities and verifiable credentials. Aries includes a protocol definition, tools, and reference implementations. The Aries protocol supports identities rooted in a variety of distributed ledgers or blockchains. This approach to identity is often called Self Sovereign Identity (SSI). - -Key components of an [Aries solution](https://github.com/hyperledger/aries) are: - -- [agents](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0004-agents/README.md), -- [DID communications](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0005-didcomm/README.md), -- [protocols](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/README.md), -- and [key management](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0051-dkms/README.md). - -Moreover, Hyperledger Aries develops a set of Request for Comment (RFCs) that describe important topics standardize across the Aries ecosystem. There are 2 types of Aries RFCs: - -- RFCs that describe individual features (in the [features](https://github.com/hyperledger/aries-rfcs/blob/master/features) folder) -- RFCs that explain concepts underpinning many features (in the [concepts](https://github.com/hyperledger/aries-rfcs/blob/master/concepts) folder) - -RFCs are for developers *building on* Aries. They don't provide guidance on how Aries components implement features internally; individual Aries repos have design docs for that. Each Aries RFC includes an "implementations" section and all RFCs with a status greater than Proposed should have at least one listed implementation. - - -## 6. Hyperledger Ursa: cryptographic library - -[Hyperledger Ursa](https://www.hyperledger.org/use/ursa) is a shared cryptographic library, it enables implementations to avoid duplicating other cryptographic work and hopefully increase security in the process. The library is an opt-in repository (for Hyperledger and non Hyperledger projects) to place and use crypto. Hyperledger Ursa consists of sub-projects, which are cohesive implementations of cryptographic code or interfaces to cryptographic code. The Ursa repository can be found [here](https://github.com/hyperledger/ursa). - - -## 7. DIF: Decentralized identity Foundation - -[Decentralized Identity Foundation](https://identity.foundation/) (DIF) is an engineering-driven organization focused on developing the foundational elements necessary to establish an open ecosystem for decentralized identity and ensure interop between all participants. - -DIF builds on W3C and Hyperledger work referenced above. Some of its work originates from Hyperledger Aries and has been moved to DIF for more effective management of IPR. DIF has among others the following working groups. - -* [Identifiers and Discovery](https://identity.foundation/working-groups/identifiers-discovery.html): A key piece of the decentralized identity equation is how people, organizations, and devices can be identified and located without centralized systems of identifiers (e.g. email addresses). DIF members are actively working on protocols and implementations that enable creation, resolution, and discovery of decentralized identifiers and names across decentralized systems, like blockchains and distributed ledgers. -* [Storage and Compute](https://identity.foundation/working-groups/storage-compute.html): Secure, encrypted, privacy-preserving storage and computation of data is a critical component of decentralized identity systems. As with identifiers and names must be self-sovereign to the owning entity, a user's identity data must remain private, only accessible to the entities they allow. DIF members are actively developing specs and reference implementations for provider-agnostic, run-anywhere solutions that provides these features. -* [Authentication](https://identity.foundation/working-groups/authentication.html): Designing and implementing DID-based authentication specs, standards, and libraries used in authenticating DIDs across a wide variety of exchanges and use cases. -* [Claims and Credentials](https://identity.foundation/working-groups/claims-credentials.html): The ability to verify the claims and assertions of identities is key in establishing trust among entities on a decentralized system that lacks a centralized hierarchy. The DIF Foundation has recently begun work on defining the specs, protocols, and tools it can provide to the ecosystem to help ecosystem participants and their customers easily integrate DID-signed claims into their apps and services. -* [DID Communication](https://identity.foundation/working-groups/did-comm.html): Produce one or more high-quality specs that embody a method (“DIDComm”) for secure, private and (where applicable) authenticated message-based communication, where trust is rooted in DIDs and depends on the messages themselves, not on the external properties of the transport(s) used. -* [Secure Data Storage](https://identity.foundation/working-groups/secure-data-storage.html): Create one or more specifications to establish a foundational layer for secure data storage (including personal data), specifically data models for storage and transport, syntax, data at rest protection, CRUD API, access control, synchronization, and at least a minimum viable HTTP-based interface compatible with W3C DIDs/VCs. - -## 7. Sovrin: SSI blockchain - -The [Sovrin Foundation](https://sovrin.org/) is a private-sector, international non-profit that was established to govern the world's first self-sovereign identity (SSI) network. The Sovrin blockchain network is based on Hyperledger Indy. Sovrin is governed by the [Sovrin Governance Framework](https://sovrin.org/library/sovrin-governance-framework/), which is a set of official documents that include legal agreements between participants in Sovrin. The services of Sovrin are registrations on the Sovrin blockchain: DIDs and DID Documents, VC schemas (generic), VC definitions (issuer-specific) and VC revocations. From 2017-2020, Sovrin has been funded via donations (Sovrin Alliance) and sale of future SOV tokens. In 2020, Sovrin started a transition process, revising its financing and structure. - -## 8. Trust-over-IP: full-stack governance - -The [Trust-over-IP foundation](https://trustoverip.org/) was founded mid 2020. It is defining a complete architecture for Internet-scale digital trust that combines both cryptographic trust at the machine layer and human trust at the business, legal, and social layers. It is has the following working group, as well as a few more that are still being started. - -* [Governance Stack](https://trustoverip.org/working-groups/governance-stack/): The scope of the Governance Stack Working Group is to define models and interoperability standards for governance frameworks that enable business, legal, and social trust between entities implementing the Trust over IP architecture stack as defined in [Hyperledger Aries RFC 0289](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0289-toip-stack) (or its successor as identified in the RFC document itself). -* [Technical Stack](https://trustoverip.org/working-groups/technical-stack/): The scope of the Technical Stack Working Group is to define (directly or by reference) the technical standards, test suites, and interoperability certification standards for the Trust over IP architecture stack as defined in [Hyperledger Aries RFC 0289](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0289-toip-stack) (or its successor as identified in the RFC document itself). -* [Utility Foundry](https://trustoverip.org/working-groups/utility-foundry/): The scope of the Utility Foundry Working Group is to facilitate a community of practice among governance authorities, implementers, operators, and service providers for Trust over IP Layer One utilities. The WG will provide process guidance for the establishment and monitoring of new ToIP Layer One utility projects, whether hosted at the Linux Foundation or external to it. Other WG activities will include creating template RFPs for service providers, maintaining a list of affiliated Foundry Service Providers, identifying areas of collaboration and alignment between associated and/or disparate Utilities, and where possible serving as a center of competence for the education and promotion of the role of ToIP Layer One utilities. -* [Ecosystem Foundry](https://trustoverip.org/working-groups/ecosystem-foundry/): The scope of the Ecosystem Foundry Working Group is to facilitate a community of practice among governance authorities, implementers, operators, and service providers of Trust over IP Layer Four ecosystems. The WG will provide process guidance for the establishment and monitoring of new ToIP Layer Four ecosystem projects, whether hosted at the Linux Foundation or external to it. Other WG activities will include creating template RFPs for service providers, maintaining a list of affiliated Foundry Service Providers, identifying areas of collaboration and alignment between associated and/or disparate ecosystems, and where possible serving as a center of competence for the education and promotion of the role of ToIP Layer Four ecosystems. - -## 9. Relevance to eSSIF-Lab - -The above-mentioned standards, open source and governance are relevant to eSSIF-Lab in multiple ways. - -* Using: Subgrantees of eSSIF-Lab will implement some of these standards, and fork existing open-source code. -* Testing: Subgrantees of eSSIF-Lab will perform interoperability tests of their implementations against other within eSSIF-Lab and outside, likely including the European [EBSI-ESSIF](https://www.eesc.europa.eu/sites/default/files/files/1._panel_-_daniel_du_seuil.pdf), the American [DHS-SVIP](https://www.dhs.gov/science-and-technology/svip). -* Contributing: Subgrantees of eSSIF-Lab will also be required to contribute to standards development where relevant. \ No newline at end of file diff --git a/doc-sources/terminology-plugin-instructions.md b/doc-sources/terminology-plugin-instructions.md deleted file mode 100644 index fd16868..0000000 --- a/doc-sources/terminology-plugin-instructions.md +++ /dev/null @@ -1,119 +0,0 @@ ---- -id: terminology-plugin-instructions -title: Terminology & Glossary plugin docs ---- -import useBaseUrl from '@docusaurus/useBaseUrl'; - - -### How it works - -This plugin parses docs in two ways: - - 1. Parses all `*.mdx` files under `docs/` and replaces each pattern with an - appropriate React component supporting a tooltip functionality (see below) - 2. Generates a glossary with all terms corresponding to the `*.md` files under `docs/terms/`. - -Parses all markdown files and generates a glossary page with all the pattern terms found in the .md files - -## Replace patterns with dynamical elements - -When writing docs, in order to refer to a term, you may use the following syntax: - -``` -%%term_text|term_name%% -``` - -where: -- `term_text`: The terminology text you want it to be visible in the documentation -page -- `term_name`: The filename of the term file, which resides under `./docs/terms` directory. - -inside `docs/*.mdx` files. After successfully running the script, the above occurrence -will be replaced by a React component, which will render `term_text` as a link to the -corresponding term page, which is in turn generated from the `term_name` attribute; -furthermore, *hovering* over `term_text` displays a term summary, as extracted from the -corresponding term page. - -### Example usage - -Say you want to reference a term that exists under the `./docs/terms/` directory, -e.g. `./docs/terms/party.md`. You can use the following syntax to reference -this term in your documentation page: - -``` -Some content that wants to reference the %%Party|party%% term -``` - -When the script runs, this will be replaced as follows: - -``` -Some content that wants to reference the Party term -``` - -which supports the functionality explained above. - -### How to correctly write a term - -This plugin assumes that you follow the structure, as explained below: - -Each term should have its own `.md` file, inside the `./docs/terms` directory, -and it needs to consist of the following structure: - -```title="./docs/terms/term.md" ---- -id: term -title: Term page -stage: draft -hoverText: This hover text will appear in the documentation page that you reference this term ---- - -### Term explanation - -content here -``` - -> Pay attention to the `hoverText` attribute, as it's important to provide this ->attribute (along with the default docusaurus attributes), so the plugin can ->fetch the correct popup text to show when referencing a term. - -### Running the script - -When you are finished referencing terms and have written corresponding term pages, -you can test this locally by running the following command: - -```.shell script -$ yarn parse -yarn run v1.22.5 - docusaurus parse -Replacing patterns with -Done in 1.41s. -``` - -This will replace all `%%term_text|term_name%%` occurrences with the React component -supporting the required functionality. - -Here's an example where the terms have been replaced. When the project is up -and running, you can visit the test example on the `/docs/replacement-test` page: - -replacement-test - - -## Generate the glossary page - -If everything works well with the above procedure, you can then generate a -glossary page, by running the following command: - -```.shell script -$ yarn glossary -yarn run v1.22.5 - docusaurus glossary -Alphabetical list of terms -Done in 1.53s. -``` - -This will generate a file in `./docs/glossary.md` where every term that has been -mentioned above, will be populated in the `glossary.md` page. - -When the project is up and running, you can visit the glossary on the `/docs/essifLab-glossary` page: - - glossary-page diff --git a/doc-sources/terminology.md b/doc-sources/terminology.md deleted file mode 100644 index bf6a4c6..0000000 --- a/doc-sources/terminology.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -id: terminology -title: "eSSIF-Lab: Concepts and Terminology" -scopeid: essifLab ---- - -:::info **UNDER CONSTRUCTION** -*This (initial version of the) terminology chapter is currently under construction. If you feel like making a contribution, please contact [the editor](mailto:rieks.joosten@tno.nl)* -::: - -The purpose of the eSSIF-Lab Terminology is to provide mental models that all of its stakeholders interpret in sufficiently the same way, so as to be able to talk, think and discuss about what it is we try to achieve and ways to achieve this. - -## Introduction - -Contributors to and users of eSSIF-Lab come from various backgrounds. Their culture may not be Western. English may not be their native tongue. They may be experts in non-technological topics. Working with one another presumes a setting where participants have some level of shared understanding. Often, sharing one's understanding at a superficial level suffices. Other situations require that underlying concepts are shared in a more in-depth fashion. It's like cars: people buying, selling, or driving cars do not need in-depth shared knowledge about cars, whereas (maintenance or construction) engineers or liability lawyers need to share a deeper knowledge of how cars do (or do not) work. - -We expect to see situations of "language confusion", i.e. in which people use words or phrases, the intension (not: intention) of which differs from the interpretation of some listeners/readers. Sometimes a casual glance at a dictionary or glossary is the solution. In other cases, deeper understanding matters, e.g. in when drafting specifications or contracts. Then [we need more than a set of definitions](https://www.sfu.ca/~swartz/definitions.htm). - -The Concepts and Terminology part of eSSIF-Lab aims helps eSSIF-Lab community participants understand one another at whatever level of precision they need. - -## Glossaries - -The traditional tool for fostering common understanding is using glossaries, i.e. alphabetical lists of words relating to a specific subject, text, or dialect, with explanations; a brief dictionary ([OED](https://www.lexico.com/definition/glossary)). Examples include the [Sovrin Glossary](https://sovrin.org/library/glossary/) and the [NIST Glossary](https://csrc.nist.gov/glossary). Other initiatives attempt to provide more background, e.g. the [terminology for talking about privacy by data minimization](https://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.34.pdf) by Pfitzmann and Hansen (2010), or the [EBSI Terminology (login required)](https://ec.europa.eu/cefdigital/wiki/display/EBP/EBSI+Terminology). - -The eSSIF-Lab project will also develop a [Glossary](/docs/essifLab-glossary). - -However, since the use of such glossaries is limited to short explanations, we will also provide (a) mental model(s) that provide a more in-depth explanation of the concepts that underly the words listed in the [eSSIF-Lab Glossary](/docs/essifLab-glossary). - -## Mental Models - -We have the following mental (conceptual) models: - - - - -A Mental Model, or Conceptual Model, is a set of of concepts (i.e. entity classes), relations between such concepts (i.e. sets of pairs of members of classes that a relation connects), and rules/constraints expressed in terms of these relations and concepts. - -The first purpose of a Mental Model 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. - -So a mental model requires careful construction, that allows the choices for its elements to be validated against many use-cases. Such validation instills trust that our model elements (concepts, relations, rules) are well-chosen. It also provides us with the experience (usually after some time) that it has made our thinking easier, and we are better equipped to resolve issues. - -The careful construction is comparable to a quest: it takes time, multiple versions, and careful reflection. And it needs continuous validation of its parts, by throwing use-cases at it and verifying that the model can describe such cases, and do some reasoning with them. - -This careful construction must ensure that the mental model gets different properties. For starters, the model 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 mental model 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. - -## Terminology and Definitions - -We attempt to create definitions that are both acceptable for business people yet are precise enough to serve as a basis for formal reasoning. We do this by using [intensional definitions](https://en.wikipedia.org/wiki/Extensional_and_intensional_definitions), i.e. by defining criteria that specify the necessary and sufficient conditions for when a term should be used. We have tried to craft these definitions such that - -- readers are likely to make the same judgements when using them, and -- these distinctions are relevant for our purposes. That’s the important stuff. - -The actual texts we choose as the name for a concept is of secondary importance; if in a particular context other names are more suitable, you can rename them there without loss of meaning or consistency. - -Together with these criteria, we provide a limited set of examples to help the reader to visualize the defined concepts, and to point out possibly unexpected consequences of the criteria. Also, we may motivate the need for having a concept by showing its relevance for the model. - -Here are some examples: - -:::note -**The following definitions will be moved to a separate eSSIF-Lab Terminology section** -::: - -### Definition -**Entity that comprises at a minimum**: - -- **a non-empty set of scopes in each of which specific objectives are being pursued;** -- **a criterion that specifies the necessary and sufficient conditions for being an instance of a named class;** -- **a set of arguments and/or use-cases (that SHOULD not be empty), and that show the relevance of making this distinction within the scope (and for its objectives);** -- **a name that is created and used within the scope that created the definition, for the purpose of referring to the class, or using it as a placeholder for its instances.** - -**For the purposes of this document, the scope of every Definition is this Document (with its objectives that have been specified above).** - -Note that this definition satisfies itself. Also note that a definition may be used in multiple scopes, where a scope that wants to use the definition that has been defined in another scope, may replace that name with one of its own choosing. This way the meaning expressed by the definition remains preserved. diff --git a/doc-sources/terminology/README.md b/doc-sources/terminology/README.md deleted file mode 100644 index 8a64147..0000000 --- a/doc-sources/terminology/README.md +++ /dev/null @@ -1,29 +0,0 @@ -# README for terminology-related files. - -:::info -The entire terminology section is still experimental/under construction -::: - -## Purpose - -The purpose of the eSSIF-Lab Terminology Corpus is to help people that want or need to -- understand the gist of texts about various topics (learners, CxO's); -- write texts on (a) specific topic(s) (authors); -- deeply understand texts (reviewers, domain experts); -- prevent and/or resolve misunderstandings with others working on the same/similar topics (engineers); -- make (e.g. design) decisions concerning specific topics based on solid, consistent and coherent arguments; -- create code and/or data models for automation purposes; -- etc. - -We have an [introduction](terminology) that explains how we go about all this. - -## Directory Contents - -- Directories: - - `eSSIFLab`, which contains all the documents for the scope `eSSIFLab`; its subdirectories contain the documents for the various subscopes, as appropriate. - - `templates` (directory) contains templates that authors may use to [contribute to, or specify new content](readme-making-contributions). - -- Files: - - [terminology](terminology) specifies the purposes that the terminology work intends to serve, and the ways in which this is done. - - [readme-making-contributions](readme-making-contributions) is a guide for people that want to create, generate or update new ***content***. - - [readme-generator-extensions](readme-generator-extensions) is a guide for people that want to create or modify the generators that produce the actual terminological artifacts from the content produced by authors. diff --git a/doc-sources/terminology/essifLab/action.md b/doc-sources/terminology/essifLab/action.md deleted file mode 100644 index de2bf14..0000000 --- a/doc-sources/terminology/essifLab/action.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -id: action -title: "Action" -scopeid: essifLab -type: concept -typeid: action -stage: draft -hoverText: "something that is actually done/executed by a single actor (as a single operation) for some party within a specific context" ---- - -## Short Description -An **Action** is something that is actually done/executed by a %%actor|actor%% in some context (i.e. in a specific place, at a specific time). During the time interval in which the action is executed, the actor may still execute other actions in other execution-contexts (multi-tasking). An action is executed for, or on behalf of, a specific %%party|party%%, which means that the primary guidance for executing the action, e.g. how to execute it, boundary conditions within which the execution must take place, etc., comes from the %%knowledge|knowledge%% of that party. The actor is assumed to have appropriate access to the knowledge of that party. In order to properly execute the action, the executing actor may also use additional knowledge(s) to which it has access. - -## Purpose -The ability to distinguish between (non)actions allows one to determine which (kinds of) %%actors|actor%% are capable of executing actions (e.g. by establishing that they have the competences required by the party), and as a consequence may be permitted and/or required to execute them. Also, this ability enables parties to determine the execution-policy, i.e. the set of rules and other guidance that actors should obey or comply with when exeucting an action on its behalf. - -## Criterion: -An **Action** is something that is done by an actor, can be considered a single operation, and is performed in a specific context, for or on behalf of a specific party, i.e. in accordance with the policy rules that this party has established for such actions. - -## Examples: -- filling in a form and submitting it. -- cleaning a car. - -## Related Concepts - -- OED defines Action as the fact or process of doing something, typically to achieve an aim ([OED](https://www.lexico.com/definition/action)), which is too generic for our purposes. - -## Background: -The %%party-action 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/doc-sources/terminology/essifLab/actor.md b/doc-sources/terminology/essifLab/actor.md deleted file mode 100644 index a3d1956..0000000 --- a/doc-sources/terminology/essifLab/actor.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -id: actor -title: "Actor" -scopeid: essifLab -type: concept -typeid: actor -stage: draft -hoverText: "Entity that can act (do things), e.g. people, machines, but not organizations." ---- - -## 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. - -## 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). - -## Criterion: -Entity that is capable of actually executing %%actions|action%% (acting, doing things). - -## Examples: - -- People (human beings) obviously qualify, as do robots and other machines. -- Stones, pictures, ideas, etc. do not qualify. -- Software applications qualify, provided they are actually running on hardware. An app that is just sitting e.g. on a mobile phone but isn't executed does not qualify. -- Enterprises, governments, and other %%organizations|organization%% do not qualify. - -## Background: -The %%party-action pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts. diff --git a/doc-sources/terminology/essifLab/agent.md b/doc-sources/terminology/essifLab/agent.md deleted file mode 100644 index 921c87a..0000000 --- a/doc-sources/terminology/essifLab/agent.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -id: agent -title: "Agent" -scopeid: essifLab -type: concept -typeid: agent -stage: draft -hoverText: "An actor that is (at that point in time) executing an action for, or on behalf of a Party." ---- - -## Short Description -%%Actors|actor%% execute %%actions|action%% for, or on behalf of some %%party|party%%, because parties are not considered to be capable of acting.[^1] Agents must act in accordance with the party for which they execute such actions, which means that for every kind of action, such parties must provide the proper guidance for their agents, e.g. in terms of policies (rules), working instructions, programs etc. We use the term %%digital agent|digital-agent%% - -## Purpose -The ability to distinguish between (non)agents is relevant in many situations, including: -- electronic communication: the agent - -## Criterion: -a property that is attributed to an %%Actor|actor%% whenever it is executing an action for, or on behalf of some %%party|party%%. - -## Examples: - -- A person that is 'doing its own things' acts as an Agent for himself. -- A person that does things for his employer acts as an Agent for that employer. -- An ambassador, when (s)he is 'in function', acts as an Agent for the country for which (s)he is ambassador. -- A person that fills in the tax return form for someone else acts as an Agent for this someone else. -- 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 %%party-action pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts. diff --git a/doc-sources/terminology/essifLab/digital-agent.md b/doc-sources/terminology/essifLab/digital-agent.md deleted file mode 100644 index db205cb..0000000 --- a/doc-sources/terminology/essifLab/digital-agent.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -id: digital-agent -title: "Digital Agent" -scopeid: essifLab -type: term -typeid: digital-agent -conceptref: ":Agent" -stage: draft -hoverText: "An Actor in the digital world (e.g. a running app, or a web-server) that executes actions for a specific party." ---- - -## Purpose - -The ability to distinguish between (non)digital actors allows us to exclusively talk about software/hardware actors and their agency. diff --git a/doc-sources/terminology/essifLab/eSSIFGlue.md b/doc-sources/terminology/essifLab/eSSIFGlue.md deleted file mode 100644 index fb8e94a..0000000 --- a/doc-sources/terminology/essifLab/eSSIFGlue.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: eSSIFGlue -title: "eSSIF-Glue" -scopeid: essifLab -type: concept -typeid: eSSIFGlue -stage: draft -hoverText: "eSSIFGlue" ---- - -## Short Description -The **eSSIF-Glue** is an interface layer that consists of a documented set of APIs between the %%TVE|tve%% and %%TRD|trd%% on the one hand, and the Wallet, Holder, Issuer and Verifier (WHIV) components on the other hand. - - Ultimately, we would like to see these APIs standardized. Having such APIs allows different Parties to create their own version of the WHIV components, supporting the SSI technologies as they see fit, and shrinking or expanding functionalities as they feel appropriate. Parties can then select such WHIV components as they see fit. - -## Purpose -The purpose of the essif-Glue APIs is to make calling the WHIV functions as simple as possible, given the functions of the %%TVE|tve%% and %%TRD|trd%% - -## Criterion: -The set of API's described at https://gitlab.grnet.gr/essif-lab/tno-ssi-service/developer-docs. diff --git a/doc-sources/terminology/essifLab/entity.md b/doc-sources/terminology/essifLab/entity.md deleted file mode 100644 index 2fcaacf..0000000 --- a/doc-sources/terminology/essifLab/entity.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -id: entity -title: "Entity" -scopeid: essifLab -type: concept -typeid: entity -stage: draft -hoverText: "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. - -## 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. - -## Criterion: -Something, anything, that some %%party|party%% knows to exist - -## Related Concepts: -- a %%legal entity|legal-entity%% is an entity that is known by (i.e. registered in the %%knowledge|knowledge%% of) a %%party|party%% that operates the %%legal-system|legal-system%% of a %%jurisdiction|jurisdiction%%. (Details are in the %%jurisdiction pattern|pattern-jurisdiction%%) - -## Background: -The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts. diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/concept-dictionary.mdx b/doc-sources/terminology/essifLab/essifLabTerminology/concept-dictionary.mdx deleted file mode 100644 index 6e4adb6..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/concept-dictionary.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -id: dictionary -title: "Concept: Dictionary (Scope: essifLabTerminology)" -scopeid: essifLabTerminology -type: concept -typeid: dictionary -hoverText: "an alphabetically sorted list of termsort) explanations, usually aimed to help people understand texts around a certain (set of) topic(s) in some context(s)." ---- - -## Short Description - -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%%. - -## Purpose - -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. - -## Criteria - -an alphabetical list of words or phrases with possibly multiple, short explanations, that exists for the purpose of helping people to find out what a word may mean in various %%scopes/contexts|scope%%. - -## Examples - -Examples include the [NIST Computer Security Resource Center](https://csrc.nist.gov/glossary), [Merriam-Webster](https://www.merriam-webster.com/dictionary/). - -## Related Concepts - -- Glossary - this is a list of words with a single meaning, that serves more specific purposes than a dictionary. -- Vocabulary - this is a body of words used in a particular language or field of expertise. A Dictionary can provide the various meanings of each such words. - -## Notes - - - - \ No newline at end of file diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/concept-file.md b/doc-sources/terminology/essifLab/essifLabTerminology/concept-file.md deleted file mode 100644 index 13131f0..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/concept-file.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -id: concept-file -title: "Concept-file" -scopeid: essifLab -type: concept -typeid: concept-file -stage: draft -hoverText: "a file that defines/specifies a concept" ---- - -## Short Description -A **concept-file** is a file that contains documentation about a specific %%concept|concept%%. To faciliate authors, a self-explanatory [template file](/terminology-engine-v1-templates/concept-file.md) is available. - -## Purpose -The ability for people to determine whether or not they are talking about the same 'thing' (idea, concept), is prerequisite for knowing that they (correctly) understand one another - which doesn't imply they agree with each other. Concept files provide the documentation of such %%things|concept%% that contribute to this ability. - -## Criterion: -a file that defines/specifies a concept. - -## Examples: -the file that contains this text is an example of a concept-file. diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/concept.md b/doc-sources/terminology/essifLab/essifLabTerminology/concept.md deleted file mode 100644 index 0cd0bdb..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/concept.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -id: concept -title: "Concept" -scopeid: essifLabTerminology -type: concept -typeid: concept -stage: draft -hoverText: "A Concept tries to capture the idea behind a classification of entities, allowing us to reason about everything in the class as if it were one thing." ---- - -## Short Description - -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. - -## Purpose - -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. - -## Criteria - -A (description/specification of a) Concept MUST be [intensionally defined](https://en.wikipedia.org/wiki/Extensional_and_intensional_definitions), i.e. associated with a criterion that can be used to determine whether or not someone or something qualifies as (an instance of) that Concept, and that has the property that it has been shown that the vast majority of contributors and other users apply it in the same manner in different situations (i.e. they arrive at the same conclusion as to whether or not someone or something qualifies under that criterion in any given situation). - -## Examples - - -## Related Concepts - -* %%Term|term%% is a label that is used in some context to refer to a %%Concept|concept%%[^2], the set of entities that satisfy the concept's criteria, or an arbitrary element of that set. Different contexts may use different terms to refer to a single concept. In a single context, a single term should be used to refer to an individual concept. - -* %%Scope|scope%% is related in several ways. First, there is (precisely, or at most one) Scope that governs the definition/specification of the Concept. Second, there may be (any number of) Scopes that use the Concept, i.e. within which Terms are defined that refer to the Concept - -* %%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 - -* essifLab -* ToIP -* Sovrin -* DIF -* NIST -* ... - -## Tags - -* Terminology - -## Use-cases - - -## Notes - -There is an important [distinction between concepts and the (multitude of) terms](https://simple.wikipedia.org/wiki/Concept) (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 -* in different contexts, a single term may refer to different concepts -* to resolve terminological disputes, which usually are about the 'correct' meaning of a term, try to establish the criteria that the different participants use for the concept behind the term. That helps participants understand each others (different) positions, and provides a better basis for resolving the conflict. - ---- -## Footnotes - - -[^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). - -[^2]: For the difference between 'Concept' and 'Term', see https://simple.wikipedia.org/wiki/Concept. diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/definition.md b/doc-sources/terminology/essifLab/essifLabTerminology/definition.md deleted file mode 100644 index af321cd..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/definition.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -id: definition -title: "Definition" -scopeid: essifLabTerminology -type: concept -typeid: definition -stage: draft -hoverText: "A Definition is a text that helps parties truely understand the meaning of a term" ---- - -## Short Description - -A **Definition** is a text that helps parties 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 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. - -## Purpose - -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. - -## Criteria - -Entity that comprises at a minimum: -- a non-empty set of %%scopes|scope%% in each of which specific objectives are being pursued; -- a criterion that specifies the necessary and sufficient conditions for being an instance of a named class; -- a set of arguments and/or use-cases (that SHOULD not be empty), and that show the relevance of making this distinction within the scope (and for its objectives); -- a %%name|term%% that is created and used within the scope that created the definition, for the purpose of referring to (instances of) the class, or using it as a placeholder for its instances. - -## Examples - -- The definition of the term %%definition|definition%% (a) is defined in, and hence valid in the scope `eSSIFLab`, (b) specifies a criterion (see the `Criteria` section above), and (c) is relevant (see the `Purpose` section above), and (d) has a name (i.e. `definition`) associated with it. Since it satisfies the criteria of `definition`, it can be referred to as 'the definition of `definition`'. -- The %%concepts|concept%% defined within the scope eSSIFLab have definitions associated with them, where the criteria, relevance and terms are defined in the %%concept-file|concept-file%% of that concept. - -## Related Concepts - -* %%Term|term%% is a label that is used in some context to refer to a %%Concept|concept%%, the set of entities that satisfy the concept's criteria, or an arbitrary element of that set. Different contexts may use different terms to refer to a single concept. In a single context, a single term should be used to refer to an individual concept. - -* %%Scope|scope%% is related in several ways. First, there is (precisely, or at most one) Scope that governs the definition/specification of the Concept. Second, there may be (any number of) Scopes that use the Concept, i.e. within which Terms are defined that refer to the Concept - -* %%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 - - -## Notes - - -For the purposes of this document, the scope of every Definition is this Document (with its objectives that have been specified above).** - -Note that this definition satisfies itself. Also note that a definition may be used in multiple scopes, where a scope that wants to use the definition that has been defined in another scope, may replace that name with one of its own choosing. This way the meaning expressed by the definition remains preserved. diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/dictionary-file.md b/doc-sources/terminology/essifLab/essifLabTerminology/dictionary-file.md deleted file mode 100644 index 7c65872..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/dictionary-file.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -id: dictionary-file -title: "Dictionary-file" -scopeid: essifLab -type: dictionary -typeid: dictionary-file -stage: draft -hoverText: "a file that specifies the contents of a dictionary" ---- - -## Short Description -A **dictionary-file** is a file that contains the specification of what does (not) go into a specific %%dictionary|dictionary%%. To faciliate authors, a self-explanatory [template file](/terminology-engine-v1-templates/dictionary-file.md) is available. - -## Purpose -%%Dictionaries|dictionary%% help people to figure out the meaning of terms, specifically if the context of the text they are interpreting isn't very clear, or the meaning of the used terms is left to the imagination of the reader. - -## Criterion: -a file that defines/specifies a %%dictionary|dictionary%. diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/dictionary.md b/doc-sources/terminology/essifLab/essifLabTerminology/dictionary.md deleted file mode 100644 index ba11a3a..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/dictionary.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -id: dictionary -title: "Dictionary" -scopeid: essifLabTerminology -type: concept -typeid: dictionary -stage: draft -hoverText: "an alphabetically sorted list of terms and explanations, usually aimed to help people understand texts around a certain (set of) topic(s) in some context(s)." ---- - -## Short Description - -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%%. - -## Purpose - -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. - -## Criteria - -an alphabetical list of words or phrases with possibly multiple, short explanations, that exists for the purpose of helping people to find out what a word may mean in various %%scopes/contexts|scope%%. - -## Examples - -Examples include the [NIST Computer Security Resource Center](https://csrc.nist.gov/glossary), [Merriam-Webster](https://www.merriam-webster.com/dictionary/). - -## Related Concepts - -- %%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 - - - - diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/entity.md b/doc-sources/terminology/essifLab/essifLabTerminology/entity.md deleted file mode 100644 index 2fcaacf..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/entity.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -id: entity -title: "Entity" -scopeid: essifLab -type: concept -typeid: entity -stage: draft -hoverText: "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. - -## 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. - -## Criterion: -Something, anything, that some %%party|party%% knows to exist - -## Related Concepts: -- a %%legal entity|legal-entity%% is an entity that is known by (i.e. registered in the %%knowledge|knowledge%% of) a %%party|party%% that operates the %%legal-system|legal-system%% of a %%jurisdiction|jurisdiction%%. (Details are in the %%jurisdiction pattern|pattern-jurisdiction%%) - -## Background: -The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts. diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/glossary-file.md b/doc-sources/terminology/essifLab/essifLabTerminology/glossary-file.md deleted file mode 100644 index 1b6cb3e..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/glossary-file.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -id: glossary-file -title: "Glossary-file" -scopeid: essifLab -type: glossary -typeid: glossary-file -stage: draft -hoverText: "a file that defines/specifies a glossary" ---- - -## Short Description -A **glossary-file** is a file that contains the specification of what does (not) go into a specific %%glossary|glossary%%. To faciliate authors, a self-explanatory [template file](/terminology-engine-v1-templates/glossary-file.md) is available. - -## Purpose -%%Glossaries|glossary%% are %%dictionaries|dictionary%% that are limited to a specific purpose or %%scope|scope%%. They provide a single meaning for each term, enabling both authors and readers to quickly establish if they associate a term with the meaning as it is defined for that scope. - -## Criterion: -a file that defines/specifies a %%glossary|glossary%. diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/glossary-terminology.md b/doc-sources/terminology/essifLab/essifLabTerminology/glossary-terminology.md deleted file mode 100644 index be91d2c..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/glossary-terminology.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: essifLabTerminology-glossary -title: Glossary of eSSIF-Lab Terminology -scopeid: essifLabTerminology -type: glossary -typeid: essifLabTerminology -stage: draft -hoverText: "essifLabTerminology-glossary - popuptext tbd" ---- - -## Purpose - -This glossary lists the basic concepts that are needed by the various stakeholders within the eSSIF-Lab project, ranging from governance, business, process, technology etc. The idea is that it defines at least the set of concepts that are often used in these varied domains, allowing a reader with a specific background to learn how the concept is used from other (valid) perspectives that may be alien to him/her. - -## Sources - - -### Include - -* eSSIF-Lab - -### Terms - - -### Patterns - - -### Concepts - - - diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/glossary.md b/doc-sources/terminology/essifLab/essifLabTerminology/glossary.md deleted file mode 100644 index dad9f8a..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/glossary.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -id: glossary -title: "Glossary" -scopeid: essifLabTerminology -type: concept -typeid: glossary -stage: draft -hoverText: "an alphabetically sorted list of terms explanations, usually aimed to help people understand texts around a certain (set of) topic(s) in some context(s)." ---- - -## Short Description - -A glossary is an alphabetically sorted list of terms and explanations, usually aimed to help people understand texts around a certain (set of) topic(s) in some context(s). However, 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. - -## Purpose - -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 - -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 - -Examples include the [eSSIF-Lab Glossary](/docs/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 - -- %%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 - -The [eSSIF-Lab Glossary](/docs/essifLab-glossary) contains the words that are defined within the scope of the [eSSIF-Lab framework](/docs/introduction). - - \ No newline at end of file diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/pattern-file.md b/doc-sources/terminology/essifLab/essifLabTerminology/pattern-file.md deleted file mode 100644 index bcd154a..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/pattern-file.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -id: pattern-file -title: "Pattern-file" -scopeid: essifLab -type: pattern -typeid: pattern-file -stage: draft -hoverText: "a file that defines/specifies a pattern" ---- - -## Short Description -A **pattern-file** is a file that describes a %%pattern|pattern%%. To faciliate authors, a self-explanatory [template file](/terminology-engine-v1-templates/pattern-file.md) is available. - -## Purpose -Describing %%patterns|pattern%% enable users/readers to get a good idea of how related %%concepts|concept%% work together as a coherent and consistent whole. Mature patterns are generally simple, and make it much easier to think about the described concepts for someone that applies the pattern than it is for people that do not. - -## Criterion: -a file that defines/specifies a %%pattern|pattern%. diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/pattern-mental-model.md b/doc-sources/terminology/essifLab/essifLabTerminology/pattern-mental-model.md deleted file mode 100644 index 7fe7ae7..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/pattern-mental-model.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -id: pattern-mental-model -title: "Pattern: Mental Models" -scopeid: essifLabTerminology -type: pattern -typeid: mental-model -stage: draft -hoverText: "This pattern captures the foundational concepts and relations that we need for creating, maintaining and using (decentralized) vocabularies (terminologies) that groups of people can use for the specific purposes they pursue." ---- - -## Purpose - -This pattern captures the foundational concepts and relations that we need for creating, maintaining and using vocabularies (terminologies) that groups of people can use for the specific purposes they pursue. Alternatively, we need these concepts to allow people to use 'decentralized vocabularies' that %%parties|party%% may create, maintain and use in a self-sovereign fashion - which means that each of them decides for itself what terms to use in what meaning, yet be able to communicate with other such %%parties|party%% in such a way that a correct understanding of what the other means, can more or less be guaranteed. - -## Introduction - -TL;DR: . - -A concept is an idea that is applied to all objects in a group. It is the way people see and understand something. The name used to identify a concept (the concept's label) is a "term". For example, the word "Dog" is the term to identify the concept of what a dog is. Everything that a person knows about a dog is the concept of the term dog. - -Different terms can be used to identify the same concept. Car and Automobile are synonyms for the same concept. Different languages have different terms for the same concept. This is what makes translation possible. The terms may be different in each language, but the concept is the same. The concept of jumping is the same to a person from England and a person from Italy, but one person uses the term "Jump" to mean the concept and the other person uses "Salto". - -## Notations - - -## - - - \ No newline at end of file diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/pattern-terminology.md b/doc-sources/terminology/essifLab/essifLabTerminology/pattern-terminology.md deleted file mode 100644 index 600d2d6..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/pattern-terminology.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -id: pattern-terminology -title: "Pattern: eSSIF-Lab Terminology Corpus" -scopeid: essifLab -type: pattern -typeid: terminology -stage: draft -hoverText: "pattern-terminology - hovertext" ---- - -import useBaseUrl from '@docusaurus/useBaseUrl'; - -## Purpose - - -## Introduction - - -## Notations - - -## - - - \ No newline at end of file diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/pattern.md b/doc-sources/terminology/essifLab/essifLabTerminology/pattern.md deleted file mode 100644 index a49fa62..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/pattern.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -id: pattern -title: "Pattern" -scopeid: essifLab -type: concept -typeid: pattern -stage: draft -hoverText: "A limited set of concepts (ideas), relations between them, and constraints, such that together they form a coherent and consistent whole." ---- - -## Short Description - -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. - -## Purpose - -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. -- to efficiently discuss and improve %%definitions|definition%% of the %%concepts|concept%% and relations in the pattern. -- to write texts using precisely defined language. - -## Criteria - -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%%. - -## Examples - - -## Related Concepts - - -## Background: -The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts. - - \ No newline at end of file diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/scope-file.md b/doc-sources/terminology/essifLab/essifLabTerminology/scope-file.md deleted file mode 100644 index 2e360dc..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/scope-file.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: scope-file -title: "Scope-file" -scopeid: essifLab -type: concept -typeid: scope-file -stage: draft -hoverText: "a file that defines/specifies a scope" ---- - -## Short Description -A **scope-file** is a file that contains the specification of a specific %%scope|scope%%. To faciliate authors, a self-explanatory [template file](/terminology-engine-v1-templates/scope-file.md) is available. - -## Purpose -%%Scopes|scope%% enable people to focus, which is important as people's short-term memory is limited to 7 +/- 2 concepts (with attributes) [(Miller, 1956)](http://psychclassics.yorku.ca/Miller/). Hence, defining a scope - what is in it and what is not - is relevant as well. - -## Criterion: -a file that defines/specifies a %%scope|scope%. - -## References - -[1]: Miller, G. A. (1956). "[The magical number seven, plus or minus two: Some limits on our capacity for processing information](http://psychclassics.yorku.ca/Miller/)". Psychological Review. 63 (2): 81–97. CiteSeerX 10.1.1.308.8071. doi:10.1037/h0043158. PMID 13310704. \ No newline at end of file diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/scope-terminology.md b/doc-sources/terminology/essifLab/essifLabTerminology/scope-terminology.md deleted file mode 100644 index d81d3a7..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/scope-terminology.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -id: essifLabTerminology-scope -title: "Scope: eSSIF-Lab Terminology" -scopeid: essifLabTerminology -type: scope -typeid: essifLabTerminology -stage: draft -hoverText: "scope essifLabTerminology - popuptext tbd" ---- - -## Governance - -The [eSSIF-Lab project](https://essif-lab.eu/) governs the terminology within this scope, according to the procedures mentioned in the [eSSIF-Lab Framework](https://essif-lab.pages.grnet.gr/framework/docs/terminology/). - -## Objectives/Issues - -Contributors to and users of eSSIF-Lab come from various backgrounds. Their culture may not be Western. English may not be their native tongue. They may be experts in non-technological topics. Working with one another presumes a setting where participants have some level of shared understanding. Often, sharing one's understanding at a superficial level suffices. Other situations require that underlying concepts are shared in a more in-depth fashion. It's like cars: people buying, selling, or driving cars do not need in-depth shared knowledge about cars, whereas (maintenance or construction) engineers or liability lawyers need to share a deeper knowledge of how cars do (or do not) work. - -We expect to see situations of "language confusion", i.e. in which people use words or phrases, the intension (not: intention) of which differs from the interpretation of some listeners/readers. Sometimes a casual glance at a dictionary or glossary is the solution. In other cases, deeper understanding matters, e.g. in when drafting specifications or contracts. Then we need more than a set of definitions. - -The Concepts and Terminology part of eSSIF-Lab aims helps eSSIF-Lab community participants understand one another at whatever level of precision they need. - -## Scope URI - - -## Inclusions - - -## Notes - - -## Tags - - - diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/scope.md b/doc-sources/terminology/essifLab/essifLabTerminology/scope.md deleted file mode 100644 index 41c39ef..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/scope.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: scope -title: "Scope" -scopeid: eSSIFLab -type: concept -typeid: scope -stage: draft -hoverText: "the extent of the area or subject matter (which we use to define patterns, concepts, terms and glossaries in)." ---- - -## Short Description - -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. - -## Purpose - -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 - -a (virtual) demarcation that serves particular purposes. - -## Examples - - -## Related Concepts - - -## Background: - -The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts. - -## Use-cases - - -## Notes - -- 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. - - \ No newline at end of file diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/semantics.md b/doc-sources/terminology/essifLab/essifLabTerminology/semantics.md deleted file mode 100644 index 76106f2..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/semantics.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -id: semantics -title: "Concept" -scopeid: essifLabTerminology -type: concept -typeid: semantics -stage: draft -hoverText: "a mapping between the (tangible/textual) terms and (intangible) ideas/concepts - their meaning." ---- - -## Short Description - -We use the term **semantics** to refer to the mapping between (tangible) %%terms|term%% and (intangible) %%concepts|concept%% (their meaning, the ideas behind it). Semantics are scoped, i.e. every %%scope|scope%% has its own semantic mapping. This implies that every %%party|party%% has - and maintains - its own (subjective) semantics, which is its subjective mapping of a set of terms onto the concepts/ideas in its %%knowledge|knowledge%%. The (erroneous) assumption that parties would (automagically) share a semantics is the cause of many misunderstandings, and hence should be identified and deleted as soon as possible. - -## Purpose - -The ability to distinguish between (non)semantics helps us to better understand one another, because it makes one aware of the fact that semantics is subjective, and its owner can update it. This allows such an owner to (temporarily) use terms in the same meaning as another party, specifically if they agree to use %%good definitions|definition%%. - -## Criteria - -A semantics is a mapping, in a specific %%scope|scope%%, between (tangible) %%terms|term%% and (intangible) %%concepts|concept%% (their meaning, the ideas behind it). diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/term-file.md b/doc-sources/terminology/essifLab/essifLabTerminology/term-file.md deleted file mode 100644 index 383db85..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/term-file.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -id: term-file -title: "Term-file" -scopeid: essifLab -type: concept -typeid: term-file -stage: draft -hoverText: "a file that defines/specifies a term" ---- - -## Short Description -A **term-file** is a file that defined/specifies a specific %%term|term%%. To faciliate authors, a self-explanatory [template file](/terminology-engine-v1-templates/term-file.md) is available. - -## Purpose -The ability to 'invent' a name for some %%concept|concept%%, or to use a different name if it is already known in some %%scope|scope%%, is commonly exercized by that work together (or that write software). Basically, this ability enables one to establish a %%semantics|semantics%%, i.e. a mapping between an idea or concept, and a word or phrase (the term) that can be used in communications, or when reasoning about that idea/concept. - -## Criterion: -a file that defines/specifies a term. diff --git a/doc-sources/terminology/essifLab/essifLabTerminology/term.md b/doc-sources/terminology/essifLab/essifLabTerminology/term.md deleted file mode 100644 index 46cad13..0000000 --- a/doc-sources/terminology/essifLab/essifLabTerminology/term.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -id: term -title: "Term" -scopeid: essifLabTerminology -type: concept -typeid: term -stage: draft -hoverText: "a word or phrase that is used in at least one scope/context to refer to a specific concept." ---- - -## Short Description - -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)). - -## Purpose - -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 - -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 - - -## Related Concepts - - -## Background: -The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts. - -## Domains - -* eSSIF-Lab -* ToIP -* Sovrin -* DIF -* NIST -* ... - -## Tags - -* Terminology - -## Use-cases - - -## Notes - -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 -* in different contexts, a single term may refer to different concepts -* to resolve terminological disputes, which usually are about the 'correct' meaning of a term, try to establish the criteria that the different participants use for the concept behind the term. That helps participants understand each others (different) positions, and provides a better basis for resolving the conflict. - ---- -## Footnotes - - -[^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). - -[^2]: For the difference between 'Concept' and 'Term', see https://simple.wikipedia.org/wiki/Concept. diff --git a/doc-sources/terminology/essifLab/glossary-essifLab.md b/doc-sources/terminology/essifLab/glossary-essifLab.md deleted file mode 100644 index f8f4641..0000000 --- a/doc-sources/terminology/essifLab/glossary-essifLab.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -id: essifLab-glossary -title: Glossary of eSSIF-Lab -scopeid: essifLab -type: glossary -typeid: essifLab -stage: draft -hoverText: "essifLab-glossary - popuptext tbd" ---- - - -## Purpose - -This glossary lists the basic concepts that are needed by the various stakeholders within the eSSIF-Lab project, ranging from governance, business, process, technology etc. The idea is that it defines at least the set of concepts that are often used in these varied domains, allowing a reader with a specific background to learn how the concept is used from other (valid) perspectives that may be alien to him/her. - -## Sources - - -### Include - -* eSSIF-Lab - -### Terms - - -### Patterns - - -### Concepts - - - diff --git a/doc-sources/terminology/essifLab/jurisdiction.md b/doc-sources/terminology/essifLab/jurisdiction.md deleted file mode 100644 index 8c7c3e9..0000000 --- a/doc-sources/terminology/essifLab/jurisdiction.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -id: jurisdiction -title: "Jurisdiction" -scopeid: essifLab -type: concept -typeid: jurisdiction -stage: draft -hoverText: "a legal system (legislation, enforcement thereof, and conflict resolution) that is operated by a party in a certain scope" ---- - -## Short Description - -A **Jurisdiction** is the composition of one %%scope|scope%%, one %%legal system|legal-system%% and one %%party|party%% 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 operate 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. - -## Purpose - -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 - - -## Related Concepts - - -## Background: - -The %%jurisdiction pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts. - -## Notes - - - diff --git a/doc-sources/terminology/essifLab/knowledge.md b/doc-sources/terminology/essifLab/knowledge.md deleted file mode 100644 index 9a70654..0000000 --- a/doc-sources/terminology/essifLab/knowledge.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: knowledge -title: "Knowledge" -scopeid: essifLab -type: concept -typeid: knowledge -stage: draft -hoverText: "The (intangible) sum of what is known by a party, as well as the familiarity, awareness or understanding of someone or something by that party" ---- - -## Short Description -**Knowledge** is the (intangible) sum of what is known, the familiarity, awareness or understanding of someone or something ([WikiPedia](https://en.wikipedia.org/wiki/Knowledge)). It includes facts ([propositional knowledge](https://en.wikipedia.org/wiki/Propositional_knowledge)), skills ([procedural knowledge](https://en.wikipedia.org/wiki/Procedural_knowledge)), or objects ([acquaintance knowledge](https://en.wikipedia.org/wiki/Knowledge_by_acquaintance)). Knowledge can be acquired in many different ways and from many different sources, including but not limited to experience, reason, memory, testimony, scientific inquiry, education, and practice. - -## Purpose -We need a term to refer to the (intangible) sum of what is known, the familiarity, awareness or understanding of someone or something of a %%party|party%%, because this is what allows the party to reason, and make decisions. When a party can successfully share (parts of) its knowledge, i.e. communicate it such that when another party interpret it, the intension is preserved, mutual understanding is achieved, which is prerequisite for doing business transactions and/or collaborating. - -## Criterion: -The intangible sum of what is known to some %%party|party%%, as well as the familiarity, awareness or understanding of someone or something by that party. - -## Notes: -- 'A knowledge' is 1-1 associated with a %%party|party%% (in a way, each knowledge defines that party). -- a knowledge includes the rules that its party has decided constitutes valid [Logics](https://en.wikipedia.org/wiki/Logic) (i.e. rules for reasoning). Such logics are usually not [formal](https://en.wikipedia.org/wiki/Formal_system), or [mathematical logics](https://en.wikipedia.org/wiki/Mathematical_logic). -- In order for reasoning with, or transferring Knowledge, it must be made explicit, e.g. in writing, speech, digitally or otherwise. The mapping of knowledge onto such representations is called ‘[semantics](https://en.wikipedia.org/wiki/Semantics)’. Every %%party|party%% determines which semantics it chooses to use. diff --git a/doc-sources/terminology/essifLab/legal-entity.md b/doc-sources/terminology/essifLab/legal-entity.md deleted file mode 100644 index 31b75d4..0000000 --- a/doc-sources/terminology/essifLab/legal-entity.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -id: legal-entity -title: "Legal Entity" -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." ---- - -## Short Description - -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. - -## Purpose - -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. - -## Criteria -A **Legal Entity** is an %%entity|entity%% that is known by and recognized to exist in a %%jurisdiction|jurisdiction%% (i.e. registered in the %%knowledge|knowledge%% of the %%party|party%% that operates the %%legal system|legal-system%% of said jurisdiction). - -## Examples - -- 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: - -The %%jurisdiction pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts. diff --git a/doc-sources/terminology/essifLab/legal-jurisdiction.md b/doc-sources/terminology/essifLab/legal-jurisdiction.md deleted file mode 100644 index e23a8ea..0000000 --- a/doc-sources/terminology/essifLab/legal-jurisdiction.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -id: legal-jurisdiction -title: "Legal Jurisdiction" -scopeid: essifLab -type: term -typeid: legal-jurisdiction -conceptref: essifLab:jurisdiction -stage: draft -hoverText: "Legal Jurisdiction: a jurisdiction that is operated by a governmental body." ---- - -## Purpose - -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. - -## Background: - -The %%jurisdiction pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts. diff --git a/doc-sources/terminology/essifLab/legal-system.md b/doc-sources/terminology/essifLab/legal-system.md deleted file mode 100644 index 80662ec..0000000 --- a/doc-sources/terminology/essifLab/legal-system.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -id: legal-system -title: "Legal System" -scopeid: essifLab -type: concept -typeid: legal-system -stage: draft -hoverText: "Legal-system: a system in which rules are defined, and mechanisms for their enforcement and conflict resolution are (implicitly or explicitly) specified." ---- - -## Short Description - -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. 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. - -## Purpose - -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 - -- 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: - -The %%jurisdiction pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts. \ No newline at end of file diff --git a/doc-sources/terminology/essifLab/objective.md b/doc-sources/terminology/essifLab/objective.md deleted file mode 100644 index 354964e..0000000 --- a/doc-sources/terminology/essifLab/objective.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -id: objective -title: "Objective" -scopeid: essifLab -type: concept -typeid: objective -stage: draft -hoverText: "Something toward which effort is directed: an aim, goal, or end of action (Merriam-Webster)" ---- - -## Short Description -**Objectives** drive %%parties|party%% as they make their goals explicit, the primary one of which is also referred to as the **mission** of that party. A party's objectives are part of its %%knowledge|knowledge%%. When made available to %%agents|agent%% of that party, these agents can do the work that is needed to reach these goals (realize the party's objectives). - -## Purpose -The ability to distinguish between (non)objectives is relevant as objectives are the drivers behind the reasoning and decisions that %%parties|party%% make, the policies and working instructions that they specify so that its %%agents|agent%% know what to do, when to do it, and how to do it. Moreover, objectives are 1-1 associated with risks (i.e. the level of uncertainty that the party experiences regarding whether a specific objective is going to be appropriately realized). Finally, objectives must be known in order to obtain (personal) data according to the [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj). - -## Criterion: -A text representing something toward which a %%party|party%% directs its efforts: an aim, goal, or end of action. - -## Examples: -- generically: anything that, according to a %%Party|party%% c.q. its way of thinking, is important to be realized, qualifies as an Objective (and identifies its owner as that %%Party|party%%). -- most people have the objective 'stay alive'. -- the equivalent in organizations is 'continuation of its existence' (many operate 'business-continuity processes' to realize this, and to identify and mitigate any associated risks). - diff --git a/doc-sources/terminology/essifLab/organization.md b/doc-sources/terminology/essifLab/organization.md deleted file mode 100644 index c296fc8..0000000 --- a/doc-sources/terminology/essifLab/organization.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -id: organization -title: "Organization" -scopeid: essifLab -type: concept -typeid: organization -stage: draft -hoverText: "a group of people that work to realize one or more objectives" ---- - -## Short Description - -An **Organization** is a group of people that work to realize one or more objectives. Enterprises and governments are the prototypical examples. However, parts of enterprises (e.g. divisions, departments, business units) should also be considered organizations. This also holds for governments and governmental bodies. - -## Purpose - -The purpose of documenting this term is to provide additional clarity w.r.t. definitions given in english dictionaries. Also, we need this notion as it is used in the eSSIF-Lab %%party-action pattern|pattern-party-actor-action%%. - -## Criteria -A (non-empty) group of people that work to realize a (non-empty) set of objectives. - -## Examples - -- Enterprises and governments are the prototypical examples. -- Parts of enterprises (e.g. divisions, departments, business units) and governmental bodies also qualify. -- Individual persons satisfy the criteria and hence qualify (see the Notes below). - -## Notes - -- One may question whether or not a single person can be a 'group of people' (who would obviously work to realize its personal objectives) and hence qualify as an organization. The answer to this question is however irrelevant within our context, because we reason with the concept %%party|party%% rather than the concepts organization and/or person. diff --git a/doc-sources/terminology/essifLab/owner.md b/doc-sources/terminology/essifLab/owner.md deleted file mode 100644 index 7afc5fe..0000000 --- a/doc-sources/terminology/essifLab/owner.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: owner -title: "Owner" -scopeid: essifLab -type: concept -typeid: owner -stage: draft -hoverText: "a Party that has the legal or rightful title to control something." ---- - -## Short Description - -The property of a %%Party|party%% that has the legal or rightful title to control something. We interpret 'legal' and 'rightful' as terms that apply to _any_ %%Jurisdiction|jurisdiction%% (that is: not just %%legal/national jurisdictions|legal-jurisdiction%%, but also those of other %%organizations|organization%% (%%parties|party%%). - -## Purpose - - -## Criteria - -A %%Party|party%% is said to be the **owner** of some %%entity|entity%% if and only if the party and the entity are %%legal entities|legal-entity%% in some %%jurisdiction|jurisdiction%%, and within the scope of that jurisdiction the party has the legal or rightful title to control the entity. - -## Examples - - -## Related Concepts - - -## Domains - - -## Tags - - -## Use-cases - - -## Notes - - - diff --git a/doc-sources/terminology/essifLab/party.md b/doc-sources/terminology/essifLab/party.md deleted file mode 100644 index 996f3fb..0000000 --- a/doc-sources/terminology/essifLab/party.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -id: party -title: "Party" -scopeid: essifLab -type: concept -typeid: party -stage: draft -hoverText: "Entity that has knowledge about what exists, ways to reason with that knowledge, and ways for making decisions in a Self-Sovereign fashion." ---- - -## Short Description - -## Purpose - -## Criterion: -Entity that has knowledge about what exists, ways to reason[^1] with that knowledge, and ways for making decisions in a Self-Sovereign[^2] fashion. - -## Examples: -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: - -The concept we know as 'party' serves a central role, and therefore occurs in various patterns, suc as: -- The %%party-actor-action|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts. -- the %%jurisdiction pattern|pattern-jurisdiction%%, which shows that a party can operate the %%legal-system|legal-system%% of a %%jurisdiction|jurisdiction%%, enforcing the rules in some scopes to the %%(legal) entities|legal-entity%% that it knows to exist and to which these rules apply. - ---- -[^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. - -[^2]: This means that the party can do this all by itself. For humans, the rights for this are laid down e.g. in the [ECHR](https://www.echr.coe.int "European Convention of Human Rights") ([ECHR articles 9-11](https://www.echr.coe.int/Documents/Convention_ENG.pdf)) - -[^3]: While the case can be made that (some) electronic components can reason, they do not do so in a self-sovereign fashion as intended by this definition. We do not want to discuss AI-equipment here. diff --git a/doc-sources/terminology/essifLab/pattern-jurisdiction.md b/doc-sources/terminology/essifLab/pattern-jurisdiction.md deleted file mode 100644 index f54e76d..0000000 --- a/doc-sources/terminology/essifLab/pattern-jurisdiction.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -id: pattern-jurisdiction -title: "Pattern: Jurisdiction" -scopeid: essifLab -type: pattern -typeid: jurisdiction -stage: draft -hoverText: "The jurisdiction pattern captures the concepts and relations that explain what a generic jurisdiction consists of, and relates it to parties and legal entities." ---- - -import useBaseUrl from '@docusaurus/useBaseUrl'; - -## Purpose - -The **Jurisdiction pattern** captures the concepts and relations that explain how generic %%jurisdictions|jurisdiction%% work, and can be constructed. It shows that it can be seen as the composition of one %%scope|scope%%, one %%legal system|legal-system%% and one %%party|party%% that operates the legal system within that scope. - -## Introduction - -While most people are familiar with what we call %%legal jurisdictions|legal-jurisdiction%%, one readily observes that the characteristics of a jurisdiction - i.e. a %%scope|scope%% within which some party organizes that rules/laws/policies are being made, enforced and conflicts resolved - can be found outside of jurisdictions in numerous other contexts. For example, - -- %%organizations|organization%% habitually will have rules (business policies) in place, enforce them (to some extent), and have ways of resolving conflicts, and therefore qualify. Specifically, multi-nationals are known to operate multiple jurisdictions, aliging the rules and scopes with those 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. -- NGO's, may run aid-projects, refugee-camps etc., ensure that a set of rules apply within the scopes of such projects and camps, and arrange for (internal) conflicts to be resolved. Hence they qualify -- All sorts of clubs (sports, leisure, ...) have rules, means to enforce them, and a conflict resolution means which they operate within the scope of the locations they control and/or their activities. -- Families qualify as well: the parents make the rules, enforce them, and resolve conflicts. -- Even individual persons (which qualify as %%parties|party%%), have their own 'scope of control', within which they work according to their own rules (e.g. morals, ethics, preferred ways of working), enforce them (pretty much automatically), and resolve any conflicts (e.g. personal problems that may arise when their rules/habits conflict with what their spouse, employer, any else requires them to do). Saying that an individual operates a (personal) 'legal system' within its scope of control is aligned with the ideas human rights that say humans are 'self sovereign'. - -Still, jurisdictions have a lot of variety. The obvious (and self-evident) variety is in the parties that operate its legal system. However, there are also differences in scopes. %%Legal jurisdictions|legal-jurisdiction%% for example may align their scopes with different territories. %%Organizations|organization%% may align their scopes with physical locations as well, possibly aligning them (also) with scopes from legal jurisdictions. Smaller clubs, e.g. a bingo club that weekly hires a cafe for a few hours to do its things, will have its scope determined by location and time. Families and individuals have scopes that are limited by their ability to control (enforce rules). - -Jurisdictions also in terms of the legal system they apply. Different jurisdictions have different (kinds of) rules, which are there to ensure and facilitate that its party realizes the %%objectives|objective%% it has set (for that scope). Often, such rules include specifications of the processes for maintaining the rules themselves, for enforcing them, and for resolving conflicts. Depending on the specific jurisdiction, the specification and maintentance of rules can be anywhere from being very informal to very formal, enforcement ranges from being almost absent to very strict, and resolution of conflicts is anywhere between ad-hoc and tedious litigation. - -Note that all the rules, processes and decisions must be part of the %%knowledge|knowledge%% of the party that runs the jurisdiction. - -## Formalized model -Here is a visual representation of this pattern, using the following [notations and conventions](/docs/notations-and-conventions#pattern-diagram-notations): - -Conceptual model of the 'Jurisdiction' pattern - -The figure shows that a %%jurisdiction|jurisdiction%% comprises a single %%scope|scope%%, a (single) %%legal system|legal-system%% system and a %%party|party%% that operates this Legal System within the Scope (which it controls). The Legal System applies to %%Entities|entity%% that are known in the jurisdiction (e.g. registered with the party as per the rules of the legal system, leading to their being registered/represented in the %%knowledge|knowledge%% of that party). These are what, specifically for %%legal jurisdictions|legal-jurisdiction%% are called %%legal entities|legal-entity%%. \ No newline at end of file diff --git a/doc-sources/terminology/essifLab/pattern-mandates-delegation-hiring.md b/doc-sources/terminology/essifLab/pattern-mandates-delegation-hiring.md deleted file mode 100644 index 4cb1c80..0000000 --- a/doc-sources/terminology/essifLab/pattern-mandates-delegation-hiring.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -id: pattern-mandates-delegation-hiring -title: "Pattern: Mandates, Delegation and Hiring" -scopeid: essifLab -type: pattern -typeid: mandates-delegation-hiring -stage: draft -hoverText: "This pattern (which remains to be documented) captures the ideas behind mandating, delegating, hiring and their relations. This is a work-in-progress" ---- - -import useBaseUrl from '@docusaurus/useBaseUrl'; - -:::info Editors Note -TNO is expected to produce the first draft of this document -::: diff --git a/doc-sources/terminology/essifLab/pattern-mental-model.md b/doc-sources/terminology/essifLab/pattern-mental-model.md deleted file mode 100644 index 7fe7ae7..0000000 --- a/doc-sources/terminology/essifLab/pattern-mental-model.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -id: pattern-mental-model -title: "Pattern: Mental Models" -scopeid: essifLabTerminology -type: pattern -typeid: mental-model -stage: draft -hoverText: "This pattern captures the foundational concepts and relations that we need for creating, maintaining and using (decentralized) vocabularies (terminologies) that groups of people can use for the specific purposes they pursue." ---- - -## Purpose - -This pattern captures the foundational concepts and relations that we need for creating, maintaining and using vocabularies (terminologies) that groups of people can use for the specific purposes they pursue. Alternatively, we need these concepts to allow people to use 'decentralized vocabularies' that %%parties|party%% may create, maintain and use in a self-sovereign fashion - which means that each of them decides for itself what terms to use in what meaning, yet be able to communicate with other such %%parties|party%% in such a way that a correct understanding of what the other means, can more or less be guaranteed. - -## Introduction - -TL;DR: . - -A concept is an idea that is applied to all objects in a group. It is the way people see and understand something. The name used to identify a concept (the concept's label) is a "term". For example, the word "Dog" is the term to identify the concept of what a dog is. Everything that a person knows about a dog is the concept of the term dog. - -Different terms can be used to identify the same concept. Car and Automobile are synonyms for the same concept. Different languages have different terms for the same concept. This is what makes translation possible. The terms may be different in each language, but the concept is the same. The concept of jumping is the same to a person from England and a person from Italy, but one person uses the term "Jump" to mean the concept and the other person uses "Salto". - -## Notations - - -## - - - \ No newline at end of file diff --git a/doc-sources/terminology/essifLab/pattern-party-actor-action.md b/doc-sources/terminology/essifLab/pattern-party-actor-action.md deleted file mode 100644 index 2d05149..0000000 --- a/doc-sources/terminology/essifLab/pattern-party-actor-action.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -id: pattern-party-actor-action -title: "Pattern: Party-Action" -scopeid: essifLab -type: pattern -typeid: party-action -stage: draft -hoverText: "This pattern captures the foundational concepts and relations that we need for thinking about people (human beings), organizations, and how they interact with one another in a decentralized, self-sovereign way - which means that each of them decides for itself whether or not to interact with others, how to conduct such interactions, etc., thereby only taking external influences into account if they want, or have some need to do so." ---- - -## Purpose - -This pattern captures the foundational concepts and relations that we need for thinking about people (human beings), organizations, and how they interact with one another in a decentralized, self-sovereign way - which means that each of them decides for itself whether or not to interact with others, how to conduct such interactions, etc., thereby only taking external influences into account if they want, or have some need to do so. - -## Introduction - -TL;DR: This pattern models that %%Parties|party%% (humans, organizations) perform %%Actions|action%% for the purpose of realizing their %%Objectives|objective%%. %%Parties|party%% are not considered to actually execute such %%Actions|action%%; they have (human and non-human) %%Actors|actor%% that work for them, execute such %%Actions|action%%, using the %%Party|party%%’s %%Knowledge|knowledge%% as the (authoritative) guidance for executing the %%Actions|action%% (as well as any other relevant %%Knowledge|knowledge%% they can access). - -`` - -The essential characteristic of %%Parties|party%% is their 1-1 link with %%Knowledge|knowledge%%, which they continually update and use e.g. for reasoning, decision making, and determining e.g. what to do, when, and with whom. %%Knowledge|knowledge%% not only includes (observable) facts, but also opinions, e.g. regarding the %%Entities|entity%% it knows to exist, relations between them, and rules (constraints, [logic](https://en.wikipedia.org/wiki/Logic)[^1]) that can be used to classify and reasoning about them, and for making decisions. - -Perhaps the most important idea in this pattern is that our %%Party|party%% concept is not considered to (be able to) act, and they need %%Actors|actor%% (i.e. %%Entities|entity%% that _can_ act) to act on their behalf and thus make them perform. This does, however, not preclude having %%Entities|entity%% that are both %%Party|party%% and %%Actor|actor%% - e.g. humans - and that such %%Entities|entity%% can act on their ‘own’ behalf. And we can continue to use the commonly used form of speech in which a %%Party|party%% performs some Action by realizing that this means that there is (at least) one %%Actor|actor%% that is actually executing that %%Action|action%%. - -In this pattern, %%Knowledge|knowledge%% takes center stage. %%Knowledge|knowledge%% contains %%Objectives|objective%% to be realized and managed. This not only triggers all sorts of %%Actions|action%% to be performed, but also guides their execution in terms of when an Action should start, when it terminates, which %%Actors|actor%% qualify for executing it, etc. Everything that is specific for a %%Party|party%% is reflected in its %%Knowledge|knowledge%%. - -This works well for human beings, which are both a %%Party|party%% and an %%Actor|actor%%. So a human being can act, implying itself as an %%Actor|actor%%, and using its personal %%Knowledge|knowledge%% as guidance. The model also works when a human being (as a %%Party|party%%) may hire someone else (as an %%Actor|actor%%), e.g. to fill in his tax return form. This other is guided by the %%Knowledge|knowledge%% of the human being that hired him, and uses its own %%Knowledge|knowledge%% for the details of filling in the tax form. - -It also works well for organizations, which are typically companies, enterprises, governments or parts thereof, i.e. groups of human beings and possibly other %%Actors|actor%% that, as a group, fit the criteria for being a %%Party|party%%. This group of %%Actors|actor%% would typically work to realize the organization’s %%Objectives|objective%%, being guided by the organization’s %%Knowledge|knowledge%% (registrations, policies, etc.). Like human beings, an organization may (have an appropriate %%Actor|actor%%) decide to hire or fire %%Actors|actor%% for longer or shorter periods. - -%%Parties|party%% set %%Objectives|objective%% that they seek to achieve, the most basic of which perhaps is its mission, or its ‘raison d'être’, to the realization of which all of its %%Actions|action%% are (ultimately) aimed. Every Objective is owned by a single %%Party|party%% (we do not consider ‘shared objectives’[^2]). - -## Notations - - -## - - ---- -## Footnotes - - -[^1]: I.e. “logic is the analysis and appraisal of arguments (Gensler, Harry J. (2017) [2002]. "Chapter 1: Introduction". Introduction to logic (3rd ed.). New York: Routledge. p. 1. [doi:10.4324/9781315693361](https://doi.org/10.4324%2F9781315693361). [ISBN 9781138910591](https://en.wikipedia.org/wiki/Special:BookSources/9781138910591). OCLC [957680480](https://www.worldcat.org/oclc/957680480).) - -[^2]: The Networked Risk Management (NRM) pattern deals with the setting and realizing of %%Objectives|objective%%, the associated risk management etc., and explains the reasoning for not having shared %%Objectives|objective%%. \ No newline at end of file diff --git a/doc-sources/terminology/essifLab/pattern-terminology.md b/doc-sources/terminology/essifLab/pattern-terminology.md deleted file mode 100644 index 7295a5a..0000000 --- a/doc-sources/terminology/essifLab/pattern-terminology.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -id: pattern-terminology -title: "Pattern: eSSIF-Lab Terminology Corpus" -scopeid: essifLab -type: pattern -typeid: terminology -stage: draft -hoverText: "pattern-terminology - hovertext" ---- - - -## Purpose - - -## Introduction - - -## Notations - - -## - - - \ No newline at end of file diff --git a/doc-sources/terminology/essifLab/peer-agent.md b/doc-sources/terminology/essifLab/peer-agent.md deleted file mode 100644 index 8906e87..0000000 --- a/doc-sources/terminology/essifLab/peer-agent.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -id: peer-agent -title: "Peer Agent" -scopeid: essifLab -type: term -typeid: peer-agent -conceptref: essifLab:Agent -stage: draft -hoverText: "(Peer Agent of a Agent): the other Agent with whom this Agent is communicating in the context of a transaction." ---- - -## Purpose - -%%Parties|party%% that participate in a (business) transaction may use %%Agents|agent%%, e.g. for conducting communications, exchanging information, etc. We need a term that can be used in the context of an Agent of such a Party to refer to an Actor with which that Agent communicates, and of which it has been established that it is actually an Agent of a %%Peer Party|peer-party%% of the Party for which it is communicating. - -## Notes - -The term 'peer agent' is specifically used in the context of a (digital) Actor that communicates with another (digital) Actor on behalf of a party that is conducting a (business) transaction with some other party. diff --git a/doc-sources/terminology/essifLab/peer-party.md b/doc-sources/terminology/essifLab/peer-party.md deleted file mode 100644 index aaf9225..0000000 --- a/doc-sources/terminology/essifLab/peer-party.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -id: peer-party -title: "Peer Party" -scopeid: essifLab -type: term -typeid: peer-party -conceptref: essifLab:party -stage: draft -hoverText: "(Peer Party of a Party): the other Party that is a participant in a transaction of that Party." ---- - -## Purpose - -Within the context of a (business) transaction, at least two %%Parties|party%% participate. From the perspective of any such party, we need the ability to refer to (any of) the other party/parties. - -## Notes - -The term 'peer party' is specifically used in the context of a (business) transaction. diff --git a/doc-sources/terminology/essifLab/risk.md b/doc-sources/terminology/essifLab/risk.md deleted file mode 100644 index c2354f6..0000000 --- a/doc-sources/terminology/essifLab/risk.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: risk -title: "Risk" -scopeid: essifLab -type: concept -typeid: risk -stage: draft -hoverText: "the deviation of the expected realization (e.g. results) of an objective of a party" ---- - -:::info Editors Note -TNO is expected to produce the first draft of this document -::: - -## Short Description - -## Purpose - -## Criterion: - -## References - -[1]: NRM, [ISO 27000:2016](https://www.iso.org/obp/ui#iso:std:iso-iec:27000:ed-4:v1:en) \ No newline at end of file diff --git a/doc-sources/terminology/essifLab/scope-essifLab.md b/doc-sources/terminology/essifLab/scope-essifLab.md deleted file mode 100644 index aa38480..0000000 --- a/doc-sources/terminology/essifLab/scope-essifLab.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -id: essifLab-scope -title: "Scope: eSSIF-Lab" -scopeid: essifLab -type: scope -typeid: essifLab -stage: draft -hoverText: "scope essifLab - popuptext tbd" ---- - -## Governance - -The [eSSIF-Lab project](https://essif-lab.eu/) governs the terminology within this scope, according to the procedures mentioned in the [eSSIF-Lab Framework](https://essif-lab.pages.grnet.gr/framework/docs/terminology/). - -## Objectives/Issues - -Contributors to and users of eSSIF-Lab come from various backgrounds. Their culture may not be Western. English may not be their native tongue. They may be experts in non-technological topics. Working with one another presumes a setting where participants have some level of shared understanding. Often, sharing one's understanding at a superficial level suffices. Other situations require that underlying concepts are shared in a more in-depth fashion. It's like cars: people buying, selling, or driving cars do not need in-depth shared knowledge about cars, whereas (maintenance or construction) engineers or liability lawyers need to share a deeper knowledge of how cars do (or do not) work. - -We expect to see situations of "language confusion", i.e. in which people use words or phrases, the intension (not: intention) of which differs from the interpretation of some listeners/readers. Sometimes a casual glance at a dictionary or glossary is the solution. In other cases, deeper understanding matters, e.g. in when drafting specifications or contracts. Then we need more than a set of definitions. - -The Concepts and Terminology part of eSSIF-Lab aims helps eSSIF-Lab community participants understand one another at whatever level of precision they need. - -## Scope URI - - -## Inclusions - -essifLabTerminology - -## Notes - - -## Tags - - - diff --git a/doc-sources/terminology/essifLab/ssi-agent.md b/doc-sources/terminology/essifLab/ssi-agent.md deleted file mode 100644 index c6bf2cc..0000000 --- a/doc-sources/terminology/essifLab/ssi-agent.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -id: ssi-agent -title: "SSI Agent" -scopeid: essifLab -type: term -typeid: ssi-agent -conceptref: essifLab:Agent -stage: draft -hoverText: "Agent that provides SSI services." ---- - -## Purpose - - - -## Notes - - diff --git a/doc-sources/terminology/essifLab/transaction-result-dispatcher.md b/doc-sources/terminology/essifLab/transaction-result-dispatcher.md deleted file mode 100644 index c73d287..0000000 --- a/doc-sources/terminology/essifLab/transaction-result-dispatcher.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -id: transaction-result-dispatcher -title: "Transaction Result Dispatcher" -scopeid: essifLab -type: concept -typeid: transaction-result-dispatcher -stage: draft -hoverText: "hovertext for transaction-result-dispatcher" ---- - -## Short Description - -## Purpose - -## Criterion: - -## Examples: diff --git a/doc-sources/terminology/essifLab/transaction-validation-engine.md b/doc-sources/terminology/essifLab/transaction-validation-engine.md deleted file mode 100644 index ce7b731..0000000 --- a/doc-sources/terminology/essifLab/transaction-validation-engine.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -id: transaction-validation-engine -title: "transaction-validation-engine" -scopeid: essifLab -type: concept -typeid: transaction-validation-engine -stage: draft -hoverText: "transaction-validation-engine" ---- - -## Short Description - -## Purpose - -## Criterion: - -## Examples: diff --git a/doc-sources/terminology/essifLab/trd.md b/doc-sources/terminology/essifLab/trd.md deleted file mode 100644 index c37fb1b..0000000 --- a/doc-sources/terminology/essifLab/trd.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -id: trd -title: "TRD - Transaction Result Dispatcher" -scopeid: essifLab -type: concept -typeid: trd -stage: draft -hoverText: "trd - popuptext t.b.d." ---- - -## Short Description - - -## Purpose - - -## Criteria - - -## Examples - - -## Related Concepts - - -## Domains - - -## Tags - - -## Use-cases - - -## Notes - - - diff --git a/doc-sources/terminology/essifLab/tve.md b/doc-sources/terminology/essifLab/tve.md deleted file mode 100644 index d954f59..0000000 --- a/doc-sources/terminology/essifLab/tve.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -id: tve -title: "TVE - Transaction Validation Engine" -scopeid: essifLab -type: concept -typeid: tve -stage: draft -hoverText: "tve - popuptext t.b.d." ---- - -## Short Description - - -## Purpose - - -## Criteria - - -## Examples - - -## Related Concepts - - -## Domains - - -## Tags - - -## Use-cases - - -## Notes - - - diff --git a/doc-sources/terminology/readme-generator-extensions.md b/doc-sources/terminology/readme-generator-extensions.md deleted file mode 100644 index ecf8f54..0000000 --- a/doc-sources/terminology/readme-generator-extensions.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -id: readme-generator-extensions -title: "Creating Terminology Artifact Generators" -stage: draft -stage: draft -stage: draft -stage: draft -hoverText: "Various terminological artifacts are generated. Click to see how you can create your own." ---- - -:::caution text needs to be authored -Content may be provided by GRNET. -::: diff --git a/doc-sources/terminology/readme-making-contributions.md b/doc-sources/terminology/readme-making-contributions.md deleted file mode 100644 index 98d57d1..0000000 --- a/doc-sources/terminology/readme-making-contributions.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -id: readme-making-contributions -title: Making Contributions to the Terminology Corpus -stage: draft -hoverText: "Click on the text to navigate to the instructions on how to contribute to the terminology." ---- - -:::note Status of this document -A first draft is under construction. -::: - -Contributing to the eSSIF-Lab Terminology Corpus is primarily done by authoring, organizing and/or maintaining a set of files that serve as input to the various generators that actually produce the terminological artifacts that serve various purposes of the eSSIF-Lab. This document describes how you can do this.[1] - -In order to contribute, you first need to understand the [ideas/concepts behind the terminology corpus](essifLab-pattern-terminology), i.e. -- what %%scopes|scope%%, %%concepts|concept%%, %%terms|term%%, %%(terminological) patterns|pattern%% are, -- the kinds of terminological artifacts such as %%glossaries|glossary%%, %%dictionaries|dictionary%%) that can be generated and -- the purposes that such artifacts intend to serve (and what makes them fit for such purposes). - -## Scope-files - -:::info Editors Note -Content may be provided by TNO. -::: - -## Concept-files - -:::info Editors Note -Content may be provided by TNO. -::: - -## Term-files - -:::info Editors Note -Content may be provided by TNO. -::: - -## Pattern-files - -:::info Editors Note -Content may be provided by TNO. -::: - -## Glossary-files - -:::info Editors Note -Content may be provided by TNO. -::: - -## Dictionary-files - -:::info Editors Note -Content may be provided by TNO. -::: - ---- -## Footnotes - -[1]: However, if the need were to arise for terminological artifacts that are not (yet) generated, you can contribute by [creating/modifying a generator](readme-generator-extensions) for such artifacts. diff --git a/doc-sources/terminology/scope-registration.json b/doc-sources/terminology/scope-registration.json deleted file mode 100644 index 936700e..0000000 --- a/doc-sources/terminology/scope-registration.json +++ /dev/null @@ -1,11 +0,0 @@ -{ "scope-registration": [ - { "scopeid": "essifLab" - , "scopename": "eSSIF-Lab" - , "location": "https://gitlab.grnet.gr/essif-lab/framework/terminology" - , "subscopes": [ - { "scopeid": "essifLabTerminology" - , "scopename": "eSSIF-Lab Terminology" - , "location": "https://gitlab.grnet.gr/essif-lab/framework/terminology/terminology" - }] - }] -} diff --git a/doc-sources/terminology/templates/concept-file.md b/doc-sources/terminology/templates/concept-file.md deleted file mode 100644 index 37cd056..0000000 --- a/doc-sources/terminology/templates/concept-file.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -id: -title: "" -scopeid: -type: concept -typeid: -stage: draft -hoverText: "" ---- - - -## Short Description - - -## Purpose - - -## Criteria - - -## Examples - - -## Related Concepts - - -## Background: - - -## Domains - - -## Tags - - -## Use-cases - - -## Notes - - - \ No newline at end of file diff --git a/doc-sources/terminology/templates/dictionary-file.md b/doc-sources/terminology/templates/dictionary-file.md deleted file mode 100644 index 42adb32..0000000 --- a/doc-sources/terminology/templates/dictionary-file.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -id: -dictionary- -title: "Title text for this dictionary" -scopeid: -type: dictionary -typeid: -stage: draft -hoverText: "" ---- - - -## Purpose - - -## Scopes - diff --git a/doc-sources/terminology/templates/glossary-file.md b/doc-sources/terminology/templates/glossary-file.md deleted file mode 100644 index 39a03be..0000000 --- a/doc-sources/terminology/templates/glossary-file.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -id: -glossary- -title: "Title text for this glossary" -scopeid: -type: glossary -typeid: -stage: draft -hoverText: "" ---- - - -## Purpose - - -## Sources - - -### Terms - - -### Concepts - - -### Patterns - - -### Glossaries - - - diff --git a/doc-sources/terminology/templates/pattern-file.md b/doc-sources/terminology/templates/pattern-file.md deleted file mode 100644 index 0a88062..0000000 --- a/doc-sources/terminology/templates/pattern-file.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -id: -pattern- -title: "Pattern: " -scopeid: -type: pattern -typeid: -stage: draft -hoverText: "" ---- - - -## Purpose - - -## Introduction - - -## Notations - - -## - - - \ No newline at end of file diff --git a/doc-sources/terminology/templates/scope-file.md b/doc-sources/terminology/templates/scope-file.md deleted file mode 100644 index db262e4..0000000 --- a/doc-sources/terminology/templates/scope-file.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -id: -scope- -title: "Scope: " -scopeid: -type: scope -typeid: -stage: draft -hoverText: "" ---- - - -## Governance - - -## Objectives/Issues - - -## Scope URI - - -## Inclusions - - -## Notes - - -## Tags - - - diff --git a/doc-sources/terminology/templates/template-file.md b/doc-sources/terminology/templates/template-file.md deleted file mode 100644 index b1de3ae..0000000 --- a/doc-sources/terminology/templates/template-file.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -id: -- -title: "" -scopeid: <scopeID> -type: <type> -typeid: <typeID> -stage: draft -hoverText: "<Text that pops up when the user hovers over a reference to this document>" ---- -<!--This template specifies the docusaurus attribtues that must be in place for the terminology-plugin to function properly. For specific generators, additional content may be required. That should be specified in the individual templates that specify the artifacts that such generators create. -The header-attributes contain the following placeholdes: -- `<scopeID>`: machine readable text that identifies the scope in which this term is defined; -- `<type>`: machine readable text that identifies the type of entity being documented/specified. Examples include `concept`, `term`, `pattern`, `glossary`, `dictionary` and new ones may be added as needed.; -- `<typeid>`: machine readable text that identifies the instance of the <type> within <existing-scope>; ---> diff --git a/doc-sources/terminology/templates/term-file.md b/doc-sources/terminology/templates/term-file.md deleted file mode 100644 index 203e0bf..0000000 --- a/doc-sources/terminology/templates/term-file.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -id: <new-termID> -title: "<New Term>" -scopeid: <existing-scopeID> -type: term -typeid: <new-termID> -conceptref: <ExistingConceptScopeID>:<ExistingtermID> -stage: draft -hoverText: "<Text that pops up when the user hovers over a reference to this term>" ---- -<!--A Term is a word or phrase that is used in at least one scope (context and/or for specific purposes) to refer to some concept. -Please fill in the placeholders in this file as follows: -- `<existing-scopeID>`: machine readable text that identifies the scope in which this term is defined; -- `<Existing Scope>`: human readable text that identifies the scope in which this term is defined; -- `<new-termID>`: machine readable text that identifies this term within <existing-scopeID>; -- `<New Term>`: human readable text that identifies this term within <Existing Scope>; -- `<ExistingConceptScopeID>`: identifier of the scope in which the concept, to which the new term will refer, is known; -- `<ExistingtermID>`: machine readable identifier that identifies a concept within <ExistingConceptScopeID> ---> - -## Purpose -<!--State the purpose(s) for which it is necessary (or at least: desirable) to define <New Term>.--> - -## Notes -<!--Usually, the meaning of a term will not be _exactly_ the same as that of the concept to which it refers. Often, there are slight differences in meaning, or the term may emphasize specific characteristics of the concept, so as to accommodate specific needs of the scope in which it is defined. Please describe such deviations/emphasized characteristics in this section, and which needs that helps accommodate.--> - -<!-- ---- -## 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/doc-sources/terminology/terminology - backup.mdx b/doc-sources/terminology/terminology - backup.mdx deleted file mode 100644 index 0c34a7d..0000000 --- a/doc-sources/terminology/terminology - backup.mdx +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: terminology -title: "eSSIF-Lab: Concepts and Terminology" ---- - -The purpose of the eSSIF-Lab Terminology is to provide mental models that all of its stakeholders interpret in sufficiently the same way, so as to be able to talk, think and discuss about what it is we try to achieve and ways to achieve this. - -## Introduction - -Contributors to and users of eSSIF-Lab come from various backgrounds. Their culture may not be Western. English may not be their native tongue. They may be experts in non-technological topics. Working with one another presumes a setting where participants have some level of shared understanding. Often, sharing one's understanding at a superficial level suffices. Other situations require that underlying concepts are shared in a more in-depth fashion. It's like cars: people buying, selling, or driving cars do not need in-depth shared knowledge about cars, whereas (maintenance or construction) engineers or liability lawyers need to share a deeper knowledge of how cars do (or do not) work. - -We expect to see situations of "language confusion", i.e. in which people use words or phrases, the intension (not: intention) of which differs from the interpretation of some listeners/readers. Sometimes a casual glance at a dictionary or glossary is the solution. In other cases, deeper understanding matters, e.g. in when drafting specifications or contracts. Then [we need more than a set of definitions](https://www.sfu.ca/~swartz/definitions.htm). - -The Concepts and Terminology part of eSSIF-Lab aims helps eSSIF-Lab community participants understand one another at whatever level of precision they need. - -## Glossaries - -The traditional tool for fostering common understanding is using glossaries, i.e. alphabetical lists of words relating to a specific subject, text, or dialect, with explanations; a brief dictionary ([OED](https://www.lexico.com/definition/glossary)). Examples include the [Sovrin Glossary](https://sovrin.org/library/glossary/) and the [NIST Glossary](https://csrc.nist.gov/glossary). Other initiatives attempt to provide more background, e.g. the [terminology for talking about privacy by data minimization](https://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.34.pdf) by Pfitzmann and Hansen (2010), or the [EBSI Terminology (login required)](https://ec.europa.eu/cefdigital/wiki/display/EBP/EBSI+Terminology). - -The eSSIF-Lab project will also develop a [Glossary](glossary). - -However, since the use of such glossaries is limited to short explanations, we will also provide (a) mental model(s) that provide a more in-depth explanation of the concepts that underly the words listed in the [Glossary](glossary). - -## Mental Models - -A Mental Model, or Conceptual Model, is a set of of concepts (i.e. entity classes), relations between such concepts (i.e. sets of pairs of members of classes that a relation connects), and rules/constraints expressed in terms of these relations and concepts. - -The first purpose of a Mental Model 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. - -So a mental model requires careful construction, that allows the choices for its elements to be validated against many use-cases. Such validation instills trust that our model elements (concepts, relations, rules) are well-chosen. It also provides us with the experience (usually after some time) that it has made our thinking easier, and we are better equipped to resolve issues. - -The careful construction is comparable to a quest: it takes time, multiple versions, and careful reflection. And it needs continuous validation of its parts, by throwing use-cases at it and verifying that the model can describe such cases, and do some reasoning with them. - -This careful construction must ensure that the mental model gets different properties. For starters, the model 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 mental model 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. - -## Terminology and Definitions - -We attempt to create definitions that are both acceptable for business people yet are precise enough to serve as a basis for formal reasoning. We do this by using [intensional definitions](https://en.wikipedia.org/wiki/Extensional_and_intensional_definitions), i.e. by defining criteria that specify the necessary and sufficient conditions for when a term should be used. We have tried to craft these definitions such that - -- readers are likely to make the same judgements when using them, and -- these distinctions are relevant for our purposes. That’s the important stuff. - -The actual texts we choose as the name for a concept is of secondary importance; if in a particular context other names are more suitable, you can rename them there without loss of meaning or consistency. - -Together with these criteria, we provide a limited set of examples to help the reader to visualize the defined concepts, and to point out possibly unexpected consequences of the criteria. Also, we may motivate the need for having a concept by showing its relevance for the model. - -Here are some examples: - -### Entity -**someone or something that is known/thought of**. - -Basically, anything you (or anyone else) can think of qualifies. That includes people, organizations, documents, data, ideas, etc. Things that you do not know that exist, but others do, also qualify. -Since there is nothing that you, or someone else, can come up with that does not satisfy the criterion, everything qualifies as an Entity. We need the term as a basis for creating intensional definitions. - -### Definition -**Entity that comprises at a minimum: - -- a non-empty set of scopes in each of which specific objectives are being pursued; -- a criterion that specifies the necessary and sufficient conditions for being an instance of a named class; -- a set of arguments and/or use-cases (that SHOULD not be empty), and that show the relevance of making this distinction within the scope (and for its objectives); -- a name that is created and used within the scope that created the definition, for the purpose of referring to the class, or using it as a placeholder for its instances. - -For the purposes of this document, the scope of every Definition is this Document (with its objectives that have been specified above).** - -Note that this definition satisfies itself. Also note that a definition may be used in multiple scopes, where a scope that wants to use the definition that has been defined in another scope, may replace that name with one of its own choosing. This way the meaning expressed by the definition remains preserved. - -### Concept -**A named set of entities that satisfy a criterion that specifies the necessary and sufficient conditions for being a member of that set** - -### Relation -**A named set of entity-pairs (L,R), and a criterion C(SRC,TGT), where - -- SRC and TGT are Concepts; -- L is an element of SRC and R is an element of TGT; -- the name of the relation combined with SRC and TGT identifies the set; -- C(L,R) is satisfied.** - -For example, a relation could be defined by: - -- name=‘is owner of’ -- SRC=’Party’ and TGT=’Entity’ and -- C(SRC,TGT)=‘SRC is the owner of TGT’ - -This relation contains all pairs (X,Y) for which Party X is the owner of Y. The set of entity-pairs (L,R) is called the extension of the relation. The criterion C(L,R) is also referred to as the intension of the relation (as, together with this definition, it intensionally defines the relation) - -### Rule (or Constraint) -**A Relation the intension of which consists of pairs that do not satisfy a specified expression that consists of concept (elements) and relations, and that can logically be evaluated.** - -### Pattern -** A coherent set of Concepts, Relations between these Concepts, and Rules that are expressed in terms of these Concepts and Relations.** - -We need Patterns as a mechanism for ‘chopping up’ mental models, in order to accommodate for the human disability to consciously oversee and think about more than 7 +/- 2 Concepts (including attributes, Relations, and Rules). -Patterns may be associated with texts e.g. for motivating its existence, explaining its purpose, etc. - -## Notations -We shall use keywords such as “shall”, “should”, “may” etc. as defined by [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). - -Also, we capitalize words in mid-sentence whenever it is used in the meaning as provided by a corresponding Definition. This allows us to also use the more colloquial meanings of words (by not capitalizing them). We appreciate any feedback regarding our (im)proper use of this kind of capitalization of words. - -Patterns will be visualized in this document using a UML-like notation, as follows: - -- a rectangle represents a (named) concept. Concepts serve as entity-classes. Their (operational) extensions, i.e. the respective sets of (runtime) instances, are disjunct. -- a solid line with a closed arrowhead represent a (named) relation/association between the two concepts it connects. The concept at the arrowhead is called the ‘target concept’ (TGT) for that relation. The concept at the other end is called the ‘source concept’ (SRC) for that relation. Names are chosen such that `<SRC> <relation name> <TGT>` is a phrase that suggests the intension(al definition) of that relation. -- a dashed line signifies that its intension is created by combination the intensions of other relations (it is a ‘shorthand’ for a path of other relations). -- an open-ended arrow is an ‘ISA’ relation, which can be read as `<SRC> ISA <TGT>`. It means that SRC is a specialization of TGT (which is a generalization of SRC). Thus, SRC must satisfy all constraints that TGT must satisfy, and has all attributes (including properties) that TGT has. -- Multiplicities use the [n..m] notation. When a multiplicity is omitted, [0..n] is intended. -- A concept that is coloured red(dish) represents a notion that is commonly used ‘in the wild’ (and hence needs not be defined here), relates to one or more concepts we need for the pattern, yet is not the same. We include such ‘red concepts’ to help readers identify and subsequently bridge gaps between commonly held thoughts and the (sometimes subtly) different meanings we need in our model. \ No newline at end of file diff --git a/doc-sources/terminology/terminology.mdx b/doc-sources/terminology/terminology.mdx deleted file mode 100644 index 76ef08c..0000000 --- a/doc-sources/terminology/terminology.mdx +++ /dev/null @@ -1,146 +0,0 @@ ---- -id: terminology -title: "eSSIF-Lab: Concepts and Terminology" -scopeid: essifLab ---- - -:::info **UNDER CONSTRUCTION** -*This (initial version of the) terminology chapter is currently under construction. If you feel like making a contribution, please contact [the editor](mailto:rieks.joosten@tno.nl)* -::: - -The purpose of the eSSIF-Lab Terminology Corpus is to help people that want or need to -- understand the gist of texts about various topics (learners, CxO's); -- write texts on (a) specific topic(s) (authors); -- deeply understand texts (reviewers, domain experts); -- prevent and/or resolve misunderstandings with others working on the same/similar topics (engineers); -- make (e.g. design) decisions concerning specific topics based on solid, consistent and coherent arguments; -- create code and/or data models for automation purposes; -- etc. - -## Introduction - -Contributors to and users of eSSIF-Lab come from various backgrounds. Their culture may not be Western. English may not be their native tongue. They may be experts in non-technological topics. Working with one another presumes a setting where participants have some level of shared understanding. Often, sharing one's understanding at a superficial level suffices. Other situations require that underlying concepts are shared in a more in-depth fashion. It's like cars: people buying, selling, or driving cars do not need in-depth shared knowledge about cars, whereas (maintenance or construction) engineers or liability lawyers need to share a deeper knowledge of how cars do (or do not) work. - -This is far from trivial, and hence we expect to see situations of "language confusion", i.e. in which people use words or phrases, the intension ([not: intention](https://www.askdifference.com/intention-vs-intension/)) of which differs from the interpretation of some listeners/readers. Sometimes a casual glance at a dictionary or glossary is the solution. In other cases, deeper understanding matters, e.g. in when drafting specifications or contracts. Then [we need more than a set of definitions](https://www.sfu.ca/~swartz/definitions.htm). - -This chapter reflects the learnings of eSSIf-Lab with respect to what such additional needs are, and provides the backgrounds of the methods, means and/or tools that may help to accommodate such needs. Here is a summary: - -1. People that read a text may need help in understanding various words or phrases, particularly if they are not very familiar with the subject matter (they may be learning, and/or the text doesn't have an associated glossary), or come from another society. For such purposes, it helps to have an alphabetically sorted lists of words and phrases, each of which associated with one or more meanings or explanations that such words/phrases may have. We call this list a %%dictionary|dictionary%%. The eSSIF-Lab project intends to look into the possibility and necessity of generating a dictionary of SSI-related words and phrases based on the materials that are readily available; if it turns out this is beneficial, the eSSIF-Lab will contribute to the extent that is allowed by the project constraints. -2. Authors (e.g. of programming code, or articles of various kinds) that produce text on a particular topic, will want the words and phrases they use to be associated with a single meaning. This also holds for people that want to discuss a particular topic. For purposes such as these, it helps to have an alphabetically sorted lists of words and phrases, each of which associated with a single meaning or explanation that they can refer to. We call such lists %%glossaries|glossary%%. The eSSIF-Lab project intends to allow for the automated generation of such glossaries whenever a specific need for that exists. -3. People may find they need to better understand the ideas/concepts that terms refer to, e.g. because their thoughts keep running around in circles, they cannot get software to work in a generic fashion, etc. The eSSIF-Lab project intends to provide a (structured) repository where people can store texts that - - describe what we call a %%pattern|pattern%% or %%mental model|pattern%%, i.e. a coherent set of %%concepts|concepts%%, relations between these concepts, and rules/constraints that apply. A pattern also motivates its existence, and provides examples of when and how it can be used in a purposeful way; - - specify individual %%concepts|concept%% in a precise and in-depth manner, beyond what is possible by the texts used in patterns; - - specify how specific words or phrases (%%terms|term%%) are mapped onto such %%concepts|concept%% within specific scopes/contexts; - - specify a %%scope (or context)|scope%%, i.e. the extent of the area or subject matter within which we define patterns, concepts, terms and glossaries, allowing patterns to be used in a limited scope, terms to be have different meanings in different scopes, etc. - -## Context - -People use %%words and phrases (terms)|term%% to (tangibly) refer to the (intangible) %%ideas and thoughts (concepts)|concept%% they have, e.g. about what exists in the world, judgements they have, etc.<sup>[semantics]</sup> This mapping of terms and concepts, which we call '[semantics](wikipedia/semantics)', that is unique for each %%person or organization|party%%, enables them to reflect on their thoughts, and to convey such thoughts to others. Good communication however requires that the semantics of the communicating parties is sufficiently the same, so that the recipient of a communication will interpret it such that it means (sufficiently) the same to him as the communication means to its sender. - -The Concepts and Terminology part of eSSIF-Lab aims helps eSSIF-Lab community participants understand one another at whatever level of precision they need. This chapter presents a number of aids we will develop/maintain to serve that purpose. - -[semantics]: we use the term %%semantics|semantics%% to refer to the mapping between %%terms|term%% and %%concepts|concept%%. We use the term %%scope|scope%% ([OED](https://www.lexico.com/definition/scope)) to refer to the extent of the area or subject matter that a semantics is relevant and/or being used. From this definition, it seems obvious that every %%party|party%% has - and maintains - its own (subjective) semantics. The (erroneous) assumption that people (automatically) share a semantics is the cause of many misunderstandings. - -## Concepts, Terminologies, Glossaries, Dictionaries, etc. - -Conveying one's thoughts is deciding which words or phrases to use for referring to the ideas or %%concepts|concept%% that one is thinking about. We will use the word %%Term%|term%% to refer to a word or phrase, that is used in some %%context (or: scope)|scope%% to refer to a specific concept. Hence, a Term can mean different things in different contexts. Examples are "localhost", or "mommy". Also, different Terms that are used in different contexts may still refer to the same concept. For example, the person referred to as "Rieks" in some contexts is known as "Mr. Joosten" in other contexts. - -Because of this, generally dealing with terminologies, i.e. sets of words or phrases with a presumed meaning, is a difficult topic, demonstrated e.g. by the work of Pfitzmann and Hansen who created a [terminology for talking about privacy by data minimization](https://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.34.pdf) (2010), the development of which took over a decade, and has seen over 30 revisions. - -A commonly used tool for fostering common understanding are %%glossaries|glossary%%, i.e. an alphabetically sorted lists of words and phrases that relate to a specific subject (or text, dialect, ...) with explanations ([OED](https://www.lexico.com/definition/glossary)). - -Glossaries come in two basic flavors. One flavor, which we will call %%dictionary|dictionary%%, is a glossary where each term is associated with multiple meanings. An example is the [NIST Glossary](https://csrc.nist.gov/glossary). It allows people that hear or read about something to search for a meaning that is appropriate for the context of that communication. - -The other flavor (for which we do not yet have a term to distinguish it from dictionaries), is a glossary that is about one specific topic/subject, and lists a set of terms that have a single meaning, that together form a coherent and consistent terminology, and serves one or more specific purposes regarding this topic/subject. An example is the [Sovrin Glossary](https://sovrin.org/library/glossary/). Such glossaries allow people e.g. to write code, or an article about the topic. - -The eSSIF-Lab project will develop glossaries (of the second kind) as needed, and for specific purposes<sup>[1]</sup>. The idea is to just develop the specification of a glossary (specifying its purpose(s), the set of terms that are to be included, and the way in which the descriptions can be obtained), and then 'simply' generate the glossary. Doing so allows the automated generation and updating of glossaries. - -[1]: Too often have we observed that people seem to think that the mere fact of having a glossary makes (many or all) terminological issues go away, and that in practice that is not the case. We seek to define glossaries only if they are demonstrably fit-for-(some)-purpose. - -## Mental Models - -A Mental Model, or Conceptual Model, is a set of of concepts (i.e. entity classes), relations between such concepts (i.e. sets of pairs of members of classes that a relation connects), and rules/constraints expressed in terms of these relations and concepts. - -The first purpose of a Mental Model 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. - -So a mental model requires careful construction, that allows the choices for its elements to be validated against many use-cases. Such validation instills trust that our model elements (concepts, relations, rules) are well-chosen. It also provides us with the experience (usually after some time) that it has made our thinking easier, and we are better equipped to resolve issues. - -The careful construction is comparable to a quest: it takes time, multiple versions, and careful reflection. And it needs continuous validation of its parts, by throwing use-cases at it and verifying that the model can describe such cases, and do some reasoning with them. - -This careful construction must ensure that the mental model gets different properties. For starters, the model 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 mental model 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. - -## Terminology and Definitions - -We attempt to create definitions that are both acceptable for business people yet are precise enough to serve as a basis for formal reasoning. We do this by using [intensional definitions](https://en.wikipedia.org/wiki/Extensional_and_intensional_definitions), i.e. by defining criteria that specify the necessary and sufficient conditions for when a term should be used. We have tried to craft these definitions such that - -- readers are likely to make the same judgements when using them, and -- these distinctions are relevant for our purposes. That’s the important stuff. - -The actual texts we choose as the name for a concept is of secondary importance; if in a particular context other names are more suitable, you can rename them there without loss of meaning or consistency. - -Together with these criteria, we provide a limited set of examples to help the reader to visualize the defined concepts, and to point out possibly unexpected consequences of the criteria. Also, we may motivate the need for having a concept by showing its relevance for the model. - -Here are some examples: - -### Entity -**someone or something that is known/thought of**. - -Basically, anything you (or anyone else) can think of qualifies. That includes people, organizations, documents, data, ideas, etc. Things that you do not know that exist, but others do, also qualify. -Since there is nothing that you, or someone else, can come up with that does not satisfy the criterion, everything qualifies as an Entity. We need the term as a basis for creating intensional definitions. - -### Definition -**Entity that comprises at a minimum: - -- a non-empty set of scopes in each of which specific objectives are being pursued; -- a criterion that specifies the necessary and sufficient conditions for being an instance of a named class; -- a set of arguments and/or use-cases (that SHOULD not be empty), and that show the relevance of making this distinction within the scope (and for its objectives); -- a name that is created and used within the scope that created the definition, for the purpose of referring to the class, or using it as a placeholder for its instances. - -For the purposes of this document, the scope of every Definition is this Document (with its objectives that have been specified above).** - -Note that this definition satisfies itself. Also note that a definition may be used in multiple scopes, where a scope that wants to use the definition that has been defined in another scope, may replace that name with one of its own choosing. This way the meaning expressed by the definition remains preserved. - -### Concept -**A named set of entities that satisfy a criterion that specifies the necessary and sufficient conditions for being a member of that set** - -### Relation -**A named set of entity-pairs (L,R), and a criterion C(SRC,TGT), where - -- SRC and TGT are Concepts; -- L is an element of SRC and R is an element of TGT; -- the name of the relation combined with SRC and TGT identifies the set; -- C(L,R) is satisfied.** - -For example, a relation could be defined by: - -- name=‘is owner of’ -- SRC=’Party’ and TGT=’Entity’ and -- C(SRC,TGT)=‘SRC is the owner of TGT’ - -This relation contains all pairs (X,Y) for which Party X is the owner of Y. The set of entity-pairs (L,R) is called the extension of the relation. The criterion C(L,R) is also referred to as the intension of the relation (as, together with this definition, it intensionally defines the relation) - -### Rule (or Constraint) -**A Relation the intension of which consists of pairs that do not satisfy a specified expression that consists of concept (elements) and relations, and that can logically be evaluated.** - -### Pattern -** A coherent set of Concepts, Relations between these Concepts, and Rules that are expressed in terms of these Concepts and Relations.** - -We need Patterns as a mechanism for ‘chopping up’ mental models, in order to accommodate for the human disability to consciously oversee and think about more than 7 +/- 2 Concepts (including attributes, Relations, and Rules). -Patterns may be associated with texts e.g. for motivating its existence, explaining its purpose, etc. - -## Notations -We shall use keywords such as “shall”, “should”, “may” etc. as defined by [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). - -Also, we capitalize words in mid-sentence whenever it is used in the meaning as provided by a corresponding Definition. This allows us to also use the more colloquial meanings of words (by not capitalizing them). We appreciate any feedback regarding our (im)proper use of this kind of capitalization of words. - -Patterns will be visualized in this document using a UML-like notation, as follows: - -- a rectangle represents a (named) concept. Concepts serve as entity-classes. Their (operational) extensions, i.e. the respective sets of (runtime) instances, are disjunct. -- a solid line with a closed arrowhead represent a (named) relation/association between the two concepts it connects. The concept at the arrowhead is called the ‘target concept’ (TGT) for that relation. The concept at the other end is called the ‘source concept’ (SRC) for that relation. Names are chosen such that `<SRC> <relation name> <TGT>` is a phrase that suggests the intension(al definition) of that relation. -- a dashed line signifies that its intension is created by combination the intensions of other relations (it is a ‘shorthand’ for a path of other relations). -- an open-ended arrow is an ‘ISA’ relation, which can be read as `<SRC> ISA <TGT>`. It means that SRC is a specialization of TGT (which is a generalization of SRC). Thus, SRC must satisfy all constraints that TGT must satisfy, and has all attributes (including properties) that TGT has. -- Multiplicities use the [n..m] notation. When a multiplicity is omitted, [0..n] is intended. -- A concept that is coloured red(dish) represents a notion that is commonly used ‘in the wild’ (and hence needs not be defined here), relates to one or more concepts we need for the pattern, yet is not the same. We include such ‘red concepts’ to help readers identify and subsequently bridge gaps between commonly held thoughts and the (sometimes subtly) different meanings we need in our model. \ No newline at end of file -- GitLab From d02305b3be9816d8c467f9961e386a4a9f205698 Mon Sep 17 00:00:00 2001 From: RieksJ <rieks.joosten@tno.nl> Date: Mon, 12 Oct 2020 10:59:06 +0200 Subject: [PATCH 05/26] updates of popover texts for specific SSI-capabilities --- docs/terms/holder.md | 2 +- docs/terms/issuer.md | 2 +- docs/terms/verifier.md | 2 +- docs/terms/wallet.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/terms/holder.md b/docs/terms/holder.md index c21ec92..f4173c3 100644 --- a/docs/terms/holder.md +++ b/docs/terms/holder.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: holder stage: draft -hoverText: "Holder: a functional component that is capable of " +hoverText: "Holder (functional component): the capability to handle presentation requests from a peer-agent, produce the requested data (a presentation) according to its principal's holder-policy, and send that in response to the request." --- ## Short Description diff --git a/docs/terms/issuer.md b/docs/terms/issuer.md index 0e6ac68..33eb4d0 100644 --- a/docs/terms/issuer.md +++ b/docs/terms/issuer.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: issuer stage: draft -hoverText: "Issuer: a functional component that is capable of " +hoverText: "Issuer (functional component): the capability to construct credentials from data objects, according to the rules of its principal's issuer-policy (specifically regarding the way in which the credential is to be digitally signed), and pass it to the wallet-component of its principal allowing it to be issued." --- ## Short Description diff --git a/docs/terms/verifier.md b/docs/terms/verifier.md index 97ffe27..16b231e 100644 --- a/docs/terms/verifier.md +++ b/docs/terms/verifier.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: verifier stage: draft -hoverText: "Verifier: a functional component that is capable of " +hoverText: "Verifier (functional component): the capability to request peer-agents to present (provide) data from credentials (of a specified kind, issued by specified parties), and to verify such responses (check structure, signatures, dates), according to its principal's verifier-policy." --- ## Short Description diff --git a/docs/terms/wallet.md b/docs/terms/wallet.md index e958b53..6a8d54f 100644 --- a/docs/terms/wallet.md +++ b/docs/terms/wallet.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: wallet stage: draft -hoverText: "Wallet: a functional component that is capable of " +hoverText: "Wallet (functional component): the capability to securely store data as requested by colleague-agents, and to provide stored data to colleague-agents or peer-agents, all in compliance with the rules of the wallet-policy of its principal." --- ## Short Description -- GitLab From 1def61a3db242136db1867f56d5672f95dae212e Mon Sep 17 00:00:00 2001 From: RieksJ <rieks.joosten@tno.nl> Date: Mon, 12 Oct 2020 15:52:07 +0200 Subject: [PATCH 06/26] terminology updates --- docs/notations-and-conventions.md | 4 +++- docs/terms/action.md | 4 ++-- docs/terms/actor.md | 4 ++-- docs/terms/agent.md | 6 ++--- docs/terms/colleague.md | 2 +- docs/terms/concept-file.md | 2 +- docs/terms/corpus.md | 2 +- docs/terms/credential.md | 2 +- docs/terms/definition.md | 2 +- docs/terms/dictionary-file.md | 2 +- docs/terms/dictionary.md | 2 +- docs/terms/digital-actor.md | 2 +- docs/terms/digital-agent.md | 3 +-- docs/terms/digital-colleague.md | 3 +-- docs/terms/digital-policy.md | 2 +- docs/terms/employee.md | 18 ++++++++++++++ docs/terms/employer.md | 18 ++++++++++++++ docs/terms/glossary-file.md | 2 +- docs/terms/glossary.md | 6 ++--- docs/terms/holder-policy.md | 18 ++++++++++++++ docs/terms/holder.md | 2 +- docs/terms/issuer-policy.md | 18 ++++++++++++++ docs/terms/issuer.md | 2 +- docs/terms/jurisdiction.md | 2 +- docs/terms/knowledge.md | 4 +++- docs/terms/legal-entity.md | 2 +- docs/terms/legal-jurisdiction.md | 2 +- docs/terms/mental-model.md | 2 +- docs/terms/organization.md | 4 ++-- docs/terms/owner.md | 18 ++++---------- docs/terms/party.md | 2 +- docs/terms/pattern-file.md | 2 +- docs/terms/pattern-jurisdiction.md | 2 +- .../pattern-mandates-delegation-hiring.md | 2 +- docs/terms/pattern-mental-model.md | 2 +- docs/terms/pattern-party-actor-action.md | 20 +++++++++++----- docs/terms/pattern-terminology.md | 2 +- docs/terms/pattern.md | 2 +- docs/terms/peer-agent.md | 2 +- docs/terms/peer-party.md | 2 +- docs/terms/policy-governor.md | 22 ++++++++++++++++++ docs/terms/policy.md | 2 +- docs/terms/presentation-request.md | 2 +- docs/terms/principal.md | 4 ++-- docs/terms/risk.md | 2 +- docs/terms/scope-file.md | 2 +- docs/terms/scope.md | 2 +- docs/terms/semantics.md | 2 +- docs/terms/ssi-agent.md | 2 +- docs/terms/term-file.md | 2 +- docs/terms/term.md | 2 +- docs/terms/terminology.md | 2 +- docs/terms/transaction-result-dispatcher.md | 2 +- docs/terms/trd-policy.md | 2 +- docs/terms/tve-policy.md | 2 +- docs/terms/validated-data.md | 2 +- docs/terms/verifiable-credential.md | 2 +- docs/terms/verified-data.md | 2 +- docs/terms/verifier-policy.md | 18 ++++++++++++++ docs/terms/verifier.md | 2 +- docs/terms/wallet-policy.md | 18 ++++++++++++++ docs/terms/wallet.md | 2 +- docs/terms/zzz.md | 15 ++++++++++++ .../patterns/pattern-party-actor-action.png | Bin 34980 -> 47787 bytes 64 files changed, 228 insertions(+), 83 deletions(-) create mode 100644 docs/terms/employee.md create mode 100644 docs/terms/employer.md create mode 100644 docs/terms/holder-policy.md create mode 100644 docs/terms/issuer-policy.md create mode 100644 docs/terms/policy-governor.md create mode 100644 docs/terms/verifier-policy.md create mode 100644 docs/terms/wallet-policy.md create mode 100644 docs/terms/zzz.md diff --git a/docs/notations-and-conventions.md b/docs/notations-and-conventions.md index 0e95d0b..b9ee6f6 100644 --- a/docs/notations-and-conventions.md +++ b/docs/notations-and-conventions.md @@ -14,13 +14,15 @@ A word in mid-sentence that is capitalized is a %%term|term%% that has a %%defin :::note We are working towards deprecating this convention, as we now have better ways of referring to words that are defined in the eSSIF-Lab Corpus.. +::: ### Pattern diagram notations %%Pattern|pattern%% diagrams will be visualized in this document using a UML-like notation, as follows: - a **rectangle** represents a (named) concept. Concepts serve as entity-classes. Their (operational) extensions, i.e. the respective sets of (runtime) instances, are disjunct. -- a **solid line with a closed arrowhead** represent a (named) relation/association between the two concepts it connects. The concept at the arrowhead is called the ‘target concept’ (TGT) for that relation. The concept at the other end is called the ‘source concept’ (SRC) for that relation. Names are chosen such that `<SRC> <relation name> <TGT>` is a phrase that suggests the intension(al definition) of that relation. +- a **solid line with a closed arrowhead** represent a (named) relation/association between the two concepts it connects. We may refer to the concept at the arrowhead as the ‘target concept’ (TGT) for that relation. Similarly, the concept at the other end will be referred to as the ‘source concept’ (SRC) for that relation. Names are chosen such that `<SRC> <relation name> <TGT>` is a phrase that suggests the intension(al definition) of that relation. +- a **green name** at either end of a relation/association is what UML calls 'role'; this name may be used to refer to (an instance of) the concept at which the name is placed as it performs its/this role in this relation. - a **dashed line** signifies that its intension is created by combination the intensions of other relations (it is a ‘shorthand’ for a path of other relations). - an **open-ended arrow** is an ‘ISA’ relation, which can be read as `<SRC> ISA <TGT>`. It means that SRC is a specialization of TGT (which is a generalization of SRC). Thus, SRC must satisfy all constraints that TGT must satisfy, and has all attributes (including properties) that TGT has. - **Multiplicities** use the [n..m] notation. When a multiplicity is omitted, [0..n] is intended. diff --git a/docs/terms/action.md b/docs/terms/action.md index 9450ab8..59e1961 100644 --- a/docs/terms/action.md +++ b/docs/terms/action.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: action stage: draft -hoverText: "Action: something that is actually done/executed by a single actor (as a single operation) for some party within a specific context." +hoverText: "Action: something that is actually done/executed by a single Actor (as a single operation) for some Party within a specific context." --- ### Short Description @@ -26,4 +26,4 @@ An **Action** is something that is done by an actor, can be considered a single - OED defines Action as the fact or process of doing something, typically to achieve an aim ([OED](https://www.lexico.com/definition/action)), which is too generic for our purposes. ### Background -The %%party-action pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts. \ No newline at end of file +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 4f14e92..eed27b7 100644 --- a/docs/terms/actor.md +++ b/docs/terms/actor.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: actor stage: draft -hoverText: "Actor: Entity that can act (do things), e.g. people, machines, but not organizations." +hoverText: "Actor: Entity that can act (do things), e.g. people, machines, but not Organizations." --- ### Short Description @@ -25,4 +25,4 @@ Entity that is capable of actually executing %%actions|action%% (acting, doing t - Enterprises, governments, and other %%organizations|organization%% do not qualify. ### Background -The %%party-action pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts. +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 98cb808..f582ee6 100644 --- a/docs/terms/agent.md +++ b/docs/terms/agent.md @@ -5,11 +5,11 @@ scopeid: essifLab type: concept typeid: agent stage: draft -hoverText: "Agent: An actor that is (at that point in time) executing an action for, or on behalf of a Party (the Principal of that actor)." +hoverText: "Agent (of a Party): an Actor that is (at that point in time) executing an Action for, or on behalf of a Party (the Principal of that Actor)." --- ### Short Description -%%Actors|actor%% execute %%actions|action%% for, or on behalf of some %%party|party%% (the %%principal|principal%% of that agent), because parties are not considered to be capable of acting.[^1] Agents must act in accordance with their %%principal|principal%%, which means that for every kind of action, the principal must provide the proper guidance for their agents, e.g. in terms of policies (rules), working instructions, programs etc. We use the term %%digital agent|digital-agent%% to refer to agents that operate in a digital domain. +%%Actors|actor%% execute %%actions|action%% for, or on behalf of some %%party|party%% (the %%principal|principal%% of that agent), because parties are not considered to be capable of acting. Agents must act in accordance with their %%principal|principal%%, which means that for every kind of action, the principal must provide the proper guidance for their agents, e.g. in terms of policies (rules), working instructions, programs etc. We use the term %%digital agent|digital-agent%% to refer to agents that operate in a digital domain. ### Purpose The ability to distinguish between (non)agents is relevant in many situations, including: @@ -29,4 +29,4 @@ a property that is attributed to an %%Actor|actor%% whenever it is executing an - 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 %%party-action pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts. +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/colleague.md b/docs/terms/colleague.md index a492963..9a71d8d 100644 --- a/docs/terms/colleague.md +++ b/docs/terms/colleague.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: colleague stage: draft -hoverText: "Colleague (of an Agent): An actor that is an Agent for the same Principal." +hoverText: "Colleague (of an Agent): any other Agent that has the same Principal (i.e. Party on whose behalf they exeucte Actions)." --- :::info Editor's note diff --git a/docs/terms/concept-file.md b/docs/terms/concept-file.md index e03f5e6..4c6917d 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 that defines/specifies a Concept." --- ### Short Description diff --git a/docs/terms/corpus.md b/docs/terms/corpus.md index b89c192..44579be 100644 --- a/docs/terms/corpus.md +++ b/docs/terms/corpus.md @@ -5,7 +5,7 @@ scopeid: essifLabTerminology type: concept typeid: corpus stage: draft -hoverText: "Corpus (of Terminology): the documentation that describes the knowledge around a set of terms and concepts." +hoverText: "Corpus (of Terminology): the documentation that describes the Knowledge around a set of Terms and Concepts." --- :::info Editor's note diff --git a/docs/terms/credential.md b/docs/terms/credential.md index 53f8776..57699d7 100644 --- a/docs/terms/credential.md +++ b/docs/terms/credential.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: credential stage: draft -hoverText: "Credential: data, representing a set of statements made by one party (the author of the credential)." +hoverText: "Credential: data, representing a set of statements made by one Party (the author of the credential)." --- :::info Editor's note diff --git a/docs/terms/definition.md b/docs/terms/definition.md index a379eae..da51aa8 100644 --- a/docs/terms/definition.md +++ b/docs/terms/definition.md @@ -5,7 +5,7 @@ scopeid: essifLabTerminology type: concept typeid: definition stage: draft -hoverText: "Definition: A Definition is a text that helps parties truely understand the meaning of a term." +hoverText: "Definition: a text that helps Parties deeply/truly understand the meaning of a Term." --- ### Short Description diff --git a/docs/terms/dictionary-file.md b/docs/terms/dictionary-file.md index 068ce44..00c5c96 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 that specifies the contents of a Dictionary." --- ### Short Description diff --git a/docs/terms/dictionary.md b/docs/terms/dictionary.md index d1f8198..af3f796 100644 --- a/docs/terms/dictionary.md +++ b/docs/terms/dictionary.md @@ -5,7 +5,7 @@ scopeid: essifLabTerminology type: concept typeid: dictionary stage: draft -hoverText: "Dictionary: an alphabetically sorted list of terms and explanations, usually aimed to help people understand texts around a certain (set of) topic(s) in some context(s)." +hoverText: "Dictionary: an alphabetically sorted list of Terms and explanations, usually aimed to help people understand texts around a certain (set of) topic(s) in some context(s)." --- ### Short Description diff --git a/docs/terms/digital-actor.md b/docs/terms/digital-actor.md index 01f3a92..63d6289 100644 --- a/docs/terms/digital-actor.md +++ b/docs/terms/digital-actor.md @@ -6,7 +6,7 @@ type: term typeid: digital-actor conceptref: ":Actor" stage: draft -hoverText: "Digital Actor: an actor in the digital world (e.g. a running app, or a web-server)." +hoverText: "Digital Actor: an Actor in the digital world (e.g. a running app, or a web-server)." --- ### Purpose diff --git a/docs/terms/digital-agent.md b/docs/terms/digital-agent.md index 38c38ff..08cabd2 100644 --- a/docs/terms/digital-agent.md +++ b/docs/terms/digital-agent.md @@ -6,11 +6,10 @@ type: term typeid: digital-agent conceptref: ":Agent" stage: draft -hoverText: "Digital Agent: an actor in the digital world (e.g. a running app, or a web-server) that executes actions for a specific party (the Principal of the digital agent)." +hoverText: "Digital Agent: an Actor in the digital world (e.g. a running app, or a web-server) that is executing an Action for a specific Party (its Principal)." --- ### Purpose -<!--State the purpose(s) for which it is necessary (or at least: desirable) to define <New Term>.--> The ability to distinguish between (non)digital agents allows us to exclusively talk about software/hardware agents. See also: %%agent|agent%%. \ No newline at end of file diff --git a/docs/terms/digital-colleague.md b/docs/terms/digital-colleague.md index 80b36a1..2ddee49 100644 --- a/docs/terms/digital-colleague.md +++ b/docs/terms/digital-colleague.md @@ -6,11 +6,10 @@ type: term typeid: digital-colleague conceptref: ":Colleague" stage: draft -hoverText: "Digital Colleague (of an Agent): a digital actor that is an agent of the same principal." +hoverText: "Digital Colleague (of an Agent): any (other) Digital Agent that has the same Principal (i.e. Party on whose behalf they exeucte Actions)." --- ### Purpose -<!--State the purpose(s) for which it is necessary (or at least: desirable) to define <New Term>.--> The ability to distinguish between (non)digital colleagues allows us to reason and communicate about the set of %%digital actors|digital-actor%% that are %%agents|agent%% for a single **principal|principal%%. See also: %%colleague|colleague%%. diff --git a/docs/terms/digital-policy.md b/docs/terms/digital-policy.md index 9aedb1c..8bbc069 100644 --- a/docs/terms/digital-policy.md +++ b/docs/terms/digital-policy.md @@ -6,7 +6,7 @@ type: concept typeid: digital-policy conceptref: ":Policy" stage: draft -hoverText: "Digital Policy: a machine-readable document that contains rules, working instructions or other guidance for digital agents so as to enable them to execute actions on behalf of the author of that policy." +hoverText: "Digital Policy: a machine-readable Policy (i.e. document that contains rules, working instructions or other guidance for Agents that can interpret such documents, so as to enable them to execute Actions on behalf of the Policy's author)." --- ### Short Description diff --git a/docs/terms/employee.md b/docs/terms/employee.md new file mode 100644 index 0000000..f476366 --- /dev/null +++ b/docs/terms/employee.md @@ -0,0 +1,18 @@ +--- +id: employee +title: "Employee" +scopeid: essifLab +type: concept +typeid: employee +stage: draft +hoverText: "Employee (of a Party): an Actor for whom/which it is realistic that it might execute Actions on behalf of that Party." +--- + +:::info Editor's note +TNO to provide the content of this file. +::: + +### 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 diff --git a/docs/terms/employer.md b/docs/terms/employer.md new file mode 100644 index 0000000..1f40d06 --- /dev/null +++ b/docs/terms/employer.md @@ -0,0 +1,18 @@ +--- +id: employer +title: "Employer" +scopeid: essifLab +type: concept +typeid: employer +stage: draft +hoverText: "Employer (of an Actor): a Party on whose behalf this Actor might execute Ations." +--- + +:::info Editor's note +TNO to provide the content of this file. +::: + +### 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 diff --git a/docs/terms/glossary-file.md b/docs/terms/glossary-file.md index 18c4c32..3fde8a9 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 that defines/specifies a Glossary." --- ### Short Description diff --git a/docs/terms/glossary.md b/docs/terms/glossary.md index c86f214..21f11dd 100644 --- a/docs/terms/glossary.md +++ b/docs/terms/glossary.md @@ -5,12 +5,12 @@ scopeid: essifLabTerminology type: concept typeid: glossary stage: draft -hoverText: "Glossary: an alphabetically sorted list of terms explanations, usually aimed to help people understand texts around a certain (set of) topic(s) in some context(s)." +hoverText: "Glossary: an alphabetically sorted list of Terms with explanations, usually aimed to help people understand texts around a certain (set of) topic(s) in some context(s)." --- ### 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 and explanations, usually aimed to help people understand texts around a certain (set of) topic(s) in some context(s). However, 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. +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 some context(s). However, 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. ### 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?--> @@ -18,7 +18,7 @@ A glossary may serve various purposes, the most important one of which would be ### 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.--> -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. +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.--> diff --git a/docs/terms/holder-policy.md b/docs/terms/holder-policy.md new file mode 100644 index 0000000..df02f7c --- /dev/null +++ b/docs/terms/holder-policy.md @@ -0,0 +1,18 @@ +--- +id: holder-policy +title: "Holder Policy" +scopeid: essifLab +type: concept +typeid: holder-policy +stage: draft +hoverText: "Holder Policy: a Digital Policy that enables an operational Holder component to function according to the rules of its Policy Governor." +--- + +:::info Editor's note +TNO to provide the content of this file. +::: + +### Related Concepts +- %%Digital Policy|digital-policy%% +- %%Policy Governor|policy-governor%% +- %%Holder|holder%% diff --git a/docs/terms/holder.md b/docs/terms/holder.md index f4173c3..529ab71 100644 --- a/docs/terms/holder.md +++ b/docs/terms/holder.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: holder stage: draft -hoverText: "Holder (functional component): the capability to handle presentation requests from a peer-agent, produce the requested data (a presentation) according to its principal's holder-policy, and send that in response to the request." +hoverText: "Holder (functional component): the capability to handle presentation requests from a Peer Agent, produce the requested data (a presentation) according to its Principal's holder-policy, and send that in response to the request." --- ## Short Description diff --git a/docs/terms/issuer-policy.md b/docs/terms/issuer-policy.md new file mode 100644 index 0000000..620d1f3 --- /dev/null +++ b/docs/terms/issuer-policy.md @@ -0,0 +1,18 @@ +--- +id: issuer-policy +title: "Isuer Policy" +scopeid: essifLab +type: concept +typeid: issuer-policy +stage: draft +hoverText: "Issuer Policy: a Digital Policy that enables an operational Issuer component to function according to the rules of its Policy Governor." +--- + +:::info Editor's note +TNO to provide the content of this file. +::: + +### Related Concepts +- %%Digital Policy|digital-policy%% +- %%Policy Governor|policy-governor%% +- %%Issuer|issuer%% diff --git a/docs/terms/issuer.md b/docs/terms/issuer.md index 33eb4d0..366f7f2 100644 --- a/docs/terms/issuer.md +++ b/docs/terms/issuer.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: issuer stage: draft -hoverText: "Issuer (functional component): the capability to construct credentials from data objects, according to the rules of its principal's issuer-policy (specifically regarding the way in which the credential is to be digitally signed), and pass it to the wallet-component of its principal allowing it to be issued." +hoverText: "Issuer (functional component): the capability to construct Credentials from data objects, according to the rules of its Principal's issuer-policy (specifically regarding the way in which the Credential is to be digitally signed), and pass it to the Wallet-component of its Principal allowing it to be issued." --- ## Short Description diff --git a/docs/terms/jurisdiction.md b/docs/terms/jurisdiction.md index 608125e..24cf498 100644 --- a/docs/terms/jurisdiction.md +++ b/docs/terms/jurisdiction.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: jurisdiction stage: draft -hoverText: "Jurisdiction: a legal system (legislation, enforcement thereof, and conflict resolution) that is operated by a party in a certain scope." +hoverText: "Jurisdiction: a Legal System (legislation, enforcement thereof, and conflict resolution) that is operated by a Party in a certain Scope." --- ### Short Description diff --git a/docs/terms/knowledge.md b/docs/terms/knowledge.md index ec8ac66..86a15ef 100644 --- a/docs/terms/knowledge.md +++ b/docs/terms/knowledge.md @@ -5,12 +5,14 @@ scopeid: essifLab type: concept typeid: knowledge stage: draft -hoverText: "Knowledge: The (intangible) sum of what is known by a party, as well as the familiarity, awareness or understanding of someone or something by that party." +hoverText: "Knowledge: The (intangible) sum of what is known by a specific Party, as well as the familiarity, awareness or understanding of someone or something by that Party." --- ### Short Description **Knowledge** is the (intangible) sum of what is known, the familiarity, awareness or understanding of someone or something ([WikiPedia](https://en.wikipedia.org/wiki/Knowledge)). It includes facts ([propositional knowledge](https://en.wikipedia.org/wiki/Propositional_knowledge)), skills ([procedural knowledge](https://en.wikipedia.org/wiki/Procedural_knowledge)), or objects ([acquaintance knowledge](https://en.wikipedia.org/wiki/Knowledge_by_acquaintance)). Knowledge can be acquired in many different ways and from many different sources, including but not limited to experience, reason, memory, testimony, scientific inquiry, education, and practice. +We limit the scope of a Knowledge to a %%party|party%% so as to allow for the existence of multiple such Knowledges, where each of them is internally consistent, yet may be inconsistent with other Knowledges. + ### Purpose We need a term to refer to the (intangible) sum of what is known, the familiarity, awareness or understanding of someone or something of a %%party|party%%, because this is what allows the party to reason, and make decisions. When a party can successfully share (parts of) its knowledge, i.e. communicate it such that when another party interpret it, the intension is preserved, mutual understanding is achieved, which is prerequisite for doing business transactions and/or collaborating. diff --git a/docs/terms/legal-entity.md b/docs/terms/legal-entity.md index afcc94d..f08680c 100644 --- a/docs/terms/legal-entity.md +++ b/docs/terms/legal-entity.md @@ -5,7 +5,7 @@ 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: an Entity that is known by and recognized to exist in a Jurisdiction." --- ### Short Description diff --git a/docs/terms/legal-jurisdiction.md b/docs/terms/legal-jurisdiction.md index 3c3939f..95beb53 100644 --- a/docs/terms/legal-jurisdiction.md +++ b/docs/terms/legal-jurisdiction.md @@ -6,7 +6,7 @@ type: term typeid: legal-jurisdiction conceptref: essifLab:jurisdiction stage: draft -hoverText: "Legal Jurisdiction: a jurisdiction that is operated by a governmental body." +hoverText: "Legal Jurisdiction: a Jurisdiction that is operated by a governmental body." --- ### Purpose diff --git a/docs/terms/mental-model.md b/docs/terms/mental-model.md index ac790ea..2829304 100644 --- a/docs/terms/mental-model.md +++ b/docs/terms/mental-model.md @@ -6,7 +6,7 @@ type: term typeid: mental-model conceptref: essifLab:pattern stage: draft -hoverText: "Mental Model: a casual and formal description (pattern) of a set of concepts, relations between them, and constraints, that provide a specific 'viewpoint', or 'way of thinking' about a certain topic." +hoverText: "Mental Model: a casual and formal description (Pattern) of a set of Concepts, relations between them, and constraints, that provide a specific 'viewpoint', or 'way of thinking' about a certain topic." --- :::info Editor's note diff --git a/docs/terms/organization.md b/docs/terms/organization.md index 6d34c84..989a86b 100644 --- a/docs/terms/organization.md +++ b/docs/terms/organization.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: organization stage: draft -hoverText: "Organization: a group of people that work to realize one or more objectives." +hoverText: "Organization: a group of people that work to realize one or more Objectives." --- ### Short Description @@ -14,7 +14,7 @@ An **Organization** is a group of people that work to realize one or more object ### 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 purpose of documenting this term is to provide additional clarity w.r.t. definitions given in english dictionaries. Also, we need this notion as it is used in the eSSIF-Lab %%party-action pattern|pattern-party-actor-action%%. +The purpose of documenting this term is to provide additional clarity w.r.t. definitions given in english dictionaries. Also, we need this notion as it is used in the eSSIF-Lab %%Parties, Actors and Actions pattern|pattern-party-actor-action%%. ### Criteria A (non-empty) group of people that work to realize a (non-empty) set of objectives. diff --git a/docs/terms/owner.md b/docs/terms/owner.md index 6c3f120..edb9570 100644 --- a/docs/terms/owner.md +++ b/docs/terms/owner.md @@ -5,19 +5,19 @@ scopeid: essifLab type: concept typeid: owner stage: draft -hoverText: "Owner: a Party that has the legal or rightful title to control something." +hoverText: "Owner (of an Entity): the role that a Party performs when it is exercizing its legal or rightful title to control that Entity." --- ### Short Description <!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.--> -The property of a %%Party|party%% that has the legal or rightful title to control something. We interpret 'legal' and 'rightful' as terms that apply to _any_ %%Jurisdiction|jurisdiction%% (that is: not just %%legal/national jurisdictions|legal-jurisdiction%%, but also those of other %%organizations|organization%% (%%parties|party%%). +An **Owner** is a role that a %%Party|party%% performs when it is exercizing its legal or rightful title to control some %%entity|entity%%. We interpret 'legal' and 'rightful' as terms that apply to _any_ %%Jurisdiction|jurisdiction%% (that is: not just %%legal/national jurisdictions|legal-jurisdiction%%, but also those of other %%organizations|organization%% (%%parties|party%%). ### 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?--> ### 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 %%Party|party%% is said to be the **owner** of some %%entity|entity%% if and only if the party and the entity are %%legal entities|legal-entity%% in some %%jurisdiction|jurisdiction%%, and within the scope of that jurisdiction the party has the legal or rightful title to control the entity. +A %%Party|party%% is said to be the **owner** of some %%entity|entity%% if and only if the party and the entity are %%legal entities|legal-entity%% in some %%jurisdiction|jurisdiction%%, within the scope of which that party has the legal or rightful title to control the entity. ### 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.--> @@ -38,14 +38,4 @@ A %%Party|party%% is said to be the **owner** of some %%entity|entity%% if and o - shows the relevance of having `<New 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.--> - -<!-- ---- -### Footnotes - -[//]: # This (optional) section contains any footnotes that may have been specified in the text above. - -[^1]: the text for footnote [^1] goes here. - ---> +<!--This (optional) section is the place to put anything for which there is no other good place to put it.--> \ No newline at end of file diff --git a/docs/terms/party.md b/docs/terms/party.md index f43aa78..3929947 100644 --- a/docs/terms/party.md +++ b/docs/terms/party.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: party stage: draft -hoverText: "Party: Entity that has knowledge about what exists, ways to reason with that knowledge, and ways for making decisions in a Self-Sovereign fashion." +hoverText: "Party: Entity that has Knowledge about what exists, ways to reason with that knowledge, and ways for making decisions in a Self-Sovereign fashion." --- ### Short Description diff --git a/docs/terms/pattern-file.md b/docs/terms/pattern-file.md index 007cda6..233dd29 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 that defines/specifies a Pattern." --- ### Short Description diff --git a/docs/terms/pattern-jurisdiction.md b/docs/terms/pattern-jurisdiction.md index d71ba28..1f381c3 100644 --- a/docs/terms/pattern-jurisdiction.md +++ b/docs/terms/pattern-jurisdiction.md @@ -5,7 +5,7 @@ scopeid: essifLab type: pattern typeid: jurisdiction stage: draft -hoverText: "The Jurisdictions pattern captures the concepts and relations that explain what a generic jurisdiction consists of, and relates it to parties and legal entities." +hoverText: "The Jurisdictions pattern captures the Concepts and relations that explain what a generic Jurisdiction consists of, and relates it to Parties and Legal Entities." --- import useBaseUrl from '@docusaurus/useBaseUrl'; diff --git a/docs/terms/pattern-mandates-delegation-hiring.md b/docs/terms/pattern-mandates-delegation-hiring.md index af00d4b..a8929e1 100644 --- a/docs/terms/pattern-mandates-delegation-hiring.md +++ b/docs/terms/pattern-mandates-delegation-hiring.md @@ -5,7 +5,7 @@ scopeid: essifLab type: pattern typeid: mandates-delegation-hiring stage: draft -hoverText: "The Mandates, Delegation and Hiring pattern (which remains to be documented) captures the ideas behind mandating, delegating, hiring and their relations. This is a work-in-progress." +hoverText: "The Mandates, Delegation and Hiring pattern (which remains to be documented) captures the ideas behind Mandating, Delegating, Hiring and their relations. This is a work-in-progress." --- import useBaseUrl from '@docusaurus/useBaseUrl'; diff --git a/docs/terms/pattern-mental-model.md b/docs/terms/pattern-mental-model.md index 4fecd62..a7777af 100644 --- a/docs/terms/pattern-mental-model.md +++ b/docs/terms/pattern-mental-model.md @@ -5,7 +5,7 @@ scopeid: essifLabTerminology type: pattern typeid: mental-model stage: draft -hoverText: "The Mental Mmodels pattern captures the foundational concepts and relations that we need for creating, maintaining and using (decentralized) vocabularies (terminologies) that groups of people can use for the specific purposes they pursue." +hoverText: "The Mental Mmodels pattern captures the foundational Concepts and relations that we need for creating, maintaining and using (decentralized) Vocabularies (Terminologies) that groups of people can use for the specific purposes they pursue." --- ### Purpose diff --git a/docs/terms/pattern-party-actor-action.md b/docs/terms/pattern-party-actor-action.md index de7fa6f..e37c29d 100644 --- a/docs/terms/pattern-party-actor-action.md +++ b/docs/terms/pattern-party-actor-action.md @@ -23,22 +23,30 @@ One may readily observe that in some way, people (humans) and %%organizations|or The main characteristic that people and organizations share, is everyone of them maintains (a body of) %%knowledge|knowledge%%. They acquire knowledge by observing the world around them, processing such observations, storing all that (using specific (tangible) representations of these (intangible) things, and sharing/disseminating it with others (here again, (tangible) representations must be used). We introduce the term %%party|party%% to refer to %%entities|entity%% that share this characteristic of maintaining (a body of) knowledge. Both people and organizations qualify as such. +#### Coherence between Parties and Actors + One may also readily observe that in other ways, people and organizations differ. For example, people eat and drink, whereas organizations do not. People can sit behind a computer keyboard, type texts, hit the `Enter` button, e.g. to send an email. Organizations cannot do that. In short: people can act (do things), whereas organizations cannot. The characteristic that sets people and organizations apart is the ability to act. -We will use the term %%actor|actor%% to refer to %%entities|entity%% that are capable of acting (doing things). People will qualify, whereas organizations do not. +We will use the term %%actor|actor%% to refer to %%entities|entity%% that are capable of acting (doing things); people will qualify, whereas organizations do not. + +Notwithstanding that organizations cannot act, it is quite common to hear statements that seem to imply that they can. If ACME is an organization and someone says: "I just received mail from ACME", this cannot be literally true as organizations cannot send messages. It is either a person or a computer system that has actually sent it. Statements such as these must therefor be interpreted in a figurative way, as a 'shorthand' for 'I just received mail that was sent by some %%actor|actor%% that `was acting on behalf of` ACME'. + +When an %%actor|actor%% is `acting on behalf of` some %%party|party%%, it is executing a single %%action|action%%. This constraint is necessary as we must allow actors to multi-taks, i.e. execute different actions more or less simultaneously, where it might execute each such action on behalf of a different party. + +In this relation `is acting on behalf of`, actor plays the role of %%agent|agent%% (of that party), and the party performs the role of %%principal|principal%% (of that actor). -Notwithstanding that organizations cannot act, it is quite common to hear statements that seem to imply that they can. If ACME is an organization and someone says: "I just received mail from ACME", this cannot be literally true as organizations cannot send messages. It is either a person or a computer system that has actually sent it. Statements such as these must therefor be interpreted in a figurative way, as a 'shorthand' for 'I just received mail that was sent by some %%actor|actor%% that was `working for` ACME', where `working for` may have various meanings: +Thus, being an agent implies that an action is being executed on behalf of some party. However, we also like to talk about actors for which it is realistic that they might do something for some party. It seems obvious that an actor, for which the party has the %%legal or rightful title to control|owner%% it, would qualify as such. But a party may also get actors that it doesn't %%own|owner%% to `work for` it. may have various meanings: -1. ACME may be the %%owner|owner% of that actor. This would be the case if the mail was sent by one of ACME's running business applications. -2. ACME may employ, or otherwise hire that actor. This would be the case if one of its employees sent the mail, or a business application that is owned by another party sent the mail on behalf of ACME. How this works is the subject of the pattern %%Mandates, Delegation and Hiring|pattern-mandates-delegation-hiring%%. +1. ACME may be the %%owner|owner% of that actor. This would be the case e.g.if the mail was sent by one of ACME's running business applications. +2. ACME may employ, or otherwise hire that actor. This would be the case e.g. if one of its %%employees|employee%% sent the mail, or a business application that is owned by another party sent the mail on behalf of ACME. How this works is the subject of the pattern %%Mandates, Delegation and Hiring|pattern-mandates-delegation-hiring%%. Note that owning, employing (or hiring) an actor is a condition that usually exists for a considerable time, at least in the order of days (weeks, months). However, some actors (e.g. humans) are capable of multi-tasking, i.e. they can do several actions (pretty much) simultaneously. For example, a person that is working for some organization may make a personal phone call, or send a personal email during working hours. This shows that the 'working for` (some party) condition can mean two things: either it is the status/condition -- that allows/enables the actor to act on behalf of some party. We refer to that as `working for`, e.g. `actor A works for party P`. +- that allows/enables the actor to act on behalf of some party. We refer to that as `working for`, e.g. `actor A works for party P`. In this relation `works for`, the party performs the role of %%employer|employer%% (of that actor), and the actor plays the role of %%employee|employee%% of that party. - the status/condition that an actor is executing a specific %%action|action%% on behalf of that party at some given point in time. We refer to that condition as `is acting on behalf of` or `is executing an action on behalf of`. We expect that whenever an actor is acting on behalf of some party, it must also work for that party. %%Actions|action%% can usually be executed in different ways. For example, sending a mail on behalf of some organization may require that the mail template and logo of that organization be used. Or accepting an order usually requires a check to see the order is 'clean', i.e. can be processed by others in the organization. What a 'clean-order check' comprises is to be determined by the organization. -So in general, the execution of an action is (primarily) guided by the policies, working instructions etc. (i.e.: the %%knowledge|knowledge%%) of the party on whose behalf that action is executed. The actor can still use other, additional knowledge (of other parties) that it has access to, but the primary guidance that it *must* use originates from the party on whose behalf it executes the action. In the previous example, a person that would send mail on behalf of the organization would use its official paper, format the mail according to the organization's templates, comply with any other applicable requirements, and then use the knowledge of itself (as a person is a party) to provide the content, phrase sentences, etc. +In general, the execution of an action is (primarily) guided by the policies, working instructions etc. (i.e.: the %%knowledge|knowledge%%) of the party on whose behalf that action is executed. The actor can still use other, additional knowledge (of other parties) that it has access to, but the primary guidance that it *must* use originates from the party on whose behalf it executes the action. In the previous example, a person that would send mail on behalf of the organization would use its official paper, format the mail according to the organization's templates, comply with any other applicable requirements, and then use the knowledge of itself (as a person is a party) to provide the content, phrase sentences, etc. Finally, we note that a party `owns` %%objectives|objective%% that it seeks to fulfill or realize, and these are part of its knowledge. The relevance of this is that a large number of the decisions that parties make have to do with their managing their %%risks|risk%% (which [ISO 27000](https://www.iso.org/obp/ui#iso:std:iso-iec:27000:ed-4:v1:en)) defines as 'effect of uncertainty on objectives'), each of which is related to one or more of its objectives. diff --git a/docs/terms/pattern-terminology.md b/docs/terms/pattern-terminology.md index 83a66ae..2b3d035 100644 --- a/docs/terms/pattern-terminology.md +++ b/docs/terms/pattern-terminology.md @@ -5,7 +5,7 @@ scopeid: essifLab type: pattern typeid: terminology stage: draft -hoverText: "The eSSIF-Lab Terminology Pattern describes the relations between terminology terms such as 'concept', 'term', 'pattern', 'mental model', 'glossary' etc." +hoverText: "The eSSIF-Lab Terminology Pattern describes the relations between Terminology Terms such as 'Concept', 'Term', 'Pattern', 'Mental Model', 'Glossary' etc." --- import useBaseUrl from '@docusaurus/useBaseUrl'; diff --git a/docs/terms/pattern.md b/docs/terms/pattern.md index 5e55728..7f43075 100644 --- a/docs/terms/pattern.md +++ b/docs/terms/pattern.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: pattern stage: draft -hoverText: "Pattern: A limited set of concepts (ideas), relations between them, and constraints, such that together they form a coherent and consistent whole." +hoverText: "Pattern: A limited set of Concepts (ideas), relations between them, and constraints, such that together they form a coherent and consistent whole." --- ### Short Description diff --git a/docs/terms/peer-agent.md b/docs/terms/peer-agent.md index 8bb646b..ed1d359 100644 --- a/docs/terms/peer-agent.md +++ b/docs/terms/peer-agent.md @@ -6,7 +6,7 @@ type: term typeid: peer-agent conceptref: essifLab:Agent stage: draft -hoverText: "Peer Agent (of another Agent): the Agent with whom this other Agent is communicating in the context of a transaction." +hoverText: "Peer Agent (of another Agent): the Agent with whom this other Agent is communicating in the context of a Business Transaction." --- ### Purpose diff --git a/docs/terms/peer-party.md b/docs/terms/peer-party.md index 3623ca5..2680877 100644 --- a/docs/terms/peer-party.md +++ b/docs/terms/peer-party.md @@ -6,7 +6,7 @@ type: term typeid: peer-party conceptref: essifLab:party stage: draft -hoverText: "Peer Party (of some other Party): the Party that is a participant in a transaction of that other Party." +hoverText: "Peer Party (of some other Party): the Party that is a participant in a Business Transaction of that other Party." --- ### Purpose diff --git a/docs/terms/policy-governor.md b/docs/terms/policy-governor.md new file mode 100644 index 0000000..7bef488 --- /dev/null +++ b/docs/terms/policy-governor.md @@ -0,0 +1,22 @@ +--- +id: policy-governor +title: "Policy Governor" +scopeid: essifLab +type: concept +typeid: policy-governor +stage: draft +hoverText: "Policy Governor (of a Policy): the Party that is the Owner of the Policy and hence decides what goes in it and what not." +--- + +:::info Editor's note +TNO to provide the content of this file. +::: + +### Related Concepts +- %%Digital Policy|digital-policy%% +- %%TRD Policy|trd-policy%% +- %%TVE Policy|tve-policy%% +- %%Verifier Policy|verifier-policy%% +- %%Issuer Policy|issuer-policy%% +- %%Holder Policy|holder-policy%% +- %%Wallet Policy|wallet-policy%% diff --git a/docs/terms/policy.md b/docs/terms/policy.md index 162d089..2db8ad9 100644 --- a/docs/terms/policy.md +++ b/docs/terms/policy.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: policy stage: draft -hoverText: "Policy: a (set of) rules, working instructions or other guidance for the execution of one or more kinds of actions, that agents (a) have access to, (b) can interpret as intended by their principal (i.e. policy owner) and (c) must use when executing such actions." +hoverText: "Policy: a (set of) rules, working instructions or other guidance for the execution of one or more kinds of Actions, that Agents (a) have access to, (b) can interpret as intended by their Principal (i.e. policy Owner) and (c) must use when executing such Actions." --- ### Short Description diff --git a/docs/terms/presentation-request.md b/docs/terms/presentation-request.md index 954e741..82996c9 100644 --- a/docs/terms/presentation-request.md +++ b/docs/terms/presentation-request.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: presentation-request stage: draft -hoverText: "Presentation Request: a (signed) digital message that a verifier component sends to a holder component asking for data from one or more verifiable credentials." +hoverText: "Presentation Request: a (signed) digital message that a Verifier component sends to a Holder component asking for data from one or more Verifiable Credentials." --- :::info Editor's note diff --git a/docs/terms/principal.md b/docs/terms/principal.md index af8cc76..01b1b0a 100644 --- a/docs/terms/principal.md +++ b/docs/terms/principal.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: principal stage: draft -hoverText: "Principal: A Party for whom, or on behalf of whom, an Actor works (the latter is then an Agent for that Party)." +hoverText: "Principal (of an Actor): A Party for whom, or on behalf of whom, the Actor works (the latter is then an Agent for that Party)." --- ### Short Description @@ -24,4 +24,4 @@ The **principal** (of an %%actor|actor%%) is the %%party|party%% for whom the ac - When a person is doing things for his employer, the latter is his Principal. ### Background -The %%party-action pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts. +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/risk.md b/docs/terms/risk.md index aac3995..58114f2 100644 --- a/docs/terms/risk.md +++ b/docs/terms/risk.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: risk stage: draft -hoverText: "Risk: the deviation of the expected realization (e.g. results) of an objective of a party." +hoverText: "Risk: the deviation of the expected realization (e.g. results) of an Objective of a Party." --- :::info Editor's note diff --git a/docs/terms/scope-file.md b/docs/terms/scope-file.md index a9e7c69..1d890fe 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 that defines/specifies a Scope." --- ### Short Description diff --git a/docs/terms/scope.md b/docs/terms/scope.md index 2d8c564..3a14770 100644 --- a/docs/terms/scope.md +++ b/docs/terms/scope.md @@ -5,7 +5,7 @@ scopeid: eSSIFLab type: concept typeid: scope stage: draft -hoverText: "Scope: the extent of the area or subject matter (which we use to define patterns, concepts, terms and glossaries in)." +hoverText: "Scope: the extent of the area or subject matter (which we use to define Patterns, Concepts, Terms and Glossaries in)." --- ### Short Description diff --git a/docs/terms/semantics.md b/docs/terms/semantics.md index 507015f..5a4e1b0 100644 --- a/docs/terms/semantics.md +++ b/docs/terms/semantics.md @@ -5,7 +5,7 @@ scopeid: essifLabTerminology type: concept typeid: semantics stage: draft -hoverText: "Semantics: a mapping between the (tangible/textual) terms and (intangible) ideas/concepts - their meaning." +hoverText: "Semantics: a mapping between the (tangible/textual) Terms and (intangible) ideas/Concepts - their meaning." --- ### Short Description diff --git a/docs/terms/ssi-agent.md b/docs/terms/ssi-agent.md index 83597c4..a4e4fbd 100644 --- a/docs/terms/ssi-agent.md +++ b/docs/terms/ssi-agent.md @@ -6,7 +6,7 @@ type: term typeid: ssi-agent conceptref: essifLab:Agent stage: draft -hoverText: "SSI-Agent: a digital agent that provides one or more of the SSI functionalities (issuer, holder, verifier, wallet) to its principal." +hoverText: "SSI-Agent: a Digital Agent that provides one or more of the SSI functionalities (Issuer, Holder, Verifier, Wallet) to its Principal." --- ### Short Description diff --git a/docs/terms/term-file.md b/docs/terms/term-file.md index 1877336..5bcee45 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 that defines/specifies a Term." --- ### Short Description diff --git a/docs/terms/term.md b/docs/terms/term.md index e262493..68027d9 100644 --- a/docs/terms/term.md +++ b/docs/terms/term.md @@ -5,7 +5,7 @@ scopeid: essifLabTerminology type: concept typeid: term stage: draft -hoverText: "Term: a word or phrase that is used in at least one scope/context to refer to a specific concept." +hoverText: "Term: a word or phrase that is used in at least one Scope/context to refer to a specific Concept." --- ### Short Description diff --git a/docs/terms/terminology.md b/docs/terms/terminology.md index 74f5d0f..a851ad3 100644 --- a/docs/terms/terminology.md +++ b/docs/terms/terminology.md @@ -5,7 +5,7 @@ scopeid: essifLabTerminology type: concept typeid: terminology stage: draft -hoverText: "Terminology: the set of terms that are used for communicating about a some specific topic(s)." +hoverText: "Terminology: the set of Terms that are used for communicating about a some specific topic(s)." --- ### Short Description diff --git a/docs/terms/transaction-result-dispatcher.md b/docs/terms/transaction-result-dispatcher.md index d112d36..516be7d 100644 --- a/docs/terms/transaction-result-dispatcher.md +++ b/docs/terms/transaction-result-dispatcher.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: transaction-result-dispatcher stage: draft -hoverText: "Transaction Result Dispatcher (TRD): a functional component 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." +hoverText: "Transaction Result Dispatcher (TRD): a functional component that is capable of stating (various, sometimes intermediary) results of Business Transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other Parties." --- ## Short Description diff --git a/docs/terms/trd-policy.md b/docs/terms/trd-policy.md index 1a2818c..b51312e 100644 --- a/docs/terms/trd-policy.md +++ b/docs/terms/trd-policy.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: trd-policy stage: draft -hoverText: "TRD Policy: a machine readable policy that enables an operational TRD component to function according to the rules of the party on whose behalf this component acts." +hoverText: "TRD Policy: a Digital Policy that enables an operational TRD component to function according to the rules of its Policy Governor." --- ## Short Description diff --git a/docs/terms/tve-policy.md b/docs/terms/tve-policy.md index 1dfc1a4..ac772f5 100644 --- a/docs/terms/tve-policy.md +++ b/docs/terms/tve-policy.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: tve-policy stage: draft -hoverText: "TVE Policy: a machine readable policy that enables an operational TVE component to function according to the rules of its principal." +hoverText: "TVE Policy: a Digital Policy that enables an operational TVE component to function according to the rules of its Policy Governor." --- ## Short Description diff --git a/docs/terms/validated-data.md b/docs/terms/validated-data.md index 596624e..8b3c745 100644 --- a/docs/terms/validated-data.md +++ b/docs/terms/validated-data.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: validated-data stage: draft -hoverText: "Validated Data: data of which some party has established that it is valid, and hence can be used, for some specific purpose(s)." +hoverText: "Validated Data: data of which some Party has established that it is valid, and hence can be used, for some specific purpose(s)." --- :::info Editor's note diff --git a/docs/terms/verifiable-credential.md b/docs/terms/verifiable-credential.md index d29dc59..e134c94 100644 --- a/docs/terms/verifiable-credential.md +++ b/docs/terms/verifiable-credential.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: verifiable-credential stage: draft -hoverText: "Verifiable Credential: credential that comes with assurances regarding its provenance (the party that issued it) and its integrity (the property that the credential is the same as it was when issued)." +hoverText: "Verifiable Credential: Credential that comes with assurances regarding its provenance (the Party that issued it) and its integrity (the property that the Credential data has not been tampered with in transit, i.e. is the same as when issued)." --- :::info Editor's note diff --git a/docs/terms/verified-data.md b/docs/terms/verified-data.md index 16e72be..c228fb5 100644 --- a/docs/terms/verified-data.md +++ b/docs/terms/verified-data.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: verified-data stage: draft -hoverText: "Verified Data: data of which some party has established that it is a truthful representation of what its author intended it to mean when the data was created." +hoverText: "Verified Data: data of which some Party has established that it is a truthful representation of what its author intended it to mean when the data was created." --- :::info Editor's note diff --git a/docs/terms/verifier-policy.md b/docs/terms/verifier-policy.md new file mode 100644 index 0000000..df8eba6 --- /dev/null +++ b/docs/terms/verifier-policy.md @@ -0,0 +1,18 @@ +--- +id: verifier-policy +title: "Verifier Policy" +scopeid: essifLab +type: concept +typeid: verifier-policy +stage: draft +hoverText: "Verifier Policy: a Digital Policy that enables an operational Verifier component to function according to the rules of its Policy Governor." +--- + +:::info Editor's note +TNO to provide the content of this file. +::: + +### Related Concepts +- %%Digital Policy|digital-policy%% +- %%Policy Governor|policy-governor%% +- %%Verifier|verifier%% diff --git a/docs/terms/verifier.md b/docs/terms/verifier.md index 16b231e..8ed186c 100644 --- a/docs/terms/verifier.md +++ b/docs/terms/verifier.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: verifier stage: draft -hoverText: "Verifier (functional component): the capability to request peer-agents to present (provide) data from credentials (of a specified kind, issued by specified parties), and to verify such responses (check structure, signatures, dates), according to its principal's verifier-policy." +hoverText: "Verifier (functional component): the capability to request Peer Agents to present (provide) data from credentials (of a specified kind, issued by specified Parties), and to verify such responses (check structure, signatures, dates), according to its Principal's Verifier Policy." --- ## Short Description diff --git a/docs/terms/wallet-policy.md b/docs/terms/wallet-policy.md new file mode 100644 index 0000000..5be069f --- /dev/null +++ b/docs/terms/wallet-policy.md @@ -0,0 +1,18 @@ +--- +id: wallet-policy +title: "Wallet Policy" +scopeid: essifLab +type: concept +typeid: wallet-policy +stage: draft +hoverText: "Wallet Policy: a Digital Policy that enables an operational Wallet component to function according to the rules of its Policy Governor." +--- + +:::info Editor's note +TNO to provide the content of this file. +::: + +### Related Concepts +- %%Digital Policy|digital-policy%% +- %%Policy Governor|policy-governor%% +- %%Wallet|wallet%% diff --git a/docs/terms/wallet.md b/docs/terms/wallet.md index 6a8d54f..b1d16a2 100644 --- a/docs/terms/wallet.md +++ b/docs/terms/wallet.md @@ -5,7 +5,7 @@ scopeid: essifLab type: concept typeid: wallet stage: draft -hoverText: "Wallet (functional component): the capability to securely store data as requested by colleague-agents, and to provide stored data to colleague-agents or peer-agents, all in compliance with the rules of the wallet-policy of its principal." +hoverText: "Wallet (functional component): the capability to securely store data as requested by Colleague Agents, and to provide stored data to Colleague Agents or Peer Agents, all in compliance with the rules of its Principal's Wallet Policy." --- ## Short Description diff --git a/docs/terms/zzz.md b/docs/terms/zzz.md new file mode 100644 index 0000000..8b81bb3 --- /dev/null +++ b/docs/terms/zzz.md @@ -0,0 +1,15 @@ +--- +id: zzz +title: "zzz" +scopeid: essifLab +type: concept +typeid: zzz +stage: draft +hoverText: "zzz: popuptext remains to be done" +--- + +:::info Editor's note +TNO to provide the content of this file. +::: + +### Related Concepts diff --git a/static/images/patterns/pattern-party-actor-action.png b/static/images/patterns/pattern-party-actor-action.png index bddd35c95d21fc90c9c05cad85d82efd4f802ebe..ba5974e564e9576577f241d49db3921489babb10 100644 GIT binary patch literal 47787 zcmd?RbyQSe^f(HFAW|YFiVTe?N=n1f-618QG>UY`(A^=a4BZWafPe_n(v5(0_fP`^ z?+(_-@As|sd+*P;9&35MbI(3|@3ZUdy>A37DM;epyn7P`1qD}HN=yX>1swwXyK@5# zxT4s$Z2|m;YNsM8f>P2;z6Sh2Hx-r_MnNf$#6Ev{9R=lDw33{fIB;FatEovy2zh*Q zbyQbZ0?w6`fFXI{L|*>six3&$L|sN2II2i<zX+7_s`&|kQmWLTq{Q<)P}1vTlY#=z zi!gbw+9p+bS>UKF3t*7(s%uh`;nWRAo+v1A=>$uA)i<fg14CSTK~liEvOG$;LbHN` z9B{5A$E_DC>-DKgQBejsDl1%J08Zqky*{CoD>o}EAWu+GWId3hvK|0(1sUW~9^j-| zNgjEwh(wM&QI?bT0B{0ez)}9QvK#<|JpToNBrSs+l9PcT!BEN+WjyPfffHalaH1$L z?OFdB$(|B$0w9+~9_4<I0`ST*o}T~!<Pji!bp((|d)9qcM1leAeO3n8t4EGr9f45* zEw^q6^5<_hJ_D=P4FOmMzyO>8LT=qqSqSncw_XUq+fPUyVAj<|U=>J&$a96CSAN1= zO;`Fk5y>RviYrJR0ESZbdy3-EiB}@}iLLC{l%GhDy#2fmpeR!UNqam}^#d*fEb-`v z3%|(}HHndS{|LY+*(5)AO*8k;bBHYUPOJ{g_>@@KlKr8pvUv#Lq`7CRMN_@)rCz7G zX^*XSpPO_4#Nv>z_h?wi#M{{KsqbcUa~8@=m)3Vz>gzVz+jfVCk5*PLFE35sQMUr5 zEA3SjR8i2;Z`{Daxpj+>i0ICpJLKe)l$6voG_<s|4<0;VVq#`t;o#ul=H})H{saYu zgv7+eq@-lz<djrY)HF3UpFe-`!qCvj$kfct!ou3x*3RDE(b?JE-OJ0{*VjKVFf<}E zGBP$cJ|Q6`B?Su2%*@Tr%_}S{Ev>Aqs;a4}`B-1y)YR16+|tt0-rn8~{C)e@*EcjY zHa0mmHT8XVc41+8d1Yl|V|!=k;Nal+`0VU##jAD|U?0m`O3Mxfg_HpK54DT_0E~iC zy(ldvtmdq@g$Rd|k2%a@)zG%9Ft9GLptXfGkntVGhS5Yx$H_5u5c1(vrH&8WwrR%; zHrl)e+1z8tFr<0cp(T3HiRtF>WMTAEwb5Wo+z(`0HnN18w+m4XN%8e=_*l&QJ5yoB zBsQ7!@f?45-O!m<pY|v$EcBd>^lMbt)t#=%*-lt#e1;4V|Le~yd7tazN8fq}==|ey zDGI*FQMMkg%UY$UIQtEuuX(v17n^;JX{V1qn|}B-8qxO(12ylCw)RFK0Q(`#BQb%) z7ex){anYgZfd<OsqNifWSwCXx^tsZYw8_FK4>4eb)O6~7O8010|9|k4#f4;aQux+p z5p&8ng?=p-Mg`8NwZ!P5_GS#4Z#bTD`leM%r*w6hFx;3dJnH8`gJVU<6qx4W#xQ=P zOyquS8=3z28r49QK_cB`jX?}HEqP_`2O-QG@MlAoR^M_x)1bE)^IZcbDU$|qe55NC z=Et>O7nh5PQ5Fi9na>!o7N;zROi07$q)aP6C|ufdi&;OYn$e!Z@}ZkZ1r+k1$ylO# z11|zqnNq}E-`>Y9iM8nwjWXmOpL2dN{&I^$n#+JOB9wMhYqH#-`t;gAT(THN$I~-z zVvSQ)b#tJVzvgI7e-U`U1wOz_G8Lk4K9;<hsPPY}&I$`d(tuAb-u=lp{bw>yBp1aZ z%r^?*Qj4t>8M-<q?eDH3{G_Bu*oQGX<4kVJk*I{LrTaNl3QtbV$-72AG{|@#KiaPe zKJPL!RE%{j4#Y?i{g;42%RO&enu_#flJ=)MM59rLnvZo%6h*)=W%Jj|80)>0?$u{3 z{fa?xY67BfqU6jmnvJAaO~nsIm2Z9JB^oWVL9b$xR&BOjlXTmjI+)nGj%bbgs}?3K zgtZ}lQ?j1pq_)9qQ8(Vur_EtSL*cr)Hz33()PH!7_k&n0g{IhLtpyI=x5Uh_?%?3A zKNN*(rfX|&${nEp*BMx}q?nZZZ(Bxb#oyDJ&yeSg<PPc_#1{sQvWnRK<2Ec>&psr` zrag>Hk`i_sBat&D9jSjtDk_QFABmN;d~20KOr{_;ol`1@!}mo+l#zXZrIh3X>14g= z%-l^<I<7U`_Yu58V17I))r0H*aPTs(m&l(#J-FH@t@ud@-Fx_iMT$xK=qEg|A4DW8 zYn|+suaOM<4f?Pijaltj#!O}Q{=08hom({r^Fgk2kq71+V#)0P=t6pk*7JdKAF(3e zNLo<1;n=A4TA(kzuYg&v*FPBh26-g~w^~0N-!$1ocT|{^CdPiB7x011K5O!W+30%W zluh4%6$S*I|5ra3)>pnv*wsAMx({%Nv??$2y>bR{UOqZ7vN=&%YR<O!p|JG(m=VEt zlkK6pe1!Ce!-LTVuBUIIm{v1xI<a4oc7mEn5~+WlBP%2hvpah$yCTI!`b0l;bH2aN zW70`|NZi?9@VG9gJ#!H5lF*o4<~fsv-%z+Ff>Z>GTxdJ9o;}usCdjrvmB51)y@B^n z5T6vzY&QZQT8$cO++VpHF0-+6A0F?POwsdg<`6UalO)Jha>)M|<swj^m+i)i1D<<t zYLoriwWidDjC#h2+%Q?wzNHfJuY#A8wUwk2`BjIi<_P|e1NEuQQRz^_w+Fq4GxCKQ zzqr88gbJcAjYN*GgjBK3HnpuK7}uzR#qS&+C_F5Np7-~WG0q3m0P*A+%i|)5%C)XS zP>4&ff9l6Rf~W}}$hj~W6OQ_Ua!^r3i09BQoWn+bsP#>V=M(9h@I6cf`6}kH&qs*C zwXS^7O{XwRB1`)C<iyp5qqhg9eR?-iGMS+Qrfy~1`VC@|&+G2K9&*`YyYGH+Q+9=| z!IWE4XR!*~#B|)&{_@=?(dP>aHP|^vTydRiE5%%v{k=L?jk!}hx;qWEmp_0t;jUqN zuHZGj`Em5_cqVSaYUV@x?3QkBgOmBnx3bz(lO5isZvrp6?oV7EP3y!pUbN{{90s_A zrm^n=;M1+XTvoaX3l@e^8?sEc7~d#ShN$zQN<ycw7LT>^AAxEwo%%OkZ&J5$lE>O` zWJEusrnd-f?Bl&%vbi(mgyp*N^uTs$bE4b!fv_;?J@ZQkws<Oygvl(}!M6N_<Z~{C zAC`q~J1TQr?=_s31pKcNZ$njJ&bLGCli91c5@X1Rt??6WLpf(d#pp4+67IlWxW1gh zo2^ZMJYK?F-l1^CPcevCNf7Z#<~n$SQCu*p&D7PGIul!iu8Tmu71p9&eZZ{0G%h6x zlPVloD%9ZFc6oC-QfN`~NTXD5sYCjZ@bU?7*zBC+j-5tHV-E<=un1L73Ot|0wLR_T zs~@f?h2~_wvHW-xpY&Acc)L7v^})mAxQ{j~GXggwTm=X(qsX@Vd+V1eCyWmdex!O= zwG7}FhAPlw?jKDZJLA8X$6%CzyM(HYnb(NPw1EM(`zcmU#Ts{Nn)1c3pLn6iDT0l# ziqW;CSXJ)PQ03juSf(lj;YBY#reL#ACA6g`7}%0szQZd<LstmmOp(wgx3_T!J$g<+ zv)9o|eprgN7WkUoAR6;|2^}3(w?jp{@9_~R%2-Us2)%@I0CPLBIvEqzSs!B{ooK{i z9d&z|#e4mQ3aQ&hTME7P9Gd(?#}|3f;|Dg9GbTJUQ62z)yE^@SX6Fo#=|7Xs_7p?K zhWaipx>*rsUqeKQ2`@AeQTA1Csn@?qPUo_;J)7@o#eq9(gY91xdzepmKWh#eXT)S7 zLzJmkJ!}z-#<)8WNwQlbUmQ%y_tj6NU-Fxd1x9h;0Ha(t&Q{2MdC9E17OO%Bkj>9Z zV4~&K1et~CcT<OSB(B(SvS{##$hA+=ieS#s;4%?v<MH)dW687}%82oC|MW8d55m-} z%1S|^VE$K=?h$@%6&bt<4kQhx@*G~BtASa!NsRCPD8txPC?GdylVP+^3=ZtTspb^J zOrkg870&{NXvp0l6o#_KvKe4%Blv?n6V+%LoIHa4BLX23Vxc#7+ngBEK!uSk#c-<k zeg$b9Acf}8`%j9wVJ+z~`IQ5Bc+oKNvUVIJYWQ3X#WSOiy)E}%5{cl9M)EL`O!*NI zG?3o)dt@CQiZf?wfH_I1(rWyvO_QOnu~h`>3sC63vD@kdJ@s~nQ@zQ85f-}p!^<a? z5K-y9`sy%rm_otE!=qCrFid!l<g3hc>;;7DUGswF8Vq&<M5{bu0cB%sNS(ypy{<7n ztC@PI$oUvSM8D+Op(tis#@pkW(dtz>MARyE!}xoo#ZmS51xb+&aNLQ!NM(*uoJnQo z45lZ(9o))lgV3xMg9m5ArN3cha=~FO@}tks2J1+7B5B%jT74l^!t{-mO=~Wf(`Ho> zJQhI^GkxwtduT)E;t+nI(fLipiLgv?PP22?A<cegA!yrXFw0g!UDRrE7{3Mqz;GQY z-4S<SUbB>4%Pp#gel-7r!cZRj{IkIJ_s1r8Uw4QSRG0=qq_`coaMyGzfe9M;r^N6* z-#9{f-#w{y$)#8gu!WZ&*GCsk-u|_x!;xF8k+9f;a(|zYAP>Po{D}x!Q3qzMvJ8aF zUK(gpY9p||g=na|S67*9c3uy*Th<H@?)F>AsjmQ^%h|th7Ex=I5t9i4IBq>8>|!W| zaF0t@k?EIzDE|nt&^|nP<(VZilCRcOs|wEP3&SH>njl#{mlFd&|G;X9iB(VF>Q71h z$u7Zwgm02zl#zmhQwhAIy!DOK@_=;J9AhnTzA!Jd$5IFkiK@sjXQ7CO80>czg9hc@ z>AskWv&xJs*lar|_^k(~SgTB?m6<rV^9e7z_!niiucxIW>F{p}OAd)47HkmT<(!gY zF<@w?Fj1@IvfwnQtqA}>T2X&65sP&FQ`iC~<KtwEg_no1QHqv`GMV1Mg>aYKtuBTn zlU6GUF%CV}!Xx-xb6Ex2?ss3uXe^=I(+5JF)2I;oG;~wl@hO0l_$1vce;GI^Md<3E z_PL$&`yDB?I$ueUtU(myBcXtWQ;ySz)8wXZcluFA5QMqGy#1ssgw`3@-YA#EhhFf9 zK~#{7Gj|s>#dtW|B-2|~ek;2-HTEPBjn?os5X1tDJoUJ+TxA(_pL4eN<LMNJt_4a; z#(skFIlDx5-<6z((8ayrj2*xq3+%z^J^mO%m;Vtm&f4=$r)E0@qeH{?94#rN%MDoe zQ^LofK7IQ1A-?Y!MuMWC>W2NfW801DiBr6Z&cqu?gSi73%nJmplc5RH`ee~hHX-k! zQMhRTll@lzLJgN1iAT@C`$=~EnQ<E3ETb>&{8bgOMkk3Uvy46kYc)PD%2lSMh1PYw zb{H2PMN15WWaa6vFy@}Wx@$fUk4|OAe&kJTizrF5;e8G^D&64k2~3x#c$jsdv1K}L z<+M7*Nan!|YCq6E6?#8|hd4onCy__iFRBWG&q_m_a1y@U@*AAHdzUi|>#${nK2$*~ zJieD@FHFvx;Q`qgKBfZefFHKgt-H5z4MgA*p4~xyAM@o~Z4kTf`sx=W>T9@P%sqQo zw(x!>vzrwSMwmeQCh-0aS10c>yCW%`;q1NQ{k?!^(`g{E5IA-rS9hN=0~GU_*zs$v zEOR@Kb?TH`iOu`<iiZp(P{b5-Xvz~^Ea*48OX3+jD*kpvg0xhHTGA6PlQiFqYWh>6 zd#hiT_#H}v*8(+;GCa8Kud`5BZ)$L_N4<EvyHWq?d_0_QXR9e4w{!8PPP6OSXtI4R ztB#Xl)>Ey<jZq!<wA5p7CaShA>Aj`4nT74@8TqN%<%`>)@ATMjgrFjvbAurJw}<-d z6B8jA!s!ZXgV-Jwa>z1QDGY+(81t#7S1oe9ChvXiq#xg(-7XCj;%xC&Qrm+=i}fdz zAcAQN-4el6<%<Fjj^0|MrGT~g`dFyH=8ek$S@MpOP;HaRj=DU&O2R{;NBgw<Z4wIJ zD)jq642)cPzhxcTZLN2&gy0P&ac8dvPC;C`YPXW6EV6iVeULe*!@_Row58L|u<``= z<W{oSg8gxoH2Jz?<Un`+w#34Z&IZfl;g^+71KidY^;27x8<>khH1*R0g1i#i;ARuM zPOXATolx9W2I`?94>@h{;2^o+s)0;g1{C2`+ag<=ZKJdlrJqYyM2e{pE$lahX?8%l zCVr%v;U=ZhE@x0*FU%<HVHZ?I*TJxKqk{BQs#;_au9b1gBTL+XifHYC*@I$7`_#A5 zQYt)T27%34$0_Ue`Lkgxbsj)K&91_G-P`3YfsxTNw39s3TOo3qPwB&Wrl*$@ww{O! zGT?&*rPE``ZC;etJHdn&egr^bBGT}!tlsf5>QI>@ZcSw0ga>!PU<$eA6~y+VDRo=f zYcA_?*-$bewrsK@Vxkg@dr48enp|1$X+C`uj@I=5Lb-?K@=CElcM-IAyCGmM+THK9 zK{YiA8l3F@vHwk<!xy>t(RJ!@5n_Mp)v{+%_ISxe<^c|NQg159=u&odXdgTxHM}P< z??oXc<|Fg;>_&gzs?i#<0YJjnT(SM%LP(RLgX*O$Zc>oGW4#+}=VeTIu(3jCb%(g# z1m}4YO#z+3)H_;UYE&3IuNIu@jN|Txuq<af^p1+kA<hS3<SGb_l5pj19YP;zFf1;i zlPy(MiA+&46hm<>jjMs+-7$z?GsvaguL%Cn6dOd8q9&LK_U?z0nXfnzwk^hb`?JOq zI$VHEzoPP=!cUVyWgwDcd(+XWmTL7@lS`J3%7)$(gddt0PJdskHzedwXQ!E0I6Z=F zS=4L_A5$POBE<gaLBYfa%&bGvm&yg{Wbh>JfABs!vQJdB_)O)t6qm)gKX7D9T@2#Y z({`tp=<f@mCE>fz=XV`0je;N&|5Mn0@F`G|;N{<ze5C3&J>*7xpMr>Jov|1+^HTCO zk>d0nP`cLC_$btWyI%OX&OB*<IKx9&=#pvwrPqza%z&9_?CS_4n%|A6W^Eg<FCf14 z3A_cK&hSqD#T66=i=`q(Fwq@{nn(&k_r+Fonv!?$HT0X=gads!+g$$Gtpaaw8i;~y z(x4W91;qR%Sm*n!aoVH?cQ|#3H5@j?EwZjcd)}E3ii-W13(QrZ+?#s{8;bnXdw3m? zRNd&tHX1H2!G?ILcE)y4AEa79Tk_6aEDJO}!-AHZNpo8WJmdY}dKnpRF#p?zd4K_1 zxc}e6KkZI`q|-m8xWWIIk&G-eLzel@ozT!udrdDY^h&iqYYp;!5VX$W@Vx$~IrHMf zDbD4{XC=YRu|g8-0GL8C{yWBR`lx>u^yb#t;sT#*!z)x%shwf?=cK`NVxd1qH4<=X zMu~|WU6BMvStdc!|BuFaTwo`Ak*_P{P9mQ*>DW|sJRRIn$9{Fn1=@<FrTY+XhGDnw zUg{(fYy8ENW7U+!HXP<Ua;;P8{s2I|`xWj0&hn!F7ii**eT^XljPF0E1L>dGfreLt zoK`W2*&M)NUwUjVA0K=^Qk96xb%nwQ97R47$!vCUb64we@rQ-ur@kW+7Z%z*UiWGx zfMqmCdJ0#laW(EbJ@vePvb!_JcHy#i>?y^r`DSq^=PS;~=+{|e*v>DWEKdZHaNrU# zYX6?<g_#D;KM*TDE|M02Zzi}klzPGmO$zr~E5ASVSU%0QcdL*Z82rWSb$%3t-1~)w z8SEHm83+SaqYG@KZe+vbl)%OFe}dgFghp1HMSy_($=qqjf1y26RcJBWR4yc*g#Cv^ zNwgmG57brDbxnkO-56hQX(a!nYM1p5#gw!abNC*`7tsG;(eUs<B;GiW#3aR+K8Wb? zW0TL}&uJR;KBM*b4F|8SU`<2^%s6Yu5{msV{QOfJ?`<S_vOxK7<w^cG)($fGTV`6< z36RG;xA0r$Rnvz^tz4}XSVCKSZET^_^2ax*20IV>`_!VY<cI=K;!TI#4bKhpGCGAy z(iRJWRfYd7sTC$l(4V`On>u&0;v&QU=#8-1SrQ3SkEr+nAVWInc0bwLs%spif>TTs zJS6gGW)`eP;Du3&BFt5P?0$b=)n97ni2mw<$S2M48?KEx{(n}kjBq~>OEPL!m4~vt zWnS~UL_hWv{x2_i5bp0T7bklweE`no>F*c_pCp@`2stdI*<9&96F$cq-&|Bm;P}b& z)O^)c=I`?BzmL->+AI?4=x(l&u9`OO5|y^jz5L4huMl0t{}Fj^FF!25)MLG!<GsZH z7&yo5J=qJie-!+W{uJMzRxh6GH0=u1-Ix3yGo;#rOE3JkgQ&!1L&>aZ#-vI~cTr%f zrnC!Rb`TEJ#MJ-mdO!kXOSDckIwSj!)uX`k*<);mP=+@=HlPjqPS`3{za0yy5C;ji zi#f$k>^(`)2qNr%ur?6p35%o^KJN`Y1fnkfZzVdknVciQXACh}$>YpZ^pyWfgqP6x zT(s#Z#scO#dqOsWidYmXiLQPA8M9yUeX!|yAVi}&h#BHnlWk_sie|ZZw{rwd&kM3H z$F>08Q=gzuML>R%TEAkC{_WoJ<#~;fV(IZ#ZsT7G@&E8X9q3cF3o?4n?6cc%GldSD z&H9CLEgOv@5rpV@>`D*^I`x=-{98`U<Vg9s!KnSthsTU+{;byGGn!pGh;P+ca3J*7 zUc+UQlk9J=FT~(yA%&mnXWi+2<VqkS2-i3M&phdP-xuWr7F+1eqpxDCNk<<{=y6(c z-u?FWu$c0O<7k3?yLSJ8Z?$$^Xtf5Hxn$Xg>NLK);cvg;Z4s=Z$yJWzggb^diJO%S zM)WR+SoU(*r9;~SJ%y(XR&e&h^w5@CnrQgaq5ObRVkcw~qsz*^3Mn=*6p!6lo?hyw za>OUgEH9{Eb@uLkshq$u!9i8goyxPCH$}3ACvYIg4uU6Xw6Z6Y2*SFnS2h&?ibqyt zU6X;X=mU3$R&Me8r+EIuG`CZ$w8=Nc+*X}=gCb|+ba7?2ifXhsHVFwYEmU4jyIT~0 z=yH2@lJ;SgcSn2izP!vH9{iS7FOcB8Cm1kGcE0R$7d?WxG9x^}w132{cRTnwCr=nv z;jP;tQ38%9AIfJ&tpkoMq(#0YKUJ{7p`|t-FCe=oKBG<jx>LtqAv5nfuO`Q^k&BIw z`|$EuTLI6W1sY<QOgTK~UU;Ota&_=5f-20l*B1x@uF{&|oTDM5@<iHh>Q`+qog-;A z!3DH2^26sen%PAYPABhTDA$63+VYM@(`sl7NzMc&;0p71<uBiw8i$^&gMYmFZMe3F zgVqkRDb^iK+9?L&<JBhq{M37Lo0M>~f{B1k3P`puY$4eIR|~2<+)AIJs6#b^vYOi) z^oI6OK+!*x;^LDQOzF4pJ}>4lLRG~K`O0MDso4Rl2%IU$^dHH+H5iG`=K)XW`tpz@ z`_!=8zDTY86)ND&tz7R;+Arl}8fIkMFMU3tAr_Ibw3L<=p){Bc{rZ+<u0PVXwX8}8 z)8>G{s=qKlZK8|R!#%L?OMl8fE3ax9&3nXCq>~%GlUQiq6bqd(^%R@+hU`-U@j@ep z3T`gr6i=lC4*foqz027UYvF3*_BAT<>9@eq*l;=an*a-9JopG57plf1)jH_k(DA7A z1;WqJE>R9)o$DI3nV!izx%cF*%$npqkN7aJDmu3uZ^(L>RQr<(n`M1^3de`P)ecbg zhR>zKdJAs&aYScB#a*pl`}^LRq=C-~1Vq@#ZtC1-sv5Vlou9w}*nUVcSJSBP^zd(3 zq9e-#-F(eE$!+);So@ovVAv3zW4yE1OKxmKo>ADltXg7+>~FxGt@p|Yx1g6gb&vjT zd!@8!hoWv4V{jBi|C3^HJ|x*gV4vUOL1uJPkCEqR9HcclDDK?56mx2g`V%D|b+RDL zjJ}NIqrwL$>?v-@GiN~~$jOCSBM_Q5-QutKG%4z<xjZ~xcO?I9HLeXYIK%iFjaf^k zPc1TRRs$dEvz=DeN?=MabvycfnA%cTMa(M;9@&M)tR{w#9ea+vIH3Z>ZRB{Cn<0ta z_Fqv8A$C_y`5ZWOz|Sk!6FW2gK8Z{E1Cw|{_*%4!Iq$d0WNtai=A=2k>OaIo3?~Ib zc66W!zGMZO|46+Vj>R{_#aPifs5rdW`v|@o5fR2>G`2eY1S=eejg^M{q0xLH872@F z{)B=<8IcdvI>%b!0Y8+A46^#4Pf-h7JQ+xlAT%Q2Q?+Ncc&WEYX=3W({q9TUM5pX1 z<MSGohQ~$Ha>IK1tl|CL6(<t)6bq?mu*w&sWT*~*<1_PR)Tb}$eurjS6f#gqSWxF$ zF)z9kCE;J;of{Tf;*7K`tAOw0KFq9pm`C^51Wp4VK6kwTOt1ZEnBOZoD5S_S4VwIS zsR^EWU&L7z3rFSyGK=PV55J^?2w}qDr&r`lzc<;B+OBmyo#wfBm116-tJrUKeViO0 zIFJh}@T%5`kMC&RfLY;iTpz(k^7Cmwxvt&XG9H~4=`v&--(sD3x5hJ_Udclt&hN4b zJvMLUVIi4wSt<x=w-rCe4{XW7K6Ws?`!ieU&xM|F=hDIj^DwWV=!&70rK|Tuqcin~ z!p)I>NV+T31i2gf`VI9B#}m2?jG;4OoGZ!(u$FucW~u$>GhPxA0gzW=qF@XTfw3za z`*eHF)N}TP!RjEA90xIcXVp{>X)-;JY!HbitKBAs4{TXrs)lTbm1F|Upkab5gtx~c zS-a?@XCO<1Jd+=-d2j+wItpR77n`*S+0zrYS~I-I1r#-&N!49uvGG^w9HlBaZ5f&6 zE)&;4^di@m&Nr6jXB^fV^V5=O9#g-oB<*>5R%1N-W_my9ck1;CnR+B?yn{>QVz5Pr z*;m~=1G+Nudc)kM){}J|3_mjkoZ-H%9GsT#TJ2FSaAXpbq%jY#WnO#aXc|O@O;l=? z{ZRk7Hr1qlla8os+5?R7Yg&I_hE|dMc+XSx^Rv{m?XRRyi#tvU`Ez&fPz*J&rViKO zL~hL7iQLc$FtxV|3p{+>Vpqo%(3rW}d#7{uq-;BUFRan{4*VW;xPg^os0K&Wb0M^j zi`peU@Is>9|H89tEE3D0gS_hCJF%rY=li{trD;FN4QaEX17d}gpmy#ezq*8hNWI5V zKkz-3tcuE`RLyy%=atRp)V_OLQ~5y9R~cw?K!h!2JbHXi>M0TW3Az>O@LG4bO9yk~ z_{SrCg%wocV)JEe>w5itC@R-II2PrS6+TDGV2^6VlO)SN`t;c_RXK1r+s;FEDC8X& z6-LvO4%{#0W9}R-!k%D=VTA|3Qm-)Qn^~%4wkxQrBZaXCHDx)Ca(4uCyr+C#44spD z@EnWrUVEpJ#<f++L@tC_7N$UVuN1gkSa^W1wfhs*TMn%Bt~@tku&-2n#XuCHIWMX> ze>sL}DoSZ5Dz^fCJy2|a`M%zMRI$?pIgB~7C5VQUbft*E@Lsx3t+lA&KFZ#{j==d+ z2;uGgN>Q`V<QeC}rX+w290xKgU=5BVmv3sVOf83o^cG56vUk&E^WDf0tB2PJ_Ccbh zaB2BEv!$fH)W37Gpa%*1<qq^iG33#r;K6zKk{)1Pv8XV#wyW@6>L=gFT7}I-9SD*0 zJS!YjeWoyt4e$Ki1TfH+>adz?^3z5WAU!7_vJ=ACo)?Hjiqc1e=(@iFCxsaVhfOix zfS-yYcjMBJFq*S0(grU`))(MjdstUKAP%yVvA$OsrJ+7ha{Q`3ezH7@pDwEkmf$cM ze_0LrV!l1O-V&#F>;qxjErlYVS>YWu^=`kvta;9RV3g+in+>DE2h3@EbudHYRY`c= zlkYR0x(SO>uB56ezxeJ+KDe)EqP`4Sx&cXpYKi>f$q-|&)p}iW#3<L#JWcE;p$EcX z{%s!W_B7E|(;Vc!)br>GLd-jCepoT@-kJIR9L;A)q-i(^4wBIkfo6q9%tkz3vb;N2 z%zw>?Y8ufHv*tpoe3|yc$+h*afQb+scfT!>l*c&LLYo=T-u`6ZQ?G|QqMNVD(f<fq z59>ml!CdtUR5kjPAC3;oVe01St~{A?xjPVcYI{|GiN$3>edJ(9pP7-QzTw<vPs+~d z1~Pg*=3A%;FIHqkvUtYwcyvi1M+<qidr+Zm9v^$F)`eT{>EQu+rn!<0(rQwO<=9nT zHRDAhW2Uj$zNpuGxYkxrUuAwlK8QsWDOJu#9YHIf6tPlJkbwXzl&^U?UKae#vFrmD zg6KMsE6kqh=${SG4%**E#yS)9A%b|bl%r5&R1zty{BBkcs}x%|7Y2(1nMqHj!2F4R ze=+S9-!}$XJr%gRuK0dg-dRa?AFieOL!BxO>I2k3%Tq<rnHtCu;%5z3N#=cMm;Nch z)M=<v2aE$#y@Sm5Jc5{cU%fzL``MQ87XtU=clb^Qu9kXB|1K9ch_4}pz?Asw6gj0B z^ndr}8!$A47k{2BPX67*KV^p=Rlgz@&}}PBzU{L}pNJ*K2Rfy3p}PH)1-ZPR%?*(> z=xtc+-7mFCrse8NtYW<3$Cu2rF=7?}Vpna1*b1y&Q^T>rYY>F##87Aa4?3st&ciHh zCDvB%nDxK>vL!sC9*#_MtD_(xTFqs7g5XF9qSRa=_1~<_-0_(Zb~lXi_{)v$Y21=y z{WMnf<QB2ZF82m~R68njM@B2(mSd`Tuqj0;d@Yd<Pj&HQ2|jx=2C<NR=9)e3pO#0h zYk>M=9O_hOSY_T>Y$Sc@BfY~+Qnt=#=lS|%9~Cfif;uFI#4`S_i<u&5w*dP1se)K; zLvo8?zv9TP5wqmrvCn_9mk($J*<1oE)CWeY%jtcMS=p8p1EDX1{-dQX?;ESRH=rZ8 zxuC1!W#j)5iY4WjCI}~AcXF5Fa%WBtf4iUu-2Bt*xaRLfUXSzEoIW^{Wgu4m7NezI zs2+NEq{qx=JYeuYJ4(1>akmiY!ZYn|{zj=5U5WdgrK{pB?yHxkqQZX^xFjS-_6Gd5 zoy-IPk+K<rJs(KegPsyjjBLC=z5WMm4FH2P3VJ;RmLhTUUCv5~THBk3!ZEj_GuCYe zOu!%Jy>DE?CvNh(1i)!K_$T6`Z|APnQb+IQ%^d23Wm10IWzPs2>-mN$&yCTiNhv+C z@??y5$*GU#$s$MUSymna8}s72H}}P1i`{oF>^ATOL&_7Cbq)ayF*3#Bdi3AyEZchD zp<4}1I9aQrw#7laYh95~{Z(Pe&i|Wp!3-VJReyHxu2Y|H<a$olH?n$Nk#Yt|aV)I4 zCQ$ydeA1xZQjmiJj)x&i5<?1`3Jf47)poX_>+{zQkeV2sWV9_hj&-SEq%l?mC>ecf z`j=9d*%@Q6m?Ece7R=nWBr5FQ{NWSfKe|E&BO>80XwJ&b&W}-fPFLyLPe1hzdbPen zCNZQgax)D%%pG0uKZkP*qzHy#&-dPRy688^{;dnJ#e~4(Q6hP3wewEg3y6OSDhEJ- zrylp3!R+U0?`uc;M4OI_`*_#?Sy%=-qA1T%#QqY8tp-l!_wSNP)Oh2MavE8E)pWp- z6yOURpzHZB#AsgK2kJ;JU2Sdc`^Iyp>q>7B{IeVH2aJ-W2H3K3jIL5kq=0pIa*ZGA z(q>+Vyq7O1hLYwSEc|g2U`xI@%<M+wL6YCk7hb9bzS>w>)7u$JX8KPujx@jM_4xJN z@`%*Z<o`6Bf*#0&3$-^Y?j}p8fv(cqUs6R{BkPCaY)Z|!v8TUw=f75As`^?-xJ>+# zlP}NxbUs*bM=RD9Ho<)Cs(%S%=y|pfY+9=h?>SIhJ2LuP24RbxjNy;e#h*B^-<W(< zs6)fVuYVs{&i}dP3fQ5kuzzJ<3*G_$0n7%e?5?t$!oZQfb}f$fNN{ONRsHdoy@hs0 z%Kbt1zi}C9olptcLLJ^y5pA!4D36M@FGu-}5W(q<`zvFTsl-$KhljcH{RbQfXZ*Ry z|7Zu$tRGWJ&D2IM#{FgP3AIFA#HT1@vI75!<ut7SH0FXHsDe+ERy*lCdRG5$`?N^I zeaQ(suqbtEBU_4sWIf~5`mgT#6$wm4!IAIM^-o1I5)cCn5rk@|K9C$A<gQ1VL5^T5 zJ@7H)+j<tE$87SWGpEC1HFwWudvX0ekEM>+INwbeJMrS(HNXmtS4~~oVJ@t1I0W2i zh7~jS;s~OcE)RmTh<~?zsb%^VZ9lXqq@p}HGa3??0YoS%2PQ)GNQSJFMR=y>wpI?3 z_*FyAsgN}d((uSEKaOZ?X=`gOut+_-Boje~Qk=CwbbATjI*M#)5$-_$uSPDQ+dke- zh9aBC4z`b-5&=hNSB1|}uvC0waBV2vz*{xdzN)5>Atg4*=>f@nQm!a6&?P<oU)^71 z!0>q?uX^peX!2blBu%;1l?BrtTI|$UaKC(aX@+x#kC)i+q?^b@!aIl!7Mu5GN!yYM zh^{8|u$H;r1HdRebH>itc9uC;NqfRnf46>-<nPm_7RA0UAGwNY&B-Mc1)vf`vL5)| zm+fZ>&;Uq|-<9kECZ65ytL~^7b_ZApi!+ed!2drtjfMO?5ggS%#d%w`_w8+Q_<IB= z?DMMuoc|gZlcUHb$C&Sn30lk;z$&jHxT7+z2V{;ReWY)G@S)=IZAYIpLzOKtC(UFe zqpR)SBu`jy0Gj~#a_+Ch_L#yV(RokRn3;`@vkcq|5)ylQsHzS)F?3-5I>rIdPsnFF z3i}+W>UgW|&H4!PdFY(`ik+uCpxg)PYqb(W;Mx<~>6=X%Yv#M$v!Q*f5=nA=3+$LM zRiFmK2b~z!5nsU0>|fuMlLf2xo%8^<j0*2WYe!KHzm}5?^?XQnsXl$J1-NI50<?h* zyz(VbRR{ad8mY-HxA9jw?*QE=01>9jN${FDFcSIgghTti36P2aH;=73FcM9OSnea# zD1T8j<>tglG(cWD&oW9DK8Yp00#y2P=S7I}XM5NIU1!y9OC2^2DxC2ej6LqbNs=BB z3o*i7uEOHv%`|2JaBCG6PA0>Ik*IwVJJ>gG!mw(=3)-!!B4jeReLhbnc@j%_g_32S z_4C)zONHZjITi4uPd`K$tetaeNj^G8w$8@l=-j$k%uI&6#0=QK^@0RM2chN=U#Eo) zZK6Md&1)_?*)WWMPmY76#-0c8=hQa~bq)6on$$N01TyvU2jacXfEw+x7eAm(hmNFu zV>U{MF|9l^tsO{>f>6Y6O7Q2NH4Dk~_tgnbbn{z~;cKNjMA+9$KAn(!c(Qlrf_z5M zK`GV)pcellcVK+et#Qd9cJ@8+C{Hu~7pOZBK($QY>XWt#I(O{%R1R!W^cy7`q1{+` ze9kj6J){Q4LZEw};_G#b2{Z1mt(0MVD4x9Rv>^8by8w~!TN+L2dD+rZw*1?H7i@~0 z#%Uk}F9_VgE0okzZ8n)>YWj`*VeDX}%ZQ9-$a6T)sDq8%tT9AqKluk}UFQV~u+J!t znkRqEtzGzpt%6L7gut!MmQJFvjDxt8VWkg#7&$S^`T);<gqMJBm-vp0ui`_V=$*$j zVq*Nz2gBor)IGk6#+#;QYK4O%ezfb*bTl_?OUoaznj^?3t!<=c>ByV=zJ`K^xP&=@ zvWwzXd8XpMR$vBbzfbzH@4b7<IP*6l=l<Zp4lvnXU)Cf2mJ{zC83k3!b0B^ps*FEh zzYbp3>hA9=iY*8cbGT)S^W)JuPo0g7CrV|)>UG(*_8U1%?w_{BU<YA~m66cV8e#g2 zL(zG2X2}-W@bG{rAa0={ZfU`7o_euBzChm~T<Hez-}d*#M;uSsAGyehfVY3F%zrKY zq==8Abuy+{X~_Fsez)@053(KhUeqn;XJ2miFZA7k97@;br$(o5^k5!(1y_{6r{sfc zjg>@3IDTeG@`FHB*e`n6Fa4WNYIyoC<DhECD~Bji{+@{4amS1|0cT2g;uZ+_kl9<m z;*%^a*N}zn+i<O$&fj0!=_W%+_}Dg?lFhW0z-mjXvu~_G10JkdB+tIC7(RP@8#ZKC zA{KeLZbrnBh{}-i5J2!S8+5@u^Q@k5v&>0*5JN~}UT=KKG3ChW!<308%o=a|mAayJ zn4lNrrb+-LgdLd>uQHI13@RELKLYM@(7_eNz=eYkgtANxjR>r)CPiWFsA*7YA#l8N zrXq-Vs4t6qcq^56eEdh*O26LNOVDcW17KTA1I>Nz6oBu56?w<4zoO(|UNAVcfC3dP ztgI^0hg5e3)>aaGI0+COcur2=deQq8h27UpZ8|x)NZV~HWKa++m<qCozOr*|M6z?z zr^FVi4Z{yC6yXz5<|YzgH3B;(zL+j&o^GaIHj2Ya@(!7MYI_O>@w0cNE;|cQVJ%9v zU>8_coJc_=cYMPGaWF%NK<=^FH3pR-#qR#dMp|i;Pw$LLOz%d*%?IdmNR<_?9UM`@ z6`$dzf#%cXP6y{ryF5eKV4_X)i>TqkfRCEw&Z~n1>vLTe{A9sRUHa$J(+|v(z9zM0 zLY|>%y%LqYFOhi2g|UApbL}B2;+ACgxxYhHy08~03_A>hmu0}B2<LeyixYi}H=wai zPx4(Ub&<Kc5Iv!?XWn8#8T@U8M1Rgdo2WKkr<lGU|79!t8-#_dTV(ZToMd}e9=v<q zZ=8-5EH-&xzsEwvT}`T7tAz-G#nfRfZH($*BBS#C4v`+lN_JrpaIB_D`8JT<dO?CR zRrbRmRbn|0B*EX8tYD&t>3{)7G+mB482XU2zCI_Pdx_cmRZs=aT1ue-PjtCbt)KaM z8Eb!)Ya^%82i8mwoVcPdrpyZ;59GL*Y`tz8=Fs~J9~s;OC$_im6C=peY@wU`oN?(; z(c4bJ5WKDIS0XcqvDaa$w~zrB-!AGQ$gO@_m(1gijx9$P(C1KyhDW4sQ}A`Q;1fEO zhOA+}Ew#9!{Dq2rGiluJTP?sZ?~yil`WaCqoX6RZG*N!?33WDz=1wG_bN(v>TUup| z@T!ii&3zxA0hKWHP4Nnzu0m^ATS?RX;lNzo>JZjSdZuq;bM$kE%Af^WCV`B%c_#G{ z2iZ{3b-ra-e=74OfDb4?3DTg?<8q)l?rWwA)Ww97cp$+p_6yww$c5>J0pAa^jBcjU ztE~&ayxeJUVxDl%>O}8^w2t*U|JsT*$7JBWRC14<&b^3O9g}k4DJ4MmHz0#wx3P{t zllqpf(lDnsdeR)d81d~4WO|f8H%j;yZ0nfUV|aR7E-ni+gl#N!PGSWQ#<jKW<=o?# z%4}3q1^2Ngm)!1;wBAi*?avRB(PV`4yokT2dRuocwQ*MN5O_67T1g%O^l=E$;pODK zREi$sd~<glHA5f<Ef63-5+yDv>oPY<&GLrayoTH*gKbv*V4_gL(J>sg07yi|S&uIs z+4Sq(Lqxecu_BLYiV*nvmC$H;UQxKewZwQR3eGjy`fTp*ap^t8*7ufsV%ouj@0WfR z-_h)U#ug=e3q_w=OCn+A_qa^Q)zjw{&p5?~Gv2t$0$MpQ-tjxfnNrhEzU&@|%v{sh zgCY3m(;{0-fyi^k6f1duN$H!)(edW+=~l`_Hke({#EHQ!3?bQ5IUP%z0fjCyUmVw= z2B0CA@RIiXnxhj}MF2&7IuvbtCG4iLdsA%tNoXOrK~}*}+c%_!3KKHRFkVR3yOk(- zV!)G#uZ*k}!>QWzh?muv=u$LL(doGAT2+HbL6~wMkjwn!g(`wO@NOGp=82Uo4vC6u zUkZ>pQ2sI!<@2pC`Z8aF2rn;ua}_8oIPg}_*}f8>i2Rb7A347}cjYzu?wRudOF8f0 zjllJkdmi_9A|gD0Apx~evH!3hYgk+z4r~$vS6)MkNRqqYdRfZAsTv<b=|iZPo6t%E zW1f5XPe0@NGBY7)V~`?}CNMS*1w_MAxvrrwg-mF!*aDewJzv{NJY)3*>VSH;0?&em zYlxnkS8g(|Wbs~kKe7dNX*JNA>8Lp_4Z3&}6c75rd=X;lHTO$Y(*p7YZs&Om9LB5d z3N_${f!Xs#Suo~t#&xcDA9@2%L-mJoS>C-`&jn;FW*pBiXh1*h<TSKE>9J<Y_k3yP zb4leW(8xnaCTF5*=3fs*c@H661fkA@_#?b6ykjp-iwS=jLm+o@k-NM)xD_?YOTR5E z)Noo?o}j)&o8fo7An<G*8BlBHiYtK9Fx1|B761td^Z<5<E9Lb#Iw>OTjF>5~{Nr*! zA?{VEysS4nQXmHSlN0_Bdf*WNATIHUEqNR-wgpt3)5r6ubqz#%Opedw!_e@7ZO6J| ztG)aO!7pNw)*RXfdVCqNap@qBj<#*AK)|7Mh09anD=fOG?PafjOSnb&zJ2AE*$I^x zxGDc$>W`O!^<)dF9&3Rsb?*g*UxEU4OEBO3_8UKPTg5t}u0%J=4TRF>0vxvyMhHFF z#yM+@Y&vP$z_^2V<rSpHt1Dh>dl@&1JjW}!fW2_zp=s{@hHV^An=RR9^j~qSC@BFm zlI-5*d%4NaP)JbN2Tq*xul<TZ+Zot}YaiIn*YtjRVEA1T?<6!GdJgC_(F(E43r29e zrgrH%%~OKmci>6V0CZ0cL?tx*VZ?wF-MS?7aMLCK^!qNUDEKr#2cl=hp-Z={1MUsP zVSut(Jdg!D4um%hv*QbJ3RszyU`e*6Lw$f)L?|$Uo@9ks%)vn<CgrqRULHL2SX&XA zpEHOk!~gB=z`EKK)2#AA%?Xg0NKSist~ura$o`e%c8W{GZ64b{a31WV8q{@l)w+3M zu*v}b<y`5|@E-r=hBecc+E&eLe?~wp>9K4R?q`X7Bo7MLc(APi6lKXjB2QB;V=TSW zuWT5d!pv~oPC+m)9}<B(*4G*`^zN!8c-bnLTT^4)8eVu-ON$`qZ^P&PE;yh;v!4a^ zZF!{MugH2ONc6W~1XMS8KMG4vBrIATKzA<tajnD(@v_Gnce9{vo#}IcE8<-3X9W7Q zr{gdZ1Ur5*7nSC#Lu`FGPuYf^Da|!FBgU2e<+a7MV?H>Vh^p(49x}&t9qgOKy}xE= ztqwf!0X)Nq+?ZeS?|S=yrZzo(*gp^QV?bmrf2x%b5CwnrLe^8a0vEOfRNcOhbSBzH zWRd6{WkHAEafyK!7PP>H?}bzu;~jnI<aw>37H}bOkL5X!zFR~(*m#wJz){_#8Fw}J zj^1HqKi;)mNb+kK28=yZ=_IrAKHgTX4`|iYGTmo-)aa%Y<-98R(fhQe;l6o=vfAs2 z9wwp#iyLm!y0PO@twMlpsudBgzc7X!=%1u`Dse627Yuzoj3o{_8CG<AT|Rd{h^%Y^ zASQ8!ldxpU0lbua=r>Bu;l+>Sq3UOxUFK(<&35PCBG=l!my_6kA5b(w65J$pf(_Af z34_@~>;_ug;aEQR<->8s`KQ+3wYW99HR7f6x|9uYr$wjEo57Op5a=o2=yD-!XauEi zz<vj^N#5}0SAoRKDBuk$`Nl2{2{Xal40Y2D$Q?W0xSc=pjA|i9-_HJ1UkxNrto|^T zEC{e#_3Q9X@f=9C58n00*f}qkFZDm%hS_1Uq&1MlM6A@g!o?qtc81XQ_aF6XEgmF8 zwrf3ecSOMlQaKRdAt2pY!WW_p9$PtXv-BmP0!L-%gqvqdz&#XMFnCwDQ4Yahva_;m z2yf<q4j-pOU1(Lo;fIvt?=;U_hA4x?aud9AR`R1|!DMrab3k2p5(DAr1bGV020)gh zEf5^q!u{srOdH#s*AQ~y?r@txu)i;~XqN#8@NjM0MLz|8N^(2=3;tQOOI@ycdmj#X zo6%kt6s^67d<+$c0I&rdPl+3l?{kVofcHP8omt(m^nP0}G-NZ(!wL)UoR<bmPFH?k z5CWgV7H<9n`VuPAm!kDLS96GqK9m7rVPBuzg%0n`1xcQ;tLy^62F;2m*`fE>Y{Ti3 zMZlF^bC$=js0TupX!44vKt{{yUOwX4K6@T%PxIB_wQhE|Tp4DW%;Jcm=dbw|yF(d; z<mj-z3=W<c%XptOaVw^wMuoBw%hE(NQ;gNXG|JB-E98<_2=(89-KJHOdqgfWx0$5A z$roE{+k1Yyaac)>70#Qe7BMu}7t{=(Cd2^GU1!(>QUdj9<|oN?X&~zM1CvF;ei+ei z7AW-x*r<HO0%5WC7?g3g(Fzpj#P$!W(>ShEz)FL8Z+i#D;CV{mK;SJ<&2GhMz!hnL z4ak`K*gGdzs2aU({>RG#$kwaC*`w+Wg2JR(xh0ly^I|4{xmW9N-rnHjWPBe4nfDH& zBfAJAKhJ7`I$t44Y)HQ^WJ_bl`>iYIdp6(3#mzJZ#A2d-^yxRE^P*R`Z*=aOhBZB7 zJI}Y-MMK<>{Ib+m5p_>^NSefHvB~EPZ9A9&2s6VnG$l`(daUq#9?PTBQCx%(oYS^I zgVDjjJ(sH#u%g~cj6twASFrPa+8TOjuy>$N>iL2+nCA{~6Y}*6Oo9KLY$K8w-;@6K zc}Efu($hdx%Giu-n`NEleekY95j%7LDKt)pOTYXyh~qV|=sT072j^suPJ#o$vF4}I zs^)bvLSQ*qkW)?&<e5(zA?K+zEz#?cca+4#eUpnM+J(5vC+y3!4{v(X5AD<B4kDW* zLB5Ocw!+Jf)U)>AKDTf%&*-*l%}axjT=N5ajPIKE{9pi}hqvffenJ}#pj}jSz|S0F z3=L}dKeW3J_bDe?)JKoNF7BOwyHw-4U4+qGgj;bKf$Q0Jp*pc^Dl)BS`$S#?Yc)`c z-)KU9be4GpWkV0*?*3_QCFqH@#2i#d2n~aOUq!O6=f;9*el%H&AJ`BR47_hJoCxAc z$|*#LiIU$FTt7`YKR!#dY)!O5kgFfFY?osu!5Phe!V{jzCheN47(y0}kg~?Nu|DbP zE+TH_>ujUAd4uDr7Le$pd=<=%AWwT_ZC}5Ehsu7K*&Cd0)x&k3kSw%o_yrn_>%0u6 zhN-G6;Np5#z=jl_JZ)mvc>|U-5XDt=tS{MRPzBRHe#-XR`h-0iOcV$vytmuqDYlwh zKt6t-^MFkjTo~N=1n6-Pi2$W;ki282RL9f#7oR#yWZx*Fr5ALw$6`Ua&yzHFRh7Wt zBbNb@>63Fw4o~8RT@0|+qt>UFkAPdM3b(2piu$fa@;zr+!&;CBm*+9>g`Gz2!G=c7 ztSfa-1J;^Ol6KCuaFLIpvl&NR2Av+NDgw8P^@q>Z!^qj0*`X9QJ;fBCXhn6FAua{p z&V}w@bKp?N-qX8^;A&$ChKZTGMEC2h6P%xuGqXQH%q||b5olRbXGy_m7E)>4i%(Xh z!D@3iLF;zo(-(qV@O<OV7WY85c3`=tjyg#dheMj08pr5-GXZlhgNh59P8#jbAns{_ zmnza2>!zzJH1A(XYA>4#fweVX-$2s&3aixTS}%Y~WY+eyY(L{KsacW*hsRD2ndEe? zZI?)ArP^={fqCNZPGp6w@#>~fnjO%E<jpvnKQ4UgcSSc>5Uz#GoBZ%P5NM{RCTECg zCa%GN9jdA19@ak7(~7*EqfAUSOyF}Ag`*gqL`b6jiXO1aY}wcLU0VBnu@IFv+W|)1 zXA9@wfNtqKciC{JWBdrt)w2;{nSz-D;O!Ohqy?k_=mL30bwk6q!wBDAtQ`+HW3Bv1 zECg?laA}AZ6J)Z^u%kkw!n#%Hu5R`I*}wFR4-J<E_dJgkYcVO0HrnmW`>G+fQTb32 z+3+5jp~_!W+yYondw?elpGbBH)YoT#WRg9k2jLS~y!-lRrz48#*%E2cHA>(W_+?Bu zW5V?Inr}GnK%ciI2N6B+9@O`V#-U|XfxRZy_3H1MIS>^IGX62o4@>1b)@;CAKsq0; zzPoVh4Ut*0cG^LyX_3j?Fkcxo^z6vqwOYq$j(z-n6*bm)^pG9xUvOj5NjEj{cD`bt z4Wqjp*PWyvOCqySrng1z#CorcqM;J2rYhf0{+;tRC^r%E0A>CQ5&FjY?YZ0-Wnl!7 z?kl60x@c|h)sJs|Wdz=Fu^PGhKnQX*Z*h~X(%`I*`_0MW1j{vRwLes7_VR7`)Gcnr z#1z!Ly80T%0U9E%>t)i(8yH}IF#a0&srkk7>~J{u*Z8~2XPXwCvK%k+c>iIf%Q*6$ zrx+Mh!RgrE)Q1Vd^yIBdY+@>eV!;Zcz;&BQ>y?rB^ADBOKH8euEr=p49una7qi4m) z@0`2<c4}Lm(Ji2(F(Kfx*qZ8A3zb8}i4h;F8s!rd<cr6CNhZ3cZr_!ErM_&k9w3)w zV=x}B`~g|UgDp^As?c;gu3xvp&!j;6We#yBEMS_Al`XxU68cAyZx4sKD_$>Fu7r7{ zL2>q<JdN4^W^x_W&-7O`rbdYG8;6$W6}D>H;PAF|!+ZDIpBMK6y>b$E7768F2Ktls z(==$g7bFMy5?&(EuzMv0HY|@VaTf+>Qzm8f2(%@-F9T1V-tF(xjIuIl@k!2~*nbPW zV)Dnt4X`$VCm~Y3AZ-S8(|Zw1Z8E=29}N-KQM8dO+_sh|&PDRf@quoGx&CiKb&+2Z zq(di0`mFY6cXAyv-E(rGm%&Y^m&4%$(j~I`&B}rOimi!omkpCrr-fd$>0^n~;}ZJW ziWVQsqnYtp&%l{l$jW^e-<Sc0quB<h4PJzwj@6{V@(Ewn!RS<7Aq#skv}b>|>XB4c zp4XdG*SK96?107dAheDZV=s4KZ2;)>v}yuhwpeU=uCexg{ZNcm><;<BhA-c8*^JH^ z{^~9IBdo96!647}&4)Oi&knfUjNV=@$48_Mp?*%iIl8%#JD|xrB=6hnN|$gBeCOuM z+?1D3A~ho*md|semMO&98}89N+H9=QORtX#M3}l-sqTlnStQ)sU*?Oeb2(1s3EUh2 zzVuM<=6lp&enjjqs0Bt8trJqj%MILR+i^2mPXk2|1<TY00<Q%97d^L9`fz<5ORDuo zAoaZxiH7bAR^k7Pwf~NXyNUY8;WUvV1d&AD=piD}yNwVn*ytfjbfWjZ5?!JMAqZBl zLG(@%qO-anh`xGTZCQS^B-eG__xFB1e?9;1&S&P#%$YOioH^%x2)(B6!?$XeoF}H$ zhYc1r?cUe4lJO3!-WCm*v)*Z8J+{0C9})X9J~Qdyqh3oMb!9O#t@0?H_7B&jbZkHh z8L+0afhpvvaRgY?+C{4mX|Oa_wUYTnh7_Oi)HD%o4wTP!Ul_)i_8|quVNE~}P#k*i zQRgY5)H`3Pih{JHJWT+E^g-Z=K3ZkJcTPX&acrEjKfL7151#v$zg^qwC?7Z1(*~hj zL=$|){3hkhj*P=Bu+p??Ma+4k=(Y!>nJE~JSEb7hc=Ds_WJAR5K_66VRn2`2-vXiC z7!jAq)2jEDffJp2KqI01glTaIhS|GI$9g3p6^`M!n$IUB81ZAsFhh3HL|L#;h|{}U zw4>H7HFgUm@|{SHlSyh}ZEQadff!n%r;GF7gmy1sOeZ!R2vN+2$~EH03w-UCQ4s92 zGewKVZCsC_H}m02O)o<H@;apMt3&=PpNmr=t5=nQQk8qS71=dZAvJtA31rUCWv~}p zEDF;!_kgfSwcH=BnF#&3-?#kp+@9<GcZIrw;T1&V=dhPzCj$tLIXb_n;IU-R=TbW~ zI;#wmdR%i>!5->X5eL+%ewI4NG+QEH`c&7L_<s<Pg5Wb7qO`WZTDIhZVir@T;mb;R zv~p*?Zzm4p_Lft^ezPR#=95P>w}@t}oyICB-8MMa?b;8MSlMSHN&o4IeJKp(|1>8t z={7m0P+N5$ZBKuL0Bz9PPgMDmh3aha@D6vR(DwEX+rT-sPPz>9y3ft)eAPhTA)7_r zL@VD18(#StnnKB*?dGjtf!>mwxhgx?O|-(%K$whp51#0J`iDl9>I_EWv%2Q3&t5&6 z3*RoLaNt&T{bxD;`@Q&qm8>`Z&P;z;=mon4km4FivtJ$me85`2V!PN--G)f@_t_)k zp@eFKPp-U`H#6$*jBS;tL%%40!-FgRmEw2pHM}JFw3N0l{IFSQR;YhyFKK@gw~g5s z$te?q`ZMpZ?WS2Zq8QxWWEWj@c|$raN9TmEVLwaBBh3%5rmZlKZJBt*AR+v;|5C|J z9*Lx~kr^Pp(U1<YI$Riw7)}xHRB`G_w7}ZDcWCI~_k(|6!!o$Vx&C^}f&oBGgCtO+ zc5VS!`sR;Fi_!a5yM)md#BYrxpbXgtqokLx=#5Q)*7M5l`aCkRI<J)&hmEt<z^Dp) zMvw`oLETMUvex)UFbMm(0moXRq*{aF`gm5cQfHapO{7T=VLNOfl!wo>KObh8greDu z?;{*_Htz~tFk?ow>@lD+!vK_y&cMu_u0)Z8I3_7vT5t!^M->q<j;S#68Y}hopI$a$ z7aXQn-4E8Zi9S+R=jXK-HjLNibJgrjz^4Tt6l}a6=Z<`4&|EL@(Y~$-Ev`yrP8IRG zTq$~x=)p%SxV^mz1@&4;Q%<Zy56S))x4?cPJ^9s=QI)4NUIu%GXnx#&@cdYs@6zd> zIT|Q7d0=iQyqJYxRep-)R^vW0QzGs=?svbF2Vp%}*~uW}O^XX__SZg|3s!pyZ(5Ko z?y<16%!`{<=~Gs4eHlS1l5}!U^ZYQMIU}!=YDi;FfYWK*7Ny>fRk3(jTHpJPUSgKC zZ`B<zPl88qt83<Z-g+q}X(ZUao9ly<CCU<*WPa2#StJ#BQ`UNw1K}VF5EcEz2U3I| zOw1G<ZB=ocD{7=AkJF{|xMI(Z+xs}Wek69wB=yzLm`BiAC3UQ+cyRgKTU<}DH7&Z> zFIK^A7JMQB7+RzF`Ulw?Z{Tg|Wf<b)y<8U#kg|Hx!S}`a*<ur9ExS9;C&^ygi}Y5b zBWQnNDetN&Q>zQ@jEZ)myL|Mx0C)h@M>jI(2^Kv+z41#<$Bq7YyP>m74ewUP@lxr% z`L4v;8<1N26;4%TmyX*Hf&o{NoE*i?2qtTUkb9`k6vj0K>U3n+!Bt*hBeE7%0k^96 zc*9G8zG%Nff_;5ey$JuJ3`m^^`dkiB{$fQ0;dA`k3sOzDf2`lqGF)Wdm|>UPMc&2T z((-y}F!GQCk;Y^%_MRl3;tTXrGNh~Z%`QuNPp_(M4r7b{FGtA2yeQ+fkCvUG^37Uz zEVJSHJwpL4%(^B6mt*xl{8cK_wo@6q-q1YM015Jg53aK4LOnefxwtC(Lryj&5WdPR zSldD{6L(cz*BH-~?K@o1eSdMF{gCyjlB%xRU(q?d)WswValm#Ta~qN({`RNnyl$N= zWL`N4{!@H@;TPI&a#1y!!fUMZo;o8_ul0iX3A3Y>d3rHDs!bRcqf&7e%+me5HIAc2 zUJcA7vENd|VqB}>D*~uvzwOEWdIdc2ZvJ!;A4#Pp6ngBmV(%zJM@4)kQ|EH7mPZXd z{`0prKMXB(Y*?-2T1-|Di8}vv&W#XM0O76uLI*jCCu^-@hxd7lWN~m)Ks(K*IR7aT z8`(>Q2Yq2g_L~j+Y{1-Q&9(KP;RcDG(hV*=aW5gml#yNVW1B}`T1_(1Sa&aahfInt zy7pKN>JXeT@WkYOc?<K%HzvC2Vr3Bp*ijL@i$<>7+Fc`(1&1R596hSjw<@n6MOb}+ z$wKcV+H*5ndc(Ar4eqc~;=4U^Je^!LJ|6W3or1fCUw|+j$JJOm3m-kQje9GR(PnlR zshOgyaso84-7oYKLhF2~NrfUU50Vi{wjbns#56y><Fn0tFQ+&s8@HijWUL7dv#0ft z<ZH{+g~n~dfK5`u7o{adePS(Tyu{kr2j5@y)qIou)5nO|+=N$;$ohG?7Qg!&g_ouD zxIxT+I%m9noA4_Gz~ES$er7b2PsjDXXB}gXsyc&J31P#QjI3~8T+cuklUzu5G&ET- zY44jkGCNULZhVH6$ys#6I<8Z6wTRJTM1L^OFZlJNImv^>Z^&*YN<$rHqH?bc45O5n z*#&%iNP9%LI9}{e74*ThXRUa)j44j+Isa}L7Tw2^Nk%`0Ufv!Slu4W}fXngee_o6v zTk<|-ON|P0rdL?Sdk+<`x5HcR2`s6G+Mqz(nQWY_mK@X;r5wZ+t8M3!vJgx3wqb3X z9w^Kk6W1}>2)MUhBHI>Zf9bf+>iQBUDS@P=7go&G5XS9z2d9hNXu{W8Z&0Hc;d%z0 zp>Rd$XQ(sihfiniND9emx935u{G1j8oOK>jul4#w_afhyL5?UNLxJu!l<q{=OK7@! z;RWLl8o<W0ghS>xj!(p_ALg}Ch2<6zBmQD@9qd~dV>B^VoQ$Jr$aPd6(ibKYIn__( z-fScD_{+?Y5$#`6^+v;nN}V2KsJ=*-)~OMA(X@bg8IlJ(IrgHri$5=RoTyGW%Cfeu zLoAPyMOd&l@8tP0Oe0B+*n_!Ci57ZPjnA>q;y>s(M2V7?aW35Ifw|0*VOlENSsz&~ z5axQvN@v`)Kjia;FJ?kkM_Il>S@73;+hh(y+`4+h;I;&w^ggqL8E$W5vj+(C;4b`O zge_pfb0DicMAc0$Godo!MLM;{4v)9<hZe4hv@8bfWZ<uK5B=2f9NkbDDDQ81EO<9B z4}PL{f;HmlCn~VJ-Nnav$laPob!VxHDXR*e0~M3QnJg^d-x9We4c2x-1qkb_Prrm^ zKav(v&yN8xg1WSn3mj@t6_MgpvilxPkrA#`IS{T!0pA@{^}{o#y+`LFcJoJ@-Bo=x z7Xyyo<<H7&fXH;auPIH}iI3cli_yiO2kPF7ou@T<=^b-=+pMttI;7VDIb-*<GR&8G zRkI$GDsI-;-ehbQaGLWUAR4M;H`QJ`;t^m$$mEy`Uu*CneitU-wa`mOivE?cyL@9{ zRPaX~(J9ByF3u--%)0<YGkBc)<$fioW}H5XGLo_VEaSuQg1M0?x7;T=Ofbu6eq$jV zAcmSe@q(1*>tQl<#2}Frp9yl~gEIUYrF9EC?~S*N2AJ?m^WO(@)eE{0Bo%H9uOBK2 z&YWYMeYeN=Ja}er$t7n|RVS|@k;m^u{cez5oOeTtj(_JX?T1Z#(SbI&nrK63s6&ws zB~I0E#r;q3$_&Wpp}0E+P5Oeg!Jq2_zTAkFxRj(ke==PEs);W}^5RFEeNj*U`amh_ z!dLk^`T?<4J9{KlJ-dvjBH+0Uwp(#B^4sBefMw806Ke^beYk|_xvZaqz(ZK7rk?WS z4TSIXD~F#Gey9a6Mf1%g&((NA_wgNt%UUwMk`&nwV$&q}_4*1m(w7ezHKfH|qQtY> z9lqY1dxxrV>L70K&I+pwz2-1!r#6<0!MGaqH#?DC#E>U^IIreBD4Sb%$m_M;>|mhM z&*zjMCw#L`|3t5}ldxyMq!b=f<9~X3zC>VHh)^aDN+1ccpbI0*!V}Z)L8R{+rA&`) zk;?PW@x}4LJ^UxaihQ@8fRIZ)AUcl&kKxBUd~M9s*chjbm-Yk4{qIDv>-yqorL2Km zgT(E+w2&_Fz*#Zf9?BP7H5>3(sKjbxg`2$U=Yf0udk#U?i(US!++$~o`-{@Oa%Wwe zJP~kybjq!*ZQG7fg%L>wdCT)7v3a4pSMFHK3UleG*-?v*KMOyRviu-~wE<@CHElU2 zC0ybBZoGnQr)*+nyQ7+~5`Q^C$YC!JwT^GS+2e03)UrnvS3gYu0xGZL*x$Xudo<j0 zG^(XBl<Wbg^v0mYlW(=BTGKX&Nzxk0#7p*C+-K`0YcEvMXgygmH;MM1NPoLglQxX& z`b9)gMXJ#51YPZ=p#hGxkM0q7R)i~3tw$OrYLkUx{uxUdI!EqvQ`i176-Mu-x?^{0 zvkBGCLT2U2l=ae!Cf8>oHXIL23v7Z87q6X~-DIvSMjYLK66GTg|D4kT#HSm@zp9%F zE6ttip0rXruZ>M=ueBw{z^!^G`PRl}0c4^!(OuVsP$nbodgli>ABS8>DD%fmZq^r% zYid~K*$e;978ekQO4z%G_}uZL9>&TeQ@aO$ON;-wlCQ$_k2!hb9(fInr<aD$p|wkE zHW5B?yZjq8jE!tm^S^#eXh9t+(BG6>9JHOr=&5ZPSI)Y&UNWQFyUOiVEENskgU;(k zy?f#NG<J(Dv$7-VOU_cJo=>VOrcfw7FG}sqfBZi<TZX;?Q_0>Nepm84BqG#b?4ac7 z_t*+}{-@W0jEp06OD#)Bqmj2iwVWIr4NUTJTyq=AelxO&R0E??BHw*vJO-17MoIl~ z-uy8JzO{UT2P>p`#u_Bxm$Y9p^E#I2QPhI+eoyu!x%i}B|6IMvMYKJtac5`etO6CU z5M2?vIC9x~e52%C(o^WwdrD*Uf}%oWz{M@YS`hCTCj8gf21-!CpOuL#F>|}j{7qT& zTwDcQE{k3)V)<Ry!#5Mkp4j+hP7u(ws#tuF;VCrR#-y|Fbu<8u%8MG<N=!$n_!Yc8 zAA9w$lj5H)r!bR?H=aD+y?d!D^SwUjws>=^Xiie>OEY#>-P8CkD09`Qv95F(oW!qt z$ffE7e3^8-{r3K0!Co#kGLV&J{vXfBe>znxf3G%0Fo4wJ5rHf_!Dvh^-obGJUnbI} zDG-|dTMmPV+hxryZgu9e(4_{ux}TaKqk;&yN=GJ_>2ONl>3sc{G7DA!MiKsyJfBE? zaQ)ruUg>iMZ!M%74bb*Uqat^O#Q!`9%$m)*euR4~klV9sVazrkLg3%sFAST!?E3U+ zGm_rH>r{0+^<v_z!iSs-ZMRfYrSEw<W{F{3BfSD_8hG`?&LX6?)Sr~4*EXXv_2ORZ z8!iNVPk0`=^tOQbJ`1){QrNu!E`aXi`>k>N=lsXp@vW$%#S=B;)RB5h^%SNDJzAJy z(tZZ}Y<;U~RM>2K@KfaT>)~AK`?++I!cVq~A2G6cbX*8K*ifcjG<TZ|Es!7h8a*U) zix3-AAkVS>4N8^2QliGKLf7WPZNc%^ZU!1E&SnlKxCfFDCwTOT@Wsr+3A%}fUqw7U zYYPBxR1K@$C60{Ns5<f>EYB0<b(Wr=BZ0xjfyJ(&ReEJ}h+w80rhAvvVI=pw&qIvF zz`-oeGQzo<{^@&3iXv2=GL)Noq9i})_GiQ=wU?x?PbjAxi$oXnASHGCwutO$4<oD? zy3H<J)I}b(cM}!2+`H>ewH;r);QG+Ph+9?T|Dk!Qxn$U;dBBmF_%b6JS<S?ewfUpC zK5(hrs&+$d<x?V&W95bv+TOIlU3OQKX72G`iWP%KkMZsAqsmbH1*wb#H67>?{I~C4 z2i_m^{vl@?M8jfwTpOc)YvBE`?$Fw=YUj0^D<9@&#N?4wJQ@y<n{KabaC=3~sFYWG zq8)aBD$>AXa@?==!cq%sm^@o)4w5<126OHlM>)Wp8D73&YCE#QO>X3UB6v@o_LC7g z%(uyVk+nA8g1=mw&tJXMQPL}hq170hp?z!JE#`Fe6SeOA>WH-!L~<=^fC#(Czz&82 z2&`Po3ki;4mPic@i$rd`)MVI+@qFTl+a)mAj6IKY_Jq6cx~+9$@prSP9H$jJsMf}e zKBBG0dKOhIDhr=Iw5HGv_bb^jJr>!FDeOnB4}pQ&ni9j2?0k=zLF&4U2)`LtLJ#(( zcy5>P(Eeyqw<m<ZQ;mDffFs(er++~0UNG+d{Nw#=up2rcN7!`X>77sE$f^UdG!2xL zlu|?slJRWV3kjW^Y96o!X06iP6|diVb94tU3ZFFG3@E+d_aJ|YmGU2E1ineit~mG< z^n2H1Y9Ebm7!!E)lRC$Ojgh&P9{2zRK?J?=N59h|`-+n3V7Nz~n6yWg%}wziuk|$( zdFW88s=Di;{n#k{VnjMb=z?*(HCYx6IxB(#k8YoWq@t8o+IYra6oj7t<FUZKqTsaP zcpmICzg%bRwM1&<{hv+=Md3InXinRkhJZe89a-Z(d+t4#W`pxKve3?mxcC@0Y??>$ zs)ZJ>dXpc`GwQ$W`DYd+V}{dewZ@O20SdO&T;+%HBMP1Tor6TAqB~75JnxR7wdgcJ z=Jssz$j6MSmcR?Q2FwGa|MetW^V<UqLs%33ww0V=ulm5YeGA&%cCYw8ebO`lJm@KT zN)*jGJ$8o_S^J=hBN}de=^vkA=&^rsCL&155xeZPt3V}iAH;}{@f<w%UkKnhZ|h)C z#E&l4|CBI@r2x@GFIwyJ^R9>re7XMLWlTn}F3p=dhb?LwcMT=i3Fr!-iz`^oM^J-? z3w^Mu4SgMRPCz|-QN7X+X8fCv|J+*ORjnR?D;QzpKO}c)T(u(TfpG)4w*Iyf_-D_N zjHY?}m9K2rbtU>G!QU_SLU>t4^G$Ggawo4d;L+h4ZrtWTlN;C=f%%T;f^AqIW^yV& zD&Hv4ZmsZ^=u_w>rFX*4h~^6|eur%0SaOqdr6fYDc7Gq9PAxp3j2#Lb9bk#Z0*QGA z><iRgl@%6*QeXP8iqe><U`37=kJBhGU%3w+5_@PfUj)&Lll|ve5I2F9wjmD85Ncj} zLKCUs^+;&0d8=rR1<S@*ozQarXey|~ZxChjGwZ=m^0GupetBQMo4L=GBmc8`m#`|; z3$DA5Zk$hduPZuwt&}!0evgy|TM|*Xp&5^l3c%OiBzQZJyl)+m;jHE=<~Hm=6rRZb zzn5bEtIjT3uLt=}d2H2x^;+xR`B&)aydJ5Ap|A`BQS~i~EJRH=k@4iuiLss1yDPW< zikDNHF6T2O-`3H&Rjm53ElgA4{WiYVmC=OJ2A|jAv5wdhA8M<W!g?X>LGJ7S9A$A- zW-rE!s%I8nHP(kUw<5rtXCGyzaW{u6ESRJhY^vH~Q9l9jis4_IZeS2L{k7224!H{A z_Qqpry}o9sK4XbwZ{gc$B4zD7T7;k9F21`ZO5mdp-KGc6X%Q^Aoqo5F8EtxG{GQ6| zt6x+vllF3&;JAo_OUodPf2H9eiVxLdkxM;#L7OoxZIGnxS3_{C31P{XL88tHg71Dd zU*OS0hNkbV<fBXA6_Dy$HXoA;p;m*jdoQ3tdeGoi=VW9`8D>GHbfFReqHS%t-p_NK zeiv8IT2$-)y|gXI?<z<#zuDpOASGVrR(8?a(uTfVG&~wzec#-Nrc7*nvRoC4R;tD0 zt4sAOb@Gtnia`M6n|AZsy(uXkFIC@9o(hnqrHvvR+K%ope-Ynu9-;%ZL5A>M(UrbE z#iK=Nf5>fyubp`2AAWTGCeIXJHL?6g^()Qm{6ucw&3P_OP4nh?ZXZ>NlB9+Gxx3C4 z&efS1gdMF7tpkerihE7|-md~glXt>O;jHro+d+%+1PRYqj?zoJZx5AvOJeV+)&9=h zP=~6w@68J#4$R}ev7W<9fPmtQBSH%~zP6wjDY9;j-Rk9Pai}j^$ZUiX9M)2%H3AJA z@k4{`@tFCbjZueE(ToM#J%$96Uzxe85ES#b@JP-blilZTZR*kRiic5OmaAVt)87N| zYF*68m+^AHFO{!y-NGtkZbLiNm!5*BI*@xLh~$H2y(k5ciT1vTLb<3fsjbF$>hiRD zkkQSBUBm+eVbo{Mc(`BBMF{I>x^;?@`uZSbe4$i_9b$Xuv1t282&XvHi&MuG+J{f8 z6a_)_N_4j6{l%?Wma@r@0#e?H%f3*O)5d86HYzkOw98M3yWe>T%|I%7^jNbHj(L`j zh8r|R?-8{4#eSFJO+;RD>&nOL_!t>|N-thQ8X@_Do)m*_*p(bdnU9oyA_<Q0L5<My z&p*=BhqK-CoUSz6Qyd0UADOOCU-IJg>hBG04&obs4cDjQ*47=1Y!VDm*qqwBf{skd z7XRofO~hq!wgFE_FsF90G}7iVTQKLFri;*Ne<<%>rOU=ghcMbLDIV9`x6xb;RPSvv zM@14|*{dZXxZ5rJysV-X$H;rnK_E=S+3=wuS>~3Wm_#}PcoTuwcU-~>6e~K`Y<P4R zLuz3q1}zRQ*;_VJsCf<NG|Mm1Z15LlVh&QV$s4$_lJ`SW4=eEv>4J+T)2i9KR~6QJ zsCb{mjS>@UR90E6-A6d528H}CILfyQz5)v$)0p;0_@(pY=c(3S4t!TsoVMoRlHp}C zruZfp4{G2CU5j*=2cbo=&{yH`&PTv`Zi<U9iVitS_O}H+`50Hv8gpGrIoD3a^2yH@ z*%hGx75Ql<bg)154aq+lCOmSNf#&FXEbZ_k>}fa?BK{F{`n{Ha-ta~V>!@LCH&K|q z<}w<pd7t<&nE0q>?Vj63@sw@giRB9*%%oX2dIN8wEv4(xG^WiVA;<J6MteSGWAs7v zG=M~{NJ3D4WW=tKfM0m!)j4l?Q*tC*-VdRu3^9Lr+J|xsI`Rr!lF&=(8%*#Jpbor^ zUH%cjy5=4LZ_?uufWYmU{H1U8!36inc@Aapq1k{pvRRm0gsMj=nT^Ic#%`U(1~(|_ zKZ_q?wwDWij9It}mn87Qcq3E*i}pwQjIAb`?Fu~7dp2QkF&R<#lR!{U*WJEZcsqCT zMlZ~3olA4C4}#l<B@7Mj1A{Ru{+V@^V{s7jUTA8CM@@aJ_Bvy(JTaEv8xj5;BDHS6 zG35*b3mKCTZgx5DvdSO~z=}`gl4;zz7;P*A<OgZdFhvQwr|K6*&qDgG;g0w&0&Imh zLh(C99rrC4hJEr-kpRurXVH95Yol`2e_?T+Xn)j8g->=4wqJc5Z*@b$arzNa7HghU zHT4BF(GRoxid_+AU+k8e$q$3CAMyJj9v%XgX)h@twJ06ch}4*2JBeIN@5RI#4_Kp| zA6S-+ny+fy5TvYwgdv~AUz$9BAuE{qTnKe>#q=vBkYSbSvNuf#x7dr^PgQgDVr6*u zKJt`nB3s*Tfj3Ibs^f|X-@BITPxd!wHrfe|Q#P3SATGU|1iGJZIZn4SABWSt|Jb~3 z4-?&&7wsuPHAU9%iHf|G*fZ>gMF~)tyNM33ykbqu#|YdkUj4S3XfXbw$vM(7?W~E| zGM7g!V*llD(v5cyhwJ$f1ek12{GF<5icJd#10$vETsUvlXdIn_Gxhm8t~z(+d(V~* zQEwS@Zgo61F9KMlj~_v4n_Vg<gF>!pSe052BPzRLDcJUijWKF2^IEg1#5n~#$fzjZ zNlRkkWsL=*b8}+Q0IG)jT=g$T1=P36U{%*o{^cNC;$l}2)O-Zq&gemrCIDiLQUCqJ znEIWF@uJjV^h8g3gR#NQ?9)+Y2ub7Ql%%j0w?~@-RU033)`2@`=h=EO%ct(JXNuUD zr48hnp%{UjUd5fVum#G?oOPcX`*cESzPz;H-c?aK36X8p;uaBV-LpD)O-*{p*3pE? z29T{+0LY&qe0$4l-T7F4EKrZ;OCN88=UsxFqdt4tGZ+?70A_9dEsD}hT^&pH%ck7% ziQ!y4<cmQ<pG-b8Z}}sr-)s2ZWg)^|zfI`I%KENDszZh=mx6i?7l@Sx01k!8*e;pg zo-nyNS1mqS0ANLYGJS#U0yv>X;}leC;ucyNXa?82VG6Hu5#qwl42>L%l`!bLr!m@b zAj#+wikZ1|0Ld;hUoyyFULJ-TziozP`y}PDbKj8vDpA2Y2)4(yaU4K~TkU=@2$cyg zforBwxN&p^8H^`dGi4ym@~t&!x?#cenfy0?3eCE8ywu(<?ipM1%F^&Ifva_D`gvX@ zSMxmEpag)i=Td)M!(0})Uix))2U+vE0PcTHNbZ*J+^cu<8tD6mC><+DP#Fd+oA0{s z+Um{@FW--y0t{|-9EFuQTD@l0jt;8MUIfwb=RmqndQvlY4UORJ^OY}vA-@dqedqk) zU@vNLvTkh51|fH55Dq@l+S}r#1!LbrK%o3t)*Of^`QSk|=ja$|Tm(LQrnvXWVgM&R zPF;W#RR>V}K!P4%#AsUNeoihtw2dx+HdGPRp84~0NF%8UhNehM9h;^m>=5kc55EEe z<pC}4?evlRi%TK-xo|>D2Aj{@1lSv=8(h>Ql4tn^q|tc(SRdLa+Or2&s^}=(AEX4I zHn1&n*Q9$*I<{KIz^i|s7Pbjl2MKc2C=<z(m3WS(6_QE0Xo|w0IcaZT%kFjwL=XYi z0PFOeaIxj%1q_X%0hVg^Ygpzmjcutg-_bR%-TLlp4*@<4ZtE9w5s@VGwqez&4Ph}> zT_zwD{|`rmSUK;ek=wggc;#RIOHgEF)gn&IWe}2XqTC_cVM;=rI~mRnyya3YtoGLD zAS{Q{uA(x}bi-(q5P|2VU~zb1vFNmSRf{I##v}fi@Q)0CmyEVmN;J)!c6)$`67VM& zmNp5}{>|4jWnWiTd)q$v6Z|uL=h;35NXNO}9cGj|Dl$v4lhO|o1`VTlQW2@xK_HP& z$7dV$xg`P?n4)^D4?hG>xF*BpKmn*A8$j9z<Kk2eY|Gpw`qiKT*%_{{s;fP{KT_KZ z8-3Y$cQ{s`M)~p~*#J!S4V;ZRjhG?QtE;@B042HL(hr+9?MIQ_=cAmqJz6z!I8Sg9 zcQ6eEW?ZTif){Q+MgZMg*zAHs8^_#xu;wTGeOZ8*oo_Cs2}4UrEgC<(O!#**?S7+^ zq(u8)Kz;sg`u@2M+X@0KYPV!c<^Fn8xWlDO*c&egw~I>}iMrVVpgP0G*VxJ)*cAEN zjWYoGJA3s3m{xH%!pQZNS88De=>;*9C%x%su+Kx4T7@c;RSWjBJ;LF<PSw@S>BD1e z*hmU@T#rm3o%6zdxHjs&XW-`HdF*oq0UB%K)H)1@%^Z<KbtVyHO#Z&$#nYB#%PmWS z*_pLZHekxUPtRZq8zDu@NnIF$(!w#Ld8+8ldl`sAT(38``v|;w;M#XK*mx=ONE#rh zX1iDGS@RT20Y0LfNZO+SXG>;$s5lfa<_VS!?+rKhy>lAjO%Rc&bg?^ZHp~9Ivb5*6 z!9{n(GL1PE*8qFMk=1^{;n;Dm)$4B^MQ|tYN3XP3K*qNbm>}UYA%WLoE+o<%KA`jE z1Dr`MW$ukeKapyc+Jey!Ns(?OH@{&bZ=@LLF|I}dlm&RHf6KfGrtTix;{X-<*7ew+ zFjefj<zr~Ny#u}IdZzV}I$*Qsg9np8*WM2xvuAL6=ZP55*l~jbG}5w)p{HecZ$~gC zalVGLWoO2BwSQ@70_OrXnVMNS`;PtW4=;Qr04#XrVI;<^$lW`s_|6M+u`hRnNI-ka zs-~KVP<Y1ZnI%Q2RDb!HcF>W6()Ef=YjVK09cgfiPM#cBONs+<oiGN05$rg}9-|bY zA@tSDi3W#j3#1lFhJ7HU(Ra8X7H^zuB&>4r<itWWtbC3{s%)1ZP5;!HI3e0t7n*(! zJCoLhk?H2!0_kEPI07e}R}Ws9NeSH(QBHwl{&F2iQv@DpUT1O0;-~f1nu0j<H`Mng zW6c)lt+$+y*MJP=%Ef4CS^juFSPL#Hx(+*1;8s358yI@<3YVsz^9D{xBU+|sD~Iul zsXur!cE%@G9?MpiJ}+{ifv`Qm-BV#L2(A#b;cQE_tBS*zLe{_uQFPFY%{AaCp8=W0 z-Ba1bso$8}2g9`InE|y4Kxu0|A7a^qB<9){3cUv$xQDj`;DbIt(mO%M$1l|VFbs$1 z%FSk+j&{zaADNNgRy@KA*WG9>+HNRB4#ug~#3&s_wt*lsuIaC+`A4r>De0!`>=rYr zKjSAjH51Y&oH;^^4~~hr?HTUQOg1$Cx|%Nr#aqupgla@(a<s)?64l6n$BA{b$nyi# zmiDre-P>4h472u)J{Sn}OJ1IX$ATX0RpiW#V;8+CS-=*$^oI>}HEtKHOfeMP=nnf4 zXaWjZ%zTV$9Z1G5n26I@7DWDX9XEpjrm9(N{-q#_=1Tt!u-QR=Fgf;Fh@mjH<ysMU zJ{-P5-hTYs`gpf$qk{plZLt`igSb|L4GxmRK9d{M(a@yR_}o{|VaJWP(Rxv}PS&I1 z$vITBel(T~Gu$$O?r<3h>nL(wPpgAo4hBAUSnM^lM@WDaxU6-u;eu{o&+LKde&nZF zN5^!)md2$VJ;-DcWr}Gzap>B?+h4q9b^BtTUL;hJJjN_r!oN1T(OgV4+YR^hDtdPD zzk*#t>IdZtF$0)+1;^@9DVTE@_3WF63svgV_~6na8^b|P1+SY#d?R}B068_hk|=5y zlYeFe-qeu!FM#7?3JUxN&=;(v>(ww&=Qaaj>Bq4`<bK@+@c2ojgb&1OZi@E-yoK&t zXSbPXi!KHV<ZV+foFJ831lnpkf`_N}f|bh{y%7SEX!R|YV;@(1a_e}=B?mQLU8wp+ zLE0C_br@^9-e(&BGx}E>szH0G0-<-jaDjt02SNKe&0pl>;0+ak2IO|Q*UY0q7{JHN z8!FhIBo1vyPXrMjs~h;K()0Q4x63O)L)T4;zQG!4+bWrqTZUdy5M*4yT9h%1(3cb_ zQeub`*S5P%?M8rOF2{>4TwWNX@e%(c_f6(?lVy-1LUlOvs7|f#<wHi4$>zEe^3(m5 zCKK5gt6xSiuE~N>E7@ybJSW2new&=xtc|<q6Z-^<YKY1d16ActVB8fxu`FahIAnqD z0VVNS1YC_by%eB{l8ij(3?q-f2pl+mG0||PN#qTXbe4H09c5x0FlO-c!#rIW9+S2T z!fb(=>`0FG<ZFNUo@*NM3xfmvNcJ3LKYB|v)+$Gi{^UPzcpTNi=K{9-+#l6=Sz-<P zC$A6sBy1RDg=dw)6H(iVJlRqRtX;wGHq7h01y7<&^ow+)@bL$$1Cv)6GmnURjs3LM zdu02@@;<oa*C>~#wrIm0j_0VCy?*chPxzq;XkQ-^|0t$jb8ngmRi_kQ07qE8e)9oW z?nM7um+)Dg$kbxtaNacH_ne;>7WKBbY;SgMOe2?=R#t0m4)<)Y1j;Uve@cYwPa;*k zA&7gmgP{PML57fdl;R+^rBkh4ct*rfzkTMK&kA@B`@dk~8U3Kj{jl3da?F3$Kq-=4 z)77|!$oE{<joaI7&;LOrx`UKcgzD{aC4dvl@|A7TL@}L|18(l50Dux;Euq}#roK3I z$HAUcjMDkf{!ryBAXxp}2c>;k?w!x`J;>?cj027S%A2(5rRO{S;fX8TUHqw3y<z=r zvahWJ%(jnX)=gx;0pb1{%z#kPR%Cg`>|iodwQ$Q002}>Ji1`B7?l50y-{}ZRhye-R zTX;|binsf~@KXE?r+~~W<d4Trm*EB0rgr$i84hFBKr+;gm-?7}N6{YSf~5C<5E)|- zUCixuuIev>2GdBwNx(W2FJ|_*v|W;pK6aJpZPP*pd`D#C;S^$^!87kmtg`SH3Bv-^ z89!9&y1KRQ8^-djJ$~pkfz6V>Jm|0;xDY^>1nYx|G;AQZKDeljc-NF*4?~bx^4ndY zP%MBv1fX9ozw9OQ#R5Ev<gh3u*S?qjXz_D`^wip6y|6)l(+8OSi4u=D-#o-{7&=d& zA%2dIurHC;MRyTw%FuU=p<Hqt{{#2v0j8%H&p#Oe`+P{nC9eFUQ`=<U1=7Vz;HS(^ zdQ^+WLO@vv+~M+|R1Mn0Z1P+~_YxjmTQ5uuNJ32V$k1N9Q*h(|g@4o@2H*MiG6}-W zl?{oNfG%t=*>jL$CT-^Tr<)Pbz9r9CXM0NYRpTZWG#5w$V=m4@80Y@L?s7bwRe6TB zp>BUUICM#9y#5f#(9{1Rasr)S+4*)_l&SU`)o!_C@G!#<gn!(#m4pA_060F~VUa+G z$%t2Y6Ck=>3d6=^M1pji*YNlb!%^^aG}7yLJj6@7eCp4y#(i7;F}hff7ez;Tx_dNZ zp+IjqgXIUZg4XC+-<ID@{N5rA6$;QsK-W0US?L^)h^};(-^9UE)zdd8je*OZZR6qM zpj~AHQTm~oTiyG3N*zoo(Sia%B07tnHk91%vly1T<uurS<NXb&Jn~kA{l94Vq}?z= zFm*;$W~2w5dp>>%k&Z=aPcU?W&Mh#;D{cLxKd(LI&Bup5QjSn`<W*F&%w>$s{jfrT zH$U7OMPICxZu8=cB~UGWl)uE{7MJ*ddme(Nm$_cQrRRx%LP44bHuyO0s!kn`sab+~ ztcuD=k_o`*IznJcWt8NXKgyF{M@OCq{hnYnzWesxHpR%Nf=*3y`)ON3#{9dx^AJqw zN5j;igC^uU?@7}jT`ae&wB7a3?cIjwhfSm=sH2SSS{pfUK|d&EF6`4KZb2~G!*q3f z!~m!TEL}aOa7<aIDFLBSC-XVB!bd>&NM`PkxsG+Tv3P<A3oI_%DRt=LCkBIp8<LnF ze3RQFF&nE0m9B~7t%(Sc+VS#a1l1#`!r>zGIMfPNqTWoCc^)hGrY;`pp!Ml>(#fA~ z)^0Qi<D4V49dAllCw+u{?UlB$!@6bP(|vk^O^c4x?c{lH%PH;pNf*tE1K~GiKArky z%y9f(QAggLpH~7XHpLrdDV<GaCx4}=(@wb`gDl+BWsen>hifikuIx@1lnG=XU=0F( zb+WjT;ZXU_{&Ym%gPaM#V`p+hKlMO$A>;J<3s9=hL=T0ENKZH8Lm9%hnS7_XMJ%kB z9Vr^pG_n72<c5%Spc$I(5(Hy}_L#-T*ebn+zukQYZ7?0_>=hjP>YcYO0TEvJi;?VW zJn)*MEXo{mzkJ#sxJ*OVr42<jj@_V7^Rk6sT)&<|A<stv*-x<`tv?X|%U~w1zGZr% z8UW6APNFk9VU<u;Tq|{<e)F>hu`U)rW-ID+ijxAXpYS}tF)#HY^{-2#BWbn?WFJ}3 zXRo=kYN6NXU3<h&&lxAWVcJ2kh_jeh>e^e_U?wCNSkhMlt@$^?jz2ND*M1B=#&i9{ ze;2T5nEMdl#jnivAfy*24pn{>+-G_i6Kg8wu_J{Br5$i5mjr#1sz~q}HaM{(4$;=t z(VWt_S>*Ig+BG+?>wZdnz)@b!b=?D&F~BhAFt(f=*h4A=O5KtEo2Jl{&~5mhAr_;- zwX>L6!jif5?hi106OGfA6aE6tg}az3gjF)ncof00+y*|^NI#VS-1?O=MGRj$aLfb< zVSo)el`&@A(L*e5BU71L40kOH2lk(IihCScFR+6IZQOZoLenQLxL(O}2jwN0tLQ;4 zGWhiZ=4|Cd1J62aLA`o8{V6{hD?+cX@K#l|Ng9`XwTWszBs}Fc76APknHjEWC--_j z(r6K1?#(}F>cH#(Gys$%7m@E5s=NTD7FY-G(2TF>Q(?m*2EEEk{Zy#=F16@zQW;`% zkncjnsn7y{nX8OxhBtp=Zw;IkuAT8H62pkW+#Ub<yJ{TPu2Ll}DKHWOE*^}Te!L#Y zjKv8&@U5n*5|-PsC-K{QYtblNS}!P*&ByEyId9=<IcXTP&+`lWZZW|8>%6a0pL70n zGOien0nLvC-Td5qJ};lD6X`Qy8LmA$^LI;&4PL!?s%elCM_M2JEyXGMNfL|c+f(Ta z^c?v-OU18`0Z5|()Hy&R`Wz;f?k~Frywc`;@{Uz*C2AmV1Am2^&oRaQ5=BbprN8G@ z<JqLIBU4F#|CPUE^_iMEK4sRuqmq5=v=@LiU}#%ArqgV=9S1ywxRuR;KcfC4w^cz< zyUVbua+vswUX?$;DPljzZ2P1&)P}%!v;WLK0zA06ek)Aa@oi!rWnK+*UbcDlkXm*S znO@vsG!{nd3zU8Nkw<n$9%Xq<oQXpC@TG$c$$R9MuZLye*)$hw?Su5;*V04v0x zF0>pBIa3;9W07}t3zjKciK+aIsZ1HQ;+Lqh(dElI1DajHw%9b}4Yu|6wowF#6=9Iq z6Aie>!bAuA7x6=&%IPZDUwoUi7u%kMy2$_i;&Y_OcZwk;X7$hCnJG&~lKab&5VFs5 z;1**`%fseX%|TRWu_}o;4X;t?#?_6EKHBxxiwjar;bPFJBo(a9*wU|dwvTT@kRHI= z^#nnI*FT%dCcTtaKL0!NS}&5bUUOyn5wtH&4l6yj)V8GmQLOZV07$?SPDe2-j<%Kl zx{Y9SFH}uv$iXDLT#-jAgO)YlHC-K#h3gq!>6Yt856*qGRvvNaq_hY|FGgK0aa@g{ zx}%l80?^?TQ&`4kiBE1evrqo|PxF7M?E~e)?32b;4rC<a<t4cQ&TV?a;R)DK-Ky>+ z^*Qn<$`@Uac{ZXZizMaQvY+nm`?|eXKe<Rv7&+K%NS<~oujCewaAP!nc5MGtdB{ZM zxoD2SaL6;WC_>AJ$<h*rBq;Rmq>^ydj29rXYU6qcU4x?0K1B`pPDD}P&nsmqW%Ewm ztsLv`VbLJ+8G6Ori5XR5^oZUYa(svnZ#uvg(@_Y*gjd~Cuj;a$A}i*ixXMs7sJ`!} z+82FwGkH%D^yU#xgKq{8YOgfGo<J(fP`Mg@W2Q`kOhc|V34i=rt^uvJ#(v*LIZ1%7 zUi$gm%C;a6`S~36-JF5K?kzWeJB_7V-Gh8V=k1*%ta%0rQ=a7Pl9bh}?f_ko|CzVx z@ZgPi6sV(3I;LkfV`4Vas`O%v)I$HeJ2^m%#+C26!~!y+SB=h7<ax@hr>f?d&l_ge z<YB_!2Q3-~D~88E-nQT0Ia*?r`~4bTw2=!Lkbq#yNcT13x?bwVLJEsN7+m6sIr9oK zwR=>xs?^p;<g8{Ep#FKs=;C8$GP-IN=oGn-R6|9evLsXwuZyc2#(S)2oo3r&C80Em zPPP^bN2HrQ!|NC6cv`<hJI3-M6Ot_$dzV@5fYb4TjDHLJKv-H{0>kSFX9;NGI2QmL z8a|}24Q~P^LvlA6zKUMtJ===x<<2@sNAn-GDSbgok}~I^e(8hDrWQi)>DDN)X-#+A z)Upt{#+hDwbRy@e4i_i-4oumY2K|_3dXc>(IXdaIBm3)_Gk$xiVT(s3+w`fP%P+;V zJzHJGvLm!35@>6lZbx1TH8dB*^nemn&x+vDgPm>x3G!(7C~s*1ih+X2c<&_;EeWMB zF!MS+6F^ocL!RZs<Mirp75e2DkX)bbUOMpFficMN6zcNIKQdZq?oWxZ@ls>Qsw8hR zs$X?Umcw$F_Y3=9W_x+jpSCHyKLEbMIE>n^+u*9vj)teLMtPg-8p{<6G|^QD!{wS| zWJWVgthl`4ixRPz$@Ii>waQ5oTcgO{7>7y7Mo5Mi${CcBnUZSjgL#d$_t(j(d>GrH zDJ3B$VU<a^hRG&1TFfMcEY!sOJePQV)U>K+FQ}l6cVl_?V;W>(NidVrm;779TjF}t zp&|46CxV-a6fzhTGFC63K#Cm<+Gx1V^`24NMqI}7+=D=KZuy$y`Fciow_0oPeWA34 zpNVqF6g5dte67T|YXTujYRhu))$(24dSgnjF74`iuj9C%&FCR<sAGy2w&hj8P0uO3 z^`I=tzVG7ArI)i9uz>;=<wEptCv93f(!K;LHmVW~6_ao&UFPZ~2gEZjnsB5eNN&CG zL=~3}JF@rWCLOk{wRhQ}4VuXPsh|5^cB}9=nxcG?qow$O+>&8%`V#$JRHnj*EQBO; zrHA>eK4wJJIlgj~>ZSecf*$Z4{f3-=sIOvh%glC`hNhqX$Gvc-<by(mV*9cXiqqwa zdR_zPAtTr~%r`&)HKA@7`Y|2CE1gB?b4jAQBww59d_pz)t%7%EAc|A9wM(1#e%C>{ zZe=4+$yN1~kx|tVTT$1?VW0*ii!!t`;paJH6|#E;vl{OvYk)F2lX@KG6rG9yMNl@L z(qP$e4~>y7H0~B>i)Zg@oXfb;b>EHb1JQBlsnWV<^cp_6-KsOE*FGJlXjP^u{PRl~ ziRSCH8ekWo+V=zCmA?`TKzW#rr)BUK!Q8{Dr0ABd_p@)<7J_;|bRRR$%J*$OVVz$) zj<s${)LCOZxhi#wK*bJ_ivlUDsgbaK*J4UggpPDc41=V71>H)|9n$N5umq2^mrgXB zj}}-|q+=Y@s+q#?*tDlsvZm)E0Q5Ib$N#H5GO|~2w1XM94u*;PI;iT}ix^hsNXPb} zJ&0!y-4n0e5;=6$L0>=ZP7D*yJ4x+1@-jbwO`VLz5m+qW<BzA0nOb$$(x<(|fR_}g zBzuf6pq3ifeY_!kyyvkU3~^f!F4Fsf$fLkIP@(9KIP~6%!gY&<mmlWZ1Rofd7F$X6 zux~Xqe#$MeH>s^R(kuJ{AsopqEGL<t7S-4J_`u26)k}opu&78z===GbgEQ5#ls|+7 zicXL<w@5^o)SD#5!9@q4L1d-B0m5koyigNuS2s!#y;y)y8IRHUV1nkX(eL1FZ%mpt zU8wJW`n0Otx<<C-x5=K`rpL@pcS#XCH{CcfX_(WPD3?Q5a4@a0_1RA#b#9w3=C=v$ z&>bU?#V*~oLPu$GWVEc833L=K%w$xK;8NaAq1U{v%n6-p<{{L2ZO{c1ZNhM#?T8H` z=VPn9SYjK@#8&@)Ba@K1-Q$Ioo?U_OJ>w>rhigga`MICZD7TTDSmOm*V6z-X=Qb4q zGABzrz^Z>Af3JQUTcr#%yx+Y<`%Mx+ZT$RhyX+#h%26l3c5hfTC9k+$P1|Fs+~<eU zEQ;A%8(uq|UJL3%Q>3i^8H7^X#AX5M&%P3Te=#yCuaqG1q_cF>m_z>USxmC5CHi@R zLjI({$v9VWHIQ)D@b7M-<_9B}`sA|wn&)M`w^Nz!@EH0r3{os?^<-LdHPd|*z2YA{ zFhl=~S^^P>ym7}fDA+h$48sCmKY1AD8~KicRxh3QBXEbl?M|4q!L_RrevdL*UU8<U z&eWq8wiLfanl>a0ejLjP43d{%E`6*o4HaNz8n^(0DgLRDbOGpy0q|b8z&luJzH320 z{Dt)-`olz69Yv3PFN$9rA@rfNFJr20tm+@kV(0Zq&;jUn*0`!j%c*z(f=Ivy70?FP z)zj6QoDUmy*2gI7F_^J$^xP<E0jp%IEf;ytdTY|VuDPJ>T987sr$pJ=S4}nxCbl!K z*SnE-Pko{SwltVpYtNlEQ^CuCoN{=?kJN0~s*xSaWOye|3KN8Qpju3VZ46IXhF~gQ znJaevGz-yul?m$6x6hrEP?wR>BICpLc7nGa1gL6BhOFKqBF{%S+9y5qhNEloQiVrN zOY|>r@5J$^PlI4Am-u9cxfQWT(A4$sDsZZkVW*<f=Ln+?R9W_R62ve7c)HVQCj_?? zgCR_Q=(6<6$GR5Hv=J9H%nb^Hlm!W~-DFegyi-cIIxv*y-@qj&Podg@9gk0leO4Lh z%$+BZp4ip`D$R4Lknd#m@4E;;`$hMwD_)O`Q{l6m-3{K=6LMhor9aed#fBO#$&@r# zzkwU$pLAitB-GYQ=fo8TH+|6_enN<13VEz=R8K*daW6yh&8z;#c<OyyC;&Q$Gcf`{ z3B|%=Mkd(%C%l~(oA0}#Q}1&-MMx}qQ1$(6LNK`pd?rb}|73FpUD{2A=Au8{zJp4~ zh{l^y@UnnQMo~NSIUX{fi@P(NX8^frh0VU=_c#~y-;7W6FAjZYefO%^l0b4oJVkRk zCTQ*Iu%43R{wKCz5XV-CoB#hW?0AV&X5A%d&J47>`X%;QhG2kbnDu8NQtP2qdROzL zf_@u|7sF4Bo&Zy#^3`<)4mU&?^Thjnm$rKaU&B+atMr9CzPl*$HGwQ2zyH(E>y?6= z(E_vPb#Yc9fd9?pYLEs09=c1YAr&T@h}@Gx#h5a=P4xe&*zNcl#k1<h6?6Ml1^~_o z`@gW~d$=xQXTD}bifh!nqvNhed5texu!rB2;|XpgQMkN<?%dam=1(6;E4PRQrBrWp ze~wfV{B%!^xl>gm*}_~o?D>c3)Y-1RV228e&YRsxbRlNnp};v_7vidBvDH6>;1xsm zp{JQ4M>wLF@a5jNF3t-8G<<#FhyAC3C_dO$RP%#K@Jbv@juoaA>g}e4ncLZcZ(hR> z&tc^txd;>YTCT3U0ciTtqM#EyY~w1L%kwjwMnJrN(@)~TK`M-jIcpOSD~AWVI-$hO zBVMS|%_Ma6=AE5T(954cE^qgl3L9NuXg?OFGs6Rr?A>9y0C<M9kLbxGL<Yjme;P5* zvhleDFL}j86I^0%;2E&TP=+L~-k$BdSVPM|fVYl^o(2^-G5@<j=qa^`61eFoO6ucF z&kG{DedjPIl&U}>Py;57b(KD5x!I?JlhAKiT~NUE&-@060)&td=+R-U&RToTr_m(c zhg=HD2$r+hJwT!8|Au?Na60_Y*(Ms-xAcggi~2C2CLj1^x-f>e7Vv{DJ%ib3H{9NO z2#|dhEwOUAqXwqQlzS3{5qs^#9|2}IM|S#062kS=nE_^{b9&!`an=9-+pNOy4Hc-z zMDrR9dtdA2?bC{<uCrX4RbOA$B@JD50fk)EkDy*jvsVeGu6n7TR2MzZ+VGC7*7H@P z?qP>>e{SiN5Msamg8&LY_zi0QeAQWxXQQmUCU@<T51D{&hl#x`0aexdTrS$rxuaK? zO5TAC^VBJM#wU7A+zGjR2~=yo|CvVu#IU-JWDXsq%n<?j&yCRN0g4pzj<D!KO!EGD zynS(0GoO-@qqOsBMhl301z1s!#1ehr9w5B>spY?kF3%uIh@Lm_n!i!kAh!k|a~9A5 z&7u5?|2Kvi2et!w{|LPmV|51dH!%4mx&0A%YZUsQ&A`@${s}@pLAt?b*pok@=U?C+ z$ot;_ULTP7-=F^9@2&%ozyDCt_G=m!ISeTIPg4L`QVu)X#?kjbe#HloE(YtA-C@@M z#`2@^G2}j=Uhc%-DcrTkiC7S9Z~`B23aNr?biN14?0A0fU-X^a_i(G7{QAsRB_Khi z&|7K$S%<s!WW7WQ2h{S>pfZHu|J&Dp7O0I1R4oer1`Rmbhd)RuV$g2nZDB&}p5#A~ z_dejch~xFYyOPpz(kKuP7w3CT^gkzbz6VAI>D7k(^J}FHYTkG)1dDZE)mq!Os?Dp8 zDIc#83z%>Nfuyc$Zfo-6qf6Re)7oRV0tn$I$F+@S<0~84*Z3TscaPSNS050q_EcKe z?Y}OYsD9dtdIza-oM%c{Xrj*Lv_Je*veiT_T1V9N;ScBi6K>9T8T)L(%O+rgZWUFB zb=EldeY?CP(b=umeQmh5>H*=3=X|2;P@=!6U3*%;!UgKhE}@ybb8|k}a_($|%L~5C zW2Dd{H~*a^1o40PF{MLZ63W-g%C}~F`}<kKE%sY`e5+&bKDr_1EsQnWO(KLgcj;ur zh59l<RBGiaX3X89NT|ednmyn#hOwN#tjeTIZwIyEysG$fpn5XU%ajkzMF%-O2Y=Qd z48Yqs`8H}fB}Zv3qd$t~3nRl5_T)|Ei0h*@|EQen&1L}38DSg}6Zq7d3e$KEK2~qv zE*-G@>w_<q*SoOHocK}$D!A?z{*}$!=xNG-ayP6VV|p|@-9Oxrs(Dh)-TiVXknTBD z<%K?K<!FmvAu=7JT;TSIMShbxg0u+~TTPiBR-as;+hdD^KD*w7tna(_`!6ol4I?X( zcX_=Elq%20q*92kxURMmdaE`Te1^Q3O)&%&M5eg`q>Soa!H$cHGyJZ6-{CKoT?7+? z!b!T{bRz=;;feq03<q+BOLF8e&AgAfq5H*&pS>_6oZpx4In+3;{bqij;X?CjHKk0b zTz>%qy`d-Z;kDCaDE&FC%l}Gf6eAchdnX#@c=Pcu?#Y9Vgjes%SIHR`7oeRFu|FFE zE8yc%eS)F$_NJ^CSA5};I63tnxqwS-x?RFG8<Ga+?gx3>Nal4>HyKc?0xSF;&LfU- z5e>-DUk}GE#(z!_kVF+}i<kAgyFTzmU@FbVolyae4AP_5YcmvpS0SxoB0`h~6Uz;~ z^zV843&uh)61yp>1jW>eLoZ`s%39E0olaPJGbcML<N-IC4{nm15C7f3f7i*RjWP&s zQ_T?v|DMl!u=5DpD0oQSyd^6CBProzd5>UYXGH&3=Gk>0r;J)L)jQNj<@LuIf`%8c z>yN~S^&-p?&`SY3sN3Lqo<IWnVDaMm8{DeYZY~ZNKQQkVI)OI(GshCXRS6%<3Q-1; z7xbur-PqPNP8Y$v$n`H3a0iC>Pu07T0ABn=cB>X>iMa1XFyw1{KG6~RCr9$m#T7Ys zpL<%yzFaU)9wv$>P~li_sKs1xh9e2h&BXWjbbB|qn7r<I3ZuEqk|1k1!RRPqg@Bq@ zILz{l&3;{+cNFX{_xdLRurVpYbNsg%necApp<bp^a0=w8W4qcTddVqm>Je62cZ8a2 zy5!geWzzcyI*!BYS`4f)o}t&OD-b&Pf|*P$Xru9x#^IviQsx51gbr$m*?q+n--mk9 zJb|Wg%nhDD2nUE!LgNz^qh5e0+oV%z?I<B}w~;K=o854~d2#+|zj$8fqsY-eC_dNe zcRarGr83RqTSt(%@r_^llr&MDZ{HonNA+~A0=5;()+_eHId!&awM{6fVfCj54biHS z<r;=^t^3p5J^kkYue~o1gz}62MwaZ^LrnIBtWma+N%k$WN0#hl3l(Eek}a~v$WHbp z*|TJ?8Ai5BS;~?nnhC@3yQBJk`@Zk{$NT5|$Lp{0%rnn(@45G$d(P+F^En$feNU?> zyK%c6GHV$Pr_Dwe6pvD28Eo<C%))|o!57{4goy_TQ^FHJd;uuzYWP-Fx&-UmX=fLo z9Kz7AJh+UT>d+YgXI(fzC6gnnz+;b9pzXh;(1Yn-8)ScjM5FX;-h(Yx^WjIRJvghb zr32kd8T0?*mewS^G%C{g#<2iF?Sz~P-mbEKY=7p)T>)#4{5JdZ^qL^A?X@RliGp9) z|L_qRM*8eId@DTcYFCrn)|CRtbTRR0gYVZ9p0Vv$4l~>K_8MJG9qBE&L26HvT_Zi_ z*yH`u9|z_x0pT~?f-lLA3ky@aC|M`>bm2@+_)Uw{+DahIlaZq2okgqs{^4|Mmb9v@ zZw`6_Bt)|6^V_D!-ZUR2vNC8cFJ8NQC;PR}5o?U=KDr7b^>*rqxJ__IUV--B_Ob>G zi@Ivs`HLKc+#tes*Bu+b=j5%fW}C<2qgm}blbf;>F5@tHHLXXvTg!qsAsrt_zGmSn zBl{-nkzYt*d;W;?V`OAS=I)WY;bTN2pQkKjvao*%AFE#XW#%tc##eh)_UD+s9Z@jl zT|_yR$6SE{5=g?P>3sqpWFSWq%N*%9Zt1pqY=my0hz~H|3O$StuP}+tf5OE_jn|2V z!m>bQ&Amb6!WwHQVrh@=C(}l5gzLD1I3eMjA!a$cr!#&wGi5wyJvrvG6sR)IwRn?) zOq*G9(|p*eWc?;oiT6+UB9<0yKT0GLkE@-vvYoq8JaBLLC*6h(kI@4@)_(5&`ws># zi)kx(;!kY8K(ud|RX?<xjw!QmII=DH7*`gRw_EBg`c-FNIleDJ7eltL^7c|TmagB- z%S$4#2;>6p=u<c>%%?_IiTR6$5wiA7fhI%jgUAmx!&SU-p@o;4B^#uCSSX~sG3Y}s z3?;hESb<;*$n%y%xUr(NN{ZRvl-uqrnSO{L=5)b-hrd52*y`?P!!Pa$<v0fTF6eL| zUE`SzlzC*5^^2MtWf{9i%^ChN9(K(WJt$6h-o4bD>2O>}gtBdvvGkuOgX7Y#UF}Id zsy#<>n%tMoAl@H`R@vGAdK?GpcuML78C8&mWYOKRhh%3{919H;nKwu|%Mb?}&ZDuV z@$YB}du9BCcgWqL37ur!QBmX4K@^f~itbrSw0&{U@!SytSH+PC+Ed2qGx$D}+jW+N zN#MU;kt|?vQFSyH#^e}2lDZ77-1s~Zzx<+#jbKx9CAD7=Y>Fs<tPh<S=9Y(l5H9^Q zTHU_q@I50RnLkZVGq~`_uLv<TEui#IO${78OAwGTq4?E57$(1&-D3B#VE%in?OHB7 zJ_0uc!34YT0DkboQ$qNBiO<U^^KaHJc(3>LZI7No@bOW%4<0-4U8Vh{3otSKBW3P# zqqx~++tPLHkk#JZJ0!8ST3`_qOisEyM4w-T?RjS@@`S+}z6`#&NR-n<lXji6n!ZsH z<(L7dQ%9oF2sy>X**UCxk?~CdHu*yT_p^|@%I|n&ss8i_hJe4MeOX1B9#mt0_fw45 zS2fa7&6YXZpjN@_IB$4#80X9L=1jkOg~v6ia>vjrq%>UH!@ww}dJ%imBX6&)xG{1N z|1)s<&>BM}9>sO9j5nw4pV~+Gi!z@QSkX~b;7ir{)`#Vy%F;|ef0Sa$H(CX$^vbwN zf6Jy?a0N{tGE5`h+M9gtWLY4?d=;tKACZCWE<CGxt|0yThlB2e8!-Md3&&ISYxR%U zCFOf|)QWsE@&^n}pz#~kDo{M;o4R9i&b)B(zALT<hvBQGEPhJ$fm<dFl(uC8>aw$A z15KZ>IW<-`(sfq*^;?-QGXXhvgTAlazt@Vsu$5jeh!v}$D80g4C~&uXrI_ViKd!^R z&O@+j^wN1w_?e^S?Y$&qp*_D!wx+f*kwC7{b5UV1Lr3PTLjZwK^GJ&X-rqoklyH($ z-PE9~FmX#>(NK&ECpn3pgi+F2@aIjLyETlLDBrYjeQA3}_KPt`nu42{XH8M^NqqI| z>5AJK=f=0W{E8~hOOu_?w~&4QYge^~E;?5>9a2^C1KzO7=2Oa!5-&bXy0yyVFDh6h z1x6_+yC!gxfq__;>|KziK+$XP;y`vr3Jaw<4Rf*qD*yVrD2u;ZvV*N;n{5p;oho%F z%K1l)#WhR076%b5mwaWCCJmyJn6Lt}m6<i-E>2xP+8{xpRDMv1H1l~Yvsrb6FgDLj zLGoJ5BhS>prkY%|H8t!BS&Y^67NuiM+WaJcTDjUA)#rZw@h=R8IwI`&c3aPxng|`u zpy0|!O240J6b@gVZyG!Xe5GReE7GGqZfusj&RfVz;>dyl1-B}eM#2QZn1Ry-M@F$; zc3QV`_2xfq`t6&^d(3@PN{IT!U`D~eYl=#6I(nUlb+!RGss>6%+JEQ&wrI0N{{2sO zD{w3ko7f*eufw<YuuB6Qd%$VgthBtPoEZJW62tKQR-1Q(tY@1G;^08G<HtH@+l=na z4{j(5-<!QTUAFsPCM5Sv9%4UXfGp|{q39pN0LG0PZ5p`&*)Ge8+emD{wx$TH;b4mc zTla13JEgmeVpA}RbW(<7bMGBeV4E`k*Nr9EZCAn<Mp|xf%qYDW<f@Bh@tI$5YvC`l z+}oIG>8tYVQF?)HaWDGq#Mmv-_&m-kKm-VTC(nG*k0;J1!?CmcAD%f^!D;oH_hqU; zDTM<oU!Gi5?BzKRXaR4j{TlR!4KOD76h7Un4pFBM_A<RD%Mo-1fCW_lyDe+4>X@{` zvb=DAHP>v><3O$mLiMQ9jb)9POFZ5d{{fZlS5nkV0=#6KNVwu(n1GWHj^}pkKvlsL zhi+X^z;G)v?8Ng2Hs;V5g&A}#_HmTJi%zJ6A3X6SqW|Mu10ye^1a2m_F+%B4oXRtb zJa$)quVXl@^%9Pf^X~fN$GzV$j2DauLL5O#Hxn!VVafnxxP5>O_ZQpC%)KnjRN)od zp;mN2mj-lT+d1MI(*%7ZC)P9W-M7~$P-DX|>~D8^^P|z%yU<lGHLNeX)plSsL6-G3 zHXpw=QJCiL2S|4QJ7$AcO}Hd(QEf>)N@x#L*KwH2U|^=sNv0eD{97{I<`He)5i^2m zB|Ok<_PR@@;SfJdH*-l4<;Kjj0C$Qh4b<YZ|D_F2%0PIXbvH6~HYq~$_GO%=jQ0CD zWqf*P%xJ7Eub<<RlQEnTxA`yaf@vB2OioQiQ29*_t_-e?&Fz`71bIxi(v6>d`9whL z*#{l&SN%ssPbwhnt@igB9!iz0IB)_svD4gT2=g@5J^x4^h&V&MHng4|m%#`o`Ss#l zi9blopj9bumLsJ{dc*55?Mwt`;BZPz<8T4BPfT3mj+eAFwk>P?vLwFs-pAq3pYN2< z(?APu0mS3Kf+&Mu$eE=qEIJ&zENblgu;?k{2M)h)GhFQY{b<9gAAtJme4C{t-b=Lb zhoMoM)9c)17&M>cUw=$3L&Ovckl#0Q-Be6_>MuQ2Pnt0E=#I_WoodUPZsbPOoA%Sp z&T;W|I-&N%09<@zLK8Tq4ZjY)LmnJtH7+qX&di<elNIUkjaKx*$2FG2W)?D2-`a+p z?)&t>MCe}2M9cF5JjE^Vg=Dj4cjjNy?5}k-Xf=f^Jq_&mef{6+=3n$DI(qluj-g!W zkumV^Ws1Lleq`Am`*(r;Hlv9Do-qUnY92)X{)_8)hyFcVkBo|-&<(^PK)R0o8Kz%& zTi#?yhsr-xwnzMfrvY%w{u^K*I3r+_AjSv&c>%%E#T>f|NTUBzYC!vg^n)Xf`kTlF zl+*t8m<E6&0*9g?FbVr3&F`2FH(+i5eF;Es<(xORg4C%2<$U}RV&E17mIR2*4m;J? zkH;f{zWj|V+U7!#`|ptNqz-o9E*@lpn-LSE7IN(+yT_scMEh`Y2Z>MjOnIZ;Uh<{E zI%qQ=tih8@PL=6pa3YOOn;rQ6rH@3nflq{9REIFZw>JCKph(4m{Vb=P-8lLs;@lh^ zGpM*!Ci!V0#6k<I^VZ5<ZV|ZTgLdW!eH!#R;Y;uGd^9%L0B{5w5X1F6pUQMpY=k$D z79+m+pI9xIyDie`Dugl?^qBxZXa(uYK8poAhQVxOPwGJy$&FajvE^+f$=ZE*D1<vr zL5MQP-{Rg?Q2kFnHtveAh}i@e52)Beh9}Z*)o*TntW&8=WSo)$myKZU5GA`LzwdHO zOg0ztIW}RSf@zT+%Vl756;xOuyR$~By~WY_9!3AXH*H}iW>Yfw*jQQt9JmjR9!z8) z+agr%p#6gagUu*Dx3>U`mZhwSBwU3qm^|8X`AF-kb02PjqCb<-xA3(l=u2=j=h(?5 z3gf85GXV)(FV{(LlRptRV1b*hb9Y1RYnK%h#}lZExXRNnlPpo}EHr-k$)H@?qEex` zQtZ;V=NGPaN0$UogxLQa@a2H#Kp`B_bh;GL8y|DGi*AP>G;&bd=kSF73Z22Nt2mc| zg4ifA7o2%gYVK>j3&b=yV(VRE+7OTn@{xE&R|^_faoV{t;zlwWqjmU#gq`@K>kl}t z@0tj8QkFWJi22LJ7xLyE?Pf|>JqzfYaS++g@T|IwsbfF0Jav+?dYb2C^v0f1JLC}5 zI%OJrS`Q~m7wqT)r%;#3OB7J_C5#~lS#08PHe?`z4GgMqPHW&MyKeY2h@4A@%+q7o z8*UJVe4oGD^a=nVU)d*x*lbWkWP-F9X{7Te3GAQG%m04%8kwd5@jpdSqe~jpLd}JM zBMm=5+V!cWK0Xvu@faR3+-@ER4^V-El4O6~24)(e`uY=q3j^BtB+75m$op8hBl(ik z1yq7Mh&+H$7x;o<$tfoc4hp3OlHxL)auKsCP;Nro{$IEaG@4MbJ9q0>-=u8up&4M8 z|G#Xt-WzNklOL<hMJmhr;8VXkH>Ls3=9(BK^ISRsD!nrI?qB#NxzZ%K{H5yBffGv< zI@F-+=SS(A@+t-r8TM;f_l{$ZT>-+<ivtsZR3wvzy%R#fPZ)8;`9S=|S8(3M_)r&O z!boTWwG~73_a~<-7_^mu$e9mq4eX?`U$c9)PLylfi5*WB7;zRY-yrQAckP0_VMXL| z-F`cCQ6VelXWq44@-U>nxVB#{UGUqSOmi1>P6hTEEL^Z0(RWfeVi3I4NfuM5Axk;C zF2)%BPHV_NP|cQ_U31c+AO!Q0Me07vFiCWp>zkwH=?e25-+k3Zwyy3x2-6i!b}%b~ zWXrdu0dskG1|?pm^i{yP#i=Mi3$gJ&6?}ED|F}f~qwJ%LdfVQ{4s(LaLL0fT1)^@d z=W2WJ#lrLX<pX06CM>`q7zu&s?^R~EDn>Z{O+f^bFcF;uF|hkncAPS${aK7q4XEx` zw>-qNi}|8wXLDYY-uNu(Zhw&bZEb7Sywh43Ccgsz-gC*<Y2{0wUO(#^@eRb~{yb$| zverDlRL}@o5XFUl)!i)Bm*l5&ENLlXUI=H_dQphC5E1WUZx=F<p<y|0T9e%Td&WvX zgPg^cj-AFQ`j$i8-|Ht^d*rJ6+qt0nKCEjj_l;LMH%4Ca^M7xq>!h!y2h!aLi$ISS zn?J}P)5Z*x+ioCL!3SMAVf>_#VTnD`Q&l8<G}DK$e8JjtRD~MbNY!ZP46>OfJ7gJ# zpd=MOJRMF{UkH>}oHVDs#`yRdM4oIz@DADCJl3^vxC#)=(XZbAkW;EVP54Rm8N2>X zUG%_=++C-a@VRt3X%LnpEH=>e^`TKc9}i=0edzR3odan~X0e3^)OnBC{MT4rwoeN1 zEBE!rr`ul@t?zf9&7kSV+WUi;<I%bu4u_xFnX;PUH>~e2;_!*2wHU?OI!#itk3)ts zys0J@AIGN9j?-^H!#1*k%+p^zx&-A<FeZypC$>;GkSaxFmuL_9xBB|}-IwVacOSZe zpR|QF{b^txqQdx?<bX;ydya0>SOV9C`&adoAw9h$g}KwlSD})1O_;h=WjN9AVPwU0 zqwCW3TH2cI!cWq<UFey;$P93Y622d>v`OV&h(oo(+1STR<uM~K4@EBSCo1Ou^jUEV z(`znG8tZaxelH4)bAnRKAj4}Q)6|46CAx*b&><^)C0GifGYCwl_qY{BEmv10|4nRK zdvVUFfAJ=j>x#L&`wM@!wr)heg9Vh)lPt@x=#7~elAvLKNik93MPT|TLG8Xt)gs@` zaV@iZR9L=BTiGmrS}cWvW>Qmr5jxudp|(_9hhY-?c&PxI^;<Cl0hcTcmB8%6c<JoJ z9AioAVdu}3(Pm5=0XnmrsY8Mu6<2EBba4!cI9IvhJ<M4@J&;H9n(Pi=4F)s}Ugup8 zJu7{Vv$%WEmEOAq_0<KI{vlv@U$h>NbCIUT@#sc=QKV9JBwBJhw=+xc%Bv}iyMz5; zKDYn8IU~Y!=a`cXx<WX)0<o=B9#aZSx?fb_DAPzNJ}py1rw{+3nHH)wg1nP7FhvdS zf4&v=@Y`Z=LP()hfc!hZRjuOgw4E|Wrg8cbL4E7iB}M~w+@0%IsvpL=^e$YM-+t&h ztb&1UH3im4;hs^MqGsC#T`Ih*MvZ`@(iDoBKf2%CN|nZaI4N}Tv8QqSn)-qf58$$| za4cQ{_24M;5OCrr&ma}|vX$;x2VBrxD!vL(kuOF9co|lQmwMInpdO?I3Tc&#)1)pT z1*eyXWWKgmwpb0v!&P^UwV=`<49OOW)1*53@|*0tBJzoLM>VMAE-**I3M7-n_mCNf z!(UF|yAIC3(60S?8?c-Yy}jOkWng0GI`wOfMsd`)o4zMEaYJc4aoVO`z0RrcuF0?8 zl>h$WW{1a^H=ch1;JN_DV&lg!QTBJht#5j_)`lQ#<{GL@y9J+7S7o94R4pXsNBM5W z-lOp=f7NnM4bo!w6UQ^EuceGa?x;Y0FKIzdR1UDdQCOAH6VaD56P-1h6b+zNL%C{0 z7v~|$@5$(rm~oHf%HcS|+Y;#UL08Eky}JeN_B*-jalo1y`d+;rm$V;~usm~efT09} zZj+qTt?UlTXIIJi>>b=Efss1^cWid!Qf-%R1zBzPq5_ydvh(e7=2MG>eB~ECeTcKY z<5j4Af9t9Ao}GPIx_0oBDnMN-v<fRu9D&t@YFr4gq5By=k^oa?6F>Mle?#$r+NKw5 zrfR$Id+r#1l2k0eXRnxli=7+1`!QM72K4K)qGJ9%dr<avRW5Uxk1_`xKm!YzpKq4C za+MAilHbjai_cTA=MTxBSMA&Vnta%J3yffF*3(<Df~!5$`3cXrw{O`fIdME?(nU(* z)A_0rlda!5)NijAPW;r(|7q@dX^Zq*pD;uM&>`4?l;h30!^6Yf4*W{rc-znI!m@$} zai;x~H$QanD@bGP<Htr&yj(H4c7js#5A$3<_SoW8l$FEa$3gPxhsN7g4r|)-^U1!i zq%eFf9tj!V4BNgj@On4VO-=f0c>D7S>YdNGR@UUfyMV3fVGB4&<{HFn)N7kAz@R=3 z7pyf%xDKrLNw0SNC`Uj7$w{_))0A@?zeTE`r6Y<K@xd<XlG)cbr_*GFgxEg!qx84> zQS#pS{>~h5hUEeorqJot<o+B2-NG`Ky6o3F<P5RAErp&ejMch2&>7B-OS&Amz>J+| zHdyH(Cn91K#;3@vN+>t0C;fEPe3J=31?Yo_`a$hw6XhAKz5Ht?je9i(Ti=SQo`}P= zQ~+Z{W-G_Y_-A#SP<ckQK0o9WPEuOzs@Ix`yJ~ztDnaICl=|S}1$ZV%m?bG|fu~wj zP@enLi9EFPV;ZJ^2A|v7tbnM09GZmX<ymoU#PGfG<o>Csgy$zU4!|dhKh_U`#J)Mb zRNf%_g-7{Dr2(G*%e*C&v3Zirm~y$-&M@7?*{Hbru(kw-Nyg9=KkD=g&3mdJpHT$2 zBPq*=r`n6WGb(w!=RE*(8J$|?>wFc&gVP-9tAh_~ASS7hQlyyy{mwmgi<L8<Izr;k z8t>;knwc%#oLItZK)?3anYt`Kw}a&8Ew2bM8*pLK4~3)WSoRhwH_aa^WwH;m6(Hcd zf#V517dFqs%k5;wDQCAIJwLgnT>zm?;T<+ubor)E20EgX^4<LTjrH{22!DPH&2q1P z1-k~J*Tzj<)>5?~IK?4lelERq4Ly-?{5XL)K)OR`Rx&~`XM_hyo`145J_^}Ut^FV) zm22)@0sN<pBv$-VoDn5HF;q~|w3bl?nk(A665WtA7OuE4Rz6u5VrgQ~<|S}y%=hpt z^%9A;K-1((uz4zWb$6&L@;T0`kZG!~Xy&V2MVcZYD|4x<Z(<@<$SP6_P&)pCpGW_r zWCG5@>=RYEp27^gu8Y2B(n6Y^ca_vujyX7}X~Zlg$2%-~u_uS}li92|_4F+4eOkng znh_cLdjZ(D;+p|zIk7<#KRdr5;#htBSX9|c@zgj8m%GpAB8le}KsV3NpuF!kbRl%c zF6ww5|J^4aNwdpuawnB}ZKq8Qh}LRH#t%NqD<~A;8bH@9(z|$O1{{~<iBe|00|5y_ z^nfNLIjVZfwI<TRix7CSeei^wOs3Q1d4p#Bq~zuRuYdwL8XJ<*XfGuJaUI<Cw;<&d z7^4qK?0AGM%(g9n;7H^-W3M0~ywLb|OYY{ugpeX8^hl5$&0TU<VA`;}qc?rQ-#dFE zG7eRc_f{aA_vG?tYo3c5ZSG-KH*$#d<);`8Mb}<pVLk8RUD<xFKW@&kXpVUMIY_Nj z*-A#;R>iVR!&Rujquz}nNm#r*?(-luo+G86U<$7!yYmYmQl5chAnvbnK650(i-g;A zJ*IfcSE6-`HshW=UFy?_V@YPF4td69tI?UnzJ7!(Aic^;A!V*Evx}?_HPmSsF@FH? zNl~fqju1jeCK}dwgMRxNelxXwt-h(VY%u~Ca}(iKfpjKGGPIWnK!h|Xa2!2+!e7g9 zdaSk|X0^s3lE|&I&34IUoPzA!v}gIk7`=Ylan7^~J-fcmbGjTFriLDm+OGkZI}!LW zdgrk)0eH6M1NO6@i^}ZfD<9cuaCrnHvXagDFgX>B?9S0epbH`%juiP$F_5%Cgho)3 zlJpTw(p_2(pL2E*Vwf6%8n4Wk!0Vd}P;|O1sD#0Djqo$v5%5rg4^x*5@re5B==5IW z=_vig*wRfB+_TJUJoxfU&{x17dOElwbapmX_i@7YJRywc<xfs_)BRNtC2ddqq%`cG zF4`qlFHfnG1@&RtnV9_|b&*u1!n^G9CJJ*DE74i0Yu>ZHr}6yLFW1O_x2*_1zPHu| z^GV&MT|Uv6A7*FZm9iQr1aV2}LcAHHhp?^m#Jip<K<uzZ8L9j$48wRXN@vM@kC*u9 z>{&Cb#OT$@Ggtgn?;1uY)f+<#(v<OLg$%30%jys?-}0)9bBrBaBaUz+n&M2{>~vbT z=CqY9a#AAV-ltvKTEo8ahSb-x?t<BVH3IF`(OdO2&mpy!ZQ>q@SbdEMDv%sGjrWQg z(t&x@P7EU>f6Xoyz&Szk(Y3*%wVJGt4P&RuuH|(xZP{GGtzw+RyhqfxlNPoqTs&&@ zV#dNr%pC8f>sH+GqTA90%J|kVa8S5|Ba3D%VgIEpUKalDF6VE7l)&v`oiuJg;AO9f z^WN{m<~ys=SsuESSJRQ^vy70|07uRcU+wxJ5^e{n=a~S<G~iYz!+uY)vX$tkr$s{7 z>Ti0}XibOfy*uaOnIzC5zt&LQ?PeRdeL42NSh~>R`HK=%Zmu6fItJ8HF{^LCo*i;` zl6DU-qL1|Wls)!T+%bx6ajAZJjOrR)GVP}uGr;2qg$Icw(7-4TgA;uRmETS+Q4op$ z|9_99!6qhgs?CZhbl_PbHO(b)HliCo`(do&5{cqVUr2~_;vt9OtP&ET;``Uzta1ls bI1a^2e9pCgud#Ve1pYMD^e$Jb-U$C6%GVz; literal 34980 zcmeEtWmuG5*Qf;usHlKQgLH^=4&6C~lyrCJAR!`+3>^au-AH$c2uKdy2q-Z$3PXzE zxk2=K-tYU)zw_f<=Q>>D?LB+1z4qE`t-WgR2~}2-zKcbKb?w@<yRtG8s@JaFf?T_H z)A#mGpr!Uc-Dlvx>n^I&V%JIsNY;Tbw=6^zMXz0}fMWkNLc4bDhJv!fb4j3G<W*~{ zh{(m$@bamyt_-{@D+67Mz>A_HmtmM3@S-j!3p`b2c@2YQUe)~u;L{D3epTP9q{L?! zq4=tyRZUSIc&f+)W942owkpeU>xEvtC@Jyigv!2ZYE@MPx_I<MWPo=SMFrrgtiY=u zF8`{z6%3XGo+?V0V}Tb%*;mcL2ly)QbJ5<atR&|H;8bh{Um&@7S5c7l0Wc`Z`!oTc zKkXNo<u2M4<a{rB+mtVH`ZcwI6=i`ZfEjoyE4C>sT;TC*lJjf+01N@1%2!WWzs3*X zi(Yx3#t$k=JbGaOLZBD;@cw?kq~YovSb|;{K*?oqxV-P>i+<RLOBg-?{<7ursr1h~ zSn)UH1r5HJQ~Nf40M-ZqgB5>+0bLhUUk<-Q`}-^Sl8noC0ES%Fhe_=XKm)H{IIn&L zpTS#x<7ffkV-hQ92@|nN7dMZQbSakhtdx0K3t&@rg6Vo?SOpfiLCgG;Y9q3mlZxAO zYkI5NMu8=?_0P6zsedxk@3FGzcXk|n={YpLJR0CX5fL^WANv`ex{#l@R8h9F@qM+a zakJ~w_p!0V)zx3We)S&TO9rS(a8*@OyLRi=?b~<m+`o^DhxhpLV-gYy3W_Jx)YSC! z^vul9SXntaIeB?`LBOAgh=hcMjEtOug7R}MEiGL`LsJV&OIuq<S66pWPjBy6uL1&t zgTuq2(Ab2;l$7-J?Ckvfg5u(`va+hWy1M$Nrl!``*7o-HuC6}dZ*XvQbaHZb_VdER z($ebc=H||~Z{JX;qobqK)6-l&k5zy|Oh*}QmuuGu9$fsp-b;%TzIH88SXM&xxu^bi zOL#i9w%e-ao!c^2gw+Mi8d@~&Y>ZE{xr*6m9ulcAVaGDr<giyJR1<1vfx^GXaN}Ug zxJT`Vy^hyfvDRQ3GUeL#n1%a3A5?HVXll&2Xxt=6@vWZQH?vnVa!@_t*g-5D-Hhe2 zm-yTpn|w68I`8>TeQ~|)y*D2DGrxoU`{a~p=jW4tcvJ?z&^ici8%P?weOvZKNDQlk z0Zx9lmJ;&pzHz^2T;c-&a7bn8<}TU|ers<E03aj%6UHL;t^Lts5$`v6LrPvm#Qrdh zZ$gilX*;B4uEX;2wVri0LD9l7cOR&}LRz6s$nWl$v>A&5&>4^y{s*efr&{Gn7Zg~+ zH4Izu{{PVbx7p+$hHQBG^~=Msr>~J#Hy`0HQssz9qMCgj9bXyu76+GQapHR5;5cMx zJ%Cv}!~v6Ka0-ISQk(r36|@vWpiwufl2$*}^gV$E^l2K1OEy6CV;d(`;DJmS7zD~C zw-Frvb<1V_C2)+&Q62ih*PU;UZ!@sAK<ty;NeEiBd;4AVHuAWj5fd!go<-Z)7n9s@ z=r!OIJ+ZYXB^4Ikm2mgMUD5unka^sL#n!0-@`=w3s&9N!GXn_U{j#VRH%Qgg`goHu z3_lY>`+XTXyz9Ci-c0I{!UKicL$DE7lfHvI2NB#Ox7yvwEb4k&FSiOY&)7I$83M&e z*KvU1v7MKDAZY}|&d6UMN6pS-y8c=_1X+l&nd^D<PGtTbLY&A{4yB7fZh8;2PQ91; z$P(^Vt{>*HfVI3m1j-T3;~1oJAR1f=2nheN(ZBlxU-oq=wRAH}y<2a#cpA_9tstw& z$uixzw6YD7>MgX=?wGYLn7Y1943m}q<n1#3iIU9?SCq6<((2c=6jjJ+n+db9kdT+- zkLCH@VMT%NGo+y2_E1Ag7mn?z&e7RnUF6Q1M%Rdx^Yfn*!xg0yCc0nX<E>7=YU7~a zK-IYd_VJF)@_QZ*+BM&o+w82swJ2QSBe&SDqm^e1j7oYsH!s9Dnk?;-s+&J)MgC41 z1!~ONx&QNLIi8Bwc+<-3$&u{k+tcHt#Ppb6uQrETLJ~`7^Iqq?V9XvRwtu11ed6$t zEot?gjs_ix0O^{4VQgK_LQ}iiksWE&z64a{y6v-15N90qfoHOe*<JM??6kd8`TLPE z+fd%}ie`ETY8!jwtQT+0g6HBtf~v<U0qdn;0k?^9$XKgqdZ?US0AZ0ecJ?f=XO%bY z&-QKf-2Prv>S9tOU0GrOuF~sl|3_xQ$`|FKT0{8O!b7KZU+yy3gYU4NRIT+pPgtQ0 z$bp_7QXe<Q2RA<_=IYdqgJxzO(o+lIrcCR5s`Zd>%Mxm-REY=Od6hpVLTRbbnaLOm zA@EdQ)3^Mx?`Ym?+cf_C6gnYe<34X>4G&i3Pq6NTrh4VjyEj1=T5yZ^WY7@ev}|b* zYL&KvuIx`y1YCn{XaX;#X%_dMFiaJ1^hoT=Of+0in(9Ol%(d9A{;VH{-9!$zL>b5y znKgwrl+Ji6g7IO-AMpJluE)kVAX$1datQ?_;k<B=kk6CXY~-PLTqURlKD(gU!KQ<! z8kGn;Dnh}Ax6P1OcN%TKAACpNOe`%J)McnLGKP1l)>{;hhx5EsqFFwlpTZ1o3_?=k zCe45XjUsc%=Rrvc5NcmXS!i7-ITL23(kM(irumqOskB&Lu0LCmszUT;4F3r;{pd2` z8wWCctWPXO4~dzRAwzWwj_uT<9dS;f6itolm0S;T)q`f~86Ic7{kR<Q^IgSVT$GG+ zfUq^LBrO*gj+95GLn)WGI4Vk3!Gdg8yba_S4QnSy#TdoN+Zy7gB^+XgQ8PKpu%Fn* zB}><KN-Z+ji9BC+bIa!4VxsXzg@9x9w?>J$UX{fS-w(6G>^5g<i$<KqKU~Df$0(FX zP-%zB>#CZH*MZH&9pH4+X`N!+wK1eWAIr~&rYo_Vy1;@Jvd~fWVG4w0m8n`{z1H}$ z+I#s7iOJHzI_4aNw%Ru<Q%Q*XY=x7*AhOdygbkLTvan@$C{yjo>XMtiR6^)JOC|FY zSL6~oQ)?@mi!Wp>Yd@~S)DP~tmu!mNZO@65+~JChZc}XoB@ZVQcR#-AW*igF|FR^+ zd5qB{yOtfbroo*Pljb^=JDZU#K5dTQ9~-Y=>~EX9@4QSfJv@<uqoky?@0jq^h=*oa zEl<fUu1AHe)t_NC6d5h0T6NqT0m%tNQjW5xK|0U^<%>G5@!#l$iErAL61rK3-eCnh zPe4_y$%JX!4dv^4vWf?2*-?gjG&+1j?cP5$ydFi)D(DZgLpc+5@w|$9uLJuVm(3>^ z((MiGEhc>|GC}-&PumR=lqC^I8pQRrObi{N?ez7U*ANXOIGqDo4p)QR@GCN<$(siD z#!`53#$0<|36KshU!v~FbVwctG!o+=9!ZG;^#1vi<k2X*M^ihwv0T#5yd-X+vZ{H+ zc7<ylYV1>$p)09#c~96;-D1NauMgPu;%i>z>l5OF5^!7EGK(a-%?F5t9i2066o?OX zEC&nj?{Y;B<8_hiv+v&__CdU$WLO#p-?wm->ru8R^B{xXsqJ@%-B_viU};N{?qc6@ z6={2BilBPriF$9!c+L#(fADR+AEgy!<9km)aLqRlLR~C}6L^C58?(x&ZvVcoVD=!o zhV?za<)1Jf4BIR|<+jJ`*IfYo0v_7?0Sz>%cQ^$B>}3WYwAt6&zLh}i@u9)t*UQ@h ziErywQg@TRuc_+Kwo=a$myNacf?e<-7qZVE!W1fH+aqTkDPO8T_|Vnjnpet~V@>q< z=)`WD#uQpLdo~L)K_lgJs3LBzqWm#38V_lXR1iyv>PewX&T$I4uAI60P)Ags4kita zq8sfSVKpy2aA>&8A^kbFm5J%BLBN_)KG~9tom>qj-6e}bkcPPvhU<-<gXF6(=o&c) zWA+$?cYtDQs5ctEVkO2F)0I+J4f{S$WP@_P+!b@yG;iUHnw+286zb#;_>RcFN#SuF zX+o-|&0s?|9`3w(xP5AVO(ov$S4S!JI1E@}knFdOQosI(c|2~1-FEa+yTJe<#j#VR zdx{TYWA7uxktQ!tQ@QZ0pgylUtZu3Ml2fGY_sXoeobebMUNdfd9B*$IpX<St=8-Rb zjGyE9b>=ILy3!{Q|A$_Z?nx5)BmOaBTLq^c%VT7PzHf<U#6~f|44AZDOa`~|OOgc- zf(W<+*@MXn`1|bcEclH#ec-d8qS}{xletOfdUHz8<j3zi8S($7Bjm9HU!+a9$QUTN z=P9%I-V@0<)6`|r8?p1>KAN$45jHAwLbq=>VfM^%zo~YA@*rt-Khq_|5u2k;8?{E0 zawJK7<X{8K;^6L4achbBTpPVdjWTVa>FZHB(0M{qmsu8LjQo~YhpZ2%Ai9{*3zaI= zSjy1V*4dYQ9U8LqV?A43HiRY5V>{-pGJne^c^s<9V?2BFh08jOp!;pHaeN=_SN9iY zzVB|D=c-whqKB#{x{d4zLnbWLnqqy<4z2wJjp@!%e5wq6f#m+d(-yTU#7ijno8kM% z9@o_*=<Qv`PTF9`vr`L=XUeM%Lp!)lvxx(wX5a1{YT*=+&h1H$^-KCr(Vm(QgyuoI zllu+fg*{0Yd=f_Rs;FCZ+sho=4I-EEzdw3^Hb%L!?!(~}IzmBA{`LUlrr)s@5$oVV zVX32K%o-w_qa*2T*u<bgRLSOd=LR=aFF_yl)?!$~fh=v6uQ6AxpI<muVYM3jGLOix zM}@e@xL_wr?IZbo<Z-P0XS;o8f?D{1l*7Lf;i3(7eyR;(GK7zg1|MzJA8qfms?GjE z4QA3pLsgUi|AgfK;p9t1z$%X7y-2w}5!FS|xt71{e|+Qm8K=-ip7}m9l8AUg!rT8l zJHNGUa|Dnfe8*mp(0m*2a87lZ{epq)7YGlD7Pl9CaOC1WB}F0ep1&rI`@QtfXD|R9 zcXxX<eQ|Q-N{S$lf*G!xiHWUl`|b8Fj79GcffRvgB<VQkc6MY=Fw%+$7A)~52UIo| zbJZ0x6qlcn(={WS%y}IlzSyP;e-T4wgJCvuixVdlBXJMFp~XQTOPc|a;iOn8q*|{q zSEf}IK}A`9X8_-oh1R@gx4Hof?huRF8;jc4V)_lroWlS<$mt^bjr9p-?A~**SIL7o zS==EI^}|XA@Cq=c$nPmB68D}fd6nF~?9A!3-GOqefS}&JYFz6Tw7=(?7?~!0o5uyF zTq%U@YvKN$LuY!5eETlY%C=INw6BGI)w+JKZsLa;%!2tpTBp}a;#2Z@W~M$9zdhtG zXO74RjRWhvcDYU~j$GtA)GOP_kC&)4I|~?@u&;IVH@=i)L%2#=)dXRLyNU{I@41|p zt>14-5elq>@b|XRAGN#yU2*$U=l_f-eQ!&PWB@~os0C{UdUG%>$wth91WDLuz~qz2 zNyF+n;lyBMO~57Vs*~6IV^tH`HmrjcULz^(f{>y3u;6M!7@fw&u!pF6dFhu(5*XbL z;HyUMkF#?}&b6buadz{R=pF$08UP%h_CR^i)CE3oDLv^h1iF49^Mby|ZZ+bxqW^ci zs!n*EW)EAo)~!6^z^RKd#^`Lbtfox4cQCWN-7;*M1Ua5RoOk5h_;##FAfflEpqP{$ z6GkV;J*P<XNxQ4XZXkPe2TZw-AYFXi#1S~hU{Sptwz){8IjWa<_fE;i@k*QVxY{2k zhDHsPx}K<_wq(fI-$J}bKAhWoXr3AEOc6F%=<?AW=sL}+he0@7r#BCmTVb~_Vb=~C zn@(}(rA@}nA{u8XV>2L&CMJH>JoKBpY3G*ZJZ~Wq3^GpDIq>Ny&0?)l(Ij*J*K3k$ zB#75ir`D;FNuO@zPDjxQq@4EPh7gGTCO>qXeQ@Dq562IWQuycIg5)bHkNWueR^Glm zt$YChA%!nf3tL97c+uxLs5N@%+Z^5^0xleMbw);?_@d>WcI;dhld<u8$sN|ot9@%l z!@Fj;ENw&3<PcRXSjnG2IzlEY5`3`p?rQ_OPd2GHE4U?|xeKUrLDRJpvb^Mq&`XWm zu2!S<6eW?oOD`<(3Nsg}lE((sLXYJa8+;n#bm*os(bL@*G1?iWfXFVxqIKt29hYCO z5!qmu(%X)bElGe3fvIj?r+v;21zX?Q4TnetX}}P7sFNSG6sV(@(pr#BkDr$hh~s$J z9f%eF(YTK5Hxvp6L9?vTWucg_GVE2wkii7}xsalMP#)Q|%f}|mh{gyNO##z~OqTG` z?(&TLhGIU*;ZPu74IVPHQd1wT!r}?nwT9QY34GeY`S2|43Y-)CT}$~kYv%cIg3{a+ zCp0dYf0ar$Dn*lp2f9`9w7rtyTsQ5n3}1J>7JG#m-%q6^s}^r6np0WB&3bpc&{aXW zml}1ul4IaZ`@S1tcBy+ewI%#Z#RU~KsI4!&36v(Z9+Gdyc1oMtwb_Sere*eBgCM$D z)qmJB1Zp!8rTp+l4*8(<3!XXZZsnuGIf9k7+wx&AD{pAV!i~rTTQPDwm47Sb6K)jf z?BkLC@%`Q<Ejr2Ix9Hed*J-JdJwi}jK$842a=2*{VgbViICss$a*@-UO$-@3S%dT? zzxnwf1#&L4bh0(7#b}&{N6JmaOb=+n!Rgso%b{=Kpbji+A|Cl>7N$e#)3bAkCihf4 zGC;3skt1zyIvy?6IEf(vCav%4VTT?%{QAl$04RM8uea={eEZ-`wwbe5K5QsTDI$)- z6HkjpK=v!a?e{d&B&El$kKpyVdlW|Xep<Mn-4E)~k>P&vhh-(%StK_fLBFR#GoJ*z zsk%;CUdYkM_K<U7eN{<30q>K6SE;0*TSp_c7JcdV+aT_N8AqNetz+%}E2fvETw>VG zO_x+h|3k%x`262`|He%<&g8?QQ}fSck8Jifeg=M9PC)pMD_3e}<b${JxZLxz>EQ6N zeCsY=k^dhezVu#Mf{$MGy=;cN&A-rIK6rnoGA2+Go7FBAfEIX76Mm&p6T&Ky*E>+d z4mzU8A5SZ!DwM+R5#N1;cS9F)wFk7mN${b2gTQA$3|^=N>8C5@zx*H2@To-lbHY9R zkY+l({6Eg=O2o?lJElnhQ{}Grm+)HZ=HmyNCRfrVApf%@Qrwlt-Cd}PZ&Q`u8`8(j zu9%`-{|1SPzL`MZB|-_$7dnU;Cm}uiQn&D+3IeB*y0Vs=@$_9Ev_N3L3GmU+lP)T5 z=mFm12Tg;(3xg(77J=P?E_BTGoZJU-#mWh_kedeH_!oZXh7UW-eVvb8t-<&cvcpE% zZLcfgViB#Kllo{jw*epNOaBl*<mpP9--gDO0{41hv7PI9Z>pCE0Y3UW%_PmzjS3p? zeFKxgD>1<7;J+5_j%SKRP@ITSgD}=jQQI$P1|kQ;=`XG}K}8HK1JZ4qWTebJe`ZxS z(facs{||31Wfg}&rriB(^w?mZ#ZwIz*Zn<VKb}Eq>QOON)HG{fMsw|9G=ZJ=@gj!n z^wp9cu@v3~Qr;jd^p*4<sZTK%PH6tkW$cT-&`)yTj<=U5-lXr<(N_Nv5;Yg#D5qJ+ zEx&61`Wz-L{mk!>&i3u!{U&1#xaKOON^PA}W#`TgP2mu(us`ZXQHXhgcN)3AP)G3f zCAoA<`yXYE8k1l`jE?80(m=gw-hK35`WCS}*{be2R`Ac@P-j$$N7D{uS6(zdjed<o zS9bH2ON4NFlfT(tWu)d(v4;b0GGuXam`>`bQSj)F<_I?h=~rT5XwjW3k%_&^q3uOv zgHxm{SSEs3g;(Y&8NfdxUXE~Qq-B5mMa1a**Z9Q1=y{+yq;B9UTcxKQ(~iU7Lb}nV zfv+cR-<omzAb(_VO;#~3CI7lPJC0mV;FR0?Gt=~)#Lj;fcMBnIzO??VWq;g20zz`3 ztm>ZIAN`%a?$tCEydVR1(Is2?FV>+GC{9PVbl=UwW&6t)H@wYHfNj2@w~C8syHV95 zUzq6bQSDre1sKQ2ZL2zE?%u`(cjH;6R(9)>4SIG<P0h}^<&@qi{=LH9iuc8%)2A&@ z>yqrd#dRnzgj9=V3=a?fh>!3o&Dv970T&lc1NNMv5MZvWB!$M*ciL_+Z#eTrZFw*G znT9{F_gl`93Ky3j#2OBG_Z)i+ZusCndUOjufcxZvnZ*>y2HQYsO$os=?Oj_-cscJZ zD9s09-6$9xG5)fHebzWhzm6{K@k}&5sp4Jtra3{#T;1C-P~}%&zbS*+il<FCoQX4P z_AuPlm2avKDrxHF5Ysl`Vcx!EkxakKkF~|NHX2P3E{u+OfE&8jxk4{+^X0CV@2DD& zrK;)4&=1E+QtZi}pVlRLh_)@`f3~{9rDy8y>S99Fr-P{PUkFHpl523?P1Z{pg#8;! zGtvbw1L;rqobY5{V(+mBZAOW|<{MR%jNA&CXpAE<t+AJz+TZY!TZE`)7UXcll60AV z3w39>=9$Ev4F(2}l0&!U)`(sWZoQM&*DqquAO-jLuNQv;W;bfAqXF5b;6la*O=s8% zq2EIdR>tZu*yw)BiA%PS53&xe=@3&=;{<=WP_lO)>mfg#+^=&CR3bLZUUY8q6W-Dn zj{iFCR@b?{J{}NYLq7lo%&@E?P<d1lht-(gM^O{-n)U@PXyeBy;U*?q@VqRLSIw2s zI+VN7aiMYeSV)Lzb|JRrJ)E*o&3pPa_?2&ee*3bQ8!+iWLMC@+CP;KBv-xZW{q@=g zdKe1u&myY07Aajp>Zd(Mdv8kY9-7FUR~4$YS31j~mUH6q6I$SdP@i*$tut%`(fB38 zF>}v*#Uz7S-0f9bE1qOEg!94bk!2a&Hz%$=H}7ukI?Cj3M`^9_9tjEs&)gX_j9>bE zbgVa)=S^TkviiQO0%zuuOm<`gQo{M55``$dS5}fS6CFLVzOMH`%^bd3`dplcokE_P zQ}_|y6Iw1KVS+fdhuE(B%Hx(}Ou91h>Qa^4k9O=S`%U1c+)bwKn5O$8sK*artED+l z8wySE!|}&J1nT@!=0VzFkBxf_i-W8zu(2M*!phUJdl^C%J01@Ro)o46McC`kgCJyd z^jrz@gyZEAI>MyG0#2N08W+FT`JLe{j84#w&jhX+s~}yX-rh;@4>jz_;n_Fqd;tx( zr<J|;m)49}1i5SKa+fMiSEu`9=MegXbfZp|WK^`MDZc*2*Z}On;wR0HBh4~BNvqKw zv3F|o`0&?2%=8ip)*pRY=<}ERsZ3Z1rE}HV#54#imHO7N@2w+lTJgo8!MZ9okh{7H z`5_L?McgrsRfy~WW`T2>vL2OEEG^{_UZa-u6AKP`3!X`c4Bw%PC||B2+?D!P2WVbm z^Lu!+A-km)N(TOBG!0F*<a3n06lyt8Bq995tTK9{bQ@v1e7kGbUb<%_D49|hQ3JE! zpCWcbK;*PG9lc;v2;p8?Fodmo10`L{Y)dj>6jjR1TeV#DM4Rn+m^9c<icR$03eHS; zpySPnn7ec$sOo!{d$(IhvLV`QRTs6!AZX0|K>1+wHX0Dj@$;Vz8<vfMnzAWf;8uXO zsDB~`bzB*se~zjr5)7Pve~qo>ZUQytQ!XeAeyOKN)kvvoekcVcL&L|0A<(-^e}Vt0 zKReMuuipM<8AHDdB1ngQ>SOe=HL&-FDj0-+*cU>iUZyF+EU*BBA(OGNeb~XcQ>hG{ zl8ix|=?QvREVHbuqHQ-}OZ6eBY=WBRM0eyX<fk#3=JZamd*YyYD*QOGe7E1bGYO)v zh~uPa1SjVIJQ9lJN7tc2YA5ahwcwM^QP8MkEhJU?&Bp)=30`-_2IIse?DK*jtS>!5 zCS;!-sea|kOl-)$mtx3vCF2BdUc@;%fov$5z*faUJS1NW^?GEtb&<enYB;dN)p`+B zL!eOrb96AVo}JbE*oJ8WWmJjXPN@8k_1o6+i5PPOGxyi~DAF11))3r32nh&NcAk9^ z^Ds+Fb{8W4L$X*hgw=xTL?Ibcx(pnfawo#9?6+Km02iZ>31I}hBZ?KpO#TP@V-m!* z+N=sR>6X{f0jhL;ASo*Sg7<?uDIlvn;LP*(4CtFr`gd;TDDL0(&;&W$u8yHOhnAg- z9DcsG_f_3*CR49Pf6y=-Y4th-A^zer#AS>~q2nv^?OfPwDMzT+5g{vPEpk>VG(G~( zjDZtOV@ak;_uGLi($8zI4s*4<+3elSpJdzddRLBc)AnPNb&+_UJgi9rXkwBW>iI=f zu{$7qJdaH-_S=K@(fE}VKfGEOTROy@?lVn%$KdKdVRpI?k-X%E>1V-jNtDtXyj=|h z+*k;;(35^~jl@<B6v@9LdifP=MNK983q-R0qg5Z>7l~mOL_igtn3n9T0J*s2r9$^f zK#NRD8~6b**OH^tv$J8}*0TJThEbE#om*2azJ9Dkz1DgZv6(=aCIb4H==(^W@REYq zpVNZ)fQ!wbg1F{l(I%qmIS$bN01EW>r9*faaeqU~V-Rfc`DtJJ<I6~iZx!QkAv-(K zcZuQo&8rai!de5TOLsX2P7TTlzRr?M{yU1g2sGNgt7;Gbdz^k1xXpHNs<oacYQ$wu z=8vxblhgdh8v8bW{wz7s?(5pxX?i)<-(&)a&xVjEvEQ)1b>7gvlSdRM{9RJ#q5jX1 z;;YarE*v^0IfVRr21$4oioQ})1NG@j2pl}iVbS>=!}flpskw|C5gE*&gTllT<k}iW z>)AcvBo6z6Xy$;*-F=HQ*THl@kTFUNO!;x)ya&8gT=tqP(An{p5j_7_Hyzpo|EUic ztw9^v&$O@5UWC{9?~fU^#OX1l?;}qh@|!)UsC@(V!(qDMDv-pO2?p|huhGmbbx#nx zkK837l0Y+-hpeVI{wsthIi4t1))bJZyp5_SBP0xY`ZfC((f@$p2BM1jKC$O70%f25 z{6FDj2^07twMfgo9|=*8^sn#)Vst;-&1ZgR41a_+^E+7^P|biOT&5<wKE-_eUMK0T zDXXZCtKlLjW`A!GIb=8?@R_ej;=3#IzdnRXX9B~x;pvqaD)j#)RKG}ltMDx0G*O>W zkqb)pipLCoHe!F~y-E^)&--w&?7RUV8mWK21)d`M8=hVzikC=Uc?!kpvh9xJ82=N} z*Y8~x3be5}2OpMu!q0tx9P!BMzvqbZ{z&Z`kD#r$56k?DzZa<dHyUm)!rx4Y18HP9 z#!vsbyUdqP=pq^ZCl77B%tIe997CR){mlzgp$A_rE$r-GvJ!27EA4Z(kPf>EO4OU0 z*@jAGf1T$}s5pa9*k#zitD1{#kveTreBSNe^kONBG!D_?Gj0BC&b*2a|K@3x+f|w2 zBR|7MwtIWw7uWOUf6amzE@-+ZdxvL&y92E^!^CE?f<A+`>FhTDj2u}iXrlpEvt2Fc zJ_L&->Ys9X`tG2d*{}A|pX8TEk`MheA4vE(&BK@v`X_7o;vFJ;*zvHX)RZmT$Emw~ zQeB!i&^34Ln|o6ck!HX)kfFGRy9C(^f8KQWP*+ou`r&$XR$9Zi=I&M;$xTUYHT$v_ z5m_AdgR{NpPqlBefWGUMUgEjf;kvK(m5v8qTNPJ$;;zhNYtxg<&4@;P)9%~1`dgAV zC8o3AQsgB#2Pj*FV#wJLAFvh)aL0qzdZuL`ruuU=FsRoyYyqCst<^*QYAGG&@ch>O z5lz1bD^CAHulU+O&YXrm3?GaCJG|Srtf*4#Bfm9&%&i7H_vqnn7$wrhlxGxIe<S;M zSwg}V$w&NG2Tqh@>q{hpHBJWzV3~M9A~Bs)5>DnXor3!!RLfPlH=3{v9^O1*$l#Lo z+8^w$J+|Re`BS9CBm<n$Krrl9=erI9#!M%amZJG7HI7_#{0k0yvT2__##;=VQZdF2 zyPA6cS<*s9v&n9Rr$Q#`8eeOf_k)x}Dk|RTw1L=bXFSGzt7(|L8vSn=S;=SjJ017_ zm!VE@$QZ6+C4}ESqtA$|l2*7qBA#rvn>1pf%*r<zi5ZN~367)qa00|I?#!P#hCv&N zw~B|~q3;wl3j8!He#kog+37|58#l8nt`32mUR_&VvPBi}yZb!i=mB|o`qVF}5zoFj za@kMQ$T4LKvy~<8F?c8QPgN9W7@WNneA`iIfD=ka6U;imI_U0vXAWD6duBSiW?hmX zMu3K+AF@ByEUcyR_Nq`*YzBXpoh{WxP6ZG*3Q`S7Uaab;B0i-;vJUP{eLaLP1J3RN zLz_MRRWYUF1@Z)X&f8nE8tnJ;=>8Y)R10`!@z8^DLZnkHpZoBw{?R`0ylpN-<w3P- z+T|?r{zt2rZx%+MZNzF7gs#>gEGm@A2d%0GjWW3bS|e+1o2v`e+G6{&v!4<_+g?+s znkev(JM(P~7EOS+1c<6z=+sS5d)QRBdF3S?pfVx*h*8kHRYAXOgE50<((r?!2*~__ z=FFBs3wF4hQyyf?dGCFbp=%{%KjNdxpdM=&(OmD+J-zAOGSRx(@lz|yFls;J*40vq zG|qb|56-+T$$U^i$W;-Szmt<sh|=m+^BZxgg~ViU1f+5F$C9Wo#2O_`tl7Wx8Zk6D z@<_BeId!1-A`Q~#+mK-?E(q}vqQ7()HxRhDSXK%J)~z}~EGyADt6j<}xSQ?E9~B9y zAei0Pu<B4F;?J|sYfG!0G|f+I1pRE%BInU<>+2e7m#j_67h+(&`_ykY(%MXKnR_6j z5=z#$<~kUS({Xy$FFb|_>eh8tI81Oj1QNA3Cd4p)YrPZqH8=v+B}5i?>5=@AnAg+y zn)iCsTkfj64ZVQ?2R^4c&v8wI?93A5xdVMbe<{5o+pAVa4`T(#?7fNFU(0-&DmJxl zhDtZD0As8$j*VY<fg2QxkPSsIB33YL?^g7FJ!YzXT``YRn(LnP_Edg=Gf?HSU;qwA z41>OpS%#ta$My_}$#{)4wS@aWq9MC*L^FfnU+>O3MBd7R2S8r3%f4UV=$CUSM1s@B zxdpJFtZUC!2d_k+_XO%-e-I-1vj{8UhPeCzY8o4|mfeQ^wiqUii5i<MZ?c9sx{!9A zz7Imge<1}=0LUCV6S$&4Yc9uQVIBLIyc<e3aPMARsgbH%TUDYBSigPVgqjS*TEUAQ zIW4dB^C_+1S=*<XY9vDrNWrVO0*d};%`-~C$rsytPg2*yQ)6CtrEnIo72LSDJtv>! z)Ka-rOmCYR4VJ$hkqbJY5iEq5mYZ?e_#~d<0hjzt7;s|Ys#~#tr%d30?~Ntyn<4^S zAZ#0qtZ9%>YGky6xl?q1dG|D*dZqB`Is+TH?lnYC73eja!uZ>}od+D7JzX!H1esmn zX5R|9!hQao>Ep}tAq|ZwP%Z;lPZr#g{ca>KSQd<V*pQ)nS)A0;L&fET+-L-~Q6HZA z_@S9aTJ@{J_gL2%+Jp!$`DgmD*amI^M|sQpnWcAqbQv6H7g0it?ym0Mktg2*&Ul0( zJh%@v{LqQ-Lw$uf!M96FA*!nKW72sDpU)z5<a&b~<CaXBp>;&~KTd`~lt4++9$u;^ zSRqty1-DB%n0`!4;4}=X$x6pT;NIW_FCmA6TlP;q$>N)P{hD^jeCFOy^!fD$8RZUv zRx_@EP{?)HqXVO78Urh!p4hJZ_v-WrmwSKkJHUxDAp@eq<S@EhmT*TzHqL@Lqk2Zw zCiuw<u6>l%04P>?a{b$PDH2X_0dkmbeO-KCuJN@{a1ydm!b$*Fcv5@ks&jpYDu5?w zX_am#GH7@iRAo;1<Al=;9-6+%?BPlE3W+%ms-J`2?ta7(ame38L+sDtl8~7WRzoHq zHw-uj^W3n6iy*2(rM2uLel2&(L?>AsGK&kR=k;^!x{Uh)y@Z*N8(iSYH1ZtblNgh| ze*mZy&UI%^;W)xn)n_mv7@ZdCOTomkqDG)hKgUa8j=`VE3KknJ0eWmL@(_rpA6(@2 zEa)r*L8UN0*_uTzkGb&ihgGs8PmHDz^nerWGX&xU7bh2$HQ|}18hiq}Tm@p%+r41< zLYD9$1TM-_KB=@UkxsBG4-^{%r(Vf~Yy==NCqQdA&olY?G!UQ_*})Qq!JHgAS%@Y4 z2e9wC1|JP9P1Cn*4;CfobFL=~t}uYT0R2K1;=t&DJd<itHnMb8iw_k?BUqIWj0X(F z5a>V@bqhFMdJky8dLG0pc{Y-P$pRjeV*!uLXI}5g0j)O`dIr~-1AL)WK$YM~i?<lN zN)vqMLf@%1v3coJNPc*#(rxhq6+tJ6$^n_l0=CIicrwhx)8-M3?*2#4!5J?Hdf}s| zOsmdhh3;!&YYJ&*c(L#kRrqcWog$<%-KJBZnF||%d)psoftEzmM^7t=$^|XSg3S}? zfUs9212WUApe-e|p3JktKr1+{4Oa$M>yHe5?LETb(5t54bwdGQ0noTek+R>PzPB6; zzpq9HyBN&d4Is-0o#fDU0F1yygV8-4$;p@NjaBq|eKqI_rJ`3+4rn@uuKNNcaB!30 z09>w&%Q?vYT^3vuN2loZ@e;Ir!Nz&E!3&7*{lQ*Exge_%T=U+l!=BYQ9!8n(F61du zpObIhyA%r-QG>H)05pX-%7Vw^y66P`^FT%-s38zr=7QNlTo;X?0tEI3nF%o#i-m76 zK;^xX_Bb&S;wXtuO>0>Q=el-J+^YBjD^<rQ9--IAGiZp>8|MSRj>&!hoS+)r&-aXs z)R*wy25xI#|8+x;i~oJZwf1YITtfE^nt%)ZA6mtw-$s%@`M@e7{1&HUlEo7K=#?)K z<!#nG)v@qTpX8EP{YJQdu|2v_E1X-8(K!d7SbYR3Rx?Q0ll@f9Y6J3kfMn)}uzWNv zy3S`b7iVpkP??YyuiRAscOdm5=RH*)p+-jBmT*ZiRQ0vZoa0=Hi-RTtnZQ$k1>tW1 zf+u8m<wGyd{#fqA=x`8fq%b;q0DrxRB^=<Rn<YHsB5Amh2>~>8JQMQzqN;%X2H7Ky zdJf14>wi12Wcn8#wu(_2UTfTC+Hr-!s$lvNP~G^?#y@CH36YScwKbuzcP4yDZSqKT zdZi1V{zGDvS<>qA+8XyIz%<EQss9S_e|8Oj7OxG5kj?Y+H$uK)ZtRedwgfJU`!x=} z%NEGbcj$#Jy>yttV#s@$`rgg?RBQg@Hpcr;c79++hgSch<m6cparSZ?3B#d^E_q~7 zY4tR5h(3A~vAxRVR*9Qe`|!EO1gOb(VY?+0&x5~~VhHr~13!Z=!^PR>2eitFrpzM9 z{KIebUEdMg*;G~GQ8^NOKbGOMTWep}ai=AEwyt|Cx}Ux*wKjJ(=-?qHjm9V$iC=7F zvWH5&{4p~f%imS{PI=muM}lQ9h7AnHn%$dGQDnGTM)se|G$Xr<v=AS2Mrl1v#_chR zv~P^a{S2z>0M~&z!}+|#!#tFpGxON3q^LH!{pzSO;+i_2=s8PKJ^C<?2;1UYwUqx{ zxg_Vq7PKLLKh`og)O2Y3@NlKZ!bXC-=?Pp^*oN#u{Hz)g@nK_A<w+h37AF`RNCpk$ zE)GvGw!tD|FsMLs6qlie1}#6t86_i>y_8q?T#%(^SdeU^x2x-je6x7GzAfI)l*#Rl zxjIL-9mRXXY1vO&SvZO7CGSFYI8Ps3zndoJt!h$P(Hm)d4Mn}Eov5C$WxGQKDS9X1 z;L$Xzh*SY$Ogx~hbm!)Fjwh-r6WL}d<NVkn857wivf=w8P7sTVp^&datZ~?c;Rn)O z+&y&^WE>t{70B1Q!FrNi?7j13y8r$A84cf&u4L(7o6a;0M#>4w0Q&tS1tWVro{oiF zh&gaHa3w(2A*C=LVdAVu5f!fe%RzFu{Q+#T_ujE4qlU^9qqe_kQO@b7R4rSWbJBP4 zFpU(}?W@y;8o^2ti#em8UcZnLcyBE=NoY=%cF;zlm=LZRrLi$U>L*!r?^a-DUk>0S zfr`+7Fi|S&QDUl=(QAnE5%rnc6Ci=Zs{^Alw4=F^T+rjrJV*3w|2rxDj3dM2?2FV2 z*D+7++f0{+10y_b8ygczCfFI>EFi+Pl4k-frOiw{lM<-@kbf*pMjD=jFE>z+hufD~ zq|i+>1NXfh;I}I`rw&IxeMC@+Gm%P%a=Ft~43mh5aaYEi?_lVdQ`L+lK_tMk_e_Jk zf|`6Ir3=T>UOqlEdgT2|5@sP)61$lA@ZxOyN+v3?kbO%6%RmTcO7tBIc@*|=NDi}V z^*SsS;)UB!B{c&cB~gct<u<8r4EXTO;8MacJy_fSCptISpk#(e)$O32`;B)R6-d~f zW3Y&qL&Q}ByML&nTurOv`_V&byehYXCB;aQ(H>^mLMJYVzW)<fpCTa?>K^k$p&OOk ziN<8IPB{TM`@-yd4=uJ#p2u<w<_ssC(UCgzXxZrup6_zSH&#t4jWD>S2>*~m^#}Y{ z2GS;Vkw?G=Ks>m0)t^AtNlINkVr4ML9}hYxe0O-YAM-%pmaB?0c#+)?12FMAIrxYN zz1lf*tmXphxL4LX$lqPH`DB`&V=(PGzG~`6km}L^wQV%y(A2eN+pC7xM4Z1KH*$<F zn|3%lO;^j9OflH8nRtzj1+Uo60s+5OJ->Pf<^3;ra%lm8>lCUUeOO)}2jY-zghFO{ zFCrlw{DLG>F^iG6yA%ogUdyxJDy&AO^z~=AXa0nM)}_W9tD3~_JW+6F`=5kqPUc4% z*tG0|h3dBK8!+=_UaGE5l7?n|TY9J>pcQCC&$;5bde?)R!1*B~2ef5lxV+^(ZhS;* zb10+x>VSRgLcp1XZ|Q$X7kk+woxqm_yDIZi8+-e+aRsI8wvE9pa$`j~=9LgmuEuqi z$98Wa`-c4Y$j!oK_<qcll9oA#N*6+Gi!Azr^aAE~N^6ZUy50~qp?=T?xpEFhTyVnd zfvy0r=iN?@dZ&wDU!i`R;4Ogw8aq(iG+!4^i_QQy*!lU{@!P{B3+d<n#HIz}KU>%( z1d}YIKVvX5@ZjWmm5@>;C);NUjDk3TGvL-ZNyn2fU+#Buc%FUva;+0`=}fhQAeG=B z0*7_=ygtrPb{ZhRcGs7dmIn;Gk|YLf4=314NBDh~1}f%pmqJTiC!@@3{mS2L*1mD; zv2s+3d~{|gUm@UgcT~q`g={C0WsN2+hQUtjJx6zHCrJi`yJ>EJth*ODzJL6b1?R%& z<9Qx@`9c)N7_mvO5rAYcvqx1YTO+Nat|8PM9V8DWKGU<@y@cZh@zzHys<X9i(rW^M zfk<s?^`{l@t7Zocdt};?(Irn^R1ZNiEJ@WAOGB=njno&LSCxVbYATFT)@ZD530DO| z4b|a?+}m+R4^~;_6Jiw95Yq1KwsbD4W0jW{-@gOI({Zz>zW50zm;s1%3e7|HR#W0w zOX1y$?RA$i3f^}l#P#c!FJa?j0Et+LDjC2kZMU`0r6KT&^RDbGS~G-<kCdl#5FQ z6(@#bj**+wc6g!ToD_;oesH;*SCCRN65a2M4LLo7o0>G3jj4i6tK&=rlK6>b3pKf$ z>r)D0^BiRj9Sk;b&1drBiKUG#5tC(>z6UQRKxGEwwWK_{<Hx>ef5IUrSpK)NrS8#k zNQcMyGL6rg)FH|BE~&b*d<}CrV{L8iJ9T?Cz11Oc({poao11!{$70z}&pG>QY6c<) zL<GVx#=@ZdOb$jwmu&lxysG{H$Lr^M;TULSNw-&hENwn2r`xG5FSC=4z%~$qd=gff zLY4?dxKOdlWj$Hg$G5rxoa0)PxO=`cZG8fmOkE02FkB0v<`q?FgbKm_EGV=e^PqD9 zLY7l1qmg5wYd>34BeLK#NzM?f*>qcS*JWVcS4?PPS2``emKCVT@5(b6B8RuA1WRZN zgCbjiUkiNe!W816zRp(<{K#uPZ1y>pWBeEi1y{6SH9H%0$NlTZSFZ6#FI0DR`9X0+ zcD+T^R{Zt0>Obf>4;ZH%?py_f;8f%~K8pkzHaip^-7>i?w;0`W7Iilly=kr#)@C11 ze<PaHbgD|xEUso$UC<Q`p}>wL?Ec{|`1a0ZzH1Ke=bCV}Ap6ZXF#w%4tfZH8W*{4w z&OoEBxph<(4KdW*S#k2_iPDTWpZ4%u5R5-^Z}s1zV}owFkE1&=63iOZ)xI@Q-vtib zoM+Ed&Gmo0s9oUw!!TY16;=GAjI?$XB*$+y;?PUjBg$uP!SY2cu?6;YyWn#-mj$Fp zB??4{3Na|jU0xQ`wmAKI=R5P0vc>Fy-WN&0Ar-Kx?xQS&Vk3%ft#3W{nv2i6>pO;- zgzlB2;i$e-#AMZm*vW|%o(J`CCu~eHK6rF5Q=2FkjnJ*(<|#j7`<Jd$tJ6PfCC%@r zJyJ!13VBrG`(*Lftg_@yad!oZ*#3ZF?L88X2a#3bO;1gOD*wd~ih1Rmrui{u!xkc0 z_xq$IFnheQ*<+<ElY7=i+Gwmq<r^E4+f$_7Q31TN!Ov+M6NSMqP=r45b+118Sb4WT z{4@DGuEDzf@E;gjNy*CzAihWDaFyww?qM>W=7F6eCmwt~AfdA8R>MO1Ms0Hp6Q1lR z;}MwoIf3h!d-?kMRw7NA%xWS6q<^ncN<HJf4EK<P3_%8lwud5jm0)VDDylo7JFbNJ z7lKUoXvGN?@lEsfMFMgg5u0CwEc`CXFw0*Sy~scRx<A{6(JY|l)-!y<gcUAUU|z-D z9@UFksd#?I9NK06os<hYFlVZSjDEj^xQTD-6J3%RCn>GRuHmIPLP7dacKGd#A=%va z&=M@_DO;tSPCWme!(|`KKAO|`OM@<kS`Hlrt$!tj9yFsROP{fA#NV^#PuUQi9?Dr< z(EJENM)RLyXW`}7Rt#&D%Ki$H`y+8>)Kr{2|0tEunF31Jb(7|3_|7V9nJ(sNEsDP3 zDfkmeJE!-Y<omlw1Z(2f-*wU{p=1)73<VuTk=nDB94?1lL0md9(bpW{Kg(@jpt?8T z5F-0OHQ*HzqAb(F<{ATBIPAD2Vy!u+;nq7Z0{c>d>r>8vbJW=Q>S{Hq$Qu72sBM?9 z4&DfEehp_Ie34(=Rp#`WQB)#I83FRTx#{EaTo6?)K~q(s_=D4yOu%=?!a1iZ-HNPL zUo}-c4H^B^boro&R+QH^o()<oL(c&vdwO$+Rinq3=HgDHfAf*g$JugL;tMNn3ddyb z2YpOH>NP}1r6H?wv%ahLScxT1fYt>`j!<+=$dr8tdNu7jNcGWaA=&y78fq=a*;zxe zlHzrJj*CF$?%nvv^{!VCS7ZJ(A$C*p)XG>asq^kluYoU}#m7}w(gAYyN3v_k9$|m+ zXwKWkEzhaVdJGV(xe)4=>DiH&Ldeo~R_E9W-%L@|lp=dng-oF#@G~wx!iZ2qmd2Pd zp~ejbXBB;Fhu3gJGE!gsovtmM2nOJuK<@G)_Tcg5x>)Z3KI-9n$Vinv$;dCKjy`!a zhnegRGzVKnAx^m6i10><3MvWXvlWO2*}zyU`Y3Dqfzna*jOH_b1KC|EFL4hCGD0Yg z2@}Oj6BeD-1Vi}pPfF#=OZ##sfWIGgJSA*iOv5||B0l`)TFax97Xvv&&pl$*FNc^m z7?L$J3<t<cR%R{B2IoC=3w(-ckzz4obP8;4E*mmMZC!p<AXroXY`9f=FPwr>@Z|AC zHy)Y;Sqt+L7Wey27H2TBa@=(QR7&mlWpBlXg&Z)vB!J-!5+y}KTpGFOL43n>1<!!k zTADv%@y93xxFx-RGJL)><u)D8HaPJ9v>o=r6hoZ-u)@_;Zz0X+_F<0rtf|YF2r3(I zZkHh7qU}?&sc+xx2tMgl79AH<1tGF~BKRb!fuC$)F1^-gD=PD?&q1-3tLM>sqUxKa z+y%x2Y<ZupKPc%74u+j}n`_Yc(X`P>(44+C0&-YZtqe#c^yf`Fn0YjEn2K#~C&N=M z*tuv0G{Gj_uK(WPJhb)%2RPC|L&>bpf18#S=;>Sx%A<PN`qDv(abs~mOhr`Vo=4M7 zy_Z1{1#S38v|Sn~zs(e==Q*@FA{m3glQFT`Ko{mZjNkcW-Br;T-furI@7`1BT##b* z7Ov>3$n3IRX^9?O_vwhZ{i2joE`sXT=)rA-Nd|~{D^ktbYNg&!Q=mb))^1hWnmN#s zCUUZQP~-JiC0k}XUJn*75{d(Vlr^&xn4UPf1~wBK1dYU`Wwzvd^$Ek?FRNI*O_Ht* zUk+1X*mT{^4Z!w&MRk)>xa#LxW6z2l`zUkw<31*-a9QV=R8`BSLJ1Z<Sq#O=PC<gw zFmUNqhqCjN%#3L$6R@j4To8AeV%g_$4yHlK)44dXIiWw-u=RGC8Fh?(q%Gp(Oh@vK zP{#rR?`HLy4!Z`8YnN04?4>J(f612227LMvO2)HwuGg5q*0Vs!?9>-2Z?YV_pO5t} z+#-yTL1?2SCy?PXW!${KuriP?wXO^Jfye0BoPB@pxD)!Ik$wl7*W?rJ@=odRKt z+r}>QRrwVCj$|jIBiEGdXo)*rE^ehi2FgKNuOV*^>{52ie`ZsnekOCDj%sP$dWa)e zrGJB;>cVYXk+Nr@TqeA}FeCg1uIgCNf!fZ4gS9W&vMA26EmLYT;TNM-$tV=a?J{1T z$V7oK5?#Zz>0)9S@_tV>W&!6pz+Cs37fJiRyj)vSpGG3r>gT#VF+XCW>o6aSaL7*) zhGggn6p`H+<-Tu_owIt{B(AgBWY0p)w`b?U@NEYgRIVmC$CqqXn+(_Lr@BXe_o%Uc z#cJo;i<XPfKi4P6<E1cfJ?N{52Ik*n)Fm4UahBG3xRbfJpPAIj8>HXCOs8>w3DgiA z?~AIl&k`&2x~(uP;{7%&t<wm@mOVTPV?0K&_e%lzV5hkvAYe25Opj-pI2_{2GP|TW zcl(kjRAu@#;@gR5fjVlJ8|1P^z+(;9i78A?EfCsi>J3(HhWuKFYqXeg5u!fFARN*@ zPrBihY=q)L&1@>hcY9=MonY8j?v%)BM~~cSzkIH~;ibOQCcTtjohn4y48&VU!8J+w zRc7n2V)#nP-a;lO=1_p+dG@&o{~~tzT?FhV_m%X-d1Njwz%c*wa{(kWa$zhhj~!a` zT?>mAA7O8AO=&|m{rO(Ge3q-NI-T(o(s;oKG<*c=qQ9;!+Q5LzpM!-ib@9V7DV55y zT4touAAIE0d7*q{C}!YJ>7Q9-0u4ehQq=|(6iJE$vqwdaw0FSr>hmJz&>q<8RIca- z9Y@0LE`9Jq!IG=^U94R$MQeCJAAQfA!muYVV~c^Pel<$!RN$oQr4>B+Z@t6Ozxo4c zfSUVl3E=>4p)(7=pwBf-GsF^#sIY38&WC`jIXyRt&V#*5t9yaz@e;GN8!F-un*cln zs=8FO-!(}qe~9wF8AO)FAh9x+O&e8zt4o!tSYD^#>lt$=sOkJ#;z;}Jq$eH&4!Jw2 ze13ca^I88c@1Tu5L9HFj?xo|(`Y64cGRuOP3KYjaNS2R&O=>4AwTPjkVbh@W4ynQ& zLkB$~e(&}As$v@TC>i6$gKSg2Nzm6p*46&1xj0CiVw171W46G*(`a3acRYhrAn-5< z96874=~L*7OMVs`QfAeQSSp*f?*R2CkT%uTTK%gK1Tdx>#6J_`6#LlBcE~jWLbi6w zYX75Q1ItnX82AV@vsYg%Wd(;^MsSxuUbq-R-x{54beL*HCJWhV&eSyc?5o^mhs{Ob zG07PU@tU4BI}ViUUn-qe&1&>AHu_sPs26!*NalC@?7h4@=K%x%@*Px2!A7$i6g}`5 zMhkcw%W4NS$$mqgh{6R>&r^1((<b|{<g5JbsuYdgZ-Q#KfB(rm!~ufHNwtIP%<FMw zh*G}KlkKl!VgF8dH!LtnBdU=I5lbtOEgGQ-{txxS?q5P$><^7q@X6@L6s$hg<h7~J z)pW${s&iO?JVxHB(yLwBiOA1q6~L6u6ha*{F$SLy=lsdef2)D^d&t&3Lb{`s)_U9^ zy*4-RZ_9w0c|KFJtIg35V}dxENupKb1FR^7Y-R1Y*-zRV`7@9+j9ZWiB)}WcFf#r_ zDJs2Dsni|~GDw@9Y%xd8K)4y%?$}eo&F_)6%VpP7$j?#$IjEva+#F$VzZB<a<wNAi z>&MF>KYfx0&3$-@GCa|H^pengl=mFJ{XF$sr(!-FZ8#<Rm%Ny#K@Ozkf)~XDs&^?z z>?5Au23*drr(~bN$w0Nj9`fZm&5e%|!|Nt0Nw{M_*U}{cKSx!(k6cP|CkQ{cA4zBT zVBlfYHg0K7;kJc;p1y(GBP8w0o@M1nNE{To%Ki3aKed(VUmHcc5>gba3!*&cEVu!9 z3tLX3Pzpr$AnA7B2hNw2euVsH6Pt%v(1oI)zr`+WYEP8u!kgBR>Kkk+7Cvg-?i~~e zDhBAF?|_6VoZ<Y3?Z33>HP4`vm(Fv+6ut}ye7e9oREdCxh9r-w5g77L>EI2s)#1;= zjDO0Vj{diRD9nhIbYXaN#w}}RLDkkCsG&}>Fuu5fv&k9sel^G%UYKW}XYKx9D~x^A zFDXhkw3uF?L_p%}wOC`~|Gmap2&zT-M%qs}f7QrA5{9^ab~+fSb=4!`&i=QgSuMjM z)-*~e+YsB4!j)yLaml276N~XJbEUNT&$Edz!7>~RI6@E-{<7!gmhI7ghUX7v_oOc2 zIyyh7b>{cxN>^L$)y$``d{W>nCMSj_XTcox#z&X9_8Q8z?Rx0(NG$D9DsY3J)B*3# z%`^QQ1GnBlV$!gu<4VwXAZA+k^Ln9qz|FEhwdRY^nMQs;lc+qPT?moVwU<_^pBQu< zu18;KfkWJm$R7u(HcZy6wg`y!yzntE&{JGAy@j%MJGie`Hj7A)dFMxQ)LfZX+9<=l zX<nvQ9Pw9_7pG4#VaPV>(EnB2SI0%Q{p}tVMWmFJ8bvxpfuRQxkVcS}M!FHnA*Dp5 zhps`okx--&MF|;(mPUyIq=cdKu0hW^zxUqz-ut<KT>nsK@3q%nvG>~Fc%ElTi#Ft) zN2SSeXBir^)f#Tzin^X0B$(Hgn~kAaEs+<!MQN2|bfYtRPHL_HO0ryxb~s#l6x$_? z=D&URRZX>u#j}MN*ypiPlmrgP&B?JmQLjvIw_yEA%*DJ&{Gjw{KD_O*->*FXj^lvJ z8ry$!A!nWe=-wAueGpghPgRwJy|(FgL?A}EE3U|)W<yoN1j&xNs=GA~8u?PK^v(>M zGtY%Ujrhf#7p_L$4!|9U-R;^$7&McF6v7QcY;sH}b!`N!Qsi6(PyXkt80K;{suUIs zUc-M0$>58M+u!Hc#hRB@RhH2`Gz0QB3PQQ?{I);2IfQLuub5J;i<zjG2i?}>#Z-K$ z7>Nv-Y1yJbpeBv9c8NC;m=r3UseTTGw2E~<l2{g)lv|8qDmyWJSo1f0X??I0xCIpb z_D@nomSDz?n(}sR-SQLB&IVw$S}UCvA8iB*f|zIMw@@)b*p`^G1JeAHa`n3>8Bj%F zl$~jf*-<Cl&icl7z0-{_97@`S@S=2z(KCh6@a_j`Rc#tzKiEc@GY;50yiSw73}Q%> zem>Lp<su`guNgNKej*ER;ZGI{glOp)zobTta|DrLUs@hT4J2DxX>K-F$#!Gcdw(OP z0yOtFeCK3bhiW}Ha$deM1Zx5YHA{*K7hZ|To+uKEdWQXew{GfS%K#gH?@j47>=B{s z;NqSc$Su+yYz&3doSWBTd4#Q{kW*E0zi@}fkvPWPtp;_ITvorPFRBNcX$L{&z7`e_ zp&{#n>eKn}emy;BD8T8r*X~bxmaPOS?P%dA{@-{=KgT(&6b`)}U;Sx#m%EaKHyWuX z{IiZwwt!a^Jbkphst=DQxZd~>e&+O%kyx;*xC-zMH-l{;r!Q&!EfNdcm)a^;asic4 zZCiZw)CU_c{-zX#*>Ci@*Anpzh^~DB2})?R;q96tQrF!iB;B}|RYjlQ4WasudrMB} zOxwvmIwPW8L5saP+kUoVmhrjk-bSNicllQ*cmO<wWho0z3v#9Xuv~fo2$J_YtI!(h zSrK1w#($?z4aJ<%+G7C!J(9c{F1Xvyru_9a{MI=fot+dlAiR-UkkbxQ6IveuM?4NB z@0_y*&|glhod782q|8rEA}R#1)~G<nA8^`1{b9qf$sfad{-W5$-K{HKZjxATBy_$g z{p<#1a6wToO9Sv-&mnHAf%$GRpvdu4;tQVjOJkubZ!v0$sDT^XvY$@w!XI5gkrRx@ z7ue!X^>C)j-OwDO$=!|bT@S+$WEkN1@St;6lqfSD4adXqgg`(qwyk#hbiNaz3g=`M z2dI_OZ1_r7JL)ECpiMtANUBSNcZpye=D$bzL;SHd7ZhMyE`E+L(Ca6!fd@Xv6jh5w zpB^zJpo_L2+p)(HnQ^GTBhA3r(5DvktQl+`3Kb*O(@e^;l=<RCT0R!2V4)-^4Lc7W zRWDm5xON9DV{(g7G*f+EXK$pvdtk^LHAY&{Veb_0sSWZ#{e4K00yS(roA|ptScw@D zbv&mM2510B`x3i>@GWG8@3BN8fA^kj7@HpU51I9w_l`ro7`#4HzM8+=!tix-yp=_F zwHR#=LQ(npe9vhsb@#wK{T@f6W9&V3OP?HOMm_9e4jIw5vf#o}oi~LO)C^g5?~!p= zH3)L9y78St)4%4X9M?(g2f|<Qz^TrSn!cc!W><JQ4C6PEP><*0pCYhThHHO;_4g@> zZPjmW0gl;p|8Veoi3PZkMCQ8bkGciFi*((}Q?Rt!^{p>^8S89KYR>@c0W}E{GDW=e zx-{6!c?@1I(Cdq*UmyinkbUR{uE&M<r(lMsu5JBv_xfNilGwq?jMF@UBz3DUX>5e7 z^wQCIj@l3B;@2G5o9!P9xkyp`)KJyQ$x*)}nx8n-MPJ97Bj3`!_rz%hTTtRuD*$5{ zYp6c9CAWPDw}y1TjpqdTkiY;;QIpt098wR!KCJ36KdegtisqofMR2J|2q0$?%^{5m zeeAxywo-@P*r{Cthn6Hj7V!7zVHMxbhe6Tm-PIvjPr<E}ezUh|SfhmM&Ba|!I}epO zWGb#k4vel`c^thVS`yn0pcwampFk!+qZ_>EzC0b#O@z;(mxjpG98=pfu4GOPATTL} zsRdzcD{;tr4P*i@+Nee1I`N_J>VR+c!*4w^`Uv=N=%(c*CXdO;mLv3(!cJt(C4iRM z@-BWac9>hRhMR8wHW?4lR}r+RrQQye9rE2avN7i*F~LPd_21%kVhy<kJ7>l3JWOHZ z26&m?^&-sL3IaI>n!Z494GF;z;2k4>uJs%Ylu3Zm=n256{Vuk)R%-bA1fX6-@Nu|5 zz4qzT*&ClbzWJZqD1$+x0eT|}xA+M*hwW*fAp`aBaq5!I38A<eh6DU)Z@hE@HBtbw zi8Y&eBylQR$k`c5>;n>14xsY{VZ!Los>Vl=i{NVH4l6J|qj-pbSMbjfiT>n!htR~T zURbO&mc8Y$@z*SPM|o2h@TmrsTJ}k}3(n5qfs|%EP^ctp#`0=1|9waecZjcftGW<? z)#d;l-GqT+9tc;`-|@#x7DBC&9bg%4Jz(pqG~uo5ME>Dg5dJCKM2;&vbsE@odHRI? zrwwxPtTby^<@4lw2M%19jXfoX|J-U@8QiLUYw*o!9;L<NwvEsv!0V8p$cct|)uKY6 z`TsJWT~lz~X1iXhpG{9Vntbm!lj1Up9IQ-t9~V3jq1xp2T@kC{_E}@I`Q5;J=B~;| zFPDl`o6H5|<Rri<4A$;T%dss~)Kug%{KymTeD6Pf+3vV3>GM6vxLPrl?U^-XJ`=`u zbe(GKm0QPkNgsk6r%28Ivw@VH$ZS^)cz{2HqeAq<`oP#qCNH$e%0-g2CH?C2znyS4 z2#QxRx`+GdBR~82<b`A7ir=-e5Mdv@RJdd@JDG{8EE{@`n^u-52uWSfpXAf;Q^7Ev zHJl>VN+H?ek&*skM>y!t#)Y#gLGp}QnV<c1aKT<-ujkH2eHj?mv!d3eTYo4FO#+O6 zKL7+8kyL)$=rT{hYqs+L_<OwBp=iY2(b6*C4ntl>pY5Q>XM+u%DW#A0*tcS3a(h$l zYO2@=q`2oy3Gj*U5biHecfoAq|2%Suc<E+Gt*Y7mXJd(L{<)>gINHIvvta{iMzY?X zzFmJ}N`ikH{SUl9<nKy?0SrITzup*N*}z!iE>iVh%6oHis|zen;L(b|x%Q%7@9YVQ z(N@oauNi@CrYAL_QV2#N3og%9)Cc=U8od0NeYU?fM2=mM5ETbF+qjZEMR1-cSwy<W zqOVX=*jykSnE)bAbolr>cj)QUc_*^riGKmIm4Yv(&i(1HF&tC$F*lBY0VTCz*-lxQ zX$=|pMnb}4T8WoxMR0bxB_y_IXh4I;(PIAD?$5lSAVM9Zgc-_>sM$dM-NgfoQ9bPg z-37aPjKJuRE1Z}Yf0~Gb@%4J4PPk4sI{xZ*UWyg%G+Q=O;^djCcs1~~N_K~OV)LjM z#(}%9TgpP;#jh63SV={uLRlUL$j?UXk0ra%&??XEU%z@u8e2FCsm&E!U7ofU$-S!T z4EaiJgF}CUf%pnDC8J{wvv9S~YvfU{+|02vg-9kIKUyi*>v*9nWKJq1luK5nICmeL zBWWYY_#EiJ<nUk(0xX!(8v{^NGKozulsSSo+TNY!Go89aLou9Fb>liz^&Aj=iA?Rz z5sApV%Qx}tVo6u#1QX?5bk5u4F2!z*0g;}6%D9Lt=$QYSD}Nocq4VRicX8T;YmB`$ zp(xsnG9e3o<%p+w^-8b<QuQ8NBOzff@t`?UsdFpJ{O;P7SD#$(UsT7=4KMk`H21@Z zH`Y%ZXxB)u)!>kx!)noR*YZmjSQs2fZz`>*3unRu;jWMK-)yJiZ^Qx%Nxp2*3~9$# zC5kt5jlX9Q)2DC)DDjOEp`>l|AXozm07%}?NH-+Xt*-5(nqk86@AZm4!$d!JWd+vV zbN@<Idi7Z~+AjcO!w)4bO3>?$6A6>6{oXU%SC^?EH{`Nh{=E?p{!ri{(EbT}-W~S! zqX0ci5@T}aV%-xfvM$TJ(dF23b;42Ge@aD5FyimUA>7JGgSQrYIb;TBRBaOtANd*j z%rQT}0?nP!K}814#wV8OmcEcFh(MjGW-pz9v3R5DKqudQv05<Sy*1AGb2dmpAhDxY z)C%*u7j;91#`bzbCzEs7EP}WIQe=sDyTGGYxHgbK!1|wZeDz&7+WO%)Jeu}PbaFj6 ze%jUC<SI9eci8ZJ)$ombx-L~-$*JI#sSNmp1F{|c--01<+q<fVui-yKF^n$1<PHqB z(f1<rxB*k{3eX&AB^`vx-8sgHRiuOWs|aW*&?kEaulo>zxBGXAb8SpMOIB(Z0q>6z z9J*jF2jAykm(2r%{kyo!zxo+KEKnJUdSX6AU{9!5WcGICz)};#0W8QHezKloR2?&S zr@_*+HLiWN`IlcQXr*Sb1Eh+%TX6H>zkDD5RBd0nwT5oACzO+$J`Ls>fSGfGR^b0j zvb&6u&JPCNGRc;NJFJ>bS6cjVkx;-YqcKw_)^DfBU6u43j{B^k6XWjTcFUjodd9|f zaD*rx3tu@82(kM&HO9H|IN!rh6I71JMpb?efDYApDT4uiVQJdwIvAb+n@biy{{6V* z=jCMcdR4tGhd2|7*7&(Vf0mOz(ixPb-VQWQaB^~RV6y3Rh%KLX@i!?8ozDt$kcL{+ zPNo4NQ5Ta$$x+XP>g2U7cz$k<`slJdO971nRW|36M}uLRo1t-cH5=c^@{T4!NU5Cd zj<@0at~~CL9c5<e(FY~f%R>_0dX+V^oVm><%K|sX-cdO?3;_27yQOnXZ*P9{-mlg- zx-2MumTcN2yVBhuit$4+9&)uCj}^L^czPddUQwYU@Keq!aWB)fc6vxOizq<(YJ@Qh zUvL@Bul-zgb99JScYS%LCRsIU*!|K@KNPqEK0{vS!8e-$VNjLR2D!AjcXH>0$Ol46 zR8T<D<0tC3W<u2LRd-b|PID5=w^+Hq@~~1j{>A%^>J=e);nL;#k<QrCCM+Nn*u<{2 zM4O&d(AK2HkVt${6i|OqL;KUNQe46L8CIYn#UeJI_8~2bU9}su>!KuZ5)N#DwG<qE zVpjyb_8jXM6ui+r4ax9QsbBD3VZRbn@2XJM03sU!1)JQ`GUB7XuOo;T-JXO1eoFuC zArsz4z^;EQuFb#vI;)z8DBEbvFacbf_G=x(UOtM{uT~Y@97%Q8Y?iOU^8HQXAwfx0 zvVK)I=fHrPF_6taz8=1G_W4eU@iR)+R%3k5(OsR@Uh$lVdOYrD`h$r?g5j}5qJ}oX zj!4n+&r`uq3@87-l)Y_hkgeGX*dliT3t9~t!mzcI4mAH<RC-^Hb_aE0qN*7%mEQz2 zyr1Q~{Q{uwf4f%0Ou!iOQU1eme2z&W;gxZ8&CT%pwlecA-2zFhD>S0*yH|GB_~@A` zD<$`~AFfZDN^Bl2y>P?1W3>{|ZVK^cjC2F4zCDS->qlg7##5<yAMQNr_Zs^Foa;N4 zA=AaZNJvZ9{C$KvrK|_!VP-#;LSUCOU2KpD%=np!)t@}IG2U55Ad&Z;6^y<an?HpC z-VAjCZ#1`=^4xpQw*{<S49jFX4@Iqc$~&RW2?_xKl5Ine)0UAU8~9HmWvZ1Zv~xqD zLtE~mX~DdFKQF5Cw(gf}PsQhTjR{w6SZC4n1{w-sk6w^R>Ce+8Nho2{34sZ8bs%(t zlKdl1Aq9$#m-lZUBJu9u(4tTLZ2vQT9h!4HjcRSBOV+W($J<?nzZ`je<dWA8$tA4} z2M2qr=@iA&D0^Yoq|)VU<ss>6@>popnFVU<b+EfC^V|ASM%DMs=j(X>gp2rk_%2Xj z)YOP4=QI3Dq`ciNO?F<XHBk8WuDW|CcP@49DGw_R<kP}qTi(1!$v?}J1uk^^0kCvU zc=yH3j<%gFAOeb5WhF0a!X`VJXPUk@XA4|VaUdk)Qd{ifT@^NfFhN-iH)N#(3RMLG zqd?*hz5)=Vpl$a$Gp++9_7pT}q3FSpj9S?s!!1|+pH9oyT<AO$$l?t8>Vz;s#3+>= z@8zm4G&l8_zW%gU+O`LR!gAb^wPt#~{`RoL;Z~3NShl_6m@O{UQ0fhgXR5f3$V@p( zu$*h2J(*{weK1bJh3sq{2Xjp=BSQ5bb{nGxc=4jnJcV*4|5k~~JAizg58kNs>nQA2 zlF`A>JK5>r6M`$I0zzZpBaAx>%yrMR?+q?y0&WkY9$$3Du@4B&KF7e_C%^bIdJqo; zMSipIzI+k7cB3e)0<g!xfz!F=#bW0Tlz;G^JkaWitk%Qm(kK4PRt^k03nI_}O!rwh z#s+wK)@PBJ)YfjS5qC`QYh0AZ=EY4CdxQeG5(GRz@B_DO^}<kqJ4Oud2vz0pg-L=l zB&Y$Roq;^KRLFl@D<G56g2A&!T2^GPNqjg@5Lto3vQ1Nt`OyOT9ik&Se(R4X2Z6#B zivPD8Ws)8gGywQLu1TM;lBcdZxLE-e1AqI)|9pRb^c}N+;7h+7n+!*OK2JdW-<SSp z4E}Acr%H=YDx2o-q51dlzxV2f0c1Zj^rIl@x<V}wH9&qk>l-=Ve;FO9YVUtPh&~7m zK}v!EI<)zT?8`_eAH0pv=xV5HM`<a1h5|@ug}=N5rv0_9F7|Z}*gPQ|@Rh(^jokOy zFvGwh;O5$6u!2fpFFbk;HwAJ9S@*GRfQ~N(s3?HUA1pP3fv+D1zdxfs^a4MU)gG%^ zD*^mmQS@SxDmM5EiX0I8aU>L0YX})Yqbrvp;U_Fq^45SDQt5@+zw-OP|Lq+Bj+~qe zJZ+Evj1_CGo9of_&mmRn7<i`NK44D)k;|J7EnzcKz~p8JKR^imFMjlCL`XhO#0v%r zh1>re^Qi2F0u@4X8Fk<bllQ_10eK2MIRw_oi@zT`JSh77@8Lh6YIRQeu4=(J^~0?O zM=4K#=-9hJ6|(4>(u&C&QL;f(^|!Ati|dL^jMs!@^jWuGv9qK5)OX)#Cs(q)cc@|Y z(9zq%SBG=QJAPmbnAg+3MtjcO-LiFXM}|oeabGM@weMRMdXxuibkPuOIsTBDi{0B> z3>b!hL<^kIP1k%@NcF}-DtuW!&3&S6>7ElHL%1ExJs4}={vO6H(R}Cg7O4c>b3O5` zD;D`adHf_mbE>gmJUR=c^Y-9QMev%>oGN7bG<_Y`pS0y|jE#jJ$VQb95jGTFC)U)N zbVcP4c7{8tSNwGK{<bwHm?&2i-XQ`Sdc~Se#vgT);j~lSkYz%8a!G&eG;%hy9D~Zq ziED4Ba?{P-L6N^77Gi3caA$d`5c6=#M`J5@!t2?=RhgBIOH>yJ&EHEPO&W)I(RwNH z!E=WVlgOW+-`=c~H#Qc_CVi;D97#j$ZHQ9yu^ot;0fFRBTCJX1cul>!&`-Ap!|@B_ z>zzA?iMkH2&-=epzJQ98Cb}tA=a$_WnlI3$KlW`sJ$<52r+}vKCC{Wt-&@(um|N<) z_LhP02QKZqs+y*|=1UmghtGe>Ioip(&5S(-{E4YBW_=*WTm>mIa=?~`U+5-b=nGPE z&XwiA)+eQ!B%>fc5Mn7U_+7o}ae4n}h6zOSiXS`6GdexE;fjSr*L0P*XhV&BegLL3 z>m5&JUu?Wq=g8t>B5@S5@MbA9ZEX3QFYsG-acY`U3j6>#?_DBkfV3!zTyfSgR$ZTT zZ|+Og*REJ~THfJv$C`F$FJGI!@>*ijKb-F>{+<nkT14b~b8F~Iq4bL8{k|7H6YPHD z_l_9tZ9v{1?(?a~WvuY62_F;xee7I}B9R$Hsc-Aoqv9B&Ld$LvTL=w=qspr>17XRU z(oUR<lqZmxWb*Gz8piP*v=X36*=0AIDewE&zj?i~`0~n8Tjd;-H8CpLRLAWJJTjNV zk4LtOF(KwB6aT1BIlLxDnFAqT6x;@TdM$-El`T~BKvU|HSfY!3wu>nxU`ZGc!Tcgv zJ~y%lgBvEdN2i$cXNrbR**m;CwM$ve6G@_(k0I6>gPC5*?6V$4)xYGFMNHRT<X~G0 z8+c_d8Kw~7(#=%jt2Zw+^tQ|Dfw`hJl3snuyUCo=mL4VBXwH4udr=^|go9j0mp`t1 zc6qJ9kDMSft)SKyfj=M9l^__MY|=tVHv0XwCtpF(wxAui)+Qp8`h`k7A67naK<<Lq zk&)2Q=&~B-x>(Bjvkn;DnKUqrNl>o3r%#{;gE>Dg=b!3^V>Z$Vbg_*Vs6_iW4zJ@S zIdvvsx+WA1s*I{?3Ffh!qimf|BCx2q&w`V^OcpteJ&d;oa1+oK$hV1+4Ad}%IG}q) z;T%x@XgG2tmS4`<+u=eUQ9a9y{y6|Ej4-Wtrs7PN3$>&~1rZ<}79i=<(mkP=PR4|b z7IP?<uVr_5qlG&w;5Xs7q5Prn73=1LT5%MAD{MbDE?c9UkG?8swMdcd%Z|u2%+D=~ zm}Y82n|46@?-sNkkYVSpJ6XD87X#kT;tPJ(tZEw0!gZqqcIw^@(@&wn;PG}MkEU~9 z<F{OSHo~#SG=7k?Vu2aGjgcqtLS(nB1*YSJmy46ItAk-~hY*{>CUSjVC({Pm-FJjo zeMgc<q+Tb5sVv!f<i1C4UuFN&b$Gk*0LhcbHtV^i`DsGUO)XY6aLZm=M-de#!c_QD zz6i>2i=`JPl3P_sM1%bv(L6AK-`h@)>2o<P{YV+kN+T3K_<e#QwSb-<Jznwsdc>}; zPTpvEvGm*{`smU9dr`z01$_@QnxSC<@LW8s^;ocJY`1Xa?`DQ~)g~by0P%J)cY#p& z+a5zg+X5--hY0&b0n(md9Q>33n_X~T+@sy&gqTZy%(P&6rL$zu+>oLw^sTjT`!j}( zi{;40dS5qk-=T>1w1P~M)~ywWOd*G*D7sG!cFw-AtXt&&__{cx&Vk*fB5qD;xyNfh z7EQ8)3f2(pqSiIQ!I-PIMwnOUN-{W%a-%OyW`T**@QbEM!wlJpZL3^Iv=-WQU($Q@ zW|1W?M|{*o752l@Vyi+E^GZ#l&+k3gQ2iG{Uc&8q@A|>MvExY~P3xNb9u>oE!+!fG zWp3P;C*~0qD2>Boc<wW08ZX~qqk4{?zrH=_HiJwq>^0XsTT#6S8-TgLT|olr03YvE ztB>#R(1gjA#TZGH-|K7Dd`3sy%7C}djNj$_jc_Qbs$@V+d)755&(%ALeyNo|bkZUS z`1xSw+v8&=nxvlHNJqh<;oT-(t89Kr)hM7M(Bk5ctGEAsOL@`Dz5MrOL0lWrnfItX zYQK(nKyT0z?@X8|jn;@6Z6UJyYb^P_GT%rdKD)YqzH@=Ter!-IDDuUz;d{CEom~$q zCSY^Ub-=RMB}J=`<^o2(FJdyx^Y=G+%OTWj@e`Z{jVVH_J+xJ>5>5OgzWQ<FE65gu z*-l@YDexWC(5{z=9X;7f{^p>yx6|1VxTAke5S%J58gu&lnCZK2vlc_Z_q9eQgTNE8 z0eC9|G5ev9Zw5$W+uE+AvW-ly6-)mY!v$wn{8zgKNK;dQ3V>Sf(XQmFyAGgdvTA>Y zq4AH$4FNeb`LQJS2pB6SziWq65i;NXD2QguB%cZi83jfIu%T1H#DPdFFsftzZR&qm zOSqfjEaw*(g6n^3@58AzLqq+QhiAYIe8@np)<{fk#=Ryd$x?vO02UunYJmtaL9^ge zzyu{pEzmuyJ{4HmAV6zwjjV&uHs5nN7WN%GSXzoBFRMTP9wyE{8Pr}b0gMYOM~Ppm z2L96D8r>GaM{5{199lTtsN<lhcS;KutFyW=bCtGj&Por=U@%$KhJJx5MfB+0?Q7w) z*Na7C1xU+e1)pAIoUI(~yL5H>%6)9G@(4zE=H1Vk$eeLDHa5<9?{dXeXY5I*uXF$E zz<aR6hgOZS8gEmcdcDiDXL80FhPfB*<`R<^ZgWf^-ql-O%moV9c#^nEjse|skT>D= zCr&Q$YemBN;=+Rd<_qvPDZxTf-|XTlgl#+L4GEE^(1)25p`S6*`VV}#K1d8XWnu_G z0*3DvC7o)Rf}>uDxv<lsKR+hcb@94c6<bx)k_^g)JfVt1F#*gctYrGcKjb1A2%K89 z(UNXyMIbVBJCo(eGMJCm2$xDy+f~`W=ChW(!VP%)*?{w1?KZRNy;1Wl7X!bw{51Hh zLm{Cl(p-I^d8Bac$!%$XXXW|}Ma~CRy$ET^BJV&f7n)4b+uapV^~>Ncw5Y=LiDc)D zCq&tC^n*AT$hM}?X^}jKJJwMm6)>%BkA`8wi+=X)tr$6gY5ZLiI(>wf6K#))6>sl$ z@jB?OW21>j1=T#?)Bfvhnnn8fFRqUd65++Y59j-2{nc|BS-KJW0VB0j0GGeo3&Um& zv|%zH-1Xu!nW8O%<ASG8x?yWR(qbxtZ2f${TS3}sdekXqbk{U8Om3)p8DjE{3=61g zEni_k>)B7H#rNzj+P{h&Q4m?{zF!>@k#O_?O)e%Pcgfs{sj4RvS~#w6q+tmu%7N$4 z(;V;EAn#|vG18&RiJu#b<Z8RAL{nzVeLWY;kyj)48s&vNs1xrs&$GnyqV?O?)QOsi z-gVK0Z0Z0mzi}&Wq^(q31@~$iOa>P?_%s#YT&Hx!EbMfOi^)8C!zw<^CA&Su(9)GG z$Iot{q9=S$kgi|&cSqvp3J=QgJ1;8?nb9}2$*eMuD7!wxkIc~*ev0Icj`~2~$smN0 z(*I|0Ct$U=A5Qoc7DZ-?`(csnb9+6~Z=&%<-+mlgP_;iyTZ(L(5*DqGo>__uO<kW` z;}ayMrTF{(_<Pm)k5?HuKKsA;KaN)d(7x&~peX^OIGn(VK%>v}*V}Lll<&d#F+X?A z2jDrGUPNIHfB*M?b)x=HYf&RuR{pFNcA&al_PD>RyVAvc7dU5XfqU9u%`pLM(fYkR zN5WK=7jRn(Oye2@-qWI|{zxa_+I<Os=|tI!dvD@_Hz;R>+hKrO;uW~|Yz~3{7xSy{ z_iGi37w&fmRecQ>#K&9X1@QAB7{=C3r>*5vUhbF*u)tRQS|$YnRy@L%ljp$a`hWX* zgg)3lg;L2s##R6EWTRXdEW=<SGXd@)H_#6aKAvwnV?*562B}q(z4=&^AJIbp`R|9l z6surkxb~j$R{P<R3v$=w0vSjU5kwddXW9eF2`@6Rc>zJBzeP69Y*J+^9@yAGYL<rl z;WeN~0Nl*)6*nAWjawDTE`d@}Rk;gjPdy!6Yha29q*diByz?mOkFyKPg1X6@z`K_| zKZngvBRUn)#<{@q&w-3Xi>KJ{A1^5oNY(6AJZbPS{85o(^gD1u2|wph^#sB3sZ1*i zxKWE2+CNN@j0D^cVc(C{S(joVzz4pw0_zf-M2q<*=s4^8G2QVdWj>4%1oH3iiyv<$ zOiN!R03J48mv_w85%KzEs$1ZCN@gIU5D22?S(~%|dBzezasf91uma;#?Bkob-kHFY zn8p3SE)<6XX@!q62uMCG0MuE(e`tK#7q~Zl(xP+XK|!~$-17XFJn)Qj9jRDxyDFZZ z_&<95*YpF=Tq>YqD707<{@wpr;?ZNg%h7{iKz?3g5D>izDFR7?!N{Hdfew(90FiMw zkOsj5tErLg2^~lX?1Mh{%UVO8-2*8by428gQdC?&Lxk+1ICo4P?tCwdV1~hhJlx#q ztWdO-T<O5_&I`K7tXR-UpqK<hY`Us3CxF-&C<_p>!~g!^1uDd}P*RZ_sqNC(L6E5c z_Vh+C3;=HMKAu<uCiW8?qEnbuE!D~jI`&w9d@Wk`lM&|8keAa<fnx{ma$;F;J3GVu zy#_n!ji^r!Eluz5%%4P^n%1~}{xW3^jiJ?F?1;)~Rgu#!UstSbnXjR!+0CtMF4I#0 zG7?pjlad@VelwIkjHB_BYU!cusDT7k*9!#;5oCQU*{0Cvkq<~2#*5!fpX+^dYt#eU zHZ?X=Gt}W_I1*fPDdU|3g)>REoqCK`2?1*0p5Pq5NIq^2wUrsHU=kf!UMr@EiP+M- zG+B;eI_x3HrdJ5xIs9}orlPY$<91Q^U6%K1-9ttm-4ePj{JYUm!HFRkq@1|!*z^$I z<upZ8=!%;Faq+LROCWT1Pm|n?EmD56w56}rdht{;5B^0>VWhT$EXKDaF2ch42DV<a zZtKDOD*wye_=u|J%c2ogPZIO)Xe;U&B%vp%cD4u~rDX|Ri#pD7+ZWrJv|k%Xa$N@X ziXP@{xR}qs7b}7DHI%-Evrc5n4Lz@ndijAxJe!<ZLeGM0ULY=@E0C)&XQJo8SLBU# zct`w1po@-N+EW<^EiI<$_HwOK9smgIP))?7M0a8opaDcyUl;BL=CZLe?#~@)KVi<y zS&5y?vt{(v8f7+C&xg~Lt=1umAHI)S&*_TrC+dX-#2l-sDp*pd77W6|)E^}#F;m7? z6|tPQ9-;x8i22TtvMhDgZA)r*4W+Q)w*r$*3-8{i;x1eNOCxqP1S2vI>(FZ>^v$@h zo$K=gzIlVaCdC}WLDik3mGfh*xMu@o;RAK2hX@oxRc^?uub-~QXSN(td&D3cs;350 zlt&*4?lQd2X_Bg!-*mFHlH+{g-5L8tX6)ivo`KxxAQPweC`az<$)nWujBgjRg-9P{ zXWG3eLIv>-5@C3^JE&6fb--t@a&JJC=vahR;&Zo?mUfnkxjE66e8U^;Ln2-p+jb91 zq41@SBL?06sQwK;MWT0%;$MD<eZkWng!v)aa`1JlzBR(<Zjev1j+?qmzB0qa`fIFk zb@^FwT|`ws(!6;%SuSeQyK1`wM8-5>hYj_0CyFj^sf2a*3Z!M$A@-(p!Zj-saY!OM zXmx+otw}R<&89*kt&%EdA2YYOm&O;)h#FU0-R1~h{I8+2EjJ|-R|K3O_Hhmy2G|bj z_hr*RMEawtQmwK&NYN*;11jqWr@EM>4sAiwB?LK8=T;tgP_W<?zC-(dT;<2puxXjz zD88|8ErrOB0aP4yx++bRLn#-^7g5#AU7LLF6=GP9D^=!iPJY$?ptgiYzh0otuC>J> zb(tifLSk|BYr-Irjz^#Tu6n3c#jm8<<)w%#>}JE05v>pFw;uP*ruL_IQa2X!MJAG! z;MCAI)qZ}9-Ipih%gp{R0b@Y1=4c-yw*;8dCITtg04d%%>#X_*c+ZW^)J4C-vguC4 zx3RDTjqTInE>a_3#)bsDPeM$E@Vj67ZS5rWc75gaB(PhE$EaB=-J|xLOh;`Z#b(7s z14(`rPo)8QC29Vu&fD_Nf$;tvZ4!XI?Y2g)L_;h_?>OU)jUcr02B0aE@9eS`N!u1} zPgR=})i_yzc+kPYwZ)NdzMF_w2k^spw-+o%+4sr#Zp24b7*G{a>j@J)bV4>YA9~y$ zPA@uonFXf`J2G&NS^-IvW9RXzK+#dl=?tg-)h>yKnkFdk*qyq`^X_U@m{#LKPN;cY zpQD9HWorAw%C8HHs%8~xt0#`{8@MtNX#ufUPC2eD;pgQHXW>X@VRHG<=td&<$qB!G zc@Yo|4!PA*yJVGIUEh(+7VZ%JY2M6gUOvOgD-d2)n=t=C>{BDlbP&RT?OUvB`z-5B z-ggNZ$;3xp={J8k6~@Lsbd-DrD2eIKOde#zoB$3<vAX6(ehJ=sF5ec@iWiN%#ZKY( zS$#I`-ZYF$1U=B6lDedjvRSv7(F%Z&Jc!tCn~aZln<~C$d=ME^MSqWXb`qUU)V+${ zb6{@adx)doKmJjjY=aD$A<7!T3%c6?@Auc{FZI|qHkn2+Y4Enf%4d9L1W0wM04O<j zs#&A9Uoz3B4v6P%=lo^Nc8XBxP;q_r(fHcxFVtlgOy8{Vtcx_*3N_ae&=sr1{JtQ~ zCH+Y5zk*};a^3|>6qi@`koz#IckMDyM?5lx_>1;J{}jH3;h3V6^gER|-7-;_f_e44 z)T&jgE>+>9b1FV>n&hL3@a^G?ZcMT9hJa7#3qbNutz$nt_9NYYp>1QDLoH2#${~ni zxZ>hL_Fh!nyS>Ef)0NuMK**1-Of~jb8{e1`Q>+YW-!-_|iopG(IG&^}kha`v#3ux7 zes%CTyrTUOR6_FrFQ<8u(4ar15e~iGH{f9&7eHZ{k>Q)I6Zn&u$Cb8Y=RKD^A^LNl z^!uhYBxgZ4EYW;Pyu0DxS7N`*HSs5DR_E)O)Xe+9`_^U|u-)C%%%Jh`XZ#O$J_7{H z!li+Ts&BFWS!xBM=iSTopEZ_xVlAhuD3nlf4Hj}wreSKSq1=?<k(Vz(NBO7!C3;{G z?@Pni`K$eyDP1JQT&bywjj1}Ld-CHJo_?jK)40V$efRbVMCcbc?znz?*2CPErf#^4 zSgLU3C2uRz8en{gfgrrX9pu&i!JK2T2ZRxF--6-__XzB4C*BeII20C1no~iK_z{0= z2{>2T3!^&CT0fDr-Po~^prEhpne7Px1;j4c&Wvqb*ge6BP$UIG+CSO^b^0~|PmB?} zS$gE!HK7p%Z)3&Bw=(DRxRYyI&z+V%LO+kWwhlxIpP|g!D|fbQ<HgB@(o5oPAbfXh zk$k(FLTDyRbgKY&!Y{8cg5O9<%E2WT7~Xa6N!Tb?*6yckqyRthCB<q&d<ezF2OvyO zuPL#ZqpGidL0!NVva?HDs~x;~`ZBc!7*6mF3`c!IJx*K!R`2=r7cEu0ZatiA9nh_w z0BZ=YfQs`_wZKk@3)ep5R6x&34kA!-8zd-xHUQ;FDuq|A71;yuQ%QjkKt#c$LN*U5 zI|F%)d<|bww~0k@Rc+~6$}X-6WH>c@3Uns&EU^Ni1!;>o{z8t9RJH{M;Cg{{;vG0P z7gvv3gs|MnAt$Gb>Ww0`h?1Yo(U9+=%A_BZt{J>|`_`4xO$(Eyfu(2!6b@imV)CpZ z>&RkEY*svm53#=(zOjf%p6&XP1#$4lZB5%X_ox@fDiA$v)adT{P^fuskm;gsy{qR# znETVoV$8=ht8OsM=^)=gDuLzldgqnsAE6cH|6+`2UuoQ*^c_vbrPq9))}KVqiWj1O zp)0yJqSewEPa&By4lgo4akkg3_wkIPH$orJ0zLi{dRu;2xK>pEuCOCy0krB`Kp_+K zUEQ+nAP@D*7P2AfGi)CYwupSg`m7J}^=a<Yr>*J*wrupG*mzGlDL-U)tMQ^0bt!!1 z1P0#}$G`_IJEnWuyVLOP{^I1HYdAi9l=cH&`Ye76edO&!@{VTHxT9{}`N(XKXIQw$ zHyZs~Q2NApvw!!oCB#it3v2M)nfak);--A@QO9yUE7)Buc9pcuBy`@8juYY`J7dUE z{1zi^#<@*WbRHFV5qFbb*cb4yZg!m>`fKw=Gjk`E-u!f1r?>d1Q``arzb(eHTE;TI z&pSN7(%4s82w%(?1FCqZWarFZ!{aSd7xYhc-lfaEkWrx$op`qYDxzg`;FATWvxjgA zQWK-#n%h<IpgIRrxpA&2&j0ze&eNmr7D+q~Xmk|}>$9B1)q`D3AWxo(ZTrk{C&`uN zP9z_8PH;1U1}m>6fNeaEb5(7cD_{zmX}@=*9B_oU2|D~~ys~S<r4aR8;I9Ol&4Cst zIWRG;obBF^aMLsmc1T$Nh?^$o6=_da|AiMW)3XiW)SX2zN~RF8S}hdpTO4nqC9h)) zi+X2fq)R#6+()|sJ{QF8f?mjE!ER*M-JoWy=Cy>R_iCVENo_P<9}IeP<}A}kQCK}D z42K(ObTN6=qbryI4*-@Ym9(e?a5ByKyoeeDS2F<Axva}Bf@Pj6vIgX(`HD|kI<MY$ zv-7Ju(vIEfa2Eg%pg0sw;ku$bYjrOoFovTunQb=X6-GgI=GxX`B7~sj9!hO{LiPmj zHEXxVQ=qdkx;9)y;7gJeC?i!Ilgze|VT)1A+apg3QCj<6OVSFWBzCEIMTiMgTgYUG zk`niv%45ebFp=E{fcsGKA$5c<5{UAPduNj{f*p^qOcepW9tg>=g<Hlu1-GV~W|VJj zpS->A1ev5xs85S~q=D(IWrJXuRZm<<dsBY3&5A6_+qF)lBHu#z(a9dgDQqq&!P#uP zg;HyZzFwaTU+X+E6l=`wQs_2IN-(O&l#_gpkDfLv9EF8>&+w{BynATnzryHGc{Mu3 z#m=kWs}0671(XJKs&($On_d@dSa>nkR%^QKRQM|W85!2xF)vnF_ElsG{#sZ+Y#ZSX zC1s?9*9?k*&9pw{Rt7zG{D|pu8|uolI|-l=T5&YCO<2ijHEJn-QSWm*g|puEX=_s6 zs=cTH-8_bO7ieaJ<xI3Q(<TFK99(9BfVYY7541`H|4|YL8Xy@z__ZmC7O!t)li?a+ zuJn#N@N&9KOME!mu2$>o?vNSTXN~3z@%3&zh=OdpFXE|UL{{v^z1J9*n@yF3mR1&X z#=Xr*ji@)rm!I(AlRCr#m`AFmw0F%D5k;@d21>)zpYKNnWU{I3s?k|gUo9GYdtn+P zP834@M4D*!`bRTE-S=Vqu3r|i!pFa6ZjN|K(E@NpGV#*(CnFD?hFTgq82{V3Pti%t zgtWvHW^%iR+JV0H_0il>X;wMoltSALfonfFFHSnY4V6n4-F^w5BbB$a<$9ZWx5l?% ze5jpAsR0&}0=<G7xNCY@sH^W9B43!H%=xSPmY05`$<$-&zQrpp{U3HlC+-ME$7C!h zaON!q<f$<vBqo5(3mR&)pM8ANxs$%Yh{I-4ZM@1Hjy3<7?^cr==Tz>-jJj(mzuxW= z_01xLQz{hJbKZ_Y>+>K+EsU{b!;c>;oVi5TA(m(F4L;L&Aa=~0^dUGLL$4ymw?<QV zsk9(G6hXdg9-`RsW>eV#vTvr4p(kVf8JFc-okL&a9!Fw+-!}IAK~uu2)}2m@hFVwY z?(ZZ|3DmX8<qv*1SSSPa+cm}%>0vxY>fDDd)!JFs@s0pG7y@KgU%Af4_FSM-X!pSX zoMG5@Q&6My18Y^!=tXeRv01s4q{SDQUI;?1UK}M&bsjaqK2}%#TCa*$;+W}D=XoqM z9Kn|fpL6OqhuHtAQLz<P5!u6YST_mqrbsy>+q-BJS**#Q{;6$djOTcK*jQk(B0hf; z5xn0Wq!?8r&jo-eGHlK+`{B2Iy{8%Us1Zu+>TQa`J!`$IY9N~;st}R0vGkD!!!h}% z!->a%GI-){mP(`<<9%!01QHO1uxD~Z+Y}#^owMPZx}B1|{@FACaRHTr&8y=PttEr# z;+#3E=U%pvXqj#zfFMfBuwAL45|2!2A6I_VG)nN*Dy86`>DZdc5Z_vJYq&XK%w8Ni zyp2cO6!o=0MxT{7fee77k~!P>EH8V^7w|^|j`8JuCf4^kMqxj4pC!V(Y6{>TQUFOK zOLo11y}HCBr?*t<pf+tJHqhPqtJ#hR*!hFze%-)JH!^mY&xKtd9J_c<6J*ojnkL7N zXr6sUcFCZG;2_ui?V${2&wuMnwHzm-40Ux>aC-_f^v&k{`O+CyOR8EQO{bR99Ng@< z%$y_5!eWK&jyj2=vq~*6|1<K=qGDc2Z~9Eom-GdjR$`nJ`BC{(H1^Pyb=J7PWp|y( ztrMd(uN&dwG~uiH8u!;6jrF=FXp~QqS8Cs+i8A{uMr9Baesdr&8@J<2NSkKG?V2go zF#{HI#&7^#3g(8ShF-1m{Qq(AZPJ&^ADM#Rk^$1(eb3++?M*kJ>$S&<JBBdcV?D6d s^ugX>gh^dy48Hom`>U$BwCwoQs7A7(WSREvU*L~|jLL&@DU-ne0nLLls{jB1 -- GitLab From 22d9fe9bde770a18526f2ef635423d3a637dfb24 Mon Sep 17 00:00:00 2001 From: RieksJ <rieks.joosten@tno.nl> Date: Sun, 25 Oct 2020 10:46:08 +0100 Subject: [PATCH 07/26] terminology updates - wip --- docs/terms/action-type.md | 13 ++++++++++ docs/terms/action.md | 8 +++--- docs/terms/actor.md | 5 ++-- docs/terms/agent.md | 11 ++++---- docs/terms/author.md | 2 +- docs/terms/business-transaction.md | 2 +- docs/terms/colleague.md | 6 ++++- docs/terms/commitment-decision.md | 2 +- docs/terms/communication-session.md | 2 +- docs/terms/concept-file.md | 2 +- docs/terms/concept.md | 5 ++-- docs/terms/credential-catalogue.md | 2 +- docs/terms/credential-type.md | 6 +++-- docs/terms/credential.md | 2 +- docs/terms/data-collector.md | 22 ++++++++-------- docs/terms/data-discloser.md | 4 +-- docs/terms/definition.md | 7 +++--- docs/terms/dependent.md | 7 +++--- docs/terms/dictionary-file.md | 2 +- docs/terms/dictionary.md | 5 ++-- docs/terms/digital-policy.md | 6 ++++- docs/terms/eSSIFLab-scope.md | 16 ------------ docs/terms/employee.md | 7 ++++-- docs/terms/employer.md | 9 ++++--- docs/terms/entity.md | 5 ++-- docs/terms/glossary-file.md | 2 +- docs/terms/glossary.md | 23 +++-------------- docs/terms/governance.md | 5 ++-- docs/terms/governor.md | 14 +++++++++++ docs/terms/guardian.md | 7 +++--- docs/terms/guardianship-type.md | 5 ++-- docs/terms/guardianship.md | 9 +++---- docs/terms/holder.md | 6 ++--- docs/terms/identifier.md | 2 +- docs/terms/issuer.md | 2 +- docs/terms/jurisdiction.md | 28 +++------------------ docs/terms/legal-entity.md | 8 +++--- docs/terms/legal-jurisdiction.md | 14 +++++++---- docs/terms/legal-system.md | 9 ++----- docs/terms/owned.md | 4 ++- docs/terms/party.md | 17 +++++++------ docs/terms/pattern-file.md | 2 +- docs/terms/pattern-guardianship.md | 2 +- docs/terms/pattern.md | 19 ++------------ docs/terms/policy-governor.md | 6 ++++- docs/terms/policy.md | 5 ++-- docs/terms/presentation.md | 2 +- docs/terms/principal.md | 13 ++++++---- docs/terms/scope-file.md | 2 +- docs/terms/scope.md | 32 ++---------------------- docs/terms/semantics.md | 2 +- docs/terms/term-file.md | 2 +- docs/terms/term.md | 22 ++-------------- docs/terms/transaction-data-collector.md | 20 +++++++-------- docs/terms/transaction-data-discloser.md | 2 +- docs/terms/verifier.md | 10 ++++---- docs/terms/wallet.md | 8 +++--- 57 files changed, 194 insertions(+), 268 deletions(-) create mode 100644 docs/terms/action-type.md create mode 100644 docs/terms/governor.md diff --git a/docs/terms/action-type.md b/docs/terms/action-type.md new file mode 100644 index 0000000..a818c4d --- /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 cebf688..9360658 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 39569a0..5715657 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 5a6a8f5..63898d3 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 99e08eb..363b6d5 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 d25c3c4..6825258 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 e4a6687..8b73d14 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 885e8d6..46dc70b 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 12ba136..5956be0 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 4c6917d..a947744 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 97f89f8..737b199 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 69d6ff6..c6bae59 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 d9037e3..3a2a1ad 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 45d49fa..c594e82 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 7bc1f06..6b7650b 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 39eee09..a24c00d 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 f49c33c..26e6046 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 0717c18..2aa5cd9 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 00c5c96..a2064b7 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 0a2cc2a..23aa5ed 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 3b8134e..4a17650 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 d06c08c..6b5d8cc 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 902f97c..e0be130 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 e86dd9d..e06937b 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 6e5dd3c..ef44162 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 3fde8a9..24ee10b 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 1038481..c28430e 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 209a02f..f82ed11 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 0000000..c5b8a4f --- /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 1f31731..8f3731a 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 74b2f03..8833643 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 b295780..5d19403 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 03bb436..ad51cec 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 5098a72..0d69e20 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 da04476..fe9c878 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 893183e..26f1887 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 eb30900..dc21ca1 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 027dcd8..300af14 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 dd662b6..53ba59c 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 1f5ac0a..1f583cb 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 c0c3458..8285842 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 233dd29..c96aac2 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 65a0cff..5e80877 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 7f43075..024d02b 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 75c703f..29156ab 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 7cb5e0d..63bcfaa 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 c0f69b7..5663e67 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 f3773b7..4e90ca7 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 1d890fe..a5efb63 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 3a14770..6cd9395 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 e42ac8e..546e504 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 5bcee45..cd823fc 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 68027d9..9291e09 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 4fb33e9..89b457b 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 152e9ba..c58f5d5 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/verifier.md b/docs/terms/verifier.md index f8ece61..6c8a83d 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 532741c..36a1bbf 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. -- GitLab From 0642d3eb8c8c796b896ed54408389a28797c88d5 Mon Sep 17 00:00:00 2001 From: RieksJ <rieks.joosten@tno.nl> Date: Sun, 25 Oct 2020 14:58:00 +0100 Subject: [PATCH 08/26] update and test %-selection regexes --- .gitignore | 1 + docs/functional-architecture.md | 58 +++++++++++------------ docs/terminology-maintenance-script.rieks | 48 +++++++++++-------- 3 files changed, 57 insertions(+), 50 deletions(-) diff --git a/.gitignore b/.gitignore index e093ec3..a5da0c1 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 062ce98..b7854db 100644 --- a/docs/functional-architecture.md +++ b/docs/functional-architecture.md @@ -26,9 +26,9 @@ Figure 1 shows the initial *functional* eSSIF-Lab architecture, and its scope, c 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*. -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 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 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 is involved in such a transaction, it will be communicating with a component that it assumes to be an agent of the Peer Party of its principal (the 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)’ to refer to an actor with which the specific 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 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. 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\].--> @@ -51,7 +51,7 @@ The top layer (in the red rounded rectangle) has the functions of actual busines 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 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 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 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 context is properly maintained if it chooses to exchange data through different %%communication channels|communication-channel%%. 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. @@ -65,11 +65,11 @@ Apart from each having a specific task, as described below, implementations that 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 **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|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%%. 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 **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 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|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|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%%. ### 2.3. SSI Protocols and Crypto Layer @@ -123,7 +123,7 @@ The purpose of the %%data collector|data-collector%% is to produce (transaction- Typically, the %%data collector|data-collector%% would start a 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 is instructed by, or on behalf of its %%principal|principal%%, to request a specific kind of 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%%. @@ -142,7 +142,7 @@ In order to make the %%data collector|data-collector%% work, a %%Validation Poli - 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. @@ -160,7 +160,7 @@ As long as data is needed, the %%data collector|data-collector%% can intermitten [^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, 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|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. @@ -176,34 +176,34 @@ As long as data is needed, the %%data collector|data-collector%% can intermitten 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). -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. 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. -%%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 (%%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\] -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|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. ### 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|holder%% Policy%/Preferences permit this, the %%holder|holder%% then requests its %%principal’s|principal%% %%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|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. @@ -221,7 +221,7 @@ Typically, and at any point in time, %%parties|party%% are capable of expressing 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). -%%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. @@ -244,7 +244,7 @@ The purpose of the %%issuer|issuer%% component is to issue ‘%credentials’, i - 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.) - 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). @@ -263,7 +263,7 @@ 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. @@ -278,7 +278,7 @@ 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. @@ -288,9 +288,9 @@ In order to make the %%wallet|wallet%% component work, a %%wallet|wallet%% polic *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 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 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: @@ -299,13 +299,13 @@ The SSI-Agent Network Architecture has two viewpoints: 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: -- 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|credential%%, …)? - 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? - … -%%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 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? @@ -334,7 +334,7 @@ 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), 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|credential%% will need to support such ‘asynchronous’ ways of working. ### 5.2. Transaction Negotiation Phase @@ -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, 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,7 +359,7 @@ 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’ 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|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: diff --git a/docs/terminology-maintenance-script.rieks b/docs/terminology-maintenance-script.rieks index c7ed67d..ac6418f 100644 --- a/docs/terminology-maintenance-script.rieks +++ b/docs/terminology-maintenance-script.rieks @@ -17,6 +17,7 @@ beg = "(?<=\W%%)" mid = "(?<=\|)" end = "(?=%%\W)" +ss = "(?:['’]?s)?" dutyright = "(?:dut(?:y|ies)|rights?)" dutyright = "%{dutyright}(?:-*(?:/|and|or|and/or)-*%{dutyright})?" @@ -29,7 +30,7 @@ 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. @@ -38,11 +39,16 @@ filter "docs/terms/credential-type.md" // with "$1$2$3" // 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%..... +// replace-regex "(?<=\s\(?%)(\w|\s|\(|\)|[/-’'"])+(?=%([)":,.!?]*\s|-\w))" +replace-regex "(?<=\s\(?%)([^%]+)(?=%(([):,.!?]|\[[^\]]*\]){0,2}\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 non-matching-text, %verifiers, %verifier's, %verifier’s, %verifier:, (%verifiers), %verifier's..... %verifier’s,?.!? +replace-regex "(?<=(?:\s\(?|/)%)((\w+((/|-|’|')\w)?)+)(?=(\)?[:,.!?]*\s))" with "%$1%%" // Then, we can expand %%show text%% into %%show text|show text%% @@ -68,25 +74,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 +100,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 +123,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 +145,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)%{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" -- GitLab From f9c6a6cb79c2dc1d0d6445a9f6449e68c23fb783 Mon Sep 17 00:00:00 2001 From: RieksJ <rieks.joosten@tno.nl> Date: Sun, 25 Oct 2020 16:17:08 +0100 Subject: [PATCH 09/26] updates regarding %-references --- docs/functional-architecture.md | 116 +++++++++++----------- docs/terminology-maintenance-script.rieks | 14 ++- 2 files changed, 67 insertions(+), 63 deletions(-) diff --git a/docs/functional-architecture.md b/docs/functional-architecture.md index b7854db..ed9a585 100644 --- a/docs/functional-architecture.md +++ b/docs/functional-architecture.md @@ -7,7 +7,7 @@ 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; @@ -20,17 +20,17 @@ To this end, this document provides an overview of - 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. -## 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 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*. -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 itself. +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 itself. -When an agent is involved in such a transaction, it will be communicating with a component that it assumes to be an agent of the Peer Party of its principal (the 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)’ to refer to an actor with which the specific 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. +When an agent is involved in such a transaction, it will be communicating with a component that it assumes to be an agent of the Peer Party of its principal (the 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)' to refer to an actor with which the specific agent has a communication session. Note that establishing whether or not an actor is a Peer Agent does not necessarily require knowing who the 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%%. +The figure below is an overview of the most important *functional* components that any party needs to conduct electronic business transactions. <img alt="eSSIF-Lab Single Party Functional Architecture Overview" @@ -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 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. 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\].--> @@ -51,29 +51,29 @@ The top layer (in the red rounded rectangle) has the functions of actual busines 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 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 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 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 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 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 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, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other parties. 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 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|credential%%) 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. 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. -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. It does so by creating Presentation Requests (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'), verifying the Presentation, i.e. checking the signature and other proofs of the veracity of both the construction of the Presentation as well as its contents, thus providing the Data Collector with verified data. -The task of the **holder** is to handle %%presentation requests|presentation-request%% that it receives from %%verifier|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|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 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|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%%. ### 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|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. 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. @@ -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) @@ -95,7 +95,7 @@ It is expected that there are already some interfaces out there that may turn ou ------ -### 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 @@ -105,7 +105,7 @@ The **SSI Tech APIs** interface layer is the union of the interfaces of the comp ------- -## 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: @@ -125,20 +125,20 @@ Typically, the %%data collector|data-collector%% would start a transaction eithe - 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|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 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%%. 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). 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, 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|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: - 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 criteria (business rules) that should be used to determine that the form is ‘clean’, i.e. that the necessary and sufficient data have been obtained and that they are consistent, coherent, and suitable for making a transaction commitment decision. + - the criteria (business rules) that should be used to determine that the form is 'clean', i.e. that the necessary and sufficient data have been obtained and that they are consistent, coherent, and suitable for making a transaction commitment decision. - the kinds of %%credentials|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]. @@ -148,11 +148,11 @@ In order to make the %%data collector|data-collector%% work, a %%Validation Poli 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 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|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 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'. ----- @@ -162,9 +162,9 @@ As long as data is needed, the %%data collector|data-collector%% can intermitten [^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|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. 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.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,24 +174,24 @@ 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, 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|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%%. +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|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. -%%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. +%%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|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). +- 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|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|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). @@ -203,13 +203,13 @@ The purpose of the %%holder|holder%% component is to handle %%Presentation Reque 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|credential%%, %%issuer|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|principal%% %%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|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 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 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|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,9 +217,9 @@ 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, 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|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. @@ -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.) - 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 policy|issuer-policy%%. +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%%. @@ -268,7 +268,7 @@ The primary purpose of the %%wallet|wallet%% Component is to (securely) store da 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,11 +278,11 @@ 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|wallet%% 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.* @@ -294,10 +294,10 @@ It is conceivable that the set of SSI functions is spread over multiple %%(digit 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|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|credential%%, …)? @@ -305,13 +305,13 @@ An individual %%party|party%% may use the single-%party SSI viewpoint to come to - How should a %%party|party%% specify the policies for the various SSI functionalities - what kind of support would be useful here? - … -%%parties|party%% that want (their %%agents|agent%%) 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 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. 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,7 +334,7 @@ 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|credential%% 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), 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|credential%% will need to support such 'asynchronous' ways of working. ### 5.2. Transaction Negotiation Phase @@ -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|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, 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, 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,7 +359,7 @@ 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|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: @@ -368,7 +368,7 @@ We foresee two ways in which %%credentials|credential%% can be issued: 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, 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%%. @@ -388,13 +388,13 @@ When reading the next sections, please be aware that when a component of one of 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 %%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%%. diff --git a/docs/terminology-maintenance-script.rieks b/docs/terminology-maintenance-script.rieks index ac6418f..bae6a65 100644 --- a/docs/terminology-maintenance-script.rieks +++ b/docs/terminology-maintenance-script.rieks @@ -17,7 +17,7 @@ beg = "(?<=\W%%)" mid = "(?<=\|)" end = "(?=%%\W)" -ss = "(?:['’]?s)?" +ss = "(?:['’]?s|\(s\))?" dutyright = "(?:dut(?:y|ies)|rights?)" dutyright = "%{dutyright}(?:-*(?:/|and|or|and/or)-*%{dutyright})?" @@ -34,21 +34,25 @@ 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" // First, convert %show text% into %%show text%% // 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%..... +// 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,2}\s|-\w))" +replace-regex "(?<=[-\s]\(?'?%)([^%]+)(?=%(([*_):;,.'!?]|\[[^\]]*\]){0,5}\s|-\w))" with "%$1%" // Only thereafter can we convert %showtext (words without trailing `%`-char) into %%showtext%% // Test set: none may match: %verif%er, %(our) (verifier)%, -// Test set: all must match: %verifier non-matching-text, %verifiers, %verifier's, %verifier’s, %verifier:, (%verifiers), %verifier's..... %verifier’s,?.!? -replace-regex "(?<=(?:\s\(?|/)%)((\w+((/|-|’|')\w)?)+)(?=(\)?[:,.!?]*\s))" +// 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%% -- GitLab From 05577c17eef41841e6e1f0e2ff5287bb42bcb05f Mon Sep 17 00:00:00 2001 From: RieksJ <rieks.joosten@tno.nl> Date: Sun, 25 Oct 2020 16:46:21 +0100 Subject: [PATCH 10/26] maintenance script seems to work ok (at least on architecture document) --- docs/functional-architecture.md | 12 ++++++------ docs/terminology-maintenance-script.rieks | 10 +++++----- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/functional-architecture.md b/docs/functional-architecture.md index ed9a585..35ca742 100644 --- a/docs/functional-architecture.md +++ b/docs/functional-architecture.md @@ -69,11 +69,11 @@ The **wallet** functionality includes the (secure) storage of credentials - both 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. It does so by creating Presentation Requests (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'), verifying the Presentation, i.e. checking the signature and other proofs of the veracity of both the construction of the Presentation as well as its contents, thus providing the Data Collector with verified data. -The task of the **holder** is to handle presentation requests 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|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 that it receives from verifier components (both of its principal, and of other parties). Typically, this means looking for the requested data in the principal's 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 for the purpose of obtaining the needed credential, which - when obtained - it can subsequently store in the wallet and use in the 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. @@ -150,7 +150,7 @@ The %%policy|policy%% must be designed in such a way that it is extendable as ne 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|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 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'. @@ -193,7 +193,7 @@ The request message must be designed in such a way that it is extendable as new 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|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|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. @@ -300,7 +300,7 @@ The SSI-Agent Network Architecture has two viewpoints: 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|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|credential%%, …)? +- 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? - … @@ -334,7 +334,7 @@ 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|credential%% 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), 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. ### 5.2. Transaction Negotiation Phase diff --git a/docs/terminology-maintenance-script.rieks b/docs/terminology-maintenance-script.rieks index bae6a65..ad3cf72 100644 --- a/docs/terminology-maintenance-script.rieks +++ b/docs/terminology-maintenance-script.rieks @@ -39,8 +39,8 @@ 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%% // Test set: none may match: %verif%er, %verif"ier%, "%verifier%", `%verifier%` @@ -56,8 +56,8 @@ replace-regex "(?<=(?:\s\(?'?|/)%)((\w+((/|-|’|')\w)?)+)(?='?\)?[:;,.!?]*(\[[^ 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].*?)(?=%%)" @@ -151,7 +151,7 @@ with "$1policy" // For 'rights', see [D]uties replace-regex "%{mid}(risk|scope-file|scope|ssi-agent)%{ss}%{end}" with "$1" -replace-regex "%{mid}(statement|claim)%{ss}%{end}" +replace-regex "%{mid}(statement|claim|statement%{ss}/claim)%{ss}%{end}" with "assertion" // [T] -- GitLab From 356d2f6678bd48fff990cbadff2ef1a3835aad05 Mon Sep 17 00:00:00 2001 From: RieksJ <rieks.joosten@tno.nl> Date: Mon, 26 Oct 2020 10:53:19 +0100 Subject: [PATCH 11/26] terminology updates - wip --- docs/functional-architecture.md | 124 +++++++++++----------- docs/terminology-maintenance-script.rieks | 10 +- docs/terms/transaction-id.md | 18 ++++ docs/terms/transaction-request.md | 17 +++ docs/terms/transaction-type.md | 14 +++ 5 files changed, 116 insertions(+), 67 deletions(-) create mode 100644 docs/terms/transaction-id.md create mode 100644 docs/terms/transaction-request.md create mode 100644 docs/terms/transaction-type.md diff --git a/docs/functional-architecture.md b/docs/functional-architecture.md index 35ca742..27b116d 100644 --- a/docs/functional-architecture.md +++ b/docs/functional-architecture.md @@ -9,28 +9,28 @@ import useBaseUrl from '@docusaurus/useBaseUrl' ## 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 -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 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 is involved in such a transaction, it will be communicating with a component that it assumes to be an agent of the Peer Party of its principal (the 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)' to refer to an actor with which the specific agent has a communication session. Note that establishing whether or not an actor is a Peer Agent does not necessarily require knowing who the 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 needs to conduct electronic business transactions. +The figure below is an overview of the most important *functional* components that any %%party|party%% needs to conduct electronic %%business transactions|business-transaction%%. <img alt="eSSIF-Lab Single Party Functional Architecture Overview" @@ -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,13 +47,13 @@ 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 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 context is properly maintained if it chooses to exchange data through different communication channels. +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 (or 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. 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. @@ -63,19 +63,19 @@ The SSI Roles Layer contains functional components that provide the functionalit 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', 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 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 **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 - 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. 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. +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 as it tries to acquire credentials from some other party for the purpose of negotiating a business transaction. It does so by creating Presentation Requests (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'), verifying the Presentation, i.e. checking the signature and other proofs of the veracity of both the construction of the Presentation as well as its contents, thus providing the 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 requests that it receives from verifier components (both of its principal, and of other parties). Typically, this means looking for the requested data in the principal's 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 for the purpose of obtaining the needed credential, which - when obtained - it can subsequently store in the wallet and use in the 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, 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. @@ -91,7 +91,7 @@ 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. ------ @@ -99,7 +99,7 @@ It is expected that there are already some interfaces out there that may turn ou 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. @@ -118,27 +118,27 @@ 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|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|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]. @@ -148,23 +148,23 @@ In order to make the %%data collector|data-collector%% work, a %%Validation Poli 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|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'. ----- -[^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|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.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,17 +174,17 @@ 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|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|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%%. +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|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 %%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). @@ -195,15 +195,15 @@ In order to make the %%verifier|verifier%% component work, a %%verifier policy|v 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|party%%), 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|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 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|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 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 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. @@ -217,7 +217,7 @@ In order to make the %%holder|holder%% component work, a %%holder policy|holder- 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|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|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). @@ -241,7 +241,7 @@ The %%data discloser|data-discloser%% may either push %%credential|credential%% 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 policy|issuer-policy%%. @@ -288,9 +288,9 @@ In order to make the %%wallet|wallet%% component work, a %%wallet policy|wallet- *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|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|digital-agent%%, 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: @@ -302,7 +302,7 @@ An individual %%party|party%% may use the single-%%party|party%% SSI viewpoint t - 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|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: @@ -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|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, 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. @@ -364,8 +364,8 @@ In the eSSIF-Lab context, we take '%%credential|credential%%' to mean any (set o 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 @@ -386,7 +386,7 @@ 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. @@ -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 ad3cf72..93d6d15 100644 --- a/docs/terminology-maintenance-script.rieks +++ b/docs/terminology-maintenance-script.rieks @@ -174,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/transaction-id.md b/docs/terms/transaction-id.md new file mode 100644 index 0000000..2d0a69c --- /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 0000000..a0b1b08 --- /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 0000000..edecd79 --- /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. +::: + -- GitLab From 2cf6ea78a3586398852cecc338efd6e3c7b16dd8 Mon Sep 17 00:00:00 2001 From: RieksJ <rieks.joosten@tno.nl> Date: Mon, 26 Oct 2020 13:10:26 +0100 Subject: [PATCH 12/26] added `glossaryText` header item in preparation for improved glossary generation --- docs/terminology-engine-v1-templates/concept-file.md | 1 + docs/terminology-engine-v1-templates/dictionary-file.md | 1 + docs/terminology-engine-v1-templates/glossary-file.md | 1 + docs/terminology-engine-v1-templates/pattern-file.md | 1 + docs/terminology-engine-v1-templates/scope-file.md | 1 + docs/terminology-engine-v1-templates/template-file.md | 1 + docs/terms/action-type.md | 1 + docs/terms/action.md | 1 + docs/terms/actor.md | 1 + docs/terms/agent.md | 1 + docs/terms/assertion.md | 1 + docs/terms/author.md | 1 + docs/terms/business-transaction.md | 1 + docs/terms/colleague.md | 1 + docs/terms/commitment-decision.md | 1 + docs/terms/communication-channel.md | 1 + docs/terms/communication-session.md | 1 + docs/terms/concept-file.md | 1 + docs/terms/concept.md | 1 + docs/terms/corpus.md | 1 + docs/terms/credential-catalogue.md | 1 + docs/terms/credential-type.md | 1 + docs/terms/credential.md | 1 + docs/terms/data-collector-policy.md | 1 + docs/terms/data-collector.md | 1 + docs/terms/data-discloser-policy.md | 1 + docs/terms/data-discloser.md | 1 + docs/terms/definition.md | 1 + docs/terms/dependent.md | 1 + docs/terms/dictionary-file.md | 1 + docs/terms/dictionary.md | 1 + docs/terms/digital-actor.md | 1 + docs/terms/digital-agent.md | 1 + docs/terms/digital-colleague.md | 1 + docs/terms/digital-communication-channel.md | 1 + docs/terms/digital-policy.md | 1 + docs/terms/documentation-interop.md | 1 + docs/terms/eSSIFLab-scope.md | 1 + docs/terms/employee.md | 1 + docs/terms/employer.md | 1 + docs/terms/entity.md | 1 + docs/terms/essif-glue.md | 1 + docs/terms/glossary-file.md | 1 + docs/terms/glossary.md | 1 + docs/terms/governance.md | 1 + docs/terms/governor.md | 1 + docs/terms/guardian.md | 1 + docs/terms/guardianship-type.md | 1 + docs/terms/guardianship.md | 1 + docs/terms/holder-policy.md | 1 + docs/terms/holder.md | 1 + docs/terms/identifier.md | 1 + docs/terms/issuer-policy.md | 1 + docs/terms/issuer.md | 1 + docs/terms/jurisdiction-governor.md | 1 + docs/terms/jurisdiction.md | 1 + docs/terms/knowledge-governor.md | 1 + docs/terms/knowledge.md | 1 + docs/ter