Preventing Unauthorized Adult and Age-Restricted Content Rendering to Children Through Hardware-Rooted Execution Finality

28.1. Human-Centered Family Handover: Designing for What Parents Actually Do

A purely logical security rule might say that an adult should never hand an unrestricted adult-configured phone to a minor. That rule is simple in theory, but family life is not always governed by ideal security procedure. Children ask to use a parent's phone for games, school work, photographs, messages, maps, entertainment, travel, or simple curiosity. A parent may initially refuse and later agree after repeated requests. The architecture in this document treats that behavior as a realistic human condition to be designed for, rather than as a reason to blame the parent or declare the technical problem out of scope.¶

The objective is therefore not to demand perfect parental behavior. The objective is to give the adult a simple, understandable and technically meaningful action immediately before a device handover, so that ordinary family emotion does not silently turn an adult-authorized device into an unrestricted adult-content device in the hands of a child.¶

The design follows a usability principle: make the transition into the safer child state easy, and make the transition back into adult rendering authority require protected adult authorization.¶

ADULT-REGISTERED DEVICE
        |
        | adult verifies once for a bounded viewing context
        v
PROTECTED ADULT VIEWING CONTEXT
        |
        | multiple permitted items may render while context is valid
        | (no biometric prompt for every video or frame)
        |
        | parent is about to hand phone to child
        v
TEMPORARY UNDER-18 MODE ACTIVATED
        |
        +-- invalidate / suspend prior adult rendering authority
        +-- advance protected policy / security state
        +-- prohibit new adult-only Finality Authority
        |
        v
PHONE OPERATES UNDER TEMPORARY MINOR RENDERING BASELINE
        |
        | child uses phone for permitted activities
        |
        | adult later takes phone back
        v
