eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

Credential Status Over Time: Verify the Snapshot, the Challenge and the Key History

—

by

eduKate Asia
Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.

中文版 · Blockchain learning guide · Previous article

Blockchain learning · Article BC094

Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.
Study photograph for illustration; it does not establish that the pictured students are studying blockchain.

A credential’s original proof, its current status and a presentation made today are different evidence objects. A verifier can check the original signature correctly while relying on a status snapshot that predates a suspension. A failed status request can leave the answer unknown without establishing revocation. A routine key rotation can change future signing authority without automatically making every older credential false.

This lesson follows one synthetic credential through an invented timeline. We apply an exact freshness rule to nine independent verification cases, including its boundary value, a service outage and a prospective key rotation. The result is a decision table with reasons, rather than one undifferentiated “valid” label.

The three-minute parameter below is deliberately chosen for arithmetic and is not a recommended production policy. No real credential, person or educational decision is involved. Sources were checked on 12 October 2026.

Choose your reading route

In this guide

Sections 1–3 define the clocks, timeline and rule. Sections 4–6 work through the surprising cache boundary, the outage and key rotation. Sections 7–9 classify all nine cases and explain the limited blockchain role. The exercise and reporting examples show how to describe acceptance, rejection and unresolved evidence precisely.

Back to contents · Next section

1. Keep three clocks on the page

The first clock is issuance: when the protected credential was actually issued under the relevant authority. The second is the status assertion’s as-of time: the time for which the authenticated status source states a condition. The third is verification: when V evaluates the presentation and the supplied status evidence.

A local download time is a fourth possible timestamp. It does not automatically update the status assertion’s as-of time. Fetching a five-minute-old document now does not make its contents a new observation of the issuer’s current state.

All times in our model are elapsed minutes on one shared exercise clock. The as-of timestamps and status statements are authenticated, and the clock basis is given as consistent. A real system would need to assess time sources, validity intervals, publication semantics and uncertainty; our arithmetic assumes those foundations rather than solving them.

The credential is C. Its subject is synthetic S, and the verifier is V. Trusted subject binding, issuer acceptance and claim interpretation are supplied as satisfactory in every case unless a presentation failure is explicitly stated.

Back to contents · Next section

2. Read the underlying timeline

C is issued at minute 0 using issuer key K1. Its genuine issuance at that time and K1’s authority then are established by the supplied independent history, not merely by a date written inside a signed object. The credential’s stated validity period covers every minute in this exercise.

The authoritative status timeline is:

  • From minute 0 up to, but not including, minute 6: active.
  • From minute 6 up to, but not including, minute 9: suspended.
  • From minute 9 up to, but not including, minute 12: active again.
  • From minute 12 onward: revoked under the toy’s terminal revocation rule.

Authenticated snapshots are available with as-of times 5, 6, 9 and 12. They report active, suspended, active and revoked respectively. The learner can see the whole timeline, but the verifier in each case receives only the snapshot specified for that case. Do not give V knowledge that its packet does not contain.

At minute 10, a separately authorised issuer-key rotation changes future signing authority from K1 to K2. The policy expressly preserves the authenticated historical K1 verification path for C. There is no supplied key compromise, backdated forgery or decision to withdraw all earlier credentials.

Back to contents · Next section

3. Apply the invented decision rule

Each presentation must satisfy V’s fresh challenge and intended verifier context. The original credential proof and its historical issuer-authority evidence must pass. These are separate from status freshness.

For status, define age as verification time minus authenticated status as-of time. V admits the snapshot only if age is at least zero and at most three minutes, inclusive. A future-dated snapshot fails this exercise’s time rule. A snapshot older than three minutes is insufficient, even if it is genuinely signed and says active.

If admitted status says active, the case passes the status condition. If it says suspended or revoked, V rejects acceptance for this purpose and records which supplied status caused that result. If no admissible status is available, V defers the decision as unresolved. A failed challenge instead rejects that presentation; it is not a status transition for C.

“Accept” in this worksheet means the evidence meets this exact policy. It does not guarantee that no status change occurred after the snapshot. This deliberately visible limitation is the main reason for showing both the learner’s full timeline and V’s narrower evidence view.

Back to contents · Next section

4. Examine the inclusive boundary

At minute 5, V receives the active snapshot as of minute 5. Its age is 5 − 5 = 0, which is admitted. With every other supplied check passing, V accepts under the policy.

At minute 8, V instead receives the active snapshot as of minute 5. Its age is 8 − 5 = 3. Because the limit is inclusive, the snapshot is admitted and the worksheet again returns acceptance.

