Protected content: align expiry deadlines when resuming Wallet approval

Analysis baseline and required implementation base

The analysis was performed on fix/0.7.1-security at 54355973e737f018e7d898a74449f9b04aaef26c. The findings below apply to that reviewed revision; their applicability to the latest protected-content workflows remains unverified.

The product owner has designated PR #70 as the latest protected-content feature/workflow line and the required base for this work.

PR metadata checked on 2026-09-29: PR #70 is open, with head feat/protected-content-listing-buy at d181ffd2af202b6551f2bf0e7e0688d229c3c5ef, stacked on PR #62. This is a planning snapshot; resolve the latest head again when work starts. No code revalidation against PR #70 has been performed for this ticket yet.

Before implementation:

1. Resolve PR feat(protected-content): buy from any live offer, found by link or in Explore #70's current head branch and commit, and record the exact revision checked.
2. Re-verify the finding against that revision, tracing the current Runtime and viewer flow and adding a focused reproduction where appropriate.
3. Record whether the issue is still present, already resolved, or changed in scope. If resolved, document the evidence and close the issue without a redundant fix.
4. If confirmed, implement the fix on top of PR feat(protected-content): buy from any live offer, found by link or in Explore #70 and submit it as a stacked PR targeting PR feat(protected-content): buy from any live offer, found by link or in Explore #70's head branch. If that parent changes, revalidate and update the stack before merging. Integrate the fix after or together with its parent.

This ticket remains deferred from the current release plan. Revalidation on PR #70 is a prerequisite to starting a fix.

Problem

Resuming a protected-content open after Wallet approval can fail even while the prepared recipient is still valid.

Runtime initially prepares the recipient with an expiry of t0 + 60 seconds. The new pending-approval resume path preserves that expiry, but builds a release operation expiring at t_resume + 50 seconds. The viewer rejects a release operation whose expiry exceeds the prepared recipient's expiry.

For example, resuming 20 seconds after preparation produces an operation expiring at t0 + 70, beyond the recipient's t0 + 60. The open fails with the decrypt-unavailable path.

Release scope and priority

• Deferred backlog: outside the current release plan, as requested by the product owner.
• Suggested priority: P2.
• Category: workflow / lifecycle correctness. This review established an availability failure, not an authorization bypass.

Evidence

Reviewed fix/0.7.1-security at 54355973e737f018e7d898a74449f9b04aaef26c against upstream/0.7.1-dev at 6c61c990b9a1d0f2c1b00ee6f5f091d3354cafac.

• Resume retains the prepared recipient expiry.
• Initial preparation uses now + 60.
• Release operation uses resumed now + 50.
• Viewer rejects operation expiry beyond recipient expiry.

Evidence level: independently checked source trace. No installed reproduction or fix has been performed.

Reproduction to add

1. Open eligible protected content with a managed Wallet that requires approval.
2. Keep the original launch/session authority and prepared recipient.
3. Advance the test clock by more than 10 seconds but less than 60 seconds.
4. Approve and replay the exact pending open.
5. Observe the expiry invariant rejecting the open, even though the prepared recipient has not expired.

Use a controlled test clock to distinguish expiry behavior from provider latency. The player also needs its own pending/resume handling; a direct Runtime test isolates this defect.

Expected behavior and implementation direction

Runtime should allow an approved exact resume within its documented approval window and enforce consistent deadlines across the recipient, rights request, release operation, and terminal evidence. Derive downstream deadlines from the retained authority lifetime, or define a deliberate approval lifecycle with sufficient time.

Preserve exact request identity and fail-closed expiry checks. Expired or revoked authority must settle cleanup explicitly; avoid silent replacement of an uncertain operation.

Acceptance criteria

• Re-verify the finding on PR feat(protected-content): buy from any live offer, found by link or in Explore #70 and record its exact head commit and evidence before implementing.
• If still present, base the fix on PR feat(protected-content): buy from any live offer, found by link or in Explore #70 and submit it as a stacked PR targeting that feature branch.
• Clock-controlled tests cover immediate resume, resume after 10 seconds, near-expiry resume, and expired authority.
• Valid resume uses the original recipient and byte-identical Wallet request.
• Downstream expiry never exceeds retained recipient authority.
• Denial, revocation, timeout, and cleanup preserve exact effect semantics.
• Installed Wallet approval followed by playback is verified on the fixed revision.

Related

• Protected content: resume playback after pending Wallet approval #82 — Protected content: resume playback after pending Wallet approval.
• Protected-content UI/UX parity gaps vs feat/dkms-esp-port: protect any file type, Creator app, open-through-decryption #42 — broader protected-content UI/UX work.
• Installed acceptance: one Runtime, two principals, mint → buy → play (ELACITY-2300) #47 — installed mint → buy → play acceptance.