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.
An additional integration we plan to offer as a template is the integration with a KYC provider, enabling a user to receive a KYC credential. To make this template as straightforward as possible, we'll select at least one KYC provider and design a custom trigger, action, and output matching their specific API surface.
In a later stage (not part of this proposal, to maintain a manageable scope), we could add further integrations, such as the ability to 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 current PRISM agent (2.1) and target the following open standards as they relate to a possible trigger or output in their current (July ‘23) 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
How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?
Our proposal tries to fill a critical gap in the Cardano ecosystem - the lack of an easy-to-use, adaptable, and open-source solution for managing digital identity workflows. Current solutions demand either deep expertise in the SSI sphere or involve costly proprietary systems that create vendor lock-in situations. Our issuing and credential workflow platform significantly mitigates these challenges by offering an interface that simplifies the process of setting up workflows for issuing and validating credentials. With this, projects can integrate SSI more effectively, focusing more on their core value proposition and less on grappling with the intricacies of SSI implementation.
By fostering a higher adoption of SSI within Cardano projects, our proposed solution enhances trust-based interactions across the ecosystem. SSI empowers users with control over their digital identities, improving security and privacy in their interactions. This, in turn, would strengthen the overall Cardano network, propelling the ecosystem forward in a robust, privacy-focused manner.
How do you intend to measure the success of your project?
The success of this project is aligned with the goals of Atala PRISM inside the Cardano ecosystem: a higher adoption and rate of projects integrating PRISM. To track the overall usage of PRISM we already developed software in the past: <https://analytics.blocktrust.dev>, this will help to determine the overall growth of the ecosystem.
Tracking and measuring the usage directly related to this platform is not feasible when the code is run independently by everyone. However, since we are not only providing the open-source code, but also offering a hosted variant, we can track the number of registered tenants as well as platform interactions (for example, how often a certain trigger was executed).
Additionally we plan to gather user feedback through a dedicated Discord channel (<https://discord.gg/6UXrUY2HUk>)
Please describe your plans to share the outputs and results of your project?
Blocktrust will keep the Cardano community informed about our progress by providing updates as we achieve each of our milestones, typically on a monthly basis. We'll be communicating through Catalyst progress reports, our dedicated Discord channel, and videos showcasing the latest features of our product.
Occasionally, we may interact with the community in real-time during the Catalyst After Town Hall sessions. These sessions will give us an opportunity to show our progress and collect immediate feedback. We already have done this several times in the past.
When it comes to product releases, updates can of course found on our Github (<https://github.com/bsandmann>) as well on a dedicated website for this proposal (<https://blocktrust.dev/workflow>) and out blog.