Json Rpc Sign Bundle Laravel Package

Technical Evaluation

Architecture fit. tourze/json-rpc-sign-bundle is a signing layer for JSON-RPC traffic — most likely a Symfony-style bundle from a prolific but low-ceremony vendor, wrapped around request/response signing (HMAC or asymmetric) rather than a Laravel-native package. Before treating it as a Laravel component, confirm whether it ships a ServiceProvider/Facade or expects Symfony's DI container. If the latter, it fits only as a low-level library consumed behind our own adapter, not as a first-class Laravel dependency.

Integration feasibility. The concept is straightforward: a client decorator or middleware that canonicalizes and signs outbound JSON-RPC payloads, with server-side verification. Feasibility hinges on three unknowns we cannot resolve from the 0.1.0 release notes (which contain only a changelog link): (1) which signature algorithm(s) and canonicalization scheme are implemented, (2) how key material is supplied and rotated, (3) whether it is PSR-7/PSR-18 compatible or binds to a specific HTTP client. Any of these being bespoke materially increases integration cost.

Technical risk.

• Pre-1.0 API instability. A 0.0.3 → 0.1.0 jump is a minor-version bump by semver convention, but in a 0.x package it is a strong signal of breaking changes with no compatibility promise. The changelog link is the only artifact; there is no prose describing what broke.
• Security-sensitive surface. Signature canonicalization, replay protection, and key handling are exactly where subtle defects are most damaging and least visible in testing. Absence of published test coverage or a security policy is a material gap.
• Vendor concentration. Single-maintainer, high-volume publishing pattern. Bus-factor and long-term maintenance risk are real.
• Documentation deficit. No README excerpt, no usage example, no migration note in the release.

Key questions.

1. Does the bundle register Laravel service providers, or is it Symfony-container-only?
2. Which algorithms (HMAC-SHA256, RSA, Ed25519) and what canonicalization is used — and is it specified anywhere we can audit?
3. Does it provide replay protection (nonce/timestamp window) or only payload integrity?
4. What is the test suite coverage, and is there a published security contact?
5. What broke between 0.0.3 and 0.1.0, and is there a public changelog with commit-level detail?
6. Are PHP version and framework constraints declared in composer.json, and do they match our runtime?

Integration Approach

Stack fit. Target Laravel 10/11 on PHP 8.1+. Treat this package as an infrastructure concern isolated to the JSON-RPC transport layer, not as something that touches domain code. If it is Symfony-coupled, wrap it: our own SigningTransport interface with the bundle as one implementation, so replacement cost stays low.

Migration path. There is no prior assessment and no incumbent, so this is a greenfield adoption rather than a migration. Proceed as a time-boxed spike in a non-production branch: install, sign a request against a local verifier, and confirm interop with the counterparty's verification implementation. The counterparty contract — not this package — is the real integration target.

Compatibility. Pin an exact version (0.1.0), not a caret range; a ^0.1 constraint permits 0.2.x-style breakage under 0.x semver rules that Composer will still resolve. Verify transitive dependencies against our existing HTTP client and any PSR implementations already in the tree to avoid duplicate-interface conflicts.

Sequencing.

1. Changelog and source audit of 0.0.3 → 0.1.0; confirm scope of changes.
2. Spike: sign/verify round-trip in a scratch service.
3. Adapter implementation behind an internal interface, with contract tests.
4. Shadow-mode deployment: sign and verify alongside the existing path without enforcing.
5. Enforce signing on one low-risk RPC endpoint; expand on evidence.
6. Decide build-vs-buy formally — a few hundred lines of HMAC signing with our own canonicalization may be cheaper to own than an unversioned 0.x dependency.

Operational Impact

Maintenance. Assume we own the integration glue indefinitely. Budget for periodic upstream audits, since release notes are changelog links rather than curated summaries — upgrade decisions will require reading commits. Maintain a fork-ready posture: keep the adapter thin enough that a vendored fork is a one-day change.

Support. No evidence of an SLA, issue triage cadence, or commercial backing. Escalation path is the maintainer's GitHub. Plan for self-support on any production incident involving signature verification.

Scaling. Signing itself is CPU-cheap and stateless, so horizontal scaling is not a concern — unless the implementation requires a shared nonce store or a central key service, which would introduce a stateful dependency and a new bottleneck. Confirm this before committing.

Failure modes to instrument explicitly.

• Signature mismatch after a key rotation — the most likely production break; needs a distinct metric and alert, not a generic 4xx.
• Clock skew on timestamped signatures — enforce NTP and alert on skew above the tolerance window.
• Replay acceptance if nonce tracking is absent or in-memory only across multiple pods.
• Silent downgrade if verification failure is caught and treated as unsigned-and-allowed; make enforcement fail-closed by configuration, and test that path.
• Dependency breakage from an unpinned transitive update.

Ramp-up. Low conceptual complexity, moderate operational subtlety. One engineer can absorb the package in a day; the harder ramp is the counterparty's verification contract and our key-management runbook. Document key provenance, rotation procedure, and rollback before the first enforced endpoint goes live. Given the pre-1.0 state, 0.1.0 is suitable for a controlled pilot, not a broad platform commitment.