@robota-sdk/agent-transport-webrtc 3.0.0-beta.81

package/src/handoff-grant-gate.ts

@@ -0,0 +1,186 @@
+/**
+ * SEC-011 (issue #1865): the channel gate consumes the cross-device hand-off grant.
+ *
+ * The same shape SEC-010's local-proof step established, for the same reason. #1810 is explicit that
+ * this package must not implement cryptographic policy, so nothing here verifies a signature,
+ * decides an expiry, or knows what revocation is. The gate holds the state machine; the verdict is
+ * injected and reported.
+ *
+ * ## What the grant proves, and what the channel proves
+ *
+ * The pairing handshake binds the CHANNEL: after it, this data channel provably terminates at the
+ * peer that knew the secret, and the DTLS fingerprints are covered so it cannot be spliced. It says
+ * nothing about who that peer is.
+ *
+ * The grant binds the TRANSFER: one user, one source device, one destination, one `handoffId`, one
+ * `sessionId`, one nonce, and the fingerprint of the channel it may be presented over. It says
+ * nothing about whether the channel it arrived on is the one it names.
+ *
+ * Presenting the grant OVER the already-bound channel is what joins them, and the fingerprint claim
+ * is what makes the join checkable: a grant lifted from one channel and replayed on another names a
+ * fingerprint the verifier does not observe. That is `channel-substituted`, and it is a distinct
+ * rejection precisely so it cannot be softened into a pass.
+ *
+ * ## Why it runs after the handshake and before the session
+ *
+ * Both edges are load-bearing, and both for SEC-010's reasons.
+ *
+ * BEFORE the handshake completes, the channel is not authenticated — a grant presented there would
+ * be handed to an unproven counterpart, and this step would weaken what it exists to strengthen.
+ *
+ * BEFORE the session is exposed, because "fail closed before content" is the first failure rule. A
+ * peer that never presents a grant must not have been talking to the session already; refusing it
+ * afterwards is not refusing it.
+ *
+ * ## The trust it produces is its own
+ *
+ * `same-user-different-host` is not `same-user-same-host`. #1812 pins that they are different values
+ * and this gate is the reason: a cross-device authorization must never satisfy a check that wanted
+ * same-machine. It travels as a value on the admission rather than being re-derived from a boolean
+ * by whoever reads it next.
+ */
+
+import type { IPeerAdmission } from '@robota-sdk/agent-interface-session-mobility';
+
+/** The frame a source device presents to show it holds a grant for this transfer. */
+export interface IHandoffGrantFrame {
+  readonly t: 'handoff-grant';
+  /**
+   * The signed grant, carried opaquely.
+   *
+   * `unknown` on purpose: this package cannot import the grant type without importing the package
+   * that owns the crypto, and typing it structurally here would create a second declaration of a
+   * signed object's shape — which is how a field ends up checked in one copy and not the other.
+   * The verifier owns the type; this gate owns the envelope.
+   */
+  readonly grant: unknown;
+}
+
+/**
+ * The cross-device authorization this gate requires before exposing the session.
+ *
+ * Absent → the gate behaves exactly as before. Requiring a grant is opt-in because an ordinary
+ * remote peer has no hand-off to authorize, and a gate that demanded one unconditionally would
+ * refuse every legitimate remote session.
+ */
+export interface IHandoffGrantProof {
+  /**
+   * Judge a presented grant. Owned by the verifier — this package asks and does not decide.
+   *
+   * Async because verifying a signature is: `verifyHandoffGrant` returns a promise, and a
+   * synchronous seam here would force the owner to block or to pre-verify, and pre-verifying means
+   * deciding before the channel that the grant is bound to even exists.
+   *
+   * Returns the admission the consumer receives, so the trust level travels as a value.
+   */
+  readonly verify: (grant: unknown) => Promise<IPeerAdmission>;
+  /**
+   * Ask the person at THIS machine whether to accept the transfer. Absent → no consent is required.
+   *
+   * Called ONLY on a verdict the verifier admitted, and given that verdict, for two reasons that
+   * both matter:
+   *
+   * The prompt can then name a PROVEN origin. Asking before verification would let anyone who can
+   * open a channel raise a dialog on someone's machine claiming to be any device they like, which
+   * turns the consent step into an attack surface instead of a control.
+   *
+   * And consent is not cryptographic policy, so it does not belong inside `verify`. A verifier that
+   * also asked a human would make "is this grant valid" and "does this person want it" one answer,
+   * and the first is the one that must be decidable without a person present.
+   *
+   * Returning false — or throwing, or having no renderer to ask — refuses. Denial fails CLOSED.
+   */
+  readonly consent?: (admission: IPeerAdmission) => Promise<boolean>;
+  /**
+   * Fired on the outcome, admitted or not.
+   *
+   * On BOTH, deliberately: a consumer told only about successes cannot distinguish "no hand-off was
+   * offered" from "a hand-off was refused", and those call for different operator responses — the
+   * second is the one that belongs in front of a person.
+   */
+  readonly onAdmission?: (admission: IPeerAdmission) => void;
+}
+
+/**
+ * True when a parsed pre-accept value is a grant frame.
+ *
+ * Module-private: `judgeHandoffGrant` is the only thing that should ask. Exporting it would offer a
+ * caller a way to check the shape and then act on it without going through the judge, which is how
+ * an admission decision ends up made in two places.
+ */
+function isHandoffGrantFrame(value: unknown): value is IHandoffGrantFrame {
+  return (
+    typeof value === 'object' &&
+    value !== null &&
+    (value as { t?: unknown }).t === 'handoff-grant' &&
+    (value as { grant?: unknown }).grant !== undefined
+  );
+}
+
+/** A refusal shaped like every other admission, so no caller has to special-case the failure path. */
+function refuse(reason: string): IPeerAdmission {
+  return { admitted: false, trust: 'unproven', reason };
+}
+
+/**
+ * Judge one pre-accept frame against the configured grant proof.
+ *
+ * Every path that is not an admitted verification returns a refusal — including a missing config,
+ * which cannot happen through the gate but would be a fail-OPEN if it ever did.
+ */
+export async function judgeHandoffGrant(
+  parsed: unknown,
+  proof: IHandoffGrantProof | undefined,
+): Promise<IPeerAdmission> {
+  if (proof === undefined)
+    return refuse('no hand-off grant verifier is configured for this channel');
+  if (!isHandoffGrantFrame(parsed)) {
+    return refuse('expected a handoff-grant frame carrying the signed grant');
+  }
+  try {
+    const admission = await proof.verify(parsed.grant);
+    // The verifier owns the verdict, but not the ability to widen it. A cross-device grant cannot
+    // establish that the peer is on THIS machine, so an admission claiming it did is refused rather
+    // than passed on — an implementation that returned the stronger level would otherwise satisfy
+    // every check that wanted same-machine, which is the one substitution #1812 forbids by name.
+    if (admission.admitted && admission.trust === 'same-user-same-host') {
+      return refuse(
+        'the grant verifier returned same-user-same-host. A cross-device grant proves the user, ' +
+          'not the machine — see SEC-010 for what same-host requires.',
+      );
+    }
+    if (!admission.admitted || proof.consent === undefined) return admission;
+    // The person, after the proof. A refusal here is not a weaker outcome than a cryptographic one:
+    // the session is equally not exposed, and the reason says which step declined so the operator is
+    // not left reading "unauthorized" when what happened is that they said no.
+    if (!(await proof.consent(admission))) {
+      return refuse('the person at this machine declined the transfer');
+    }
+    return admission;
+  } catch (error) {
+    // allow-fallback: fail-CLOSED, not a fallback to a degraded path. A verifier that throws has not
+    // reached a decision, and "not reached" is not "allowed" — the refusal below is strictly more
+    // restrictive than the success path, never less. Letting it propagate would be worse: the throw
+    // unwinds through the channel's message subscription and leaves the gate parked in its grant
+    // state with the channel open, which is a hang — fail-open wearing a crash's clothes.
+    return refuse(
+      `the grant verifier could not decide: ${
+        error instanceof Error ? error.message : 'unknown error'
+      }`,
+    );
+  }
+}
+
+/**
+ * Build the frame a source device presents on the channel.
+ *
+ * Lives beside the judge that reads it, so the two cannot drift: a sender that hand-built the object
+ * would keep compiling after the frame gains a field, and the failure would surface as a refusal on
+ * the far side with no hint that the SENDER is the stale half.
+ *
+ * Deliberately not a "send" — it returns the frame and leaves transmission to whoever owns the
+ * channel, for the same reason `localProofFrame` does.
+ */
+export function handoffGrantFrame(grant: unknown): IHandoffGrantFrame {
+  return { t: 'handoff-grant', grant };
+}

