Trust in a Person-Centric Internet

01

Executive Summary

Atlas Paper 001 asked whether the Internet lacks a person-controlled presence layer. Atlas Paper 002 defined a proposed boundary for that layer without claiming it was built. This paper is narrower and more concrete: it is about trust specifically — how a relying party comes to accept an assertion about a person, how that trust is scoped and limited, how it is withdrawn, and how the system remains accountable without needing a permanent record linking a person to everywhere they have used it.

Unlike Papers 001 and 002, this paper is not written entirely ahead of implementation. A credential layer, a published verification key, one independent relying party, and per-relying-party identifiers exist and have been exercised against production infrastructure. Section 12 states plainly what has been verified and what has not, so the distinction between design intent and demonstrated behavior stays visible throughout.

The central claim is that trust in this model has three separable parts: a cryptographic part (can the assertion be checked against a key, without asking the issuer), a scope part (what does the assertion actually claim, and to whom), and a discipline part (does the issuer retain anything that could later re-identify who an assertion belonged to). The first part can be made a mathematical property. The third part, as this paper is published, is still a written rule about what the issuing system chooses not to store — not yet a property enforced by the cryptography itself. Section 11 is explicit about that gap and what closes it.

02

The Trust Problem, Restated for a Person

Most deployed trust models assume an institutional relying party trusts another institution: a browser trusts a certificate authority, a bank trusts a payment network, an enterprise trusts an identity provider. The subject being vouched for is usually a server, a domain, or an employee acting inside an organization's own account system.

A person-centric model inverts the usual shape. The subject is an individual who may interact with many unrelated relying parties, none of which the person works for or has a standing account relationship with in the ordinary sense. The question is not "does this organization trust that organization" but "can an independent relying party trust a claim about a person it has never seen before, issued by a party the relying party does not otherwise depend on operationally."

This restated problem has a specific failure mode that institutional trust models do not: if the issuer becomes a place where every relying party's trust decision is jointly visible, the issuer becomes exactly the kind of centralized observer of a person's life that Paper 002 identified as the largest design risk. A trust model for a person-centric Internet has to solve verification and avoid recreating that observer in the process of doing it.

03

Terminology

This paper reuses the terms defined in Atlas Paper 002 (Person, Relationship, Claim, Credential, Relying Party) and adds the following, specific to trust:

Assertion. A signed statement, issued by Atlas, that a specific relying-party-scoped identifier corresponds to a credential Atlas has verified. An assertion is not a claim about the person's name, history, or any attribute beyond the fact of holding a valid credential, unless a relying party has separately negotiated additional claims.

Verification. The act of a relying party checking an assertion's signature against Atlas's published key. Verification does not require contacting Atlas at the time of use.

Linkage. A record, held by any party, that connects two otherwise-separate facts about the same person — most importantly, a record connecting an identity to a network address, or a record connecting the same person's identifiers at two different relying parties.

Rule versus guarantee. A rule is an operational choice about what a system does not do or does not store. A guarantee is a property the cryptography or protocol enforces even if the operator's choices changed. This paper treats the distinction as load-bearing rather than semantic: see Section 11.

Closed registration. A relying party is admitted individually, with its cryptographic setup confirmed in advance, rather than through an open standard any party can integrate against unannounced.

04

Trust Establishment

Trust begins with a credential rooted in a one-time recovery phrase the person holds, not in any single device. The credential is user-scoped; device sessions sit beneath it, so replacing a device does not require rebuilding trust with every relying party that already accepted the person's identity.

Atlas issues assertions signed with an asymmetric key. The public half of that key is published at a stable, well-known location (a JWKS endpoint) that any relying party can fetch independently. Atlas's role in trust establishment ends at signing; it does not participate in, or need to be reachable during, the relying party's verification step.

Key rotation is supported without breaking already-issued assertions: an active signing key can rotate while previously retained public keys remain available for verifying assertions signed before the rotation, so a relying party is not forced to re-verify its entire history against a single, permanently fixed key.

05

Verification Without a Shared Secret

The distinguishing property of this model is that a relying party's trust decision does not depend on a secret shared with Atlas, a live API call to Atlas at verification time, or a session token that could be replayed or that ties the transaction back to an Atlas-operated service. A relying party checks a signature against a public key the same way a browser checks a TLS certificate: independently, offline if needed, and without asking the issuer to vouch for the specific transaction as it happens.

