### stuff

- introduce hosts
- why did methods
- intros + bios + welcome to the show

#### character **(Mircea)**
- **did:ethr, what is it?**
A DID that initially resolves to a self-referencing and self-attesting DID document, but that supports document updates and versioning based on an ethereum smart-contract registry.
Sort-of like did:key but with key rotation possible.
You can create did:ethr without transaction, making every eth account and every Secp256k1 public key a possible did:ethr

- **lifecycle**
CRUD, creating is free and immediate (and requires no registration), DID resolution is done by reading events from erc1056, updating and deleting costs some ETH, updating is sending tx to ethereum, deleting by setting controller to 0.

- **a bit of technical things**
ERC1056 explainer, how it works? meta-transaction?
- ERC1056 a smart-contract registry for attributes posted by ethereum accounts about themselves. These accounts are the default controllers of their attributes, but this control can also be rotated to other accounts.
- transaction costs can be decoupled from the actual signer by a meta-transaction mechanism.

- real life stories, why was it invented, what problems it might solve, why is it a good method for my use case

for our uport mobile app, used for logging in and every use case that required signing, also for issuance and presentation of verifiable credentials.

we had experimented with other DID method designs, e.g., did:uport (now deprecated), did:eth (never was registered but didn't support update), and with did:ethr, you got the best of both, creation is free and updates possible if required.

- how did you get involved? **(Mircea, Oliver)**

we joined uport because excited about SSI, breaking up silos, no need for central parties, better privacy.

did:ethr was a big part of uport and we kept working on it as Veramo (ConsenSys Mesh) since it makes a lot of sense for us.

- who else is involved

pelle, oed were the original authors but we are now mainaining it and continuing to improve it.

### conflicts
- challenging when dev, technical, political

early DID spec was very different from the current proposed W3C recommendation. so, the DID spec has changed a lot and we had to incorporate those changes.

this meant also a lot of interop issues during that developement process. for example, have been using publicKeyHex that were deprecated by the DID WG in the final speciciation.

other challenges: update is required for service endpoints, and for propoer encryption keys.

Why not? since you shouldn't do ECDH-ES with K-256 keys since if you choose the points on the curve not wisely, your private key could get comprosied. DISCLAIMER: we are not cryptographers.

we are very privacy-aware and consensys has also worked with the EU Commission on GDPR reports.

political challenges were mostly related to other initiatives, less-privacy preserving ones, e.g., erc725, which in the early days wanted to store claims about the user on the blockchain.

- clarifying things from the spec, erc1056, delegate, challengegins, good solution why

### resolution

- ERC 1056
- Transaction costs

since, did:ethr supports multiple networks, tx costs might differ. costs only happen if update, deletion.

we cannot really provide estimates, since the gas costs depend on the price of gas today and the size of the changes people make to their DID docs.

eip1559 might also change the price of gas, so we assume it might become cheaper on mainnet. Just as an example, earlier today (before EIP1559) someone spent 51k gas for an update, around 4$ today.

posting delegate is cheaper than posting an RSA key.

we do also support sidechains, like mattic/polygon/RSK where cost is less problematic.

on each of those networks, they represent different DIDs, since erc1056 is a different instance and lives on those networks.

- updates of ERC1056

no need for update until recently,
now some ppl are asking for eip1271 contract signatures, it allows the contract to some eth addresses that are externally owned accounts

- governance of ERC1056 (**Oliver**)

changes to erc1056 requires changes to the did:ethr spec, since the contract address is part of the spec. the spec itself is goverend through DIF and the spec can be improved through openening github tickets until consensus was reached.

for example many of the recent changes were related to making the spec DID Core compliant. other things that have been added is the support for different key representations.

current deployment of erc1056 cannot be updated. every new deployment would be totally independent which likely means that it will be a new DID method.

The Ethereum protocol is improved through the EIP process and miners would eventually need to adopt those changes.

- EIP 1559

shouldn't influence too much, changes transaction fields (tip) only for the underlying web3 provider level.

should be backwards compatible.

- Delegation capabilities

delegates are just new entries in the respective authentication section. they are not allowed to make updates to the controller (owner of the DID).

delegates are typically bound to some expirationtime.

also representable onchain.

- DID Document for a public key and/or for an ethereum address
- “Identity” in the spec

This is going to be changed, we are well aware of the distinction that was made by w3c as part of the discussion in the w3c vc/did wg for exxample.

- History

uport was founded 6(???) years ago. we were one of the early adopters of DIDs. did:uport, erc725, did:nacl as precursor to did:key, did:muport

- What we were solving when it was developed
- we did some back of the napkin calculations and came up short if everybody on the planet suddenly wanted to use did:uport. We needed a more scalable solution for uPort.
- since most uPort users were not updating their DID docs, it made sense to optimize for the DID creation which should be free and self-attesting (to avoid the need for registration).

- projects/implementations (**Oliver**)
- the implementation closest to the current spec is the typescript implementation that we maintain under DIF. We also created a Kotlin implementation that currently conforms to a slightly older spec, but contributions are welcome! (https://github.com/uport-project/kotlin-did-jwt)
- traction-wise, before we solely focused on the Veramo open source framework, we had supported or seen a number of POC/Pilot projects built on uport. the canton of zug (small city in switzerland) used it for their citzens, we did a POC with GLEIF to provide VCs to individuals acting on the business capacity, and with Onfido where we worked on a reusable KYC/user onboarding project in the financial sector as part of the FCA sandbox in the UK.

- around 450 projects that have a dependency on did:ethr. we don't know most of them but we can see activity on ERC1056.

- what is next
- in the resolver
- supporting multiple key types and verification relationships, as well as batch updates.
- more expressive service entry updates
- supporting initial-values
- possibly more focus on layer 2
- updates possible if we update erc1056 (possible on some other EVM blockchains)
- multiple types of initial keys
- contract signatures using EIP1271

- where do you want to see it in the future
- it would be nice if this DID method is one that survives the requirements of future projects and the decentralization landscape.

- implementatoins, where is it used now (**Oliver**)
- the implementation closest to the current spec is the typescript implementation that we maintain under DIF. We also created a Kotlin implementation that currently conforms to a slightly older spec, but contributions are welcome! (https://github.com/uport-project/kotlin-did-jwt)

- traction-wise, before we solely focused on the Veramo open source framework, we had supported or seen a number of POC/Pilot projects built on uport. the canton of zug (small city in switzerland) used it for their citzens, we did a POC with GLEIF to provide VCs to individuals acting on the business capacity, and with Onfido where we worked on a reusable KYC/user onboarding project in the financial sector as part of the FCA sandbox in the UK.

- around 450 projects that have a dependency on did:ethr. we don't know most of them but we can see activity on ERC1056.

### stuff we want to share
IS there anything else we want to particularly share with did:ethr?
announcements at the end of the stuff is possible
- project
- where is it used
- ...
-
urls to checkout (sandbox)
- did:ethr spec and resolver in DIF
- veramo.io is an implementation of did:ethr
- kotlin-did-jwt for kotlin implementation