Problem
Today, identity-aware encryption requires the developer to manage the OIDC JWT by hand:
const lc = new LockContext()
const identified = await lc.identify(userJwt) // caller fetches + passes the JWT
await client.encrypt(...).withLockContext(identified.data)
LockContext.identify(jwt) hand-rolls the OIDC→CTS federation (a raw fetch() to /api/authorize with { workspaceId, oidcToken }) and the caller is responsible for sourcing a current, unexpired JWT on every call. This is the same federation that @cipherstash/auth's OidcFederationStrategy now performs — with token caching/refresh and workspace assertion built in.
Desired end state
When an OidcFederationStrategy is configured on the client, encryption/decryption calls can be "locked" simply by specifying a JWT claim (e.g. the identity claim), with no manual identify(jwt) step:
// strategy created once with OidcFederationStrategy (getJwt provided)
await client.encrypt(...).withLockContext({ claim: 'sub' }) // shape TBDThe strategy owns fetching/refreshing/federating the JWT; the SDK derives the lock context from the configured claim. Devs no longer thread raw JWTs through every operation.
Dependency (now available)
OidcFederationStrategy shipped in @cipherstash/auth 0.40.0 in both the Node entry and @cipherstash/auth/wasm-inline (create(workspaceCrn, getJwt, baseUrl?) / createWithStore(...)). The CRN/region parity bump that brings auth 0.40.0 into stack lands in #528 (CIP-3245).
Notes / open questions
- API shape for "lock by claim" on
.withLockContext() — accept a claim selector vs. a small options object.
- Migration/back-compat for the existing
new LockContext().identify(jwt) flow (keep as a lower-level escape hatch?).
@cipherstash/protect has a parallel LockContext (src/identify/index.ts) that hand-rolls the same federation — decide whether it consolidates onto the strategy too.
Separate from #523/#528 (that work is the AccessKeyStrategy CRN parity bump; this is a new identity model built on OidcFederationStrategy).
Problem
Today, identity-aware encryption requires the developer to manage the OIDC JWT by hand:
LockContext.identify(jwt)hand-rolls the OIDC→CTS federation (a rawfetch()to/api/authorizewith{ workspaceId, oidcToken }) and the caller is responsible for sourcing a current, unexpired JWT on every call. This is the same federation that@cipherstash/auth'sOidcFederationStrategynow performs — with token caching/refresh and workspace assertion built in.Desired end state
When an
OidcFederationStrategyis configured on the client, encryption/decryption calls can be "locked" simply by specifying a JWT claim (e.g. the identity claim), with no manualidentify(jwt)step:The strategy owns fetching/refreshing/federating the JWT; the SDK derives the lock context from the configured claim. Devs no longer thread raw JWTs through every operation.
Dependency (now available)
OidcFederationStrategyshipped in@cipherstash/auth0.40.0 in both the Node entry and@cipherstash/auth/wasm-inline(create(workspaceCrn, getJwt, baseUrl?)/createWithStore(...)). The CRN/region parity bump that brings auth 0.40.0 into stack lands in #528 (CIP-3245).Notes / open questions
.withLockContext()— accept a claim selector vs. a small options object.new LockContext().identify(jwt)flow (keep as a lower-level escape hatch?).@cipherstash/protecthas a parallelLockContext(src/identify/index.ts) that hand-rolls the same federation — decide whether it consolidates onto the strategy too.Separate from #523/#528 (that work is the AccessKeyStrategy CRN parity bump; this is a new identity model built on OidcFederationStrategy).