After 0.8.0: Open Runtime-minted protected content in external apps such as base.ela.city (L5 of #388, options) #400

Parent: #91. This is the proposed last layer (L5) of #388. It is open for discussion. @andersalm @SashaMIT, please comment on the options below.

Problem

base.ela.city (elacity-web on Base) already does mint, buy and marketplace in its own way. It cannot open content that the Runtime mints. We do not want to port the Runtime into base.ela.city.

Goal

An entitled Base user opens Runtime-minted video and documents on base.ela.city. The Runtime security boundary stays intact.

Constraints agreed so far

• The seed node is the first entry point. It never sees a content key (CEK) or plaintext.
• base.ela.city changes as little as possible.
• The Runtime code is reused, not ported.

Shared base (the same for all options)

• Caller identity: the user's wallet signs a short delegation that binds an ephemeral recipient key, the asset and an expiry. This is a new "external viewer" principal. It is not a Runtime sign-in, and it only grants "read this asset if entitled".
• Rights: each custody node checks the Base AuthorityGateway itself, as in feat(protected-content): buy from any live offer #206.
• Keys: custody nodes seal their shares end-to-end to the recipient key. The seed holds one share and routes requests. It never holds two shares in the clear.
• Seed role: a public HTTPS edge served by the Runtime gateway, with a new, explicit admission class for allowed origins. It relays to the second custody node over Carrier.

Option A: Embedded Runtime viewer (the Runtime renders in a frame)

base.ela.city page --iframe--> viewer frame (Runtime origin; seed for now)
   wallet signs delegation <--postMessage--+   | decrypt core (Rust -> WASM)
                                           |   | Runtime player / reader UI
                                seed edge -+---> custody nodes -> shares sealed to the frame key

• How: base.ela.city adds an iframe and a small postMessage client (open(asset) and events). The frame runs the Runtime decrypt core as WASM and the existing Runtime player and reader. The host page only relays the wallet signature.
• base.ela.city work: very small. media-player and ddrm-reader do not change.
• Runtime work: a WASM build of the decrypt core, a frame-hosted viewer, and the external-viewer admission class.
• Security: plaintext is in the browser, inside the frame. This is the same as the Runtime viewer today. The frame protects against third-party scripts, but not against the entitled user, because the host page holds the wallet.
• For: one surface for all content types. Format changes stay in the Runtime. Later, the user's own Runtime can serve the same frame (a service worker, if needed, goes inside the frame).
• Against: phone and full-screen reading inside an iframe need care. COEP require-corp and frame-ancestors need setup. The UI is less native.

Option B: Key-release protocol (base.ela.city renders with its own readers)

media-player WASM --license(Runtime system ID)--> seed edge -> custody -> shares sealed to the WASM key
ddrm-reader backend --CekRecoveryStrategy-------> seed edge -> custody -> shares sealed to the backend

• How: the Runtime publishes a versioned key-release contract (delegation in, sealed shares out), and the seed serves it over HTTPS. base.ela.city adds two adapters: a media-player license handler that combines two shares in WASM, and a ddrm-reader CekRecoveryStrategy that keeps the CEK on the ddrm-reader backend.
• base.ela.city work: medium, in two repositories.
• Runtime work: small (the edge and the contract).
• Security: strongest for documents, because the CEK never reaches a browser. Video has the same trust as the current Chipotle flow.
• For: native UX. Each product keeps its own renderers.
• Against: base.ela.city must read Runtime formats. Runtime media is fMP4 parts, but media-player expects DASH and PSSH. Runtime documents use chunk identity, but ddrm-reader expects encryptedDataCid. Public reads of the encrypted bytes are also necessary. Each Runtime format change can break another repository.

Option C: Dual wrap at mint (no Runtime at read time)

Runtime mint -> CEK to dKMS custody (2-of-3) AND CEK wrapped for Chipotle/Lit
base.ela.city -> current Chipotle flow, no change

• How: the Runtime also writes a Chipotle-compatible PSSH, and DASH packaging for video, when it mints.
• base.ela.city work: none.
• Runtime work: large and permanent (the Lit encoder, DASH packaging, and parity with the transcoder).
• Security: two custody systems hold every key. Revocation and policy are split. The seed sees no CEK, but the Lit TEE does.
• For: no new read-time service.
• Against: it ties dKMS to Lit/Chipotle and works against the purpose of dKMS. Content that is already minted needs a re-wrap.

Proposal for discussion

• First, define the key-release contract (delegation, external-viewer principal, sealed shares) in L1/L2 of After 0.8.0: Rebuild protected content on develop as a layered stack (successor of #203–#206) #388. Options A and B both use it.
• Ship Option A as L5: one embedded viewer for all content types, with almost no work in base.ela.city.
• Keep the Option B ddrm-reader adapter in reserve, in case documents must keep the CEK off browsers.
• Do not do Option C.
• Longer term, Option A is the first capability of a general interop surface: an external principal, a Runtime-origin frame and typed Runtime operations. Mint or buy from other apps can be added later, after a security review. The seed is only the first host.

Open questions

• Which option do we adopt?
• Is the "external viewer" principal (a wallet delegation, not a Runtime sign-in) acceptable under PRINCIPLES §16 and the deferred "Mode B" wallet work?
• Custody release waits for Base finality (about 15 to 20 minutes after a buy). Is that acceptable for buy-then-open on base.ela.city?
• Which origins does the seed admit, and who maintains that list?