Hi Kristina,
Today, most people have in mind the Issuer-Holder-Verifier model. Other
use cases are hypothetic at the moment.
This document includes a privacy considerations section (section 11) and
the guidance given in that section
about verifier-verifier unlinkability looks appropriate on pages 47 and 48.
You wrote:
To sum up, I think we could add back into the SD-JWT document a
sentence saying there are ways
other than batch issuance to achieve verifier-verifier unlinkability.
Indeed, ZKP such as BBS or BBS+ could be used but the performances of
such algorithms are rather poor
and their inconvenients are rather important. ZKP should not be
recommended at this point of time.
Batch issuance of digital credentials is a much more practical solution.
However, one advantage of BBS and BBS+ is their ability to link digital
credentials issued by different Issuers.
This topic is not currently addressed in the document because the base
mechanism does not support it.
On September 23, I sent an email to the mailing list with the following
topic:
How to get the benefits of BBS+, without its drawbacks while using
conventional cryptography ? (Was SD-JWT and Unlinkability)
This characteristic can be achieved using traditional cryptography *if
and only if* that cryptography is supported by a specific
Holder hardware/software configuration as well as by specific protocols.
Such guidance should be added into the Security Considerations section.
On September 18, I sent an email to the mailing list with the following
topic:
Re: WGLC for SD-JWT
At this time, I got no replies from the editors.
Denis
SD-JWT document has a clearly defined scope and one can implement
“something useful”that is meant to be in scope by reading only SD-JWT
document.
Also please see my other response about SD-JWT not being meant only
for issuer-holder-verifier model. There might be usages of SD-JWT
outside that model that do not need batch issuance. Like,
theoretically, using sd-JWT as a content of an access token for
whatever reason.
Once again, “what we can do is to add a text saying more clearly that
the details of batch issuance are defined elsewhere and what kind of
details need to be defined in that document”.
On Tue, Sep 24, 2024 at 11:10 AM Dick Hardt <dick.ha...@gmail.com> wrote:
I understood your point. :)
As a reader, I had no idea I was supposed to look elsewhere for
guidance on either unlinkability, explicit typing, or decoy digests.
My other point is the document should stand on its own and not
require other documents to do something useful.
On Tue, Sep 24, 2024 at 10:01 AM Kristina Yasuda
<yasudakrist...@gmail.com> wrote:
And my point is that SD-JWT document is a wrong place to look
for such actionable language. The intention is not and should
not be to define a stand alone batch issuance protocol in
SD-JWT document.
What we can do is to add a text saying more clearly that the
details of batch issuance are defined elsewhere and what kind
of details need to be defined in that document.
Best,
Kristina
On Tue, Sep 24, 2024 at 9:22 AM Dick Hardt
<dick.ha...@gmail.com> wrote:
My feedback is that the current language on batch issuance
is not actionable, and that this document should stand on
its own
If the reader is supposed to take guidance from other
documents, then you should refer to those other documents,
but I would have that in addition to specific guidance.
On Mon, Sep 23, 2024 at 10:03 PM Kristina Yasuda
<yasudakrist...@gmail.com> wrote:
> there is no guidance on how many to issue, nor how a
holder chooses when to reissue the same ones
> the question about users randomly selecting some to
store and some to reject.
These are great points, however, just like JWT/JWS
specifications do not define how to manage the
lifecycle of those,SD-JWTdocument is not a right place
to discuss them. What you call a "hack" is not meant
to be fully specified in SD-JWT document itself.
Please review documents such as OpenID4VCI to
improve various aspects of batch (re)issuance.
On another note, and not sure this was your original
point, but I can recall that originally, we had a text
in the document that there are other ways to achieve
verifier/verifier unlinkability, other than batch
issuance, mainly using advanced cryptography (aka
ZKPs). Then, upon receiving feedback that such text is
not really actionable or implementable, because it was
not well established how to use ZKP with SD-JWTs, we
removed sentences alluding to the mechanisms that are
not batch issuance.
However, I think that might be changing, looking at
the work cryptographers at Google have been
demonstrating recently. I think we are eagerly waiting
for that work to be published and peer reviewed.
To sum up, I think we could add back into the SD-JWT
document a sentence saying there are ways other than
batch issuance to achieve verifier-verifier unlinkability.
Best,
Kristina
On Sat, Sep 21, 2024 at 5:56 PM Dick Hardt
<dick.ha...@gmail.com> wrote:
I understand it has become the accepted approach.
It still comes across as a hack, and there is no
guidance on how many to issue, nor how a holder
chooses when to reissue the same ones.
I'm amused by the decision to use implicit typing
in a disclosure to save a few bytes, but we will
send dozens of credentials to minimize the chance
of linking :)
On Sat, Sep 21, 2024 at 4:29 PM Daniel Fett
<m...@danielfett.de> wrote:
Hi Dick,
Batch credential (not claims) issuing has
become the default approach to circumvent the
inherent limitations of salted-hash-based
credentials formats. This was neither invented
by us, nor is it unreasonable to ask
implementers to do it. Protocols such as
OpenID4VCI support it.
-Daniel
Am 21.09.24 um 06:42 schrieb Dick Hardt:
Is it really going to be practical to batch
issue claims, and have the holder randomly
choose between them on presentation?
As an implementer, what is the right number
of claims to be in a batch?
This section of the draft reads as a hack to
add a new capability (unlinkability) to a
mechanism that did not have that as a design
objective.
This is going to be like the "alg":"null" for
SD-JWT. :-)
_______________________________________________
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
