[MINUTES] CCG Atlantic 2026-08-25

This CCG Atlantic community group call provided an update on the W3C
Decentralized Identifiers (DIDs) Working Group, covering its history,
achievements, and ongoing debates. The working group, which has been active
since 2024, is nearing the end of its charter and has reached significant
milestones, including Candidate Recommendation (CR) snapshots for DID 1.1
and DID Resolution. The discussion highlighted the challenges and progress
in standardizing DID resolution, DID URL dereferencing, and other related
specifications, emphasizing the need for broader implementer feedback and
diverse opinions to refine the standards.

*Topics Covered:*

   - *W3C DID Working Group Update:* The session provided an overview of
   the W3C DID Working Group's progress, including its history, charter, and
   achievements over the past two years. The primary goal of the working group
   has been to address concerns regarding interoperability and standardize DID
   resolution and related specifications.
   - *DID Core Specification (DID 1.1):* DID 1.1 is nearing completion as a
   recommendation, with minimal changes expected due to its CR status,
   focusing on clarifying the DID document representation by removing the
   abstract data model and standardizing on JSON while allowing for roundtrip
   conversion from other formats.
   - *DID Resolution Specification:* This specification, which defines how
   to resolve DIDs to their associated metadata and DID documents, has reached
   a CR snapshot, though DID URL dereferencing features were marked as "at
   risk" due to time constraints. The work standardizes the resolution
   algorithm, interface, HTTPS binding, and data model for resolution options,
   document metadata, and resolution metadata.
   - *DID Specification Registries:* The working group discussed the
   challenges and complexities of establishing a W3C registry for DID methods
   and other extension points, ultimately deciding to deprioritize this work
   due to time constraints and contentious debates around governance and
   authority.
   - *DID Rubric:* The DID rubric, a set of criteria for evaluating DID
   methods, has been "jsonified" for better maintainability and version
   control, making it a strong candidate for a future W3C registry.
   - *DID Threat Model:* The requirement to produce threat models for
   specifications, driven by the security review group, has been incorporated,
   helping to rigorously analyze potential threats and inform security
   considerations, although its late introduction into the process presented
   challenges.
   - *DID URL Dereferencing:* This is an area of ongoing debate and work,
   aiming to define how resources can be referenced relative to a DID using
   DID URLs, including handling paths, query parameters, and fragments. The
   current focus is on modularizing the algorithm and defining standard
   components like path handlers and path service types.
   - *Active Debates and Challenges:* Key areas of contention include the
   degree of standardization versus leaving room for implementer innovation,
   the precise boundaries of the dereferencing algorithm, architectural
   terminology, and the security concerns surrounding relative DID parameters.

*Action Items:*

   - Encourage implementers of DID methods, particularly those involved in
   resolution, to engage with the DID Resolution specification and submit
   their DID resolvers to the resolution test suite to demonstrate
   implementability.
   - Seek feedback from implementers of DID URL dereferencing to help
   refine the specification, particularly regarding strong opinions on how DID
   URLs should be utilized and handled.
   - Encourage individuals with strong opinions on areas of active debate,
   such as DID resolution and DID URL dereferencing, to join the working group
   and contribute their expertise.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-atlantic-2026-08-25.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-atlantic-2026-08-25.mp4
*CCG Atlantic - 2026/08/25 12:00 EDT - Transcript* *Attendees*

Alex Higuera, Benjamin Young, Dmitri Zagidulin, Erica Connell, Gregory
Natran, Harrison Tang, JeffO - HumanOS, Jennie Meier, Kaliya Identity
Woman, Lancine Toure, Otto Mora, Ted Thibodeau Jr, Will Abramson
*Transcript*

Will Abramson: Hey folks.

Will Abramson: Give folks a couple more minutes.

Will Abramson: I'm going to start joining while I'm doing the So, welcome
to today's community group call 25th of August. thanks for being here.
Yeah. Today you're going to actually have me presenting maybe joined by a
bit of Otto. we're going to talk about the W3C decentralized identifiers
working group and just give an update on where we're at and how things are
going and maybe some of the open debates going on raging in the group. it's
a little bit slap dash but I hope it's fine. Just before I get into that
quick administrative stuff.

Will Abramson: Code of ethics and professional conduct reminder people
treat people with respect and must continue to create a welcoming community
here. next IP note anyone is welcome to participate in these calls. However
substantiative contributors to any CCG work items must be members of CCG
with full IPR agreements signed. just reach out to me or Mimmude or Denin.
We're happy to help you if you have any questions with that. call notes. So
these calls are recorded and transcribed and the transcription and
recording are made available on the W3C CCG mailing list within 24 hours.
introductions or reintroductions. Anybody new to the call today want to say
hello or anybody just fancy saying hello in mostly familiar faces. You're
welcome.

