Assess risk
Assess current evidence algorithms, parameters, TSA certificates and policy conditions; do not impose one schedule on every record.
MOBILE-ID · TRUSTED LTANS
Renewal & Crypto-Agility
Assess risks and select timestamp or hash-tree renewal before required protection conditions are lost.
| Decision | Input | Result |
|---|---|---|
| Timestamp renewal | Previous evidence; tree hash remains suitable. | New archive timestamp in the applicable chain. |
| Hash-tree renewal | Original data and prior evidence under the processing model. | Rehash, new tree, new timestamp and new chain. |
Hash-Tree Renewal requires access to the archived data and prior evidence required by the applicable Evidence Record processing model.
Outcome and scope
Maintain evidence continuity before required protection conditions are lost, with a traceable renewal decision.
Documentation scope Workflow design and integration contract; operational configuration is confirmed per environment.
| Prepare | Receive |
|---|---|
| Evidence due for review; changes in algorithms, certificates or trust policy. | A new evidence version retains historical links and post-renewal verification. |
Participants: Cryptographic-policy owners, approvers and renewal operators.
Workflow and decision points
Choose mode
Distinguish timestamp and hash-tree renewal. For hash-tree renewal, verify access to original data and prior evidence before approval.
Pin starting revision
Pin the starting evidence revision so concurrent renewals cannot silently publish conflicting histories.
Validate continuity
Verify the result, retain previous/next linkage and update the next review under the applied policy.
States, guards and authority
| Current | Guard | Actor | Next | Artifact / recovery |
|---|---|---|---|---|
| DUE / ASSESSED | Required data and mode-specific approval available | Renewal + approver | APPROVED | Retain mode, source revision, algorithm and approvalId. |
| APPROVED | Pin starting revision before execution | Renewal Service | RUNNING / BLOCKED_DATA_ACCESS | HASH_TREE without bytes blocks; do not switch to TIMESTAMP to evade the guard. |
| RUNNING | Continuation validates and is persisted | Renewal + Evidence | COMPLETED / FAILED | Update schedule only after publication; retain history/checkpoints on failure. |
Exceptions and controls
| Situation | Action | Boundary |
|---|---|---|
| Tree hash no longer suitable | Evaluate hash-tree renewal under its processing profile. | Do not substitute timestamp renewal merely to avoid data access. |
| Original data unavailable | Block the data-dependent operation and notify its owner. | Retain BLOCKED_DATA_ACCESS in the target business workflow. |
| TSA outage | Bound retries or use an approved fallback. | Publish only after verification and retain prior evidence. |
Authorization, approval and recovery
Timestamp renewal extends a chain while its tree hash remains suitable. Hash-tree renewal reprocesses original data and prior evidence with a secure algorithm and starts a new chain.
If data is unavailable, block hash-tree renewal, notify its owner and restore access before retry; never relabel it as successful renewal.
Reconciliation artifacts and acceptance
Record reason, mode, old/new algorithms, original-data access, approval and outcome; reconcile all due objects.
- Hash-tree renewal with revoked data access must block; restore rights and reconcile the job before resuming.
- Changing mode, algorithm or starting revision requires a distinct decision and validation result.
Integration and data contract
| API | Application scope | Documentation |
|---|---|---|
| POST /v1/renewals | renewals:write | Renewal API |
GET /v1/renewals/{renewalId} | renewals:read | Renewal API |
Technical input and references
| Element | Definition |
|---|---|
| Input | Current evidence version, algorithm risk assessment, renewal mode and original-data access when required. |
| Output | New evidence version, renewal decision, verification result and linkage to the full history. |
Choose mode and handle missing inputs
| Condition | Decision | Stop condition |
|---|---|---|
| Hash remains suitable; timestamp protection needs renewal. | Evaluate TIMESTAMP under profile. | Do not build on unverified tokens. |
| Assessed risk requires a new hash/tree. | Evaluate HASH_TREE with originals and prior evidence. | Missing bytes/decryption/prior evidence blocks execution; no mode switch to hide failure. |
| Chain protection prerequisites have already been lost. | Assess limits, retain results and escalate. | New renewal does not retroactively repair old gaps. |
Execute and reconcile a scenario
| Element | Action |
|---|---|
| Synthetic ID | ren-test-001 |
| Task | Assess risk → choose TIMESTAMP or HASH_TREE → check inputs → approve. |
| Acceptance case | Revoking BYOS reads before HASH_TREE stops work; do not switch modes to hide failure. |
These are business test criteria; synthetic packages alone do not establish backend execution or valid ERS.
Next steps
