mehranshakeri
commented
2 years ago Does the "Wallet SDK > Create Identifier" mean generation of DID & DIDDoc and anchoring them in the Verifiable Data Registry?
Closed acarnagey closed 2 years ago
mehranshakeri
commented
2 years ago Does the "Wallet SDK > Create Identifier" mean generation of DID & DIDDoc and anchoring them in the Verifiable Data Registry?
acarnagey
commented
2 years ago Yes, creating the anchor file hash, and linking the DID and DID Document to the Ethereum blockchain and IPFS to effectively store the DID and DID document.
Therecanbeonlyone1969
commented
2 years ago This implementation allows for the same mnemonic for multiple keys. This behavior is discouraged in NIST-800-57.
@acarnagey it would be great if the solution would allow for multiple mnemonics and subsequent mnemonic management. Doable?
Therecanbeonlyone1969
commented
2 years ago @acarnagey ... could you please include a live demo meeting during a Baseline show (weekly), or General Assembly (monthly) and a demo video into the proposal?
Thank you!
The TSC will be completing voting by next week.
Sjaaaakster
commented
2 years ago @acarnagey, i addition to @Therecanbeonlyone1969 his comment:
Would love to see in the proposal what kind of content you could create that would give more reach as a baseline protocol community, considering the need your work would bring.
Thinking of blog posts / demo videos / use case descriptions / developer meetings.
OR13
commented
2 years ago we can do a video demo, I will have our team look at revising the proposal to include that... probably a technical walkthrough video would be best if we want to encourage further contribution.
acarnagey
commented
2 years ago @Sjaaaakster Work to be done section is updated with the following:
humbitious
commented
2 years ago I'm concerned about this one. The timeframe extends over many months (not something we usually do...preferring shorter timeframes) and I need to know more about how this isn't subsidizing development that will support the commercial efforts of transmute. That is the red line for grants. If a commercial enterprise has the work on their roadmap to support their offering's sales or adoption, then they should fund the work. If the work doesn't rise to the level of prioritization for them to fund it, then one must ask if we are propping something up that deserves to remain on the backlog.
acarnagey
commented
2 years ago @humbitious The proposed elements in this proposal are currently not part of our core roadmap. Transmute has a demonstrated history of contributing to the open source community at DIF, W3C and at Baseline. The work proposed has strong synergies with work underway at DIF and W3C with VCs + DIDs and digital assets (e.g., NFTs) and Wallets.
Sidetree.js and verifiable-data (the proposed foundation for delivering the scope of work under this RFP) today is not our core commercial product. It is part of our open-source contribution.
In case Transmute is awarded the grant, our team will be happy to work with the Baseline team to reduce the total delivery time to ~4-6 months. This work will run in parallel to our ongoing efforts for our core commercial product.
Transmute's Element Sidetree protocol allows for anyone to create their own node to create, update, and resolve DID's. By implementing wallet features directly into the Element Sidetree node, we can allow for the users of those nodes to take advantage of the Public Key Infrastructure that Element provides to issue Verifiable Credentials with the DID's, and generate Presentations. By extension, since DID's are effectively a form of key management, we can provide tools for managing these keys, and the digital assets that they control on the Blockchain. We can provide storage and backups for wallet keys, as well as NFT's. By providing wallet tools that are integrated with a deployed Sidetree node, we believe that it will provide value to anyone who sets up and uses a node. And will allow for more users to integrate the Baseline Protocol into their business flow by having trusted Open Source projects that they can deploy, test, and connect to.
samratkishor
commented
2 years ago Questions:
"This implementation allows for the same mnemonic for multiple keys. This behavior is discouraged in NIST-800-57."
Can we address this one? Since we aim for enterprise adoption, we should at least meet NIST requirements.
"The downside to a client-side wallet is the problem with data redundancy. The data only exists in the client’s persistent browser storage. So the owner of the wallet is solely responsible for backing up and controlling their own data."
Can we solve this with enabling third-party cloud backups like what WhatsApp or Signal offers?
OR13
commented
2 years ago @samratkishor Can't really address that, since BIP39 and BIP44 are as they are... however, you can use them in a 1 time fashion, which essentially destroys their utility.
OR13
commented
2 years ago We're withdrawing this application.
However anyone is welcome to use any of the open source stuff that supports DIDs / VCs / NFTs here:
https://github.com/OR13/didme.me
Grant Title
Element Wallet
Details on Grant Work
What we are going to deliver
The Baseline request for proposal describes two main criteria to be met. The first criteria being a client-side non-custodial wallet implementation. And the second is a wallet SDK which consists of a REST interface for interacting with a server.
We believe that to meet the criteria, the most effective solution is to continue off the work of the previous Sidetree V1.0.0 implementation of the Element Sidetree node.
We will fork the baseline repository and add an example folder ‘element-wallet’ which calls an Element Sidetree node API to create the did:elem, also we will use a universal wallet implementation to carry out wallet function requirements and expose an API for these wallet functions that are documented in swagger.
By doing this we can create a non-custodial solution to manage keys with tools provided by the client side browser in the baseline example. DID’s can be created and managed with these keys. By effectively managing DID’s and keys in a client-side wallet implementation, we can build off the Public Key Infrastructure that Element provides and build tools for issuing Verifiable Credentials and preparing presentations.
We can further extend the universal wallet implementation functionality of the client-side tools by providing additional plugins with Web3 for sending and receiving cryptographic assets, managing Non-Fungible Tokens, and sending messages with BRI’s.
Once the work is completed the Transmute team will also provide the following:
How we are going to deliver
The primary deliverable for this grant is the client-side wallet implementation. The functionality of that wallet can be copied into a server-side REST API. Thus the first deliverable will be the client-side implementation of the wallet functionality. The second deliverable will be the server-side implementation of the wallet SDK and documentation.
How it checks off their requirements
The client-side wallet implementation will have a page to create keys with a mnemonic phrase and hdpath. This should satisfy the condition of being BIP39 and BIP 44 compliant. When creating a key, the user will have the option to choose from Secp256k1 and Ed25519 which should satisfy the condition for supporting common elliptic curves for digital signature generation.
Digital assets on Distributed Ledger Technology or Consensus Controlled State Machines are controlled by demonstrating control of the private key for a specific hash. Thus we can demonstrate ownership of prototype tokens (Bitcoin), fungible token (Ethereum), and non-fungible tokens (Ethereum based smart contracts). These assets can be managed by the private keys stored in the wallet, which should satisfy the condition for sending, receiving, and visually representing in a User Interface 1 protocol token, d. fungible token, and 1 non-fungible token for at least two public blockchains.
Furthermore, we can use the hosted node instance to create Element based DID’s. The keys stored in the wallet will allow us to update and deactivate the DID, fulfilling the condition of DID creation and management for DID Element.
After effectively managing DID’s, those identifiers can be used by the client-side wallet to issue and verify Verifiable Credentials, as well as generate presentations for DID’s hosted by the Element Public Key Infrastructure.
The above conditions should fulfill the requirements of the client-side wallet implementation of the compliant with the W3C Universal Wallet specification. These updates can be sent as a Pull Request to fulfill the requirements of the first task outlined in the Request for Proposal description.
We will have an integration test where we implement @baseline-protocol/messaging to send a test message locally.
Once these requirements are completed on the client-side, we can clone the functionality of the client into Wallet SDK, which acts over a REST interface. The included functionality is as defined in the list below.
Wallet SDK:
This functionality of the client-side functionality available over REST interface along with the endpoints documented and tested should fulfill the requirements of the second task outlined in the Request for Proposal.
Motivation and Overview
Motivation
The motivation for this proposal is to continue on the work of the previous grant, which included creating a Sidetree v1.0 Element node. In this next version of the grant, we want to build on the Public Key Infrastructure that was implemented with Element, and add client-side wallet implementation for managing keys, and by extension the assets that those keys control.
Effectively a DID is a method for establishing a public key by signing a proof. And these proofs are hosted on ledgers that can be recognized by anyone, not just a select number of individuals within a walled-garden. We want to allow for more users to make use of the Baseline Protocol by providing available tools and examples for connecting to Public Key Infrastructure that Element provides. And by extension be able to issue Verifiable Credentials which are able to leverage the Public Key infrastructure that did:elem’s provides.
By extension, this also means that we want businesses and organizations to have control over their own keys. Which means providing tools for importing and managing their own key material and providing a client-side wallet implementation to allow them to maintain control over their own Verifiable Credentials, DID’s, NFT’s, and Digital Tokens.
Overview
Decentralized Identifiers (DID) is an emerging standard from the W3C that describes self-sovereign identifiers that allow anyone to make cryptographically proven statements in a trust-less manner by publishing public keys on a ledger.
DIF community members including Transmute, Microsoft, and others have developed Sidetree. Sidetree is a layer 2 protocol designed for scaling CRUD operations on DIDs on top of any ledgers.
Element is the most popular Sidetree-based DID Method on Ethereum and was developed primarily by Transmute with support from ConsenSys and other DIF members. Updating Element to the latest version of Sidetree V1.0 to maintain version parity allows for the continued conversion of ION users (Microsoft’s Sidetree implementation on Bitcoin) and the ability to apply existing software tooling and expertise directly to scalable DIDs on Ethereum.
The Universal Wallet is a W3C draft which defines a standard for storing different types of digital assets within a single interface. The purpose is to provide a modular implementation of a wallet type that can be updated and adapted to allow users to store their own digital assets without vendor lock-in.
Verifiable Credential Is a data model for conveying claims made by an issuer about a subject.
Verifiable Presentation Is data derived from one or more verifiable credentials, issued by one or more issuers, that is shared with a specific verifier.
Value to the Baseline Protocol
The value provided to the Baseline Protocol is to allow for adoption. The Element Sidetree protocol allows for anyone to create their own node to create, update, and resolve DID’s. By implementing wallet features directly into the Element Sidetree node, we can allow for the users of those nodes to take advantage of the Public Key Infrastructure that Element provides to issue Verifiable Credentials with the DID’s, and generate Presentations.
By extension, since DID’s are effectively a form of key management, we can provide tools for managing these keys, and the digital assets that they control on the Blockchain. We can provide storage and backups for wallet keys, as well as non-fungible tokens.
By providing wallet tools that are integrated with a deployed Sidetree node, we believe that it will provide value to anyone who sets up and uses a node. And will allow for more users to integrate the Baseline Protocol into their business flow by having trusted Open Source projects that they can deploy, test, and connect to.
By having an example of universal wallet with support for issuing vc’s and creating did’s on two public blockchains baseline has more examples for their standards and more companies can adopt these standards easier and faster also making baseline more reputable.
Downsides / Execution Risks / Limitations
Downsides
This implementation allows for the same mnemonic for multiple keys. This behavior is discouraged in NIST-800-57.
The downside to a client-side wallet is the problem with data redundancy. The data only exists in the client’s persistent browser storage. So the owner of the wallet is solely responsible for backing up and controlling their own data.
Execution Risks
Updating Element comes with limited execution risk that is inherent to almost any software development project: Unforeseen development effort that would increase scope, push deadlines, or both.
These can be mitigated by adhering to traditional agile development rituals and open communication between the development team and stakeholders.
Limitations
Securing digital assets and tokens to test with. In this proposal we will be using the Bitcoin and Ethereum blockchains. These assets up to including the mainnets will be required to acquire tokens and test repeatedly for each one of the environments.
Persistent storage for Progressive Web Applications. The LocalStorage API in the browser has a limit of 5MB. This limit will be more than enough for storing mnemonics, public/private keys and DIDs. Depending on the size of Verifiable Credentials and other Digital Assets being stored in the wallet, use of IndexedDB might be required to take advantage of the additional storage quota.
Universal Wallet is an emerging standard from the W3C that describes a portable, extensible, JSON-LD wallet, supporting digital currencies and credentials. This is a new and experimental wallet implementation that would require plugin development and testing.
Deliverables / Schedule / Milestones
The described tasks for an open-source non-custodial wallet implementation falls into two major categories. The first being the front-end client-side deliverables for the first task. And the second being the Wallet SDK deliverables for the second task.
In this case the first deliverable is arguably much more labor intensive. As it requires both creating a user interface and the underlying functionality required to fulfill the requirements. The second deliverable is taking the results of the first deliverable, and expositing the functionality over REST interface and documenting.
As such the timeframe for the first deliverable is outlined as 4-5 months, where-as the second deliverable is outlined as 2-3 months. Details for the execution and the criteria for each deliverable is described in the tables below.
Milestone 1 - (4-5 months)
Milestone 2 - (2-3 months)
Budget and Justification
To date, Transmute has committed a tremendous amount of resources to the development of the Sidetree Protocol and Sidetree Element. As a major contributor to each of these implementations, we have a vested interest in seeing that they stay in parity.
Transmute requests a total budget of $30,000 to complete the work needed to update the wallet functionality of the Element Sidetree node User Interface and server-side wallet calls.
The funding provided would allow us to elevate the priority and timeline for updating the Element implementation of Sidetree. These updates will mature the technology so it's easier to use and can support enterprise scale. This translates to accelerated adoption and an expanded pool of contributors for Element and Ethereum. Below is a breakdown of the budget by milestone and month. We estimate milestone 1 will take four to five months. We estimate milestone 2 will take two to three months. We expect Milestone 1 will require the most development work.
Applicant Background
Transmute is in various stages of implementation with customers across multiple industry verticals including: Mobility, Financial Services, Identity Management, Government and Supply Chain Logistics. Two notable examples of this work are Transmute’s proof-of-concept work with GS1 (US, Canada, & Global) where we successfully demonstrated use of verifiable credentials for product-related claims and our ongoing work to streamline origin tracking and enhance global shipment security with the Department of Homeland Security Silicon Valley Innovation Program and U.S. Customs and Border Protection.
Transmute has a reputation for building and leveraging open standards in our products, and we hold several leading contributor roles in the W3C and the Decentralized Identity Foundation (DIF) communities.
Orie Steele, CTO and Co-Founder at Transmute, has a MS in Computer Science and BS in Cyber Security from Stevens Institute of Technology. Orie has managed security concerns for startups and publicly traded companies ranging from Host Based Intrusion Detection, Automated Scanning and Vulnerability Assessment, Logging Aggregation and Alerting, Policies Procedures and Documentation for HIPAA compliance, Front End Security Architecture, API Security Architecture, and Applied Cryptography (Patient IO, sold to AthenaHealth). He has built secure web applications in Finance, Energy, and Healthcare.
Adam Carnagey, Senior Software Engineer at Transmute, has a BS in Computer Science from Texas A&M University. Adam has experience building fullstack SaaS solutions for both the B2B and B2C sectors. He has worked on Web and Mobile development, as well as back-end systems for data-rich applications at a range of companies from startups to large organizations in verticals such as: capital markets, ecommerce, medical, logistics, construction, blockchain, and cloud services.
Ben Collins (better known as ‘Kion’) is the creator of DashGL.com, a site which provides tutorials for writing simple games for Linux in C using OpenGL and the GTK toolkit, and also supports a simple-as-possible 3D file format with plugin support for various 3D editors and engines. Ben enjoys reverse engineering proprietary 3d file formats from the 5th and 6th generation of computer consoles. Ben has experience with Full Stack Development, and deploying applications in Linux environments.
Isaac Byrne, Software Engineer at Transmute, is a self-taught developer with a BS in Business Administration from Johnson & Wales University. Isaac has experience building full-stack solutions for both small business and large enterprises including a Fortune 500 pharmaceutical company and a Global 2000 Industrial Automation company.
Community Grant Agreement
I understand and agree to the 'Process for Approved Grants' outlined here