Embedding crosses a trust boundary. It needs a narrower claim than “the page can show another page.”
Frame and bridge in an interactive AUP Web session
This section describes the interactive AUP Web-session renderer. In that renderer, use frame for an isolated document context or controlled embed. A capability bridge at window.aup is available only when the frame is explicitly bridge-enabled, trusted, and same-origin. Third-party embeds should remain isolated by default; a bridge is not a general cross-origin SDK.
The Web Device document target is a different path. Its static frame output and Markdown content embeds do not establish a window.aup bridge, parent session, or general data/action access. Treat an embedded document frame as third-party content unless a separate interactive-session contract says otherwise.
Before enabling one, make the following decisions visible in review:
- Which exact origin is trusted?
- Which data path and actions are available to the embed?
- How are session lifetime, parent/child messages, and failure handled?
- What browser/device target actually passed the intended interaction?
Surface in an interactive AUP Web session
In the interactive AUP Web-session renderer, surface can render an AFS path or connect to a remote AUP endpoint. Nested-session behavior still depends on the runtime and connection context. Do not promise that any remote endpoint, cross-origin transport, or nested event flow will work merely because the surface node parses.
terminal is a distinct WebSocket terminal widget, not the AUP protocol itself. It therefore carries its own endpoint, authorization, and lifecycle review rather than inheriting a blanket AUP trust claim.
The first documentation edition has one direct document-target input example, but it does not use a frame, bridge, or surface. A full runtime demo still needs its own origin, least-privilege data scope, and browser acceptance before it belongs in a reference page.