Merge branch 'rj-updates' into 'master'

updates of README, creation of subdirs, and started with drafting subdir-READMEs

See merge request !14

README.md

-# eSSIF-Lab Framework
+# eSSIF-Lab Project
 
-## Introduction
+This repository contains files that subgrantees/beneficiaries of the eSSIF-Lab open calls:
+- need, in order to be maximally aware of what other beneficiaries are doing, enabling their solutions to become optimally interoperable.
+- create, in order to satisfy the aforementioned needs of the other beneficiaries, and
+- create, in order to satisfy eSSIF-Lab overall project requirements, as (will be) stated in this document.
 
-This page provides guidance to applicants for eSSIF-Lab open calls about what types of developments are planned and requested.
+Also, this repository contains some guidance for applicants to any of the eSSIF-Lab open calls. 
+
+## README for Applicants
 
 Applicants are expected to be already active in the SSI field and to be familiar with commonly used terminology, such as “verifiable credential”, “wallet”, “issuer”, “holder” and “verifier”. Applicants are also expected to direct their work so as to realize the various benefits, and counter the risks associated with SSI, as summarized e.g. in the blog “[Self-Sovereign Identity - the good, the bad and the ugly](https://blockchain.tno.nl/blog/self-sovereign-identity-the-good-the-bad-and-the-ugly/)”.
 
 Subgrantees are expected to work in an ecosystem with other subgrantees for the purpose of ensuring interoperability at the various levels (technology, processes, business/policy), scalability of solutions, and ensuring that solutions are fit-for-purpose (i.e. can actually be used in practice). This implies that subgrantees collaborate in the project to maintain a shared vision, functional architecture and specifications of functionalities, API’s, ways of working etc. 
 
-The eSSIF-Lab consortium has drafted 
-
-- an initial [Vision and Purpose document](essif-lab-vision-and-purpose.md), which states at a high level what it is eSSIF-Lab aims to contribute in terms of impact that it wants to see realized.
-- an initial [Functional Architecture document](essif-lab-functional-architecture.md), which identifies several functional components that sit on top of different kinds of SSI-technologies in order to realize the vision, purpose and impact. 
-
-Applications for the “Infrastructure-oriented Call” are expected to submit proposals for work in the SSI-Roles layer, and/or work in the SSI Protocols and Crypto layer if that is necessary for establishing/improving interoperability, scalability or features that provide generic business benefits.
-
-Applications for the “First Business-oriented Call” are expected to submit proposals for work that extends the eSSIF-Lab basic infrastructure/architecture with business solutions that makes it easy for organizations to deploy and/or use SSI, reduce business risks, facilitate alignment of business information, etc.
-
-## eSSIF-Lab Framework
-
-The eSSIF-Lab framework is an SSI-domain-specific [software framework](https://en.wikipedia.org/wiki/Software_framework) that is 
-
-- built upon the extensions provided through the infrastructure-oriented call
-- dedicated to the development of generic services that use SSI in 1<sup>st</sup> business-oriented call
-- dedicated to the development of SSI-based applications in 2<sup>nd</sup> business-oriented call
-
-The eSSIF-Lab framework has an architecture which is further developed during the project. We expect the subgrantees to form a business ecosystem together under eSSIF-Lab coordination. The emphasis is on interoperability, i.e. development and implementation of standardized protocols, data models and API’s, including contributing to standardization and performing of interoperability tests. 
-
-This means that all eSSIF-Lab open calls are directly related to the [eSSIF-Lab functional architecture](essif-lab-functional-architecture.md), for which we have an initial version as a 'stick in the ground', and that we expect to be further developed and refined as subgrantees cooperate during the whole eSSIF-Lab project in 2020-2022.
-
-## Relationships between the opens call
-
-Figure 2 sketches relationships between the open calls.
-
-![Relationship among eSSIF-Lab open calls](/images/Relationship-among-eSSIF-Lab-open-calls.png)
-
-
-Figure 2: Relationships between the eSSIF-Lab open calls
-
-The key requirement to the eSSIF-Lab framework is that it is consistent and integrated, and this is why the eSSIF-Lab framework has an architecture (work in progress), and why we expect the applicants to form a business ecosystem together under eSSIF-Lab supervision. 
-
-The emphasis is on interoperability, i.e. development and implementation of standardized protocols, data models and API’s, including contributing to standardization and performing of interoperability tests.
+The eSSIF-Lab consortium has drafted:
 
-## First business-oriented call: examples
+- an initial [Vision and Purpose document](https://essif-lab.pages.grnet.gr/framework/docs/vision-and-purpose), which states at a high level what it is eSSIF-Lab aims to contribute in terms of impact that it wants to see realized.
+- an initial [Functional Architecture document](https://essif-lab.pages.grnet.gr/framework/docs/functional-architecture/), which identifies several functional components that sit on top of different kinds of SSI-technologies in order to realize the vision, purpose and impact. This document will be updated as necessary throughout the project. 
 
-**Please surprise us!**
+Proposals may be submitted to any of [three calls](https://essif-lab.eu/open-calls/):
 
-The following are examples of topics that would be suitable for a potential proposal in the first business-oriented call. Applicants should use these for inspiration, and not take them normatively. Useful ideas and concepts for SSI that are not listed here are also very welcome. In case of doubt, contact us at [info@essif-lab.eu](mailto:info@essif-lab.eu).
+1. The [Infrastructure-oriented Call](https://essif-lab-infrastructure-oriented.fundingbox.com/), which is **currently (still) open**, requests proposals for work in the [SSI-Roles layer](https://essif-lab.pages.grnet.gr/framework/docs/functional-architecture/#3--essif-lab-infrastructure-functional-components), and/or work in the SSI Protocols and Crypto layer if that is necessary for establishing/improving interoperability, scalability or features that provide generic business benefits. There is a [guide for applicants](https://s3.amazonaws.com/fundingbox-sites/gear%2F1587280828747-eSSIF-Lab_GuideforApplicants_IOC_Updatedv.3.pdf), and a [FAQ](https://s3.amazonaws.com/fundingbox-sites/gear%2F1587280828747-eSSIF-Lab_GuideforApplicants_IOC_Updatedv.3.pdf) for this call.
 
-- **Credential catalogue**. This is a capability that allows issuers to advertise their credentials and associated metadata, enabling verifiers to decide whether or not to use such a credential for filling in forms associated to a specific business transaction. Credential catalogues are instrumental in making SSI work: they are the ‘shop windows’ that allow issuers to advertise their credentials such that they will be ubiquitously used. 
-- **Yellow pages service**. This is a capability that enables verifiers to search for organizations that issue credentials that they may consider to use for filling in forms for specific business transactions. This service can be seen as a search engine that knows where to find credential catalogues of many organizations, and knows what kinds of credentials are similar, and which are not.
-- **Web shop SSI business plug-ins**. Technologies like WordPress make it easy for prosumers to open a web shop. There exists a simple solution to integrate inventory control and payments with the web shop. Can you provide a solution that enables an equally simple integration of SSI credential checks (basically building a plugin that has TVE and TRD functionality)? 
-- **Usability solution**. Usability is key to adoption of new technology. Providing a consistent user experience between applications is an important part of this. An example is the “folder” metaphor for digital file systems. Users understand that files go into folders, and that folders can go into other folders. What are usable metaphors and elements to rectify SSI concepts like “verifiable credential”, “credential request”, “verified signature” and more? And how could a good user-interface solution be commercialized? Do not just think about ‘users’ (individuals) that have an SSI wallet app, but also think about the kinds of usability that people need as they design forms that need to be filled in, or the various business- and/or SSI-component related policies. 
-- **Barrier to entry**. Parties have reasons for bureaucratic walls, e.g. keeping jobs for manual checking or postal administration processes. What could be rationales for organizations to lower this barrier? And what business models could provide the right incentives to the bureaucrats? 
-- **Meta-wallet**. What solutions could be conceived for users to seamlessly use multiple SSI wallets/ apps on multiple devices and/or in the cloud? 
-- **GDPR-violator check**. Solution to forward signed over-asking credential queries to authority. Or a service that allows for issuing a credential that contains ALL information an organization has about a person, have it revoked/replaced when the information changes, supports users that seek to exercise GDRP rights such as the right to rectification, right to be forgotten etc. How can legal and tech support to ultimate collect fines from violating verifiers be turned into a business? 
-- **Application attestation services**. In case of high-value high-risk transactions, (verifier/holder/issuer) agents may want to know that they are dealing with a peer agent whose functionality, integrity, and agency can be trusted to a sufficiently high degree. It is thinkable that such security-properties can be checked by services that are run by parties that specialize in such matters. For example, functionality may be attested to by credentials from an official accreditation agency. Integrity may be attested to by online services that can remotely check the status of apps. Agency may be attested to by ‘multi-factor authentication providers’. All such services may result in credentials that verifiers may ask for as they need the associated assurances.
+2. The [First Business-oriented Call](https://essif-lab-first-business-oriented.fundingbox.com/), for which the **application deadline has passed**, called for proposals that extend the eSSIF-Lab basic infrastructure/architecture with business solutions that makes it easy for organizations to deploy and/or use SSI, reduce business risks, facilitate alignment of business information, etc.
 
-## Infrastructure-oriented call: examples
+3. The [Second Business-oriented call](https://essif-lab-second-business-oriented.fundingbox.com/), which is **expected to launch in late spring 2021**, will be open to SMEs and startups developing commercial SSI-based applications and services with focus in the verticals of HealthTech, eGovernment, Education or competing in the generic track of Open Disruptive Innovation.
 
-**Please surprise us!**
+## README for Beneficiaries.
 
-The following are examples of potential proposals. Applicants should use these for inspiration, and not take them normatively. Useful ideas and concepts for SSI that are not listed here are also very welcome. In case of doubt, contact us at [info@essif-lab.eu](mailto:info@essif-lab.eu).
+Beneficiaries are the parties that have signed a sub-grant agreement for a project under one of the calls. For each of the calls, we have a README in the directory that contains the material for its beneficiaries, as follows:
 
-- **SSI wallet**. eSSIF-Lab needs multiple wallet codebases to validate interoperability and to integrate with. A wallet must provide safeguards against inadvertent adding, reading, modifying or deleting contents; be available when needed; and provide only access to applications that are allowed to. What codebase could you offer? 
-- **SSI smartphone app**. eSSIF-Lab needs multiple SSI apps that act on behalf of its owner; and that provides a user interface to register with the app, to get (re)authenticated, to specify preferences, to work with a browser for obtaining credentials, issuing credentials, filling in forms and requesting credentials from web-servers (to reduce the risk of dealing with fraudulent servers/fishing sites), to manage credentials it has obtained or issued, and to check the logs. What codebase could you offer? 
-- **SSI browser add-on**. How could the SSI wallet/app functionality be made available as browser plug-in? What codebase could you offer? 
-- **Web server proxy**. eSSIF-Lab may need a web solution, where the wallet resides in the cloud. What provisions can be made to make such solutions sufficiently secure? What codebase could you offer? 
-- **Credential-query solution**. How could a verifier agent semantically specify what combination of credentials it requires? What solution can you offer to further automate the credential query-response process at both the verifier and holder side? 
-- **Automated issuer referral**. How could an SSI application be automatically referred to appropriate issuers, when a requested credential happens to be missing in the wallet? 
-- **Revocation service**. Many credentials (e.g. driver’s license) need the possibility of revocation. While many solutions exist (e.g. revocation lists, online status protocols, accumulators), each has its merits and drawbacks that may make it unsuitable for certain issuers to use. For example, how could a verifier at some later time check the revocation status of a credential in absence of the holder, while respecting GDPR? What solutions do you envision? 
-- **Cryptographically enforceable issuer policies**. As stated by the Dutch ministry of internal affairs, a government should protect its citizens from data-guzzlers, e.g. foreign customs or tech giants that may coerce Dutch citizens to provide all credentials from their wallet. So, what solution can you envision that enables an issuer to cryptographically enforce a policy to prevent such abuse? 
-- **Calamity override**. In case of a calamity, what solution could you offer to give a health worker emergency access to health-related credentials, while respecting the self-sovereignty of the patient?
+- [Business Open Call #1 README](./business-open-call-1/README.md)
+- [Infrastructure Call README](./infrastructure-call/README.md)
+- [Business Open Call #2 README](./business-open-call-2/README.md)
 
 ---
\ No newline at end of file

business-open-call-1/README.md

+## README for eSSIF-Lab Business Open Call #1 
+
+The purpose for Business Open Call #1 (BOC#1) is to extend the eSSIF-Lab basic infrastructure/architecture with business solutions that makes it easy for organizations to deploy and/or use SSI, reduce business risks, facilitate alignment of business information, etc.
+
+---
+
+**TO BE FURTHER ELABORATED**
+
+---
\ No newline at end of file

business-open-call-2/README.md

+## README for eSSIF-Lab Business Open Call #2 
+
+The purpose for Business Open Call #1 (BOC#1) is to develop commercial SSI-based applications and services with focus in the verticals of HealthTech, eGovernment, Education or competing in the generic track of Open Disruptive Innovation.
+
+This call is **expected to launch in late spring 2021**, and will be open to (European) SMEs and startups 
+
+---
+
+**TO BE FURTHER ELABORATED**
+
+---
\ No newline at end of file

essif-lab-vision-and-purpose.md

-<p align="center"><img src="images/EU-flag.jpg" height="80";" /> <img src="images/eSSIF-Lab logo.png" height="80";" /></p>
-
-eSSIF-Lab is funded by the European Commission, as part of the Horizon 2020 Research and Innovation Programme, under Grant Agreement Nº 871932 and it’s framed under[ ](http://ngi.eu/)[*Next Generation Internet Initiative*](http://ngi.eu/).
-
-# eSSIF-Lab Vision and Purpose
-
-<p align="center">Author: Rieks Joosten (TNO)</p>
-
-It is the eSSIF-Lab vision that Self-sovereign Identity (SSI) will *empower European citizens (as well as other individuals, of course)* by providing new means to manage privacy, eliminating logins, and making electronic transactions much faster and much safer, both via the Internet and in real, 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, often have specific applications in mind for which they provide a solution (vertical ‘stovepipes’), many have 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 **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<sup>[1]</sup>.
-
-Within (the limitations 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<sup>[2]</sup>.
-
-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.
-
-## 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](images/eSSIF-Lab%20-%20vision%20context.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 *RA*, i.e. an SSI-aware app on his 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 *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) 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<sup>[3]</sup>. *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.

infrastructure-call/README.md

+## README for eSSIF-Lab Infrastructure-Oriented Call
+
+The Infrastructure Oriented call has projects in the [SSI-Roles layer](https://essif-lab.pages.grnet.gr/framework/docs/functional-architecture/#3--essif-lab-infrastructure-functional-components), and/or work in the SSI Protocols and Crypto layer if that is necessary for establishing/improving interoperability, scalability or features that provide generic business benefits. 
+
+More details can be found in the [eSSIF-Lab framework](https://essif-lab.pages.grnet.gr/framework/), [guide for applicants](https://s3.amazonaws.com/fundingbox-sites/gear%2F1587280828747-eSSIF-Lab_GuideforApplicants_IOC_Updatedv.3.pdf), and the [FAQ](https://s3.amazonaws.com/fundingbox-sites/gear%2F1587280828747-eSSIF-Lab_GuideforApplicants_IOC_Updatedv.3.pdf) for this call.
+
+---
+
+**TO BE FURTHER ELABORATED**
+
+---
\ No newline at end of file