package/src/index.ts

@@ -0,0 +1,21 @@
+export { WebRtcTransport } from './webrtc-transport.js';
+export type { IWebRtcTransportOptions, IIceServer } from './webrtc-transport-options.js';
+export type {
+  IConnectionApproval,
+  IConnectionApprovalContext,
+  IHostReconnectConfig,
+} from './pairing-gate.js';
+// The judge and the frame predicate stay internal: they are this package's policy plumbing, and a
+// composition root only needs to SUPPLY the port and, on the peer side, know the frame's shape.
+export { localProofFrame } from './local-peer-proof.js';
+export type { ILocalPeerProof, ILocalProofFrame } from './local-peer-proof.js';
+// SEC-011 (issue #1865): the cross-device hand-off grant gate. The verdict is injected — this
+// package implements no cryptographic policy.
+export { handoffGrantFrame } from './handoff-grant-gate.js';
+export type { IHandoffGrantFrame, IHandoffGrantProof } from './handoff-grant-gate.js';
+export { createInMemorySignalingPair } from './signaling.js';
+export type { ISignalingClient, ISignalMessage, TSignalKind } from './signaling.js';
+export { WsSignalingClient } from './ws-signaling-client.js';
+export type { IWsSignalingClientOptions, IWebSocketLike } from './ws-signaling-client.js';
+export { loadWerift } from './werift-loader.js';
+export type { IWeriftModule, TModuleResolver } from './werift-loader.js';

