FiberLatch Access — Weeks 1–2 Progress Update
Hi everyone,
Here is the first progress update for FiberLatch Access since the proposal was approved.
The work for Weeks 1–2 focused on defining how the reusable access package should work before implementation begins. That phase is now complete.
So far, I have completed:
The project scope and boundaries
The access receipt format
Expiration and replay-protection rules
Signing and verification rules
The design for the reusable Node.js package
A public ledger for tracking the remaining work
The main goal of this phase was to make sure the package stays small, secure and useful to developers.
The package will allow a host application to issue, verify and redeem access receipts after a trusted Fiber payment. Normal receipt redemption will not require a Fiber RPC call.
The host application will still control payment verification, storage, revocation and the final decision to grant access to the protected resource.
The package is being designed for Node.js developers and will support both ESM and supported CommonJS projects.
All the work is available publicly here:
Repository branch:
Package design:
# FiberLatch Access Reusable Package Design
## 1. Purpose
This document defines the smallest reusable Node package that lets a host application validate trusted access-receipt claims, sign receipts, verify received receipts, evaluate bindings, and atomically redeem access through host-owned persistence.
The package is intended for the paid-resource example required by the grant. It is not hosted infrastructure, a payment product, or a general web framework.
## 2. Design Constraints
- Local library, not hosted infrastructure.
- Node-focused and framework-independent.
- No Fastify dependency.
- No Prisma dependency.
- No SQLite dependency.
- No Fiber RPC dependency during receipt verification or redemption.
- No payment creation or routing.
- No payment settlement.
- No dashboard.
- No CLI.
- No React SDK.
- No checkout interface.
show original
Receipt format:
# FiberLatch Access Receipt Format
## 1. Document status
This document proposes the FiberLatch Access receipt format.
It records the current backend baseline without claiming that the frozen signing and verification specification is complete.
It does not claim that the package or the full grant work is complete.
It does not change payment routing, storage ownership, or final access enforcement.
The signing and verification specification, the expiration and replay specification, and the package implementation remain deferred.
## 2. What the receipt is
A FiberLatch Access receipt is a signed JWT that represents access granted after a trusted payment result.
It is not proof of payment.
It is not a standalone authorization system.
The host application remains responsible for payment trust, persistence, and final enforcement.
## 3. Current signing and verification baseline
The current backend signs receipts using `EdDSA`.
show original
Expiration and replay rules:
# FiberLatch Access Expiration and Replay Rules
## 1. Purpose
This document defines when a FiberLatch Access receipt is valid, how it is consumed, and how replay protection is enforced by a host application.
It specifies portable lifecycle rules for redemption.
It does not define signing policy, key management, package API shape, or host-specific storage schema.
## 2. Responsibility boundary
FiberLatch Access defines the expiration and replay rules.
The host application owns persistent redemption state.
The host application performs final access enforcement.
A signed receipt alone does not provide replay protection.
`jti` identifies a receipt but does not by itself prevent reuse.
The persistent state transition must be atomic.
Payment verification and payment routing remain outside this specification.
Fiber RPC must not be required during ordinary receipt redemption.
The receipt package may describe the rules, but it must not own the authoritative redemption store.
show original
Signing and verification rules:
# FiberLatch Access Signing and Verification Rules
## 1. Purpose
This document defines how FiberLatch Access receipts are signed and cryptographically verified.
It separates cryptographic verification from host authorization and keeps the package boundary out of scope.
It does not define package exports, storage adapters, HTTP response bodies, or the eventual package API.
Receipt verification alone does not grant access.
## 2. Responsibility boundary
The host controls payment trust, receipt issuance, persistent redemption state, and final access enforcement.
The verifier checks cryptographic validity, issuer, audience, time validity, and approved claim structure.
Persistent revocation, exhaustion, replay protection, and subject or resource binding remain host-owned.
Ordinary receipt verification and redemption do not require Fiber RPC.
The verifier must not become a payment verifier or a payment-routing SDK.
## 3. Current implementation baseline
The current backend behaves as a compact signed JWT/JWS system:
show original
Progress ledger:
# FiberLatch Access Grant Ledger
This ledger separates prior FiberLatch foundation from grant delivery, tracks blockers, and prevents unreviewed work from being counted as complete.
| ID | Approved deliverable | Prior foundation | Grant-specific artifact required | Current grant status | Evidence | Blocker or open decision | Next action |
| -- | -------------------- | ---------------- | -------------------------------- | -------------------- | -------- | ------------------------ | ----------- |
| D1 | FiberLatch Access scope and design | Existing backend docs, repository evidence, and the historical proof | `docs/fiberlatch-access-scope.md` and any later design notes that freeze the scope boundary | VERIFIED COMPLETE | `docs/fiberlatch-access-scope.md`; commit `b28cc1b0722b531fee8d1efaec24ce5c3ba9143e`; independent review `APPROVE`; `npm test` passed (57 tests across 8 files); `npm run build` passed | None | D2: specify the proposed access receipt format |
| D2 | Proposed access receipt format | Current receipt claim implementation in `src/domain/receipt-claims.ts` and signing code | `docs/fiberlatch-access-receipt-format.md` | VERIFIED COMPLETE | `docs/fiberlatch-access-receipt-format.md`; commit `b606abbdff759f3bafef53280225b4b4f7962a96`; technical review completed; hygiene verification passed | None | Specify the expiration and replay rules |
| D3 | Expiration and replay-protection rules | `src/domain/redemption-policy.ts`, `src/repositories/access-receipt-repository.ts`, and `src/services/fiber-latch-service.ts` | `docs/fiberlatch-access-expiration-replay.md` | VERIFIED COMPLETE | `docs/fiberlatch-access-expiration-replay.md`; commit `556bed351d4c8b7dbc0ce13306564905e2613e11`; independent technical and public-hygiene review completed; `npm test` passed (57 tests across 8 files); `npm run build` passed | None | Next grant task: specify the signing and verification specification |
| D4 | Signing and verification rules | `src/integrations/receipts/jwt-access-receipt-signer.ts` and `src/config/signing-key.ts` | `docs/fiberlatch-access-signing-verification.md` | VERIFIED COMPLETE | `docs/fiberlatch-access-signing-verification.md`; `9215d264bbd434a3f85df0b2bd836d5efada3b46`; independent security and public-hygiene review completed; `npm test`: 57 tests across 8 files passed; `npm run build`: passed | None | Next task: reusable package design |
| D5 | Lightweight Node.js access receipt package | `src/core/index.ts`, the existing backend service, and the current build/test setup | `docs/fiberlatch-access-package-design.md` | IN PROGRESS | `docs/fiberlatch-access-package-design.md`; commit `8dadae65319dd20cf57c67ab60801e11748293da`; reusable package design verified; package implementation has not started; next step is the isolated package skeleton and package-consumer distribution proof | Package implementation has not started | Next task: create the isolated package skeleton and package-consumer distribution proof |
| D6 | Paid-resource example | `scripts/demo-local-access.ts`, `scripts/demo-protected-resource.ts`, and the historical demo docs | A grant-specific paid-resource example that consumes the approved package boundary | NOT STARTED | Baseline demos only; no grant-specific example yet | The package boundary is not yet defined | Build the example after the package contracts exist |
| D7 | Documentation and final report | `README.md`, `QUICKSTART.md`, `CHANGELOG.md`, and the current docs set | Grant-specific documentation and a final report that map evidence to the approved deliverables | NOT STARTED | Existing documentation only; no grant-specific final report yet | Documentation must wait for the approved scope and package contracts | Write documentation after the implementation evidence exists |
## Evidence rules
Acceptable evidence:
- commit SHA
- tagged release
show original
The existing backend foundation still passes all 57 tests across 8 test files, and the TypeScript build is passing.
To be clear, the reusable package itself has not been implemented yet. The completed work so far is the specification and package-design phase.
The next step is to begin the Weeks 3–4 implementation work:
Create the isolated packages/access package
Prove that the built package works for ESM and CommonJS projects
Implement receipt claim validation
Implement signing and verification
Implement binding and replay-safe redemption
Begin the paid-resource example
I will continue sharing updates here as implementation progresses.