At the risk of drawing oauth chairs ire.... and only because I happened to be reading this thread w/ chagrin.
No one thinks that SD-JWT is a perfect answer to the problem. It isn't. Sadly the perfect solution doesn't exist. So as we make our way to better and better solutions, let us take this next step. [How do you eat an elephant? one bite at a time.] What is needed: Either a paragraph in Privacy Considerations and/or Security Considerations that outlines the shortfalls. Something short, sweet, and to the point. Preferably something that uses the current draft terminology (Holder, for example). K? I hope you all have happy holidays. Deb Sec AD On Tue, Dec 24, 2024 at 8:00 AM Brian Campbell <bcampbell= 40pingidentity....@dmarc.ietf.org> wrote: > I take serious exception to just about everything you've said here. > > You have been given multiple opportunities, and even encouragement, to > contribute text on the subject. That what you've proposed hasn't been well > received in no way makes it acceptable to level such accusations towards > me. > > > > On Sun, Dec 22, 2024 at 1:36 PM Watson Ladd <watsonbl...@gmail.com> wrote: > >> On Sun, Dec 22, 2024, 2:35 PM Brian Campbell >> <bcampbell=40pingidentity....@dmarc.ietf.org> wrote: >> > >> > >> > >> > On Sat, Dec 21, 2024 at 1:37 PM Joseph Heenan <jos...@authlete.com> >> wrote: >> >> >> >> >> >> < ... snip ... > >> >> >> >> The current text is clear that there are situations where >> issuer-verifier linkability can’t be fully prevented. >> >> >> >> Process wide, I believe if you think the text currently in the >> specification is inadequate, you need to make a concrete suggestion that >> doesn’t introduce new problems and hence can gain consensus with working >> group members. >> >> >> > >> > I believe this kinda gets at the heart of things here. It does for me >> anyway. There are indeed some legitimate and not obvious or intuitive >> privacy considerations inherent in salted-hash based selective disclosure >> mechanisms like SD-JWT (also SD-CWT, ISO mdoc/mDL, and probably others I'm >> unaware of) that deserve serious treatment in a prospective RFC. The >> authors on this draft have endeavored to provide thoughtful treatment of >> the topic(s) and believe that the current text, while obviously not >> perfect, is reasonably clear and provides sufficient discourse on the >> subject(s). Watson feels otherwise, which is a completely reasonable >> viewpoint. However, at this stage of things especially, I believe it is >> incumbent on him to provide a concrete suggestion that doesn't introduce >> new/unwanted problems and can be viewed as at least acceptable as rough >> consensus of the working group. This thread and several others of a very >> similar vein over the last few months suggests that, from my perspective as >> both draft author and WG participant anyway, the various proposals don't >> meet that bar. >> >> Brian, >> >> I strongly object to our with your procedural summaries. I think it's >> an underhanded way to admit that the current text is inadequate while >> excusing inaction on your part as draft author, and try to ape the >> authority of the WG chairs. That's a bit besides the real point, but >> I do want to register my profound unease with this rhetorical >> strategy. >> >> Nobody here, including you here disagrees that there are subtle issues >> that deserve careful treatment. I think, and IETF wide consensus has >> said that the place for those considerations is in the security >> considerations and privacy considerations of this draft. We don't >> sweep those problems under the rug anymore. Saying we need another RFC >> is saying "go spend x years trying to get this work that this group >> isn't interested in done somewhere while I throw roadblocks in your >> way, and real users face harms that we couldn't be arsed to put one >> paragraph in talking about". TLS 1.3 didn't just have a securities >> consideration section, it had 3 entire appendices going into careful >> detail about what it does and doesn't do, how to work around it, etc. >> >> The fact that you and everyone else feels content to shoot down text >> rather than try to meet me halfway shows that this isn't an honest >> attempt to achieve rough consensus or conversely say my views are in >> the rough because of actually thinking through the issue. I've been >> consistent in raising this issue for over a year: to pretend that the >> WGLC is at all relevant to where we are is a ridiculous excuse made >> possible only by your own inaction on this issue. I've tried to tweak >> the text to make it work better, at length, but it's very hard when >> people say they have concerns without being clear or suggesting >> alternatives. I'd appreciate you doing me the same courtesy, rather >> than sitting back and saying "nah, no one agrees enough for us to >> handle it". I agree that my text may be too limiting or overly >> prescriptive, but the people closer to the problem need to provide >> input if there is going to be a text we can live with. >> >> The only reason this is still an issue is refusal to address it: to >> add a clear description of what the issuer-verifier linkability >> problem means in practice together with actionable mitigations. Why >> hasn't that happened? Secondly the verifier-verifier unlinkability >> really doesn't have much in the way of actual mitigations: it says you >> can use one-use credentials, etc. but doesn't mandate, provide >> designs, explain how to issue based on a previous credential etc. It >> at least has that material. >> >> To be absolutely clear, this is what the current text says in its most >> relevant section "In considering Issuer/Verifier unlinkability, it is >> important to note the potential for an asymmetric power dynamic >> between Issuers and Verifiers. This dynamic can compel an otherwise >> honest Verifier into collusion. For example, a governmental Issuer >> might have the authority to mandate that a Verifier report back >> information about the credentials presented to it. Legal requirements >> could further enforce this, explicitly undermining Issuer/Verifier >> unlinkability. Similarly, a large service provider issuing credentials >> might implicitly pressure Verifiers into collusion by incentivizing >> participation in their larger ecosystem. Deployers of SD-JWT must be >> aware of these potential power dynamics, mitigate them as much as >> possible, and/or make the risks transparent to the End-User." >> >> That text has a lot of problems: >> >> - It presents the issue as one of coercion or malfeasance, rather than >> e.g. excessive logging, or some other information leak letting the >> issuer see what the verifier knows. >> - It says deployers must mitigate the power dynamics, rather than use >> technical means, with no real guidance as to what that mitigation >> looks like >> - It doesn't say what the risks are that must be made transparent >> >> It's not something that someone can use to say "no, we shouldn't do X" >> for any X. >> >> All I've been asking to add now is a specific example of what a user >> might need to know and that if this can't be achieved, don't use >> SD-JWT. I'm surprised by the enormous pushback to this. All I want to >> know is is there some form of this we could live with, or what are the >> concrete issues people have with the proposal. So far I've gotten that >> actually naming mitigations is a problem. How on earth do I work with >> that? >> >> Conversely, if you think age verification with SD-JWT is fine, save me >> the time and let me know. >> >> Sincerely, >> Watson >> > >> > >> > >> > >> > CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited. >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you._______________________________________________ >> > OAuth mailing list -- oauth@ietf.org >> > To unsubscribe send an email to oauth-le...@ietf.org >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*_______________________________________________ > 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
