Repository navigation
feat!: async Signer interface, unified OID policy — release 4.0.0 - #47
Merged
Merged
Conversation
Signing now goes through the Signer interface — the signing-side
counterpart of Level1KeyProvider. localSigner(privateKey, curve) wraps a
raw in-memory key; any backend that produces DER ECDSA signatures
(WebCrypto, HSM, cloud KMS) can implement Signer without the private key
ever entering the library.
signAndEncodeTicket(ticket, { level1, level2? }) is authoritative for the
header's security claims (OIDs and Level 2 public key written from the
signers); signLevel1/signLevel2 sign the ticket's data exactly as given,
erroring on contradictory OIDs and leaving absent OIDs absent — which
makes out-of-band-algorithm barcodes producible for the first time — and
no longer triple-encode via placeholder signatures. getPublicKey (key
derivation) is renamed derivePublicKey to end the collision with
Level1KeyProvider.getPublicKey.
BREAKING CHANGE: signing functions take Signers and are async;
SigningKeyPair is only generateKeyPair's return type; getPublicKey is
renamed derivePublicKey. Migration guide from 3.0.0 in CHANGELOG.md.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BMYUez7fcvaL34RUjxKZRJ
API surface audit: every type defined in types.ts is exported, internal oids helpers (resolveAlgorithms & co) stay private, and naming/input conventions are consistent — except controlTicket, the last hex-only entry point, which now accepts string | Uint8Array like the rest of the pipeline. README gains the previously undocumented exports: getOpenTicketValidityWindow, derivePublicKey, signPayload, getSigningAlgorithm/getKeyAlgorithm and signatureKey. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BMYUez7fcvaL34RUjxKZRJ
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BMYUez7fcvaL34RUjxKZRJ
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Signerinterface — the signing-side counterpart ofLevel1KeyProvider:{ curve, sign(data), getPublicKey?() }.localSigner(privateKey, curve)covers raw in-memory keys; WebCrypto/HSM/KMS backends implementSignerwithout the private key ever entering the library.signAndEncodeTicket(ticket, { level1, level2? }),signLevel1(ticket, signer)andsignLevel2(ticket, signer)are async.signAndEncodeTicketwrites OIDs and the Level 2 public key from the signers (always self-consistent output);signLevel1/signLevel2sign the ticket's data exactly as given — contradictory OIDs are an error, absent OIDs stay absent, which makes out-of-band-algorithm barcodes producible for the first time.signLevel1/signLevel2rebuilt on the composable primitives (no more placeholder signatures and triple encode).getPublicKey(key derivation) renamedderivePublicKey, ending the collision withLevel1KeyProvider.getPublicKey.controlTicketaccepts raw bytes as well as hex (string | Uint8Array) — it was the last hex-only entry point.types.tstypes re-exported (verified by diff), internaloids.tshelpers stay private, README now documents every export (getOpenTicketValidityWindow,derivePublicKey,signPayload,getSigningAlgorithm/getKeyAlgorithm,signatureKey).The
website/app depends on the published npmdosipas-ts@^3.0.0and keeps building; its signing calls migrate when it bumps to 4.x.Test plan
npx tsc --noEmitandnpm run buildpassSigner, the requiredgetPublicKeyon Level 2 signers, andcontrolTicketbytes input🤖 Generated with Claude Code
https://claude.ai/code/session_01BMYUez7fcvaL34RUjxKZRJ
Generated by Claude Code