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. 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. The payload is envelope-signed with COSE_Sign1 over a JCS-canonicalised representation, bound to the issuer's Sovereign-tier handle per the Identity-Attributed Git Commits draft. Briefs carry a mandatory not_after (default 24h) and reference a revocation endpoint discovered via DNS TXT records. A brief may be requested by its reader or delivered as a standing brief without a request, and a handle may address a brief to itself. The document defines the wire format only; rendering, storage, and retention are out of scope.
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 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, after the prohibited fields have already crossed 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 [RFC8610] 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, 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.
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.
Sovereign-tier handle Per [IDCOMMITS] Section 2.2. A handle representing a human individual or formal organisation that holds its own private key and can sign.
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 Reader 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
; 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 for a reader to settle 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. An unrecognised category therefore never widens the released scope.
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 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. Envelope and Signing
5.1. Canonicalisation
The payload is canonicalised using JCS [RFC8785] prior to signing. Because JCS produces a deterministic byte sequence from a JSON document regardless of key ordering or whitespace, 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. 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.
The consent_gate field in the emitted brief echoes the scope actually honoured. From it 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 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.
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.
- 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.
- 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) 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, and this document's Scope section places that layer 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 validation as [IDCOMMITS] Section 6.1 requires, 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.
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
- 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 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 [RFC8126].
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 [RFC8126]. 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.
12. Delivery (Normative)
A brief is delivered in one of two modes, named by delivery.
- requested: the reader presents its capability token and the issuer composes in response, as in Section 6. This is the default when delivery is absent.
- standing: the reader has registered a capability token with the issuer, and the issuer MAY compose and deliver a new brief when the brief's content changes, without a further request.
The consent gate of Section 6 applies to a standing brief as it does to a requested one. Revoking the registered token ends standing delivery; the issuer MUST NOT deliver a standing brief against a revoked token.
The delivery value is unrelated to provenance_class. The first describes how a brief reaches its reader; the second describes how a signal was obtained.
13. Briefs Addressed to the Issuer
A handle MAY issue a brief whose aud equals its iss, for example an agent composing, for its own principal, the signals gathered from several sources about that principal. Such a brief MAY carry an empty accord array, since no inter-organisational Accord binds a handle to itself. Every other rule in this document applies unchanged, including signature, provenance rejection, lifetime and consent gate.
aud names the handle the brief is for. A brief addressed to an agent handle is not a brief to that agent's principal. An implementation that intends a principal to read a brief MUST address the principal's handle, and SHOULD NOT treat delivery to an agent acting for the principal as delivery to the principal.
14. Relationship to Existing Drafts
This section lists the related drafts and how this document depends on each.
+==============================+=============+=====================+ | Draft | Layer | Relationship to | | | | this document | +==============================+=============+=====================+ | [MCPDNS] | L1: | Normative. This | | | transport | document uses DNS | | | discovery | TXT discovery for | | | | key and revocation. | +------------------------------+-------------+---------------------+ | [IDPRONOUNS] | L1: handle | Informative via | | | grammar | [IDCOMMITS]. | +------------------------------+-------------+---------------------+ | [IDCOMMITS] | L2: atomic | Normative. This | | | attestation | document inherits | | | | key custody and | | | | signature rules. | +------------------------------+-------------+---------------------+ | [ACCORD] | L2: inter- | Normative. Briefs | | | org | are exchanged under | | | handshake | an existing Accord. | +------------------------------+-------------+---------------------+ | draft-morrison-morning-brief | L3: | N/A. | | (this) | periodic | | | | payload | | | | exchange | | +------------------------------+-------------+---------------------+
Table 1
15. Acknowledgments
The author thanks colleagues at 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 specified in [COMPUTE-GATE]; the rationale is restated in this document at the level required for protocol implementation.
Additional contributors will be named at review time.
16. 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., "Identity Accord Protocol: A Peer Ceremony for Bilateral Agreements Between Identity-Substrate-Bound Principals", Work in Progress, Internet-Draft, draft-morrison-identity-accord-03, 2026, <https://datatracker.ietf.org/doc/draft-morrison-identity-accord/>;.
[IDCOMMITS] Morrison, B., "Identity-Attributed Git Commits via Tier-Structured Trailers", Work in Progress, Internet-Draft, draft-morrison-identity-attributed-commits-04, 2026, <https://datatracker.ietf.org/doc/draft-morrison-identity-attributed-commits/>;.
[MCPDNS] Morrison, B., "Discovery of Model Context Protocol Servers via DNS TXT Records", Work in Progress, Internet-Draft, draft-morrison-mcp-dns-discovery-09, 2026, <https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-discovery/>;.
17. Informative References
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>;.
[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>;.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>;.
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/info/rfc8552>;.
[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>;.
[X402] x402 Foundation (Linux Foundation), "x402: An Open Standard for HTTP-Native Payments", 2026, <https://github.com/x402-foundation/x402>;.
[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>;.
[COMPUTE-GATE] Morrison, B., "The Compute-Location Gate: Provenance-Class Routing of Identity Inference with Wire-Layer Refusal of Unconsented Provenance Classes", Work in Progress, Internet-Draft, draft-morrison-compute-location-gate-04, 2026, <https://datatracker.ietf.org/doc/draft-morrison-compute-location-gate/>;.
[IDPRONOUNS] Morrison, B., "Identity Pronouns: A Reference-Axis Extension to ~handle Identity Systems", Work in Progress, Internet-Draft, draft-morrison-identity-pronouns-05, 2026, <https://datatracker.ietf.org/doc/draft-morrison-identity-pronouns/>;.
[MORRISON-IFT] Morrison, B., "Identity Field Theory: Toward a Physics of Being Known", 2026, <https://doi.org/10.6084/m9.figshare.31951383>;.
[ALTER-URI] Morrison, B., "The 'alter' URI Scheme for Dispatchable ~handle References", Work in Progress, Internet-Draft, draft-morrison-alter-uri-scheme-05, 2026, <https://datatracker.ietf.org/doc/draft-morrison-alter-uri-scheme/>;.
Appendix A. Changes from draft-morrison-morning-brief-02
- Editorial pass: the references to other drafts move to the revisions submitted alongside this one. [IDPRONOUNS] is added as a reference in place of a bare draft name in Section 14. [RFC8610] and [RFC8126] are added for the CDDL-adjacent notation and the registration policies. The defined term Conformant Verifier is renamed Conformant Reader to match Section 8, and Sovereign-tier handle is added to the definitions. The DNS dependency paragraph of Section 10 now follows [IDCOMMITS] Section 6.1. Emphasis capitals outside BCP 14 key words are set in lower case. No requirement changes.
- Prose rewritten against the drafting rules, and every citation of another draft in the stack pinned to its latest posted revision.
- Section 14 now lists [MCPDNS] as normative, as the references have since -02.
Appendix B. Changes from draft-morrison-morning-brief-01
- Replaced the fixed signal kinds (decision, contact, commit, escalation, draft, other) with the category field alone, drawn from a new "Morning Brief Signal Categories" registry (Section 3.3 and Section 11.4). The fixed set fitted one kind of organisation's working day and said nothing of a signal's subject, and kind and category carried the same values. Urgent items stay in the escalations array.
- Added standing delivery (Section 12) beside requested delivery, and the delivery key to the ABNF key-name list.
- Allowed a handle to address a brief to itself (Section 13), with an empty accord array in that case, and stated that a brief to an agent is not a brief to its principal.
- Named the referenced documents in words in the abstract.
- Rendered the schema of Section 3.1 and the grammar of Section 3.2 as figures. In -01 the fence characters were visible and the figures ran as text.
- Added an informative reference to [MORRISON-IFT], cited in Section 1.2 for scoping consent by (category, provenance_class).
- Stated in Section 2.2 that a handle named in prose is an alter: URI [ALTER-URI], added as an informative reference. The wire fields still carry the bare handle.
- Stated the scope of [EU-AI-ACT] Article 5(1)(f) in Section 4.3 and Section 10.1, including its exception for medical or safety reasons.
- Stated in Section 4.2 that an aggregate over a cohort below the threshold is treated as a passive-individual observation.
- References: updated the title of [ACCORD]; corrected the [IDCOMMITS] section numbers in Section 5.2 and Section 10.8; pointed the Acknowledgments at [COMPUTE-GATE]; removed the reference to a conformance specification that is not published.
- Section 1.1 now states [EU-AI-ACT] Article 5(1)(f) as it reads, inferring emotions, with its exception for medical or safety reasons. It previously read "emotional or behavioural state".
- Moved [MCPDNS] to the normative references, because readers resolve keys and the revocation endpoint through it.
- Cited [X402] for the x402 commerce-quote key, added as an informative reference.
- The _alter-brief-revocation label is requested in the existing "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]. -01 named a registry "pending establishment".
- Tone: Section 4.3, Section 7.1, Section 10.1, Section 10.4 and Section 14 no longer describe the document's own intent or standing, and Section 14 no longer calls this document a sibling of drafts it depends on normatively. List items in Sections 8, 9, 11.3 and 12 use colons in place of dashes.
Author's Address
Blake Morrison Alter Meridian Pty Ltd Email: blake@truealter.com