package/src/local-peer-proof.ts

@@ -0,0 +1,135 @@
+/**
+ * SEC-010 TC-08: joining the rendezvous proof to the channel the session will run on.
+ *
+ * ## What each half proves, and why neither is enough alone
+ *
+ * The pairing handshake binds the CHANNEL: after it, this data channel provably terminates at the
+ * peer that knew the secret, and the DTLS fingerprints are covered so it cannot be spliced. It says
+ * nothing about where that peer runs.
+ *
+ * The guarded rendezvous binds the ENVIRONMENT: a peer that reached a 0700 directory owned by this
+ * user could only have come from this machine, as this user. It says nothing about which channel
+ * that peer later opens.
+ *
+ * Presenting the rendezvous nonce OVER the already-bound channel is what joins them. The channel is
+ * authenticated by the time this runs, so nobody else can inject the frame; the nonce is single-use,
+ * so nobody can re-present one they observed. Together they say: the party on this channel is the
+ * party the kernel vouched for, on this attempt.
+ *
+ * ## Why this runs after the handshake and before the session
+ *
+ * Both edges are load-bearing.
+ *
+ * BEFORE the handshake completes, the channel is not yet authenticated — a nonce presented there
+ * would be a secret handed to an unproven counterpart, and this step would weaken the very thing it
+ * exists to strengthen.
+ *
+ * BEFORE the session is exposed, because "fail closed before content" is SEC-010's first failure
+ * rule. If the proof arrived after exposure, a peer that never presents one would have already been
+ * talking to the session, and refusing it afterwards is not refusing it.
+ *
+ * ## This package decides nothing
+ *
+ * #1810 is explicit that WebRTC must not implement cryptographic policy. Single-use, expiry and
+ * revocation belong to the grant ledger in `@robota-sdk/agent-remote-pairing/local`, which is
+ * node-only; this module takes an injected `redeem` and reports what it was told. That also keeps
+ * `node:fs` out of this package, and keeps the ledger testable without a data channel.
+ */
+
+import type { IPeerAdmission } from '@robota-sdk/agent-interface-session-mobility';
+
+/** The frame a local peer presents to show it reached the guarded rendezvous. */
+export interface ILocalProofFrame {
+  readonly t: 'local-proof';
+  readonly nonce: string;
+}
+
+/**
+ * The local-environment proof this gate requires before exposing the session.
+ *
+ * Absent → the gate behaves exactly as before. Requiring the proof is opt-in because a remote peer
+ * over WebRTC has no rendezvous to have reached, and a gate that demanded one unconditionally would
+ * refuse every legitimate remote session.
+ */
+export interface ILocalPeerProof {
+  /**
+   * Redeem a presented nonce. Owned by the ledger — this package asks and does not decide.
+   *
+   * Returns the admission the consumer receives, so the trust level travels as a value rather than
+   * being re-derived from a boolean by whoever reads it next.
+   */
+  readonly redeem: (nonce: string) => IPeerAdmission;
+  /**
+   * Fired on the outcome, admitted or not.
+   *
+   * On BOTH, deliberately: a consumer told only about successes cannot distinguish "no local peer
+   * connected" from "a local peer was refused", and those call for different operator responses.
+   */
+  readonly onAdmission?: (admission: IPeerAdmission) => void;
+}
+
+/**
+ * True when a parsed pre-accept value is a local-proof frame carrying a nonce.
+ *
+ * Module-private: `judgeLocalProof` is the only thing that should ask. Exporting it would offer a
+ * caller a way to check the shape and then act on it without going through the judge, which is how
+ * an admission decision ends up made in two places.
+ */
+function isLocalProofFrame(value: unknown): value is ILocalProofFrame {
+  return (
+    typeof value === 'object' &&
+    value !== null &&
+    (value as { t?: unknown }).t === 'local-proof' &&
+    typeof (value as { nonce?: unknown }).nonce === 'string'
+  );
+}
+
+/** A refusal shaped like every other admission, so no caller has to special-case the failure path. */
+function refuse(reason: string): IPeerAdmission {
+  return { admitted: false, trust: 'unproven', reason };
+}
+
+/**
+ * Judge one pre-accept frame against the configured proof.
+ *
+ * Every path that is not an admitted redemption returns a refusal — including a missing config,
+ * which cannot happen through the gate but would be a fail-OPEN if it ever did.
+ */
+export function judgeLocalProof(
+  parsed: unknown,
+  proof: ILocalPeerProof | undefined,
+): IPeerAdmission {
+  if (proof === undefined) return refuse('no local-peer proof is configured for this channel');
+  if (!isLocalProofFrame(parsed)) {
+    return refuse('expected a local-proof frame carrying the rendezvous nonce');
+  }
+  try {
+    return proof.redeem(parsed.nonce);
+  } catch (error) {
+    // allow-fallback: fail-CLOSED, not a fallback to a degraded path. A ledger that throws has not
+    // reached a decision, and "not reached" is not "allowed" — the refusal below is strictly more
+    // restrictive than the success path, never less. Letting it propagate would be worse: the throw
+    // unwinds through the channel's message subscription and leaves the gate parked in its proof
+    // state with the channel open, which is a hang — fail-open wearing a crash's clothes.
+    return refuse(
+      `the rendezvous ledger could not decide: ${
+        error instanceof Error ? error.message : 'unknown error'
+      }`,
+    );
+  }
+}
+
+/**
+ * Build the frame a local peer presents on the channel.
+ *
+ * Lives beside the judge that reads it, so the two cannot drift: a sender that hand-built the object
+ * would keep compiling after the frame gains a field, and the failure would surface as a refusal on
+ * the far side with no hint that the SENDER is the stale half.
+ *
+ * Deliberately not a "send" — it returns the frame and leaves transmission to whoever owns the
+ * channel. A helper that both built and sent would need a channel to be testable, and would put the
+ * frame's shape and the carrier's lifecycle in one place.
+ */
+export function localProofFrame(nonce: string): ILocalProofFrame {
+  return { t: 'local-proof', nonce };
+}

