The Morning Brief: A Federated, Identity-Attested Situational-Awareness Payload

Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 28, 2026.

Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document.

Introduction

Problem Statement Organisations and their agents routinely exchange bounded-horizon situational-awareness payloads: what happened since the last exchange, what is on fire, what decisions were taken, what is open. The daily "standup" is the human idiom for this exchange; agent-to-agent protocols in deployment today reproduce the same shape without a shared wire format. Each implementer ships its own JSON blob, its own authentication story, its own retention assumptions, and its own implicit answer to the question of how the signals inside the payload were obtained. The absence of a shared wire format produces three operational defects: No portable attestation. A brief from one organisation to another cannot be cryptographically bound to a specific issuer handle without bespoke integration. The receiver either trusts the transport (TLS to a known endpoint) or implements a custom signing scheme per counter-party. No provenance discipline. Signals in an ad-hoc brief are flat strings. The receiver cannot distinguish a statement the subject actively made from an inference drawn from passive telemetry. This distinction is legally significant in jurisdictions where inference of emotional or behavioural state from workplace telemetry is prohibited ( Article 5(1)(d)). A flat payload offers no hook for that gate. No consent gate before release. A receiver that wants a subset of the brief today cannot signal that intent before the sender composes the payload. Consent is enforced post-hoc by filtering on the receiver side, which assumes the prohibited fields ever reach the wire. This document specifies a wire format that addresses all three defects: an envelope-signed payload bound to a Sovereign-tier handle, a provenance_class field on every signal entry with a grammar-level prohibition against passive-individual observations traversing the wire, and a capability-token gate presented by the receiver before payload emission.

Design Goals Federated. No central clearinghouse. Issuer and reader each resolve the other's handle via . Identity-attested at the sovereign layer. Envelope signature is COSE_Sign1 over a JCS-canonicalised payload, bound to the issuer's Sovereign-tier handle per . Provenance-typed at the grammar level. Every signal entry carries a provenance_class. Passive-individual observations MUST NOT appear on the wire; they are rejected at parse time, not at policy time. Consent-gated before release. The reader presents a capability token scoped by (category, provenance_class). The issuer filters the payload against that scope BEFORE signing and transmission. Bounded lifetime with published revocation. Every brief carries not_after (default 24h). The issuer publishes a revocation endpoint via DNS TXT per . Readers MUST honour both. Protocol, not platform. A separate conformance specification (, Apache-2.0) allows any identity-attestation authority to implement this protocol against its own substrate. The wire format does not embed any single authority's namespace.

Scope This document specifies: The Morning Brief payload structure in CDDL-adjacent form and an ABNF grammar for the canonical serialisation. The provenance_class taxonomy and the grammar-level rejection of passive-individual-local. The capability-token consent-gate exchange. The COSE_Sign1 envelope binding to the issuer's Sovereign-tier handle. The not_after default and the DNS-published revocation endpoint lookup. Reader behaviour for accepting, rejecting, and surfacing brief states. Media-type and IANA considerations for application/morning-brief+cbor and +json. This document does NOT specify: UI rendering of briefs. Rendering is an implementation concern for consuming clients. Storage or retention of briefs by readers. Retention is governed by the reader's data-protection regime and the issuer's not_after and revocation signal. The psychometric or behavioural inference layer that produces signal payloads within an issuer organisation. This document treats signals as opaque strings with an attached provenance_class. The ~handle identity primitive, which is defined in and incorporated by reference via . The inter-organisational handshake that establishes the Accord relationship between issuer and reader. This is defined in .

Terminology

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 when, and only when, they appear in all capitals, as shown here.

Definitions

