Trusted reality compositor (TRC): OS-level per-frame receipt verification and fail-closed rendering and egress control for synthetic overlays
An operating-system overlay-control system obtains, for a synthetic overlay, a validation result produced by validating a Reality Receipt (R2) under a freshness policy relative to a current signed head of an append-only log, including verification of an origin signature, an inclusion proof, and append-only evolution on head advance. From the validation result, the system determines an egress-permit vector that enumerates downstream egress action identifiers and follow-on privilege identifiers and specifies permitted or denied states. Operating-system authorization gatepoints and privilege-control interfaces enforce fail-closed control so that requested downstream egress actions and follow-on privileges are allowed only when permitted by the egress-permit vector and otherwise are blocked, withheld, or refused with a Structured Precondition-Failure code. In some embodiments, capability tokens or device RUN_PERMITs are invalidated and require revalidation when the egress-permit vector, a policy version, or a deny-code registry digest changes.
1 . A computer-implemented system comprising:
(a) one or more processors;
(b) memory storing instructions that, when executed by the one or more processors, cause the system to:
(c) obtain, for a synthetic overlay, a validation result produced by validating a Reality Receipt (R2) associated with the synthetic overlay under a freshness policy relative to a current signed head of an append-only log, the validation result indicating whether the R2 satisfies the freshness policy and append-only evolution on head advance;
(d) determine, from the validation result and for the synthetic overlay, an egress-permit vector that, in machine-readable form, enumerates one or more downstream egress action identifiers and one or more follow-on privilege identifiers and specifies, for each enumerated identifier, a permitted state or a denied state;
(e) provide the egress-permit vector to one or more operating-system authorization gatepoints coupled to one or more downstream egress paths and to one or more privilege-control interfaces coupled to issuance, activation, or use of one or more follow-on privileges; and
(f) enforce, via the one or more operating-system authorization gatepoints and the one or more privilege-control interfaces, fail-closed control such that a requested downstream egress action or a requested follow-on privilege for the synthetic overlay is allowed only when permitted by the egress-permit vector and otherwise is blocked, withheld, or refused with a Structured Precondition-Failure code.
2 . The system of claim 1 , wherein the one or more downstream egress action identifiers comprise at least one of Share, Upload, Record/Capture, Clipboard export, or Drag-and-drop export.
3 . The system of claim 1 , wherein the one or more follow-on privilege identifiers comprise at least one of session enablement, egress permission, a capability token, or a device RUN_PERMIT.
4 . The system of claim 1 , wherein the egress-permit vector is represented as a machine-readable map or bitmask that, for each enumerated identifier, specifies the permitted state or the denied state and, for each denied state, at least one deny code.
5 . The system of claim 1 , wherein the Structured Precondition-Failure code includes, in machine-readable form, at least one deny code and an identifier of the requested downstream egress action or the requested follow-on privilege that is denied.
6 . The system of claim 1 , wherein the egress-permit vector enforces deny-by-default such that any downstream egress action or follow-on privilege not explicitly permitted by the egress-permit vector is treated as denied.
7 . The system of claim 6 , wherein, when a request specifies an identifier not present in the egress-permit vector, the system treats the identifier as denied and returns a Structured Precondition-Failure code including at least one of UNRECOGNIZED_ACTION or UNRECOGNIZED_PRIVILEGE.
8 . The system of claim 1 , wherein the one or more downstream egress paths comprise at least one of a cast path, a mirror path, a remote-composition path, a snapshot/export path, a Record/Capture path, or a Clipboard/Drag-and-drop path.
9 . The system of claim 1 , wherein the one or more privilege-control interfaces comprise at least one of a token issuance application programming interface (API), a session enablement interface, an egress-permission interface, or a device RUN_PERMIT control surface.
10 . A computer-implemented method for invalidating overlay-linked follow-on privileges, the method comprising:
(a) determining, for a synthetic overlay and from results of validating an associated Reality Receipt (R2), a current egress-permit vector;
(b) authorizing issuance, activation, or use of a capability token for the synthetic overlay, or authorizing a device RUN_PERMIT associated with the synthetic overlay, only when the current egress-permit vector permits the authorization;
(c) cryptographically binding the capability token to (i) an overlay identifier for the synthetic overlay and (ii) a vector digest computed over a canonical encoding of at least a permitted portion of the current egress-permit vector;
(d) detecting a change to at least one of (i) the current egress-permit vector for the synthetic overlay, (ii) a policy version identifier applied in determining the current egress-permit vector, or (iii) a deny-code registry digest used in selecting deny codes; and
(e) responsive to the change, via at least one privilege-control interface, revoking or disabling the capability token or the device RUN_PERMIT and denying subsequent issuance, activation, or use of the capability token or the device RUN_PERMIT unless revalidation is performed.
11 . The method of claim 10 , wherein the capability token has a least-privilege scope and a temporal validity.
12 . The method of claim 10 , further comprising refusing issuance, activation, or use of the capability token when the vector digest does not match a current permitted egress-permit vector for the synthetic overlay.
13 . The method of claim 10 , wherein the at least one privilege-control interface comprises at least one of a token issuance application programming interface (API), a session enablement interface, an egress-permission interface, or a device RUN_PERMIT control surface.
14 . The method of claim 10 , wherein the at least one privilege-control interface further controls at least one of session enablement or egress permission as an additional follow-on privilege for the synthetic overlay.
15 . The method of claim 10 , wherein revalidation requires freshness to a current signed head and append-only evolution on head advance, together with anti-replay and predicate checks.
16 . The method of claim 10 , wherein revoking or disabling comprises revoking or disabling a previously issued capability token or device RUN_PERMIT for the synthetic overlay.
17 . The method of claim 10 , further comprising, when subsequent issuance, activation, or use of the capability token or the device RUN_PERMIT is denied, returning a Structured Precondition-Failure code that includes at least one deny code and an identifier of the denied privilege.
18 . A non-transitory computer-readable medium storing instructions that, when executed by one or more processors of a device having one or more operating-system authorization gatepoints and one or more privilege-control interfaces, cause the device to:
(a) combine at least two policy sources under a deny-precedence rule to determine, for each of one or more downstream egress action identifiers and one or more follow-on privilege identifiers for a synthetic overlay, a permitted state or a denied state in an egress-permit vector;
(b) for each denied identifier, select a controlling policy source identifier corresponding to a highest-precedence policy source among the at least two policy sources that produced a denial for the denied identifier;
(c) select at least one deny code from a deny-code registry having a registry digest computed over a canonical encoding of the deny-code registry;
(d) return, for the denied identifier, a Structured Precondition-Failure code that includes the at least one deny code, the denied identifier, the controlling policy source identifier, and the registry digest; and
(e) cause a requested downstream egress action or requested follow-on privilege corresponding to the denied identifier to fail closed at the one or more operating-system authorization gatepoints or the one or more privilege-control interfaces.
19 . The non-transitory computer-readable medium of claim 18 , wherein the deny-precedence rule treats a denial from any one of the at least two policy sources as a denial for a corresponding identifier in the egress-permit vector.
20 . The non-transitory computer-readable medium of claim 18 , wherein the at least two policy sources are associated with a per-action precedence order.
21 . The non-transitory computer-readable medium of claim 18 , wherein the egress-permit vector is represented as a machine-readable map or bitmask and, for each denied identifier, includes at least one deny code.
22 . The non-transitory computer-readable medium of claim 18 , wherein the egress-permit vector enforces deny-by-default such that any identifier not explicitly permitted is treated as denied, including when a request specifies an identifier not present in the egress-permit vector.
23 . The non-transitory computer-readable medium of claim 22 , wherein the Structured Precondition-Failure code includes at least one of UNRECOGNIZED_ACTION or UNRECOGNIZED_PRIVILEGE when the request specifies the identifier not present in the egress-permit vector.
24 . The non-transitory computer-readable medium of claim 18 , wherein the at least two policy sources comprise at least one policy pack identified by at least one of policy pack id, policy version, or policy sig, and at least one policy module identified by at least one of policy plugin id, plugin hash, or plugin sig.
25 . The non-transitory computer-readable medium of claim 18 , wherein the device preserves unknown codes for forward compatibility and logs conflicts among vendor-extended deny codes as signed conflict records.