WAI Extension: Remote Desktop

Mirrored from the canonical text at commit 260cbd09 (2026-11-08).

Status: Draft. Registers the record wai.live.remote: one principal’s screen shared into a room and controlled from it. The host publishes its screen as the room’s screen track, each frame an object with its WAI receipts, and signs a screen statement, WDS1: what it captures, the frame size that is the coordinate space of every input, the actions it injects, and the encoder that made the frames, named as packaging §7 (its paragraph 7.5) requires of an encoder that is not a pure function of its input, and read by no step that accepts or refuses anything. A principal whose grant carries the control power, a grant attribute, sends input statements, WDI1: pointer, key, text, touch and clipboard actions in the frame’s coordinates. The host injects an input only when every rule of §5.3 holds at the input’s instant, and signs an outcome, WDO1, for every input it receives: applied, naming the first frame it captured after it injected the actions, or refused, with the rule that refused it. Control passes by the room’s grants alone, or, in a room that keeps a floor, by floor statements, WDF1, that request, give, release and take it back. A viewer that presents the frame an outcome names signs a latency record, WDL1: the instant of its action and the instant its platform reports the frame presented, both on its own estimate of the room clock, with the round trip that estimate rests on. Everything rides in the room’s events, as meta payloads their authors sign; a verifier recomputes every outcome from the rules and refuses a host that applied what the rules refuse. A host that states a sealing key takes key, text and clipboard actions sealed to it (§5.5): their fields travel in one HPKE ciphertext a statement, which the host alone opens, beside a commitment to each action, while pointer, wheel and touch actions stay in the clear, as the screen shows them anyway. A viewer verifies every outcome without the plaintext; a verifier given the host’s opening key also opens every seal and checks every commitment (§11.4). No new transport. The reference implementation is the remote_desktop module of wai-rs (feature remote_desktop); the reference host agent and its browser viewer are joule-moq-remote and the room page of joule-moq-web; the corpus is live-conformance/remote/, and its second implementation is live-conformance/remote_desktop_verify.py. Keywords MUST, MUST NOT, SHOULD, MAY are RFC 2119/8174.

Texts read for this revision: the live family this extension builds on, as merged (live-events, live-rooms, moq-streaming-format, live-metering, live-recording, confidentiality and co-watch), packaging §7 (its paragraph 7.5) and jwp-receipts; RFC 8032, FIPS 180-4 and RFC 6381; RFC 9180 (§4, §5.1, §6.1, §7.1) and RFC 7748 §5, for sealed actions; HID Usage Tables 1.5 §10, the Keyboard/Keypad page (0x07); and the W3C UI Events specifications for pointer buttons, wheel deltas in pixels and keyboard code values (uievents, uievents-code). No other outside text is pinned: the rules of this extension are WAI’s own.

1. Scope

In scope: the grant attributes this extension reads (§3.1); the host’s screen track and its screen statement, what the host captures and the encoder it names (§3); how the statements ride in a room’s events, how they are read, and who signs each (§4); input statements, their actions, the host’s rules and how it applies an input (§5), and key, text and clipboard actions sealed to the host (§5.5); outcomes (§6); handover of control, by grant change and by the floor (§7); measured input-to-photon latency (§8); session records and metering (§9); where each rule is enforced (§10); and verification at two levels (§11).

Out of scope: a transport; how a host captures its screen or injects an action, which is its platform’s; how a codec encodes a frame (§3.6); how a sink decodes and draws one; the host’s clipboard and files sent to viewers, which this revision does not define; audio from the host, which is a room audio track like any other (live-rooms §6.1); and a recording of the session, which the room’s recording policy governs (live-rooms §3.7, live-recording).

Relationship to the core spec: wai.live.remote is a record (SPEC §5): signed records a WAI tool emits and verifies. It names no payload format and is not dispatchable. The frames are payloads of capabilities SPEC §5 already registers (wai.video.avc, wai.video.hevc, wai.video.av1, wai.video.vp9), one access unit an object.

Relationship to live-events: this extension changes nothing in it. Its statements are payloads of the meta kind (§4.2 there), which live-events leaves to applications, as co-watch’s are, so every statement is signed by its author, chained, stamped with the room clock and rate-bounded by its author’s policy (live-events §5, §6). An outcome that names a frame anchors it (live-events §3.1).

Relationship to live-rooms: the descriptor’s and the grant’s layouts are unchanged. The screen is the room’s screen media kind (live-rooms §6.1, publish bit 2), and its tracks are named as live-rooms §6.1 names every track. The host mark and the control power are grant attributes (§3.1), which live-rooms §4.4 signs with the grant and leaves to the extensions that read them: a new power bit would be refused by every room verifier of the current revision (live-rooms §3.4: no power above bit 4). The direct power (live-rooms §3.3, bit 1) is the power to give and take back the floor (§7.2).

Relationship to packaging §7 (its paragraph 7.5): a frame is made by an encoder that is not a pure function of its input, so the host names that encoder and its version. The name is a statement about where the bytes came from; the bytes are bound by their digests in their receipts, and nothing recomputes them (§3.6).

2. Terms

