DID Topical call on resolvers — Minutes

Date: 2020-04-16

See also the Agenda and the IRC Log

Attendees

Present: Justin Richer, Brent Zundel, Kyle Den Hartog, Manu Sporny, Markus Sabadello, Tim Cappalli, Daniel Burnett, Phil Archer, nat holloway, Dave Longley, Yancy Ribbens, Drummond Reed, Joel Hartshorn

Regrets:

Guests:

Chair:

Scribe(s): Amy Guy, Manu Sporny

Content:

• 1. PR 253

Brent Zundel: our topic today is the did resolution contract, resolution in general
… there are some PRs we can look at, comments about metadata
… there are different ways we can go with this
… during the face to face in AMS, the group agreed that it would be amenable to the notion of putting a resolution contract in the DID core spec
… there’s a couple of PRs now that propose how this could be
… now we get to talk about it
… at some point we’ll be refining proposals, which can be a good way to get the conversation going
… for now I’m going to open the q

Manu Sporny: we should probably talk about the DID resolution PRs first becuase there’s something concrete
… and then metadata, and then some of the parameter cleanup stuff that may be affected by the previous topics
… really feels like the thing on everyone’s midn is the resolution contract

Justin Richer: a +1 to what manu suggested in terms of the order
… the resolution at least in terms of what my PR has done and what markus has started
… what that does is provides a place in the overall system for metadata and we need to have a place for this thing
… a definition of this concept and how it relates to the other components before we get into the arguments about what goes where
… right now I’m noticing a lot of arguments about ‘i need this parameter’ and it might go one place or another but we don’t have a good definition of what those places are

Brent Zundel: which PR should we start with?

Justin Richer: Markus and I and others discussed this last week - what we’d recommend is starting with #253 which is mine

Brent Zundel: https://github.com/w3c/did-core/pull/253

Justin Richer: if there are additional things, there probably are, from Markus’ #247 that need to be pulled in then we can do that using #253 as the base

Markus Sabadello: I agree with justin, we can start to look at his PR which incorporates some of the content from my original PR
… there are some good pieces in both but yeah we can start with his
… I think the general objective or goal of this call should be to see if we’re all in agreement on the general scope of those PRs
… there may still be different opinions on how much of DID resolution should be in DID core and how tightly integrated or separated those documents should be
… that’s the main question, the details of which metadata, which parameters, we can work on that also in the github issues

1. PR 253

Markus Sabadello: the general objection I think should be to see what the contract should be or what should be in DID core

Brent Zundel: https://github.com/w3c/did-core/pull/253

Manu Sporny: I did a full detailed review of the PR yesterday to make sure we have latest
… there are a number of things I like about both markus and justin’s PR
… specifically the non normative stuff that’s said
… there’s a decent bit of exposition about what resolution is and what the process is
… there’s really good language we should put in DID core that talks about resolution at a high level, introducing the concept and that sort of thing
… as far as a next step for the PR, I’d really like the non normative stuff split out from the normative stuff
… the non normative stuff could find a home in the DID core spec, it’s good, and we could take the normative stuff later
… I’m focussing on the positive stuff. There is some base level description about what DID resolution is that is really good and we should put in there

Kyle Den Hartog: I’ve pusehd for things being more normative. I don’t necessarily understand the impact of that from a standards level
… I’m open to opinions but I figured it’s worth me expressing why I have such a strong opinion on this
… I don’t want to have to support legacy code around a resolver, especially when they’re complex, the best way i see to solve that is to create a strong contract so I don’t have to cause a breaking change when resolution comes around and things change with it
… that’s why I’m working to try and constrain it
… all of the other statements that come in with the normative aspects, I’m amenable to change on that front

Justin Richer: I strongly disagree with breaking the normative statements out of this, I’ve gone into detail on the tracker
… the entire point of my PR was the normative statement
… The whole purpose of this exercise from my perspective and my understanding of the f2f in AMS, was to create something that would allow different implementations to behave similarly at a high enough level
… The suggestion that making everything non normative and pointing to another doc and promising it might be a real spec someday is a huge step backwards
… it would be less than unproductive. It would undo some additional work that’s happened