However, the learner knows C was suspended at minute 6. Thus the minute-8 policy acceptance coexists with an actual suspended status at that time. There is no arithmetic contradiction. The rule permits bounded-old evidence, and that evidence does not include the intervening change.

The honest report is “accepted under the snapshot policy, using active status as of minute 5.” It is not “proved active at minute 8.” Whether a real use case can tolerate such a gap is a separate risk and policy decision, not answered by our chosen three-minute number.

This example is not a recommendation to accept known suspended credentials. V is not supplied the minute-6 change in that case. A system with an authenticated newer suspension observation cannot pretend the older active snapshot is its complete evidence merely to obtain a favourable result.

Back to contents · Next section

5. Distinguish a suspension observation from an outage

In an independent minute-8 case, V receives the suspended snapshot as of minute 6. Its age is two minutes and it is admitted. V rejects acceptance because the supplied status says suspended. The reason is positive status evidence, not failure to retrieve a page.

At minute 9 in another case, V has only the old active snapshot as of minute 5. Its age is four minutes, so it is too old. The status endpoint is unavailable and no other status evidence is supplied. V defers as unresolved.

The learner knows the authoritative status has returned to active at minute 9. V nevertheless lacks an admissible snapshot establishing that fact. This is the mirror image of the earlier case: an actual active state can coexist with a deferred decision because the verifier does not possess sufficient evidence.

Neither inference should be replaced with a guess. An outage is not evidence that the issuer revoked C, and a previously active snapshot is not automatically fresh enough. The result should identify the missing or stale evidence rather than attach a false revoked label to the credential.

Back to contents · Next section

6. Handle the historical key at minute 10

At minute 10, V receives the active snapshot as of minute 9. Age is one minute, so the status condition passes. The original credential proof is still evaluated using the authenticated historical K1 authority path that our policy explicitly preserves.

The new future-signing key K2 does not retroactively sign C, and C’s original protected bytes do not change. Under the supplied history, routine rotation alone does not invalidate this credential. The case is accepted because the historical proof path and all other conditions pass, not because old keys must always be trusted forever.

Change the facts and the answer may change. A compromise finding, an uncertain issuance time or a policy that lacks reliable historical authority evidence would require a different analysis. A date asserted by an untrusted signer would not be enough to prove that a credential predates compromise.

W3C’s Bitstring Status List specification notes that a digital credential’s status need not be identical to the status of an underlying qualification. That reinforces the need to name what changed rather than treating a technical event as an automatic educational conclusion. W3C Bitstring Status List v1.0

Back to contents · Next section

7. Classify all nine independent cases

Each case resets to its stated evidence packet. There is no shared cache that secretly accumulates all earlier snapshots. Unless specified otherwise, proof, authority, subject binding and the fresh presentation checks pass.

Case A: verification at 5, active as of 5. Age zero. Accept under the policy.

Case B: verification at 8, active as of 5. Age three. Accept under the policy, while explicitly retaining the as-of qualification. The learner’s full timeline shows suspension at verification time.

Case C: verification at 8, suspended as of 6. Age two. Reject for the observed suspended status.

Case D: verification at 9, active as of 5, endpoint unavailable. Age four. Defer because no admissible status is supplied. Do not mark revoked.

Case E: verification at 10, active as of 9, prospective key rotation effective at 10 with the preserved historical K1 path. Age one. Accept.

Case F: verification at 13, revoked as of 12. Age one. Reject for observed revocation.

Case G: verification at 14, active as of 9, no other snapshot supplied. Age five. Defer for insufficient freshness. The learner knows revocation occurred, but V’s packet cannot be rewritten to include it.

Case H: verification at 10, active as of 9, but the presentation contains a different challenge from V’s fresh expected challenge. Reject that presentation. Do not describe this as a revocation of C.

Case I: verification at 14, a supplied authenticated status assertion marked active as of 15. Age minus one. Defer because the time evidence fails the rule. Authentication does not make a future-dated assertion admissible under this policy.

The totals are three acceptances, three rejections and three deferrals. The categories describe this invented evidence policy, not all possible credential-verification systems.

Back to contents · Next section

8. Connect the model to standards carefully

W3C Verifiable Credentials Data Model v2.0 includes credential status among the evidence relevant to verification. Data Integrity 1.0 describes checks for an expected challenge and domain in its proof framework. These support separating credential evidence from the particular presentation session. W3C credential data model and W3C Data Integrity