package/src/negotiated-certificate.ts

@@ -0,0 +1,80 @@
+/**
+ * The remote fingerprint the pairing confirmation binds to, read from the certificate the DTLS layer verified.
+ *
+ * The SDP is delivered by an untrusted signaling path, and a DTLS stack accepts the remote certificate when it
+ * matches ANY fingerprint the SDP advertises. Binding a value read from SDP text would therefore let the bound
+ * fingerprint and the verified certificate differ. Reading the certificate itself, after the DTLS layer has
+ * verified it, makes the binding and the connection share one source of truth.
+ */
+
+import { createHash } from 'node:crypto';
+
+import type { RTCPeerConnection } from 'werift';
+
+const HASHES: Readonly<Record<string, string>> = {
+  'sha-256': 'sha256',
+  'sha-384': 'sha384',
+  'sha-512': 'sha512',
+};
+
+/** SDP-form fingerprint (`AB:CD:…`, upper case) of a DER certificate. Throws on an unsupported algorithm. */
+export function certificateFingerprint(der: Uint8Array, algorithm: string): string {
+  const hash = HASHES[algorithm.toLowerCase()];
+  if (!hash) throw new Error(`unsupported DTLS fingerprint algorithm: ${algorithm}`);
+  const hex = createHash(hash).update(der).digest('hex').toUpperCase();
+  return hex.match(/../g)?.join(':') ?? '';
+}
+
+/**
+ * Call `onVerified` with the remote certificate's fingerprint once the DTLS handshake — including its own
+ * fingerprint check — has completed, or `onFailed` if the handshake fails or closes first, or the certificate
+ * cannot be read. Returns an unsubscribe function.
+ *
+ * werift moves the DTLS transport to `connected` only after `verifyRemoteCertificateFingerprint` succeeds, and
+ * the data channel runs over that DTLS session, so no channel frame can precede this callback.
+ */
+export function whenRemoteCertificateVerified(
+  peer: RTCPeerConnection,
+  algorithm: string,
+  onVerified: (fingerprint: string) => void,
+  onFailed: (reason: string) => void,
+): () => void {
+  const dtlsTransport = peer.sctpTransport?.dtlsTransport;
+  if (!dtlsTransport) {
+    onFailed('no DTLS transport for the data channel');
+    return () => undefined;
+  }
+  let done = false;
+  const settle = (): void => {
+    if (done) return;
+    const der = dtlsTransport.dtls?.remoteCertificate;
+    done = true;
+    if (!der) {
+      onFailed('the DTLS layer exposed no remote certificate');
+      return;
+    }
+    try {
+      onVerified(certificateFingerprint(der, algorithm));
+    } catch (error) {
+      onFailed(error instanceof Error ? error.message : String(error));
+    }
+  };
+  if (dtlsTransport.state === 'connected') {
+    settle();
+    return () => undefined;
+  }
+  if (dtlsTransport.state === 'failed' || dtlsTransport.state === 'closed') {
+    onFailed(`the DTLS handshake ended ${dtlsTransport.state}`);
+    return () => undefined;
+  }
+  const subscription = dtlsTransport.onStateChange.subscribe((state) => {
+    if (state === 'connected') settle();
+    else if (state === 'failed' || state === 'closed') {
+      if (done) return;
+      done = true;
+      onFailed(`the DTLS handshake ended ${state}`);
+    } else return;
+    subscription.unSubscribe();
+  });
+  return () => subscription.unSubscribe();
+}

