Summary

  • RFC 9246 requires a token generated for CDNI redirection to preserve a present expiry and not-before value. It also prohibits adding either claim when it was absent.
  • A redirecting CDN can update the issuer, issuance time and appropriate route context. A fresh signature or newer issuance time is not a fresh time grant.
  • Explicitly enabled segment renewal calculates the next expiry from verification time and the renewal interval. That mechanism should not be substituted for an ordinary route handoff.
  • Expiry is optional in an individual token under the profile. Required acceptance claims, trusted keys and per-request enforcement therefore matter alongside the preservation rule.
  • This is protocol and governance analysis, not evidence of a measured CDN defect or an inventory of universal implementation support.

A new envelope can contain the old deadline

Suppose a content provider grants a request access until logical time sixty. The user agent reaches an upstream delivery network at ten and is redirected towards a downstream network at twenty. Each handoff may need a new signature because the next verifier trusts a different signer and the destination URI has changed. The operational temptation is to treat that new signed object as a new sixty-unit opportunity.

That would confuse route autonomy with time authority. If the second handoff sets expiry to eighty merely because it created a token at twenty, it has lengthened a grant that was supposed to end at sixty. The signature can be cryptographically valid while the transformation is wrong. This timeline is an analytic example, not a reproduced incident.

The CDNI URI Signing profile draws the boundary explicitly. For an ordinary redirection token, an existing expiry survives with the same value. Time spent navigating remains time spent. A changed signer does not reimburse it.

The distinction matters because a newly issued token is visually reassuring. Logs can show a recent issuance time, a valid signature and a recognised recipient. All three observations may be correct. They still do not show that the signer was allowed to restart the entitlement clock.

What the standard actually preserves

RFC 9246 was published in June 2022. Its RFC Editor status page identifies it as a Proposed Standard on the Internet Standards Track. It profiles signed JSON Web Tokens for per-request content access in cooperating delivery networks, and can also be used within a single-CDN arrangement. It is not digital rights management or a means of recalling content already delivered.

Section 2.1.4 makes the expiry transformation rule precise. When a received JWT contains exp, a JWT subsequently generated for CDNI redirection must also contain exp with the same value. If the received token has no exp, redirection must not add one. Verification must reject a request at or after the stated expiry, or when the verifier cannot perform the required expiry check.

The corresponding not-before rule is equally narrow. A present nbf survives redirection unchanged; an absent nbf cannot be introduced by that operation. A request earlier than nbf is rejected. Equality with the not-before boundary is permitted, whereas equality with expiry is not.

These rules do not say that every conforming individual token contains both claims. The profile requires support for its listed claims, but distinguishes implementation support from mandatory use in every token. The URI container is mandatory; expiry is optional. A content provider that needs exp in every accepted original grant must make that acceptance requirement explicit rather than pretend the redirection rule already supplies it.

The prohibition on adding an absent expiry can appear counterintuitive. Adding a short deadline may seem safer. But redirection is a defined transformation of a received grant, not an invitation to silently create a different claim set. If the original token fails a locally agreed acceptance requirement, the appropriate result is rejection or a separately authorised new grant, not an improvised repair disguised as route forwarding.

Issuance age and access duration are different quantities

JSON Web Token, RFC 7519, gives iat its general meaning: when the JWT was issued. Under the CDNI profile, a present iat is updated when a new redirection JWT is generated, and an absent iat may be added. The resulting token can correctly have a newer issuance time and the original expiry.

Issuer context changes too. Where iss was present, it remains present but identifies the redirecting CDN. The next verifier needs a trusted mapping from acceptable issuer to the relevant signing key and must check that the claimed issuer matches the key actually used. An audience can be adjusted for the intended configured chain identity. A URI container can be changed to match the redirected URI.

Those permissions are specific. They do not convert every claim into a freely editable routing convenience. A fresh iat answers how old this signed object is; exp answers when access under its time condition ends. Deriving one from the other without the relevant authorisation changes the meaning of the grant.

This is why signature validation cannot finish the review. JSON Web Signature, RFC 7515, supplies integrity machinery. JWT Best Current Practices, RFC 8725, addresses algorithm, issuer, audience and related validation risks. They help determine whether an object was signed and is appropriate for the receiving context. A trusted signer still needs to respect the particular transformation it is performing.

Key distribution is outside the CDNI profile's detailed scope. Asymmetric keys separate signing capability from ordinary public-key verification. Symmetric shared signing keys are supported for legacy compatibility but are not recommended: possession gives a party the ability to mint tokens, not just inspect them. Neither architecture removes the need to constrain a legitimately trusted signer's policy decisions.

A short window must not become verifier leeway

Generic JWT processing permits limited clock-skew leeway for exp and nbf. RFC 9246 explicitly does not. A library default that is reasonable for another JWT application must not quietly broaden the CDNI request window.

The profile requires relevant signing and verifying systems to have synchronised time and recommends NTP. RFC 5905 provides the time-synchronisation reference. Coordination of clocks does not restore time consumed by routing, and a slow route does not become a new grant.