Morning Brief: A bounded-lifetime situational-awareness payload exchanged between two handles under an Identity Accord . A brief is a single unit of exchange, signed as a whole by the issuer and addressed to a specific audience.
Issuer: The handle whose Sovereign-tier key signs the brief's COSE_Sign1 envelope. The issuer is the iss field of the payload.
Reader: The handle named in the brief's aud field. The reader is the intended consumer. A brief MAY be addressed to an agent handle, an organisational handle, or a group, subject to the terms of the underlying Accord.
Signal: A single bounded entry within the signals array of a brief. A signal carries a kind, a provenance_class, a source reference, a timestamp, and a body.
Provenance Class: A controlled-vocabulary tag on each signal indicating the class of observation that produced it. See Section 4.
Active Signal: A signal whose body was actively produced by its subject for the purpose of being shared. Examples: a typed decision, an explicit status update, a scheduled commit. provenance_class = "active".
Passive-Aggregate Signal: A signal whose body is a statistical aggregate over a population of k >= 1000 subjects, such that no individual is identifiable. provenance_class = "passive-aggregate".
Passive-Individual-Local Signal: An observation about a single individual derived from passive telemetry (typing cadence, audio features, biometrics, presence heuristics). These observations MUST NOT leave the device on which they are computed and MUST NOT appear on the Morning Brief wire. The token is defined in this document only to specify the grammar-level prohibition.
Capability Token: A bearer token presented by the reader to the issuer's brief endpoint, scoped by the cartesian product of (category, provenance_class) pairs the reader is authorised to receive. The token is consumed by the issuer at composition time, before signing.
Not-After: The UTC timestamp after which a brief MUST NOT be relied upon. Default 24 hours from issuance.
Revocation Endpoint: A URI published by the issuer via DNS TXT per that returns the revocation status of a brief identified by its envelope identifier.
Conformant Verifier: A consumer of Morning Briefs that implements the parsing, consent-gate enforcement, provenance rejection, and signature verification rules defined in Section 8.

Payload Structure

Abstract Schema A Morning Brief is a map with the following top-level fields. In the canonical CBOR serialisation, fields are encoded with integer keys; the JSON debug serialisation uses the string labels below. ``` MorningBrief = { v : uint, ; protocol version, = 1 iss : handle, ; issuer Sovereign handle aud : handle / array of handle, ; intended reader(s) iat : time, ; issuance timestamp not_after : time, ; expiry timestamp accord : [+ accord-ref], ; accord binding (>=1 entry) summary : tstr, ; human-readable precis signals : [* signal], ; zero or more signals escalations : [* escalation], ; zero or more escalations x402 : ? commerce-quote, ; optional commerce quote consent_gate : gate-descriptor, ; scope actually released revocation : uri, ; revocation endpoint } signal = { id : tstr, ; issuer-unique signal id kind : "decision" / "contact" / "commit" / "escalation" / "draft" / "other", provenance_class: "active" / "passive-aggregate", ; passive-individual-local ; is FORBIDDEN source : uri, ts : time, body : tstr, attest : ? COSE_Sign1_structure, ; optional per-signal ; attestation } escalation = { sev : "critical" / "high" / "medium", ref : uri, sla : ? duration, } commerce-quote = { quote_uri : uri, price : decimal, currency : tstr, ; e.g. "USDC" ttl : duration, } gate-descriptor = { scope : [+ (category, provenance_class)], token_endpoint : uri, } accord-ref = { peer : handle, accord_id : uri, ; reference to Accord record } ``` The handle type is a ~-prefixed identifier per .

ABNF Grammar for Canonical Serialisation The CBOR serialisation is canonical for transmission. The JSON serialisation is permitted for debugging, human-readable logs, and test vectors. Both serialisations MUST preserve the same field set and the same type discipline. The following ABNF defines the lexical grammar of the JSON debug serialisation. The CBOR canonical form is governed by the schema above. brief = "{" brief-members "}" brief-members = pair *( "," pair ) pair = quoted-key ":" value quoted-key = %x22 key-name %x22 key-name = "v" / "iss" / "aud" / "iat" / "not_after" / "accord" / "summary" / "signals" / "escalations" / "x402" / "consent_gate" / "revocation" provenance-value = %x22 "active" %x22 / %x22 "passive-aggregate" %x22 ; passive-individual-local is syntactically absent ; from this rule by design; see Section 4.3. A parser that encounters the literal string "passive-individual-local" as the value of any provenance_class field MUST reject the entire brief as malformed and MUST NOT process any of its contents. This is a grammar-level rejection, not a policy filter.

Provenance Classes (Normative)

Active An active signal is one whose body was produced by the subject for the explicit purpose of being shared through this channel. Examples include typed decisions, explicit status updates, and commits authored with clear attribution . Active signals are the default expected class for brief contents.

Passive-Aggregate A passive-aggregate signal is a statistical summary computed over a population of at least 1000 subjects, such that no individual subject is identifiable from the aggregate. Implementations MUST enforce the k >= 1000 threshold at aggregation time and MUST NOT emit an aggregate with a smaller cohort. Aggregates over cohorts smaller than this threshold are categorically passive-individual observations and are prohibited on the wire per Section 4.3.

