Meeting minutes
wip: Special topic call yesterday, first of the year. Light agenda today. did:core, PRs, etc.
manu: Want to go over administrative issues.
mic bowman: From Intel, joining to represents Intel's interests.
DID Core
<manu> w3c/
manu: The first thing is administrative. This is our DID core repository, doesn't match title. We have published the controlled identifier document. We have made the decision to call it controlled identifiers, or CID.
… We want to rename this to just DID, and rename the source repository to match.
ivan: DID Core currently on TR is the recommendation. When do we plan to publish DID Core or DID?
… I think the right time to do all these things is when we do that.
… Then we can put the right history.
… It will be DID 1.1.
… Will the history start there or go back to 1.0?
manu: 1.0.
ivan: I think we should rename it when we publish the first working draft.
pchampin: The transition request for DID 1.1 has been accepted. I contacted the system team about the renaming and I mentioned the transition request so that everything is ready so that when DID 1.1 is published the correct history will as well.
… DID Core is already a recommendation, and republishing a recommendation can be tricky. The right thing is to redirect to the new name.
<Zakim> manu, you wanted to note that did-core /is/ an issue. :)
manu: However, I think in the redirect discussion we did not want did-core to be used anymore, and to have /did-core redirect to /did.
pchampin: When you say go, you want it to become the latest.
manu: Yes.
pchampin: It might be trickier because it means republishing the recommendation.
wip: There are four open PRs, some of them may be too straightforward to go over on this call.
w3c/did-core#874
manu: We can sub-topic each one and go through them.
wip: This is just adding an example to the list of examples.
w3c/did-core#875
wip: Verification ID is a relative URL.
… 875 addresses 812 and improves examples.
w3c/did-core#876
wip: 876 adds audience section to the document. Mostly borrowed Michael's text.
w3c/did-core#877
wip: Manu has done a lot of work to align this with other spec.
manu: The group requested that we do this as a PR. Normally I try to do this as an editorial change, but it's a massive change.
… What this is trying to do is that over the last year decisions have been made, and there's a subset of people that wanted to see a controlled identifier specification but use the web platform. That's the CID spec.
… That was basically a copy/paste of the DID spec, but with the DID stuff taken out.
… So we are removing duplication from the DID spec.
… It defers to the CID spec, saying that if you want to do things like "also known as", go to the CID spec, with the modulo that DIDs are allowed as well.
… and makes DID a requirement for the document ID.
… The only other issue I ran into is that since the CID spec is not published yet and is in TR space, a subset of the terminology is not yet published.
… That will hopefully be fixed in the next month, which should fix it. The PR is ready for review.
… It's a massive PR to layer the specs correctly.
ivan: The CID spec is not published in the TR space under that name. It was published under the name of Controller Document, just to be clear.
… Manu, last time you sent an email saying that there's a PR there but don't review it yet. Is it now ready for review?
manu: I removed the draft state and it is now ready for review.
markus_sabadello: Can you comment what this means for the abstract data model and consumption and production of entries that are set for update?
manu: I tried to make those changes in this PR and it became complicated. Some of the sections are still useful, but I'm going to try to do those in a separate PR.
… This PR does not attempt to remove the abstract data model. There is still some misalignment between the CID and DID specs, so I expect to make those changes later.
DID Extensions Next Steps
wip: I want to review the status of resolutions agreed to before Christmas.
… DID Extensions doesn't have an owner. I think it would be wonderful to get someone to tag some of these issues. For example, the resolution and DID core have nice labels on them and we should do the same.
manu: +1 I think it needs someone that's more in charge of it. I've been the fallback and I'm continuing to process pull requests for new DID methods.
… Maintainers are processing the straightforward requests. There also need to be some PRs that are restructured, adding "last updated" etc. and modifying the listing to not show things that have not been updated in a while.
… There's a concept that we could include DID traits in future.
… We need someone who can spend more time than I am able to.
wip: I agree. There's one path for DID method entries, there's another path to update documentation, e.g., adding a new list for path parameters.
… Currently, the challenge is that nobody is responsible for it.
manu: I'll also add that we have 57 issues, and a lot of them are "not what this registry does", and people will object when told so.
… We've got issues that are 5 years old that need to be closed. Whoever takes this on needs to take on a not insignificant amount of work.
wip: I'm not seeing anyone volunteer now. I'll keep bringing this up.
manu: There's a point of diminishing returns on this. We can put a huge amount of effort into it, but it won't have a significant return. It can have a significant negative return if not done right, though.
markus_sabadello: Regarding the extension, in the resolution repository we have about 6 issues on adding new DID parameters, and we're not sure if they should be defined in DID resolution or in DID extensions.
… There are potential issues that could introduce new parameters.
wip: I feel that there are changes that we want to make and we have made resolutions that no one is addressing.
<manu> yep, good points Will. :)
DID Resolution Issues and PR Proccessing
<Wip> https://
wip: For me, this is over to you, Markus. There are five open PRs. It seems that compared to DID Core there are a limited number of reviewers.
… Maybe there's discussion to be had about adding more.
manu: What I typically do in DID Core and others is max out the number of reviewers, and there are usually people who address them.
… I don't know if there's a way in GitHub to say "always add these reviewers", and it's usually the same six people.
markus_sabadello: I didn't think about the possibility of automatically adding people or manually tagging people.
… Some of these are from before the holidays. I would be happy to give an overview to explain what the open PRs are about.
wip: I don't think you can provide a review unless tagged.
manu: You can provide an unsolicited review but it gets a grey checkmark.
w3c/did-resolution#104
markus_sabadello: That adds placeholders for DID parameters that we have defined in DID Core.
… And adds placeholders for parameters for the dereferencing mechanism so we can document how to process each of them.
… I would add that this has to do with the question of how many parameters we want to define in DID resolution itself.
… We have the possibility to define some parameters in DID resolution itself and registering extensions for new DID parameters.
w3c/did-resolution#106
markus_sabadello: I think this would be ready to merge. There haven't been a lot of reviews but this is something we decided to do before the holidays.
… There's a list of parameters from DID Core that have been moved to DID Resolution.
… What should I do about these reviews? Just manually tag people?
wip: I don't know what's best. I can provide a review, and I have reviewed some.
manu: Manual reviews by just adding people would work for now. There may be a way to automate through the code owners file, but it may be an abuse of that file.
markus_sabadello: For now, I'll add people manually.
w3c/did-resolution#107
kevindean: On previous sub-topic, there are GitHub Actions that can automate adding reviewers.
w3c/did-resolution#103
markus_sabadello: This adds some more details to the dereferencing algorithm. It's related to 104, which we talked about.
… This adds a number of details to the dereferencing algorithm, e.g., if the DID is not found, or has no path, etc.
… I added another commit to that today. I tried to incorporate some of the conclusions from yesterday's special topic call.
… It's possible for DID methods and specifications to define how the path and query are treated in a DID URL.
w3c/did-resolution#108
markus_sabadello: That's about the HTTPS interface. We have sections about the algorithm, how to resolve a DID, how to reference a DID URL.
… Those algorithms as well as the DID resolution algorithm are described not as a classic client-server protocol, you don't necessarily have a resolution endpoint, but rather as an abstract interface.
… That's why there's a separate section on the HTTPS binding.
… How DID resolution can be done over HTTPS interface where you can run HTTP GET on a single endpoint.
… I added some details to improve it.
wip: Markus, do you have some issues you want us to focus on?
markus_sabadello: No specific ones.
w3c/did-resolution#55
markus_sabadello: This is a few years old. There haven't been any comments. I think it's about the question of what happens in one of the verification relationships if we reference a verification method that's in another DID document.
… Imagine that you have a reference in a DID document to a verification method that is in another DID document, e.g., modelling a corporation that has different divisions.
… What are the implications of this? Should it be allowed?
manu: I think currently it is allowed, you can reference keys elsewhere.
… We have no such limitations today and I don't think we should have one. The security implications are open-ended.
<ivan> +1 to manu; no reason why not...
manu: We warn people that if you refer to a key that is not under your control and you give that key the ability to do something, beware.
… I think that's where we are. The answer is that we should be allowed to reference multiple keys in a DID document.
… Some DID methods might allow it, some might not, there are safe ways to use the feature, there are dangerous ways to use that feature.
… Something may need to go in the CID spec. David Chadwick raised a PR over the holidays related to this.
… We can do this, and we have warned people about the implications.
<aaron2> Note: delegation of authority delegates authority.
w3c/did-resolution#79
wip: Christopher is not on the call.
… Are these things that we want to spend time on, and should we split them into separate issues?
markus_sabadello: Yes, I think we should spend time on these.
… The questions of whether there should be authentication in DID resolution or whether there may be security or selective disclosure, have come up a number of times over the years.
… We need to discuss to what extent we want to cover these things.
<aaron2> There is definitely a use case for a internal identity and access management derver within an orginisation
<aaron2> server
w3c/did-resolution#78
wip: This is a bug.
markus_sabadello: There's a separate JSON-LD context for DID resolution. There's one for DID core, and one for CID.
… We define two additional data structures in DID resolution: result and dereferencing.
… The JSON-LD context needs to live somewhere and uses W3 URL which is not working.
… I don't know where to raise a PR or an issue or how to fix it.
… It also raises the question about what the final context URL should be.
pchampin: If I understand correctly, what is required is a pull request on w3id.org.
… It shouldn't be too hard, but I don't know if you have to be the owner.
manu: I'll submit the PR to w3id.org. There is another question about where it lives. It should probably live under ns.w3.org.
… I know in the VC working group that we had members that were adamant that it be in the W3C space.
… Do we use a w3id.org URL or w3.org?
aaron2: Do we need a decision before publication?
manu: We don't need to wait until it's a recommendation to fix it. Historically, groups and staff have preferred to wait until the recommendation is published before the URL is published.
… There's a halfway point where we've redirected that URL to GitHub Pages, which stays dynamic until the final version is published. There are options, each with benefits and drawbacks.
… I'm fixing the bug right now.
ivan: I think that what happened in the VC is that any context file etc. that is new is put on the W3C NS.
… Whether it's put there as a redirect or physically, it's immaterial.
… If there's already a deployment using w3id.org, we leave it there.
… In VC, we agreed that any new deployments use W3C NS.
… I would favour for new ones to put in W3C and add redirection like we do for similar URLs.
… I'm not against w3id but it raises eyebrows every time we use it.
<pchampin> +1 to what ivan said
manu: It's fixed.