• Room, room clock, principal, event, chain, grant, grant in effect, room key, merged order, present: as in live-events §2 and live-rooms §2, §9.2 and §9.3. A room key is the room authority’s key or the clock’s.
• Statement: the payload of a meta event whose first four bytes are one of the magics of §4.1. It is named by the digest of its event (live-events §3.2).
• Host: a principal whose grant in effect carries remote_host with the value true (§3.1). Its screen is what it captures and publishes (§3.5).
• Controller: a principal whose grant in effect carries the control power (§3.1).
• Frame: one object of the host’s screen track: one access unit of the capability its screen statement names, in a WAI1 envelope (moq-streaming-format §3), with its receipts (§3.2).
• Action: one pointer, key, text, touch or clipboard input (§5.2). Its class is the bit of the control power that allows it.
• Sealing key: an X25519 public key (RFC 7748 §5) a host states in its screen statement (§3.3). Its opening key is the matching private key, which the host holds.
• Sealed action: a key, text or clipboard action whose fields are sealed to the host’s sealing key (§5.2, §5.5). Its opening is a salt and its fields; its commitment is the digest that binds them (§5.5). A statement’s seal holds the openings of its sealed actions.
• Estimate: a principal’s estimate of the room clock, on which it stamps its events’ t.
• A short field is a u8 length and that many bytes; a token is 1 or more bytes of ! to ~ (0x21–0x7E), as in live-rooms §2.

Integers are little-endian; a signed integer is two’s complement. A digest is SHA-256 (FIPS 180-4), 32 bytes. Ed25519 is RFC 8032’s, verified strictly (SPEC §7 Signatures): a key that fails step 1 or 2 is bad_key, and a signature that fails a later step is bad_signature. µs is microseconds of room clock.

3. The host and its screen

3.1 The attributes

This extension reads two grant attributes (live-rooms §4.4):

A decimal integer here is 1 or 2 of the digits 0–9, the first not 0. A grant whose remote_host is neither true nor false, or whose remote_control is not of that form or is above 15, is refused rd_attr_malformed. A grant without remote_host does not host, and one without remote_control carries no control power. A host’s grant MUST also let it publish the screen media kind (live-rooms §3.3, publish bit 2); one that does not cannot sign a screen statement (§4.3).

The authority states who hosts and who controls in the grants it signs, and changes either by exchanging a grant (live-rooms §4.6, §7.1 here). The value of remote_control is the classes: 1 pointer alone, 3 pointer and keys, 15 everything.

3.2 The screen track

The host publishes its screen as its own track of the screen kind (live-rooms §6.1): the Track Namespace of the room id, its key and screen, the Track Name its layer, 0 for a single layer. The track’s catalog entry declares the capability its frames carry (moq-streaming-format §4, wai_capabilities), its codecs value (codec, RFC 6381), its size, wai_receipts true and its receipts track (moq-streaming-format §4.1), and a sink verifies each frame against its receipt before it decodes it, as it verifies every object of a room. Each frame is one group of one object, so a group receipt covers one frame; a frame that is an intra-coded picture (an IDR access unit, or an AV1 or VP9 key frame) carries key true in its manifest’s target.

The track digest of the screen is the anchor track of its layer 0 (live-events §3.1): SHA-256 over the namespace’s rendering <room>-<host>-screen (the room id and the host’s key as 64 lowercase hexadecimal digits each), one zero byte, and 0.

A host SHOULD send an intra-coded frame at least every two seconds, and at once when a principal joins, so that a viewer that joins decodes within that time.

3.3 The screen statement

A screen statement is a meta payload of at most 5 + 32 + 1 + 32 + 2 × 3 + 1 + 8 + 1 + 16 × 8

• 1 + 1 + 2 + 4 + 1 + 3 × 256 + 2 + 32 bytes, within the default max_payload of live-events §5.

3.4 Rules and the chain

A screen statement whose fields break §3.3’s table is rd_statement_malformed. Then:

1. its track is the track digest of its author’s screen (§3.2): otherwise screen_wrong_track;
2. its prev is the digest of the event of its author’s screen statement before it in the merged order, or 32 zero bytes when it has none: otherwise screen_unlinked.

The host’s screen in effect at a point of the merged order is its last screen statement the room accepted before that point. A statement is replaced, never amended: a new size, a new scope, a pause, a resume or a new encoder is a new statement, which takes effect at its place in the merged order.

3.5 What is captured

What a host captures is the host’s choice, and the screen statement states it: whether the frames hold a whole display, one window or a region of a display (scope, region); the rectangles it blanks before it encodes (redactions); whether its pointer is drawn (pointer); which actions it injects (accepts) and how much clipboard text it takes (clip_max); whether it takes key, text and clipboard actions sealed (seal, §5.5); and whether it captures at all (state). A host MUST capture nothing outside what its screen in effect states, MUST blank every redaction in every frame before the frame reaches its encoder, and MUST NOT publish a frame while its screen in effect is paused. A sink SHOULD show its viewer the scope, the redactions and the state.

A host that stops sharing for a moment pauses (a statement with state 2) rather than leaving; one that resumes signs a live statement, and its next frame is intra-coded.

3.6 The encoder

