Closed asitplus-pteufl closed 3 years ago
Optical transport with the HC1
preamble refers to v1 of this specification. Compression mechanisms is pretty much locked by this IMHO, but other CWT parameters may be a bit more flexible.
New cryptographic algorithms are of course possible, but affects every verifier. The benefits of new algorithms must therefor very carefully considered. ES256 may not be the optimal algorithm for all use cases, but it is currently our only reasonable choice (with the PS256 as backup, see #30).
A new format for kid
does not necessarily change HC1
.In theory, one could introduce other key identifier formats as long as the creators of trusted lists agrees. Verifiers doesn't need to know of such as scheme as they do a plain match between the key identifier on the trusted list and the key identifier in the CWT.
@jschlyter not sure if I fully got it, from my perspective HC2 or something would be introduced as soon as changes are introduced which break the current validator apps (whatever these changes are). e.g. updated algorithms which need to be supported, or any other change which would break the current validator implementations.
is this the understanding of HC1 , HC2 etc.? (this was what we had in mind, since we need to assume that these changes are going to happen).
is this the understanding of HC1 , HC2 etc.? (this was what we had in mind, since we need to assume that these changes are going to happen).
Yes, I think you got it exactly right.
further explanation of the prefix would be necessary:
Is this in the sense of the validation suite we proposed (https://github.com/ehn-digital-green-development/hcert-spec/issues/9)? Meaning, that the validator app could read this and know which processing chain to use. e.g. HC1 refers to the current version, HC2 would refer to a modified scheme, where we made necessary changes to the processing schemes (anything, e.g other compression, DIDs as KIDs, other defined cryptographic algorithms?)