Prior art for the Resolution Protocol

A survey made 2026-10-12 by fetching the primary sources. Quotes are verbatim. UNVERIFIED marks items whose primary text could not be opened.

Headline: none of SIPREC, Zoom, Microsoft Teams or Google Meet lets an individual keep their own words out of a transcript. The available models are:

Per-voice control is the gap this protocol fills.

1. Telephony and conferencing: IETF SIPREC

RFC 6341 (requirements), RFC 7245 (architecture), RFC 7865 (metadata), RFC 7866 (protocol).

What SIPREC says:

Adopted:

Rejected: advisory preferences. In RP a voice's lowering is binding.

2. Meeting platforms

Adopted: silent until consented (Teams) as a profile option. Rejected: auto-consent for any class of participant (Meet).

3. Consent and policy vocabularies

4. Retention and deletion

5. Provenance

6. Indicators and law

7. Spec design

# Prior art for the Resolution Protocol

A survey made 2026-10-12 by fetching the primary sources. Quotes are verbatim. **UNVERIFIED** marks items whose primary text could not be opened.

**Headline:** none of SIPREC, Zoom, Microsoft Teams or Google Meet lets an individual keep *their own words* out of a transcript. The available models are:
- consent or leave (Zoom);
- consent or stay muted (Teams);
- consent or get removed, or stop the recording for everyone (Meet);
- hide my name but keep my words (Teams captions).

Per-voice control is the gap this protocol fills.

## 1. Telephony and conferencing: IETF SIPREC

RFC 6341 (requirements), RFC 7245 (architecture), RFC 7865 (metadata), RFC 7866 (protocol).

**What SIPREC says:**
- **Opt-out on request:** a UA may "request at session establishment time that the CS should not be recorded" (6341 REQ-016). Requests to start, pause, resume or stop recording "MUST be notified about the outcome" (REQ-017).
- **Indication:** "the SRC MUST provide recording indications to all participants" (7866 §6.1.2). The values are `a=record:on|off|paused` (§7.1.2), and a media-level value overrides the session-level one.
- **Preference:** `a=recordpref:on|off|pause|nopreference`. "The absence of the a=recordpref attribute … indicates that the UA has no recording preference" (§7.3.2).
- **Preferences are advisory:** "The SRC is not required to honor the recording preference" (§7.3.2), and "the UA's only mechanism to avoid being recorded is to terminate its participation" (§5.3).
- **Participant timing:** each participant has associate and disassociate times, in RFC 3339 format (7865 §6.6.1, §6.8.1).
- **Awareness:** "only for the case where the users are aware that they are being recorded" (7245 §5).

**Adopted:**
- requested level kept separate from applied level;
- "absence = no preference";
- the outcome is reported back after every change;
- a narrower scope overrides a wider one;
- per-voice association times.

**Rejected:** advisory preferences. In RP a voice's lowering is binding.

## 2. Meeting platforms

- **Microsoft Teams:**
  - `-ExplicitRecordingConsent Enabled` (learn.microsoft.com/MicrosoftTeams/meeting-recording).
  - In audio conferencing, "all participants are muted once the meeting recording or transcription starts. Once a participant decides to un-mute, they're prompted to provide consent" (conferencing-recording-consent).
  - "You can choose to hide your name in live captions … and the saved transcription": the name is hidden, the words are kept.
- **Google Meet:**
  - Admins can require consent for "transcription, recording, and AI note-taking".
  - "Allow users to quickly stop the artifacts on decline" (knowledge.workspace.google.com/admin/meet/manage-participant-consent).
  - "Participants joining through Meet hardware devices" and dial-in participants "are automatically consented".
- **Zoom:** a recording disclaimer with Continue / Leave Meeting. **UNVERIFIED** (client-rendered docs; secondary sources only).

**Adopted:** silent until consented (Teams) as a profile option.
**Rejected:** auto-consent for any class of participant (Meet).

## 3. Consent and policy vocabularies

- **ISO/IEC TS 27560:2023** (consent record structure; **UNVERIFIED**, paywalled). From the W3C DPV guide: a consent record is "the documentation of information about a data subject's consent"; the structure is Header, Processing, Parties, Events.
- **Kantara Consent Receipt v1.1** (draft 8 read): "Consent is not possible without an identifier".
  - **Rejected:** RP uses a local pseudonymous voice handle, not an identified data subject.