Passive-Individual-Local (Forbidden on the Wire) A passive-individual-local observation is an inference about a single subject derived from passive telemetry such as typing cadence, audio features, biometric signals, engagement heat maps, or presence heuristics. Such observations MUST remain on the device that computed them and MUST NOT appear on the Morning Brief wire under any encoding, any field, or any extension. The grammar of Section 3.2 omits the passive-individual-local token from the provenance-value rule precisely so that a conformant parser treats its appearance as a structural violation. An issuer that transmits a brief containing such a value has produced a malformed brief; a reader that accepts such a brief has violated this specification. The rationale for grammar-level exclusion rather than policy-level filtering is that emotion-adjacent inference from passive workplace telemetry is categorically prohibited by Article 5(1)(d) in workplace and education contexts. A policy-level filter is an implementation detail that can fail silently; a grammar-level exclusion is a machine-checkable invariant that cannot.

Envelope and Signing

Canonicalisation The payload is canonicalised using JCS prior to signing. JCS produces a deterministic byte sequence from a JSON document regardless of key ordering or whitespace, enabling the issuer and reader to agree on the exact bytes covered by the signature. When the canonical CBOR serialisation is in use, the same deterministic ordering MUST be applied to the map keys before the signature is computed, using the CBOR canonical-form rules of Section 4.2.

Envelope Signature The signed envelope is a COSE_Sign1 structure with the following parameters: alg: EdDSA (Ed25519) per Section 5. kid: the issuer's Identity-Key-Id value per Section 4.1. Payload: the JCS-canonicalised brief payload. The signing key is the issuer's Sovereign-tier signing key, the same key bound to the issuer's ~handle by the DNS-published record per and . Brief signing and commit signing are governed by the same key-custody discipline; key compromise affects both surfaces identically.

Verification A reader verifies a brief by: Resolving the issuer's public key via using the kid named in the COSE_Sign1 headers. Recomputing the canonical serialisation of the payload. Verifying the Ed25519 signature against the recomputed bytes. Checking that iat <= now <= not_after. Querying the revocation endpoint (Section 7) if policy requires revocation freshness.

Consent Gate (Normative)

Ordering Rule The consent gate MUST be enforced BEFORE the issuer composes or signs the brief payload. This ordering is normative: a gate applied after payload composition requires the issuer to produce the full superset payload in memory, from which a filter removes fields the reader is not authorised to see. In the event of a filter defect, the full superset is a leak candidate. The gate-before-release rule removes the unauthorised fields from the compositional step; they are never produced.

Capability Token The reader presents a capability token to the issuer's brief endpoint prior to payload emission. The token scope is a set of (category, provenance_class) pairs that the issuer is authorised to release to this reader in this request. The issuer consumes the scope at composition time; fields outside the authorised scope MUST NOT appear in the resulting payload. The consent_gate field in the emitted brief echoes the scope actually honoured, so that the reader can detect drift between the scope it requested and the scope the issuer applied. Token issuance, rotation, and revocation are governed by the Accord relationship established under and are out of scope for this document.

Lifetime and Revocation

not_after Default Every brief MUST carry a not_after field. The default value is 24 hours after iat. The rationale for a bounded lifetime is twofold: Freshness. Situational awareness loses value quickly. A brief older than a day is of archaeological interest, not operational interest. Liability bound. An issuer who accidentally emits a brief with a sensitive signal has a bounded exposure window. A 24-hour ceiling prevents indefinite replay. Issuers MAY specify a shorter not_after for higher-sensitivity contexts. Issuers SHOULD NOT specify a longer not_after; readers MAY reject briefs with not_after - iat > 24h.

Revocation Endpoint The issuer publishes a revocation endpoint URI via a DNS TXT record under the issuer's policy zone per . The record is keyed by _alter-brief-revocation underscore-prefixed label. The endpoint accepts the brief's envelope identifier and returns a boolean revocation status with a short cache lifetime. Readers processing a brief for a decision with material consequence SHOULD query the revocation endpoint even when not_after is in the future. Readers MAY cache revocation responses for the interval indicated by the endpoint's response headers, but MUST NOT cache beyond the brief's not_after.

Reader Behaviour (Normative) A conformant reader MUST perform the following steps in order for each received brief: Parse the outer COSE_Sign1 structure. A reader that cannot parse the envelope MUST reject the brief. Resolve the issuer key and verify the signature. The reader resolves the issuer's public key via and verifies the Ed25519 signature over the canonicalised payload. Signature failure is a terminal rejection. Enforce grammar-level provenance rejection. The reader scans the parsed payload for any occurrence of passive-individual-local as a provenance value. Its presence anywhere in the brief is a terminal rejection; the reader MUST discard the brief and SHOULD log the violation against the issuer handle. Check lifetime bounds. The reader MUST verify iat <= now <= not_after. Out-of-bounds briefs are rejected. Check revocation, if policy requires. The reader queries the revocation endpoint per Section 7.2. Revoked briefs are rejected. Check consent-gate scope echo. The reader compares the brief's consent_gate.scope to the scope it presented in its capability token. A mismatch is not necessarily a rejection (the issuer may lawfully narrow the scope), but a widening is a conformance violation and MUST be rejected. Verify per-signal attestations, if present. Signals MAY carry their own attest COSE_Sign1 structure. If present, the reader verifies each per the same key-resolution path. A conformant reader SHOULD distinguish four brief states in any user-facing surface: verified-fresh - envelope signature valid, lifetime in bounds, revocation check passed. verified-expired - signature valid but not_after in the past. unverified - signature failed or key could not be resolved. revoked - revocation endpoint indicated the brief was revoked. Conflating these states is a security defect.

