Why 120 seconds: trust on a lease

Reading the Draft · No. 4 · Source: draft-li-rttp-iqa-addressing-00 §6.2 · Reference specification AICENT-009 · Sister pillars: rttp:// (CRI 27) · iqa:// (CRI 28)

The fourth reading of this specification stops at an almost reflexive point: "120 seconds — why that number? Who decided? Isn't it too short?" Before answering, look at two more fundamental positions the merged document takes in Section 6.2: "Replay across epochs" — standing material is rotated on a defined cycle, so "a previously valid answer can become invalid without any change to the URI; a client MUST NOT treat a cached answer as current indefinitely"; and "Silence is not assent" — "An endpoint that is unreachable, times out, or returns an error MUST NOT be read as affirmative standing: absence of evidence is not evidence of compliance."

Together these two state one thing: the time-boundedness of trust is not an optional add-on for us — it is a premise of the system. Once you accept that a revoked or compromised subject's old answer must lapse, you must answer "how fast" — and any answer bounded by a rotation cycle is, in essence, a lease. 120 seconds is the concrete graduation of that lease; its precise definition lives in the reference specification AICENT-009. The merged document deliberately does not repeat it (Section 9.2: "The scheme defines addressing and client behaviour only; it does not define a transport, a discovery mechanism, or the attestation algorithm").

Why is short the right direction? Compare three reference points: TLS certificates are counted in years, with revocation patched after the fact via CRL/OCSP — revocation lag counted in days. The IETF Agent Identity Protocol draft candidly concedes its revocation cache: "In the worst case, a revoked agent can continue making calls for up to 60 seconds after revocation." IQA's lease turns the direction around: instead of cleaning up after a revocation propagates, expiry happens before residue can exist — lapse into ghost, and ghost does not resurrect from any cache.

And the cost of short? Verifiers must re-acquire answers more often. Two facts absorb that cost: first, the default read operation is SAFE-class in the specification (Section 5.4: omitting the action means "read the current standing," read-only); second, verification is locally completable — the offline position has always been that the verifier owes nobody anything. Asking every 120 seconds is asking a question a local computation can answer.

One line: 120 seconds is not trust's lifespan; it is trust's re-pricing interval — we demote "was trustworthy" from an asset to a state that must be continuously renewed, because that is how a subject's trustworthiness should be measured in the real world anyway.