Manu Sporny: I’ve got no problem with the non normative language. The concern around the normative language.. kyle, you asked what’s the issue here with normative language
… I’m going to go with the worst case, which nobody is suggesting but we might accidentally find our way there, which is
… the group is not chartered to work on DID resolution, flat out
… There is some wiggle room, that’s true, where we could potentially do some resolution things that look like resolution, or the contract stuff you could aruge is kind of there as long as we’re careful with the language
… if we go too far we’re going to be violating our charter
… I don’t think we’re there yet, but if we pull this PR in we’re violating our charter
… we could rework the PR so its’ not doing that but what we’re left with at that point is this pseudo abstract interface that has normative statements around it
… yes you can do that, but I think it’s a half measure, and the reason we’re taking it is because resolution is out of scope
… we’re twisting ourselves into, we’re doing acrobatics to try and work on resolution when it’s not in our charter
… what I’d rather we do is figure out a way to do the layering correctly
… that basically means we need to figure out a way to pull the DID resolution spec into the group, so the people who want to talk about resolution and I know people really need certainty around it
… kyle you really want to know what these interfaces are, justin you really want clarity about inputs and outputs
… how do we do that in a way that fits with our charter and keeps the group focussed?
… What I’m suggesting is the non normative language is good. Let’s point to the DID resolution spec, which is where all the normative things should be said anyway
… that’s where the real meat of resolution happens
… it’s totally appropriate for a group to set itself up for a rechartering
… all of us want resolution to happen as a w3c standard, we know we need it
… I’ve been in other working groups where we set the work up just like this
… you put non normative stuff in the document, say there will be future work, implementers should really pay attention to it. We signal that that is where all of us are headed
… in doing that we don’t end up with a half measure in the DID core spec
… we end up with something that points to another document appropriately and says did resolution is important and this is what it does, but if you really want to know how it works read that other document
… the layering is right, we have a nice clean separation of concerns
… we have the ability to publish that document as a NOTE in the WG
… in doing so we make a stronger case for the rechartering of the WG to work on resolution

Justin Richer: I can’t disagree strongly enough with the notion of that approach making the layering better
… what we have right now is a lack of layering
… that is fundamentally the problem that these contracts that these are trying to solve
… this is to allow the WG to focus
… because we have not been able to focus on core problems because we keep running into issues that would be solved if we had a place to talk about inputs and outputs of a resolution function and this kind of operational stuff
… that’s why we have arguments about we need a matrix param for an id or a type or how can I parse this thing that’s coming back, because we don’t have palces for that
… I want to emphasise the fact that this PR very clearly and very explicitly does not define how resolution happens
… nor does it define how dereferencing happens
… the details, the processes, the implementations, and the deployments of all of that are still completely up to whoever wants to do it
… which is why all of the references to DID resolution are non normative
… if you read my spec carefully, not my first rodeo, you’ll see all of the normative requirements are internal and self consistent
… there are no normative reuqirements to the DID resolution spec
… this is how you access this process, and how that process happens, happens out of your sight. Somebody else is going to do that. When it comes back this is what the result is going to look like
… this is not solving DID resolution
… whether DID resolution should be in spec is a different argument
… this is explicitly not defining how that works
… If you elieve resolution is completely out of scope this is fine
… furthermore, if we are doing all of this work and saying we’ll fix it when we recharter, then I would argue we should dissolve the WG immediately and recharter so we can do this correctly
… if that is the only way we can look at success in terms of we’ll fix it later, we shouldn’t be trying to fix it now, that is embarrassing

Brent Zundel: Short statements please for folks on the q

