Sidetree on Ethereum “Element
Sidetree On Ethereum “Element”
Thursday 12H
Convener: Karyl Fowler (CEO, Transmute) & Orie Steele (CTO, Transmute)
Notes-taker(s): Margo Johnson
Tags for the session - technology discussed/ideas considered:
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Technology Discussed: Scalable Decentralized Identity & Attestations
Creating DID using Element -- DID:ELEM
Demo of Sidetree Ethereum: https://www.youtube.com/watch?v=KY_dt2tKQxw
Go to element-did.com to try the demo
Contribute! https://github.com/decentralized-identity/element
Went through in the video:
1. Creating and importing an encrypted wallet
2. Creating DID document using both light node and full node methods
3. Batching and creating more than one DID at a time
4. DIDs are created, resolvable in light and full node
5. Updating a DID document in full node, new operation to add service node
6. Multiple service endpoints on DID document
7. Currently supports Create and Update
8. See tests in element implementation for Recover and Delete (will be added to UI later)
Q&A
Is Transmute currently hosting a node?
Yes, Transmute is running a node -- using Infura to host.
Gihhub repo, where is the solidity code?
It should be in the Element lib package in Github repo.
Differences from previous anchoring?
Element is initially being tested for scalable attestations
IoT device, Ad-tech platform… lots of attestations need some form of batching operation.
Currently use Element for anchoring attestation, mixed with ETHR as DID identity method. For example -- a ETHR-DID can issue ELEM-DIDs.
Public attestations?
Default behavior for element is to use IPFS as storage layer, so operations are public
But Element has a pluggable storage mechanism and can select different contracts.
Anchoring to a different contract is an option, could be to a private database
Operations only visible to permissioned users
Clarification about anchoring attestations...
Sidetree method used for anchoring DIDs — not just identities but also attestations
Service section of DID document
Service endpoint says there is anchored credential, if you have right privileges can access and verify information.
What about the sidetone protocol is useful for attestations? Why better than centralized database?
Centralized database can be better in cases - JSON LD signed and registered to DIDs
Sidetree as DID method has build-in CRUD support — can use same set of code for both use cases
Combination of infrastructure
Using mechanics of DID for credentials
Closing notes
Still testing with combination of ETHR-DID and ELEM-DID
Actively using in Transmute ID transmute.industries/transmute-id
Thinking through inter-operability from one method to another
Long run use whichever is most cost-effective, safest for anchoring