[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 two of our two part episode. Part one can be found at Rubrik CC.
[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 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:33] 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: Here we continue the conversation.
We'd like to change gears to talk about the people involved in developing and implementing did BTCR2. And we'll start with the three of you. How did you get involved in did BTCR2? Will. Will you go first?
[00:02:10] Speaker E: Sure, yeah. Did BTCR2 was one of the first projects I took on since joining Legendary Requirements way back in. I'm not even sure when.
And it's been real fun, right? Just having a gnarly research project essentially is how it started. Me, Joe, and Ryan just kicking about these ideas and looking at DID Ion, looking at DID btcr, looking at the other DID methods out there and looking at Bitcoin as well, trying to figure out, okay, what's possible in this design space, how do we move the needle a bit further and achieve some of these properties.
And I think it's been, I mean, it's been fun to see that sort of concerted effort over a Long period of time finally start to pay off, start to be realized both in a spec and in implementation. I've really enjoyed seeing that come on.
[00:03:00] Speaker D: I got involved in the same way, although slightly different, that I had been working sort of collaborating with Ryan through rebooting the Web of Trust and maybe some of the W3Z stuff. And I'd been aware of BTCR, been a big fan, was happily advocating it to people I knew who might want dids. We included it in our first DID method rubric. And as our relationship with Ryan advanced, it seemed like a no brainer to say, hey, there were a bunch of things in BTCR that are cool, but there are also a bunch of problems.
Let's see if we can address a bunch of those problems and maybe come up with a sequel that I'll hand it off to Ryan because he's really been the one who drove both BTCR and BTCR2.
[00:03:46] Speaker C: You know, when I think about how I got into this, it's kind of funny. It's all Christopher Allen's fault. He ran into me at a conference and said, you know, you really need to come to rebooting Web of Trust. And I did. And Joe and Christopher were running this conference in a way that I just really enjoyed it. Really.
It felt great to participate as a person in that collaborative environment.
And I think rebooting robotrust has been extremely special in that way. There's been a focus on getting something done. And one of the things that was available to get done the first time I showed up was people were working on decentralized identifiers.
It was really the absolute initiation of the idea.
There was no white paper to read, there was no spec.
And Christopher Allen, Drummond Reed managed Horny and a couple other people were sitting around a table saying, there is a thing that we can do. This design space is open now because of blockchains.
Something is different.
You can have key material that you can revoke without needing a central party to coordinate that revocation, unlike the PGP key servers.
So this was a cool, brand new idea and I really wanted to work on it.
I knew nothing about it. I started that meeting as the scribe. I said, I don't know anything about this, but I'll write your notes down for you.
It turned out to be engaging enough that I ended up as one of the first editors of the draft specification for decentralized identifiers before it had moved to the CCG or into the W3C at all. And I knew that it was going to be the Case that I would be the person most interested in and most capable in advancing the Bitcoin DID method, which I felt was the one that kind of started off the whole thing as a decentralized, self sovereign idea.
So I kept working on it. Here I am.
[00:06:14] Speaker E: Cool. I would just add one other thing.
[00:06:15] Speaker D: To my story, really.
[00:06:17] Speaker E: It is about rebooting the web of trust. Right. I first met Joe and I think, Ryan, you might have been there too. Like you and Dan pape, maybe at Arbot 8 in Barcelona. So I was a PhD student then. That's how I kind of came into contact with these folks and then eventually ended up at Legendary and working with them. So it's been great. And I also say big up to Ryan and Digital Contract Design for really supporting and funding this work for so long. Right. Like, and not giving up, being committed to the decentralization and the philosophy of Bitcoin and wanting to make a DID method using that technology and that has that philosophy through it. I think it's fantastic.
[00:06:57] Speaker C: It has not been an easy slog. You know, there have been a lot of W3C meetings that I felt were completely unnecessary. And you know, we got our formal objections against our stuff and then we had. Then we were the ones filing the formal objections because our procedural complaints were being ignored. Both Joe and I filed procedural objections as well as formal objections.
And that has felt at times like it really wasn't worth it. I mean, if you look at who's sending a lot of messages on what apps, it's Moxie. Marlinspike has brought cryptography and private communications to a lot of people by totally ignoring specifications of any sort and just saying, I'm only working on the app and I can change it whenever I want to.
And here we are doing the exact opposite thing.
But the reason that it seems worthwhile is that it's not just us and it's not just our app.
There is a need to integrate with the rest of society.
And one of the most visible signs of that is the adoption of the true age technology to check your driver's license using decentralized identifiers. So this stuff, it is coming and we can either be totally outside the system or we can have, in the parlance that Bitcoiners are very familiar with, do you want your on ramp and your off ramp or not? And that's what this is.
[00:08:51] Speaker D: Yeah, I want to double down on that connection, Ryan, which is that there is a sea change going on in the world around moving to digital credentials. There are a bunch of standards wars going on, MDLs versus verifiable credentials, all that jazz. But the architecture is to use credentials that are cryptographically grounded.
And I think BTCR2 is vital to enable nation states to accept a reasonable and a trusted and a rigorous user provided identifier.
Now we have to convince the governments to do that, which is a different battle.
But I'm really bullish on BTCR2 because I think it provides a way that that can be adopted by like the state of Utah. They're reinventing how they are handling identity in Utah and the digital mobile driver's license that they're going to be doing are going to have a different framework than most of the rest of the country. And I'm excited to introduce those folks to BTCR2 because I think it solves a lot of problems they're trying to solve.
[00:09:54] Speaker B: So beyond the three of you on the call here today, who else was involved in creating the did BTCR2?
[00:10:01] Speaker C: Specific it's a long list.
We've got Kevin Dean coming in from Legendary Requirements, Dan Pape coming in from Digital Contract Design, Jenny Meyer coming in from Digital Contract Design, and we have contributors in Kate Sills who helped with some early coordination, and gentech who's doing some consulting with Digital Contract Design. And then huge shout out to Marcus Sabadello over at Danube Tech. He is working on integrating BTCR2 with the Universal Resolver, which is not only our Java implementation, but it is the premier well known resolver and it's kind of the Rosetta Stone in the dead world for whether something works and whether a specification is sensible. So Marcus is doing the Java implementation and then we also have another contributor over in the library space from Digital Contract Design, Tay Oster. And with all the folks that I've mentioned there, we're covering Java, TypeScript, Rust and Python. So we're going to have a fair amount of code coverage coming out.
[00:11:32] Speaker E: Yeah. And I would just add it's been really fun to see. It's really this year where we started to have an explosion of all these different contributors coming in and first testing the spec.
Does it do its job properly? Can you implement to it? And also just starting to implement it. It's been fun to see these implementations come along.
Definitely shout out to Marcus being able to develop something in your library and then test it against the Universal Resolver.
Fantastic.
[00:12:00] Speaker A: What's important about decentralized Identity work to you?
[00:12:03] Speaker D: Personally, I think what's most important to me about decentralized identity is that centralized identity often causes unnecessary harms unnecessary oppression, unnecessary limitations of agency, just because the system wasn't particularly designed to deal with all the edge cases and all the situation that you might think of. Because it's hard to have a system that rigorously deals with all those sorts of things. So we have systems today where people are unnecessarily harmed and that just seems like a waste. It's like, you know, it's a transaction cost problem. Like we just don't need that kind of suffering and harm. And I think if we had a decentralized architecture for identity, then we could get rid of a lot of the ones that we just don't need. You know, there are places where it is appropriate for a police officer to point a gun at someone.
There are places where society has realized, hey, there are points in time where individuals freedoms need to be curtailed, but we shouldn't have to give my address to the bouncer at the bar.
Now I'm a white male, I'm not really concerned about it, but I think it's really lame that vulnerable people in this world have to share their home addresses just to be able to get into an adult establishment. I think that's ridiculous. So that's sort of where I'm coming from is I think it's not that centralization is inherently bad, it's that we over relied on it and we figured out a better way to do it. So let's fix this so we can get rid of all that unnecessary problems. It's not going to fix all the problems, but it'll I think, fix a lot of them in a very concrete way.
[00:13:35] Speaker E: Yeah, I think I agree with a lot of what Joe is saying.
[00:13:38] Speaker F: Right.
[00:13:39] Speaker E: I think decentralized identity and decentralized identifiers really enable us to think about a new design space for digital identity systems.
And it's definitely not going to get rid of all these harms, but I think it will reduce them and give more agency and power to individuals trying to navigate these systems. And for me personally as well, I also really like decentralized identifiers as potentially unlocking and empowering people with cryptography. Like public key, cryptography is a key technological innovation that is critical for the future of digital systems and humans interacting securely and with trust. I've been able to verify digital transactions and I think we're only really just at the beginning of unlocking the potential that is locked up in our understanding of what cryptography could do to transform those digital interactions.
And I think dibs are a big part of enabling that. Wow.
[00:14:42] Speaker F: All Right.
[00:14:43] Speaker C: Tough act to follow.
So first, I can't believe we rent our identities and we rent them from corporations.
That is insane. It's crazy. And not only that, but when they want to, for political reasons, they shut people off.
That is double insane. I have lost these identities because I, when I lost my credit card and some bill didn't get paid fast enough.
I lose these identities because I've got a phone number that I didn't use for a few months and then it's gone.
Every, every end user license agreement is, is painful to encounter even though at this point I click through them the same way everybody else does.
[00:15:35] Speaker F: I didn't always.
[00:15:36] Speaker C: I've had business partners angry at me for wasting time reading the eula.
Second, you really need a web of trust to do anything. So that contacts list, that is the stickiness, that is what the big corporations are extracting the revenue from you or through your advertising, through advertising to you. They are, that's their key, that's their stickiness.
You need to be able to interact with others.
And if, if you're not going to be renting your identity, then you're going to have to manage your own web of trust.
That's the next, the next step.
Third, a good web of trust can help you recover from a loss and is actually a key tool for recovering properly backed up funds.
So here we've been talking about you keeping your keys for yourself and your ability to add a new pairwise identity and interact through that and gradually attach meaningful aspects of your life into that relationship the way we gradually do as humans. Here we've disclosed a bit about our professional lives, but not really revealed anything about a personal life.
And yet with, with everyone else in the call, naturally, you know, I have revealed things about my personal life and it's been, it's, it's been a gradually deepening friendship.
So that's important. But you can also use your web of trust to be one of your most important tools for sharing keys and sharing shards of keys and recovering from a loss.
Everything that we're doing is really, it's about securing identity in a self sovereign way and that includes the recovery of it. And then lastly, I was just noticing last night, URLs don't work. I had to change some URLs and I'm realizing, wow, I'm invalidating all these links to this old URL.
Okay, well if only I had a nice redirect that was under my control.
Oh, what would that be? That would be a did.
Okay, I guess there's some concepts here, like if you could actually manage properly these dids, you would have the same tools you need to create URLs that work. So you know, there's just a cute.
[00:18:44] Speaker F: One to throw on the end.
[00:18:46] Speaker E: So I'd just like to add one thing which is really just a double click on something Ryan is saying. You know, we're seeing a terrifying rise of authoritarianism around the world. And these authoritarian actors are able to wield power by exert, you know, like control or like exerting influence on the identities that we are and identifiers that we are renting in these digital platforms today.
Most of our lives is conducted within and across these digital systems. And if we don't, even if we don't even really exist in them apart from by the will of some other person, it's not a good place to be.
[00:19:22] Speaker B: So who do you expect to be using this did method the most? Is there a particular group of people you're targeting? Are you hoping it is universal? Everyone uses it for everything.
[00:19:33] Speaker C: I've got an answer here. I think it's really for people who don't want to lose everything again.
That ultimately is what self sovereign identity is offering now. Our BTC 2 feature set is also your best chance for privacy, but that requires cooperation from your counterparty and your resolver. So whether web of trust networks can stay out of the corporate advertising model surveillance machine that that remains to be seen. But what we can be really good at is we can be really good at you creating something that nobody can take away from you.
[00:20:11] Speaker B: Yeah, I like the framing of your best chance for privacy because privacy is inherently not in your control once you've engaged with someone else. So all you can do is provide the tools that increase the odds, if you're careful, that you can be private but you can't ever guarantee.
[00:20:30] Speaker D: Yeah, I think that's right. I mean we've designed the spec to support as much general purpose usability as possible. Like we've tried to make sure that this can be used as a general purpose identifier for as many use cases as we could think of. But in terms of who's actually going to bother to use it, I expect it's going to be people who already sort of see Bitcoin as a way to improve our digital world in part because they've already bought into the anti censorship features of the blockchain. And so if we can help them move into a digital world where they have greater control than they do today, maybe that audience is who's really first going to pick this up and start using it.
[00:21:14] Speaker E: Yeah, I think I would say people who hopefully are desperately searching for a truly decentralized DIT method, we hope this can be the answer to their desires.
[00:21:25] Speaker A: Awesome.
Now this podcast has been juicy from the start, but often we say this is where we turn our attention to the juiciest bits, I guess. Conflict. So what were the political, technical or human challenges that you've faced in developing BTCR2?
[00:21:45] Speaker C: Oh, wow. Yeah, we had political challenges between the, between the publishing of BTCR and you know, our early work on BTCR 2.
We had that. We had a big fight in the W3C about whether they were going to decide which DID methods are standardized in the DID working group itself.
And that was going to require a group of people who came together for their own reasons relating to their own DID methods to pick each other's DID methods and bless them and pick winners and losers, basically in a committee.
And I could see exactly where this was going. The purpose of, of that request seemed almost entirely to keep DID BTCR out of that blessing and make sure that it was killed early and that nobody had to pay any attention to it.
And this was very obvious because of all the dismissive comments against anything blockchain related that I heard in so many meetings headed dismissive comments by the so called leaders in the field and the chair of the working group at tpac. All of these.
And then, you know, it was also clear that it wasn't just at BTCR that, that people are out to get. There are competing identity standards that are not using the W3C's did standard at all.
And so there were weird requests coming in that had no technical basis and seemed like quite, quite obviously there to distract, redirect and just show the working group that you weren't going to get what you wanted because these other members who were coming in really late started saying, oh yeah, we don't want this anymore.
And you know, then you've got. Meanwhile, at the same time you've got banks denying crypto businesses bank accounts.
I personally had two bank accounts shut down during that era and I'm not even running a crypto business.
[00:24:33] Speaker D: We did too.
[00:24:36] Speaker F: Wow.
[00:24:37] Speaker C: I didn't know that.
[00:24:39] Speaker D: It was about the time I got involved in rebooting Web of Trust and had one or two, probably a Coinbase transaction and I had some international direct wire transfers to support rebooting the Web of Trust to pay for a venue. And the bank just saw this activity and they're like, yeah, we don't want to be your bank anymore. Bye bye.
[00:24:59] Speaker C: Yeah, so there's, there's always more to the story. You know, I was using PL boxes for my addresses as, you know, just a standard safety technique and I'm sure everything looked weird.
I, you know, none of this work that I've done the W3C has made any money. I'm sure that looked weird. Weird.
And sure I'm doing the same thing with international, working with people internationally, sending them money.
So there you go.
That's just off the top of my head.
[00:25:40] Speaker F: That's a start.
[00:25:41] Speaker D: Sure.
[00:25:41] Speaker A: A lot of challenges.
[00:25:43] Speaker D: Yeah. I want to comment on two things. I totally agree that W3C is a fascinating set of challenges.
Arguably was more of a challenge with BTCR and getting the DID method spec adopted at all. We've largely avoided BTCR2 because it hasn't been in a W3C context.
Nevertheless, it's a weird fight.
And the way that the DID method working group incubation is happening between DIFF and the W3C really created two gatekeeper communities that are both trying to pick winners and losers.
And we have been reached out to by people who have DID methods that they want to be blessed and approved to horse trade votes so that they'll vote for us if we vote for them. And I'm like, this is exactly the kind of thing that doesn't lead to better technical standards. It leads to political trade offs and compromises. And I'm really not all that interested in it. The other sort of weird thing that has been a challenge is a perspective by many in this space, and it only indirectly affects BTCR2 that we can solve some of these decentralized problems through surveillance.
This is an architecture that I think DID Carry should get credit for introducing with their idea of watchers and DID Web verifiable history. And I think DID Web S also introduce this notion of watchers and witnesses to observe this decentralized system so that they can provide some sort of authoritative statement about whether or not a given DID has changed in a weird way. And all that to me feels like this weird aberration of, hey, instead of trying to trust a system that has a protocol, I'm going to defer back to a centralized entity and say, I'll just let Google watch all of the DID document history out there and if they see anything weird, I will believe Google if Google tells me that a given DID seems to be questionable. And I have to say I have enjoyed Google performing that service for me in the browser. And so I Get sort of, there's a systemic value of having a gatekeeper who's actually trying to keep you to go from bad to bad websites. I remember once I was looking for some, some software because I moved hardware from one computer to another, didn't have the initial manufacturer's disk. So I went to Aware site, downloaded the driver and Google said, you don't want to go to that site because it's dangerous. It had a big red blocking pop up and I ignored it because I'm like, I know what I'm looking for. I know I'm going to Aware site. Leave me alone.
As soon as I clicked on that link, it took over my computer. I literally powered down and pulled out from the network immediately. And so Google was doing a good job trying to help me. But I don't think that we can get the kind of freedoms we are trying to create with decentralized technologies if we keep reintroducing these centralized parties to help us in that way.
[00:28:43] Speaker B: So turning our attention back to some of the technical specification a little bit, I did want to talk a little bit more about this idea of aggregators.
Ryan, earlier you had mentioned some of the business cases are different way businesses might change structure themselves around these aggregators. But I was hoping that you three could talk a little bit more about the purpose of aggregators and their relationships to beacons within the specification. Often you'll see the term beacon aggregator, I believe in the spec. So just give an overview of really what aggregators are, what their purpose is and how they kind of fit into this space and how maybe an end user of a did BTCR2 might think about the aggregator.
[00:29:28] Speaker C: I think maybe the right split here is for me to just say a little bit about the business function of the aggregator and then to say that there's a lot left unspecified because it is one of those business functions. And then maybe I'll hand it to Will to talk about the technical aspects of how some of the aggregators work in order to have shared control of a utxo. And I mentioned a UTXO earlier. So I'll just explain that that is kind of a bitcoin, that is the unspent transaction outputs that are bitcoins that can be spent.
And when you own a utxo, it means you can control an unspent transaction output and send it to whoever you want.
So these aggregators, we're saying that they're going to be the ones that spend that UTXO and put the Data in this 32 bytes of, of data in the, in the OP return.
Well, if we are also saying that users have control over when their updates are announced to the blockchain, whether when they are aggregated into this single transaction with, with a small amount of data, then what we're really saying is those users have say in when the cohort of other users move that utxo. And that means they are participants in a shared utxo.
So if the aggregator's job then is to be this collective that takes in many people's updates, puts it into a tree and then moves, moves the UTXO onto the blockchain at the right time, I think I could get into more of the details of how that cohort decides to move the UTXO onto the blockchain. This is the part that, that will worked out actually. This is. I gotta hand this part to Will.
[00:32:06] Speaker E: Right.
Okay. Yeah. Maybe I can talk from the beacons point of view first.
So a didcontroller needs to put beacons in their DID document as we've discussed, because beacons are the mechanism that they use to announce updates.
And mostly so far we've discussed one type of beacon and that is a singleton beacon. So that is typically just controlled by the D.I.D. controller and they spend transactions to announce single updates to their document. But there are two other types of beacon that we've defined in our, in our specification. And these are a map beacon and a sparse merkle tree beacon SMT beacon.
And both of these beacons have different approaches to aggregate multiple updates into a single 32 byte bit of data that they can broadcast on chain. And I'll get into that in a minute. But also these beacons are still identified by a single address.
And the way that we have recommended these addresses are constructed is that they use the Music 2 construction. So these are a pay to taproot address that use music2 and music2 is a multi sig scheme. So, so this is basically a Schnorr public key that is like converted into a taproot address. And that Schnorr public key is to spend or to create signatures from that Schnorr public key. It is an N of N signature scheme. So every single participant in the cohort controls one of the N keys that compose the public key. That effectively is the address of that beacon cohort. And I think as Ryan has mentioned, this is just one way that we are exploring how to secure the UTXOs of a beacon and particularly an aggregate beacon. And we would love to have people come along and show us other ways where a cohort of people can secure UTXOs in a way that they are confident of. The reason that we require or recommend, strongly recommend this N of N approach is because every single participant needs to be able to check the beacon signal, the bitcoin transaction that is getting spent from the beacon, from the aggregate beacon. And by having an N of N address, they have to get sent the transaction and then they partially sign it using their one of N key.
And so they get to check what they're signing, then sign it and send that back to the aggregator. This is really the aggregator's role just to coordinate this signing process and also to coordinate the address generation. The aggregator. If I want to join a cohort, the first thing I have to do is create my Schnorr public key, my Schnorr key pair, really. I send the public key to the aggregator. The aggregator is collecting lots of public keys together and then combining them into a N of N address, which they then can send back to each of the participants and go, hey, use this address.
You want to check that your key is in there. And then you can include that address in your DID document as a beacon of a specific type. And then similarly, when authorizing beacon signals, so bitcoin transactions that spend from that address, the beacon aggregator can coordinate that signing process. So Music 2 is a well defined in a bitcoin bit, which I'm not Exactly sure, maybe bit327. Anyway, it's a well defined protocol, but it's an interactive protocol that requires messages going backwards and forwards between each of the signing parties.
So it's quite complicated and we want a central entity that can coordinate that so people don't have to send these messages all around to everybody. So I think that's the main thing that the aggregator constructs these signals, sends them off to each of the participants. The participants then could check the contents of those signals and authorize them independently. So the final thing I'll just talk through briefly is these two different types of beacons. So as I said before, MAP beacon and SMT beacon. So a MAP beacon is a beacon who broadcasts signals where the 32 bytes of data in the OPERA term is a commitment to what we call a beacon announcement map. And this is a JSON document that Basically maps from did so did btcr2 identifiers to 32 bytes that commit to the actual update or that identifier.
So a resolver would have to first retrieve the announcement map document and then retrieve the update that is announced for the specific DID that They're resolving. Then a slightly more complicated one is the sparse merkle tree beacon. SMT beacon. And in this case the beacon signal. The 32 bytes in that beacon signal is a sparse merkle tree root. So it's a merkle tree root, but a specific type of merkle tree called a sparse merkle tree. And the key feature of a sparse merkle tree is we use the dids to index leaves in that tree. And those leaves can either contain data, so they can contain, and in our case they contain updates, or really like 32 bytes that commit to an update for a specific index to that leaf, or they can be empty. And that's the key thing. Like sparse merkle trees can be empty.
So, and the reason for that is if I'm aggregating, say, a thousand dids in a single update, some of those dids might not have updates that they want to, you know, commit to or they want to broad. They want to. They might not want to announce updates in that beacon signal. But we don't want to wait.
The cohort doesn't want to wait until everybody has an update to announce. They need to be able to move on. So I think that's the key thing. So these sparse merkel trees allow leaves to be empty so that divs don't need to update every time the cohort announces a signal. But resolvers need to be able to check for the signal that they're processing, that this signal either contains an update for the DID that they're resolving, or it definitively does not contain an update. And sparse merkle trees allow you to create proofs of non inclusion. And so the resolver would require a proof of non inclusion if the DID controller hasn't updated in that beacon signal from the sparse method.
[00:38:32] Speaker F: All right, so maybe I can add something about the business models that I hinted at in the very various options that exists. Some. Some people will want an aggregator that absolutely only makes updates when they have signed and checked that their update is correct. So only submits beacon signals when. When that user has checked their participation in the beacon signal. And most of the time they'll be confirming that they do not have an update. Other people may want to work with a beacon aggregator that does almost everything for you. It holds the data that you need to do a resolution.
And maybe it has a much more relaxed policy about posting beacon signals to the blockchain by having a special set of people who are designated as the online checkers and signers, and that means trusting somebody else. And BTCR2 is made. So if you want to be the first type of user that does not trust somebody else, but that verifies it yourself, you can be.
But if you want to participate in a business model that makes it easy and allows you to go offline whenever you want without blocking other people's updates, you can participate in that business model. And you can do that.
There's going to be a spectrum of business models about how you authenticate to the aggregator what other services the aggregator offers, how often they are posting these beacon signals to the blockchain, because that could get expensive someday.
Maybe some people want an update once a month and other people want updates every. Every 30 minutes. Those people, you know, they can pick their appropriate providers to do so. So that's part of the spectrum of possibilities that we don't want to incorporate and require in this.
And that aspect is completely outside the spec. How you make that update happen. The spec only says what that update must look like for the resolver to verify it.
[00:41:09] Speaker E: I think there's one last piece to that, actually, which is just that even if you are trusting these aggregators in that way, they can't take over your did. Right? The update is signed and secured by the DID controller. The only thing they might be able to do is invalidate your DID by posting an update that you don't have. If you can't produce that update to the resolver, then the DID must be viewed as invalid. So they can validate it, but they cannot do an update to your DID that you didn't authorize. I think that's important distinction.
[00:41:43] Speaker F: Thank you. Yeah, I agree.
[00:41:46] Speaker A: On the subject of beacons, why are there so many different kinds of them?
[00:41:51] Speaker E: Right.
[00:41:52] Speaker F: So we've already heard a lot about the singleton beacon that is about making sure that you have some way to make your own Bitcoin transaction to keep your DID updated and alive. The other two types of beacons are the map beacon, which is all about aggregation, where your data is public, and we dumped all the simplest ways to have a public DID into that one. And then the sparse Merkle tree beacon is where we dumped all the best options for having privacy.
So the sparse Merkle tree beacon doesn't reveal which dids are in it, which dids are updated, which dids are skipping the update, what the update is, it doesn't reveal any of that. All you can see if you have the sparse Merkle tree beacon address is that you can see that someone, or either someone has updated their DID, or well, they just decided to post another 32 bytes to the blockchain and maybe everybody has a non inclusion proof.
So that's basically it. It's making public accessibility easy to understand and easy to to retrieve versus making things as private as possible.
[00:43:28] Speaker A: Great, thank you.
[00:43:31] Speaker F: I think the other thing I want to hear from Will is what else do we Want to use ZCaps for? So we've got a mechanism that kind of says somebody used a zcap to update the DID document. I can clearly imagine delegating the right to update the DID document in other ways. Are there other things that we're currently already aware of that we would want to delegate that need to be built into the DID method rather than into, let's say the messaging app or the banking app?
What is the DID method and the resolver need to know about versus the app layer?
[00:44:18] Speaker E: Maybe I'll talk about the capabilities first and Joe can help.
I mean, because we haven't actually touched on this much. I touched on it a little bit. The updates that to did BTCR2 did documents are secured using a capability invocation. And this is an invocation of the capability to update the DID document.
And one of the reasons that we chose to use capabilities and specifically the ZCAP LD specification, which is just a data model for defining a capability, is so that we have the ability to delegate and attenuate these capabilities.
So the root capability gives, you know, invoking the root capability gives you authority to update any of the DID document.
But you might imagine it being useful to delegate to a specific key the ability to only add services to the DIDD document, even if it's just your key that you control. It might be useful to have some device that can only add new services, only update your social media profile, for example, but not do anything else.
Any combination of that. Only add verification methods or whatever it is. Right? Like there is that ability baked in to the use of ZCAPs that we have. We still need to explore it further and define the exact language for attenuation. Really. Like what are the different pieces of the document that we can attenuate and how do we describe that? But I think that is a whole possibility space that we enable by using capabilities.
[00:46:01] Speaker B: In this one, I will call out there that that type of attenuation requires something like the beacon to function because you need something that's enforcing the rules of delegation that have been written, right?
[00:46:15] Speaker D: Actually, that's not quite true, Eric. It's the resolver who ends up enforcing those rules.
We don't trust the aggregator in general. That's a strong principle. We Try to hold to minimize that trust.
[00:46:27] Speaker B: But in the case of having an attenuation for an update, there's no inherent resolver involved, so.
[00:46:35] Speaker E: Good. Yeah, but the resolver is processing the updates and checking if this update is valid or not.
[00:46:41] Speaker F: Right. So, Eric, the distinction that's being made here is the aggregator takes whatever is supposedly an update, and it can take an update that kills the DID by being invalid.
[00:46:55] Speaker E: Yeah, it just does what is told and broadcasts it.
[00:46:58] Speaker D: And the resolver applies the business logic to say, oh, maybe we have the zcap that lets us attenuate this thing. And so if the update exceeds that authority, then it's the resolver who would catch that problem.
[00:47:11] Speaker F: Yeah, and the error that the resolver would throw would be invalid did.
[00:47:16] Speaker E: Or invalid DID update. I'm not sure yet. Some error. But I think there is an interesting point in there which usually in the capability architecture, this service, the issues, the capability verifies them. Right. You're going back to that service and invoking the capability to do X within that service. In our system, we kind of have this abstract service which is the DID itself and the capability to update the did. And then the resolver, or any resolver is the person enforcing the result rules that would typically be enforced by a single entity.
So it's a slightly different use, but I think it's an interesting use of capabilities in this.
[00:47:53] Speaker D: I think there was a wrinkle here that maybe Eric was touching on, which has to do with our N of N commitments about the beacon signals and the ability with ZCAPs to delegate an update.
So you can use the ZCAP delegation architecture and let someone else only say update an attestation method. But that doesn't mean that they can sign and update as part of the aggregation protocol. So they wouldn't be able to get that update on Chain unless we figure out how to get it to the aggregator. Now, the easiest way to do that is they send that to the root controller and they're the only ones who actually sign the Bitcoin transactions. But we really haven't teased out, is there a better way to do that? It certainly would allow, for example, if I'm running a large team of 20 or 30 people, I could put myself as a gatekeeper for what goes on Chain, but still let them send me updates with their new keys or their new endpoints or whatever they want to add. But that pattern still has the controller as a bottle deck, and we sort of haven't quite unpacked a better way to do that.
[00:49:00] Speaker A: So.
[00:49:02] Speaker F: The alternative to having a zcap model controlling updates would be to delegate from one DID or from one DID DO document to another subsidiary DID and say regarding services, the services in this document are A, B, C and whatever is in this subsidiary did.
And that's the kind of the competing model. And I think we don't know yet what we can do one way versus the other.
[00:49:38] Speaker D: I'm curious what mechanism you're referring to.
There used to be a pattern that Will and I have touched on where the controller property in the DID document was read to mean that you go resolve that DID document and check the verification methods and stuff in there. That has been reversed because that was a misinterpretation. I actually wrote that line, but that's no longer how the spec reads.
[00:50:09] Speaker F: So yeah, and that I think that was the right move for the spec because it meant that you needed to keep resolving to figure out what the document was and resolvers can't afford that risk.
Yes, I am saying that at the application layer do you keep resolving into another DID in order to figure out what's going on. And this is really a question of what must be in a DID document for a different kind of application to understand versus what can you afford to say, well, this is my DID document. I'm using my local application context.
I can just include stuff from another did.
[00:50:53] Speaker D: Yep. I think related to that is also there's a modest trap of imagining that updating your DID document is is the better way to update your cryptographic material. But often I can sign a statement with one DID telling you, hey, let's use another did.
And if I can get you that statement, then you have a cryptographically rooted bit. It's not anchored to the blockchain. It doesn't have this long term providence or these other privacy features. But I can just tell you, hey, use this other did. And one of the nice things about that feature is I can actually change the DID method.
I could use a DidKey to sign a VC that tells you, hey, stop using DidKey anymore. Now go use Did BTCR2, that pattern. I think especially in some of the applications we've been developing with you, Ryan, if you have a channel with the other party, well, maybe you don't need an on chain update. You just let them know that you have a different key.
I think the balance of which use case uses which pattern more effectively is still to be discovered, but we have both those options.
[00:51:57] Speaker F: Yeah.
[00:51:58] Speaker B: So I understand that with this idea of beacons and aggregators in BTCR2, there's some ideas about future uses for beacons in particular. So I'll toss it to you. Will, what is the future of beacons that you have in mind?
[00:52:12] Speaker E: Yeah, well, I think beacons are an interesting mechanism or concept that we've discovered as part of this work. And I like to think of beacons as. As beacons give you the ability to publish correlatable streams of information.
I think beacons on bitcoin as we're using them allow you to publish correlatable streams of information that are anchored to the bitcoin blockchain.
That's pretty cool. Like anchored in time. In a globally ordered system, we're using beacons to anchor BTCR2 updates right in time.
So we're not putting the updates on there, we're putting commitments to those updates on there.
I think you could use beacons to anchor any structured information in time in the same manner. And I think it's not just information. These commitments are to updates, but these updates are signed updates. From a DID document. From a did. Right. So there is an identifier behind it, not just a bitcoin address.
That identifier is defining the beacons that you should watch, you should listen to.
I like to think of it a bit like a radio station. We've also talked about like a lighthouse as a way, right? Shining a light on the things that you should look at. But the DID tells you in the DID document, look at these addresses, listen to these addresses. They're going to publish streams of information that you should care about.
And the type of information that we're currently using is for updates to the DID document. But that is just one type of information. I think there are lots of different use cases for anchoring information in a globally ordered time system.
So this is just a wacky idea that I chucked around. I think I mentioned it to Joe in Geneva first and I've just been thinking about it kind of ad hoc, but I think beacons are could be broader than just used to announce updates to a DID document. And we've not really explored that at all. But it's an interesting and exciting potential future for this work.
[00:54:18] Speaker B: I'll just give a 30 second note, mostly to remind Joe and Ryan, but I think this thought aligns very closely to the use cases we identified coming out of the Gordian WebKMS original key security questions where we arrived at the point saying that the Gordian WebKMS architecture didn't increase your immediate security, but they could be used to do things like attenuations and rule enforcement, but not to increase your security architecture.
[00:54:57] Speaker A: All right, well we've wrapped up our conflict section, so let's look to the future. What's next for BTCR2?
[00:55:06] Speaker F: A lot of work to do.
[00:55:09] Speaker E: Wow.
[00:55:09] Speaker F: You know we, we are working on libraries.
We've got some spec editing still left. We're headed to Tab conf in Atlanta October 13th through 16th and we're going to start telling other people about it and seeing how people respond.
What do they want?
Do people believe that a web of trust increases their self custody security?
Or if they don't, we'll just learn from them until we, according to my thesis, learn enough to explain how it does increase their self custody security.
[00:56:05] Speaker D: I will also add two other events that some of us are going to be at and we'd be happy to talk the BTCR2.1 is the Internet Identity Workshop in October. I think that's the third week of October up in Mountain View. I'll be there and Erica will be there. And then some of us are also going to be at the W3C Technical Plenary and Advisory Committee. It's called TPAC, which is in November.
So if you happen to be going to that, be happy to chat with you about didbtcr2 and how could people.
[00:56:35] Speaker B: Get involved with didbtcr2 if they wanted to contribute?
[00:56:39] Speaker E: Well, I think, you know it's all open source, right? Like we would love you to read the specification, provide feedback. If you're interested in doing implementation, that would be great. I think all of our libraries, Ryan, maybe correct me if I'm wrong, but I think all of our libraries are open source under development and I guess we can provide links in the show notes. So also I'm sure we would love to have feedback implementers or people using those libraries and integrating the BTCR2 into whatever ideas you have.
[00:57:09] Speaker F: Yeah, wallets that want to distribute shards and use a webatrust for key recovery. Those are our intended customers for the libraries and we want to work with everybody who wants one of these dids.
[00:57:29] Speaker A: All right, we'd like to take a moment for our Shameless Plug segment. Who's got some Shameless plugs today?
[00:57:37] Speaker F: Well, I've got one that's a little bit of a mix with the look to the future topic that we just wrapped up. But I can already see a bunch of things that are going to go into BTCR3 or its better named equivalent and one of those is a zero knowledge proof roll up. We have been furiously simulating and doing back of the envelope calculations to make sure that as these proofs of inclusion and non inclusion stack up in your identity wallet that you'll be able to transmit them to the relying party and they transmit them on to the resolver if there is an external resolver in a timely manner and get your transaction validated quickly.
I think we can take this amount of data that we're sending right now and over the course of 10 years of data stacking up with a BTCR2 setup, we should be able to reduce that amount of data transferred by 10,000 or 50,000 times in a BTCR3 setup that uses a constant zero knowledge proof.
[00:59:00] Speaker E: Yeah so my Shameless plug is over the summer I've been having great fun creating I guess like this poetry or art. And really this is for Metalabel. I don't know if people haven't listened to it. I really recommend you listening to the CCG talk on the 9th of September from the guys at Metalabel, which is a collective platform that allows artists to come together and flexibly release work.
And they're doing cool stuff, but why I bought them on the CCG is because they're doing stuff with dids. It's a great talk, very interesting. Anyway, I've been playing around in that space for myself developing a label called Anomalous Thought Forms.
It's just a bit of fun really, but I have a label I released Anomalous Thoughts there and you're welcome to check it out if you're interested and also create your own label. It's fun to have a place to release creative work. Don't be shy.
[00:59:57] Speaker A: Awesome. We will link to Meta label and your meta label will if you want to give us the link we can link that in the show Notes Anybody else with a Shameless plug?
[01:00:07] Speaker D: I do have a shameless plug. I would like to let everyone know about the Digital Fiduciary initiative, which you can check out our introductory website about
[email protected] the idea is to create a new professional association that embodies a new professional class of oath bound certified individuals who are empowered to deal with identity issues in a fair and reasonable way, who are committed to putting the interest of the identity subject above their own.
In the same way that a doctor, a lawyer, an accountant, those are also fiduciaries and they must put the interests of their clients above their own within their domain. So in the same way that a lawyer can't use your legal problems to monetize it individually or separately, a Digital Fiduciary would not be able to use your identity related information for their own interest. And we think this is an interesting way to create a decentralized trust architecture that that actually leverages how Western society has dealt with this problem. Or at least in America, we have decentralized trust in doctors and in lawyers and in accountants in a way that scales in a very different way than anything that scales that's online. Right. It's not a single major provider. It's. You just have lots of doctors and you have lots of lawyers and they individually keep track and hold each other accountable. But you as an individual human being get to choose your doctor, you get to choose your lawyer. And so that's what we're trying to do with the Digital Fiduciary Association. If any of that sounds interesting, go check it out.
[01:01:39] Speaker A: All right, very good. Thank you. We will link to that in the show notes as well.
Before we wrap, we mentioned earlier in the conversation tabconf, along with a couple of other events. And I know our listeners are familiar with IAW and maybe even tpack, because we've discussed both of those on previous episodes. But TabConf is new. Can somebody just tell me a quick, quick and dirty what is it? I think we have the when is it? And we will link again to the show notes. But what is tabcomfo?
[01:02:11] Speaker D: So it stands for the Atlanta Bitcoin Conference and it will be in Atlanta and it is several days. I think it's four, not five for the week, but four days of bitcoin advocacy and technical discussions trying to make bitcoin better.
[01:02:26] Speaker F: And to that I would add they're very focused on building open source projects and they've got a builder day and workshops which are sessions where people are kind of actively engaged in learning a particular skill or concept.
So it's really hands on.
[01:02:46] Speaker A: Cool, that's great. Thank you very much for that. 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 Hsu. I'm Eric o'. 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 the 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.