package/src/pairing-channel-lifecycle.ts

@@ -0,0 +1,31 @@
+import type { IPairingChannel } from './pairing-gate-options.js';
+
+function send(channel: IPairingChannel, data: string): void {
+  try {
+    channel.send(data);
+  } catch {
+    // The peer is gone; pairing frames are best-effort once the carrier is closing.
+  }
+}
+
+function close(channel: IPairingChannel): void {
+  try {
+    channel.close();
+  } catch {
+    // The carrier is already closing or closed.
+  }
+}
+
+function reportDeliveryError(
+  callback: ((error: Error, event: string) => void) | undefined,
+  error: Error,
+  event: string,
+): void {
+  try {
+    callback?.(error, event);
+  } catch {
+    // A diagnostic callback cannot prevent carrier teardown or escape into the committed operation.
+  }
+}
+
+export const pairingChannel = Object.freeze({ send, close, reportDeliveryError });

package/src/pairing-controllers.ts

@@ -0,0 +1,79 @@
+/**
+ * Constructing the admission controllers the gate drives.
+ *
+ * "Which controller runs, with what inputs" is a different subject from "what state is the gate in
+ * and what may reach the session" — the same boundary that already moved the frame vocabulary into
+ * `pairing-frames.ts` and the best-effort channel calls into `pairing-channel-lifecycle.ts`.
+ *
+ * Split out because `pairing-gate.ts` had reached the size limit, where the rule is to split rather
+ * than extend. These two functions were the largest thing in it that was not about gating, and they
+ * touch nothing of the gate's own state: they take inputs, wire a controller's `send` to the
+ * channel, and hand back the controller plus a settled/rejected outcome for the caller to act on.
+ */
+
+import { startHostReconnect, startPairingHandshake } from '@robota-sdk/agent-remote-pairing';
+
+import { pairingChannel } from './pairing-channel-lifecycle.js';
+
+import type { IHostReconnectConfig, IPairingChannel } from './pairing-gate-options.js';
+import type {
+  IPairingResult,
+  IReconnectResult,
+  TPairingRole,
+} from '@robota-sdk/agent-remote-pairing';
+
+/** What both controllers need to talk on the channel and bind to it. */
+export interface IControllerContext {
+  readonly channel: IPairingChannel;
+  readonly localFingerprint: string;
+  readonly remoteFingerprint: string;
+  /** Handshake timeout (ms); fail closed on expiry. */
+  readonly timeoutMs?: number;
+}
+
+/**
+ * Start the B3 first-pair handshake.
+ *
+ * `onAccepted`/`onRejected` rather than handing the promise back, so a caller cannot forget to
+ * attach a rejection path — an unhandled rejection here would leave a gate waiting forever on a
+ * handshake that already failed, which is a fail-OPEN shaped as a hang.
+ */
+export function startFirstPairController(
+  context: IControllerContext,
+  secret: string,
+  role: TPairingRole,
+  onAccepted: (result: IPairingResult) => void,
+  onRejected: () => void,
+  start: typeof startPairingHandshake = startPairingHandshake,
+): ReturnType<typeof startPairingHandshake> {
+  const controller = start({
+    secret,
+    role,
+    localFingerprint: context.localFingerprint,
+    remoteFingerprint: context.remoteFingerprint,
+    send: (frame) => pairingChannel.send(context.channel, JSON.stringify(frame)),
+    ...(context.timeoutMs !== undefined ? { timeoutMs: context.timeoutMs } : {}),
+  });
+  controller.result.then(onAccepted, onRejected);
+  return controller;
+}
+
+/** Start the E3 host-side reconnect exchange against a pinned device key. */
+export function startReconnectController(
+  context: IControllerContext,
+  config: IHostReconnectConfig,
+  onAccepted: (result: IReconnectResult) => void,
+  onRejected: () => void,
+): ReturnType<typeof startHostReconnect> {
+  const controller = startHostReconnect({
+    hostIdentityId: config.hostIdentityId,
+    localFingerprint: context.localFingerprint,
+    remoteFingerprint: context.remoteFingerprint,
+    hostPrivateKey: config.hostPrivateKey,
+    resolveDevicePublicKey: config.resolveDevicePublicKey,
+    send: (frame) => pairingChannel.send(context.channel, JSON.stringify(frame)),
+    ...(context.timeoutMs !== undefined ? { timeoutMs: context.timeoutMs } : {}),
+  });
+  controller.result.then(onAccepted, onRejected);
+  return controller;
+}

