15:51:26 <RRSAgent> RRSAgent has joined #did
15:51:26 <RRSAgent> logging to https://www.w3.org/2020/01/14-did-irc
15:51:29 <Zakim> RRSAgent, make logs Public
15:51:29 <Zakim> please title this meeting ("meeting: ..."), ivan
15:51:43 <ivan> Meeting: DID Working Group Telco
15:51:43 <ivan> Chair: burn
15:51:43 <ivan> Date: 2020-01-14
15:51:43 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2020Jan/0005.html
15:51:43 <ivan> ivan has changed the topic to: Meeting Agenda 2020-01-14: https://lists.w3.org/Archives/Public/public-did-wg/2020Jan/0005.html
15:51:44 <ivan> Regrets+ phila, dezell, justin
15:52:34 <hadleybeeman> hadleybeeman has joined #did
15:55:18 <ivan> present+
15:56:29 <rhiaro> present+
15:59:14 <jricher> jricher has joined #did
15:59:27 <Irene__Jolocom_> Irene__Jolocom_ has joined #did
15:59:32 <Eugeniu_Jolocom> Eugeniu_Jolocom has joined #did
15:59:50 <Irene__Jolocom_> present+
15:59:53 <chriswinc> present+
16:00:02 <tzviya> present+
16:00:09 <JoeAndrieu> JoeAndrieu has joined #did
16:00:22 <gannan> gannan has joined #did
16:00:32 <JoeAndrieu> present+
16:00:40 <mike-lodder> mike-lodder has joined #did
16:01:19 <deiu> present+
16:01:41 <gannan> present+
16:01:42 <Eugeniu_Jolocom> Eugeniu_Jolocom has joined #did
16:01:43 <dlongley> present+
16:01:45 <markus_sabadello> markus_sabadello has joined #did
16:02:05 <brent> brent has joined #did
16:02:09 <markus_sabadello> present+
16:02:10 <Irene__Jolocom_> q: how does one become a scribe (eventually)?
16:02:13 <mike-lodder> present+
16:02:19 <Eugeniu_Jolocom> present+
16:02:26 <wayne> wayne has joined #did
16:02:30 <wayne> o/
16:02:38 <Irene__Jolocom_> :-)
16:02:48 <Irene__Jolocom_> I will shore up my courage for next week. :+1:
16:02:49 <joel> joel has joined #did
16:02:55 <joel> present+
16:03:02 <brent> present+
16:03:04 <ivan> present+ Irene__Jolocom_
16:03:27 <Tom_S__USAA_> Tom_S__USAA_ has joined #did
16:03:34 <dbuc> dbuc has joined #did
16:03:39 <Tom_S__USAA_> present+
16:03:47 <wayne> present+
16:04:03 <oliver> oliver has joined #did
16:04:06 <oliver> present+ oliver_terbu
16:04:11 <jricher> present+
16:04:29 <brent> scribe+ dbuc
16:04:30 <dmitriz> dmitriz has joined #did
16:04:35 <dmitriz> present+
16:04:42 <dbuc> dbuc present+
16:04:53 <dbuc> present+
16:05:14 <manu> present+
16:05:20 <jonathan_holt> jonathan_holt has joined #did
16:05:51 <drummond> drummond has joined #did
16:05:59 <drummond> present+
16:06:05 <Orie> Orie has joined #did
16:06:06 <Orie> present+
16:06:11 <agropper> agropper has joined #did
16:06:14 <TallTed> present+
16:06:18 <ivan> present+ andrei
16:06:22 <agropper> present+
16:07:15 <selfissued> selfissued has joined #did
16:07:18 <selfissued> present+
16:07:33 <manu> Orie: Hi Orie Steele, CTO and Cofounder of Transmute. Our focus is on applying DIDs and VCs to raw materials, imports, and supply chain logistics.
16:07:35 <manu> scribe+
16:07:49 <IdentityWoman> IdentityWoman has joined #did
16:07:51 <IdentityWoman> present+
16:07:55 <ken> ken has joined #did
16:08:01 <manu> @@@: Hi, developer with Jolocom, implementing a DID Method, also DIF member, very happy to see everyone here.
16:08:15 <ken> present+
16:08:26 <manu> Wayne: 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.
16:08:29 <dlongley> s/@@@/Eugeniu_Jolocom/
16:08:35 <manu> s/@@@/Eugeniu/
16:08:54 <SamSmith> SamSmith has joined #did
16:08:58 <SamSmith> q
16:09:13 <ivan> present+ SamSmith
16:09:15 <manu> brent: 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.
16:09:16 <brent> q?
16:10:17 <manu> Topic: Security and Privacy of DIDs
16:10:40 <dbuc> We just start scribing for content, right?
16:11:27 <dbuc> ok, was just trying to understand if I had to scribe reintroductions and that stuff that isn't real content
16:11:35 <manu> s/ok, was just trying to understand if I had to scribe reintroductions and that stuff that isn't real content//
16:12:28 <manu> i/Orie: Hi Orie Steele/Topic: Introductions/
16:12:36 <manu> brent: How would you like to go through the slides?
16:12:47 <manu> Sam: I'd like to just go through the slides, then answer questions after.
16:12:54 <dlongley> scribe+ dbuc
16:13:12 <dbuc> Scribe dbuc, Daniel Buchner
16:13:32 <dbuc> SamSmith: in late 90s there was work on self-certifying URLs, they look like DIDs
16:13:47 <ChristopherA> present+
16:14:35 <dbuc> SamSmith: 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
16:14:58 <dbuc> SamSmith: the core of this is establishing control over an identifier
16:15:29 <dbuc> SamSmith: in both cases the control authority is a pub/priv key pair, the controller of which can make signed statements linked to it
16:16:08 <dbuc> SamSmith: From a security perspective, we're creating a DID method infrastructure to replace the CA infrastructure
16:16:41 <dbuc> SamSmith: current system is hierarchical and you must trust the various entities involved in that stack
16:17:22 <dbuc> SamSmith: DID infra = multiple method providers, multiple implementations, and less trust required, because most are backed by decentralized systems
16:17:57 <dbuc> SamSmith: we must trust code and delivery infrastructure, and there is more complexity
16:18:51 <dbuc> SamSmith: different vulnerabilities involved in DID infra. TEEs and other components can help verify code integrity, for example
16:19:34 <dbuc> SamSmith: Everything in DID land must be end-verifiable - end user can verify if they optionally desire to do so
16:20:24 <mike-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
16:20:36 <dbuc> SamSmith: Pinning, notaries, DNS Sec all are inadequate
16:21:15 <dbuc> SamSmith: Cert Transparency is a public, append-only event log with consistency and inclusion proofs
16:22:00 <dbuc> SamSmith: the system is still based on a trusted hierarchy, but the system is observable and transparent for the purposes of verifiability
16:22:00 <Orie> Classic paper on Trust: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf
16:23:02 <dbuc> SamSmith: Both Sidetree & KERI use end-verifiable logs for DIDs
16:23:19 <manu> I'm lost there -- end-verifiable logs for what?
16:23:31 <IdentityWoman> This is the Trillian project - https://github.com/google/trillian for the merkle trees Sam is talking about.
16:23:48 <dbuc> SamSmith: Pub/priv keys are the base, CSPRNG + collision resistant seed
16:23:52 <Orie> manu, key control events for the did.
16:23:54 <IdentityWoman> Ben Laurie who used to come to IIW has worked  on this for google.
16:24:28 <Orie> The KERI Paper: https://arxiv.org/abs/1907.02143
16:24:30 <manu> I'm lost - isn't this just "How to create a good private key?"
16:24:37 <dbuc> SamSmith: this approach ensures that the key controller is the only one who can make verifiable assertions
16:25:01 <mike-lodder> manu - No this is stating the strength of the private key is based on entropy and random data
16:25:03 <jonathan_holt> present+ jonathan_holt
16:25:10 <mike-lodder> that's why its decentralized
16:25:22 <manu> ... but isn't that just "use a good random number generator"?
16:25:24 <dbuc> SamSmith: we can extend this to content addressable identifiers
16:25:55 <mike-lodder> Right but the security of the system depends on a "good random number generator"
16:26:03 <dbuc> SamSmith: main sec concepts are primary/secondary roots of trust, with end-verifiabiltiy
16:26:26 <manu> q+ I'm completely lost
16:26:30 <manu> q+ to say I'm completely lost
16:26:39 <dbuc> SamSmith: End-verifiabilty > Ambient Verifiability
16:27:21 <dbuc> SamSmith: Exploits are contained with duplicity detection
16:27:59 <manu> q+ to note that we may need to state the problem statements?
16:28:17 <dbuc> SamSmith: Loci-of-Control: who controls what
16:28:53 <dbuc> SamSmith: the controller of the current private key is/should be the only entity that can make verifiable statements
16:29:23 <dbuc> SamSmith: many types of statements can be made - xfer of control, delegation, revocation, authorization, etc.
16:29:32 <manu> q-
16:30:20 <dbuc> SamSmith: Identifier features: ephemeral vs persistent
16:30:46 <mike-lodder> TL;DR - DIDs are about trust and control
16:30:49 <mike-lodder> I think
16:31:02 <dlongley> i think this is good material for evaluating DID methods
16:31:20 <dlongley> but much of it is not specific to interop on the data model
16:31:22 <dbuc> SamSmith: How to establish control: inception statement includes info about the suite and other metadata about the created DID and PKI state
16:31:43 <dlongley> so good for the rubric doc we want to produce
16:32:29 <dbuc> SamSmith: transfer statements change the state of the identifier and its current PKI metadata
16:33:15 <Orie> 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.
16:33:20 <dlongley> q+ to say this entire group is about achieving interop at the authorization layer, not the establishment layer, which is left to DID methods
16:33:23 <dbuc> SamSmith: I believe we are spending too much time doing interop at the authorization layer, and should spend more at the establishment layer
16:33:27 <markus_sabadello> q+
16:33:45 <brent> ack dlongley
16:33:45 <Zakim> dlongley, you wanted to say this entire group is about achieving interop at the authorization layer, not the establishment layer, which is left to DID methods
16:34:21 <dbuc> dlongley: thank you for the info Sam, this could be useful for the rubric on how to create/architect DID methods, etc.
16:34:47 <Irene__Jolocom_> @Ivan: Eugeniu of Jolocom is called Eugeniu Rusu
16:34:49 <dbuc> dlongley: this may be out of scope, because many of these aspects are left to DID Methods
16:35:28 <dbuc> SamSmith: understood, but might want to think about driving interop at the DID establishment/state change layer
16:35:51 <brent> q?
16:36:04 <dbuc> SamSmith: a failure of DID Methods that do a poor job on these things, may reflect badly on the DID spec and ecosystem
16:36:19 <dlongley> q+ to say there's a compromise where we explicitly we will not work on that that happened to get this group going that Sam may not be awar eof
16:36:29 <brent> ack markus_sabadello
16:36:48 <kimhd> kimhd has joined #did
16:37:02 <dbuc> markus_sabadello: also want to mention rubric work. I am convinced the work of self-certifying DIDs should be recommended as a best practice
16:37:38 <dbuc> markus_sabadello: what should we do with this? Put some language in the spec? Add to the rubric as a guidance?
16:38:02 <brent> q?
16:38:29 <dbuc> markus_sabadello: some methods clearly don't follow these practices, like DID Web, BTCR, etc.
16:39:24 <dbuc> SamSmith: one consideration is there are two method possibilities: methods for establishing authority and a method for transfer/state change
16:40:43 <dbuc> SamSmith: 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
16:41:15 <dbuc> SamSmith: we will have a system with lots of flexibility, but a more difficult security challenge
16:41:30 <dbuc> q+
16:41:53 <brent> ack dlongley
16:41:53 <Zakim> dlongley, you wanted to say there's a compromise where we explicitly we will not work on that that happened to get this group going that Sam may not be awar eof
16:41:54 <ivan> scribe+ manu
16:42:12 <dbuc> SamSmith: we should focus more on establishment methods to achieve more homogeneity across DID Methods
16:42:31 <kimhd> q+
16:42:59 <dbuc> dlongley: we're focused on data model, which is separate from the things you mentioned
16:43:39 <dbuc> dlongley: suggest putting these guidances in the rubric\
16:43:48 <wayne> q+
16:43:51 <markus_sabadello> q+
16:44:43 <dbuc> SamSmith: creating a library is a good idea, would simplify implementations
16:44:48 <brent> ack dbuc
16:45:32 <manu> dbuc: 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.
16:45:52 <manu> dbuc: 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.
16:45:53 <brent> ack kimhd
16:46:14 <dbuc> kimhd: don't like some of the less strict approaches
16:46:32 <dbuc> kimhd: at minimum this should be in the spec in the sec section
16:46:48 <brent> +1 to adding this content to the security considerations section of the core spec
16:46:53 <drummond> +1 to Sam's key points being included in the Security Considerations part of the spec.
16:46:56 <brent> q?
16:46:59 <manu> +1 to adding this content to Security Considerations.
16:47:05 <dlongley> +1 to adding something to security considerations to mention DID method implementations matter and how they do, etc.
16:47:05 <Orie> See https://www.w3.org/TR/did-core/#security-considerations
16:47:05 <manu> (or some variant of it)
16:47:11 <dbuc> kimhd: it will help people like me who will use this. Without it, the tech may come off as too immature
16:47:12 <brent> ack wayne
16:47:37 <drummond> 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.
16:47:47 <drummond> q?
16:48:07 <dbuc> wayne: 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
16:48:13 <drummond> +1 to including this in the Security section of the Rubrics document.
16:49:22 <oliver> +1 markus (ethereumaddress as one example)
16:49:31 <dlongley> 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
16:49:34 <jonathan_holt> q+
16:49:37 <dbuc> 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
16:49:42 <dlongley> and specific to DID methods -- though they could share tech.
16:49:54 <brent> ack markus_sabadello
16:49:57 <brent> ack jonathan_holt
16:50:47 <dbuc> jonathan_holt: we should separate DID Methods from DID vendors
16:50:58 <dlongley> q+ to say i think Sam Smith is talking about getting an authoritative DID Document which happens before doing authentication/authorization at the application level, which is where the DID Document data model comes in ... Sam is covering the resolution process
16:51:06 <brent> ack dlongley
16:51:06 <Zakim> dlongley, you wanted to say i think Sam Smith is talking about getting an authoritative DID Document which happens before doing authentication/authorization at the application
16:51:09 <Zakim> ... level, which is where the DID Document data model comes in ... Sam is covering the resolution process
16:51:09 <brent> q+
16:51:26 <dbuc> dlongley: I think Sam is talking about getting an authoritative DID Document
16:51:58 <dbuc> dlongley: seems to be talking about generation of the DID and resolution of its changes
16:52:12 <brent> ack brent
16:52:33 <dbuc> Zakim: would like proposals or ideas of concrete ways we can move forward with this information
16:53:01 <Orie> q+
16:53:07 <brent> ack Orie
16:53:44 <wayne> q+
16:53:46 <drummond> q+
16:54:31 <dbuc> Orie: 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
16:54:44 <agropper> Where does government input come into the process?
16:55:06 <manu> When the government (or their contractors) send that input :)
16:55:12 <brent> ack wayne
16:55:15 <dbuc> Orie: think it's fine that we detail the different approaches and tradeoffs in the sec section of the spec and rubric
16:55:18 <dbuc> wayne:
16:55:31 <dbuc> wayne: this would help me pick the best DID Methods
16:55:45 <brent> ack drummond
16:57:45 <dbuc> drummond: 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
16:58:02 <kimhd> thanks to Sam for presenting this. Great work. Bye all
16:58:22 <Orie> 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
16:58:56 <dbuc> Zakim: who will raise an issue in the DID Core spec, and who will raise one in the DID rubric repo?
16:58:58 <SamSmith> they will be on my GitHub page  smithsamuelm
16:59:20 <Orie> SamSmith link if you can for notes
16:59:44 <drummond> I will volunteer to explore the Note idea with Sam and anyone else who is interested
16:59:44 <SamSmith> https://github.com/SmithSamuelM/Papers/tree/master/presentations
16:59:51 <dbuc> Zakim: Sam, can you raise those issues?
17:00:04 <dbuc> SamSmith: I will, good sir!
17:00:34 <dlongley> 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
17:01:18 <ivan> rrsagent, draft minutes
17:01:18 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/14-did-minutes.html ivan
17:01:25 <ivan> zakim, end meeting
17:01:25 <Zakim> As of this point the attendees have been ivan, rhiaro, Irene__Jolocom_, chriswinc, tzviya, JoeAndrieu, deiu, gannan, dlongley, markus_sabadello, mike-lodder, Eugeniu_Jolocom, joel,
17:01:29 <Zakim> ... brent, Tom_S__USAA_, wayne, oliver_terbu, jricher, dmitriz, dbuc, manu, drummond, Orie, TallTed, andrei, agropper, selfissued, IdentityWoman, ken, SamSmith, ChristopherA,
17:01:29 <Zakim> ... jonathan_holt
17:01:29 <Zakim> RRSAgent, please draft minutes
17:01:29 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/14-did-minutes.html Zakim
17:01:31 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
17:01:35 <Zakim> Zakim has left #did
17:01:41 <ivan> rrsagent, bye
17:01:41 <RRSAgent> I see no action items