The Morning Brief: A Federated, Identity-Attested Situational-Awareness Payload
draft-morrison-morning-brief-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Blake Morrison | ||
| Last updated | 2026-08-11 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-morrison-morning-brief-01
Network Working Group B. Morrison
Internet-Draft Alter Meridian Pty Ltd
Intended status: Informational 9 August 2026
Expires: 10 February 2027
The Morning Brief: A Federated, Identity-Attested Situational-Awareness
Payload
draft-morrison-morning-brief-01
Abstract
This document defines the Morning Brief: a federated, identity-
attested situational-awareness payload exchanged between
organisations, their agents, and peer agents operating under an
Identity Accord [ACCORD]. A Morning Brief carries a signed, bounded-
lifetime summary of signals, escalations, decisions, and optional
commerce quotes from one ~handle to another. Every signal entry
carries a provenance_class distinguishing active self-report, passive
aggregate observation, and passive individual observation; the last
of these is forbidden on the wire and rejected at the grammar level.
Readers present a capability token scoped by (category,
provenance_class) that gates release BEFORE payload emission, not
after. The payload is envelope-signed with COSE_Sign1 [RFC9052] over
a JCS-canonicalised [RFC8785] representation, bound to the issuer's
Sovereign-tier handle per [IDCOMMITS]. Briefs carry a mandatory
not_after (default 24h) and reference a revocation endpoint
discovered via DNS TXT per [MCPDNS]. The document defines the wire
format only; rendering, storage, and retention are out of scope.
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 10 February 2027.
Morrison Expires 10 February 2027 [Page 1]
Internet-Draft Morning Brief August 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.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Payload Structure . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Abstract Schema . . . . . . . . . . . . . . . . . . . . . 7
3.2. ABNF Grammar for Canonical Serialisation . . . . . . . . 8
4. Provenance Classes (Normative) . . . . . . . . . . . . . . . 8
4.1. Active . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Passive-Aggregate . . . . . . . . . . . . . . . . . . . . 8
4.3. Passive-Individual-Local (Forbidden on the Wire) . . . . 9
5. Envelope and Signing . . . . . . . . . . . . . . . . . . . . 9
5.1. Canonicalisation . . . . . . . . . . . . . . . . . . . . 9
5.2. Envelope Signature . . . . . . . . . . . . . . . . . . . 9
5.3. Verification . . . . . . . . . . . . . . . . . . . . . . 10
6. Consent Gate (Normative) . . . . . . . . . . . . . . . . . . 10
6.1. Ordering Rule . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Capability Token . . . . . . . . . . . . . . . . . . . . 10
7. Lifetime and Revocation . . . . . . . . . . . . . . . . . . . 11
7.1. not_after Default . . . . . . . . . . . . . . . . . . . . 11
7.2. Revocation Endpoint . . . . . . . . . . . . . . . . . . . 11
8. Reader Behaviour (Normative) . . . . . . . . . . . . . . . . 11
9. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10.1. Emotion-Adjacent Inference and EU AI Act Article
5(1)(f) . . . . . . . . . . . . . . . . . . . . . . . . 13
10.2. Consent-Gate Ordering . . . . . . . . . . . . . . . . . 14
10.3. Revocation and not_after . . . . . . . . . . . . . . . . 14
10.4. Essential-Facility and Antitrust Posture . . . . . . . . 14
10.5. Key Compromise . . . . . . . . . . . . . . . . . . . . . 15
10.6. Passive-Aggregate Threshold Attacks . . . . . . . . . . 15
10.7. Capability-Token Binding . . . . . . . . . . . . . . . . 15
Morrison Expires 10 February 2027 [Page 2]
Internet-Draft Morning Brief August 2026
10.8. DNS Dependencies . . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11.1. Media Type Registrations . . . . . . . . . . . . . . . . 15
11.1.1. application/morning-brief+cbor . . . . . . . . . . . 16
11.1.2. application/morning-brief+json . . . . . . . . . . . 16
11.2. DNS Underscore Label . . . . . . . . . . . . . . . . . . 17
11.3. Provenance-Class Vocabulary Registry . . . . . . . . . . 17
11.4. No Other IANA Actions . . . . . . . . . . . . . . . . . 18
12. Relationship to Existing Drafts . . . . . . . . . . . . . . . 18
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Normative References . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
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
inference of emotional or behavioural state from workplace
telemetry is prohibited ([EU-AI-ACT] Article 5(1)(f)). A flat
payload offers no hook for that gate.
Morrison Expires 10 February 2027 [Page 3]
Internet-Draft Morning Brief August 2026
* *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.
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.
1.3. Scope
This document specifies:
* The Morning Brief payload structure in CDDL-adjacent form and an
ABNF grammar for the canonical serialisation.
Morrison Expires 10 February 2027 [Page 4]
Internet-Draft Morning Brief August 2026
* 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].
2. Terminology
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.
Morrison Expires 10 February 2027 [Page 5]
Internet-Draft Morning Brief August 2026
2.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.
Morrison Expires 10 February 2027 [Page 6]
Internet-Draft Morning Brief August 2026
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. Payload Structure
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)
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", category :
"decision" / "contact" / "commit" / "escalation" / "draft" / "other",
; the scoping 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].
Morrison Expires 10 February 2027 [Page 7]
Internet-Draft Morning Brief August 2026
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"
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.
4. Provenance Classes (Normative)
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 typed decisions, explicit status updates, and commits
authored with clear attribution [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. Aggregates over cohorts smaller
than this threshold are categorically passive-individual observations
and are prohibited on the wire per Section 4.3.
Morrison Expires 10 February 2027 [Page 8]
Internet-Draft Morning Brief August 2026
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 [EU-AI-ACT] Article 5(1)(f)
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.
5. Envelope and Signing
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, 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.
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.
* kid: the issuer's Identity-Key-Id value per [IDCOMMITS]
Section 4.1.
Morrison Expires 10 February 2027 [Page 9]
Internet-Draft Morning Brief August 2026
* 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. Consent Gate (Normative)
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.
Morrison Expires 10 February 2027 [Page 10]
Internet-Draft Morning Brief August 2026
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. Lifetime and Revocation
7.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.
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.
8. Reader Behaviour (Normative)
A conformant reader MUST perform the following steps in order for
each received brief:
1. *Parse the outer COSE_Sign1 structure.* A reader that cannot
parse the envelope MUST reject the brief.
Morrison Expires 10 February 2027 [Page 11]
Internet-Draft Morning Brief August 2026
2. *Resolve the issuer key and verify the signature.* The reader
resolves the issuer's public key via [MCPDNS] and verifies the
Ed25519 signature over the canonicalised payload. Signature
failure is a terminal rejection.
3. *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.
4. *Check lifetime bounds.* The reader MUST verify iat <= now <=
not_after. Out-of-bounds briefs are rejected.
5. *Check revocation, if policy requires.* The reader queries the
revocation endpoint per Section 7.2. Revoked briefs are
rejected.
6. *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.
7. *Check consent-gate scope containment.* For every signal in the
payload, the reader MUST verify that the pair (signal.category,
signal.provenance_class) is a member of the consent_gate.scope
set echoed in the brief. A signal whose pair falls outside the
echoed scope is a terminal rejection of the entire brief; the
reader MUST discard the brief and SHOULD log the violation
against the issuer handle. This step is independent of step 6.
Step 6 detects drift between the scope the reader requested and
the scope the issuer echoed; this step detects drift between the
echoed scope and the payload actually delivered.
8. *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.
Morrison Expires 10 February 2027 [Page 12]
Internet-Draft Morning Brief August 2026
* revoked - revocation endpoint indicated the brief was revoked.
Conflating these states is a security defect.
9. 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.
10. Security Considerations
10.1. Emotion-Adjacent Inference and EU AI Act Article 5(1)(f)
[EU-AI-ACT] Article 5(1)(f) 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 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
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.
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
Morrison Expires 10 February 2027 [Page 13]
Internet-Draft Morning Brief August 2026
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 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 [RFC9052]; 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.
Morrison Expires 10 February 2027 [Page 14]
Internet-Draft Morning Brief August 2026
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.3: DNSSEC requirement where
available, TLS-terminated .well-known fallback, and independent
transparency-log anchoring where a log is deployed.
11. IANA Considerations
11.1. Media Type Registrations
This document requests registration of the following media types in
the "Media Types" registry.
Morrison Expires 10 February 2027 [Page 15]
Internet-Draft Morning Brief August 2026
11.1.1. 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 10 of this document.
* Interoperability considerations: CBOR canonical form per [RFC8949]
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.
11.1.2. application/morning-brief+json
* Type name: application
* Subtype name: morning-brief+json
Morrison Expires 10 February 2027 [Page 16]
Internet-Draft Morning Brief August 2026
* Required parameters: none
* Optional parameters: charset (UTF-8 is the only permitted value).
* Encoding considerations: 8bit; UTF-8 only.
* Security considerations: see Section 10 of this document. Note
that the JSON debug form is not intended for production exchange.
* Interoperability considerations: JCS [RFC8785] 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 [RFC8259].
* 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.
11.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.
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.
Morrison Expires 10 February 2027 [Page 17]
Internet-Draft Morning Brief August 2026
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. No Other IANA Actions
This document requests no other IANA actions.
12. Relationship to Existing Drafts
The Morning Brief is a sibling, not a dependency, of the other drafts
in the ALTER identity-protocol stack.
Morrison Expires 10 February 2027 [Page 18]
Internet-Draft Morning Brief August 2026
+==================================+=============+===============+
| Draft | Layer | Relationship |
| | | to this |
| | | document |
+==================================+=============+===============+
| draft-morrison-mcp-dns-discovery | L1: | Informative. |
| | transport | This document |
| | discovery | uses DNS TXT |
| | | discovery for |
| | | key and |
| | | revocation. |
+----------------------------------+-------------+---------------+
| draft-morrison-identity-pronouns | L1: handle | Informative |
| | grammar | via |
| | | [IDCOMMITS]. |
+----------------------------------+-------------+---------------+
| [IDCOMMITS] | L2: atomic | Normative. |
| | attestation | This document |
| | | inherits key |
| | | custody and |
| | | signature |
| | | rules. |
+----------------------------------+-------------+---------------+
| [ACCORD] | L2: inter- | Normative. |
| | org | Briefs are |
| | handshake | exchanged |
| | | under an |
| | | existing |
| | | Accord. |
+----------------------------------+-------------+---------------+
| draft-morrison-morning-brief | L3: | N/A. |
| (this) | periodic | |
| | payload | |
| | exchange | |
+----------------------------------+-------------+---------------+
Table 1
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.
Morrison Expires 10 February 2027 [Page 19]
Internet-Draft Morning Brief August 2026
13. 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.
14. References
14.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>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/info/rfc9053>.
[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/>.
Morrison Expires 10 February 2027 [Page 20]
Internet-Draft Morning Brief August 2026
[IDCOMMITS]
Morrison, B., "Identity-Attributed Git Commits via Tier-
Structured Trailers", 2026,
<https://datatracker.ietf.org/doc/draft-morrison-identity-
attributed-commits/>.
14.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>.
Author's Address
Blake Morrison
Alter Meridian Pty Ltd
Email: blake@truealter.com
Morrison Expires 10 February 2027 [Page 21]