Will Abramson: No. Okay. Anyone have any announcements or reminders they
want to share with the group? I guess I'll just share that next week. I'm
going to be at GDC, which is the conference in Geneva, the global digital
collaboration. I'm in conversation with Mammud about whether we're going to
have a call. I think we're just confirming the speaker. So imagine a CR
call is quite tentative and it maybe cancelled depends if the speaker is
available. we'll let you know within the next couple of days hopefully. Any
other announcements or reminders or work item updates from folks want to
share?
00:05:00

Will Abramson: All then let's just dive into it. Let me show my screen.
Yeah. So, as I said, just going to give a little rundown on the W3C
decentralized identifiers work and where we're at. So, Toatoto and I are
the chairs of this working group and we've been going since 2024. So, we're
coming to the end or trying to come to the end. So, I think it's a good
time to give an update. we've reached some important milestones. So, let's
see where we're at. Yeah, I'll start I'll just give a brief history of talk
about what DIDs are.

Will Abramson: probably a lot of us are familiar but I think it's great to
just give some context for those maybe people who are watching this
recording. and then I'll dive into really the main bit of the session which
is like okay this did working group what does that even mean we've been
going since 2024 which was two years now what we achieved I guess and
really looking at the major specs that we're dealing with and what has
changed I don't know if anyone on the call is implementing ds but we're
hopefully going to flag some things to be aware of in the upcoming
standards that

Will Abramson: pay attention So, brief history. as I said, I've ripped a
lot of this stuff off other people's slides, from the past because I just
have to pull this together real fast. But this just is just to give you a
sense of kind of the history of these ideas and how far we've come, right?
We're talking about over 10 years of work by people in this community. and
then at the W3C in various working groups, if you have a look so in 2019
the first W3C did working group charter was approved and then that work
started right and then there was this for more objections and then in what
2022 did version 1.0 became a recommendation and then obviously take some
time to rearter and all that stuff.

Will Abramson: And I guess what's interesting about the state we're at now
is we're starting to see tentative signs of adoption in the marketplace of
decentralized identifiers and their counterpart verifiable credentials
which is great. So California Department of Motor Vehicles there's a true
age deployment which is about convenience stores and age verification in
convenience stores is blue sky's deployment and social media. they have
their own d method there's various government identity systems that are
exploring proof of concepts or iwords or even adoption of bids VCs so it was

Will Abramson: It's great to see right this sort of effort sometimes feels
a bit fruitless and 10 years of work right it's starting to pay just we're
starting to see things being adopted in the wild which is great. yeah and
then maybe some people think this is not such a good thing. There's over
267 d methods and counting and yeah I mean I helped create this website. I
mean, it really just tracks the W3C' registry, The W3C's list of did
methods. which maybe if there's time I'll get into some of the
contentiousness around that registry list thing in a bit.

Will Abramson: But what's been interesting to see is obviously AI has
driven both use cases for decentralized identifiers and ease at which any
person can submit a DID method to the registry. So, maybe 50 of these DID
methods happened in the last year and certainly my sense is many of these
DID methods are exactly the same just with a different name on it. so I
guess I should say not all DID methods are created equally. I think it's
great that there is diversity, but as you're sort of trying to navigate
this space, it's very important that you review the spec and try and
understand whether this method is really something that you want to be
using and relying on.
00:10:00

Will Abramson: Yeah and then just a note the did working group got
recharged in 2024. So that's kind of like what we're really going to be
talking about. So before we get into that what are did so I think these
slides maybe originally came from Drummond I took them from a TAC
presentation but credit to whoever created these slides because I did not.
Yeah. So first, bits should be a permanent or really a persistent
identifier, it is a URL that never needs to change. So you can update the
cryptographic material behind it, but the identifier itself can stay the
same for as long as you want to use it. it should be resolvable. So given
that identifier, you should be able to look up and discover metadata that
is associated with that identifier.

Will Abramson: And it's really that metadata that gives it this
cryptographically verifiable nature, we have an identifier, we resolve it
to a DID document which contains the metadata and in that metadata there is
cryptographic material that we can use to have verifiable interactions with
the controller of that identifier. and lastly, it should be decentralized
and not all bid methods in the registry are decentralized or there's
various definitions of decentralization but the fact is anybody should be
able to create a decentralized identifier without requiring them to
register that identifier with some authority. have. So there four
requirements that kind of stimulated this work and trying to define what is
an identifier that could meet these requirements.

Will Abramson: So yeah I talked about We have uniform resource names that
kind of look like this. and then are very similar but they just have a
different scheme. So the scheme did and then we have this thing called a
DID method which is effectively the name space for a bunch of identifiers
within that name space and then the did method is a specification that
defines how you take a divid method specific string and execute the
resolve. I mean really how do you do create read update and deactivate and
read here is So resolve would be how do you take that string and resolve it
to the authoritative document at a point in time.

