Product Licensing and Entitlement

Overview

This product is licensed software. An installation's entitlement to operate is defined by a signed license issued by the Specaria platform. This license serves as the single source of truth for entitlement; the product does not grant capabilities based on local configuration alone.

The licensing system is designed to verify an installation's right to use the software and to enforce capacity limits, while allowing for temporary network disruptions. It requires periodic outbound connectivity to the Specaria platform to fetch public keys for license validation.

How it works

The product's entitlement is determined by a continuous verification process involving the signed license and the Specaria platform.

1. An operator installs a signed license, which is an RS256-signed token, into the product.
2. The product makes an outbound HTTPS request to the Specaria platform to fetch the public keys required to verify the license's signature.
3. The product validates the license against the fetched keys.
4. This verification process is repeated periodically to ensure the license remains valid and to synchronize with any key rotations on the platform.

If the product cannot reach the Specaria platform to refresh the verification keys, it enters a bounded offline grace period. During this time, functionality continues, but if connectivity is not restored before the grace period ends, the product enters a degraded, read-only mode. Entitlement checks "fail closed," meaning access is restricted upon prolonged failure, while telemetry reporting "fails open."

sequenceDiagram
    participant P as Your Product Installation
    participant S as Specaria Platform

    P->>P: Load signed license
    P->>S: Fetch public verification keys (HTTPS)
    S-->>P: Return public keys
    P->>P: Verify license signature using keys
    Note over P: Verification is repeated periodically.

License Contents

Each signed license contains the following information:

• Expiry: A timestamp after which the license is no longer valid.
• Installation Binding: A unique identifier that ties the license to a specific product installation.
• Capacity Caps: Two distinct limits on usage:
  • Discovered Services: The total number of unique backend services the product has identified.
  • Converted/Active Services: The number of services actively being exposed through the platform, measured over a rolling window.

Comparison with Legacy Licensing Model

This licensing model supersedes an earlier, static-file based system. The previous model involved a license file uploaded by an operator and validated offline using public keys that were bundled into the product binary at build time.

The current, platform-integrated model improves on this by dynamically fetching verification keys. This allows for key rotation without requiring a product update. A bundled key still exists, but it serves only as a bootstrap seed for the initial startup before the first successful connection to the Specaria platform. It is not used for long-term license verification.

Design Scope

The licensing model is intentionally designed with specific boundaries on its behavior and data access.

• No Payload Inspection: The system does not send any API request/response payloads, backend hostnames, or end-user Personally Identifiable Information (PII) to the Specaria platform.
• Outbound-Only Connectivity: The product initiates all connections to the Specaria platform. The platform does not require or use inbound network access to your installation.
• Graceful Offline Handling: The product does not immediately stop processing traffic if the Specaria platform becomes unreachable. It continues to operate within a defined offline grace window before any functionality is degraded.

See Also

• License Model Details
• Capacity Counting Logic
• Offline Grace Period Behavior
• Egress Allow-List Requirements

All SOAP-to-REST docs