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 ?
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 ?
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.
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.
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 tooauth-le...@ietf.org
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