Will Abramson: So apologies this is everybody knows this stuff now I try
and be a bit faster but yeah so d is a digital control point often we have
these control points that live in someone else's server like our email
address or our username and password right we have to go knock on somebody
else's door and then tell them the password but they kind of then look it
up in their system and say yeah you are all about trying to move these
control points into our device so we give people identifiers but the
cryptographic material by which we can have verifiable interactions on
behalf of that identifier exists on our device not on somebody else's
server. There are a lot of benefits for this model but particular events
like honeypotss and it just puts the control of these identifiers in
control I guess. Yeah.

Will Abramson: So as we said this is the bid right so you create these bids
they never need to change but over time you can change the cryptographic
material through which you prove control over that identifier. So you can
have a single persistent identifier with rotatable cryptographic material
and other information through which people can come to understand the
control of this identifier. Yeah. And this is really the goal is more and
more of our digital interactions are backed by cryptography that are in
control. the controllers of those identifiers have cryptographic backing
instead of we defer that authority to some system who then tells us what
information is true or I think we see with AI you get that even more, right?

Will Abramson: you have all of these actors now doing things and you really
don't even know if they're human or not, but also we don't even know if the
actions that they're taken are trustworthy in closed, I think cryptography
is the ways that we can start to anchor our digital interactions in some
kind of basis of truth or digital facts. and I definitely believe we need
more people to have bits and use cryptography through bits. So, I thought
there's any questions about that? I just kind of rush through that.
00:15:00

Will Abramson: I think we're all up to speed on bits and why they're
important, but if anyone has any questions, please jump on the queue. No.
Okay, good. yeah. did working group 20 24 to present. Yes, this has been
interesting for me. I wouldn't have said in 2024 that this was really
something that I was well equipped to be a chair of a working group. It's
been a fantastic experience to kind of learn on the job, I guess you'd say.
so let's see where we got to, right? Yeah. So we start a working group with
a charter, right?

Will Abramson: Before you can have a working group at the W3C, you have to
define through the W3C and the W3C has a bunch of members. They sign off on
charters. Basically, they approve them. so the charter itself was a whole
battle going backwards and forwards. not a battle but there was a lot of
contention in the charter definition because one of the reasons we needed
this charter or the justification for this charter was we had to address
the concerns raised in version 1.0. So when we had a formal objection there
were a number of different organizations that objected to the vid 1.0

Will Abramson: a standard because of the perceived in non-interoperability
across div methods. and this charter one of the purposes of it was to
address that those concerns to demonstrate how DIDs do in fact enable
interoperability even when people have different divided methods when their
identifiers are across multiple different bit methods. So yeah, we put some
things in the charter. In particular, we said, okay, we don't really need
to do much on the did core specification. We're just going to tain so we're
going to iterate it to version 1.1. And that means you can do something
that the W3C class is class one to three level changes. It basically means
we can't add any new features. The only changes we can make that would be
normative would be if we can justify they are for fixing a security flaw or
a bug in the specification.

Will Abramson: So the idea is in general 1 should be backwards compatible
with did 1.0 And then additionally we said we are going to define the
resolution. So we're going to come up with a entirely new specification
which has no basis even though we adopt the CCG did resolution spec which
was a final work it final community report from this group which was great
as a basis but that work comes into our working group and doesn't it really
is up to the group to decide. we could throw that entire spec away or we
could build on it. Basically nothing is defined until there's a 1.0
specification and the work was to create this 1.0 standard that people can
then rely on for how to did resolution and then there were some other
things that we had in scope.

Will Abramson: So we had the DI specification registries which we thought
maybe we'll turn it into a W3C registry which is this new sort of construct
from the W3C that continued maintenance of a spec rather than issuing them
as a final I think that in the version 1.0 this was a work item working
draft. There's some name for this thing which basically means a note,
right? That's what it was. It was a note, So at the end of the work, they
publish this note. But the problem is then the working group stops being
active and that note can't be updated over time. And the idea of a registry
is they create a mechanism by which these things can be continually
maintained even when the working group is not active and working under a
chart.

Will Abramson: We also said we're going to do some stuff around this did
rubric work and we also thought maybe we turn that into a registry and then
maybe we're going to define a plain se representation maybe we're going to
work on the did implementation guide and these are just at the start right
so in 2024 we're like what do we want to work on these are the things we
might work on let's put them in our chart because it's really hard to add
things to the charter once you have it approved but it's easy to not do the
things that are in your charter, you don't have to do all these things. We
just saying we might do them.
00:20:00