encoder names the encoder that made the frames, and its version, as packaging §7 (paragraph 7.5) has a floor name an encoder that is not a pure function of its input: the encoder’s name, @, and its version as the encoder reports it. api names the interface the host drove it through, by role:

hardware states where it ran, as the interface reports it: 0 general-purpose processors, 1 a fixed-function media engine, 2 not stated. A host that cannot tell states 2, never 1.

The three fields describe how the frames were made, and nothing else. No step of this extension reads them to accept or refuse a frame, an input, an outcome or a latency record; no digest a verifier recomputes covers them, beyond the statement’s own event; and no verifier re-encodes a frame. Each frame is bound by the content hash its receipt states (jwp-receipts), and a viewer that holds a frame and its receipt holds the bytes the host published, whatever made them. A host that changes its encoder signs a new screen statement.

4. Statements

4.1 Carriage

Each statement is the payload of a meta event: its magic, a version byte of 1, and the fields its section lists. A meta payload whose first four bytes are none of these magics is not this extension’s, and a sink that does not implement it shows none of them: they are timed metadata for its application (live-events §4.2). Every statement is bounded by its author’s policy (live-events §5, max_payload): an authority that gives a principal the clipboard class gives its grant a max_payload that holds the clipboard text it allows.

4.2 Reading

A statement that ends before a field, that holds bytes after its last field, whose version is not 1, or whose field holds a value its section does not allow, is rd_statement_malformed.

4.3 Who signs

A screen statement whose author’s grant in effect at its t does not carry remote_host with the value true or does not let it publish the screen kind, an outcome whose author is not the host of the input it names, and an input statement or a latency record by a room key, are rd_not_permitted. A floor statement’s author is checked by §7.2. A grant’s powers and attributes are those of the author’s grant in effect at its event’s t (live-rooms §9.2 step 4). Since a statement is a meta event, the room verifier has already held it to its author’s grant: a principal whose policy does not permit meta cannot send one (live-rooms §9.2 step 4, kind_not_permitted).

5. Input

5.1 The input statement

dt_us is how long before its event’s t the action happened, so the action’s instant is t − dt_us; it is at most t. The actions are in the order they happened: each one’s dt_us is at most the one’s before it. A statement that breaks this, or whose count is outside 1 to 32, is rd_statement_malformed. So is one with a sealed action whose ciphertext is not exactly 16 bytes longer than the openings of its sealed actions (§5.5), and one with no sealed action that holds any byte after its last action. A controller batches the actions of a short interval (a pointer moving over one display refresh, a key and its release) into one statement, so that the rate its grant’s policy bounds is a rate of statements, not of actions.

5.2 Actions

Coordinates are in the frame of the screen statement the input names, from (0, 0) at its top left, x below width and y below height; the host maps them to what it captures (its scope, its region and any scaling). UTF-8 is RFC 3629’s: no overlong form, no surrogate, nothing above U+10FFFF. A field outside its row is rd_statement_malformed; a coordinate outside the frame and clipboard text longer than clip_max are not malformed but out of bounds (§5.3 step 6), since they depend on the screen. A controller in a page maps a keyboard event’s code (uievents-code) to its HID usage. A sealed action is of the type it seals wherever a rule reads an action’s type (accepts, §3.3 and §5.3 step 5), and of that type’s class; accepts has no bit for type 8.

5.3 The host’s rules

A host decides on an input statement when it receives it. With t the statement’s event’s t, P its author and n the instant the host decides (the t of the outcome it signs, §6), the host refuses it at the first of these that holds, with the reason and its number:

1. its host is not the host’s key, or its screen is not the digest of the host’s screen in effect at the input’s place in the merged order: input_wrong_screen (1);
2. P’s grant in effect at t does not carry the control power with the class of every action: input_not_permitted (2);
3. the host’s screen in effect keeps a floor (floor 2) and P does not hold it at the input’s place in the merged order (§7.3): input_no_floor (3);
4. the screen in effect is paused: input_screen_paused (4);
5. an action’s type is not among the screen’s accepts: input_unsupported (5);
6. an action’s coordinate is outside the frame, or a clipboard action’s text (a sealed clipboard action’s length) is longer than the screen’s clip_max bytes: input_out_of_bounds (6);
7. n less the instant of its first action is more than the screen’s max_age_ms × 1000: input_stale (7);
8. the screen in effect states a sealing key, and an action is a key, text or clipboard action in the clear (type 4, 5 or 7): input_unsealed (8);
9. it carries a seal, and the screen in effect states no sealing key, or the seal does not open under the host’s opening key, does not read, or does not keep its commitments (§5.5): input_bad_seal (9).

Otherwise it applies the input (§5.4). It applies all of a statement’s actions or none of them. A host MUST NOT apply an input these rules refuse, and MUST sign one outcome for every input statement addressed to it that it receives (§6).

The rules are made at the input’s place in the merged order: the grant in effect, the screen in effect and the floor are those every party holding the room computes there, so a verifier recomputes the host’s decision (§11.2). Rule 9 reads what a seal holds, which the opening key alone opens: a verification at the commitment level makes it only where the screen states no sealing key, and one at the opened level makes it in full (§11.4). A host decides as soon as it holds the input and every record before it that the rules read: its own screen statements, the clock’s lifecycle, and the floor statements. An input that crosses a grant change, a new screen or a floor change on the wire is decided by its place, and refused if the rules then refuse it; its author sends it again under what is in effect.

