NSURLCredentialPersistencePermanent lacks built‑in client‑side expiration

When using NSURLCredentialPersistencePermanent the credential is written to the user Keychain, but Foundation does not attach an expiration timestamp or automatically purge the entry when the server later rejects it.

The URL Loading System will replay the stored credential for subsequent challenges until a 401 forces the delegate to react, and removal via removeCredential:forProtectionSpace: does not instantly invalidate in‑flight connections. App Sandbox and Keychain Access Groups further limit visibility across processes.

Developers must decide how to track a client‑side TTL, coordinate invalidation across sessions, and whether to rely on Keychain change notifications.

• What pattern ensures timely invalidation without a custom timestamp store?
• How can removal be coordinated across multiple processes sharing the same protection space?
• Are there OS‑level notifications for Keychain entry changes that can trigger refresh?