- **W3C ODRL 2.2:**
  - Permission, Prohibition, Duty and Constraint (leftOperand `elapsedTime`).
  - Conflict strategy `prohibit`: "the Prohibitions MUST override the Permissions".
  - **Adopted:** RP's "lowest wins" is ODRL `prohibit`. Decay steps are Duties ("derive the lower level, then delete the higher one when elapsedTime ≥ P").
- **W3C DPV 2.x:**
  - Processing terms: StorageDuration, StorageDeletion, Record, Derive, Pseudonymise, Erase ("to remove data from existence i.e. without the possibility of retrieval").
  - Consent statuses: ConsentGiven, ConsentRefused, ConsentWithdrawn, ConsentExpired, ConsentRevoked, ConsentUnknown.
  - **Adopted:** these terms for the RP event log.
- **IEEE 7012-2025 (MyTerms):**
  - The individual is "the first party", proffering "their own terms … read … by machines".
  - "The recorder shall record rejected agreements". Terms should be "able to be read aloud by text-to-speech".
  - It is the closest philosophical precedent: a small named ladder of terms proffered by the individual.
- **Global Privacy Control:** a single, unextendable signal ("deliberately defined without an extension mechanism").
  - **Adopted:** the core levels are closed, with no extension mechanism.

## 4. Retention and deletion

- **NIST SP 800-88r2 (Sept 2025), cryptographic erase:**
  - "key sanitization … making recovery of the decrypted target data infeasible".
  - Pre-condition: "no sensitive data has previously been stored on the ISM in plaintext form". CE should not be trusted where keys have been "backed up or escrowed".
  - **Adopted** as the RECOMMENDED enforcement, with the pre-conditions as MUSTs.
- **Microsoft Purview:** "Retention wins over deletion", "The longest retention period wins".
  - **Inverted on purpose:** in RP the lowest level and the shortest retention win.
- **Google auto-delete** (18 months by default, from 2020): precedent for decay as a default, but delete-only with no downgrade.
- **Data degradation research** — Anciaux, van Heerde, Bouganim, Pucheral, Apers: *Data degradation: making private data less sensitive over time*, CIKM 2008 (DOI 10.1145/1458082.1458301); *InstantDB*, ICDE 2008.
  - Accurate data degrades step by step to coarser states, then is removed.
  - This is the academic ancestor of verbatim → gist → outcomes. Abstract wording **UNVERIFIED**.

## 5. Provenance

- **C2PA 2.2:**
  - External manifests are "an acceptable model".
  - Redaction leaves "a record that something was removed" (`c2pa.redacted`, reason `c2pa.PII.present`).
  - There is no transcription or summary action.
  - **Optional binding:** a sidecar manifest with an assertion `org.resolutionprotocol.levels`.
- **W3C Verifiable Credentials 2.0:** a device's conformance claim can be a VC. Not for per-utterance consent.

## 6. Indicators and law

- **W3C Media Capture:** "Any false-to-true transition indicated MUST remain observable for … at least 3 seconds". UAs are "encouraged … to make any generic hardware device indicator light match".
  - **Adopted** for RP indicators.
- **OS mic indicators** (iOS orange dot, Android 12) serve only the device owner. There is **no standard for bystander-facing indicators**; RP §10 fills it.
- **EU AI Act Art. 50:**
  - 50(1): people are "informed that they are interacting with an AI system".
  - 50(2): synthetic text is "marked in a machine-readable format", except where the system does "not substantially alter the input data".
  - **Implications:** verbatim transcription is arguably exempt; gist and outcomes plausibly are not, so the provenance manifest helps.

## 7. Spec design

- W3C QA SpecGL: a conformance clause, who implements it, conformance labels, test assertions.
- RFC 8174: requirement keywords count only in capitals.
- RFC 7942: an implementation-status section.
- W3C SRGS 1.0: per-language grammars with semantic tags; an SRGS binding of RP grammars is possible.
- Unicode CLDR (UTS #35): locale fallback "en_US_someVariant, en_US, en, root".
  - **Adopted:** BCP 47 locales with truncation fallback.