[MINUTES] CCG Atlantic Weekly 2026-02-17

CCG Atlantic Weekly - 2026/02/17 11:56 EST - Summary

This meeting featured a detailed presentation by Stephen Curran on
DID:webbh, a new DID method with a focus on verifiable history and
decentralized identity. The discussion also touched upon administrative
updates for the W3C website and upcoming events in the digital identity
space.
Topics Covered:

   - *Administrative Updates:*
      - Review of CCG Code of Ethics and Professional Conduct.
      - IPR policy for substantive contributors.
      - Call recording and minutes distribution.
      - Discussion on updating the CCG's W3C website profile and potential
      issues with the current website structure and naming.
   - *Announcements & Reminders:*
      - 42nd Internet Identity Workshop (IIW) in April.
      - Agentic Internet Workshop following IIW.
      - DID:Africa conference next week.
      - Digital Identity Unconference Europe in June.
   - *DID:webbh Presentation:*
      - Introduction to DID:webbh, its key differences from DID:web
      (self-certifying identifier, verifiable history).
      - Explanation of the DID:webbh log entry structure (DID Document,
      Version Time, Proof, Version ID, Parameters).
      - Discussion on verifiability and the role of DNS for discovery.
      - The concept of "portable DIDs" and constraints around it.
      - DID URL path handling and linking DIDs to verifiable presentations
      and attested resources.
      - Security mechanisms: Pre-rotation, witnesses, and watchers.
      - Real-world deployments and implementations of DID:webbh.
      - Specification status (1.0 stable, DIF recommended).
      - Future steps and considerations: Specification evolution,
      post-quantum cryptography, heartbeat parameters, optional DNS,
and handling
      multiple DID versions.
      - Emerging trends: Using DID log format with blockchain.

Key Points:

   - *DID:webbh* emphasizes *verifiable history* as the primary source of
   trust, with DNS serving only for discovery.
   - The *self-certifying identifier (SKID)* is a core component of
   DID:webbh, generated from the DID's initial entry.
   - *Log entries* in DID:webbh are chained together via hash linking,
   creating an immutable and verifiable history.
   - *Portability of DIDs* is a feature that must be explicitly declared at
   creation time using portable=true.
   - The specification deliberately *excludes governance details* for
   witnesses and watchers, allowing ecosystems to define their own policies.
   - DID:webbh is *DIF recommended* and has multiple implementations
   available, demonstrating its readiness.
   - *Real-world adoption* is growing, with organizations like BC Gov and
   the First Person Project utilizing DID:webbh.
   - Future development will focus on *specification evolution*, including
   DID URL path handling, post-quantum algorithms, and managing DID history
   effectively.
   - The concept of a *"heartbeat" parameter* is being explored to ensure
   active maintenance of DIDs.
   - The *optionality of DNS* in DID resolution is being considered,
   influenced by the experience with DID:cell and DID:skid.
   - There's an emerging trend of using the *DID:webbh log format* and
   linking it to blockchains for enhanced verifiability.

Text:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-atlantic-weekly-2026-02-17.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-atlantic-weekly-2026-02-17.mp4
*CCG Atlantic Weekly - 2026/02/17 11:56 EST - Transcript* *Attendees*

Alex Higuera, Benjamin Young, Brent Zundel, Denken Chen, Dmitri Zagidulin,
Drummond Reed, Elaine Wooton, Erica Connell, Harrison Tang, JeffO -
HumanOS, Jennie Meier, Joe Andrieu, Kaliya Identity Woman, Martina
Kolpondinos, Otto Mora, Parth Bhatt, Patrick St-Louis, Rob Padula, Stephen
Curran, Ted Thibodeau Jr, Will Abramson
*Transcript*

Stephen Curran: Hey, good.

Will Abramson: Sorry, it's on. How are you?

Stephen Curran: How are you?

Will Abramson: Yeah, thanks.

Harrison Tang: Hey, Will.

Will Abramson: Hey, Harrison.

Stephen Curran: Did I do a quick test share?

Will Abramson: Yeah, good idea. yes that is showing screen not in
presentation mode there right…

Stephen Curran: Let's see. That works.

Will Abramson: but it showed your screen yeah perfect no problem Yeah,…

Stephen Curran: Good stuff. Thanks,

Will Abramson: I'll give folks a few minutes and then start off.

Stephen Curran: Yeah. oh.

Stephen Curran: Drummonds, you're quite a heavenly looking creature with
that halo at your head.

Drummond Reed: I'm here.

Drummond Reed: I want to be one of the angels. listening to you. that's my
favorite Google Meet background. if you look carefully, the deer we're at a
little glam and…

