DID Working Group Telco — Minutes

Date: 2020-01-14

Attendees

Present: Ganesh Annan, Pamela Dingle, Ivan Herman, Amy Guy, Eugeniu Rusu, Irene Adamski, Chris Winczewski, Tzviya Siegman, Joe Andrieu, Andrei Sambra, Dave Longley, Markus Sabadello, Michael Lodder, Wayne Chang, joel, Brent Zundel, Daniel Buchner, Tom S., Oliver Terbu, Justin Richer, Dmitri Zagidulin, Manu Sporny, Drummond Reed, Orie Steele, Ted Thibodeau Jr, Adrian Gropper, Michael Jones, Kaliya Young, Kenneth Ebert, Samuel Smith, Christopher Allen, Jonathan Holt, Kim Duffy

Regrets: Phil Archer, David Ezell

Guests:

Chair: Brent Zundel

Scribe(s): Daniel Buchner, Manu Sporny

1. (Re)introductions

Orie Steele: Hi Orie Steele, CTO and Cofounder of Transmute. Our focus is on applying DIDs and VCs to raw materials, imports, and supply chain logistics.

Eugeniu Rusu: Hi, developer with Jolocom, implementing a DID Method, also DIF member, very happy to see everyone here.

Wayne Chang: Hi Wayne Chang, implementer at Consensys, working with low power devices, still need to figure out how to do identity and credentialing at that layer.

Brent Zundel: We have a F2F meeting in two weeks, please come to that. Reach out to Chairs if you don’t have details for that. We have additional meetings in preparation for F2F, first one is today, one hour after the end of this call, right after W3C CCG meeting.

2. Security and Privacy of DIDs

Samuel Smith: Slides are here: https://github.com/SmithSamuelM/Papers/blob/master/presentations/W3C_DID_Security_Concerns.pdf

Brent Zundel: How would you like to go through the slides?

Samuel Smith: I’d like to just go through the slides, then answer questions after.
… in late 90s there was work on self-certifying URLs, they look like DIDs
… was a system that attempted to create a system not based on Certificate Authorities or other centralized entities. Recently there has been work on Cert Transparency, which attempts to fix things in the current CA system
… the core of this is establishing control over an identifier
… in both cases the control authority is a pub/priv key pair, the controller of which can make signed statements linked to it
… From a security perspective, we’re creating a DID method infrastructure to replace the CA infrastructure
… current system is hierarchical and you must trust the various entities involved in that stack
… DID infra = multiple method providers, multiple implementations, and less trust required, because most are backed by decentralized systems
… we must trust code and delivery infrastructure, and there is more complexity
… different vulnerabilities involved in DID infra. TEEs and other components can help verify code integrity, for example
… Everything in DID land must be end-verifiable - end user can verify if they optionally desire to do so

Michael Lodder: Another concern to be aware of is tagging attacks. The remote access you have in the look ups and resolution, the more an attacker can inspect those lookups and tag them which violates privacy

Samuel Smith: Pinning, notaries, DNS Sec all are inadequate
… Cert Transparency is a public, append-only event log with consistency and inclusion proofs
… the system is still based on a trusted hierarchy, but the system is observable and transparent for the purposes of verifiability

Orie Steele: Classic paper on Trust: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf

Samuel Smith: Both Sidetree & KERI use end-verifiable logs for DIDs

Manu Sporny: I’m lost there – end-verifiable logs for what?

Kaliya Young: This is the Trillian project - https://github.com/google/trillian for the merkle trees Sam is talking about.

Samuel Smith: Pub/priv keys are the base, CSPRNG + collision resistant seed

Orie Steele: manu, key control events for the did.

Kaliya Young: Ben Laurie who used to come to IIW has worked on this for google.

Orie Steele: The KERI Paper: https://arxiv.org/abs/1907.02143

Manu Sporny: I’m lost - isn’t this just “How to create a good private key?”

Samuel Smith: this approach ensures that the key controller is the only one who can make verifiable assertions

Michael Lodder: manu - No this is stating the strength of the private key is based on entropy and random data

Michael Lodder: that’s why its decentralized

Samuel Smith: but isn’t that just “use a good random number generator”?
… we can extend this to content addressable identifiers

Michael Lodder: Right but the security of the system depends on a “good random number generator”

Samuel Smith: main sec concepts are primary/secondary roots of trust, with end-verifiability
… End-verifiability > Ambient Verifiability
… Exploits are contained with duplicity detection
… Loci-of-Control: who controls what
… the controller of the current private key is/should be the only entity that can make verifiable statements
… many types of statements can be made - xfer of control, delegation, revocation, authorization, etc.
… Identifier features: ephemeral vs persistent

Michael Lodder: TL;DR - DIDs are about trust and control

Michael Lodder: I think

Dave Longley: i think this is good material for evaluating DID methods

Dave Longley: but much of it is not specific to interop on the data model

Samuel Smith: How to establish control: inception statement includes info about the suite and other metadata about the created DID and PKI state

Dave Longley: so good for the rubric doc we want to produce

Samuel Smith: transfer statements change the state of the identifier and its current PKI metadata

