SOAP-2-REST Licensing Overview

Learn how SOAP-2-REST licensing works. Entitlement is defined by a signed license from the platform, controlling expiry, installation binding, and

{/* AUTO-GENERATED from the docs pipeline — do not edit by hand /} {/ source doc_id: prd-s2r-docs-public-knowledgebase-licensing-readme · version: 1.7.7 */}

Overview

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

The license is verified against public keys that the product fetches from the Specaria platform. Each license contains:

An expiry date.
A binding to a specific installation.
Two capacity caps:
1. The number of services that may be discovered.
2. The number of services that may be run as converted/active.

This document provides an overview of the licensing model, its operational requirements, and its behavior during network disruptions.

How It Works

The licensing mechanism is designed to validate entitlement by periodically communicating with the Specaria platform.

License Verification Flow

The product's entitlement is expressed as an RS256-signed license. The product validates this license's signature using public verification keys.

Unlike earlier models where keys were bundled statically, the current model fetches these keys from the Specaria platform via an outbound HTTPS connection. This allows for security practices like key rotation without requiring a product update. The product periodically re-verifies its license against the fetched keys.

The diagram below illustrates the communication between a SOAP-2-REST installation and the Specaria platform for license verification.

sequenceDiagram
    participant P as SOAP-2-REST Installation
    participant S as Specaria Platform

    P->>S: Fetch verification keys (Outbound HTTPS)
    S-->>P: Return public keys
    loop Periodic Re-verification
        P->>P: Verify signed license using fetched keys
    end
    Note over P,S: All connections are outbound from the installation to the platform.

NOTE

An optional capacity heartbeat may also be sent from the product to the platform.

Bootstrap Process

A verification key is bundled into the product binary, but it serves only as a bootstrap seed. This seed key is used for the very first startup to establish initial trust before the product has successfully contacted the Specaria platform. It is not used for long-term license verification.

Summary of Key Topics

Topic	Summary
License model	RS256-signed license as source of truth; verified against keys fetched from the Specaria platform; re-verified periodically.
Capacity counting	Two dimensions — discovered services (no decay) and converted/active services (decays over a rolling 7-day window).
Offline grace	A bounded grace window when the platform is unreachable, then a degraded/read-only mode; telemetry fails open, entitlement fails closed.
Egress allow-list	Outbound HTTPS to the Specaria platform; metadata only, never payloads or PII.

Relationship to the Earlier Static-File Model

The current platform-integrated licensing model (v1.0) supersedes a predecessor that used a static-file approach. In the earlier model:

Public verification keys were bundled into the product binary at build time.
The license was a file uploaded by the operator.
Validation was performed entirely offline with no contact to an external platform.

The v1.0 model's shift to fetching keys from the Specaria platform enables key rotation and periodic re-verification, enhancing security and operational flexibility.

Design Scope and Limitations

By design, the v1.0 licensing model has the following characteristics:

It does not send sensitive data. Your SOAP payloads, backend hostnames, or any end-user Personally Identifiable Information (PII) are never sent to the Specaria platform. Communication is limited to metadata.
It does not require inbound connectivity. The Specaria platform never initiates connections to your product installation. All communication is outbound from the product to the platform.
It does not immediately stop traffic on platform disconnect. The product includes a bounded offline grace window to handle temporary network disruptions without affecting running services.

Troubleshooting

Platform Unreachability

If the SOAP-2-REST installation cannot connect to the Specaria platform to verify its license, it enters a bounded offline grace window.

During the grace window: The product continues to function normally. Existing runtime traffic is not affected.
After the grace window: If connectivity is not restored, the product enters a degraded/read-only mode.

This behavior is governed by the principle that "entitlement fails closed." While telemetry failures are tolerated ("fail open"), the inability to verify entitlement eventually restricts functionality after the grace period expires.