]> Alter Meridian Pty Ltd

blake@truealter.com

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.

Introduction

Problem Statement Organisations and their agents routinely exchange bounded-horizon situational-awareness payloads: what happened since the last exchange, what is on fire, what decisions were taken, what is open. The daily "standup" is the human idiom for this exchange; agent-to-agent protocols in deployment today reproduce the same shape without a shared wire format. Each implementer ships its own JSON blob, its own authentication story, its own retention assumptions, and its own implicit answer to the question of how the signals inside the payload were obtained. The absence of a shared wire format produces three operational defects:

• No portable attestation. A brief from one organisation to another cannot be cryptographically bound to a specific issuer handle without bespoke integration. The receiver either trusts the transport (TLS to a known endpoint) or implements a custom signing scheme per counter-party.
• No provenance discipline. Signals in an ad-hoc brief are flat strings. The receiver cannot distinguish a statement the subject actively made from an inference drawn from passive telemetry. This distinction is legally significant in jurisdictions where inferring a person's emotions from workplace telemetry is prohibited outside medical or safety reasons ( 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.

Design Goals

1. Federated. No central clearinghouse. Issuer and reader each resolve the other's handle via .
2. Identity-attested at the sovereign layer. Envelope signature is COSE_Sign1 over a JCS-canonicalised payload, bound to the issuer's Sovereign-tier handle per .
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 , 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 . 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.

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, defined in and incorporated by reference via .
• The inter-organisational handshake that establishes the Accord relationship between issuer and reader. This is defined in .

Terminology

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

Definitions Where this document names a handle in prose, the identifier is an alter: URI as defined in , 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 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 . 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 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.

Payload Structure

Abstract Schema A Morning Brief is a map with the following top-level fields. In the canonical CBOR serialisation, fields are encoded with integer keys; the JSON debug serialisation uses the string labels below. =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 . The x402 key carries an optional commerce quote for a reader to settle with the x402 payment protocol .

ABNF Grammar for Canonical Serialisation The CBOR serialisation is canonical for transmission. The JSON serialisation is permitted for debugging, human-readable logs, and test vectors. Both serialisations MUST preserve the same field set and the same type discipline. The following ABNF defines the lexical grammar of the JSON debug serialisation. The CBOR canonical form is governed by the schema above. 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.

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.

Provenance Classes (Normative)

Active An active signal is one whose body was produced by the subject for the explicit purpose of being shared through this channel. Examples include recorded decisions, explicit status updates, and entries their subject has signed under the key custody rules of . Active signals are the default expected class for brief contents.

Passive-Aggregate A passive-aggregate signal is a statistical summary computed over a population of at least 1000 subjects, such that no individual subject is identifiable from the aggregate. Implementations MUST enforce the k >= 1000 threshold at aggregation time and MUST NOT emit an aggregate with a smaller cohort. 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.

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

Envelope and Signing

Canonicalisation The payload is canonicalised using JCS 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 Section 4.2.

Envelope Signature The signed envelope is a COSE_Sign1 structure with the following parameters:

• alg: EdDSA (Ed25519), registered in Section 2.2, using the key bound to the issuer's handle per Section 5.5.
• kid: the issuer's Identity-Key-Id value per Section 4.1.
• Payload: the JCS-canonicalised brief payload.

The signing key is the issuer's Sovereign-tier signing key, the same key bound to the issuer's ~handle by the DNS-published record per and . Brief signing and commit signing are governed by the same key-custody discipline; key compromise affects both surfaces identically.

Verification A reader verifies a brief by:

1. Resolving the issuer's public key via 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.

Consent Gate (Normative)

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

Capability Token The reader presents a capability token to the issuer's brief endpoint prior to payload emission. The token scope is a set of (category, provenance_class) pairs that the issuer is authorised to release to this reader in this request. The issuer consumes the scope at composition time; fields outside the authorised scope MUST NOT appear in the resulting payload. The consent_gate field in the emitted brief echoes the scope actually honoured. 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 and are out of scope for this document.

Lifetime and Revocation

not_after Default Every brief MUST carry a not_after field. The default value is 24 hours after iat. The 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.

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

Reader Behaviour (Normative) A conformant reader MUST perform the following steps in order for each received brief:

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

Media Types This document defines two media types:

• application/morning-brief+cbor: the canonical CBOR serialisation. This is the on-wire format.
• application/morning-brief+json: the JSON debug serialisation. Intended for test vectors, logs, and development tooling.

Deployments SHOULD default to the CBOR form for production exchanges. The JSON form is for human-readable contexts where wire efficiency is not a concern.

Security Considerations

Emotion-Adjacent Inference and EU AI Act Article 5(1)(f) 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.

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

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

Essential-Facility and Antitrust Posture A specification 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 ; the canonicalisation is JCS ; the key discovery is DNS-based per . 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.

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

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

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

DNS Dependencies Brief verification depends on DNS resolution for issuer key discovery and for revocation-endpoint lookup. Mitigations for DNS poisoning are as described in Section 9.4: DNSSEC validation as Section 6.1 requires, and independent transparency-log anchoring where a log is deployed.

IANA Considerations

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

application/morning-brief+cbor

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

application/morning-brief+json

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

DNS Underscore Label This document requests IANA to add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry established by :

• RR Type: TXT
• _NODE NAME: _alter-brief-revocation
• Reference: Section 7.2 of this document

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 .

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.

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

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.

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.

Relationship to Existing Drafts This section lists the related drafts and how this document depends on each.

Draft	Layer	Relationship to this document
	L1: transport discovery	Normative. This document uses DNS TXT discovery for key and revocation.
	L1: handle grammar	Informative via .
	L2: atomic attestation	Normative. This document inherits key custody and signature rules.
	L2: inter-org handshake	Normative. Briefs are exchanged under an existing Accord.
draft-morrison-morning-brief (this)	L3: periodic payload exchange	N/A.

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 ; the rationale is restated in this document at the level required for protocol implementation. Additional contributors will be named at review time.

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. Alter Meridian Pty Ltd Alter Meridian Pty Ltd Alter Meridian Pty Ltd Informative References Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. x402 Foundation (Linux Foundation) European Parliament and Council of the European Union Alter Meridian Pty Ltd Alter Meridian Pty Ltd Alter Meridian Pty Ltd Alter Meridian Pty Ltd

Changes from draft-morrison-morning-brief-02

• Editorial pass: the references to other drafts move to the revisions submitted alongside this one. is added as a reference in place of a bare draft name in Section 14. and 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 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 as normative, as the references have since -02.

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 , 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 , added as an informative reference. The wire fields still carry the bare handle.
• Stated the scope of 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 ; corrected the section numbers in Section 5.2 and Section 10.8; pointed the Acknowledgments at ; removed the reference to a conformance specification that is not published.
• Section 1.1 now states 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 to the normative references, because readers resolve keys and the revocation endpoint through it.
• Cited 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 . -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.