+1 Richard Mike Prorock Founder https://mesur.io/
Grab a meeting! https://calendar.app.google/aNUcr41gvTAiMUG49 On Mon, Jul 22, 2024 at 5:44 PM Richard Barnes <r...@ipv.sx> 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. > > --Richard > > On Mon, Jul 22, 2024 at 7:25 PM Watson Ladd <watsonbl...@gmail.com> wrote: > >> >> >> On Mon, Jul 22, 2024, 3:30 PM John Bradley <ve7...@ve7jtb.com> wrote: >> >>> I agree that single-use proof keys and batch issuance are a must. >>> >>> Issuer verifier collusion is admittedly a problem. To address that we >>> do need different cryptographic methods. >>> >>> MDOC also has the same issue. >>> >>> We should document the risk, but short of stopping EUID and mobile >>> driver's license deployment, we have limited options. >>> >> >> The problem only appears when the drivers license or EUID is used in a >> way that makes the user think their data is private. You don't have to >> support UX that lies to the user. >> >> >>> Hopefully, we can make quick progress on JWP. >>> >>> John B. >>> >>> On Mon, Jul 22, 2024 at 2:14 PM Watson Ladd <watsonbl...@gmail.com> >>> wrote: >>> >>>> Dear Oauth, >>>> >>>> I'm disappointed to see SD-JWT work continue with inadequate privacy >>>> considerations. The fact is an Issuer can link any showings to >>>> issuance of the credential. This is not foregrounded sufficiently in >>>> privacy considerations, nor do we discuss how to ensure users are >>>> aware. We really need to use more RFC 2119 language and highlight >>>> these issues. Section 11.1 about local storage which has never been an >>>> IETF concern before is far more prescriptive than 11.4, and that's not >>>> a good thing. To be clear, the threat model must include an issuer >>>> that is a government issuing credentials that if used to verify age on >>>> certain websites or via a digital wallet on site, and learned about by >>>> the issuer who may have access to data from the site, will result in >>>> imprisonment or execution. This is not a hypothetical scenario. >>>> >>>> Users and UX designers will have intuitions that do not match the >>>> reality and that result in bad decisions being made. That's on us. A >>>> driver's license doesn't leave a trace of where you showed it, but the >>>> SD-JWT does. >>>> >>>> At a minimum I think we mandate batch issuance and one time usage >>>> using RFC 2119 language. We need to say in clear, unambiguous English >>>> that this mechanism enables an issuer to connect every presentation of >>>> a credential to the issuance. >>>> >>>> Sincerely, >>>> Watson Ladd >>>> >>>> -- >>>> Astra mortemque praestare gradatim >>>> >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > 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
