06:04:42 <RRSAgent> RRSAgent has joined #did
06:04:42 <RRSAgent> logging to https://www.w3.org/2020/01/29-did-irc
06:04:44 <Zakim> RRSAgent, make logs Public
06:04:46 <Zakim> please title this meeting ("meeting: ..."), ivan
06:05:25 <ivan> Meeting: DID Working Group F2F, 1st day
06:05:35 <ivan> date: 2020-01-29
06:07:39 <manu> RRSAgent, meeting spans midnight
06:09:08 <ivan> Chair: burn, brent
06:10:04 <ivan> Agenda: https://docs.google.com/spreadsheets/d/11haGLiY3AYi8uxIQcfndAixmtXjymNTTFbDQWRYkKrQ/edit#gid=0
06:10:34 <ivan> Meeting slides:  https://docs.google.com/presentation/d/1XI5rrEdBUSYd2tW07GfzOjBkvgKmfeKQyh95Ekl-u8o/edit#slide=id.p
06:17:18 <ivan> Agenda: https://tinyurl.com/didwg-ams2020-agenda
06:17:37 <ivan> Meeting slides: https://tinyurl.com/didwg-ams2020-slides
06:17:48 <ivan> ivan has changed the topic to: F2F Meeting slides: https://tinyurl.com/didwg-ams2020-slides
07:04:38 <yofukami> yofukami has joined #did
07:12:10 <yoshiaki> yoshiaki has joined #did
07:12:40 <yofukami> yofukami has joined #did
07:23:40 <SamSmith> SamSmith has joined #did
07:25:27 <brent> brent has joined #did
07:25:52 <brent> we have a minor webex issue. Webex won't start until 9 this morning.
07:36:59 <burn> burn has joined #did
07:37:09 <ken> ken has joined #did
07:37:20 <tplooker> tplooker has joined #did
07:38:41 <burn> present+
07:39:43 <manu> scribe: manu
07:39:43 <tplooker> present+
07:39:47 <manu> Topic: Welcome
07:39:57 <manu> brent is going over logistics.
07:40:18 <manu> We are in Spaces, Microsoft Schiphol (thank you Microsoft!)
07:40:45 <manu> Dial in information has been sent out to the mailing list.
07:41:37 <manu> brent: We need to get dinner organized tonight. About 20 people raised their hands. Christopher will plan dinner.
07:41:57 <manu> burn: We will get a plan together for dinner by noon-ish.
07:42:30 <manu> brent: IPR Policy - if you are a DID WG member, we look forward to your contributions. If you are observing, please refrain from making substantive contributions.
07:43:11 <manu> Eric: I promise not to be substantive. *laughing*
07:43:34 <manu> burn: You can provide input on requirements, goals, etc... but not how to solve the problem.
07:44:48 <manu> brent: Today's agenda is here -- https://docs.google.com/spreadsheets/d/11haGLiY3AYi8uxIQcfndAixmtXjymNTTFbDQWRYkKrQ/edit#gid=0
07:45:20 <manu> brent: We have introductions, thank you to Microsoft for the space, food, etc.
07:45:40 <manu> brent: We start the day with level setting, security issues, DID and IoT. Then a break.
07:46:12 <manu> brent: We will then talk about encodings and data models. Lunch. Then extensibility, break, then metadata and an open slot at the end of the day.
07:46:29 <manu> brent: we can talk about issues/PRs in open slots in agenda.
07:46:33 <manu> rrsagent, draft minutes
07:46:33 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/29-did-minutes.html manu
07:47:02 <gannan> gannan has joined #did
07:47:08 <markus_sabadello> markus_sabadello has joined #did
07:47:11 <manu> brent: This is a good time to learn how to scribe, please volunteer.
07:47:44 <manu> brent: Put your name on one of these boxes on Agenda if you want to scribe. Don't scribe when you're presenting.
07:48:11 <manu> brent: The scribing of the meeting is happening in IRC - on #did channel.
07:48:20 <selfissued> selfissued has joined #did
07:48:20 <manu> burn: Everyone needs to be on IRC.
07:48:25 <selfissued> present+
07:48:31 <gannan> present+
07:48:37 <drummond> drummond has joined #did
07:48:42 <ewelton> ewelton has joined #did
07:48:42 <drummond> present+
07:48:43 <manu> brent: If you have something to say, queue, present+, etc.
07:48:47 <JoeAndrieu> JoeAndrieu has joined #did
07:48:56 <manu> present+
07:48:58 <Oskar> Oskar has joined #did
07:49:03 <brent> present+
07:49:09 <ken> present+
07:49:11 <yancy> present+
07:49:15 <Oskar> present+
07:49:16 <ewelton> present+
07:49:19 <yoshiaki> present+
07:49:54 <manu> brent: We are going to introduce ourselves - your name, who you work for, single sentence why you're here, what is your favorite programming language and why?
07:51:12 <manu> burn: Hi Dan Burnett, my favorite language is Oz - created for teaching, started with small primitives, then built from there - language can do just about anything you can think of, with a small set of primitives. Example on screen shows how easy it is to do multithreading.
07:51:39 <ChristopherA> present+
07:52:07 <JoeAndrieu> present+
07:52:44 <manu> brent: Hi Brent Zundel, I work for Evernym. I'm here because I love DIDs, and I love the power of Self Sovereign Identity... my favorite language is ML - small functional programming language from Haskell. In grad school, I had to write a parser generator ... everyone else was using C++, had to print out code because professor was a sadist... everyone else had 30-40 pages of code, my ML program was a page and a half.
07:53:24 <manu> brent: Hi Ken Ebert, from Sovrin Foundation. I'm here because of focus on privacy. Favorite programming language is used for Carol the robot, great beginning programming language.
07:54:07 <manu> tobias: Hi Tobias Looker, from Mattr. Working on decentrlaized identifier tech - excited about new wave of technology for this standard. My favorite language is TypeScript or C# - from a syntax perspective, good static/dynamic balance.
07:54:50 <manu> yancy: Hi I'm Yancy Ribbens, I work for no one. I took a compilers class, had to use ML - favorite language is Rust recently - new for me, like type safety and reinvention - how to write memory safe code.
07:55:50 <manu> yoshiaki: Hi Yoshiaki Kami, working for a company in Japan. I'm working for European Japanese reference architecture, identifiers are very important. I'm not a programmer, very difficult to choose.
07:56:12 <yoshiaki> s/Kami/Fukami/
07:57:00 <yoshiaki> s/working for a company/working for Data Trading Alliance, an industrial consortiom in Japan/
07:57:25 <manu> ChristopherA: Hi Christopher, I used to be with Blockstream, now with Blockstream Commons. I also do RWoT. I like highly constrained environments, most fun experience is implementing Forth in assembler - 12 words in assembler, rest is made by composing base words. I'd like to do that, but in principles of typed language, believe ML is one of them.
07:59:15 <manu> selfissued: Hi Mike Jones at Microsoft. Worked on a lot of different standards in identity space... OAuth, JWT, OpenID Connect - bringing some of that expertise to bear here. Want to make DIDs useful/simple while making things decentralized. I liked Bliss - DEC system DEC10, DEC 20, VAX - Bliss unofficially was an acronym for "Bill's Language for Implementing Systems Software" - gave you full control over bits, bytes, pointers... but in a more typesafe and
07:59:15 <manu> principled way. I write C# these days mostly because it's easy.
07:59:43 <manu> @@@: Hi my name is @@@, work at Spherity. I'm not a programmer, but spent lots of time in MATLAB.
08:00:11 <manu> drummond: Hi I'm Drummond Reed at Evernym, helped get this DID thing going. Not a programmer, except in ABNF, love ABNF. I have written a few things in Basic.
08:00:52 <manu> SamSmith: Hi Sam Smith, worked in a lot of different things. Here on behalf of ConsenSys. Happy to be here. Also, worked in space for a while in IoT. Favorite programming language is Python - started using Python in version 1 in production.
08:01:31 <manu> Karsten: Hi Karsten from Spherity, physicist. I like DIDs because unknown actors will meet each other to establish trust using DIDs/VCs. I do a lot of C / C++, lots of simulation.
08:01:51 <SamSmith> Spelled Carsten
08:02:09 <manu> Oskar: Hi Oskar from TNO, Duch Research Institution. I'm technical coordinator for SSI arena focus on interoperability, integration, getting whole ecosystem running. I'm here to liase with all of you. I like Java because I'm an organized guy.
08:03:01 <selfissued> q+
08:03:01 <manu> JoeAndrieu: I'm Joe Andrieu, I'm here on behalf of Legendary Requirements. I do requirements engineering. I like lisp, like LPC (written in Amsterdam).
08:03:06 <brent> scribe+
08:03:42 <manu> selfissued: I'd like to retract my favorite programming language, now xml2rfc. :)
08:03:47 <manu> *laughing*
08:03:55 <ken> s/Duch/Dutch/
08:04:40 <gannan> s/Karsten/Carsten/
08:04:41 <brent> manu: Hi, I'm Manu, CEO of Digital Bazaar. One of the editors of the DID Spec, my favorite programming language is @@@ because it started messay and dirty , but turned into something that everyone uses.
08:04:41 <drummond> Javascript = "the people's language" = true
08:04:55 <brent> s/@@@/Javascript/
08:05:14 <manu> MichaelShea: Hi Michael Shea, independent, former programmer many years ago. C and C++ were my favorites - also leading task force for SSI and IoT for Sovrin Foundation. Seeing DIDs and IoT and some activity on mailing list - why I decided it was useful to join.
08:05:19 <Entropy> Entropy has joined #did
08:05:48 <Oskar> The European project eSSIF-Lab (essif-lab.eu) funds start-ups and SMEs to build useful SSI stuff: open-source components, generic SSI functionality and services, and sector-specific SSI applications. Email: oskar.vandeventer@tno.nl
08:05:52 <manu> markus_sabadello: Hi Markus Sabadello, founder of Danube Tech. I'm here because everything I'm doing has to do w/ DIDs - foundational for Web. My favorite programming language is Java.
08:05:55 <drummond> DIDs = "new foundation for the Web itself" = true
08:06:19 <manu> Eric: Hi Eric Welton, I'm here because I like to write about what's going on here. I like custom programming languages, fit for purpose.
08:06:45 <presenter> presenter has joined #did
08:07:00 <manu> Oliver: Hi Oliver Terbu, with ConsenSys - favorite programming language i C, C++, and now like TypeScript - like implementations for ReactNative, run on mobile backend. I'm here because DIDs are important, foundational for universal identity
08:07:04 <Carsten> Carsten has joined #did
08:07:18 <drummond> Yeah Identitywoman!
08:08:39 <manu> Kaliya: Hi Kaliya, named IdentityWoman - mainly because only woman in the room (and here we are again). I also work w/ Wireline, interested in DIDs in existing world, less interested in how Web uses DIDs - PKI seems to be a focus, curiosity that I bring in terms of that - haven't registered that much. I've been stewarding and leading in this community - thought there might be contentious things in this group, would like to moderate and help get us to other side.
08:08:39 <manu> This is important work.
08:09:02 <drummond> +1 to Kaliya helping facilitate any embroglios
08:09:16 <manu> Kaliya: I don't have a favorite programming language - if programming languages are about how you manifest into the world and create, as a facilitator - for me, Open Space Technology is something powerful that we've used in this community, that would be my favorite.
08:09:32 <ken> s/Carol/Karel/
08:09:55 <manu> Ganesh: Hi Ganesh Annan, from Digital Bazaar. I like how DIDs affect security and privacy considerations. Javascript is strongest, but really like Python - it's followed me throughout my career. The versatility of Python is why I love it.
08:11:13 <manu> dezell: Hi David Ezell, represent Conexxus, we do standards in convenience retail. You have to have respect for C, Java, Javascript is getting better. Microsoft Macro Assembler was powerful. There is a property of decentralized technology that is important in the convenience store space.
08:12:30 <manu> dezell: If you think of some of the specs we write, a central authority is "good enough"... problem is that's a self selecting group, some thing centralized is fine, others don't participate. We are interesetd in decentralized technologies in general. We have a project underway with National Association of Convenience Stores that starts w/ age verification. Why is it important to do this at W3C? Same reason that it was important that it was important to do XML at
08:12:31 <manu> W3C.
08:12:37 <manu> dezell: I'm here to offer that support.
08:13:30 <manu> jricher: Hi Justin Richer, here from Bespoke - here on behalf of SecureKey - been doing a lot of work w/ them. Favorite programming language... did quite a bit in LambdaMoo - use Java the most, Python is great - list comprehensions are beautiful language constructions.
08:14:17 <manu> jricher: I'm here because I want these technologies to succeed so I have more diverse tools to apply to projects. I have a lot of experience in standards space, like to bridge engineers w/ architects - I move between those spaces.
08:14:34 <manu> Juan: Hi Juan, work with Karsten at Spherity. I like C++, Python - don't have strong opinions.
08:15:43 <manu> Eugene: Hi Eugene, work with Jolocom - in Berlin. We work with Verifiable Credentials, excited to see where this space is going. As implementers, we want to be aware of discussions. I'm curious about some of the discussions we're about to have today. I am a victim of Javascript/Typescript - enjoy Rust, Go - don't know them enough to say I like them.
08:15:44 <nicole> nicole has joined #did
08:16:09 <manu> Charles: Hi Charles from Jolocom, easier to get a feeling for things in person. I like TypeScript - Typescript is easy.
08:16:33 <manu> Joachim: Hi Joachim, here from Jolocom, learning about different perspectives on topic of DID. Looking forward to learn more.
08:17:57 <manu> burn: Hi, Dan Burnett from ConsenSys - got involved before DIDs... walking by when Manu was presenting Verifiable Credentials, stopped and listened, and thought this is the right way to approach identity. Takes focus off of consolidation, definition, I believe that Verifiable Credentials and Decentralized Identifiers, not identity, are two technologies that can help solve these problems in a way that avoids consolidation.
08:18:25 <manu> brent: We have next slide, as we discuss things, if there is something you want to talk about, add it to the slide.
08:18:25 <manu> q+
08:18:42 <manu> q-
08:20:05 <Justin_R> Justin_R has joined #did
08:20:09 <brent> burn: I want to remind us all why we are here.
08:20:40 <brent> ... The mission of the working group is to standardize the DID URI scheme, the DID data model, and (reading the slide)
08:21:00 <brent> ... In scope (slide 12)
08:21:07 <mshea> mshea has joined #did
08:21:23 <JoeAndrieu_> JoeAndrieu_ has joined #did
08:21:41 <brent> burn: the item about use cases is to talk about future uses for access management
08:22:01 <brent> ... we will produce a note that is a refined use cases document
08:22:10 <brent> ... the resolution spec is not in scope
08:22:17 <brent> ... out of scope (slide 13)
08:22:52 <brent> ... we will not define browser APIs, specific DID methods, or attempt to solve identity on the web.
08:23:06 <brent> ... not an accident that none of our specs sayt we are solving identity.
08:23:21 <brent> ... any questions
08:23:32 <brent> ... deliverables (slide 14)
08:23:36 <JoeAndrieu> JoeAndrieu has joined #did
08:23:52 <brent> ... some links (slide 15)
08:24:04 <brent> ... summary of our w3c process
08:24:07 <oliver> oliver has joined #did
08:24:11 <oliver> present+ oliver
08:24:12 <brent> ... (slide 16)
08:24:26 <brent> ... working drafts don't imply consensus
08:24:34 <brent> ... it does not mean we agree.
08:24:54 <brent> ... there is a point at which we believe it is technically complete, this is when we get to CR.
08:25:07 <brent> ... then we need at least 2 implementations of each feature
08:25:19 <brent> ... then we go to PR
08:25:29 <brent> ... slide 17 (nice process picture)
08:25:49 <brent> ... we also have a timeline
08:26:32 <brent> ... our first public working draft was last year.
08:26:43 <brent> ... we got a use cases and requriements note out
08:26:57 <brent> ... we will talk about the rubric this meeting
08:27:14 <brent> ... we backwards calculated the other dates
08:28:32 <brent> ... (slide 18) has dates for each step in getting to CR and PR
08:28:47 <brent> ... we need multiple CRs (I didn't say that)
08:29:01 <brent> ... we need our first CR my November 2020.
08:29:09 <brent> ... we need a feature freeze in May 2020
08:29:21 <brent> ... its easy to think we have time.
08:29:26 <brent> ... we don't
08:29:48 <brent> ... After CR, there can't be any substantive changes
08:30:06 <brent> ... all this to say, this is why the chairs will be pushing to feature freeze.
08:30:19 <brent> ... we don't want to recharter to get our first spec out.
08:31:06 <brent> ... for this meeting: the primary goal is to get agreement on the JSON/JSON-LD/Abstract data model question
08:31:20 <brent> ... we cover background and necessary things day one.
08:31:30 <brent> ... so that tomorrow we can get to a decision
08:31:49 <brent> ... assuming we get that done, we can cover the other goals (slide 19)
08:32:11 <brent> ... there are aspects of the metadata discussion that may be pertinant to our main goal
08:32:20 <brent> ... any questions?
08:32:27 <brent> JoeAndrieu: metadata is today?
08:32:43 <brent> burn: this afternoon, so we have it in mind when we make the big decision
08:32:54 <ivan> ivan has joined #did
08:32:57 <brent> ... for those of you who have slides, get them in
08:33:04 <ivan> present+
08:33:14 <ivan> zakim, who is here?
08:33:14 <Zakim> Present: burn, tplooker, selfissued, gannan, drummond, manu, brent, ken, yancy, Oskar, ewelton, yoshiaki, ChristopherA, JoeAndrieu, oliver, ivan
08:33:17 <Zakim> On IRC I see ivan, oliver, JoeAndrieu, mshea, Justin_R, nicole, Carsten, presenter, Oskar, ewelton, drummond, selfissued, markus_sabadello, gannan, tplooker, ken, burn, brent,
08:33:17 <Zakim> ... SamSmith, yofukami, yoshiaki, RRSAgent, Zakim, deiu, llorllale, rhiaro, ChristopherA, bigbluehat, jfishback, Travis, hadleybeeman, wayne, dlehn, manu, dlongley, yancy
08:33:17 <brent> ... is there anything in the agenda to talk about did resolution and what we're doing?
08:33:35 <brent> JoeAndrieu: we should talk about the boundary between the two
08:33:37 <markus_sabadello> present+
08:33:55 <brent> burn: look at the agenda, if you don't see a place where your comments will fit, let us know
08:34:07 <brent> ... we're trying to get knowledge without going into a rathole
08:34:20 <brent> ... any other rquestions?
08:34:48 <brent> burn: a story I want to tell
08:35:12 <brent> ... (standing) My technical background is in computer speech recognition.
08:35:31 <brent> ... I had to decide whether to continue with that or to continue with standards.
08:35:40 <brent> ... I jumped into WebRTC with both feet.
08:35:50 <brent> ... it has spawned better work in W3C and IETF
08:36:03 <brent> ... but, something very bad happened
08:36:31 <brent> ... we started working on a standard. One company that didn't participate started promulgating a competiting standard.
08:36:39 <brent> ... that did not result in what they wanted.
08:36:48 <brent> ... it resulted in horrendous confusion
08:37:04 <brent> ... companies looking to deploy, came in and saw the battle.
08:37:11 <brent> ... investment dried up.
08:37:19 <brent> ... conflict reults in everybody losing
08:37:35 <brent> ... it is important that we come together to write A standard
08:37:47 <brent> ... that's what matters (even if there are different formats)
08:37:58 <brent> ... we will talk about extensibility and interoperability
08:38:11 <brent> ... if you're frustrated, talk more with htose you disagree with
08:38:20 <manu> q+ to talk about what happened w/ RDFa/Microformats/Microdata/JSON-LD over the past decade.
08:38:22 <brent> ... don't leave, that will damage the industry
08:38:40 <brent> ... others have chimed in with similar stories
08:38:52 <brent> ... any quyestions?
08:39:08 <manu> q-
08:39:36 <brent> ewelton: I was asked to look at DIDs, because a company I worked for wanted to determine if they had cooled down enough to actually use
08:39:54 <manu> scribe: manu
08:39:58 <ChristopherA> q+
08:40:02 <brent> q?
08:40:11 <brent> ack selfissued
08:40:17 <brent> ack ChristopherA
08:41:10 <Eugeniu_Rusu> Eugeniu_Rusu has joined #did
08:41:25 <manu> ChristopherA: A little more history - co-author of SSL/TLS and led group that made TLS the international standard that it is today. We had these conflicts then - one of the big breakthroughs was - we found where we could have all of the important stuff in common, and then very few things we could go in radical different direction. The design allowed for more, that helped us break through impasse.
08:42:16 <charles> charles has joined #did
08:42:19 <jonathan_holt> jonathan_holt has joined #did
08:42:19 <manu> ChristopherA: We got 80% in common,  how you get up to certain part of protocol, then had ciphersuites - you had to specify those, and as separate RFCs. If we tried to just pick a few, it would've failed. I think that's a pattern in standards design - coming up with 20% agreement, then more until 80%.
08:42:27 <nicole> nicole has joined #did
08:42:57 <jonathan_holt> present+ jonathan_holt
08:43:19 <manu> burn: This is the standards process, this is normal. This is completely normal to disagree at beginning, standards process is writing down when you agree, then keep building on that stuff. Often end up w/ what Christopher said. I can provide my input on interop for standards (over a beer). Standards are useful for companies because it reduces the development time.
08:43:28 <ivan> Topic: security
08:44:36 <manu> brent: Two weeks ago, Dr. Sam Smith provided a deep dive into security concerns wrt. spec. I did my best to summarize, might have oversimplified... summary is that each DID Method has a different solution for verification and control of a DID. Different protocols, infrastructure, this is the big concern. We need to keep this in mind while moving forward.
08:45:01 <manu> brent: We are designing an architecture that could have a lot of badness - what other concerns around architecture concerns should we have as we have in mind.
08:45:24 <manu> MichaelShea: When you say verification of control, what do you mean?
08:46:02 <manu> brent: Well, resolution we need to make that's secure, code on computer is secure, DID Document stored on ledger, what are ledger guarantees? Is it peer or key did, is it self-certifying? etc.
08:46:11 <manu> q+ to note a few other security concerns.
08:46:22 <ivan> present+ SamSmith
08:46:30 <brent> q?
08:46:35 <ChristopherA> q+
08:46:36 <ewelton> q+ to what extent do we try to solve security vs. qualify security and mark as rubrics?
08:46:44 <brent> manu: implementation complexity is also somehting
08:46:56 <Eugeniu_Rusu_> Eugeniu_Rusu_ has joined #did
08:46:58 <JoeAndrieu> q+ to mentioned conflation of control & authentication
08:47:00 <brent> ... we want a secure system, so we make sure we do things in a limited way
08:47:05 <ken> q+
08:47:10 <brent> ... so they can be implemented in the right way.
08:47:19 <brent> ... this limits implementation at the edges.
08:47:19 <ivan> guests+ Michael_Shea
08:47:32 <ivan> ack manu
08:47:32 <Zakim> manu, you wanted to note a few other security concerns.
08:47:42 <brent> ... we don't know where this tech is going. we are going to enable someflexibility.
08:47:54 <brent> ... this may allow implementors to shoot themselves in the foot
08:48:09 <ivan> ack ChristopherA
08:48:13 <brent> ack ChristopherA
08:48:40 <burn> scribe+
08:49:04 <manu> ChristopherA: I'd like to speak for innovation in cryptography and cryptographic systems - especially over last decade and last 2-3 years, we're going way beyond crypto of today. Most of this stuff is coming from crypto communities... cryptographic circuits, multisignatures, zero knowledge proofs, scriptless scripts - cambrian explosion right now.
08:49:57 <SamSmith> q+
08:50:04 <brent> ack ewelton
08:50:04 <Zakim> ewelton, you wanted to what extent do we try to solve security vs. qualify security and mark as rubrics?
08:50:06 <manu> ChristopherA: JOSE was a disaster when it came out, everything is a disaster when it comes out, but it's roots are in 1980s single signature technologies - we're able to go beyond that. I'm not saying don't support more proven types of approaches, but don't lock out emerging technologies, because we could lose it all if folks go w/ new emerging technologies.
08:50:29 <manu> Eric: Is the goal for security to try to solve a meta process vs. identify characteristics concerns and address them as rubrics.
08:50:39 <brent> q?
08:50:44 <brent> ack JoeAndrieu
08:50:44 <Zakim> JoeAndrieu, you wanted to mentioned conflation of control & authentication
08:50:50 <oliver> oliver has joined #did
08:51:06 <ivan_> ivan_ has joined #did
08:51:10 <yoshiaki> yoshiaki has joined #did
08:51:13 <oliver> present+ oliver
08:51:21 <ivan_> q?
08:51:25 <ivan_> q+
08:51:32 <manu> JoeAndrieu: It's going to be vital for us to distinguish in conversations and spec, proof of control over DID Document and authenticating as the DID. People conflate those two, different use cases, analyze them differently. DID Control is method specific, two different surface areas - let's talk about them as different things.
08:51:37 <brent> ack ken
08:52:12 <drummond> q+
08:52:22 <brent> ack SamSmith
08:52:25 <manu> Ken: Even though ZKPs are strong in Sovrin ecosystem, we're upgrading those now - if we lock ourselves in, we will lock out the future and not be able to migrate forward. We need some sort of rubric to test minimum security levels. We do want to shut out insecure systems.
08:53:11 <selfissued> q+
08:53:28 <manu> SamSmith: I've been thinking about this problem for a while, one of the things that might be helpful is to step back and think about how we layer security - cryptographic agility, how we address infrastructure differences, if we layer this right, we can get best of both worlds. If we layer it wrong, we'll bifurcate the trust map and make the rest of history a never ending retreat/fallback positions and security patches.
08:53:49 <brent> q?
08:53:51 <manu> SamSmith: My biggest concern is that we're failing badly from a security design perspective - we've maximized ability for people to exploit.
08:53:53 <brent> ack ivan_
08:53:57 <ken> ken has joined #did
08:54:26 <brent> q?
08:54:26 <manu> Ivan: More a question coming from a non-expert... I haven't seen anything in document for biometrics / FaceID - is this ok, do we want to have bridges for that? What do we do there.
08:54:33 <brent> ack drummond
08:54:37 <JoeAndrieu> q+ to comment on biometrics
08:55:11 <peacekeeper> peacekeeper has joined #did
08:55:40 <manu> drummond: I wanted to reinforce what sam said, first on extensibility - no way people in room will know right security practices 5 years from now... we need to allow for extensibility and innovation - many of problems on how to deploy securely is something we want to consider, but these are not in scope. Let's make sure we get layering right, but let's not inhibit innovation.
08:55:47 <brent> ack selfissued
08:55:48 <manu> drummond: Let's not block innovation.
08:56:37 <manu> selfissued: I wanted to second Chris' point about cryptographic agility and innovation, we don't know what algorithms are needed for what use cases in future. We don't know what'll become compromised next week. Any long term standard in security must ensure innovation in 20% for systems that update at their own pace.
08:56:46 <brent> ack JoeAndrieu
08:56:46 <Zakim> JoeAndrieu, you wanted to comment on biometrics
08:56:53 <markus_sabadello> markus_sabadello has joined #did
08:57:00 <markus_sabadello> q+
08:57:24 <oliver> q+
08:58:01 <manu> JoeAndrieu: Wanted to respond to Ivan - in part on use cases work - there is a huge amount of concern around privacy and biometrics - there is conflation around DID Method and biometrics - no one has proposed biometrics yet, but design allows for it, but want to move biometrics to the edge, like a phone, don't put them in DID Document. The ultimate mechanism is cryptographic, keys secured biometrically.
08:58:10 <manu> Ivan: We may want to put that in the document.
08:58:29 <brent> ack markus_sabadello
08:59:14 <brent> ack oliver
08:59:14 <manu> markus: The way the spec and DID Method specs, DIDs inherit underlying DID methods - facebook method only as secure as facebook. Is that a feature? Or do we want stronger security properties?
08:59:48 <manu> Oliver: We have to limit the decentralized extensibility model to uphold certain amount of security properties... isn't W3C DID Method registry already a registry for such features?
08:59:53 <JoeAndrieu> q+ security of key loss & recovery needs attention
08:59:57 <manu> q+ to speak to DID Method Registry.
09:00:50 <manu> Oliver: Imagine you extend DID Method in a way that changes security mechanism for basic DID Method - that's a problem that needs to be solved, we should have an IANA registry, limit scope of extensibility to certain scope, like authoritative keys.
09:00:54 <manu> ack manu
09:00:54 <Zakim> manu, you wanted to speak to DID Method Registry.
09:02:10 <manu> manu: We could extend DID Method Registry, we'll talk about that. We do want to limit DID Methods from overriding how security primitives in DID Core work.
09:02:36 <selfissued> q+
09:02:40 <manu> brent: What should we do about these issues? We could require DID Method sto follow common practice, how do we layer security, security considerations, bad practices, rubric?
09:02:42 <brent> ack selfissued
09:02:46 <ken> q+
09:02:56 <JoeAndrieu> q+ to talk about best practices for key management
09:03:29 <ewelton> q+ request clarification on the term "layer" - used now several times
09:03:40 <manu> selfissued: I did something dangerous on flight here and read every word of DID spec, one of the things I read was that there were places where spec imposes requirements on DID Methods. Security considerations, privacy considerations. I agree with Manu's suggestion that methods shouldn't change core functionality - impose requirements on DID Methods, even though we're not doing a protocol spec, data model spec.
09:03:43 <brent> ack ken
09:03:47 <manu> q+ ewelton
09:04:06 <manu> Ken: We'll need some sort of rubric to evaluate.
09:04:12 <manu> q+ to not trust humans to do this.
09:04:17 <juan_caballero> juan_caballero has joined #did
09:04:38 <manu> Ken: The number of DID Methods is growing, we're over 40 now, we will need a rubric.
09:04:38 <brent> ack JoeAndrieu
09:04:38 <Zakim> JoeAndrieu, you wanted to talk about best practices for key management
09:05:02 <manu> JoeAndrieu: I want to endorse the idea of a rubric, we've been working on one about decentralization - doesn't address security, doesn't support privacy.
09:05:35 <yancy> q+
09:05:56 <brent> ack ewelton
09:05:58 <manu> JoeAndrieu: We need to clarify securtity related to key management, and security assuming keys are well managed. Best we can do w/ key management to point to external references... if keys are compromised, everything is off. We should separate those two things.
09:05:59 <SamSmith> SamSmith has joined #did
09:06:01 <SamSmith> q+
09:06:06 <manu> ewelton: About layer/layering - what does that mean?
09:06:10 <brent> ack manu
09:06:10 <Zakim> manu, you wanted to not trust humans to do this.
09:07:47 <burn> manu: Not to argue ... Concerned with how much we are asking humans to do (bad for security).  DID core spec has normative language around DID methods.  Humans have to read and understand this in approving DID methods, which may ultimately fail.  These rubric docs will be very complex human-readable docs.  Headed towards 50-90 items that an expert has to check for each and every DID method.
09:08:22 <ivan_> present+ phila
09:08:28 <burn> ... some have argued decentralized extensibility is bad.  My argument somewhat agrees with this, unfortunately.  We need to consider this.
09:08:30 <brent> ack yancy
09:09:15 <brent> ack SamSmith
09:09:19 <manu> yancy: The best way to harden a system is to reduce the attack surface - that means we should focus on bare minimum essentials are - segues into thing slike matrix parameters, what are use cases, we should minimize feature sets to helps us be as secure as possible.
09:10:33 <markus_sabadello> q+
09:11:24 <manu> SamSmith: First bullet, make DID Methods follow same thing to establish control authority - maybe we can do a trust spanning layer hour glass approach - standard set of config data, looks like events - we say it's too late to put the genie back in the bottle - that's bad for security, but look at ecosystem, if we design DID Method the right way, all other DID Methods will die and we'll be left w/ 1-2 DID Methods, layered security model - roots of trust, ability
09:11:24 <manu> for that config to change the establishment mechanism, we get all we need. If you have too much extensibility, you get OpenSSL OpenVPN - too much agility to do something wrong.
09:11:40 <manu> SamSmith: If we built ideal DID Method, and that wins in market, that's great.
09:12:32 <manu> Markus: Building ideal DID Method, with ideal properties - what if other DID methods that were not as good, keep going, like did:web - the point of the decentralization rubric is not to come up with the one best thing. Maybe security rubric could have the same. KERI-based ones are more secure than DNS based ones?
09:13:09 <manu> brent: First one doesn't seem to be possible... which of these others? Where do we want to go - add things to security considerations.
09:13:33 <ChristopherA> q+
09:13:38 <manu> brent: Do we want to do a rubric to start? Expand test suite to look for specific security considerations? DID Method can algorithmically done? What does the group want to do?
09:13:43 <JoeAndrieu> q+
09:13:45 <manu> q+ to suggest a few plans of action.
09:13:46 <gannan> q+ to ask for clarification on what we can do?
09:13:47 <ivan_> ack markus_sabadello
09:13:49 <brent> ack markus_sabadello
09:13:53 <brent> ack ChristopherA
09:14:04 <brent> Zakim, close the queue
09:14:04 <Zakim> ok, brent, the speaker queue is closed
09:14:35 <brent> q?
09:14:54 <SamSmith> q+
09:14:55 <brent> ack JoeAndrieu
09:14:58 <manu> ChristopherA: I am concerned that there has to be a common  practice - I have a demo of multisig control authority that can't be implemented - it's self-sovereign multisig - I have a Tor baesd connection to a node I control, 3 keys, can do multisig, but not with what we have right now. I don't think there'll be a common practice.
09:15:09 <brent> ack manu
09:15:09 <Zakim> manu, you wanted to suggest a few plans of action.
09:15:57 <SamSmith> q-
09:16:13 <burn> manu: we need to write much of this down into security section, until it gets large enough to deserve its own doc.  +1 to joe's comment about a rubric.  Don't like security rubric, because it needs to be firm guidance.
09:16:21 <brent> ack gannan
09:16:21 <Zakim> gannan, you wanted to ask for clarification on what we can do?
09:16:28 <manu> JoeAndrieu: I think we need to do a rubric, it's going to take a lot longer than people realize, but we can't provide direct guidance.
09:16:49 <manu> gannan: Establishing common practice, sounds like protocol issue - what can we state about this stuff?
09:16:54 <burn> manu: we need to give guidance, which can't happen in a rubric
09:17:02 <manu> brent: We can normatively require DID Methods to implement themselves in a certain way.
09:17:12 <brent> Zakim, open the queue
09:17:12 <Zakim> ok, brent, the speaker queue is open
09:17:18 <manu> Topic: DIDs and IoT
09:18:27 <manu> SamSmith: IoT Characteristics - large number of devices, 80 billion by 2025 - by and large, IPv6 - probably see Internet switch over next 5 years... 5G is almost 100% IPv6... rest of world using IPv6.
09:18:55 <dezell> dezell has joined #did
09:19:24 <manu> SamSmith: This is a driving function, there will be way more IoT devices, need identifiers, than everything that we do combined, these devices are limited resources - example, IETF CoAP - UDP alternative, DTLS/CBOR solution - two major groups, industrial Internet of Things - commercial vs. home.
09:20:35 <manu> SamSmith: Differences between two are significant - many of these devices are industrial IoT. This building we're in HVAC, security systems, IoT things - what tends to happen is integration is happening in the cloud - all device families are siloed, HVAC vendor, window treatments, have non interop devices - only way they can talk together, operationally integrate w/ the cloud - that's a challenging problem, they can't talk to each other in same building.
09:21:15 <manu> SamSmith: Data integration, not just talking to each other, - future is, there is not enough cloud compute capability to manage those sorts of things, zettabytes - future, has to be done on the edge. Strong driver for DIDs to have ability to authenticate in edge, do operational integration in edge.
09:22:08 <manu> SamSmith: Two types of devices - direct IP enabled devices, home automation - indirect IP enabled - some non IP stack, IP gateway device, bluetooth, zigbee, non-IP stack devices might talk to gateway - tends to happen more in commercial IoT makes it cost effective to have a gateway.
09:22:23 <manu> SamSmith: In general, authenticated control is more important than confidentiality.
09:23:30 <manu> SamSmith: CoAP based system, gateway - diagram explanation
09:24:02 <manu> SamSmith: The biggest issue for IoT is security - IoT devices are in public building, someone can pull device, mess with it, may not know.
09:24:36 <manu> SamSmith: That is an overarching concern, problem w/ IoT is most devices have default credentials. 90% of installers don't change default passwords.
09:24:43 <manu> ChristopherA: They are no longer going to allow that.
09:25:36 <manu> SamSmith: Some devices only have LAN access, some have unencrypted data, anything we do as identifier standard that requires WAN access, no LAN version, just won't work.
09:26:04 <manu> SamSmith: Edge vs. Cloud integration - future will be edge, devices are not self-sovereign in any way. Edge integration, that would have to change.
09:26:40 <manu> SamSmith: IoT provisioning - typical provisioning method, some sort of on device label - limited physical security.
09:27:18 <manu> SamSmith: number sticker, scratch off ID, barcodes, QRCodes - anything more complex is going to fail.
09:27:46 <manu> SamSmith: puts an upper limit to fully support IoT, how complex can provisioning be? Bootstrapping identifier, not going to be adoptable if it's heavyweight.
09:29:07 <burn> q?
09:29:20 <manu> SamSmith: If you can do a self-contained boostrap, you can simplify the system. Some devices are using contextual information, looking at nearby devices, won't authenticate them - different location, most cases, IoT devices have low value, no need for persistent identifier - self-certifying identifiers, you don't need anything - if something has been hacked, throw it away, reprovision.
09:29:38 <manu> SamSmith: Rarely do these things communicate pairwise - getout of lan onto gateway.
09:31:53 <manu> SamSmith: Future is non-siloed edge integration, sensors with authorized tlemetry, actuators... there is already an alternatiev standards tack IETF/TCG - Device ID - Implicit Identifier. Implicit identity, self certifying id created on first power up. This one is private, manufacturer doesn'nt know private key, on power up, genreates key on boot up. Any tampering creates new DID.
09:33:13 <manu> SamSmith: This is a CBOR/JSON CWT spec.
09:33:41 <manu> SamSmith: IoT Interop - oBIX, XML based legacy 1990s...
09:34:12 <manu> SamSmith: numerous walled garden standards, numerous consortia - in Europe, IoT EPI - big tent approach, mostly architecture, not implementation,
09:34:55 <manu> SamSmith: Project Haystacks getting the most adoption, uses tag model - key-value pair w/ registered set of tags, simple model, easy portability - broad adoption - winning over industry consortia
09:35:44 <manu> SamSmith: Interesting thing - Haystacks achieved broad industry adoption via tagged semantic model, brix project, haystacks tag ontology as overly to enable some RDF models to sit on top of haystacks. Doesn't encumber underlying encodings whie allowing any RDF standard encoding to apply to this model.
09:36:02 <manu> SamSmith: That's the end...
09:36:14 <manu> q+ to note Web of Things
09:36:26 <dezell> q+ to second Manu
09:36:36 <manu> SamSmith: Are we going to integrate w/ IoT? Constrained encodings, CBOR...
09:36:36 <brent> ack manu
09:36:36 <Zakim> manu, you wanted to note Web of Things
09:36:48 <JoeAndrieu> q+ to ask about filament
09:36:55 <burn> manu: great info, thanks.  we are clearly missing this big sector.
09:37:03 <ChristopherA> q+
09:37:08 <burn> ... how do we liaise with them.  Have we missed the boat?
09:37:25 <burn> ... sounds compatible with did:key.
09:37:31 <burn> SamSmith: yes.
09:37:39 <burn> manu: we need to reach out and share that.
09:37:52 <burn> ... w3c has web of things working group that is connected here.
09:38:02 <burn> SamSmith: haystack tag ontology group is using W3C stuff.
09:38:23 <burn> ... they do an overlay using W3C standards
09:38:23 <brent> q?
09:38:30 <burn> manu: WoT uses JSON-LD
09:38:32 <jonathan_holt> Not to complain, but is there audio on the webex?
09:38:51 <burn> ... need to see what they needed in WoT to make everything work
09:39:09 <burn> SamSmith: defined dictionary with meta-semantic model
09:39:32 <burn> ... for large factory automation projects, worth overhead to map to semantic model for benefit of data analytics
09:39:42 <burn> ... in most cases simple tags are enough.
09:39:56 <brent> ack dezell
09:39:56 <Zakim> dezell, you wanted to second Manu
09:39:59 <burn> ... for big buildings with thousands of devices the semantic overlay is helpful
09:40:48 <brent> q?
09:41:15 <ChristopherA> That WG has a 7am ET call? Wow, that is 4am PT.
09:41:21 <brent> zakim, close the queue
09:41:21 <Zakim> ok, brent, the speaker queue is closed
09:41:33 <manu> dezell: Second the shout out to Web of Things - deeply embedded in company projects, security meeting is 8am ET - rough hour, think this group should engage with them. This aspect is important part of DIDs. Was present on PSIG review of PR for Web of Things - security folks had two issues, one was the presence of "id:" in thing description, could be subject to replay attack, or recognition of endpoint if you didn't know it was... Security section in document,
09:41:33 <manu> security section is non-normative, was a big issue in their work.
09:41:39 <brent> ack JoeAndrieu
09:41:39 <Zakim> JoeAndrieu, you wanted to ask about filament
09:41:54 <manu> JoeAndrieu: Has anyone looked at Filament? Jeremy Miller, XMPP?
09:42:26 <manu> SamSmith: Looked at filament, lots of industry specific protocols, Nest guys (filament) -- Jeremy Miller, Telehash used for IoT stuff. Hundreds of them
09:42:48 <manu> Fun fact: earliest DID method we know of was implemented using Telehash :)
09:43:08 <brent> ack ChristopherA
09:45:27 <manu> ChristopherA: There is a great connection in crypto security industry around problems w/ security - verification w/ hardware crypto, as an example, box we did w/ Blockchain commons - paper display on one side, you can route to my mac via Onion, key ops w/ QRCodes - also do this w/ VPS, keys are completely split - device can't sign anything by itself. The thing it talks to contributes signature - VC is only valid once it reaches threshold of attestment.
09:45:27 <manu> Multisignature - VC proof would say you have to have at least two of 10 instruments for it to be valid... and approval of the cloud device.
09:45:52 <manu> ChristopherA: These are the things we're doing in crypcurrency space, I want to see this stuff - there is a mesh there w/ IoT, but we're doing more sophisticaed crypto.
09:46:00 <manu> rrsagent, draft mintues
09:46:00 <RRSAgent> I'm logging. I don't understand 'draft mintues', manu.  Try /msg RRSAgent help
09:46:08 <manu> rrsagent, draft minutes
09:46:08 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/29-did-minutes.html manu
09:46:49 <manu> i/I want to remind us all/scribe: brent/
09:47:02 <manu> rrsagent, draft minutes
09:47:02 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/29-did-minutes.html manu
09:55:46 <identitywoman> identitywoman has joined #DID
09:55:52 <identitywoman> present+
09:56:02 <gannan> gannan has joined #did
10:11:53 <ivan_> rrsagent, draft minutes
10:11:53 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/29-did-minutes.html ivan_
10:12:41 <gannan> gannan has joined #did
10:12:42 <ken> ken has joined #did
10:12:54 <JoeAndrieu> q?
10:13:04 <charles> charles has joined #did
10:13:04 <JoeAndrieu> scribe+ JoeAndrieu
10:13:41 <nicole> nicole has joined #did
10:13:56 <ivan_> zakim, who is here?
10:13:56 <Zakim> Present: burn, tplooker, selfissued, gannan, drummond, manu, brent, ken, yancy, Oskar, ewelton, yoshiaki, ChristopherA, JoeAndrieu, oliver, ivan, markus_sabadello, jonathan_holt,
10:14:00 <Zakim> ... SamSmith, phila, identitywoman
10:14:00 <Zakim> On IRC I see nicole, charles, ken, gannan, dezell, SamSmith, juan_caballero, yoshiaki, ivan_, Eugeniu_Rusu_, jonathan_holt, JoeAndrieu, Carsten, presenter, Oskar, ewelton,
10:14:00 <Zakim> ... tplooker, burn, brent, yofukami, RRSAgent, Zakim, deiu, llorllale, rhiaro, ChristopherA, bigbluehat, jfishback, Travis, hadleybeeman, wayne, dlehn, manu, dlongley, yancy
10:14:18 <oliver> oliver has joined #did
10:14:20 <Justin_R> Justin_R has joined #did
10:14:20 <oliver> present+ oliver
10:14:27 <markus_sabadello> markus_sabadello has joined #did
10:14:30 <markus_sabadello> Yo
10:14:38 <JoeAndrieu> markuse_sabadello: Yo
10:14:40 <identitywoman> identitywoman has joined #DID
10:14:47 <mshea> mshea has joined #did
10:15:01 <JoeAndrieu> ... Not going to go into the hard details about how interop and everything works.
10:15:08 <phila> phila has joined #did
10:15:15 <JoeAndrieu> ... we want to look at some of the formats and syntaxes that have been discussed
10:15:45 <phila> present+
10:15:49 <JoeAndrieu> ... found nine : JON-LD, JSON, IPLD, CBOR, XML, PDF, ASN.1, YAML, XDI
10:16:04 <JoeAndrieu> ... please add to slide if you know of others (but don't delete)
10:16:13 <JoeAndrieu> ... Let's start with JSON-LD
10:16:23 <JoeAndrieu> ... Primary format in the spec. Been there since the beginning
10:16:27 <charles> charles has joined #did
10:16:34 <JoeAndrieu> ... based on semantic web principles and RDF graph model
10:16:56 <JoeAndrieu> ... linked data / RDF has a background connected to decentralization on the web.
10:17:19 <JoeAndrieu> ... Ivan's paper: the web is about linking. linked data is trying to do the same thing for data.
10:17:33 <JoeAndrieu> ... Some may remember FOAF: where you can point to other identifiers who are my friends
10:18:01 <JoeAndrieu> ... for these JSON-LD is great. permissionless extensibility. compability with a bunch of things
10:18:20 <JoeAndrieu> ... Also a lot of interest in JSON (pure JSON)
10:18:25 <burn> q?
10:18:52 <JoeAndrieu> ... ubiquitous support, familiar to developers. no external network dependencies, comapability with a bunch of things (JOSE, OIDC, DIDComm)
10:19:03 <JoeAndrieu> s/comapability/compatability/
10:19:07 <manu> q+ to speak to "JSON Benefits" - some of which are the same for JSON-LD - clarification -- slide 43
10:19:30 <JoeAndrieu> ... Another is IPLD
10:19:35 <burn> q?
10:19:43 <burn> zakim, open the queue
10:19:43 <Zakim> ok, burn, the speaker queue is open
10:19:43 <jonathan_holt> cool! Thanks!
10:19:46 <JoeAndrieu> ... content-addressable, distributed storage, location- &  protocol- independent
10:19:56 <JoeAndrieu> ... censorship resistant
10:20:24 <JoeAndrieu> ... CBOR has also been mentioned. Also used in IPLD
10:20:42 <JoeAndrieu> ... very compact. great for IoT. easy to map to JSON
10:21:00 <JoeAndrieu> ... might be possible to do JSON-LD in CBOR
10:21:08 <JoeAndrieu> ... but also maybe pure JSON in CBOR
10:21:22 <JoeAndrieu> ... So what do we mean by data model, syntax, serialization, etc.
10:21:40 <JoeAndrieu> ... XML: obviously the best for everything
10:22:02 <JoeAndrieu> ... good for data-types, namespaces, lots of tooling
10:22:06 <manu> q+ to speak to "JSON Benefits" - some of which are the same for JSON-LD - clarification -- slide 43
10:22:15 <burn> q+ to comment on XML
10:22:15 <JoeAndrieu> ... PDF has been proposed. Express a DID Document as PDF.
10:22:20 <manu> q+ to note about JSON-LD subset (and other subsets)
10:22:37 <JoeAndrieu> ... not so much as human readable PDF, but rather embedding a DID Document in a machine readable form inside a DID Document
10:22:53 <JoeAndrieu> ... These are some of the formats, some of the discussions we have had in the community on this topic
10:23:25 <JoeAndrieu> ... We can't have this discussion in isolation. We can't just compare these two directly.
10:23:35 <JoeAndrieu> ... There are dependencies on the intentions for DIDs
10:23:53 <JoeAndrieu> ... What's the purpose of the DID Document?
10:24:12 <JoeAndrieu> ... Did document describes the sbuject -> JSON-LD preference
10:24:20 <JoeAndrieu> q+ to disagree about purpose alignment
10:24:32 <tplooker> q+
10:24:46 <JoeAndrieu> ... if DID Document contains meta-dataa for interacting with the subject -> JSON Preference
10:25:08 <JoeAndrieu> ... Similarly, do we think DIDs are part of the web?
10:25:24 <JoeAndrieu> ... are DID Documents resources on the web -> JSON-LD Preference
10:25:42 <JoeAndrieu> ... if DID Documents are mor like DNS records -> JSON preference
10:25:55 <JoeAndrieu> ... -> likely affinity between world view and technical approach
10:26:19 <JoeAndrieu> ... Some DID Methods don't care the format of the DID Document.
10:26:42 <JoeAndrieu> ... But for example, did:sov doesn't have native support for any of the proposals. they store it on its own format.
10:27:12 <JoeAndrieu> ... the ethereum smart contract based DIDs tend to treat the Document as virtual, serializing as necessary
10:27:46 <JoeAndrieu> ... did:key is currently JSON-LD, but it is so simple and constrained, you may not actually be using any of the features of JSON-LD and might be better suited for "pure JSON"
10:27:52 <burn> q+ to remind that when we started, DID document was a physical presentation of information needed to work with the DID, with no requirement that it be stored anywhere, only provided as needed
10:28:12 <JoeAndrieu> ... other dependencies include support for public key formats
10:28:41 <JoeAndrieu> ... We just added JWK support, but do we really want a JWK public key inside an XML or CBOR DID Document?
10:29:02 <JoeAndrieu> ... How would we do that? It would be more natural to do everything in the chosen format
10:29:38 <JoeAndrieu> ... Fragments in DID URLs: dereferencing fragments is not defined by the DID core spec, but rather on the mime-type
10:29:49 <oliver> q+
10:29:52 <JoeAndrieu> ... so if we have multiple encodings, that might change the semantics fragment identifiers
10:30:12 <SamSmith> q+
10:30:14 <JoeAndrieu> ... Let's discuss: interop, extensibiltiy, resolver behavior
10:30:15 <ChristopherA> q+
10:30:18 <ken> q+
10:30:25 <Justin_R> q+
10:30:34 <burn> zakim, close the queue
10:30:34 <Zakim> ok, burn, the speaker queue is closed
10:30:37 <burn> ack manu
10:30:37 <Zakim> manu, you wanted to speak to "JSON Benefits" - some of which are the same for JSON-LD - clarification -- slide 43 and to note about JSON-LD subset (and other subsets)
10:30:42 <JoeAndrieu> manu: two things
10:31:05 <JoeAndrieu> ... One. I don't know if people knew to the group. VC spec and DID core spec, the goal was to use a subset between all these formats.
10:31:18 <JoeAndrieu> ... so, we strove to use the minimal subset you can represent in JSON, CBOR, and JSON-LD
10:31:33 <JoeAndrieu> ... so, even those the VC spec says it's JSON-LD, it is actually a very limited subset
10:31:57 <JoeAndrieu> ... So, we don't necessarily have network dependencies (because we are using a subset of JSON-LD)
10:32:09 <JoeAndrieu> ... specifically, one should not go out  to the network in run-time
10:32:16 <JoeAndrieu> ... for things you don't understand
10:32:26 <burn> ack burn
10:32:26 <Zakim> burn, you wanted to comment on XML and to remind that when we started, DID document was a physical presentation of information needed to work with the DID, with no requirement that
10:32:29 <Zakim> ... it be stored anywhere, only provided as needed
10:32:34 <JoeAndrieu> ... On the other hand, in some cases, you go out to the network regardless of format
10:32:54 <JoeAndrieu> burn: still a good portion of the world that uses XML
10:33:01 <drummond> drummond has joined #did
10:33:07 <drummond> present+
10:33:08 <JoeAndrieu> ... it's not crazy to assume that maybe there will be an XML representation
10:33:09 <drummond> q?
10:33:29 <JoeAndrieu> ... Second, when we started, the DID Document was a physical representation, but it is not required that it ever be stored anywhere.
10:33:49 <JoeAndrieu> ... this is an explicit requirement: the document is not the thing, it's the information in the document that matters
10:33:53 <burn> q?
10:33:57 <burn> ack JoeAndrieu
10:33:57 <Zakim> JoeAndrieu, you wanted to disagree about purpose alignment
10:34:25 <manu> JoeAndrieu: Markus, you had suggested that if the metal model for a DID Document is how to interact with the subject, you might go to JSON. I'm flipped, I don't see that at all.
10:34:31 <burn> ack tplooker
10:34:33 <brent> JoeAndrieu: real quick. Markus suggested the mental model for a DID doc is how to interact with the subject, the format is JSON. I'm not seeing that
10:34:36 <manu> JoeAndrieu: Don't think I need to spend more time on that, but I don't see the affinity.
10:35:13 <JoeAndrieu> tobias: If we make all of these encodings first class options, then we have content negotiation as a huge upfront requirement for everyone using the tech
10:35:29 <JoeAndrieu> ... but we need to know what level we are supporting these alternatives
10:36:05 <JoeAndrieu> ... What is a DID Document? A lot of time... is it a rendering of events into the current state? Or is it the actual thing the decentralized system actually represents
10:36:20 <burn> ack oliver
10:37:00 <burn> ack SamSmith
10:37:00 <JoeAndrieu> oliver: re: fragment semantics: we are writing specifications for the did data model and did -resolution and it doesn't seem to be a problem
10:37:16 <JoeAndrieu> SamSmith: I think there is still confusion about what the purpose of a DID Document is.
10:37:24 <JoeAndrieu> ... the first thing you need to do is establish control authority?
10:37:42 <JoeAndrieu> ... the way methods are being written its not clear where we are on this question
10:37:51 <Justin_R> +1 to sam's point on information models
10:37:52 <JoeAndrieu> ... I'm not talking about hte data model, but the information model
10:38:19 <JoeAndrieu> ... if you think about what happens with a URL: before you go to a given server, you have to resolve the authority
10:38:34 <JoeAndrieu> ... Are we going to standardize that establishment of control authority
10:38:40 <JoeAndrieu> q+ to talk about authority
10:38:45 <burn> ack ChristopherA
10:39:08 <burn> ack ken
10:39:11 <JoeAndrieu> ChristopherA: some people already touched on my issues
10:39:39 <JoeAndrieu> ken: concur with Markus: there's a difference between our internal representations and what are present to the outside.
10:39:58 <JoeAndrieu> ... we expect to be able to publish multiple serializations for interoperability
10:40:20 <JoeAndrieu> ChristopherA: One of the problems I'm seeing is that we are not talking about who the audience is for the DID document
10:40:41 <JoeAndrieu> ... If I'm a consumer of the app, I really don't care out rotation happens. I'll defer that to a resolver.
10:40:55 <JoeAndrieu> ... however if I am writing a resolver, then I do care about those things
10:41:07 <burn> ack Justin_R
10:41:08 <JoeAndrieu> ... I'm a little worried we aren't thinking about these differences
10:41:19 <JoeAndrieu> Justin_R: +1 to that
10:41:22 <burn> s/out rotation/how rotation/
10:41:27 <JoeAndrieu> ... we need to be honest about what the DID Document structure is
10:41:38 <burn> q?
10:41:40 <JoeAndrieu> ... we need to be very careful about what is expressed AND expressable in a DID Document
10:41:49 <JoeAndrieu> ... that gets to the core of what I see in the debate
10:41:50 <burn> zakim, open the queue
10:41:50 <Zakim> ok, burn, the speaker queue is open
10:41:53 <burn> q+ JoeAndrieu
10:41:59 <burn> zakim, close the queue
10:41:59 <Zakim> ok, burn, the speaker queue is closed
10:42:10 <JoeAndrieu> ... What I'm seeing is "use JSON-LD" but turn off all the stuff that makes JSON-LD special
10:42:27 <JoeAndrieu> ... so can we count on that extensibility? or Should we assume it is turned off?
10:42:51 <JoeAndrieu> ... Or on the JSON side, can we be sure we only have strings, numbers, etc.?
10:43:22 <JoeAndrieu> ... Given Markus's big list is great. (NO to ASN.1 but glad its considered)
10:43:27 <drummond> q?
10:43:38 <JoeAndrieu> ... we need to get to the lowest common denominator
10:44:05 <JoeAndrieu> ... if this working group wants to be able to depend on LD structures to understand that a field is a particular type, etc., a date
10:44:25 <burn> ack JoeAndrieu
10:44:28 <JoeAndrieu> ... instead we have JSON-LD docs that aren't really JSON-LD
10:44:37 <JoeAndrieu> ... and vice-versa
10:44:51 <JoeAndrieu> ... [I mean JSON docs that aren't really JSON]
10:45:22 <brent> Topic: Different Encodings: Model Incompatibilities
10:45:30 <JoeAndrieu> manu: Things to be aware of as we go into the discussion.
10:45:43 <JoeAndrieu> ... Different encodings: Model incompatibilities
10:46:06 <JoeAndrieu> ... Four categories: primitives, structure, canonical form, extensibility
10:46:36 <JoeAndrieu> ... [nice concise definitions of those four]
10:47:13 <JoeAndrieu> ... A bunch of primitives that are or are not supported in different models
10:47:55 <JoeAndrieu> ... Integers as keys (including negatives), BigNums, Byte Strings, ordered sets and unordered sets
10:48:04 <JoeAndrieu> ... Does order matter? Where? When?
10:48:16 <JoeAndrieu> ... tagged values and tagged types. "This is an IP address"
10:48:34 <JoeAndrieu> ... number representations in different platforms matter.
10:49:04 <JoeAndrieu> ... JSON states numbers can be infinite, but reality is different. Typically 32 or 64 bit, depending on platforms
10:49:15 <JoeAndrieu> ... In short: this is not a simple choice
10:49:22 <JoeAndrieu> ... Data Model structures: three kinds
10:49:35 <JoeAndrieu> ... 1 Flat Structure (flat name-value pairs)
10:49:51 <JoeAndrieu> ... 2 Tree structure (most formats allow this).
10:50:11 <JoeAndrieu> ... but the question is does the structure imply anything semantically. Typically yes, but what?
10:50:32 <JoeAndrieu> ... Do certain names mean something? "id" in JSON-LD does. In JSON it doesn't.
10:50:55 <JoeAndrieu> ... Can you have arbitrary references to other entries in the document?
10:51:27 <JoeAndrieu> ... Because of that referenceability wrt public keys, we are almost certainly using a graph structure not a tree structure
10:51:40 <burn> zakim, open the queue
10:51:40 <Zakim> ok, burn, the speaker queue is open
10:51:42 <burn> q?
10:51:44 <JoeAndrieu> ... 3. Graph structure?
10:51:45 <jonathan_holt> technically, CBOR does specify a 'canonical form' in the RFC see: https://tools.ietf.org/html/rfc7049#section-3.9
10:51:50 <JoeAndrieu> ... Canonical Forms
10:52:03 <JoeAndrieu> ... CBOR does not have a canonical form
10:52:33 <JoeAndrieu> ... One has to be defined by the protocol. CBOR doesn't haven't it implicitly. Rather the spec gives guidance on how to do it.
10:53:16 <JoeAndrieu> ... JSON does not have a canonical form, but there are schemes for doing it (JCS), but has corner cases.
10:53:40 <JoeAndrieu> ... JSON-LD does have a canonical form
10:53:49 <JoeAndrieu> ... that form is not a standard yet, but there is work happening in that direction.
10:54:07 <JoeAndrieu> ... if we care about digital signatures, then we care about canonical forms
10:54:12 <JoeAndrieu> ... Extensibility:
10:54:36 <JoeAndrieu> ... If we use @context from JSON-LD and the JSON encoding doesn't, then we have two completely different models for extensibility
10:54:40 <selfissued> selfissued has joined #did
10:54:46 <selfissued> present+
10:54:55 <selfissued> q+
10:54:59 <JoeAndrieu> ... If JSON-Only uses registry, do JSON-LD implementations have to pay attention to it?
10:55:09 <jonathan_holt> q+ to pitch dagCBOR as a deterministic representation in IPLD
10:55:12 <JoeAndrieu> ... How do you know if your implementation is up to date with the current registry?
10:55:38 <JoeAndrieu> ... This comes down to: do we want a canonical form, how do we sign it without introducing security problems
10:55:48 <JoeAndrieu> ... buckets!
10:56:05 <tplooker> q+
10:56:31 <JoeAndrieu> ... That means put extensions in a particular property, but then there is a question about what others should do if they find a bucket they don't understand.
10:56:38 <JoeAndrieu> ... these are not the only things
10:56:41 <oliver> q+
10:56:46 <JoeAndrieu> ... what else are there?
10:56:59 <ChristopherA> q+
10:57:00 <SamSmith> q+
10:57:03 <markus_sabadello> Q+
10:57:04 <drummond> q+
10:57:05 <burn> zakim, close the queue
10:57:05 <Zakim> ok, burn, the speaker queue is closed
10:57:08 <manu> q+
10:57:20 <burn> ack selfissued
10:57:27 <JoeAndrieu> selfissued: Two responses
10:57:48 <JoeAndrieu> ... in passing, Manu, you promulgated the assumption that canonicalization is necessary to sign. It is not.
10:58:06 <JoeAndrieu> ... Canonicalization is one way to do it. But JWT signs without canonicalization.
10:58:20 <JoeAndrieu> ... so we don't need to deal with that hairball
10:58:22 <manu> We have a mismatch of definitions... I agree with Mike that you can do it.
10:58:30 <JoeAndrieu> ... Different point: CBOR v JSON
10:58:53 <burn> ack jonathan_holt
10:58:53 <Zakim> jonathan_holt, you wanted to pitch dagCBOR as a deterministic representation in IPLD
10:59:05 <JoeAndrieu> ... Occam's razor suggests that we make the CBOR one exactly the JSON representation applying a standard translation to CBOR and not doing CBOR specific things
10:59:24 <tplooker> q-
10:59:34 <jonathan_holt> just to plug IPLD.... pass
11:00:04 <burn> q?
11:00:06 <burn> ack oliver
11:00:36 <Justin_R> -1 to version fields
11:00:39 <JoeAndrieu> oliver: staying up to date with JSON & registries is a hard problem to solve. but we could maybe deal with that with a version field
11:01:06 <burn> ack ChristopherA
11:01:32 <JoeAndrieu> ChristopherA: first, to respond to you have to have the entire JSON thing along with it.
11:01:58 <JoeAndrieu> ... that means that signature chains mean an explosion of sizes. so JSON not so great for multi-sig
11:02:07 <JoeAndrieu> ... I'm one of those people who likes JSON-LD for a different reason.
11:02:28 <JoeAndrieu> ... A lot of us came to JSON-LD because of the open world model and graphs, into JSON-LD from RDF
11:02:51 <JoeAndrieu> ... I came into JSON-LD because I can do a merkle-tree of the quads. I can do that with JSON-LD, but not with JSON.
11:03:27 <JoeAndrieu> ... I have a bunch of statements in JSON-LD, with each independently provable.
11:03:58 <JoeAndrieu> ... It's the simplest form of data minimization you can do. In contrast to issuing separate claims for every distinct assertion.
11:04:08 <JoeAndrieu> ... You just can't do that in some of these other stacks.
11:04:10 <brent> q?
11:04:30 <JoeAndrieu> ... We could separate from the JSON-LD thing from the canonicalization.
11:05:05 <JoeAndrieu> ... Just give me a merkle-tree. and I'll verify it
11:05:22 <burn> ack SamSmith
11:05:41 <JoeAndrieu> SamSmith: There are lots of standards that use much simpler data models and they work practically, and well
11:05:50 <manu> q+ to talk about "simpler" and other use cases.
11:06:04 <JoeAndrieu> ... there is a sense that if we don't have the ideal level of extensibility and all of these features, then we have the impreseion that will be a problem.
11:06:14 <JoeAndrieu> ... the real world is less about the ideal and more about practical adoption
11:06:29 <JoeAndrieu> ... sometimes that is more important to us as a standards organization
11:06:43 <JoeAndrieu> ... I spent ten years pushing superior tech that failed in the marketplace
11:06:58 <JoeAndrieu> ... concern is that we tend to err on the side of being ideologues instead of what will work in the marketplace
11:07:09 <JoeAndrieu> ... we should temper our conversations with a sense of adoptability
11:07:28 <selfissued> q+
11:07:30 <burn> ack markus_sabadello
11:07:32 <JoeAndrieu> burn: everyone gets to say everything without censorship
11:07:35 <JoeAndrieu> ... for now
11:07:48 <burn> q?
11:07:56 <JoeAndrieu> markus_sabadello: I liked Oliver's comments about registries and versions
11:08:17 <burn> ack drummond
11:08:21 <JoeAndrieu> ... Perhaps there is some way that a registry and JSON_LD context could be kept in sync
11:08:38 <JoeAndrieu> Drummond: I want to reinforce something Sam said.
11:08:50 <JoeAndrieu> ... I posted the first issue that we should look at an abstract data model
11:09:01 <JoeAndrieu> ... all the discussion has made me even more passionate than ever
11:09:21 <JoeAndrieu> ... I define that as the core data model. This is what we absolutely have to figure out and agree on.
11:09:39 <JoeAndrieu> ... pure encoding is not the clear differentiator.
11:09:54 <JoeAndrieu> ... They are all actually graph models with different complexity
11:10:24 <JoeAndrieu> ... What we are solving is so low level... if we solve that ONE problem well, DIDs will be enormously successful, with NO extensibility at all
11:10:50 <JoeAndrieu> ... this is not to say extensibility isn't good, but that we must not fumble the ball
11:10:58 <JoeAndrieu> burn: lunch is coming up.
11:11:17 <JoeAndrieu> ... I know we haven't had enough time for discussion. We will have more time as we go.
11:11:24 <burn> zakim, open the queue
11:11:24 <Zakim> ok, burn, the speaker queue is open
11:11:34 <JoeAndrieu> ... Please keep comments short to keep the conversation flowing.
11:11:45 <ivan_> Topic: Abstract Data Modeling Options
11:11:54 <JoeAndrieu> ... So far, we've just been talking about potential incompatibilities
11:12:02 <JoeAndrieu> ... So I'm going to talk abstractly about abstract data models
11:12:09 <JoeAndrieu> ... What are we modeling?
11:12:20 <JoeAndrieu> ... Data processing (processing of a DID Doc)
11:12:24 <JoeAndrieu> ... Data Storage
11:12:32 <JoeAndrieu> ... Data transmission
11:12:54 <JoeAndrieu> ... The processing we are talking about is various computer languages. We HAVE to be agnostic there.
11:13:18 <JoeAndrieu> ... For storage, we'll likely store them in databases, but that's not really what we are standardizing here
11:13:29 <JoeAndrieu> ... Schema definitions my help.
11:13:54 <JoeAndrieu> ... For transmission, note we don't have to use the same format as we do for storage
11:14:09 <JoeAndrieu> ... Suggestion is that the transmission format is what we are modeling here
11:14:30 <JoeAndrieu> ... Other than PDF, most of us are talking about transmission.
11:14:43 <JoeAndrieu> ... This matters because it affects how you do modeling
11:15:05 <JoeAndrieu> ... Why do people use JSON?
11:15:18 <JoeAndrieu> ... It basically was an alternative to XML for transmission
11:15:43 <JoeAndrieu> ... I've done tones of XML. JSON is effectively a wire format for messages transmission and exchange.
11:15:53 <JoeAndrieu> ... By that, I mean a specific serialization
11:16:17 <chaals> chaals has joined #did
11:16:24 <JoeAndrieu> ... Alternatives to JSON for serialization of Data: CSV, XML, YAML, CBOR
11:16:46 <JoeAndrieu> ... Argument: we should not be picking one, we should be using an abstract data model that works with any of these serialization
11:16:58 <JoeAndrieu> ... What level are we defining?
11:17:21 <JoeAndrieu> ... Spec was designed to be an abstract (exchange data model)
11:17:27 <JoeAndrieu> ... could deifnine at different levels
11:17:55 <JoeAndrieu> ... A Conceptual data model defins semantic roles and relationship without getting into syntax
11:18:13 <JoeAndrieu> ... typically uses a graphical representation that simplify an overview
11:18:29 <JoeAndrieu> ... Examples: object role model (ORM, very high level)
11:18:45 <JoeAndrieu> ... or Entity Relationship Model(express, UML, IDEFIX)
11:19:11 <JoeAndrieu> ... A structural level presents roles and relationship as fields (sometimes with syntactic requirements)
11:19:57 <JoeAndrieu> ... if we choose a modeling language that also allows us to model ties to procedures is that implementers could then take that model and extend it, using that modeling language to provide the computation support they need.
11:20:01 <oliver> oliver has joined #did
11:20:10 <oliver> present+ oliver
11:20:13 <JoeAndrieu> ... All of that is out of scope, but if we use such a language, it might help downstream adoption
11:20:57 <JoeAndrieu> ... Bunch of examples of favorite structural modeling languages
11:21:09 <JoeAndrieu> ... Are we modeling a transmission model?
11:21:23 <JoeAndrieu> ... and are we modeling a conceptual or structural model?
11:21:46 <JoeAndrieu> ... suggestion we should probably go to a structural model, with a format that has a graphical representation
11:21:57 <JoeAndrieu> ... it's just so nice for explaining to people what we are doing.
11:22:16 <manu> q+ to note that we are modeling a transmission format that is structural - we do abstract data model today, folks might not realize it.
11:22:33 <JoeAndrieu> ... Examble structural formats: EXPRESS, Protobuf, UML, IDEF1X
11:22:58 <JoeAndrieu> [see slides for details]
11:24:51 <dezell> q?
11:24:59 <dezell> q+
11:25:43 <ivan> q+ to ask about available tools for specs
11:26:05 <JoeAndrieu> ... those are the examples. we don't have to pick from just one of these.
11:26:10 <manu> q- later
11:26:22 <JoeAndrieu> ... this was to help us understand what our choices are as we consider abstract data models
11:26:46 <JoeAndrieu> ... This is a UML diagram that was complete and correct.
11:26:58 <JoeAndrieu> ... Some of the terms have changed, but it was accurate at the time.k
11:27:13 <JoeAndrieu> ... This avoids the bias of any particular syntax.
11:27:53 <JoeAndrieu> ... But we couldn't get anyone to write a specific syntax EXCEPT JSON-LD, so we got rid of the UML and moved forward with JSON-LD.
11:28:08 <Justin_R> q+ to talk about transmission formats
11:28:08 <burn> q?
11:28:13 <JoeAndrieu> ... We'd love to have this for DIDs, we just need people to step up and produce them.
11:28:16 <manu> q- later
11:28:19 <drummond> q+
11:28:23 <burn> zakim, close the queue
11:28:23 <Zakim> ok, burn, the speaker queue is closed
11:28:29 <manu> q- later
11:28:31 <burn> ack dezell
11:28:37 <ken> ken has joined #did
11:28:47 <JoeAndrieu> ... dezell: I'm wondering why JSON Schema didn't make the list.
11:29:08 <JoeAndrieu> ... it is the underlying spec for [something] . I'm a UML fan, but the value comes out in a tooling
11:29:27 <JoeAndrieu> ... the graphs turn into real code.
11:29:35 <burn> q?
11:29:37 <burn> ack ivan
11:29:37 <Zakim> ivan, you wanted to ask about available tools for specs
11:30:03 <JoeAndrieu> ivan: JSON Schema is a moving target. They keep coming up with new versions. Stability is a problem.
11:30:26 <JoeAndrieu> ... we have had discussions with the JSON Schema people. They keep saying "sure a real standard would be great".
11:30:51 <JoeAndrieu> ... We have editors who have to create documents. Which are the ones that have good tools for editors?
11:31:11 <burn> ack Justin_R
11:31:11 <Zakim> Justin_R, you wanted to talk about transmission formats
11:31:48 <JoeAndrieu> Justin_R: big +1 to transmission and structural format coverage. There are assumptions that get glazed over
11:32:06 <JoeAndrieu> ... if we really are an abstract data format, then our data format need to actual exist and be serializable
11:32:22 <JoeAndrieu> ... what we have been doing a bad job at is realizing what those costs and weights are for other people
11:32:39 <burn> ack drummond
11:32:44 <JoeAndrieu> ... We often look at these as how easy it is for us in the group, without awareness of what it means for others.
11:33:04 <burn> ack manu
11:33:04 <Zakim> manu, you wanted to note that we are modeling a transmission format that is structural - we do abstract data model today, folks might not realize it.
11:33:08 <JoeAndrieu> drummond: as one who is passionate about abstract data models, I will volunteer, if we do UML
11:33:25 <JoeAndrieu> manu: Agree that we are doing a transmission and structural format
11:33:50 <JoeAndrieu> ... I had thought we were ALREADY doing a data model spec. I don't think there is much debate to be had at this level.
11:34:07 <JoeAndrieu> ... We can argue details, but there doesn't seem to be anything controversial here.
11:34:08 <ivan> q+
11:34:34 <JoeAndrieu> burn: right, but there are lots of people who may not have realized that we are making an abstract data model and what that means to our collaboration
11:35:16 <dezell> I'd like to reference the XMLInfoset spec: https://www.w3.org/TR/xml-infoset/.  It's purpose was to decouple XML syntax from the information content.  Probably worth a look.
11:35:33 <JoeAndrieu> manu: the diagrams in the VC spec were removed because of feedback from implementers
11:35:50 <JoeAndrieu> burn: yes. I'm not saying we should have ONLY visual representations
11:36:08 <JoeAndrieu> ... we are chartered to define a data model AND one or more specific data realizations
11:36:16 <burn> q?
11:36:23 <JoeAndrieu> burn: LUNCH!
11:36:38 <ivan> rrsagent, draft minutes
11:36:38 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/29-did-minutes.html ivan
11:51:03 <charles> charles has joined #did
12:19:53 <gannan> gannan has joined #did
12:25:10 <ken> ken has joined #did
12:28:26 <brent> brent has joined #did
12:29:02 <ken> scribe+
12:29:46 <nicole> nicole has joined #did
12:30:47 <ivan> ivan has joined #did
12:32:02 <JoeAndrieu> q?
12:32:13 <brent> Zoom Link for audio: https://zoom.us/j/5593214233
12:32:40 <phila> phila has joined #did
12:32:43 <chaals> chaals has joined #did
12:32:54 <Justin_R> Justin_R has joined #did
12:33:00 <ken> Brent: Who's going to dinner?
12:33:17 <tplooker> tplooker has joined #did
12:33:28 <ken> ... 21 people.
12:33:30 <tplooker> present+
12:34:27 <ken> ChristopherA: Who would like to eat in Amsterdam?
12:34:41 <ken> ... OK. I'll find a place that works.
12:34:51 <ken> ... by the break.
12:35:29 <mshea> mshea has joined #did
12:35:39 <drummond> drummond has joined #did
12:35:41 <drummond> present+
12:35:46 <ken> Topic: DID Doc Extensibility via Registries
12:36:03 <ken> self_issued: What to registries accomplish?
12:36:14 <ken> ... They prevent name collisions.
12:36:38 <ken> ... And provide authoritative links to where to find definitions.
12:37:04 <juan_caballero> juan_caballero has joined #did
12:37:05 <ken> ... Idenitifiers can use names with the same meaning.
12:37:08 <juan_caballero> https://tools.ietf.org/html/rfc7518
12:37:31 <ken> ... Samples are IANA web token claim registry.
12:37:40 <juan_caballero> (JWA spec mentioned in ref to prev slide)
12:37:53 <ken> ... See https://www.iana.org/assignments/jwt/jwt.xhtml
12:38:12 <ken> ... (Explain sample)
12:38:13 <gannan> gannan has joined #did
12:38:46 <ken> ... Claims for specific use cases are included.
12:38:50 <burn> zakim, open the queue
12:38:50 <Zakim> ok, burn, the speaker queue is open
12:38:52 <burn> q?
12:39:54 <Chunming> Chunming has joined #did
12:39:57 <ken> ... Specifications are required to add to IANA JSON Web Token Claims pending expert review.
12:40:21 <ken> ... Second example: https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms
12:41:14 <ken> ... How to add to a registry?
12:42:00 <ken> ... This is a decentralized method of publishing definitions.
12:42:07 <Justin_R> q+ to talk about how registries like this get enforced
12:42:29 <manu> q+ to note about IETF registries being a decentralized extensibility mechanism.
12:42:38 <ken> ...The DID spec prohibits redefinition of terms.
12:43:00 <ken> ... Registries can help us avoid conflicts.
12:43:05 <brent> q?
12:43:12 <brent> ack Justin_R
12:43:12 <Zakim> Justin_R, you wanted to talk about how registries like this get enforced
12:43:20 <markus_sabadello> q+
12:43:22 <samsmith> samsmith has joined #did
12:43:23 <drummond> q+
12:43:28 <selfissued> selfissued has joined #did
12:43:29 <samsmith> q+
12:43:40 <selfissued> present+
12:43:43 <Eugeniu_Rusu> Eugeniu_Rusu has joined #did
12:43:51 <ken> Justin_R: An important note when looking at the suite of JOSE fields. It creates a source for enumeration of fields.
12:44:09 <selfissued> q+
12:44:33 <ken> ... I think this is strongly needed so that implementors can follow the directions in the documentation.
12:44:37 <chaals> chaals has joined #did
12:44:53 <ken> ... The registry tells the implementor what they have to do.
12:45:22 <ken> ... When I see that field, I know what library to point at it.
12:45:42 <Justin_R> to clarify, I believe we really need this for DID methods
12:45:48 <drummond> q?
12:46:05 <ken> self-issued: Claiming there is no registry does a disservice to implementors.
12:46:13 <ChristopherA> q+
12:46:18 <ken> ... From a normative standpoint.
12:46:25 <ChristopherA> q-
12:46:28 <ken> ... I think that is a mistake.
12:46:43 <ken> ... I filed an issue on that topic.
12:46:44 <Carsten> Carsten has joined #did
12:47:15 <Justin_R> I want to point out to everyone that this mapping is explicitly in the WG charter
12:47:17 <ken> ... Especially with indentifiers that are not human readable.
12:47:38 <brent> ack manu
12:47:38 <Zakim> manu, you wanted to note about IETF registries being a decentralized extensibility mechanism.
12:47:42 <ChristopherA> q+ on not all "levels" of a registry entry need normative and conformance testable defines. Right now all entries in DID Registry are "provisional"
12:47:46 <ken> ... A more normal practice is to use human readable names.
12:48:39 <ken> manu: Depending on the definition of decentralized, registries have high process when there is disagreement.
12:48:51 <ChristopherA> q?
12:49:07 <oliver> oliver has joined #did
12:49:08 <ken> ... Disagreement can be legit or political.
12:49:10 <oliver> present+ oliver
12:49:58 <ken> self-issued: Fair enough. Usually there are directions to the reviewers to guide their actions.
12:49:58 <brent> ack markus_sabadello
12:49:59 <JoeAndrieu> q+ to distinguish registry for methods v registry for properties
12:50:31 <ken> markus_sabadello: Mike, do you think the registry approach will work with high volumes of additions?
12:50:36 <brent> q?
12:51:02 <brent> zakim, close the queue
12:51:02 <Zakim> ok, brent, the speaker queue is closed
12:51:05 <ken> ... Right now these are handled by JSON-LD definitions.
12:51:29 <ken> ... With 1000s being added I wonder if a registry can handle it.
12:51:42 <ken> ... Would it make sense for service types?
12:52:17 <ewelton> q+ to intentional versus emergent interop
12:52:23 <burn> So there is a bar to entry for adding to a registry - not necessarily a bad thing
12:52:29 <ken> self-issued: I would hope that service types would be registered. If not, how do implementors find out what the interoperabiliity is supposed to be?
12:52:55 <brent> ack drummond
12:52:56 <ChristopherA> q?
12:53:20 <ken> ... The registry says these are the service definitions that digital-bazaar created, or ChristopherA created.
12:53:33 <ken> drummond: I put the original text in. Sorry
12:53:35 <ewelton> registries require explicit, intentional interoperability - but an open-world model will allow opportunistic, emergent interoperability
12:53:52 <ken> ... I never expected we would have over 40 methods.
12:54:08 <ken> ... It has grown beyond expectations.
12:54:33 <ken> ... Point 2 Registries are a method, but not the only method.
12:54:59 <ken> ... The core features are in the spec. The extensions are not.
12:55:01 <brent> q?
12:55:06 <brent> ack samsmith
12:55:11 <ken> ... Both methods can work together.
12:55:46 <ken> samsmith: We have an informal method name. The rest can be defined within the method spec.
12:56:00 <ken> ... The model can name space to avoid collisions.
12:56:09 <markus_sabadello> q+
12:56:21 <ken> ... Namespaces are good; we should have more of them!
12:56:32 <brent> ack selfissued
12:56:48 <ken> self-issued: RFC7515
12:56:58 <ken> ... Search for collision.
12:57:27 <ken> ... JWS spec discussion of names. Public names are registered.
12:58:02 <ken> ... Collisions resistant names use some natural prefixes to prevent collision.
12:58:39 <ken> ... Using my domain name as the prefix helps me define my own "namespace"
12:58:51 <brent> q?
12:59:04 <ken> ... There are other collision resistant names that are longer and not registered.
12:59:16 <jonathan_holt> as an aside, OIDs are a valid URIs
12:59:23 <markus_sabadello> q-
12:59:23 <ken> ... You lose the definition if it is not registered.
12:59:27 <brent> ack ChristopherA
12:59:27 <Zakim> ChristopherA, you wanted to comment on not all "levels" of a registry entry need normative and conformance testable defines. Right now all entries in DID Registry are "provisional"
13:00:29 <ken> ChristopherA: An early proposal involved a whole block chain to register all the names.
13:00:36 <ken> ... It was too complicated.
13:01:21 <ken> ... A five level staging system involved documentation, implementation, live-system, etc.
13:01:36 <ken> ... It was censorship-resistant.
13:01:38 <Justin_R> +1 to the levels and measures, this is what the normative teeth would apply to
13:02:07 <ken> ... I suspect that only a few will make it all the way through.
13:02:34 <ken> ... It's probably out of scope for this group to set up all and run a registry long-term.
13:02:39 <brent> ack JoeAndrieu
13:02:39 <Zakim> JoeAndrieu, you wanted to distinguish registry for methods v registry for properties
13:03:05 <ken> JoeAndrieu: With an eye to compromise, I think there is a difference between method and property name spaces.
13:03:14 <ken> ... They should be treated differently.
13:03:15 <Justin_R> +1 to them being separable, though I'd add they might have the same solution
13:03:31 <ivan> Topic: Extensibility via JSON-LD
13:03:31 <brent> zakim, open the queue
13:03:31 <Zakim> ok, brent, the speaker queue is open
13:03:34 <ChristopherA> provisional, conformance/test available, reference implementation available, live test available, poc available, in production, deprecated
13:03:39 <ken> Topic: DID Doc Extensibility using JSON-LD
13:03:51 <ken> manu: Why might we want to do this?
13:04:10 <ken> ... Add method-specific properties.
13:04:44 <ken> ... Add new service types.
13:05:13 <ken> ... Add cryptographic methods.
13:05:50 <ken> ... Or merge data with Verifiable Credentials.
13:05:50 <phila> q+ to talk about GS1 link types as potential service types (touches on registers convo)
13:07:08 <ken> ... To extend a DID Doc with JSON-LD you define a vocabulary, create a context, and append it to an @context property.
13:07:45 <ChristopherA> q+ on To manu's point, at one point we going to make a DID document, in whole, or partially, a Verifiable Credential. In my prototype, the proof type for my version of these VCs was singed by "SatoshiSignatureProof2009"
13:07:46 <ken> ... A simple single feature would take about an hor.
13:07:48 <jonathan_holt> q+ to ask about cross domain ontologies like dbpedia.org, which is a DAG not a tree structure and classes may have multiple superclasses and handles translation between languages via aliases
13:07:58 <ken> s/hor/hour/
13:08:03 <ChristopherA> q+ to manu's point, at one point we going to make a DID document, in whole, or partially, a Verifiable Credential. In my prototype, the proof type for my version of these VCs was singed by "SatoshiSignatureProof2009"
13:08:32 <ken> ... Using the new context is very simple.
13:08:38 <JoeAndrieu> q+ to point out that innovation is going to come from more than just method implementers
13:08:39 <ChristopherA> q?
13:08:53 <ken> ... There is no formal mechanism, unlike a registry.
13:09:25 <ken> ...
13:09:49 <ken> ... For JSON-only developers, you need to update your schema and validation.
13:10:34 <ken> ... Security may require some restrictions to JSON-LD extensions.
13:10:56 <ken> ... Decentralized extensibility can reduce peer reviews.
13:11:12 <ken> ... Sometimes JSON-LD is too complex for a use case.
13:12:07 <ken> ... Benefits include reduced roadblocks from the workgroup or registry.
13:12:33 <ken> ... Property conflicts are eliminated.
13:13:19 <ken> ... This method of extensibility is compatible with VC data model.
13:13:37 <ken> ... That's it.
13:13:48 <brent> ack phila
13:13:48 <Zakim> phila, you wanted to talk about GS1 link types as potential service types (touches on registers convo)
13:14:02 <ken> phila: I'm with GS1.
13:14:17 <brent> q?
13:14:22 <ken> ... A benefit is that it prevents the reinvention of the wheel.
13:14:23 <mshea> mshea has joined #did
13:14:27 <markus_sabadello> q+
13:14:35 <ken> ... We have a bunch of service types.
13:14:49 <brent> ack on
13:14:49 <Zakim> on, you wanted to manu's point, at one point we going to make a DID document, in whole, or partially, a Verifiable Credential. In my prototype, the proof type for my version of
13:14:52 <Zakim> ... these VCs was singed by "SatoshiSignatureProof2009"
13:15:01 <ewelton> q+ to comment on extensibility biases and restricted scope
13:15:15 <ken> ... I'd like the existent context we have to be useful to others.
13:15:38 <brent> ack jonathan_holt
13:15:38 <Zakim> jonathan_holt, you wanted to ask about cross domain ontologies like dbpedia.org, which is a DAG not a tree structure and classes may have multiple superclasses and handles
13:15:41 <Zakim> ... translation between languages via aliases
13:16:04 <ken> jonathan_holt: I am concerned about cross-domain ontologies.
13:17:04 <manu> q+ to answer
13:17:05 <brent> q?
13:17:12 <brent> ack ChristopherA
13:17:12 <Zakim> ChristopherA, you wanted to manu's point, at one point we going to make a DID document, in whole, or partially, a Verifiable Credential. In my prototype, the proof type for my
13:17:12 <ken> ... Having a single domain be the authoritative source for the context is a potential security issue.
13:17:15 <Zakim> ... version of these VCs was singed by "SatoshiSignatureProof2009"
13:17:28 <ken> ChristopherA: Both DID docs and claims are about the subject.
13:17:52 <ken> ... We had our DID doc be a VC that was self-signed.
13:18:19 <ken> ... A second signature was base on a sitoshi's signature.
13:18:38 <brent> s/sitoshi's/satoshi's/
13:19:19 <ken> ... Extensibility could be provided by VCs.
13:19:19 <brent> ack JoeAndrieu
13:19:19 <Zakim> JoeAndrieu, you wanted to point out that innovation is going to come from more than just method implementers
13:19:49 <ken> JoeAndrieu: The method name space should be considered separately from the property name space.
13:20:20 <ken> ... We will have differences of meaning regarding a property with the same name.
13:20:58 <ken> ... I want less in the did document.
13:21:13 <ken> ... I don't want all the service endpoints in the did doc.
13:21:19 <brent> ack markus_sabadello
13:21:38 <ken> ... If we can reduce the amount of data in the did doc, fewer extensions will be needed.
13:21:55 <ivan> q to ask what types of extensibility do we actually need
13:22:02 <ivan> q+ to ask what types of extensibility do we actually need
13:22:07 <ken> markus_sabadello: Earlier we wanted to avoid registering did methods.
13:22:26 <ken> ... It brings us back to the definition of the purpose of the did doc.
13:22:41 <drummond> q?
13:22:46 <drummond> q+
13:22:59 <ken> ... Is it a minimal document for the did and small service endpoint
13:23:23 <ken> ... Or is it a represent of "me" more completely?
13:23:56 <brent> q?
13:23:58 <ken> ... What happens when the registry potentially gets compromised?
13:24:09 <rhiaro> present+
13:24:39 <brent> ack ewelton
13:24:39 <Zakim> ewelton, you wanted to comment on extensibility biases and restricted scope
13:24:43 <ken> ... Compromising the semantic meaning of properties is also a risk.
13:24:49 <juan_caballero> audio still bad?
13:25:02 <ken> ewelton: What can the did doc represent?
13:25:08 <juan_caballero> markus has a soft voice, eric is speaking pretty clearly and loudly, tho
13:25:16 <brent> good audio: https://zoom.us/j/5593214233
13:25:25 <ken> ... We mostly agree on the core fields, but what about the fields beyond that?
13:25:43 <brent> q?
13:25:46 <ken> ... We can give guidance on how extensibility works.
13:26:10 <ken> ... A set of VCs might be a better way to extend the data in the did doc?
13:26:39 <ken> ... This group has very few women or Asians in it and will reflect our biases.
13:27:03 <ken> ... I am more in favor of the open world model.
13:27:11 <brent> ack manu
13:27:12 <Zakim> manu, you wanted to answer
13:27:22 <samsmith> q+
13:27:27 <brent> zakim, close the queue
13:27:27 <Zakim> ok, brent, the speaker queue is closed
13:27:47 <ken> manu: Responding to "http" for contexts. There are other methods.
13:28:06 <selfissued> q+
13:28:37 <ken> ... re: "I'm concerned about centralization of semantic meaning." Some thought (20 years) has gone into this.
13:28:39 <juan_caballero> https://wiki.dbpedia.org/
13:28:51 <ken> ... Schema.org is an example.
13:29:08 <IdentityWoman> IdentityWoman has joined #DID
13:29:14 <ken> ... You can disagree and put up your own definition.
13:29:23 <drummond> q?
13:29:57 <ken> jonathan_holt: I am struck by the one source of truth and reliance on http protocols.
13:30:25 <ken> ... A centralized model vs. a decentaralized model.
13:30:30 <drummond> I love the "turtles all the way down" analogy - we always  need to keep that in mind with DID documents
13:30:57 <selfissued> q+
13:31:10 <brent> zakim, open the queue
13:31:10 <Zakim> ok, brent, the speaker queue is open
13:31:17 <selfissued> q+
13:31:22 <ken> brent: Can we discuss the remaining queue after break?
13:31:25 <manu> q+
13:31:29 <markus_sabadello> q+
13:31:59 <ken> Topic: Break
13:32:41 <phila> In my defence, burn, I was on a boat when you asked about the boat trip :-) I'd like to be 'in'
13:43:33 <charles> charles has left #did
13:47:22 <Justin_R> Justin_R has joined #did
13:47:31 <ken> ken has joined #did
13:47:41 <drummond> drummond has joined #did
13:47:42 <drummond> present+
13:47:45 <drummond> q?
13:48:14 <juan_caballero> juan_caballero has joined #did
13:48:18 <charles> charles has joined #did
13:48:22 <mxshea> mxshea has joined #did
14:03:21 <brent> q?
14:03:38 <brent> Topic: continued Extensibility discussion
14:03:54 <selfissued> selfissued has joined #did
14:04:13 <brent> ack ivan
14:04:13 <Zakim> ivan, you wanted to ask what types of extensibility do we actually need
14:05:29 <brent> scribe+ yancy
14:05:53 <yancy> ivan: look at dbpedia as the machine readable version of all the media wikipedia has put together
14:06:09 <juan_caballero> metadata*
14:06:11 <yancy> ... if I'm on the linked data world, my data can be combined and put into dbpedia
14:06:27 <yancy> ... there are a large number of these databases
14:06:32 <yancy> ... public domain etc
14:06:40 <yancy> ... you can tthink of it in smaller terms
14:06:41 <brent> q?
14:06:42 <yofukami> yofukami has joined #did
14:06:59 <yancy> ... som vc credentials and all the way of combining data in one credential is what it's all about
14:07:18 <yancy> ... if we have that, and this is a usecase for us, then json-ld can be used for that
14:07:28 <yancy> ... we need to decide on the use-cases
14:07:43 <oliver> oliver has joined #did
14:07:47 <yancy> mike:  does combine mean both from my databases into another
14:07:48 <oliver> present+ oliver
14:07:49 <oliver> q+
14:08:17 <yancy> ivan: imagine this is one big datanase and tyou have a query with all the details
14:08:18 <burn> q+
14:08:31 <yancy> ... just daying that this is a possible use case
14:08:39 <yancy> s/daying/saying
14:08:42 <manu> q+ to mention Veres One, DIDs referring to other DIDs, and merging with Verifiable Credentials.
14:08:43 <JoeAndrieu> q+
14:08:52 <brent> ack drummond
14:09:08 <brent> q+ drummond
14:09:14 <phila> q+ to talk about similar activities
14:09:26 <brent> ack samsmith
14:09:34 <yancy> sam: my suggestion is that we two types of docs that we discuss extensibility for
14:09:48 <yancy> ... this is for the presentation I gave to the wg a week ago
14:10:01 <yancy> ... there are two activities that happened when accessing a did
14:10:04 <brent> s/for/from/
14:10:08 <yancy> ... there are two roots of trust
14:10:23 <yancy> ... cryptographic and infrastructure
14:10:38 <yancy> ... infrastucture is a blockkchain
14:10:59 <yancy> ... and you're dependanct on the distrubuted consouious
14:11:18 <yancy> ... cryptagraphic is one that's signed
14:11:34 <yancy> ... it's a self-cert
14:11:52 <dezell> dezell has joined #did
14:11:59 <yancy> ... some people provide proof in a DID doc
14:12:17 <yancy> ... that type of establishment doesn't need any extensive amount of extensibility
14:12:24 <yancy> ... once you've establehed it
14:12:39 <yancy> ... they are no longer a security vector
14:12:54 <yancy> ... common authorizations can have a line drawn
14:13:03 <yancy> ... can draw at establish auth
14:13:11 <yancy> ... or above service authorization
14:13:51 <yancy> ... arguments for open world or infinite become valid in that case
14:14:12 <yancy> ... I think that's the porblem is that we need to make seperation of concerns
14:14:15 <brent> ack selfissued
14:14:42 <yancy> selfissued: people seem concerned about having qa fixed set of people deciding whats part of the record
14:14:51 <yancy> ... this wg is part of such a group
14:14:57 <yancy> ... we seem to be ok doing that
14:14:58 <brent> s/qa/a/
14:15:12 <brent> ack manu
14:15:12 <Zakim> manu, you wanted to mention Veres One, DIDs referring to other DIDs, and merging with Verifiable Credentials.
14:15:45 <yancy> manu: I think that before we had  a discussion about a layer that's pre-diddocument
14:15:55 <brent> q+ to say merging DID Docs with VCs is probably a terrible idea.
14:15:58 <ewelton> q+ to support sams position and combine it with markus'
14:16:01 <yancy> ... I think the part you're concerned about is what happens before the did doc is crated
14:16:09 <yancy> ... I think we should seperat them
14:16:10 <oliver> q-
14:16:22 <yancy> ... bu I don't know if this group should sepearte them
14:17:03 <yancy> ... I want to point out that its under the extensibiity discussion
14:17:22 <yancy> sam: some extensibility could go into that document
14:17:30 <yancy> ... then you auth an encryption
14:17:42 <yancy> ... if you look at in terms of iot...
14:17:57 <yancy> manu:  there are a lot of other uses cases that come up
14:18:09 <yancy> ... veris one stores did docs
14:18:18 <yancy> ... the ledger is built aroun the mechanizm
14:18:25 <yancy> mechanism
14:18:26 <brent> s/veris/veres/
14:18:53 <yancy> ... we merge data sources on a regular  basis
14:19:05 <yancy> ... there are many times when json-ld is usefull
14:19:25 <drummond> q?
14:19:36 <yancy> ... we also have usecases where some diddocs refer to other diddocs
14:19:47 <yancy> ... in some cases they are associated
14:20:11 <yancy> ... there are use cases that are not yours that are feeding into the desire to have more complex use cases
14:20:13 <brent> ack markus_sabadello
14:20:15 <tplooker> q+
14:20:31 <yancy> markus_sabadello:  json-ld context is a type of registry
14:20:41 <yancy> ... that's not so different then a registry
14:20:51 <yancy> ... it's just ayone can run there own registry
14:21:06 <brent> ack burn
14:21:46 <yancy> burn: from rfc 3968
14:21:57 <yancy> ... basically there is resolution and de-referencing
14:22:12 <yancy> ... slide 93
14:22:44 <yancy> ... in the process of doing resolution we realized there are these things you neede to do
14:23:00 <yancy> ... but there's no requirement that they need to be stored that way
14:23:11 <yancy> ... the did doc was just an idea about this stuff
14:23:20 <yancy> ... and gradually stuff started to be added
14:23:34 <yancy> ... orginally this was just a way to give information that was asked for
14:23:49 <yancy> ... we may have chaned our minds, but this was the original way it worked
14:23:59 <yancy> ... that's why some of us say the format doesn't matter
14:24:11 <brent> q-
14:24:28 <brent> ack JoeAndrieu
14:24:33 <yancy> ... in order to understand the de-ref you need to understand a resource
14:24:44 <yancy> Joe:  I like the seperation of authority
14:24:49 <yancy> .. and what does that mean
14:25:02 <yancy> sam: I think it's a problem with how identifiers are used
14:25:25 <brent> q+ to say merging DID Docs with VCs is probably a terrible idea.
14:25:33 <yancy> Joe: I know this will make you said but to answer the question I think the link is an anti-pattern
14:25:42 <yancy> ... what I care about is I like json-ld
14:25:48 <tplooker> q-
14:25:54 <yancy> ... if ytou need linked then of course you go jsonld
14:26:21 <yancy> ... I need somone to inovated with a service type and a goup of white males that get to decide the future
14:26:28 <yancy> ... and it needs to be not white mails
14:26:34 <brent> ack drummond
14:26:35 <yancy> s/mails/males
14:26:49 <yancy> drummond: slide 93
14:27:03 <yancy> ... consolidates a bunch of things we've been talking about
14:27:06 <yancy> ... the core is the core
14:27:15 <yancy> ... jus like molten is the earth
14:27:16 <tplooker> q+
14:27:23 <yancy> ... to add you need to version teh spec\
14:27:34 <yancy> ... they don't need to use them all but cant becahnged
14:27:46 <yancy> ... next degree is the centralzied base
14:28:15 <yancy> ... I think we could have one tha't both namespaces and key type sercvices
14:28:30 <yancy> ... the point there is it's extension through centralized coordination
14:28:50 <yancy> ... but we know how to do collision free namespaces
14:29:01 <yancy> ... do we have any choice?
14:29:18 <yancy> manu: i'm opposed
14:29:35 <ChristopherA> q?
14:29:36 <yancy> drummond: there's a lot of details there and a lot are really good
14:30:02 <gannan> s/teh spec\/the spec/
14:30:04 <ChristopherA> q+
14:30:20 <brent> ack phila
14:30:20 <Zakim> phila, you wanted to talk about similar activities
14:30:39 <yancy> phila: my carrier in standards begin with a massive failure
14:30:49 <yancy> ... because i was telling people how todo stuff
14:30:57 <gannan> s/becahnged/be changed/
14:31:00 <yancy> ... the one im working is successfull
14:31:15 <yancy> ... extensibility is what makes your standered usefull
14:31:24 <yancy> ... it has a layer of validation
14:31:26 <gannan> s/centralzied/centralized/
14:31:34 <yancy> ... we are going to bolt in on to what we already got
14:31:44 <yancy> ... because I need extensibility and flexibility
14:31:48 <brent> ack ewelton
14:31:48 <Zakim> ewelton, you wanted to support sams position and combine it with markus'
14:31:56 <gannan> s/my carrier in/my career in/
14:31:59 <yancy> ewelton: I like the levels that sam dreew
14:32:27 <yancy> ... there is this idea of what was said that we have methods that have  a mechanism and we wan t a core data model that does that
14:32:37 <manu> q+ to bring up technical concerns, we're still a bit too meta.
14:32:41 <gannan> s/standered usefull/standard useful/
14:32:42 <yancy> ... but then markus said is this a did document of myself\
14:32:53 <yancy> ... so everyhthiong is forming a nice structrue
14:33:04 <yancy> ... and it gives a better definition of the trust mechanics
14:33:12 <yancy> ... and we need it to be crisp[
14:33:21 <yancy> ... and how can we formalize it into a discussion
14:33:30 <gannan> s/sam dreew/sam drew/
14:33:33 <brent> ack brent
14:33:33 <Zakim> brent, you wanted to say merging DID Docs with VCs is probably a terrible idea.
14:33:36 <yancy> ... so how can we capture and strucutre that
14:33:49 <brent> ack tplooker
14:33:49 <yancy> brent: merging did docs and vc is bad
14:34:07 <yancy> tplooker:  if we look at the presentation, jose outlines a bunch of registries
14:34:20 <yancy> ... and created a rpocess to create that core registry over time
14:34:29 <yancy> ... and manu drew a process to open claims
14:34:42 <yancy> ... and openid tokens can be created with new claims
14:34:51 <gannan> s/did document of myself\/did document of myself/
14:35:12 <gannan> s/crisp[/crisp/
14:35:17 <JoeAndrieu> q?
14:35:20 <yancy> ... I want to start creating new claims beyond the did spec that will never be createed
14:35:33 <yancy> ... or Im happy for them to be symantically unambigous
14:35:46 <yancy> ... are we expecting to updated teh core data-=model
14:35:59 <yancy> ... and they updated the context in an editor manor
14:36:04 <brent> ack ChristopherA
14:36:04 <ivan> q+
14:36:29 <yancy> christopherA:  one of your points is theres a distinctiojn about people that just want tthe keys
14:36:37 <yancy> ... and don't care about the establishment
14:36:47 <yancy> ... vs those that care about rotaibilty
14:36:52 <yancy> ... and drummonds thing
14:37:04 <brent> s/distinctiojn/distinction/
14:37:06 <yancy> ... one side is in the direction of how to rotate
14:37:13 <brent> s/tthe/the/
14:37:18 <yancy> ... and the other direction is how to record teh simplest stupidest client
14:37:21 <brent> ack manu
14:37:21 <Zakim> manu, you wanted to bring up technical concerns, we're still a bit too meta.
14:37:31 <yancy> manu: I like what im hearing
14:37:35 <yancy> ... but it's too much meta
14:37:38 <ChristopherA> q?
14:37:43 <yancy> ... we need to get to some discussion
14:37:50 <yancy> ... nothing wrong with the disagram
14:38:00 <yancy> ... I'm just using this as an example
14:38:13 <yancy> ... so that green there the registtry extensiton
14:38:26 <yancy> ... but does the greeen thing make it impossible?
14:38:28 <tplooker> q+
14:38:39 <ChristopherA> q+ on (to respond manu's question of getting more technical) Why does endpoints (for features other than key material) have to be in DID document?
14:38:41 <yancy> ... bu with the green stuff do you require a json-ld context
14:38:44 <samsmith> +q
14:38:54 <yancy> ... if that's not true we havn't solved anytihng
14:39:03 <yancy> ... is that open to the josn-ld folks
14:39:24 <brent> zakim, freeze the queue
14:39:24 <Zakim> I don't understand 'freeze the queue', brent
14:39:29 <yancy> ... it's those kind of specifics, in my head befiore adding to the spec
14:39:31 <brent> zakim, close the queue
14:39:31 <Zakim> ok, brent, the speaker queue is closed
14:39:33 <brent> q?
14:39:42 <yancy> s/befiore/before
14:39:48 <brent> ack ivan
14:39:56 <yancy> ivan: first of all, I will answer
14:40:02 <gannan> s/josn-ld/JSON-LD/
14:40:05 <yancy> ... mainly with some changes coming up
14:40:23 <yancy> ... in will be possible without complication the working group goes to a maintance working group[
14:40:31 <yancy> ... and I know tehre may be version issues
14:40:42 <brent> s/group[/group/
14:40:44 <yancy> ... but if we don't change to structure it will be probably possible
14:40:53 <yancy> ... but what you where saying is interesting
14:41:04 <yancy> ... because there is a parallel
14:41:14 <yancy> .... tehre should be a way to have a spec
14:41:25 <brent> s/tehre/there/
14:41:25 <yancy> .... that has a data exchange modle in teh document
14:41:35 <yancy> ... we have json-ld as possible
14:41:36 <brent> s/modle/model/
14:41:44 <brent> s/teh/the/
14:41:45 <yancy> ... the jsonld would refer only to one single element
14:42:04 <yancy> ... if someone wants to make use fo tink linked data facility
14:42:08 <yancy> ... if no so what
14:42:20 <yancy> ... I can see something come out of this by expecting both sides
14:42:33 <yancy> ... if it is an informatl registry then all bets are off
14:42:43 <Justin_R> q+
14:42:44 <yancy> ... but something like that might be possible\
14:42:46 <brent> ack tplooker
14:42:46 <drummond> q+
14:43:02 <yancy> tplooker:  if you treat the green rign as the expanding core over time
14:43:12 <yancy> ... and others that will never be agreed on
14:43:19 <yancy> ... tehen that sorts everythign
14:43:26 <juan_caballero> (in drummond's diagram) on slide 93
14:43:28 <yancy> ... an you update that context att the ctner
14:43:37 <yancy> ... and because for example
14:43:40 <brent> s/tehen/then/
14:43:51 <yancy> ... if an open-id connect provider and they dont' publisha  spec
14:44:03 <yancy> ... its just informal by starting to emit things
14:44:08 <brent> ack ChristopherA
14:44:08 <Zakim> ChristopherA, you wanted to comment on (to respond manu's question of getting more technical) Why does endpoints (for features other than key material) have to be in DID document?
14:44:10 <yancy> ... so I don't know how it relates
14:44:18 <yancy> Christophera:
14:44:20 <drummond> q?
14:44:35 <yancy> still havent' figured otu why did stuff needs to be in an endpoint
14:44:45 <yancy> ... why am I putting them allin this dag
14:44:54 <yancy> ... progessive thing to get to the key that they want
14:45:00 <yancy> ... they need to prove to me
14:45:16 <brent> ack samsmith
14:45:18 <yancy> ... in bitcoin we are trying to get to a point where no pub keys are revealed
14:45:31 <yancy> sam:  they have a combination that uses a tag based registry
14:45:41 <yancy> ... and its'a symantic overlay
14:45:45 <brent> zakim, open the queue
14:45:45 <Zakim> ok, brent, the speaker queue is open
14:45:48 <yancy> ... and you get the best of both worlds
14:45:54 <ivan> Topic: Metadata
14:46:06 <juan_caballero> props to yancy (but keep going)
14:46:42 <yancy> gannon: I had the pleasure of reading the long issue
14:46:47 <yancy> ... as well as teh rfc logs
14:46:55 <yancy> ... slide 95 is background
14:47:09 <ivan> s/teh/the/
14:47:18 <yancy> ... just want to say dan you've touch on the things i'm taling about
14:47:40 <yancy> ... see slide 97
14:48:06 <yancy> ... slide 98 did doc explained
14:48:37 <yancy> ... the way Ilook at that is theres an object and graph model that relates to that did
14:48:48 <brent> q?
14:48:49 <yancy> ... slide 99
14:49:00 <drummond> q?
14:49:08 <yancy> ... it is the output of calling DID resolve on some did
14:49:19 <yancy> ... and we did that to give full intention to that did method
14:49:31 <yancy> ... slide 100
14:50:16 <yancy> ... we can not make assumptions of how its rooted in a database
14:50:35 <yancy> ... a did doc is not a file in a falesystem
14:50:45 <yancy> ... so when thinkg about did document created
14:50:52 <yancy> ... slide 102
14:51:03 <yancy> ... this can be though of as the same way as a date header
14:51:09 <ivan> q+
14:51:13 <yancy> ... the date that's put on the header and response
14:51:27 <yancy> ... I thikn that's the way we're supposed the think about it
14:51:34 <yancy> ... slived 103
14:51:55 <yancy> ... slide 104
14:51:59 <oliver> oliver has joined #did
14:52:00 <oliver> present+ oliver
14:52:03 <oliver> q+
14:52:05 <drummond> q+
14:52:08 <ivan> s/slived/slide/
14:52:17 <JoeAndrieu> q+
14:52:19 <brent> ack ivan
14:52:28 <yancy> ivan:  I know it will sound like bike shedding
14:52:30 <markus_sabadello> q+
14:52:35 <jonathan_holt> q+ to ask about how to define time universally?
14:52:44 <yancy> ... isn't it time to use something besides a DID document
14:53:06 <yancy> ... the effect of using a did document leads to the discission we're having now
14:53:21 <yancy> chrisphera:
14:53:24 <yancy> there is some history
14:53:32 <yancy> ... thhere was a DDO
14:53:42 <yancy> ... then we started calling it a DID document
14:53:45 <brent> q?
14:53:50 <yancy> ... in my world it needs to be created
14:53:52 <brent> ack oliver
14:53:57 <yoshiaki> s/thhere/there/
14:54:00 <yancy> oliver:  if you read teh date field of http
14:54:04 <manu> q+ to say this "thing" has an identifier, and there is information about that identifier... not information about the information.
14:54:11 <yancy> ... wouldn't this break the proof of the did document
14:54:22 <yancy> ... if they protected it with the proof
14:54:36 <brent> ack drummond
14:54:53 <yancy> drummond:  I want to make the point that you said antything in the did doc must describe the subject
14:55:03 <yancy> ... thre's inforation about the did subject
14:55:10 <yancy> ... should we seperate that
14:55:16 <yancy> ... create date and update date
14:55:34 <yancy> ... are we taling about when the tea pot was made and broken or not
14:55:41 <yancy> ... how do we seprate that
14:55:48 <brent> q?
14:56:00 <brent> ack jonathan_holt
14:56:00 <Zakim> jonathan_holt, you wanted to ask about how to define time universally?
14:56:01 <Justin_R> q+ to update your face
14:56:02 <yancy> Joe: couple things
14:56:07 <brent> q+ jonathan_holt
14:56:12 <yancy> ... need bare witness
14:56:21 <yancy> ... it couldbe a bout a group which I'm a member
14:56:21 <brent> ack JoeAndrieu
14:56:28 <phila> q+ to suggest the spec states that it is inappropriate to seek metadata about the DID-doc
14:56:35 <burn> q+ to ask if DID subject is, officially, the URI resource for the DID scheme
14:56:36 <yancy> ... I don't like arbitrailty sucking everything up because i'm not my did
14:56:42 <Justin_R> s/bare/bear/
14:56:46 <yancy> ... is the controller in charge?\
14:56:57 <yancy> ... then that' metadat
14:57:06 <yancy> ... the reason I said on that update date
14:57:23 <yancy> ... if  a controller wants to update the date abd it took 3 days for bitcoin to get tthe tranasaction
14:57:28 <brent> q?
14:57:30 <yancy> .... did the did conterller say it
14:57:34 <jonathan_holt> +1 to Joe
14:57:40 <yancy> markus:  I wanted to say somethin similar
14:57:45 <yancy> ... in the resolution spec
14:57:47 <brent> ack markus_sabadello
14:57:55 <yancy> ... in the resoltuoin there is teh resolultion result
14:58:09 <yancy> ... to me whats in the did doc can be different for each resolution process
14:58:10 <phila> q+ to suggest the spec states that it is inappropriate to seek metadata about the DID-doc, but can seek metadata about the resolver
14:58:21 <Justin_R> s/resoltuoin/resolution/
14:58:21 <yancy> ... the metadat about the persoin may be different
14:58:31 <yancy> ... changes only when the controller updtes it
14:58:41 <yancy> ... the second thing i wnated to say about created
14:58:55 <yancy> ... I disagree with what gannon said
14:59:06 <yancy> ... I thikng the did document is createx when the did is created
14:59:16 <yancy> ... it may not be stored as a file
14:59:28 <yancy> ... and the resolver retrives it and constructs it
14:59:37 <brent> ack jonathan_holt
14:59:45 <ken> +1 to markus' comments
14:59:47 <yancy> jonathan_holt:
14:59:49 <burn> q+ to ask whether separating discussion into 'did info' vs. 'did doc' would help
14:59:55 <yancy> ... I think time is relative
15:00:05 <yancy> ... the time may be relavant
15:00:11 <yancy> ... was an issue with eth classic
15:00:22 <yancy> ... by jumping ahead in the timestamp
15:00:26 <brent> ack manu
15:00:26 <Zakim> manu, you wanted to say this "thing" has an identifier, and there is information about that identifier... not information about the information.
15:00:27 <yancy> ... and that should be considered
15:00:35 <yancy> manu: wanted to +1 drummond
15:00:43 <yancy> ... there are two thihngs were talking about
15:00:56 <yancy> ... I think it's interesting that joe and I disagree
15:01:05 <yancy> ... I don't think it has any affect on the decision
15:01:28 <yancy> ... and I think markus is write that your framing of whats a crated date is spot on
15:01:34 <burn> q+ to use 'did info' and 'did prez' instead
15:01:41 <yancy> .... that did doc that this group is creating
15:01:46 <yancy> ... it has an identifier
15:01:59 <yancy> ... that I think by and large has information asserted by the did
15:02:12 <yancy> ... and it becomes obvious
15:02:27 <yancy> ... markus example is outside since teh contrller didin't make that assertion
15:02:40 <brent> q?
15:02:42 <yancy> ... this is info asserted by the controller
15:02:48 <drummond> q+
15:02:52 <brent> ack Justin_R
15:02:52 <Zakim> Justin_R, you wanted to update your face
15:02:56 <yancy> ... and there is a clean break about what's data and metadata
15:03:10 <yancy> justin_r: what I observe here
15:03:21 <yancy> ... is that people want to make statemenets about two things
15:03:32 <yancy> ... the document and info that got the document here
15:03:41 <yancy> ... and we don't have a clear way to express that
15:03:49 <yancy> ... and people are getting upset about that
15:03:56 <yancy> ... like the created_at
15:04:03 <burn> q+ to talk about result of process vs. asserted info
15:04:05 <ken> +1 to Justin_R's categorization of the data/metadata
15:04:46 <yancy> ... this is something that is something that needs to fit with the resolution process
15:04:47 <markus_sabadello> q+
15:04:55 <yancy> ... we might be able to define thingss about the did doc
15:05:05 <yancy> ... and however that comes back is up to the method
15:05:07 <brent> ack phila
15:05:07 <Zakim> phila, you wanted to suggest the spec states that it is inappropriate to seek metadata about the DID-doc and to suggest the spec states that it is inappropriate to seek metadata
15:05:10 <Zakim> ... about the DID-doc, but can seek metadata about the resolver
15:05:14 <yancy> ... and theres' lots with response headers
15:05:26 <yancy> phila: I like the thing about how the did doc isnt' real
15:05:35 <yancy> ... and so I wonder if we can state in the spec
15:05:46 <yancy> ... and say it's not appropriate
15:05:57 <yancy> ... and if you need software that depends on that it's wrong
15:06:18 <yancy> ... nobody has asked us about the did doc unless you ask you get redirected to the service
15:06:27 <yancy> ... nobody asked about metada about that
15:06:52 <drummond> q?
15:07:02 <brent> ack burn
15:07:02 <Zakim> burn, you wanted to ask if DID subject is, officially, the URI resource for the DID scheme and to ask whether separating discussion into 'did info' vs. 'did doc' would help and to
15:07:02 <yancy> ... I think this idea that the did doc that only treats it in that way
15:07:05 <Zakim> ... use 'did info' and 'did prez' instead and to talk about result of process vs. asserted info
15:07:19 <yancy> burn: just going to say
15:07:32 <yancy> ... wonder if the did subject is the uri resource
15:07:36 <JoeAndrieu> q+ about URI resource
15:07:44 <yancy> ... keep goin back to rfc 3986
15:07:58 <yancy> ... the resource doen't need to be real
15:08:11 <yancy> ... so did subject and resource doesn't need to be the same thing
15:08:26 <yancy> ... I like the idea of being clearer about sepering process
15:08:28 <Oskar> q+ to what is the purpose of a DIDdoc, what security/trust issue does it address?
15:08:33 <yancy> ... from informatio
15:08:46 <yancy> ... was looking a did info a nd did presentation
15:08:57 <yancy> ... clearly thrers' different levels
15:09:01 <brent> ack drummond
15:09:12 <yancy> drummon:  first point I want to respinod to dan
15:09:22 <JoeAndrieu> q+ to talk about URI as resource
15:09:25 <yancy> ... we do say in the spec the did identifies the did subject
15:09:33 <yancy> ... bucket 1
15:09:42 <yancy> ... not sure how the did subject could
15:09:53 <yancy> ... threre's a metapoint about identfying the did subject
15:10:06 <yancy> burn: a did has a resouvce and that could be anything
15:10:31 <Justin_R> to clarify my statement from earlier for the notes, I actually mentioned three things: data in the document, data about the document, and data about how the document got there
15:10:36 <brent> s/resouvce/resource/
15:10:39 <brent> q?
15:11:10 <yancy> drummond: I wante adress what just says by syaing I agree with him
15:11:16 <tplooker> q+
15:11:16 <yancy> ... metadat describes data
15:11:24 <yancy> ... its really just a graph
15:11:34 <yancy> ... you put a node in the graph of the document
15:11:45 <yancy> ... and under it we put al metadata about the document
15:11:53 <yancy> ... its not rocket science
15:12:04 <brent> ack markus_sabadello
15:12:05 <phila> +1 to drummond
15:12:09 <yancy> ... we're not even sure we're talking about the did subject
15:12:21 <samsmith> q
15:12:24 <yancy> markus: with regard to the resouce
15:12:34 <burn> q+ to talk about making it rain
15:12:40 <yancy> .... sometimes we treat the did as an identifier
15:12:50 <yancy> ... and sometimes we treat as a subject.
15:13:09 <brent> q+ to say we're having trouble with metadata because we have trouble with data.
15:13:24 <yancy> ... final thing I wanted to say is that I agree that it's inline with architecture tor return meta-data
15:13:32 <yancy> ... I just don't like did resolution response
15:13:39 <brent> acl Oskar
15:13:44 <brent> ack Oskar
15:13:44 <Zakim> Oskar, you wanted to what is the purpose of a DIDdoc, what security/trust issue does it address?
15:13:45 <yancy> .. which sounds like client server protocol
15:13:50 <gannan> +1 to DID Resolution Result
15:13:56 <yancy> Oskar:  some of this is confusing
15:14:04 <yancy> ... what is the purpose fo a did document
15:14:06 <jonathan_holt> Time in blockchains is relative:  i.e. The `timestamp` of bitcoin block #180966 is 2012–05–20 23:02:53
15:14:06 <jonathan_holt> The `timestamp` of bitcoin block #180967 is 2012–05–20 23:02:13.
15:14:18 <brent> q?
15:14:28 <yancy> jusin_r: a lot of people are already deploying
15:14:40 <ivan> s/jusin_r/justin_r/
15:14:42 <yancy> ... and coming in to the group we realize there are no defintions
15:14:50 <drummond> q+ to answer what is the purpose of a DID document
15:14:59 <brent> ack JoeAndrieu
15:14:59 <Zakim> JoeAndrieu, you wanted to talk about URI as resource
15:15:22 <yancy> ... I think there are 3 different resources
15:15:29 <yancy> ... the uri as a subject
15:15:35 <yancy> ... once you treate as url
15:15:42 <yancy> ... you're not getting back a subject
15:15:56 <brent> ack tplooker
15:16:03 <yancy> ... if theres a service end-point, you only get back what's seralized and returned
15:16:15 <yancy> tplooker:  if you put a reolver into jus a uri
15:16:28 <yancy> ... is that did itself considered a URL?
15:16:45 <yancy> ... which in my mind is an assertions about the subject by the did controller
15:17:17 <yancy> JoeA:  I think you should get back the whole document
15:17:17 <brent> ack burn
15:17:17 <Zakim> burn, you wanted to talk about making it rain
15:17:24 <yancy> burn:  you may not agree with me
15:17:31 <yancy> ... want to atalk about making it rain
15:17:40 <yancy> ... and if somene else asks what it identifies
15:17:48 <yancy> ... it identifies a subject
15:17:58 <yancy> ... the did subject might be the sku
15:18:09 <yancy> ... so what is the resouce that I'm manipulationg?
15:18:18 <yancy> ... there might be a did for the sku
15:18:43 <ewelton> q+ to talk about the use of dids in conversation as a subject
15:18:51 <yancy> ... I would draw a distinction between the did subnject and the resource
15:18:54 <manu> q+ to note we're dangerously close to HTTP Range 14 and we really shouldn't go there.
15:19:17 <manu> q+ to say someone should define these things and we should put them in the spec. I think we have enough to give that a shot.
15:19:28 <yancy> ... if the did subject is me, and you want to call me it's dan
15:19:35 <yancy> ... I don't have a phone in my brain
15:19:52 <brent> ack brent
15:19:52 <Zakim> brent, you wanted to say we're having trouble with metadata because we have trouble with data.
15:19:53 <yancy> ... and youll call some number that i'm going to answer
15:20:22 <yancy> brent: we are having trouble defining the metadata about the data
15:20:36 <yancy> ... we need to figure that out before we talk about metada
15:20:45 <yancy> ... we need to come to some agreement
15:20:45 <brent> ack drummond
15:20:45 <Zakim> drummond, you wanted to answer what is the purpose of a DID document
15:20:47 <burn> maybe look at items in DID doc and list where they come from -
15:21:03 <yancy> drummond: id love to have time to draw anothr diagram
15:21:11 <yancy> ... there are two dots
15:21:12 <burn> asserted by DID controller, resolution process, etc.
15:21:19 <yancy> ... the did is the label on that arc
15:21:31 <yancy> ... the did subject is whatever that dot is on that arrow
15:21:42 <yancy> ... and for any controller they define what that dot is
15:21:59 <JoeAndrieu> q?
15:21:59 <yancy> ... and if dan says its pointing at the sky, it's whatever dan thinkgs the sky is
15:22:14 <JoeAndrieu> q+ to mention informal knowledge
15:22:18 <yancy> ... in someway it gives us the ability to describe what we thingk something is
15:22:31 <yancy> ... the first dot is teh did controller\
15:22:41 <yancy> ... there dot one
15:22:53 <yancy> ... point two is JoeA as usual is right
15:23:03 <yancy> ... I want to clarify what he's correct about
15:23:13 <yancy> ... when markus and I collaborated
15:23:14 <tzviya> tzviya has joined #did
15:23:28 <yancy> ... and if we get to it we have a proposal of how to clarify that
15:23:39 <yancy> ... the did document is never the subject
15:24:11 <yancy> ... from a web representation, because it's metada, we have this thing markus pointed out
15:24:18 <yancy> ... it's a resouce on the web
15:24:35 <yancy> ... the DID itself is a uri and not a URL
15:24:55 <phila> q+ to argue against /
15:24:57 <yancy> ... if you want to identify the did document you add one character.  or proposal is to add forward slash
15:25:09 <brent> ack ewelton
15:25:09 <Zakim> ewelton, you wanted to talk about the use of dids in conversation as a subject
15:25:19 <yancy> ewelton: +1 to all that
15:25:29 <yancy> ... the thought I had was the did could be anyting
15:25:33 <drummond> q+
15:25:35 <ChristopherA> q+
15:25:43 <ChristopherA> q-
15:25:53 <ChristopherA> q+ to About /
15:25:53 <yancy> ... and if I create a document outside of did land that describes teh seating chart, that's how it will be in the did document
15:26:03 <Eugeniu_Rusu_> Eugeniu_Rusu_ has joined #did
15:26:03 <yancy> ... I may want you to add information about it
15:26:11 <yancy> ... and I don't need heavy crypto
15:26:14 <tplooker> q+
15:26:17 <yancy> ... and I say if I created a did
15:26:37 <yancy> ... I would have control over that and I don't need to establish authrority over that
15:26:43 <yancy> ... it's more like a uuid
15:26:48 <yancy> ... a lightweight di
15:26:54 <yancy> s/di/did
15:26:57 <brent> ack manu
15:26:57 <Zakim> manu, you wanted to note we're dangerously close to HTTP Range 14 and we really shouldn't go there. and to say someone should define these things and we should put them in the
15:27:00 <Zakim> ... spec. I think we have enough to give that a shot.
15:27:04 <yancy> manu: im concerned this is range 14
15:27:19 <yancy> ... http14 is a discussion onging for 20 years
15:27:38 <yancy> ... there is no correct answer and thousands of engineers haven't found an answser
15:27:41 <phila> -> https://en.wikipedia.org/wiki/HTTPRange-14 HTTP Range 14 in Wikipedia
15:27:42 <JoeAndrieu> s/http14/range 14/
15:27:50 <drummond> the Wikipedia page on HTTPRange14 is highly recommended
15:27:50 <yancy> ... the way you escape is someone produces some defintions
15:28:09 <yancy> ... and if its' good enough for a few members, then we move on
15:28:10 <drummond> q?
15:28:17 <yancy> ... you should read about it
15:28:25 <markus_sabadello2> markus_sabadello2 has joined #did
15:28:31 <jonathan_holt> issue #14.  https://www.w3.org/2001/tag/group/track/issues/14
15:28:54 <yancy> ivan: if you have a url against a resouce, and the resouce is a book, what exectly are you referring to
15:28:57 <gannan> q+
15:28:57 <markus_sabadello2> Last year we spent several weeks discussing DIDs and httpRange-14 during the DID Resolution calls. A summary is here: https://docs.google.com/document/d/1gSUP9DEp7IO8jyNDsVnC-7Ed6PjbMRxl89nGYUoWoeI/
15:29:06 <samsmith> q
15:29:14 <samsmith> q+
15:29:39 <yancy> q
15:29:46 <brent> ack JoeAndrieu
15:29:46 <Zakim> JoeAndrieu, you wanted to mention informal knowledge
15:30:01 <yancy> JoeAndrieu: I think we have a proposal
15:30:08 <yancy> ... I think it resolves what we mean
15:30:16 <yancy> ... but lets get the proposal
15:30:23 <ivan> -> HTTP Range 14 discussion https://en.wikipedia.org/wiki/HTTPRange-14
15:30:34 <yancy> ... I want to touch on how we instantiate identity as attributes
15:31:00 <yancy> ... what clicked for me is there's a problem around formal vs informal identity
15:31:13 <yancy> ... whatever the controller defined may not know what it is yet
15:31:24 <yancy> ... I don't need a legal form of identification
15:31:30 <brent> ack phila
15:31:30 <Zakim> phila, you wanted to argue against /
15:31:32 <jonathan_holt> "Tim's argument that HTTP URIs (without "#") should be understood as referring to documents, not cars"
15:31:33 <yancy> ... i'm just trying to figure it out
15:31:50 <yancy> phila: dont do the slash thing
15:32:04 <yancy> ... a query I want the did doc or don't
15:32:09 <brent> ack drummond
15:32:14 <yancy> ... especially if it's just one char
15:32:36 <yancy> drummond: what we did want to do to address manus point
15:32:48 <yancy> ... and we spent 15 years working on the symantic web problem
15:33:01 <yancy> ... we hadn't said there's a huge case for a type that's abstract
15:33:09 <yancy> ... and realized there is a did
15:33:21 <manu> q+ to note developers are going to screw this up :(
15:33:25 <yoshiaki> s/symantic web/semantic web/
15:33:32 <yancy> ... and a defintion can evolve over time and that we pull symantic naming over dids
15:33:49 <yancy> ... and fantastic we can get to more sophistaicated ways about symantics
15:34:02 <markus_sabadello> q+
15:34:10 <yancy> sophisticated
15:34:32 <yancy> ... if there are addional buckets, we can agree on the metadata
15:34:32 <brent> ack ChristopherA
15:34:32 <Zakim> ChristopherA, you wanted to About /
15:34:36 <ken> q+
15:34:52 <yancy> christophera: hopefully dids will never be seen by a user
15:35:15 <yancy> ... but another chanallange where i've dealt with the slash at the end
15:35:31 <yancy> ... that will translate to xml
15:35:47 <yancy> ... the pattern we've seen has been challanging
15:36:00 <ken> s/chanallange/challenge/
15:36:04 <yancy> s/challanging/challenging
15:36:06 <brent> ack tplooker
15:36:18 <yancy> tplooker: was going to make the point about what the difference would be
15:36:28 <yancy> ... trying to tease out the details to the developer
15:36:41 <yancy> ... and to resolve it you need to add a slash
15:36:57 <yancy> ... would not give merit by confusing the developer
15:36:58 <brent> ack gannan
15:37:08 <yancy> gannon: want to make sure this issue moves forward]
15:37:37 <yancy> ... feels like there's some precuruser about what gets put in a did document
15:37:59 <burn> q+
15:38:07 <yancy> ... and if theres agreement I take input and try to bring it back to the group to resolve
15:38:08 <brent> ack samsmith
15:38:08 <JoeAndrieu> q+ to say registration is a meta-data bucket
15:38:10 <drummond> +1 to Ganesh's proposal of how to move forward
15:38:15 <Justin_R> +1
15:38:19 <markus_sabadello> +1
15:38:21 <yancy> sam: I used a functional description
15:38:37 <yancy> ... we have established did documents
15:38:53 <yancy> ... then you go to binding of identify and you have circular definition
15:39:07 <yancy> ... you first have to verify the did document has not been tampered with
15:39:16 <burn> q+ to ask group to look at where each element and potential element of a DID doc comes from
15:39:20 <yancy> ... and we don't have a clear understanding of what a did document is
15:39:35 <yancy> ... anthing in my locus of controll is in my locus of controll
15:39:53 <yancy> ... any infomration that I put information in
15:40:13 <yancy> ... when I see these discussions about metatdat I want to pull my hair out
15:40:15 <brent> ack manu
15:40:15 <Zakim> manu, you wanted to note developers are going to screw this up :(
15:40:21 <manu> 1. A DID is an identifier that identifies a resource.
15:40:21 <manu> 2. Dereferencing the DID gives you a DID Document.
15:40:21 <manu> 3. A DID document is the resource that is associated with a decentralized identifier (DID).
15:40:21 <manu> 4. A DID document contains information asserted about the DID by the controller of the DID.
15:40:22 <manu> 5. Any information that isn't asserted by the controller of the DID (i.e. metadata about the DID Document) is placed elsewhere.
15:40:26 <yancy> ... because we don't have a way to know if its been tampered with
15:40:46 <oliver> oliver has joined #did
15:40:48 <yancy> manu:  not syaing this is the right language but we should go through that on github
15:41:31 <drummond> q+
15:41:32 <burn> no to number 3
15:41:34 <JoeAndrieu> q+ to say #1 is wrong
15:41:46 <burn> we MUST NOT make the DID document the resource
15:42:05 <brent> q?
15:42:18 <brent> ack markus_sabadello
15:42:21 <ChristopherA> q+ to respond to Manu's list, in particular item 4
15:42:26 <phila> q+ to ask if 4 is really correct? Isn't it about the resource the DID identifies
15:42:27 <yancy> markus: I wanted to say a few more things about the slash
15:42:57 <yancy> ... some times we treat is and identifer for the document
15:43:08 <yancy> ... when we use a fragment
15:43:09 <burn> For the minutes, manu confirmed that #2 meant to say "Resolution" instead of "Dereferencing"
15:43:16 <yancy> ... some of this is reflected here
15:43:29 <yancy> ... the first one makes it sound like and identifer for the subject
15:43:40 <yancy> ...3 sound more like indifier for did document
15:43:53 <yancy> ... are we ok with someimes we use for both
15:44:09 <yancy> ... usually theres a very strong reaction
15:44:11 <drummond> Drummond is NOT okay with conflating the resource that is the DID subject and the resource that is the DID document
15:44:15 <brent> ack ken
15:44:18 <yancy> ... one for subject one for did doc
15:44:27 <JoeAndrieu> q+ to say a tool is sometimes defined by how it is used (hammer)
15:44:31 <yancy> ken: I think it's useful to talk about what types
15:44:40 <yancy> ... are there other types
15:44:55 <burn> q+ to say absolutely not to #3
15:44:58 <brent> ack burn
15:44:58 <Zakim> burn, you wanted to ask group to look at where each element and potential element of a DID doc comes from and to say absolutely not to #3
15:45:02 <JoeAndrieu> q
15:45:14 <yancy> burn: along the lines of what ganon says
15:45:23 <yancy> ... look at them and see where they come from
15:45:31 <yancy> ... and what we want is the bukets
15:45:43 <brent> s/bukets/buckets/
15:45:44 <yancy> ... start with the buckets and say how does that get there
15:45:50 <markus_sabadello> q+
15:46:02 <yancy> ... unless we look att the specifics were never going to reach a decision
15:46:08 <yancy> ...im with markus
15:46:15 <yancy> ...the document is not the resouce
15:46:15 <manu> q+ to note that we can take this to a PR now and probably make progress... maybe.
15:46:24 <yancy> ...its information about the processing
15:46:28 <drummond> Drummond wants to argue passionately that the root of the DID document is the DID subject, and that all direct properties of the root describe the DID subject. To describe any other "bucket", add another property to the DID document that we define in the spec represents another resource (e.g., the DID document), and then have subproperties of that describe that resource.
15:46:37 <yancy> ...im willing to say its about the subject
15:46:40 <brent> ack JoeAndrieu
15:46:40 <Zakim> JoeAndrieu, you wanted to say registration is a meta-data bucket and to say #1 is wrong and to say a tool is sometimes defined by how it is used (hammer)
15:46:48 <yancy> JoeA: 1 and 3 are wrong
15:46:57 <brent> zakim, close the queue
15:46:57 <Zakim> ok, brent, the speaker queue is closed
15:47:04 <yancy> ...human is not a resouce teh way the web thinks about resouce
15:47:15 <yancy> ...so I think the way you use a tool can define that tool
15:47:23 <brent> s/teh/the/
15:47:25 <yancy> ...a hammer could be a tool or a weapon
15:47:56 <yancy> ...it echos what I said earler that we don't have clear distinctions
15:47:57 <jonatha__> jonatha__ has joined #did
15:48:08 <yancy> ... if you auth it doesn't mean you control the document
15:48:24 <brent> q
15:48:28 <drummond> Drummond also reminds himself to talk about a third role in addition to "DID subject" and "DID controller", which is "key controller"
15:48:42 <yancy> sam: we have a circular definition
15:48:47 <brent> ack drummond
15:48:59 <yancy> drummond: discovered a new extensibility section
15:49:39 <yancy> ... want to put in a plea to keep the did subject as just the resouce identified by the did
15:49:51 <yancy> ... the uri url urn distinction
15:50:03 <yancy> ... we need to identify the way things are on the web
15:50:20 <burn> Disagree STRONGLY with Joe.  Don't confuse the group by suggesting that return of an artifact somehow just makes it the resource.  This may be theoretically interesting to say, but it just turns the DID into a normal URL that references a file called the DID doc.
15:50:20 <yancy> ...where it gets tricky is they way you want to identify things
15:50:28 <ChristopherA> q+ to (concern to limit purpose as minimal to authentication OR control authority — I could maybe argue that maybe there needs to be 2 did documents, one for each)
15:50:40 <yancy> ...then at least we can take a point and say what is identifying is the subject or any other bucket
15:50:58 <yancy> ...if you look in the abstract data model, and the root of the tree is a subject
15:51:10 <brent> q?
15:51:12 <yancy> ...we are going to establish properties
15:51:51 <yancy> ...theres a did subject, controller and a third role
15:52:06 <yancy> ...someone could auth using data that's not the subject or controller
15:52:12 <yancy> ...and I call it the third roll
15:52:19 <yancy> ...the key controller
15:52:23 <burn> s/third roll/third role/
15:52:34 <brent> ack ChristopherA
15:52:34 <Zakim> ChristopherA, you wanted to respond to Manu's list, in particular item 4
15:52:47 <yancy> christopherA:
15:53:12 <yancy> ... so I really want to limit the purpose to as minimal as necessary
15:53:25 <yancy> ...we use a backslash for one and forward for the other
15:53:43 <yancy> ... I get more territory for other stuff of developers putting in PII
15:53:59 <yancy> ...you want to do teh min for the buisness purpose
15:54:23 <yancy> ...if its a control app that allows ocap to work
15:54:25 <ivan> q+
15:54:30 <brent> ack phila
15:54:30 <Zakim> phila, you wanted to ask if 4 is really correct? Isn't it about the resource the DID identifies
15:54:31 <yancy> ...that very first step is all I want
15:54:52 <yancy> phila: #4 contains info about the did, and surely it's about the did subject
15:55:06 <yancy> ... we need to be clear about what we're describing
15:55:16 <yancy> ...that's what range 14 ended up with
15:55:30 <yancy> ...and whne you resovle tahat you end up with a 303
15:55:48 <yancy> ... you need to be more explicit about that
15:55:57 <yancy> ... I think drummond came up with 3
15:55:58 <JoeAndrieu> suggested fix for 4: A DID document contains information asserted by the controller of the DID. separately, we have the issue of limiting the data in the doc
15:55:59 <manu> q+ to argue for semantic ambiguity when it comes to HTTP Range 14
15:55:59 <brent> ack markus_sabadello
15:56:07 <yancy> ... and drummond came up witha 4th
15:56:11 <JoeAndrieu> q+
15:56:24 <yancy> ivan: if I have a did that I established for myself,c and I use it
15:56:36 <yancy> ... to make assertations about my name
15:56:48 <yancy> ...no that did is only referring to me and never anytrhing else
15:57:03 <yancy> ...that identifier will have it's own life, for example like on the web
15:57:07 <brent> ack manu
15:57:07 <Zakim> manu, you wanted to note that we can take this to a PR now and probably make progress... maybe.
15:57:20 <yancy> maun: that was the discussion I was hoping for
15:57:28 <yancy> ... no chair tossing yet
15:57:31 <burn> s/maun:/manu:/
15:57:44 <yancy> ... at least we can have a discussion about that
15:57:58 <yancy> ... want to discuss semantic ambiguity
15:58:19 <yancy> ...developers always screw it up, they only copy the base.
15:58:29 <yancy> ...we have it working well
15:58:41 <yancy> brent: this WG is awesome
15:58:57 <yancy> ... we've talked about a lot of things to do
15:59:40 <yancy> ... this last 1.25 hours has made us look at different things. back when we talked about DDOs we looked back and decided that want right
16:00:04 <yancy> ...lets get a PR that gets a refinement about what we did
16:00:19 <ivan> zakim, end meeting
16:00:19 <Zakim> As of this point the attendees have been burn, tplooker, selfissued, gannan, drummond, manu, brent, ken, yancy, Oskar, ewelton, yoshiaki, ChristopherA, JoeAndrieu, oliver, ivan,
16:00:23 <Zakim> ... markus_sabadello, jonathan_holt, SamSmith, phila, identitywoman, rhiaro
16:00:23 <Zakim> RRSAgent, please draft minutes
16:00:23 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/29-did-minutes.html Zakim
16:00:25 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
16:00:29 <Zakim> Zakim has left #did
16:01:28 <ivan> rrsagent, bye
16:01:28 <RRSAgent> I see no action items