On Thu, Jan 16, 2025 at 12:49 AM Christian Bormann <chris.borm...@gmx.de> wrote: > > 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:
Thanks and sorry to have completely missed this was happening. > > > > 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. My consideration here is just about the cost in bits. 1 bit status- easy, everyone gets the same thing, wanted it. 2 bit status - by only defining one of them in the application, we force any application with 2 defined statuses up to 4 bit status symbols. Feels like a waste. > > > > > > 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 would use it to restrict the freedom in the status URL. Honestly the mechanisms here are not going to be that private: having the Holder show nonmembership is a lot better. > > > > > > 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? It's more advice on how to set them up, which that sentance doesn't give. > > > > > > 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. Thanks! > > > > 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 > > -- Astra mortemque praestare gradatim _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
