And the draft doesn't have a sufficiently strong statement saying this tech (which has significant limitations: every TEE has fallen due to side channels) is needed for relevant application scenarios.
I'm not saying this work shouldn't continue: I'm saying that we need to ensure we get the privacy and security considerations right, and make clear the limitations and that users shouldn't be mislead about the degree of anonymity they have. The applications being envisioned are dangerous. Sincerely, Watson Ladd On Mon, Jul 22, 2024, 6:51 PM Wayne Chang <wa...@spruceid.com> wrote: > Hi Watson, > > Here’s an approach based on TEEs that can in theory create unlinkability > for things like mdocs and SD-JWTs while also conforming to FIPS 140-2/-3. > No new crypto, and PQC-friendly. > > > https://blog.spruceid.com/provably-forgotten-signatures-adding-privacy-to-digital-identity/ > > Best, > - Wayne > > On Mon, Jul 22, 2024 at 16:26 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
