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
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 at https://github.com/bsandmann/blocktrust.CredentialBuilder
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 (https://github.com/bsandmann/blocktrust.Mediator - 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.
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: https://github.com/bsandmann/blocktrust.DIDComm), as well as the DID Peer library (See here https://github.com/bsandmann/blocktrust.PeerDID). Both libraries will be extensively used in our other PRISM projects and also find the use in this proposal.
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.
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.
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.
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.
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.
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 ...
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 on the website (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.
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.
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.
After a few days of CA-work, the research continued: step by step, it goes deeper into the SSI material and new ideas are emerging. Primary focus is to dig into DID specifications and to think through possible workflows for different trust models.
Along the way, the technical design for a POC is starting. The approach is currently to provide several generic modules as a microservice: For DID-based authentication, for creating, tracing and verifying them. Above all, there is always the question of complexity in the architecture conception. How does one want to build such a system? How small-scale do you want to be with the microservices, or is a system that consists of perhaps only two or three components and is tightly coupled sufficient for a POC?
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)
The initial batch of funding was received, and the work will begin next week with the research phase.