Atlas Paper 001 — The Missing Layer of the Internet

Executive Summary

Internet participation is mediated through identities and controls created by service providers, employers, governments, device vendors, applications, and network operators. Each relationship may be legitimate, but the individual is repeatedly represented as an account inside someone else’s system.

Existing technologies solve important parts of this environment. VPNs protect traffic. Mesh systems connect trusted devices. Identity and access management systems authenticate users. Zero Trust systems evaluate access. Public-key infrastructure, passkeys, and verifiable credentials establish forms of cryptographic trust.

This paper asks whether a distinct layer remains missing: a persistent, person-controlled Internet presence that can carry identity relationships, trust assertions, privacy preferences, device context, and secure connectivity across changing networks and providers.

Atlas Identity is the working name for an open research initiative intended to test that thesis. It is not presented as a replacement for existing technologies. The initial proposition is that those technologies may become interoperable building blocks beneath a person-centred control and presence layer.

The Internet Recognizes Accounts, Not People

A person can have hundreds of digital identities, yet none necessarily represents that person independently of the organization that issued it. A bank knows a customer account. An employer knows a workforce identity. A social platform knows a profile. A network sees addresses and device activity. Each view is contextual and provider-controlled.

This fragmentation creates repeated enrolment, inconsistent trust, duplicated security controls, and limited continuity when a person changes location, device, network, or provider. The individual can manage many accounts, but does not ordinarily carry a native Internet presence that those systems can recognize by consent.

What persistently represents the person, rather than merely an account, device, or network attachment?

The Existing Landscape

VPN

Encrypts and routes traffic through another network endpoint. It primarily establishes secure transport and an alternate egress path.

Mesh networking

Creates authenticated private connectivity among enrolled devices, users, and services, often with identity-aware policy.

IAM and identity providers

Manage authentication, authorization, and identity lifecycle within organizational or service boundaries.

ZTNA and SASE

Apply identity, device, and policy controls to application and network access, usually for an organization.

PKI, passkeys, and credentials

Provide cryptographic mechanisms for authentication, signatures, assertions, and trust relationships.

Privacy and personal-data systems

Help users manage consent, disclosure, and data rights, but do not ordinarily provide a complete network presence.

These categories overlap and continue to evolve. The Atlas thesis should be rejected or narrowed if an existing category already provides the complete person-controlled role proposed in this paper.

The Proposed Gap

The proposed gap is not another authentication protocol or encrypted tunnel. It is the absence of a coherent layer through which an individual can establish and govern a persistent presence across multiple digital relationships.

A Personal Internet Presence could provide continuity across:

devices and operating systems;
home, mobile, enterprise, and public networks;
identity providers and organizational relationships;
private connectivity and public Internet access;
privacy, disclosure, and routing preferences;
human, application, and agent interactions.

Persistence must not mean universal exposure. A viable architecture may require selective identifiers, context-specific credentials, rotating network attributes, explicit consent, and strong separation between unrelated relationships.

The Personal Internet Presence Layer

Atlas Identity proposes a person-controlled layer that allows an individual to establish, manage, and present a secure Internet presence without requiring one network, employer, government, or application provider to define the person.

Person-controlled

The individual governs participation, relationships, and disclosure.

Persistent

Presence survives changes in network, location, provider, and device.

Contextual

Different relationships can receive different identifiers, policies, and claims.

Interoperable

Existing identity, networking, security, and trust systems remain usable components.

Revocable

Trust and access can be withdrawn without rebuilding the person’s entire presence.

Accountable

Privacy must not become a promise of invisibility or immunity from lawful process.

Initial capabilities to investigate

presence and relationship management;
identity and credential orchestration;
device enrolment and posture context;
secure transport, routing, and split-tunnel policy;
privacy and selective-disclosure controls;
developer interfaces for trusted interactions;
governance, audit, recovery, and revocation mechanisms.

Technical Drawings

The following diagrams translate the initial Atlas thesis into reusable architectural references. They are conceptual rather than production specifications and should be reviewed alongside the assumptions and open questions in this paper.

Personal Internet Presence high-level architecture — **Figure 6.1 — Personal Internet Presence: High-Level Architecture.** The Atlas client combines identity, presence, policy and secure networking functions and uses the Atlas network to reach applications, services, organizations and other users.

Trust relationship model — **Figure 6.2 — Trust Relationship Model.** Each relationship is independently scoped between the person and the relying entity; unrelated organizations do not inherit one another's trust.

Secure connectivity and traffic flow — **Figure 6.3 — Secure Connectivity and Traffic Flow.** The client establishes an encrypted relationship with the Atlas network, which applies user policy and routes traffic to public applications, APIs, private resources or peers.

Identity and key architecture — **Figure 6.4 — Identity and Key Architecture.** User-controlled keys and recovery mechanisms feed an identity vault that issues scoped assertions for applications, devices, networks and transactions.

Atlas Diagram Library

Open the reusable visual reference library to view or download the current diagrams independently of this paper.

Open Diagram Library

Comparison Framework

Capability	VPN	Mesh	IAM	ZTNA	Atlas proposal
Encrypted transport	Core	Core	—	Often	Uses
Private device/service connectivity	Partial	Core	—	Partial	Uses
Organizational authentication	Partial	Partial	Core	Core	Uses
Application-access policy	Limited	Partial	Partial	Core	Uses
Person-controlled persistent presence	—	Limited	Limited	—	Proposed core
Cross-provider relationship orchestration	—	Limited	Limited	Limited	Proposed core
Unified privacy, trust, and routing controls	Limited	Limited	Limited	Partial	Proposed core

This table is a research hypothesis, not a competitive claim. Reviewers are specifically asked to identify overlaps, omissions, and inaccurate boundaries.

Open Questions

Does the proposed gap exist, or is it already covered by existing identity, wallet, mesh, or Zero Trust architectures?
Would individuals value persistent Internet presence enough to adopt and maintain it?
Which elements should be centralized, federated, or decentralized?
How can continuity exist without creating a universal tracking identifier?
Who issues, verifies, revokes, and disputes trust assertions?
How should personal, professional, pseudonymous, and anonymous contexts coexist?
What responsibilities belong to the platform, provider, organization, and individual?
How should applications and AI agents interact with a person’s presence?
What minimum proof of concept could falsify or validate the thesis?
What commercial model avoids turning the individual into the product?

Call for Industry Review

This paper is deliberately incomplete. Its purpose is to expose the thesis to informed challenge before the architecture is overbuilt or described as solved.

Reviewers are asked to address three direct questions:

What existing technology or architecture already does this?
Which assumption is incorrect, incomplete, or unsafe?
What experiment should Atlas Identity build first?

Reviews should identify specific systems, standards, papers, companies, or implementations wherever possible. Substantive corrections will be tracked in future versions.

Challenge the proposal

Submit structured technical feedback, identify prior art, or recommend an experiment.

Send a review Open a GitHub issue