Media Types This document defines two media types: application/morning-brief+cbor - the canonical CBOR serialisation. This is the on-wire format. application/morning-brief+json - the JSON debug serialisation. Intended for test vectors, logs, and development tooling. Deployments SHOULD default to the CBOR form for production exchanges. The JSON form is for human-readable contexts where wire efficiency is not a concern.

Security Considerations

Emotion-Adjacent Inference and EU AI Act Article 5(1)(d) Article 5(1)(d) categorically prohibits the placing on the market of AI systems that infer emotions of a natural person in the workplace or in education institutions. A naive situational-awareness payload that includes inferred emotional or engagement state from passive telemetry is a direct breach if used in org- or education-facing flows. This specification pre-empts such breaches at the grammar layer. The provenance_class vocabulary deliberately excludes passive-individual-local from the wire; the ABNF of Section 3.2 renders the forbidden value syntactically unreachable; and the reader-behaviour rule of Section 8 step 3 requires terminal rejection of any brief in which the forbidden value appears. Implementers cannot make this specification Article 5(1)(d) compliant by adding a filter; the filter is the grammar itself. An implementation that routes passive-individual signals to the wire by encoding them under active or passive-aggregate labels has produced a non-conformant brief and is separately liable under the Article 5(1)(d) regime.

Consent-Gate Ordering The gate-before-release ordering of Section 6.1 is normative. A gate applied post-composition is a different specification and MUST NOT be referred to as conforming to this document. Readers SHOULD treat any issuer that advertises post-composition gating as out of conformance and SHOULD refuse exchanges with such an issuer.

Revocation and not_after A brief's signed payload is replayable for as long as the signature verifies mathematically. The not_after field provides a hard upper bound on acceptance, defaulting to 24 hours to limit the exposure of any single brief to at most one operational day. The DNS-published revocation endpoint allows the issuer to shorten that window in response to mis-issuance or leak detection. Readers performing material actions on the basis of a brief SHOULD NOT rely on not_after alone when the action is sensitive; they SHOULD additionally check revocation. Readers performing routine display SHOULD rely on cached revocation up to the cache lifetime indicated by the endpoint's response.

Essential-Facility and Antitrust Posture A specification that requires issuers to use a single attestation authority to produce trusted briefs creates an essential-facility problem. If the specification is "open" in the sense of publicly readable but its operation requires accounts at a particular provider, competition regulators treat the resulting lock-in as anticompetitive. This document is deliberately protocol-not-platform. The envelope is COSE_Sign1 ; the canonicalisation is JCS ; the key discovery is DNS-based per . None of these depends on any specific attestation authority. To make this posture operationally real, a separate conformance specification is published under Apache-2.0 and tracked in the issuer's public standards repository. Any attestation authority or identity substrate may implement against that conformance specification and produce briefs that readers of this protocol accept without special integration. Implementers who encounter a deployment that requires a specific attestation authority to produce or verify briefs SHOULD treat that requirement as a conformance defect and escalate it through standards-body channels.

Key Compromise A compromised Sovereign signing key enables an attacker to mint briefs purporting to come from the compromised issuer. Mitigations are inherited from Section 9.1: key rotation under a new kid, historical key retention for retrospective verification, and compromise-vs-hygiene distinction in the rotation metadata. Readers encountering a compromise-rotated key SHOULD treat briefs signed by that key as suspect even when the signature validates.

Passive-Aggregate Threshold Attacks The k >= 1000 threshold for passive-aggregate signals is a privacy floor, not a privacy ceiling. An attacker with auxiliary information may still re-identify individuals within an aggregate of 1000 subjects if the aggregate is sufficiently high-dimensional. Implementations producing aggregates for emission SHOULD apply standard statistical-disclosure-control techniques (noise injection, cell suppression, top-coding) in addition to the threshold. This specification defines the minimum acceptable cohort size; it does not define the maximum acceptable disclosure risk.

