Commit c4bdd4fc authored by Oskar van Deventer's avatar Oskar van Deventer
Browse files

Update README.md

parent 2735f50a
# ESSIF-Lab
\ No newline at end of file
# eSSIF-Lab Framework
## Introduction
This page provides guidance to applicants for eSSIF-Lab open calls about what types of developments are planned and requested.
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. eSSIF-Lab maintains the [eSSIF-Lab Vision and Functional Architecture](https://docs.google.com/document/d/17sSGizpisvd6P2FDu95f1yVz0-ofOZJOt4RzZgyd8wQ) document in which the (current, draft) vision and functional architecture are described.
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 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.
This means that all eSSIF-Lab open calls are directly related to the eSSIF-Lab architecture, see Figure 1 below. This architecture will remain work in progress during the whole eSSIF-Lab project in 2020-2022.
![eSSIF-Lab Architecture](C:\Users\deventermov\TNO\H2020 eSSIF-Lab - Team\Communication\20200306 Technical Annex for Gitlab page\images\eSSIF-Lab Architecture.png)
*Figure 1: eSSIF-Lab architecture*
Figure 1 is explained in more detail in the (living) document “[eSSIF-Lab Vision and Functional Architecture](https://docs.google.com/document/d/17sSGizpisvd6P2FDu95f1yVz0-ofOZJOt4RzZgyd8wQ/edit?usp=sharing)”. It sketches the relationship between the Infrastructure Open Call (which focuses on the SSI Roles Layer -green bar-) and the Business Open Calls (which focuses on the Business Transaction Layers (red bar – everything above the yellow ESSIF ‘Glue’-).
## Relationships between the opens call
Figure 2 sketches relationships between the open calls.
![Relationship among eSSIF-Lab open calls](C:\Users\deventermov\TNO\H2020 eSSIF-Lab - Team\Communication\20200306 Technical Annex for Gitlab page\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.
## First business-oriented call: examples
**Please surprise us!**
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).
- **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.
## Infrastructure-oriented call: examples
**Please surprise us!**
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).
- **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?
---
\ No newline at end of file
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment