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
