Re: [EXT] ETSI TR 119 476 on selective disclosure

Its relatively recent, but we changed the "example renderer for
vc-jose-cose" to use "sd-jwt" by default (instead of JWT by default), and
we added test cases for sd-jwt to the test suite:

- https://w3c.github.io/vc-jose-cose/#example-example-credential
-
https://github.com/w3c/vc-jose-cose-test-suite/blob/main/testcases/secured-vc-jwt-sd/spec.yaml

If there are sd-jwt cases you want covered in tests, please file issues
here:

- https://github.com/w3c/vc-jose-cose-test-suite

We are specifically looking for examples that reflect "realistic iss / kid"
values, and x509 or DIDs if you plan to use them.

Regards,

OS

On Wed, Aug 30, 2023 at 9:27 AM Altmann Peter <peter.altmann@digg.se> wrote:

> @Orie Steele
>
> Correct. I would even add assuming issuers are trusted not to collude with
> anyone, unsinkability is achieved when combined with batch issuance and
> single use attestations. This is why the ETSI TR recommends batch issuance
> for salted attribute hash based approaches.
>
> You also correctly point out that the batch issuance proposal is
> problematic and burdens several actors, not to mention makes revocation
> more difficult too. Note here that for some attestations, e.g., the PID
> (Person Identification Data) attestation, the public sector is not allowed
> to use non standard cryptography. We recognize the value of alternative
> solutions that do not require batch issuance and that can protect against
> issuer collusion too, and hope that these will be available for public
> sector use in the future as standardization efforts progress. In ways, I
> view the ETSI TR also as a call for standardization.
>
> @Manu Sporny
>
> Thanks for pointing out concerning areas! We always intended to update the
> text once we could gather input from experts. To respond to your concerns:
>
>    - *The TR does not include a variety of SD schemes that are under
>    active development*. This is due to several factors, non of which are
>    us being biased toward a particular solution. Our analysis is, however,
>    possibly biased due to our diverging understanding of the various
>    techniques / schemes. With that being said, we tried to focus our initial
>    analysis mainly on the techniques that were relevant for the eIDAS
>    negotiations. What is relevant is of course an opinion and we recognize
>    that we can make decision not everyone agrees with. For instance, we did
>    look at ACDC, ECDSA-SD, and Gordian Envelopes, but chose not to include
>    these since we either did not find them relevant for the attestation
>    formats that are currently prioritised by the European Digital Identity
>    Wallet (EUDIW) or could not find a clear enough description of the
>    technique in time for publication of the ETSI TR. This is not to say that
>    we do not recognize the merits of the work, and we may have missed how they
>    can support the core EUDIW formats. If so, please let me/us know. The field
>    is incredibly complex and any work such as this ETSI TR benefits greatly
>    from multiple eyes. For a future ETSI TR, we may extend the focus on
>    schemes / techniques that are relevant for formats beyond the core EUDIW
>    formats.
>    - *Some conclusions do not align with the specification text in the
>    VCDM, especially the claim that SD-JWTs are incompatible with VCDM*.
>    This was one of the topics we discussed the most and where we sought
>    external input. A few clarifications here, we only intended to state that
>    joint utilisation of VCDM 1.1 and the SD-JWT specification that was
>    available at the time was problematic to the point that the two are
>    incompatible without further work. We are aware of the ongoing work with
>    VCDM 2.0 and SD-JWT and SD-JWT VCs, and we would much welcome input on how
>    to jointly utilise the two (I know this is a core interest for several
>    large scale pilot actors in the EUDIW trials too), but these were not
>    included in the report for a few reasons. The two main ones being:
>       - The specification was not available at the time of authoring the
>       text
>       - The Architecture Reference Framework for EUDIW specifically
>       mentions VCDM 1.1, so our analysis focused on VCDM 1.1.
>    - *Unlinkability and batch issuance*. I here refer to my above reply
>    to Orie. Batch issuance is not a good solution; arguably quite a bad one
>    that burdens the issuer, holder, revocation service etc. And as you point
>    out, past experiences are worrying. But for the certain public sector
>    issued attestations like the PID, we are constrained by certain
>    requirements and have to work with the assumption that issuers will not
>    collude. If you have a proposal on how to enable unlinkability using
>    standard cryptography and that works with salted attribute hash based
>    approaches, I am all ears! In particular, I am excited about the work with
>    BBS+ and hope that standardization efforts go smoothly.
>
>
> Thank you both, and with hopes of additional comments and inputs. As
> stated, we are in the process of collecting everything so that an updated
> version of the ETSI TR can address the concerns you mention, provide
> additional clarifications, and extend the analysis to a deeper and wider
> coverage of techniques that are relevant outside of the EUDIW Core formats.
>
> BR,
>
> Peter Lee Altmann
> PhD. Specialist Digital identitet
> PhD. Specialist Digital Identity
>
> DIGG – Myndigheten för digital förvaltning
> Agency for Digital Government
>
> +46 (0)72-464 18 06
> www.digg.se
> On 30 Aug 2023, 15:41 +0200, Manu Sporny <msporny@digitalbazaar.com>,
> wrote:
>
> On Wed, Aug 30, 2023 at 5:54 AM Sebastian Elfors
> <sebastian.elfors@idnow.de> wrote:
>
> Hopefully, this clarifies the principles of unlinkability as described in
> ETSI TR 119 476.
>
>
> Hi Sebastian and Peter, thank you for the paper and all the effort
> that went into it. I have skimmed it and found a number of areas of
> concern. I'll just mention three of them in this email, as I haven't
> been able to read it in depth.
>
> The first issue is that it doesn't include a variety of other
> selective disclosure schemes that are under active development...
> namely, ACDC, Gordian Envelopes, the Singapore governments work, and
> ecdsa-sd. The latter one is a part of a deliverable for the VCWG:
>
> https://w3c.github.io/vc-di-ecdsa/#ecdsa-sd-2023
>
> presentation about it is here:
>
>
> https://docs.google.com/presentation/d/1d-04kIWhPuNscsAyUuRH3pduqrNerhigCWahKe6SNos/edit#
>
> The second issue is that some of the conclusions reached in the
> analysis don't seem to align w/ with the specification text in the
> VCDM specification. Most notably, the claim that SD-JWTs are
> incompatible w/ the VCDM. I'll try to find more time to read through
> the material with my VCDM Editor hat on, but given the length of the
> paper (and the VCWG's current workload), it might take a while to get
> back to you on this.
>
> The third issue has to do w/ Brent's read on the paper... I was
> confused in the same way that he was wrt. how the term unlinkability
> is used in the paper.
>
> Issue a batch of SD-JWTs to the Holder to enable the Holder to use a
> unique SD-JWT per Verifier. This only helps with Verifier/Verifier
> unlinkability.”
>
>
> Oof, no, that's a dangerous thing to suggest.
>
> Hopefully, this clarifies the principles of unlinkability as described in
> ETSI TR 119 476.
>
>
> It helps, and it aligns more closely with what I thought the
> definition of "unlikability" was... but it highlights more concerns as
> a result. I'll be bold and say that it would be a stretch to say that
> the current trajectory supports unlinkability at any real depth. In
> fact, it proposes that unlikability is possible, but using an approach
> that has been demonstrated to fail in the past, which is effectively a
> variation on stateful signatures.
>
> The problem w/ stateful signatures over the many years that they've
> existed is that implementers usually get the "state tracking" part of
> the implementation wrong in a variety of ways. In fact, we had
> considered it for ecdsa-sd and decided that it would create two
> untenable issues:
>
> * a misimplementation at a wallet would result in a privacy failure
> (accidentally sending a previously used signature/hash).
> * it would require coordination among multiple devices if the wallet
> was multi-device capable (which we expect a number of wallets to be
> multi-device capable).
>
> So, instead of stating that "it is possible for ecdsa-sd to be
> unlinkable", we chose to say: "No, we shouldn't even promise that
> because it's so easy for an implementation to mess it up and create a
> privacy failure."
>
> That is why we believe that if unlinkability is desired, you will need
> to use a scheme that actually supports it at the cryptographic layer
> -- something like BBS+, which the VCWG is also working on.
>
> More as some of us read through more of the paper... thank you again
> for the analysis, you've got the attention of at least some of the
> people in the WG. :)
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>