Certificate caching without stale trust

What the public implementation shows

SIPS Connect exposes a certificate download service and cache tests alongside the XAdES certificate interfaces used during message verification.

The cache sits between time-sensitive payment processing and an external repository that supplies participant trust material. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleA certificate cache is safe only when freshness and failure behavior are designed with it.

The decision behind the mechanism

Caching reduces repeated repository calls, but the service boundary preserves one place to define lookup identity, expiry, refresh, and unavailable-source behavior.

An unbounded cache can continue accepting revoked or replaced trust material; a cacheless design can make every payment depend on a remote lookup. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Key cached entries by the same identity used in verification.
• Apply bounded lifetime and explicit refresh behavior.
• Reject ambiguous or invalid certificate responses.
• Measure cache and repository outcomes separately.

How the control should be operated

Certificate retrieval should record source, lookup key, cache result, expiry, and refresh failure while never persisting private material.

That evidence lets operations separate repository outages from invalid participant signatures. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.