Understanding and Implementing peer DID’s in 60 min or Less

Understanding & Implementing Peer DIDs in 60 Min or Less

Wednesday 10B

Convener(s): Daniel Hardman

Notes-taker(s): Daniel Hardman

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:

1. Notes from Daniel Hardman:

We reviewed the following slide deck:  https://docs.google.com/presentation/d/1T25zaBt__s3Y0vGJuFrh2yTKw-22IwykN_ONHwbbNo0/edit

Short summary: You can implement peer DID support in your codebase in 60 min or less--maybe in just 5 or 10 min in python or node.js. We talked about the tradeoffs that peer DIDs make, what they're good and bad for, and how their authorization mechanism works.

For more info, please see:

j.mp/peer-dids-group

https://openssi.github.io/peer-did-method-spec

github issues at https://github.com/openssi/peer-did-method-spec

https://github.com/evernym/pypeerdid (ref impl of layers 1 and 2)

*********** *********** ************** *************** ************ **********

2. Notes from Alexander Tam:

slide 1

- most did methods have a relationship between two parties that is mediated by did control

- eg. bob and acme want a pariwise relationship

- acme would have a public did (green), pairwise did: A.did@A:B

- register and update on central source of truth (eg. blockchain, facebook servers)

- bob would have a pariwise did: B.did@B:A

- register and update on central

- acme can resolve B.did@B:A

- problem:

- everyone can resolve that did, can be a security issue

- don't need the public resolution (resolve) for pairwise did

slide 2

- same idea without central source

- bob creates pairwise did and registers and updates it with acme

- acme does the same

- idea simple, but execution can be difficult

- comment

- peer did have different features than public dids

- no discovery

- can have multiple key pairs in a relationship

- eg. bob has many devices all connected with acme

- groups?

- two ways to do groups

- hub and spokes model, talk to hub and hub routes message to correct person

- n-wise model, all members enumerate all other members in the group (direct commuication)

slide 3

- why interesting?

- all listed items in slide

- trade offs

- no discovery

- others

slide 4

- how to create?

- solution is a pull request at the moment

- *stuff on slides*

- identifier of numeric base algo, for backward compatability

- self certifing identifier

- guuid instead?

- no, cause you can't prove the person using is the one it was assigned to

- no proof at beginning at chain of custody

slide 5

- how to share

- *stuff of slides*

slide 6

- 3 layers of support

- layer 1

- be able to recognize a valid did, can do if you understand regex

- trivial

- layer 2

- can accept and give static peer dids (static = can't update)

- few hours

-

- layer 3

- complexity of decentralized protocol for state of updates (key rotation)

- DIDcomm + week

can have a mismatch of different did definitions, or different of static and dynamic did

- just have to communicate that you are using static or dynamic when communicating

-

- comment

- can't have did in diddoc since you generate did after

slide 7

- *stuff on slides*

- open issues

- look at repo on github

comment

- if only static, why need dids

- case 1: flow with normal dids, would be annoying to switch to public key

- case 2: need ability to distribute trust

- eg. need 3 of the 5 keys to do operation, cant do with public key

- didkey vs peer did

- use ssh key in a did context

- missing characteristics that are present in peer did

- daniel has a spreadsheet showing why use peer did

- going through code on first page slides

- line 12 is layer 1

- just a regex line

- line 14 - 17 is the resolver

- line 23 -34, one liner of getting did from doc

- raw bytes, sha52 hash, prepend a byte (multiple codex), base58 encode

- line 76 - end, authorization of identity controller

- reason why you don't just use public key, code is how to do 3/5 keys needed

slide 8

- update peer did's did doc

- delta says

- add this key

- just delete id

- *stuff on slides*

slide 9

- json showing profiles and rules, can make as complex as you want depending on the context

- eg. phone was stolen, what do I do

slide 10

- crdts, same tech that allows multiple people to edit a google doc

- conflict free replicated data types

- look on wiki

- doesn't solve all problems but a lot of them

slide 11

- agent knows pending change but hasn't been endorsed yet, so you can gossip about it before it's true

- eg. need 3/5 keys, first key to endorse is pending

- send all changes along until enough have accumulated to pass

slide 12

- include state in communication so they know if they are out of sync

slide 13

- skipped

slide 14

- more info

- peer did discussion gorup, first link

- last link is peer did implementation in python

- comment

- permission and auth are built into did methods, so no need to put in diddoc

- peer did is a method spec not a protocol

- for exchange use aries protocol

- or roll your own

- spec says how dids look and have certain security properties

- aca py is not yet compliate with spec

- if can't reach bob, on failure what happens?

-

- going through an example of the gossip protocol (not in slides)

- see how gossip works if communication is blocked between certain parties

- state becomes out of sync, however as soon as another party that got the update starts to communicate with the out of sync parties, the in sync party brings all the out of sync parties into sync since state is shared with communication

- ordering is not enforced, making it not a ledger

- did is associated with genesis version only, have to use deltas to get new doc

- public reputation and discovery are reasons for public dids