IMHO, it is just a matter of setting the reader's expectations right through adequate privacy considerations. When it comes to collusion attacks, we can think not only of issuer-verifier but other varieties as well. We should perhaps list those scenarios. In ISO/IEC 27551 that only deals with the model without holder, it still lists 8 varieties of unlinkability. We will have many more in the issuer-holder-verifier model. We should be aware that there is an operator behind the holder, which can turn hostile.
Best, Nat Sakimura 2024年7月23日(火) 13:35 Wayne Chang <wa...@spruceid.com>: > Yep, TEEs definitely have limitations that should be managed via > defense-in-depth to prevent things like side channel attacks. > > It’s also true that such identity systems based on transmission of raw > digital signatures have been deployed in production today and continue to > gain momentum. > > It’s important that we balance the various approaches to privacy, as not > to let perfect be the enemy of the good, while also paving a path to the > ideal. > > Best, > - Wayne > > On Mon, Jul 22, 2024 at 20:33 Watson Ladd <watsonbl...@gmail.com> wrote: > >> 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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