Kyle Den Hartog: something I’ve been thinking about, on Markus’ PR, is the idea of what actually is a DID method
… in my mind it’s a way to go from an identifier to a DID document
… there’s multiple ways to do that the data is stored in many ways
… that’s going to impact the resolution, which is why we see in the universal resolver multiple drivers and implementations to do the exact same thing
… I’m still puzzled as to what goes in a resolution spec
… I’ve seen markus’ algorithm, which does a good job of identifying it, but to actually write code and implement the drivers seems a bit difficult in my mind without understanding the implementations and the registry itself
… that’s why I think it makes sense to define the mapping here as we see in 1.8 of the scope of the charter
… and allow the harder question, how do you perform the mapping, to the DID methods themselves
… that makes sense because they’re going to be so wildly different depending on the properties of the underlying registry

Phil Archer: you’ll know I was very unhappy with the PR as it was then. i’m now much much happier
… I think the work that justin and markus have both done takes us a long way forward
… I understand that we’re dancing around what we are and are not chartered to do and we have to be careful
… the thing that convinced me was that i asked the question could it be you could throw away the DID resolution doc and replace it with something radically different and still fulfil the normative parts in the PR
… if the answer is yes then i’m happy. that means that’s what is in the DID resolution doc at the moment is non normative
… if we’re publishing it as a note, normative stuff should not be there
… the normative stuff fin the PRs looks okay to me, I think it’s in the bounds of our charter to say these are things we should expect
… though the references are written as informative, the text does not distinguish it enough
… it needs to say here is a possible method you could take to meet these requirements
… I think the direction of travel is good

Daniel Burnett: I think phil covered a lot of this
… the chairs have talked about this too, frequently, and we do believe this contract approach without normative statements on the resolution process is within our charter
… but normative statements about resolution is not in scope of our charter

Dave Longley: Our charter says: “DIDs resolve to DID Documents” … we can say this (and should) but not talk about “how” it happens.

Daniel Burnett: whether we go with the contract approach or not, the group needs to decide, but as long as it stays away from normative statements on how resolution must occur, it’s within our scope

Brent Zundel: agree

Justin Richer: this is a question to the chairs - the way i have written my PR, 253, the intent was to not make any normative statements about the resolution process, but about how to access the resolution process from the outside
… is that type of statement in scope or not?

Brent Zundel: i do

Drummond Reed: I agree with Brent. That is in scope.

Brent Zundel: I believe it is appropriate to make normative statements about the inputs and outputs of resolution

Justin Richer: that was my goal

Drummond Reed: That’s the definition of “a contract”.

Daniel Burnett: I agree
… largely.. because I still have to think about some edge cases
… I’m not giving you an unqualified yes on that
… I think it is worth continuing this direction because it has the potential to be okay as long as we have appropriate watchdogs on it, like phil is being
… thanks phil

Drummond Reed: Phil is definitely an “appropriate watchdog”. Best we can get!

Justin Richer: to clarify.. having normative statements around this in concept is okay even if the details need to be worked out
… what manu has requested is a removal of all normative statements from the PR

Kyle Den Hartog: my question is for manu, because he wants to remove all of them, I want to get an understand of what you saw as the most concerning statements?
… i saw in your review you were good up until the point he said something I didn’t fully understand - I want an understanding of where you see the concerns with the PR right now

Manu Sporny: there are a number of normative statements where I was reading it and going what test are we writing for this to make sure it’s a testable statement?
… Things that popped out are statements like all implementations must provide a function of the following form
… all implementations of DID resolvers, for example, MUST provide a function of the following form, is clearly a normative statement about a DID resolver

Manu Sporny: all implementations MUST provide a function of the following form -> >dereference ( did-url, input-options ) -> ( content, did-document-metadata, did-dereference-metadata )

Manu Sporny: statements like this.. that’s where I feel like we’re asserting something beyond just the input and output to a function and talking about what implementations must and must not do
… there are other statements like concrete bindings MUST NOT define additional inputs to this function
… now we’re talking about bindings for did resolution

Drummond Reed: Isn’t that an “input ==> output” requirement?