Stephen Curran: The dog's moving.

Stephen Curran: Deer is moving.

Drummond Reed: you can't see much in this, but it keeps me in the center.
But there's a duck on the pond, too. So, yeah. …

Stephen Curran: One of my favorite backgrounds that somebody did was they
had a video running with them coming into the room behind them. So you
watching them and then they would come in, look over their shoulder and
then go out of the room again.

Drummond Reed: distracting. There you go.

Otto Mora: Is it Bambi or…

Otto Mora: I mean I can't tell. Is it the Shire from Lord of the Rings?
Nice.

Drummond Reed: I think it's sort of inspired.

Drummond Reed: If you're in Google Meet and you go down backgrounds all the
way to the bottom, you get this set of fantasy ones. I think there like
eight of them and they're all of a theme like this.

Stephen Curran: Yeah.

Drummond Reed: The other thing the sunlight actually is slowly …

Drummond Reed: what I mean in the trees. So I just love this one. It's just
like, yeah, I want to live there. So, yeah. All fun stuff. Any

Will Abramson: Okay. …

Will Abramson: I think we can probably get started. I mean I was talking a
few more folks including man who's the topic I wanted to talk to him about
but let's get started and hopefully I'll drop in later. So welcome everyone
to the credentials community group call the 17th of February and today we
got Steven Curran joining us to talk about did webb and did attested
resources. before I go into that and just review the admin. so we follow
the code of ethics and professional conduct.

Will Abramson: So, please let's continue to create a welcoming community,
treat everyone with respect. I'm sure we do a great job of that, but let's
just keep that in mind. second IP note. So, anyone's welcome to participate
in these calls. However, substantiative contributors to any CCG work items
must be members of the CCG with full IPR agreement signed. If you have any
questions about that, get in touch with me, Denan, or Mammud can help
third, this call is recorded and the minutes and recording is sent out to
the mailing list. I think probably within 24 hours at the end of this next
introductions or reintroductions. Anyone new to the call today who wants to
say hello or anyone hasn't said hello for a while and just feels like
picking up, jump on the queue. Patrick, yes,…
00:05:00

Will Abramson: go for it.

Patrick St-Louis: Yeah, just want to say a little hi.

Patrick St-Louis: Some people here might know me. I'm attending many calls
but this specific calls usually kind of clashes in the agenda but have been
assisting Stephen Kuran in deploying WebVH and working on this. So this
meeting sounded very interesting. I see a lot of familiar faces in here.
It's great to see. And I'm about to start reading your book, Drummond,
Self-Soververing Identity. A bit late to the party, but I'm sure it will be
an interesting read,…

Patrick St-Louis: especially in today's context.

Drummond Reed: I'm thrilled.

Drummond Reed: You'll find that it's amazingly enough for four years old
almost entirely still, current or accurate. It's just all the specs have
been evolved and…

Drummond Reed: you won't find unfortunately any web VH in it because
Stephen come up with the idea early enough.

Patrick St-Louis: I would question a lot of things…

Patrick St-Louis: if I found whatation there.

Will Abramson: Okay.

Drummond Reed: But Stephen promised me that the call goes that he'll write
the next edition.

Stephen Curran: I did.

Will Abramson: Anybody else want to say hello before we move on?

Stephen Curran: Yeah.

Will Abramson: seeing anyone. rod Anyone have any announcements or
reminders they want to share with the community today? Hi, you're muted.

Kaliya Identity Woman: Hi, I didn't know I was on video. it's freezing
here. I want to share a few things. One, we have the 42nd internet identity
workshop coming up April 28th to 30th. we are committed to accessibility.
So, if you want to be there, talk to us. We will help you get there. we
also have the agentic internet workshop happening the day after IW. And
we're also looking at potentially having a interoperability something room
where people can hang out and get their agents to talk to each other
happening in parallel to the last day of IIW if people are interested.

Kaliya Identity Woman: So yeah, those two things and there's folks in South
Africa hosting the did on conference Africa next week. So if you're in
South Africa or Southern Africa or friends they can still attend that and
we have the digital identity unconference Europe coming up June 22nd to
24th in Copenhagen. and early bird tickets are available and so our
sponsorships and quite frankly sponsorships are open for all the above. But
anyways, thank you

Will Abramson: Thanks for a lot coming up. any other announcements,
reminders? and then also any CCG work item updates. I have one thing to
share. maybe I can ask Denim to share, but the chairs recently reached out
about updating our website profile. So the CCG kind of has confusing
website management things,…

Stephen Curran: Bless.