Will Abramson: Yeah and I kind of talked about this but the theory that we
landed on during the chartering was if we can did resolution create a
standard way for DIDs to be resolved to their metadata right their DID
documents and other associated metadata then that is a mechanism by which
we can demonstrate interoperability among these divid methods right you
think I'm somebody who discovers a bid in the files and I have a standard
interface that I can execute a resolution request for that did and get back
a DID call standardized document then we have this interoperability layer
because it doesn't matter what the DID method is that DID document should
Always.

Will Abramson: is contain a set of standardized fields that I can then use
to have verifiable interactions with the divid controller. So that's what
we hope to demonstrate and hopefully when we get to the final vote we won't
get similar objections. Yeah, this is just a little bit I put in about
okay, how does a working group work? So, you have your charter, then you
publish these things called working drafts. working drafts are just so you
constantly have the latest spec in a working draft state, I think. but,
you're continuously iterating on this in the group, right?

Will Abramson: processing issues like updating the spec, all that sort of
stuff. And then once you think you're ready, you create a candidate
recommendation CR. You move to CR. and you need sort of a working group
decision to move to CR and team approval. And then once you're in VR, you
can continually iterate on your CR releases, but eventually you say,
"Right, we're done now." And then you are sending out to wide review. So
that means you're asking the community to review this spec and approve it.
and then also it goes out to AC review. And basically the goal is to get to
here to a formal W3C recommendation.

Will Abramson: You start over here which is just like the working groups
involved. Then I missed the step to get to CR first you need to go through
horizontal review. So the W3C has a bunch of working groups like TAG the
technical architecture group like internationalization and security privacy
and there are basically experts that sit on these groups and then they
provide review over your current spec and raise any issues that they think
you need to address before you can move into CR. So getting to CR is like a
big step.

Will Abramson: It's like, yes, we now think we have something that is
final, although we might change it and iterate on it. this is final and
good enough to eventually move to W. So, hopefully I explained that It's
kind of complicated and I'm still, learning the ropes a little bit. yeah.
So, then I just wanted to update folks. where is the group we had this
charter back two years ago. get the great news is we have a CR snapshot
which is like we have a CR release basically. Wait.

Will Abramson: for both of our core specifications. So did 1.1 had a
snapshot in March which are so we might still be making some changes while
it's in CR but these are going to be very minimal. We really think did 1.1
is good to go. And then We were trying really hard to get all of our
features into the did resolution spec but decided to mark some features at
risk so we could get a snapshot in time for the end as we come to the end
of our chart. We thought it was really important that we get ACR snapshot
of something that the group has consensus on and what we decided that
something just did resolution.

Will Abramson: So the did resolution spec actually defines two things which
I'll get into in a bit but they how to resolve a did and then they define
this thing called did URL dreferencing and we marked all did URL
dreferencing at risk not because we don't want it I think the group is all
in agreement that we definitely want to dig referencing but because we
didn't feel confident that we could get to consensus over this spec feature
in time given our current charter status which runs out in October.
00:25:00

Will Abramson: So we wanted to just get something into a CR snapshot and
then continue work once we have that in snapshot continue working on dig or
did URL dreferencing this was just thought the better practice right we
really didn't want to finish or have our charter expire without a CR
snapshot for did resolution because that would be considered like a fail of
the group What So did certification registries. We did a bunch of stuff on
this and really it was maybe a distraction at the start on reflection cuz
people have a lot of opinions about the DID specification registries, right?

Will Abramson: that is the registry for the DID methods but also for any
extension points to both the additional properties in DID document and also
to resolution arguments and things like that. So basically a bunch of list
stuff that what we did do is we did specification registry into three
separate documents. and maybe even three separate repos, but in particular,
we wanted to pull the did methods work out. And we were thinking eventually
we would try and transition that did methods registry into a proper W3C
registry, but we abandoned this due to just time constraints and
prioritization. I think still if there is a future iteration of this work,
we would probably pick

Will Abramson: that back up. But we were arguing a lot about, what are the
rules of the registry? who's going to, is the W3C even the right entity to
be authoritative over these are the set of approved bids, right? A lot of
people push back against that. Basically, it was a rat hole. We got stuck
in it for a little while and then we just decided, right, let's stop so
we're still, active in the D specification registries. We just didn't have
it as a priority. Yeah. And then the did rubric me and Joe have been
working on the side to try and we haven't added any partic criteria. So for
those people who don't know the DID rubric is a set of criteria that you
can use to evaluate whether a DID method is right for your use cases.

Will Abramson: So it's a set of questions with a set of responses and you
bring your subjective self and the use case that you care about and the
idea is you should select a few DI methods and this is a tool by which you
can help make a more informed decision and we iterated a few criteria based
on some work that Joe did by applying this rubric to a bunch of different
bid methods. But the main thing that we did is we jsonified it. So now the
did rubric is not just a text like a HTML document that has all of the
criteria in it is a HTML document that is generated from a set of JSON
files and that just makes it much easier if anyone on this call was
interested or anyone in the future wants to add a new criteria or propose
changes to existing criteria.