PROTECTED ADULT RE-AUTHORIZATION
        |
        +-- succeeds -> new bounded Adult Viewing Context may be created
        |
        `-- absent / fails -> adult-only content remains NON-RENDERABLE

28.2. Device Registration and Age-Class Baseline

This case study distinguishes a device registered or provisioned for a minor from a device registered or provisioned for an adult. A device MAY obtain its protected age-class baseline from a verified date of birth, a privacy-preserving age credential derived from that date of birth, a family or platform enrollment record, or another trusted age-assurance process accepted by policy.¶

If the verified registration state establishes that the registered user is below the applicable adult threshold, the device is a Minor-Registered Device under this profile. A Minor-Registered Device MUST NOT issue Rendering Finality Authority for content classified as adult-only or otherwise prohibited to that age class. Adult content therefore remains non-renderable on that device even if an adult account is later logged in, an application possesses an adult service credential, or adult content bytes are downloaded or cached.¶

The Minor-Registered Device rule is a device-policy floor, not a claim that the operating system continuously identifies the person holding the phone. Ordinary application login, account switching, possession of an OVER_18 service credential, or a previous adult session MUST NOT silently override the protected minor registration state. If policy permits the device itself to change from minor-registered to adult-registered status, that change MUST occur through an explicit authorized re-provisioning or age-registration procedure rather than through ordinary content access.¶

If the verified registration state establishes an adult user, the device is an Adult-Registered Device. Adult registration makes the device eligible to request adult-content authority, but it MUST NOT itself authorize adult rendering. When adult or other age-restricted content is about to become perceptible, the protected device environment MUST require fresh or sufficiently recent verification of the adult-authorized user as required by the applicable assurance profile. Only after that verification succeeds may the PED issue a bounded Rendering Finality Authority for the protected session.¶

Verified device age registration
          |
          +-- registered user is MINOR
          |        |
          |        v
          |   MINOR-REGISTERED DEVICE
          |        |
          |        `-- Adult-only Rendering Finality Authority MUST NOT issue
          |             -> ADULT CONTENT REMAINS NON-RENDERABLE
          |
          `-- registered user is ADULT
                   |
                   v
              ADULT-REGISTERED DEVICE
                   |
                   | adult content requested
                   v
              Fresh / current adult verification required
                   |
             +-----+-----+
             |           |
          succeeds     fails
             |           |
             v           v
        Bounded Finality  NO AUTHORITY
        Authority may     -> NON-RENDERABLE
        issue

The resulting rule is asymmetric: minor registration can be a protected hard-deny baseline for adult content, while adult registration is only permission to attempt adult verification, not permission to render.¶

28.3. Threat Scenario

Consider a phone owned by an adult parent. The parent has a valid privacy-preserving OVER_18 credential and legitimately opens age-restricted content. Later, the parent locks the phone, closes the application, leaves the device unattended, changes applications, or hands the device to an underage child. The child then attempts to start, resume, cast, mirror, or otherwise render the same or different restricted content.¶

The following facts MUST NOT, by themselves, authorize rendering for the child:¶

• the phone is registered to or normally used by an adult;¶

• an adult account remains logged in;¶

• an OVER_18 credential was previously validated;¶

• the device remains unlocked;¶

• a content application retains cookies, access tokens, or cached state;¶

• restricted content has already been downloaded, buffered, decrypted inside a protected path, or partially rendered; or¶

• a previous Rendering Finality Authority was valid for an earlier adult viewing context.¶

The protected rendering path therefore distinguishes ownership and eligibility from current authority to produce perceptible restricted content.¶

28.4. Required Five-Way Separation

A deployment addressing registered-device age state and shared adult/minor use SHOULD separate five states:¶

1. Device Age Registration: protected device policy records whether the device is minor-registered or adult-registered based on verified date of birth, an age-class credential, or an equivalent trusted enrollment result. Minor registration can prohibit adult Rendering Finality Authority at the device level.¶

2. Adult Eligibility: a trusted process establishes only that an authenticated subject satisfies the applicable age threshold, for example OVER_18.¶

3. Current Adult Viewing Context: a protected local mechanism establishes that an eligible adult has recently and intentionally activated the restricted-content viewing context on the relevant device or profile.¶

4. Temporary Under-18 Handover State: protected device policy records that an adult-owned device has deliberately entered a temporary minor baseline for family handover; incompatible adult rendering authority is invalidated or suspended while this state remains active.¶

5. Rendering Finality Authority: a bounded, non-bearer authority permits the specified restricted-content effect through the specified Finality Sink while the required context remains valid.¶

Device Age Registration, Adult Eligibility, Current Adult Viewing Context, Temporary Under-18 Handover State, and Rendering Finality Authority are distinct. A minor-registered device does not progress to adult Rendering Finality Authority under the child-safety profile. An adult-registered device may establish a bounded adult context without per-video authentication, but Temporary Under-18 Mode overrides that adult context for protected restricted-content rendering until an authorized adult transition restores adult eligibility.¶

Device age registration
        |
        +-- MINOR -> Adult Finality Authority prohibited
        |              -> DO NOT RENDER adult content
        |
        `-- ADULT -> adult eligibility may be evaluated
                       |
                       | necessary, but not sufficient
                       v
              Protected adult verification / viewing context
                       |
                       v
              Restricted Content Candidate Act remains NON-RENDERABLE
                       |
                       v
              Protected Enforcement Domain validation
                       |
                       v
              Scoped, short-lived Rendering Finality Authority
                       |
                       v
              Protected Rendering Finality Sink
                       |
                       +-- valid current context -> RENDER
                       |
                       `-- absent / expired / changed context -> DO NOT RENDER

28.5. Protected Adult Viewing Context

A higher-assurance deployment MAY maintain a protected Adult Viewing Context as local protected state. The protocol does not require one universal biometric or identity mechanism. The context may be established by an implementation-specific user-presence mechanism such as a secure device PIN, passkey, local biometric confirmation, trusted wearable confirmation, or another protected user-verification mechanism accepted by policy.¶

The content provider need not receive the adult's civil identity, biometric template, or exact date of birth. The locally protected result can be limited to the fact that the required adult-presence condition is current for the bounded viewing context.¶

The Adult Viewing Context MAY be bound to device identity, protected user or profile context, application identity, content class, active session, policy epoch, revocation epoch, intended rendering sink, freshness state, and an expiration or revalidation condition. These bindings may be represented inside the Rendering Finality Authority or maintained as protected local state checked by the PED and Finality Sink.¶

An implementation MUST NOT infer current adult presence solely from possession of a previously issued OVER_18 credential or from the continued existence of an adult account session.¶

28.6. Normal Adult Rendering Flow

One possible adult flow on an Adult-Registered Device is:¶

1. The adult requests restricted content. The request becomes a Restricted Content Candidate Act and remains non-renderable. Adult device registration alone does not authorize display.¶

2. The PED validates that the device is not subject to a protected minor-registration hard deny, then validates the applicable age-threshold evidence and other policy predicates.¶

3. Where the deployment requires current adult presence, the protected device environment requests a fresh or sufficiently recent adult-presence confirmation.¶

4. The protected environment establishes a bounded Adult Viewing Context.¶

5. The PED commits protected validation evidence and issues scoped Rendering Finality Authority bound to the applicable device, application, session, content or policy class, sink, epoch, freshness, and expiration state.¶

6. The Finality Sink independently verifies the authority immediately before releasing the protected rendering effect.¶

7. Restricted content becomes perceptible only while the required authority and protected context remain valid.¶

This flow prevents the age-assurance result from directly turning into permanent display permission.¶

For usability, a deployment MAY authorize a bounded series of rendering operations inside the same protected Adult Viewing Context. The adult need not re-authenticate for every video when device, session, sink, policy, freshness, and other required bindings remain valid. Revalidation is associated with meaningful state changes, expiry, handover, or risk transitions rather than with every frame.¶

28.7. Minor-Registered Phone: Adult Content Never Becomes Renderable

Consider a phone registered to a 15-year-old using a verified date of birth or an equivalent trusted age-class credential. The protected device state identifies the phone as minor-registered for the applicable adult-content policy.¶

1. An application, browser, message, AI service, cache, or streaming service obtains adult-classified content.¶

2. The content becomes a Restricted Content Candidate Act and remains non-renderable.¶

3. The PED evaluates the protected device registration state and determines that the device is minor-registered.¶

4. No adult Rendering Finality Authority is issued for the prohibited content class.¶

5. The Protected Rendering Finality Sink withholds the relevant protected effect, such as key release, decryption-to-usable-output, protected-surface admission, compositor display, audio output, casting, or mirroring.¶

6. The content remains non-renderable even if an adult account is logged into the application or the content bytes are already present on the device.¶

Under this strict child-safety profile, ordinary adult authentication inside an application does not override the device-level minor registration. The device must first be explicitly re-provisioned out of the minor-registered state through an authorized age-registration process, if such a transition is permitted at all.¶

28.8. Adult-Registered Phone: Verification Before a Protected Adult Rendering Session

Consider a phone registered to an adult. The device's adult registration does not create a permanent adult-content pass. Before establishing or renewing a protected adult rendering session, the protected environment requests fresh or sufficiently recent verification of the adult-authorized user, for example through a protected PIN, passkey, biometric confirmation, or another policy-approved local verification mechanism. The architecture does not require a new biometric interaction for every video or frame; a successful verification MAY establish a bounded Adult Viewing Context covering multiple permitted items while its protected conditions remain valid.¶

If verification succeeds, the PED may issue a short-lived, device-bound, session-bound, application-bound where applicable, content-or-policy-bound, sink-bound Rendering Finality Authority. If verification fails, is cancelled, is stale, or cannot be established, no such authority issues and the adult content remains non-renderable.¶

This means the adult phone behaves differently from an unrestricted bearer credential: the device being registered to an adult is only the first eligibility condition; the adult must still verify before the protected adult rendering session begins.¶

28.9. Why Device Age Registration or an Adult-Verification Setting Alone Is Not Enough

A device-age registration rule is useful policy input, but the rule does not by itself establish the consequence-control property defined by this document. An implementation can correctly record that a device belongs to a minor, or correctly require an adult verification step, while still allowing restricted content to become perceptible through a later path that does not consult or cannot be controlled by that setting.¶

This distinction is central to the case study. The architecture does not propose replacing age registration, parental settings, or adult verification. It makes those results technically load-bearing at the protected rendering boundary.¶

MINOR device registration
        |
        v
Upstream setting / parental policy = DENY
        |
        v
Normal application path blocks content
        |
        +-------------------------------+
        |                               |
        | alternate / stale / local     | normal path
        | rendering path                |
        v                               v
Decoder / GPU / cast / mirror /      BLOCKED
AI-generated or cached content
        |
        v
No protected finality check
        |
        v
RESTRICTED CONTENT MAY STILL BECOME PERCEPTIBLE

Device registration / age assurance / adult verification
        |
        v
POLICY INPUTS
        |
        v
Restricted Content Candidate Act
        |
        v
NON-RENDERABLE
        |
        v
Protected Enforcement Domain validates current state
        |
        +-- MINOR-REGISTERED -> no adult authority
        |
        `-- ADULT-REGISTERED + current adult verification
                    |
                    v
          bounded Rendering Finality Authority
                    |
                    v
          PROTECTED RENDERING FINALITY SINK
                    |
              +-----+-----+
              |           |
           valid        invalid / absent / stale
              |           |
              v           v
           RENDER      KEEP NON-RENDERABLE

