Source-linked AI summary
Onions in the ATmosphere: Decentralizing Trust in Identity
Paul Syverson, Nick Gerakines
TL;DR
Meaningful identifiers and self-authenticating identifiers can be associated, but discovering and trusting that association remains vulnerable to manipulation. The paper applies secure onion-association techniques to atproto identities and combines both approaches; it reports broader resistance from the combined approach, with handle-based website setup taking minutes rather than hours for domain setup.
Problem
Associating meaningful and self-authenticating identifiers requires discovering the association and establishing its correctness, while traditional discovery and trust infrastructure remains vulnerable to manipulation.
Source: §1 · pp. 1–2Method
The paper applies secure onion-association techniques to atproto DID associations and combines onion and DID associations within a single identity.
Source: §1.1 · p. 2Results
The combined approach offers stronger and broader blocking and manipulation resistance; handle-based website setup takes minutes, compared with hours for domain registration, DNS configuration, and TLS issuance.
Source: §3.1 · p. 8, §6 · p. 12Takeaways & Limitations
Combining onion and DID associations provides broader access to blocking-resistant and manipulation-resistant systems than either approach currently offers alone.
Source: §1.1 · p. 2, §6 · p. 12At the time described, Bluesky was the only atproto handle issuer with DID documents tracked in public append-only logs, limiting straightforward use to Bluesky handles and onion addresses when no registered domain is controlled.
Source: §3.1 · p. 9
Abstract
from arXiv · showhide
Multiple approaches have been implemented for identities that associate meaningful identifiers, such as domain names, with self-authenticating identifiers, such as onion addresses. While these approaches offer various advantages both from identifier meaningfulness and from identifier self-authentication, identifier association itself is subject to blocking, hijack, fingerprinting, and other forms of surveillance and manipulation. So too are the resources associated with an identity comprising a meaningful identifier and a self-authenticating identifier. This paper describes ongoing work on two such approaches to self-authenticating meaningful identity (SAMI): associating a registered domain name with an onion address (onion association) and associating an atproto handle with a decentralized identifier (DID association). We present both the application of already implemented and published means of secure onion association to DID association and the combination of both in a single identity. Finally, we describe grounding identity association and integrity in contextual trust, wherein trusting attestations of identity relies on contextual relevance of an attestor to the identity rather than relying only on structural authority, for example as embodied in the traditional centralized infrastructure.
1 Introduction
The paper combines meaningful identifiers with self-authenticating ones to form SAMIs, addressing the difficulty of discovering and trusting their associations. It outlines two SAMI approaches, related infrastructure, and the adversary model motivating its contributions.
1 Introduction
- SAMI combines a meaningful identifier with a self-authenticating identifier, addressing the trade-off between human usability and exposure to manipulation of authentication infrastructure.Associations also raise problems of discovery and correctness under traditional, mostly centralized trust.Source: §1 · pp. 1–2
1.1 Contributions
- The contributions apply secure onion-association techniques to atproto identities, combine both approaches in one identity, and propose contextual trust alongside tools and deployment.The paper also describes bidirectional-link validation and a practical way to use atproto handles as website names without registering a domain.Source: §1.1 · pp. 2–3, §1 · p. 2
1.2 Basic background: AT Protocol identity
- Atproto accepts did:web and did:plc identifiers; in this paper, only a meaningful handle paired with a self-authenticating identifier constitutes an identity or SAMI.A did:plc DID is a self-authenticating string recorded with DID-document updates in a public, verifiable log; a did:web DID relies on a domain and hosted document.Source: §1.2 · p. 3
1.3 Basic background: onion association
- Onion addresses encode their own public keys, while Tor provides private lookup and routing; they offer site owners greater autonomy over access and authentication than traditional domains.Onion addresses are not resolvable in DNS.Source: §1.3 · p. 3
1.5 Adversary Model
- The adversary aims to disrupt discovery, validation, or use of an identity, including by hijacking its identifier association; the model includes DNS and TLS hijacks.For onion-service use, the assumed adversary controls a small fraction of Tor guards, with ten percent offered as a ballpark assumption.Source: §1.5 · pp. 4–5
2 Synthesizing DID methods
The paper links did:web and did:plc identifiers to combine their properties, then applies onion-association certificate techniques to atproto identities. It specifies reciprocal DID-document checks to make handle hijacks detectable in public records and connection exchanges.
2 Synthesizing DID methods
- Listing each DID under alsoKnownAs in the other's document combines did:web control of the DID document with did:plc transparency, while mirrored fields preserve shared authentication data if either location is blocked.Clients able to reach both documents can compare their fields or identify how far the website document lags PLC updates.Source: §2 · pp. 5–6
2.1 Handle hijack
- Because DNS-based handle resolution can be hijacked, the proposed reciprocal links require both DID documents to list only the same two DIDs as siblings and restrict the handle to the did:plc document.A false handle association in the PLC leaves permanent public evidence; the added mechanisms aim to make it detectable during connection exchanges.Source: §2.1 · p. 6
2.2 DIDs in TLS Certificates
- For handles that are DNS names other than bsky.social subdomains, the did:plc DID can be encoded as a subdomain SAN, recording the association in both PLC and CT logs.The paper notes this technique does not work for bsky.social subdomain handles without explicit inclusion of those handles in certificate SANs.Source: §2.2 · p. 6
3 DIDs at .onions
The section links atproto handles to onion-hosted DID documents, enabling websites with meaningful names without registered domains. It also describes trust and access trade-offs between DID and onion association.
3 DIDs at .onions
- Mutual DID-document references enforce consent, while shared signing keys and controller designations create an authorization graph for delegated updates.The onion DID’s controller can be the registered-domain DID, authorizing it to update the onion DID document.Source: §3 · p. 7, Figure 1 · p. 7
- A registered-domain controller cannot change the onion DID’s identifier or connection-authenticating key, but accepted updates could reset its signing key or alter its alsoKnownAs entries.Problematic updates require manual retrieval and acceptance; the onion maintainer can reject them or remove an outside controller.Source: §3 · p. 8
3.1 Website names from atproto handles
- A Bluesky handle and onion service suffice for a discoverable, meaningful-name website without registering a domain; access requires a Tor-capable client.The onion-hosted site and handle-associated DID documents provide the association.Source: §3.1 · pp. 8–9
- PLC recording takes minutes, compared with hours to register a domain, configure DNS, and obtain TLS; CT logs typically allow 24 hours for certificate inclusion.The PLC tracks the SAMI association; the 24-hour delay applies when relying on CT logs alone for transparency.Source: §3.1 · p. 8
- At the time of writing, Bluesky is the only atproto handle issuer whose DID documents are tracked in public append-only logs, constraining transparent domain-free setup.Without a registered domain, the described approach currently needs a Bluesky handle and onion address for the stated transparency and resistance properties.Source: §3.1 · p. 9
- No atproto-provider standard or existing WebExt yet supports the handle-to-onion approach, though manual discovery and validation are possible without Bluesky’s cooperation.The connected website’s signatures and DID document validate the association.Source: §3.1 · p. 9
3.2 Dirt simple trust
- DID association offers simpler dirt-simple trust, while onion association offers greater blocking and manipulation resistance through automatic routing; that rerouting is not yet implemented in the DID-based WebExt.The onion-association rerouting was implemented in an earlier WebExt for SATAs.Source: §3.2 · p. 9
- Without dirt-simple trust, control of an onion address can enable domain-control manipulation with no more resistance than TLS-hijack protections; structural remedies can conflict with decentralized-identity goals.The passage also applies this vulnerability to DID association with a domain.Source: §3.2 · p. 10
4 Contextual Trust
The section contrasts broad account verification with assurances grounded in an attestor’s relevance to an identity. It describes onion-association attestations and their adaptation to atproto, including a remaining implementation gap.
4 Contextual Trust
- 6694 verified accounts (85%) were Bluesky-verified, while generic proofs may also be offered by better-resourced attackers for matching or lookalike identifiers.The text also cites Bluesky doppelgangers as a handle problem and argues that badges alone do not assure identity context.Source: §4 · p. 10
4.1 Background on onion association SATAs with contextual trust
- Sattestations bind a domain name to an onion address, with contextual labels that can be delegated to narrower scopes such as USG:DOJ:FBI.Trust is likewise scoped: an attestor should make attestations only for identities relevant to its label.Source: §4.1 · pp. 10–11
4.2 Contextual trust for Bluesky trusted verifiers
- Sattestations require the identity owner’s self-attested identifiers and label, preserving authority-independent control; the extension’s check for label agreement is not yet implemented.Bluesky trusted verifiers provide contextual relevance by displaying which verifier issued a badge, while configured trust roots are still under development.Source: §4.2 · p. 11
4.3 Integration with AT Protocol
- DID documents can incorporate membership or endorsement credentials, with HTTP signatures binding them to active service provision and enabling composable contextual trust.The proposed framework allows basic clients to follow service endpoints and more manipulation-resilient clients to perform cryptographic and credential validation.Source: §4.3 · pp. 11–12
- Inline endorsements can remain accessible from a recipient’s onion-hosted repository when access to the atproto firehose is blocked.Remote attestations rely on the relay, which currently does not speak to Tor; an onion service can serve the recipient’s records, including an inline endorsement.Source: §4.3 · pp. 11–12
5 Implementation Notes
The implementation provides a browser extension for bidirectional handle validation and DID-document signature verification using standard tools.
5 Implementation Notes
- The reference implementation uses RFC 9421 signatures and browser-native Web Crypto to verify DID-document responses against embedded public keys.It provides interchangeable Python Flask and Caddy server-side signers.Source: §5 · p. 12
- The WebExt retrieves the referenced DID document and verifies the response signature against its embedded public key.The server signers generate standard Signature and Signature-Input headers using ecdsa-p256-sha256.Source: §5 · p. 12
- The WebExt checks bidirectional handle–DID validation for handles that are also the name of the visited domain, a tool the authors describe as the first available for this check.The paper says users are otherwise expected to perform the protocol’s crucial bidirectional check manually.Source: §5 · p. 12
6 Conclusion
The conclusion presents applying secure onion association to atproto identities and combining both approaches in one identity as the paper’s contributions.
6 Conclusion
- The paper applies existing secure onion-association methods to atproto identities and combines onion and DID association in a single identity.Source: §6 · p. 12
- Combining the approaches offers stronger and more broadly available resistance to blocking and manipulation of identifier associations and identity-associated content.Source: §6 · p. 12
- The authors look toward broader adoption of their more decentralized approach to verified identities across the ATmosphere.Source: §6 · p. 12