Will Abramson: it becomes something that we can version and track in a much
more I guess code and version control maintainable way. So we think this is
a great candidate for W3C registry. We hope we can make that transition but
we just don't know about the horizontal review required for a W3C registry.
Basically, this is an entirely new process that W3C is still figuring out
and we would be one of the first people through that process. But we
believe we've done all the work needed. It's just going through that
process of making it a W3C registry and doing that transition. And then
finally, the did threat model. Yeah. So this also slowed us down but I
think it's been fruitful.

Will Abramson: basically the security review group or the security interest
group sure what they call them exactly but they introduced a new
requirement which is that every specification going through a working group
should have or maybe even must Love and a threat model against it and that
was so that these threat models which is a more formal and rigorous way of
analyzing the threats associated with a specification and the kind of
software that those specifications produce are documented. So currently
specifications always require security considerations and privacy
considerations.
00:30:00

Will Abramson: The idea from the security group is these threat models
would drive the discovery of and documentation of the security
considerations. And this was really to help the security review group do
their reviews faster because they were they would have to do this work
anyway just to understand the specification. they're maybe trying to get
through. They're all volunteers and they're trying to review the security
concerns associated with any number of specs, right? The idea is that by
having this threat model in place, the group has done more of the thinking
themselves and is easier for the security group to on board and kind of
orient themselves in the specification that's being considered.

Will Abramson: So again, this is new and are still under sort of process
development, but I think as we'll see it has been very interesting for how
it's helped people and I think if we'd have done this at the start right
part of the problem is this kind of got dropped on us quite late in the
process if we' done this threat model at the start particularly for did
resolution when we adopted this spec from which was like it kind of looked
polished. so we adopted it from the CCG, but many members of the group kind
of had their mental model of how did the resolution worked, but hadn't
taken the time to internalize the language in the spec and how the spec
said it worked. I think the threat model is one way to kind of get that
level of detail that is required to, have confidence the group has
consensus over all the features in the spec.

Will Abramson: Any questions before I just go Yeah. So did 1.1 and this was
the easy one, we weren't doing too One thing which is a major change really
although it shouldn't affect any implementations I don't expect is before
in did 1.0 there was this concept of an abstract data model for a not a a
DID document. we remove this. So, now the specification says defines a
single representation and that representation is JSON, but it must also be
compatible with JSONLDD processing and then additional representations are
allowed. So xable.

Will Abramson: would be allowed but they must support roundtrip conversion
to the JSON representation defined by the spec and I think that I expected
this to be more controversial than it was like everybody kind of agreed
that this was a good thing to do and that the abstract data model was
confusing things so this is not to preclude other representations but we're
just saying we are picking a concrete representation that is our

Will Abramson: base representation and other representations must be able
to be converted to this representation. I think this helps interoperability
right if everyone knows that they can convert to a common format the base
format then they can operate on that use that base format to produce the
format that they care about. yeah what else? Yeah. So did core in 1.0

Will Abramson: O did sort of handwave at resolution like we knew resolution
was something that we wanted but we didn't define it right there was just a
sort of abstract placeholder function names for dreferencing and did URL
dreferencing and a section on did parameters that we thought would be
useful for did URLs we felt belonged in did resolution And so we moved all
that stuff out. So basically we said, this is fine, but this stuff is all
placeholder. we kind of took control of it in the did resolution spec,
which our feeling was this means it's like new content, even though it was
initially defined in DID 1.0, it wasn't really defined enough to be
normative. I think that's at least my understanding of what happened there.

Will Abramson: And then the other thing that we did is in the VC work they
define this thing called a controlled identifier which kind of a little bit
confusing but basically it's like DID a decentized identifier but without
the need for it to be a controlled identifier can just be any URL that
resolves to a controlled identifier document which is effectively so the
idea was that would extend controlled identifiers but because the VC
working group didn't actually DID docu specification under their control
they couldn't do that work. So we basically did that.
00:35:00

Will Abramson: So now we say did 1.1 depends on the controlled identifier
spec and a bunch of definitions which were in both controlled identifier
1.0 and did 1.0 have now been just removed from DID1. 1.1 and they point to
control identifier spec. So again, there's not too much here to worry about
from the augmentation perspective, I don't think. we made a bunch of
editorial updates to the spec. but yeah, these are all just sort of bit one
thing that you maybe would be a bit confused about is this if you're
reading if you're scanning the 1.0.1

