Decentralised News · Editorial by Heath Muchena · Evidence reviewed 12 November 2026 · Edition 1.0
What Matters
A quick credential check can rely on status information retrieved long before the proposed action. Measure request time, time since a documented status refresh and validity limits separately. DN’s local worksheet compares two declared verification paths and exposes unknown refresh evidence. It does not verify credentials, measure providers or decide whether an agent may transact.
DN Evidence Block
Source-backed: published W3C credential specifications, HTTP caching rules and OpenID presentation requirements. DN contribution: a two-path timing and status-refresh budget, with explicit expiry and unknown states. Not measured: provider response times, credential validity, revocation propagation, trading performance or production failure rates. All worked numbers are illustrative. Documentation cut-off: 12 November 2026.
The seven-millisecond answer that leaves a question open
Imagine a purchasing agent presenting a supplier credential before committing an order. One implementation returns a result in seven milliseconds. A second takes 87 milliseconds because it refreshes a status dependency. The first looks faster. That comparison says little until the buyer knows what each path checked and how old its status evidence was.
The practical question is not simply how quickly a verifier returns. It is whether the result contains the evidence the intended decision requires, within the time available. A fast answer to a narrower question should not be presented as a faster answer to the complete question.
DN’s identity architecture map explains which identity layer belongs where. The Agent Passport organizes disclosures. This article addresses a different implementation decision: how to compare credential-processing paths without hiding status age inside a single latency figure.
Pin the specification before comparing implementations
W3C Verifiable Credentials Data Model 2.0 and Data Integrity 1.0 are Recommendations dated 15 May 2025. The model represents issuer claims and validity information; Data Integrity supplies mechanisms for authenticity and integrity. Neither description turns a timing measurement into proof that an agent’s proposed commercial action is authorized. [1] [2]
Version selection also needs a date. Bitstring Status List v1.0 is a Recommendation. A v1.1 Working Draft appeared on 11 November 2026; it remains work in progress, not an interchangeable final standard. Record the implemented version and profile instead of citing whichever editor’s draft a search result happens to return. [3] [6]
For a procurement comparison, that means giving each candidate the same credential format, cryptographic suite, issuer configuration, status mechanism and decision policy. Otherwise, apparent speed can come from doing different work. Document any unavoidable differences as part of the result.
Keep five clocks separate
| Clock | Question | Evidence to retain |
|---|---|---|
| Request elapsed time | How long did this defined path take? | Start/end boundaries, configuration and outcome |
| Credential validity | What validity interval is stated for the credential? | The actual credential fields and applicable verification policy |
| Status-list validity | What interval is stated for the status document? | The status document, version and validity fields |
| Time since status refresh | When was the relevant refresh or revalidation last documented? | Refresh event, response identity and its meaning |
| Decision time | When would the protected action use the result? | A consistent clock basis and the action boundary |
The credential model defines validity and status as separate concerns. Its authorization discussion also leaves authorization rules to the relevant ecosystem. DN therefore records the timing evidence alongside, rather than in place of, the business permission decision. [1]
Do not relabel a validity start as an observation timestamp. Likewise, recording when a file arrived does not establish when an issuer last changed the underlying status. A useful log explains the event each timestamp denotes. Where that explanation is unavailable, keep the freshness conclusion unresolved.
A refresh hint does not extend validity
Bitstring Status List v1.0 defines an optional ttl in milliseconds before a refresh should be attempted. An absent value has no assumed default. The hint does not replace the list’s validity period. The specification also permits a holder to supply a status list, while a verifier may seek a more recent one. [3]
Operationally, this creates separate configuration questions: which refresh policy the verifier follows, which validity limits it enforces and what happens when a dependency cannot be refreshed. Write those answers down before comparing the fast path with the refresh path.
A status service outage is particularly revealing. Does the system return an error, preserve an explicitly limited previous result, request human review or continue as though fresh evidence arrived? The article does not prescribe one universal outage policy. It asks the operator to make that choice visible and test it for the particular action.
HTTP freshness is another layer
RFC 9111 calculates cache freshness from a response’s freshness lifetime and current age. Age calculation accounts for more than the time since the local application received the body. Revalidation can update cache metadata without replacing the representation. These are HTTP rules, not a guarantee about the issuer’s internal status-update process. [4]
DN’s worksheet deliberately does not implement an HTTP cache. Its input is a reviewer’s documented last successful status refresh or revalidation. The computed interval means exactly that: time since the entered event. It does not mean time since revocation, age of the credential’s claims or a measured bound on how quickly an issuer publishes changes.
That distinction matters when a network request succeeds but returns the same list. Preserve what was refreshed, which response was used and the relevant configuration. A green network indicator alone cannot establish that the implementation met its intended evidence policy.
Presentation freshness and status freshness answer different questions
OpenID for Verifiable Presentations 1.0 is a Final specification dated 9 July 2025. Its request nonce binds a presentation to a particular transaction, and its validation requirements depend on the presentation format and holder-binding mechanism. A fresh presentation exchange should not be confused with a freshly checked credential-status dependency. [5]
For example, a verifier can receive a newly produced response while consulting an older cached status document. Conversely, a recently retrieved status document cannot fix a presentation bound to the wrong request. The operational record needs both checks, with separate evidence and outcomes.
Keep raw credentials, subject identifiers and presentation contents out of a public benchmark file. Configuration aliases and permitted evidence references are usually enough to explain the timing experiment. Preserve sensitive source records in the operator’s controlled environment.
Use the DN Credential Check Budget
The instrument compares two declared paths. For each, enter four sequential, non-overlapping durations: transport, proof processing, status processing and policy processing. Enter a common elapsed-time budget, decision timestamp and local refresh interval. A last-refresh timestamp and a status-list expiry can remain unknown.
The tool adds the timing segments, compares the sum with the declared budget and separately reports whether the entered refresh interval has been reached. It also checks the supplied credential and status-list expiry against the decision time. Those date comparisons are partial checks, not credential-verification results.
DN Credential Check Budget
Compare entered sequential timings, refresh intervals and expiry dates. This does not verify credentials, fetch status, implement an HTTP cache or authorize an action.
Use non-sensitive aliases and reference labels. Inputs remain in this page’s temporary memory. Downloading creates a local JSON file; nothing is submitted to DN. All example values are illustrative.
No record has been built. Unknown evidence remains unknown.
View the generated JSON record
For the illustrative example, transport takes four milliseconds, proof processing two and policy processing one. Path A adds no status-request time, producing seven milliseconds. Its last documented refresh was five minutes before the decision. Path B adds 80 milliseconds for status processing, producing 87 milliseconds, with a refresh one second before the decision.
Under the example’s 100-millisecond timing budget, both sums fit. Under its 60-second refresh policy, A is due for refresh and B is within the entered interval. This does not prove B’s issuer state is current, either credential is valid or either route is permitted to execute. It exposes why “seven is faster than 87” is an incomplete procurement conclusion.
What the arithmetic means
Path elapsed time = transport + proof + status + policy. Refresh interval used = decision time − documented refresh time. The local rule marks refresh due when the interval used is greater than or equal to the reader’s interval. An expiry is reached when decision time is at or after the supplied expiry. These boundary conventions are explicit model choices.
Do not sum overlapping spans. If a trace measures proof and status work concurrently, use the actual critical path in a separate analysis. Do not insert the full end-to-end request time into “transport” and then add components already included in it. The acknowledgement in the tool confirms these accounting assumptions; it is not evidence that they are true.
Blank numeric inputs are invalid rather than zero. Unknown refresh or expiry dates remain unknown in the export. Changing any field invalidates the previous result and disables its download until the record is rebuilt. The export preserves input basis, documented source date, formulas, assumptions and the two path results.
Turn a comparison into a defensible measurement
A later empirical test needs an agreed unit of work: one specified presentation format, the same credential set, the same policy and the same status outcome. Keep warm-cache, cold-cache and failed-dependency observations separate. A cache hit and a remote retrieval can both be useful results, but they belong in different rows.
Record unsuccessful attempts as well as successful ones. A path that returns quickly because it rejects every request has different operational value from one completing the expected checks. Similarly, a timeout omitted from a latency report can make the remaining requests look deceptively strong.
Define the population before calculating percentiles. List region, hardware, concurrency, software build, cryptographic suite, status-list size and test window. State whether the reported duration ends at proof verification, policy evaluation or the final protected action. DN has not run that experiment for this article and publishes no percentile or vendor ranking.
For emergency revocation, use the separate kill-switch framework. This worksheet does not estimate containment time or residual spending authority. For general source timestamps, DN’s data-age calculator addresses another question again: age since a declared source event.
Privacy is part of the timing design
W3C’s status-list guidance considers correlation risks and caching, including the risk of an issuer learning where a holder presents a credential. A performance optimization should therefore be reviewed alongside its privacy consequences. [3]
The DN decision is to keep the latency record small. Publish the method and aggregate observations when a real test exists; retain only the references needed to reproduce the conclusion. Avoid turning benchmark transparency into a public directory of credential holders and commercial interactions.
Methodology, limits and corrections
Edition 1.0, 12 November 2026. DN reviewed the primary documents below and designed the worksheet and examples. No issuer, wallet, verifier or trading API was contacted by the instrument. No credential proof, HTTP header, signature, status bit, nonce or authorization policy is verified in the browser.
The worksheet assumes the entered timestamps share a trustworthy clock basis. It does not estimate clock error, infer missing validity limits or reconstruct issuer publication history. A result within an entered budget remains conditional on those assumptions. Use the application’s actual verification and authorization controls for execution.
JSON uses dn.credential-check-budget.v1, version 1.0.0. Inputs stay in the page’s temporary memory; a download creates a local file. The tool makes no network requests and stores no credentials. Use aliases and non-sensitive references. Source-document changes, an implementation correction or contrary reproducible evidence should trigger a new editorial review; no automatic monitoring is claimed.
Change log: initial edition replaces the proposed credential-latency leaderboard with a bounded comparison model. Send corrections with the claim, relevant primary source and reproducible example to press@decentralised.news.
Frequently asked questions
Does the faster path win?
Only on the entered elapsed-time comparison. The status-refresh and expiry results remain separate, and neither path receives an authorization verdict.
Can I paste a credential into this tool?
No credential contents are needed. Enter non-sensitive configuration aliases, timing values and evidence dates instead.
Does a recent refresh prove the issuer has published every change?
No. The tool calculates time since the stated refresh event. Issuer update behavior requires separate evidence.
Why not report a p95 verification time?
That requires a defined sample of actual requests and failures. Two entered paths cannot establish a provider distribution.
Is this a live status monitor?
No. It is a local worksheet. It neither fetches status lists nor schedules checks.
Primary sources
- W3C Verifiable Credentials Data Model 2.0.
- W3C Verifiable Credential Data Integrity 1.0.
- W3C Bitstring Status List v1.0.
- RFC 9111: HTTP Caching.
- OpenID for Verifiable Presentations 1.0.
- W3C Bitstring Status List v1.1, Working Draft, 11 November 2026.
Published schema and illustrative record
The schema documents this instrument’s JSON format. The example below contains constructed illustrative inputs and outputs; it is not a provider measurement, verified case or live dataset. The instrument above creates a separate record from the inputs you choose. These resources do not establish an API or an automatic monitoring service.
JSON Schema — dn.credential-check-budget.v1
Schema version 1.0.0. The schema identifier is a versioned reference, not an asserted network endpoint.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "urn:dn:credential-check-budget:v1:1.0.0",
"title": "DN Credential Check Budget record",
"type": "object",
"additionalProperties": false,
"properties": {
"schemaId": {
"const": "dn.credential-check-budget.v1"
},
"schemaVersion": {
"const": "1.0.0"
},
"instrument": {
"const": "DN Credential Check Budget"
},
"documentationReviewedDate": {
"const": "2026-11-12"
},
"recordCreatedAt": {
"type": "string",
"format": "date-time",
"pattern": "^(?:20\\d{2}|2100)-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\\d|3[01])T(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d\\.\\d{3}Z$"
},
"inputBasis": {
"type": "string",
"enum": [
"illustrative",
"self_reported"
]
},
"inputs": {
"type": "object",
"additionalProperties": false,
"properties": {
"configurationRef": {
"type": "string",
"minLength": 1,
"maxLength": 240
},
"decisionContext": {
"type": "string",
"minLength": 1,
"maxLength": 200
},
"decisionTime": {
"type": "string",
"format": "date-time",
"pattern": "^(?:20\\d{2}|2100)-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\\d|3[01])T(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d\\.\\d{3}Z$"
},
"maxElapsedMs": {
"type": "number",
"minimum": 0.001,
"maximum": 1000000
},
"maxRefreshSeconds": {
"type": "number",
"minimum": 0.001,
"maximum": 31536000
},
"credentialExpiresAt": {
"anyOf": [
{
"type": "string",
"format": "date-time",
"pattern": "^(?:20\\d{2}|2100)-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\\d|3[01])T(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d\\.\\d{3}Z$"
},
{
"type": "null"
}
]
},
"acknowledged": {
"const": true
},
"paths": {
"type": "array",
"prefixItems": [
{
"type": "object",
"additionalProperties": false,
"properties": {
"id": {
"const": "A"
},
"description": {
"type": "string",
"minLength": 1,
"maxLength": 160
},
"timing": {
"type": "object",
"additionalProperties": false,
"properties": {
"transportMs": {
"type": "number",
"minimum": 0,
"maximum": 1000000
},
"proofMs": {
"type": "number",
"minimum": 0,
"maximum": 1000000
},
"statusMs": {
"type": "number",
"minimum": 0,
"maximum": 1000000
},
"policyMs": {
"type": "number",
"minimum": 0,
"maximum": 1000000
}
},
"required": [
"transportMs",
"proofMs",
"statusMs",
"policyMs"
]
},
"lastRefreshAt": {
"anyOf": [
{
"type": "string",
"format": "date-time",
"pattern": "^(?:20\\d{2}|2100)-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\\d|3[01])T(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d\\.\\d{3}Z$"
},
{
"type": "null"
}
]
},
"statusExpiresAt": {
"anyOf": [
{
"type": "string",
"format": "date-time",
"pattern": "^(?:20\\d{2}|2100)-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\\d|3[01])T(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d\\.\\d{3}Z$"
},
{
"type": "null"
}
]
}
},
"required": [
"id",
"description",
"timing",
"lastRefreshAt",
"statusExpiresAt"
]
},
{
"type": "object",
"additionalProperties": false,
"properties": {
"id": {
"const": "B"
},
"description": {
"type": "string",
"minLength": 1,
"maxLength": 160
},
"timing": {
"type": "object",
"additionalProperties": false,
"properties": {
"transportMs": {
"type": "number",
"minimum": 0,
"maximum": 1000000
},
"proofMs": {
"type": "number",
"minimum": 0,
"maximum": 1000000
},
"statusMs": {
"type": "number",
"minimum": 0,
"maximum": 1000000
},
"policyMs": {
"type": "number",
"minimum": 0,
"maximum": 1000000
}
},
"required": [
"transportMs",
"proofMs",
"statusMs",
"policyMs"
]
},
"lastRefreshAt": {
"anyOf": [
{
"type": "string",
"format": "date-time",
"pattern": "^(?:20\\d{2}|2100)-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\\d|3[01])T(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d\\.\\d{3}Z$"
},
{
"type": "null"
}
]
},
"statusExpiresAt": {
"anyOf": [
{
"type": "string",
"format": "date-time",
"pattern": "^(?:20\\d{2}|2100)-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\\d|3[01])T(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d\\.\\d{3}Z$"
},
{
"type": "null"
}
]
}
},
"required": [
"id",
"description",
"timing",
"lastRefreshAt",
"statusExpiresAt"
]
}
],
"items": false,
"minItems": 2,
"maxItems": 2
}
},
"required": [
"configurationRef",
"decisionContext",
"decisionTime",
"maxElapsedMs",
"maxRefreshSeconds",
"credentialExpiresAt",
"acknowledged",
"paths"
]
},
"results": {
"type": "object",
"additionalProperties": false,
"properties": {
"paths": {
"type": "array",
"prefixItems": [
{
"type": "object",
"additionalProperties": false,
"properties": {
"id": {
"const": "A"
},
"elapsedMs": {
"type": "number",
"minimum": 0,
"maximum": 4000000
},
"elapsedBudgetStatus": {
"type": "string",
"enum": [
"within_entered_budget",
"exceeds_entered_budget"
]
},
"elapsedBudgetRemainingMs": {
"type": "number",
"minimum": -4000000,
"maximum": 1000000
},
"secondsSinceEnteredRefresh": {
"anyOf": [
{
"type": "number",
"minimum": 0,
"maximum": 3200000000
},
{
"type": "null"
}
]
},
"refreshStatus": {
"type": "string",
"enum": [
"unknown",
"refresh_due_under_entered_policy",
"within_entered_refresh_interval"
]
},
"statusExpiryStatus": {
"type": "string",
"enum": [
"unknown",
"entered_expiry_reached",
"entered_expiry_not_reached"
]
}
},
"required": [
"id",
"elapsedMs",
"elapsedBudgetStatus",
"elapsedBudgetRemainingMs",
"secondsSinceEnteredRefresh",
"refreshStatus",
"statusExpiryStatus"
]
},
{
"type": "object",
"additionalProperties": false,
"properties": {
"id": {
"const": "B"
},
"elapsedMs": {
"type": "number",
"minimum": 0,
"maximum": 4000000
},
"elapsedBudgetStatus": {
"type": "string",
"enum": [
"within_entered_budget",
"exceeds_entered_budget"
]
},
"elapsedBudgetRemainingMs": {
"type": "number",
"minimum": -4000000,
"maximum": 1000000
},
"secondsSinceEnteredRefresh": {
"anyOf": [
{
"type": "number",
"minimum": 0,
"maximum": 3200000000
},
{
"type": "null"
}
]
},
"refreshStatus": {
"type": "string",
"enum": [
"unknown",
"refresh_due_under_entered_policy",
"within_entered_refresh_interval"
]
},
"statusExpiryStatus": {
"type": "string",
"enum": [
"unknown",
"entered_expiry_reached",
"entered_expiry_not_reached"
]
}
},
"required": [
"id",
"elapsedMs",
"elapsedBudgetStatus",
"elapsedBudgetRemainingMs",
"secondsSinceEnteredRefresh",
"refreshStatus",
"statusExpiryStatus"
]
}
],
"items": false,
"minItems": 2,
"maxItems": 2
},
"elapsedDifferenceAMinusBMs": {
"type": "number",
"minimum": -4000000,
"maximum": 4000000
},
"fasterEnteredPath": {
"type": "string",
"enum": [
"equal",
"A",
"B"
]
},
"credentialExpiryStatus": {
"type": "string",
"enum": [
"unknown",
"entered_expiry_reached",
"entered_expiry_not_reached"
]
},
"credentialValidityDetermined": {
"const": false
},
"authorizationDetermined": {
"const": false
},
"issuerStateFreshnessEstablished": {
"const": false
}
},
"required": [
"paths",
"elapsedDifferenceAMinusBMs",
"fasterEnteredPath",
"credentialExpiryStatus",
"credentialValidityDetermined",
"authorizationDetermined",
"issuerStateFreshnessEstablished"
]
},
"sources": {
"const": [
{
"id": 1,
"url": "https://www.w3.org/TR/vc-data-model-2.0/"
},
{
"id": 2,
"url": "https://www.w3.org/TR/vc-data-integrity/"
},
{
"id": 3,
"url": "https://www.w3.org/TR/vc-bitstring-status-list/"
},
{
"id": 4,
"url": "https://www.rfc-editor.org/info/rfc9111/"
},
{
"id": 5,
"url": "https://openid.net/specs/openid-4-verifiable-presentations-1_0.html"
},
{
"id": 6,
"url": "https://www.w3.org/TR/2026/WD-vc-bitstring-status-list-1.1-20261111/"
}
]
},
"limitations": {
"const": [
"Timing segments must be sequential and non-overlapping; no request is executed or timed by this tool.",
"Refresh age means time since the entered successful refresh/revalidation event, not issuer-state age or revocation propagation.",
"The refresh boundary is inclusive: elapsed interval greater than or equal to the entered policy means refresh due.",
"Expiry is treated as reached at or after the entered UTC timestamp. Missing dates remain unknown.",
"Only expiry comparisons are performed; proof, status, validFrom, issuer trust, holder binding and authorization are not verified.",
"No HTTP cache semantics are implemented. Clock synchronization and event meanings are reader assumptions.",
"Accepted timestamps use a strict UTC subset for years 2000–2100; leap seconds are not supported.",
"Inputs remain local; the record is neither a provider benchmark nor permission to act."
]
}
},
"required": [
"schemaId",
"schemaVersion",
"instrument",
"documentationReviewedDate",
"recordCreatedAt",
"inputBasis",
"inputs",
"results",
"sources",
"limitations"
]
}Illustrative example JSON record
This fixed example is published for inspection and integration testing. Its record timestamp is not an evidence-verification timestamp.
{
"schemaId": "dn.credential-check-budget.v1",
"schemaVersion": "1.0.0",
"instrument": "DN Credential Check Budget",
"documentationReviewedDate": "2026-11-12",
"recordCreatedAt": "2026-11-12T12:00:00.000Z",
"inputBasis": "illustrative",
"inputs": {
"configurationRef": "Illustrative single-format verifier; no operational measurements",
"decisionContext": "Supplier credential before a hypothetical purchase",
"decisionTime": "2026-11-12T12:00:00.000Z",
"maxElapsedMs": 100,
"maxRefreshSeconds": 60,
"credentialExpiresAt": "2026-11-12T13:00:00.000Z",
"acknowledged": true,
"paths": [
{
"id": "A",
"description": "Illustrative cached path",
"timing": {
"transportMs": 4,
"proofMs": 2,
"statusMs": 0,
"policyMs": 1
},
"lastRefreshAt": "2026-11-12T11:55:00.000Z",
"statusExpiresAt": "2026-11-12T13:00:00.000Z"
},
{
"id": "B",
"description": "Illustrative refresh path",
"timing": {
"transportMs": 4,
"proofMs": 2,
"statusMs": 80,
"policyMs": 1
},
"lastRefreshAt": "2026-11-12T11:59:59.000Z",
"statusExpiresAt": "2026-11-12T13:00:00.000Z"
}
]
},
"results": {
"paths": [
{
"id": "A",
"elapsedMs": 7,
"elapsedBudgetStatus": "within_entered_budget",
"elapsedBudgetRemainingMs": 93,
"secondsSinceEnteredRefresh": 300,
"refreshStatus": "refresh_due_under_entered_policy",
"statusExpiryStatus": "entered_expiry_not_reached"
},
{
"id": "B",
"elapsedMs": 87,
"elapsedBudgetStatus": "within_entered_budget",
"elapsedBudgetRemainingMs": 13,
"secondsSinceEnteredRefresh": 1,
"refreshStatus": "within_entered_refresh_interval",
"statusExpiryStatus": "entered_expiry_not_reached"
}
],
"elapsedDifferenceAMinusBMs": -80,
"fasterEnteredPath": "A",
"credentialExpiryStatus": "entered_expiry_not_reached",
"credentialValidityDetermined": false,
"authorizationDetermined": false,
"issuerStateFreshnessEstablished": false
},
"sources": [
{
"id": 1,
"url": "https://www.w3.org/TR/vc-data-model-2.0/"
},
{
"id": 2,
"url": "https://www.w3.org/TR/vc-data-integrity/"
},
{
"id": 3,
"url": "https://www.w3.org/TR/vc-bitstring-status-list/"
},
{
"id": 4,
"url": "https://www.rfc-editor.org/info/rfc9111/"
},
{
"id": 5,
"url": "https://openid.net/specs/openid-4-verifiable-presentations-1_0.html"
},
{
"id": 6,
"url": "https://www.w3.org/TR/2026/WD-vc-bitstring-status-list-1.1-20261111/"
}
],
"limitations": [
"Timing segments must be sequential and non-overlapping; no request is executed or timed by this tool.",
"Refresh age means time since the entered successful refresh/revalidation event, not issuer-state age or revocation propagation.",
"The refresh boundary is inclusive: elapsed interval greater than or equal to the entered policy means refresh due.",
"Expiry is treated as reached at or after the entered UTC timestamp. Missing dates remain unknown.",
"Only expiry comparisons are performed; proof, status, validFrom, issuer trust, holder binding and authorization are not verified.",
"No HTTP cache semantics are implemented. Clock synchronization and event meanings are reader assumptions.",
"Accepted timestamps use a strict UTC subset for years 2000–2100; leap seconds are not supported.",
"Inputs remain local; the record is neither a provider benchmark nor permission to act."
]
}