Capability-Token Binding A capability token presented by a reader MUST be bound to the reader's Sovereign handle under the Accord relationship . A bearer token with no binding to a specific reader is a replay vector and MUST NOT be accepted by conformant issuers.

DNS Dependencies Brief verification depends on DNS resolution for issuer key discovery and for revocation-endpoint lookup. Mitigations for DNS poisoning are as described in Section 9.3: DNSSEC requirement where available, TLS-terminated .well-known fallback, and independent transparency-log anchoring where a log is deployed.

IANA Considerations

Media Type Registrations This document requests registration of the following media types in the "Media Types" registry.

application/morning-brief+cbor Type name: application Subtype name: morning-brief+cbor Required parameters: none Optional parameters: none Encoding considerations: binary Security considerations: see Section 11 of this document. Interoperability considerations: CBOR canonical form per Section 4.2 is required. Published specification: this document. Applications that use this media type: agent-to-agent and organisation-to-organisation situational-awareness exchange. Fragment identifier considerations: none. Additional information: Deprecated alias names for this type: none. Magic number(s): none. File extension(s): .cbor-brief Macintosh file type code(s): none. Intended usage: COMMON Restrictions on usage: none. Author: Blake Morrison. Change controller: IETF.

application/morning-brief+json Type name: application Subtype name: morning-brief+json Required parameters: none Optional parameters: charset (UTF-8 is the only permitted value). Encoding considerations: 8bit; UTF-8 only. Security considerations: see Section 11 of this document. Note that the JSON debug form is not intended for production exchange. Interoperability considerations: JCS canonical form is required when the payload is to be signed. Published specification: this document. Applications that use this media type: development and debugging tools for the Morning Brief exchange. Fragment identifier considerations: per . File extension(s): .json-brief Intended usage: COMMON Restrictions on usage: SHOULD NOT be used on production exchanges; CBOR form is preferred. Author: Blake Morrison. Change controller: IETF.

DNS Underscore Label This document uses the underscore-prefixed DNS label _alter-brief-revocation. Registration of this label in any applicable DNS scoped-label registry is requested, pending registry establishment.

Provenance-Class Vocabulary Registry This document requests establishment of a "Morning Brief Provenance Classes" registry with initial entries: active - see Section 4.1. passive-aggregate - see Section 4.2. The passive-individual-local token is intentionally NOT registered. Its non-registration is the normative expression of its prohibition on the wire. Future additions to this registry MUST NOT register any token whose semantics would permit single-subject passive inference to cross the wire. The registration policy is Standards Action per BCP 26.

No Other IANA Actions This document requests no other IANA actions.

Relationship to Existing Drafts The Morning Brief is a sibling, not a dependency, of the other drafts in the ALTER identity-protocol stack. Draft Layer Relationship to this document draft-morrison-mcp-dns-discovery L1: transport discovery Informative. This document uses DNS TXT discovery for key and revocation. draft-morrison-identity-pronouns L1: handle grammar Informative via . L2: atomic attestation Normative. This document inherits key custody and signature rules. L2: inter-org handshake Normative. Briefs are exchanged under an existing Accord. draft-morrison-morning-brief (this) L3: periodic payload exchange N/A. The Morning Brief is the first "dynamic payload" draft in the stack. The earlier drafts define how a handle is known; this document defines what a handle shares while being known.

Acknowledgments The author thanks the founding circle of Alter Meridian Pty Ltd for adversarial review of the consent-gate ordering rule and the grammar-level provenance rejection. The passive-individual-local prohibition on the wire is motivated by the compute-location provenance gate articulated in Section 5; the rationale is restated in this document at the level required for protocol implementation. Additional contributors will be named at review time following the first round-trip exchange of briefs under an Identity Accord.

References

Normative References Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, July 2017. Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. Rundgren, A., et al., "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020. Morrison, B., "The Identity Accord: An Inter-Organisational Handshake Protocol", draft-morrison-identity-accord, work in progress. Morrison, B., "Identity-Attributed Git Commits via Tier-Structured Trailers", draft-morrison-identity-attributed-commits, work in progress.

Informative References Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017. Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, December 2020. Morrison, B., "Discovery of Model Context Protocol Servers via DNS TXT Records", draft-morrison-mcp-dns-discovery, work in progress. European Parliament and Council of the European Union, "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)", 2024. Morrison, B., "Morning Brief Conformance Specification (Apache-2.0)", https://truealter.com/standards/morning-brief-conformance, 2026.

Author's Address Blake Morrison Alter Meridian Pty Ltd Email: blake@truealter.com URI: https://truealter.com