Decide whether to drop the unsigned option

[paulbastian]

The unsigned option hasn't shown any interest at all and complicates matters within the draft. Therefore, we consider to drop this feature again. Is anybody planning to use this?

[cre8]

I support the removal of the unsigned option. If the verifier does not want to validate the signature, it can skip this "feature" without any further step. This signature operation on the issuer site is also quite small compared to the other functions like interacting with the database and building up the bit string.

The argument "signed data is more valuable in a data breach" was only brought up when a it was personal data, which is not the case in this scenario. In this case, the status list is all the time public available, so there is no need to hack into any system to get it ^^

[manecke]

Our aim should be to create specifications that are as consistent and compact as possible. Each additional endpoint or option also offers new attack vectors.

We also try to create a system that is as secure as possible. We have Trusted Verifier, Trusted Issuer etc. With this in mind, I see no benefit in using unsigned data. In this case, I cannot check the integrity and authenticity of the data on a terminal device at a later point in time. In addition, the data would then be transferred as raw data in the cluster.

In this sense, I would take up IDunion's suggestion and only offer the signed option and only offer this option. Clients who do not want to check the integrity of the data can simply do without validating the list/signature. This corresponds to the unsigned option (the amount of data is only one signature larger).

Furthermore, in the offline use case, if I cache the data on a terminal device, I need the option of being able to check the data. In my view, this option should be prioritized. You should also generally consider whether I really want to omit the check in a status list. This is at least questionable in the majority of cases.