Meeting minutes
<swcurran> +
Agenda Review, Introductions
burn: Agenda for today, announcement from PA, DID Core issue/PR processing, rest of time is DID Resolution issue/resolution PR processing. Any request for changes
<KevinDean> I've messaged Joe to see if he can join.
manu: Let's introduce the controller concern brought in VCWG yesterday.
<KevinDean> To discuss the controller concern.
burn: Ok, we can add
<KevinDean> He will join shortly.
burn: Any introductions?
<TallTed> ack
bparth24: Hi, this is my first DID WG meeting, with Moby, started career as software engineer and transitioned into technical product management, software development teams from POC to launch, worked in different verticals, healthcare, supply chain, finannce, and now Web3 decentralized identity related and VC related. Nice to meet you all.
bparth24: I joined based on my own interest, not on behalf of Moby here.
burn: Are you joining as an individual?
bparth24: Yes
TPAC Topic Announcement
burn: You're welcome to participate as an observer today, please contact Pierre-Antoine to talk about Invited Expert status.
<burn> w3c/
burn: We've started putting together an Agenda for TPAC, if you have any other topics that you'd like to request, if you have new DID Features to share with the group, add yourself to the Github issue in IRC. It's important that we get that in, we're going to try to finalize the Agenda next week.
DID Wg site migration
burn: Pierre-Antoine, would you like to discuss this?
<pchampin> https://
pchampin: Historically, the WG home page has been managed by Ivan at the address above.
<pchampin> https://
pchampin: It's a generated website, in the meantime, the W3C infrastructure has evolevd quite a bit, and we have the page above that's automatically generated, containing most of the information that we have on the home page.
pchampin: The suggestion is to decomission the old webpage and favor the new one because it's generated automatically and because the old page requires manual intervention from team contact. We switch from specific minutes generation tool by Ivan to the one provided by W3C, minutes generated from IRC bots that anyone can generate/edit. This is the suggestion.
pchampin: We will lose some features, like full names for individuals. I believe there would be more value in using W3C infrastructure because it makes many people and chairs/contact able to update information. We'll do the migration soon, unless someone objects.
ack
<Zakim> manu, you wanted to ask about minutes inclusion in Github issues.
manu: it was nice being able to see which issues were discussed
pchampin: no. There is a new bot that does something similar, but not as nice.
pchampin: It does not have that feature. Note that recently this has not been activated, one part of Ivan's tooling that I'm not familiar with. We haven't had that for a while.
pchampin: If I have to spend time on getting it working, more useful to get it integrated than continuing to use other tooling.
<TallTed> https://
manu: one of the valuable features of Ivan's tool is the inclusion of meeting in the github issues being discussed. Is this part of the W3C tooling?
TallTed: That bot is the Github bot and here's the web page. I don't know if it's official W3C tooling, but it's running on W3C IRC server.
manu: Ok, +1 to migrating and +1 to integrating ivan's feature into the W3C tooling
burn: Ok, no volunteers to integrate the feature yet, but agree that it's valuable.
DID Core Issue/PR Processing
manu: we've got 3 PRs in DID core.
w3c/did-core#813
manu: I believe that we addressed TallTed's concerns, and I believe that JoeAndrieu responded with an ok.
<JoeAndrieu> +1 to merge
manu: Just wanted to double check before I merge.
TallTed: Yes, I believe that's fine.
manu: good, we can then merge.
w3c/did-core#852
manu: we don't have any reviews on this one yet. We need more reviewers.
… I'll try to tag folks.
… We may want to add a default set of code reviewers. Otherwise, people forget to tag people and don't get reviews.
<ivan> FWIW +1 for Multibase, it is in line with the "sister" work at VC
decentralgabe: I'll take an action to setup the github repo.
w3c/did-core#858
manu: we got positive reviews on this. It's been out there for 2 weeks.
… Merging unless there are any objections.
… Do we want to do issue processing?
burn: we have a new topic, so rather not.
DID controller update from VCWG
manu: a discussion came over about what the controller field means in the DID/controller document.
… There are some misalignments which we need to discuss, though not necessarily today.
<Zakim> JoeAndrieu, you wanted to say I think we can get there
JoeAndrieu: I agree, it's a bit of a mess on how we're talking about it and what led to David Chadwicks concern, I think we can get there, patterns that people have used that we don't have consensus on... DID as value of controller field, pattern is not in sync w/ proposals -- reverse the patterns, think about it more clearly to figure out how to use this stuff.
manu: This is just a request to the Chairs to coordinate w/ the VCWG Chairs to figure out where the discussion happens.
DID Resolution Issue/PR Processing
burn: Markus is still on leave, anyone familiar with issues/PRs to walk us through them.
Wip: I could walk us through some of it.
w3c/did-resolution#84
Wip: This is the reverse of the one Manu just talked about, moving content from DID Core into DID Resolution.
Wip: We need more reviews on this, but it's the sister PR to the one we just merged on DID Core.
w3c/did-resolution#49
Wip: Markus is requesting changes, there are merge conflicts.
w3c/did-resolution#83
Wip: This is about HTTP binding in the spec. Is this something we should have in the spec? How will we want to change it?
manu: We should have HTTPS be one of the mandatory to implement interfaces, library interface being the other one, and implementers need only implement ONE of those. It's useful to use HTTPS for the test suite and it won't be throw away code for developers.
<Zakim> JoeAndrieu, you wanted to support MTI https binding
JoeAndrieu: I'm a big supporter on mandatory to implement for HTTPS binding, because that's how we integrate with the Web. Elika mentioned a view as being by "anything you can get to by a URL" or by a browser, if we can provide a way that any conformant DID Method provides an HTTP accessible interface in an implementation somewhere, then we can have software components that can get standard DID Document data.
JoeAndrieu: I think think is how we get cross-method interoperability, wanted to try to put a definition of that out there.
manu: with a concrete HTTPs bindings, and with us being able to assert that there are features that are shared across DID documents, we would be able to argue this is cross-method interop.
… It might be good to write down what we believe is cross-method interop, so that we can point people to that.
<Zakim> JoeAndrieu, you wanted to say I think the semantics are a form of extensibility, and so there will always be gaps in cross-method interop
decentralgabe: Chair hat off, I do think that cross-method interop does mean accessing/using properties across DID Methods consistently, I don't think they all need to be the same, but some understanding on how some properties are used. For example, class of controllers that apply to some DID Methods, different set for others. Property that has certain type and same understanding in other DID Methods. This should be communicated clearly so people
accessing docs can do that interoperability.
JoeAndrieu: I think the semantic meaning of properties is we need two features of 1) shared understanding of common properties, and 2) extensibility architecture. If we have those two, you will have some DID Methods that extend in some direction, but not everyone needs to extend in that direction.
JoeAndrieu: Our job is to figure out what are the properties that should work in every DID Method.
Wip: This is a great discussion, but Chairs are intending to discuss this at TPAC. Keep in mind that we're going to work on this at TPAC.
Wip: Any other comments before we move on?
w3c/did-resolution#82
Wip: What are the serialization of the results from DID URLS / dereferencing -- dependency on our decision on the abstract data model?
Wip: I think he's saying "we need concrete output"
Wip: And perhaps it needs to be JSON-LD
manu: I wouldn't say the serialization needs to be JSON-LD.
… we need a concrete serialization. If we do HTTPS, we need to define what concrete syntax goes in the request and in the response.
… Fundamentally, the request and response are JSON.
… Some responses need to be a valid DID document, some can be JSON, other can be JSON-LD.
… It feels to me that we are not going to get rid of the abstract data model, and because of that it makes our decision on the concrete syntax harder.
… At least it should be JSON. The good thing is that JSON-LD can be represented in JSON.
… But I don't think that resolver will have to do any JSON-LD processing.
smccown: I have a general question that's relevant to this discussion, every group I go in, we have this "JSON vs. JSON-LD" question, I'm comfortable with either. Specific question, if you have a JSON-LD item and it links in another item, when first item is signed, we don't always put those linked items under the signature, which means you're signing an object that are important but can't be signed, because target of the link can change.
smccown: Some notable examples of that recently. I'm not saying I don't want to use JSON-LD because of that; how do you handle that situation?
smccown: How do you validate the links under the signature?
https://
manu: we had that discussion about the VC data-model.
… We have a solution to that called "related resource" (link above).
https://
manu: To be clear: it only strongly works in JSON-LD. JSON does not have any link semantics.
… You can reliably sign all objects that are linked to -- alternatively you can retrieve the data you are signing.
… The same thing could be applied to DID documents. Hopefully that answers your question.
smccown: That is awesome, thank you so much. Is this required/normative?
manu: there are plenty of times where you don't want to sign the things that are pointed to (e.g. pointer to a logo, that may be refreshed).
… So it is not a good idea to mandate that everything is signed.
… Applications should make the decision to sign externally linked resources or not.
smccown: Ok, yes, that answers my question. Is it well known that linked items are signed or not?
manu: no. You are largely asking application dependant questions. The VC data-model and DID core specs don't go into that level of details.
… Typically you would go together with other implementers of your use-case area, and make an additional specification (this is the allowed cryptography, c14n is done that way...).
… But we work at a more generic level.
smccown: Ok, thank you.
Wip: Take a look at issues, 80 and 83 where Markus is trying to get some feedback.
VCWG recharter
<ivan> https://
ivan: The VCWG recharter call went out yesterday, if you are an AC Rep, please vote, if you are not, please tell your AC rep to vote. If you have already voted, good job! :)
Next Up
burn: Anything else that needs to be brought up today?
burn: Thanks to PA and manu for scribing, we'll chat again next week!