This matters for two reasons beyond convenience. First, it removes Atlas from the relying party's uptime and availability dependency graph — a relying party can keep verifying already-issued assertions even during an Atlas outage. Second, and more importantly for the accountability question in Section 9, it means Atlas does not learn, in the ordinary course of verification, which relying party a person is authenticating to at any given moment — because no call to Atlas is required for that step to happen.

06

Unlinkability: Trust Without Correlation

Each relying party Atlas connects to receives a different, fixed identifier for the same person, derived so that two relying parties cannot match their respective identifiers for that person even if they compare notes directly, and so that Atlas's own issuing system is the only party that could compute the correspondence — a property addressed further in Section 11.

This derivation is deliberately not deferred. Paper 002's governance principles noted that changing an identifier scheme after a relying party has integrated means breaking that integration and re-credentialing every affected user. The derivation exists as an interface from the point of the first relying party's integration, with a trivial function acceptable as a first implementation as long as the pairwise property itself is correct from day one.

Unlinkability at the identifier layer does not, by itself, prevent correlation through other channels — timing, IP address, device fingerprint, or behavioral pattern can still link two sessions even when the identifiers cannot be matched directly. This paper treats identifier unlinkability as one layer of a broader privacy model, not a complete solution; the same caution Paper 002 raised in its context-separation discussion applies here without modification.

07

Limiting Trust: Scope, Approval, and Closed Registration

Trust is scoped, not global. An assertion states that a credential is valid and, where negotiated, that specific limited claims hold — it does not carry a person's full profile, and a relying party receiving an assertion for one purpose cannot silently escalate the request into a broader disclosure without the person's participation.

Relying parties are approved individually rather than through an open standard anyone can integrate against unannounced. This is a deliberate limitation, not an oversight: it lets each relying party's cryptographic setup — how it fetches and pins the published key, how it handles rotation, what it does with an identifier once it receives one — be confirmed in advance, rather than trusted blind at first contact. The cost of this choice is that Atlas cannot yet claim to be an open, permissionless identity standard; Paper 002's Section 13 governance discussion already anticipated this trade-off between interoperability and verified correctness.

Atlas also declines a category of trust entirely: it does not monitor, log, or flag which destinations a person's traffic reaches, and does not attempt to make itself the arbiter of what a relying party or a network should permit. Policing destinations is treated as a separate function that does not belong inside an identity trust system, both because it does not scale safely and because a system positioned to make that judgment is a system that must also keep the records needed to make it.

08

Revocation

Trust granted is trust that must be revocable without disproportionate cost. Atlas supports revocation at two independent levels: a single device can be revoked without affecting the identity a relying party continues to see for the person's other devices, and an account can be revoked or recovered in full through the self-held recovery phrase, which rotates the credential and invalidates prior sessions.

Revocation propagation has a real, previously measured cost worth stating plainly rather than assuming away: an early mesh-layer prototype (Atlas Paper 002, Addendum, Section 21) found that server-side revocation enforcement was immediate, but a revoked device's own local status display continued to show its prior state for a period afterward. The lesson generalizes to the credential layer discussed in this paper: a device's self-reported status is not evidence of its actual trust state, and any future design decision that depends on a device accurately knowing it has been revoked, rather than on the issuer's and relying party's independently verifiable state, would repeat that mistake.

Revocation is deliberately asymmetric with recovery. Recovery restores the person's own control after loss; it is not a mechanism by which Atlas, a relying party, or a third party can force disclosure of who was behind a credential. No entity other than the person holding the recovery phrase can trigger recovery, and Atlas keeps no copy of that phrase to do so on anyone's behalf.

09

Accountability Without a Universal Identifier

A frequent objection to unlinkable, person-controlled identity is that it trades accountability for privacy — that a system unable to correlate a person's activity is a system that cannot be held responsible for abuse. This section states why that objection does not automatically follow, and where it still applies.

Accountability in this model is relationship-scoped rather than global. A relying party that issues a pairwise identifier to a person can still apply its own reputation, rate-limiting, and dispute-resolution mechanisms against that identifier within its own relationship — exactly as it could against any account-based identifier today. What the person-centric model removes is a different capability: the ability for a relying party, or an observer compelled to ask multiple relying parties, to assemble one person's activity across services they each separately used. Removing cross-service correlation is not the same as removing within-service accountability.