Will Abramson: this is our W3C website homepage, but we also have this Hang
This is our actual website. We would say our main homepage. And what we
wanted to do is ask if the W3C staff could update this text on here to
point to our homepage. And the staff staff got back to us and they actually
raised a few issues that they weren't super happy with about our website. I
was hoping Mano would be on to maybe just talk about this. But basically we
need to make some changes to this website. One of them Den maybe can you
speak to this?

Will Abramson: thinking was the one…

Will Abramson: who reached out about this and got back some comments from
Ian Jacobs that now need to sort of track

Denken Chen: …

Denken Chen: our chairs are trying to making our new website to be listed
on the W3C's official website for the CCG. the one I'veed here, the
dub3.org/ slashgroupscredentials. it's kind of confusing for newcomers
particularly from my side point of view we have one official page on the
W3C and W3C has another block system based on WordPress and these two are
not very customizable. So, we had another new website w3-cc.org
00:10:00

Denken Chen: work and we trying to put that onto a W3C's domain and there
were some feedbacks that the main concern is that this is a CCG web page
but we describe all of the efforts the community have been producing
including the specifications standards developed by the working group D and
did and is verifiable credentials working group and they were concerned
that people may get confused that the community group produce standards
which it doesn't. so we may need to adjust some of the content to meet the
requirement there and our chairs will move that forward and that's it.

Will Abramson: Yeah, thanks I think we will raise issues probably against
the repo and then track them there, but we need to make some changes
because of W3C bureau. Patrick Yes,…

Patrick St-Louis: Sounds like the biggest problem is the standards page
specifically. I understand that's…

Will Abramson: exactly. Yes,…

Patrick St-Louis: because this refers to maybe things that were at one
point on CCG but have been since then evolved.

Stephen Curran: freak.

Will Abramson: I think it's that. And then also kind of annoyingly, they
don't love that in fact they asked us to not use their logo because it's
not under the w3.org or…

Patrick St-Louis: There we are.

Will Abramson: website and they're also checking if we should have this
domain contain W3C in so I don't know that's why I would have liked Mario
here because I'm sure would have some interesting thoughts on that but
anyway we can deal with this offline I don't want to take any more of
Stephen's call time but just I think this site is good we're just going to
have to do a few tweaks to satisfy that probably shouldn't told them about
it never Duncan I mean Stephen over to

Stephen Curran: Okay, thanks. Glad to be here. let me share my screen. I've
got presentation of course. So, let me share the screen. Okay, we can see
the screen. I'll jump into slideshow mode. Okay, that's working.

Otto Mora: Yeah.

Stephen Curran: Okay, Thanks. okay. Want to give people an update on did b
I confess that I asked to be allowed to present at this in I think it was
September and was told, "Yep, absolutely. How about February?" So I was
kind of surprised at the lead time needed and in the meantime I didn't add
things when I prepared this about attested resources.

Stephen Curran: So, this is about DI webbh. I'll mention where our tested
resources come in, but it actually is a good and useful thing that we've
added as part of our did webb deployment work, but this will be about webb.
the slides are available at this link. If anyone wants to jump to it now,
feel free to do so. This just, redirects to the actual Google slides that
I'm using. So agenda did web plus verifiable history and some more so we'll
talk about that what we're doing with it in the real world and what others
are doing with it in the real world.

Stephen Curran: lots of folks which is good specification status and
deployments that are out there and then next steps that we're working on
and we're would like to invite others to help us with. So looks like did
web with sort of one huge glaring difference and then a couple of subtle
ones. So subtle one number one of course is that it's web. The big monster
one is the 44 character third segment of the DID which is the
self-certifying identifier or SKID. And this SKID self-certifying is
generated from the DID the initial entry as you'll see of the DID.
00:15:00

Stephen Curran: And then the last really subtle one is that unlike did web
which resolves to at a place derived from the onent of the name. It's a
JSON lines file that is the source of the information for resolving the big
thing to know about webb versus that did webbh the trust is not did web
relies on DNS to go find the file and that gives you the document in that
it does work but the trust is not in the DSS DNS.

Stephen Curran: the trust and again I put that in quotes because you've got
to understand what it did is for and I hope most folks realize it. but
trust is in the verifiable history. The fact that there is verifiability
from the skid that is embedded in DID the identifier through each that
resolves into the DID doc. So the DNS is only for discovery. The DID is
verifiable regardless of where the log is found. And so the log can be
found in different places, can be sent to you, can be found on a watcher,
all sorts of places and it's still verifiable. the DNS is to tell you, by
the way, you can also find it here. That's very important about it.

Stephen Curran: John Jordan's been working on some documents about why we
as in BC gov is very interested in DID webph and making it happen as a
interoperable easy to use way to share. And so he's got a document called
the trustworthy web is a verifiable web. And this is for a noncredentials
knowledgeable audience. And so I include this here and the quote from the
beginning for you to take a think about. John's got some great stuff here
and recommend clicking on the link here and taking a look at the document.

