Meeting minutes
<Wip> https://
<ottomorac> transcriber-bot, resume
Wip: We went through document last week, we want to reground. Where do we have consensus?
Wip: There are two main points we need to discuss -- Markus has thoughts on two major points.
Wip: First one -- do we pass in full DID URL to resolution, or a DID?
Wip: For Dereferencing function, there are PRs up, focus on conversation on getting PRs through.
Wip: any other things to discuss?
manu: Jeffrey Yasskin from TAG said that Markus addressed his issue in a PR Markus raised, when do we chat about that?
Wip: Tomorrow, it's schedule for tomorrow.
Wip: I don't believe, based on Jeffrey's comments, he's reviewed dereferencing.
JoeAndrieu: I know Jeffrey approved changes, but reading his last comment, he's still suggesting maybe possible direction is to state RFC3986 isn't useful. I don't think we've cleared up his confusion.
Wip: If he does review DID URL dereferencing, some of this might surface again.
Wip: Useful to share screen?
Wip: I'll share my screen to look at document above.
Wip: 1 feels editorial and can be done at the end. Broad consensus minus Markus' concern -- we're pushing that.
manu: Can we mark these?
Wip: 1 is orange, Markus is slightly against
Wip: 2 is red, Markus is strongly opposed
Wip: 3 is green, we have a PR, we can move to resolution in PR
Wip: 4 is red, big change, PR exists, few different things bundled up in here.
Wip: 4a is red, remove HTTPS binding, PR exists.
Wip: 5 is orange, we might be able to get consensus on it separately.
JoeAndrieu: Reason this is in 315, don't know how to separate in current algorithm, more complicated to separate it as a PR, but open to someone trying.
Wip: Maybe this can't be independent from function signature.
Wip: maybe 5 is tied up in 4 and 8.
Wip: 6 is red, tied up on HTTPS is involved for dereferencing.
dmitriz: There is potential confusion, two accept properties -- input options passed to dereferencer, other is HTTP Accept header.
JoeAndrieu: This is about both, also in the function, separate to 6 and 6a, could separate between HTTP headers and the function itself.
Wip: 7 is green, just updating the image.
Wip: 8 is orange, refactoring is a good idea and supported, but when we get into details it might become complicated.
Wip: 9 is green, add step that says a dereferencer must allow user to select resolver.
JoeAndrieu: we could do this separately, say if client or dereferencer does it.
Wip: This is a change everyone is for, though.
swcurran: Wondering if we can have conversation around why there would be two algorithms called when it's only one. The algorithm is DID URL dereferencing, that's all we do. You pass in a DID URL, naked DID or parameters, could have version time, and a result comes back. Can we have conversation on whether we should talk about two different things and two different calls? Ignoring the fragment, which is handled by thing calling, everything else is handled
… by nebulous, logical thing called DID URL dereferencer. F
swcurran: First step is to get DID Document, separation makes so many of these conversations difficult.
Wip: We should have that conversation, let's keep going through this document.
manu: I think 10 is orange, we can make it backwards compatible.
JoeAndrieu: I think we can change it because it's a security issue -- still think this should be red. Either Markus' -1 are red, or we argue and we override.
Wip: 10 is red for now, we'll have to discuss.
Wip: 11 is red because Markus is -1'ing it as the thing sent to the resolver.
Wip: 12 is orange, might be difficult conversation, but general consensus to clarify this.
Wip: 13 is green, general consensus on retrieval strategy.
JoeAndrieu: 13 is dependent on 12 and dependent on algorithm, which is 8.
JoeAndrieu: Current algorithm doesn't pick strategy to execute.
Wip: 14 is orange, where is the boundary for the algorithm?
Wip: My instinct is to pick hard topic first, if we can decide on 2, it'll help turn some of the orange items to green as well.
manu: There is an issue when the strongest opposing voice on many of these isn't here... those that are here are largely onboard.
Wip: Is there an HTTPs binding to dereferencing?
Wip: We could have no HTTPS binding, but still ahve function signature.
manu: Digital Bazaar feels very strongly that the specification should not have an HTTPs Binding for dereferencing. We have never had consensus on this in the group. We believe it is an attack vector, people can request massive files via dereferencing, or send the system on a variety of loops dereferencing, and we don't think that is appropriate for a specification of this type. We will not formally object to the feature, but we certainly will not
… implement it and we will speak strongly against anyone that does.
<Wip> https://
<swcurran> https://
JoeAndrieu: I copied text to 4a that should be on 4, which is heart of concern -- if I have a DID URL, I need to resolve it, and describing algorithm should work without needing another 3rd party function. Going from URL to use it in my application, shouldn't have to implement dereferencer function, you don't need this function, you can execute algorithm -- when derefrencing in browser, they might do a lot of things to dereference, I want to echo
… Stephen's frustration that there aren't two things we're describing here. We differ on what we define those things, we have to define resolve (that is the point of interop), so anyone can resolve through HTTP interface.
JoeAndrieu: we're defining how someone who has a DID URL, preprocesses it, handles response, we should get rid of function because it has us have an additional limitation on inputs/outputs and I cannot change it, I wouldn't implement it, I would object if we don't define the algorithm in such a way that it's independent of software called a dereferencer.
swcurran: Manu, your comment about removign HTTPS binding son dereferencer, same for resolver?
swcurran: or is that the same thing?
manu: the thing that we are opposed to is retrieving any arbitrary resource using an HTTPs endpoint. The only return value that we want to implement for an http binding is the one that return the DID document.
manu: The thing we are opposed to is retrieving an arbitrary resource using an HTTP endpoint. We are OK with getting the DIDDoc so that you can do the dereferencing yourself, but you have do the dereferencing is some arbitrary resource. The client can do the dereferencing, following the spec, but our code won't do that. Return the DIDDoc and
something else gets the resources.
manu: we would rather have an alg where the return value is a did document and then you can take it from there
Back to you manu
markus_sabadello: As I've said in some of the issues, I'm against changing the language we've had for a long time. We are resolving DIDs and dereferencing DID URLs, important to think this. Resolving DID URLs, dereferencing DIDs, think it would break a lot of things if we break the clear separation we've had. Some of the proposals in that direction are based on misunderstanding of specification and how it works. versionId and versionTime are resolution
… options passed to a DID Resolver, doesn't mean we're resolving DID URLs.
Wip: We're focused on the HTTPS Binding right now, are you going to formally object if we remove the HTTPS Binding.
markus_sabadello: Yes, I'd object, we have some some use cases that need HTTPS Binding, but it's important for some use cases to have it. What Joe wants is also supported by the specification. Because we define a function w/ inputs/outputs, it doesn't prevent anyone from derefrencing client side.
manu: I guess one thing on the feature and formal objection. In order to have the FO , the burden of proof is that the feature should have consensus by the group.
manu: if we go this route then it will just result in a delay.
manu: on the point regarding implementation of https binding being optional, this is actually a security issue. From DB's position this will be dangerous. I know this has been in the spec for a long time, but I feel people have not really been reading this deeply and following it.
manu: Respond to formal objection idea. If you FO you have the burden to show there is concensus that the feature is in the spec. The claim is there is not a concensus so it will be unlikely to proven. This is a high chance as a security risk, and we strongly think it is a bad idea. We should not help them do something that dangerous. Pushing
… back hard that this had consensus. It's been in the spec, but people have not been thinking. Just the HTTPS binding. We don't want a client to insist we do this. We don't want it in the spec.
JoeAndrieu: Speaking to Marku's comment about not needing to implement dereferencer. It's inseparable from the current algorithm, that doesn't depend on this function (that I think is a bad function). If we formally define what client does more appropriately, it's a huge shift to clear this up. If we can't define how a client calls a dereferencer and how to use it, that's a big problem.
JoeAndrieu: I think the challenge is that we need to formally define how the client should behave here. How does a client call a resolver once it has a DID url.
bigbluehat: Is this a SHOULD vs. MUST or a MAY? Even with SHOULD/MAY, there are concerns that Manu/Joe both spoke to.
markus_sabadello: I don't understand what the problem is with the function -- function has inputs and outputs
markus_sabadello: There is an algorithm that is executed, it is an algorithm, it can be executed on client-side, it's what Joe is describing -- don't understand what the problem is with it. No one is saying you can implement it yourself, no one is saying you need a remote endpoint, algorithm has inputs/outputs -- also how dereferencing HTTPS URLs works, you have to mention browser as analogy, exactly like that. You have an HTTPS URL you dereference it,
outputs, same thing/... there are inputs/outputs, same thing/outputs, same thing. DID URL representation of resource together with metadata, has inputs and outputs, more client-side than HTTPS URLs, implement entire derefrencing function entirely on client-side, including DID Resolution -- for example did:key or did:jwk, all resolution, all derefrencing can happen on client-side. What's the problem with expressing as a logical function.
Wip: We're migrating a bit into logical function discussion. I'm hearing strong support for removing, and also hearing Markus is opposed.
manu: Markus, my comments are not about the logical function. I'm only speaking to the binding. We're bouncing between the two. Let's stick to the HTTPS binding. There are thing that you said that I agree, with but we're not talking about that.
<Wip> Here are the use cases - w3c/
markus_sabadello: Ok, so regarding HTTPS binding for dereferencing, shared two use cases in comments, one is DID Linked Resources, if you have DID URL that references a DID Linked Resource, the result of dereferencing is an image and value of HTTPS binding is you can put it in browser, you can have HTTPS URL which uses binding for DID URL dereferencing to return representation of resource over HTTPS binding. Redirect a service endpoint URL, where you can
… construct HTTPS URL that includes DID URL that result is redirect, useful for a number of reasons. Persistent identifier, URL backed by DIDs, these things would be unspecified if we remove the binding.
markus_sabadello: I can understand that we can remove it and people can implement it. Valuable feature in deployments, for that reason, we should keep it and emphasize that dereferencing on client-side is preferred, and point out security considerations, but I don't think we should remove it.
dmitriz: What if we lean into optional nature of it, standalone spec? Not in core DID Resolution spec?
You mean like did-extension style Dimitri?
markus_sabadello: I have to think about it, very parallel to binding for DID Resolution, would make it more complicated if we put it in another spec. Helps interop -- good reasons we want HTTPS binding for Resolution, same applies for Dereferencing.
<dmitriz> @ottomorac - yeah
Wip: We need to make decisions that some aren't going to like and move forward. Can more conversation help move this forward? Or do we need to make a decision about the feature?
<TallTed> s| outputs, same thing/... there are inputs/outputs, same thing/outputs, same thing| ... there are inputs/outputs, same thing
manu: We need to continue the conversations so that we can get to an educated position on what they want to see going forward.
markus_sabadello: Agree to having more calls about this.