@xemahq/sealed-credential
v0.1.0
Published
Layer-1 crypto primitive for the Xema OS credential broker (plan §W4 / Pillar 3.1). Seals an opaque credential payload into an audience-bound, short-lived (TTL ≤ 60s) JWE (`dir` + `A256GCM`) bound to a credentialBindingId + inputHash + correlationId, and
Readme
@xemahq/sealed-credential
This package belongs to Layer 1 — a framework-agnostic crypto SDK whose only
dependency is jose. It is the credential-sealing primitive for the Xema OS
credential broker (master plan §W4 / Pillar 3.1).
What it is
Seals an opaque credential payload into an audience-bound, short-lived
(TTL ≤ 60s) JWE (dir key-management + A256GCM content-encryption, the
scheme proven by llm-gateway's gateway-token sealing), bound to a
credentialBindingId + inputHash + correlationId, and unseals it with
audience + TTL verification.
deriveSealingKey(secret)— deterministic 32-byte key from a shared secret.sealCredentialEnvelope(key, input)— the broker seals a resolved credential for exactly one audience (the executing gateway/runner).unsealCredentialEnvelope(key, token, { audience })— the gateway/runner decrypts; mismatched audience, elapsed TTL, or tampering fail-fast with a closedSealedCredentialErrorCode.
Invariants
- The credential never travels unencrypted; only the holder of the key + the named audience can unseal, and only before the TTL elapses.
- Generic over the payload type — the broker (seals) and the gateway/runner (unseals) share one tamper-evident envelope; credential semantics live in the broker, not in this primitive.
- The caller MUST still cross-check
inputHashagainst the live request, so a captured envelope can't be replayed against a different invocation.
