Draft binary wire · controlled endpoints

Raw bytes. Bounded trust.

SDB1 is a draft signed/authenticated binary record for systems that control both endpoints. It keeps the payload byte-for-byte, supports HMAC-SHA-256 and Ed25519, and is shaped for a bounded parse and conditional zero-copy hot path.

Explore the GitHub Key Atlas → Start with SDB1 Check the fit ↓

64Fixed bytesnetwork-order header 02Native cryptoHMAC + Ed25519 00Transcodesraw payload unchanged

fixedSDB1 · lengths · flags · algorithm · time

extensionskey · purpose · type · schema · opaque claims · once ID

payloadexact raw bytes · attached or detached

authheader || payload || external AAD

Legacy sd1 lab belowloading its Wasm byte core…

Live public-key lab

A mention can find a key. Only crypto can prove a signer.

Map a GitHub identity's current public material into four honest jobs: verify with signing keys, encrypt only to capable encryption subkeys, leave login keys alone, and refuse unsafe lifecycle states.

Try @Spaceghost → Inspect generic SSHSIG

Private keys never enter the page. Message plaintext stays local; only an explicit public-directory lookup reaches GitHub.

directory hintSpaceghost

VERIFYSSH signing

ENCRYPTcapable GPG subkey

REFUSEDexpired · revoked · unsupported

A narrow, defensible fit

Use it where the buffer path matters.

SDB1 favors controlled protocols with raw payloads, explicit limits, and owned receive-buffer lifetimes. Standards interop is a reason to choose JWS or COSE instead.

BYTES

No payload transcoding

No JSON, Base64, or application-object serialization occurs on the SDB1 path. The raw payload is authenticated byte-for-byte.

Wire guide →

POLICY

Meaning that must be enforced

Purpose, content type, schema ID, opaque issuer/audience/subject claims, time, critical extensions, and consume-once IDs are authenticated, then checked against caller policy. Applications define identity and session meaning.

Verification flow →

PATH

Borrowed, when ownership is real

The scanner can borrow a buffer. Crypto may still gather unless signParts is truly streaming/scatter-gather, and safe high-level APIs may copy.

Fast networking →

Capability, not category replacement

Know what SDB1 wins—and gives up.

Better shaped for bounded parsing and a borrowed hot path. Comparable on the corresponding single-signature or MAC features. Behind on standards, ecosystem, and broader families.

Capability	SDB1 draft	JWS Compact	COSE_Sign1	COSE_Mac0
Payload	Raw bytes unchanged	Base64url by default; RFC 7797 opt-in unencoded payload	CBOR byte string or detached	CBOR byte string or detached
Attached / detached	Both	Both, with profile details	Both	Both
External AAD	Yes	No separate general external-AAD input	Yes	Yes
HMAC-SHA-256	Native ID	JOSE algorithm profile	Not a signature algorithm	Standard COSE MAC algorithm
Ed25519	Native ID	EdDSA profile	Standard COSE signature algorithm	Not a MAC algorithm
Critical extensions	Unknown critical fails	Protected `crit`	Protected critical headers	Protected critical headers
Self-description	Exact critical content type + schema ID	Protected headers + application profile	Protected headers + CBOR/application profile	Protected headers + CBOR/application profile
Parse shape	64-byte fixed header + bounded extensions	Compact delimiter/Base64 parse	CBOR/COSE implementation + local limits	CBOR/COSE implementation + local limits
Standards / ecosystem	Project draft; no independent implementation	IETF; broad JOSE tooling	IETF; broad COSE/CBOR tooling	IETF; broad COSE/CBOR tooling
Multi-signature / countersignature	No	Use JWS JSON serialization	Use broader COSE structures	Use broader COSE structures
Encryption	Use `OpenPGP-encrypt(SDB1)`	Use JWE	Use COSE encryption structures	Use COSE encryption structures

Draft trust boundarySDB1 has no external audit or independent implementation yet. XDP/eBPF may bounds-check, classify, rate-limit, or redirect a candidate record, but it must never authorize one. Userspace signature/MAC and policy verification are required.

Legacy compatibility lab · sd1

Explore the earlier text envelope.

This live workbench intentionally remains on the older Base64url sd1 profile. It is useful compatibility tooling, but it does not demonstrate SDB1's raw-byte binary path.

01 · Trusted application inputs

Wasm core

Execution engine The Ruby gem produces the same wire token; use the runtime lab below to prove it against the fixed Ruby vector.

Payload shape

Payload

HMAC demo secret For learning and trusted tools. Normal public browsers should usually verify asymmetric signatures rather than hold shared secrets.

Key ID

Required purpose

Lifetime

02 · Portable envelope

Protocolsd1

Header—

Payload—

Signature—

Inspectable header · untrusted until verify

Creating a local example…

Payload view

—

Legacy sd1 compatibility

The earlier token still crosses every runtime.

The checked-in sd1 Ruby fixture is reproduced by Wasm, Web Crypto, and pure JavaScript. Migration to SDB1 requires verify, then re-sign; the profiles are not wire-compatible.

01 · WebAssembly corebyte primitives

const core = await loadSignedDataWasm();
const signer = createWasmHmacSigner(
  core, secret, { keyId: "forms-1" }
);

const token = await sign(payload, {
  signer,
  purpose: "example/form/1"
});

02 · JavaScript APIbrowser + Node

const envelope = await verify(token, {
  signer,
  purpose: "example/form/1"
});

if (envelope.verified) {
  use(envelope.payload);
}

03 · Ruby gemsecond language

envelope = SignedData.verify(
  token,
  signer: signer,
  purpose: "example/form/1"
)

use(envelope.payload) if envelope.verified?

Run the interoperability lab →

Legacy sd1 tool

Feed one byte at a time.

See ParcelStream handle awkward chunks and keep framing separate from authentication. This serializer lab is not part of SDB1's raw-payload path.

Open the stream lab →

Adjacent application profile

SignedData, then SignedForm.

Keep the core wire independent while a future cross-runtime SignedForm profile defines fields and can optionally bind destination and revision policy.

See the no-coupling plan →

From first record to deployment boundary

Read the draft before choosing it.

Start with fit and wire semantics, then validate the actual parser, crypto adapter, and network path.

5 MIN

SDB1 getting started

Sign raw bytes, enforce claims, use detached payloads and AAD, and understand the copy boundary.

Start here →

WIRE

SDB1 wire draft

Fixed header, bounded extensions, signing input, algorithms, and complete verification order.

Read the wire guide →

NET

Fast networking

XDP classification limits, userspace verification, AF_XDP leases, TCP reassembly, and honest benchmarks.

Read the boundary →