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