Will Abramson: 1.1 specification you might feel it feels a bit light on
some of the definitions and that's because we're just saying go look over
here which is a bit unfortunate I think but that's what we got left with so
it just means you have to read both specifications before you understand
the different properties in a document yeah so this is the first CR. So I'm
going to talk about the thing the features in the specification that are
currently in our candidate recommendation.

Will Abramson: So before I get to that, I'm going to talk about what did
resolution is I've been talking about a bit. Maybe I should have defined
this earlier, but the idea is this sort of operation or in here this is
this function which we are defining in our spec. So it's an operation that
you can execute by calling resolve. You pass in a decentralized identifier
and a set of options and you get back some document metadata and document
metadata is DID document such as maybe the version of the DI resolution
metadata is metadata about the resolution operation that just got executed
maybe the time that it got executed at or I don't know some properties
about the resolver that actually executed the request like all that stuff.
These are just JSON objects that you can put things in that are useful to
your method or your resolver.

Will Abramson: There are also some things that we standardize. yeah and
resolution is defining a standard interface to execute a resolution request
and receive a standardized response for any DID method. So the point is it
doesn't matter what DID method this is I can still execute this request and
as long as I have a resolver. So this is the caveat like you do need a
resolver that understands the divid method that you are executing against
but still that resolver should implement this standard interface and you
should get back this standard response and independently of the did method
you should be able to understand this response because you understand that

Will Abramson: document that's specified in D call 1.0 and now 1.1 and then
document metadata and resolution metadata is defined by this divided
resolution spe And then this diagram is just maybe to help us a bit more.
I'm going to come back to this diagram in a bit, but this was the outcome
of the threat modeling work that Joe and Steven Mac are kind of heading up.
And it's an attempt to kind of pull apart the different architectures of
the system we're talking about. I don't want to get into too much.

Will Abramson: I think that this is more important later on when I'm
talking about the differences of opinion that come across but effect
effectively you have some client device that encounters did URL right maybe
it receives a verific a verifiable credential and there's a issuer did in
there right some device gets something that is a dig URL and it has to
execute resolution requests so it calls out to a resolver which maybe is in
the
00:40:00

Will Abramson: device or it might be on the cloud somewhere or it might be
somewhere else right in the resolver exposes this interface that we've just
defined right resolve the resolution options return this metadata and then
what the resolver is going to do is going to check does it understand that
did method that it's resolving for and then it might read from BDR state so
that might be reading from bitcoin it might just be like for did key you
don't need a vdr But the DDR is kind of like the sort of deterministic
generation of the div document from the encoding in the identifier itself.
But this is just trying to pull apart some of the logical pieces of this
architecture. But it doesn't have to be read the client could be all of
these in a single piece.

Will Abramson: But I think the key thing here for me at least is that there
is this resolve operation that we are trying to standardize. And this
resolve operation takes in ds and it spits out a standard response of did
document metadata. yeah so just to kind of go over that again right we
define this resolution algorithm. So that is this algorithm that all did
resolvers must implement right. So these are the steps before and after
executing a resolution operation defined by a specific So every method
defines how to resolve DIDs of their DID type and this kind of wraps on
around that operation to take transform standard inputs into the required
thing inputs for the operation and return back standard outputs. And this
also includes

Will Abramson: defining some standard error states. Yeah, we define the
standard interface which I talked about and we say that all inputs and
outputs must be serializable to JSON. We define a HTTPS binding. So that is
like how do you execute this interface over a HTTP request. and we define
the data model for what is a resolution options to docu document metadata
and resolution metadata and for some properties in these objects we define
their property name and for example resolution options we define version ID
and we have some information about what version ID is and how it should be
used and this is a change actually so this was initially defined find in
did core so did 1.0

Will Abramson: As the standard errors were just a string so invalid did
we've now migrated those to use this RFC which was used throughout the VC
work and now errors are a structure so an object that have a type and it's
a specific type that defines that we're defining yeah and then this is a
key point like resolving clients must trust the resolvers they use to
execute

Will Abramson: resolution requests this is sort of implied and a bit
implicit. We're trying to make this a bit more clear and it's part this is
the threat, right? If you're executing resolution requests over HTTPS to
resolvers that you don't really know or trust, you are implicitly trusting
the result that you get back, you have to use that result. you give them a
did and some options and they give you a response. There's not easily ways
for you as the client to verify that those responses match or are
authoritative for the divid that you pass in. The way that you do that is
you probably audit the resolving code and maybe you host the resolver
yourself, right? Or you have a business relationship with the resolver that
you trust.

Will Abramson: But the point here is you kind of have to trust that. I mean
there are some people exploring ways that in the metadata there might be
information that you could use to do some client side verification of the
response but not all good methods are going to support that. And at the end
of the day this is important code that you are depending on and you should
understand what that means for your system. So this is just flag we are
actively seeking feedback from influencers of SID resolution. So if you
implement this specification or you implement did resolution for your DID
method but maybe you haven't really looked at this specification now is a
good

