Skip to main content
Vendor-neutral signing abstraction for Glide’s VC issuer and did:web document builder. All four backends — AWS KMS, GCP KMS, HashiCorp Vault Transit, and an env-key reference implementation — satisfy the same KmsSigner interface, so application code is decoupled from any single KMS vendor. The private key never leaves the HSM; callers send a payload and receive a signature. The env-key backend holds a software private key in process memory and is fail-closed: buildKmsSigner throws at boot time when NODE_ENV=production.

Install

npmjs.com/package/@glideco/kms-signer

Why a neutral interface?

A single long-lived issuer key (e.g. for did:web:glide.co) cannot live in an env var — that fails any external compliance audit. The three production backends share one interface so the VC issuer code, the did:web document builder, and any future long-lived signing path are not entangled with a specific cloud KMS. Switching from AWS to GCP is a one-line change in the boot path.

KmsSigner interface

keyId shapes accepted per backend:
  • AWS KMS: arn:aws:kms:<region>:<acct>:key/<uuid>, alias/<name>, or the short alias/<name> form.
  • GCP KMS: projects/<id>/locations/<r>/keyRings/<ring>/cryptoKeys/<name>.
  • Vault Transit: transit/keys/<name>.
  • env-key: env-key-<algorithm> (auto-derived if omitted).

Dev / test: env-key backend

Production: bring your own backend

Build a did:web document

The output is the JSON that VC verifiers fetch to validate signatures over AgentSanctionsPassCredential and any other VC Glide issues.

ECDSA and IEEE P-1363

For es256 and es384, node:crypto’s default sign.sign(key) emits ASN.1 DER — every JOSE/JWS verifier and VC cryptosuite expects IEEE P-1363 raw r‖s (64 bytes for P-256, 96 for P-384). The env-key backend passes { dsaEncoding: 'ieee-p1363' } internally. Production backends that wrap AWS KMS should verify the Signature bytes are in the same format — AWS KMS returns DER by default and may require a DER→P-1363 conversion step.

Reading list