Package
@flashyid/sdk
The relying-party surface for Flashy ID delegated authority: verify an assertion is genuinely from Flashy ID and that the delegation it carries authorises a specific action, from one import, holding no secret. Plus the grant kernel (issue / attenuate / verify / permits) and the rail token minters.
version 0.2.0 · measured 2026-10-19 from a checkout · source: flashyid/packages/sdk
npm i @flashyid/sdkDelegation is attenuation, never inheritance: a grant may only carry a subset of the granter’s scopes, attenuate refuses a wider cap, a later expiry or a changed purpose, and a change that could let a child hold authority its parent lacks is wrong by definition.
Enforcement comes before minting. evaluateGrant and enforce return ALLOW, DENY or ESCALATE, and the package ships that gate before any way to mint authority — identity that nothing checks is theatre.
Edge cases — each one paid for once
The provider mints with a drift-tested copy, not an import
flashyID’s own rail minter cannot tsc-resolve the SDK across the app’s rootDir, so src/lib/rail.ts there signs with jose directly and a test mints the same inputs through both, asserting identical claims and header. The test is what makes the copy safe — the estate’s vendored-checker pattern, applied to a signer.
A consent a caller can request is auto-approval
mintConsentToken is a pure function the provider calls from one place — the interaction flow, after an authenticated human approves a specific draft — and is deliberately not an endpoint. Exposing it would let a relying party request the consent the consent layer exists to refuse.