Episode Transcript
Speaker 1 00:00:06 Welcome to the rubric. I'm your host,
Speaker 2 00:00:08 Joe Andrew I'm Eric shoe.
Speaker 1 00:00:11 And I'm Erica Connell today on the rubric. We speak with Oliver turbo and merchant Nestor, editors of the did ether specification to understand the motivations behind the method and get a peek into future plans
Speaker 3 00:00:24 Says it doesn't really require any interaction with the chain. This is free and doesn't require registration
Speaker 2 00:00:31 On the rubric. We meet the people making decentralized identity or reality. We discussed the techniques and motivations behind the movement, including decentralized identifiers, which encompasses DIDs, did documents and did methods. So you can make better decisions about which did method is appropriate for your use. Decentralized identifiers enable robust identity based services without dependence on a trusted third party. Instead of being forced to use central centralized identity verification services like Facebook, Google, or the department of motor vehicles, dense can be created by anyone anywhere and use for any purpose. Did methods are the magic ingredient that give DIDs their flexibility before creating any specific? Did you first choose a did method, which determines how you perform the create read, update, and deactivate operations on a date of that method once created each data includes the name of its method in the identifier itself, so that when you use the, did others know how to retrieve the associated document that contains the cryptographic material for secure interactions, different did methods use different underlying mechanisms with different performance security and privacy trade offs. This show, the rubric interviews, the creators and users of different did methods to better understand their motivations approach and future plans to help you make better decisions about which did method best fits your needs.
Speaker 1 00:01:49 Joining us is Oliver turbo. The architecture standards lead at consensus identity Albourne has been working in the digital identity space for about a decade. He was involved in various standardization activities, such as the upcoming ISO 1 8 0 1 3 5 mobile driver's license, W3C, verifiable credential, and the emerging W3C decentralized identifier standard. Currently he is co-chairing two working groups in the decentralized identity foundation with focus on did come and defining a bridge between open ID connect, decentralized identifiers and VCs as part of the IDF diff liaison in his capacity at consensus identity, he works on identity strategy and architectures to use SSI technology in internal and external projects.
Speaker 2 00:02:42 I also have merchant NIS store, senior protocol developer consensus identity. He started working in the identity space at consensus after joining the U port project in 2017. After a decade spent in computer security industry at bit defender, he is now working to together various standard implementations from the identity space into an agent framework called Venmo. Welcome to the show.
Speaker 3 00:03:07 Uh, nice to be here. And, uh, thank you for the invitation.
Speaker 4 00:03:12 Absolutely. We're glad to have you did ether brings decentralized identifiers to Ethereum the world's second largest cryptocurrency network, early contributors to the dead conversation. The folks behind did ether helped establish several innovations that significantly improved the cost effectiveness and usability of cryptocurrency based identifiers. I will start us off with the simplest question. There is what is did ether?
Speaker 3 00:03:38 So did ether is a dead method, uh, that built a dead document around a public key or an easier mattress. And this document is self attesting. Self-referential initially sort of like, um, did ki builds a document around the key, but with the ability to later update the document or to add extra services to it, and it is anchored, uh, on the, on, on one easier network, it can be anchored on multiple team networks.
Speaker 4 00:04:15 What makes did either unique?
Speaker 3 00:04:19 Oh, um, I guess this is harder to answer because I don't really have a working knowledge of all the did methods out there probably after the listening to all the episodes you'll be producing, I'll be able to answer this. But the one thing that drove us to build the ether in the first place was that we needed a dad method that didn't require registration. So before this, we were working with, uh, did methods called, did the report, uh, which is now deprecated, that one required, um, a transaction to be sent whenever a new debt was, was created. Uh, but then we noticed that most, uh, the IDs that were created were never actually updated. So actually people were just fine with just using the date as a, almost as a string. So then this, let us do to the next step, which took, which was to do a, like a back of the napkin calculation and realized that, you know, we, we, we couldn't scale to the whole world if everyone suddenly wanted to use this method. So we needed something that would be free to create and have extra bits, uh, as, as we'll talk about.
Speaker 2 00:05:38 So it really was driven out of this need for free creation because you notice this pattern where most DIDs that are created are never updated. They're temporary DIDs that are only meant to be used for a couple of days, so there's no need to update.
Speaker 5 00:05:53 Okay. So again, without knowing all the different in detail. So since there might be also the medicines that are in cottony cereal, but there's also very special about it, is it is it is that it supports multiple different cereal networks. So in fact, we can reuse it with, um, all kinds of different PBM blockchains from, so we have cognitive support for, you know, the cereal main net for a lot of the serum tests nets, but we also have support for, for rootstock the RSK chain or, or in medical polygon, which are side chains of the cereal and technically any EDM compliant blockchain might be possible. And this also includes, um, enterprise blockchains, you know, um, quorum is the enterprise blockchain cereal, and we even saw some people are using something that could be sort of,
Speaker 2 00:06:42 Yeah, cool. So it has just this flexibility kind of across any Ethereum based chain. Is that a good summary?
Speaker 5 00:06:51 Yeah. It's important. Any EVM compliant? Um, blockchain VVM means, um, the serial rectal machine,
Speaker 2 00:06:58 But do these EVMS need to have ERC 10 56 enabled, I assume they do, or is that just a given as that a stupid question, because it's a given that would have,
Speaker 3 00:07:09 It's not a stupid question. Actually, this ERC 10 56 is a smart contract, which can be deployed on any EVM network and anyone could deploy it. It's w we don't decide it. We provide some pre-baked, you know, pre pre-compiled complex contracts, if anyone is, um, you know, is willing to deploy them. So, one of the things that comes out of this, um, usage of events as building blocks for the document is the fact that we can go back in history and see how the document appeared at the particular time. So this allows us to have, you know, was this signature valid at this state kind of questions answered. And also recently this was baked into the spec as, as a version ID, uh, kind of query that you can do as great, perhaps for the, for the resolver. So w which allows us to, to use, uh, you know, issuers from the past, uh, actually to, as, as signers for data,
Speaker 2 00:08:12 Closing out this little bit of an intro about did ether, um, would you guys mind walking us through kind of the typical life cycle for did either? Um, you've mentioned that the creation is free, but, um, how would one go about creating a did ether and then updating it and then retiring it once it's, uh, needing to be deactivated?
Speaker 3 00:08:33 Yep. Uh, I can take that. So, uh, creating a debt ether is not just creating any Ethereum images, which can be done by, uh, generating, you know, sick P 2, 5, 6 K one, uh, uh, public key, and then hashing it. And that's, that's the peer mentors. So th this also applies smart contracts. So you, you can, you can wrap a smart contract behind it, that ether. So actually any Ethereum address is a valid ether. If you prevent, you know, like Dave, call it ether to it, this is also true for public key identifier. So you can take the, just the public key part and presented ether to it. That's also a valid eater. So this is creating since it doesn't really require any interaction with the chain, this is free and doesn't require registration. And if you just create it and use it, if it's not even visible to anyone.
Speaker 3 00:09:27 So like most of ethers out there are actually still private. Um, people don't know they exist, like not, not the whole world knows that they exist, then updating this means sending a transaction to the ERC 10 56 registry, where the ether is anchored, which so through, through this transaction transaction, you can change the controller of, of the dat. You can add new keys, you can add services or like remove existing ones, uh, from, from the document. And then the active in get means, um, send a setting the controller to the novel identity. So the, the novel address actually only view which, uh, renders it useless. You could also like argue that if you've never updated it, and nobody knows about it, the activating, it would just mean throwing the private key away. So that's also possible.
Speaker 2 00:10:27 Yeah, I think there was something interesting you brought up in there, which is actually, I think one of the unique things about did ether that I've seen as far as the other methods we've reviewed, and this is, uh, this ability to add extra services where in the spec you actually call out that did ether allows for delegation because of this, I believe, um, you might, one of you just walking us through, uh, what type of delegation is enabled through did ether, um, and what that kind of enables.
Speaker 3 00:10:56 Um, so delegation is a way in which the signing capabilities of, uh, the ID can be, uh, sort of enhanced by other kids. So this is sort of like an early form of smart contract signatures, where you, you, as a controller of a, of a debt easer would delegate signing capability to another address on, uh, on hunching. Of course, this, this signing capability is going to be visible in the document as well. So this, these delegates are just other ATO mattresses, uh, that could sign on your behalf on chain. And also they appear in the documents or the, they are like valid signers for off-chain use cases as well.
Speaker 2 00:11:42 Okay. So it's specifically key delegation, essentially.
Speaker 3 00:11:46 Yes, yes. Yeah. Um, it's, it's more like if you matches delegation cause the what, when you add a delegate, there's no new key added, it's like a blockchain counter D uh,
Speaker 4 00:11:58 Yeah. And are these delegations, um, limited to the verification relationships we're familiar with? Or could it be an arbitrary delegation? Seems to me like, it's, it's always going to be a verification relationship, but is there any extensibility there
Speaker 3 00:12:14 As it comes to the document, it's, it's only about the verification relationship, uh, for on chain use cases, the verification relationships are not really interpreted in the same way. So any contract could check that a signature is, is coming from the same identifier, cetera.
Speaker 4 00:12:31 Okay. So we've mentioned ERC 10 56 and what we'd like to do, especially for those members of our audience who are not familiar with how Ethereum works. Um, could you explain what an ERC is at a conceptual level and then how, how is it leveraged to make it either a reality?
Speaker 3 00:12:49 Um, I guess on a conceptual level, URC means just a Ethereum request for comments, if, uh, just to, I think there's, there's like, uh, a link to their own world or of our artsy, I think. But, um, so, so the, the, the attempt here is to create sort of like a standard or like a community adopted, uh, community accepted definition of contract interface, where people know what to expect from, from such such an interface. This in, in our case, this, uh, smart contracts defines, uh, uh, a registry of attributes, uh, that, uh, relate to these Ethereum mattresses. And these attributes are controlled by each Ethereum address, like, um, as, as, as controller. So they're, they're not claims about other addresses. Each address makes these posts, these attributes on its own behalf, and then control of this address can be delegated to other, uh, can be rotated to other addresses. And, and this forms, the, the infrastructure let's say, uh, on which we based the resolution process of the, of the ether. So for the ether, the initial document is just the it's own address, or it's on public key. Then if an update is, is made, this update appears as an event that is emitted by this registry, uh, contract, and then these events are compiled into the, um, the, the document that results, uh, after resolution.
Speaker 4 00:14:30 Okay. So the ERC is really it's equal VIN to an RFC. So it's a conversational document to get agreement in the community. And then there's a specific smart contract that I'm sure has some sort of a identifier or hash probably, um, that implemented that is that sort of how it works. And then the transactions on Ethereum can leverage that smart contract.
Speaker 3 00:14:53 Uh, yeah, but the difference is that there's not, no, uh, like in many cases, this is not about like one single contract instance. It can be multiple, like for, uh, Ethereum tokens, for example, uh, there is an ERC 20, which represents a fungible token that can be, uh, exchanged, uh, and there are multiple contracts implementing this year CD 20 interface, for example, for, for every coin out there that is deployed on here. Um, so it, it just represents the interface. Then there, there can be multiple instances.
Speaker 4 00:15:27 Excellent. I appreciate that clarification, but there is a specific smart contract for did ether that is implementing ERC. Uh, what's the number again? ERC 10 56.
Speaker 5 00:15:39 Yeah. So there's actually specific instances of that. Um, small compact deployed on various, the Syrian blockchains and to the contract addresses of those instances is actually included in the Eastern spec. So since the diesel spec is the authoritative source, um, for the ISA resolver, um, the result of compliant with solar would need to go to the specific conflict addresses.
Speaker 2 00:16:06 Okay. So you list the address of the contract on each chain that supports it currently, or at least that you know of that supports it.
Speaker 5 00:16:14 Yes, yes.
Speaker 3 00:16:15 Yeah, of course people are our feet to deploy these contracts, uh, at other, uh, other addresses. Um, and then just use them for testing, for example.
Speaker 4 00:16:26 So if I have a data ether that's has an update that is anchored on the Ethereum main net. Um, how does someone in a different EVM know that or find that out, or how does that work?
Speaker 5 00:16:42 So each DAPs are, has, um, the chain identifier part as part of the vid. So it will be like the ID, colon, ESR, colon main net that indicates we need to go to the mainland to Robson, et cetera. So if there is no, um, identify or no name of the specific option in the VAB, then it always defaults to certain minutes. So, so in your case, in your case, um, you would have different dates. Um, the different ESE templates is six, the name of the blockchain, the chain changes.
Speaker 4 00:17:23 Yeah. That makes perfect sense. So, so the identifier itself may include an alternative network to go look for the smart contract. Um, but if you don't have that, then it goes to a theory of main net. Yeah. That makes a lot of sense.
Speaker 2 00:17:40 Yeah. Another wrinkle that you brought up in your description is this concept that did ethers can be created with either your public key or an Ethereum address. Yes. Is it one of these preferred or maybe one of them used more often or more commonly? And why would someone pick one of these over the other or is there a reason, is it essentially just a user's choice, whatever they feel like, or
Speaker 3 00:18:06 I guess we would, we would want to encourage people to create, uh, that ether with the public key identifier instead of the Ethereum address, this is sort of like a super set of the, the one that's created with easier matches. So always for a public key, there is a corresponding Ethereum address. So which means that if you have the public key, you can get the same address, but the other way around is a bit harder. It's like, normally it's impossible, but if there are transactions that are, uh, that corresponded at this year mattress, arguably someone could discover the public key and then, uh, find out the larger, uh, did document.
Speaker 2 00:18:44 So in essence, if you use the Ethereum address, discoverability might be more difficult as far as being able to tell who the actual controller is.
Speaker 3 00:18:53 No, no. So the controller is obvious if you, if you use both, both of them, the difference is that when you start with the Ethereum address, uh, it's, it's impossible to list the public key in the document because the document gets created from, from events on, on, on chain. And if there are no events on chain for that material Manchester, then it's impossible to discover the public key from it. Uh, which means that you will only be able to verify like, uh, there's a, there's a need for like ECDS sec P recovery method, 2020, or something like that. So that's the only, uh, so-so not all signatures that would be possible with that. So that's why we encourage people to use the public key identifier, uh, as a starting option, because then people would be able to verify, you know, like completely normal sec P signatures.
Speaker 5 00:19:48 Yeah. Sort of thing is worth, um, with the public key in it. Um, you will be able to resolve a document that contains the public key itself. And if you only had the, the serum address without any updates on your septum, 56, then the resulting that document would only contain the production account ID.
Speaker 4 00:20:10 So I've got one last question before we move on to the next section or segment of our show, which is, you've mentioned that the public key version, can you support arbitrary public keys or it needs to be set P 2 56 K one,
Speaker 3 00:20:25 Uh, for the moment needs to be simply 2, 5, 6 K one.
Speaker 4 00:20:29 Okay, perfect. That makes sense.
Speaker 3 00:20:31 Uh, so this is as initial identifier, you can add the different types of public keys later to the document.
Speaker 4 00:20:38 All right. Once there is a dead document that someone could resolve on chain, we can use arbitrary crypto. It's just that initiating needs to be P
Speaker 3 00:20:46 Two, six K one. Right.
Speaker 5 00:20:50 And it kind of makes sense because, you know, since you're authenticating the update operations to right to the ESC 10 to six, or needs access to your Syrians, you need , which is based on PK, Monkees,
Speaker 1 00:21:07 Micha. Tell us a little bit about how you got involved in this work.
Speaker 3 00:21:11 Okay. Uh, so I, uh, was convinced by the, um, SSI dream, uh, by the UPR team. And then I joined the support team and then stayed on the support team and then took over, uh, maintenance of this dad method, which was created by while I was there.
Speaker 1 00:21:32 And what was it about DIDs and this idea of dead methods. That was, that was interesting to you. That was compelling enough for you to go. Yeah, I'm gonna, I mean, I'm on the team, but yes, I want to see, I want to explore that more. I want to work on that project.
Speaker 3 00:21:49 I was convinced by the, um, the lack of need for a centralized authority to issue identifiers. So given, given, giving people the ability to create identifiers for themselves for not just for people, but for anything, and then to use those in various ways, without requiring some centralized authority to exist, seemed very appealing. Of course, at the time, uh, like in the initial days, I wasn't even thinking of them as dates. Uh, it was just, um, like he was quite heavily Ethereum focused initially. So I was thinking of them as just the theorem accounts, but, uh, then I came to embrace this idea of, of, you know, different, uh, that, uh, options with methods, uh, with different capabilities, which this rubric podcast is now exploring. And, uh, then realize that, you know, the whole world is possible up there with these, uh, things.
Speaker 1 00:22:53 Yeah. And when, when was that, like you're saying this idea of DIDs and did methods now is kind of formal and stuff, but there was this time when people were working on these projects and it wasn't quite established as, you know, decentralized identifiers. Uh,
Speaker 3 00:23:09 For me it was like, uh, starting with mint 2017. Uh, I guess the idea is already existed as a thing then, but we hadn't yet adopted them fully in Newport. At least that's when we started to adopt them more, more and more, and to try to drive the standard also. And with, with some, some of the ideas and, uh, mistakes that we had run into, uh, to not have people make the same.
Speaker 1 00:23:36 And Oliver, how about for you? How did you get involved?
Speaker 5 00:23:39 I mean, African approaching in the digital identity space for quite a while. So I worked with, or SAML two or MediConnect and all that kind of stuff I was visiting I w every year and then, uh, just saw, wow, this is really the self sovereign identity paradigm, which is awesome. It has all these nice properties, like, um, breaking up data silos and also mitigating the risk of third parties, being able to track where you use your data and so on. And, um, so this infamous identifier are really just, um, just needed in order to have a 40 decentralized SSI system, in my opinion. And they are credentials. We can use credentials, verified credentials for those who don't know we can, um, use, uh, them with without this. Um, since the specs also allows non data-based credentials, but in my opinion, only you will be, you will be able to have a free decentralized system. And that's what it's, why did specifically, I decided I was filing specific excited about this. I joined them report three years ago, but, uh, my previous company, or you found out about did send VCs and SSI, and also tried to convince my previous employer, um, to two years, that kind of stuff, um, which was also like, um, identity, um, solution promoter.
Speaker 3 00:25:03 So what is important about this work to you?
Speaker 5 00:25:06 I think we have a chance to get it right. We can fix the internet, the identity layer of the internet, which we all agree might be broken up to a certain degree. It's really what I just said earlier. Like, um, current identity systems on the internet, they, they have a lot of flaws. Um, they basically empower the wrong people. Um, you're supposed to become products and, and so on. I think we had some, we'll see some SSI. We have the chance to fix that.
Speaker 3 00:25:40 Oh, I'm very much on the same page here with all my, so, uh, yeah, I'm trying to fix the, the current health. Yeah. It's God's work
Speaker 2 00:25:54 Well, obviously you too, um, that we have here today, aren't the only people involved with Diddy ether in this space. I just want to give you a moment to maybe shout out to anyone else that you'd like, who else is involved with did ether, um, and with DIDs in general, maybe that you'd like to,
Speaker 3 00:26:11 Uh, right. So we are not actually the, the creators of the ether. We're just the current maintainers. The creators are, uh, I guess if you look at the IRC 10 56, uh, it's uh, uh, Perry brown guard and showed those system. And they, they, uh, were in the super team when, um, when, when these were created and, uh, now we are making them, but a big shout out to them for all the great work
Speaker 5 00:26:40 They did. Awesome. Big shot up to the folks from WSP CDAD working group, who managed to get the, gets back in the very good shape and you know, about to published a recommendation. Hopefully soon later this year, apparently we have the proposal recommendation. Maybe, maybe also shout out to the decentralized identity foundation since, um, the user did spec is not maintained under the foundation. Awesome, great people who worked there. And again, also the pre-trial to W3C folks, we can work well together, the solution.
Speaker 4 00:27:15 So in our next segment, we'd like to talk about the challenges that you've faced with that ether. So w what were some of the technical or political, or other challenges that, uh, you guys wrestled with as this came together?
Speaker 5 00:27:29 Yeah, so, I mean, in the early days of sort of that early stage of the bid spec, obvious we see grandma's still a CCG spec was very different from the current proposed W3C recommendation, current spec. Um, so we had a lot of spec changes is what, a lot of legacy stuff. And we now have to fix the ISA spec and also the, um, that we solve the implementation. And, uh, but just find commentation to comply with the latest version of the specification. So I think there was one after the nature issue since the first community draft or not a good spec is quite old. So it had an off changes, and we just need to ensure that the current spec, uh, all aspects, easily inspect reflects all of those. Um, I think, uh, other technical challenges, obviously transaction costs, I'm sure we can create the D Esau with no gas costs, if not zero transaction what's you only get to say option account ID or a public key, but also to verify signatures.
Speaker 5 00:28:40 Um, so you cannot really encrypt data to someone you cannot really add service end points and so on. I think those are challenges that we, that we have faced that can be mitigated with a tool solutions or side chains where the gas costs are lower. And I mean, there are, are also like political challenges. So when we primarily operated in the, in the zoom community and, um, they were like also counterproposals to how you would do identity on, on a serial, then we're a little bit less privacy preserving. I mean, there were things like ERC 7 25, for example, but maybe, um, Marsha will be, it would be best suited to talk about that since he joined the team a little bit older than me.
Speaker 3 00:29:30 Yeah. Uh, so please, first of all, please, excuse me if I'm misrepresenting Amanda only talking from memory now, so understood. Okay. So, uh, I, I think in those days we were trying to promote more privacy preserving practices. And, uh, at the time there, there were these counterproposals that were trying to muddle together identifiers and claims about identifiers all on chain. And we wanted to promote, um, a method that had maybe less on chain data, or maybe less dangerous data on chain so that, you know, like best practices can, can flourish. Yes. So this is like, um, in terms of political struggle, uh, and then in terms of like technical issues, as Oliver said, you know, like we, we gave a lot of consideration to gas costs, for example, uh, which is why we decided to use this event system for updates instead of any other, like launching registry, like fully on using conching state as, uh, you know, as the document data,
Speaker 2 00:30:34 Just out of curiosity, do either of you happen to know what the, uh, let's say, a typical update would cost on Ethereum main net,
Speaker 3 00:30:43 Uh, 10 day. So it all depends on the size of the update. So the size of the public key, for example, or the size of the URL for the service end point that you are adding, but just, I guess if we look at the, you know, uh, set attributes, a transaction today on an ERC 10 56, it costs roughly $4. And this is just before UAP, 1559, uh, goes into effect. So I don't know exactly how prices will be, uh, affected. Uh, we hope just as any other smart contract developer out there, that prices would drop at some point. Yeah,
Speaker 5 00:31:22 I think to further reduce the price, or also supports the notion of mega transactions. So it's analysis to update, uh, entries in BSE 10 56 without being the one who sends the transaction. So you can basically is to the user who owns and fully controls the DLT user. They can, uh, create an off chain transaction and then provide this often transaction to a meta transaction, let's say gateway. And that gateway then wraps this off-chain transaction in a Metta transaction sciences and sensitivity cereal. And our 10 56 contract would verify the metal transaction and unwraps the option transaction, and we'll update them the entry accordingly. So that's also like a way how you would allow the use of, to pay the gospels or not by themselves.
Speaker 2 00:32:21 So that's like a batching mechanism, or is it slightly different than batching?
Speaker 3 00:32:26 It would also be possible with this, but the actual idea here is the decoupling of, of the cost bearing from the, um, the controller of the did with who's making the, from the drug tester of the transaction, who is actually paying the gas cost. So this allows like services to be, to be, uh, implemented that paid gas on behalf of users, for example.
Speaker 4 00:32:53 Right. And, and one of the motivations here is so that if there's an organization who wants to onboard a bunch of members, those members can control the cryptography, but the organization is paying to, to onboard them into did ether.
Speaker 3 00:33:05 Right? Exactly.
Speaker 4 00:33:06 Now you mentioned, um, using events instead of, uh, on chain transactions, I'm slippery on how that works. It would be great if you could explain for our audience, like, what's the difference between an event that propagates through Ethereum and an on chain transaction, and why is the cost different between those two,
Speaker 3 00:33:27 Right it's events versus on change state, uh, in, in all cases, transactions are still involved, but in, in one situation you can have a contract that, uh, registers some state on chain, which, um, so this state can be interrogated by the contract itself or by other contracts, for example. And in other transactions and events are a feature of material, let's say where they can act as logs, for example. So while that transaction is running, these events can be emitted. They're not actually processed on chain. They're just like recorded by the notes and they become part of the history of the chain. But the difference between different there's a difference of cost between data that is propagated as just blogs and data that is stored on chain as, as state. That's why we choose the event, uh, system, because it's cheaper than storing state on chain. And also like at the time it solved this, this, um, this privacy issue that we were trying to address, which was that people were sending more and more to posts personally, uh, identifiable information on chain. And we thought that if that, if we, if we make this a registry focused, mostly on the off-chain situation where, uh, you only use the logs, then it sort of, uh, discourages this, this use of, of PII on chain.
Speaker 5 00:35:04 And one don't emphasize that also the knobs are actually incurred on chain. So it's done on slot machine, but the LA you know, secured by the blockchain,
Speaker 4 00:35:14 So a hash, or is committed to the chain.
Speaker 3 00:35:17 Yeah. So these logs they're emitted from transactions. So from, from a smart contract code that gets executed. So that's the, that's why they have the same security implications as just on chain state. It's just that the storage is done somewhere else.
Speaker 4 00:35:34 So if I were to update my did ether, is it possible to add arbitrary properties to the document? Or can I only update verification relations at methods?
Speaker 3 00:35:46 The URC 10 56 registry allows you to set arbitrary attributes, but they will not be visible in the document unless the resolver in terms of interprets them as, uh, the document updates and the resolver, uh, interpret them based on the, uh, the way the spec is written and the, of course, the implementation. So we've seen people actually use these, uh, 10 56 registries as arbitrary key value stores, but, uh, only the proper format updates get propagated as the document entries. So that limits you to verification, relationships and service endpoints.
Speaker 4 00:36:29 I have a question. Have you thought about using did ether to refer to non fungible tokens? Yes.
Speaker 3 00:36:38 There was actually a recent project that we did like a proof of concept where we S so we were talking about this, this sort of new dead method called data NFT, which yeah. So before, before it was proposed by, by Joe, we had an internal version that would, uh, find the owner of an NFT and just reference to it as a debt ether, or actually use the same deck ether infrastructure to build the document for data NFT. Now, the, the actual spec for the dynasty, um, mentions the chitin link, uh, that, that ceramic uses, for example, uh, to refer to a different date method and then use that method as, as controller. But initially, yeah, we were, we, we had this internal, uh, toy that we, uh, made, which allows you to sort of sign messages on behalf of your NFT.
Speaker 5 00:37:33 And we also build a demo , it's not a production application where they can play around with it. You can basically, um, add on behalf or tweet on behalf of the NFT itself, whoever controls, whoever owns the NFT, be able to chat on behalf of bandwidth to use. So you would, um, your icon, which will app how it works. Um, and see, we're seeing, um, the BNB NFT and science sense between Chester for key of the VOD. NFCU I think it's using the authentication or verification relationship. And that is based on our work with commercial just mentioned. And I think you, if the use case might be really interesting, um, I think it can do what other things between owners of NFTs and creators and so on. I think that's a lot of potential.
Speaker 4 00:38:30 One of the things we talked about in our pre-show conversation is about the use of the term identity in the spec. You use it in a different way than I usually do. And I've written a lot about, um, you know, sort of this quandary that the industry is in about people use identity, meaning slightly different things. We'd like the definition, the identity is how you recognize, remember, and respond to specific people in things including ourselves. And that is independent of how you manifest that mechanism, right? So you might use username password, you might use facial recognition, all of those are forms of identity. I think you made it in a slightly different way. And I just wanted to give a chance to unpack sort of how are you approaching what identity meant in that spec. And is it, is it fair to say that it mostly in the spec, you mean identifier, which I think is sometimes true?
Speaker 3 00:39:22 Yeah. That that's actually very fair to say, as we speak, there's a PR that is, uh, in draft stage to correct the spec. And this is based on, on the pre show, uh, call. And we were actually a very aware of this, uh, difference in, in, in semantics. And we were planning to, uh, change this anyway. So, uh, but thank you for the heads up.
Speaker 4 00:39:49 Anything I can do to advance the cause of decentralized identity.
Speaker 3 00:39:52 Yeah.
Speaker 4 00:39:55 If Sirium recently announced a fairly significant change to, um, I guess how gas prices are set or configured, this is EIP 1, 5, 5, 9. I don't understand it fully, but I'm curious how it interacts with did ether, uh, whether it changes it or it gives opportunities for future things. What does it mean for did ether?
Speaker 3 00:40:16 We're hoping to get in? It would mean a reduction in gas costs, uh, for, for, uh, transaction updates. Other than this, there is nothing, there is no direct influence, actually. It's just the, uh, the way transactions are, are going to be sent. Now, TCO might have different costs calculation, let's say, but it doesn't really affect the existing infrastructure.
Speaker 2 00:40:39 And, uh, what about kind of looking even more forward to a Ethereum 2.0 is a big topic. I know. Is there any expectation of that, uh, changeover really affecting, did either in any way?
Speaker 3 00:40:55 Yeah, I expect there will be change. There will be changes once that is happening, but I think that the existing infrastructure would still exist. So the debt ether created now would be able to live, um, for, uh, longer than if the point. But, uh, I think after if the 0.0, uh, is a thing, some, some, either a new dataset that similar to the Deezer or, uh, an update, uh, for the current one, uh, might be one of the things. But, uh, I, I cannot speculate exactly how that would look right now.
Speaker 2 00:41:32 A lot of people are waiting for it. No one really knows when 2.0 is going to be.
Speaker 3 00:41:37 Uh, one thing to mention here is that since that ether is also, um, already deployed on multiple Ethereum networks, it's, it's likely that, uh, east 2.0 will only affect, uh, let's say mainly it, if it affects it at all, while other networks or other EVM chains won't be actually affected by it,
Speaker 1 00:41:58 I've heard you both mentioned gas costs a couple of times in our conversation today. And, uh, for me and for other listeners, what is that? What does a gas cost?
Speaker 3 00:42:10 Right. Uh, I can try to answer that. So, uh, on, on Ethereum, when you want to send a transaction, there, there is some code that is executed and the developers of Ethereum, uh, thought of a way to limit the number of instructions that could be, uh, executed by that code so that you don't, you know, cause denial of service or make, make notes, get stuck in a loop. And this mechanism is, is gas. So every instruction on Ethereum costs a little bit of gas. And if you want to send a transaction, for example, that ex executes some code, you can specify a maximum amount of gas that you would like to be spent, and you can also set a price that you're willing to pay for this gas. So essentially, uh, the price of computation, and this is, uh, like the gas price will vary based on demand, the gas amount that is actually used. That's going to be static for the same transaction. The same amount of gas will be used, but based on the, the, the load on the network, you might be required to pay more or less to get your transaction to go through. And since I'm updating the ether documents right now, costs, uh, gas, uh, this means that on, on easier networks that use actual, you know, uh, value, uh, for, for gas that will cost some, uh, value some money.
Speaker 5 00:43:44 Yeah. So gas, gas, it just refers to the fee or price, um, conduct the transaction, my ex if she would, uh, a smart contract on the Syrian blockchain.
Speaker 1 00:43:55 Great. That makes sense. Now I understand a little bit more. Thank you.
Speaker 3 00:44:00 Moving
Speaker 1 00:44:00 Onto our next segment. I have one other question, actually, just to reflect back what I heard about a little bit of the history here, as I understood it, there first was a, you poor you part designed, uh, something that looked like, uh, did method and that sort of went away. And the next iteration was, did ether that was created by Newport. And then, um, the two of you stepped in after that to manage the, did either spec and, and now are running it forward. Is that the right progression of, of what happened?
Speaker 3 00:44:36 Yeah, just as trivia. There was actually another did method in between how did Eve, which was sort of like did key, but without the limited to set P uh, 2, 2, 5 61, so it didn't have any update capability. It was just like, uh, wrapping a key and, uh, sort of at the same time, there was a date NACCHO, which is also like the key sort of a precursor would be, we could argue, uh, for that key that, uh, wrapped EDD 2, 5, 5, 1 9 keys. So we were using this for both signing and encryption, uh, for, um, ephemeral DVDs. This was also like not updatable. So it's, uh, both of them, both of them were very similar to the key, but there, there were jobs along the way.
Speaker 5 00:45:27 It's not registered with nectar or even a history. Yeah. There are already already enough with message.
Speaker 1 00:45:38 Right. But it's great. It is great. I love trivia. It's good. And a good history about how the development came around. So thanks. Thanks for that.
Speaker 2 00:45:46 Moving into, uh, the end of our show here, what's next for did ether, do you have any plans going forward? Are there updates to the spec? We know we have, uh, some languaging updates around the term identity, so what's next for D did he say,
Speaker 3 00:46:00 Um, so there are a few plans that they stood a resolver back, which, um, would allow us to support multiple key types in verification relationships. Right now, there is sort of a limited set of key that are, that are, um, described in the spec, but we could describe a bit more and there is a proposal to reduce costs even further by having like smaller events names for, for these key updates. There is also a need for a more expressive service century than just the type and the URL. Uh, especially for dotcom, we would need to express like, uh, routing keys or, uh, stuff like that. That that is not possible right now. So, so we need to update the way, um, services are updated in the document. There is also a plant updates to, to support initial values, which would allow you to bootstrap a larger document from a slightly larger identifier, uh, than just the public key, and also focus on more layer, two situations.
Speaker 3 00:47:10 So maybe some cost reduction there, and there are all also because there's, this URC 10 56 can be deployed on multiple networks. There, there are also like possible updates that could be done if we were able to, uh, change the, this interface, which like off the top of my head would be, uh, using different types of keys for the initial identifier. So you just start with a key, for example. And also after the spec, after, uh, 10 56 was written, there have been sort of like standardization attempts for what we call Metro transaction or what we call contract signatures. So they, all of these have their own AIPs with their own, uh, sorry, their, their own ERCs with their own contract interfaces, which would probably be best if they existed as like, uh, one, uh, definition.
Speaker 4 00:48:10 And where is this work taking place? How can someone get involved?
Speaker 3 00:48:13 It's all the stuff that I mentioned about the resolver, uh, that would be in the ether, dead resolver, uh, repository and get hub, uh, which is hosted by the decentralized identity foundation. And for the ERC 10 56 updates. There is an ether did registry repository that holds the, the con the reference contract code, but updating that for the current resolver would not be really possible because, uh, the contract doesn't have any update capabilities. So if we wanted to update that, we would probably need to create a new debt method or something that referenced the old code as well, um, in a way, but that's, that's sort of our scope right now.
Speaker 4 00:48:59 And just to clarify what types of changes would need that level, I guess that's the question? What types of changes are you talking about that would, that would be more complicated. It needed a new contract.
Speaker 3 00:49:10 So I mentioned earlier the using different types of keys, for example, for as the initial identifiers and changing some of the methods, signatures to be compliant with the other ERCs that were developed after the EA 10 56 was, was published.
Speaker 4 00:49:28 And what'd, you need to change that smart contract to support additional properties.
Speaker 3 00:49:33 Um, I guess we would only do that if, if required right now, we don't feel the need to support other types of things in the contract. So we can use this, the existing infrastructure for quite a lot, but if it ever, ever became a requirement, like if, uh, suddenly events, uh, disappeared from, from Ethereum, we would of course, need to change the contract to no longer rely on events. Yes.
Speaker 5 00:49:57 So, for example, if you just want to add routing keys to the useful outcome, which are additional properties in the document, then you don't need to change the ESE 10 46 contracts, because since the interface already allows, that only thing that would need to change is to resolve a code. So how to enter in the spec, the bit the suspect, um, but you don't need to change anything in the deployed registry to, um, to support additional properties, the document properties and so on.
Speaker 4 00:50:26 Okay, great. So for organizations that like some of the dead properties that are in the dead spec registries, they can support that at the resolver level without needing to update the underlying smart contract. Exactly.
Speaker 5 00:50:39 And if you all want to get involved in deciding on the future of the easterly aspect, then I think the best place to go is to go to the decentralized identifier. So decentralized identity foundation repository, the spec is magic match error system create the issue. So we can have a conversation there and then come to consensus and then change the spec. So this is how the spec actually was
Speaker 4 00:51:03 Excellent. We will put URLs in for those repos in those groups. So we'll, we'll round the corner to make sure we're getting the right URLs.
Speaker 2 00:51:11 We have a question we'd like to ask everyone at the end, but what did method, other than that either is your favorite? I think that's been the answer like 80% of the time we've asked that
Speaker 4 00:51:26 Question. Maybe we should give away the Diddy awards and, uh, did key would definitely win for, uh, the, the most favorite to hit method out there.
Speaker 2 00:51:36 All the people that are making other methods like did key.
Speaker 4 00:51:38 Is that the same for you America? Yeah. Yeah.
Speaker 3 00:51:41 While we're here, I would like to also give a shout out to get web maybe because it brings everyone that's outside of the dead space into this space. So even though it's not really what we are, uh, you know, uh, proud of, but you know, it, it serves a purpose,
Speaker 2 00:51:59 Always good to have a bridge, like,
Speaker 1 00:52:02 All right. And as a followup to that, we'd like to know if you have any announcements or what we call shameless plugs or shameless plugs.
Speaker 3 00:52:10 Uh, so we cannot, uh, end the show without mentioning the project we're currently working on, which is, uh, called . It is a framework for multiple dead methods and multiple verifiable credential standards to coexist and to work together and to create did agents that can act, uh, and do did NVC stuff. Yeah, it's a, it's a, uh, TypeScript framework. That is a multi-platform. So you can use it in, you know, backends frontends mobile, wherever that tries to bring together a lot of these standards that are going on and protocols that are being developed into a coherent package so that people can come into the space without too much knowledge of the underlined, uh, problems that still exists.
Speaker 5 00:53:03 Yeah. It supports, um, you know, Creighton, uh, issuance of air confidentials, uh, in various forms, the native fleet supports the JWT verifiable credentials, but we have now a ending, um, PR that supports and supports that adds support for LD proofs. And you also have a first version of did come back to that conversation in the vacation that is developed in the deaths and previously in the Airbus project and excited about this.
Speaker 4 00:53:34 So for Venmo, is your output largely software, or do you also offer like production services that are running in the cloud
Speaker 3 00:53:43 It's software that can be deployed? So we offer some, some guidance on how to deploy, uh, agents, uh, based on, on the ground framework. So, and also, uh, part of the same repository, there's a command-line application that can also be launched as a server. So you can, you can run agents as a server. There is another team in consensus that is using the VMO package to host, um, agents, uh, and other like functionality. And they offer, uh, you know, as a service, uh, kind of package.
Speaker 5 00:54:15 And the other team is searchable.
Speaker 3 00:54:17 Yes. Sorry. I forgot to mention that
Speaker 4 00:54:20 Certeau that's se RTO is that rice and I have announcement, which, um, Oliver already touched on, which is that the did core specification is now formally a proposed recommendation at the W3C. This is the final step before it becomes a publish global standard, um, which the W3C calls a technical recommendation. And so there's a window here. If, if you or your company are members of the W3C, it's your chance to vote, to adopt that document. And if we get this podcast out in a timely fashion, we can actually use this as a reminder, but chances are, you've already voted for it if you've heard about this podcast. But if you haven't talked to your AC rep, make sure that they vote. Yes. So that we can actually turn this into a proper standard. And that will bring us to the end of our show today. Thank you, mayor chair. Thank you, Oliver. And thanks also to our staff, our producer, Eric Connell, and my co-host Eric Shu. I'm your host, Joe Andrew, wherever you are,
Speaker 1 00:55:20 Find the rubric podcast. Please take a moment to subscribe to our feed. So you'll be notified when our next episode is released. We look forward to you joining us next time. The information opinions and recommendations presented in this podcast are for general information only. And any reliance on the information provided in this podcast is done at your own risk. The views, thoughts, and opinions expressed by the speakers in this podcast belong solely to the speakers and not necessarily to the speakers, employer, organization, committee, or other group or individual.