Orie Steele: This is advice for DID Method implementers, it might be matter for the did core spec, to the extent that this advice is either promoted or not through the spec language. I think its helpful shared context for evaluating spec language. It might help with general purpose interop in the future, w.r.t. Sidetree / Peer Dids / KERI.

Samuel Smith: I believe we are spending too much time doing interop at the authorization layer, and should spend more at the establishment layer

Dave Longley: thank you for the info Sam, this could be useful for the rubric on how to create/architect DID methods, etc.
… this may be out of scope, because many of these aspects are left to DID Methods

Samuel Smith: understood, but might want to think about driving interop at the DID establishment/state change layer
… a failure of DID Methods that do a poor job on these things, may reflect badly on the DID spec and ecosystem

Markus Sabadello: also want to mention rubric work. I am convinced the work of self-certifying DIDs should be recommended as a best practice
… what should we do with this? Put some language in the spec? Add to the rubric as a guidance?
… some methods clearly don’t follow these practices, like DID Web, BTCR, etc.

Samuel Smith: one consideration is there are two method possibilities: methods for establishing authority and a method for transfer/state change
… if I am doing a resolver, and each method does their own scheme for these things, I have to do a sec audit for all of them
… we will have a system with lots of flexibility, but a more difficult security challenge
… we should focus more on establishment methods to achieve more homogeneity across DID Methods

Dave Longley: we’re focused on data model, which is separate from the things you mentioned
… suggest putting these guidances in the rubric\

Samuel Smith: creating a library is a good idea, would simplify implementations

Daniel Buchner: Regarding the practicality over how much value you’ll get out of working on these DID Method specific things into core, practically speaking is that the ecosystem will follow a power law curve, there will eventually be 5-6 methods that people will gravitate to over time.
… I don’t know if all of them will follow these best practices, I don’t think we’ll have 50 DID Methods, we’ll have far fewer in the end.

Kim Duffy: don’t like some of the less strict approaches
… at minimum this should be in the spec in the sec section

Brent Zundel: +1 to adding this content to the security considerations section of the core spec

Drummond Reed: +1 to Sam’s key points being included in the Security Considerations part of the spec.

Manu Sporny: +1 to adding this content to Security Considerations.

Dave Longley: +1 to adding something to security considerations to mention DID method implementations matter and how they do, etc.

Orie Steele: See https://www.w3.org/TR/did-core/#security-considerations

Manu Sporny: (or some variant of it)

Kim Duffy: it will help people like me who will use this. Without it, the tech may come off as too immature

Drummond Reed: This issue seems important enough that we may even want to publish a separate Note about it and point to that from the shorter coverage in the Security Considerations section of the DID spec.

Wayne Chang: when we try to bring this to enterprise/biz, we’re going to encounter many situations that fall outside of these more strict approaches/practices

Drummond Reed: +1 to including this in the Security section of the Rubrics document.

Oliver Terbu: +1 markus (ethereumaddress as one example)

Dave Longley: you need an authoritative DID Document before application level authorization/authentication happens – and this is the part I think Sam smith is talking about, which is a resolution level problem

Markus Sabadello: one aspect we overlook: we use a pub/priv key as the basis for control of a DID, but in theory you could have other mechanisms of control over the ID

Dave Longley: and specific to DID methods – though they could share tech.

Jonathan Holt: we should separate DID Methods from DID vendors

Dave Longley: I think Sam is talking about getting an authoritative DID Document
… seems to be talking about generation of the DID and resolution of its changes

Brend Zundel: would like proposals or ideas of concrete ways we can move forward with this information

Orie Steele: I have had conversations with Sam about KERI/Sidetree. What I find attractive about KERI is that it describes, in a shared way, the same thing that DID Methods like Sidetree and Peer DIDs are both doing in common

Adrian Gropper: Where does government input come into the process?

Manu Sporny: When the government (or their contractors) send that input :)

Orie Steele: think it’s fine that we detail the different approaches and tradeoffs in the sec section of the spec and rubric

Wayne Chang:
… this would help me pick the best DID Methods

Drummond Reed: this is great work Sam, and I want to make another suggestion: this topic is deep enough that it should be in the sec section of the spec, and the rubrics doc should have a section, but we should also produce a separate block of content that fully details this at a granular level

Kim Duffy: thanks to Sam for presenting this. Great work. Bye all

Orie Steele: We’ve considered attempting to formalize both sidetree, peer dids, (maybe others) under the keri terminology, but it would require some significant collaboration among did method implementers

zakim: who will raise an issue in the DID Core spec, and who will raise one in the DID rubric repo?

Samuel Smith: they will be on my GitHub page smithsamuelm

Orie Steele: SamSmith link if you can for notes

Drummond Reed: I will volunteer to explore the Note idea with Sam and anyone else who is interested

Samuel Smith: https://github.com/SmithSamuelM/Papers/tree/master/presentations

zakim: Sam, can you raise those issues?

Samuel Smith: I will, good sir!

Dave Longley: this sounds good – i think we may even have an opening to resolve the layering issue – which is that we need another layer before you get an authoritative DID Document where interop between DID methods may be useful