5.4 Applying

A host applies an input by injecting its actions into what it captures, in order, each sealed action as the action it seals (§5.5), each at its coordinates mapped from the frame. Text and clipboard text are taken as given; the host injects no key or button state the actions do not state, and SHOULD release, when a controller loses control (§7), every key and button that controller left down.

5.5 Sealed actions

Keys typed and text composed or pasted can be passwords. A host that states a sealing key in its screen statement (seal, §3.3) takes key, text and clipboard actions sealed to it, so that no party but the host reads them: not a relay, not the room service, not a viewer. Pointer, wheel and touch actions stay in the clear: the host’s screen shows where the pointer goes and what it does, and the screen is the room’s. A sealed action keeps in the clear what rules 1 to 8 of §5.3 read: the type it seals, which gives its class (rule 2) and is held to accepts (rule 5); its dt_us (rule 7, and the latency records of §8); and a clipboard text’s length (rule 6). A text’s length is not in the clear: its opening pads it to 64 bytes.

The opening of a sealed action is 16 bytes of salt, then the fields of the type it seals: for a key, its usage (u16), down and modifiers (u8 each), as §5.2 lays them out; for a text, its length (u8, 1 to 64), then 64 bytes, the text and zero bytes after it; for a clipboard text, its length bytes of UTF-8, with no length before them. A sender draws each salt afresh from a cryptographically secure random source.

The commitment of a sealed action at index k among its statement’s actions, from 0, is SHA-256 over the 18 bytes wai:remote-commit (ASCII) and 0x01, the room id, the author’s key, the statement’s host and screen, k (u8), the action’s dt_us (u32), of (u8) and its opening. It binds the input (its fields, and the room, the host and the screen statement it is sent to), its order (its index among the statement’s actions and its instant) and its author. The salt keeps it from being guessed: a key’s fields take a few thousand values, and a commitment over them alone would name the key to anyone who tried each.

The seal is HPKE’s single-shot SealBase (RFC 9180 §6.1), base mode, with DHKEM(X25519, HKDF-SHA256), HKDF-SHA256 and AES-128-GCM (RFC 9180 §7.1: KEM 0x0020, KDF 0x0001, AEAD 0x0001), and:

• pkR: the sealing key of the screen statement the input names (screen);
• info: the 16 bytes wai:remote-seal (ASCII) and 0x01, the room id and the host’s key;
• aad: the author’s key, then the statement from magic through its last action;
• pt: the openings of its sealed actions, in their order among its actions.

The statement holds the seal after its last action: enc, 32 bytes, then the ciphertext, which is 16 bytes longer than pt. A sender draws a new ephemeral key for every statement (RFC 9180 §4.1: GenerateKeyPair, or DeriveKeyPair of fresh random bytes).

Opening. The host opens a seal with OpenBase under its opening key, the same info and aad, and reads each sealed action’s opening from what it opens to, in order, each as long as its of and length make it. Rule 9 of §5.3 holds, for the first of these reasons, which a verification at the opened level states (§11.4; §12’s fourth table):

1. the screen statement the input names states no sealing key: seal_no_key;
2. OpenBase fails: the seal was made to another key, by another author or in another room, or was altered: seal_not_opened;
3. what it opens to does not read as the openings: a key’s fields outside §5.2’s row, a text’s length outside 1 to 64, a padding byte that is not zero, text that is not UTF-8, or bytes left over: seal_unreadable;
4. a sealed action’s commitment is not the commitment of its opening: seal_commitment.

The aad binds the seal to its statement and its author: a principal that copies another’s sealed input into a statement of its own sends a seal that does not open.

A controller MUST seal every key, text and clipboard action it sends to a host whose screen in effect states a sealing key, to that key, and MUST NOT send one in the clear: the host refuses it (rule 8). A host MUST open a sealed input before it injects it, and inject only what rule 9 accepts. A host SHOULD make a sealing key for each session and discard its opening key when the session ends, so that a later compromise of its own keys opens none of the session’s inputs; it MAY give the opening key to a verifier it wants to check the session at the opened level (§11.4).

6. Outcomes

6.1 Layout

An applied outcome’s event carries an anchor (live-events §3.1): the screen track, the group and the object of the first frame the host captured after it injected the last action, which is the first frame that can show what the actions did. A host signs it once that frame is published. A refused outcome’s event carries no anchor, and the host signs it at once.

6.2 Rules

An outcome is checked, in this order:

1. its input is the digest of an input statement the room accepted: otherwise outcome_unknown_input;
2. its author is that input’s host (§4.3): otherwise rd_not_permitted;
3. no outcome before it in the merged order names the same input: otherwise outcome_duplicate;
4. its fields agree with its outcome and with one another: an applied outcome has reason 0, an anchor whose track is the track digest of the host’s screen and whose object is 0, and a content not all zero, and the input’s t ≤ applied_at ≤ captured_at ≤ its own t; a refused one has a reason from 1 to 9, no anchor, applied_at, captured_at and content zero, and a t at or after the input’s. Otherwise outcome_invalid;
5. the rules of §5.3, made at the input’s place with n the outcome’s t, give what it states: applied when none refuses, and refused with the reason of the first that does. At the commitment level (§11.4), rule 9 is made only for an input whose screen states no sealing key: a sealed input to a screen that states one, which rules 1 to 8 accept, takes an outcome that states applied or refused with reason 9. Otherwise outcome_mismatch.