There is still a legitimate availability trade-off. A chosen original access window must allow enough time for realistic HTTP exchanges and transient network delays. The standard's security discussion recognises that extremely short windows can deny legitimate users. The place to make that choice is the agreed grant duration, not an undisclosed tolerance added independently by every verifier.

With several CDNs, the distinction becomes consequential. Locally generous expiry checks can accumulate differences in acceptance even when every signer preserved the numerical exp. A correct value and a widened interpretation are separate failure modes. Both belong in the review, without assuming that either occurs in a particular deployed network.

Renewal is a deliberately different delegation

Segmented delivery creates another problem. A video player may seek, switch representations and request segments in an order that cannot be predicted in a manifest. Signing every possible segment URI for a long playback period can create an unnecessarily long-lived access surface.

RFC 9246 therefore defines Signed Token Renewal. After correctly verifying a token and successfully delivering a segment, a CDN can supply a token for subsequent access to related resources. The next expiry is calculated using the verification time plus the interval carried by cdniets. Renewal also requires the specified transport claim, cdnistt.

The arithmetic is different from redirection preservation. If verification occurs at fifty-five and the renewal interval is thirty, the calculated next expiry is eighty-five. That is an illustration of an explicitly enabled renewal rule, not permission for a route handoff to change an exp of sixty into eighty-five.

The transport can be disabled, cookie-based or query-based. The IANA CDNI parameters registry identifies those values. Transport value zero does not mean that renewal is secretly available; the profile recommends omitting the renewal pair when it is not wanted.

A rolling segment window is not automatically an absolute programme cutoff. If a business arrangement needs both continued short-lived playback access and a final entitlement boundary, it must specify where that additional condition is enforced. That observation does not invent a new registered JWT claim or require the content provider to approve every segment online.

The important question is what authority was delegated. A downstream network can verify and renew within an agreed local policy without understanding every commercial reason behind it. It cannot justify an unintended time extension simply by describing every freshly signed object as renewal.

Transport association does not enlarge URI scope

A renewal cookie may be associated with a path subset using cdnistd. The omitted depth means zero; zero can associate transport with any path. That does not override the signed URI container's authorisation constraint.

The profile's cookie and query alternatives also have domain limits. Cross-domain cookie restrictions can require query transport, and the described renewal process expects the manifest and segments on the same domain, with cross-domain redirection handled when obtaining the manifest. A token's convenient transport is not proof that an unrelated destination should receive or accept it.

URI matching has its own boundary. The profile checks the URI container against the requested content URI after removing the signing package, using the percent-encoded representation. URI syntax, RFC 3986, provides that reference. Rewriting a URI to reach the authorised resource is not the same decision as broadening a pattern to cover additional resources.

The standard permits container forms that can cover related resources. Its security discussion warns that a wildcard container, combined with absent additional constraints, can become a broadly usable skeleton key. That is not a reason to describe every signed URI as equally dangerous; it is a reason to review the actual scope and claim requirements.

Enforcement must run before delivery

The CDNI framework, RFC 7336, and requirements, RFC 7337, separate a content provider's distribution policy from enforcement by cooperating delivery networks. The metadata interface, RFC 8006, carries the relevant configuration.

In RFC 9246, URI Signing metadata has an enforcement flag that defaults to true. When enforcement is false, the downstream network does not verify the token merely because a signed package appears in the URL. The existence of a signature in a delivered request is therefore not evidence that the intended checks ran.

Likewise, an empty issuer list in the metadata does not mean trusting every issuer on the Internet. It means accepting issuers from the trusted issuer keystore. The default still depends on an independently established trust boundary.

Footprint and capabilities semantics, RFC 8008, helps advertise metadata capability, while request-routing redirection, RFC 7975, supports choosing the downstream route. A network's geographic suitability or capability advertisement does not prove that a particular request preserved its deadline or underwent enforcement.

Replay state is not renewed by a new signature

A present jti also has preservation rules for redirection. It remains the same, and redirection cannot add it when it was absent. Under the profile, a verifier receiving jti must support the corresponding storage check and reject repeat use for the same content.

The identifier is not replay protection by itself. State retention, content scope and expiry cleanup matter. Without exp, bounded least-recently-used storage can eventually allow an identifier to be reused. Nor does a shared identifier establish a magically coordinated one-time ledger across all delivery networks.

These details reinforce the main distinction. A new signed envelope can carry the same constrained access event. Refreshing the envelope does not erase its elapsed time, replay history or required checks. Local distribution contracts must say how those responsibilities transfer.

CDNI logging, RFC 7937, and the profile's URI Signing extensions provide enforcement and denial observations. They can corroborate a transformation review. A success field alone is not proof of every claim check, and diagnosis should avoid exposing bearer tokens or personal data merely to reconstruct the route.

The evidence here is the published protocol and its referenced coordination machinery. It does not measure deployment coverage, demonstrate a vendor bug or establish an incident rate. The minimal-specification and local-decision framework and The Policy Mirror supply the governance lens, not replacement token semantics: define the limited shared promise, let each participant implement it locally, and preserve voluntary cooperation within that promise.

Sources