Manu Sporny: I can go through, it happened more than a couple of times
… where either the statement was so abstract that implementing would require us to implement something in the test suite which is a call out to an implementation of a DID resolver, an actual implementation of the function and the only place that function would exist is in a DID resolver
… the other class of concerns is I don’t know how to write a test for some of the language here
… that was happening over and over as I was reading through
… to be clear, I’m asking for the removal of all normative statements in that category
… not for the removal of all normative statements
… there are some made around metadata that if modified could make sense
… by and largeI’m concerned that most normative statements are talking about implementations of DID resolvers
… if we’re not talking about DID resolvers, if we’re not then it’s an abstract functional interface then how are we testing that abstract interface when there’s no representation for it
… when you don’t have something concrete it is incredibly difficult or impossible to write a test suite
… it has to do with the details, which i”m not hearing a lot about
… I’m hearing a high level discussion but not a nitty gritty about the stuff this PR does
… that’s why my concerns are
… how do we write test suite stuff for this? where do we go too far in some of these normative statements?

Kyle Den Hartog: thanks that was helpful

Justin Richer: I would be happy to talk details. Trying to keep this short
… the purpose of statements like the one manu pointed to and others like it are really you’re not a resolver if you don’t resolve
… that is the definition
… from the spec work I have been doing for more than the last decade it is generally preferable to define things in terms of normative requirements that describe functionality as opposed to declarative statements that say this is a thing that exist
… precisely because of testability
… as I commented, to me these actually make writing a test suite simpler
… you can now define a test around is this thing a resolver
… if you are testing an implementation of a resolver then you can have a whole bunch of functions you can cal with different inputs and then you create an adapter to the test suite, which is how you plug implementations in, which ties that function to the underlying implementation
… which is exactly what an implementation would need to do in order to make that function available to a general caller and consumer of the function

Kyle Den Hartog: about the testing of the dereference function, how I envision it would work is you write a test that provides a valid did, and you’d expect back a did document
… you don’t care what the contents are, just that it meets the structure and contains normative aspects
… and a test that if you provide an invalid string it doesn’t return a document, it returns an error
… that’s the bounds.. I can know I’m putting in a string and getting back an object
… that may be too specific
… but that’s how if i was writing the test suite how I would write the test for it

Phil Archer: I hadn’t thought about this in terms of writing tests

Justin Richer: +1 to kdenhartog ‘s point

Phil Archer: if we’re getting to the point that we’re going to be writing a test suite and checking if your resolver meets the contract
… that’s getting towards defining resolution, beyond our charter, murky water
… I have some sympathy of what manu is saying that some of those statements about input and output is getting very close to that
… I don’t think a contract, going half way, would be testable in a test suite
… if the aim is you can write a test suite, we are getting close to going outside charter
… having said that, the process is there to make sure we do our job right and end up with a document with all the right bits
… the point at which the process gets in the way of what we’re trying to do.. it’s not that hard and fast, sometimes you can just.. let it go..

Drummond Reed: +1 to Phil’s point

Dave Longley: my main concern is along the lines of what manu is saying, which is some of the normative statements are going to require us to test resolvers and we’re worried about running afoul of the charter
… I wonder if it would make it easier to avoid charter problems by making definitions instead of normative statements
… saying a DID resolver is this thing that does this.. you MUST implement a did resolver happens in the DID resolver spec later.. seems to be a way to get around these issues

Manu Sporny: I think what’s been said is getting to my point.. kyle, there’s nothing wrong with what you said, absolutely that’s how you’d write the tests - those are resolver tests
… the language in this PR would result in us writing tests for resolvers, that’s the point
… the argument that we’d put language in that doesn’t result in normative language about resolvers is the half measure I’m concerned about
… it doesn’t help anyway. Gives us some idea of the shape., but there’s a place we can write the stuff the group needs for interop
… there’s a CCG work item, DID Resolution, they can do a test suite with all of these normative reqs, in the test suite, nothing is stopping anyone from working on that today
… the issue I have is doing acrobatics to pull that into the WG
… the tests that will result from the normative language in the PR are DID resolver tests. flat out. That’s what they are
… That’s great, we should work on that, ideally outside of the group because it’s not in our charter
… but if the group feels strongly, sure, kick off the rechartering process
… but we’re bending over backwards to say it’s not actually resolution, we can’t write tests for it
… that doesn’t help interop at all
… what helps interop is someone writing the test suite and providing normative statements in the CCG document, and the implementers should go there and follow those
… and make those work ,not do a half measure