An input statement with no outcome is unanswered. A verifier states it; it is not a refusal, since a host may never have received it.

7. Handover of control

7.1 Two ways

Control passes in one of two ways, as the host’s screen in effect states.

• By grant (floor 1, open). Every controller may send input, and the classes it may send are its grant’s. Control is handed over by exchanging grants (live-rooms §4.6): the authority exchanges the grant of the principal giving up control for one without remote_control, and that of the principal taking it for one with it, each effective at a tick of the room clock. From that tick the rules of §5.3 refuse the first and accept the second.
• By the floor (floor 2). Controllers may send input only while they hold the floor, which floor statements pass (§7.2). The grant still bounds what the holder may send: the floor selects one controller, and its grant’s classes are what it may do.

7.2 The floor statement

A floor statement whose action is outside 1 to 4, or whose to is not zero exactly when its action is give, is rd_statement_malformed. Its author, with t its event’s t:

• request: a controller at t; it changes nothing, and tells the host and the holder that the author asks for the floor;
• give: the host, a room key, a principal whose grant in effect holds the direct power, or the floor’s holder; to is a present controller at t, and not the host: otherwise floor_not_eligible;
• release: the floor’s holder;
• take: the host, a room key or a principal whose grant in effect holds the direct power.

An author who may not send its action is floor_not_permitted, but a release by a principal that does not hold the floor is floor_not_holder. A floor statement whose host is not a principal that has signed a screen statement before it in the merged order is floor_not_permitted.

A floor statement these rules refuse at its place is not a refusal of the room. It is recorded: it stays in its author’s chain, held to the room’s rules as every event is (live-rooms §9.2), and it changes nothing: the floor in effect after it is the floor in effect before it. A verifier states it with its reason (§11.3) and computes the floor without it, and a host gives it no effect. So two floor statements that cross on the wire, such as a holder’s release that takes its place after the host has taken the floor back, leave the floor where the statements these rules accept put it, and the room verifies.

7.3 The floor in effect

A host’s floor starts held by no one. In the merged order, a give that §7.2 accepts passes it to to, and a release or a take that §7.2 accepts leaves it held by no one; a floor statement §7.2 refuses changes nothing. The holder also loses it, and it is held by no one, at the leave of the holder, at a grant_exchange that makes the holder’s grant in effect one without the control power, and at the leave of the host. The floor in effect at a point of the merged order is the floor after every statement and lifecycle event before that point.

A floor is kept whatever the host’s screen in effect states: a host that moves from open to floor and back keeps its floor’s holder, and its rules (§5.3 step 3) read the floor only while its screen keeps one.

8. Input-to-photon latency

8.1 The latency record

A record whose source is outside 1 to 3 is rd_statement_malformed. Its digest, where a party names it apart from its event, is SHA-256 over the record from magic through rtt_us. It carries its own signature, beside its event’s, so that it stands on its own: a viewer that shows a third party the latency it measured presents its records and its grant, with no other event of the room.

8.2 Rules

A latency record is checked, in this order:

1. its room is the room id: otherwise wrong_room;
2. its viewer is its event’s principal: otherwise latency_wrong_key;
3. its signature verifies under viewer (§8.1): bad_key, bad_signature;
4. its input is the digest of an input statement the room accepted, by viewer, whose host is the record’s host, with an action at index action: otherwise latency_unknown_input;
5. its outcome is the digest of the outcome of that input, which the room accepted, and which states it applied; its track, group and object are that outcome’s anchor’s, and its content that outcome’s content; its input_at is the input’s t less the action’s dt_us: otherwise latency_mismatch;
6. its presented_at is at most its event’s t: a record states what was presented, never what will be. Otherwise latency_ahead;
7. its presented_at is at least its input_at, and its latency_us is the difference: otherwise latency_mismatch.

8.3 What it measures

A latency record measures from an action to the presentation of the first frame that can show it. Both instants are on the viewer’s own estimate, so the room clock’s offset cancels from the difference; what remains is the estimate’s drift over the interval, which the viewer keeps small by measuring its clock against a room key’s as co-watch §7.3 has a player do. The first frame that can show an input is the first the host captured after injecting it (§6.1): the host’s operating system and the application under the pointer may take longer to draw the effect, so the record is a lower bound on the time until the effect is seen, and is exact when they draw it in time for that frame.

A viewer SHOULD state as presented_at the instant its platform’s frame-timing interface reports for the frame it drew: the presentation time of a video frame callback, or the start of the display refresh after the one in which the frame was drawn, never the instant it was decoded. A light sensor (source 2) watching the display measures the photon itself, and is the record a laboratory makes. A viewer with no display, such as an agent that reads the screen or a test harness, states source 3 and the instant it held the frame verified against its receipt: no photon is involved, and the record measures the path to the viewer alone.

