On Wed, Aug 23, 2023 at 10:02 AM David Waite <da...@alkaline-solutions.com> wrote:
> > On Aug 23, 2023, at 10:16 AM, Watson Ladd <watsonbl...@gmail.com> wrote: > > > > On Wed, Aug 23, 2023, 3:35 AM Daniel Fett <m...@danielfett.de> wrote: > >> > >> Hi Watson, > >> > >> can you please be specific about the "standard, 22 year old security > >> definitions" and "schemes of this type"? > >> > >> Not having to make assumptions would certainly help to have a useful > >> discussion. > > > > Unlinkability as defined in CL01 > > (https://link.springer.com/chapter/10.1007/3-540-44987-6_7) . The > > security considerations section of the draft does explicitly admit > > this shortcoming. > > Could you elaborate more on what you think is standard (and in what context) > and what do you consider “schemes of this type” > > For example, are you talking about properties for anonymous credentials from > the academic space as set by [Chaum85] or perhaps [CL01]? Or maybe are you > talking toward some existing requirements specified by a regulated space? > > Assuming you are speaking primarily to multi-use unlinkability, there are > efforts within the broader IETF ecosystem around that - such as an effort to > describe BBS usage within the CFRG, and proposals/efforts to leverage that > within privacypass and jose. Those obviously will not have the benefit of > being able to be implemented on top of broadly available and accepted > cryptographic operations. I would refer to these as trade-offs rather than > shortcomings. Why should users accept worse privacy just because it means we can use "accepted" cryptographic operations? It's a tradeoff where the costs that are most salient to decision makers (the need for "acceptability", e.g. their own ability to make decisisons) are at odds with the privacy cost to users, and where it ultimately rests on an illusion that primitives matter most. As for availability it really doesn't take many implementations to have enough for almost all purposes, and those who aren't served can make their own. We learnt long ago in TLS that providing one good option and many bad ones was not a good idea, as people will use the bad ones. I'd like us not to make the same mistake here. Sincerely, Watson Ladd > > -DW -- Astra mortemque praestare gradatim _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
