Hi Watson, > 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. That is definitely something we are considering, but so far, most people that wanted to use more than 1 bit were asking about “suspended” Our main concern was to keep things interoperable if “suspended” is the main feature people are looking for more values. Paul, Tobias and me had a discussion about this yesterday to process the discussion from the interim meeting and are currently still leaning towards keeping suspended registered, but add additional context and privacy considerations (which was brought up in the interim meeting if the decision was to keep it) > 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. The mechanism was designed in a way to also allow hosting by other parties (e.g., CDNs) - forcing well-known URLs would prevent that. The content is also not very static so probably not a good fit to .well-known in general? Regarding the privacy properties: I fully agree and I hope we can introduce and use better mechanisms in the future, but this seemed to be the most usable & best scaling mechanism right now (without more required changes like other proofs etc.). > It's more advice on how to set them up, which that sentance doesn't give. Does https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/230 work for you? Best Regards, Christian On 17.01.25, 01:54, "Watson Ladd" <watsonbl...@gmail.com> wrote: 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