Bitstring Status List v1.0 specifies a particular way to publish status information such as suspension and revocation, and discusses verifier caching. Our three-word active/suspended/revoked service is an abstract teaching model. It is not a one-bit encoding of three states and does not claim to implement that specification’s validation algorithm, time-to-live handling or complete semantics. W3C status-list specification

All three cited documents are Recommendations dated 15 May 2025 and identify errata resources. The three-minute maximum, the terminal revocation rule and the accept/reject/defer procedure are our explicit classroom assumptions. Readers should not attribute those invented choices to W3C.

Back to contents · Next section

9. Identify what an issuance anchor cannot answer

Suppose C also has an independently verified digest anchor recording its issuance representation in a known blockchain context. That extra historical evidence does not automatically contain the status change at minute 6 or the revocation at minute 12.

A verifier still needs the relevant status evidence and its interpretation. If status updates are themselves published on a chain, the design must specify the authoritative update, its inclusion and finality requirements, and which state the verifier has actually checked. A reference to an old issuance block cannot stand in for all those facts.

The same principle applies to an explorer screen. “Found onchain” may identify a historical record while saying nothing about the current status source or the freshness rule. A block timestamp also should not be silently substituted for a status assertion’s defined as-of time.

This lesson does not design a chain-based status system. It shows the question such a design must answer: what evidence connects this decision time to the relevant status, with what permitted delay and unresolved uncertainty?

Back to contents · Next section

10. Exercise: change the rule or the evidence

  1. Why does Case B pass the policy even though the full timeline says suspended?
  2. If the maximum age were changed from three minutes to two, what would happen to B with the same evidence?
  3. Why is D deferred rather than revoked?
  4. What additional supplied assumption allows E to use K1 after the rotation?
  5. Does H prove that C’s issuer withdrew the credential?
  6. Can downloading the as-of-5 snapshot again at minute 9 change its age to zero?
  7. Does I’s authenticated signature eliminate the negative-age problem?

Answers and reasoning

  1. The admitted snapshot is active as of 5 and exactly three minutes old. Policy compliance does not establish no later status change.
  2. B would be deferred for insufficient freshness if no other admissible evidence were supplied. This is a changed policy, not a changed historical timeline.
  3. The available snapshot is too old and the endpoint is unavailable. Neither fact supplies a revoked assertion.
  4. Genuine issuance time and historical K1 authority are independently established, and the policy explicitly preserves that verification path without a compromise finding.
  5. No. It establishes a presentation challenge failure under the case assumptions, not an issuer status action.
  6. No. Local fetching does not replace the authenticated assertion’s as-of time.
  7. No. The source can be authenticated while its timestamp remains outside the policy’s admitted range.

Back to contents · Next section

11. Report the decision and its evidence horizon

For B, write: “Accepted under the three-minute snapshot policy using active status as of minute 5, evaluated at minute 8. This result does not establish uninterrupted active status through minute 8.” The full teaching analysis can then explain the intervening suspension that V did not observe.

For D, write: “Deferred: the available status assertion is four minutes old, and no admissible replacement was obtained. Current status is not established by this packet.” Do not replace that sentence with “credential revoked” or “issuer dishonest.”

For H, write: “Presentation rejected because the challenge does not match the expected session challenge. This result does not change the credential’s issuer-maintained status.”

A useful report names the credential, policy version, verification time, status source and as-of time, proof path, presentation result and unresolved evidence. It does not need to expose unrelated personal history. Keeping those fields separate makes later review possible without pretending that one pass/fail label contains the entire timeline.

Back to contents · Next section

Frequently asked questions

Does fresh-enough mean definitely current?

Not under this model. It means the snapshot meets the stated age limit. The intervening-change example shows why those claims differ.

Is an unavailable status service the same as revocation?

No. Without adequate alternative evidence, our policy defers. The cause of the outage and the actual status remain separate questions.

Does key rotation invalidate every old credential?

No universal result follows. Our case preserves independently authenticated historical authority; different compromise evidence or policies require different analysis.

Does a failed presentation erase a qualification?

No such consequence is defined here. Presentation acceptance and underlying educational status are separate matters.

Back to contents · Next section

Sources and further reading

Primary references checked on 12 October 2026:

For the institutional processes behind correction and withdrawal, read Credential Correction, Reissue and Revocation. For record-level assurance, read Digital Record Authenticity. The present task is narrower: computing a verifier’s time-dependent decision from the evidence it actually holds.

Back to contents