[insanitybit]

You don't have to revoke a key as soon as it is rotated. If you rotate every week you can have a job that runs every week, offset by one day, to revoke.

[withinboredom]

Right, but there’s no way to do that on the same day every year, or even the “first Tuesday of every June” because that may or may not always fall within a year.

Also, these tokens have to be rotated by a human. So weekly is way too often.

[insanitybit]

> Right, but there’s no way to do that on the same day every year, or even the “first Tuesday of every June” because that may or may not always fall within a year.

Why would that matter?

[withinboredom]

Because we are humans. If I say “see you in a year” that doesn’t mean a year to the second.

[insanitybit]

I don't understand the problem here. You can have a separate revocation schedule.

[withinboredom]

If you don’t understand it, you must not work with a lot of humans doing human things. Ask a bunch of friends that don’t work with computers what today, plus one year is. You’ll hear everything from “365 days” to today’s date next year to 365.25 days. At no point do you hear the current time, on this date.

So if lots of things go wrong that you are having to rotate this in a year, you are doomed to fail because there’s also a time stamp on it. There’s no grace period, so things will break.

If there’s a revocation system, there’s no reason for a hard expiration of the token is still being used.

[insanitybit]

A grace period would not solve anything. If it were "one year and one day" you'd have the same exact problem.

Revocation and expiration are virtually the same thing.

[robertlagrant]

> If you rotate every week you can have a job that runs every week, offset by one day, to revoke.

This might be a silly question, but how do you authenticate that revoke?

[insanitybit]

Usually tokens have the right to revoke themselves or you have a separate system like Vault that manages revocation.