Mandatory issuer Field

[SchulzeStTSI]

The optional usage of the issuing country should be mandatory in the spec to harmonize all issued QR codes.

[gabywh]

The optional usage of the issuing country should be mandatory in the spec to harmonize all issued QR codes.

We do not decide what is mandatory and what is not mandatory. We keep to the EU regulation.

[martin-lindstrom]

The optional usage of the issuing country should be mandatory in the spec to harmonize all issued QR codes.

So you are saying that there are issued codes where there is no issuer field? If so, they are no accoding to the specification. Let's not change the specification. There is a reason we added the issuer field as required.

[asitplus-pteufl]

@martin-lindstrom the CWT issuer is not mandatory. I think that @SchulzeStTSI was referring to the CWT issuer field. https://github.com/ehn-dcc-development/hcert-spec/blob/main/hcert_spec.md#334-issuer

[martin-lindstrom]

@martin-lindstrom the CWT issuer is not mandatory. I think that @SchulzeStTSI was referring to the CWT issuer field. https://github.com/ehn-dcc-development/hcert-spec/blob/main/hcert_spec.md#334-issuer

My bad. I was so sure that the iss claim was mandatory that I didn't even bother to check the spec. @jschlyter Has it really been optional from the beginning?

[asitplus-pteufl]

let me use this opportunity and check on how others deal with this issuer field. We (AT) do not do anything with it except for inserting it. We do not use it for validation (since it is not mandatory), we don't use it for displaying purposes (again not mandatory) (if we were allowed to display this information anyways we would use the info from the signature certificate). So currently it is unused. Also the question remains: Should it be used to make sure that the issuer is the same as in the DSC? What information does it provide and how is that used? My interpretation so far: It is there since it is specified in CWT, but we do not have a clear view on how it is used due to two reasons (1) not mandatory and (2) not quite clear why it is there - except for technical CWT reasons.

[jschlyter]

My bad. I was so sure that the iss claim was mandatory that I didn't even bother to check the spec. @jschlyter Has it really been optional from the beginning?

Yes, per CWT and JWT specification the iss OPTIONAL. Once the signature is verified, you have the issuer (from the trusted list) anyway, so it's mostly for informational purposes. As @asitplus-pteufl writes, the issuer can be found in the DSC.

As stated in section 3.3.4, the iss claim can be used by a Verifier to identify which set of DSCs to use for validation. If one only have one set of DSCs, its use is limited.

[SchulzeStTSI]

Yes I mean the iss field in the CWT. It was declared as optional from the beginning. To get it from the DSC is possible but we have then three different ways how to get the country of the certificate. DSC C field, ISS, Field CO. We should harmonize the behavior here to stop confusion and make it crystal clear. Set this field to required is a good step forward, because otherwise you have to rely very hard to DSC requirements, which is a very big winding in another direction. Currently all states add the issuer field, so it's practically already mandatory. From my perspective it's simply an additional complexity to allow this field as optional.

[jschlyter]

@SchulzeStTSI Given that you only have a single trusted list, what would you use the iss claim for? The Country of the certificate (and issuing organization) is always present in the DSC, why look at anything else?

[SchulzeStTSI]

@jschlyter Of course it can be extracted. But this means then, that the iss field overrides the DSC field if present, right? And the DSC informations are injected after the signature checkup. Which can maybe lead to side effects, that more data is present than in the certificate visible. How to handle conflicts? E.g. iss is a different field than the certificate country (happen in france where iss= CNAM).

[asitplus-pteufl]

agree with @SchulzeStTS, we would need at least clear rules/guidelines on how to treat each value and which relations are possible. Is a scenario where Germany acts as issuer but puts AT into the DCC possible? And if yes, which fields need to be put in which field? Need they be validated (e.g. if mixing up countries is not possible, a security check whether the issuers match in the different fields would be prudent)?

[jschlyter]

The reason for having the iss claim is that there was a requirement to select different trusted list and validation rules based on issuing country. The real identity of the issuer can only be found in the DSC, and includes both organization and country. Just ignore the iss claim if you have a single trusted list. I will let others decide if this needs to written down somewhere.

[ryanbnl]

It turns out that there are four country codes: the iss claim, the issuer in the DCC at schema level and the country codes from the DSC and CSCA.

There are for several countries legitimate reasons for these codes to differ: for example the UK, France and The Kingdom of the Netherlands in effectively umbrellas for multiple Sovereign countries. In those cases the CSCA and DSC are controlled by different (but legally / constitutionally connected) entities. The value of the iss claim and the DCC schema are then open to interpretation.

[ryanbnl]

What should we do with this PR @dslmeinte @skounis @SchulzeStTSI? I'd like to either merge or close it. For a merge we should first check:

1) actual usage (via the QA repository, not much work for me). 2) relation with the regulation text / appendixes (if this is defined there we cannot change anything here).

Then if we merge we need to ask in the Tech IOP to confirm (and bundle with other changes if there are other changes).

[dslmeinte]

I think we should close this: I think the current interest in the EU DCC has waned so much that getting this (frankly: quite detailed) thing exactly right is not worth the effort required to do it the right way (including approval via TechIOP etc.).

Apart from that, I don't feel that I'm qualified to give a green light for merging.

[ryanbnl]

I also favour closing it.

[skounis]

+1 for closing it.

[ryanbnl]

That's enough for me :-) Closing this as the DCC is considered stable and no changes are desired or forseen.