Stephen Curran: It's really useful and you can share it hopefully with the
idea of it is to be shared with people that don't understand credentials
but want to know why dids are important verifiable credentials are
important and did webb is particularly important in that it enables a
trustworthy web because it becomes veri So back to the somewhat more techy
part, did web plus verifiable history. so the document that JSON l file
contains every version of the divid that exists and all of it contained in
a log. So each did version is an entry in a the log each entry has these
five.

Stephen Curran: It's a JSON object and has five elements to it. JSON lines
is used so that we just append each entry to the file. so it's not a JSON
file itself. but JSON lines a resolver would retrieve and processes
verifying each log entry as it goes. the parameters in here configure DID
tell the resolver how to process it and that's very important for enabling
very longlasting We want DIDs to last many years to be used and parameters
allow it to do that. So we'll take a look at what these items within the
JSON object are. So this is what a log entry looks like.

Stephen Curran: I'll start with the simplest thing, DID document. This red
thing state is the attribute and its value is the DID doc. So this is the
simplest of all did docs. but the entire doc is always contained within the
state. next simplest is Version time is when the controller published the
dead according to the controller. Of course, that's up to them to do it
accurately, but of course, there's verification we can do on that. It can't
be in the future and each version must progress in time. So, we do have
some constraints that we can monitor that the D is being honest in
production of time its time value. The next one that's fairly easy to
understand is a proof.
00:20:00

Stephen Curran: So this is a data integrity proof on the entry and it's
just attached the way any other data integrity proof is attached. it must
use the crypto suite ED DSA JCS 2022 that is defined in the 1.0 O
specification that must be used and it's signed with a key that is defined
up here in the parameters and we'll get to the parameters in a moment. So
we'll see the correlation between this key that's used to sign the version
You'll notice it's a hash. And basically, it's a hash of the hash or the
version ID of the previous entry. And for the first entry, it's the skid
which is contained in the DI itself.

Stephen Curran: and then the skid plus of the rest of the entry and that
gets hashed and put into a multibase hash and put here into the version IB.
So this is version one and this is the hash for that version. we'll see how
that enables the linking of all of them together making it impossible to
insert versions in the middle. And finally The parameters do as I said
configure the divid. So in the very first one there's certain one certain
entries certain attributes that have to be in the first one. Skid is one of
them. So this defines what the skid is for this div. We also have to define
in the first one the method meaning the version of the specification that's
being used. that version 1.0

Stephen Curran: 0 of webb continues until we change it in a later entry in
a later parameter. So this DID to evolve in its use of the specification
over time and that allows us very long lasting DIDs. And finally These are
a list of keys. There's one in this one that must be used to sign an update
to the DID. So DID in order to create version two it must be signed by this
key and a proof attached to it. So that is where the verification of
authorization to update it. This is really an authorization key to update
the dig. So that's what a log entry looks like. so we've got proof of
control for every entry chained like a ledger.

Stephen Curran: So, we've got the self-certifying identifier that's
generated at the creation of the DID. We've got an explicit list of keys
authorized to update the DID and pre-rotation can be used for that as well.
So, we can commit to a future key by putting the hash of that key in and
commit that we're going to use that key when we update the data in the
future. Note that authorization keys are separate from the keys in the DID
doc. So you could put the authorization key in the DID doc, but you don't
have to. The idea is the DID doc can contain whatever the DID controller
wants unconstrained by anything in webH. So that authorization key that you
saw does not have to be in the DID doc.

Stephen Curran: It is used for authorization to rotate the DID entries are
chained via the version ID hash that you saw. So in order to generate the
hash, we put the skid of the DID along with entry one and we generate a
hash for entry two. We take that has that we generated, we put it in along
with the rest of entry two and we generate hash for entry two and so on.
And so that means everything is linked together and it's impossible to
insert an entry in the middle of the log in any optional and allowed is
external witnesses can be defined that sign the version ID of the hash of
an entry.

Stephen Curran: And so that adds security and robustness to the use of the
DID. I cannot see any hands up or anything. So please jump in and tell me
if anyone's asking.

Otto Mora: You're

Stephen Curran: Okay, did web plus verifiable history? you may publish a
did web alongside a did webb by v via a very mechanical algorithm. So given
a did webb you can absolutely just run a process on the result of the most
recent did to generate the did.json
00:25:00

