I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document is Almost Ready.

* The security issue outlined in section 13.5 ("Dishonest clients") adequately justifies maintaining confidentiality of the full list of revoked hashes, or at least of recent additions to the list, without reference to privacy as mentioned in section 13.1. The privacy issues posed by hashes of tokens that are not widely distributed or visible to passive observers are not at all clear to me.

* Furthermore, doesn't the security issue identified in 13.5 imply that only RSes should be notified of revocations, and clients left to wonder until their requests are denied, or at least until after the RSes to which the token is relevant have been notified? Secrecy matters really only because we want to prevent bad actors with access to the token from taking advantage of it during the window between revocation and RSes being aware of that revocation: if you notify the bad actor proactively, it doesn't really matter that you kept it secret from other nefarious observers. (Note that changing this would require the changes to the recommendation from 13.4.)

    For what it's worth, this is not a novel problem, and it is one that plagues revocation systems in general. Moreover, all the possible approaches are unsatisfying in some way, often relying on assumptions about the state of mind/intent or expected behavior of the adversarial actor.

* I do not understand the criteria specified for purging hashes of revoked tokens in section 10.1. In particular, why is the first criteria required? If an RS never sees a particular token, this implies the hash would be kept forever, or at least until memory pressure is encountered. Should the RS not also be allowed to expunge a hash if the TRL endpoint signals removal via expiry? At that point the token would be invalid anyway, revoked or not.

Other comments:

* I did not review the properties of, or analyze the correctness of, the database consistency algorithm and associated update protocol used to keep registered devices up-to-date with relevant token hashes. I do not know if this algorithm and protocol were based on something specific, so if that is not the case then my main observation would be that the consistency requirements here are not unique to the proposed revocation function, so it may be worth reviewing literature relevant to the problem space associated with database view consistency across distributed and intermittently-connected devices to see if there is something more generic that can be leveraged in solving this problem.

* I also did not review any of the appendices.