Open lmammino opened 3 years ago
For my point of view validate
function should throw
(aka return a Result::Err) when some validations fail.
If you need to know also the info, we can split the "parse" and the "validation" phase into 2 function call. Something like
let cwt: Cwt = decode_cwt(data).unwrap();
match cwt.validate() {
Ok(_) => { },
Err(err) => { .... },
}
As shortcut
fn validate(data: &str) -> Result<(), ValidationError> {
let cwt: Cwt = decode_cwt(data).unwrap(); // this error could be transformed into a ValidationError using a dedicated variant
cwt.validate()
}
Regarding this problem I've seen that CwtHeader
has kid
and alg
declared as Option
s but it seems to me that if any of those information are missing it should be considered an error.
3.2 Structure of the payload
[...]
The integrity and authenticity of origin of payload data MUST be verifiable by the Verifier. To provide this mechanism, the issuer of MUST sign the CWT using an asymmetric electronic signature scheme as defined in the COSE specification (RFC 8152).
For the parsing and verification I agree with @allevo that they should be in two separate functions.
I would also add that given that the decode_cwt
function returns a Cwt
should be declared as a static method of the Cwt
struct. This counts also for validate
which directly interactes with its data.
I my mind, one should be able to write Cwt::decode(data)?.verify(trust_list) == SignatureValidity::Valid
Also it might be a good idea to rename the Cwt
struct as we are not parsing a generic CWT but a specific one that contains an HCERT.
EDIT: I missed the discussion on #8, I'll talk about this last part over there
Right now the library only validates a certificate based ONLY on the status of the signature. In reality a certificate can be considered invalid even if the signature is validated correctly.
As far as I understand there are several other factors that we should support in terms of validation:
DgcContainer
struct already collects these timestamps but we offer no easy way to check the current time against them.Business Rules (or country-specific rules): see #19 for dedicated issue.
In the context of this issue I think it will important to figure out an ergonomic API that:
Maybe we could have a dedicated
CertificateValidity
struct that can contain various fields like this:SignatureValidity
,TimeValidity
andBusinessRulesValidity
could be enums that can encapsulate all the different state of validation that is relevant for them. For instance:Finally we could have a
is_valid()
method on theCertificateValidity
struct that simply returnstrue
orfalse
if all the conditions are satisfied or not...