Stephen Curran: JSON associated with the DID web. And so you must insert an
also known as entry in the DID web that happens in that mechanical
translation and you wind up with a did.json which is the DID web did do and
then you have the json JSONL DID log from which you can resolve or extract
after verification you can extract the that is the whatever version of the
DID doc you want. So that's how it aligns with DID web.

Stephen Curran: this has been a surprisingly controversial feature that
we've included and we included it right from the start assuming that
because of the nature of the web the DNS portion since it's the verified
part of it may change over time. We wanted to make it that a DID could be
portable in that it could be moved from one DNS location to another. we
have put constraints on that because of feedback that people see a risk in
DIDs moving around particularly a risk that the controller may not want it
did to move around and somebody may move it without their knowledge.

Stephen Curran: So we put limits on it. So it may be The only way it can be
portable is if at creation time in the very first entry there is a portable
equals true value in the parameters. So if this is not in the first entry,
the DID is not port meaning it may not be moved from its DNS location. it
can be made not portable. In other words, a later entry could include a
parameter called portable false, but the reverse is not possible. So you
can't change it to become true later.

Stephen Curran: it must be done declared at the beginning and the result of
it is that did retains its skid and its history and how that history
contributes to its reputation. So the enterprise version if you will of
that is the digidhome.com becomes newhome.com and retains its skid retains
its history and so people can see that it retains it.

Stephen Curran: I see this as an interesting one, which is I could have a
did on a platform like Google and this might be my did on the Google
platform and then later I move that did to the Yahoo because it's much more
modern and newer and so I retain the skid, retain the history and people
can look back and still see things I've signed with the older version. but
it does allow me to move it. But again, that is potential use cases. If you
don't want to have that, you simply don't put this portable true and you
don't get that ability. It is a new DID. Obviously, changing this part of
it makes a new DID. So, it's not like it is the same DID, it is a different
DID. However, the skid and the history are retained.

Stephen Curran: so that long the verifiability of control is retained.
we've got defined access to resources DID URL path. So we can simply take
the DID and add a path to it. By default, the resource that's pointed to
can be found at the same relative location as the DID itself. So we're
using that same transformation of DID to HTTPS. however, that location the
DID controller can override it.
00:30:00

Stephen Curran: So we put in that if you don't do anything it automatically
implies the resources will be found relative to where the did log is found
but you can't override that. And then another super interesting one, we use
that same sort of capability to have a did did URL resolves to a verifiable
presentation that contains credentials did as the credential subject.

Stephen Curran: And so the idea there is that you can have an attestation
from a verifiable credential from somebody that DID to some legal entity
identifier. So the legal name of the registration legal entity identifier
and things like that. So that's the idea of So you could and we'd like to
see this with every did so that there's this ability to have did who is and
be able to find out verifiable credentials that others have said about this.

Stephen Curran: once you've bound it to the legal identifiers, you might
include other verifiable credentials, other certifications that are bound
to those identifiers. So did identifier to the real name of the entity and
then certifications that use the real name of the identity that are bound
to that. This also could create a distributed trust registry where the
trust registry rather than going to the trust registry to look up the dead.
the trust registry would issue a credential to the did about what the trust
registry says and that could be found via who So I think that's a super
interesting capability and would love to see it everywhere. So we just keep
talking about it.

Stephen Curran: a couple more security mechanisms. Pre-rotation, witnesses,
and watchers. I should have watchers down here. So the key with these so
pre-rotation simply means that you put in your update key which is a
representation of a public key and then the is a hash of the next update
key that you're going to use. And so you're committing to it but you're not
telling the world what it is.

Stephen Curran: you're only telling it And what this does is prevent
somebody from compromising this key and then updating the dead. it could
compromise this key, but unless it also compromises this key, it's not able
to update the DID. So that's the capability that's there with witnesses
allow you to specify a DID key that must sign a proof associated with an
entry. And you could have multiple witnesses and a threshold saying, I have
three witnesses and two of them must provide proofs that they're willing to
whatever approve means, that this entry be published.

Stephen Curran: witnesses and watchers in particular. So watchers simply
here's a URL that we know is watching this did and not only is it watching
the did but we notify that watcher did whenever we publish a new entry or a
new resource we will notify the watcher. So anyone can be a watcher of a
dead but an official watcher if you will is proactively notified when a
date is updated or if a did is a resource is published.

Stephen Curran: both of these witnesses and watchers are pretty simple
specifications of what the feature is and we very deliberately leave
covenant governance out of scope. So a witness would sign what it signs is
the version ID of a new entry. why it does that, how it decides yes, I'm
going to sign it or no, I'm not going to decide that's out of scope of the
specification. We simply say Here's how you have witnesses. but how you do
that is out of spec. One of the other things is notice this is DID key.
It's not some arbitrary It must be DID key.
00:35:00

