The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back

Credentials CG Telecon

Minutes for 2019-02-05

Christopher Allen: Hmm, the gateway phone isn't answering
Vaughan Emery: Vaughan+
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]

Topic: Announcements and Reminders

Christopher Allen:
Kim Hamilton Duffy: Folks who can't connect: if you already have a SIP client, can you try connecting via sip:ccg@
RWoT 8 in Barcelona, Spain
Ryan Grant: Present- cannot connect to audio
There is a public meet-up Thursday night, VCWG face-to-face march 4-5th
Christopher Allen: IIW coming up in Mountain View
Drummond Reed: Dan,this Drummond, I'm planning on attending
Dan Burnett: Please contact us in CCG or VCWG if you are interesting in attending

Topic: Work Item Review

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?
Christopher Allen: Please respond to the issue.
Christopher Allen: Still open PRs. "Kim is there intent to address them?
Kim Hamilton Duffy: I think we can close it out. We have been closing them as needed.
Christopher Allen: "Manu: what is the status?"
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
Michael Herman: ...Normative ...informative...
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 ???
Markus Sabadello: Reminder: DID Resolution kickoff call, 7th Feb 2019, 9pm Vienna CET = 3pm US Eastern = noon US Pacific,
Michael Herman: If people have feedback on the diagram at the bottom of, Drummond and I and others are discussing it here:
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
Christopher Allen: &
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.
+1, This an important foundational concept here
Michael Herman: What do you mean by DID Object?
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"
Drummond Reed: +1
Dmitri Zagidulin: Yeah, +1 to that
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?
Markus Sabadello: DID Resolution draft has some early thoughts on this in the Introduction:
Drummond Reed: Thanks Markus
Christopher Allen: There is history Drummond and I created a CID just with the key, but missing key rotation. old language keeps coming in.
Ken Ebert: If DIDs are about control and proving ownership, if you are removing .... need namespace resolution
Dave Longley: Notes that you can delegate where the keys come from for that
Ken Ebert: But if you waterdown the DID and remove the neceessity for the description of the key it removes the main purpose of the DID
Manu Sporny: +1 To control of an identifier! :)
Dan Burnett: +1
Dave Longley: <-- delegating the "controller" for the identifier to another DID document.
Drummond Reed: Control of the identity is not the control of the identifier
Dave Longley: +1 Control of an identifier
Drummond Reed: DIDs future is extraordinary and we don't want to lose it
Brent Shambaugh: +1 To talking more about this
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.
Moses Ma: Bye everyone!