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

3.1. 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 ([EU-AI-ACT] 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.¶

3.2. Design Goals

1. Federated. No central clearinghouse. Issuer and reader each resolve the other's handle via [MCPDNS].¶

2. Identity-attested at the sovereign layer. Envelope signature is COSE_Sign1 [RFC8152] over a JCS-canonicalised [RFC8785] payload, bound to the issuer's Sovereign-tier handle per [IDCOMMITS].¶

3. 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.¶

4. 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.¶

5. Bounded lifetime with published revocation. Every brief carries not_after (default 24h). The issuer publishes a revocation endpoint via DNS TXT per [MCPDNS]. Readers MUST honour both.¶

6. Protocol, not platform. A separate conformance specification ([ALTER-CONFORMANCE], 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.¶

3.3. 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 [MCPDNS] and incorporated by reference via [IDCOMMITS].¶

• The inter-organisational handshake that establishes the Accord relationship between issuer and reader. This is defined in [ACCORD].¶

4.1. 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 [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

4.2. Definitions

Morning Brief

A bounded-lifetime situational-awareness payload exchanged between two handles under an Identity Accord [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 [MCPDNS] 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.¶

5.1. 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 [IDCOMMITS].¶

5.2. 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 [RFC5234] 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.¶

6.1. 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 [IDCOMMITS]. Active signals are the default expected class for brief contents.¶

6.2. 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.¶

6.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 [EU-AI-ACT] 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.¶

7.1. Canonicalisation

The payload is canonicalised using JCS [RFC8785] 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 [RFC8949] Section 4.2.¶

7.2. Envelope Signature

The signed envelope is a COSE_Sign1 structure [RFC8152] with the following parameters:¶

• alg: EdDSA (Ed25519) per [IDCOMMITS] Section 5.¶

• kid: the issuer's Identity-Key-Id value per [IDCOMMITS] 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 [MCPDNS] and [IDCOMMITS]. Brief signing and commit signing are governed by the same key-custody discipline; key compromise affects both surfaces identically.¶

7.3. Verification

A reader verifies a brief by:¶

1. Resolving the issuer's public key via [MCPDNS] using the kid named in the COSE_Sign1 headers.¶

2. Recomputing the canonical serialisation of the payload.¶

3. Verifying the Ed25519 signature against the recomputed bytes.¶

4. Checking that iat <= now <= not_after.¶

5. Querying the revocation endpoint (Section 7) if policy requires revocation freshness.¶

8.1. 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.¶

8.2. 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 [ACCORD] and are out of scope for this document.¶

9.1. 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.¶

9.2. Revocation Endpoint

The issuer publishes a revocation endpoint URI via a DNS TXT record under the issuer's policy zone per [MCPDNS]. 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.¶

12.1. Emotion-Adjacent Inference and EU AI Act Article 5(1)(d)

[EU-AI-ACT] 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.¶

12.2. 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.¶

12.3. 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.¶

12.4. 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 [RFC8152]; the canonicalisation is JCS [RFC8785]; the key discovery is DNS-based per [MCPDNS]. None of these depends on any specific attestation authority. To make this posture operationally real, a separate conformance specification [ALTER-CONFORMANCE] 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.¶

12.5. Key Compromise

A compromised Sovereign signing key enables an attacker to mint briefs purporting to come from the compromised issuer. Mitigations are inherited from [IDCOMMITS] 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.¶

12.6. 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.¶

12.7. Capability-Token Binding

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

12.8. 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 [IDCOMMITS] Section 9.3: DNSSEC requirement where available, TLS-terminated .well-known fallback, and independent transparency-log anchoring where a log is deployed.¶

13.1. Media Type Registrations

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

13.2. 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.¶

13.3. 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.¶

13.4. No Other IANA Actions

This document requests no other IANA actions.¶

16.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.¶

[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.¶

[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, July 2017.¶

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.¶

[RFC8785] Rundgren, A., et al., "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020.¶

[ACCORD] Morrison, B., "The Identity Accord: An Inter-Organisational Handshake Protocol", draft-morrison-identity-accord, work in progress.¶

[IDCOMMITS] Morrison, B., "Identity-Attributed Git Commits via Tier-Structured Trailers", draft-morrison-identity-attributed-commits, work in progress.¶

16.2. Informative References

[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017.¶

[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, December 2020.¶

[MCPDNS] Morrison, B., "Discovery of Model Context Protocol Servers via DNS TXT Records", draft-morrison-mcp-dns-discovery, work in progress.¶

[EU-AI-ACT] European Parliament and Council of the European Union, "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)", 2024.¶

[ALTER-CONFORMANCE] Morrison, B., "Morning Brief Conformance Specification (Apache-2.0)", https://truealter.com/standards/morning-brief-conformance, 2026.¶

18.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC5234]

Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC8152]

Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <https://www.rfc-editor.org/info/rfc8152>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/info/rfc8785>.

[ACCORD]

Morrison, B., "The Identity Accord: An Inter-Organisational Handshake Protocol", 2026, <https://datatracker.ietf.org/doc/draft-morrison-identity-accord/>.

[IDCOMMITS]

Morrison, B., "Identity-Attributed Git Commits via Tier-Structured Trailers", 2026, <https://datatracker.ietf.org/doc/draft-morrison-identity-attributed-commits/>.

18.2. Informative References

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.

[MCPDNS]

Morrison, B., "Discovery of Model Context Protocol Servers via DNS TXT Records", 2026, <https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-discovery/>.

[EU-AI-ACT]

European Parliament and Council of the European Union, "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)", 2024, <https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.

[ALTER-CONFORMANCE]

Morrison, B., "Morning Brief Conformance Specification (Apache-2.0)", 2026, <https://truealter.com/standards/morning-brief-conformance>.