Hello, I've taken a look at the document. There are some things that confuse me.
First off section 1.3 isn't something I've seen in other IETF documents. I do think it's a good idea. The allocation of status types in the registry has implications, and I don't think they are the right ones. First it implies that any application that uses 2 bits has only one application defined status available. Why not always make it application defined and say "here is the default that is useful"? On that note I don't get temporary expiry: why not reissue in those cases? I do like the thoroughness of the security considerations section. Perhaps a .well-known URL should be suggested to avoid a tracking vector. I think we should strongly recommend partitioning status lists by expiry of issued tokens. This makes retirement much easier. X509 CRLs weren't that bad a representation of a list of revocations, especially when a small number were revoked. The reasons that environment failed were more complex. I think we should put text in encouraging short lived tokens instead. Sincerely, Watson -- Astra mortemque praestare gradatim _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