A viewer measures the actions it chooses: every input, or one in so many. A record is a sample, and a verifier states each one; it states no percentile over a room, since which actions were measured is the viewer’s choice.

8.4 The legs and their uncertainty

From a latency record and the outcome it names, a verifier states three legs:

• up: the outcome’s applied_at less the record’s input_at: from the action to its injection;
• host: the outcome’s captured_at less its applied_at: from the injection to the capture of the first frame after it;
• down: the record’s presented_at less the outcome’s captured_at: from the capture to the presentation.

They sum to latency_us. The host leg is on the host’s estimate alone and the total on the viewer’s alone. The up and down legs cross from one estimate to the other, and each is stated with an uncertainty of half the sum of the two rtt_us, rounded down: the most a clock measured over a round trip of that length can be off, when the path’s two directions take equal time. When either estimate states no round trip, the uncertainty is not stated, and the crossing legs are stated without it. A leg that crosses estimates may come out negative by up to its uncertainty; it is stated as it is.

9. Session records and metering

A remote desktop session is the room’s session, and its records are the room’s:

• the session: from the host’s join to its leave, the clock’s lifecycle (live-rooms §7.2), and in it every principal’s presence, its grant in effect, and each grant exchange that handed control over;
• what happened: the host’s screen statements, every input, its outcome and the floor, in the chains of their authors, which a verifier replays (§11) and states;
• what it cost: the host’s screen track is a track of the room, and every hop that carried it signs its per-hop session record, as it does for every track; the room-session receipt totals them, its publisher-seconds and subscriber-seconds included (live-metering §3, §4). The input statements, the outcomes and the latency records are events of their authors, which live-metering counts as events sent and delivered. An action costs its share of an event’s bytes; a frame its object’s;
• what was kept: a recording of the session, when the room’s recording policy records it (live-rooms §3.7), is a recording of the room (live-recording); its manifest holds the screen track and the events, so a recording of a session verifies as the session does.

This extension adds no record for any of these.

10. Where each rule is enforced

• The host applies only what §5.3 accepts, signs an outcome for every input it receives (§6), captures only what its screen statement states (§3.5), and names its encoder (§3.6). It is the rules’ enforcement point: it is the one party whose machine an action reaches, and the one that holds the opening key of its sealing key (§5.5).
• A relay or a room service that carries the room’s events carries each principal’s events in its chain order, as it carries every event, and a sealed action as it is: it holds no opening key.
• A room service that keeps a session’s records (§9, §11.1) SHOULD bound how many it keeps, and SHOULD bound them per principal first. A bound per principal falls on the principal that reaches it: the service keeps none of its records past the bound, cuts its chain there and removes it (live-rooms §7.2, leave reason 2), and the session goes on for everyone else; a host that knows the bound takes none of that principal’s records past it either, so the host and the service hold the same records and the session verifies. The host itself is held to no bound of its own, since its records answer the others’ inputs and grow with the room. A bound on the whole session is a safety net, set well above the bound per principal times a room’s usual number of active principals, so that the bound per principal is the one any single principal meets first: when the session’s bound is reached the service ends the session, every principal’s leave signed, the host’s last. Either way the records kept are whole chains, and a verifier accepts them. It MAY decline to forward an input statement to the host whose author carries no control power at its t (§5.3 step 2), which it can tell from the grants it holds; it then never reaches the host, and stays unanswered.
• The room authority signs the grants that mark the host and give the control power (§3.1), and exchanges them to hand control over (§7.1).
• Controllers send actions in the coordinates of the screen in effect, and send again what was refused once what refused it has changed.
• Viewers verify each frame against its receipt before they decode it (§3.2), and state latency as §8.3 has them.

After the fact, a verifier (§11) checks every one of these against the room: an input a host applied that §5.3 refuses, an outcome that states another reason than the rule that refuses, and a latency record that names another frame than the host’s outcome, are each found out. A floor statement by a principal that may not send it is stated, and passes nothing (§7.2).

11. Verification

11.1 Inputs

A remote desktop verifier is given what a room verifier is given (live-rooms §9.1: a descriptor, grants, a key-log head or none, and the chains), and at the opened level the opening keys of the hosts’ sealing keys (§11.4). Every statement this extension defines is in the chains.

11.2 Steps

It runs these steps and stops at the first refusal, which it reports with the reason and where:

1. The room (live-rooms §9): a refusal, at room with the room verifier’s own place. A gap is not a refusal; the steps go on, and the checks that look up another statement (§6.2 steps 1 and 5, §8.2 steps 4 and 5) are not made for a statement whose lookup fails: the statement looked for may be in the gap.
2. The grants’ attributes (§3.1), in the grants’ order: at the grant’s index.
3. The statements, in the merged order: each meta event the room accepted whose payload begins with a magic of §4.1: §4.2, then §4.3, then the rules of its section in the order the section gives, with the screen in effect, the floor in effect and each grant in effect at its place. A floor statement §7.2 refuses is not a refusal: it is stated (§11.3) and changes nothing. The checks of an outcome and of a latency record that look up another statement (§6.2, §8.2) are made after every statement has been read, since the statement they name may follow them in the merged order. At the record.
4. The outcome (§11.3).

