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

1.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 inferring a person's emotions from workplace telemetry is prohibited outside medical or safety reasons ([EU-AI-ACT] Article 5(1)(f)). 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.¶

1.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 [RFC9052] 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. Scoping consent by provenance class as well as by category follows the provenance-class extension of consent in [MORRISON-IFT], Section 6.2.¶

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. Any identity-attestation authority can implement this protocol against its own substrate. The wire format does not embed any single authority's namespace.¶

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

• Requested and standing delivery.¶

• Briefs a handle addresses to itself.¶

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

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

2.2. Definitions

Where this document names a handle in prose, the identifier is an alter: URI as defined in [ALTER-URI], for example alter:~example.com for an organisation or alter:~alice for a person. A handle carried in the iss, aud or peer field keeps the bare ~-prefixed form of Section 3.1; the value ~alice corresponds to the URI alter:~alice.¶

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 category, 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 recorded decision, an explicit status update, a request put to the reader. 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.¶

3.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
                                             ; unless aud = iss, see
                                             ; Section 13
  delivery        : ? "requested" / "standing", ; Section 12, default
                                             ; "requested"
  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
  category        : tstr,                    ; a registered signal
                                             ; category, Section 3.3;
                                             ; the dimension
                                             ; consent_gate.scope is
                                             ; drawn against, see
                                             ; Section 6.2 and Section 8
                                             ; step 7
  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]. The x402 key carries an optional commerce quote, which a reader settles with the x402 payment protocol [X402].¶

3.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" / "delivery"
provenance-value = %x22 "active" %x22 /
                   %x22 "passive-aggregate" %x22
                   ; passive-individual-local is absent from this
                   ; rule; 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.¶

3.3. Signal Categories

A signal's category says what the signal is about. It is the dimension a capability token scopes against, together with the signal's provenance class. The initial categories are:¶

• event: something that happened during the brief's window.¶

• decision: a decision taken during the window.¶

• request: an action or an answer asked of the reader.¶

• status: the current state of something the reader follows.¶

• other: a signal that fits none of the above.¶

Urgent items are carried in the escalations array, not as a signal category. An issuer MUST NOT emit a category that is not in the "Morning Brief Signal Categories" registry (Section 11.4). A reader that receives a category it does not recognise MUST treat the signal as other for presentation. It MUST still apply Section 8 step 7 to the category as received, so an unrecognised category never widens the released scope.¶

4.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 recorded decisions, explicit status updates, and entries their subject has signed under the key custody rules of [IDCOMMITS]. Active signals are the default expected class for brief contents.¶

4.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. An aggregate over a cohort smaller than this threshold is treated as a passive-individual observation and is prohibited on the wire per Section 4.3.¶

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 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 exclusion is made in the grammar rather than in a policy filter because [EU-AI-ACT] Article 5(1)(f) prohibits AI systems that infer the emotions of a natural person in the workplace and in education institutions, except for medical or safety reasons, and passive individual telemetry is a common basis for such inference. A policy filter can fail silently. A grammar-level exclusion is checked by every conformant parser on every brief. It catches the forbidden value wherever it appears under its own name; Section 10.1 states what it does not catch.¶

5.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, so the issuer and reader 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.¶

5.2. Envelope Signature

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

• alg: EdDSA (Ed25519), registered in [RFC9053] Section 2.2, using the key bound to the issuer's handle per [IDCOMMITS] Section 5.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.¶

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

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

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

7.1. not_after Default

Every brief MUST carry a not_after field. The default value is 24 hours after iat. The lifetime is bounded for two reasons:¶

• Freshness. Situational awareness loses value quickly. A brief older than a day seldom describes the current state.¶

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

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

10.1. Emotion-Adjacent Inference and EU AI Act Article 5(1)(f)

[EU-AI-ACT] Article 5(1)(f) prohibits placing on the market, putting into service, or using AI systems to infer the emotions of a natural person in the workplace or in education institutions, except for medical or safety reasons. A situational-awareness payload that carries emotional or engagement state inferred from passive telemetry can bring its issuer within that prohibition when used in workplace or education flows.¶

This specification pre-empts one specific failure mode at the grammar layer. A compliant issuer correctly classifies a signal as passive-individual-local, then attempts to transmit it under that label; that attempt is what gets rejected. The provenance_class vocabulary 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.¶

This grammar-level rejection does not, by itself, make an implementation Article 5(1)(f) compliant; it defends the literal-token case only. Whether a signal is classified correctly in the first place is a property of the issuer's psychometric or behavioural inference layer, which this document's Scope section places outside what this specification defines. An implementation that routes passive-individual signals to the wire by encoding them under active or passive-aggregate labels has produced a brief that is syntactically conformant but substantively non-conformant, and is separately liable under the Article 5(1)(f) regime; this specification supplies no mechanical means to detect that mislabelling.¶

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

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

10.4. Essential-Facility and Antitrust Posture

A specification whose trusted output can be produced only through a single attestation authority makes that authority an essential facility for every party that exchanges briefs. A specification that is publicly readable but whose operation requires an account at a particular provider invites scrutiny as lock-in from competition regulators.¶

The envelope is COSE_Sign1 [RFC9052]; the canonicalisation is JCS [RFC8785]; the key discovery is DNS-based per [MCPDNS]. None of these depends on any specific attestation authority. Any attestation authority or identity substrate may implement this 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.¶

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

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

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

10.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.4: DNSSEC requirement where available, TLS-terminated .well-known fallback, and independent transparency-log anchoring where a log is deployed.¶

11.1. Media Type Registrations

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

11.2. DNS Underscore Label

This document requests IANA to add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry established by [RFC8552]:¶

• RR Type: TXT¶

• _NODE NAME: _alter-brief-revocation¶

• Reference: Section 7.2 of this document¶

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

11.4. Signal Category Registry

This document requests establishment of a "Morning Brief Signal Categories" registry. Each entry carries a category name, a short description and a reference. The initial entries are event, decision, request, status and other, each as described in Section 3.3, with this document as the reference.¶

The registration policy is Specification Required per BCP 26. The designated expert SHOULD refuse a category that duplicates an existing one, and SHOULD refuse one whose meaning depends on a single implementer's tooling rather than on what the signal is about.¶

11.5. No Other IANA Actions

This document requests no other IANA actions.¶