Revocation may require a lot of processing at Relay(s)

[gwendalsimon]

When a service provider wants to revoke a user, the revocation system should update the denylist of all Relays. Typically adding a token ID (e.g., cti) to a local database. Yet, in moQ, a Relay is expected to maintain a list of "validated tokens" associated with some established connections (WebTransports) and to continue streaming to these connections, until revalidation of the token.

At the reception of an update in the denylist, the Relay should parse all existing validated tokens to check whether it should be denied. It may be a significant processing task.

Not sure how to fix it.

One option would be for the token issuer to indicate, in the token, the claim that is expected to be used for denial (it may be cti, but also some other claims), so that the Relay may store all validated token in a HashTable with the said claim in key.

[wilaw]

I think we should indicate that if you intend to revoke tokens, you MUST include a cti claim. The relay can then store the CTI against that session and easily match it against a denylist update.

At the reception of an update in the denylist, the Relay should parse all existing validated tokens to check whether it should be denied. It may be a significant processing task.

The relay does not have to re-parse tokens it has already parsed. It parses them once upon receipt and stores the CTI as metadata against that session.