11.3 Outcomes and what a verification states

• refuse: the reason and where (§11.2).
• gap: no refusal, and the room has a gap: the gaps, under the code delivery_gap, and what accept states, computed from what the verifier holds, with each outcome and latency record whose lookup failed stated unchecked.
• accept: no refusal and no gap.

With accept or gap, the verifier states:

• each screen statement, in the merged order: its digest, host, state, size, scope, floor, accepts, capability, codec, encoder, api and hardware;
• each input statement, in the merged order: its digest, author, host, the classes of its actions, the number of its sealed actions when it has any, and its outcome: applied (with the frame its outcome names), refused with the reason, or unanswered; and at the opened level, for a sealed input, what its seal gave (§11.4);
• the floor: each change of each host’s floor in effect, in the merged order, with the instant and the holder, or none;
• each floor statement §7.2 refuses, in the merged order: its digest, author, host, t, action and reason (§12’s third table);
• each latency record, in the merged order: its digest, viewer, source, latency_us, and its legs (§8.4) with their uncertainty, or unchecked;
• for each host, the count of inputs applied, refused for each reason of rules 1 to 7, and for rules 8 and 9 where that count is not zero, and unanswered.

11.4 Two levels

A remote desktop verification is made at one of two levels.

• The commitment level is what every party that holds the room verifies, with no key beyond the room’s. It makes every step of §11.2 and reads no seal’s plaintext: it makes rule 9 of §5.3 only where the screen statement a sealed input names states no sealing key (§6.2 step 5). It checks every statement’s form, every outcome against rules 1 to 8, the floor, every latency record and every chain. A host that applies a key, text or clipboard action sent in the clear to a screen with a sealing key, or a sealed input to a screen with none, is found out at this level; one that applies a seal that does not open, or refuses one that does, is not.
• The opened level is a verification also given an opening key for each sealing key the room’s screen statements state. For each sealed input it opens the seal with the opening key of the sealing key of the screen statement the input names, makes rule 9 in full, and requires every outcome to state what all nine rules give. It states what each sealed input’s seal gave: opened, with the input statement as it reads opened (each sealed action replaced by the action it seals, and no seal); the reason rule 9 holds (§12’s fourth table); or unopened, when it was given no opening key for that sealing key, and then that input is checked as at the commitment level.

The opened level is optional: the opening key is the host’s to give, and a room verifies without it. A room the opened level accepts, the commitment level accepts.

12. Reasons

The codes this extension adds that refuse a room, each with where it is raised:

The reasons a host states in a refused outcome, each with its number and the rule of §5.3 it names; a verifier refuses none of them, and states each input refused with them:

The reasons a floor statement is refused at its place (§7.2); a verifier refuses none of them, states each floor statement refused with them, and computes the floor without it (§7.3):

The reasons rule 9 of §5.3 holds for a seal (§5.5), which a verification at the opened level states of each sealed input it does not open (§11.4); a verifier refuses none of them:

A remote desktop verifier also raises every code a room verifier raises (live-rooms §11 and the live-events codes it lists), at the room; wrong_room, bad_key and bad_signature for a latency record (§8.2); and delivery_gap for a gap, which is not a refusal.

13. Conformance

live-conformance/remote/ holds the corpus, in one file, vectors.json, written from fixed seeds by wai_remote_desktop_vectors gen. It has rooms, each a room (descriptor, grants, key-log head or none, chains) and the outcome §11.3 gives it with everything it states.

• Accepted: a session of a host that keeps a floor, a controller of pointer, keys and touch, a controller of every class but touch, a viewer with no control power, and a lead with the direct power: the host gives the floor and the holder’s click and key are applied; the viewer’s input is refused input_not_permitted and the second controller’s input_no_floor; the second controller requests the floor, the host gives it, and its clipboard text is applied, while the first’s input is refused input_no_floor; the holder releases it and the lead gives it back; the host resizes its screen, and an input in the old coordinates is refused input_wrong_screen; a touch it does not inject is refused input_unsupported, a pointer off the frame input_out_of_bounds, and an input decided too late input_stale; an input the host never answers is unanswered; it pauses, and an input is refused input_screen_paused; it resumes, and a wheel turn and composed text are applied; it takes the floor back; and latency records from both controllers, with their legs. And an open session in which control passes by grant exchange: the first controller’s input before the exchange is applied and its input after it refused input_not_permitted, and the second controller’s refused before it and applied after it.
• Accepted, with a floor statement §7.2 refuses: each reason of §12’s third table at least once, each stated and changing nothing: the floor given by the viewer and given to the viewer, released by a controller that does not hold it, requested by the viewer, taken by a controller, and stated for a principal that is no host; and three whole floor sessions, each with the holder after the refused statement the one before it: a controller that does not hold the floor gives it to itself, a controller releases the floor another holds, and the holder’s release takes its place after the host took the floor back, a race on the wire.
• Gap: the floor session with one record of a controller not delivered.
• Refused: each reason of §12’s first table at least once, each vector a session of one defect: among them a host that applied an input that each rule of §5.3 refuses, a host that refused a good input or stated another rule than the one that refuses, an outcome that names no frame, and latency records naming another frame, signed by another key, or presented after they were signed.
• Sealed (§5.5), after every vector above, each stating what the opened level gives it under the corpus’s opening key (opening_key) beside what the commitment level does: a session of a host that states a sealing key, in which keys, a composed text and a clipboard text are applied sealed, a text in the clear is refused input_unsealed, a text sealed to the viewer’s key, one whose commitment is another text’s, one whose opening does not read and another controller’s copy of a sealed input are each refused input_bad_seal, and, on a screen with no sealing key, a sealed text is refused input_bad_seal and keys in the clear are applied; three sessions the commitment level accepts and the opened level refuses (the host applies the text sealed to the viewer’s key, applies the text whose commitment is another’s, refuses a seal that opens); and vectors both levels refuse (the host applies a text in the clear to a screen with a sealing key, applies a sealed text to a screen with none, refuses keys in the clear by rule 9; a ciphertext one byte short, a sealed action that seals a touch, a sealing key of 31 bytes). Every other vector holds no seal, and the opened level gives it what the commitment level does.