Stephen Curran: And that was to prevent a recursive loop of having to
determine what type of did the witness was using. What that means is who
that witness is and who it represents, what entity it is, all of that is
out of scope. That's governance. and so anyone using this witness may want
to determine who owns this did key. That's out of scope for the
specification, but an ecosystem would define how they would do that. And
that allows for a simple implementation of the specification, but allowing
an ecosystem to do whatever it needs to do. Okay.

Stephen Curran: So, quick summary of DIDs in the real world. I've got lots
of links in here to live, implementations and real things that are working.
Hence why I put the, link up here to this, slide deck. so we deploy DID
webH servers. There's several implementations of DID webb servers that are
got additional links later on. So that would be deployed to some location.
It doesn't have to be a DI webb server. You can simply publish the log file
on a GitHub repo if you want or anything else. But we have did webb servers
that provide additional governance rules over who can publish to it. So for
example, an enterprise may want to have a webba server.

Stephen Curran: BC Gulp has one and it controls what the various
suborganizations are allowed to publish on that DID b server. So there's
governance on who's allowed to publish to that. A DID controller would DID
webb using something like a framework like ACPI which we use but there's
again a number of different frameworks that implement did webb number of
implementations they follow the rules of their server and publish the log
which inherently publishes the dat in creating it they come up with a skid
for it and then

Stephen Curran: that location of the server defines what the DNS part of
that is. They might request credentials about the div and publish a slash
who is verifiable presentation. They can publish A tested resources which
I'm not going to talk about but I said when six months ago. attested
resources would be published to the web server. So things that are
accessible via the path did URL path and we've implemented full support and
actually there's a number of implementations for full support of a nonredit
objects what we're doing with it BCG gov is transitioning all of our did
webba or indiebased and onred objects so we're going to be publishing
instead of rooted

Stephen Curran: in Indie will be rooted in a DID webph server. Once the
controller has published their they can use the key to publish the DID sign
things, decrypt things. They can issue credentials in any format. We're
also using W3CBC's with the webb and of course use any protocol to exchange
Anything that supports s can use the webb. Obviously others can resolve the
divid. there's number of resolvers out there. that resolver would verify
the history to make sure everything is correct with the verification
according to the rules of the specification. that would give them in the
doc that they retrieve the public keys that are being used to sign or
publish to able for decryption to happen and then they could verify and
encrypt things.

Stephen Curran: they also might who is endpoint to get a verifiable
presentation and learn more about the DI. Again, we think that's super
important. The DID controller then creates an update to their DID webb and
publishes that which adds a new entry to the log. So that's did webb in the
real world. minimal dependencies and it's a pretty small library. It's a
couple of K in the various libraries that have been implemented lines of
code. So it's pretty concise.
00:40:00

Stephen Curran: we use JSON lines so that we can just append files and that
enables DID resolver to cache the state of a DID and its current and then
only requests the new lines that have been added, the new entries that have
been added. we use multiash and multike key and base 58 coding so that
multiash and multi key so that people can tell which h algorithm is So
we've got flexibility in which hash algorithm and which key types can be
used but the specification although we do use those encodings in multi-ash
so that in future we can be flexible we're very specific in each version of
the spec and this is why the version of spec is very important so we
constrain what a resolver has to know what algorithms it

Stephen Curran: has to support in order to resolve them. So only data
integrity suites with JCS and EDSA and D key can be used and that is very
purposeful that we can multiash so we have flexibility in the future but
using the specification and versioning in the specification to constrain
what a resolver has to support in order to

Stephen Curran: be able to implement it. So to improve in interoperability
we'll talk a bit more about that in a later slide. So where are we right
now the spec is at 1.0 and stable. we completed the process back in
September which is why I asked to speak here to let everyone know that we
are now officially DIFF recommended. So diff has a process that a dit
method goes through a series of hurdles to pass and we've quietly done that.

Stephen Curran: diff hasn't made any announcements because they're waiting
for more did methods to get through all the hurdles but did webb completed
I think last September and became diff recommended obviously registered in
the divid methods registry and available in the universal resolver the
information site did webbdh.info info is there with all of the
documentation, the spec, the demos, deployments, and so there's at least
five implementations in counting. and we really used implementations to get
feedback into the spec as we built it. So, at DIFF, there's three full
registration and resolver implementations in TypeScript, Python, and Rust.
all of them are pretty fast.

