Thanks for your thoughts Denis, I have answered inline. I only have a short time to reply right now so apologies for the terse response, and I may follow up if I have more thoughts.
On Mon, Dec 23, 2024 at 1:59 PM Denis <denis.i...@free.fr> wrote: > Hi Wayne, > > I changed the title of this thread into: Issuer-Verifier unlinkability. > > Let us come back for a moment with real world example: the use of a mobile > driving licence. > > A simple way to support the Issuer-Verifier unlinkability property would > be for the Issuer, once a digital credential has been issued, > to immediately delete the user account that has been created as well as > the digital credential that it has issued. > > However, from a practical point of view, a major problem would arise: how > can the Issuer manage the suspension or the revocation > of the issued digital credential ? > Short-lived credentials. Alternatively, you could build a ZKP-based revocation system that is non-PQC atop the existing P-256 ECDSA systems, as I don't know that the TSA mDL final rulemaking has requirements on exactly how revocation is handled--so perhaps the door is open for interpretation, and this would require policy weigh-in. > > If the police, acting as a Verifier, wants to verify that the mobile > driving licence is not suspended or revoked, how can it do it ? > Today, when LEOs bring your license to their car, they query their system to see if the license is suspended or revoked. Pragmatically, I imagine this system will continue to exist and be utilized across the 50 US states at least, with mDL. > > This means that, one way or another, the Issuer shall remember that it has > issued that digital credential to a user > and that information can be used to establish a link between a digital > credential issued by the Issuer and > a presentation proof received by the Verifier. > > One additional remark: when the user will need to renew his digital > credential, he would have to start again from zero. :-( > > The slide 14 called " A Pragmatic Approach for Today: Provably Forgotten > Signatures" is unable to solve the problem previously identified. > Whatever kind of cryptographic technique will be used or TEE used by the > Issuer, it cannot support Issuer-Verifier unlinkability property. > > The slide 18 states: > > "The future of digital identity lies in zero-knowledge proofs (ZKPs) that > support post-quantum cryptography, > enabling enhanced privacy and selective disclosure". > > I don't believe so. > > ZKPs are computationally intensive and the size of the key pairs and of > the digital signatures are big. > ZKP schemes like BBS, BBS+ or BBS#, by their construction, cannot be > post-quantum resistant. > > > Without awaiting for the discovery of post-quantum ZKPs, today it is > already possible to use post-quantum resistant algorithms. > I'm proposing that we await the discovery of post-quantum ZKPs that are efficient, even though today's STARKs can support it but are big/slow. The problem is that I don't think you'll be able to get the BBS/BLS/etc. through NIST due to the reasons you mention above and their focus on PQC. > > > One solution is straightforward: to use one-time use digital credentials > and a key binding mechanism based on > an OTS (One Time Signature) algorithm like the Winternitz OTS PLUS (WOTS+) > scheme which is the current state of the art. > By construction, "Constant-sum WOTS+" is guaranteed to be immune to timing > attacks. > Thanks, interesting to consider this approach. > > A further major advantage is the fact that this type of algorithm can be > supported using the current format of the SD-JWT, > while this would not be the case for ZKPs. > > Denis > > Hi all, resurfacing this approach as it may provide issuer-verifier > unlinkability for SD-JWTs and formats like it depending on your threat > model. > > https://csrc.nist.gov/Presentations/2024/wpec2024-3b4 > > Best, > Wayne Chang > Founder & CEO | SpruceID <https://spruceid.com/> | LinkedIn > <https://www.linkedin.com/in/waynebuilds/> > > > On Mon, Dec 23, 2024 at 09:07 Joseph Heenan <jos...@authlete.com> wrote: > >> >> >> On 23 Dec 2024, at 16:02, Denis <denis.i...@free.fr> wrote: >> >> Joseph wrote: >> >> I believe I've said that, including in your PR I linked above: there are >> situations where SD-JWT is the best currently available deployable >> technology >> for a user disclosing their age to a verifier, and yes, it is absolutely >> appropriate to use the best currently available deployable technology to >> solve a real world problem. >> Yes, in some situations it can’t achieve issuer-verifier unlinkability, >> but in those situations it can still achieve better data minimisation than >> alternative technologies. >> Maybe in the future we will have better solutions available and at that >> point it might be appropriate to start adding stronger text. >> >> A presentation where only a date of birth is disclosed is an example >> explicitly mentioned in the specification too. >> >> I’m deliberately avoiding the term ‘age verification’ there as I think >> you’re trying to use it to describe some fairly specific situation that >> hasn’t been defined >> - I’m not sure whether a stronger statement is possible about the >> specific case of age verification you seem to be thinking of, as I’m not >> clear on what that case is, >> and as I said in my 1st August comment “age verification” is an overly >> generic term that incorporates a large number of very disparate use cases. >> >> I think differently: >> >> SD-JWT *as currently described* is NOT "*the best currently available >> deployable technology for a user disclosing their age to a verifier*". >> >> >> That is not what I said - the ‘in some situations’ is a very important >> qualifier. (And maybe I should have said ’format specification’ or >> something rather than ’technology’.) >> >> Although I’m somewhat puzzled why you didn’t go on to name what is the >> best technology, it seemed more like you were agreeing it is the best >> technology and explaining how it can be extended using available extension >> points to build a good solution for this use case. >> >> The major problem is that SD-JWT is only a piece of a puzzle >> that includes other entities - that have not yet been identified. >> In order to secure the two exchanges described in this draft, other >> protocols and other entities would need to be considered. >> >> As an example, *in its basic form*, OpenID4VCI is insecure. >> >> A Framework would be needed to identify all the pieces of the puzzle and >> to describe how they interrelate. >> >> To close the loop, SD-JWT **as currently described** SHOULD NOT be >> considered to be secure enough >> for disclosing one or more age threshold values to a Verifier. >> >> >> I don’t think anyone is arguing that the SD-JWT specification contains >> all the information you need to implement a fully secure age verification >> ecosystem, and the same applies to OpenID4VCI and SD-JWT VC as well. Nor >> should they contain these things - they are flexible building blocks that >> cover many uses cases and can be further profiled/constrained/extended, and >> they are building blocks that people appear to be successfully building >> secure solutions on top of. This seems close to complaining that the HTTP >> RFC doesn’t tell you how you should use cookies when you’re implementing a >> banking portal. >> >> Thanks >> >> Joseph >> >> _______________________________________________ >> 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 > > > -- Best, Wayne Chang Founder & CEO | SpruceID <https://spruceid.com/> | LinkedIn <https://www.linkedin.com/in/waynebuilds/>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