package/src/pairing-frames.ts

@@ -0,0 +1,34 @@
+/**
+ * Predicates over the pairing/reconnect frame vocabulary the gate admits pre-accept.
+ *
+ * Issue #2046: these are thin adapters over the OWNER codec in `@robota-sdk/agent-remote-pairing`,
+ * which decodes every required field (presence, base64url, length ceiling) rather than only the `t`
+ * discriminator this file used to check. A true answer means the narrowed value is well-formed; the
+ * browser `ResponderGate` imports the same codec, so one corpus governs both carriers.
+ */
+
+import {
+  decodeEnrollFrame,
+  decodePairingFrame,
+  decodeReconnectFrame,
+  type IEnrollFrame,
+  type TPairingFrame,
+  type TReconnectFrame,
+} from '@robota-sdk/agent-remote-pairing';
+
+export type { IEnrollFrame };
+
+/** True when a parsed value is a well-formed B3 pairing frame (`pair-nonce` | `pair-confirm`). */
+export function isPairingFrame(value: unknown): value is TPairingFrame {
+  return decodePairingFrame(value).ok;
+}
+
+/** True when a parsed value is a well-formed reconnect frame (`rc-hello` | `rc-host` | `rc-device`). */
+export function isReconnectFrame(value: unknown): value is TReconnectFrame {
+  return decodeReconnectFrame(value).ok;
+}
+
+/** True when a parsed value is a well-formed first-pair enrollment frame carrying a device SPKI. */
+export function isEnrollFrame(value: unknown): value is IEnrollFrame {
+  return decodeEnrollFrame(value).ok;
+}