- From: CCG Minutes Bot <minutes@w3c-ccg.org>
- Date: Wed, 23 Oct 2024 05:50:38 +0000
- To: public-credentials@w3.org
Thanks to Our Robot Overlords and Our Robot Overlords and Our Robot Overlords and Our Robot Overlords for scribing this week! The transcript for the call is now available here: https://w3c-ccg.github.io/meetings/2024-10-22/ 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-10-22/audio.ogg A video recording is also available at: https://meet.w3c-ccg.org/archives/w3c-ccg-weekly-2024-10-22.mp4 ---------------------------------------------------------------- W3C CCG Weekly Teleconference Transcript for 2024-10-22 Agenda: https://www.w3.org/Search/Mail/Public/advanced_search?hdr-1-name=subject&hdr-1-query=%5BAGENDA&period_month=Oct&period_year=2024&index-grp=Public__FULL&index-type=t&type-index=public-credentials&resultsperpage=20&sortby=date Organizer: Harrison Tang, Kimberly Linson, Will Abramson Scribe: Our Robot Overlords and Our Robot Overlords and Our Robot Overlords and Our Robot Overlords Present: Harrison Tang, Joe Andrieu, James Chartrand, Christopher Allen, Wolf McNally, Will Abramson, TallTed // Ted Thibodeau (he/him) (OpenLinkSw.com), Rashmi Siravara, CC, Gregory Natran, Erica Connell, Stephan Baur, Vanessa, Jeff O - HumanOS, Jennie M, Leo, Hiroyuki Sano, Japan, Savita Farooqui, Alex H, Nis Jespersen , Manu Sporny Our Robot Overlords are scribing. Harrison_Tang: Welcome everyone and welcome to this week's w3c ccgb uh today we're very excited to have Christopher Allen uh here to present on Guardian envelope ivian and controller documents I think about a little bit more than a year ago we have uh Christopher here to talk about Gordon envelope and really look forward to seeing updates and new developments to this initiative. Harrison_Tang: Want to quickly go over the administrative stuff um first of all just a quick reminder on the call the benefits and professional conduct just want to make sure everyone uh holds respectful and constructive conversations. Harrison_Tang: Uh the second just a quick note on the intellectual property anyone can participate in these calls however also sensitive contributions to any ccg work items must be member of the ccg with full IP agreements signed so if you don't have the w3c account or have questions in regards to the account or the computer license agreement uh feel free to reach out to any of the cultures. Harrison_Tang: A quick note on these calls so these calls are automatically being recorded and transcribed uh and we will publish the um. Harrison_Tang: A video recording audio recording and the transcription in the next 1 or 2 days. Harrison_Tang: We are used GT chat to cue the speakers during a call so you can type in Q Plus to add yourself to the queue or cue minus to remove. Harrison_Tang: All right just want to take a quick moment for the introductions or uh reintroduction so if you're new to the community where you haven't been active and want to re-engage feel free to just uh unmute and uh introduce yourself a little bit. Harrison_Tang: I see actually all familiar faces so I'll skip to the next section uh. Harrison_Tang: a quick. Harrison_Tang: No on the announcements and reminders so any announcements or reminders. Harrison_Tang: Uh I I do have 1 so next week is the internet identity Workshop so we will not have a ccg meeting next Tuesday and I will send out the uh meeting reminder or cancellation reminder uh a week uh tomorrow right so again so we won't have. Harrison_Tang: A meeting next Tuesday and we will resume the Tuesday after that on November 5th and we will have Auto and Kim Duffy to talk about the if credential schemas. Harrison_Tang: Any other announcements or reminders. Harrison_Tang: Any updates on the work items. Harrison_Tang: So we have scheduled uh different um task force and uh work items uh leads to actually present here in the next few weeks uh and then we will also have a Q4 quarterly review and open Agenda and work item updates on November 19th so that's uh. Harrison_Tang: All right last calls for introductions announcements reminders or work items. Harrison_Tang: All right let's get to the main agenda so again I'm very glad to have Christopher here to talk about Guardian envelope inian and controller documents uh thanks to him uh he has sent out uh presentation deck already to the public list so um I well I actually seen a PDF not a link but uh you can just go find the email that I sent the agenda email that I sent and Christopher I have shared that via an email with a PDF attachment. Harrison_Tang: All right thanks Christopher I think the floor is yours. Christopher Allen: Thank you um let me introduce wolf McNally he's our lead engineer on this project and uh he has a a uh uh presentation that'll do a little recap and then talk specifically about the opportunities with controller documents uh wolf. Christopher Allen: I'm not hearing you off um you were. Harrison_Tang: I think there might be an audio issue because uh he was not muted. Christopher Allen: There we go yes we can. Wolf_McNally: How about now can you hear me now okay that will do all right uh okay very good uh so I'm trying to figure out how to share my screen in the system I should share video and that didn't work that shares a video file so is there a way to share the screen directly. Wolf_McNally: Oh I see it okay. Harrison_Tang: Yes it's the third button and by the way like uh because we run yeah by the way because we run this on the some someone's server so the if the presentation is too big or kick people out but it's fine just like re rejoin via the same link and then the session the recording everything will work as uh as expected. Wolf_McNally: Also said bandwidth that will turn off my video and share my screen here um. Wolf_McNally: We can do it to share. Wolf_McNally: Right so you should be seeing my slides right now. Wolf_McNally: Guardian envelope Elysian and controller documents does everybody see that. Wolf_McNally: Very good all right so I'll proceed um my name is Wolf McNelly I am the lead researcher uh for blockchain comments and uh Christopher Christopher and I have collaborated very closely for a number of years on various projects including the 1 and today here um. Wolf_McNally: So a little bit about blockchain Commons for those of you are a building not for profit social benefit Corporation. Wolf_McNally: In Wyoming but we operate worldwide and we're committed to open source and uh defense of patent strategy and anyone can use all of our tools it's all open source unencumbered. Wolf_McNally: And we have done quite a few projects over the years um a few of which are. Wolf_McNally: Briefly depicted here. Wolf_McNally: Um we rely on our sponsors uh our sustaining sponsors our GitHub sponsorship and uh individual donations that can be made and obviously uh the Sony's QR codes might go buy a bit fast obviously they'll be uh video of this later. Wolf_McNally: Obviously our our our homepage blockchain comments um is our portal to everything that I'm going to show you here thank our sponsors. Wolf_McNally: Um and we'd like to invite you to join the conversation of course I already showed our homepage here um but we also have discussion forums. Wolf_McNally: we have. Wolf_McNally: Low volume announcements mailing list. Wolf_McNally: we have. Wolf_McNally: A signal groups uh General and specific topics. Wolf_McNally: Uh we have our monthly Guardian developer meetings on the first Wednesday of every month. Wolf_McNally: And by joining our live Vol announcements list all those you'll receive all this announcements and we have a special uh meetings for special interest groups like our Frost implementers group and our bill account salon for Hardware developers and more. Wolf_McNally: So um we did send out uh a set of links and so on but I want to do a quick recap so that we're all kind of up to speed on the technologies that I'll be talking about. Wolf_McNally: So our intro materials uh include videos and of course I'll be talking about Guardian envelope a lot today so uh we have an envelope playlist on YouTube youtube.com blockchain Commons and then just going to be uh go to the uh uh Guardian envelope playlist and that starts out with a teaser which is just basically uh a minute long kind of commercial which is just kind of hit some bullet items very very fast and very visual. Wolf_McNally: and then we have. Wolf_McNally: Much more in depth 2-part series uh understanding Guardian envelope Parts 1 and 2 where. Wolf_McNally: Walk through all the design principles and implementation according envelope and give a number of examples so I seem to be going fast here today um the the YouTube videos are kind of uh essential watching uh to get all the details. Wolf_McNally: And of course we have our websites including our our uh main portal for envelope developer blockchain comments.com. Wolf_McNally: So um envelope itself is a smart document system built on determining a 64 and now some of you probably heard of core the common uh the uh concise binary object representation which is you can think of as like. Wolf_McNally: binary Json. Wolf_McNally: We have a variant of it that's an IT internet draft called dcore which focuses on determinism um and I'm sure most of you know what that is but that is that the same semantics semantics always encoded the same binary stream which gives you the same hashes when it comes time to sign and so we wanted to build that into our system at the very lowest levels. Wolf_McNally: So DC4 is binary concise self-describing good for iot and constrained environments and this platform and language agnostic and there are tons of implementations and you don't need uh our DC Board of notation to implement core it just makes it a lot easier. Wolf_McNally: It's deterministic at the binary level up. Wolf_McNally: Which for example means there's like 1 way to encode each numeric value unlike Json there's no 0 minus 0 0. Wolf_McNally: Strings always uh are normalized to you uh unicorn normalization form C. Wolf_McNally: M map or dictionary keys or automatically sorted no context required to sort. Wolf_McNally: and you. Wolf_McNally: Need to connect. Wolf_McNally: Canonicalize as a separate step. Wolf_McNally: Guardian envelope itself is built on top of dcore and it has a particular semantic structure that is based on semantic triples which uh the uh you know the semantic web kind of pioneered rdf and things like that um we use uh symmetric triples are subject predicate object. Wolf_McNally: And in what we call envelope notation this is not Json this. Wolf_McNally: Not um Ski war uh. Wolf_McNally: Diagnostic notation this is our own notation we call uh envelope notation but there's a sub a subject and then zero or more particular object pairs which are called assertions accurate. Wolf_McNally: That's important to note for this audience particularly this is not the particularly typically the meaning of the subject used in the verifiable credentials domain which is a person or organization about which plans are made. Wolf_McNally: In some cases it can be so uh and you'll understand why in a minute that um that this isn't just a system for creating verifiable credentials or whatever this is basically a much more General system and we use the term subject between that 1 particular thing about which assertions are made which aren't necessarily credentials. Wolf_McNally: Envelope itself is structured as a number it's a it's an enumerated type and everything about show you all these cases are themselves valid envelopes standing entirely by themselves. Wolf_McNally: Um there's 5 basic cases specified in our internet draft for envelope. Wolf_McNally: Are leaf and this is any any DC board data at all is a leaf um so it's you know it's very expressive in terms of that just generality. Wolf_McNally: then there's. Wolf_McNally: The node which pairs a subject with 1 or more assertions. Wolf_McNally: Assertions which are predicate object pair. Wolf_McNally: and again. Wolf_McNally: Predicates and objects and I'll I'll repeat this a couple times are themselves envelopes so um and they form a tree structure. Wolf_McNally: Um then there's the lighted node which is basically a hash that's left in place with a whole branch of the tree has been removed um so in this preserves the hash tree. Wolf_McNally: And wrapped and wrapped is basically a way that you can make assertions or meta assertions about the uh wrapped Envelope as a whole and you'll see why that's important. Wolf_McNally: And then we have 3 extension cases which are defined uh in separate documents but in a reference implementation are all fully implemented. Wolf_McNally: and they are. Wolf_McNally: Uh and uh this is basically encrypts the entire branch of the tree. Wolf_McNally: And also records its hash as a uh. Wolf_McNally: As authenticated data so it can't be tampered with. Wolf_McNally: Value and this is a way of basically taking uh for example uh rdf and like often use long URLs that are often repeated and there's ways of duplicating that we also have known values which are essentially small integers which are mapped to uh onset of various kinds which could include the things you're used to seeing in URLs but they're much more compact. Wolf_McNally: And compressed and we use the the deflate algorithm so for large binary objects inside of trees and so on where you might want to compress the whole branch of the tree you can't you can do that. Wolf_McNally: These 8 cases are essentially what caused you envelopes and I want to emphasize its envelopes all the way down you can have envelopes since I have envelopes and stuff envelopes and so structure that looks like a tree. Wolf_McNally: Um and uh. Wolf_McNally: Again I want to emphasize that every node in an envelope tree is itself an envelope. Wolf_McNally: So for example you see the node and assertion cases the node the top very top level has um at the very top a subject and then 1 or more assertions as you just see 1 subject here which is a leaf and then 2 assessments have a predicate and object the first predicate object pair that's a known value and a leaf and the second you can see the predicate that's a leaf as well. Wolf_McNally: But any child node without assertions can be replaced by a node with assertions and this includes even predicates so you can make assertions on predicates you can make assertions on objects you can make assertions on assertions so even a complete assertion can become the subject of a node. Wolf_McNally: It's very flexible you can basically have as many levels of Rich metadata as you wish. Wolf_McNally: Um and every node in the tree has you digest these digests are mostly mostly not serialized with the um envelope itself but calculated when being read in um there are a few cases um which preserve the top level digest their transformations of the tree um and they do record their assertions and those are Elysian encryption and compression and so basically when you replace a branch of the tree with any of these you actually preserve the diet history all the way back to the top 3. Wolf_McNally: And this allows for you know very powerful features particularly holder based delusion which we'll be talking about in a minute. Wolf_McNally: So Elysian is in fact a game changer or things like controller documents and other documents that might have sensitive parts because you can uh you only have to transmit the data that you want. Wolf_McNally: And signatures are preserved as long as the digest tree remains uh maintains proof of the elided data. Wolf_McNally: Um and then after you like data inclusion proofs can allow you to reveal parts of the document later in a verifiable way. Wolf_McNally: So I want to give example. Wolf_McNally: So this is envelope notation of uh of a driver's license it has as its subject uh they're the uh e281 uh 1 029 which is the driver's license number which is the subject of the envelope um and then uh a type declaration is a driver's license the number of other fields you're familiar with those little symbols to the left of those those are called life hash those are essentially a visual hashing algorithm that we uh developed and uh you can find out more about that at life of visualizing a shock 256 hash at a glance and the point of showing you the these here is that every single 1 of these um arms of the tree and in this case we're pointing at the assertions not the predicates and objects specifically but the subject of the envelope um and its assertions all have unique hashes also at the top level you see the envelope has curly braces around it and then has another assertion on that that's a wrap envelope and that's the purpose of of wrap envelope is to make meta assertions about the content of the entire envelope itself in this case it's a signature. Wolf_McNally: Um and you can see what is being signed is itself that top level um uh wrapped envelope. Wolf_McNally: So that is what this is signed by the signature and this basically opens up a whole variety of possibilities. Wolf_McNally: Now in a practical circumstance you'll want to add salt and this is basically used to decorate certain things like the word John is very guessable um as well as dough and obscure dates and so on so you see all the fields here that would normally have uh it would be rather guestable have a few bites of salt added and this is just an insertion on the object of the uh of the assertion so you know again uh sometimes it's going to be a little bit recursive in terms of how I speak about these things um but you notice that that also has changed the top level digest and hence the signature for Signature systems like ed25519 where the signature is terministic. Wolf_McNally: Systems like Shore where there's salt where there's basically a non Sage to the signature but uh you would expect in this case that the the top level hash would change and therefore the signature would be unique based on that so and the purpose of salting things just so when you Allied things um the the the the hash left in place is not correlated with the actual data validated so I'm going to just for brevity um not show the salt for the moment. Wolf_McNally: But I want to show you what illusion looks like so for example if I had the full document if I was the holder of this document and it was asked to prove my date of birth from my photo I can essentially Allied everything that uh was unnecessary to do that in this case of a lighted my driver's license number uh and all the assertions that had to do with that now I've left the elided no nodes in place there's 5 of them in the internal uh insertions uh assertions and 1 at the top level um and this basically gives me everything I need just including my photograph which is biometric information uh to prove the to prove my claim. Wolf_McNally: And the signature itself is still valid because the lighted uh nodes allow the same hash to be calculated and propagate upwards to the the tree. Wolf_McNally: So if somebody then later asks me now prove where you live um and they already have the live version of the document I don't need to provide everything um in the document again I don't need to provide a new version of the document in fact I only need to reveal 1 assignment. Wolf_McNally: Um and again this has been signed by a verifier of some kind the driver's license issuing authority so um you know their signature is you know we need to have that remain intact every step and by and Progressive trust uh allows us to as we trust. Wolf_McNally: People who want to verify information about us reveal things and as I said you don't need to reveal the whole envelope in fact in many cases all you need to reveal like in this case is an assertion this is called an inclusion proof and I'll show you another inclusion proof later which is a little bit more um complex but sometimes an inclusion proof can be as simple as this because the hash especially assaulted um assertion like this these globally unique there's only 1 thing that can possibly fit in the allotted tree at that point and that is this assertion nothing else can fit. Wolf_McNally: So we've extended Gordon envelope in a number of ways including what we call the gordian seal transaction protocol and again this is part of our recap I just want to point this out we talked about this extensively in our videos but it's a peer-to-peer request response to style exchange designed for a variety of environments uh that could be unreliable or insecure and it basically provides our layer of security for things like the internet and Bluetooth and NFC and tour and even lowly QR codes which we have uh a technology uh which we allow us to create animated QR codes including any amount of data. Wolf_McNally: In a QR code not a series of non repeating Fountain codes. Wolf_McNally: So uh the idea is you can use the same uh request response protocol over all these things. Wolf_McNally: What does that look like as an envelope. Wolf_McNally: Answer a slide last moment so this is allows us to do things like establish key agreement exchange data between uh peers or clients and servers facilitate confidential backups and Co coordinate multi successions and things like that. Wolf_McNally: Um and also this is without local state and I want to emphasize that because that's the main reason why I want to remind you guys of of uh what gstp is and how it works because this takes advantage of a lot of the the um. Wolf_McNally: The built-in features of envelope so for example this is a request for you know a generic request with a body there's a function identifier here and a set of arguments the uh the envelope itself the request includes the sender public key. Wolf_McNally: Signature by the sender as well so you can use this as an introducer packet where nobody has ever seen this key before but they can verify that the sender has the private key that created this packet. Wolf_McNally: Do that we can add what's called encrypted State continuations and this is where we offload state from whoever is sending into the future essentially so the uh sender continuation you see here is an encrypted message that is Ari encrypted that's the has recipient seal message back to myself if I'm the sender. Wolf_McNally: And so the receiver um uh receives it but can't do anything with it all they can do is send it back with their response uh meanwhile the recipient continuation uh is basically a packet I have previously received is that is the the uh my correspondent as encrypted back to themselves I can't do anything with it except to send it back to them and so in this way you can basically continue operations uh in uh just constrained environments environments where you don't want to keep track of a huge amount of State uh uh server environments which you need to horizontally scale things like that so um uh so this is a way of kind of leveraging uh our public key encryption to uh to basically move State into the future. Wolf_McNally: All right so let's talk about improving on controller documents. Wolf_McNally: There are several ways to propose to improve control documents and as I'm sure you're all familiar there's SeaWorld. Wolf_McNally: And there's creating bespoke divorce just for controller documents. Wolf_McNally: We'd like to propose that gordian envelope is the best choice. Wolf_McNally: And so why would we propose that so obviously we've talked about all the flexibility and advantages we've already discussed. Wolf_McNally: That holder based delusion is really the big win. Wolf_McNally: Because with Ds you have to reveal a method and a verification key but with an envelope you can elide additional keys or endpoints. Wolf_McNally: And verifiably revealed at a later time as I demonstrated with the driver's license. Wolf_McNally: What does that look like for a controller document well this is a reimagining of a controller document purely as an envelope and I'll talk about about how to integrate into the existing controller document document architecture in a moment but I want to show you what it would look like if we completely redesigned uh um control documents for envelope itself and again this is a an identifier with a series of assertions with keys controllers um could be endpoints and so on and verified by a signature. Wolf_McNally: At signature verifies and of course in real life scenario we would also be adding salt. Wolf_McNally: Once we add uh decide what parts of it what to allow it for a particular purpose. Wolf_McNally: We can basically Allied at various levels everything we don't need to accomplish that purpose. Wolf_McNally: In fact if we just want a very general introduction we can actually Allied everything all 3 uh top level assertions in there and the signature still verifies at this point all we revealed is our identifier um a key and the signature which verifies that we have the the uh the private half the. Wolf_McNally: So let's focus on this for a moment um the lighted uh assertions are still there you can see their hashes here. Wolf_McNally: And what would inclusion proof look like in this case now inclusion proof we have to match 1 of match 1 of those hashes. Wolf_McNally: In this case if we want to just review the agreement public key uh for encryption purposes then um it would look like this it would look just the part of the envelope and I mentioned um showing a more um sophisticated inclusion proof in this case all I'm doing is uh uh the revealing the key and just the parts of the tree necessary to form that particular Global Union cache that fit into that particular assertion of the tree and so when that's actually integrated with the tree it looks like this um so you can unlock uh a uh an envelope by revealing just the part of the tree that can be still of these light it as you need it to be um with the rest of the uh with the original document. Wolf_McNally: And of course the signature still verifies. Wolf_McNally: So how do we integrate this with existing infrastructure. Wolf_McNally: So here's a uh an envelope of of just a segment of uh of a did that includes a couple of service endpoints. Wolf_McNally: And these have insulted. Wolf_McNally: And then we align them so that we basically have uh an identifier and a couple of lighted end points. Wolf_McNally: And then we B 64 encode this now we're in Json land. Wolf_McNally: And then we integrate this with our Json did so in this case we have a service type of lighted services in the service endpoint which include our lighted envelope and therefore is you know we can basically reveal inclusion proofs about this uh at a later time to uh to reveal parts of the envelope that uh that actually revealed the service itself. Wolf_McNally: That's the uh the uh the presentation um Christopher I are happy to take your questions. Christopher Allen: Yeah well a couple a couple of other notes um so all of this is implemented currently in Rust and in Swift um their sum of the individual pieces are implemented in other languages like typescript and things like DC board there are now implementations in half a dozen different languages uh after uh some a lot of support from the core Community uh for this uh the um. Our Robot Overlords are scribing. Harrison_Tang: Sorry at some point we probably uh will need to take some time to upgrade the system but. Christopher Allen: Okay I'm back I'm not sure I did everybody get knocked off is that what happens when this happens. Wolf_McNally: I believe so yeah. Harrison_Tang: Uh yeah yeah because like yeah because the video I think takes a lot of time with so. Wolf_McNally: I'll keep mine off then. Christopher Allen: Yeah I'll keep my I'll turn mine off as well. Our Robot Overlords are scribing. Our Robot Overlords are scribing. Christopher Allen: Um which is important because the uh. Christopher Allen: You know having all of the cryptography and as completely separate layers means that we can very easily add other kinds of signature formats and things of that nature so we already support uh sep in Shore and ecdh we support 25519 signatures uh we support x0 25519 for key agreement um but we even have an oddball uh proof of concept of using SSH Keys uh uh which include all the various forms of uh you know RSA Etc um but more not so much that that uh that these are um um that we're trying to offer cryptographic agility uh it's more that it's a completely separate layer that's up to the application to decide what they need so if uh for instance we talked about using salt for anti-c there's no. Christopher Allen: Reason why. Christopher Allen: Couldn't do a. Christopher Allen: Plus signature as well um we have an implemented that but that's um. Christopher Allen: Um uh you know very deliberately designed such that you can do that or Quantum signatures or whatever else as needed um the only cryptography that is required for the base 5 use cases is shot to 56 um uh and CH I think uh Chacha Polly um uh that's it. Christopher Allen: Well are there any other kind of high-level points that you want to. Wolf_McNally: I think I hit on most everything uh yeah I mean actually the uh uh ietf Chacha 20 poly 1305 implementations are is our um is our symmetrically encrypted node and and then we add on to that uh next 25519 sealed message to encrypt the actual uh symmetric key and that's how we doing our encryption. Christopher Allen: We also have um uh a uh. Christopher Allen: Shamir secret sharing uh version of encryption so that you can split uh data into multiple parts and only by restoring uh Quorum or a quorum of quorums uh uh will you actually recover um the uh the data which again just you know basically covers the flexibility of how all of the cryptography is uh carefully separated from um the uh the the the the layer of the triples and the layer of the core um um yeah so uh open to questions. Harrison_Tang: If you have any questions uh feel free to just uh type in Q Plus but I do have uh start with 1 or 2 questions so first of all uh can you uh go a little bit deeper and then clarify how illusion works because uh you know like uh for example when you change something in the document right the signature will fail so how do you actually dynamically Elite certain assertions and then using the same signatures uh and then the still the same signature still works. Wolf_McNally: So basically as I mentioned can you hear me. Wolf_McNally: Yeah so um as I pointed out the the the structure of an envelope is a tree every tree every is in similar to a Merkel Tree in that uh you know every note of that tree has its own unique signature hash. Wolf_McNally: There's you know hashes or digest is the term for it um and then each level of the tree is the hash of those hashes essentially so it goes back all the way up to the top of the root hash. Wolf_McNally: Um now there are certain Transformations and as I mentioned there are 3 of them um Elysian encryption and compression that actually transform the entire branch of the tree where you substitute that node um for another node that that actually declares the hash of that node so for example a leaf which is just um any core that you want um its hash is calculated but a lighted note carries a hash with it and it's that hash that's propagated up towards the top um so that when you exchange for example a leaf for a lighted node rather than calculating the hash now you're basically using the hash in the in the uh declared the declared hash in that lighted node which is the same hash to carry up to the top of the tree so by transforming certain branches to the tree you preserve the top level hash now you have changed the document and so we we refer to the difference between um semantic equivalence and structural equivalence so semantic equivalence is you transformed the uh 1 version of the envelope in such a way that it has the same. Wolf_McNally: um top little hash. Wolf_McNally: Same structure and so uh we have tools that let you compare envelopes for both structural equivalence as well as semantic equivalence semantic equivalence is very fast because you just um calculate hashes now certain things like encrypted um which is is the ietf Chacha uh uh 20 poly 1305 the poly 1305 part there is for additional authenticated data which basically means that data that you cannot change without without uh um making the the payload on a crypto and so um uh we use that mechanism in that case to declare the hash. Wolf_McNally: And in that case the it becomes essentially tamper-proof that the depth of your node can't be changed without invalidating the actual signature um and obviously you know if somebody wants to spoof something and change something um you know then uh they can but you can but once the the envelope that part of the envelope you Loop comes on encrypted or uncompressed which anybody can do or whatever you can actually you compare the hash of that part that was uh declared with the actual hash that you've calculated and that's proof that that the envelope itself was um an Integrity so and things like signatures also add a layer of verification so when you hide something you're not signing the the for example the core serialization you're signing the actual digest at that note of the tree and so as long as the that um. Wolf_McNally: Intact and again you can't change the contents that have been signed um without uh changing the hash the hashes that are stored in the the serialized envelope and therefore. Wolf_McNally: Uh invalid in the the signature does that help you understanding. Christopher Allen: Here let me. Harrison_Tang: Yes so the signature pop oh sorry please. Christopher Allen: Oh I was just going to add a my uh this isn't a clarification just another way of thinking about it you know we talked about um uh envelope being a hash tree but in fact it is a hash trie of hash trees so every triple is a hash tree and in the root of that triple is a hash and that then in turn is used as part of the hash tree that is above it um of a of a you know subject predicate object um up to the root uh of the thing so you can basically leave out any the details of any tree uh and uh just leave the hash and everything is still valid. Harrison_Tang: Got it so the signature part in the gordian envelope is actually not 1 signature it's actually kind of a miracle tree essentially is that correct. Wolf_McNally: Well it's it's signing the digest of a treat so once you have that root hash of the tree you're signing you know you take an envelope you wrap it so that it basically you're making a meta assertion when you sign um and then you know so you have a new envelope that wrapped envelope which it had the curly braces around it and that envelope has a unique root hash and then you generate a signature for that unique reach and then you add an assertion to that wrapped envelope which is your verified by assertion with that signature and that way anybody receives that envelope with the public key and recalculate that root hash from the envelope because that's not again the digest except for those 3 cases uh a lighter encrypted compressor not actually serialized with the envelope the receiver you know uh deck serialized the envelope which calculates the entire digest tree then they um take that root hash. Wolf_McNally: And then they use that with the signature and the public key to verify that that the hash is correct. Wolf_McNally: So uh you know that that that verifies that the envelope is intact and has not been tampered with. Harrison_Tang: Got it okay thank you well. Christopher Allen: Yeah I mean. Christopher Allen: Well let's talk less about VC let's talk about did uh controller because we looked at that a little bit more so there already is uh with the did documents sort of an abstract way of looking at the structure and we can absolutely reproduce that structure in fact we can re reproduce a lot more kinds of structures than just uh the uh node labeled graphs of uh of Json LD and rdf we can also do Edge labeled graphs and a bunch of other different kinds of structures uh we have a research paper that explores how we can represent a wide variety of of things so my presumption would be that um. Christopher Allen: Uh if you can't directly interpret a controller document that is in the envelope format that the uh resolver takes the uh non-aligned information and constructs a standard um uh controller document uh using the abstract syntax um for that and that's what is actually returned to the client if it doesn't you know understand uh uh the uh uh the um doesn't understand the the core directly um uh which does mean that the those clients will have you know a uh uh you know we'll have to think about and this would be something we'd have to add to the resolver spec of okay you know it you know uh what was aided because there isn't really a concept in controller documents of aided uh to. Christopher Allen: In the abstract uh model um but the resolvers can absolutely handle this type of thing I did show this and describe this to Marcus a while back and he said yeah I think that's you know it's definitely uh a resolver can definitely construct a uh uh a Json uh uh did controller document um I think some of the other things we started talking about verifiable credentials um the uh the context uh uh in particular the semantic context and all of those different types of attributes um are more complex because you may have uh some contexts that are uh static and fixed uh such as the VC context but then you might have you know an application context or whatever that changes and you have to retrieve those. Christopher Allen: Um we believe we can support uh that that complexity because of the fact that all of the uh every individual piece of an envelope itself is an envelope so for instance you could put in the predicate uh you know here's the owl context here is the Json LD context here is the whatever context and or use known values to compress those types of things um. Christopher Allen: Which uh really you know allows for a lot of flexibility in the ability you know to uh um uh to represent everything that is in a verifiable credential we don't have a proof of concept for that at this point it's you know uh we're uh you know sort of a funding uh limitation because there's a lot of richness there. Wolf_McNally: Christopher I'd like to add something here as well because for example you just mentioned you know predicates and predicates in the examples I gave uh you know I I didn't explain this but this is explained in our videos. Wolf_McNally: That whenever you see single quotes around a string that is a known value uh and the single quotes basically that's basically just 2 or 2 3 by integer from a 64-bit integer namespace so it has very little little um overhead uh in sort of storage for an envelope but uh we are are essentially starting a registry of known values we intend to eventually have you know um all the all the rdf predicates registered as unique integers uh in a particular domain you parse for the ones that you care about um you can still use your URLs if you like cuz strings can be predicates as well or you can basically have a search on predicates it's really up you know uh uh because you know predicates themselves are envelopes so um uh the platform itself is incredibly flexible and very semantically rich in terms of what you can express with it I haven't you know obviously um but you say so myself as the designer of envelope I haven't seen anything that can do what envelope can do in terms of the richness um how that richness is deployed is basically um a question for research and that's part of why we're here as well let's discuss with the community. Wolf_McNally: what you need and. Wolf_McNally: What are the. Wolf_McNally: Pursuing it together. Christopher Allen: Yeah but also think you know other things that you know a lot of other systems are limited that you can for instance only have 1 type associated with a semantic triple uh you know which would be the quad uh because of envelope you can have multiple types associated with uh a particular um uh triple uh you can say this is a you know a binary key in 1 you can say this is a 25519 public key uh in another you can say that this is a you know in fact a snore uh aggregated key uh in anothers uh so you can have all of this You Know Rich complexity that allows for um uh additional uh you know levels of of uh of of context uh so that makes it richer than the the both the the the the underlying format of. Christopher Allen: Of uh Json LD or um uh uh or rdf uh because we have this ability to do a lot more different kinds and styles of stuff I do know that w3c has an effort um with kind of an it used to be called rdf star I don't know what the new name is uh I don't uh I understand there may be a future version of Json LD uh that might support uh more but I haven't seen any of these also deal with kind of the illusion cases and um uh you know if uh we'll we'll be tracking see what uh what's going on in those efforts but I think the key. Wolf_McNally: Yeah I like to add some here too. Wolf_McNally: Oh yeah so also I just saw my example so if you look at like for example the proof block of a data or control document um you know it's because the limitations of Json you see a series of key value pairs that Define the type of the key and the key material itself and so on um with ours you didn't see that you just saw a signing public key agreement public key um those are actually core structures so those are keyboard structures if you look at our specs uh they Define usually a short core array uh which has you know a series of sequence fields which includes a you know um an algorithm identifier in the key material um and um in some cases like public keybase we can actually bundle those things together so there's an agreement public key and assign a public key together um so that's all you need to exchange to do both encrypted and signed Communications um but because we can mix freely sibur itself which is self-describing and so on with the higher level structures of envelope which is symmetrical triple so we can choose which way to do this uh on a much more flexible basis and things that didn't start out in the envelope. Wolf_McNally: As long as they. Wolf_McNally: Which is most Civil War structures um then they can be freely mixed into envelopes um and so there's you know there's there's no reason why any Civil War structure that conforms to DC or can't be the object of a of an assertion so um you know we deliberately designed it in a layered fashion like that to be very flexible. Christopher Allen: I mean even for instance you could do core LD which does uh its compression taking advantage of some of the unique aspects of uh of uh Json LD for uh Json LD based uh controller documents or verifiable credentials and basically you know put embed that inside an envelope um so uh uh you know you would then be able to do certain kinds of Illusion things uh until you get to the point where the there's a Json LD object which doesn't support Elysian uh conversely we showed at least a proof of concept uh in the slides of the opposite which is you could put a very small um uh constrained uh Envelope as a an encoded in uh based 64 uh and then be able to have an individual function uh be able to uh with. Christopher Allen: Within Json. Christopher Allen: Or a Json document to be able to be alighted uh have individual items allowed um you know in particular I I care about um uh the keys and I mean I think the big as a security um uh and privacy person uh I never want to reveal more keys than I absolutely have to um so uh the you know uh for instance on you know with my signing keys for signing code um you know I have 1 for every uh a different key for every machine uh I use uh so that I can uh uh revoke an individual machine without revoking all of my other machines uh but that means that when I sign things I only want to reveal the public key for the machine that I'm using but I want but I can use envelope to commit to all of the keys uh that I have and then later go oh you know uh you know back in commit 15 uh I can demonstrate that. Christopher Allen: Committed to this other signing key that I did not reveal until today um so uh I think that's an important um you know aspect of these types of things I think the other aspect of things is that that um uh. Christopher Allen: We when we think about verifiable credentials we often are thinking about the the the atom that is a verifiable credential in the spec but in fact that is not really the way uh I would describe the architecture I would probably you know call it the verifiable presentation spec of which a small part of it is the verifiable credential um because in fact the verifiable presentation has a lot of structure and things that you can do with it that are um uh you know that embed various types of things gordian envelope in when it's used in kind of VC use cases is more like a verifiable presentation you have a wide variety of things that you can uh uh can offer uh and then of course with gstp we get some of the did Cam type of features as well. Stephan_Baur: Yeah thanks so I have just 2 short questions and I have to admit I didn't fully you know uh understand the presentation but um I just saw there and this might have been because you used the example of controller uh documents but I just saw a lot of public Keys being mentioned straight out and I just wonder if there is a sort of like an aspect of this where key rotation becomes now uh a problem so that's my first question I hope that's not the case right and the second question is given the name of your organization uh is this used in in any sort of blockchains that are currently um you know having that on the road map or something. Christopher Allen: Well I said the first question uh second but uh as far as blockchain Commons um uh most of our support in the blockchain community is at layer zero um so we are you know we are not explicitly used in any particular blockchain uh instead we are used by wallets um uh at the so we have a variety of Standards around uh uh Keys creation of keys seeds for Keys um and uh we have a you know a various protocols for doing things like signing and uh uh and other stuff with those keys uh that are adopted uh mostly in the Bitcoin Community but uh we also have some adoption in uh aetherium zcash and chia um uh but the you know most of that work is in the Bitcoin Community but it's not at the blockchain layer this is not a this is not a layer 1 or a layer 2. Christopher Allen: Uh function this is uh more for um you know how do we provide privacy at uh the layer zero um so uh we are to answer the first question we are very careful about um how we reveal uh keys and and things of that nature that's 1 of the real powers of a lighted um you know we can support a wide variety of the different uh kind of patterns that um are available in uh a variety of did methods uh obviously you know we we demonstrate how you can do a pre-commit and Allied uh a key uh. Christopher Allen: A you know kind of a um you know non-implementation um and uh we can do the equivalent of carry we can do the equivalent of btcr um and a few other things uh We've not tried to do the equivalent of some of the smart contract based rotations uh but you know I think the proof of concept is uh good enough at this point to show the architecture is designed for that kind of flexibility does that answer. Wolf_McNally: Also to add that uh I also like to add a couple things you know 1 um Christopher touched on it but you know blockchain Commons despite the name of our organization is not focused exclusively on the blockchain space at all it's focused on the uh personal um sovereignty digital privacy human rights space and how Technologies can be best used for that uh the name itself came about when blockchain was the chief way that was actually being kind of advanced but you know our mission itself has always been broader than blockchain based per cell itself so um and the other thing that. Wolf_McNally: Touched on is uh briefly in the slides but we didn't really go into it is um uh a proposal it's not implemented or anything like that yet called xid extensible identifiers or Zid which essentially um is kind of a super set of controller documents that has you know verifying great permission structure. Wolf_McNally: Allows for very fine grained key rotation um and um and so as well as um uh kind of a hash chain of all revisions of the document back to its Inception so um you know so yes we have given a lot of thought to things like key rotation and security over time as uh as the lifetime of an identifier evolves. Christopher Allen: Yeah and I will say you know just to be clear you know I've been you know I'm the co-author of the original did spec and uh um a lot of the you know original Concepts were there uh I'm kind of you know opinionated and I don't really personally feel that any spec that doesn't do key rotation is a did spec. Christopher Allen: At the personal opinion and uh uh you know when those both those specs went to to Final Call um you know I raised my concern about uh the you know the Privacy problems of revealing too many keys uh but did not would you know since I didn't have an alternative I didn't have a a solution um I did not block or you know push too hard on those types of things instead I I stepped away from uh uh for instance I was I was co-chair of this community for 5 years I stepped away from that and some of the other responsibilities to basically go okay how are we actually going to make this work and that's uh when uh uh wolf and I started puzzling through okay you know what are the pragmatic uh things that we can do uh which ultimately became Guardian envelope gstp and some of this other stuff was you know we we didn't have. Christopher Allen: Have a. Christopher Allen: We didn't have a. Christopher Allen: An answer to the problems that that I had raised uh and now we do. Wolf_McNally: Yeah it was really a matter of thinking it through from first principles and Christopher has been you know obviously the Visionary regarding that and you know then relying on myself for my design and Engineering expertise but not necessarily trying to be directly compatible with um existing specs but we are firmly convinced that we can you know create envelopes that are fully isomorphic um with existing documents um and you know so if you transferred back and forth between them but also can have many other capabilities including obviously we've highlighted here holder base delusion as you know essentially baked in. Stephan_Baur: Wonderful great thank you. Harrison_Tang: Well do you have a 1 last question. Christopher Allen: Well I mean if if we if we you know to be very specific um there are a variety of did methods uh that um are concerned about some of these types of issues uh so for instance um 1 of the things that sibur allows us to do is uh is to have very very small uh a lighted uh documents so in the case of um uh squares um uh bit torrent uh based did method uh they're constrained to 1K uh we in fact can you know basically have a fully elided uh uh uh did do document in like 250 some 6 bytes that can be uh or a little bit larger than that but you know certainly under 512 that can very richly describe uh you know uh you know. Christopher Allen: A very complex and deep uh document and can handle things like BBS keys that are large etc etc uh because you basically commit though you you show that you've committed to those values when you do the the verifiable presentation uh side of things not and uh not uh public in the did document um so they have some very specific requirements as far as size uh other um uh other uh methods have very specific requirements around uh uh endpoints they want to put a lot more data into the endpoints to allow it to to function but then you have the problem of that endpoint then maybe reveals uh you know who the part you know reveals information that would allow for correlation um so uh you might want to have multiple endpoints or uh you know be able to hide aspects of endpoints. Christopher Allen: And that particular case. Christopher Allen: They could use. Christopher Allen: We were talking. Christopher Allen: Talking about which would be a uh you know a Json uh Service uh that you know uses A foliated Envelope as the value for it so I'm not sure which will uh which of those 2 approaches you know fully native core document uh will be uh of Interest or uh you know just being able to align individual values uh inside core or adjacent LD documents um we think this is an important future it obviously is not going to be easy in the in a vc11 did 1 1 uh deadlines and context but we want to throw these opportunities out there and see what uh people are um interested in focusing on we're looking for Partners at this point we can't do this without um you know parties that are interested in it so. Harrison_Tang: All right thank you thanks Christopher thank you all for a great uh presentation as well as the discussion so thanks a lot. Harrison_Tang: Sorry about the technical difficulties that we had earlier on. Wolf_McNally: Thank you for having us. Harrison_Tang: All right so I think uh Christopher has shared the uh the presentation welfare share the presentation and then there are links to a blockchain comments uh and you can go there if you want to get more information uh this concludes today's ccg meeting thanks a lot. Wolf_McNally: Thank you everybody.
Received on Wednesday, 23 October 2024 05:50:46 UTC