Transport Layer

The transport layer is the foundation of Atlas. It defines how data moves between any two endpoints on the network using standard HTTP/2 extended with three authentication headers and a universal envelope format.

Atlas does not invent a new transport protocol. It adds a thin cryptographic layer on top of HTTP — any existing web server or client can participate with minimal changes.

Two Building Blocks

The transport layer is composed of two separable modules that work together but can each be adopted independently:

Atlas Sign

Stable root identity, delegated signing keys, portable proof bundles, and three HTTP headers that authenticate every request. Designed as a standalone replacement for OIDC and PassKeys — no central account database required.

Atlas Envelope

Self-describing data record that carries its Schema.org type, validation rules, and authorship proof. Any app can validate any envelope without prior coordination — a serialization format, not a service.

How They Work Together

Atlas Sign authenticates the transport — proving who sent a request and that they are authorized. Atlas Envelope authenticates the data — proving who authored a record and that it has not been tampered with. Together they provide end-to-end verifiability from the HTTP request down to each individual data record.

Authenticated HTTP Request

GET /envelopes/type/SocialMediaPosting HTTP/2.0
atlas-identity:  <root-public-key>
atlas-signature: t=1712150400; s=<falcon-signature>
atlas-proofs:    [{ "data": { "@type": "Permit", ... }, "signature": "..." },
                  { "data": { "@type": "Intangible", "additionalType": "atlas:proofOfWork" }, ... }]

Signed Envelope Payload

{
  "signature": "<falcon-signature-base64>",
  "data": {
    "@context": "https://schema.org",
    "@type": "SocialMediaPosting",
    "text": "Hello from Atlas.",
    "datePublished": "2026-04-03T12:00:00.000Z"
  }
}

Design Principles

Principle	How
Incremental adoption	Add three HTTP headers to existing requests — that is enough to access the network. No infrastructure changes required.
No mutual trust	Every request and every envelope is independently verifiable. Apps do not need to trust each other to exchange data.
Post-quantum ready	All signatures use Falcon-1024, a NIST-standardized lattice-based scheme resistant to quantum attacks.
Schema.org native	Envelopes use Schema.org types as their schema language — no custom IDL, no code generation, immediate interoperability with search engines and structured data tooling.