WITHOUT EXECUTION-FINALITY
Age/device setting -> policy decision -> application tries to enforce
                                      |
                                      `-- later or alternate path may render

WITH EXECUTION-FINALITY
Age/device setting -> PED decision -> scoped authority -> protected sink
                                                        |
                                                        `-- no valid authority,
                                                            no protected rendering effect

28.10. Handoff to the Minor

When the device moves outside the protected adult viewing context, the implementation SHOULD invalidate, suspend, or require revalidation of the corresponding Rendering Finality Authority according to the applicable assurance profile. Relevant state changes can include:¶

• device lock or unlock;¶

• protected user or profile change;¶

• application termination or material backgrounding;¶

• session expiry or inactivity;¶

• adult-presence freshness expiry;¶

• content-class escalation;¶

• change of rendering sink or output path;¶

• start of casting, mirroring, remote display, or XR output;¶

• security-epoch or device-attestation change;¶

• revocation or policy-epoch change; or¶

• another deployment-defined event indicating that the prior protected viewing context can no longer be relied upon.¶

After such an event, the child's possession of the adult's phone does not restore the former adult authority. The Candidate Act remains or returns to a Non-Renderable State unless the required current authorization predicates are established again.¶

Father verifies adult eligibility and presence
        |
        v
Adult Viewing Context A
        |
        v