Will Abramson: time to do so. we would be happy to help you become
conformant. We would love it if you can submit any did resolvers that you
have to the resolution test suite. all you need is a live HTTP endpoint to
execute a resolution request and a small set of test cases. So you need to
provide an endpoint that we can hit using the HTTPS binding and a set of
bids that we can hit it with that execute the exercise both successful
resolution and a various failure states that are standard. So for example a
divid method with a invalid did you know you should provide us an invalid
for a divid method that your resolver understands.
00:45:00

Will Abramson: And the purpose of this is just so we can demonstrate to the
W3C and the wider community this spec is being implemented and it is
implementable, right? the spec defines a bunch of normative requirements on
implementers. We want to demonstrate to the W3C that these requirements are
being met by implementers and the spec is understandable and being
implemented is useful. All right. So then we get to the next bit, right,
which is what do we still have left to do? What other bit that we really
hope we can get into CR before we're intending not to exit C to WC until we
have this PC in. And this is all about D URL dreerencing.

Will Abramson: So did URL dreferencing defines how resources can be
referenced relative to a DID and retrieved using DID U urls. So whereas a
DID resolves DID document and a bunch of stuff URL can be referenced to any
number of different types of resources. so yeah a did URL which is
important to note but also it can have all of these optional extra parts.
So it can have a path it can have some query components and it can have a
fragment and the referencing did URLs this bit of the specification we're
trying to define is okay which bits do we standardize around how the
referencing did URL handles these additional parts that you might see on a
DID.

Will Abramson: So dreferencing a did which DID URL just gets you to the DI
document. There is dreferencing with a fragment which is going to get you
in this case probably a verification method with the document. But really
this fragment should just be interpreted as a object a sub bit of the
document right so you have a document in this case I'm imagining there's a
verification method in there that has an ID of key-1 and then there's a
path. So the path has really been a lot of our discussion. How do we handle
paths? that wasn't really discussed at all in the previous specifications
and we wanted to support dreferencing. So you can identify resources DID
document using a path that can then be retrieved in the dreferencing
process.

Will Abramson: And then also there's Query parameters might be things like
version ID which is about the div document itself. What version of the
divid document you want? But also might be other service query parameters
like this one is service which is defined and this is saying okay I want a
service back and I'm expecting that service to have this ID and here we've
said it should be retrieving the resource defined by the service. and I
think part of the challenge has been that we want to be open to extension
and innovation, these query parameters, we're only standardizing a very
small number of them, but query parameters are an extension point and
anybody can use query parameters that have, custom behavior. and we want to
be able to support that.

Will Abramson: We also want these paths to be backwards compatible with the
ways in which people have been using paths in bids within the wider
community wherever possible. so it's turned out to be kind of complicated
to get the right combination of these things and define the algorithm that
handles that. one of the things that we have kind of agreement on is that
we're going to refactor the current algorithm in the did resolution s So
the did resolution spec was adopted from the CCG work item and we've tried
to make it a little bit more modular. So there is a series of highle steps
that you execute to do URL dreerencing.

Will Abramson: So a DID URL dreerencing you take a DID URL and then you
have to prepare to resolve the DID so you can get back the standard
response that you then use to continue with your dreferencing process. So
you take the D URL you extract the DID and DID parameters and then you
construct the resolution options. So you're saying okay from this D URL DID
I need some resolution options. You got to create those objects that you
can then use to execute the resolution request to get back the standard
response. and then you determine the retrieval strategy we've called it. So
this is okay based on that standard response and did URL what resource am I
retrieving the default resource will just be the DID document. But it's
really step three that we've tried to understand the different combinations
of things in the DJ URL and how they might affect the resource.
00:50:00

Will Abramson: resource that gets retrieved and then you actually retrieve
the resource and then in this case we've use the resource and this has some
contentiousness in our community but this is what we've gone for so far.
and so using the resource might be, you've got a verification method,
you're going to use it to verify a proof. Or maybe you have the referenced
an image and you want to use that to render the image on a web page. maybe
the dig URL is to a resource that you would render in a HTML page. I see
that I'm getting close to time, but I'll keep going. So yeah, there are
some points of agreement, which is great. this is a big one. I think there
is strong consensus that clients executing did resolution requests must be
able to conigure DID resolvers they use to resolve bids of specific DID
methods.

