- From: CCG Minutes Bot <minutes@w3c-ccg.org>
- Date: Wed, 10 Jul 2024 16:20:39 +0000
- To: public-credentials@w3.org
Thanks to Our Robot Overlords for scribing this week!
The transcript for the call is now available here:
https://w3c-ccg.github.io/meetings/2024-07-09/
Full text of the discussion follows for W3C archival purposes.
Audio of the meeting is available at the following location:
https://w3c-ccg.github.io/meetings/2024-07-09/audio.ogg
A video recording is also available at:
https://meet.w3c-ccg.org/archives/w3c-ccg-weekly-2024-07-09.mp4
----------------------------------------------------------------
W3C CCG Weekly Teleconference Transcript for 2024-07-09
Agenda:
https://www.w3.org/Search/Mail/Public/advanced_search?hdr-1-name=subject&hdr-1-query=%5BAGENDA&period_month=Jul&period_year=2024&index-grp=Public__FULL&index-type=t&type-index=public-credentials&resultsperpage=20&sortby=date
Organizer:
Mike Prorock, Kimberly Linson, Harrison Tang
Scribe:
Our Robot Overlords
Present:
Kimberly Linson, Harrison Tang, Pascal Knoth, Stephen Curran,
Vasily Suvorov, Accelerate, Jon St. John, Martina, Hiroyuki Sano,
Nate Otto, Jeff O - HumanOS, Stephan Wagner, Jennie M, Gregory
Natran, Martina Kolpondinos, Lucy Yang, Markus Sabadello, Nis
Jespersen , Tim Bouma, Mahesh Balan - pocketcred com, Daniel
Buchner, Anil John, James Chartrand, Will Abramson, Kamal L, Joe
Andrieu, Laura Paglione, Erica Connell, PL/T3, Benjamin Young,
Alex H, Manu Sporny, Patrick St-Louis, Rashmi Siravara, GregB,
Wendy Seltzer, Dmitri Zagidulin, Taylor - LEF, Mahesh Balan -
pocketcred.com, Andrew Whitehead, TallTed // Ted Thibodeau
(he/him) (OpenLinkSw.com), bengo, Brian, Kaliya Young, Micah
Peltier, Bob Wyman, Adam Burdett, Emiliano Sune, Tim Bloomfield,
John Henderson, Geun-Hyung Kim, Sharon Leu, Drummond Reed
Our Robot Overlords are scribing.
Kimberly Linson: All right well welcome everyone.
Kimberly Linson: Everyone uh to this Tuesday's ccg meeting um I
think that uh before I even make an introduction we can tell that
today is a very popular And Timely topic because of the number of
folks that are attending today um I am super excited to hear from
Stephen Curran today and I I know a couple of us have gone
through the slide deck already and had a have a have a.
Kimberly Linson: Really excited to hear what he has to say so
I'm going to keep my housekeeping notes as brief as possible so
that we can.
Kimberly Linson: Hear from Stephen and then jump into uh what I
think will be a very good discussion.
Kimberly Linson: So here.
Kimberly Linson: Here we go running down the the agenda uh we
follow the w3c code of ethics and professional conduct um which
helps us to be a collaborative and productive uh working group or
community group um and I think we are all uh we all have that
type of mind um so if you want to read more about that you can
look at it in the agenda.
Kimberly Linson: Anyone is welcome to be a part of the these
this call and we are grateful to have so many folks on today uh
and hope that you will um consider joining us.
Kimberly Linson: As often as you are able and if you are
interested in in contributing work um on a more regular and uh
basis then we would invite you to uh to become a member of the
ccg with a assigned IPR agreement and you can do that uh in the
links that are also in the agenda.
Kimberly Linson: We keep calling notes um uh minutes and audio
recordings of these meetings and we use uh the chat feature here
to QR speakers so um anyone who wants to participate so you can
just put on in the chat.
Kimberly Linson: Q+ and now we'll add you to the queue and I
will do my best to moderate this discussion um and be uh.
Kimberly Linson: Mindful of trying to hear from as many voices
as possible uh all right well now.
Kimberly Linson: Come to uh the time in our call where I am
going to invite anyone who is new to this community or hasn't
been uh attending a meeting in a while uh to introduce themselves
or reintroduce themselves let us know what you have been up to
and you can go ahead and put yourself on the Queue to do so.
Jon St. John: Can I just jump the queue Kimberly.
Jon St. John: Since it's hard for me to.
Kimberly Linson: You certainly can we're so excited to have you
here yes John great the floor is yours.
Jon St. John: Hi sorry for me to get on the Queue yeah just I
want to say hi and I haven't been here for a while so John Jordan
from BC government and I just want to let that folks know that
excited to hear people's comments and thoughts on the work we've
been doing so Stephen and I have been working together for.
Jon St. John: 7 Almost 8 years now and the work that he's
presenting is.
Jon St. John: You know funded by the BC government so just so
people know.
Jon St. John: Where it's coming from and and uh have a great
meeting.
Kimberly Linson: Great thank you John.
Kimberly Linson: Anyone else like to introduce themselves or
reintroduce themselves.
Kimberly Linson: All right how about updates.
Kimberly Linson: For the.
Kimberly Linson: Community do we have any announcements
reminders.
Kimberly Linson: I think.
Kimberly Linson: That everyone needs to know about.
Lucy Yang: Thank you Kimberly um a few weeks ago I presented
about the under California um mobile driver's license Community
hackathon I just want to provide a quick update so we have firm
up the dates for the for both events the first events will be
open to anyone to apply that will be on October 1st um and and
then we will have a separate government a government event that
will be taking place in Sacramento right after IBEW under that 1
will be on November uh 1st on on a Friday the first 1 will be in
Silicon Valley in Computer History Museum so I will share to the
list and the updated brief we just got approved but for potential
participants but I just want to share an update so everyone knows
that we you know we have dates and firmed up thank you.
Kimberly Linson: Great thanks Lucy that's really exciting uh
Erica.
Erica Connell: I just a quick announcement that rebooting the
web of trust uh will be convening in Ventura California in
October uh 7th through 11th so it's the time of year to get your
Advanced reading papers in and I'll drop the link in the chat the
early bird tickets are available now thanks that's it.
Kimberly Linson: Great thank you.
Kimberly Linson: Anyone else with an announcement or reminder
for the community.
Kimberly Linson: All right well do you have anything to share
with the community about uh work items.
Erica Connell: https://rwot13.eventbrite.com/
Kimberly Linson: No no worries I just wanted to make sure I
didn't didn't skip it on our bulleted list but I think we want uh
all the time we can have for Stephen today anyway so that's
perfect uh all right well in in that case I'm going to go ahead
and uh turn it over to Stephen I don't think he needs much more
of an introduction um I think everyone knows he's a Pioneer in
this space and we're really glad to have him so Steve in the
floor is yours.
Stephen Curran: Awesome thank you so much you can hear me.
Kimberly Linson: We can hear you great.
Stephen Curran: All right and sharing.
Kimberly Linson: We see it.
Stephen Curran: All right screen is there excellent okay did TDW
trust did web or if you say it fast trusted web um a uh thing
we've been working on as John mentioned from uh government of
British Columbia digital trust team a verifiable portable
web-based did method with history um perhaps even considered an
extension to did web so that's where we're going today um going
to give a bit of a background um I know there's not a lot needed
on bids and did methods but I'll talk about that briefly Ledger
base dids benefits and costs.
Stephen Curran: Did web in particular web-based is benefits and
costs and then get into um what trust did web is talk about the
mechanics and some other topics.
Stephen Curran: Um so did its decentralized identifiers um
decentralized self-created and published identifiers um versus
centralized.
Stephen Curran: So not giving to you um and published such that
given it did it's resolved into an Associated did do and all
standardized in the did course back.
Stephen Curran: Did docs contain um public Keys generally um
allowing uh signing of data that others can verify receiving
encrypted data from others that only um that did control or can
decrypt.
Stephen Curran: And crucially um can be rotated without changing
the identifier and that's a lot about what we're talking about
here which is how do you rotate Keys um within a did Doc without
changing the identifiers um often they contain service endpoints
that resolvers can use to contact the owner in some way get files
from them get verifiable credentials verifiable presentations
various other things they can do communicate with them and I've
got a couple of links here for example I did publish the um uh
link to the slides if anyone wants to throw that into the chat
that would be good.
Kimberly Linson:
https://docs.google.com/presentation/d/12NSbKbE3YfjjPuq8m0uEdn6hQ43wbW3YrW5auksbASQ/edit#slide=id.p
Stephen Curran: Um so use cases issuers issue verifiable
credentials that are verified using a key published in a did do
um proof of control so if you've got a subject that is uh the
subject of a verify the credential the holder for example could
prove that they are the subject.
<kimberly_wilson_linson> Presentation Link above:
Stephen Curran: By using their did and and using the key within
the did um can be used in combination or instead of a centralized
identifier so 1 of the things we're going to talk about here is
um.
Stephen Curran: Um cryptographically uh having it did for
cryptographically proving things that it is there did but have it
also bound to their legal identity bound to their um uh legal
entity identifier from whatever they were issued by their
jurisdiction.
Stephen Curran: You can even use.
Stephen Curran: For people to use as email addresses cell phone
number Replacements um blue sky is doing um some really
interesting things where where Blue Sky identities um identifiers
on the blue sky Network are actually did with a handle for the
person um but the identifiers itself is it did and the keys for
managing and that get used as part of using your blue sky
identifier comes from the did Doc so um think of a service that
might provide email um messaging different kinds of services and
being able to use a did for that and have a key associated with
it um obviously for people they would have as many as they would
need your work did your you know just like you have your work
email address and your personal email address and your gaming
email address and so on all of those things could be separate
dates for an individual.
Stephen Curran: Um objects related to it and peer-to-peer
messaging is also um really useful did Cam messaging is all based
on dids and using um peer-to-peer messaging so uh did methods as
we know are are are the it did Define simply that there are dids
did resolve and you get a did Doc out of it and here's the format
of it did Doc did methods are how you store a did such that it
can be resolved and there are yes 195 last time I checked and I
must confess that I only checked 3 weeks ago so it could be
larger than that.
Stephen Curran: Largely um the the addition of of did methods
came about because every um.
Stephen Curran: Every platform every um blockchain every Ledger
that came out um had has its own did method and way to publish it
did on a given um platform and that's a result in many did
methods um each 1 different um and requiring often special
software for publishing and resolving it did um there is a
universal resolver and register um published by uh diff and and
managed um by this call but but those aren't recommended for
production at least the public versions of those but you could
run your own so those are all of course open source and you could
um deploy your own Universal resolver and registar.
Stephen Curran: Um ledgers were very popular for using it um and
and this gives some context for um the did TDW so dids are
exactly the kind of public data that are ideal to put on a ledger
anything you want absolutely published for the rest of the world
to be able to see in you so public um ledgers are robust always
available replicated across nodes the ordering is um verified
there's no need to call home to the owner of the did to get the
did do it's it's in a a third party that's distributed around.
Stephen Curran: Um when you update a did when you rotate it all
of the previous versions remain available um you you have to
prove who you are you have to um.
Stephen Curran: Uh have authorization to update it did or to to
add or update anything on a ledger so that's covered um immutable
once it's once it's version is published it can't be altered and
and even if the issuer disappears if if um if they dissolve as a
company their website goes away Ledger base dids can't be deleted
so that can be very important for long lasting verifiable
credentials.
Stephen Curran: Um public ledgers have Associated
cryptocurrencies often and that's an issue in quotes for some um
it's it's pretty tough for John Jordan to go to the premiere and
say hey we just need to get some Bitcoin to um to Route the trust
of all of our our citizens um credentials um that's a little bit
of a tough 1 so but if you don't have a token it's pretty hard to
operate a ledger who pays um how to how does that get managed um
interfacing can be difficult um and there are many many types and
many instances of ledgers and that's created many did methods and
as a result we wind up with.
Stephen Curran: So we get.
Stephen Curran: Did web is is brilliant and dead simple there um
but it's got some issues um did web of course is just simply
publishing the did do at a defined place on the on on a web
server and you.
Stephen Curran: Convert the dead string into an HTTP address and
retrieve the file at that point um you don't get any history so
if um if the key has been if the did has been rotated a new
version of the did doc has been published um any previously
active public Keys may not be there um there's no verification of
that non-existent history so who made the change was it actually
made by the controller of the did or did someone decide to take
over um the publishing of it and and should should everyone
trusts that change.
Stephen Curran: Its not.
Stephen Curran: Lot of you.
Stephen Curran: Is the current version really what was published
if the if the controller decides hey I didn't mean to publish
that key I met this other key so I'm just going to publish again
that could be considered a rotation or it could be an update to
the current version it's really not too clear um the loss of
control there there's often a call home to the did owner to
retrieve it.
Stephen Curran: But on the other hand as a bonus if the domain
name is is associated with the owner of the debt you get a
benefit from that and there's a spec that I've linked here um
for.
Stephen Curran: Dns-based High asuransi did web um that could be
added and and I'll talk about that later because it also applies
to the TDW.
Stephen Curran: Um and of course you may lose control of your
your web service and and your uh your did web may have to be
deleted disappeared and moved so it's not overly portable and
that's an issue.
Stephen Curran: Um our our claim as we started this work because
there's there's really just 3 core bid methods um 2 special
purpose ones that that we think are incredibly valuable did key
for just a raw public key wrapped as it did so that you can use
it in place of any other did and then did Pierre which is not
published per se but actually shared between peers so only the
the 2 or 3 or however many parties that are are in a peer
relationship actually discover and learn about the Deads they
they simply transfer them between 1 another um but that allows um
the use of dids to be dids to be used but only between those
parties that need them and then the last 1 for any published did
did web is the only 1 that really has traction.
Stephen Curran: But as mentioned before dead simple to use but
kind of inefficient and all the other did methods are really just
competing um to be noticed to try to say hey use this did method
because it's on a platform that's that's really valuable and and
that's that's more a a competition.
Stephen Curran: So our.
Stephen Curran: Premise there's not a sufficiently capable
dominant dig method for public bids and so we get to x uh XKCD um
so we get to this um we thought hey there's only 195 so what
would be 1 more that can't be that bad so that's what we did did
TDW um trust did Webb specification linked on this slide and also
at the end so that's available.
Stephen Curran: Um so let me jump into what that is.
Stephen Curran: Um very similar to did web but with a ledger
list verifiable history so um what would some would call a micrel
ledger um instead of or beside and it could be both um the the
did webs did Json file there is a did Json L and that is not a
typo um that's an extra l meaning Json lines and I'll mention
that in a little bit.
Stephen Curran: A resolver would retrieve uh and process the
Json L file and and retrieve in that action the entire did Doc
history so all of the versions of the did do chained together so
they're um chained as in a as in the blockchain um.
Stephen Curran: Type of thing and all of them signed by the did
controller so that authorization can be done.
Stephen Curran: Um that did contains a self-certifying
identifier and and that enables uniqueness and portability and
we'll talk a bit about portability um we've added to this defined
URL path handling and 2 really important things um did Slash path
to file gets resolved to a file and and that file can be used for
various things associated with the did so it's it's uh you want
to provide some mechanism to a good to associate that file that
gets produced with the did and then did Slash who is which John
Jordan came up with which is a really cool way of determining
much like you use who is on the internet who is the controller of
the did based on the attestations that have been received by that
did from others um so that could be a way that is a way we we
hope and we'd love to see every did method implemented as a way
to find out.
<anil_john_[us/dhs/svip]> Love the /whois feature!
Stephen Curran: Oh I got this did or I got this verifiable
credential presented to me and it's from some issuer let me just
do a did Slash who is to find out who that issuer was and so a a
really good way to um determine who is behind a given did.
Stephen Curran: Small and simple implementation with minimal
dependencies I'll get to that list and high security features um
so um we borrowed a few things here from um the concepts that
have gone into carry so things like pre- rotation and Witnesses
and then as well um DNS binding um using that mechanism for um
DNS High Assurance with did web well it can also be done with did
TDW to create a um a a back and forth between DNS and the did.
Stephen Curran: So um this is what it did looks like did TDW
Aviary ID and then a skid so this long 28 or more character um
hash is a skid uh self self-certifying identifier and this
resolves to um in this case we matches exactly what um this did
web of this would be which is https Avery Aviary ID slash.
Stephen Curran: Then the skid which is in this case a folder or
at least a logical folder and then slashed did jsonl.
Stephen Curran: Um so that's how you retrieve how you take a did
convert it and retrieve the log.
Stephen Curran: Um Kudos here to uh in particular Brian Brian
rior and Whitehead and John Jordan for um collaborating on this
we we did a lot of iteration on requirements implementation
specification back to requirements um we think we've got a
reasonably clear simple and complete spec and and that's what's
linked um to implementations less than 1500 lines of code in
typescript.
Stephen Curran: Um but we're definitely um you know looking for
feedback um security Simplicity Clarity and and what more can we
achieve with it so that's where we're going next and I'll have it
at the very end a slide on how we can get help on this so to the
mechanics.
Stephen Curran: Um I am watching the um.
Stephen Curran: Uh the uh.
Stephen Curran: Uh chat go through them so if anyone has any
questions or anything and want to jump in uh I can see that.
Stephen Curran: Um the mechanics so it did to http
transformation is identical to um.
Stephen Curran: Uh did web except there must be a skid this 1
12345 represents the skid so it can be in a in a path.
Stephen Curran: It could be in the subdomain and so you got a
well-known and we're also playing with mechanisms and this is the
issue related to that of how to add the skid in some convention
to the did such that um you you have it at the root of the
domains uh do well known so um this isn't in the uh the spec yet
but we've got an issue for how to do it and so this is 1
possibility and underscore is an invalid character for a TLD so
that did could have underscore and then the skid and then we we
just dropped the skid from that so the skid remains in the did
but dropped from the URL.
Stephen Curran: As I mentioned um once you've done the
conversion retrieve and process the log and each entry produces a
deduct version so this is what a log looks like this is where the
Json L Json lines comes in each each entry is a an array of Json
so uh an array.
<bruno_hivert_(he/him)_-_https://dtlab-labcn.org> You could use
the user/password @ feature of an URL
<manu_sporny> yes ^
<andrew_whitehead> @ is only allowed in the ID part if
percent-encoded
Stephen Curran: You uh 6 different values always exactly 6 um an
entry hash which is just a string it's a hash a version ID which
is a number starting with 1 and must increment by exactly 1 on
each version version time is determined by the um uh issuer the
controller of the did so it's whatever time they put but it is
verified to be incrementing and before now so you can't publish
what you did in the future and all of the versions have to be
incrementing.
Stephen Curran: Um parameters we're going to talk about
parameters you've got the did Doc itself in this as an entry and
finally there's data Integrity proofs on this um generally 1 but
but depending on the security features you're using could be
multiple.
Stephen Curran: Um so that is what it looks like I'm going to
briefly show 1 of of what it looks like but I'll get into more uh
I'll repeat this slide a little later so you've got your entry
hash you've got your version your time the parameters this is a
very very simple the doc which only has the ID field in it so
it's very simple and then finally you've got it and data
Integrity proof.
Stephen Curran: So that's what a each log entry looks like um
Json lines is as I mentioned um.
Stephen Curran: Um lines where a car uh a carriage return um is
between each 1 so it makes it nice for building at logs it turned
out that um the Andrew and Brian came up with this um design and
discovered that Json lines was a thing um Sam Sam Curran pointed
out that Json lines was a thing hence where we got to using the
term Json lines in that evidently it's very commonly used at
Amazon and other places.
Stephen Curran: Okay the parameters item is the most unique
thing on that list I think everything else in that array is
recognized the parameters is what allows you to control how the
generation of the did version is done and how the verification
can be done so it's a Json Str with information about how to
process the log um it's got configuration setting and what
version of the spec are you using what hashing algorithm are you
using what cryptography um algorithm are you using so um these
items are to enable long lasting um uses of the keys of of a did
and the keys within a did so their opinionated for
interoperability um the spec contains which hashing algorithms
are are permitted to be used.
Stephen Curran: Um cryptographic algorithms are permitted to be
used um but they're agile to enable long-lasting and the whole
idea there is a new version of a spec enables different hashing
algorithms to be used in different cryptography and you can
specify at any point in any version Oh I'm switching to version
2.0 of the spec so that allow that notifies the verifiers but it
also constrains the in the um choices that the.
Stephen Curran: In which hashing algorithms they're allowed to
use which cryptography they're allowed to use so this balance
between opinionated for interoperability and agile for
long-lasting DS.
Stephen Curran: Um there is a an entry that contains the
authorized keys to update the data and I've got a slide later
about that um the authorized keys to update the data do not come
from the didck itself but rather are um declared in the
parameters item.
Stephen Curran: Um there's data to manage additional features so
there's some Advanced features and and the parameters can be
empty for some did versions meaning hey the parameters that used
to apply they continue to apply I'm not changing any of them so
just keep processing it using those parameters so a verifier has
to track you know which parameters are in effect at what time
when they're processing.
Stephen Curran: Of the dependencies this is the dependency list
um Json lines um base 32 encoding we're using base 32 because of
um the desire to use the um hashing algorithm.
Stephen Curran: Um the hash I mean in the skid and therefore in
the did and in the http.
Stephen Curran: Um we're using Shaw 3256 right now we're using
Json patch as to transition from 1 did Doc to the next so the
idea is the first record will have the entire did Doc in it
subsequent can either have the entire did Doc or can have a Json
patch which is just the um previous the patch to the previous
version to create the new version um we've got an issue been
posted to say hey maybe we should drop that so we're still
debating that.
Stephen Curran: Um multi key is used to tell which type of key
is being used in particular in the um authorized Keys list.
Stephen Curran: What is the format of the key so that again
speaks to that what cryptography Suites are we allowing to be
used and then for a particular entry which which um.
Stephen Curran: Which algorithm is being used for a given key.
Stephen Curran: Um we've got Json canonicalization scheme used
um again there's another issue or at least comments on an issue
about using something less than that something simpler um and w3c
data Integrity using JCS and eddsa so that's the um data
Integrity proof format um that is in Spec of uh the current
version of the spec uses did key for the key reference there is
an an issue raised again about maybe we should be using jws for
this so um those are the type of discussions that are happening
right now as far as the um.
Stephen Curran: Uh the spec.
Stephen Curran: Um a bit more on the mechanics I'm not going to
take long on this um I'll try to be quick because this gets into
the technical details but for those that are um have a a
technical belt of how we do things um I'll cover the skid
generation how an entry hash gets created and what is involved in
the data Integrity proof for signing and verifying.
Stephen Curran: Um so a skid selfish uh self-certifying
identifier is generated on creation of the did itself so it is
done when the first log entry is created and the way you do that
is you construct the first log entry.
Stephen Curran: Um minus the proof so the data Integrity proof
will be added later so we don't include that in this and then we
have special whole uh placeholder the literal string curly brace
s c i d in capitals and then a closed curly brace that literal
string is put wherever the skid will eventually be placed so um
first of all it's going to appear here in the um in the first and
I'll talk about why it appears here in the first entry.
Stephen Curran: Parameters at least um at least once and it is
guaranteed to appear at least once in the did doc because it has
to be in the ID value of the did dog so we're going to have
multiple places where this curly brace skid curly brace appears
so we we start with that and then we do this calculation we take
the input with the placeholders we use um Java or Json
canonicalization scheme.
Stephen Curran: We have the output of that we base 32 that we
lowercase it because we want to use it in in the um did string
and the HTTP string and finally we take the first at least 28 um
characters of that and that becomes the skit so that calculation
is done out once when we're first creating it.
Stephen Curran: After you create the version the the scheme the
parameters and the did do you calculate the skid and then you do
a simple test text replacement of the skid for wherever you see
the placeholder and that gives us both the first entry.
<andrew_whitehead> That slide should say something like {"value":
{...<DIDDoc>...}}
Stephen Curran: And for most of the first entry and gives us our
skid that we're going to use from now on for this identifier.
Stephen Curran: Next we have um the calculation of the entry
hash so on every the first value in every line is the entry hash.
Stephen Curran: So again this time we start with an input log
minus um the data Integrity proof we haven't added that but we we
do have the skid if it's the very first 1.
Stephen Curran: Um this 1's the second 1 so um the skid isn't
there um so we have a value here of of an input entry hash we
have and then the rest of the parameters here's the Syntax for
what the patch looks like so in the previous 1 we had value
equals did Doc and this 1 we've got patch people's dish do did do
and that's how you can tell whether um you've got the folded dock
in this value or you just have the patch.
Stephen Curran: Okay so um we want to change these all together
we want to create a micro Ledger we want to create a a linkage
between a previous entry of the of the log and the current 1 and
that um prevent is that sort of goal of immutable if you will if
I can use that term from a micro Ledger perspective um it's not
as immutable as what published on a ledger and.
Stephen Curran: With all of the the you know the consensus
algorithm and so on but it is the micro Ledger equivalent so in
the very first version we initially set the value to the skid.
Stephen Curran: All other versions We put we set this entry hash
to the previous entry hash so that is what creates the linkage
we.
Stephen Curran: Ulate the entry hash based on the previous value
leading into it.
Stephen Curran: We then do a calculation much like we did
previously we JCS that input we hash it we base 32 we lower it
and we get a calculated entry hash and then we simply take that
value and we play replace it with uh.
Stephen Curran: Replace what was their previously with this
calculated value and now we have our entry hash.
Stephen Curran: So that's the second calculation we do.
Stephen Curran: Um adding a proof.
Stephen Curran: The data Integrity proof is across the did do so
you take the current did do.
Stephen Curran: You use the entry hash as a challenge and it's
got to be signed by an authorized key and I haven't shown the
authorized key but I'll show you that in a moment I took that out
of the slides but it's there in a moment.
Stephen Curran: Um so once I we have the data Integrity proof we
add that as the last entry of the log so that's Sixth and last
entry.
Stephen Curran: And finally we append that new log entry as Json
line so we take that array we remove all the um unneeded white
space and that becomes the um New log entry with Carriage turn in
it so we append that um to whatever we previously have as the log
and we.
Stephen Curran: Publish that or republish it as they as the did
jsonl file so that's how we get there.
Stephen Curran: Um I threw this in at the last minute just to
remind her a verification is any time I've said I've I've talked
about how you get your data Integrity proof how you get the skid
how you get the entry hash the the the the version must be
incrementing that the time must be incrementing all of those are
the things that are done on verification you grab it and you do
all of those operations that were used to produce the log to
verify the log.
Stephen Curran: So back to this screen so again we've got our
entry hash we've gone over how we got that um this is a number
that increments has to increment by 1 this is the um time um
again controller asserted um but we do verify that it is
incrementing and before now.
Stephen Curran: These are the this item in blue is the
parameters so we've got oh we're using version 1 of the did TDW
spec so that's our method the hash algorithm we're using is Shaw
3256 the skid is this and the skid appears here in the parameters
so that we don't have to parse and look for it we just know what
it is based on the parameters this will only appear in the very
first item in the log.
Stephen Curran: And then we've got an array that are the update
keys in um multi-key format and these are the keys that are
permitted to update um to sign the data Integrity proof.
Stephen Curran: Um so when we rotate it it's basically or or key
rotate the uh.
Stephen Curran: Keys what we're doing is updating this parameter
we're putting a new array in here of new keys that would update
it.
Stephen Curran: Um we have the did itself here we've got value
equals so this is the entire did document we could have patch
here and this would be Json patch.
Stephen Curran: And then finally we're using uh data Integrity
proof we're using the E ecdsa JCS 2019.
Stephen Curran: That's currently the 1 that's specified um
supported and did TDW um spec version 1.
Stephen Curran: The verification method is the did key pointing
to this 1.
Stephen Curran: And and so on um I think I've got this elsewhere
but just to point out.
Stephen Curran: In the very first version this is version 1 um
update Keys is added from then on the data Integrity proof must
be signed by the.
Stephen Curran: Active up-to-date Keys um that are in place.
Stephen Curran: And that's it for the basics.
Stephen Curran: So I'll leave a second open for any questions
man.
Manu Sporny: Yeah this this is fantastic Stephen so I I was able
to look through the slide deck before the presentation your um
explanation of it uh matches um what I was thinking uh was going
on here so so it's it's great um I I I definitely agree um with
the notion that you know just standard did web probably needs
some and or if not all of this stuff um uh for some some of the
higher security use cases um I'm wondering if uh there's been a
lot of discussion or any discussion about kind of the optionality
here meaning like you know if if it were you know if did web were
to pull in some of these features or if we I not my personal
opinion is ideally merged the specifications um what what are the
thoughts around optionality meaning like some folks may just want
to use um.
Manu Sporny: Some of the features not all of them um have you
have you discussed kind of optionality and what can be optional
and what's a definitely not optional thing yet.
Stephen Curran: Yes um so the spec outlines what optional and
what's um required um.
Stephen Curran: 2 2 Or 3 of the main features uh first of all
the I'll get back into it a little bit more because I've got
further slides to go after this this is the the slide about
publishing it did web is is you could actually publish the 2
beside each other and it's it's a very simple text replacement
literal text replacement of did TDW for did Webb and then
inserting a also known as for the did TDW did.
Stephen Curran: And and then you just publish the file so it's
very simple to use to actually produce it did web from this and
let it be known oh by the way there's a log for this did if you
want to use it um and you want to verify every part of this so
that's probably the quickest answer um but uh there it's very
clear which option or which items are are optional and which are
required.
Kimberly Linson: Great thank you Dimitri you're next.
Dmitri Zagidulin: Yeah just wanted to say uh.
Dmitri Zagidulin: Stephen and the rest of the team uh this is
really excellent work and just for context to everybody else uh
at about the same time I was also working on a similar spec uh
that you use a slightly different history format uh but added uh
very similar features but once uh once I found out about did DW I
discarded my spec and I'm all in on this 1 and I wanted to um.
<manu_sporny> Oh man, love the "idenity" and "deceltiralized"
Dmitri Zagidulin: About um the upgrade path from did web to did
TDW uh but you've you've answered it uh with the also known as
and and I think that's that's sufficient I think that's an easy
way.
Dmitri Zagidulin: Uh for existing did webs to add the history
log and the verifiability.
Dmitri Zagidulin: Um provided that the resolvers are smart
enough to understand the additional richness so just wanted to
say.
Kimberly Linson: All right thank you uh Marcos.
Markus Sabadello: Um yes I also agree this is really a great
work thanks for the presentation I I have a question about the
slash who is feature um I I wonder how that relates to the linked
verifiable presentations work which is also in the in the
specification um maybe I can talk about it.
Stephen Curran: Yeah I've got I've got slides on that so I've
got a few more slides these won't take long they're more
introductory so people are aware of additional capabilities with
this and so I'll hit on the did who is at that.
Kimberly Linson: Okay great and uh Patrick.
Patrick St-Louis: Yeah just another quick question about the
upgrade pad so let's say there's an organization they have a did
web already they have use case and they need to preserve their
did web is there a path forward for them to add up to W because I
know the TDW uh introduced the concept of the skid which might
not be present and existing did well so is there a way for an
entity to preserve a did web that doesn't have a skid and tag on
maybe a new TDW and create a link between these 2.
Stephen Curran: Well um we can definitely look at that um and
that is the way you worded that is actually a really interesting
way which is the transition from an existing um we can um we've
thought about a few things with but always from that other
perspective of starting with and publishing as it did web but
what you're talking about is slightly different I like it and
we'd have to think about it a bit.
Patrick St-Louis: Well maybe like could this kid become more
something that happens outside of the did itself like when you
have a TDW you get this kid in another way than having it
hard-coded in the path it becomes something you fetch at a
specific place or.
Stephen Curran: Um could be I don't know that's what I mean is
that we haven't really gone through that but boy you should help
us out with that.
<andrew_whitehead> The SCID must be in the DID itself to enforce
the integrity
Stephen Curran: Okay let me get to a few more things.
Stephen Curran: And I see that that's the end of the.
Kimberly Linson: Yeah go ahead.
Stephen Curran: The queue so um I'll get you a few more things
yeah so um just it did so the whole thing we started with um was
this thing is just a did um it can be used wherever it did can be
used the content is completely unconstrained the only thing is
it's got to have an ID in it which I'm pretty sure is the did
chorus back requirement that it's got to have the ID in it um
discoverable from the identifiers resolved from https um
verifiable portable by changing the location of the did so the
HTTP address the DNS you know server and path and subdomain
whatever you want but retaining the skid and the log so
portability is there so this idea um of of of of of being able to
for instance be on Blue Sky for a while and then switch to
another 1 but retain the same did so that.
Stephen Curran: Verify that it's truly the same person that was
on blue sky before the same identity that was on blue sky before
is now on some other 1 but they've changed their location um more
secure and then did web and and arguably our premise more useful
and agile than uh EXO x509 keys so just it did.
Stephen Curran: Man yeah isn't that classic I didn't even notice
the identity decentralized on that picture until after I showed
it to somebody else but yeah it's pretty brilliant.
Stephen Curran: Um challenges uh I did want to put off um we we
have had a number of conversations with the log file getting
large depending on the use case um we've done uh or Brian and
Andrew have done testing of their implementations and it and it
does um.
Stephen Curran: Fairly quickly um so we think that can be
handled compression is good 70% compression on all the cases
we've done so far with gzip and um there is a TTL parameter as a
hint to the controller about how long they want to Cache um so
that they can cache and then just continue on with the processing
um you do have this trade-off with did web of a call home to
retrieve the log but also the domain name giving the hint who
controls it um portability I did say oh yeah that's awesome it
can be portable and that is good because your reputation um done
through the verification is there but if you move it without a
redirect it gets a little tricky because um you have issues so
we've got witnesses and Watchers um that are possible and I'll
talk about those in a bit.
Stephen Curran: And then the self asserted um nature of version
time um so those are the challenges we see um and we think we're
pretty happy with um with those um I mentioned this um how to
publish in parallel with the did web so you can have a did TDW
first and then publish a did Webb in parallel with it now um
Patrick's question gave me thinking of how do we do the reverse
how do we have it did web that does not have a skid in it and add
it and that is tricky so we haven't thought enough about that yet
um but that's that's um the type of question we want to get get
out.
Stephen Curran: Um verifier beware you lose the verifiability
and the provenance if you use just the did web and so we have
we've had much internal discussion about promoting this
capability we included in the spec is how to do it but we don't
automatically do it as part of the um publishing.
<kimhd> I love this work. At the same time, I marvel that 2024
SSI we are working so hard to replicate things that were easy on
blockchains (in 2016 SSI)
<manu_sporny> yes, agree ^ :)
<dmitri_zagidulin> @kimhd - ah yes, but WHICH blockchain :)
<manu_sporny> (but this work is necessary given "public opinion"
on blockchains)
Stephen Curran: Um we had a number of debates about how to
authorize and in fact the first version of authorized used did
Doc keys keys within the did Doc um as the thing that had to
authorize the update had to sign the data Integrity proof on the
the versions um we got rid of that and put it into the parameters
because it was just much cleaner to implement and and because
there's not a clear um statement in the SPAC we didn't find about
exactly what key what reference key should be used um for this
type of authentication for controlling the update so we we didn't
do that so the the did Doc Keys you could put the same um keys
that you're using to control the uh to authorize the updates into
the dock or you may keep them separate and use different ones um.
Stephen Curran: Is is kind of an interesting question.
<dmitri_zagidulin> one could argue that the 'controller''s
assertionMethod keys are the ones who are authorized to update
<manu_sporny> agree ^
<kimhd> yes, people throwing out bebe with bathwater. Times will
change
Stephen Curran: Um these are the rules I went over this earlier
the first log I think I did first log entry must have an update
keys in it and the proof on the first log entries must be signed
by those update keys in all subsequent log entries they must be
signed by the keys active from previous from the previous entries
um so the second 1 would also be updated by the update keys but
if you include a new if you rotate the update keys in the second
1 the third 1 would be would be signed by that and so on it gets
confusing to talk about those things um update Keys is an array
and all our authorized um blue sky has a a number of interesting
things about how they use the multiple authorized keys to manage
the did 1 use is to um restore uh ah ah d control over it did
when the um the did owner actually loses their keys and so that's
something that I.
Stephen Curran: Service might.
Stephen Curran: In in publishing them.
Stephen Curran: Um did URL handling the pads and the who is so
um obviously it's ideal to have did and path to file convert to
http did to http and then path to file it's dead simple to do um
ledgers it's much trickier and you have to think about different
things with with.
Stephen Curran: Based it it's dead simple so we wanted to get
that in a way in we did it with service entries but we did it
with implicit service entries so even if you did Doc doesn't
include this the resolver should use um an explicit uh or a
implicit service to resolve those um the files 1 uses the
relative ref from the did core spec to set the location of files
and the who is uses diffs linked to VP specification and let me
talk a bit about that so the path to files is is is basically
trivial um.
Stephen Curran: We did.
Stephen Curran: We don't put the files in well known so if well
known is there it gets dropped from the HTTP path but in other in
all aspects you know the file is is relative to where the did
jsonl where the the domain is.
Stephen Curran: Um all sorts of uses for that and um and and
we're using it in a variety of ways of of what files can be
there.
Stephen Curran: Um the slash who is I think is really cool um
John came up with this so the slash who is returns a verifiable
presentation with the did as the credential subject in all the
embedded verifiable credentials so what does that mean.
Stephen Curran: Um you have a bunch of verifiable credentials.
Stephen Curran: That are issued with the data as the subject you
put them in an array as the controller whichever ones you want to
publish and then you sign that um using the did key um and
publish it as a a verifiable presentation.
<manu_sporny> I've always dreamed of a '/whodis' mechanism...
this is only off by one letter. :P
Stephen Curran: If I receive a VC do I trust the issuer all I
need to do is find out the did of the issuer and then do a issue
or did who is and I get a VP back and those VCS might be the
legal entity might be a industry specific authorization might say
oh I'm a member of a trust registry.
Stephen Curran: And then I can decide do I trust those issuers
and it if I don't know who those issuers are I recursively do
that and as a result I can do a series of HTTP requests and I can
do an entire pass of do I trust the issue or or not.
<anil_john_[us/dhs/svip]> I love this /whois feature! Of course
John came up with it! :-)
Stephen Curran: And and eventually I could even pass that to a
human to make the decision so I did a paper way back in 2018 and
and this I'm I'm kind of always been trying to figure out how the
heck you would do this traversal in in a trivial way and this is
the first time I've seen it that that makes that really easy to
do um this.
Stephen Curran: Um linked VP is the spec that enables that um
and and we take advantage of it.
Stephen Curran: Um I've talked about portability before so
basically you change the the the web location but you retain the
skid and you retain the history and that allows a verifier to say
oh you know oh you really did change from Gmail to Yahoo and and
I can see that that old gmail um did you used to that used to be
held by the the the Google service is now held by the Yahoo and
it has the same province has the same history it truly is the
same controller.
<anil_john_[us/dhs/svip]> Glad to see that it plays well with HA
DIDs w/ DNS!
Manu Sporny: +1 To HA DIDs w/ DNS!
Stephen Curran: Um a couple of advanced features that I'm
running out of time but I really want to hit um hi asuransi did
with DNS this there's a spec um that a number of of folks in the
community have done um its goal is a 2-way linkage between did
Webb dids and DNS and basically in the DNS you have entries that
point to the did web and the key used to update it and entries in
the did Webb did Doc um to the DNS uh that that is that it's
bound to and so you basically get sort of a 2-factor
authentication between DNS and DS this exact same approach
applies to did TDW there's no reason um that these 2 do not work
perfectly well together for that so I highlight that use and and
there.
Stephen Curran: There's a bunch of features in the TDW that are
inspired by KERI and the work being done there um obviously they
identifier the skid and the event log the self-certifying
identifier all of those are are carry features the event log.
Stephen Curran: That's what key event um means in in KERI so
those 3 things are there and I've covered those pretty um
thoroughly but pre- rotation and Witnesses are also there.
<manu_sporny> ^ lol -- yesss to "decentralized whois" -> "whodis"
:)
Stephen Curran: Simply means committing to a key without
exposing it.
Stephen Curran: Um the reason this is a good idea is if an
active key is compromised um did control can be lost if the.
Stephen Curran: Attacker that is compromised the key is able to
rotate to a new key that they control and so the.
Stephen Curran: Original controller can lose can lose that um.
Dmitri Zagidulin: +1 To making pre-rotation a general DID Core
2.0 feature
Stephen Curran: In in there's quite a discussion about this in 1
of the issues but the idea is they would have to both lose
control of the dead and the did serve or and the web server so
they'd have to lose the key and the web server for this um but um
it is possible and you want to prevent it so the idea is we have
a a.
<manu_sporny> yes, agree w/ "lose key and server" being a pretty
high bar for successful attack... might matter more when you
change domains?
Stephen Curran: In a whenever we have uh we can use optional use
um pre- rotation and every time you have update Keys you have
next key hashes those are hashes of the um update keys and then
to rotate you have to go to the pre you must use a pre- rotated
key 1 that you've committed to in a prior version of the did Doc
so this allows um.
Stephen Curran: Much safer use of uh of keys and control over
those keys um suggested practical use is in the implementers
guide this is only done for the updated keys and did and did TDW
we think there should be a did core feature support pre- rotation
of did do Keys um but we didn't Implement that and so that's not
there.
Stephen Curran: Uh certainly a possibility but it's not there.
Stephen Curran: And then.
<manu_sporny> Yeah, pre-rotation in DID Core seems to be gaining
momentum for standardization in v2.0
Stephen Curran: The final feature is Carrie has um Concepts
called um Witnesses Watchers judges juries and so on um Watchers
are all external parties that monitor uh uh and identifiers and
make sure that the owner doesn't do anything um.
Stephen Curran: Inappropriate with their did um so they're not
malicious um that could be anybody so this is not included in the
spec um but anyone can do it if they want to um because there is
only 1 location where the did exists um.
Stephen Curran: But a witness is.
Markus Sabadello: +1 To figuring out which features could be
standardized in a method-independent way, e.g. key pre-rotation,
cache ttl, etc.
<manu_sporny> witnesses can be supported via the parallel
signatures / chained signatures w/ Data Integrity.
Stephen Curran: Um actually a party that approves updates before
publication and so we've got a mechanism included in the spec
that defines how Witnesses which are um parties to the update of
a did um carry out that and basically the idea is a controller
constructs an entry passes it to a witness each witness would
then both verify and approve um whatever approved means in the
ecosystem um the the governance and then generate a date
Integrity proof that would get appended to the data Integrity
proof who would he add it to the array of data Integrity proofs
on the log so that's the witness mechanism.
<bruno_hivert_(he/him)_-_https://dtlab-labcn.org> And witness can
be automated
Stephen Curran: Um last slide sorry I've taken so long um we are
starting to push uh and getting this into a working group and
task force um love to have any help contact me if you're
interested I'm especially interested in somebody that is spec the
spec World Savvy because I am not I I like to build these things
I just don't know how to um do a good job at at figuring out um.
Stephen Curran: How to get it through the step process so if
anyone would be willing to help out with that I'd love to talk um
bcgov hosts the specifications currently and a typescript
implementation and a python implementation so all are there with
these links um we are going to move it to incubation um
originally talked about trust over IP although we're not 100% on
that so possibly different w3c might be um good locations for
that glad to get guidance from those in the community on that.
Stephen Curran: Apologies for taking so long and I saw Kim had
to leave and so with that I'll stop sharing and turn it back over
to the hosts if they're still here.
Harrison_Tang: Yes um any last questions from the audience.
Harrison_Tang: Money please yeah.
Manu Sporny: What would be the best sorry what what would be the
best Forum to kind of coordinate on this Stephen like um would
you like public mailing list or GitHub issues tend to kind of
bury the conversation it feels like this is fantastic work and I
think um it it it it needs to happen right and so what what's the
best venue what would you prefer uh where would you prefer the
discussion happen on kind of next steps.
<pl/t3> Sounds like a CCG WG ;-)
Stephen Curran: Uh I I would like to get it into a working group
as soon as possible and I'm just trying to figure out where that
working group would be and so I'll love to have guidance from
anyone who knows the best place to do that given this is what
we're trying to accomplish so um I am open to that and then
immediately get into um regular conversations um.
Stephen Curran: To discuss and evolve get this input like I've
heard today.
Harrison_Tang: Any recommendations in regards to which group to
join I saw in the comments ccg can be 1 of 1 of the groups so the
so Stephen if you uh if you are interested maybe we can uh
reconnect upline.
<andrew_whitehead> Most discussion is in the Github issues at the
moment: https://github.com/bcgov/trustdidweb/issues
Stephen Curran: Yeah sorry about that.
Harrison_Tang: All right any last questions I know we're a little
bit over time but still a lot of people are online yeah no no
worries great.
Harrison_Tang: All right I don't see any other questions um so uh
thank you thank you Stephen uh for actually a great presentation
today it's very very well attended and a lot of great discussion
so thanks a lot and then I will connect with you offline in
regards to whether you would like to uh you know continue this
discussion and work items in in the ccg context.
Stephen Curran: Excellent thank you so much.
Harrison_Tang: Great this thanks a lot uh this concludes this
week's cjd meeting thanks for attending.
Received on Wednesday, 10 July 2024 16:20:46 UTC