Reflecting on Two Years of Analytics Data
blocktrust analytics platform
Two years ago, I set out to provide statistical insights into PRISM—tracking the number of DIDs created, credentials issued, and ultimately exploring the big question of adoption. A lot has changed since then: the underlying technology, Atala's business strategy, platform developers, users, and the broader outlook.
Let's rewind to where we were two years ago. Atala PRISM v1 was in the hands of many developers, primarily through the PRISM Pioneer program. While v1 had some rough edges, it was a working technology. The PRISM Pioneer cohorts developed promising use cases, pushing the limits of what was possible at the time. We saw the first deployment of DIDs on the mainnet for Ethiopia's Ministry of Education, along with hints of other projects and future growth. The PRISM community (later known as Atala Astros) was growing, with regular town halls and updated educational materials. During this period, the analytics platform was envisioned, funded, and quickly built to provide more details about what was happening on-chain. At that time, you could see every DID and credential being created live on-chain. With the analytics tool, you could monitor activity in real time and make educated guesses about adoption, growth, and development on the testnet, as well as business interactions on the mainnet. Although there was some adoption, it wasn't as much as we had hoped. The pool of people interested in decentralized identity solutions (SSI) and Cardano wasn't limitless. Eventually, the influx of new community members slowed, and interest waned.
So, what went wrong? Different people may have different opinions, but as a builder, I saw three main issues:
1. PRISM v1 provided the community with an SDK (Kotlin) to create DIDs and to issue, revoke, and verify credentials. What initially seemed promising quickly proved insufficient. The Atala team didn't provide a wallet, and the question of how to transfer credentials from one party to another was not addressed. Additionally, a critical component—the PRISM node responsible for reading and writing operations to the blockchain—was closed-source and unavailable. The analytics solution I provided partially addressed the issue by giving developers some visibility into on-chain activity.
2. The unavailability of the PRISM node also raised concerns about the business model. How much would it cost to create a DID or issue a credential using the Atala stack? These questions remained unanswered throughout v1's existence (and even to some extent for v2). This uncertainty hindered any serious business planning. A concept where DIDs were nearly free could suddenly be upended by a pricing strategy that made them costly, such as $10 per DID or credential, as seen in other ecosystems. The lack of clarity and commitment to a long-term strategy was a dealbreaker for many.
3. Figuring out a viable business model for SSI is challenging. Many have failed, and almost everyone involved in this sector has pivoted—often multiple times. This applies to ecosystem providers, developers of kits like Atala, and businesses building SSI products. If you don't have a strong business case or deep pockets, your SSI project is at risk of failure. Fortunately for those of us building on Atala, IOG had the resources and persistence to continue investing in and building out the platform.
PRISM v2 and Analytics Adjustments
Before moving on to what happened with PRISM v2, let's briefly summarize the analytics solution. The vision was to create two things: first, a statistical tool to monitor on-chain activity and provide developer tools; second, an analytics tool to uncover relationships between issuers and holders through credentials issued. Think of it as a graph where DIDs are nodes and credentials are edges, forming relationships between them. With PRISM v1, building this graph was possible to a certain extent. Combined with some statistical information, it gave a look at what was happening on the network—since it was all on-chain. This understandably raised privacy concerns, but in the early stages of the project, privacy wasn't much of a focus for either v1 developers or myself.
All that changed with PRISM v2. It marked a complete departure from what had been built before. Instead of providing an SDK, the new idea was to offer a hosted service with API endpoints for creating DIDs, issuing credentials, and verifying them. PRISM v2 also introduced the concept of connections (using DIDComm v2), enabling a secure, private communication channel between two parties, which could be used to exchange credentials. Later, the Atala team also provided lightweight SDKs for building applications that interact with these hosted services (agents). PRISM v2 was made available to selected beta testers in early 2023, with a full release much later. Since it was a completely new product (written in Scala, with TypeScript, Python, and Swift SDKs), it was delivered in stages, with capabilities gradually expanding.
The most important change, however, wasn't in the code—it was aligning with the broader SSI community. While v1 was a Cardano-centric solution inspired by Bitcoin's Sidetree implementations, v2 focused on interoperability. The challenge when envisioning v2 was determining the interoperability target. Should we align with DIDComm v1 or v2? What about AnonCreds? OpenID4VC? With limited resources, the team had to make strategic decisions on which technologies to support first. With hindsight, it's easy to say what should have been done, but at the time, predicting the direction of the industry was difficult. Despite this, good technical leadership allowed for solid early decisions, though there is still some catching up to do in supporting a wider set of standards.
Evolving the Analytics Platform
The shift to PRISM v2 also meant rethinking the analytics platform. While I managed to adapt the statistical tool for v2, the original vision for the graph view fell apart. It would have been possible to fulfill the initial proposal for v1's sake, but that approach would have had no relevance to the broader community. Instead, I focused on ensuring support for v1 and partial support for v2 on the statistics pages while letting things settle. In the meantime, we at Blocktrust explored a range of concepts, from tooling and infrastructure to building a custom wallet for v2. We participated in conferences, working groups, and found ourselves deeply immersed in the world of SSI. Our perspective expanded as we saw how the SSI space was growing and evolving.
In the Cardano community, PRISM is often perceived as a unique identity solution developed by IOG, but that's far from the current reality. Today, the Atala team is just one of many companies implementing existing standards—most of which have no specific connection to Cardano. The overlap between Cardano and SSI is minimal: technically, it’s only that issuer DIDs are anchored on the Cardano blockchain using a metadata transaction. Although the technical details are more complex, the overlap is not as significant as some assume. Furthermore, SSI's current trend is to move away from blockchains altogether. The Atala team has considered supporting not only Cardano-based DIDs but also other Verifiable Data Registries (VDRs).
Finding a New Vision
The changes around v2 and the constant learning process led to the project taking longer than expected. I needed a new vision for the tool that would carry it beyond the original proposal. Otherwise, as with many other proposals, I could have just completed the requirements and moved on. I found that new vision in late 2023 and began a complete redesign of every component related to the graph view. This meant writing new software libraries to cover every aspect of W3C credentials, DIDs, trust registries, and more. Since I was working in .NET, I also had to overcome the challenge of implementing standards that were barely represented in the .NET ecosystem. In April 2024, I had a working proof of concept and was able to present it at the Internet Identity Workshop in Mountain View.
The following months were spent refining ideas, stabilizing the application, and adding new features. Now, the platform has reached a point where it's ready to close out the Catalyst proposal. That doesn't mean it's bug-free, production-ready, or perfect, but it fulfills the proposal requirements and serves as a valuable tool for working with PRISM data. Development will continue, especially on the graph view, even without Catalyst funding. While this kind of application is still very early for many SSI use cases, I strongly believe that its value will grow over the next few years. Although PRISM isn’t at the center of SSI developments, the did method is up-to-date and highly capable, even in an increasingly crowded space.
While recent events around restructuring the Atala business unit may impact SSI adoption within Cardano, Hyperledger Identus (formerly Atala PRISM) is alive and well, with a great community continuing to build new ideas.
The Need for Identity Wallet Standardization in the Cardano Ecosystem
blocktrust identity wallet
In the expanding digital ecosystem, the traditional forms of identity verification have proven inadequate to secure personal and transactional data. Decentralized identifiers (DIDs) are the new frontier of digital identity, providing secure, verifiable, and personalized identification. At the heart of these are identity wallets, such as Blocktrust's Identity Wallet, which store and manage DIDs for individuals, ensuring seamless and secure interactions in the digital sphere.
One such sphere of interaction is between identity wallets and websites. This article delves into the interaction mechanisms and argues for the need for standardization. We will also explore the Cardano ecosystem's efforts towards this standardization and how the PRISM onboard and authenticate protocol is paving the way for a secure digital future.
Why is Standardization Necessary?
Identity wallets are becoming more prevalent, offering a unique advantage in providing smoother, streamlined user experiences without the need to switch contexts or devices. This wallet can pop up right on your screen where needed, offering use-cases such as registration, sign-in, exchange of credentials, and message exchange.
However, with the increasing adoption of identity wallets, we face a conundrum: the lack of a standard interaction model between identity wallets and websites. With each wallet and website defining their interaction protocol, we are at risk of creating a fragmented ecosystem, with potential vulnerabilities and inefficiencies. Standardization is essential to ensure interoperability, security, and usability, fostering a robust, secure, and frictionless digital ecosystem.
Standardization in the identity wallet space is significantly more challenging than in the traditional crypto-wallet realm, largely due to the variety of communication channels that need to be considered. While crypto wallets primarily rely on one or two methods of interaction, identity wallets leverage multiple channels for communication with websites. These channels include Out-of-Band (OOB) Messages, HTTP-Endpoints, background/service-worker-scripts for browser-extension-wallets, and DIDComm, each of which poses its unique requirements and challenges for standardization.
When executed correctly, standardization unlocks broader and more potent use-cases. One of the most significant benefits is the establishment of a secure communication channel between the user's wallet and the website. This channel can function independently of whether the user is actively visiting the website or not. This independence paves the way for 'two-message' scenarios where websites can send updates to the user's wallet, which can be responded to at a later time.
Beyond just notifications, this channel can also be used for trust delegation and proofs of authorization. Users can delegate trust to other entities, and those entities can demonstrate this authorization to a website, all secured and verified through the identity wallet. This functionality presents endless possibilities for a more interactive, dynamic, and secure digital ecosystem.
For developers looking to integrate their websites with identity wallets, it's crucial to understand the technical details of the interaction models. Especially DIDComm offers new ways of interation with websites, which we haven’t seen before in the Web2 or Web3 world.
The development of specific protocols such as PRISM's Onboard & Authenticate further enhances the standardization process. These protocols define the method for a website or service to register a DID, facilitating smoother and more secure interactions.
Diving Deeper into PRISM's Onboard and Authenticate
PRISM's Onboard and Authenticate is a feature designed to streamline the registration and authentication processes, utilizing Decentralized Identifiers (DIDs). During onboarding, a user's wallet generates a PeerDID, which is sent to the PRISM service and stored in its database, thus completing the onboarding process. Authentication is where PRISM's service shines. The user's wallet signs a challenge from the PRISM authenticate service using the DID used during onboarding. Once signed, the initial challenge, the PeerDID, and the signature are returned to the PRISM service, which verifies the signature. If it's valid, the user is considered signed in, and the confirmation is relayed back to the website. It therefore abstracts the process of nonce generation and signature verification into Http endpoints.
This approach takes care of the technicalities of SSI, DIDs, and signatures, allowing developers to focus on the user experience without worrying about the underlying complexities. Developers interested in leveraging this feature can refer to the documentation here: https://docs.atalaprism.io/enterprise-api/.
However, while PRISM's onboard and authenticate service it a practical service it is important to note there are still several considerations to take into account.
Authentication Persistence: Even as the PRISM service handles the cryptographic aspects of the interaction, website owners and developers still need to ensure a persistent way of identifying a signed-in user. This could be implemented via cookies or Bearer tokens, for example. It's worth noting that a PRISM agent, is not a token server issuing and handling the lifetime of JSON Web Tokens (JWTs). Therefore, developers need to have a strategy for managing user sessions across subsequent requests and page visits.
Initial Interaction Model: Another important consideration is the lack of a defined interaction model for the initial contact between the website and the wallet. For instance, in the case of a mobile wallet, the encoding of the QR Code intended for scanning is not explicitly specified. In the case of a browser-extension wallet, there is no clear guidance on how the wallet should be invoked via the injected script. This lack of standardization creates a hurdle for developers looking to ensure a seamless interaction.
Potential of DIDComm: It's also worth mentioning that while the PRISM Onboard and Authenticate service is a significant step in the right direction, it doesn't fully utilize the potential of a DIDComm connection. Even though the service essentially establishes a DIDComm connection through the sharing of PeerDIDs, it does not harness this connection for advanced use cases. It presents an area where further development and innovation could bring about even more powerful and versatile solutions.
For more information about the blocktrust identity wallet integration with PRISM onboard and authenticate head over to https://identitywallet.blocktrust.dev
On wallet security - part 2
blocktrust identity wallet
Reviewing our previous 2023-02-03 blog post on this topic, we noted the process of providing strong security for a browser extension wallet involves reducing the likelihood and impact of multiple potential attack vectors. That post listed three key risk mitigation areas: First, to assure the end user has resources to gain a sufficient understanding on the topic of digital identity, product features, and their responsibilities (e.g., to secure their secrets). Second, that the product and development practices mitigate platform risks. Finally, that great care must be applied in product design and implementation of cryptographic primitives, libraries, and storage.
The occasion of this second blog entry on wallet security corresponds with the completion of our Catalyst Fund 9 Milestone 3. During that milestone we assessed in more detail the most likely and significant security threats related to the user’s identity data, given an understanding of the latest design and implementation of the Blocktrust Identity Wallet. While this review was somewhat limited due to budget, the good news is that it didn’t reveal any tough security issues that will prevent us from releasing the identity wallet to the Chrome Web Store if we label it as a beta release for testing purposes. The review also helped shape our feature roadmap and prepare us for a more thorough security review prior to a full-fledged, generally available release. We’ve referenced some additional resources on security guidelines at the end of this blog post to help readers understand the scope of a thorough review.
We’ll next dive into detailed risk items, organized by risk area: User Education/Experience, Browser Extensions, and Identity/Crypto Browser Extensions. For each item, the risk score (high, medium, or informational) is indicated, as assessed based on our current code base and the likelihood of a potential exploit and impact if an exploit were it to occur. Several of these scores are not yet in an acceptable range for a general release, so that indicates some implicit action items that need to be addressed along with others to consider in the Recommendations section.
User Education/Experience Risks
- A new user might not understand what their responsibilities are for protecting their secrets (mnemonic seed phrase and password) and backups. High
- A new user might not understand features when used for the first time, such as DIDs, Contacts, and Credentials. Medium
- A user might not know when a new backup is recommended and why. High
- A user might not be able to readily discover resources to find more in-depth information about the product and SSI. Low
- A user might be subject to social engineering attacks. Users can be manipulated through social engineering techniques to reveal their wallet credentials or perform unintended actions, leading to unauthorized access. High
Brower Extension Risks
Permissions and Privacy. Browser extensions often require various permissions to access user data or interact with websites. It's important to test that the extension requests and handles permissions correctly, and that it respects user privacy by not collecting or transmitting sensitive information without explicit consent. Low
Compatibility with Different Browsers and Versions. Browser extensions need to be tested across different browsers (e.g., Chrome, Edge, Brave, and potentially Firefox, Safari) and their various versions. Each browser may have its own unique APIs, extension development frameworks, and security mechanisms, so it's crucial to verify that the extension functions correctly and securely across these platforms. Low
Content Security Policy (CSP). Content Security Policy is a security mechanism that helps mitigate cross-site scripting (XSS) and other code injection attacks. Testing the extension against different CSP configurations can help ensure that it doesn't violate the policy and that it can function within the allowed constraints. Low
Cross-Site Scripting (XSS). XSS vulnerabilities are a common security concern for browser extensions. Testing should include injecting malicious scripts and verifying that the extension properly sanitizes user input and prevents XSS attacks. Low
Cross-Origin Resource Sharing (CORS). CORS allows controlled access to resources from different origins. Extensions often interact with web pages from different domains, so it's important to test that the extension handles CORS requests securely and doesn't introduce any cross-origin vulnerabilities. Low
Web Access and Communication. If the extension communicates with external servers or APIs, it should be tested to ensure that it establishes secure connections, properly validates server certificates, and protects sensitive data during transmission. Low
Update and Patch Testing. Browser extensions may undergo frequent updates or patches to address security vulnerabilities or introduce new features. It's important to test the extension's ability to update smoothly and securely, without compromising existing functionality or introducing new vulnerabilities. Medium
Malicious Behavior. Test the extension against potential misuse or abuse scenarios to ensure it cannot be manipulated to perform malicious actions or interfere with user browsing experience or data. Low
It’s interesting to note that our wallet extension uses Chromium Manifest v3 (versus v2), where Google’s primary goals for v3 included improved privacy and security. So, we feel good about that. Many v2-based extensions in popular usage, including password managers, have vulnerabilities in these areas. Using a v3 manifest causes the browser to disclose certain requested permissions to the user and obtain their approval prior to continued usage. In addition, v3 extensions have improved sandboxing (runtime isolation) of the extension code (e.g., better isolation of the trusted messages between the web page script and the service-worker).
In addition, we chose to implement “chrome.storage” persistence, which can only be accessed by its creating extension. So, that’s a vast improvement over extensions that use the browser’s Local Storage, where a user can more easily inspect that content.
Identity/Crypto Browser Extension Risks
While the Identity Wallet is not a cryptocurrency wallet, similar vulnerabilities exist for an identity wallet. Here are some common vulnerabilities associated with such extensions.
Malicious Extension Downloads. Users may unknowingly download malicious extensions that claim to be crypto wallets but are designed to steal their private keys or sensitive information. Medium
Fake or Compromised Extension Stores. Attackers can create fake or compromised versions of legitimate extension stores, tricking users into downloading malicious crypto wallet extensions. Medium
Poor Code Quality. Extensions with poor code quality, such as inadequate input validation and lack of proper encryption, may be susceptible to various types of attacks. Low
Man-in-the-Middle Attacks. Attackers can intercept the communication between the extension and the wallet service, compromising the integrity and confidentiality of data exchanged. Low
Phishing Attacks. Users can be tricked into entering their wallet credentials or private keys into fraudulent websites or pop-up windows, leading to unauthorized access to their funds, DIDs or credentials. Medium
Extension Permissions Abuse. Extensions that request excessive permissions can potentially access sensitive data or perform malicious actions without the user's consent. Low
Supply Chain Attacks. Attackers may compromise the supply chain of the extension, injecting malicious code during the development or distribution process, leading to potential security breaches. Medium
Keylogging and Screen Capture. Malware or spyware installed on a user's system can capture keystrokes or screenshots, potentially exposing sensitive wallet information. Low
Holder vs Subject. An additional risk specific to identity wallets is that a credential holder is not necessarily the subject of a credential. Therefore, identity binding is important to reduce verifier’s risk with some credential presentations. High
In addition to considering each of these areas, we also studied Lace's Audit Report, since the potential vulnerabilities of a cryptocurrency browser extension and one for identity are similar.
Recommendations for Next Risk Assessment and Audit
In general, a repeated and more rigorous security audit needs to be conducted prior to the first generally available release of the product. Such an audit must cover design, user experience, development processes related to security (e.g., developer education, code reviews, static code analysis, checklists, prerequisites for release, monitoring third party components for known issues and updates), user experience, and dynamic testing.
It is recommended we engage a security firm with specific and deep knowledge in the subject of browser extension wallets.
The dynamic testing should be based on the scenarios identified during threat modeling exercise performed with the team.
Recommended Product Enhancements
The security audit process also yielded a list of recommended features and user experience enhancements. In addition to the topics that don’t currently have a Low score, we’ll consider the following recommendations:
- Redesign our key-management system. Design and implement a more secure vault module as a separate component, and potentially open source that separately.
- Consider open sourcing more wallet components.
- Design and implement a redundant backup and recovery mechanism solution, to reduce risk of data loss based on having single points of failure (e.g., the latest one backup).
- Improve password strength requirement.
- Lock out a user for about 30 seconds after 5 bad password attempts to thwart brute-force attempts to crack password.
- Add a user confirmation for any signing events (e.g., authentication to a website or issuing of a credential).
- Optionally leverage a hardware wallet for the primary key.
- Implement second factor authentication mechanisms (2FAs) for unlocking and decrypting (e.g., machine-based, browser signature based, or U2F/FIDO).
References
DotNet Security Cheat Sheet - OWASP
ASP.NET Core security topics (Microsoft)
Threat modeling methodology (Microsoft)
Code with Engineering / Security
To learn more about the Blocktrust Identity Wallet, visit blocktrust identity wallet
progress report
Building the graph UI
blocktrust analytics
As described in the milestone and the initial roadmap, the next step in the project is to build a graph-based UI to visualize the relationship between DIDs and credentials. The goal is to implement a private area where users can upload their known DIDs and credentials to build a connected graph between their known DIDs (either their own, or DIDs they know) and credentials (either their own or credentials or credential-presentations which have been sent to them).
To realize this vision, multiple steps have to be implemented: 1) a private area with a login has to be set up (partially done). 2) The user must be able to provide a list of DIDs and credentials to the service (also partially complete) 3) The service must an internal graph of the relationships of those DIDs and credentials (not done yet) and 4) a UI must be built which can display the graph (this was the focus of this month). To get a deeper understanding of the goal of this kind of display, take a look at the graphics on this website describing the project: https://blocktrust.dev/Analytics
I first looked into existing graph-visualization libraries (like D3.js) which over a wide range of different display types. But it turned out that they do look nice, but don’t over the required interactivity. The user should also be able to click on a node and select further options (e.g. filtering). Also, I wanted to have the possibility to move the nodes around and order them to analyze their relationship better. The solution was therefore to build my own graph-solution with the same framework the rest of the application was also built with (Blazor WebAssembly). As I expected in my roadmap, this would take a while. The current-state of this part of the application looks as follows: Nodes (for DIDs and Credentials) can be created programmatically. They can be connected by lines (currently only non-directional). They can be moved around by dragging and dropping the nodes to order them. Additionally, the Canvas can be zoomed in and out by using the mouse-wheel. The screenshots in the attached document show this as a simple example. In the next step, the display will be refined, and it will be connected to the existing backend to import an arbitrary number of nodes (DIDs and credentials). This will most likely take at least 3-4 weeks to work out all the small issues with this kind of display. Additionally, a few work items (like automatic ordering of the nodes) are still undefined.
progress report
Continuing the CredentialBuilder
p2p transactions based on trust
Over the last weeks, it got more apparent that the initial goal of the proposal isn’t possible anymore with the current architecture of PRISM v2. In the old version of PRISM credentials could be created by the SDK on an edge-device, while the user had full control over the issued credential. With the upgrade of PRISM numerous improvements were introduced, but the issuing of credentials is now centralized on the PRISM agents.
While I’m looking at alternative designs, the work continued on the Credential Builder (https://credentialbuilder.blocktrust.dev), which is a platform for everyone to try out the PRISM v2 without the need for coding. Depending on the possibilities of realizing the initial idea of the concept, I might shift the proposal in this direction to complete something which has a clear value proposition for the community. The PRISM team is aware of the project and it will be used as material for the cohort of PRISM students, to get a better grasp of how SSI in general and the PRISM agents specifically work. If I should decide to shift the initial proposal into this direction, I’ll first contact the Atala Team, as well as the Catalyst team. Until then, the work continues: In the last weeks the “credential presentation flow” was integrated into the credential builder. The flow consists of a DIDComm messages which is being sent by the verifier to the holder to request a credential-presentation of a specific credential e.g., a diploma. The holder receives the DIDComm messages and then decides if he wants to grant the request. If so, the credential is being to the verifier for verification (checking the signature, the issuer-did and the revocation-status of the credential). The work itself if carried out by the PRISM agent, while the credential builder provides an interface to inspect the interaction. In the provided documentation, you see screenshots of the credential presentation flow. Further information about this can be found in the Atala PRISM v2 document. More general information to this can be found here: https://github.com/hyperledger/aries-rfcs/tree/main/features/0454-present-proof-v2
progress report
UI Improvements
blocktrust identity wallet
After the IIW conference last month and all the work leading up to that, we took a little break and focused on fixing the code. With a hard deadline as for the conference, you often acquire a lot of of technical debt which we wanted to clean up before tackling new features. In this process, we also fixed numerous smaller UI problems and tried different approaches on how to display and notify the user of incoming DIDComm Messages, e.g. for the Chat feature. This for example, included a way to display PeerDID as as Identicon, a less distracting way to display the date, a new notification design and changes in the way the messages are loaded from the storage.
For the next milestone, we promised to show progress on the Sign In with DID protocol. Ofter the last months we refined our own solution of that protocol which is currently working (including a demo-page), but in light of new developments in the community we are backtracking a little bit trying to find a common solution: First the Atala PRISM team is developing a solution (“Sign in With Atala PRISM” in their enterprise offering), as well as Eric Duneau with “Login with DID”. Both solutions, as well as ours, are nearly identical from a technical standpoint, but don’t work together due to minor details in the protocol. So, we reached out to find common ground on a reference implementation, but we haven’t been talking to all parties up to now. We hope to show an interoperable solution soon, but as usual, those things take a bit longer.
In the attached document, you’ll find screenshots of the overhauled chat window. For the newest build of the wallet you can also go to https://github.com/bsandmann/blocktrust-identity-wallet and install it as a browser extension.
progress report
Work on supporting libraries
blocktrust analytics
The Analytics proposal made some good progress over the last weeks. This doesn’t so much in great new features, but in a growing maturity of the overall project and related libraries. Dozens of commits were made alone the open-source projects like the blocktrust.Mediator library and the DIDComm library as well as the Analytics project (also on GitHub but still closed sourced) itself. A few months ago, we went on the journey of porting / developing a range of different libraries to be used with our blocktrust Analytics platform. While these projects are mainly used by the Analytics platform itself, the project does have an overlap with the blocktrust IdentityWallet proposal we just presented at IIW (Internet Identity Workshop) in Mountain View on April 19th. We are currently about 2 months behind schedule, due to the fact that we wanted to be interoperable with PRISM v2 (which was not in the proposal!) and therefore had to embark on a lot of additional work. Most of this work is now complete and we are hoping to be on schedule again over the next month.
progress report
Demoing the IdentityWallet at IIW
blocktrust identity wallet
The identity wallet made some huge leaps forward this month. In preparation for the Internet Identity Workshop (IIW) in Mountain View (April 18-20 2023) we worked on interoperability scenarios with other teams inside and outside the Cardano / PRISM ecosystem. The main goal was to have a Connect-a-thon at the conference with different vendors of Identity Wallets and Mediator, showing DIDComm v2 interoperability. The event happened on the 19th of April, and we had a huge success demonstrating the ability to send ‘BasicMessages’ between the blocktrust Identity Wallet, the RootsId Wallet and also the PRISM v2 (Proof of concept wallet) in front of a diverse audience of SSI specialists. This is a major breakthrough due to the fact that we showed interoperability between not only different products, but also a vastly different underlying tech stack (Python, .Net, Rust, JVM, Swift and Typescript).
Over the last weeks we spent a lot of time refining the UI, talking to other teams and testing different setups. The attachment shows some pictures from the conference (together with Tony Rose, Head of the Atala Team), as well as some current screenshots of the app.
progress report
Announcing CredentialBuilder
p2p transactions based on trust
The work on the project continued with some experiments with the PRISM v2 beta: Over the last weeks we introduced a new project called “blocktrust CredentialBuilder”. The CredentialBuilder is a browser-based UI on top of PRISM agents. The Atala team currently only offers a Jupyter notebook and a Rest-API to interact with the hosted PRISM agents. The CredentialBuilder makes it far easier to connect two PRISM agents (using the PRISM Connect protocol), publish DIDs and offer credentials. This might help onboard new non-technical /business people to PRISM and also help to better understand the exact capabilities and (missing) features of the current state of v2.
The continuation of the CredentialBuilder will be an intermediate step for this proposal – on one hand, to deliver further tangible value for the community and also to evaluate the initial goals of the project against the reality of PRISM v2. Not all plans initially laid out for PRISM v1 are still possible with the current design of v2. So other the next months I continue to deliver value to the ecosystem and evaluate ways to find a path to the initial idea with corresponds to the current realities of PRISM, the whole ecosystem and the benefit for the overall SSI and Catalyst community.
The CredentialBuilder is currently online at https://credentialbuilder.blocktrust.dev To use it you’ll need API-keys to the current PRISM beta program. The attachment shows some screenshots of the CredentialBuilder which demonstrates the basic features. The project is open source and available here
progress report
Wallet-to-Wallet chat
blocktrust identity wallet
In preparation for the IIW conference in Silicon Valley next month, we slightly changed our plans for the wallet. Initially, we hoped this time around to focus on the Sign-In mechanism of the wallet. Our first integration should have been improved by now to have an updated demo. Instead, about three weeks ago, we decided on focusing on interoperability first. One of these interoperability cases is the sending of messages between different SSI-Wallet, namely different instances of the blocktrust wallet, the Roots ID wallet, as well has hopefully very soon also the new hosted PRISM agent. To enable this interoperability, we heavily invested into porting multiple libraries to .net (peerDID, DIDComm).
Last week we finally achieved the breakthrough that our wallet is able to talk to the RootsWallet. This is significant because the underlying technology is quite different. The wallet of the RootsID team uses the JVM based Aries framework as well as the PRISM SDK to build a mobile Wallet. We, on the other hand, use a complete .net stack, to create a Browser-Extension-Wallet. Since we will demo this achievement to a wider audience at the IIW conference and therefor have to further polish the interaction, we are unable to hit the milestone. But nonetheless, we can report numerous changes reflecting that a lot of work has gone into the wallet and the underlying libraries. In the attached document, you see different screenshots of new elements of the wallet, as well as the wallet sending messages to another instance of the wallet. Sadly, we didn’t have much time to produce a video of the interaction, but we’ll have additional material for the next milestone. The newest release of our wallet can be downloaded here: https://github.com/bsandmann/blocktrust-identity-wallet/blob/main/README.md
progress report
The next building block: the blocktrust mediator
blocktrust analytics
This month we were unable to hit the milestone, we initially planned to hit. Instead, we changed course a bit: The initial plan was to focus on a first prototype of how a UI for displaying the relationship between different DIDs and VC might look like. But this plan was made a few months ago, and it assumed that that VC will still be written on the blockchain. With the upcoming changes of PRISM v2, this won’t be the case anymore, and the relationship graph previously envisioned would be less useful in its old form. Instead, the communication of between DIDs moved more into the focus (communication between DIDs was not a topic at all for PRISM v1). Communication between DIDs happens with a protocol called DIDComm which we heavily invested in over the last month (see previously reports) to port it and other necessary libraries over to .net. In the last month we wrote another important piece of required software: a mediator. (we also open sourced the library, and you can find it here.
). A mediator is (on a basic level) similar to an e-mail server. It is running somewhere in the cloud, and it is able to receive and forward DIDComm messages to clients, which are not online all the time, like a wallet. The investment is the library did not only help our other project, the “blocktrust Identity Wallet”, as well as other projects like the RootsId team, but is a necessary component for the analytics platform, as it finally offers the building block to send messages between parties. While we open-sourced the code, we also have an instance of the mediator publicly running at https://mediator.blocktrust.dev for everybody to use. It generates QR codes, a external wallet could scan and then connect to it to use it different features. How does the work continue? With the upcoming release of PRISM v2 we have multiple changes to incorporate in our existing codebase, which will take additional time and will most likely cause us to not hit the milestone for the next month again. The public nodes for PRISM v1 have already shut down, and to finish a analytics platform for a product that doesn’t exist anymore doesn’t make sense. The necessary upgrade for PRISM v2 will take some additional weeks – in combination with the slightly changed focus, we are a bit behind schedule, but the main focus should always be to build a valuable product for the community and that’s what we are committed to continue doing.
progress report
While waiting for v2 (Part V)
p2p transactions based on trust
We are still waiting for the release for PRISM v2. Simultaneously the work continues full time on different projects related to Atala PRISM. After the port of the DIDComm and PeerDID library, last month, we also open-sourced the blocktrust mediator this month (see here - also running in the cloud at https://mediator.blocktrust.dev). We also achieved a breakthrough in interoperability between the blocktrust wallet (which will also be used in this proposal) and the wallet of the team of RootsId-Team by sending messages back and forth for the first time (which is also a requirement for this proposal). Since some information on PRISM v2 are still a bit unclear and most of the time is invested into the more tangible projects and required foundational work, this project is moving much slower.
On wallet security
blocktrust identity wallet
The blocktrust identity wallet is a browser-extension wallet currently in development. An early proof-of-concept was initially funded in Fund9 of project catalyst and is now on its way to become a minimal viable product. While the wallet was first envisioned as a wallet primarily for PRISM v1 (the SSI platform of IOG), the target changed to become a more general SSI wallet, compatible with PRISM v2 and potentially other DIDs methods and Credentials types in the future. With a growing feature set, the complexity of the application grows – despite it being still in an early state – and therefor also the complexity and challenges of the underlying security architecture.
In this blog post, we want to give an overview of the different attack vectors a browser-extension wallet is facing, as well as to showcase some of the security measures we currently have in place or planning to adopt in future releases.
By far the most prevalent attack vector of any kind of crypto or identity wallet is on the user itself. While cryptocurrencies are deemed as a complicated topic by many and the handling of different private keys, transactions and wallet addresses is by no means easy to grasp in the beginning, the handling of its own digital identity can even be more confusing for the average user. Both cryptocurrencies and blockchain based digital identity have a certain technology overlap, and thus security concepts of one area may also apply in the other. And so does the language: In the identity space we also have to deal with mnemonics, private key pairs as well as certain objects which are anchored on the blockchain. The confusion about these words and the lack of understanding on what they mean exactly and how to correctly behave in certain situations in the main attack vector. An inexperienced user can easily fall into the trap of following malicious instructions, installing seemingly legitimate software, or just clicking on the wrong button one too many times. In the case of cryptocurrencies, this may cost you a lot of money, but in cases of where you lose control over your own identity, the consequences could even be more grave, causing problems well beyond material loss. Think of getting your physical wallet stolen: The loss of a few bills are usually not the main problems, it is your stolen identity which surely have effects for the following months, even in the best case, that the thief didn’t even try to use your identity for his own advantage to impersonate you. It's easy to see that the security measures which have to be in place around protecting your digital identity have to be as robust and better even more robust and fool-proof than those in place for the handling of digital currencies.
The good news: The identity space can learn from the mistakes made with crypto wallets early on. This is not only true for the application architecture and the proper use of cryptographic primitives, but also the user experience. The detailed explanation of every action one can take in the wallet, a good visualization of potential dangers areas and guardrails for the inexperienced user are the most important security features by itself. The mitigating of phishing attacks due to educated wallet users which don’t fall into scams and obvious traps will have a bigger overall impact, than the use of a single slightly more secure algorithm.
But it is not only about explanation, it is also about forcing the user not to take shortcuts: A good example of this is the login to the wallet with a password. While it is often the case that password requirements are somewhat strict, requiring at least 8 characters and a number, this doesn’t make a password safe by itself: A low entropy password like “111111111” or a common password like “Password123” might pass the static rule of the requirement, but are still not secure. Only with mechanisms like password-rotation and the using of a second password or reentering of a password for sensitive actions like the signing of credentials or documents can a wallet achieve a basic level of security. Security mechanisms against brute forcing passwords also helps. On top of that, a hardware based key storage or signing or multifactor authentication can improve the security considerably. One key aspect is here is not to make these additional security measures optional, but force the user to use them. The hard problem is not just to implement them, but to make them part of a general user experience in which the user doesn’t feel hassled or restrained.
Another attack vector, often closely related to the user itself, is the platform the wallet is running under. In our case, it is the browser and the operating system. Both of them could potentially be compromised, which can cause a major threat to the security of the data being stored in the wallet. A browser riddled with malware and an operating system home to a selection of viruses and keyloggers might not be able to extract data from a closed wallet, but as soon as the user enters a password or authenticates through other means, opportunities open to either grab the password directly or read the unencrypted wallet-database directly from memory. And this is not only true for personal computers, but also mobile devices. A wallet can only be secure under the assumption that the execution is environment itself is not compromised. And this nearly always comes again down to user education.
But it's not always that simple: A clean system isn’t secure forever. Security holes, previously unknown, get found and have to be patched. So, the user is forced to install updates regularly, not just on the OS, the browser, but also the wallet has to be updated – everything in the hope that the update is an improvement in overall security and doesn’t introduce new ways a attacker might take.
When it comes to the security, one major aspect is of course, the cryptographic algorithm used to secure its contents: the private keys of the DIDs, the Credentials, the mnemonic phrase and all communication related data (e.g. messages). Additional material like non-sensitive logs, contacts or settings could also be protected, but don’t have to in any case. In the most simple case, the contents of the wallet are encrypted as soon as the wallet is closed, and decrypted when the user opens the wallet with his password. In the process of closing the wallet, every plaintext information maybe persisting in memory is also scrubbed, so that in the end only an encrypted file is left in the storage of the wallet.
The algorithm used is usually AES-CBC (better AES-GCM) with a key derivation function like PBKDF2 (with at least 500,000 iterations) to increase the difficulty of brute-force attacks. While it is obvious on what algorithms to use, the devil often lies in the implementation itself: Is the function to produce secure random numbers correctly called and not reused? Is the nonce (or initialization vector) correctly populated? The minor details in implementation can make a big difference, and it is often not entirely obvious if an implementation is secure, just because the outcome of the encryption function is ‘unreadable gibberish’.
While we are still in the process of developing the wallet, we had countless learnings on our way, and we are by far not done with our security architecture. We currently do implement a good selection of features mentioned earlier and are already on par with some of the existing crypto-wallets out there, but are still not where we want to be.
Over the coming weeks we will do a redesign of our key-management system and implement a more secure vault-module in our wallet which can handle a wider range of keys (including support for PeerDIDs) and different access tiers. Currently, the encryption and storage of the keys is deeply integrated into the wallet itself, which makes it harder to determine and inspect its security properties under memory leaks. One idea is also to open-source this vault component earlier and separately from the core of the wallet, to open it to public review even before the rest of the wallet is ready.
We hope that this brief explanation of our thinking was informative. As soon as we have new information about the upcoming architecture and implementation of our vault-module we’ll post a follow up to this introduction here, too.
progress report
Multiple DIDs and backup & restore
blocktrust identity wallet
Support for multiple DIDs In the last month, we mainly worked on the support of multiple DIDs inside the Blocktrust Identity Wallet. While the use of just one DID was a practical first step, in real-world scenarios a user will most likely have multiple DIDs, representing different identities. For example, the user might have one DID for work and another one for his personal life. To some degree, this is comparable to the multiple e-mail addresses one has. Being able to seamlessly switch between these DIDs inside the wallet was the main goal of the recent work (See also attached screenshots and milestones).
To bring the concept of multiple DIDs even further, we ported an implementation of the PeerDID library from Kotlin (https://github.com/sicpa-dlab/peer-did-jvm) over to .net. We open sourced the library (you can find it here) and made the adjustments to make it fit into our existing infrastructure. The move to also support Peer DIDs is in alignment to the future version of Prism v2, which heavily relies on Peer DIDs. Since we want our wallet to be compatible with v2, this was a necessary work item, which hasn’t been on our initial agenda. The use of Peer DIDs extends the concept of having multiple DIDs beyond just having a single DID for work and private concerns, but having a DID for every single relationship you have. The DIDs are also not always written to the blockchain, but created on the fly whenever you create a new connection to someone. . The current implementation of having multiple DIDs doesn’t support Peer DIDs yet, but the work we did this month including the port of the library is the foundation to integrate peer DIDs over the coming weeks.
Other minor work items have been done on the security model of the wallet, as well a back & restore concept which allows the user to back up the wallet contents in an encrypted piece of data and then restore the backup, for example on another device (see screenshots in attachments). As usually the newest build with support for multiple DIDs as well as the new backup & restore feature can be downloaded here Since this report also overlaps with the latetest milestone, you can also see a video of those feature in the related POM video. Further information on us and the project can be found here: www.blocktrust.dev
progress report
DIDComm v2 support
blocktrust analytics
As mentioned in the last report, one major work item was the port of the DIDComm v2 library from Kotlin over to .Net. This work continued far into this month. Sadly, it doesn’t make for a great report because it isn’t visual, but let me explain what is going on: The DIDComm v2 specification (https://identity.foundation/didcomm-messaging/spec/) describes how DIDs can exchange messages. These could be, of course, Verifiable Credentials, but also simple text messages or even payments. PRISM v1 had no support for DIDComm and didn’t have a opinion on how to exchange data between wallets. Since most of the projects for PRISM v1 were just prototypes anyway, that didn’t matter too much, since data could just be copied and pasted from the sender to the recipient. With the upcoming PRISM v2, the Atala team chose to implement DIDComm as their protocol of choice to send messages between parties and integrated DIDComm deep into the foundations of PRISM v2. Luckily, SICPA (a Swiss company famous for producing banknotes) took the DIDComm spec and wrote a library to be used on the JVM (Java, Kotlin, Scala, …). Since the PRISM project is based on Kotlin, the Atala team could simply take the library to use it in their code – which they did. As you can see here (https://github.com/decentralized-identity/didcomm-messaging), the DIDComm library is available in a wide range of programming languages, but not .net. So, most of the last two months was spent to port the library over to .net, so we can use it in our blocktrust projects: the wallet and the analytics software. Of course, the project was made open source. You can find it here
The port of the library is a major milestone for us, but has never really been part of the initial plan, due to the fact, that at the time of proposal writing it was completely unclear what PRISM v2 will contain and what not. But since we are not here to just work on what was initially planned, but to deliver a product which is not only relevant in the lifespan of PRISM v1 (which is coming to an end in a few weeks), but in the long term the port was a necessary work item. With over two hundred files and over 2000 tests, the port of the library was indeed a major investment.
What will this library enable us to do in the future? It will allow this proposal not only to track DIDs, but also understand and analyze the communication between DIDs. The platform will be able to visualize connections of a customers' wallet to other parties and might even offer debug tools to better understand the trust graph.
What are the next steps? Since the work on the port is completed, the main focus will return on the different features of the analytics platform which will be using the new capabilities: Mainly continuing the build of the private area, so a user can upload their DIDs and connections to get a visualization of those (the graph feature is promised for the next milestone).
Due to the major time invested in the port of the library, the project might be delayed for a few weeks, before hitting the next milestone, but the project is on track to deliver even more features than originally promised.
Thanks for your interested and supporting the blocktrust analytics platform. For more information about us go to blocktrust.dev or try out the current version of the analytics platform on https://analytics.blocktrust.dev
progress report
While waiting for v2 (part IV)
p2p transactions based on trust
While the waiting for PRISM v2 continues, a few more features are getting clearer, the use of DIDComm, WACI, PeerDIDs and JSON Credentials. While this project is mostly on hold presently the work continues on the other PRISM related projects. We just finished the port of the DIDComm v2 library to .Net (see here), as well as the DID Peer library (See here). Both libraries will be extensively used in our other PRISM projects and also find the use in this proposal.
progress report
Video and UI-Tests
blocktrust identity wallet
Over the holidays we had a little break and the work continued at the beginning of January: one major work item was the port of the DIDComm v2 library to .net. The work isn�t completed until now and will require about two more weeks of work. After that, we�ll switch to implementing protocols on top of DIDComm v2 to finally achieve interoperability. The DIDComm v2 library will be made open-source after completion of the port. This will happen before the next report.
Another focus of our work was to improve the wallets' capability to run in different environments. We started that work earlier and have now a stable version, which can also sync information over different environments: e.g. you could open the wallet as a extension and as a Iframe running inside a another website and information gets immediately shared between the different instances of the wallet. This is particularly important for any kind of work with Verifiable Credentials to prevent double-signing and lower the chances of a user doing something wrong or invalid when having open multiple instances of the wallet.
We also worked on improving our CI/CD pipeline. Furthermore, we are now able to run UI-tests on the wallet inside our pipeline, which will help in the long term to further ensure the quality of our build. We decided to use a library called PlayWright for this and worked on setting this up for some first basic tests on a remote-build agent. As always you can find the newest build and instructions how to run it here: https://github.com/bsandmann/blocktrust-identity-wallet For the upcoming milestone we also produced a video which demonstrated many features also mentioned here in this report: https://www.youtube.com/watch?v=z1JFYxqNM3I&ab_channel=LivelyGig
progress report
Private area
blocktrust analytics
In the first week of January, I submitted the video for the proof of achievement, which also represents a good reference for this report. The analytics platform is currently available on the preprod-network as well as on the mainnet. With the completion of the first milestone, the work now switched to the development of the private-area of the website. This is a part of the page a user can register for and log in to. This is currently under development and will likely take a month to have all the requirements in place. The idea here is not to use a traditional login with a username and password, but leverage a Verifiable Credential. There are different ways to accomplish this and since this hasn�t really done before this requires some research, which is carried out currently. The most promising path seems to be to use a special variant of a self-signed token based on OpenID Connect.
Another point which currently takes a lot of time is the porting of the DIDComm v2 library over to .net. The library currently only available for the JVM, rust and typescript will provide the .net ecosystem as a whole the ability to build DIDComm based applications. The porting is not directly part of the proposal, but will be leveraged by the proposal when the porting is complete. With the holidays in between, this summarizes what has been done over the last month and which items are currently worked on. Please don't hesitate to have a look at the current version of the application here https://analytics.blocktrust.dev/ (for the preprod network) and here for the mainnet (https://bt-analytics-mainnet.azurewebsites.net/)
progress report
While waiting for v2 (part III)
p2p transactions based on trust
The work on the proposal itself is currently mostly on hold until PRISM v2 comes out. Meanwhile we work continues on other PRISM related topics like the Blocktrust identity wallet and the PRISM analytics platform. Also, we are currently working on a DIDComm v2 library to allow .net developers to take part in the PRISM ecosystem.
progress report
Logging, Website interaction and state machines
blocktrust identity wallet
In the process of redesigning the underlying architecture of the wallet, we decided to go with a statemachine-approach to model the different states the wallet can be in. We started the work on this, but are still in the process of finding the optimal pattern. The basis idea is, that the wallet is always in a very specific and well-defined state. When a action occurs (like the creation of a DID), the wallet undergoes a strict transition from one state to the next. Whenever the user exists the wallet or another session is opened, the last state is restored from the encrypted storage and every information not in alignment with the last state is thrown out. This architecture keeps the wallet-data coherent and provides safety in cases of abrupt termination in every situation.
Another feature we have worked on and which we�ll develop further along the way is the Logging-Service, which offers methods to query the data stream of incoming events. These could be system-messages, user-interaction or incoming data from external sources.
An overarching topic, we also mentioned in the last report, is interoperability. A lot of resources are currently going into the development of a .net compatible library for DIDComm v2. The current reference implementation doesn't have support for .net, so we have to build it ourselves. This is a considerable endeavor and not covered by the initial plan, but nonetheless a crucial feature for future development. The main goal is to archive interoperability with RootsWallet in the next weeks.
Lastly, we also worked on the improved website-integration and the support of the direct injection of the wallet inside a website (using Iframes). These extents the different modes the wallet can run in to four: As a normal extension, the fullscreen-extension-mode, as a Popup opened by a click on a website and now also injected into a website as a overlay.
progress report
Mainnet and data-migration
blocktrust analytics
The analytics-platform is finally also available on mainnet (https://bt-analytics-mainnet.azurewebsites.net/), which required an architectural overhaul in some parts, due to the size of the dataset. The previous approach of syncing the data were (while being feasible in general) not up to the task of syncing the dataset in a acceptable amount of time. Currently, the project is using SQL-databases living on Microsoft Azure. This is producing a bit more costs than initially estimated, and we are looking into ways of optimizing the infrastructure in regard to future growth and feature expansion while keeping the costs in a reasonable manner (and inside the proposals budget). In the end in comes down to the expected performance we would like to provide in the long term and with upcoming features.
The next major development regarding personal accounts and the management of the collection of DIDs has already begun, but currently takes a back seat due to the development of a .net implementation of DIDComm v2. At first glance this might be unrelated to the analytics platform, since this is a way of inter-wallet communication, but with the integration of agents and the ability to export and store DIDComm Messages from a wallet this opens up an entirely new dimension of possibilities.
progress report
While waiting for v2 (part II)
p2p transactions based on trust
Nothing new on the PRISM front. V2 is scheduled for Q1. The work is halted until further information comes out regarding the SDK.
Meanwhile, the work steadily continues with the Wallet. We are redesigning the internal architecture and preparing to add new features like DIDComm v2. While this work is separate from this proposal, both projects are interconnected, due to the necessity of having also a wallet for P2P transactions. Please have a look into the wallet and analytics-platform where most of the time and effort is currently put into.
progress report
Insights into the preprod-network
blocktrust analytics
The project is based on the already developed proof-of-concept of the analytics platform for the testnet. In the first month, the project was updated to use the new blocktrust SDK to align with the PRISM SDK on version 1.4.1. The update included a new type of operation which wasn�t available on 1.3.3 which is the �Deactivate DID� operation. The new operation caused some major rework and required also some additional testing, since the official PRISM node is not behaving as it should in some cases. The causes different results in the resolution of some DIDs. Since these are all edge cases, the real-world differences shouldn�t be relevant at this stage.
Additionally, the project was also released to support the preproduction network, which required some additional work to make the code more agnostic of the underlying Cardano-network. The project is now using a CI/CD pipeline to roll out a new version of the analytics platform to each network independently. The current version can be found here: https://bt-analytics-preprod.azurewebsites.net/ The mainnet analytics will also follow in a few days. The next item on the to-do list is the integration of a private area, which allows users to monitor a specific set of DIDs over time.
progress report
Facing Manifest v3
blocktrust identity wallet
This is the first progress report of the newly funded browser-extension wallet: The first funding round occurred in the beginning of November.
Ed Eykholt was onboarded on the Identity Wallet project and is now its Lead Developer. In the last month, we spend some time re-architecting some core components of the wallet. The first iteration of the wallet was in many ways just a proof of concept, and it left many architectural questions unanswered. While we are still in the process of finding out of how to structure things best, we rebuild most of the core-services. We also updated our existing PRISM SDK to 1.4.1 and made the necessary adjustments in the wallet and connecting services.
The biggest problem we tackled early on was the migration to Manifest Version 3: Currently, nearly all Browser-Extensions (including the Crypto-Light-Wallets) face the same problem: Chrome requires new browser-extensions submitted to the web-store to use v3 instead of v2. This seemingly small change forces big projects to rethink their complete internal architecture of how to interact with webpages. Instead of a few days of refactoring, this caused those big projects like Metamask to go on a multi-month journey which isn�t over any time soon. Until now, nearly no v3 extensions are available, despite the fact, that projects are able to submit v3 extension over a year now. This shows the problems many extension developers are still facing. Since we restarted our developer effort on the wallet, and we were free to throw away old approaches we might have it a bit easier, than other projects, but we are also not completely there yet. The extension is running on v3 now, but we have to still figure out some architectural pattern for ourselves, since there are currently no reference implementations of how to build browser-extensions-wallets � even for crypto with the new manifest version. Doing everything is WebAssembly was also a additional hurdle which didn�t make thing easier in the current stage of the project.
Additionally, we made a few smaller UI changes and currently working towards the first milestone, which includes logging and the activity history.
Overall, we are quite happy with progress we made so far � it was by no means fast, but we are confident to pick up speed after leaving the topics of browser-interop behind us and focusing more on the business logic, which we can implement in .net.
progress report
While waiting for v2
p2p transactions based on trust
The Atala PRISM team is still working on refining PRISM v2. Since the changes from the existing version to the new will change the architecture substantially, my work on the codebase for p2p-proposal is still halted until further information is released. Nonetheless, the work continues on other related projects like the Blocktrust Identity Wallet and the Analytics Platform, both projects which still can continue without access to v2, because of their long backlist of ideas and concepts which can be implemented without being dependent on the concrete implementations of the VC model of PRISM.
Also, the blocktrust team got a new addition with Ed Eykholt, who is mostly focused on the wallet. A few days ago, we met up at IIW (Internet Identity Workshop) in Mountain View, to discuss everything SSI and the strategy for blocktrust. We also met Lance Byrd and Rodolfo Miranda from the Roots-Wallet team to align on an interoperability strategy. All these topics don�t relate directly to the proposal, but may give some better understanding where things are going and that the proposal slowly moved from a single goal to an overarching strategy around PRISM.
progress report
A new timeline
p2p transactions based on trust
While the project is still on track, and I�m working full time on different things related to Atala PRISM, the timeline of the proposal has shifted a bit. Let me explain: The architecture of the proposal relies on Verifiable Credentials, which are shared publicly and signed by both parties. Sometime in the next months Atala PRISM v2 will be released which will be a major redesign of the Verifiable Credentials and the architecture of PRISM in general. Recent discussions with the PRISM team have revealed that the current version won�t even be patched anymore, and all the internal development effort is put into finishing v2. This new development let me to the conclusion that I would be in the best interests of all parties to delay the completion of this proposal until PRISM v2 is out. This will ensure that the project will have a longer life span and is not just a proof-of-concept to be abandoned shortly after. In the meantime the work towards the proposal continues along with other projects based on Atala PRISM. From the initial idea and the proposal a company is slowly forming and the work continues not only in code, but also in SSI-working groups, discussion with IOG and new ideas and projects emerging.
This being a major change in the initial timeline, I�m happy to answer potentials doubts or questions from the community to address this change. Feel free to contact me.
progress report
Understanding the ecosystem
p2p transactions based on trust
As promised, now an update regarding the last post. The proof of concept for my own PRISM node is now online in the Cardano test-network and at the same time also an analytics platform for PRISM. As new blocks are created in the test-network, they are scanned and analyzed for PRISM operations found in the metadata. If a PRISM operation (e.g. the creation of a DID or the issuing of a Verifiable Credential (VC)) is detected, it is decoded and verified, and then written to an SQL database.
In this process, not every operation located on the test-network is valid. Cardano is a permissionless blockchain and theoretically anyone can write new PRISM operations to the blockchain and make claims that are not true. Consequently, each operation must be checked. Are the operations in the correct order? Are the signatures valid? Which in turn requires that the DID already exist with the corresponding public keys as well and have not been revoked, etc. All valid PRISM operations then end up in an SQL database.
Based on the node and the SQL database, another application then performs a statistical evaluation with each new block and makes it available on an interface. This is the basis for the current PoC of blocktrust analytics (https://analytics.blocktrust.dev). Using these statistics, we can now see for the first time what�s going on in the PRISM ecosystem. How active is the developer community? What about IOG's collaborations? E.g.: with Dish or the Ministry of Education in Ethiopia? But it's not just about statistics. Using a database of all existing DIDs and VC will also help developers and companies better understand what they are doing on the blockchain. Why do operations fail? How many VC has a particular DID already issued?
However, the most exciting topic is certainly the formation and analysis of the slowly emerging trust network. However, this is outside this proof-of-concept. This was primarily created to investigate the feasibility of such an analysis platform.
So how does this all fit in with the existing proposal? As I mentioned earlier, I realized more and more in the course of the work that I can theoretically implement the proposal relatively quickly as a demo, but there is still a lack of tools around in our ecosystem to be effective. A completed proposal that immediately ends up in a drawer is no help to anyone. So the work continues step by step in the direction of the original plan - just with a few detours via solutions and tools that really help to expand the ecosystem and provide the basis for achieving an impact with the original proposal as well.
progress report
At the core lies the node
p2p transactions based on trust
Work on the white paper and the concept continued, but more slowly than expected. Regardless, all of my work time is going into topics that have something directly to do with PRISM and that are advancing my understanding of SSI. A significant portion of that is just going into understanding the node, the intricacies of the DID resolution, and all PRISM relevant data on the chain. I've already come a long way in this process, writing substantial parts of my own PRISM node that reads and evaluates the blockchain. (This way I also already found a few bugs that are existing in the official PRISM node � and that I have reported to IOG).
Why is this relevant to the proposal? Having your own implementation of a node increases the freedom of possibilities to make feature enhancements that are relevant to the proposal. So far, the premise has always been: how to implement the idea of a trust network based on PRISM. This inevitably led to architectural twists, and constraints. With the newfound understanding and the existing technical foundation, this opens up new ways to implement the original proposal more effectively. Is this the fastest way to complete the proposal? No, but the dissatisfaction of quickly implementing a half-baked solution that then ends up in a drawer is increasing. So, I'm going to dig a little deeper into PRISM, finish the PoC of a PRISM compatible node first, then come back to the proposal. It is becoming apparent that the proposal will take a little longer to implement, but I doubt that is problematic since the time and funding will go exclusively to PRISM related projects, contributing to the overall development of the ecosystem.
In return, as a supporting feature, there will be something to see here within 2 weeks that has not been seen before in the PRISM ecosystem. So much for the teaser ...
progress report
The three stages of trust
p2p transactions based on trust
While the last time (interrupted by the summer vacations) the work was very much about the wallet, the SDK and Catalyst, I continued with the already overdue white paper. The central question is how to enable trust between two parties without a central platform. A goal that I realize increasingly is actually a step too far. It tries to realize something for which some foundations are missing. Not that it can't be done, but without those foundations it can only be a PoC and nothing more�and that would be a waste.
In my opinion, there are three stages of creating trust on the web: The first, and the easiest stage, is to make a statement and make it verifiable by others. I have already explained this topic in detail in the proposal 'PRISM credentials for the web' (and also here https://blocktrust.dev/WebCredentials). With this first level, positive statements can be presented in a trustworthy (and verifiable) way on the web. The second level of the trust hierarchy is to be able to present both positive and negative statements on the web in a trustworthy manner. While at the first level there are ways to suppress negative statements, at the second level it must be technically ensured that this is not possible. The manifestation of this idea is a review system for PRISM. This always involves one party making a statement to another party. In the third stage, the review system gets extended so that two parties can make statements about each other. It is easy to see how this third problem is the most complicated to solve.
My original proposal (naively) set out to solve the third problem, while the first two before that have not been solved by anybody yet either. Thus, working on the third issue is always working on the underlying two problems as well. Correspondingly, it takes a little longer than originally anticipated�but I would consider this to be positive, since along the way the other issues are also addressed and shaped into tangible implementation concepts, PoCs and new proposals. The solutions are not just questions of what my code looks like, but also questions of how to standardize schemas in general and what changes would have to be made to the PRISM SDK and the Node itself to be able to solve all of these three stages in a technically clean way.
So, work continues on the white paper (currently primarily concepts for extending the PRISM node and implementation ideas for the review system) and some concrete implementations along the way.
progress report
An alternative way of looking at things
p2p transactions based on trust
The focus of the work has shifted a bit in the last weeks: instead of continuing to work on the concrete implementation of the proposal, I first focused on the technical foundation. As noted before, the situation around the SDK is still very unclear. Although the announcement to make the SDK public is still floating in the air as ever, there is still nothing definite. The hope that something will happen in the near future is rather low. And the situation is understandable: with the publication of the SDK, IOG also opens its business model to third parties: a strategic decision with consequences that cannot be reversed. Securing the business model instead by locking the SDK (and thus access to the Node) behind a paywall is thus understandable - although I believe that such a decision, should it be made, will not have a positive impact on the ecosystem.
And how is this relevant to my proposal? In the technical implementation I have always assumed that for each transaction usually 4 credentials are written to the blockchain: 2 for the start of the transaction and 2 for the completion of the transaction. Due to the architecture of PRISM, this is inevitable as there are no multi-signature credentials. A (possible) business strategy that attempts to generate revenue from issuing credentials is difficult to be compatible with this type of proposal: the cost would theoretically have to be in the low cents for all four transactions combined for the concept to work in the real world. A scenario that seems unrealistic in the current setup of Cardano and Atala PRISM. So instead of trusting that the proposal can be built on a business model of PRISM, I looked at alternatives: What would it mean to write an SDK and a Node myself? Similar to PRISM, but not identical. What could multi-sig credentials look like and how could the cost to write to the blockchain be reduced? These questions have not all been answered, but the first step has resulted in an SDK that is compatible with the PRISM SDK, but architecturally different and based on .net. Not because the Kotlin SDK is bad, but because it gives me the freedom to continue working on the PoC for the proposal. The SDK is explicitly not part of the proposal, but a way to implement the proposal.
Where do we go from here? First, a light wallet (a browser extension) has been created in the last few weeks based on the SDK, which will be the starting point for the wallet to be used in the proposal. This light wallet can be further developed relatively quickly (thanks to .net MAUI) into an Android wallet. Furthermore, a website is currently being created under the label 'blocktrust' with a summary of the technologies and proposals that have all grown out of the original proposal. So things are moving forward - perhaps not always focused on the envisioned goal of the proposal - but still in a big way: all for a better world with SSI.
progress report
Continued POC and questions regarding the SDK
p2p transactions based on trust
In addition to the continued immersion in SSI specific topics, the POC was the central topic of the last weeks. The white paper was postponed somewhat in favor of practical experience with the SDK. In the course of this, various problems in the architecture of the SDK were revealed: For example, the SDK always assumes that the private keys are known within the SDK. Signing credentials via a browser wallet is not natively supported. To implement such capabilities, new functions had to be written, which required some code duplication. In other places, too, one gets the impression that the SDK was written only for an Atala-specific application purpose and not from a perspective that is open to alternative application use cases.
As far as the release of the SDK is concerned, there is still some uncertainty: It has not yet been communicated to what extent the node will be released, who will be allowed to run the node, how the accounting-model on the node will work, if there will be node-as-service operators, etc. The questions primarily concern the business model of Atala PRISM and less the implementation of the proposal. Nevertheless, they are critical to the way forward and the underlying structure of the implementation of the proposal. At the heart of this is the question: who will pay for the costs of issuing credentials and how can they be paid? Regardless of the costs themselves (and their amount), this has architectural implications and questions the philosophy behind P2P transactions: In addition to the transactions for issuing a transaction token, does there need to be a transaction for payment? One is a transaction against the PRISM node, the other is a transaction against the Cardano blockchain. How would an integrated wallet look like to consolidate this whole process into one user action in a user-friendly way? Or does one use a centralized service where there is a settlement account? The most convenient solution from the user's point of view, but not necessarily in the spirit of the very idea of creating a decentralized solution. Unfortunately, all these questions cannot be answered yet, because IOG does not release any information about this at the moment.
In a conversation with Tony Rose (product manager for PRSIM) I was able to raise these points personally. The result was also only that the business model on the part of IOG is not yet definitely determined. Regardless of the unclear strategy regarding the SDK, the support on the part of PRISM is very good. Besides these developments, there were two weeks of Easter vacation for me, so that work will resume regularly at the end of April.
progress report
Research and POC Planing
p2p transactions based on trust
After the completion of the PRISM Pioneers program a few months have gone by, so I started working through some of the already visited material to get a better understanding of a few technical details. The new version (1.3.1-SP1) was integrated and some experiments completed. There are still a lot of open questions regarding the release version of the SDK and the node itself. Especially around the business model of IOG.
In addition to the technical experiments the research around trust-models, SSI and possible cryptographic solutions to the trust problem is ongoing. This will likely continue for the next weeks: mainly studying the W3C specifications in detail and reading Self-Sovereign Identity by Alex Preukschat and Drummond Reed. Meanwhile I�m taking a lot of notes which I�ll compile to a draft of the whitepaper.
A first result of the research phase is a new proposal for Fund 8: Self-Souvereign identity which can be found here. The proposal has an overlapping with the ongoing proposal, but only regarding theoretical aspects � not technical ones. It is about the trust-building phase before a transaction even happens. In the proposal we try to find a better way to do endorsement on the web. Have a look at the proposal or visit blocktrust.dev.
The project is schedueld to be finished until 2022-09-30 (End of September 2022)