REFERENCE
Glossary.
Precise definitions for the terms used across the Ewii site. Built for engineers and security reviewers who want a single reference rather than a marketing rephrasing.
- Hub
- The operator-side component of an Ewii deployment. The Hub runs in the operator's infrastructure, accepts inbound connections from Clients in customer environments, validates each Client's identity, and brokers application-layer queries between the operator's services and the customer-side workloads.
- Client
- The customer-side component of an Ewii deployment. The Client is a signed container image the customer runs alongside the database or service the operator needs to reach. The Client opens a single outbound connection to the Hub on port 443; no inbound firewall rules are required.
- Relay
- A network component that forwards encrypted traffic between the Hub and the Client. The relay holds ciphertext only — it cannot decrypt the application-layer payloads, which are end-to-end encrypted between the Hub and the Client.
- Outbound-only
- A connectivity model in which the customer side only initiates connections outward and exposes no inbound listeners. The customer's firewall does not require any inbound rules for the operator's traffic. See /insights/outbound-only-vs-site-to-site-vpn for the architectural argument.
- Workload identity
- An identity issued to a specific workload (a service running specific code in a specific environment), as distinct from a user identity or a network identity. Workload identity allows authorization decisions to survive infrastructure-level events. The dominant standard is SPIFFE.
- SPIFFE
- Secure Production Identity Framework For Everyone. An open-source standard for issuing cryptographic identities to workloads. SPIFFE produces SVIDs (SPIFFE Verifiable Identity Documents) in X.509 or JWT form. Maintained by the Cloud Native Computing Foundation.
- SVID
- SPIFFE Verifiable Identity Document. A cryptographic identity for a workload, in X.509 certificate or JWT form. Issued by a SPIFFE workload API in the workload's environment, validated by the consuming party against the issuer's trust bundle.
- Trust bundle
- The set of certificate authorities that a relying party considers authoritative for issuing identities. In Ewii, each customer has a separate trust bundle on the Hub side; an SVID issued by Tenant A's issuer will not validate against Tenant B's trust bundle.
- mTLS
- Mutual TLS. A TLS handshake in which both the client and the server present certificates and validate the other party's certificate. Provides mutual authentication at the transport layer. mTLS is a primitive Ewii uses; it is not a complete connectivity solution. See /compare/vs-mtls.
- ChaCha20-Poly1305
- An authenticated encryption with associated data (AEAD) cipher. Used by Ewii for application-layer payload encryption between the Hub and the Client. Specified in RFC 8439. Selected for its performance on commodity hardware without dedicated AES instructions.
- X25519
- An elliptic-curve Diffie-Hellman key exchange function over the Curve25519 elliptic curve. Used by Ewii for ephemeral key exchange at session establishment. Specified in RFC 7748. Provides forward secrecy.
- HKDF
- HMAC-based Key Derivation Function. Used by Ewii to derive session keys from the X25519-derived shared secret. Specified in RFC 5869. Used with SHA-256 in the Ewii cryptographic primitive matrix.
- Cosign
- A tool for signing and verifying container images. Customers run `cosign verify` against the Ewii Client image before deployment to confirm its provenance. Maintained as part of the Sigstore project.
- MCP
- Model Context Protocol. A standard for AI assistants to call external tools. MCP servers wrap tools (databases, APIs, ticketing systems) for use by AI models. The connectivity problem MCP made urgent is the subject of /insights/mcp-connectivity-problem.
- Identity-verified query
- A query whose authorization is bound to the identity of the requesting workload, validated cryptographically at issuance. Distinguished from a connection-authorized query, where authorization applies to a connection rather than a query.
- Architecture Review
- A 60-minute working session between the Ewii team and a prospective operator's technical and security leadership. The session walks through the operator's use case against the Ewii architecture and produces a trust-center pack draft. Schedule at /architecture-review.
- Trust Center pack
- A single document set containing the artifacts a regulated procurement review requires: topology diagram, cryptographic primitive matrix, identity model, audit model, failure-mode analysis, subprocessor table, and audit reports. Available at /trust.
- CAIQ-Lite
- Consensus Assessments Initiative Questionnaire — Lite. A 73-question security questionnaire across 17 control domains. Maintained by the Cloud Security Alliance. The most common starting point for a SaaS security questionnaire in 2026.
- ITSG-33
- IT Security Guidance 33. Canadian federal government information-system security guidance. Defines security control catalogs at protected levels (Protected A, B, C). Ewii maintains an ITSG-33 control mapping for the Protected B level.
- PCI-DSS
- Payment Card Industry Data Security Standard. Mandatory for any system that stores, processes, or transmits cardholder data. Ewii's deployment for payment-card-data customers is documented for PCI-DSS scope reduction; the Hub does not enter cardholder-data scope.
- HIPAA
- Health Insurance Portability and Accountability Act. United States federal regulation governing the use and disclosure of protected health information. Ewii deployments touching PHI require a Business Associate Agreement (BAA) — see /trust.
- PHIPA
- Personal Health Information Protection Act. Ontario provincial legislation governing personal health information. Ewii deployments for Ontario healthcare customers are aligned with PHIPA in addition to HIPAA where US data is involved.
- FIPPA
- Freedom of Information and Protection of Privacy Act. Ontario provincial legislation governing personal information held by provincial institutions. Relevant for Ewii deployments at provincial ministries.
- MFIPPA
- Municipal Freedom of Information and Protection of Privacy Act. Ontario municipal-government counterpart to FIPPA. Relevant for Ewii deployments at municipal institutions in Ontario.
- BAA
- Business Associate Agreement. A contract required under HIPAA when a covered entity discloses PHI to a business associate. Ewii provides a BAA template for healthcare customers. See /trust for the current template.
- KMS
- Key Management System. A system for generating, storing, rotating, and destroying cryptographic keys. Ewii Canadian deployments use Canadian-controlled KMS infrastructure to satisfy data-sovereignty requirements.
- Zero-trust architecture
- An architectural pattern in which no implicit trust is granted based on network location. Defined in NIST SP 800-207. The seven properties an honest zero-trust connectivity deployment satisfies are listed in /compare/vs-zero-trust-marketing.
- Defense-in-depth
- A security pattern in which multiple independent controls protect the same asset, so that the failure of one control does not produce a catastrophic outcome. Ewii layers transport encryption, application-layer encryption, identity validation, and per-query authorization for defense-in-depth.
- Threat model
- A structured analysis of the threats a system is designed to defend against, the assumptions the analysis depends on, and the residual risks. Ewii publishes a threat-model summary as part of the Trust Center pack.
- On-premises (on-prem)
- Infrastructure running in the customer's own datacenter or private cloud, as opposed to a third-party cloud. The Ewii Client is deployed on-prem, alongside the customer's database or service. The Hub may be on-prem (for the operator) or in any environment the operator chooses.
- Hub-and-spoke
- A network topology in which a central hub connects to multiple endpoints (spokes), as distinct from a mesh topology in which endpoints connect to each other. Ewii is a hub-and-spoke deployment by design — one Hub per operator, many Clients per Hub.