[MINUTES] DID WG Special Topic 2025-10-01

Meeting Summary: DID Working Group Special Topic Call - 2025/10/01

*Attendees:* Benjamin Young, Dave Longley, Dmitri Zagidulin, Joe Andrieu,
Manu Sporny, Markus Sabadello, Parth Bhatt, Shaun Conway, Stephen Curran,
Steven McCown, Ted Thibodeau Jr, Will Abramson

*Topics Covered:*

   - Discussion on how the DID resolution specification should handle paths
   in DID URLs.
   - Review of existing approaches to path resolution in DID methods (e.g.,
   did-web, did-cosmos).
   - Backward compatibility considerations with existing implementations.
   - Whether to use service endpoints or other properties for path
   resolution.
   - Defining the scope of the PR to be raised.

*Key Points:*

   - *Problem:* Current DID methods handle paths inconsistently, leading to
   interoperability issues.
   - *Proposed Solution:*
      - Define a standard approach within the DID resolution specification
      for handling paths.
      - DID resolvers would look for a specific service type (e.g., "static
      path resolver") in the DID document to resolve paths.
      - If the service is not found, fall back to did method-specific path
      resolution, ensuring backward compatibility.
   - *Algorithm:*
      1. Resolve the DID document.
      2. Look in the DID document for a service that matches the path in
      the DID URL.
      3. If found, use the service definition to resolve the path.
      4. If not found, use the did method spec to resolve the path.
   - *Implementation:*
      - A base PR will be created to add a new section in the DID
      resolution spec to address path resolution.
      - Additional PRs will be raised for specific resolver types: static,
      dynamic, and one for Cosmos.
      - The group will reach out to the did-check community for feedback.
   - *Key Decisions:*
      - The group agreed to use service definitions to handle the
      resolution, which will be the standard approach.
      - The DID resolution spec would include "must" statements for new
      mechanisms, but DID methods could override path resolution.
   - *Next Steps:* Stephen Curran will take the lead on creating the base
   PR.

Text:
https://meet.w3c-ccg.org/archives/w3c-ccg-did-wg-special-topic-2025-10-01.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-did-wg-special-topic-2025-10-01.mp4
*DID Working Group Special Topic Call - 2025/10/01 10:01 EDT - Transcript*
*Attendees*

Benjamin Young, Dave Longley, Dmitri Zagidulin, Joe Andrieu, Manu Sporny,
Markus Sabadello, Parth Bhatt, Shaun Conway, Stephen Curran, Steven McCown,
Ted Thibodeau Jr, Will Abramson
*Transcript*

Will Abramson: Hey there Joe.

Joe Andrieu: How you will

Will Abramson: I don't know if we should have changed back to Zoom for this
call, but let's go. they're doing

Dmitri Zagidulin: Hello.

Joe Andrieu: I'm gonna ping Sean Conway.

Joe Andrieu: Who else are we hoping is going to show up? Okay.

Will Abramson: Marcus said he was coming.

Will Abramson: I hope Manu will come, but I don't know. Mar just said he'd
be a few minutes late.

Will Abramson: Hopefully a few more folks joining. Good start. Hey man.

Manu Sporny: How you doing?

Will Abramson: Yeah, I noticed that this is still in Google Meet. I think
that's fine, right?

Will Abramson: Do we think we okay just to continue this call in here and
not scribe and just use the transcription?

Manu Sporny: Yeah, because it's being transcribed and…

Will Abramson: Yeah. Right.

Manu Sporny: it'll be summarized and sent to the mailing list and
everything. So, yeah.

Will Abramson: That makes things a little easier. so Marcus did let me know
he's going to be a few minutes late. I know D you said maybe Sean will be
coming.

Will Abramson: Happy to get started or we can wait a couple more moments.
Okay.

Joe Andrieu: Yeah, I think I'd give Sean a 50/50.

Joe Andrieu: Because the date was changed. It was unclear if he could make
this date, but he did say he was going to try.

Will Abramson: Maybe we get started and see how we go. People trying, we
can always refresh them. So yeah, welcome to today's special topic The
focus today is really a discussion around the bid paths and there's three
labeled issues on the bid resolution repository and I had a little review
of them before this call. I think there are two almost like separate
discussions going on there.

Will Abramson: One is what does the DID resolution specification want to
say about standardize around how paths should be design developed defined
by DID methods versus the other end of the spectrum not saying anything and
leaving it up to DID methods to just define how paths work for the dids in
their method or did extension and then the other one is I think mano the
issue you raised around do we want to do anything to create a specific path
some standard functionality that we recommended methods use an easier way
of doing relative ref or URLs. So I don't know where we start.
00:05:00

Will Abramson: I mean I think the first I would probably say we start
around the issue that Joe raised 150 so that's this issue and it is more
about what is did resolution what do we want to do as a did resolution spec
to define path more generally currently path is referenced very little in
the dreferencing algorithm we basically say bid methods can define how path
should be interpreted There are no normative requirements in the divided
resolution spec today that define how paths work. I think in Joe's issue,
he's at least highlighting that there are currently numerous different
either did methods I mean or did extensions that are defining how path
works and they're not defining them in a compatible way.

Will Abramson: So the question is is that a concern and do we want to do
something about matter

Manu Sporny: To directly answer that, yes, I think it's a concern and yes,
I think we should do something about it. Primarily because I think the path
we're on is just going to lead to conflicts and interoperability problems.
so that's Statement two is but there exists a world out there that is
already there at some level of deployment and so we need to be careful
about not breaking the existing ecosystem or if we are going to break the
existing ecosystem we have to have a very good idea or reason to do it but
I think there's some proposals on the table where we don't break any
anything and make it non-backwards compatible and we still

Manu Sporny: at a better path to interop. what I would like is for Joe you
to go through issue 150 and kind of explain what you're trying to get at
there. I'm trying to read through it,…

Joe Andrieu: Sure, happy to do that.

Manu Sporny: but I think it'd be good if we're going to discuss 150. I
think it would be good to just get your perspective on…

Will Abramson: Yeah, just

Manu Sporny: what you think the issue is and then what you think we might
be able to do about it.

Joe Andrieu: Do we have a queue? I'll just dive in then. the short of it is
that working with did Cosmos we came up with a mechanism that used a linked
resource property in the DID document which then had a path property that's
where you would look if there was a path part DID URL. you would go look up
the path property in the linked resource section that matches and that
would let you know what to do with that path.

Joe Andrieu: but For example, with did webb there is a proposal for a slash
and that is handled differently. And so now we have a situation where
unless I know and every did method deals with the path part differently. I
have to have bespoke language to figure out what do I do for each did
method. And I think it would be worthwhile for us to converge to understand
what do we want to do with the path part in the URL itself. what is that
what are we going to do with the URL syntax and then where do we put it in
the did document or did metadata because that's also a tension between the
did linked resources which is not the linked resources that's the checked
initiative where their linked resource data is in the metadata document.

Joe Andrieu: So now we also have two places that you might go to find what
you're supposed to do with this path. So I think all that's just really
confusing and…

Joe Andrieu: I think it would be good if we could figure out how could we
harmonize this so a common dreerence or resolver could look at this did and
understand there's a path part here's what I do with it and that's
hopefully largely true regardless of the method.

Will Abramson: Great. Thanks,…

Will Abramson: Nice.

Manu Sporny: Yeah, plus one on that goal.

Manu Sporny: I think that that would be great if we got there. I am a bit
concerned that we may not get there because people have already done things
that are potentially just in conflict with one another. but I'm saying that
without, knowing for certain that's the case. I'm wondering so I think Joe
you outlined some patterns that I think are useful meaning if there is a
path then potentially in the DID document there is a way for you to figure
out…
00:10:00

Joe Andrieu: Yeah.

Manu Sporny: how to resolve that path. Right? So, it's a giant handwave,
but it's kind of like I think the general approach that might work did
resolver sees a path. there ideally is a standard way like a service
description or something like that in the DID document that the resolver
can then take a look at and see if the path matches something in there. and
then it does some standardized thing.

Manu Sporny: and if it doesn't find that generalized mechanism whatever
we're going to potentially create here then maybe the way we continue to
have backwards compat is we say and then you might have to do something
that's did method specific and that's totally up to the DID method and we
really wish people would not do that but we can't stop people from doing
that and so did in their drivers decide that they're going to process paths
and did method specific ways.

Manu Sporny: But I think what I would like us to accomplish is to define
for example a service endpoint that says that maybe matches on a particular
path description and then has some kind of instruction on where you should
go or what you should do to resolve that path to something else.

Manu Sporny: an alternate URL, a resource something of that nature.

Will Abramson: Thanks, Demetri.

Will Abramson: You're all muted speaker.

Dmitri Zagidulin: Oops. Thank you. so that first option that Mona mentions,
I think that would be ideal as well in the sense that we're essentially
defining a trait, We're defining a, standardish control flow. a path, look
in the service descriptions for one or more path related services like this
is the default handling path. this is apply that if it's not there fall
back on the did method spec if not I don't know throw an error…

Dmitri Zagidulin: but I think that would allow us to in a backwards
compatible way u essentially address this elegantly

Will Abramson: So I have a question maybe someone tweet…

Will Abramson: how is this backward compatible with did checks approach and
even did cosmos approach if we're having a sounds like you're proposing
that a service is the place that would be resolved where you would go look
in the service to find what out the path right and I think is the did
linked resources approach they kind of do it very much custom on the divid
method and then the linked resources has its own property in the divid
document as I understand it maybe someone can help me understand that

Will Abramson: All right. Mhm.

Manu Sporny: Yeah, I mean that's the fallback, that's fine. it's totally
backwards compatible with that. and the way it's backwards compatible is a
did resolver will go and look for this, generalized trait as Dimmitri said,
it sees a path. It's like, okay, one way that I could resolve this is I go
and I look for a very specific service like a static path resolver service
and it's got some properties and I'm going to go in there and I'm going to
look for that and I'm going to use that to come up with the new URL that
actually has the resource.

Manu Sporny: But if the did resolver doesn't find that service or
description for it, which will be the case in checked or webvh or whatever
then its fallback is then I'm going to do something very did method
specific and the driver is going to take that path and then try to resolve
it. as so I think that works. we don't do anything that breaks the existing
ecosystem. If they don't want to use this new mechanism, then they don't
need to and they can continue to do what they're currently doing with the
downside that it's did method specific.
00:15:00

Will Abramson: Okay. Go.

Manu Sporny: And that may or may not be a good

Joe Andrieu: Yeah,…

Joe Andrieu: plus one to that notion of backward compatibility. if we can
agree on a way to do it go going forward that has the least amount of
disruption then we can adopt that moving forward and as long as we don't
break how they're already doing it that fallback I think does work pretty
well. I'm not sure it should be a service endpoint. but I'm not sure that
it shouldn't.

Joe Andrieu: when we put things together for the linked resources, it
didn't feel like a service endpoint, but there was some debate even amongst
our team why don't we just make this a service endpoint. and the biggest
difference for us was a feeling so I don't know if it really has technical
merit but the sense was that what we're talking about is a specific
resource that's going to be secured in any number of different ways. It is
not an arbitrary service endpoint that's returning arbitrary content. It is
a link to a specific piece of content that is baked in our case it was
NFTTS. So we wanted to know for example that the image that we're telling
you is the image for this NFT has this hash and not that it's an endpoint
where you get the image and it might be whatever that endpoint returns.

Will Abramson: I'm perfect.

Joe Andrieu: So there was a bit of a distinction for us in that but I'm not
sure how important that distinction is from the standards level.

Manu Sporny: So I want to get into that discussion, but I want to make sure
that we're all in agreement on this general notion of, it's basically what
Dave Lonely put into chat, that's the algorithm that we're suggesting that,
we think is probably going to work. and then we can get into, the details
of, is this a service endpoint? is a different property and that sort of
stuff. But I don't want to get to that discussion until we have consensus
that effectively what Dave has typed in the chat channel is what we want to
do. By the way, that is not going to be saved we need to say that out loud
because it's not going to be saved in the minutes. sorry let me say it out
loud. So Dave or Dave, do you want to say it since you wrote it?

Dave Longley: Yeah. Yeah, that's fine. I just wrote four quick steps here
to describe when Will was asking about how this is backwards compatible. I
wrote a quick little algorithm for a resolver which step one is resolve the
DID document which would be DID part of it. Then you look in the DID
document for a service that matches the path on DID URL. if it's not found,
which will always be the case until anyone adds this new feature. So, this
will cover all the backwards compatibility cases. So, if you do not find
that, the did method spec to resolve the path. But if you do find it, so
someone has opted in to using this new feature, then use that service
definition to resolve the path. And then we can debate whether or not it
should be a service definition or something else. but that's the general
idea.

Will Abramson: Thanks, Demetri.

Dmitri Zagidulin: So, I agree with the proposed algorithm and here's
Marcus. So, we should probably repeat what we were saying.

Dmitri Zagidulin: Quick procedure question. is there any reason why we
don't use the IRC that might capture this stuff?

Will Abramson: this call was changed to Google meet…

Will Abramson: because of it was for the test suite and I haven't changed
that so it was a mistake maybe yeah the IC channel is open…

Dmitri Zagidulin: Yeah, no, no worries.

Manu Sporny: It's

Dmitri Zagidulin: But just chat wise, we can use IRC. and…

Will Abramson: but I guess I'm not

Will Abramson: the Q or anything. There's nothing.

Dmitri Zagidulin: and just to address Joe's point, I agree that it doesn't
quite feel like service endpoint. I think for better or for worse, we left
service endpoints as the only ex point of extension in the spec. So that's
kind of why raising it.

Will Abramson: Yeah, welcome Marcus. So yeah, we've just been discussing
what the b did resolution spec wants to say about handling the path and we
seem to be moving towards consensus around defining a way that path will be
hand handled assuming some service some thing has been added to the divid
document.
00:20:00

Will Abramson: So it's like opt in for DID controllers to use this
mechanism that we defined generally by the DID resolution spec and…

Will Abramson: if people aren't using that then they'll fall back to did
custom approach. Hopefully I can Joe

Joe Andrieu: Yeah,…

Joe Andrieu: plus one. I think that is the right algorithm and whether or
not it's a service endpoint, I think is an interesting also maybe esoteric
debate. but I wanted to put an anchor in the ground that unfortunately the
two firms that have defined linked resources as extensions aren't on this
call and I realize the future belongs to those…

Will Abramson: What do you mean?

Joe Andrieu: who show up but I just want to try again to get the checked
folks and Sean Conway I think it'd be Alex from check now that I think
Anchor is not involved but I'd just like to have another reach out and try
and get

Joe Andrieu: because I think it's going to be relatively easy for Shan to
support this algorithm. I think it's going to be a lot harder for checks,
but I'd like to hear their case for the metadata approach.

Will Abramson: Okay, I can try and reach out to them and see if we can get
another call or get them on the main call sometime. yes, I put myself on
the queue actually just to ask about step two look in did document for a
service that matches can someone explain a bit more about that? So I did
URL there's a path in it and then I'm looking in the service is it for a
particular type of service obviously or would it be like the ID of that
service would have the path in it someone can help me understand that
that's great because I know that the linked resources approach has a
prophecy called path that defines the path of that thing manner

Manu Sporny: I think I just forgot what I put myself on the queue for. it
was plus one to Joe, but we do want to get feedback from, the two firms
that have implemented this, but they can give feedback on the PR. we'll
reach out to them. They'll have plenty of opportunity. I think we're just
trying to figure out what type of PR do we want to raise and then once we
raise the PR it'll have plenty of time to have input from all the folks. to
answer your question, I think there's this proposal here on…

Will Abramson: Mhm.

Joe Andrieu: Oops.

Manu Sporny: what the service description could look like. if we do a
service description, I do agree with Joe. I think it's a bit of an esoteric
discussion. So maybe we can talk about it at a higher level where it's kind
of like whatever we do whether it's a service or it's another property or
whatever that thing has to have some key fields in it and those key fields
I think Dave you're probably on the queue to explain more about the
difference between a static resolver and a dynamic resolver but just to
give us something concrete to talk around here's a proposal right there's
this concept of two different types of resolvers

Manu Sporny: We think that you might be able to specify a base path where
if your URL starts with this then you will use this service endpoint to do
it. a static resolver just tax the path to the end of the service endpoint.
in the dynamic resolver has a HTTP API that you use to you basically give
it the full URL the full did URL and then it will give you back a new URL.
So it's dynamic. It can change based on the time of day or…

Manu Sporny: phase of the moon or whatever. I'll stop there.

Will Abramson: Okay, thanks.

Will Abramson: Joe

Joe Andrieu: Yeah,…

Joe Andrieu: I think this is one of the architectural disconnects, but
maybe we can align the linked resources approach is specifically you give
the path not the keyword path. So if your path in the URL is slash you
would put a property called path that has the value of who is as a string.

Joe Andrieu: So every entry is defining what you need to retrieve and
validate a particular path as a resource that's out there in the cloud. so
that is not a shared service endpoint across all these different path
things…
00:25:00

Will Abramson: Thanks, Joe. Dave

Joe Andrieu: but a different entry for each item in the path.

Dave Longley: I think Monu mostly explained what I got on the queue to
respond to. but the basic idea here is when a did URL shows up, we can have
several as the group wants to define that we think are useful, several of
these different service definitions that are each given their own type that
are going to behave in some different way. they provide some different
primitive and you look in DID document for something that matches DID URL
according to the path and perhaps also the type. So maybe we can slot in
whatever Joe was talking about for how that other feature works using this
same concept. So the general idea is we're going to tell resolver you look
for these specific types of services.

Dave Longley: If you find them, you apply these matching rules against the
DID path. And if you have a match, you use that service definition and its
type to do the resolution according to whatever its type is. And then as a
group, we agree these are the types we want to have and…

Dave Longley: this is the new behavior we provide. And it's all optin and
backwards compatible.

Will Abramson: Next, Marcus.

Will Abramson: Can't hear you. Speak.

Markus Sabadello: Sorry, I'm late to the call so I missed some you
discussed. I think I'm a bit skeptical about what I'm hearing. I always
thought that it was a nice feature. the D core and D resolution
specifications don't really interfere with the path and we did method and
the D controller to use the path if we start defining rules here on how to
dreference the path I like a bit the HTTP specification telling you what
pass you can have on your web server and

Markus Sabadello: what they mean. but I'm not totally opposed to start
introducing this logic, but it feels a bit strange to me. And I still would
be up to the method to do with the path whatever they want. I would not
want to break what for example check is doing, right? they're using the
path and it has nothing to do with the service endpoints. So I think that
we talked about fallbacks right and things like that. So there's probably
some middle ground that works for everyone. But yeah, I feel a bit uneasy
about restricting basically.

Markus Sabadello: To me, it feels like adding rules on what the path can be.

Will Abramson: Thanks Marcus and…

Will Abramson: yeah the discussion has always been around ensuring
backwards compatibility so we would not be trying to create check
implementation Manny

Manu Sporny: Yeah, that's what I also wanted to say. Marcus, I think you
might have missed the part of the discussion where we said this is not
going to break existing did methods have that have decided to process paths
in different ways. This mechanism we're going to define is purely optin and
the method can always override it. so I don't think that we explicitly
talked about are there any backwards compatibility issues I think we
currently think there are not modulo Joe you said that maybe checked might
have an issue although I don't see it right now what the issue might be so
we're going to have to have them provide some input certainly I don't think
there wouldn't be any backwards compat issue

Manu Sporny: with Cosmos either. yeah, and I forgot what I put myself on
the queue for.

Will Abramson: Yeah, thanks Stephen.

Manu Sporny: That's one of the bad things about this is you can't remind
yourself. That's it.
00:30:00

Stephen Curran: Yeah, I just wanted to disagree with Marcus' statement that
this should be left up to the did method. I think there should be
consistency or a way to have a consistency. So I like what I'm seeing. I
also joined late so I missed the early part of it but what I'm seeing on
the screen resonates in that it gives a clear way for a did method to
express hey if I have paths to resources here's where you find them and a
way to override to more specific things and other ways to do it but I
really want to see it as part of the did core or did resolution specs and
not just leave it up to the did method.

Will Abramson: Thanks to you, Marcus. Good question.

Markus Sabadello: My question is then maybe you discuss this too. What does
this mean for the existing service f parameters? are those still

Will Abramson: I guess that goes to as well what changes would we need to
be making to the spec to actually, what does the PR look like to this? And
one of the things as Stephen was talking about is other changes that we'd
need to make to bib core as well. Dimmitri

Will Abramson: Thanks Richard.

Dmitri Zagidulin: So to answer the relative rough question so this provides
essentially syntactic sugar for it.

Dmitri Zagidulin: So both mechanisms would still be valid. This is just a
nicer way of doing it, but we wouldn't break any

Manu Sporny: Yeah, as for what we would need to change, what does the
concrete PR look like? I don't think we need to change the did core spec. I
think there's an open question. It might be better to have something in the
core spec, but I don't think we need to change the DID spec at all at this
point. I think we can add something in the did resolution spec because we
can make class 4 changes there. So, we can do anything we want to there.
This is a part of the resolution process.

Manu Sporny: if we say we're going to do this through a service then we
just define what the new service types would be and then we would add an
algorithm which is effectively what Dave's been typing into the chat
channel on the path resolution algorithm if you see a specific type and
then we can say that did methods are they can override this algor

Manu Sporny: algorithm with whatever they want if just to leave it so that
for whatever reason the did method developer is just like I hate this then
they can make the decision to break that part of it knowing that it's going
to create problems with interup so think it feels like a fairly
straightforward PR for the base functionality I think the other thing we
need to decide probably on this call is this a service endpoint or…

Manu Sporny: is this a different property in the DID document? That's it.

Will Abramson: Thanks. M I got myself on the cube to talk about the types
and…

Will Abramson: really to wonder. So currently on here we've got two
different types and we would be saying somewhere if you're doing this
algorithm you look for these specific two types right they're the types
that you check for the past and if don't you fall back to someone did me
specific fallback would and that's a fixed close set is there another
option to create one sort of generic type did URL resolver and then have
more specific types as well so these services might have multip

Will Abramson: multiple types just to allow people to extend this or do we
really not want people to be extending this and just these are the core
features that you should be using Dave

Dave Longley: So it might be helpful to model it that way to allow for
future extension, but I think it would be pretty challenging to do that
kind of extension without going through the DID resolution working group. I
think it would be harmful to interoperability if it's something that's done
DID resolution layer. I could imagine someone creating one of these and
then people just won't have the tooling to use it.

Dave Longley: But we might want to take that modeling anyway so people can
experiment with it. But I don't think you're going to get good wide
interoperability unless the did resolution group actually does something
with it. so I'm kind of ambivalent on
00:35:00

Will Abramson: and wait.

Will Abramson: Thanks. Bye.

Manu Sporny: I don't think we need that level of extensibility at this
point. someone would have to give us a compelling use case. And so, yes,
extensibility is good, but we already have an extensibility mechanism here.
You just define a new service type if you want to do something other than
what we're saying.

Will Abramson: Mhm.

Manu Sporny: Plus one also to what Dave said, we're really trying to define
some corded resolution thing. So I don't think we should incentivize people
to come up with new resolution mechanisms that are supposed to apply to all
did methods but not go through the did working group or the resolver work
to do that. I don't think there's a strong need to do it right now and we
already have our bases covered there because we have decentralized
extensibility built into the data model.

Manu Sporny: I think one of the last things we need to write a concrete PR
here is to decide whether or not this is a service type or it's a core
property of the DID document. I will note that whatever we do here, we will
probably need to put in the DID v11 context, which is fine. We can do that.
it's non-normative. but we're going to have to decide if this is a property
of the DID document, path resolver or something like that or if we just do
another service, or we define it through the services mechanism. I have a
pretty strong preference to just making it a service. Seems like this is
why we had services attached.

Manu Sporny: The service doesn't mean that you have to run a server out
there on the internet. service can be static like that this first thing
here for the static resolver. you literally take this URL and you paste
this URL to the end of it. if we wanted to do this on you have to list
every single path. someone could do that here with I think the a path
property. so that's my suggestion is can we make it a service type and
raise the PR based on

Manu Sporny:

Will Abramson: Thanks. B Joe,…

Will Abramson: you're me, Joe.

Joe Andrieu: Thanks, if we make it a service type, I think we can probably
make that work. but in our linked resource, we have a ton of properties
because we provide a variety of different ways to prove that the resource
at the other end is the one you want it to be and that it could be
compressed or it could be encrypted. there's an incredible amount of
flexibility here. We could import all these properties as in the context of
that service endpoint, but I just want to make sure that this is where
We're going to have a conversation about what these properties are,…

Will Abramson: True. M.

Joe Andrieu: these additional properties, so that we can get them into the
service endpoint. If we don't think these properties belong in a service
endpoint, then I would argue, then we need it in a different property.

Manu Sporny: I think there's another way to cut that Joe which there's a
new type that has all these properties in there and we're saying that and
we could have a discussion on each one of these things and maybe that's
what we should do but I'm a bit wary of having that because this is a lot
right and I know that there was a lot of thought that went into all of this
stuff including all of it. I'm just concerned about taking, the simple
feature and making it, fairly complex to start rather than just start with
a simple thing and then there's nothing blocking, the Cosmos stuff from
doing continuing to do this or defining a new service type that, does
resolution.
00:40:00

Manu Sporny: Just some thoughts there. I was hoping to keep the initial
quick turnaround and…

Will Abramson: Thanks, Stephen

Manu Sporny: then maybe do additive stuff to it versus us having to have a
big long discussion about every single one of these properties before we
raise that PR. That's it.

Stephen Curran: Plus one largely to what Manning said, we decided not to
did link resources just because of the need to have everything in there
because it puts so much in there. as a default. I like it being a separate
approach and so have no problem with it, being available. But I think for a
generic resolve did URLs in some simple way, I much rather keep the service
endpoint that's been proposed as a simple way to do it and…

Will Abramson: Next, go.

Stephen Curran: then did le resources where it makes sense.

Joe Andrieu: So, I'll express a little frustration here.

Markus Sabadello: Let's check

Joe Andrieu: I thought we were going to try and support this extension
that's already shipped in production. So, I know we're supporting it. it's
fall back. But if the proposal is, hey, let's figure out a system that we
can all use so it all plays nicely together, and then we're rejecting the
thing that we built with Cosmos, that's really frustrating. I would be okay
if we standardized three new service end types, this static one, the
dynamic one, and one that looks like this. That would work for me.

Joe Andrieu: But deprecating this so that it's a fallback and ignoring it
in the conversation about how do we all do it together, I think it's
unfortunate.

Will Abramson: Thanks, Joe.

Will Abramson: And it'll be interesting to hear from Sean. I think I saw
Sean on the call as well.

Will Abramson: So, if you want to share your perspectives, that'd be great.
U Marcus

Markus Sabadello: Yeah, I'm looking forward to the great proposal…

Markus Sabadello: because a lot of things are not clear to me how it would
work at this and how it would be backwards compatible but we compatible
with relative ref and so on. I'll just say one thing which is that some of
the current uses of the path like in the case of Cosmos and Jack just to
remind everyone they don't use services at all. I don't need services that
the path reference this kind of resource and it has nothing to do with the
service. there's no need for a web server. there's no need to be reference
these paths without any of that in a me specific way right and I think
whatever that in the end I think it's important to maintain this

Will Abramson: Focus.

Manu Sporny: Yeah, I mean one way to process that, Joe, to maybe there's a
base PR that we raise and then we raise each type resolver type as a
separate PR. So this would be one R, this would be another PR and then the
Cosmos one would be another PR. and that's how we have the discussion
around it. Would that work for you, Joe? Okay.

Joe Andrieu: Yeah, I think that's a reasonable approach.

Will Abramson: Yeah, I think the only thing I'd add is…

Will Abramson: if we do that, we probably definitely need to reach out to
the tech folks and see how we involve them in that process. so it feels
like we are aligned at least in the general direction right in the did
resolution spec we want to specify something that is going to be the
default approach to handling paths.

Will Abramson: So do we know what that initial base PR would look like and
is anyone willing to take a stab at getting it together?

Manu Sporny: I have a pretty good idea of what it would look like and I'm
happy to put a base PR and a couple of other PRs together. However, I'm
very busy. So, I would love it if somebody else wanted to take that item.

Manu Sporny: But if not, I can did working group work queue.

Will Abramson: Thanks. Is anybody else willing to help him out? Yes.
00:45:00

Dmitri Zagidulin: I'm willing to help, but I'm losing track of where the
consensus is

Will Abramson: I think I'm hearing is at least we have consensus for this
base which is going to outline the approach of and I think we have
consensus around using the service property right this is going to be a
service with some specific types but there's maybe a little bit less
consensus is what exact types we're going to support matter

Manu Sporny: Yeah. Yeah. I think the concrete next steps are raise a PR to
add some new section to the DID resolution spec that talks about path
resolution. so there's a base algorithm there that is defined in that
section that follows roughly what Dave Longley typed out in the chat
channel. and then there would be three PRs raised on top of that. one for a
ic did ver, one for dynamic did URL resolver and then one for one modeled
after the Cosmos mechanism and then we can ask the check folks if they want
to raise one for whatever they have. so I think that that is the concrete
set of changes that would go into did resolution or…

Manu Sporny: PRs that would be raised against resolution.

Will Abramson: Thanks. Yeah,…

Will Abramson: I put myself on the key just wonder what of this is going to
be like a normative language? did resolvers going to be expected to
implement and process all of these new types that we're introducing? Are
they going to be optional? what does that look like? manner

Manu Sporny: we're definitely going to have must statements around this
language. and then we are going to say that a did method can override the
way path resolution is done so that we don't get anyone formally objecting…

Will Abramson: Good. Thanks, Marcus.

Manu Sporny: because that's my presumption here we'll see what happens when
the PRs are raised. yeah that's it.

Markus Sabadello: regarding where this would go. And right now in the
digital solution, we have a section called dreferencing the primary
resource. And that right now has an algorithm that says what to do when
there is a path, what to do when there's an parameters, what to do if there
is no path. So I would assume it would go in there.

Will Abramson: Thanks. Yeah, sounds right to me. Stephen Okay,…

Stephen Curran: I've been working in that area a bit. Manu, if you'll help
me out,…

Stephen Curran: I'll take a shot at it. And …

Manu Sporny: Wonderful. Thank you,…

Manu Sporny: Stephen. Yep.

Stephen Curran: yeah. Okay. The toughest.

Will Abramson: great. Thanks a lot.

Stephen Curran: And Joe, I'll probably contact you as well because I know
less about did link resources. So, yeah.

Will Abramson: Okay. Is there anything else we need to cover today in this
call? Feels like we have a decent direction to address this path discussion.

Will Abramson: I guess I will try and reach out to check but maybe I'll
wait until this PR's in and we can just ping them on the PR but maybe I'll
reach out and share the minutes for this call and see if they have any
comments or queries. So anything else you want to bring up around the data
path discussion or we can end early and with a direction which is good. not
hearing anyone. Happy to end. Thanks for coming towards consensus and I'll
see you tomorrow. Cheers.
Meeting ended after 00:49:37 👋

*This editable transcript was computer generated and might contain errors.
People can also change the text after it was created.*