Finality Lease A
        |
        v
Restricted content may render
        |
        |  lock / timeout / profile change /
        |  app transition / revalidation event
        v
Finality Lease A expires, suspends, or becomes stale
        |
        v
Minor uses the same phone
        |
        v
Old adult status is NOT sufficient authority
        |
        v
Fresh required adult context unavailable
        |
        v
Finality Sink -> CONTENT REMAINS NON-RENDERABLE

28.11. Immediate Handoff While Content Is Already Playing

The hardest variant occurs when the adult successfully authenticates, starts restricted content, and immediately hands the still-unlocked and still-playing device to a child. A one-time age check cannot by itself detect that physical change of viewer.¶

A deployment requiring stronger protection SHOULD therefore use bounded or event-driven revalidation rather than issuing an indefinitely valid adult session. Revalidation MAY be triggered by lease expiry, inactivity, screen-off/screen-on transition, application transition, a new restricted title, content-class escalation, output-path change, a high-risk policy event, or another protected continuity signal.¶

For high-risk content, an implementation MAY pause, blank, mute, or otherwise return the protected output to a non-perceptible state before requesting revalidation. Rendering resumes only if the required adult-authorized context is re-established and new or renewed Finality Authority is successfully verified.¶

A deployment MAY also use privacy-preserving local continuity mechanisms, but this document does not require continuous camera monitoring, continuous facial recognition, or continuous transmission of biometric information. The protocol requirement concerns the validity of current authority, not continuous identification of a human viewer.¶

28.12. Illustrative State Machine

RESTRICTED CONTENT CANDIDATE ACT
     |
     v
NON-RENDERABLE
     |
     | check protected device age-registration state
     |
     +-- MINOR-REGISTERED
     |      |
     |      `-- Adult Finality Authority prohibited
     |           -> REMAIN NON-RENDERABLE
     |
     `-- ADULT-REGISTERED
            |
            | adult verification required
            v
       ADULT VERIFIED / BOUNDED VIEWING CONTEXT
            |
            | PED validation + protected evidence
            v
       FINALITY AUTHORITY ACTIVE
            |
            | sink verifies current bindings
            v
       RESTRICTED CONTENT PERCEPTIBLE
            |
            | expiry / lock / profile change / revocation /
            | context loss / required revalidation failure
            v
       NON-RENDERABLE

The important property is that the state transition back to NON-RENDERABLE does not depend on deleting the content bytes. Delivery, caching, buffering, or protected decoding may already have occurred. The security consequence is enforced by withholding or terminating the protected ability to make the content perceptible.¶

28.13. Illustrative Minor-Registered Device Denial

The following non-normative example illustrates the intended device-policy semantics. It does not add fields to the normative JSON schemas defined earlier in this document.¶

{
  "candidate_act_id": "rca-minor-device-552",
  "device_registration_age_class": "MINOR",
  "content_class": "ADULT_SEXUAL_CONTENT",
  "decision": "DENY_RENDER",
  "permitted_effects": [],
  "protected_sink_action": "KEEP_NON_RENDERABLE",
  "reason": "MINOR_REGISTERED_DEVICE_PROHIBITS_ADULT_RENDERING_AUTHORITY"
}

28.14. Illustrative Policy Result After Handoff

The following non-normative example shows the logical result when a previously valid adult session is no longer sufficiently current for protected rendering. It illustrates policy semantics and does not add fields to the JSON schemas defined earlier in this document.¶

