Network Working Group S. Das Internet-Draft Independent Inventor Intended status: Informational 27 August 2026 Expires: 28 February 2027 Preventing Unauthorized Adult and Age-Restricted Content Rendering to Children Through Hardware-Rooted Execution Finality draft-das-child-safe-rendering-finality-01 Abstract Online child-safety controls commonly operate before the final rendering boundary. Platforms may use account-age flags, parental settings, content labels, recommender controls, server-side classification, age-assurance systems, access policies, or application filters to decide whether adult or age-restricted content should be available to a user. Those controls are important, but an upstream decision does not by itself guarantee that the content cannot later be decrypted, decoded, composited, rendered, forwarded, mirrored, or otherwise materialized through another software or device path. This problem is becoming more important as content delivery becomes more distributed, encrypted, AI-mediated, personalized, and dynamically generated. A modern device may receive content through applications, browsers, content-delivery networks, embedded web views, messaging clients, recommendation systems, generative-AI services, caches, cloud gaming or streaming pipelines, local AI models, or third-party SDKs. The security question is therefore no longer only whether content was classified or whether an age check occurred upstream. A later question must also be answered: is this specific protected content authorized to become perceptible to this recipient, on this device, under the current eligibility, policy, and revocation state, at this moment? This document defines a protected rendering execution-finality architecture for adult, pornographic, sexually explicit, violent, gambling-related, or otherwise age-restricted content. A proposed rendering is represented as a Restricted Content Candidate Act and remains in a Non-Renderable State until a Protected Enforcement Domain validates the applicable recipient, content, device, policy, age-or-eligibility, freshness, revocation, and sink predicates. Protected validation evidence is committed before, or atomically with, release of scoped non-bearer Rendering Finality Authority. Das Expires 28 February 2027 [Page 1] Internet-Draft Child-Safe Rendering Finality August 2026 A Protected Rendering Finality Sink independently verifies that authority immediately before the content becomes perceptible. Depending on the implementation, the sink may control content-key release, decryption, media-decoder enablement, GPU or compositor access, protected-surface creation, audio output, casting, screen mirroring, display enablement, or an equivalent materialization boundary. Content bytes may therefore be delivered to a device while remaining technically non-renderable. The architecture deliberately does not define a universal age- estimation algorithm, identity system, or content-classification scheme. Those mechanisms may supply inputs to the Protected Enforcement Domain. This document defines the consequence-control step that prevents an upstream policy result from becoming merely advisory at the point of rendering. UNICEF has warned that pornographic content can harm children and that digital restrictions have not kept pace with technological shifts. The ITU Child Online Protection programme provides global guidance for safer digital environments, and the United Nations Committee on the Rights of the Child has called for protection of children from harmful content and online risks in the digital environment. The European Commission has likewise adopted protection-of-minors guidance and a privacy-preserving age- verification approach for adult-restricted content. These materials motivate the problem addressed here; they do not endorse this particular technical architecture. The central protocol principle is: permission to deliver content is not permission to render it. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 28 February 2027. Das Expires 28 February 2027 [Page 2] Internet-Draft Child-Safe Rendering Finality August 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Why This Is Required Now . . . . . . . . . . . . . . . . . . 5 3. International Child-Safety Motivation . . . . . . . . . . . . 5 4. Core Security Distinction . . . . . . . . . . . . . . . . . . 6 5. Threat and Failure Model . . . . . . . . . . . . . . . . . . 6 6. Dual-Boundary Architecture . . . . . . . . . . . . . . . . . 7 7. Restricted Content Candidate Act . . . . . . . . . . . . . . 9 8. JSON Interoperability Profile . . . . . . . . . . . . . . . . 9 9. RestrictedContentCandidate JSON Schema . . . . . . . . . . . 9 10. RenderingPolicyDecision JSON Schema . . . . . . . . . . . . . 16 11. RenderingFinalityAuthority JSON Schema . . . . . . . . . . . 18 12. RenderSinkVerify Request JSON Schema . . . . . . . . . . . . 20 13. Protected Enforcement Domain Validation . . . . . . . . . . . 22 14. Protected Validation Evidence . . . . . . . . . . . . . . . . 22 15. Rendering Finality Authority . . . . . . . . . . . . . . . . 22 16. Where Enforcement Occurs . . . . . . . . . . . . . . . . . . 23 17. Content-Key and Decryption Enforcement . . . . . . . . . . . 23 18. Decoder, GPU and Compositor Enforcement . . . . . . . . . . . 23 19. Audio, Casting, Mirroring and Secondary Outputs . . . . . . . 24 20. Complete Allow Transaction Example . . . . . . . . . . . . . 24 21. Complete Denial Transaction Example . . . . . . . . . . . . . 26 22. Fail-Closed Requirements . . . . . . . . . . . . . . . . . . 27 23. Replay, Revocation and State Changes . . . . . . . . . . . . 28 24. Generated and AI-Transformed Content . . . . . . . . . . . . 28 25. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 26. Security Considerations . . . . . . . . . . . . . . . . . . . 29 27. Interoperability with Existing Age-Assurance and Platform Systems . . . . . . . . . . . . . . . . . . . . . . . . . 29 28. Frequently Asked Questions . . . . . . . . . . . . . . . . . 29 28.1. FAQ 1 — How can Execution-Finality protect children without creating continuous surveillance? . . . . . . . 29 Das Expires 28 February 2027 [Page 3] Internet-Draft Child-Safe Rendering Finality August 2026 28.2. FAQ 2 — Does this require Apple, Google, Microsoft, NVIDIA, AMD, Qualcomm, or other vendors to redesign their hardware? . . . . . . . . . . . . . . . . . . . . . . . 31 28.3. FAQ 3 — Won’t cryptographic enforcement make video, gaming, and AI rendering slow or battery-intensive? . . 32 28.4. FAQ 4 — Who issues and validates age credentials? . . . 33 28.5. FAQ 5 — Can VPNs, proxies, or alternative rendering paths bypass it? . . . . . . . . . . . . . . . . . . . . . . 34 28.6. FAQ 6 — What happens when AI transforms restricted content? . . . . . . . . . . . . . . . . . . . . . . . 35 28.7. FAQ 7 — How are Finality Leases protected against theft and replay? . . . . . . . . . . . . . . . . . . . . . . 36 28.8. FAQ 8 — What happens if the operating system or application is compromised? . . . . . . . . . . . . . . 37 28.9. FAQ 9 — Who controls the content policy? . . . . . . . . 38 28.10. FAQ 10 — Can governments or platforms abuse the mechanism for censorship? . . . . . . . . . . . . . . . . . . . . 39 28.11. FAQ 11 — How does it work offline or during authorization-service outages? . . . . . . . . . . . . 40 28.12. Central Architecture and Five Core Rules . . . . . . . . 40 29. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 30. Intellectual Property Considerations . . . . . . . . . . . . 42 31. Informative References . . . . . . . . . . . . . . . . . . . 42 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction Child-safety systems frequently make policy decisions far from the point at which content becomes visible or audible. A server may classify content as adult-only. An account system may determine that a user is under an applicable age threshold. A parental-control service may deny a content category. A platform may enforce a regional policy. Yet the media pipeline may contain many later components: encrypted transport, local cache, decoder, GPU, compositor, protected surface, display controller, speaker path, casting interface, or screen-mirroring function. The execution-finality model treats the final materialization of restricted content as a separate consequence. The relevant security property is not merely that a policy engine produced DENY. The property is that the protected content cannot become perceptible unless the final rendering boundary verifies current, act-specific authority. Das Expires 28 February 2027 [Page 4] Internet-Draft Child-Safe Rendering Finality August 2026 The narrow scope of this document is adult and age-restricted content rendering. It does not attempt to standardize child identity, parental consent, age estimation, content moderation, recommender algorithms, or the legal definition of harmful content across jurisdictions. 2. Why This Is Required Now The technical need has intensified because content is no longer delivered through a single predictable application path. Streaming platforms, browsers, encrypted media pipelines, social applications, short-video feeds, generative AI, multimodal assistants, local models, cloud rendering, game engines, mixed-reality systems, and third-party SDKs can all participate in content selection and materialization. AI also changes the scale and dynamism of the problem. A system can generate or transform sexually explicit or otherwise adult material on demand, select content based on inferred interests, synthesize new variants that were never pre-classified as static files, or route a user through multiple content sources. An upstream catalogue label alone is therefore less reliable as the sole technical enforcement point. This document does not assert that child-safety controls were unnecessary in earlier Internet systems. The narrower claim is that modern content stacks create more paths between upstream policy and final perception, increasing the value of an independently verified rendering boundary. 3. International Child-Safety Motivation UNICEF states that pornographic content can harm children and has expressed concern about the large quantity of pornography that is easily accessible online. UNICEF has also stated that efforts to restrict children's access in digital environments have not kept pace with technological shifts. The ITU Child Online Protection initiative provides policy-maker, educator, industry, parent, and child-focused guidance intended to support safer digital environments for children. Its current child online protection work emphasizes child-centred and rights-based protection mechanisms. The United Nations Committee on the Rights of the Child, in General Comment No. 25 (2021), treats the digital environment as encompassing networks, content, services, applications, connected devices, artificial intelligence, robotics, automated systems, algorithms, and Das Expires 28 February 2027 [Page 5] Internet-Draft Child-Safe Rendering Finality August 2026 data analytics. The Committee has repeatedly recommended protecting children from harmful content and online risks while respecting their rights and privacy. The European Commission's protection-of-minors guidance under the Digital Services Act addresses harmful content and recommends effective age-assurance measures for adult content such as pornography. The Commission's age-verification approach is designed to let a user prove that an applicable age threshold is met without unnecessarily revealing identity or exact age. These sources provide policy and risk context only. They do not define, require, or endorse the execution-finality mechanism specified in this document. 4. Core Security Distinction The central distinction is: CONTENT DELIVERY != CONTENT RENDERING AUTHORITY AGE CHECK != DISPLAY FINALITY CONTENT CLASSIFICATION != DECRYPTION AUTHORITY SERVER-SIDE ALLOW != DEVICE-SIDE MATERIALIZATION AUTHORITY Figure 1 5. Threat and Failure Model A restricted-content system may fail even when an upstream classification or eligibility decision was correct. Examples include stale age state, revoked parental policy, cache replay, alternate application paths, direct decoder access, a compromised application, a malicious embedded SDK, casting or mirroring, a stale decryption key, sink substitution, modified content metadata, or a generated- content path that bypasses the original classifier. Das Expires 28 February 2027 [Page 6] Internet-Draft Child-Safe Rendering Finality August 2026 A conforming deployment therefore assumes that ordinary application- layer software may be buggy, compromised, overly permissive, or unable to enforce the last consequence boundary by itself. 6. Dual-Boundary Architecture A deployment MAY use two execution-finality boundaries. The first boundary governs DELIVERY: whether protected content may be transported to or retained within a device or protected environment. The second boundary governs RENDERING: whether that content may become visible, audible, cast, mirrored, decrypted into a usable representation, or otherwise perceptible. The second boundary is the critical boundary defined by this draft. Content received after successful delivery remains non-renderable until a current Rendering Finality Authority is independently verified. Das Expires 28 February 2027 [Page 7] Internet-Draft Child-Safe Rendering Finality August 2026 Restricted Content | v Encrypted / Protected Candidate Payload | v Delivery Policy / Delivery PED | v Delivery Finality Authority | v Device Receives Protected Payload | v STILL NON-RENDERABLE | v Device-Side Protected Enforcement Domain | +-- recipient / eligibility state +-- content class +-- parental / regulatory policy +-- device and session state +-- policy / revocation epoch +-- nonce / freshness +-- intended rendering sink | v Protected Validation Evidence | v Scoped Non-Bearer Rendering Finality Authority | v PROTECTED RENDERING FINALITY SINK | +-- PASS -> permitted rendering | `-- FAIL -> remain non-renderable Figure 2 Das Expires 28 February 2027 [Page 8] Internet-Draft Child-Safe Rendering Finality August 2026 7. Restricted Content Candidate Act A Restricted Content Candidate Act represents a proposed materialization of age-restricted content. It may describe a video frame sequence, image, audio stream, interactive scene, generated media object, XR scene, game asset, webpage media object, or another protected representation. The Candidate Act MUST remain non-renderable while required execution-finality validation is incomplete. 8. JSON Interoperability Profile This revision defines a JSON-based interoperability profile so that implementations can evaluate a concrete contract rather than only an abstract policy model. JSON objects MUST be encoded as UTF-8. Implementations MUST reject unknown load-bearing fields when the active schema declares additionalProperties=false. The JSON profile does not require HTTP as the transport. The objects may be carried over a local protected IPC mechanism, an operating- system service boundary, a trusted application-to-enclave channel, a platform API, or another authenticated transport. A future revision may define a media type or explicit transport binding. 9. RestrictedContentCandidate JSON Schema { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "urn:ietf:params:json-schema:child-rendering-candidate:00", "title": "RestrictedContentCandidate", "type": "object", "additionalProperties": false, "required": [ "version", "candidate_act_id", "act_type", "content", "recipient_context", "policy_context", "render_request", "freshness", "finality_sink" ], "properties": { "version": { "type": "string", "const": "1.0" Das Expires 28 February 2027 [Page 9] Internet-Draft Child-Safe Rendering Finality August 2026 }, "candidate_act_id": { "type": "string", "minLength": 16, "maxLength": 128 }, "act_type": { "type": "string", "enum": [ "RENDER_VIDEO", "RENDER_IMAGE", "PLAY_AUDIO", "RENDER_INTERACTIVE", "RENDER_GENERATED_MEDIA", "CAST_PROTECTED_CONTENT", "MIRROR_PROTECTED_CONTENT" ] }, "content": { "type": "object", "additionalProperties": false, "required": [ "content_id", "content_digest", "content_class", "classification_source", "protection_state" ], "properties": { "content_id": { "type": "string", "maxLength": 256 }, "content_digest": { "type": "string", "pattern": "^sha256:[0-9a-fA-F]{64}$" }, "content_class": { "type": "string", "enum": [ "ADULT_SEXUAL_CONTENT", "SEXUALLY_EXPLICIT_CONTENT", "AGE_RESTRICTED_VIDEO", "AGE_RESTRICTED_AUDIO", "AGE_RESTRICTED_INTERACTIVE", "AGE_RESTRICTED_GENERATED_MEDIA", "OTHER_RESTRICTED" ] Das Expires 28 February 2027 [Page 10] Internet-Draft Child-Safe Rendering Finality August 2026 }, "classification_source": { "type": "string", "maxLength": 256 }, "classification_confidence": { "type": "number", "minimum": 0, "maximum": 1 }, "protection_state": { "type": "string", "enum": [ "ENCRYPTED", "KEY_WITHHELD", "PROTECTED_SURFACE_ONLY", "NON_RENDERABLE_BUFFER", "OTHER_PROTECTED" ] }, "origin_service": { "type": "string", "maxLength": 256 }, "generation_model_id": { "type": [ "string", "null" ], "maxLength": 256 } } }, "recipient_context": { "type": "object", "additionalProperties": false, "required": [ "recipient_context_id", "eligibility_state", "eligibility_evidence_ref" ], "properties": { "recipient_context_id": { "type": "string", "maxLength": 256 }, "eligibility_state": { "type": "string", Das Expires 28 February 2027 [Page 11] Internet-Draft Child-Safe Rendering Finality August 2026 "enum": [ "ELIGIBLE", "NOT_ELIGIBLE", "UNKNOWN", "EXPIRED", "REVOKED" ] }, "eligibility_evidence_ref": { "type": "string", "maxLength": 512 }, "age_threshold_claim": { "type": [ "string", "null" ], "enum": [ "OVER_18", "OVER_LOCAL_THRESHOLD", null ] }, "parental_policy_ref": { "type": [ "string", "null" ], "maxLength": 512 }, "privacy_preserving_proof": { "type": "boolean" } } }, "policy_context": { "type": "object", "additionalProperties": false, "required": [ "jurisdiction", "policy_id", "policy_epoch", "revocation_epoch" ], "properties": { "jurisdiction": { "type": "string", "maxLength": 64 Das Expires 28 February 2027 [Page 12] Internet-Draft Child-Safe Rendering Finality August 2026 }, "policy_id": { "type": "string", "maxLength": 256 }, "policy_epoch": { "type": "integer", "minimum": 0 }, "revocation_epoch": { "type": "integer", "minimum": 0 }, "parental_control_state": { "type": "string", "enum": [ "ALLOW", "DENY", "NOT_APPLICABLE", "UNKNOWN" ] }, "platform_policy_state": { "type": "string", "enum": [ "ALLOW", "DENY", "REVIEW", "UNKNOWN" ] } } }, "render_request": { "type": "object", "additionalProperties": false, "required": [ "device_id", "application_id", "render_mode", "output_targets" ], "properties": { "device_id": { "type": "string", "maxLength": 256 }, "application_id": { Das Expires 28 February 2027 [Page 13] Internet-Draft Child-Safe Rendering Finality August 2026 "type": "string", "maxLength": 256 }, "component_id": { "type": [ "string", "null" ], "maxLength": 256 }, "render_mode": { "type": "string", "enum": [ "LOCAL_DISPLAY", "LOCAL_AUDIO", "XR_DISPLAY", "CAST", "MIRROR", "REMOTE_DISPLAY" ] }, "output_targets": { "type": "array", "minItems": 1, "items": { "type": "string", "enum": [ "DISPLAY", "SPEAKER", "HEADSET", "XR_COMPOSITOR", "CAST_SINK", "MIRROR_SINK" ] } }, "requested_resolution": { "type": [ "string", "null" ], "maxLength": 64 }, "requested_audio": { "type": "boolean" }, "requested_decryption": { "type": "boolean" Das Expires 28 February 2027 [Page 14] Internet-Draft Child-Safe Rendering Finality August 2026 } } }, "freshness": { "type": "object", "additionalProperties": false, "required": [ "nonce", "created_at", "expires_at" ], "properties": { "nonce": { "type": "string", "minLength": 16, "maxLength": 256 }, "created_at": { "type": "string", "format": "date-time" }, "expires_at": { "type": "string", "format": "date-time" }, "session_id": { "type": [ "string", "null" ], "maxLength": 256 } } }, "finality_sink": { "type": "object", "additionalProperties": false, "required": [ "sink_id", "sink_type" ], "properties": { "sink_id": { "type": "string", "maxLength": 256 }, "sink_type": { "type": "string", Das Expires 28 February 2027 [Page 15] Internet-Draft Child-Safe Rendering Finality August 2026 "enum": [ "CONTENT_KEY_RELEASE", "DECRYPTION_GATE", "MEDIA_DECODER_GATE", "GPU_COMPOSITOR_GATE", "PROTECTED_SURFACE_GATE", "DISPLAY_ENABLE_GATE", "AUDIO_OUTPUT_GATE", "CAST_GATE", "MIRROR_GATE" ] }, "attestation_ref": { "type": [ "string", "null" ], "maxLength": 512 } } } } } Figure 3 10. RenderingPolicyDecision JSON Schema { "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "RenderingPolicyDecision", "type": "object", "additionalProperties": false, "required": [ "candidate_act_id", "decision", "decision_id", "validated_policy_epoch", "validated_revocation_epoch", "permitted_effects", "denial_reasons" ], "properties": { "candidate_act_id": { "type": "string" }, "decision": { "type": "string", Das Expires 28 February 2027 [Page 16] Internet-Draft Child-Safe Rendering Finality August 2026 "enum": [ "ALLOW_RENDER", "DENY_RENDER", "ALLOW_RESTRICTED_MODE", "REQUIRE_REVALIDATION" ] }, "decision_id": { "type": "string" }, "validated_policy_epoch": { "type": "integer", "minimum": 0 }, "validated_revocation_epoch": { "type": "integer", "minimum": 0 }, "permitted_effects": { "type": "array", "items": { "type": "string", "enum": [ "RELEASE_CONTENT_KEY", "DECRYPT", "DECODE", "CREATE_PROTECTED_SURFACE", "COMPOSITE", "DISPLAY", "PLAY_AUDIO", "CAST", "MIRROR" ] } }, "denial_reasons": { "type": "array", "items": { "type": "string", "enum": [ "RECIPIENT_NOT_ELIGIBLE", "ELIGIBILITY_UNKNOWN", "ELIGIBILITY_EXPIRED", "PARENTAL_POLICY_DENY", "PLATFORM_POLICY_DENY", "CONTENT_CLASS_MISMATCH", "POLICY_EPOCH_STALE", "REVOCATION_EPOCH_STALE", Das Expires 28 February 2027 [Page 17] Internet-Draft Child-Safe Rendering Finality August 2026 "NONCE_REPLAY", "DEVICE_MISMATCH", "APPLICATION_MISMATCH", "SINK_MISMATCH", "OUTPUT_TARGET_NOT_PERMITTED", "ATTESTATION_FAILURE", "AUTHORITY_EXPIRED" ] } }, "validation_evidence_ref": { "type": "string" }, "decision_expires_at": { "type": "string", "format": "date-time" } } } Figure 4 11. RenderingFinalityAuthority JSON Schema { "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "RenderingFinalityAuthority", "type": "object", "additionalProperties": false, "required": [ "authority_id", "candidate_act_id", "candidate_digest", "validation_evidence_ref", "permitted_effects", "sink_id", "policy_epoch", "revocation_epoch", "nonce", "issued_at", "expires_at", "consumption" ], "properties": { "authority_id": { "type": "string" }, "candidate_act_id": { Das Expires 28 February 2027 [Page 18] Internet-Draft Child-Safe Rendering Finality August 2026 "type": "string" }, "candidate_digest": { "type": "string", "pattern": "^sha256:[0-9a-fA-F]{64}$" }, "validation_evidence_ref": { "type": "string" }, "permitted_effects": { "type": "array", "minItems": 1, "items": { "type": "string" } }, "content_digest": { "type": "string", "pattern": "^sha256:[0-9a-fA-F]{64}$" }, "recipient_context_id": { "type": "string" }, "device_id": { "type": "string" }, "application_id": { "type": "string" }, "sink_id": { "type": "string" }, "sink_type": { "type": "string" }, "policy_epoch": { "type": "integer" }, "revocation_epoch": { "type": "integer" }, "nonce": { "type": "string" }, "issued_at": { "type": "string", "format": "date-time" }, Das Expires 28 February 2027 [Page 19] Internet-Draft Child-Safe Rendering Finality August 2026 "expires_at": { "type": "string", "format": "date-time" }, "consumption": { "type": "string", "enum": [ "SINGLE_USE", "FRAME_WINDOW", "SESSION_BOUND" ] }, "max_frame_count": { "type": [ "integer", "null" ], "minimum": 1 }, "max_duration_ms": { "type": [ "integer", "null" ], "minimum": 1 }, "signature_or_mac": { "type": "string" } } } Figure 5 12. RenderSinkVerify Request JSON Schema { "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "RenderSinkVerifyRequest", "type": "object", "additionalProperties": false, "required": [ "candidate", "authority", "sink_runtime_state" ], "properties": { "candidate": { Das Expires 28 February 2027 [Page 20] Internet-Draft Child-Safe Rendering Finality August 2026 "$ref": "urn:ietf:params:json-schema:child-rendering-candidate:00" }, "authority": { "type": "object" }, "sink_runtime_state": { "type": "object", "additionalProperties": false, "required": [ "sink_id", "current_policy_epoch", "current_revocation_epoch", "authority_consumed", "device_attestation_state", "output_path" ], "properties": { "sink_id": { "type": "string" }, "current_policy_epoch": { "type": "integer" }, "current_revocation_epoch": { "type": "integer" }, "authority_consumed": { "type": "boolean" }, "device_attestation_state": { "type": "string", "enum": [ "VALID", "INVALID", "UNKNOWN" ] }, "output_path": { "type": "string", "enum": [ "DISPLAY", "AUDIO", "XR", "CAST", "MIRROR" ] }, "screen_capture_active": { Das Expires 28 February 2027 [Page 21] Internet-Draft Child-Safe Rendering Finality August 2026 "type": "boolean" }, "external_display_attached": { "type": "boolean" } } } } } Figure 6 13. Protected Enforcement Domain Validation The Protected Enforcement Domain (PED) MUST evaluate all predicates required by the applicable deployment before releasing Rendering Finality Authority. Typical predicates include recipient eligibility, age-threshold evidence, parental policy, content classification, content digest, jurisdiction, platform policy, device identity, application identity, requested output mode, output target, current policy epoch, current revocation epoch, nonce freshness, device attestation, and intended Finality Sink identity. A successful upstream age check MUST NOT itself cause decryption or display. PED validation success authorizes creation of scoped finality authority; it does not complete the rendering consequence. 14. Protected Validation Evidence Before, or atomically with, Rendering Finality Authority issuance, the PED MUST commit protected validation evidence. The evidence MAY be represented by a protected signed record, MAC, enclave or HSM assertion, sealed state, monotonic-state commitment, append-only protected record, or equivalent protected mechanism. A Boolean ALLOW value by itself is not sufficient finality authority. 15. Rendering Finality Authority Rendering Finality Authority MUST be act-bound, content-bound, recipient-bound, device-bound, application-bound where applicable, policy-epoch-bound, revocation-epoch-bound, nonce/freshness-bound, effect-bound, and sink-bound. Possession alone MUST NOT be sufficient. The authority is non-bearer because the Finality Sink independently verifies the protected bindings before enabling the permitted materialization effects. Das Expires 28 February 2027 [Page 22] Internet-Draft Child-Safe Rendering Finality August 2026 An authority for DISPLAY MUST NOT automatically authorize CAST or MIRROR. An authority for one device MUST NOT automatically authorize another device. An authority for one content digest MUST NOT authorize modified or substituted content. 16. Where Enforcement Occurs The most important deployment question is where the final technical gate is placed. The gate SHOULD control the first boundary at which the protected content becomes perceptible or can be trivially converted into a perceptible representation. Possible Protected Rendering Finality Sinks include content-key release, decryption, media-decoder enablement, GPU command submission, protected-surface creation, compositor admission, display-plane enablement, audio-output enablement, XR compositor access, secure-video path enablement, casting, or screen mirroring. A server-side policy endpoint alone is not a Protected Rendering Finality Sink unless bypassing it also makes the protected rendering technically impossible. 17. Content-Key and Decryption Enforcement Where encrypted or otherwise protected media is used, withholding the usable content key is a strong enforcement point. The key-release component MAY act as the Finality Sink or as one element of a chained finality path. If validation fails, the usable key MUST NOT be released into an unprotected application context. If a key was previously released under a bounded authority, its validity SHOULD be constrained by session, content, policy epoch, time, frame window, or equivalent protected state. 18. Decoder, GPU and Compositor Enforcement For media that is already locally encrypted or decoded inside a protected pipeline, the Finality Sink MAY be placed at a decoder, GPU, protected-surface, or compositor boundary. The implementation MUST prevent ordinary application code from converting a denied Candidate Act into a visible frame through an alternate unprotected surface. Protected rendering MAY therefore require that decoded frames remain in protected memory or protected surfaces until the compositor verifies current finality authority. Das Expires 28 February 2027 [Page 23] Internet-Draft Child-Safe Rendering Finality August 2026 19. Audio, Casting, Mirroring and Secondary Outputs Adult or age-restricted content can be materialized through secondary paths even when a local display is controlled. Audio, HDMI or external displays, wireless casting, screen mirroring, remote-display APIs, accessibility capture paths, and similar outputs MAY therefore require separate consequence classes or sink-bound authority. A local-display authority MUST NOT be interpreted as universal authority for every secondary output. 20. Complete Allow Transaction Example The following example shows an adult-classified video that remains key-withheld until the device-side protected sink verifies current eligibility, policy, device, content, freshness, and output-path state. { "candidate": { "version": "1.0", "candidate_act_id": "rca-8f3d0d0d-20260826-000001", "act_type": "RENDER_VIDEO", "content": { "content_id": "asset-adult-99182", "content_digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", "content_class": "ADULT_SEXUAL_CONTENT", "classification_source": "platform-classifier-v7", "classification_confidence": 0.998, "protection_state": "KEY_WITHHELD", "origin_service": "media.example", "generation_model_id": null }, "recipient_context": { "recipient_context_id": "recipient-session-771", "eligibility_state": "ELIGIBLE", "eligibility_evidence_ref": "ageproof:opaque:44e2...", "age_threshold_claim": "OVER_18", "parental_policy_ref": null, "privacy_preserving_proof": true }, "policy_context": { "jurisdiction": "EU", "policy_id": "adult-content-policy-eu-v4", "policy_epoch": 412, "revocation_epoch": 39, "parental_control_state": "NOT_APPLICABLE", "platform_policy_state": "ALLOW" Das Expires 28 February 2027 [Page 24] Internet-Draft Child-Safe Rendering Finality August 2026 }, "render_request": { "device_id": "device-3dd18", "application_id": "app.media.client", "component_id": "protected-player", "render_mode": "LOCAL_DISPLAY", "output_targets": [ "DISPLAY", "SPEAKER" ], "requested_resolution": "1080p", "requested_audio": true, "requested_decryption": true }, "freshness": { "nonce": "f9014acbe771440ab5208751", "created_at": "2026-08-26T17:35:00Z", "expires_at": "2026-08-26T17:35:30Z", "session_id": "sess-fb211" }, "finality_sink": { "sink_id": "render-sink-secure-compositor-01", "sink_type": "GPU_COMPOSITOR_GATE", "attestation_ref": "attest:device-3dd18:epoch-88" } }, "authority": { "authority_id": "rfa-d48d7f", "candidate_act_id": "rca-8f3d0d0d-20260826-000001", "candidate_digest": "sha256:bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb", "validation_evidence_ref": "pve:9f1172", "permitted_effects": [ "RELEASE_CONTENT_KEY", "DECRYPT", "DECODE", "CREATE_PROTECTED_SURFACE", "COMPOSITE", "DISPLAY", "PLAY_AUDIO" ], "content_digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", "recipient_context_id": "recipient-session-771", "device_id": "device-3dd18", "application_id": "app.media.client", "sink_id": "render-sink-secure-compositor-01", "sink_type": "GPU_COMPOSITOR_GATE", "policy_epoch": 412, "revocation_epoch": 39, Das Expires 28 February 2027 [Page 25] Internet-Draft Child-Safe Rendering Finality August 2026 "nonce": "f9014acbe771440ab5208751", "issued_at": "2026-08-26T17:35:01Z", "expires_at": "2026-08-26T17:35:30Z", "consumption": "FRAME_WINDOW", "max_frame_count": 900, "max_duration_ms": 30000, "signature_or_mac": "base64url:protected-authenticator" }, "sink_runtime_state": { "sink_id": "render-sink-secure-compositor-01", "current_policy_epoch": 412, "current_revocation_epoch": 39, "authority_consumed": false, "device_attestation_state": "VALID", "output_path": "DISPLAY", "screen_capture_active": false, "external_display_attached": false } } Figure 7 21. Complete Denial Transaction Example The following example shows a denial where the recipient is not eligible and parental policy also denies rendering. The important result is not merely an error response: all materialization controls remain disabled. Das Expires 28 February 2027 [Page 26] Internet-Draft Child-Safe Rendering Finality August 2026 { "candidate_act_id": "rca-minor-session-223", "decision": "DENY_RENDER", "decision_id": "decision-99831", "validated_policy_epoch": 412, "validated_revocation_epoch": 39, "permitted_effects": [], "denial_reasons": [ "RECIPIENT_NOT_ELIGIBLE", "PARENTAL_POLICY_DENY" ], "validation_evidence_ref": "pve-deny:3882", "decision_expires_at": "2026-08-26T17:36:00Z", "sink_action": { "release_content_key": false, "decrypt": false, "decode": false, "create_protected_surface": false, "display": false, "play_audio": false, "cast": false, "mirror": false, "result": "CONTENT_REMAINS_NON_RENDERABLE" } } Figure 8 22. Fail-Closed Requirements If required authority is missing, malformed, expired, stale, replayed, revoked, consumed, content-mismatched, recipient- mismatched, device-mismatched, application-mismatched, policy- mismatched, output-mismatched, or sink-mismatched, the content MUST remain non-renderable. Failure MUST NOT be converted into a warning followed by display. Implementations MUST NOT use 'best effort' rendering for content subject to this protected finality profile when current authority cannot be established. Das Expires 28 February 2027 [Page 27] Internet-Draft Child-Safe Rendering Finality August 2026 23. Replay, Revocation and State Changes Eligibility and parental state may change after content is delivered. A device may also restore an old application snapshot or replay a previously valid rendering authority. The Finality Sink SHOULD therefore verify current policy and revocation epochs immediately before materialization and MUST enforce nonce or equivalent anti- replay state. An old authorization MUST NOT automatically override a later parental-control change, account-state change, legal-policy change, device revocation, or recipient eligibility change. 24. Generated and AI-Transformed Content Generative AI may create age-restricted media that has no stable catalogue identifier. The Candidate Act therefore supports content digests, generation-model identifiers, classification sources, and protected output state. A generated object SHOULD be bound to the classification and authority actually used for the attempted rendering. This draft does not define how AI-generated content is classified. It defines how a classification or policy decision can be made technically load-bearing at the rendering boundary. 25. Privacy Considerations Child-safety enforcement can itself create privacy risk if systems unnecessarily expose a child's identity, exact age, browsing history, or content choices. Implementations SHOULD minimize disclosure and MAY consume privacy-preserving eligibility proofs that state only whether the required threshold or policy condition is satisfied. The rendering sink generally needs the validated eligibility result and bindings necessary for effectuation; it does not necessarily need the user's civil identity or exact date of birth. Logs and validation evidence SHOULD avoid recording unnecessary content titles, URLs, identity attributes, or detailed viewing history where a digest, opaque identifier, or protected commitment is sufficient. Das Expires 28 February 2027 [Page 28] Internet-Draft Child-Safe Rendering Finality August 2026 26. Security Considerations Threats include compromised applications, forged age state, stale parental policy, replayed authorities, content substitution after classification, sink substitution, screen-capture bypass, casting bypass, unprotected decoder paths, key extraction, rollback of revocation state, and malicious SDKs. Implementations SHOULD place load-bearing checks within protected execution, trusted operating-system, hardware-backed, or equivalently isolated enforcement paths when the threat model includes compromise of ordinary application software. 27. Interoperability with Existing Age-Assurance and Platform Systems The execution-finality layer is designed to consume outcomes from existing systems rather than replace them. Inputs MAY come from privacy-preserving age verification, platform account state, parental-control systems, content classifiers, regulatory policy, trusted identity providers, device policy, or enterprise/family safety services. Those systems answer whether a condition is satisfied. The Finality Sink answers whether the specific protected rendering consequence may now occur. 28. Frequently Asked Questions 28.1. FAQ 1 — How can Execution-Finality protect children without creating continuous surveillance? The biggest challenge is determining whether the person receiving content is a child or an adult. A naive hardware-rendering gate could require continuous camera access, facial analysis, or age estimation. That would create serious privacy, security, and regulatory concerns. Execution-Finality should avoid continuous biometric surveillance altogether. Instead, the architecture separates age assurance from execution enforcement. A trusted age-assurance provider can establish only the minimum fact required, for example that the user belongs to an Under-18 or 18+ age class. A privacy-preserving credential, potentially using zero- knowledge techniques, can prove that condition without exposing the user’s name, date of birth, face, or other unnecessary personal information. Das Expires 28 February 2027 [Page 29] Internet-Draft Child-Safe Rendering Finality August 2026 Age Assurance | v Privacy-Preserving Credential | v Policy Decision | v Finality Lease | v Protected Rendering Sink Figure 9 The hardware does not need to know who the person is. It only needs to determine whether the current rendering operation possesses valid authority under the applicable policy. A short-lived Finality Lease can be issued for a particular device, session, policy, and rendering destination. The lease can be cryptographically bound to: * age category or eligibility class * device public key * content or policy classification * authorized rendering sink * policy version * expiration time * nonce * revocation information * the protected session This avoids creating a permanent adult token. Authorization can instead be temporary, scoped, revocable, and bound to an authenticated device or session. Das Expires 28 February 2027 [Page 30] Internet-Draft Child-Safe Rendering Finality August 2026 For a family device, the system can use explicit authorization transitions. An adult can authenticate and establish an authorized session; when the device is locked, handed over, or the authorization expires, the protected session terminates. A child subsequently using the device receives the applicable child policy. Most importantly, age determination occurs upstream while finality enforcement occurs downstream. The Finality Sink should not ask whether the person is 17 or 18. It should ask whether this rendering operation is currently authorized under the applicable policy. Design principle: age should be an authorization attribute, not a continuously monitored biometric state. 28.2. FAQ 2 — Does this require Apple, Google, Microsoft, NVIDIA, AMD, Qualcomm, or other vendors to redesign their hardware? No. That would be an unnecessarily difficult deployment model. Execution-Finality should not prescribe a particular GPU, operating system, processor, secure element, display controller, age-assurance provider, or content-classification implementation. The standards layer should define the protocol and security semantics of the finality boundary. Different platforms can implement that boundary differently. Apple could use secure hardware and a protected media pipeline; Android manufacturers could use trusted execution and their display stack; Windows could integrate with protected media and graphics infrastructure; smart TVs could use secure media pipelines; cloud- gaming platforms could enforce the boundary in protected streaming and rendering components. Content / Application | v Policy Engine | v Finality Authority | v OS Enforcement Point | v Protected Media / GPU Path | v Finality Sink Das Expires 28 February 2027 [Page 31] Internet-Draft Child-Safe Rendering Finality August 2026 Figure 10 The standards layer can define what constitutes valid execution authority and how that authority must be verified, including authorization evidence, cryptographic binding, content identity, policy identifiers, device or sink identity, freshness, expiry, revocation, replay protection, scope, and failure behavior. The physical implementation remains platform-specific. The adoption proposition is therefore not “build a completely new child-safety processor.” It is “provide a trustworthy enforcement boundary capable of validating standardized finality authority.” A staged deployment path can be: * Stage 1 — Software enforcement: browsers, applications, and operating systems implement the protocol. * Stage 2 — Trusted execution: authorization mechanisms move into secure OS or TEE components. * Stage 3 — Protected media paths: high-risk content is prevented from bypassing the trusted execution path. * Stage 4 — Hardware finality: new devices can place the final enforcement point inside protected media, GPU, compositor, display, audio, or XR pipelines. * Stage 5 — Ecosystem adoption: content providers, AI providers, browsers, app stores, and platforms use the standardized interface. The architecture is therefore hardware-rooted where hardware support exists, but protocol-defined and implementation-neutral at the standards layer. The interface is standardized; the implementation is not. 28.3. FAQ 3 — Won’t cryptographic enforcement make video, gaming, and AI rendering slow or battery-intensive? It would if every frame had to undergo a complete cryptographic authorization check. That should not be the design. At 120 Hz, a display can process 120 frames every second. Performing an expensive authorization operation on every frame would be inefficient. Execution-Finality should therefore use authorization epochs or Finality Leases. Das Expires 28 February 2027 [Page 32] Internet-Draft Child-Safe Rendering Finality August 2026 Authenticate | v Verify Policy | v Issue Finality Lease | v Protected Session | v Render Thousands of Frames Figure 11 For example, a 10-minute lease could authorize a particular protected session. Individual frames would not each need a new authorization transaction. The lease can be cryptographically bound to Device + Session + Content/Policy + Rendering Sink + Expiry + Nonce. Another finality check occurs when a meaningful security state changes, such as authorization expiry, device change, rendering-sink change, content-classification change, policy change, revocation, protected-session transfer, or a new high-risk content category. For a 30-minute cloud-gaming session at 120 Hz, the architecture does not perform 120 cryptographic authorization checks every second. A session can be authorized once for a bounded epoch and then render more than 200,000 frames under that protected session, subject to the lease and revalidation rules. The same principle applies to AI-generated content. An AI model can generate large numbers of candidate outputs without individually invoking the finality protocol. The protected effect boundary is the critical point. Architectural distinction: generation can be high-volume and computationally cheap; effectuation must be authoritative and policy- compliant. Performance principle: cryptographically protect authorization state transitions, not individual frames. 28.4. FAQ 4 — Who issues and validates age credentials? This should not be controlled by a single global authority. The architecture should support a federated age-assurance model. Das Expires 28 February 2027 [Page 33] Internet-Draft Child-Safe Rendering Finality August 2026 Possible credential issuers can include regulated age-assurance providers, identity providers, government-approved providers, platform-operated age-assurance services, and other trusted authorities accepted by the relying party. The important separation is: credential issuer is not necessarily the policy authority, and neither is necessarily the rendering authority. Age Provider | | “User satisfies 18+ condition” v Age Credential | v Policy Authority | | “18+ may access this content” v Finality Authority | | scoped authorization v Finality Sink Figure 12 The Finality Sink validates only the authorization evidence and bindings required for the protected effect. A credential or signature by itself is not execution authority. The executor must correlate the evidence with the exact action or effect and make the applicable authorization decision. A stronger privacy design uses attribute-based credentials rather than identity-heavy credentials. Instead of disclosing a person’s identity and exact date of birth, the credential can establish only that the authenticated subject satisfies the applicable age threshold. 28.5. FAQ 5 — Can VPNs, proxies, or alternative rendering paths bypass it? A network-level mechanism can be bypassed. A protected effect boundary is designed to address that weakness. A VPN can hide a network destination; a proxy can alter the request path; alternative DNS can bypass DNS filtering; and an AI model can transform content. None of those should automatically grant authority to cross the protected effect boundary. Das Expires 28 February 2027 [Page 34] Internet-Draft Child-Safe Rendering Finality August 2026 Untrusted Internet | VPN / Proxy / AI / Browser | v Candidate Content | v Policy Evaluation | v Finality Authority | v Finality Sink | v Pixels Figure 13 The important requirement is alternate-path closure. If an application can simply bypass the protected rendering path and directly access an unprotected display or output path, the architecture is incomplete. Every consequential rendering path that the deployment claims to protect should converge on an authenticated enforcement boundary. Depending on platform design, this may include the display compositor, protected media decoder, GPU pipeline, XR compositor, cloud-streaming client, secure display controller, audio path, cast path, or mirror path. The architecture does not claim to prevent physical capture. A person can photograph a screen with another camera. Execution- Finality protects the digital effect boundary, not physical reality. 28.6. FAQ 6 — What happens when AI transforms restricted content? This is a critical issue because a restriction tied only to an original URL or file identifier can disappear when an AI system creates a modified representation. Das Expires 28 February 2027 [Page 35] Internet-Draft Child-Safe Rendering Finality August 2026 Restricted Image | v AI Transformation | v New Representation | v Policy Re-evaluation / Authority Check | v Finality Sink Figure 14 The authorization should be associated not merely with a URL, but with the material content or effect being authorized. Conceptually, the finality decision can bind the original content digest, relevant transformation lineage, final content digest, policy, age or eligibility class, and destination sink. The system does not necessarily need to understand every transformation semantically. Low-risk transformations such as resizing may preserve an existing authorization where policy permits, while higher-risk generative modification can require a new policy evaluation and new authority. Key rule: transformation does not automatically create new authority. An AI model can generate something new, but generation itself does not make that output authorized. Computation is not authority. 28.7. FAQ 7 — How are Finality Leases protected against theft and replay? A Finality Lease should not be a simple bearer token. It should be cryptographically bound to the conditions under which it was issued. A lease can include or bind: * lease identifier * device public key * session identifier * content or policy digest Das Expires 28 February 2027 [Page 36] Internet-Draft Child-Safe Rendering Finality August 2026 * authorized sink identifier * policy epoch * revocation epoch * expiration * nonce * permitted effect scope The sink verifies the required bindings. Stealing the lease therefore does not automatically allow an attacker to use it on another device, sink, session, content item, policy epoch, or output path. Replay resistance can use unique nonces, expiration, session binding, device-key binding, sink binding, policy epochs, atomic consumption where appropriate, and revocation or status checks. Particularly sensitive operations can use single-use authority. A crucial distinction is that freshness is not the same as authorization. A fresh lease can still be revoked or outside the permitted policy. A valid signature proves integrity or control of a key; it does not by itself prove that the protected effect is authorized. 28.8. FAQ 8 — What happens if the operating system or application is compromised? The answer depends on the assurance profile. If everything is controlled only by ordinary software and the operating system is malicious, an attacker may bypass a software-only enforcement mechanism. For higher-assurance child-safety enforcement, the protected path can be structured as: Das Expires 28 February 2027 [Page 37] Internet-Draft Child-Safe Rendering Finality August 2026 Application | v Operating System | v Trusted Execution / Protected Service | v Protected Rendering Path | v Hardware-Rooted Finality Sink Figure 15 The application can be compromised without automatically gaining finality authority. Stronger protection can use secure boot, hardware-backed keys, trusted execution environments, authenticated OS components, protected media paths, authenticated display or compositor paths, and hardware-enforced access controls. No architecture should claim complete protection if an attacker has unrestricted control of the hardware. The standard can therefore define assurance profiles such as Software Finality, OS/TEE Finality, and Hardware Rendering Finality, allowing progressive deployment with explicit security expectations. 28.9. FAQ 9 — Who controls the content policy? The Execution-Finality protocol should not decide what is child-safe. That is a critical separation. The architecture separates policy creation, policy evaluation, and finality enforcement. Policy Authority | v Policy Identifier / Version | v Policy Decision | v Finality Authority | v Finality Sink Das Expires 28 February 2027 [Page 38] Internet-Draft Child-Safe Rendering Finality August 2026 Figure 16 Different jurisdictions and organizations may legitimately apply different policies. A national regulator, a school, a parent, a platform, or another competent authority may define or select policy under its own legal and operational context. The protocol therefore carries or binds a policy identifier and policy version rather than embedding one universal definition of harmful or child-safe content. The Finality Sink enforces whether the specific operation was authorized under the applicable policy; it does not decide what society should consider appropriate. 28.10. FAQ 10 — Can governments or platforms abuse the mechanism for censorship? Yes. This is a legitimate architectural risk and should be addressed explicitly. A mechanism capable of preventing one category of content from reaching children could theoretically be expanded to restrict other content or adult users. Anti-abuse safeguards should include: * Scope limitation: authority explicitly binds purpose, content class, age or eligibility class, jurisdiction, policy version, expiration, and authorized sink. * Policy transparency: policies have identifiable versions, issuers, scopes, and auditable changes. * Separation of powers: age-credential issuance, policy definition, finality-authority issuance, and hardware control should not automatically belong to one entity. * Privacy minimization: the Finality Sink should learn only what is necessary to decide authorization, rather than collecting detailed viewing histories or civil identity. * Adult-rights separation: a child-safety profile should not automatically become a general adult content-control profile. These safeguards are important for interoperability, legitimacy, and standards acceptance because the enforcement mechanism should be technically narrow even when policy sources differ. Das Expires 28 February 2027 [Page 39] Internet-Draft Child-Safe Rendering Finality August 2026 28.11. FAQ 11 — How does it work offline or during authorization- service outages? The system should not require an online cryptographic transaction for every frame or every media object. Short-lived Finality Leases allow bounded offline operation after an authorization decision has been made. Online Authorization | v Policy Evaluation | v Finality Lease | v Bounded Offline Operation | v Lease Expiry | v Renewal / Revalidation Figure 17 Failure behavior should be risk-based and policy-defined. High-risk content can fail closed when current authorization cannot be established. Already-authorized lower-risk sessions may continue only until the bounded lease expires, depending on policy. Lease duration can vary by risk. Lower-risk operations may receive longer leases; higher-risk operations may receive short leases or require online authorization. The exact durations should be policy- defined rather than hard-coded into the protocol. This prevents a cached authorization from becoming a permanent bypass while avoiding an online transaction for every rendered frame. 28.12. Central Architecture and Five Core Rules Taken together, the FAQ answers produce the following child-safety architecture: Das Expires 28 February 2027 [Page 40] Internet-Draft Child-Safe Rendering Finality August 2026 AGE ASSURANCE | v Privacy-Preserving Proof | v POLICY AUTHORITY | v Policy Decision | v FINALITY AUTHORITY | v Short-Lived, Scoped Lease | +-- Device Binding +-- Session Binding +-- Policy Binding +-- Sink Binding +-- Expiry / Nonce / Revocation | v +---------------------------+ | Protected OS / TEE | | Enforcement Boundary | +-------------+-------------+ | v Protected Path | v +---------------------------+ | FINALITY SINK | | GPU / Decoder / | | Compositor / Display / XR | +-------------+-------------+ | v PIXELS Figure 18 The five core rules are: * No continuous biometric surveillance. Das Expires 28 February 2027 [Page 41] Internet-Draft Child-Safe Rendering Finality August 2026 * No age credential is itself execution authority. * No valid finality authority means no protected effect. * No alternate path may bypass the protected effect boundary. * Cryptographic verification protects authorization transitions, not every frame. 29. IANA Considerations This version requests no IANA actions. If a future version standardizes an Internet media type, URI scheme, error registry, or globally interoperable consequence-class registry, the corresponding IANA considerations will be added. 30. Intellectual Property Considerations Certain concepts described in this document are related to pending patent applications in the DAS Protocols family. Any disclosure required by an applicable standards-development process should be made separately in accordance with that process. This section is informational and does not specify licensing terms. 31. Informative References [UNICEF-PORN] UNICEF, "Protection of children from the harmful impacts of pornography", . UNICEF states that pornographic content can harm children and that digital restrictions have not kept pace with technological shifts. [ITU-COP] International Telecommunication Union, "Child Online Protection", . ITU Child Online Protection programme and guidelines. [UN-CRC-GC25] United Nations Committee on the Rights of the Child, "General Comment No. 25 (2021) on children's rights in relation to the digital environment", . United Nations guidance on children's rights in the digital environment. Das Expires 28 February 2027 [Page 42] Internet-Draft Child-Safe Rendering Finality August 2026 [EU-MINORS] European Commission, "Guidelines on the protection of minors under the Digital Services Act", . European Commission protection-of-minors guidance. [EU-AGE] European Commission, "The EU approach to age verification", . Privacy-preserving age-verification approach for adult- restricted online content. Author's Address Sangam Das Independent Inventor Balasore 756001 Odisha India Email: info@sangamdas.com Das Expires 28 February 2027 [Page 43]