Is the spec defining a Universal Public Certificate resolver?

[vitorpamplona]

In other words, can a verifier unpack a new HC1 payload realize the signature is unknown and call a resolver to automatically find, download, and install the referenced certificate chain and use it to verify the payload?

[dirkx]

In other words, can a verifier unpack an HC1 payload,

Yes. find and download and install the referenced certificate chain and use it to verify the payload?

Yes if it has this hardcoded in its software -and- that country gives access to this (the Netherlands will do so - it will be on a public CDN).

Most countries will highly optimise this - e.g. see the payload on https://dgc.idsec.se/tp/ and https://github.com/DIGGSweden/dgc-trust/blob/main/specifications/trust-list.md for an example.

Dw.

[vitorpamplona]

But my question is, would there be a single resolver to figure out which country the HC1 comes from and then download the key automatically so that verifiers don't need to know which country is doing what?

[vitorpamplona]

In other words, how do verifiers know that if they have a Sweden certificate, they need to download public keys from https://dgc.idsec.se/tp/trust-list?

Manually hardcode each country's download info?

[vitorpamplona]

On a regular Verifiable Credential, this is generally solved with a Universal DID resolver (such as https://dev.uniresolver.io/), or a DNS Resolver if the key is on a record whose direct link was signed inside the payload.

[asitplus-pteufl]

so we have two components, (1) the EU trust gateway, which is not publicly available, but contains all DSCs and CSCAs for all member states (2) a national trust list.

how the national backend distributes this information to its verification apps is up to the national backend. here is the austrian overview:

• DSCs are downloaded from the EU trust gateway, verification steps against the CSCAs etc. are taken
• the KIDs are calculated for each DSC and a national trust list is created that basically contains a map from key-id to public key of the DSCs, our national trust-list is also based on COSE/CBOR and it is signed by the backend.
• the national verification apps download this trust list and when a QR code gets validated we have the following procedure
• KID is taken from COSE structure
• KID is used to get the public key from the downloaded trust list, signature is verified

so there is no defined place where an arbitrary app can go to and download the DSCs, but in theory (from a technical point of view) some publicly available national trust lists could be used.

[asitplus-pteufl]

so to answer your previous question, e.g. a German validation app will not need to go the Swedish trust list, but just take the information from its national trust list that contains all the DSCs.

[vitorpamplona]

Ok, should we start creating a Universal Public Certificate resolver, then?

Because, as an independent verifier, not attached to any state, I need a place to get a single new key that follows the same format for all HC1 and that I can make sure all keys using HC1 are there.

[vitorpamplona]

Something like hc1resolve.io/<KID>

[asitplus-pteufl]

a careful answer, since I do not know to much details on the gateway (from a legal perspective): I think that only the member states would get direct access to the gateway, since there is an upfront manual registration process which registers the client TLS certificates that are required for access. If it is legally fine, you could probably also take a national trust list which is offered publicly.