Jonathan Holt: Jonathan holt (aka jonnycrunch) is the scribe ✪
Jonathan Holt is scribing.
Will Abramson: I also have never managed to connect - from Edinburgh :( ✪
Topic: Introductions and Re-introductions
Jonathan Holt: Hi Jonathan Holt, clinical geneticisct physician, startup founder (TranscendX) credentialining, health records. Also named Chair of WG for IEEE - DLT technologies in healthcare, focused on identity. [scribe assist by Manu Sporny] ✪
Christopher Allen: Linked data key format reqistry needs a repo (new home) do we have any volunteers? ✪
Kim Hamilton Duffy: We have a link in place but it is going in DID spec repo. We probably went thru the process. Kim will set it up and will need to close the issue. Does anyone know who has the files? ✪
Manu Sporny: What we are trying to do with the linked data format is key format. I think all we need is the suite format. Don't think we need another repo. just need one registry format and signature format update the table? ✪
Manu Sporny: It would be great if someone could pick it up. we need the crypto suite updated first. looking for volunteers ✪
Kim Hamilton Duffy: I think manu is responding to 56 not 42. I will make a note and close it out. Manu: agree ✪
Topic: DID Issue Review
Christopher Allen: The remaining time is regarding Michael Herman, bunch of changes, suggestions. some were problems lacking document, or draft is not up to date. he then posted 4 key questions ✪
Christopher Allen: First one is #157. the underlying purpose .. have we really defined our underlying audience. ✪
Michael Herman: I think the thing to focus on is who is the audience? My background in blockchain dev, I wanted to use these for non-fungible entities. but it wasn't permeable . Is it for software devs? Once with understand who it is then is the DID a lower level technology. we need a high level of precision. ✪
Kim Hamilton Duffy: I have to drop early today, at the 30 minute mark ✪
Drummond Reed: Finding mute button .. Even though the first audience was very broad around self-sovreinty. Audience is broad, not just developers. there are people who won't implement the spec, but would be involved. Manu is a past-master of the spec. dive down into the spec ✪
Michael Herman: Not talking about the details of the spec. but where is the spec going (bow of the ship) ✪
Michael Herman: Can't be precise without understanding where it is going ✪
Drummond Reed: The primary target audience is "implementers". ✪
Manu Sporny: If we had to pick one it would be developers ✪
Drummond Reed: BTW, I think Manu is one of the best in the business at doing what he just said—writing understandable specs. ✪
Manu Sporny: There are enormous about of details for implementers, but we write it in a way that could be readable and get an general understanding followed by more details and can write interoperable software. Reason why you might not follow is we haven't done the documentation. need more work on introduction for broader audience. ✪
Manu Sporny: @Drummond -- aww, thanks buddy :) -- thrilled to be working w/ a great communicator such as yourself as well :) ✪
Kim Hamilton Duffy: That is great context Manu, thanks. I want to work that into an FAQ ✪
Christopher Allen: Some of the people who are reading the spec are managers. other don't like blockchains or other assumptions. I had discussion with colleague and he missed really important concepts. We need to be better and make it more approachable. ✪
Michael Herman: Chris, this is a good dovetail to the next issue #158 ...which talks about scope ✪
Justin Richer: With my experience in writing spec. you need to approach it with and engineering hat, precision and focus. It is very tempting to use standard spec to make a point regarding greater vision. I would very strongly caution the group to not spend time on dense philosophical arguement, rather than just building it. ✪
Christopher Allen: We are finding balance. moving on to the scope of normative issue #158 ✪
Christopher Allen: When do we say it is out of scope and need to re-think the approach. ✪
Michael Herman: It was update just in the 30 min. ✪
Michael Herman: What you see in the diagram is "indy sovrin ... whole ecosystem". frame the work for normative discussion. ✪
Michael Herman: We have been talking about the direction. separating the ID from the ?? ✪
Manu Sporny: The ecosystem can get large very quickly. we should focus on the core. "what is informative and what is normative?" ✪
Michael Herman: What is normative and in scope and what is informative and out of scope. back to restucturing. ✪
Manu Sporny: Expectation, beginning of the spec is for grounding. next section talk about DID, and why a DID url. what you get back is a normative model and what features you get back. after that we will talk about concrete syntax, then DID method spec. if you write a DID method spec it is very difficult to write. When it get to W3C, if it doesn't boil down to a test then not normative. we want very specfic specs there. the DID spec won't talk about ??? ✪
Michael Herman: If people have feedback on the diagram at the bottom of https://github.com/w3c-ccg/did-spec/issues/158, Drummond and I and others are discussing it here: https://github.com/w3c-ccg/did-spec/issues/151 ✪
Manu Sporny: The question is "is this a good place to end up?" ✪
Drummond Reed: I do feel the benefits now rather then when we first wrote it, i think our ability to define what the DID spec needs to do. For example URI analogy, the difference they all are identifer specs. it is in scope to define what the DID method spec need to do, define the socpe of the DID method spec. line will be clearer. hope to get some work done at RWoT. ✪
Michael Herman: The devil is in the details. any feedback on issue #158 and #151 ✪
Christopher Allen: Moving on the #151, data model. we don't name it. there has been some comments in the list and issue regarding DID and DID doc that is causing some confusion in the community ✪
Drummond Reed: Just to clarify, I was saying that there is a clear analogy between the URI spec as a generic spec from which others create specific URI scheme specs and the DID spec as a generic spec from which others create specific DID method specs. ✪
Michael Herman: It is about the DID data model. the conversation wandered. I'm satified that we are going to have this data model. save the rest of the conversation of another time ✪
Manu Sporny: Regarding Data Model: I don't think we had clarify on the data model and syntax regarding how it all fits together. we have some more clarity now and the group feels happy were we ended up. intro discussed broad concepts. Lessons were learned after writing this mostly needs testing to pass muster with w3c. if you look at this spec you can get what we are working towards ✪
Manu Sporny: +1, That's a discussion we need to have. ✪
Michael Herman: I'm cool with that. I've added a comment. Can DID be used without DID documents? There is a strong case for using DIDs without DID docs. ✪
Christopher Allen: Issue #155 and #159. is it a URL, URI. it really comes back to the DID document. one is created implcitly. With Bitcoin, everything come from the blockchain. not the endpoints, yet, it always creates something. Who is the consumer of the DID document? Who is the creator of the DID document? ✪
Michael Herman: The backend of #151 is a good primer for the conversion. End to end Alice get a job, transcipt. soup to nuts that uses DID but don't use the DID document. There is a 7 layer model. I'm questioning the DID is only relevant with DID document. ✪
Drummond Reed: +1 To dlongley's point that the term is "DID document". We no longer call it a DID Object or DDO. ✪
Dave Longley: "Generation of a DID document from a DID" is just another way to do "resolving" ✪
Dmitri Zagidulin: It's /still/ a DID Document, even if it's like a data: url ✪
Manu Sporny: We are having a mismatch. Have heard the argument. maybe there is an argument that the DID document can be generated via an algorithm. there are difference use-cases. we are not on the same page yet. what should you be able to do with a DID? ✪
Drummond Reed: I do NOT like the term "Verifiable DIDs". ✪
Manu Sporny: +1 To not be unnecessarily exclusionary -- we want broad applicability for these things. ✪
Drummond Reed: I will argue very strongly against it. ✪
Dave Longley: Another note about the history of DIDs -- the first implementation some ~5 years ago did consider key rotation, however, bringing in CIDs a few years later as a way to cryptographically "claim" a DID really helped complete the design. ✪
Michael Herman: I agree with Manu, my main point. we should not be exclusionary . This 7 layer model enforces this approach. in layer 3, addresses the middle ground. I think we can be more inclusive on all of these things. ✪
Michael Herman: Thank you for the great discussion "this morning" ✪
Drummond Reed: I will be on the absolute warpath against adding that modifier, because it completely destroys the core meaning of a DID. ✪
Christopher Allen: Good points. where we draw the line. ✪
Christopher Allen: Another plug for RWoT post a topic. ✪