Standard internal API-to-API communication model for Dream Consistency services, Client libraries, request authentication, authorization, and secure transport.
| Decision | LOCKED BASELINE |
| Primary implementation | DreamConsistency.Security.ServiceAuth |
| Client pattern | DreamConsistency.<Service>.Client NuGet package |
| Deployment model | Service identity and configuration are Realm/environment specific. |
| Production status | Baseline accepted; additional production hardening is required for sensitive financial flows. |
Internal API consumers should normally use a versioned Client NuGet package provided for the target service. The Client library encapsulates service location, HTTP communication, request signing, stable client-side models, and transport concerns.
Shared service consumers should not manually construct internal HTTP calls throughout application code. A dedicated Client NuGet package provides the supported integration surface.
| Component | Responsibility |
|---|---|
| Service API | Owns domain logic, HTTP endpoints, authorization, server-side DTOs and persistence. |
| Service Client | Consumer SDK, typed HttpClient registration, request/response client models and remote error handling. |
| ServiceAuth | Calling-service authentication and request-integrity protection. |
| Consumer | Depends on the Client package rather than duplicating target-service HTTP logic. |
DreamConsistency.Security.ServiceAuth provides authenticated
internal service requests using HMAC-based request signing.
The signature is bound to the concrete HTTP request rather than acting as a reusable bearer credential.
Binding the signature to method, path, query and body protects request integrity and prevents a captured signature from being trivially reused for another operation.
| Identity | Meaning |
|---|---|
Service_UUID |
Stable identity of the logical service type across environments and deployments. |
ServiceInstance_UUID |
Identity of a concrete deployed service instance in a particular Realm/environment. |
The same tested application image may therefore be deployed into multiple Realms while keeping separate runtime instance identities and Realm-local secrets.
The target API remains responsible for endpoint-level or capability-level authorization based on the validated calling service identity.
ServiceAuth authenticates the caller and protects request integrity. It does not encrypt the HTTP payload.
Financial information, credentials, secrets, password-related data and other sensitive payloads must never rely on request signing as a replacement for transport encryption.
Timestamp and nonce validation are part of the ServiceAuth security model. Production deployments must fail closed when a request falls outside the accepted timestamp window or when a nonce has already been accepted.
Replay protection must remain valid when a service runs with multiple replicas. It must not depend only on isolated per-process memory where multiple instances can accept the same replayed request independently.
ServiceAuth signing secrets are runtime secrets. They must not be stored in source control, application images, committed configuration files, or Client NuGet packages.
Vault, Jenkins credentials, environment injection, or another approved secret-delivery mechanism must provide secrets to deployed services.
Authentication failures must fail closed. Invalid signatures, unknown callers, replayed requests, invalid timestamps, missing required authentication material, and unauthorized service operations must never silently downgrade to trusted execution.
Cross-service business workflows must also assume that the remote request can fail after local work has already succeeded. Workflows spanning multiple services or databases therefore remain idempotent and retry-safe.
Internal services are normally deployed per Realm/environment where their domain requires Realm-local state.
The shared Billing service follows the same communication pattern.
When Billing requires authoritative commercial information, it uses an explicitly approved product-side service contract rather than directly reading another domain's database.
| Area | Required Direction |
|---|---|
| Replay protection | Shared/multi-replica-safe nonce validation. |
| Signing keys | Reduce shared-secret blast radius and support controlled key rotation. |
| Authorization | Explicit caller permissions at the target API boundary. |
| Transport | Encrypted transport for sensitive production communication. |
| Observability | Security events and caller identity should be auditable without logging secrets. |
| Date | Change | Author |
|---|---|---|
| 2026-09-30 | Established the shared Dream Consistency Service-to-Service Communication baseline based on the existing AccessControl Client/API and ServiceAuth implementation. | Branko |