{
  "candidate_act_id": "rca-shared-device-441",
  "previous_adult_eligibility": "OVER_18",
  "current_adult_viewing_context": "REVALIDATION_REQUIRED",
  "decision": "REQUIRE_REVALIDATION",
  "permitted_effects": [],
  "protected_sink_action": "SUSPEND_RESTRICTED_RENDERING",
  "reason": "PRIOR_ADULT_STATUS_IS_NOT_CURRENT_RENDERING_AUTHORITY"
}

If the required revalidation succeeds, a deployment may create new or renewed bounded authority. If it does not succeed, the protected rendering effects remain disabled.¶

28.15. Security Claim and Limitation

This architecture does not claim that a device can always determine which physical person is looking at a screen. If an adult authenticates and immediately hands an already-playing device to a child during an otherwise valid lease, and the implementation has no event or protected signal capable of causing revalidation, the device cannot reliably infer the physical handoff.¶

The defensible security claim is narrower and technically important: a successful adult age check, an adult-owned device, an adult account, or a previous adult session MUST NOT automatically become permanent or freely transferable restricted-rendering authority for every later user of that device.¶

Risk can be reduced through short-lived authority, protected session binding, explicit profile separation, revalidation on meaningful state transitions, higher-assurance local user-presence checks, sink-bound authority, and fail-closed behavior when required current authority cannot be established.¶

28.16. Core Rules Derived from the Case Study

• A device registered or provisioned as belonging to a minor, based on verified date of birth or equivalent trusted age-class evidence, MUST NOT issue adult-only Rendering Finality Authority under the strict child-safety profile.¶

• Ordinary adult account login or possession of an adult service credential MUST NOT override a protected minor-device registration state.¶

• An adult-registered device MUST still require fresh or sufficiently recent adult verification before adult-content Rendering Finality Authority may issue.¶

• Adult device ownership MUST NOT be treated as adult rendering authority.¶

• An adult account login MUST NOT be treated as indefinite restricted-content authority.¶

• An age credential establishes eligibility; it MUST NOT by itself establish indefinite current-viewer authority.¶

• A child profile MUST NOT inherit a previously issued adult Rendering Finality Authority.¶

• A materially changed device, session, profile, application, output, policy, revocation, or protected-presence state SHOULD trigger expiry, suspension, or revalidation as required by the applicable assurance profile.¶

• Where current adult authorization cannot be established, the Protected Rendering Finality Sink MUST keep the restricted effect non-renderable.¶

• A device-age or parental-control setting that is enforced only at an upstream application or account boundary MUST NOT be treated as equivalent to protected rendering finality when alternate materialization paths remain available.¶

• If a deployment claims that its age-setting mechanism is itself sufficient final enforcement, every protected materialization path within that claim MUST enforce the current setting or authority before the restricted effect becomes perceptible and MUST fail closed when that enforcement state cannot be established.¶

The resulting design principle is: protected device age registration establishes the baseline policy; minor registration can make adult content categorically non-renderable; adult registration permits an adult-verification attempt but does not itself authorize display; protected presence or control establishes a bounded viewing context; and Rendering Finality Authority controls whether restricted content may become perceptible.¶

29.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.¶

Age Assurance
      |
      v
Privacy-Preserving Credential
      |
      v
Policy Decision
      |
      v
Finality Lease
      |
      v
Protected Rendering Sink

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.¶

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.¶

29.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

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.¶

29.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.¶

Authenticate
    |
    v
Verify Policy
    |
    v
Issue Finality Lease
    |
    v
Protected Session
    |
    v
Render Thousands of Frames

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.¶

29.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.¶

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

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.¶

29.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.¶

Untrusted Internet
       |
VPN / Proxy / AI / Browser
       |
       v
Candidate Content
       |
       v
Policy Evaluation
       |
       v
Finality Authority
       |
       v
Finality Sink
       |
       v
Pixels

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.¶

29.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.¶

Restricted Image
      |
      v
AI Transformation
      |
      v
New Representation
      |
      v
Policy Re-evaluation / Authority Check
      |
      v
Finality Sink

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.¶

29.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¶

• 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.¶

29.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:¶

Application
    |
    v
Operating System
    |
    v
Trusted Execution / Protected Service
    |
    v
Protected Rendering Path
    |
    v
Hardware-Rooted Finality Sink

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.¶

29.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

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.¶

29.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.¶

29.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

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.¶

29.12. Central Architecture and Five Core Rules

Taken together, the FAQ answers produce the following child-safety architecture:¶

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

The five core rules are:¶

• No continuous biometric surveillance.¶

• 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.¶