Will Abramson: The analogy that helped me understand this is I don't know
if anyone here uses cryptocurrencies or MetaMask or any of these apps right
so you download MetaMask and what MetaMask is doing is it's pointing to
blockchain nodes Bitcoin Ethereum nodes or anything right like it is mostly
just pointing to them using a URL they're hosted for you but Metask enables
the configuration of those URLs so that you can point it at your own
Bitcoin node or your own Ethereum node. And in the same way, clients should
have that capability to configure the resolvers that they trust because
it's their trust relationship that we're talking about here. So they must
have some say over the resolvers that they use for specific div methods.
And in particular, they must be able to say if they want to self-host that
stuff, then they should be able to configure clients to use the resolvers
that they choose.

Will Abramson: The second one is like clients should not blindly promote
all bid query parameters into resolution options. Right? There are some
risks around doing this. Basically here is a query parameter. What you
might do is extract the did and say okay this query parameter I'm just
going to promote it into the resolution options object and execute the
resolution request. Instead, we think all clients should understand the
query parameters that they choose to promote in the context of their
business situation, Not just blindly promote all of them because there are
risks where some security risks associated with this. So, work in progress
and the main bit of work is this PR.

Will Abramson: This is a number of different PRs that Joe and Steven have
been backwards and forwarding on, but if you want to get the latest context
of where we're at, 344 is a great one to look at. We're particularly defi
trying to define that we're trying to put the bones onto this algorithm and
get consensus We kind of have consensus on the high level steps. What we
don't have poor consensus yet exactly the contents of these individual
steps. And in particular, we want to define this thing called a path
handler, which is a standard way to define path handling objects, which
would go in a DID document and then how you would handle paths that are in
a DI URL. And then there's also talk of this path service type which we're
going to define which would be kind of a standard way to do something like
a did web vh who is so yeah active areas of debate.

Will Abramson: So what are we struggling with or where are we not quite
clear and this is just my sense right to do take this with a pinch of salt
but I think a big part of the confusion that we are facing is how far do we
standardize versus leave to implementers right where does the end for the
specification and how much do we let implementers figure it out so there
are whole different levels of this are we going to do we did with res
resolution and define a HTTPS binding to a dreference function. are we
going to define a dreference function with explicit inputs and outputs? Are
we defining a specific software component that executes dreferencing and
returns some result to some other entity?
00:55:00

Will Abramson: Yeah, are we just defining an algorithm that the client
executes to form dreferencing? Yeah. And then also again on these
boundaries does the dreferencing algorithm retrieve the resource at all or
is it just providing URLs that some other client or some other process is
actually then going to use that URL to fetch the resource. This to me is
all about where do we draw the boundary on the system that we're trying to
define. And it's not to say that have if we didn't want to standardize It
doesn't mean HTTPS binding is not allowed. It's just that there is not in
this current specification a standard way that this is how you should
implement HTTPS. And then we've had a big discussion recently about
architecture terminology.

Will Abramson: And I think again this goes back to the threat modeling
stuff which Joe and Steve Macau have led and it's led to them kind of
having some clear in their head terms that maybe haven't been shared widely
with the group and I see I'm not quite I made yeah I don't know how that's
anyway I was saying basically the discussion is there a client of a
dreferencer which then executes resolution or is it there's just a client
of a resolver and the client is the thing that executes the referencing.

Will Abramson: So we're hoping to get clarity on which of those things we
prefer. And then finally, there's been some security concerns raised with
relative did parameter which we are not sure how we want to handle because
some people depend on relative ref and it does have some useful
capabilities that we don't seem to be able to replicate in other
approaches. But there is a lot of good arguments that maybe relative ref
should be removed pr Okay, there's 3 minutes left. Sorry that was a bit too
long. hopefully that was useful. Do anyone have any last comments,
thoughts, reflections, questions?

Otto Mora: just to say that it was a great summary will really well put
together really detailed. I know that this may be confusing to some of the
folks here but it's been a ton of work over the last few months. great to
work with you as co-chair. and we really are looking for people with strong
opinions on these areas of active debate.

Otto Mora: I think it's one of the things that we've been lacking in the
group is people that perhaps did method authors have strong opinions around
this topic that would enrich the debate. I think it's some of the things
that we would really benefit from having folks in the working group that
can bring more nuance opinions around these areas of debate that
resolution, how it should work and so on.

Will Abramson: Yes, totally.

Will Abramson: I definitely agree with that. Yeah. I mean, we can just end
then. I guess that was great. I mean, we're about at time anyway. Hopefully
that was useful. I know it was a big dump of a lot of stuff and maybe it
doesn't all fit together. But, if you are a did method implement and you're
doing resolve stuff, we would love to hear from you. We'd love for you to
try and implement this spec. It would really help us. and then did URL
dreferencing, right?

Will Abramson: problem is you audit just doesn't have enough implementers
who are really thinking about how they want to use the URLs that have
strong opinions about how it should work. cool. Thanks to Yeah.

Otto Mora: Thank you.

Will Abramson: Have a great rest of your day.
Meeting ended after 00:59:43 👋

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