By: Tom Sydney Kerckhove <syd@cs-syd.eu>
Answer a held key without waiting for a fetch, and accept an unnamed key Two things a resource server gets wrong in the same place. The key set was one MVar used as both the state and the lock a fetch is made under. Taking it to fetch empties it, so every read blocked for as long as that fetch took: a token naming a key the issuer published long ago waited on an issuer it needed nothing from. The state is now a TVar that is read without waiting, and the lock is an MVar of its own, so concurrent requests still make one request to the issuer. The second look under the lock is what lets a request that queued behind a fetch be answered by it rather than find the keys unchanged and be told the issuer was asked too recently to ask again. A token whose header named no key was refused outright. RFC 7515 makes that header optional, and an issuer publishing exactly one key has already said which key signed its tokens, so refusing them meant refusing every token such an issuer mints. keyFor now resolves an unnamed key when there is exactly one to resolve it to, and still refuses with none or several rather than trying each in turn, which is the guessing that naming a key exists to avoid.