Meeting minutes
prsent+
ottomorac: Thanks for attending, first topic is horizontal reviews.
ottomorac: We've been discussing in regards to have volunteers to help out. The DID spec might be easier to do an HR for. DID Resolution will take more work.
<ottomorac> w3c/
ottomorac: We do have two issues that we've opened for this.
<ottomorac> w3c/
manu: Horizontal review is required for any normative standards track specification.
… We have already gone through this for the DID spec.
… It should go pretty quickly. I volunteered to put together some of it but welcome help in putting it together.
… The DID Resolution spec is going to take quite a bit of work.
… There are good instructions on what you have to put together in the issues.
… W3C has it pretty well documented.
… Usually what happens is they have a questionnaire and you fill it out. You fill it out and submit to the issue tracker.
… They review the spec and respond. Sometimes they pull you in to talk about the spec in their meetings.
ottomorac: ok, denken if you or anyone else in the group is interested, let us know and we'd be happy to take any help on that.
DID Core PR Processing
<ottomorac> w3c/
w3c/did#887
ottomorac: You've gotten some feedback from Ted in there, and from Ivan -- just be aware of the PR.
manu: 887 is a pretty big change.
… It's not normative. We're still trying to align with the DID spec.
… We're trying to eliminate the abstract data model and follow what the control spec is doing, which is establish a processing algorithm.
… It also makes the media type clear. There's now just one media type application/did. And you can also use JSON-LD on it to process it.
… Basically, what this does, the base specification we depend on is INFRA. It's debatable whether INFRA is abstract data model; I assert that it is, others assert that is isn't.
… This is the data model for the web and DOM environment, and it has a concrete mapping to JSON.
… You map INFRA to JSON and that's it.
… We used to have two representations in the spec, after years of debate. After we had some implementation experience, people asked why we had two.
… What I've done here is that we have one JSON representation. The PR includes the @context value and deletes the entire JSON-LD representation.
… We preserved the rules because we can't make breaking changes. We just need other folks to look and see if they agree.
… The other thing that I couldn't remove that there could be other representations. You can have a document and a YAML representation for it, as long as you can round-trip to JSON losslessly.
… Any representation is legitimate as long as it can round trip to the concrete data model.
… I don't think it makes any normative changes so we're within our charter.
ottomorac: Yes, that explanation makes sense.
ottomorac: Seems like we're on the right path forward.
manu: I'm probably going to leave it until the call next week to give extra review time.
w3c/did#886
<ottomorac> Clarify restrictions on identifiers used in DID documents. #886
ottomorac: Same sort of situation -- Ted had some changes that have been merged.
manu: This is asking when parameters should be dropped.
… Is a DID document with an ID in it, can you put query parameters or fragment identifiers in the ID?
… This states clearly not.
… We also provide non-normative guidance, saying if you are going to have a long-lived canonical identifier, you should probably not use a query parameter, unless you really know what's going on there.
… The query parameter is probably not something you want to store, just the base DID.
… Fragment identifiers, you probably want to use, because it may refer to a validation method.
… If you do use a fragment identifier, make sure it's unique over the lifetime of the document.
… If you use key1, key2, key1, key2... over years, it can change the way the document is handled.
… This text goes over that at a high level and addresses issue 337.
<denkeni> +1 to make it clear in did spec
ottomorac: This one makes sense too.
TallTed: I'll take a quick look at it, but expect it'll be fine.
manu: There's a triple-bracket syntax for references.
… I think you made the right change. ReSpec substitutes the specification for the name in the square brackets.
… You have to know what it expands to.
ottomorac: I think we're nearly ready on it, maybe get final approval from Ted and then wrap it up.
DID Core Issues
ottomorac: I took a look at these, need for a PR from some folks, unless we have a specific issue to discuss, feel free.
manu: There are four issues. We need Joe for one of the class 2 ones.
… I'm wondering if we can talk about at least one of them.
… Let's go with 849.
w3c/did#849
manu: We could either decide to take it over and do the PR or just mark it pending close because they haven't provided something.
… I suggest we just mark it pending close. If it's really important to folks, they will respond. We haven't received a response in 15 months.
… We can say that we discussed it in the working group and that we'll close it in seven days unless they raise a PR.
… In this discussion, the scribe contents will be injected into the issue.
w3c/did-resolution#137
ottomorac: Ivan and Markus provided input here. Any other input?
manu: I think we should use JSON. I don't think there's a strong argument for JSON-LD in the resolution spec.
… Ivan did raise it, but we would object to using JSON-LD for the API calls, but the data is JSON-LD. I don't think there's a strong argument for JSON-LD in the API.
… I'll note that the reason we're saying this is that this is exactly what we did in the VC API.
ottomorac: ok, makes sense.
DID Resolution Issue Processing
<ottomorac> w3c/
w3c/did-resolution#13
<ottomorac> Validate signatures/proofs of DID Document #13
manu: This one is interesting because of what verifiable history is doing to did:web.
… You can put any data integrity proof on it. You can sign the entire DID document.
… The controller of the document can use one of their keys to assert that the DID document is that and that it's digitally signed.
… You can put a proof on it, and the data integrity spec is very clear about where you put the proof.
… It's the DID method that needs to specify whether documents are signed or not.
… did:webvh definitely has a cryptographic log that verifies the changes and you get a mini blockchain over the history of the DID document.
… You can have one or more signatures. All of those details are in the did:webvh specification and it's clear how you are supposed to construct those.
… Where DID Resolution comes into it is that you can have a flag in DID Resolution that says I require there to be a signature on the DID document or a cryptographic signature on the event log before returning the result to me.
… You can, using a DID resolver, that you do not what any DID documents back that don't have any assurance on the DID or the history of the DID.
… I think the result is that we could add a parameter that says "verify a signature" or "require cryptographic log verification". We should ask Markus what he wants to do here.
ottomorac: so that's a DID resolution flag?
manu: Yes, I think so.
<ottomorac> w3c/
w3c/did-resolution#111
<KevinDean> manu: I think we should just mark this ready for PR.
<KevinDean> ...Can you call a DID resolver on your local machine, on localhost? The answer is yes, we should clarify that.
ottomorac: We could move on to DID Rubric/Traits next.
<KevinDean> manu: JC was wondering how we were going to integrate the DID traits stuff.
<KevinDean> ...We should talk about that.
Next Up: DID Traits and Rubric discusson
w3c/did-extensions#619
manu: Happy to have a discussion about DID Traits and Rubric... I do think we could integrate the traits into the DID Extensions quite easily by adding a 'traits' array with string identifiers for each trait and making it optional for DID Method registrants to fill that out by themselves. We can provide a table of trait identifiers to explanations about what the trait means.
ottomorac: Next week is IIW, so we won't have a call until April 17th.
<ottomorac> m2gbot, link issues with transcript
<m2gbot> Something wrong happened: Failed loading minutes from https://