Hi Watson, We tried to bring your points into the OAuth interim meeting. Here my attempt to reflect the major parts of the discussion that happened there and the perspective from the editors: 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? There was some discussion around this and especially the status type “suspended”. We tried to summarize everything in this issue https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/222. Our current perspective is that we think some pre-defined values are important to guarantee interoperability. The minimum that needs to be pre-defined would imho be valid and invalid. Suspended was a value that came up several times in discussions, but we agree that if that value is kept as a pre-defined value, it should be accompanied by privacy considerations. I do like the thoroughness of the security considerations section. Perhaps a .well-known URL should be suggested to avoid a tracking vector. Could you elaborate where exactly you would use a .well-known URL? I think we should strongly recommend partitioning status lists by expiry of issued tokens. This makes retirement much easier. We expect this to happen automatically to certain degrees when using status list. We also had concerns that focusing a lot on partitioning might create correlation issues and therefore would not “strongly” recommend it. The draft currently states “The lifetime of a Status List Token depends on the lifetime of its Referenced Tokens. Once all Referenced Tokens are expired, the Issuer may stop serving the Status List Token.” which we thought provides enough guidance? 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. We created an issue (https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/223). We expect a lot of use-cases to have rather short-lived credentials which also makes the handling of a possible status a lot easier. It makes sense to be a bit more explicit about it. Best Regards, Christian On 02.01.25, 22:49, "Watson Ladd" <watsonbl...@gmail.com> wrote: 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 |
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