Stephen Curran: these are for rust entries. So a 10-year-old did which
updates every month rotates publishes a new version every month and I
believe it's five witnesses that are verifying that the whole did log is
only about 200k that would need to be downloaded and verification can be
completed in about 28 milliseconds. So that's end to end for a 10year-old
did. That's pretty good. We're pretty pleased with that. as far as
resources, DIP also has did resource browser and watcher implementations.
Affinity has done a ton of work did webb using it in all of their
implementations and particularly in the first person project and the work
they're doing with the Linux kernel around

Stephen Curran: the first person project and first person credentials. so
they have a repo with a full set of tools, another server different from
this one witness implementation, watcher implementation and then a browser
I for looking at the data published on that. at the open wallet foundation
there are a plugin for a package for credo. the plug-in for Occupy includes
witness support.

Stephen Curran: these all are totally interoperable and are used in various
places for issuers and verifiers using API and CTO and then wallets u
mobile apps based on Credo and Biffold and then here's a series of
tutorials one just a wizard for did using the Rust implementation and then
a couple more larger ones that are sort
00:45:00

Stephen Curran: browserbased understanding a didd log and then walking
through using didd webb as the root of issuing holding and verifying in on
credits deployments are planning are expanding the selected link here is to
the info site for the page there I've actually got to get it upgraded I've
realized how I did get it upgraded before but I'll do

Stephen Curran: that the Swiss eid team announced support for did webb
obviously in British Columbia we're using it and other provinces will be
using it the first person project network is now using it in the form of
didk skid vh which is a meta u did method based on vh and so they're using
that implementation in their work and that again is related to the Linux
kernel work and what will expand out into the first person credentials and
so on. And then finally, the United Nations Transparency Protocol has did
web as their initial but have added now did webb as what they're
encouraging folks to use for a more network of verifiable credentials.

Stephen Curran: Please let us know if you are doing did webb and further so
lots of implementations there is a divid webb sandbox you could take a look
at and use so this is a sandbox you can use for automated test pipelines so
if you want to publish did webb's there's no SLA on it it's open for
testing we're not resetting it but it might become reset on the 1st and
15th of every month, but intended for anyone wanting to run automated test
pipelines. So, finally, next steps and what we're doing first of all,
deployments.

Stephen Curran: We're heavily focused on deploying as I say at BCG gov for
example we're transitioning off of hyperdenture indiebased onto did webb
rooted credentials and then also publishing UNP style W3CBC credentials So
anything involving DIDs will be rooted in DID webb. the spec needs to
evolve. recently there's been work in the DID resolution spec on DID URL
path handling.

Stephen Curran: and so once that gets added we'll want to upgrade how we've
defined P handling to be aligned with the data resolution as always
whenever we evolve this the spec we want to look at should we change our
hashing and data integrity crypto suites algorithms? Should we make any
adjustments there? And obviously one thing we could start to think about is
there's starting to be some PQs that might be used postquantum algorithms
that might be used. So do we want to add those at this point and enable
that?

Stephen Curran: that is as I said a did would declare in an entry saying
hey I'm now using version two of the spec and the resolver would have to be
able to handle a one and two versions. We're also exploring best practice
ways to manage obviously we have the full history available. How can we be
both DID compliant but take advantage of the fact that the full history of
the is available. All of the keys that have ever been published did keys
can fall into four we see as four categories.

Stephen Curran: the current one that's being used to sign things today.
Inactive ones that were being used to sign things, no longer signing new
things, but can be revoked because they were compromised, and then revoked
because they were never compromised, but no credentials should be verified
with them any longer. So, we're exploring how we can take advantage of our
full history, did compliant, and be concise in the size of the law. And
then the did sell and did skid work has triggered a few conversations. Some
of them were already going on, but we did want to look at them, which is
heartbeat.
00:50:00

Stephen Curran: This one's a very simple one which just will be a new
parameter that commits the did controller to have a minimum time between
updates and if they miss adding an update before a minimum time the would
be considered deactivated.

Patrick St-Louis: Is it more a maximum time before updates?

Stephen Curran: Yes.

Patrick St-Louis: Meaning if it's more than that time. Okay.

Stephen Curran: Yeah, it could be one of those. Don't ask me to think about
it on the fly. okay.

Stephen Curran: so they have to put out a new version whatever they commit
to every 30 days, every 90 days, every year, whatever it is. so that's just
an easy change. They can just publish a new update. we might also allow an
update without a do change. So, if we want to minimize the size for a pure
heartbeat, which means a pure heartbeat entry would be one where the only
reason we're publishing it is because we said we would publish one. we
could optimize the size of that by allowing the did do to not change. In
other words, not be included in it. So, we're talking about that and we'll
figure out what that'll do. But the basic heartbeat feature is very simple.

