DataFab Licensing Service
Version: 1.0 Last Updated: September 2026
Component Overview
The licensing service is the vendor-side component of the licensing mechanism for DataFab components delivered into a client environment. A licensing agent bundled with the licensed application periodically sends a signed usage report to the service. The service checks that the report comes from a registered instance running an approved build, records the usage counters and returns a signed, time-limited lease that allows the application to keep running. That is its only function: it sits outside the application’s processing path and never sees the data the application works on.
Each call carries an instance identifier, a hash of the deployed build and aggregate usage counters. The service records those calls and the leases it issues, and nothing else. It has no access to the client environment, and it neither receives nor stores personal data or any data the licensed application processes.
Licensed application + agent (client env) ──outbound TLS──▶ Licensing Service (DataFab AWS)
◀──signed lease (status, valid until)──
Deployment and Connectivity
| Aspect | Position |
|---|---|
| Hosting | Deployed in the DataFab AWS environment, in a region agreed with the client, as one application service with a PostgreSQL database |
| Direction | One-directional — the client environment opens outbound TLS connections to the reporting endpoint |
| Inbound access | None — the service never initiates connections into the client environment and holds no credentials, network route or access into it |
| Authentication | Every report is signed by the agent with an Ed25519 private key that never leaves the client environment; the service verifies the signature against the public key registered for that instance and rejects anything else. No passwords, tokens or other secrets are transmitted |
| Response integrity | Every lease is signed by the service with its own Ed25519 key; the agent verifies it against the service’s public key, published on a read-only endpoint |
| Build integrity | Each report includes a hash of the deployed build; only builds approved by DataFab receive an active lease |
| Availability | If the service is unreachable, the licensed application keeps running on its last valid lease until that lease expires |
| Operator access | Instance registration, build approval and usage reporting are exposed only through a separate operator interface, protected by an operator key that is never shared with the agent |
What Data the Service Receives
The service receives one kind of message: a usage report. Its shape is fixed by the report schema; any other field in a request is ignored and not stored.
| Report Element | Content | Personal Data |
|---|---|---|
report_id |
Random identifier for the report, used to de-duplicate retries | No |
instance_id |
Identifier of the licensed instance, assigned by DataFab when the instance is registered | No |
period_start, period_end |
The reporting window | No |
code_digest |
Cryptographic hash of the deployed build | No |
metrics |
Aggregate usage counters for the window — one count per usage category dictated by the service (see collection scope below), optionally split per tenant | No — counts only |
| HTTP headers | The instance identifier and the report signature | No |
The service has no access to client systems, records, documents or any data beyond the report body.
What Data the Service Produces
The response to every report is a signed lease. It contains only licensing state.
| Lease Property | Description |
|---|---|
| Status | active, or blocked with the reason (unknown instance, invalid signature, malformed report, unapproved build) |
| Validity | Issue time and expiry; the lease lifetime is configured per instance |
| Accepted report | The identifier of the report the lease was issued for |
| Collection scope | The usage categories the agent should count in the next period |
| Signature | Ed25519 signature over the lease, verified by the agent |
What the Service Stores
All records live in a PostgreSQL database inside the same DataFab AWS environment and are reachable only through the operator interface.
| Record | Contents | Source |
|---|---|---|
| Registered instances | Instance identifier, display name, the agent’s public key, lease settings, the usage categories to collect, time of last report | Set by DataFab at registration |
| Approved builds | Hash and version label of each approved release, and who approved it | Set by DataFab |
| Usage reports | The report elements above and the time received | One row per call from the agent |
| Issued leases | Instance, lease status, validity window, time issued, reason if declined | Generated by the service |
The usage reports and issued leases are the call statistics. They are used for licence and usage reconciliation and for a watchdog that flags an instance that has stopped reporting. Application logs contain no report contents; standard access logs record the time, endpoint and outcome of each call, plus the source address of the calling environment.
The service never receives or stores:
- Business data of any kind: no records, documents, transactions, cases or other content the licensed application processes.
- Customer, client or end-user records: no names, identifiers, account numbers, contact details or free text.
- User activity inside the licensed application: no logins, usernames or operator actions.
- Details of the client environment: no hostnames, internal addresses, configuration or credentials.
- Files, logs or database extracts from the client environment.
The only effect the service can have on the client side is to decline to renew a lease.
Retention
No report content beyond the counters exists to retain. Long-term records on the DataFab side are limited to the licensing records themselves.
| Data | Retention | Purpose |
|---|---|---|
| Usage reports (counters) and issued leases | Term of the licence agreement | Licence and usage reconciliation, audit |
| Instance and build registry | Life of the instance | Report verification, kill-switch, watchdog |
Related Documents
- Onboarding — tenant activation, where licensing is provisioned for a newly onboarded organization
- OSINT Service — the other vendor-side service, using the same outbound-only, region-agreed connectivity pattern
- Trust & Compliance — security, compliance and governance for managed deployments