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

All,

Thanks for your comments Brent, Manu and Orie. It’s very useful to get your feedback on the ETSI TR 119 476, and we will gather all feedback with the intent to present it to the ETSI ESI management. We’ll also propose a new work item to update the ETSI TR once we have reached a critical mass of feedback.

I’d like to continue on the track that Peter pointed out: The main focus of the ETSI TR is to analyze the two PID formats that have been recognized for selective disclosure in the ARF, i.e. SD-JWT and ISO mDL MSO. Those formats were selected since the cryptographic algorithms used for signatures are approved by SOG-IS and allow for post quantum safe cryptography. Furthermore, the SOG-IS approved algorithms are allowed for use by the public sector in the EU.

In Annex A.1 of ETSI TR 119 476, there is a table with a column indicating if the cryptographic algorithms are plausible quantum safe. Feel free to review, and let us know if you have any comments on that.

Kind regards,
Sebastian

From: Altmann Peter <peter.altmann@digg.se>
Sent: Wednesday, 30 August 2023 16:28
To: Sebastian Elfors <sebastian.elfors@idnow.de>; Manu Sporny <msporny@digitalbazaar.com>; Orie Steele <orie@transmute.industries>
Cc: Brent Zundel <Brent.Zundel@gendigital.com>; public-vc-wg@w3.org
Subject: Re: [EXT] ETSI TR 119 476 on selective disclosure


CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
@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<http://www.digg.se/>
On 30 Aug 2023, 15:41 +0200, Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>, wrote:
On Wed, Aug 30, 2023 at 5:54 AM Sebastian Elfors
<sebastian.elfors@idnow.de<mailto: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#<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/