Drummond Reed: Establish a deterministic mapping between DID method identifiers and the resolution process used to resolve that DID method.

Drummond Reed: this is the bullet point we’re talking about from the charter? ^
… as I’ve been listening, what justin was describing, and what was in the PR, is doing exactly that
… the argument that that is not within the scope of our charter I don’t think they hold any weight
… justin can speak to this, I believe that is the reason he was insisting on that point in our charter
… if we had brought resolution in scope we’d have a natural pairing of a identifier document spec with resolution spec
… but I also don’t feel it’s an abomination to turn around and take this contract approach
… I believe this language does define what the resolution contract is like, I don’t have an issue with normative statements about a target that would be a resolver
… we’re not defining a protocol, just what needs to go in and what needs to go out

Justin Richer: I’m glad that manu made the point that this language will force us to create resolver tests, because that is patently untrue
… We need to remember from the perspective of our spec, what are we testing?
… DIDs, DID URLs, DID Documents
… we’re testing how those behave in a particular contexts
… to go back to kyle’s example, I’d have a test function where I’d hand you a DID and get back a DID document
… Here’s the thing about test suites, having written a number myself
… it deeply matter which portion is under test, because the rest of it is what gets mocked
… if we have a bunch of DIDs we’re testing to make sure the syntax matches and we get the behaviour we would expect with different changes, we can throw those against a mock resolver that is not resolving anything, but making sure it can parse the string that comes in for the DID and hand back a hard coded result when you do the right thing and a different hardcoded result when you do the wrong thing
… the same thing is true when you need to do tests on the DID Docs themselves
… you need to make sure what you’re getting back is a DID Doc and is parsable into this format
… we could burn through those URLs and read a bunch of files off disc
… this gives us context and the context they’re going to be used

Daniel Burnett: This is a data model and representations specification. As long as we stay with no normative statements regarding process and/or protocol we are okay. The problem is statements like “when handed this, we must behave this way”.

Justin Richer: that is vitally important in defining what those pieces are, and focussing on the problems we actually want to solve

Kyle Den Hartog: I’m going to play devils advocate to my own argument.
… right now, as I look through the spec, I”m not finding a place where it says if I provide a DID I’m required to receive an object that returns with the same ID. I’m not seeing anywhere we’re defining that mapping
… my question is how do we go about defining that mapping without talking about resolution?

Daniel Burnett: Agree with dlongley that we can define what we do with any particular doc we receive without putting requirements on how it was created.

Brent Zundel: I was going to ask if we can change the wording of the normative statements, i think we’re past that… does every normative statement need to be testable in the test suite?

Dave Longley: I would think every normative statement needs to be testable, just my opinion
… I think what we might be able to get away with is a difference in these tests between what tests for a did resolution spec would be
… what we would be testing is simply that if put a DID in to a resolve function it doesn’t have to be the correct DID document, just a valid one

Justin Richer: +1 this is the kind of point I was making as well

Dave Longley: doesn’t have to be the correct DID Document for that DID
… a resolver test for the did resolution spec would require that
… that can explain how we’re not running afoul of our charter
… we’re defining a deterministic mapping between a DID and a valid DID Document. aCtual DID resolver tests would require that
… that could be where we draw the line