Where the objection does apply, honestly, is at the point closest to the person: an account can be revoked, and how many credentials it requested in a period can be counted, but which past network address a specific person used is not retained beyond a short operational window, and what destinations a person's traffic reached is not logged at all. A regime that wanted that specific kind of accountability — retrospective, per-person destination history — is a regime this design does not support and is not attempting to approximate partially. Section 12 states this as a table rather than prose, because a partial version of "we don't keep that record" is not a coherent middle position to claim.

10

Governance

Paper 002 argued that governance must separate protocol conformance from authority over people, and that a standards body should define formats without deciding who a person is. This paper's governance position is narrower and specific to trust decisions: the closed relying-party approval process described in Section 7 is itself a governance mechanism, not merely an engineering convenience, and it needs the same public accountability any gatekeeping function needs.

Two governance obligations follow directly from operating a closed approval process. First, the criteria for approving a relying party should be public, even while the roster of approved relying parties may reasonably start small. Second, and more urgently while Section 11's gap remains open, the operational rule about what Atlas's issuing system does and does not store needs to be independently checkable, not merely stated — the difference between a claim made in this paper and a claim that has survived outside review is exactly what Section 11 and Section 14 exist to keep separate.

This paper does not propose a certification mark, a conformance program, or a governance body beyond Atlas's own operation at this stage of testing, consistent with Paper 002's caution against premature certification. That remains appropriate while there is one operator, one demonstration relying party, and a still-open cryptographic gate; it will need to be revisited before any claim of broader interoperability is made.

11

A Rule, Not Yet a Guarantee

The unlinkable per-relying-party identifier described in Section 6 already holds as a property: no relying party, alone or comparing notes with another, can derive a person's identifier at a different relying party from the identifier it holds itself. That much is a property of the derivation, not a promise about behavior.

What is not yet a property is the question of whether Atlas's own issuing system could compute which person a given identifier belongs to, because it is the system that signed it in the first place. Today, the honest answer is that it could be asked to. The reason that question is unanswerable in practice right now is a written operational rule: the issuing system stores nothing about a credential after handing it out except a count, with no credential value, hash, or linking key retained anywhere. That rule is real and currently in effect, but it is a rule about what the system chooses not to do, not a mathematical guarantee that it cannot.

The step that converts the rule into a guarantee is a blind-signature scheme at the issuance layer, reviewed by an outside cryptographer before it ships, so that Atlas becomes structurally unable to compute the correspondence at all rather than merely committed not to look. This is the one outstanding step in Atlas's build order that gates opening beyond invited testers; every other step in the sequence — including the credential layer, the pairwise derivation, and the revocation mechanisms described above — is already closed. This paper will be revised, not silently updated, when that step ships.

12

What Has Actually Been Verified

Papers 001 and 002 were published ahead of implementation and were explicit about that. This paper is published alongside a running system in closed testing, so it draws a firm line between what has been exercised against real infrastructure and what remains design intent.

This section should be read as a snapshot, not a permanent record — it will go stale as the system changes. The current authoritative version of these claims is maintained on the Trust & Data page, which this paper defers to whenever the two documents might otherwise drift apart.

13

Threats to the Trust Model

Compelled disclosure at the issuer. Because the linkage gap in Section 11 is currently a rule and not a guarantee, a legal order compelling Atlas to retain and disclose linking data in the future is a live threat until the blind-signature step ships. This paper does not claim immunity from lawful process; it claims that, once that step ships, there will be nothing responsive to disclose because nothing will have been recorded.

Relying-party misuse of an identifier. A relying party could attempt to combine its own pairwise identifier with other signals it independently collects — browser fingerprinting, payment metadata, IP address — to build a profile that identifier unlinkability alone does not prevent. This is the same caveat raised in Section 6 and inherited from Paper 002: identifier design solves one channel of correlation, not all of them.

Approval-process capture or error. Because relying-party registration is closed and manual, a mistaken or coerced approval could admit a relying party whose cryptographic handling of assertions is unsound, or whose intentions do not match its stated integration. Closed registration reduces this risk relative to an open standard but does not eliminate it, and the governance obligations in Section 10 exist specifically to keep the approval criteria checkable.

