Sidetree on Ethereum “Element

From IIW

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