Transmute Releases Technical Workbenches
Explore the standards-based scalable identifiers and encrypted data storage tools that power Transmute’s product.
Transmute is proud to announce the release of several new technical workbenches as a part of our continued commitment to open-standards development, interoperability, and product transparency. Whenever possible, our team strives to provide interactive proof of functionality along with standards, specifications, and library support.
This new suite of tools is available for developers to experiment with today and includes:
Transmute leverages these workbenches as part of our global trade solutions, where our customers benefit from verifiable data workflows and integrated capabilities. Reach out to our team here to learn more.
Workbench Details
Read on to learn technical details of what is included in each workbench, and follow the links to see how each works for yourself.
Element Testnet Workbench https://staging.element.transmute.industries/workbench
We’ve updated did:elem to support the latest stable version of the Sidetree protocol, and we’ve reimplemented our block explorer from https://element-did.com to support the new Sidetree filesystem and the latest element dids.
We’ve also added universal wallet* support to the element workbench, so you can create a Sidetree did and control it with the same keys you use for did key or any other universal wallet compatible product.
*The universal wallet is also an official work item of the W3C CCG https://github.com/w3c-ccg/universal-wallet-interop-spec.
Data Vault Workbench
https://staging.date-vault.transmute.industries/workbench
We’ve added support for encrypted data vaults to the universal wallet spec, and provide a developer user interface which is similar to a database administration interface which helps DID controllers explore their vaults, documents, and indexes inside encrypted data vaults.
We also published the first vendor interoperability tests in the Secure Data Store working group: https://github.com/decentralized-identity/secure-data-store. These tests help vendors prove they are interoperable.
Having workbenches like these helps Transmute separate standards, libraries, sample implementations, demos into microservices which are independently upgradeable and valuable by themselves as standalone products.
For example, our Sidetree node for Element regularly anchors testnet DID activity, and it’s helpful to be able to explore that activity on our block explorer, even if you didn’t use our node to anchor those events… If you want to dig into the Ethereum related details, we happily link you to https://ropsten.etherscan.io/ for more detailed information about the Ethereum transactions and blocks.
Our encrypted data vault workbench demonstrates the concept of “wallet portability” by showing how wallet content can be encrypted client-side and replicated between clients. This demonstrates the value of encrypted data vaults and the universal wallet interop spec at the same time…. It also helps us prove that encrypted data vaults work with did:key and did:elem.
DID Key Workbench
https://did.key.transmute.industries
We’ve added support for BLS12381, which is used to construct zero-knowledge proofs using https://github.com/w3c-ccg/ldp-bbs2020
We’ve also added support for the “NIST Curves” which are legacy elliptic curves that are supported almost everywhere, including natively in web browsers. Not everyone trusts them, you should review https://safecurves.cr.yp.to/. Nonetheless, we have shown them to be working with DID Key, which opens the door for legacy integration and interoperability.
We use DID Key for testing, and because of its simplicity it’s an ideal starting point for learning about DIDs and VCs.
The DID Key Workbench also has the first [to our knowledge] support for content-type and multiple did document representations. Support for multiple representations in the DID Core Specifications is currently being defined and subject to change. Today, there is a lot of language which describes JSON-LD, and almost no examples of JSON or CBOR. We hope that by showing how did:key can support both JSON and JSON-LD we can help the community figure out the representation sufficient for it to be testable.
