HOS Events 0.1

1. 01At-least-once delivery

   The same event can arrive more than once. Consumers deduplicate on source + id.

2. 02No global order

   Ordering holds only when a producer declares it, per subject or in total. Otherwise consumers order by time, then source, then id; delivery order never decides.

3. 03Declared capability

   A consumer processes only what the producer's manifest declares for the property. Undeclared means denied.

4. 04Source authority

   Only the declared system of record changes a value. Other facts are recorded and shown as conflicts, never merged into a single truth.

5. 05Replay

   Producers declare replay support and retention. Replays are JSON Lines, one event per line; a certified Event Producer profile provides at least 30 days.

6. 06Minimal data

   Data objects are closed. People appear only as pseudonymous references, message content never enters HOS, and vendor detail lives in namespaced extensions.

Example: the synthetic PMS manifest

1. 01Signed by its producer

   A producer signs its manifest, so a consumer can check who declared its capabilities and that nobody has changed them since. A consumer verifies a manifest it retrieves before trusting any declaration in it. A manifest that fails counts as no manifest: nothing is declared, so nothing is processed. A manifest an operator installs by hand, as the conformance scenarios do, is trusted as configured.

2. 02Three files

   A public producer serves, on one HTTPS origin, its manifest at /.well-known/hos/manifest.json, the signature at /.well-known/hos/manifest.jws and its public keys at /.well-known/hos/jwks.json. A private producer gives the three through configured, authenticated URLs.

3. 03Detached signature

   manifest.jws is a JWS in compact serialization with a detached payload (RFC 7515, appendix F): the header and the signature, with nothing between the two dots. The payload is the manifest in its canonical form (RFC 8785), in UTF-8, so spacing and member order in manifest.json do not matter. The manifest itself carries no signature.

4. 04Header

   The protected header holds alg, Ed25519 (RFC 9864) or ES256; kid, the signing key's id in the producer's key set; iat, when the manifest was signed; and exp, when the signature expires, both in whole seconds since the epoch. Every other algorithm is refused, none and EdDSA included, and so are crit and b64.

5. 05Keys

   jwks.json is a JSON Web Key Set (RFC 7517) of public keys only: an OKP key on Ed25519 for Ed25519, an EC key on P-256 for ES256. Each kid is unique in the set. A key that states alg, use or key_ops states its algorithm, sig and verify.

6. 06Verification

   A consumer canonicalizes the manifest it received, finds the key named by kid, checks that the key fits alg, and verifies the signature. It then checks that iat has come and exp has not, allowing at most 60 seconds of clock skew.

7. 07Rotation

   A producer signs its manifest again before exp. To change keys, it adds the new key to its key set, signs with it, and keeps the old key until every manifest signed with the old key has expired. A compromised key is removed at once, and whatever it signed then fails verification.

{
  "alg": "Ed25519",
  "kid": "Rmvn6iiK5EPEKShAwybtwHfST8XHnptFp5kdveGjsfk",
  "iat": 1790380800,
  "exp": 1821916800
}

Reference situation schema (non-normative)