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: 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. ✪
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: 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. ✪
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: 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. ✪
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. ✪
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: 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: 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: 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: 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: 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: 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: 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: 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: 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. ✪
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. ✪
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. ✪
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: 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 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!
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. ✪
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. ✪
<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. ✪
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. ✪
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. ✪
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. ✪
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. ✪