Episode Transcript
[00:00:06] Speaker A: Welcome to the Rubric. I'm Eric o'. Connell.
[00:00:08] Speaker B: And I'm Eric Shue.
[00:00:10] Speaker A: Today on the show we talk with Ryan Grant, Will Abramson and Joe Andrew, co editors and implementers of the DID BTCR2 specification.
This is part one of a two part interview. Part two of the conversation can be found at Rubrik.
[00:00:28] Speaker C: I mean we could rag on BTCR easily. It had so many problems.
[00:00:35] Speaker D: 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 our listeners that's you can make better decisions about which DID method is best for your use.
[00:00:51] Speaker A: 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:09] Speaker B: DID methods are the magic ingredient that give DID 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 include the name of its method in the identifier itself. The 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:34] Speaker A: Different DID methods use different underlying mechanisms with different performance, security and privacy trade offs.
[00:01:41] Speaker D: 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:01:51] Speaker A: Ryan Grant has been working in Self sovereign identity since 2016.
Ryan, you were on one of our first episodes about didbtcr. Welcome back to the show.
[00:02:02] Speaker E: Thank you. It was fun and it's going to be fun again.
[00:02:05] Speaker B: Well, Abramson has a PhD in cryptography and Digital Identity. He currently chairs the Decentralized Identifier Working Group and the Credential Community group at the W3C. Will is a Senior Engineer at Legendary Requirements with a major focus of his work being the research and development of the DID BTCR2 DID method. Will, you've been a co host on the show. Welcome as a guest today.
[00:02:27] Speaker F: Thanks. Good to be here.
[00:02:29] Speaker A: Joe Andrew is the president of Legendary Requirements, a requirements engineering consultancy specializing in decentralized identity. He's the editor of the Use case documents for W3C decentralized identifiers and Verifiable Credentials. He's also published a primer on functional identity and Five Mental Models for Identity.
Joe, you're usually hosting the rubric. Today you're a guest. Welcome to the show.
[00:02:54] Speaker D: Thanks. It's kind of fun to be on this side of the interview.
[00:02:57] Speaker A: Great. Let's get started.
Did BTCR2, the DID method, formerly known as BTC1, is a censorship resistant DID method using the Bitcoin blockchain as a verifiable data registry to announce changes to the DID document. In your own words. What is did BTCR2?
[00:03:18] Speaker E: So BTCR2 is an extension of things that we learned working on btcr and it explores a variety of techniques that we thought up along the way. And it really focuses on resistance to censorship and efficiency in cost and energy usage regarding blockchain space.
And we're also very interested in privacy and we've got some non correlation features that very efficient DID creation allows. You can basically have more dids. And we're working on software that also uses those extra dids in more pairwise relationships.
[00:04:10] Speaker C: And then the last thing that we.
[00:04:12] Speaker E: Really aimed for is non repudiation of the type that you would want for a serious contract.
A contract that can not only say, yes, I'm signing this now, but with the proper did, you can prove that you have maybe not signed something else, such as you don't have two primary residences. That might be something that might matter for a loan. And that is also relevant in the news lately.
[00:04:39] Speaker D: One of the examples I like for that one, Ryan, is a digital receipt where if you have late publishing, then you may go buy the, you know, the thousand dollar computer and get a digital receipt. And if they can repudiate it, then when you bring it back for service, they may have manipulated the VDR and the receipt now looks like it is not signed by the vendor who sold it to you. And so that's just a concrete example where we do rely on these documents in a way that they need to be able to say I signed it. And that's knowable, like they can't take it back.
[00:05:13] Speaker F: Yeah. And if I was trying to try and sum up what Ryan said into a sentence, then I would say did BTCR2 is a decentralized, censorship resistant, scalable DID method that's really been developed and design over the past three years. So it's had a lot of effort put into it. And we have this method that we think is useful and usable and is decentralized where a lot of people have stopped focusing on the decentralized aspect or are struggling to realize these properties.
[00:05:46] Speaker E: Yeah. And to even boil that down, A little more, we could say BTCR2 is the premier did method for self sovereign identity.
[00:05:55] Speaker B: That's a lofty goal. I suppose that leads into. We've done a podcast with btcr and I think you already spoke to many of the features that might answer this question. But what are the primary improvements to the BTCR did method that BTCR2 provides?
[00:06:09] Speaker F: I can speak to one of them. I mean, a key one that we focused on initially was offline creation in DID btcr. To create a DID btcr, you had to get a bitcoin transaction accepted in into a block at a specific height so you could reference that transaction. It was the reference to that transaction that was the identifier, the method specific identifier. But the problem with that is a transaction accepted into a Bitcoin block takes 10 minutes, or depending on your security guarantees that you want up to an hour. We wanted to be able to create did BTCR2s without any dependency on any other party. So individuals did controllers could spin off as many DID BTCR to identify as they want without relying on or having to depend on any external systems.
[00:06:58] Speaker D: Another big feature that we improved on was the risks of late publishing. The way that BTCR let you specify additional features in the DID document was with, I think it was called a continuation document. But the bitcoin reference would point to a URL and you could go to that URL to get the rest of the DID document. Conceptually, the details, you, you can go read the spec in that pattern. The person who's hosting that website could change that document. And so that's kind of a form of late publishing. Didion also had late publishing sort of baked into it. And so in light of both of those, we were like, well, is there a way we can have scale, some sort of aggregation, but also avoid this problem where people can change the DID document after the fact. And I think we've made good progress with that. Yeah.
[00:07:46] Speaker E: And we started with the question of what do we allow if we have aggregators that can collect more than one DID document update for a single bitcoin transaction?
And as we kind of pushed that idea, we had to think for quite a while about the change in the meaning of the key that you are using to affect your DID document update?
Because in btcr, that key is the same key that is moving the transaction on the blockchain.
But in BTCR2, you now have participation in a larger cohort, and the owner of that UTXO is either a cohort or theoretically even someone else. The aggregator and so we had to think a lot about how to validate and control the DID in a provable way without letting someone else take it over and without that aggregator blocking your updates.
And we think we found some good solutions to that.
[00:09:17] Speaker F: Yeah. And I'll just add to that. Ryan is talking about this concept that we've introduced in BTCR2 called a beacon. And a beacon is something that is defined by a bitcoin address and spends from those beacons announce updates. And they can announce a single update, but also they can announce many updates aggregated together into a single bitcoin transaction. And that's how we can achieve scale.
Also, the updates themselves are secured by verification methods within a DID document, within that D.I.D. that's being updated D.I.D. document. It's kind of like there's these two authorization structures. One is secure your updates using cryptography in your DID document. The second is spend a transaction from a beacon that is identified in the DID document as well.
[00:10:07] Speaker D: One of the other things we did was we provided a way for the controller of the DID document to choose to keep the elements of the DID document or updates to the DID document private.
There's a presumption in a lot of the DID work that DID document access is public, so that if you have the did, you have some sort of guarantee or expectation that you can resolve the DID and get back to cryptographic material to secure your interactions with that identifier. But Ryan convinced us there were some good use cases where in fact you want to keep it private because you don't want to share your service endpoints or all of your authentication and authorization keys to the public. And so we'll talk about later how we came up with this mechanism whereby the content of the DID document is anchored on chain, but it isn't available to the public in certain configurations.
[00:10:59] Speaker C: Yeah, optionally. So we certainly support, you know, the public DID for your long running identity, your professional identity, say, where you do want all of that easily resolvable and you want people to be able to find whatever your newest address is in whatever the newest social media site is. But the pattern that we were able to introduce is, especially with all these offline dids, there are lots of things, say, for the Internet or for internal to your company, where there's no reason that you need to share them outside of the set of cohorts that are your relying parties trying to verify your DID document material.
And we found a way to keep that private, if you. Private, if you. And they agree, because once you're handing once you're showing someone else your DID document, you know that's out of your hands.
[00:12:06] Speaker A: Right. So you have talked about the. Some of the limitations of DID btcr. What about limitations of other DID methods that you were seeking to improve. Were there any chell?
[00:12:18] Speaker C: I think you're the best person to talk about late publishing.
[00:12:23] Speaker D: Yeah, I was trying to think if there was something other than that.
[00:12:27] Speaker C: I mean, we could rag on BTCR easily. It had so many problems.
[00:12:33] Speaker D: You know, one of the, I mean, a lot of this we address with btcr. I think, you know, offline publishing is a big problem that we address. But BTCR also had that. I think the other methods that we learned from, for example, taught us things as opposed to us innovating above and beyond them.
So, for example, DID Ether, which is one of the earlier DID methods, came up this way to use a key that is compatible with Ethereum, even if you're not on chain. So that was where we got the pattern that we're using for this. You can create it off chain. And only if there are updates to the DID document do you have to put anything on chain. So that was something we learned from DID Ether, but it wasn't on a BTC did, and so we wanted it on Bitcoin did. So the limitation of the other method was that it was on Ethereum.
We want an identifier architecture that's on Bitcoin. And I think that was a huge driver for us.
[00:13:34] Speaker C: Yeah, that was invented by Christian Lundqvist and he was basically doing great work in the space at the same time we were. And he got to that one first.
And it separates the idea of I'm creating a thing and I need to write to this blockchain from the idea that, well, I can read from this blockchain.
So you do need to be able to read from the blockchain to verify the did.
[00:14:07] Speaker F: I was going to say the other DID method that certainly we learned from and improved on is Didion. You know, Didion were doing things on Bitcoin. So we definitely were looking at their work. They kind of made some progress towards aggregation and scale, but their method had some limitations. Where to as a resolver to resolve DID ION identifiers, you had to be scanning and processing every single Didion transaction that was ever broadcast on the Bitcoin network.
Whereas in our approach, resolvers have a much more limited scope. They only need to process the Bitcoin transactions that are relevant to the dids that they care about to the DIS that they are resolving.
So we were concerned that, you know, to actually in practice run a DID ion resolver, you would have to have a lot more energy and be a lot more intensive system that would create centralization.
[00:15:04] Speaker D: Yeah, it really was designed for big operators like Microsoft or Google who are going to have a data center and they are happy scanning all of the updates in all of reality. I think there's something you pointed to earlier, Ryan. The fact that they have access to all of that information is not a design feature. I think it's a privacy nightmare because they're getting some interesting metadata and we don't really know what they can glean from it, but they are putting these large actors in the center. I really like what we were able to come up with. The resolver only pays attention to the dids it cares about, which lets us have small compute footprints so that we can have more democratic resolvers rather than these big monolithic super centers.
[00:15:47] Speaker C: Yeah. I'll add to Will's thoughts about Didion. We did a really long analysis on whether it was even necessary to create another DID method after Didion arrived.
I mean, it, it did solve some bandwidth problems with access to the number of on chain transactions required and it did allow the unilateral action that you need to avoid censorship. And Joe and Will had basically added. Well, Joe had added the reputation wording to the didcore spec and so he was able to kind of focus on that. And then Joe and Will came back and said, yeah, that's a real problem. And here are some use cases where it really matters. They helped me understand that. And then another thing that was going on was maybe not specific limitations of other DID methods, but I had this general sense that there was design space that was unexplored.
And I knew that I wanted something without privileged nodes where not only is there like, you know, it's decentralized, there's more than one you can join with your data center class machine as well. But I wanted something that theoretically everybody could run on their own phone.
And peer to peer people can validate dids between their two phones without engaging any other parties in the ecosystem and merely reading and receiving blockchain bitcoin blockchain transactions.
And so that's, I think very unique in DID methods that can also be rotated.
Now there are lots of DID methods where they just give you a key.
And yeah, you can do things with just a key, but this is a DID method with full support for key rotation and, and that mix of peer to peer capability and full like all of the crud in the DID method spec that's unique here.
So we've mentioned, I think, this hidecar data already in this conversation, but that's what led us to this more peer to peer friendly way to send data to the validator.
[00:18:23] Speaker D: I don't think we've introduced sidecar data. Well, actually we talked about the privacy feature of it, but we didn't explain the sidecar data was how we got there.
[00:18:32] Speaker C: Okay, now's a good time to.
[00:18:35] Speaker B: Well then maybe I'll throw it right back to you guys and ask the.
[00:18:39] Speaker D: Question.
[00:18:41] Speaker B: Could you explain sidecar and sidecar data and what its purpose is in BTCR2?
[00:18:48] Speaker D: So sidecar data is data in addition to the did itself that the resolver uses to confirm the provenance of the history that is indicated on the blockchain when the resolver is figuring out the canonical DID document that should be returned. At this point in time, it reviews all of the updates that we found on Bitcoin and, and needs to have, not only on the bitcoin commitment that says a particular update was applied, but the actual update, which is an edit to the DID document, also must be provided. And so the collection of updates can be provided as what we call sidecar data, which means that if you are not in communication about that data with the controller, you simply can't reconstruct the DID document. So, so one way to publish sidecar data would be like in a PowerPoint presentation. Like if there was a situation where I'm talking to 1,000 people at a conference and I want them to use this did, I could potentially, in my material that I distribute, also provide them sidecar data. Or I could provide an endpoint and they reach out to me and say, hey, do you got that sidecar data? Or when I communicate the did, especially if it's in an interactive channel that along with that DID I provide the sidecar data.
[00:20:12] Speaker C: I think this is a good time to point out that it is possible to create and use BTCR2 dids without needing to communicate any sidecar data to relying parties. It's totally optional. And our method for publishing that data when it's not sidecar data is to say we're using content addressable storage, and that means ipfs or some similar system.
[00:20:50] Speaker F: Yeah, and I guess I would finally just add we're using the bitcoin blockchain to anchor updates in block time in bitcoin block time. It provides us some global ordering of these updates. But what it doesn't provide us, the bitcoin blockchain doesn't provide the updates, it provides a means to validate some updates if we have those updates against the information that is anchored to the bitcoin blockchain. So resolvers have to retrieve this information from somewhere.
And one of those places might be sidecar data. Another place might be content addressable storage like ipfs.
[00:21:24] Speaker C: Yeah, that's how we get our space and energy efficiency. We do not put this on the bitcoin blockchain. We don't push other transactions out in block space.
We say that's your data to pass around to your verifying resolver and your relying parties.
So on chain, we only ever put one 32 byte op return in one transaction.
And another way that we have to keep this very efficient is that we can scale to extremely large cohorts when bitcoin participants can share a UTXO safely.
So that we only need one or two of these very large aggregators in any given block.
And that keeps things much more scalable. Theoretically, this need take no more block space than open Timestamps does, which is a venerable timestamping service that also uses opreturn data on the bitcoin blockchain.
[00:22:54] Speaker B: Okay, so sidecar data, effectively, it sounds like, serves two purposes. One is it assists with the efficiency of the BTCR2 method in that you only need to post a small bit of data to the actual blockchain for validation, and you can deliver other data externally from the chain itself. But it also provides DID controllers with a way to have more granular control over what data they share with who.
[00:23:22] Speaker C: I think that's right. I think if it's more of a choice between whether you're publishing the data necessary to resolve the update in content addressable storage, or whether you are not publishing it and are just transmitting it to the relying party using the sidecar data scheme.
So we knew we needed to get that data out of the chain, which is a very different philosophy than some other bitcoin DID methods that purposefully drop this stuff in the chain. And I think that for me, that's just the right way to interact with bitcoin.
[00:24:12] Speaker D: Yeah, I'll do a quick shout out to the DID method, btco, which is using the ordinals approach, which does put it on chain, and it's an interesting feature to put your DID document directly on chain, but it doesn't have privacy features. It bloats the chain. I guess a lot of problems with it.
[00:24:30] Speaker C: There's one more thing that's probably appropriate to say here about the cohort size and controlling a UTXO BTCR2 is kind of asking the bitcoin community, hey, if this is going to work, well, are you going to help us share a UTXO safely? And there are a few changes to Bitcoin that could make that safer.
And it's something that's not fully understood. People are not. You do not have a million parties sharing a single UTXO right now in a safe way.
And we're out to kind of put this question into the world and say, if you like this, how are you.
[00:25:23] Speaker E: Going to do that?
[00:25:24] Speaker C: And we have some ideas about using rollups, optimistic roll ups. We can create a scheme using pre signed transactions. We can use within one transaction, we can use Taproot. And if Bitcoin advances its opcodes, pre signed transaction schemes can be greatly improved with either OPCAT or opctv.
And so we're kind of asking those questions and it'll take a lot more adoption before other people really understand what we're asking.
But I know that there are other reasons that people are going to need large cohort shared UTXOs in Bitcoin.
So it'll be something that the community is going to have to figure out.
[00:26:22] Speaker B: Okay, so we've gotten, I think into some decent depth. But before we go too much further into features, I do want to take a step back and ask about the basic crud operations for BTCR2.
So whoever wants to take this, could you walk us through the create, resolve, Update and destroy operations and how those work and maybe in particular for the create, could you talk about what it would be like to create a BTCR2 did directly on the blockchain? We've already covered that. You can create it off the blockchain. So what might it look like if you're on the blockchain?
[00:26:56] Speaker F: So I think actually in didbtcr2 it's best to do create, update, resolve. Because really to your question, Eric, to get a did BTCR2 onto the blockchain, that is the update step.
So for creating a did BTCR2 you have two options. The first option is you generate a SEC P256K1 key pair and you take the public key of that.
You encode it in its compressed form. So that's 33 bytes of data that represents that public key.
And then you take those 33 bytes and use BEC32M encoding scheme developed in the Bitcoin community to encode those 33 bytes plus an additional byte at the start which represents the network and the version of that identifier. So the version is just one. This is the version one of the identifier. The network might be bitcoin or signet or it's really a number, but that number signifies which bitcoin network the identifier will anchor its updates to. So you take all Those and you Beck32 encode it to to produce the resulting BTCR2 identifier. And bec32m encoding also takes a human readable part. It's just a string value that goes at the start of the identifier. And for this version of this type of identifier we use K because K signifies this is a key derived identifier, if you like. The slightly more complex perhaps approach is to bring a to create a Genesis document.
And this is an intermediate representation of the initial DID document that you want to create. Except the identifiers are replaced by a placeholder value. Then we sha256 # a canonical version of that DID document that Genesis document to get 32 bytes of data. And then again we're just running that through the BEC32 encoding algorithm to produce the method specific identifier for that DID. So that's create.
Maybe I'll pause there. I don't know if anyone else wants.
[00:29:12] Speaker C: To take adding a little bit onto the create. You know, the purpose of hashing the document is that that Genesis document is going to control how it is updated using its own beacon, declarations and key material. So anchoring that. It's interesting because the anchor is a totally offline operation. It's just a hash and yet it refers to update pointers, the beacons that will see their data posted online.
[00:29:56] Speaker F: I think that's a great point, Ryan, actually.
But in both cases the identifier, the BTCR2 identifier, is committing to the initial DID document. So in the key based we have a resolve process that basically just can derive the initial DID document from those initial key bytes. And in the Genesis document you are saying this is my DID document and you are committing to it through the hash. And what Ryan is talking about with the beacons is really key is critical that in BTCR2 every did document includes a beacon and the beacon goes in the service array and it basically just defines a bitcoin address. And it's those bitcoin addresses that resolvers again are watched to discover updates and that DID controllers are going to spend from to broadcast and announce updates to that DID document. So if you don't have a beacon in your DID document, you can't update it.
[00:30:50] Speaker D: The main reason for the initial DID document is so that you can add the service endpoints or additional keys or whatever with the initial creation in a deterministic way. We're following the pattern of DID key, where it's only the cryptography of that single key that we can represent the DID document.
We can put a beacon for a singleton update, which we'll explain what that is in a bit. We can guarantee one way to update, but if you want to use a scalable update through an aggregator, then you need to add a beacon explicitly in which you have joined the aggregation cohorts, and then you have the address to put in your DID documents. So that's the main reason that we have this initial DID document construct.
[00:31:36] Speaker F: Okay, now let me talk to you about how you update a DID BTCR identifier, and it's DID document. So the first thing the DID controller needs to do is construct something we call a BTCR2 update. This is a JSON document that defines a few things. The most important thing is the patch. This is a JSON patch object as defined in an IETF spec that really defines the mutation of the current DID document to the next DID document. So that is, do you want to add a service? Do you want to remove a verification method? Any of those things you can define using JSON patch. I guess this is a little bit of an improvement, maybe in our DID method. JSON patch defines an arbitrary way to update any JSON document, rather than explicitly defining operations in the spec like add service. So that's just a slight difference. Anybody can create an update to their DID document that adds any properties they want, as long as they produce a conformant DID DO document.
[00:32:38] Speaker D: Which also means that we're not validating what's supposed to be in that DID document. So some methods will only let you add verification methods of understood verification relationships. Like they're applying some structure, and that could be helpful. But if you wanted to put additional stuff in your DID Document or you want to be flexible to future changes in specifications, that becomes a little problematic. So the JSON patch lets us have completely arbitrary transformations, makes it much more flexible, totally.
[00:33:06] Speaker C: We do check for validity in the in the resolution phase.
[00:33:12] Speaker F: Yes, the transformation has to produce a conformant DID Document, but that DID Document can also contain other properties that just aren't defined by the DID core spec. And that's still fine.
I create this patch. This patch defines how I want to update my DID document.
In the update object, we also have three other properties that are about the update. One is called target version id.
And this is the version ID of the DID document after the update has been applied. So the initial DID DO document that we created is version one. So if I'm creating an update to my initial DID document, the target version ID would be 2.
There is also a source hash and a target hash. And these kind of just create a chain link between the DID documents throughout their version. So the source hash points to the hash of the canonical version one DID document. The target hash is the hash of the canonical version 2 did document. So, like the document, after you've applied this update that you're defining, so that's kind of the update, but there's one extra part which is really important, and this is the proof. So you've created this document that defines your update. Then the didcontroller needs to secure this update. And we use data integrity proof. We explicitly chose to use the capability invocation, proof, proof, purpose.
And we define that to secure your update, you have to create a invocation of the capability to update that DID document.
And this is a new feature, I think, in our DID method, where we're using capability invocation and binding the authority to that DID document. So the capability, the root capability to update a DID BTCR to DID document is deterministically derived from the DID itself.
And it's basically saying the root authority is defined in this DID document, the current DID document for that did BTCR2 identifier. So in this case it would be the version one did document. And you're basically saying the keys that can secure this update must be defined as verification methods in the version one DID document. And those verification methods must be authorized for the capability invocation relationship. That's it, right? We've done all this work. We've got an update. It defines how we're changing the DID document. We've secured it, so nobody else can change it. The DID controller has secured this update. That's great.
But we need to now tell the world that we have this update.
We call this like announcing the update. So this is where beacons come in. So in the initial DID document, as we mentioned, there should be some beacons. These beacons specify bitcoin addresses. To announce a BTCR2 update, you basically select a beacon that you want to announce it from and create a spend from a UTXO that is controlled by that beacon, controlled by the beacons address. We call these spends, these bitcoin transactions, beacon signals.
And beacon signals, as Ryan has mentioned previously, commit to essentially 32 bytes of data in the last UTXO of the Bitcoin transaction and how you announce your update in that beacon signal is dependent on the type of. And maybe we'll go into this later, so I'll just talk to you about singleton beacons. So singleton beacons are the simplest Type where the 32 bytes announced in the bitcoin transaction in the opreturn sort of style are just the 32 bytes hash of the BTC1 update you just created. And so in that way, by expending this transaction from the beacon, you are anchoring that update in bitcoin block time and making it discoverable by any resolvers.
So that's the high level of update. Hopefully it was understandable.
[00:37:23] Speaker D: Well, one momentum is just to say it is this sequence of all of these updates, all of which are anchored on chain, and then all of those updates must be available to the resolver. And so if they have the combination of the commitments on chain and the copy of all the updates, which they either got by content addressable system or they got it by sidecar data or it was the initial deterministic DID document so they could generate it, they have all that. Then they can recreate the entire provenance of the history of that DID document to produce the version of the DID document at any given point in time, since Bitcoin anchors it in time. So we can ask what is the value of this DID document two years ago when they signed this vc?
Or I could ask what are the keys today? Because I'm authenticating the user into an interactive system.
One thing I would add, if it's not obvious, the whole point of the off chain creation is that you can immediately use it without any kind of update.
All of those offline created updates can be updated. So we have the offline creation that folds into updates.
[00:38:29] Speaker F: I think you meant all those offline creators created the documents can be updated.
[00:38:34] Speaker D: What did I say? The updates could be updated.
Yes, I was wrong.
[00:38:41] Speaker C: The consequences of not always using content addressable storage are that you can have a chain of DID documents, a provenance that requires you to hand a specific piece of data to your relying party before they can get to a current DID document, even if your current DID document is entirely public.
And that consequence is interesting.
And it's going to be something that identity wallets need to pay close attention to.
[00:39:33] Speaker F: I think that reminds me, there is a little piece to update maybe that is miss that I missed on the end of that, which is so you've announced your update in a beacon signal in a bitcoin transaction. There's 32 bytes of data now public and out in the world. But there's only 32 bytes of data. Right? That is not the update.
So the DID controller needs to decide what are they going to do with the update that they just created.
They have really two options. One is they could make it public by putting it on a content addressable storage system like ipfs. Two is they could decide to keep it private.
And in that way they just have to associate it in some data store that they own and control.
This is the update for this did and it moves it. That's really it. Then when they come to resolve, they need to provide that as sidecar data.
[00:40:24] Speaker D: Another nice feature of updates we didn't touch on is the resilience that we enabled by.
We have a strong expectation that users are going to have tons of beacons. I don't know more than one certainly. I don't know if it's going to get in dozens. That sounds crazy, but the idea is that you can have multiple beacons for resiliency. Once you start joining a cohort and you're all coordinating to sign the bitcoin transaction and you've created that beacon address, that cohort could fail because people choose to not participate. And so by having multiple beacons, you can have resilience against those types of failures.
And we have the established best practice that is a should, that you should always have a singleton beacon so that if all your aggregation efforts, all your efforts to be nice to the environment and to save money on bitcoin transactions, those could all collapse. But you always have the singleton beacon as a fallback so that you can always update your did. You may have to pay a transaction fee for that one DID, because that's how singleton beacons work. But at least you have that fallback.
[00:41:27] Speaker F: Yeah, and similar on the resilience angle, we allow you to announce your update across multiple beacons. That's not a fail state. You can announce it in different beacon signals and as long as it's the same update, that's perfectly fine.
[00:41:43] Speaker D: Great.
[00:41:44] Speaker F: Seems like we should talk them through the Resolve operation with Resolve. So Resolve, if we start with the did resolution spec, resolve takes in a did, in this case a did BTCR2 and some resolution options.
The first thing to point out is the resolution options is the place where you would submit the resolver in the resolution request would provide sidecar data.
A resolver gets a did. They might get some sidecar data. They would compose, put that in the resolution options and execute a resolution request.
Then the first step that the resolve operation does is generate and verify the initial DID document. They don't look on chain, they need to retrieve and verify the initial DID document against the identifier. And if you remember, the BTCR2 identifier encodes either a 33 byte secp256k1 public key or a 32 byte hash of some Genesis document.
So if it's a public key, they can just derive the initial DID document. Similar to didkey, apart from we have a derivation that adds beacons in there. If it's the genesis, then they have to take those 32 bytes and either look in their sidecar data to see if they've got the Genesis document, or query a content addressable storage system to retrieve the Genesis document. And then from the Genesis document, there's just a transformation that happens which you put in the actual DID itself over the placeholder values. So that's the first step. You've got the initial document. The next thing the resolver has to do is look in those initial documents, the initial document they've just generated.
Identify all the beacons.
So all the beacons, they should be in the service array and they have a specific type BTCR2 beacon. They identify all those, they identify the addresses for each of those beacons and then they start scanning the bitcoin blockchain.
And basically you can think of this as starting from block one of the Bitcoin blockchain and looking block at a time at every single transaction in there. And they're looking for beacons.
In practice, bitcoin block explorers can index the blocks and transactions. So that is a really simple query, but you're basically looking for the first beacon signal from the beacons in the DID document. You are resolving in block history.
So you scan, scan, scan, and then you might find a beacon signal. You find a spend from a beacon address and then you kind of pause your scanning and you have to process that beacon signal. So processing a beacon signal is the act of seeing what type of beacon broadcast that signal and processing it according to the algorithm defined by the type to retrieve and validate some BTCR2 update that was announced in that beacon signal for the DH that is being resolved.
So there are three different beacon types that we support currently in the spec today. Those are singleton beacon. So the singleton beacon case is fairly straightforward. The beacon signal contains in its last transaction output 32 bytes of data. Those 32 bytes of data are the SHA256 hash of a BTCR2 update.
So they have the hash of this data, they now need to find the update that matches that hash. And again, this is the question, like do I either look insidecard data or I look in against a content addressable storage system? So you know, I get the update and I validate it was the update that was announced in the signal, and then I have to apply that update to the DIV document. So I'm basically looking in the update, checking that it's for the target version. So if I'm on the initial DID document, that's version one, I'm looking for the update that's version two. If I discover a version three, then we have that as a fail state because that's effectively await published. You can't skip ahead in history. And then I look at the patch.
The first thing actually I do is verify that it is a verify the data integrity proof the capability invocation on that update. So verify that it is a authorized update from the DID controller. An authorized invocation of the capability to update the DID document.
Yes. So we've processed a beacon signal, we've got an update, we've verified the proof on it. Then we check that the update is the right version so it's applied to the current DID document. Then we take the patch and we apply the JSON patch to the current DID document, like the version one DID document to get to version two. And then the final check is does the target hash in that update match the update that you the updated DID DO document you just produced?
So if that's all matches, then you move on and you're now on a version 2 div document which might have new beacons in there. You continue scanning the blockchain using those beacons and those beacon addresses and just keep going until you get to the end of the, you know, to the current block in the Bitcoin blockchain. So scan, scan, scan, identify beacon signal, process beacon signal, get update, verify the update, apply the update, continue scanning, and that is resolved in a nutshell.
[00:47:13] Speaker A: Awesome.
[00:47:14] Speaker B: And last but not least, how do you deactivate or destroy a BTCR2 did?
[00:47:22] Speaker F: So deactivate is very simple. It's just an update. But the JSON patch in the update needs to add the property to the DID document that is deactivated equals true. So deactivated true. So it's just a JSON patch that adds deactivated true to the DID document. So construct an update, the same as in the update section, announce that update, and as long as you're adding the deactivated true property to the DID Document, then that is considered the activity key.
[00:47:49] Speaker D: And you may choose to remove other properties, but you don't have to, right?
[00:47:53] Speaker F: Yeah.
[00:47:54] Speaker B: It was brought up earlier as one of the new features, but BTCR2 introduces this idea of private DID documents. Could you explain what these are and what aspect of privacy you actually receive as a user of one of these private DID documents? I think it was mentioned earlier that it's only as private as the person you share it with keeps it private. So maybe just talk a little bit more about that.
[00:48:17] Speaker C: Sure, I guess. Private DID Document is not a special kind of DID document. There's nothing different about the format or its use or the verification of it.
The only difference is that the data needed to verify the DID document may not already be stored in a publicly available content addressable system storage. The implication of that is you, the DID controller, need to hand the relying party sidecar data that fills in the gaps for things that are not in publicly addressable storage.
So you can have DID documents where you maintain all of the data in this private way so that you always transmit it to your relying party using a sidecar format.
[00:49:10] Speaker F: But.
[00:49:12] Speaker C: As we stated earlier, they are a counterparty and the risk is that the counterparty may reveal anything you show them. You can't control other people with the protocol. So that. That's the distinction there.
[00:49:25] Speaker F: I think I would add one of the sort of experiences for users of private DID documents is.
It means that your DID has become an interactive did. It cannot be non interactively resolved. And by that I mean there is some expectation that you will be able to provide the sidecar information to the resolver at the time that they are executing that resolution.
Whereas a public version, just from the DID alone, the resolver should be able to resolve the did.
[00:49:58] Speaker C: Yeah, this implication is really interesting for who's in the loop on resolving a did. It means that if somebody wants to resolve your did, they need to be in enough communication with you that you can get them this sidecar data.
And that can be transmitted in an initial QR code if it's a small amount, or it could be bootstrapped through another did, or you could be in a local situation where you make it public in that local situation in a way that they, you know, they get that stuff out of band somehow.
[00:50:45] Speaker F: Right?
[00:50:45] Speaker C: Out of band and sidecar are very closely related concepts.
As far as the resolver or resolvers have a will. What's the name of the extra data field in the universal resolver?
[00:51:01] Speaker F: Well, they take in resolution options, which is just a JSON object that DID methods can specify properties that they want to use in those options. Yeah, we specify sidecar data as a property, right?
[00:51:14] Speaker C: Yeah. Our specification says when you're dealing with a resolver that accepts resolution options, you put the sidecar data there. It remains to be seen what all the situations are that it makes sense to have an interactive DID document, as Will may have just coined. I like that term, but if you don't want that, you can always publish things.
[00:51:39] Speaker A: Okay.
[00:51:40] Speaker D: There's another aspect I want to raise here, which is sort of the fallacy or the hype of the content addressable system. There's a notion that if you put it on ipfs, you don't have to worry about it, but if you actually want to secure your did, you need to keep that content around because it may not be pinned by anyone else at any future time.
So part of this sidecar architecture brought that right in the forefront because the DID controller must maintain all those updates in order to have the resolver pick it back up. And instead of naively throwing it over the wall and believing that IPFS will keep it forever, which is sort of the didion approach, we let it be much more specific in that relationship.
[00:52:24] Speaker C: This is a perfect opportunity to kind of bring in the idea of different business models for different beacon aggregators.
We have stopped the specification at the point of saying what any beacon aggregator does.
They run their own business. They help you get your update into an OP return aggregated at whatever cost is right for you and whatever amount of security is right for you. And one of the services that we expect them to provide is keeping the necessary data for your DID available and online.
[00:53:04] Speaker D: Right. That's great. So your aggregator will help or we expect aggregators to help you with this data storage question.
[00:53:11] Speaker C: Yeah, this is not.
We've made something specification wise. This is one of the most complicated DID methods.
However, it is also made so that users have a great amount of choice. And that choice includes not only how they use it, but what business relationships they engage in so that it is easy to use.
[00:53:36] Speaker A: Yeah, that's great.
This is the end of part one and concludes our show today. The conversation continues on our next episode and that will bring us to the end of our show today.
Ryan, thank you for joining us today. We appreciate that, Joe, thank you. And thank you, Will.
Thanks also to my co host, Eric Shue. I'm Erica Connell. You can find all of our episodes at Rubrik cc. Consider subscribing 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 necessarily to the speaker's employer, organization, committee, or other group or individual.