A conforming verifier gives every room the outcome, the reason, the place, and everything else the corpus states, at both levels. wai_remote_desktop_vectors verify and the test tests/remote_desktop.rs check that the file regenerates byte for byte, that wai-rs gives every room its outcome at both levels, that every reason of the four tables of §12 appears, and that §12 lists exactly the reference’s codes. live-conformance/remote_desktop_verify.py is the second implementation, written from this text: it shares no code with wai-rs; it verifies each room with the live-rooms corpus’s second implementation (live_rooms_verify.py), every signature with WAI’s strict rule (claim-conformance/_ed25519.py), and every seal with the HPKE, X25519, HKDF and AES-128-GCM the aggregation corpus’s second implementation writes from their texts (telemetry_aggregate_verify.py); and it mutates copies of the corpus and requires every copy to fail. The browser viewer’s module (web/room/remote.js of joule-moq-web) writes the corpus’s input statements, sealed ones among them, floor statements and latency records byte for byte, and gives every input of the corpus the outcome the corpus states.

14. Security and privacy considerations

• Input reaches a machine. An applied action types and clicks on the host as its user would. The host is the enforcement point (§10): it applies only what the grant in effect allows, at the input’s place, and states every decision, so a host that applies more than the grant allows is found out by any verifier holding the room (§6.2 step 5). The authority decides who controls, in the grants it signs; the host decides what it injects at all (accepts) and how old an action may be (max_age_ms). A room key cannot send input (§4.3): the room’s services never act on a host’s machine.
• Every statement is signed by its author and rides in its author’s chain. A relay can withhold an input but alter none, and a withheld input is a gap in its author’s chain and is unanswered. A replayed input is a duplicate (live-events §6.2) and is decided once.
• What is captured is the host’s. The screen statement states the scope, the redactions, whether the pointer is drawn and whether capture is paused (§3.5), and a sink shows them. A frame can hold whatever the host’s screen holds at that instant, including personal data and credentials; a host that shares a window rather than a display, or that redacts, shares less. A room that needs its frames unreadable by its relays is confidential (confidentiality): its objects and events are sealed end to end, and the rules here are unchanged. A recording of the room keeps its events as they are, a sealed action sealed: the room’s recording policy decides (live-rooms §3.7).
• What a controller types is sealed to a host that states a sealing key (§5.5): a relay, the room service, every viewer and a recording of the room hold a ciphertext and a commitment for each key, text and clipboard action, and only the holder of the opening key reads them. A commitment is salted, so it cannot be guessed from the few values a key takes, and it binds the input, its order and its author, so a host that opens a seal can show a third party one action’s opening without the others, and that party checks it against the record. What stays in the clear is what rules 1 to 8 read and what the screen shows: that an input holds key, text or clipboard actions and how many, their instants, a clipboard text’s length, and every pointer, wheel and touch action. The instants of keystrokes can say something of what was typed; a controller that needs them hidden sends text as one composed text action, whose length is hidden too. The host reads what it injects, as it must: a host is trusted with what is typed into it.
• The encoder’s name is a statement. It says what made the frames, as the host reports it, and is not evidence of it; nothing is accepted or refused on it (§3.6). The receipts bind the bytes.
• A latency record is a viewer’s claim: it proves that the holder of the viewer’s key stated it, not that it is true, as a presentation statement of co-watch §14 is. A modified viewer can state any instant. The record names the frame by its content hash and the host’s outcome, so it cannot claim a frame the host did not name, and its presentation can be no later than its own event (§8.2 step 6). A light sensor’s record is as good as the sensor.
• Keys and timing. A controller’s statements say when and where it acted, which is personal data, and to a host with no sealing key what it typed too. A principal that needs its sessions unlinkable across rooms uses a key per room, as live-events §11 has every principal do. Taking part in a room under a grant is taking part in its mechanics, and this extension adds no consent step to them. Where a regime asks the operator for a lawful basis for processing what a room carries, the operator records it as a lawful-basis claim (jwp-receipts §2.4.6).