Yeah, so the title's actually kind of a uh a pun or something. So um yeah, so hi, I'm Paul Syverson from the Naval Research Lab. If you don't know me, uh thing I'm probably most known for is uh I invented onion routing with a couple of my NRL colleagues uh forever ago back in the 90s, and then a few years later with a couple of non-NRL colleagues created uh a version of that we call uh Tor. And this is the main thing I've been working on pretty much ever since. Um what I've been working on mostly for the last uh several years, advanced, there we go, is um the question of there's uh a lot of domain names that have associated onion addresses.
If you don't know what an onion address is, I don't have enough time to explain it. So for our purposes, you can just think of it as pretty much like uh PLC DID because it's uh cryptographically self-certifying address. And um domain names are generally human meaningful and onion addresses are these cryptographically things that are not, and uh turns out how to discover when things are associated and uh how to be sure they're bound together has all kinds of problems that uh um has all kinds of problems and uh which I have spilled out in all of these papers that I'm not gonna actually talk about, but that's there if you want to go look for them.
Uh and then also fortunately uh solutions to these.
Add proto identities, so handles and DIDs uh with a couple of goals. One is to improve and generalize Bluesky verified uh accounts to be um more than they are now, explicit about who the verifier is and also to provide uh some context uh uh to be decentralized, so it's not limited just to the Bluesky trusted verifiers um and also open so that anybody can have uh a verified identity and uh in addition we want to synthesize these together in a way that allows us to have self-certifying minifall identities that are um consistently transparent, that are blocking resistant.
This is one of the things onion services provide in a way I won't explain, uh and robust to uh TLS certificate hijack. Uh and also everything we've done is sort of fully backwards compatible so that if you are running something that doesn't know anything about our stuff, as long as it uses the standard protocols, nothing's gonna break. You won't get the advantages, but nothing's gonna break. So uh this is joint work with the uh force of nature who is Nick Jerichinus, who's right there. Um yes. Um so suppose as an example I didn't know about smoke signal, and Nick says, Oh, here's this cool thing, smoke signal, you should check it out.
And let's assume that he and I have a you know trusted channel over signal and we've validated that and uh that I trust Nick about identifiers for uh domains or maybe just for particular domains, we can come back to that. Um but what if smokesignal.evs uh has a TLS hijack. So just what I mean by that, well, if you go to smokesignal.events you get the little the usual lock icon, and if you click on that, you can see uh certificate that says that an authority, in this case Let's encrypt, says, oh, the key that's uh authenticating this connection uh is in fact uh associated with the name smoke signal.
So uh that's great. Only problem is um it's way too easy to um obtain uh bogus TLS certificates. It's not completely trivial, and a lot of people have done a lot of work to make it harder, but I don't think this is a problem that's going away anytime soon. It's just a a big bad problem. So um the answer, what if it gets hijacked is somebody can basically set up their own version of smoke signal and get me to think whatever about upcoming events or maybe reveal some kind of sensitive information in in the course of RSVPing.
So in in general, bad situation. But what if instead of giving me just the link to smokesignal.events the URL includes the PLC DID for smokesignal.events. And again, we have the trusted channel that that I'm getting things from Nick from. Now if I go and uh follow that URL, we have a Firefox extension that Nick created that ultimately I would like this to just be built into Firefox, but you need to crawl before you walk. So this extension checks that the key that DID that we get there's a header that gets sent. And it makes sure that the key that signed the header is in fact associated with this DID and that further that the DID that's uh that's um in the DID document matches uh the DID that was in the URL.
As opposed to if, for example, there was the the DID was not a not a good DID, then you would fail the checks. So great. Um so this is uh provides what I like to call dirt simple trust. The idea is I need all I need is the address and I'm kind of done. That's enough. Um I I can't I can't be hijacked or anything as long as we have this, I discovered it in this way. Uh relatedly, it also offers what I would call authority independence. So the idea is no authority, no CA can say, oh no, here's the new key for uh uh smoke signal um be because they don't control the key that is associated with the DID.
Um I can't be tricked about that. So um because I learned of this URL from from Nick, and because it passed the checks uh when I tried to connect to it, I can trust that Nick told me that the uh handle and DID are in fact uh bound together, and further that um because I trust Nick, I can trust that they are bound together. But we're not quite done because uh in order to do this, we had to have this you know signal exchange, and uh Nick has been very tolerant of me, but I think if every time I wanted to have a secure connection with anything I had to have a signal communication with him, maybe that would try even Nick's patients.
So uh we therefore have it automated so that um we have a record that um you get a signed header that's signed by say ngerakinus.me as well as by smoke signal that says uh that that these are bound together. And further, and this is where I'm introducing contextual labels, uh it could have a label like for example this is a Nick project. This is a project that Nick did. So let's contrast this with the way uh Bluesky currently handles uh verified accounts. So um you can Bluesky will directly verify somebody's account as belonging to someone, but they also have uh handful of trusted verifiers.
And that's fine, but it has some limitations. For one thing, you have to be important in order to uh in order to to get uh a verified account, or you have to be affiliated with one of these is about 20 currently uh trusted verifiers. Most of them are journalism organizations, and I mean I think that's great, but the rest of us are just SOL if we don't have you know one of these affiliations. So um what we have is it it it supports that kind of functionality and uh I think should replace it. Um so you can just do the same thing.
That's what I got here on the left, your left, whatever. But it it doesn't have to be centralized like that. You could also have say, like the town of Springfield is gonna tell you where what the local uh uh entities are in Springfield. So you might have a local news source in Springfield, and this is a good way you can resist pink slime journalism because uh you won't have some uh you know somebody from far away masquerading as as uh being from Springfield. Or it can also be even at the individual level, so this scales both up and down.
So like if you somebody I just made this entity up, but as far as I know, uh but you know you have somebody named Vegan Piper, maybe uh you trust them about where there are vegan restaurants around, uh but maybe you don't trust them about that and you but you do trust them about you know bagpipe supplies so uh you can you can choose which you want to trust them on so uh don't have a lot of time here so um that's it and I'll be happy to take any questions do we have any questions for Paul we've got a couple of minutes yes all right uh for the record uh those of us at Bluesky also think that they should replace the verification systems you have to crawl before you with I've they you know real problem that was being solved in real time right away and clearly the right thing to do but I think this is a good migration.
Yeah absolutely so that was a question over here was or did you change your mind yeah hi yeah I was just wondering if you've investigated in your work putting the signature information or any kind of that relational information on the Atmosphere itself I get why it has to be in the HTTP signatures but if there's any connection to like some sort of record that this person trusts this org or something like that. Well it's excellent. I mean it I mean in it yeah it is it it's in there. I mean so there's there's a lightning talk so uh a lot of content made it onto the four unfortunately but the idea is that the HTTP signature could reference for example a uh have could include an AT URI that is in the in a repository that has more involved contextual trust information and the DIP documents themselves represent a whole lot of information you can have key controllers identity controllers also known as relationships and the bi-directional relationship representing conceptual conceptual uh referencing for DIDs uh keys verification methods etc and even shared keys across them can show that hey this identity uh you know is affiliated with John Hopkins for example which is affiliated with you know a parent entity and so forth and the the trust can be uh traversed um using those ideas that's the idea in in my role as MC I'm gonna move us along but do please uh talk to Paul and Nick for the benefits of people online what was asked was well is this directly built into AT and uh uh the short version is Nick said yes.
Excellent fantastic excellent all right next up