Episode Transcript
[00:00:09] Speaker A: Welcome to the Rubric. I'm your host, Joe Andrew.
[00:00:12] Speaker B: I'm Erica Connell.
[00:00:13] Speaker C: And I'm Eric Schue.
[00:00:15] Speaker B: Today we'll talk with two of the authors and implementers of Did PKH, Wayne Chang and Joel Thorstenson.
This is part two of a two part interview with Wayne Chang and Joel Thorstenson about Did TKH. Part one of the conversation can be found in our previous episodes, so I.
[00:00:38] Speaker D: Call this the opera Winfrey method of distribution.
[00:00:41] Speaker A: On the rubric, we talk to the folks making decentralized identity happen. We chat about the technologies and motivations behind decentralized identifiers, including dids, did documents, and did methods, so that our listeners, that's you, can make better decisions about which did method is best for your use.
[00:00:59] Speaker B: Decentralized identifiers enable verifiable interactions without dependence on a trusted third party. So instead of being forced to use centralized verification services like Facebook, Google, or the Department of Motor Vehicles, dids can be created by anyone, anywhere and be used for any purpose.
[00:01:19] Speaker C: 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 did of that method. Once created, each did includes the name of its method in the identifier itself. This is so when you use the did. Others know how to retrieve the associated did document that contains the cryptographic material for verifiable interactions.
[00:01:46] Speaker B: Different did methods use different underlying mechanisms with different performance, security, and privacy trade offs.
[00:01:54] Speaker A: This show the rubric reviews different did methods with their creators and implementers so you can make better decisions about when and how to use dids in your applications.
[00:02:04] Speaker B: Joel Thorstensen is co founder of three Box Labs and co creator of Ceramic Network. He's been working on user centric identity and data since he first joined consensus in 2015. Before diving into crypto full time, Joel studied complex adaptive systems in Sweden. Joel, welcome to the show.
[00:02:24] Speaker E: Yeah, thanks for having me.
[00:02:25] Speaker C: Wayne Chang is the co founder and CEO of Spruce Systems Incorporated, a digital identity startup that focuses on open source and user control of data. He is an active contributor to the self sovereign identity ecosystem and was a former co chair of the w three C verifiable credentials working group. Prior to founding Spruce, he worked on decentralized identity at consensus and built an acquired health tech startup. Wayne, welcome to the show.
[00:02:52] Speaker D: Thanks. Really great to be here.
[00:02:53] Speaker B: Here we resume the conversation.
[00:02:57] Speaker C: Who else has been important to the evolution of DidPkh?
[00:03:01] Speaker E: Well, I think I called him out right before but the world Connect team was sort of early on this proponent of chain agnostic standards and ways of representing accounts and blockchains in an agnostic way, because their use case really called for it. And so that really helped out the PTH standard.
[00:03:29] Speaker D: Yeah. Other call outs I'll have. I think Boris and Brooklyn from fission systems have made a lot of contributions here. They really like more traditional forms of cryptographies, including jots or envelopes for them.
But they too saw we have this community that's really excited to use the technology. There's just no clear technical path or on ramp for that to be possible. So I think they made some great considerations, contributions also, Juan from center is really concerned with how do we basically have best practices so that we can achieve compliance in a lot of parts of the cryptocurrency industry, but at the same time keeping with the same principles that make web three user controlled and focused on autonomy. So being able to solve those problems in the industry with its own technology, I think was pretty compelling. So those are some examples of other folks looking into it.
[00:04:30] Speaker A: Great. You mentioned, of course, your two companies, and then you also mentioned wallet Connect.
What other companies have been involved?
[00:04:40] Speaker D: Oh, I mentioned fission systems and center just now.
[00:04:43] Speaker E: Then there's a few different projects, organizations that have been sort of like, oh, hey, I want support for Tesos or I want support for rweave. I can't really say any particular companies there that are involved, but there's been individuals contributing or individuals connected to some project.
So there's a few different people in the community as well.
[00:05:08] Speaker A: All right, now let's shift gears. What were the political, technical, or human challenges in developing? Did PKH.
[00:05:19] Speaker D: I think it's, what do we call the networks? Comes to mind, because I think that if we called it like, does that mean Ethereum mainnet? Does that alienate other projects that are built on EVM?
Because did PKH ETh could mean Ethereum virtual machine or just Ethereum mainnet? It's not very clear. So I think that those are some considerations that were made kind of early on to keep the identifiers a lot more based on namespaces and things that are just more closer to technical specifications than things like brands.
If we were to do it again, I have to think about what that means. I think there were certain aspects of the EVM that were non standard for Ethereum accounts at the time, for example. So maybe the PKH EVM would be interesting to better strike the balance between human readable and something less controversial based on specifications. So to me that's like one of the things that stuck out in the beginning.
[00:06:19] Speaker E: Yeah, I guess another thing in the chain agnostic standards alliance around these namespaces is what constitutes a blockchain. Is PGP a blockchain?
Not really, but it is sort of like a way of having an account that can be represented, in theory, could be represented as a type ten account id. I think for now we chose not to include PJP or those sort of public key use cases, but there are definitely other use cases.
Is iota a blockchain?
Not really, but it's sort of like in the same space.
[00:07:05] Speaker D: Maybe we could call it a crypto chain, a cryptographically verifiable link of something, because I think PGP does have delegations and that's a form of crypto chaining for this term. So depending on your definition. But I think that the general mo with respect to DidPKH has been. Where are there people already excited to use their key material for things? And how can we define a roadmap to make that safe for them?
[00:07:33] Speaker B: All right, how do you generate a verification method for a did?
[00:07:37] Speaker E: PKH did, I mean, it's fairly straightforward.
You mainly see if I can find an example. You mainly just take the identifier itself, add a type. That's. Let's see if I can find the example.
I don't know this exactly by heart. Type for an Ethereum account is like a sec pk. One recovery method controller, of course, is the dad itself. And the blockchain account id is just like strip dad pth from the dad. And then just put that as the blockchain account id. That's pretty much it.
[00:08:20] Speaker B: Right. But that means it's different for every chain, is that right?
[00:08:24] Speaker E: It's different for every chain because each chain has like a different, or may have a different sort of curve or algorithm that they're used for their public keys.
[00:08:36] Speaker D: Yeah. I think at the same time though, there is a lot of coverage with EVM compatibility though. So that one verification method that's defined for Ethereum addresses is broadly applicable for, I think, probably a majority of users in blockchain.
[00:08:50] Speaker E: Yeah, we estimated that we had support for like 70% at least of wallets by supporting Ethereum type wallets and Solana wallets.
[00:09:02] Speaker A: So I'm still trying to get at the Ethereum address. Takes the public key, chops off a bunch of bits and then you're suggesting that from that Ethereum address, which is in the PKH itself, that did itself, there's some out of band mechanism so that you can recover those extra bits to get back to a public key.
[00:09:25] Speaker E: There's no out of band system for Ethereum accounts. So for Ethereum accounts like bitcoin accounts, I suppose.
Let's talk about Ethereum, because it's simple. You essentially generate a signature, and in order to verify the signature, when you verify the signature, you actually recover the public key.
Based on the signature and based on the message payload that you sign, you can recover the public key. And then in order to verify the signature, you just take the hash of the public key and truncate it and compare it to the Ethereum address.
And that's essentially how you verify a signature.
[00:10:09] Speaker D: This operation is called EC recover.
[00:10:12] Speaker A: I thought for Ethereum you'd said you wouldn't be able to do that for.
[00:10:16] Speaker D: Solana you wouldn't be able to do that because it uses that word's curve. And I'm not certain that you can do Ec recover with that.
[00:10:23] Speaker E: I think actually for Solana we include the entire public key as part of the identifier. I think for Tesos, though, they have like a hashed Ed.
So there, it doesn't work there you actually need.
[00:10:40] Speaker D: Yeah, that's a good point about Salana. So although you can't perform something like EC recover for Solana Keys, Solana addresses are just the base encoded key so you don't lose any information from truncation and things. You can just have the key in hand.
And we call this the hash because it's the identity hash. You just copy and paste it.
[00:11:03] Speaker E: I think one thing that might be interesting to talk about, I don't know if this is the right time, but the way both of us are intending to use PKH is through object capabilities.
So we could spend some time jumping into how that would work and why that's a different approach than sort of what people are doing elsewhere.
[00:11:38] Speaker A: Yeah, that would be great.
[00:11:39] Speaker D: Cool.
[00:11:39] Speaker E: So I can give it a shot and then I'll let Wayne weigh in.
The way this would work is you have like an application that's probably a web application, could be a mobile application, and this can be done in sort of a variety of different ways.
But the simplest way of doing it is the application can generate key pair generate. Then the application wants to request access to some resources that the PKhdad control. So they generate a message saying like, hey, I want access to resource a, B and C. This is my did key.
And can you please sign it and ask validity for a certain amount of time?
And this message is sent to the user's wallet. It's signed by the user. They can read through the message.
Both of us are using this sign in with Ethereum standard. That's just like a standard way of encoding a message payload that's easy to read for users and basically says like give this UrI access to these resources and some sort of like domain binding and maybe some expiry, you send this signed message back to the app. Now the app can take this message and the signature and then go to the resource and say like, hey, sign a message with the did key, refer to the capability that was signed by the PKH did, and now take some action on this resource. So you can essentially very easily delegate from your did PKH to a session key that lives in a user's application or browser. And the reason this is nice, especially for the UX, is in sort of the crypto wallet ecosystem, you always have to confirmation dialogue of like, hey, do you want to sign this message? Hey, do you want to sign this message? Which makes a lot of sense when you're dealing with financial transactions, but if you're dealing with, you're building sort of like some data drive or some social network or something else you don't want to like, for every comment you make, every like you do on a post, you don't want to have to sign like a pop up in your wallet that's just like, hey, do you want to sign this? Like. And so this delegation of access to resources allows for a way better user experience, and it sort of really makes it useful.
[00:14:29] Speaker D: I'd also like to expand on the decentralized social media use case, which I'm pretty excited about. Imagine if every time you clicked the like button or the follow button on your network of choice, you create a verifiable credential that says, I follow this person and you get a copy, and that person gets a copy and you're free to take it wherever you want. After that, you're not locked into a platform and you get complete freedom to decide to rehome to a different platform if you want to. So I think this is really exciting because that is linked to your key material, and you can further, if you want to link your key material to a more human, understandable identifier, such as an ENS name in Ethereum or even a domain on DNS. So I think that this allows us to have a lot of the bones of it. And instead of the platform's centralized database being the authoritative truth and provenance of the relationships in the network, these verifiable credentials that you can have a copy of are the authoritative source. They can also maintain a revocation list that you control or status list so that you can decide to unfollow someone at any time.
[00:15:39] Speaker C: So this is a question from the spec about some language. So I'm going to read a little bit and then I'll get to the question.
In the spec, it says if a did PKH is controlled by a key pair, which is valid for generating a blockchain published did document according to another method, such as did Tezos, did BTCR, or did ether, its did document can be translated to the form of that method's documents and it can be registered there. What do you mean by translated to the form? Is this a formal definition of translation or is there a generative mechanism that can be used?
[00:16:19] Speaker D: I think this is a non normative note about you might have the same blockchain account with a different did method resolve to a different did document because you're using a different did method, but it might be a little novel that the same blockchain account that is used as part of the did is also a valid subpart of a different did method. Right. So I think that was kind of a call out for that is my interpretation. Joel, I don't know if you have anything to add there.
[00:16:47] Speaker E: No, I think that's right. I guess to give a concrete example, there's this other did method called ETHR, which basically is like an on chain registry on Ethereum, and your Ethereum address by default is a PKH did, but you can also register that in the ETHR registry to be a different method.
So this is probably referring to that.
[00:17:12] Speaker D: Yeah, I think one of the things working on a lot of these other blockchain related methods, something that I never really liked about it, was that you have the blockchain account. That kind of implies a specific key pair, but then you give the ability to rotate that to have a different implied key for dids. Right. Whereas on the network, many networks, you're just never able to kind of change that blockchain account's association to the private key. So that always struck me as an incongruency in the architecture for methods that allowed you to have Ethereum address with a certain public address. Sorry, a certain Ethereum address, but you're actually authenticating with a different key for it. So I think that it was nice that we avoided that for did PKH by not allowing rotation at all.
[00:17:59] Speaker A: Another example from the spec you list a did PKh BIP 122 with a long identifier here, which I took to some blockchain explorers to see if they would come up with anything and didn't find anything. So given that address, specifically the one that was in the spec for BIP 122, how do we turn that into a did document with valid verification methods?
[00:18:29] Speaker D: Well, I'd say that it's great that you didn't find it on the blockchain at all, because it means that someone who is operating this identifier can just kind of stay off the blockchain if they so choose right. And to receive a document with a verification method, we do just copy and paste the bitcoin address that's there. As a result, the verification method is implied. As discussed earlier, we do EC recover for bitcoin as well, and you can make sure that it maps back to the bitcoin address. So EC recover will help us recover the original public key. If someone authenticated, assuming that they signed for the authentication or issued a verifiable credential, they'd have basically this ECDSA signature that you could perform EC recover on and get the original public key. So that's the verification method, I guess.
[00:19:22] Speaker E: Just for this specific example, while it's true that you can use bitcoin account that has not never touched the chain, this particular one that you were talking about, because I saw it in your document, I actually looked it up on the Explorer right now, and I can see that there is an account here that had bitcoin on it in the past.
And so I think the reason you couldn't find it in the Explorer when you were searching, you probably copy pasted not only the bitcoin address, but also the thing that comes after bip one, two two, which is the hash of the Genesis block of bitcoin. And the reason we have the hash of the Genesis block of bitcoin is sort of like to delineate between different forks of bitcoin.
So if you want to look it up specifically on bitcoin, you copy the sort of last piece, which is the bitcoin address after the last colon.
[00:20:23] Speaker A: I see. So I misparsed it. That makes sense.
[00:20:27] Speaker D: And in your defense, it's not the most ergonomic read to read the entire hash representing main net bitcoin. So that's definitely something that was a design decision at a certain point. Should we make them as human readable as possible? I was actually team human readable as possible at the time. But basically I think that to reduce a lot of the human problems and controversy that we discussed earlier, we decided it was constructive to just avoid this problem, because what is the true bitcoin is a tough conversation to have.
[00:21:08] Speaker A: But it's fun though. Let's put on our gloves and box it out.
[00:21:13] Speaker E: Ethereum actually, or like the EVM type ten space, actually, much nicer, right? Like mainet is one and then some. Testnet is like three, or robstone I think is testnet and then a bunch of different ones.
Why can we have numbers for ethereum but not for bitcoin? And the reason is that the Ethereum community maintains this list of numbers that map to different EVM networks. So it's easy to do that mapping. And the Casa group didn't have to maintain that list, whereas in bitcoin and some other blockchain ecosystem there was no such list and therefore there wasn't an easy thing we could adopt. And the Casa community didn't really want to maintain their own lists of every other blockchain.
So the easiest pass was just like, let's just take the genesis hash and be sort of done with it.
[00:22:13] Speaker B: Soul bound tokens have been proposed as the web three solution for self sovereign identity. How does did PKH fit into that conversation?
[00:22:28] Speaker D: Let's just kind of back up on what a soul bound token is and where the name comes from. It is not meant to be bound to human souls, as some interpretations may have you believe. I think it was something that is derived from the game World of Warcraft. There are these soul bound items that are stuck to your character and you can't remove them, or rather other characters can't wear them. I think they're yours. And basically that was the concept for these public claims that could exist on a public blockchain. That said, some attribute, some attestation about your Ethereum address. So an identifier, not a person, and often represented as an NFT, or more specifically a non transferable NFT.
So I think that my interpretation of this is that there are a lot of parallels with verifiable credentials. And actually, instead of the holy war of vcs versus nfts, which I think was kind of in season maybe a few months ago, I take the stance that actually an NFT is representable perfectly as a verifiable credential. Using the data integrity proof suites, you could have a data integrity suite that allows a verifiable credential with a claim. I own one of this NFT. You can actually have instructions in there, in the data integrity, in the proof section that says just go look it up on the blockchain with these steps. You don't have to perform any cryptography to do that and make sure that it's there. Right? So I see a solbound token or NFT representing an attestation or claim as basically just a publicly listed version of a verifiable credential. Perhaps it's a more compact version of. If you put a verifiable credential on a public blockchain, but you're trying to do something like establish public key infrastructure or whatnot, is it bad to put things in the public forever and always if they shouldn't go there? Absolutely. So that's why it really depends on what's your privacy model, what's your threat model?
[00:24:38] Speaker E: Okay, so two things did PCH doesn't really care about solbound tokens or any of that. It's agnostic. You can use it or you cannot.
One common misunderstanding though about solbone tokens is that they're public. You don't have to have them be public. You can have them just be like an encrypted blob that's on chain and then users sort of, or even use commitments that are on chain so they can be completely private. And the one benefit you have with sort of encrypted and committed to certain knowledge, proof on chain, is that you can, in theory, well, no one has built this yet, but as far as I'm aware. But you could build a system where you can make proofs of non inclusion. So if there is a registry of something, and the only way to get access to something is to not be on that list, then you can make a proof that you're not on that list. As far as I'm aware. That's not so easy to do with verifiable credentials because you need some sort of public state to do that.
[00:25:48] Speaker D: I think you could achieve it if you had some kind of something akin to a revocation list. Right, but an inclusion proof or something. But that would have to build on top of the VC data model. I think the VC data model could support it. You would need extra mechanisms and maybe that would just point to a blockchain. Right. So I think that it could be compatible. I also like the point that you make about solbound tokens aren't necessarily all on Mainet Ethereum, although I think that's a context that a lot of people talk about them in, or polygon, which are public blockchains. There are blockchains that are built on zero knowledge circuits that the only thing that goes into the blockchain is basically a proof and not the actual data itself. And then Mina is another example of this. And I think that as you look at the spectrum of different types of blockchain architectures, there are some that actually the soulbound token looks a lot like an, you know, digitally signed representation of something, even if it's not JSon. So starts to get pretty blurry to Joel's point. But to tie it back to did PKH, if we were to make a verifiable credential, represent a solbound token and use that in the proof, well, the data subject would probably be a did PKH for ETh or whatever chain it is, and I think that would be a good way for it to tie in. But yeah, fundamentally you don't need to use a sold on token with did PKH at all. They can be totally separate concepts.
[00:27:19] Speaker C: So, moving to wrap up our recording here, what's next for did PKH?
[00:27:26] Speaker E: I think the next thing that we would like to happen is for the spec to get a little bit cleaned up. Right now it's just like a markdown document in the GitHub repo. It's like cleaning up the language and making it into sort of more of something nicer looking would be a good step.
[00:27:45] Speaker D: Totally agree with that. Love the idea of stack work moving forward. For me, a lot of it is also figuring out how this graphs into other did methods to provide more features for users that want it. For example, one thing I'm really excited about is did ens, and it's meant to be a public identifier for anyone or machine, anything but something that's human readable. And solving those problems in Zuko's triangle around human readability, but also consistency and others being able to go to a ETh address and have that resolved to your latest PKh by virtue of who's registered as the authenticator.
I think this helps you lift into more permanent identifiers, like a Twitter handle, and I think that's exciting because you get more use out of it and it's more human friendly.
[00:28:40] Speaker E: Yeah. I'm also interested in exploring sort of ways of leveraging this fact of you can issue object capabilities with these dad PKH identifiers, and then sort of composing multiple object capabilities together to create sort of this meta identity. It's sort of similar to what Wayne was talking about, but not necessarily relying so heavily on chain registers like ens.
[00:29:10] Speaker D: Yeah, I think that there's an effort at the CCG with respect to authorization capabilities, and there are a few other proposed ways to do it, but you need someone to sign off on it at the end of the day. And letting people with PKH or even attached to DNS sign off on a permission slip to do a specific thing I think is a very powerful idea, especially if the permission slip includes that this holder of the permission slip can further delegate some sub permissions. Those are some pretty interesting models that we're enabling, models that allow for users to bring their own data vaults to things.
[00:29:46] Speaker E: There's also a lot of object capability work going on in a working group called UCAN, and their work on that is getting a bunch of adoption in a bunch of different projects as well.
[00:30:03] Speaker B: How can our listeners get involved?
[00:30:06] Speaker E: Well, they can find the didpey age GitHub repo and either contribute a new blockchain identifier. If it's not registered already in CaSA, that can be registered there also.
Yeah, just like build implementations or help with the specification.
[00:30:32] Speaker A: All right, as we move to wrapping up this podcast, we like to ask all of our guests, other than the did method we're talking about today, which is did PKH, what is your favorite did method?
[00:30:45] Speaker E: I think the did method that makes you lull the most is probably the best one. The one for me was actually, I think one Wayne created called did.
Very fun. Did.
[00:30:56] Speaker D: Did.
[00:30:56] Speaker A: All right.
[00:30:58] Speaker D: Yep, that was Charles Lahner and our team. I think that recursion is great. And for me, I think lulls is a good metric. Did meme has been very hilarious from Ori Steel from transmute. I also did ENS because it's human readable, so I'd have to pick between some of those.
[00:31:19] Speaker B: All right, we'd like now to take a moment for our shameless plug segment. Do you have any shameless plugs or outs now? Is the time related or unrelated to our conversation here today?
[00:31:33] Speaker E: Sure. So the project I'm building is called ceramic network, and it's essentially taking these primitives of SSI and dids to create a decentralized data network where data is composable. So people building applications don't have their data siloed into particular, into sort of like their own database. And you can sort of pull in data models from other applications and sort of compose on data in the same way, in the blockchain ecosystem, you can compose on smart contracts. And of course, we're using the ADpkh there for me.
[00:32:13] Speaker D: Spruce's mission is to help users control their data across the web, whether that's web two, web three, web five. We're not zealous about any particular technology, just that users experience more control in the world. So basically towards this we built a suite of software called Didkit. It's written mainly in rust and Didkit has a command line mode. We recommend you check it out and run it locally. We support Didpkh there you can use it to issue verifiable credentials. We also work on a library called SSX, stands for self sovereign anything. It's the best way to install sign in with Ethereum and graft it into didpkh use cases. So please check it out spruceid.com great, thank you.
[00:32:55] Speaker B: Yes, we'll provide links to both ceramic network and the spruceid.com in the show notes so listeners can find the links there and check it out.
[00:33:05] Speaker A: I'm going to shamelessly plug our did directory service, which happens to be the easiest way to find details on any w three c registered did method, including the ones that have been mentioned on the show. Did PKh did did I don't know about this did SSX if that's in there yet, although we could find out because all you need to do is go to diddirectory.com methodname so SSX and see if something comes up. So I guess SSX maybe isn't registered with the w three c registry.
[00:33:38] Speaker D: SSX is just a library. It's not a did method.
[00:33:41] Speaker A: Not a did method. Okay, perfect.
My shout out stands. A diddirectory.com is the easiest way to find out about any registered did method, and I would like to invite both of you, or really only takes one of you. If you add a contact email to your w three c registration entry, you can take control over that listing at the did directory and add a logo. Add additional marketing material, links, images, et cetera.
[00:34:08] Speaker D: Joe, when can we add a did to gain control over that entry?
[00:34:14] Speaker A: That's a great question.
Probably not in the next six months, but we would like to get there. The biggest problem actually is we are anchored right now to the w three registry, which is an unfortunate form of centralization.
But the way that you gain control in the did directory is by we defer to the information in the w three c registry. So if you can get dids added to the w three c registry, that would be a first step to us being able to use that as an authentication mechanism.
[00:34:43] Speaker D: Great, thank you.
[00:34:45] Speaker C: For those that are fans of Blizzard that was mentioned earlier soon tm some people might get that joke.
I'll give a shout out for our did method rubric evaluation site. Did evaluations.com if you go there, you can see legendary requirements evaluations for did web, did ion, and did Varys one.
[00:35:11] Speaker B: And that will bring us to the end of our show today.
[00:35:15] Speaker A: Wayne thank you for joining us on the show. Joel thank you. Thanks also to our staff, our producer, Eric O'Connell, my co host, Eric Shu, and I'm your host, Joe Andrew.
[00:35:26] Speaker B: Wherever you 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.
[00:35:39] Speaker F: 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 speaker's employer, organization, committee, or other group or individual close.
