Meeting minutes
Agenda Review, Introductions
ottomorac: Update on horizontal review, now closer to submission want to get that ready.
<Zakim> manu, you wanted to proposal agenda item on community update.
Community Usage Update
<manu> CA DMV announcement on usage of DIDs: https://
manu: California DMV has just announced a new driver's license in the state issued to the 34 million people in the state. It includes a 158-byte VC in the license, which includes a DID.
… It will take a while to get to everyone, but they're printing licenses every day. Great news for DIDs and VCs as the fourth-largest economy in the world.
… This is for the physical cards. They are already issuing digital ones, of which there are about 2.7 million only. The physical deployment is much bigger.
markus_sabadello: This sounds fantastic.
… What's the DID method? And are there DIDs for the issuer and for the subject?
manu: It's a did:web ID for the California DMV.
… The digital ones are using did:jwk, hopefully changing to did:key in the future.
… There is no DID for the individual; it's for the card itself.
… The card is did:web for the issuer, and includes a status list.
… The digital ones align with the MDL and are valid for 30 days.
Horizontal Review Update
<ottomorac> w3c/
<ottomorac> Will would like one final review before he submits the information for TAG review.
ottomorac: Will would like one final review before he submits the information for TAG review.
… Right at the bottom of the issue, you'll see the latest from him.
wip: Marcus merged all the issues related to TAG, and I took another look at what TAG was asking for.
… I have tried to align what they're asking for to sections in the document. I would like others to review that I have done this correctly.
… For web platform tests, we're going to put "not applicable".
… Also, they're asking for a request from the working group for a TAG review. They want us to point to something in the minutes that asks for it.
manu: The relationship to other technologies section in the spec, what are you concerned about us not covering?
… They ask, what other technologies do you consider? We considered DNS and outlined problems with the DNS system and explain why DIDs are better.
… What would you like to see in that section?
wip: If we all think it's fine, we can go ahead with it.
… I'm wondering what research we've done related to the problems.
manu: I linked to the acknowledgment section that shows all the meetings and work that went into it to show that a lot of research has been done.
… We're proving to you, the TAG, that we did our homework.
… I don't think we need a super-deep discussion of everything that happened at Rebooting.
wip: I'm happy that we can provide answers to all the questions they have asked.
… What can we point to that shows that we actually asked for a TAG review?
manu: I've never seen that requirement before. It might be new.
… If you want to, you can point to this discussion.
… After this call, I will raise this issue, and we can be done with the horizontal review.
wip: After this call, I will raise this issue, and we can be done with the horizontal review.
Processing PRs
<ottomorac> https://
ottomorac: We have a few PRs, there have been a few mergers.
… There is one on my side I wanted to bring.
w3c/did-resolution#211
ottomorac: I see a minor suggestion from Manu that we should strengthen the statement to a "MUST".
… Any comments from the group?
manu: We don't need to do it, but I'm wondering if there's a good reason to not return "feature not supported" if you don't support the feature?
… MUST feels like if you don'
… MUST feels like if you don't support a feature, you return something saying so. Why wouldn't you do that?
wip: It sounds sensible. But are we saying "MUST" on any of our other errors?
manu: I think it's an independent decision. I think for a "feature not supported", it's a very general and important thing.
… For others, we can take it on a case by case basis.
w3c/did-resolution#182
ottomorac: On my PR, per guidance from the group, there should be a base conforming DID resolver, that includes a local binding. I don't know how explicit we want to be about including the local binding.
… I also defined an HTTPS resolver that implements an HTTPS binding.
… I don't know how explicit we need to be about a local binding being present in a resolver.
… I'm happy to defer to what the group has here, and I see that there are comments from Will and others in the issue.
manu: I think we're almost there for this one. I found a couple of nits. I don't know if local binding is a subsection of resolving.
ottomorac: It's a separate section.
manu: I don't think we need to say must implement. We should probably point to the section on local binding algorithms as it's pointing to the definition right now.
… Point to the section that contains that definition and the algorithm rather than just the definition.
… The only other feedback there is, I know why we mentioned "Let's Encrypt", but at some point they may be the AOL and CompuServe of today. We should avoid brand names.
markus_sabadello: Maybe I don't remember correctly, I was a bit surprised to see that the confirming DID resolver is defined to implement a local binding.
… I didn't understand that. I thought a conformant resolver could have any binding they want.
… Maybe we discussed it last time and I don't remember.
wip: I think I agree with Markus. There is no conformance statement about implementing local binding.
… A conformant resolver is any implementation of the "resolve" algorithm, then we're subclassing that and constraining it for HTTPS.
manu: I thought we did have normative statements for local binding. If we don't, then I agree with Markus and Will. Conformant statements are about implementation.
… Whatever section we point to, an implementer must say that that's what they implement.
… My understanding is that every resolver must implement local binding, but I may be wrong as I'm not fully familiar with the spec.
wip: A conformant DID resolver says nothing about the binding, only about the functionality.
… We then extend it to say that a conformant HTTPS resolver must have an HTTPS binding.
ottomorac: Where in the spec should we mention HTTPS binding?
manu: Will, I think what you describe is too abstract. What we're saying is that you can do A or B, but I'm writing a test suite that has to call A or B. What piece of software and I writing to do that?
… If the the first thing is that abstract, the only useful conformance class is HTTPS, because I can write for that.
… To me, a library API call is still testable, but I need to read your docs to write the test.
… Implementers want to advertise something concrete like an HTTPS resolver, not something abstract.
markus_sabadello: I agree that we should require HTTPS as a binding. Local binding is very abstract.
… DID resolution has already been defined as an abstract function. We're not saying that every DID resolver must implement every protocol.
<ottomorac> https://
markus_sabadello: We're not really defining a library interface. Local binding is abstract. Remote binding is abstract. HTTPS binding is a concrete remote binding.
ottomorac: Maybe this is the section I can point to.
<Zakim> manu, you wanted to propose some text for "local binding" as "inputs and outputs"
ottomorac: Keep the other class as having normative statements about what needs resolving, then subclassing as necessary.
manu: The other way that you can define conformance classes is as inputs and outputs. Whatever we want to call it, we're saying that for local you're implementing section 4. It has an input DID and an output resolution result.
… We can save the concrete expression.
… This can get us towards something like did:key being something that we resolve.
… We can get to something like, "DID resolver implements section 4, DID resolution, with a concrete input (DID and options) and output (DID resolution result)".
… By using the word concrete, it's not abstract anymore. It's JSON or CBOR or something.
<markus_sabadello> q#
manu: What we should probably have one here is provide a concrete definition.
<ottomorac> A did resolver implements section 4 did resolution with a concrete input and a concrete ouput. Concrete input being did, and output being a concrete did resolution result..... and mention output format
manu: If we say concrete, it's not as abstract, but we should probably pick a format such as JSON.
wip: I think that's what it's already saying. A conformant implementation is any hardware or software that implements section 4.
… I would prefer a description of conformance that is independent of binding.
markus_sabadello: We do have a concrete binding in section 8.
<Zakim> manu, you wanted to speak to interop concerns w/ the way the language is written now.
manu: That's better. It's normative but it has no normative statements in it.
… Will, what are you going to implement? What's your input and output format for a conforming DID resolver?
… "I'm going to implement YAML and we're both conformant and we're not interoperable."
… If we at least lock down the input and output format to JSON we've got a good, testable suite.
markus_sabadello: I understand conformance classes and being interoperable with a concrete format. In practice, what people do, is for local binding the inputs and outputs are objects in application memory.
… I don't think there's ever a JSON object in a programming language implementation in memory.
manu: We would have to figure out how to write conformance language to get to something concrete and testable.
… I don't know how we test in-memory conformance. We can't necessarily test across languages. We have to get it to an interoperable format.
… If the boundary is not well defined, the we don't have interoperability.
markus_sabadello: I understand. I think that makes sense. In sections 8 and 9, we have concrete statements about DID resolution results and DID dereferencing results.
… We should add the same for inputs.
manu: +1 to that. Maybe we could do something simpler and say that a concrete implementation that takes a conformant DID as input produces a concrete serialization.
… I think we can just say it takes a DID as input and provides a DID resolution result as described in section 4, DID resolution.
… It doesn't have to be serialized to JSON but it must be serializable to JSON.
… Then you have a concrete implementation.
… We should probably move this language down into the DID resolution section and say that implementations must provide results that can be serialized to JSON.
<ottomorac> Normative statement: Implementations must provide results that are serializable to JSON.
wip: I know this is taking a while, I just wondered where we want to fix this. Otto's PR is good to go, what we're talking about here is the conformance statement itself. We can address this in another PR.
manu: +1, let's end Otto's suffering. I think these are separable things.
DID Resolution Issue Processing
w3c/did-resolution#209
<Wip> https://
wip: I was trying to write some tests and then came across issues in this section of the spec.
… There's a TODO there. The issue is to do the TODO.
manu: I could take this. I don't feel very strongly about keeping it but I can see how it might be useful in systems that store DIDs and want to pin two a very specific version of the DID.
markus_sabadello: This should be easy to specify if no one has done it yet. This is similar to hash links for HTTP URL including a hash of the resource that the URL is pointing to.
<manu> ah, right, I had forgotten about all of that -- thanks for the reminder, markus_sabadello
manu: Thank you, Markus. I had forgotten about those use cases. We should keep it and I'll write a PR for it.
others
ottomorac: Any TPAC items?
wip: The only thing I would say is that it would be very useful to have time to move all DISCUSS labels to READY FOR PR.
… We need to assign those issues and address them.
<ottomorac> m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/