diff --git a/docs/notations-and-conventions.md b/docs/notations-and-conventions.md index 33f3ded052791d4e642a4e84e5bafa2543007cdf..7be3b956191096735113c82dd3790cda0a598b38 100644 --- a/docs/notations-and-conventions.md +++ b/docs/notations-and-conventions.md @@ -20,12 +20,12 @@ We are working towards deprecating this convention, as we now have better ways o %%Pattern|pattern%% diagrams will be visualized in this document using a UML-like notation, as follows: - A **rectangle** represents a (named) concept that is explicitly defined. Concepts serve as entity-classes. Their (operational) extensions, i.e. the respective sets of (runtime) instances, are disjunct. -- A **rectangle that is coloured red(dish)** represents a (named) concept that is commonly used ‘in the wild’ (and hence needs not be defined here), relates to one or more concepts that are explicitly defined 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. -- 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 ` ` is a phrase that suggests the intension(al definition) of that relation. -- A **solid line with an open arrowhead** represents an ‘ISA’ relation, which can be read as ` ISA `. It means that SRC is a specialization of TGT (which in turn is a generalization of SRC). It means that SRC must satisfy all constraints that TGT must satisfy, and also that it has all attributes (including properties) that TGT has. +- A **rectangle that is coloured red(dish)** represents a (named) concept that is commonly used 'in the wild' (and hence needs not be defined here), relates to one or more concepts that are explicitly defined 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. +- 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 ` ` is a phrase that suggests the intension(al definition) of that relation. +- A **solid line with an open arrowhead** represents an 'ISA' relation, which can be read as ` ISA `. It means that SRC is a specialization of TGT (which in turn is a generalization of SRC). It means that SRC must satisfy all constraints that TGT must satisfy, and also that it has all attributes (including properties) that TGT has. - A **solid line with a solid diamand** at one end is a composition; the element at the 'non-diamond-end' of the line is 'part of' (the 'part') the element at the 'diamond-end' of the line (the 'whole'); if the 'whole' ceases to exist, then its 'parts' also cease to exist. - A **solid line with a hollow diamand** at one end is an aggregation; the element at the 'non-diamond-end' of the line is 'part of' (the 'part') the element at the 'diamond-end' of the line (the 'whole'); if the 'whole' ceases to exist, then its 'parts' usually do not cease to exist, but 'live on'. - 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** with a closed arrow (solid triangle) signifies that its intension is created by combination the intensions of other relations (it is a ‘shorthand’ for a path of other relations). +- A **dashed line** with a closed arrow (solid triangle) signifies that its intension is created by combination the intensions of other relations (it is a 'shorthand' for a path of other relations). - A **dashed line** with a pointed arrow (`>`) represents a dependency, where the SRC concept somehow depends on the TGT concept. The kind of dependency is specified by `<>`, where `text` specifies the kind of dependency. Example: `<>` says that SRC is an instance (or: instantiates) TGT. - **Multiplicities** (or: **cardinalities**) use the [n..m] notation. When a multiplicity is omitted, [0..n] is intended. diff --git a/docs/project.md b/docs/project.md index 156779efd1635f4b9b4308a740f30216a7f46456..d869d1fd8b66442f110281b64c331bb000b77d68 100644 --- a/docs/project.md +++ b/docs/project.md @@ -26,4 +26,4 @@ For interop purposes, we also maintain a page related to [SSI standards](ssi-sta ## 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 +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/docs/ssi-standards.md b/docs/ssi-standards.md index ab284048adad47b08331102d3db0d13e9bb6823d..3e36c7e56ee3abc8fd69ee5ffc677df3e801c168 100644 --- a/docs/ssi-standards.md +++ b/docs/ssi-standards.md @@ -3,6 +3,10 @@ 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 diff --git a/docs/terminology-maintenance-script.rieks b/docs/terminology-maintenance-script.rieks index fc15465fe745bec38104cab990731c794760b8a0..e548121a64a3aa447f61f1825b1e6d2991870916 100644 --- a/docs/terminology-maintenance-script.rieks +++ b/docs/terminology-maintenance-script.rieks @@ -30,7 +30,7 @@ dutyrighttype = "%{dutyright}-types?" // `filter "*.txt"` - any .txt file in the root folder // `filter "**/*.txt"` - any .txt file -filter "docs/functional-architecture.md" +filter "docs/terms/*.md" // PREPROCESSING: convert single-%-notations into %%-notations. diff --git a/docs/vision-and-purpose.md b/docs/vision-and-purpose.md index f97a98c6cc9e3f2038c0c04b3b11bdcf90b5b362..8ad7bca740b8806f445aea91122c19a57f267fdf 100644 --- a/docs/vision-and-purpose.md +++ b/docs/vision-and-purpose.md @@ -8,7 +8,7 @@ sidebar_label: 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 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, scalable and business/information agnostic technologies, that form an infrastructure that every application for every %%party|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|party%% 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|business-transaction%% and which %%parties|party%% 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. @@ -20,9 +20,9 @@ The situation we would like to see is one in which we have SSI-enabled, interope ## Context -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]. +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 electronically support %%business transactions|business-transaction%%, i.e. the exchange of goods, services, funds, or data between %%parties|party%%, which we call ‘participants’ to the transaction[^2]. +In the context of these rights and freedoms, we seek to electronically support %%business transactions|business-transaction%%, i.e. the exchange of goods, services, funds, or data between %%parties|party%%, which we call 'participants' to the transaction[^2]. Supporting such transactions requires each participant to have one or more %%electronic (digital) agents|digital-agent%%, i.e. equipment (e.g. an app on a mobile phone, a webserver, a browser, …) that provides such support and that (provably) acts on behalf of that participant.