Recovery-phrase loss or theft. The self-held recovery phrase is both the strongest privacy property in this design and its clearest single point of failure: losing it is unrecoverable by design, and an attacker who obtains it can trigger a real recovery that Atlas has no independent way to distinguish from the legitimate owner acting.

14

Falsifiable Hypotheses

H1. A relying party can make a correct trust decision about a person-centric identity assertion using only a published key, with no shared secret and no live call to the issuer. Verified against one demonstration relying party; reject if a second, independently operated relying party cannot replicate this without additional out-of-band trust.

H2. Two relying parties cannot derive a shared correlation for the same person from their respective pairwise identifiers alone. Holds as a property of the derivation; not yet tested against two real, independently operated relying parties actively attempting to collude.

H3. An identity system can decouple a credential from the network address that used it, on live infrastructure, not only in design documents. Verified on the current egress infrastructure; reject if any table anywhere is later found to join an identity to an address.

H4. The gap between an operational no-storage rule and a cryptographic no-computability guarantee can be closed without changing the client-facing credential interface. Open; this is precisely what the blind-signature implementation behind the existing issuance interface is intended to test.

H5. Revocation can be enforced server-side and by relying parties without depending on the revoked device's own awareness of its state. Supported by prior mesh-layer evidence (Paper 002, Addendum, Section 21); reject if any future credential-layer design is found to rely on client self-reported revocation state for a security-relevant decision.

15

Open Questions for Industry Review

1. Is closed, individually approved relying-party registration a defensible governance model at this stage, or does it concentrate too much unilateral judgment in one operator?
2. What independent mechanism could verify, rather than merely state, that an issuing system stores nothing beyond a count — short of the blind-signature guarantee itself shipping?
3. Which correlation channels outside identifier design (timing, fingerprinting, payment metadata) most urgently need an explicit mitigation before this model could responsibly scale past a handful of relying parties?
4. Does relationship-scoped accountability (Section 9) actually satisfy the abuse-handling needs relying parties have in practice, or does it merely relocate a problem they will ask Atlas to solve for them regardless?
5. What would constitute sufficient outside cryptographic review of the blind-signature step before it should be trusted to gate public launch?
6. Should the criteria for approving a relying party be published before or after the roster of approved relying parties grows past the current single demonstration integration?

16

Conclusion

Trust in a person-centric Internet does not require a shared secret, a live check-in with the issuer, or a permanent record joining a person to everywhere they used their identity. What it requires instead is a published key a relying party can verify against independently, an identifier derivation that keeps relying parties from comparing notes, a revocation path that does not depend on the revoked party's cooperation, and an honest account of which of those properties are already mathematical and which are still operational promises.

This paper has tried to keep that last distinction visible rather than rounding a rule up to a guarantee for the sake of a cleaner thesis. The credential layer, the published key, the pairwise identifiers, and the decoupling of identity from network address are built and verified against production infrastructure. The step that would make the deepest privacy property in this design a matter of cryptography rather than operator discipline is not yet shipped. Both of those statements are part of the same paper because both are true at the same time.

17

References

1. Atlas Identity, Atlas Paper 001: The Missing Layer of the Internet, Version 1.0, July 2026.
2. Atlas Identity, Atlas Paper 002: Defining the Personal Internet Presence Layer, Version 0.1, July 2026, including Addenda (Sections 21–22).
3. Atlas Identity, Trust & Data disclosure page, updated September 13, 2026.
4. IETF RFC 7515–7519, JSON Web Signature, JSON Web Encryption, JSON Web Key, and JSON Web Token (the JOSE/JWT family).
5. D. Chaum, "Blind Signatures for Untraceable Payments," Advances in Cryptology: Proceedings of Crypto '82, 1983.
6. W3C, Verifiable Credentials Data Model v2.0, W3C Recommendation, May 2025.
7. NIST Special Publication 800-63 Digital Identity Guidelines series.
8. IETF RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3, August 2018.

18

Call for Review

This paper makes verifiable claims about a running system alongside open design questions. Reviewers are specifically asked to challenge the verified claims in Section 12 against the live Trust & Data page, not only the open questions in Section 15.