Meeting minutes
<ottomorac> transcriber-bot, connect
Agenda
Otto Mora: Sounds good. Um… Let me...
… So, today we, um… we have, uh… a
… request for a manual regarding the VC-recognized entities and some references that they want to make
… Uh, then we have a dip resolution PR with, uh… some small changes that, um, Steven had. Uh, then we have another resolution issue that we just want to check on
… And then, uh, we'll be resuming the Digital Realty Referencing, uh, discussion, which centers around PR344 from, uh, yesterday, uh, from the Special Topic Call, so we'll be continuing that. Anything else that folks want to add?
VC Recognized Entities: reference to WhoisService and PathService
Otto Mora: Okay
<ottomorac> w3c/
Otto Mora: No worries, so we'll move on to the first topic, which is VC-recognized entities, and this… ah
… Uh, link here. I'll, uh, I'll share my screen to present that, but I'll let Manu kind of
… maybe speak more to what the request is
Manu Sporny: Alright, great. Uh, thanks, Otto. Um...
… Uh, so, uh, the W3C Verifiable Credential Working Group, um
… Is has a task force called the Recognized Entities Task Force. And the purpose of that group is to basically let anyone, any entity, uh, it could be a big giant authority like a business register or
… uh, you know, uh, GS1 or some government, um, uh, recognize who should be issuing things like
… birth certificates, or driver's licenses, or things that have, you know, a regulatory, legal, you know, purpose
… Or it could just be for you to say, like, hey, I've got a club, I've got a, you know, a
… a book-reading club, and these are the members in the book-reading club that I recognize, right? So these are… it's not, you know
… uh, X509 certificates, uh, necessarily. It's just a way for you as an individual or as an organization to say, we've got an ecosystem, these are the people that I recognize to do certain things in that ecosystem, like issue a credential. Um
… In that specification, we have, um, discovery services, so if you get a verifiable credential that's issued by someone, and you don't know who the issuer is, how do you figure out
… you know, how to get to an issuer you do know, or someone that you do know that recognizes that entity. So, um, uh
<JoeAndrieu> We really need to stop using language about recognition lists as being about who "should" issue credentials.
Manu Sporny: so… so that's what the recognized entity spec is about. It… it's… it's… you will get something in a verifiable credential, and it's… it'll be like, hey, if you don't know who I am as an issuer, go check with, you know
… for lack of a better term, the authority on issuing these types of credentials. They know who I am, and so you trust them, and I issued this thing, so my credentials should be good for you, right? Okay, so one of the discovery mechanisms that we have are DIDs, right? And specifically
… um, things in the WHOIS service, um, or things that could exist in the PATH service. And we, uh, talk about an algorithm in that specification about, like, hey, if you see a DID
… there's some discovery stuff that you can do. You can go to that DID document, and if they have a WHOIS service, you can go and look at the WHOIS service, and they might have a recognized entity credential in there that tells… speaks to, kind of, what communities or what ecosystems
… they're a part of. Like, you know, what credentials does that DID… is that DID officially recognized to issue, for example?
… Um, okay, so in the spec, we talk about WHOIS, and we talk about PATH service, and one of the very good pieces of feedback we got was, hey, why don't you just normatively refer to WHOIS and PATH service over in the DID resolution spec? And we were like, uh
… We're still kind of working on that. I don't know if we've got a stable reference that we can point to, and so this conversation is about
… Does this group feel like we have a stable reference?
… that the Verifiable Credential Working Group can use
… Such that we will not block them from going to candidate recommendation and recommendation on the timeline that they're on
… Which is… might be faster than the timeline we're on for did resolution
… Um, there are a couple of ways that we could go forward. We could, one, create
… A well-thought-out. Who is Service Pat, Service, you know
… discovery mechanism portion in some specification, and tell them to link to that, and promise them that we're going to get to REC before they do. Or, we could look at their spec, and the algorithm they have there, and give them a nod, and say, yeah, that looks low-lined, and once we have. A good
… normative reference for you, you can update to that. But until that happens, like
… Stay separated from us, keep going on your timeline, and then once we catch up, you can link to us in the future
… Let me stop there, see if there are any questions, concerns, additions, changes
Otto Mora: Yeah?...
Pierre-Antoine Champin: I do believe there's a third way. The fact that deed resolution is now in candidate recommendation makes it, I believe, an acceptable reference for a rec...
… Because there's the… one… one level… one maturity level of difference which is tolerated. So… I believe that if… if we publish it as a candidate recommendation snapshot. they could normatively reference to it, even if they go to RAG before us
Otto Mora: Okay. Yeah, Marcus?...
Markus Sabadello: Uh, yeah, just to talk about a comment that I posted on that issue, there is another service type called Linked Verifiable Presentation, and...
… To me, it feels like that would be the right mechanism for
… for solving the the use case. And it's also the service type which which the who is feature indeed. Webvh is is using. It's also using the linked verifiable presentation service type
… And I think that's designed for exactly this use case. You have a date and you want to find out something about who is behind that
… But it's a TIFF specification. I'm not sure if that can be referenced
Otto Mora: Uh-huh...
<Zakim> JoeAndrieu, you wanted to say I don't think we have time to get WhoIs into did resolution. Maybe we'll get PathService in.
Otto Mora: Yeah, I'm familiar with JC's work on that point. Uh, Joe?
Joe Andrieu: Um, yeah. So...
… I don't think right now we have any good language in our spec about who is. And I don't think we have time to get it into our current work. Um
… For path service, I think we have a shot. This is wrapped up in PR 344 and how we're gonna resolve the referencing
… Um, and frankly, we need to get to that before we get to who is, because who is is designed to use the past part. So, those two things need to work in synchrony. Um
… And I think if we try and take that on, we're… we're not gonna finish this spec
<Zakim> manu, you wanted to ask about spec text that talks about Whois and PathService for /whois.
Otto Mora: Okay...
… Manu?
Manu Sporny: Yes, I agree with Joe. I don't think we want to add one more thing we're working on. But we have to ask this group and understand what the position is. So I agree with Joe. I don't think we have time for who is...
… Um, uh, and I also agree with Joe, path service might be the way to do this. Uh, Marcus, to your point, the link verifi- we did look at link verifiable presentation, uh, its spec status is marked as pre-draft. Um, and it is not a W3C
… I don't… we can ask. I don't know if that's the right solution, uh, because we're… because it's in a bucket of solutions that could be the WHOIS service, PAT service, and now we've got link verifiable presentation. And so, we need to tell them
… to link to something. I can bring it up with the group if they want to, like, not use the WHOIS service or PAT service and use link verifiable presentation instead. Uh
<swcurran> I think LinkedVP is part of it, but whois goes further on who you use LinkedVP in this context.
Manu Sporny: I'll bring that up with the group as one thing that this group, you know, asked them to think about. Um, but what they really need is, like, a good normative
… you know, easily defensible thing to link to. And a pre-draft diff spec probably does not meet that requirement. I don't, and depending on the IPR mode
… Hopefully it was W3C mode, and if it's not W3C mode, then we've got to have a discussion with the lawyers, and it becomes, you know
… maybe a little more difficult. Um, so I don't know how this spec was created, or where the IP on it is, and
<markus_sabadello> https://
Manu Sporny: Uh, but we need to figure that out, uh, as well. Um
Otto Mora: Oh, but it's… sorry, sorry, it is ratified, sorry. There's this version, the 1.0. Yeah, bye...
Manu Sporny: Oh, okay, okay, alright. So then, PA, the question's to you. If we wanted to link to a link-verifiable presentation...
… could we do that? Um, since it's a diff spec and it's ratified, I don't… and again, I don't know what the IPR regime is on… under this spec. Um
<swcurran> IPR is likely W3C Mode
Otto Mora: Marcus?...
<pchampin> the response should be here https://
Markus Sabadello: Yeah, I can't… I can't talk to the legal issues and how to… and whether that can be referenced. On the technical side, I think it would be the...
… the right solution. As I said, who is in GitWebVH also uses this service type, and I don't really understand what this has to do with the PATH service, by the way. I mean, I'm
… not a big fan of the… of the PATH service, but even if I was a fan of PATH service, I don't really understand
… why this is being considered here. Because I think there's nothing really happening with a deed path. Right? The the use case is. you have an issue date, and then you want to discover something about that date. So in in my mind, that's just classic
… uh, resolution and finding the right service endpoint, given a service type, I don't really think you need to do anything with a… with a TID path, uh
Otto Mora: Okay...
Markus Sabadello: Yeah, right, yeah...
Otto Mora: Uh, Pierre?...
Pierre-Antoine Champin: Yeah, just to point out, I pasted a link to the guidelines about normative references. Everything is there...
… Basically, the rules are, if it's available, if it's stable, should be okay. There's a section about licensing, which I should double check as well. But I
… I would be rather optimistic about that, but of course we need to double check
Otto Mora: Mm-hmm...
<Zakim> JoeAndrieu, you wanted to explain the path bit
Joe Andrieu: Actually...
Otto Mora: Okay, and then Joe's gonna talk about the pet service...
Joe Andrieu: About the path, to speak specifically to Mark at this point. The...
… The best definition for who is today is in WebVH. And WebVH proposes that the path part of a DID URL has slash who is. And that is the trigger. And so
… Either that is a method specific dereferencing, sort of fallback
… Or… We have to figure out how the past part works. So that's the entanglement, is that the current definitions for who is, you do use the past part. You could have a service equals, uh
… Who is? That would be a different way to do it, but it's not how they proposed it in WebVH
Otto Mora: Thanks, y'all. Okay, Manu?...
Manu Sporny: Yeah, and from a simplicity, you know, to implement standpoint, it's basically user dereference to get the document at who is...
… you know, it must be a verifiable presentation, and then you look for the recognized entity in there. We're trying to figure out a simple, simple way
… uh, you know, to implement this, rather than pulling in, like, you know, the LinkVP spec is, you know, talks about, like, oh, here are the all the different types of formats you could get back, and it's kind of like, oh, that makes it more complicated, and the group was trying to stick to, like
… the simplest solution to achieve the use case, uh, and not necessarily expand, you know, what the Recognized Entity spec needed to support. Um
… So there's, you know, there's that. So, you know, the, the, the question, you know, is. What does this group suggest?
… They do. And
… Hopefully, what this group suggests is something that group is okay with doing
… because the other option on the table is just remove DIP-based discovery, right? Um, if we can't… if we can't get to something simple, or if this takes too long, or… or whatever, um, which I don't suggest we do, like, I… there's a… there's a… there… there is… just to give a little bit more background, there
… you know, there are, um… are good arguments that did-based discovery is, like, too complex. Just put it in the VC and get it done, because, like, it's… it's so much easier to do it that way. Um
… there are some arguments that, well, there's some ecosystems that are so dynamic that you can't do that. Like, the recognized entities change from day to day, and, you know, um
… You can't necessarily rely on that. We haven't worked our way through all those details yet, but
Otto Mora: Okay. Marcus?...
Manu Sporny: there is a point here where we make it too difficult on the other group, and they're just like, we're just gonna figure out a different way, um, to do it. Uh, that's it...
Markus Sabadello: Yeah, the easiest thing would be to just resolve the data and look for the service endpoint by service type without doing anything with the...
… with the path, I, I think that's the, that's the complex part. I, I understand the design in D2FBH is that, uh, there can be a slash who is path, and then using. Pass service and things like that, you can
… you can then dereference the DTRL and get something back at that path, but this would also require an extra step for the
… processing of the VC, because you would have to take the issuer, which does not have a WHOIS in it, and you would have to add slash WHOIS
… path, then you would have to go through all the path handling, path service processing, which is still controversial. And then you get
… something at the end, and compared to that, you can just resolve the bit and look for the linked EP service type. This is… this is what people have been doing for many years, just looking up services from the… from the bit document, so that would be
… My recommendation without getting into the past of
Otto Mora: Mm-hmm...
… Uh, Manu?
Manu Sporny: Yeah, I mean, a plus one heard, Marcus, that that's your recommendation. Um...
… I think we have three options
… At least
… There's the LinkVP stuff, there's the WHOIS service, and there's the PATH approach. And
… That group is probably going to have to talk through all three of them
… So, for example, Marcus, and this is just me speaking personally, um, I, you know, as an implementer of recognized entities, I don't care how complex the process is that the spec does, or how many different, you know, algorithm steps there are, I just, I'm gonna put in a
… URL to the dereferencer, and I'm gonna get back, you know, um… I'm gonna get back a presentation, and I'm gonna process that. Like, that's… and I want that presentation to have a recognized entity thing in there. Like, I don't care what, you know, DNS does behind the scenes to keep itself updated, I just send it
… you know, a question and gives me an answer. So, I think things like that, um, will come into play, um
… And I think what that group needs to contemplate is that we are dealing with 3 ways to solve the same problem
… And if this group doesn't have a single suggestion, then that group is going to have to reason through
… the different approaches
<Zakim> JoeAndrieu, you wanted to speak to "dereferencer"
Manu Sporny: Which is fine, I'm just saying, like, you know, I think that group was hoping for a simple answer. Yes, ref this section of this spec, and you're done. And I think probably the reality is it's more complicated than that
Joe Andrieu: Um...
Otto Mora: Joe?...
Joe Andrieu: I guess the first thing I want to say is, I think Marcus is right, the simplest...
… Way that has spec text to support the majority of the operation is having a service
… Um, and we did find a type that's who is. Um… Uh
… That's not that much different than linked VP except for the entanglement or not of the diff spec
… Um, but we… we have a service mechanism in our… Uh, toolbox
… And I think that's the way If you want to be most compatible with the rest of the ecosystem, that would be the way to do it
… Using the path or using linked VP will pull in other things that we don't have yet and have more, I feel, have more complications. But I also need to push back against the idea that you're just going to call a dereferencer. We also don't have a standardized dereferencer
… I'm opposed to that. What we have is a resolver
… And we have someone who's calling that. And so I really want us to clear up our language around the client to resolver, that's the dereferencer. We don't have a client to a dereferencer. Like that error is part of what is a quagmire we're caught in
… And what is needed
… for DIDs is resolution. And we have a API that supports that. And what we're trying to figure out is how do you properly call that API? How do you prepare for it? How do you actually execute the call? And how do you respond to the response?
… Um, we do not have any consensus about defining a standalone dereferencer, um, and what its inputs and its outputs might be. Um, and we just define that the output might be a VP. Um… That's… that's weird and strange to me. So, you know, the
… I just want to try to get to the simplicity that our specification is asking us for is that we have resolution, we have a resolver, and we need to talk about how you call that. um
… Talking about other potential pieces of software that might be written distracts us from what we're trying to standardize
<Zakim> manu, you wanted to ask about "ok, then which service?"
Joe Andrieu: That's it
Otto Mora: Yeah. Uh, Manu?...
Manu Sporny: Okay, so, uh, if we go down that path, then which service? Should that group use?...
… Who is service or the Link VP? One
… and I haven't heard from Steven yet, but I don't know, Steven, if your slash who is thing, I… you know, if nobody's fighting for slash who is, that's fine, uh, you know, we can kill it, but
Otto Mora: Okay, Marcus, and then Steven...
Manu Sporny: what, uh, what service are we suggesting that group uses? And, and, if we suggest something, where's their normative definition for that thing?...
Otto Mora: Michael's...
Markus Sabadello: Yeah, I would also be interested in Stephen's opinion here...
… As far as I know, the WHOIS feature in WebVH uses exactly the linked verifiable presentation approach. I think there is no such thing as a WHOIS service type, but, uh, Stephen… Knows that better
Otto Mora: Okay, uh...
<JoeAndrieu> +1 to the lack of a normative definition of the type. and maybe figuring out how to adopt the DIF spec is the fastest route. maybe
Stephen Curran: Um, yeah, I mean, our attempt was to use Slack, who is, and try to move that forward. Um, I am...
… lost at the idea that there's no such thing as a URL referencer, and I'm trying to wrap my head around that, so I'm back to waiting on that conversation. I agree that
… The DID link VP is the closest thing we have right now. I would be glad to work on so Manu part of the sovereign tech maybe to help you in moving that forward, moving something forward and I'm glad to do that. Um, I would like to see every
… Uh, did Method be able to support slash who is as a path, but… you know
… you know, Marcus is right, you can just
… Have this convention that there's this one service that you can call, and its purpose is to
… Um, we might want to take it one level up, which is to say, not just to return a DP, but a return a DP with a recognized entity about the DID
… Um, that you're… you're querying on. And that… that is the vision of what SlashU is, that you can just… Oh, who's this issuer? I have no idea who it is. I can… I can re
… Um, the reference, the URL, did slash who is, and I get back a link to BP. I may get back a link to BP that contains
… um, VCs about that DID, and that identifier, and the entity behind it. It's all… this is all in aid of
… identifying who an entity is. Really not
… The use case isn't typically a person, but more an entity, and so it is used in
<Zakim> manu, you wanted to try to suggest a path forward.
Stephen Curran: recognizing entities. That's it
Otto Mora: Thanks, Daniel...
Manu Sporny: Right, so let me try and suggest a path forward. We don't have a normative reference for them right now. I think that's a… uh...
… Hopefully that's correct, right? We do not have a normative reference for you, Verified Credential Working Group. We are working on it. We cannot give you a timeline
… I think that's where we are. I think we've got some good ideas for what it could be. Um, I don't… so that's the current thing, is, like, we just tell them, we don't have a normative reference for you, here's some ideas. Talk about, you know, talk amongst yourselves
… we can try to move this forward, Steven, as you mentioned. I agree with Steven's approach. I think that that is what I would personally prefer to see. Uh, but at the same time, I don't think there's anything wrong with what Marcus suggested as an interim
… Um, because both of them get… get them to the document they need, uh, I think. Um
<Wip> +1
Manu Sporny: But we'll have to hash it out in this group, and I don't think this is a priority for this group right now, meaning, like, we have more important things to do, which is finish the spec. This is a side quest, you know, for us. An important one, but, like, I think we need to stay razor-sharp. focused on getting did resolution. finished off and
… out to out to REC
… So if folks are okay, I can take that message back to the group and then they will think about the different approaches and then maybe they'll provide some feedback to this working group about what they plan to do going forward
Otto Mora: Okay, and do we need to open an issue for for ourselves, or let's go...
… Okay
Manu Sporny: Yeah, might as well track it, right? It's a need that another working group has from this working group...
Otto Mora: Okay, I'll do that. Okay, cool. Excellent...
w3c/did-resolution#354
Otto Mora: Okay, thank you so much. Alright, um, so I wanted to quickly try to get to Steven's PR, and then, uh, I'll just skip over to the 344. So
… Let me just do topic 4, 3, 5, 4. So on this one, I believe it's just a minimal text change from
… From you Steven Right Uh and we just wanted to get folks to review it
Stephen Curran: Yes, um, thanks for bringing that up. Yeah, there… 322 is an issue about how, um, the test suite is suggested to be used...
… And so, I just put in a minor PR that backs off of. Um, saying that implementers
… should be using the TAF suite, saying they could use it, and it might be helpful to them
… So something along those lines. So a very simple change that addresses the particular concern that Joe raised in issue 3, the 3, 2, 2
Otto Mora: Okay, perfect...
Stephen Curran: And that would allow closing 322, I think, as well. So the big thing, Joe, would be to you to look at it and say...
Otto Mora: Okay, cool. So yeah, so… our reviews on this, please, and uh… if everything goes well, we would merge tomorrow...
Stephen Curran: Do you think it… does it address your concern on 322? The reason for you raising 322?...
Otto Mora: dials...
Joe Andrieu: Uh, that's more complicated...
Otto Mora: Yep...
Stephen Curran: Sure...
Joe Andrieu: Sorry, let me jump on the queue since no one's on it...
Otto Mora: Go ahead...
Joe Andrieu: I'm happy with this PR. I did look at it. I was just about to hit my approve button...
… When I realized I needed to click over to the other tab. The
… I don't know that addresses issue 322 and just as socializing an issue rather than opposing this
… I actually I'm not sure that we should be recommending that people do this
… Because the test suite shouldn't be about that. The test suite is about testing the specification for, implementability
… And there's a slippery slope here that I've heard
… Off and on folks imagine that our test suite is somehow proving that software, is correct
… Um, and even listing software so that it can be known to be correct. Um, but that's… that's really not what it's doing, and it's dangerous if people think that it is. Um
… Because we don't have, like, a cybersecurity monitoring kind of capability, so
… All we can do is do self-reported stuff, and it'll only be reported every once in a while. Um, so it's really not a good
… way to think about, how do I know which software is working correct today? Um, but… but I think we should… we should accept this. I think, you know, your change to this
… didn't create this question, Steven. I just wanted to raise it as it, you know… we're using the test suite for two different purposes, and I'm not sure the second one's really gonna help us
Manu Sporny: Uh, yeah, I...
Otto Mora: Mm-hmm. Uh, Lana?...
Manu Sporny: Uh, don't disagree with a lot of what you said, Joe. Um, and I think folks know my position on this. I think if we leave. a vacuum...
… In the ecosystem, somebody else will fill it, and they may not have the same motivations that we do
… And so, total plus one, totally agree. The purpose of W3C test suites is to… the primary purpose is to test the specification and the implementability of the specification
… That is definitely not in question. We, Digital Bazaar, are seeing other organizations enter into the conformance testing sphere. And… A danger is that
… an actor that does not have the same sort of alignment that the DID Working Group decides that they're going to create conformance test suites for DIDs, and they're going to decide, you know, what validation should be, and they will write it into regulation, and that will become the way that
… You validate, uh, implementations. The working group will totally lose its ability to, uh, guide that stuff. We are seeing some of this happen in the European Union already, um, with, you know, uh, testing organizations, finding businesses
… business models implementing or, you know, creating test suites for, you know, some of the specifications that we're writing. So that is the… that is the danger that I'm concerned about. Um, uh
… One way to address that is to make our test suites a little more aligned with the real world and what vendors need in the real world, which is the ability to point to something and say, like
… We're not telling you that, you know, the… we're not telling you that this, you know, you can do your security compliance testing using this thing, but here's a general, like
… litmus test that those security, uh, folks should be running at least as a minimum against the implementation, um, and then they should be doing a whole bunch of other stuff, you know, in the future there. And I agree with Joe, like, this is… this is a long-standing discussion at W3C. I don't think we solve it here, and I don't think we
… should. Take too much
… working group time doing it, I just wanted to air the concern that I have. Um, if we look at test suites in the traditional sense
… That W3C has been looking at them, which is outdated, you know, in the way that, you know, software is built these days. That's it
Otto Mora: Mm-hmm...
<Zakim> JoeAndrieu, you wanted to say yes, perhaps someone with the actual capacity to fill it.
Otto Mora: It sort of sounds like it partially addresses Joe's concern, but not the larger concern. Is that the case, Joe?
Joe Andrieu: Uh, no, not at all, actually. I think this is… Mando and I just have different opinions, and I respect his opinion and the experience that's led him to have that position. Um, but right now, the W3C is struggling with strategic direction...
… Um, and I don't see that creating more registries, creating more monitoring services that we expect volunteers to run is going to scale. Like, I don't think that's going to help us. I don't think we have the constitution, uh, as a body to do the kind of work that you're proposing, Manu. I think it is actually more appropriate
<Zakim> manu, you wanted to note wpt
Joe Andrieu: for someone who has the authority to impose conformance to define conformance to their laws and regulations. What I don't think is useful is for the way that our organization is structured as volunteers contributing to voluntary standards. Um, I think we just don't have the wherewithal, um, to do what you're proposing
Otto Mora: Okay, uh, Banner?...
Manu Sporny: In general, for most working groups, Joe, I agree with you. I will point out web platform tests as a counterexample where the vendors did get together and put something in W3C-ish...
… space and have, uh, you know, um, uh, something there that the vendors, it's not a voluntary thing, right? I mean, it's like they pay money and hire developers and, and fund, you know, open source, uh, you know, projects to, to create and maintain these things
… Uh, so I'm not suggesting W3C take it on, uh, or it's taken on an involuntary basis, but there are examples of, like, very thorough, you know, operational test suites that the browser vendors use as part of their shipping strategy
Joe Andrieu: Ha!...
Otto Mora: Okay...
Manu Sporny: where the work is done out in the open and, you know, somewhat in the orbit of W3C. But again, that's going to be my last comment on this. I want us to move on...
Joe Andrieu: I also want to move on but I just wanted to say yes web platform test is exactly the kind of organization that should be doing it not W3C right they have web platform test suites for what WT specs for W3C specs like I think that should be the place we would put our attention because they are building that capacity I'm worried about
… overwhelming like we we're struggling to manage the...
… that did method registry, um, and people are misusing it as a form of endorsement and all sorts of other things, and I'm seeing registries sneak up in other places that I now have to go and try and talk people out of doing, so
<Zakim> danpape, you wanted to ask about what current did implementers should do with that test suite
Joe Andrieu: So thanks for pointing to a great example of someone other than the W3C, who we don't feel is somehow morally bankrupt and taking advantage of the situation and doing something that we're afraid of
Otto Mora: Okay, Dan, last word, and then we'll move on...
Dan Pape: Hi, um, no, I just wanted to ask, as a DID implementer, um, who was actively writing to that. Resolution Test Suite...
… Should I not be doing that, or should I just
… Understand that that doesn't mean I'm
Otto Mora: someone can...
Dan Pape: I've got a good DID, it's just a DID that's passing the resolution test suite...
Otto Mora: Going...
Joe Andrieu: Yeah I'll just jump in to to to say yes I think that's right I think I think it is useful but you should understand it's it's point was to test the spec. And so...
… Take the results with a grain of salt about where you're at in your development pipeline
w3c/did-resolution#344
Dan Pape: Sure. Okay, cool. Alright...
Otto Mora: Okay, thank you. So okay, so 3, 4, 4 now. So we had a conversation yesterday around this, and Stephen walked us through a presentation with some of his observations on the comments that folks had had raised...
… Uh, and I think we, uh, made some good progress there, but then we also got, um
<manu> Just to note: web-platform-tests/
Otto Mora: into a deeper conversation about a client and. And so a different interpretation of it, I believe. So maybe the
… The idea here was to have Joe explain to us how he's seeing it and why we might be looking at the concept of client a little bit differently
Joe Andrieu: Sure. So I'm going to anchor an analogy that we've used before, but I think it's not working. So I'm going to try another one. But the analogy I've been using is...
… It's like a web browser. And a web browser absolutely dereferences URLs. But what we don't have is a standard for a CLI that the browser itself exposes the result of the retrieval of web pages
… Right? The browser is doing a display action. It doesn't have this function that's a library call where you pass in parameters and you spit out back the resources
<swcurran> A web server does the DID URL dereferencing. Not the browser.
Joe Andrieu: Um, and my opinion is that what we are defining is the equivalent of HTTP, like how the browser actually goes and gets the resource. That's resolution
… And in order to use HTTP correctly, we're describing what you do
… What headers mean, what you do with the response, how you respond to a redirect URL, that sort of thing. But what we're not making the browser do is expose a particular function with a given signature and a given set of return values
… Um
… Another way to think about it is, with, sending an email. So, if you're writing an app, I'm going to pick Node.js just so we have something concrete
… Um and I need my web server that I'm implementing in Node.js to be able to send an email
… I'm almost certainly going to use some library. I'm going to go look at NPM JS and I'm going to find a library for handling mail. And that library is going to have some interface and I'm going to figure out if that interface works for me. Maybe it uses promises, maybe it uses callbacks, maybe it
… It does things in any number of ways. At the end of the day, I'm expecting that with the right configuration profile, that that library will open a call to SMTP
… And actually pass that message on to the email network. And so in in our situation we the SMTP is the resolve spec
… And we are defining an HTTPS binding so that we can call a server and perform resolution, we get back a concrete result. But what we're not defining is we're not defining the interface that that Node.js library has to implement
… And that's because we have use cases that have been excluded from the current definition, the attempt to create a dereferencer that I tried to point out and I got a lot of pushback and said, we'll just use a URL, magically everything's there. But that's not the case
… The way I see this specification is that we need to define resolution. That is the method specific component that every DID method does differently. And what we're trying to do is create a standard interface to resolve
… So that different software applications can all resolve, even if the DID method under the hood does something weird, right? The resolver for a given DID method understands that DID method, but what we're trying to standardize is how you call resolve
… So
… The way I see this is we are not creating a new piece of software that we are standardizing interface for that would call that. The only notion of a dereferencer in the approach that I'm taking is the client of Resolve
… So, some… some piece of software gets a DID URL, and it wants to work with it in some way. It is going to dereference that URL and get it to a handler, so the right handler can do the right thing. And as part of that, it calls resolution
… So I don't know if that new analogy helps at all, Steven, but hopefully that walks around the space a little bit with some more language
Otto Mora: Okay, thank you, Joe. Marcus...
Markus Sabadello: we're defining an interface for resolving, and we're also defining an interface for dereferencing, but these interfaces and these functions have always been meant to be completely abstract. I...
… Wrote a pull request, uh, yesterday, uh, 3… 56, uh, which is trying to explain that a bit better, because it… it seems that this is sometimes
… Misunderstood. There's been
<ottomorac> w3c/
Markus Sabadello: There's some language in the specification which talks about these functions, the resolve function and dereference function
… in a way that says you cannot modify them, and I think you cannot modify the signature, and I think that language is a mistake, so that's why I created this
… Pull request. the language that I'm proposing here
… is to point out that both Resolve and Dereference are abstract interfaces to algorithms with logical inputs and outputs, but it does not mean that you have to implement them as an endpoint, you don't have to implement them
… in a specific form, such as a function call or an SDK, you don't have to use the, uh
… names of the variables in the way as they are in the spec. You don't have to have a function that's called resolve or dereference. These are abstract interfaces with logical inputs and outputs for a resolve algorithm and a dereference
… algorithm and I'm hoping that this is an improvement
<Zakim> manu, you wanted to ntoe maybe we just add a word "resolution client"?
Otto Mora: Okay… Thanks for that. Um, Manuel?...
Manu Sporny: Uh, yeah, going back to, uh...
… what… something Joe said about, uh, you know, what… what he means by the word, you know, when… when… when he says client. Um, maybe we can just add, you know, typically what happens when we… when a word means two things, maybe we can qualify it. We're talking… Joe, you're talking about the resolution client, right? Meaning, like
Joe Andrieu: If you want me to jump in, there is only one client. I would oppose defining two clients. I think that is the disconnect. Like, that's what we're arguing about...
… Like, we need resolution. There are clients to resolution. Creating a new piece of software that
Manu Sporny: Yeah, oh...
Joe Andrieu: We now need a client that's a client of another piece of software. That's what I'm opposing. I think that's a bad idea. I don't think we have consensus around it. I think the way it was presented in the spec to date did not clarify that that is what was happening. There's no diagram that points to a dereferencer that calls the
… resolver and a client that's calling the dereferencer...
… Like that it was discovering that this was what was behind the function definition as Marcus was working on it that raised alarm bells for me
<Zakim> manu, you wanted to react to manu
Joe Andrieu: Sorry
Manu Sporny: yeah, noted… sorry, I put myself back on the queue, uh, because I was just expecting a yes or no answer. Um, that is totally fine. Um, uh...
… I'm not speaking to that thing you just responded to, Joe. I know you're on the queue to respond to Marcus about it, like, and I… you know, that's a separate thing. I'm trying to get down to just… when we say client, I think people are getting confused. Like, because in their mind, client could
… be a bunch of different types of clients, and it's not clear. So, all I'm saying is, like, let's put a word in front of the client when we use it, so that people understand we're talking about a very specific type of client, the resolution client, the resolver client
… Um, and that client is separate from other types of clients that do other types of things. The, the thing that tripped me up yesterday when we were talking about this, Joe, is, you know, you were like, well, um, and then the, the, the client should make a call
<markus_sabadello2> DID 1.0 terminology entry for "DID URL dereferencer": https://
Manu Sporny: on what, you know, properties it should, or what, you know, query parameters it should allow through and which ones, you know, it shouldn't. And I was kind of like, which client are we talking about, right? So like, and then we started talking about business rules and I was like, well, resolution clients don't have business rules in them. They
… don't know about the use cases
… And so, I was getting very confused about, like, which… which part of the system, you know, uh, we were talking about. Um, I think
… I think you were talking about a resolution client, but I wasn't sure yesterday. So that's the suggestion, is, like, can we
… We should stop saying client because it's confusing. Just like just saying user agent can be confusing when talking about code executing and business rules and things like that. So it's a question. I'm not talking about anything else. I was like, let's stop saying client
… Let's say resolution client so that we're just talking about what the resolution client should be doing. Um, that's it
Otto Mora: Thanks, Ronald. Steven?...
Stephen Curran: I mean, Joe, your explanation somewhat helped me understand your view, but it didn't help me understand it...
… I think that we're not defining what a browser does, we're defining what a web server does, if we want to use that analogy. A browser sends to a web server a URL
… And that web server has a way to figure out what to do. Now a web server can do anything it wants and each one is unique to the
… Um, to the base that you send it. In this case, what we're trying to do is
… standardize a way for a URL to be interpreted so that different implementations can interpret the same URL
… Um, the same URL in the same way
… taking into account that the DID may be… the DID method may be different for each one, but if the same DID… the same… essentially the same URL is passed in. Um, it's going to
… react to it in the same way. I think that's what we're trying to do. We are trying to define a way to come up with a way to implement a library that is consistent
… Given that the DID method will influence what those things are. So yeah, very much a difference in mental model
… the source of much disconnect. I don't understand what
… you know, my reaction to your statement would be to say, let's remove the DID URL algorithm from the entire spec, and just stop it, resolve, and be done with it, and just stop this whole conversation. That's my reaction to it, if yours is the appropriate. Um… um, interpretation. I… I would really
… Maybe try to have somebody else try to present that
… That same model, maybe in a different way, so
<Zakim> JoeAndrieu, you wanted to point out we are not defining an interface for dereferencing.
Stephen Curran: Because, Joe, I've heard it, and I don't understand what it gets us. That's it
Otto Mora: Thanks, Stephen. No...
Joe Andrieu: Yeah, for most of what you said, Steven, I was nodding along because I agreed with the words that came out of your mouth. But then there was a twist when you said, well, we are defining the library. What we are defining is the web server, which is running this Resolve, like in the analogy...
… It's the resolver that we are trying to figure out. And that is the hard function whose inputs and outputs we are being very specific about how you serialize them so that we can have interoperability across different resolvers, even for different DID methods
… What we are talking about in the dereferencing algorithm is how you call that. Like what you need to do beforehand. And then what you do after when you get the result back, because it did resolver will give you a did document and the did document because of the extension points that we have
… May have some very complicated additional things that you need to do to actually get to the resource pointed to by the did URL, whether it's a linked resource or did linked resource or a path service object like there are different ways that you may need to interpret that did document. So it if. If
… If we end up there, I agree, getting rid of the dereferencing algorithm altogether may be our best option. I think that's something Marcus would, not Marcus, I'm sorry, Dimitri would back. He's always said, look, we're defining resolution. I don't understand the stuff that's before it
… Personally, I think we have all this complicated stuff beforehand and afterhand that is unique to our particular type of URL, and I think we should explain that. Um… But the, the
… the equivalence in your analogy is the server side Http endpoint. That is the resolve endpoint that we are trying to standardize around. But how your Npm. Library might expose a feature to an app that's running. That's entirely up to whoever's gonna write that NPM library We
… We don't have, I believe, a consensus to define that interface
Otto Mora: Okay, Marcus was next...
Markus Sabadello: I posted a link in the chat to the terminology entry for DID URL dereferencer in DDRL 1.0. It says DDRL dereferencer is a software and/or hardware system that...
… performs the TTRL dereferencing function for a given TTRL or TID document. This is something we've had in the standard for many, many years
… really don't understand, Joe, why you want to remove that, or why you think it's a bad idea to have TTRLD references. You keep saying things like, we should not define interfaces or functions for a new piece of software, but it's not a new piece of software. Anything that
… implements a DDRL dereferencing algorithm is a DDRL dereferencer. The piece of software that you have that verifies a credential and looks up the public key for verifying DVC, that is also a dereferencer. It doesn't
… need to be a separate component, or a remote endpoint, or an explicit method call. That's what I'm trying to emphasize in my latest pull request, so
… I really don't see why we want to remove this abstract interface that we've always had
<Zakim> manu, you wanted to note that talking about the client is useful (and needs to be done /somewhere/).
Otto Mora: Okay, um, Mano?...
Manu Sporny: Um, right, uh...
… I… maybe it'll be useful to highlight the options, you know, that we have, and the one that we've kind of… we're down the path of, right? So, Steven, you know, you mentioned, like, we're really talking about the web server, you know, portion of this, the server-side component. Um, like, why don't we just define that
… in, you know, one way, and be done with it. We don't have to define all this resolution and preparing stuff and whatnot. So, and as Joe mentioned, that is what Dimitri had suggested we do. That is one path, and it's a totally reasonable path that we could take
… Um, and it's the most minimal path, right? Like, if we make that decision, we're pretty much done, and as a working group, we're done, and we can move on. Um, uh, however, the other thing that we could do, which is a bit more of a step, is define
… the web servers part of it, and the client part of it, or at least talk about the client part of it enough where a implementer can figure out what they more or less need to do. We kind of spell it out for them. And if we think about the web
… We have the HTTP spec that largely deals, you know, in talking about how, you know, servers should respond. It also talks about clients there, right? And we have a massive specification
… Uh, on how user agents behave when they process HTML and all that kind of stuff. So, at some point, somebody's gonna have to write all this stuff down, right? The question is, you know, who's gonna do it, and what gaps do we leave if we don't do some of the work?
… So I think where the group is currently, I think where we have, you know, consensus is let's at least talk about this. We have to talk about the server component, you know, of this thing. And we should talk about the client component, the, you know, resolver client part of it
… Um, enough so that an implementer has a pretty good idea of the things they need to consider and take into account, no matter how they choose to implement this thing, right? I think that is… I think, Joe, that's your position and what we're working towards
… And I think we have a lot of consensus in the group to do that. I think that is kind of the middle ground that we're at. And then the next step, we could go further and we could more concretely define the, you know, functions, abstract functions, whatever, which is, I think, Marcus, what you're saying, like, we've had this in here for a long
… time. Why are we removing it? Why can't we just
… You know, define this thing so that we're even more concrete about, you know, um
… what an implementer, uh, should do. And so I think that, that thing, I don't think we have consensus for, um, uh, Marcus, and I think that's why we're, you know, discussing, uh, this kind of, uh, more, more middle ground. Um
… Each one of those things, I think, is a technically reasonable thing to do. I know there's disagreement in the group, but, like, those are three steps, and we're on, you know, we're on… we've decided to definitely do the first step, and we're doing the second step now
… Um, and I think there's an argument, Marcus, that the third step belongs in software libraries, and that is something that some software library author, you know, is going to do. Um
… and that that's fine, because they're going to fill in the gaps, right? So, speaking as an implementer, we're gonna implement something, and whatever the DID resolution spec leaves out, we're gonna figure out some way to do it, and write a software library, and we're gonna put it out there
… And maybe people use our software, maybe they don't, but we do have to fill in all of these gaps on how all of this stuff happens. So hopefully, the spec helps us do as much of that as possible. But whatever it doesn't mention, like, for example, if there isn't a dereferencing function signature
… We're going to create one because we have to in order to write software, right?
… So hopefully, I think, you know, so Steven, like, I think that's why we're talking about clients, because it's helpful to implementers to talk about them more holistically about the ecosystem. That's why we went just beyond the server stuff, but I think that's also the reason why we're not going all the way to
… Specifying, you know, the dereferencing function, and inputs and outputs, and your concrete inputs and outputs, and things of that nature. That's it
Otto Mora: Okay, I want to give the last word to Joe since we are at time. So last word, Joe...
Joe Andrieu: Oh, we're out of time. Yeah, I know, unfortunately, Marcus, I know you're probably going to want to respond to this, but we did have a resolution maybe two months ago...
… To get rid of the function for dereferencing because it created confusion
… by creating two clients, which was counter to the definition of clients in the spec. And, people didn't understand if the dereferencer is calling resolve or the like. The whole thing was confusing, and it was over prescriptive for use cases
<markus_sabadello> Link to that resolution?
Joe Andrieu: That I personally have implemented, that you have agreed should be standardized. I mean, it should be conformant, but according to that language, it would not have been. And so we had this conversation several months ago. We as a group did have a resolution about it. So I've been proceeding on the basis that that resolution was a decision we
… made. Um… I understand that you'd like to reverse that decision
… I was looking for a link to that, Marcus. I couldn't find it in the time we had on this call, but it would be good to track it down
Otto Mora: Okay, I'll try to track it down. Okay. So, we'll discuss those options. I'll have the, uh...
… link to the resolution, and we'll more detail on it. Thank you