As said I offer it as a starting point. There might be some value in the existing text, but I found it distracted from clear presentation of the problem. What's the problem with using MUST? We have to give people who use these documents clear guidance.
I think the tautology is obvious: if SD-JWT doesn't offer the property X that is required, it MUST NOT be used when X is required. and that's exactly what should appear. On Wed, Jul 31, 2024, 4:58 PM Brian Campbell <bcampb...@pingidentity.com> wrote: > > I guess I had envisioned suggestions that didn't delete a bunch of existing > valuable and useful text. Rather I was expecting (or maybe just hoping) for > thoughtful suggestions adding to what's already written that, as I'd said, > better frame the risks and difficulties around Issuer/Verifier Unlinkability > (perhaps especially with respect to something like a government issuer > compelling collusion from verifiers). I'm also not a big fan of broad strokes > RFC 2119 language in privacy considerations. > > On Wed, Jul 31, 2024 at 11:31 AM Watson Ladd <watsonbl...@gmail.com> wrote: >> >> I've opened >> https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/448 >> as a step torwads this. >> >> On Wed, Jul 31, 2024 at 5:31 AM Brian Campbell >> <bcampb...@pingidentity.com> wrote: >> > >> > >> > >> > On Tue, Jul 23, 2024 at 11:15 AM Leif Johansson <le...@mnt.se> wrote: >> >> >> >> On Mon, 2024-07-22 at 19:43 -0400, Richard Barnes wrote: >> >> > I would observe that any solution based on garden-variety digital >> >> > signature (not something zero-knowledge like BBS / JWP) will have >> >> > problems with issuer/verifier collusion. One-time tokens and batch >> >> > issuance don't help. There is no such thing as SD-JWT with >> >> > issuer/verifier collusion resistance. At best you could have SD-JWP. >> >> > >> >> > I don't think this needs to be a blocker on SD-JWT. There are use >> >> > cases that don't require issuer/verifier collusion resistance. We >> >> > should be clear on the security considerations and warn people away >> >> > who care about issuer/verifier collusion resistance, and accelerate >> >> > work on SD-JWP if that's an important property to folks. >> >> > >> >> >> >> >> >> +1 on this >> > >> > >> > I'm generally a +1 on this too. There is an attempt at a discussion >> > around unlinkablity in the privacy considerations at >> > https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-unlinkability >> > currently. Concrete suggestions to that text about how to better frame >> > the risks and difficulties around Issuer/Verifier Unlinkability (perhaps >> > especially with respect to something like a government issuer compelling >> > collusion from verifiers) would be welcome for consideration. >> > >> > 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. >> >> >> >> -- >> Astra mortemque praestare gradatim > > > 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
