Concept

Identity model

Every party communicating through HexaEight has an identity. There are two kinds — user identities and agent identities — and a small set of rules governs which can talk to which.

User identities

A user identity is an email address, validated by the HexaEight Authenticator mobile app. A user creates their identity on their phone; the same identity is usable from any device the user signs in on.

User identities are intended for humans — people who initiate conversations with agents on their behalf. A user identity is bound to the person, not to a machine.

Agent identities

An agent identity is a hostname bound to a specific machine. Two forms exist:

• Generic agent identity — automatically generated names in the form web0-bliss-cyan-<rotating-word>. The first three words are derived from the issuing user's email so no two users can claim the same prefix; the final word rotates per issuance.
• Custom-hostname agent identity — a hostname under a domain you control (for example, agent01.acme.com). Custom hostnames require a DNS TXT proof of domain ownership before the platform will issue the identity.

Agent identities are intended for autonomous software. An agent does not need a human at the keyboard to send or receive messages.

Machine binding

An agent identity is activated on a specific machine through a one-time activation flow. The activation produces a file (hexaeight.mac) that the SDK uses thereafter to authenticate the agent. If the file is moved to another machine, the agent identity no longer works there.

The same agent identity can be activated on multiple machines (a separate activation per machine). This is the foundation of the swarm scaling model.

What identifies an identity over the wire

Inside the SDK, an identity is represented by an opaque cryptographic identifier issued by the platform at activation time. This identifier is embedded in every outbound message and is what the receiving SDK uses to fetch the corresponding decryption key.

From the application's perspective, you address messages by identity name (an email address or a hostname). The SDK handles the translation between that human-readable name and the cryptographic identifier underneath. Pages later in this documentation describe the wire format in detail if you need that information; for most development work, the identity name is the only thing you ever need to type.

Communication rules

The platform enforces a small set of rules about which identity types can communicate with which. These rules exist for a specific security reason described below.

Identity lifetime is tied to the license

An identity is valid for as long as its underlying HexaEight license is valid. The licensing model differs depending on how the identity was acquired:

• Standalone license — issued for a fixed term (annual, multi-year). The identity remains usable as long as the license is in good standing. When the license expires, the identity stops working until you renew. Renewal preserves the identity name and credentials; you do not get a new identity.
• Azure Marketplace VM — billed per running VM. Multiple identities can be issued and used as long as the VM remains running (and billable). When the VM is stopped or deallocated, the identities issued against that VM stop working.

Within an active license period there is no rotation cycle, no certificate renewal, and no scheduled re-keying. The identity is stable for the license's lifetime. Messages signed under that identity remain cryptographically verifiable thereafter using the standard HexaEight signing facilities.