Stephen Curran: this is the big interesting and controversial and the
experience that the first person project using didkid VH is doing is very
helpful on this. Maybe we make the DNS part of the DID al. did cell which
was introduced recently and did skid both do not include any DNS. how you
discover where the DID itself. They provide other mechanisms or assume that
the resolver knows and I put that in quotes where that is. So making the
DNS part of the D optional is technically straightforward. The question we
have is whether it's helpful for did DVH and so we're thinking about that.

Stephen Curran: very interesting to see how it's being used. For example,
as a peer did in first-person project where two peers exchange did webb
logs and then that they know where to find it. did PLC from Blue Sky does
not have a location because the DIDs are stored in a known place. And so
we've been actually talking about this for quite a while, but the did sell
and did skin experience has accelerated that. So we're thinking about that.
And then finally, one of the big things we've done is u witness proofs did
log but are in a separate file. and that we did because there's a big
tradeoff in the size.

Stephen Curran: So we made much the witnesses file very small through how
it gets managed. so there's this trade-off of having a single larger file.
it doubles the size of the didd log over time. depending of course on your
witness strategy and what your ecosystem requires. In a general that case I
mentioned earlier, it would double the size of it. but it would be in a
single file. So that's the trade-off. it also allows us to remove some what
I now consider excess governance that we put into the spec. Remember I
talked earlier about we really wanted to not put governance in the spec to
enable oblivious witnesses.

Stephen Curran: So what did cell calls that? So we're looking at that as
well. And then the final thing that is we're considering that's really
important is this is going to be the first time did 1 are in the wild. now
we want to be able to have a DID that transitions from V1 to V2. So it says
in some entry in the middle of the log, it says, "Hey, I'm using version
two from now on." And we want to make sure we understand and document and
provide guidance and help for implementers of resolvers of exactly how to
handle multiple versions. we punted on that issue as we went from the 0.5
and so on, but with the 1.0 to the next version, we are going to have to
address that.
00:55:00

Stephen Curran: Here's where we meet. I'll leave it there. I haven't left
much time for questions. I apologize for that. Here's where we meet. weekly
meetings at diff and…

Stephen Curran: zoom and Interesting there. glad to have anyone participate
and let us know what you're doing with it. And with that, I will stop.

Will Abramson: Great. Thanks,…

Will Abramson: It's wonderful to hear a dead method getting such adoption
and…

Will Abramson: the implementation experience from that is great for this
community in general, I think. Does anybody have any questions? We probably
have time for one or maybe two.

Stephen Curran: Sorry about that.

Will Abramson: That's all right. I mean, I took a bit of time at the start.
Anyone?

Otto Mora: It's great to see it. I mean, congratulations to Stephen. This
is really great work. And also congrats for the wide adoption and
deployment. there's people out there that say ds are not real or whatever.
hey, it's here. It's adopted. it's gaining more adoption in fact. And also
great work by Stephen on the did Patel at W3C D working group. We're very
grateful for his efforts there.

Stephen Curran: I don't get credit for DI webb. I think a ton of people did
a ton of work of really great things. the implementers that worked along as
we did the spec and adjusted. So, I created the agenda for the meeting,…

Stephen Curran: but they really did a ton of work to get it to where it is
today. And I'm really pleased with where we've got to and look forward to
hearing about other implementations.

Will Abramson: Great. Thanks.

Will Abramson: Okay, I'm not seeing anyone on the queue, so maybe we just
close a little bit early and give back a little bit of time. But thanks
again, Stephen. I really appreciate you coming on. I know it's not you who
did all the work, but you have spearheaded it. So, it's great to see sharing

Drummond Reed: And Stephen, you did spearhead the work to get it through
the did methods task force and become the first diff recommended did
method. So yeah,…

Stephen Curran: Yes. Recommended.

Stephen Curran: Yeah. Yeah.

Drummond Reed: that is a big deal and once there's another one at least the
can announce that. But this group knows.

Stephen Curran: Yeah. I'm going to throw one more out there as I think
about it.

Drummond Reed: Yeah, I will say from a didkid standpoint of all the
skidbased did methods it did webvh that is getting the most attention. so
keep going.

Stephen Curran: One of the other things that we're seeing and I think I had
it on one slide but anyway other using the the did log format that webb
defines but storing it on a blockchain linking it to a blockchain and
connecting it and so merging the verifiable history with what gets
published on other than just a web server that is also happening and quite
interesting. So that is another possibility that we provide is we just use
the log format which is pretty flexible, pretty nice I think and allows for
publication anywhere. Yeah.

Will Abramson: Interesting.

Drummond Reed: Thanks. Good job, Stephen.

Will Abramson: All right, thanks everybody. have a great rest of your week
and yeah, you next Cheers again.
Meeting ended after 00:59:06 👋

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