Credentials Community Group

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.

Harrison_Tang: I think there might be an audio issue because uh he was not muted.

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.

Harrison_Tang: Sorry at some point we probably uh will need to take some time to upgrade the system but.

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.

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.

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.

Harrison_Tang: Yes so the signature pop oh sorry please.

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.

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.

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.

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.

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.

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.

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.

The W3C Credentials Community Group

Meeting Transcriptions and Audio Recordings (2014-today)

Go Back

W3C CCG Weekly Teleconference

Transcript for 2024-10-22