Please describe your proposed solution.
The problem
The blocktrust team has been working on PRISM-related projects, including wallets, mediators, and analytics tools, for over a year and a half (see https://blocktrust.dev). Although PRISM has significantly evolved, its adoption isn't as widespread as we all had hoped. Our experience suggests that one major obstacle is the complexity, concepts, and language surrounding SSI, which is quite different from the general crypto space. Grasping the capabilities of an SDK and writing software to integrate it into one's projects, such as issuing a schema-compliant credential, onboarding user DIDs, or offering a way for a user to provide a credential to a website, is not trivial. Costly proprietary solutions that aim to lock you in without the ability to retrieve your credentials aren't viable options for the community either.
Identifying the gap
When looking at the challenges many projects face with integrating digital identity into their endeavors, it's apparent that these problems are often similar and can be grouped into two main categories:
- <u>Projects that want to issue credentials</u>, for instance, a project where a user should receive a credential for completing a course or where a user should receive a credential for being part of a selected group such as a DAO, or for paying a subscription fee.
- <u>Projects that aim to verify a user's identity</u>, either through a KYC-credential or a simple membership or social credential.
The Atala PRISM SDK (or the agent) provides methods for both these groups (which obviously often overlap), but it lacks the intermediate steps. It misses the ability to model all this in a workflow: if this, then that. Here are a few examples:
- If you fill out a form on a specific page, a previously defined credential is automatically sent to your provided wallet address.
- If you scan this QR code, you are registered and redirected to another page.
- If you send your KYC-credential to this address, it is automatically verified, and an API request is executed to a protected endpoint.
- If you use the sign-in button on my website, a JSON Web Token is automatically issued to you.
Of course, these features can be built out by each project, integrated with the PRISM SDK/agent in their respective codebase. However, it isn't straightforward, and in many cases, these are <u>common problems</u> which don't have be solved over and over again. Each project should focus on their core value proposition and not deal with the code details of SSI which they want to use DIDs and VC for these common use-cases. Think of this proposal as Zapier of IFTTT for SSI.
Bridging the gap
We propose building an open-source toolkit with an easy-to-use UI for enabling these workflows. One should be able to set up these default workflows and modify them to fit the requirements for issuing and validating credentials. We believe this can be achieved without the user writing any code related to SSI. The solution will be completely open-source, based on open standards (refer to the standards section below), and will include a version of the service hosted by us. This way, anyone can utilize it for their project integration. The primary goal of this proposal is to get the SSI adoption finally started.
Technical details
The solution will be written in C#, compatible with .NET, and can be easily hosted on Windows, Linux, or macOS. It will be shipped as a Docker image, containing both the application and a PostgreSQL database. This allows everyone to run it in their preferred hosting environment, either locally or in the cloud.
The solution will be tenant-based and can be easily set up for a single tenant or multiple ones. Each tenant can establish multiple workflows (based on the "If this, then that" principle) which can be integrated into various projects. The following features are being planned:
<u>Triggers</u> are operations that the application can listen to. Once configured, they can be activated to receive inputs. The inputs could include:
- an endpoint to receive a previously defined POST-request, which may submit one or more of the following fields:
- W3C JWT Credential data
- Peer DID Address
- PRISM DID Address
- Key/Value Pair of Claims
- API-Key
- an auto-generated page containing a form with the same fields mentioned above, along with an arbitrary HTML formatted message.
- an endpoint to receive a previously defined GET request (a redirect) with multiple predetermined query-parameters.
- a DIDComm endpoint for receiving:
- Basic messages, Trust Pings and Problem report messages
- PRISM connect protocol request
- Propose Credential, Offer Credential or Request Credential messages (WACI)
- Propose Presentation or Receive Presentation messages (WACI)
<u>Actions</u> are optional operations that can extract, validate, or transform all or parts of the inputs into an output based on prior configuration. These actions can include:
- resolving a DID
- verifying a credential to ensure it:
- was issued by a predefined DID (or list thereof)
- follows a predefined schema
- contains certain key/value pairs
- checking input values to contain a specific value (e.g., authorization key or DID)
<u>Outputs </u>are executed depending on the action. These could include:
- calling a predefined endpoint on an arbitrary server
- issuing / revoking a credential to a specific DID or even multiples at once using DIDComm
- sending out arbitrary DIDComm messages (e.g., PRISM connect request)
- creating, updating, deactivating, or publishing a DID
- generating a QR code for an Out-of-Band connection
- sending out invites for onboarding
These building blocks of triggers, actions, and outputs can be arranged in an arbitrary manner. Some projects might only need a mechanism for sign-in with a DID, while other projects may require multiple interconnected workflows, from onboarding to credential issuing and various levels of verification. To drive adoption, we'll offer templates for the most common workflows.
In a later stage (not part of this proposal, to maintain a manageable scope), we could add further integrations, such as the ability to integrate with an KYC-provider, listen to operations on the blockchain like a specific metadata payload, a PRISM event (e.g., a new DID published), or a payment sent.
Open standards
To execute on this proposal we target the surface specification of the PRISM agent (2.5) and target the following open standards as they relate to a possible trigger or output in their current official specification:
DID PRISM, DID Peer, W3C VC Model 1.1, DIDComm v2, Mediator Coordinator protocol, WACI Issue credential protocol, WACI Present proof protocol, Basic Message protocol, Problem Report protocol, Trust Ping protocol, Out of Band (OOB), PRISM Connect protocol