Richard, it all depends on how you scope the problem. Hellō uses garden variety crypto and does not have collusion issues and has true minimal disclosure as Hellō is an abstraction layer and the original issuer is not exposed.
The internal operation of Hellō prevents any party from viewing user data. https://www.hello.coop/pages/approach.html No new exciting technology. It is a centralized service that addresses privacy by taking the separation of duties to the level of geopolitical independent jurisdictions. Issuers don't need to adopt any new technology they are not already using. Developers just use vanilla OpenID Connect. /Dick On Mon, Jul 22, 2024 at 4: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