Manu Sporny: can you have normative language in a spec that’s untestable? absolutely you can. There’s a question of how useful that is. i don’t think we can avoid that kind of language in the DID methods section, we’re making normative statements around a spec
… we’re trying to give something to a human that’s enforceable
… but if you have a normative statement that’s not testable it makes it very difficult for people to figure out if they conform
… over time, WGs I’ve seen doing this have attempted to reduce the number of untestable normative statements to 0 when possible
… we can, but we can question the use of a normative statement that’s not testable
… The other point - i’m totally happy if the group wants to say that resolution is in scope
… and we’re going to avert our eyes and go down this path if the WG feels that’s the right direction
… Listening to the arguments, we have a name for the process where you provide a DID and get back a DID Document - that’s called the resolution process
… these tests that we’re going to write are going to be resolution tests
… nothing wrong with that. Just want the group to be on board that that is what we’re doing
… if we’re honest we can do a better job in the spec that that is what we’re doing
… we can say it is a resolution tests
… we can say it’s a resolution function not a resolver, which I think is what justin is trying to do with the PR, but the PR comes across as defining the resolution process
… This whole us pretending that we’re not doing resolution is very problematic
… I think this is more a request to the chairs that you’ve got to put something forward to the group that makes it clear what the reading of that statement that drummond put into IRC is, because that is definitely not my reading of it
… it’s so vague, who knows what it means
… as a group we need clarity on whether or not resolution or this functional view of resolution is what we’re going for

Dave Longley: you could use a valid resolver to implement the tests we’re talking about – but you could also use an invalid resolver… i think that’s important.

Manu Sporny: if the group agrees, it becomes much easier to write normative statements around that

Drummond Reed: I’m going to defer to justin, but I do agree that the more we can be direct about the resolution process the easier everything gets
… I also want to point back to phil’s point, if our charter has a statement like this in it and it’s determined by the chairs that that means we can define this contract based approach to resolution, which I also want to point out by definition resolution is abstract because the actual resolution process gets defined by DID methods

Justin Richer: +1 to “requirements on did methods” but not “did methods”

Drummond Reed: we’re defining the requirements on DID methods but not the methods themselves

Kyle Den Hartog: I would be quite in favour of calling it what it is, calling it resolution
… I think it makes life simpler
… with that said, I recognise the scope creep
… i think that can be avoided, that’s a method’s responsibility to define that
… something we can define within DID core to make this normative is a DID method must define a deterministic mapping between a DID or a DID URL and a DID document
… and put some normative statements around what that DID Doc should look like
… that’s what I care about when I say contract
… that I put a string in and get a DID document back.. and the one I expected

Justin Richer: push back what kyle is describing, is definitely more of a resolution style test, I agree the group’s direction as it is right now, that is a bit far out
… what is not far out is defining I give you a string and that string is a valid DID and I get back a DID Document
… I really like what drummond said, defining requirements on DID methods and DID resolution, but not defining DID methods and DID resolution, which is the line I was trying to hit
… this is not just jumping around the charter interpretation weirdness
… this would actually be valuable
… even if we were doing a detailed resolution spec, we should still have these high level functions and they need to be normatively tied to if you have a DID and you’re getting a DID doc, this is what you do
… we’re already doing that in section 9 with DID methods
… we’re putting normative requirements on DID methods
… if we can’t do that with the resolve and dereference functions, we have to delete or make non normative the DID methods section

Manu Sporny: +1 to move DID Methods out.

Justin Richer: we can’t argue that one is allowed another is not

Justin Richer: -1 to moving methods out

Drummond Reed: I agree with that conclusion of Justin’s

Justin Richer: that’s not what you were supposed to take away from that., manu

Drummond Reed: Total -1 to moving DID methods out

Brent Zundel: what if it was reworded: “all implementations MUST provide a dereference function that accepts the inputs: did-url, input-options; and which provides the following outputs: content, did-document-metadata, did-dereference-metadata.”

Phil Archer: I think I agree with Justin’s conclusion too

Manu Sporny: No, I think it’s a good idea… let’s take DID Methods out… that belongs in a separate document too… DID Method Authoring Requirements….

Brent Zundel: is that more testable and more appropriate? ^

Justin Richer: how is that different?

Brent Zundel: it’s not but it could be more palatable

Kyle Den Hartog: -1

Brent Zundel: thanks for coming everyone

Drummond Reed: Thank you Amy!!