Conformance
An implementation is REP-conformant if it satisfies the requirements below. This page is extracted from REP-RFC-0001 Section 11.
Gateway conformance (MUST)
Section titled “Gateway conformance (MUST)”A conformant gateway implementation MUST:
- Read only
REP_*prefixed environment variables - Classify variables into exactly three tiers based on prefix (
PUBLIC,SENSITIVE,SERVER) - Strip the classification prefix from variable names in the payload
- Reject startup if variable names collide after prefix stripping
- Run secret detection guardrails on PUBLIC tier variables
- Inject a
<script id="__rep__" type="application/json">block into HTML responses - Compute and include an HMAC-SHA256 integrity token
- Encrypt SENSITIVE tier variables using AES-256-GCM
- Issue single-use, time-limited session keys via
/rep/session-key - Never transmit SERVER tier variables to the client under any circumstances
Client SDK conformance (MUST)
Section titled “Client SDK conformance (MUST)”A conformant SDK implementation MUST:
- Read from
<script id="__rep__">synchronously on import - Verify payload integrity on initialization (SRI hash)
- Expose
get()as a synchronous function - Expose
getSecure()as an async function - Make no network calls during initialization
- Freeze the public variable object to prevent mutation
Optional features (MAY)
Section titled “Optional features (MAY)”Conformant implementations MAY implement:
- Hot reload via Server-Sent Events
- Manifest file validation at startup
- TypeScript type generation from manifest
- Framework-specific adapters (React hooks, Vue composables, Svelte stores)
- Codemod tooling for migration
- “MUST”, “SHOULD”, and “MAY” follow RFC 2119 conventions
- The reference implementation (gateway in Go, SDK in TypeScript) satisfies all MUST requirements and implements all optional features
- Alternative implementations need only satisfy the MUST requirements to be conformant