eu-digital-green-certificates/dgc-certlogic-android

BoosterNotification Rules are validated as OPEN

Closed this issue · 6 comments

Describe the bug

Rule BNR-DE-4161 is validated as OPEN when we validate a Vaccination certificate
Exception: java.lang.RuntimeException: date argument of "plusTime" must be a string

All Rules are validated as OPEN when we validate a Recovery certificate
Exception: java.lang.RuntimeException: date argument of "plusTime" must be a string

Expected behaviour

Rule should be validated as FAIL

Vaccination certificate
dataJsonNode:
{"external":{"validationClock":"2022-01-15T10:51:03.857+01:00","valueSets":{},"countryCode":"de","exp":"2022-07-30T15:01:59Z","iat":"2021-07-30T15:01:59Z","issuerCountryCode":"de","kid":"","region":""},"payload":{"issuer":"DE","validFrom":1627657319,"validUntil":1659193319,"nam":{"gn":"AstraZeneca","fn":"Vaccine","gnt":"ASTRAZENECA","fnt":"VACCINE"},"dob":"1921-08-21","v":[{"tg":"840539006","vp":"1119305005","mp":"EU/1/21/1529","ma":"ORG-100001417","dn":2,"sd":2,"dt":"2021-08-02","co":"DE","is":"Robert Koch-Institut","ci":"URN:UVCI:01DE/IBMT102/3CU9LYH1VHUMMDF86T7X3S#L"}],"t":[],"r":[],"ver":"1.3.0","dateTimeSeparator":"T","empty":0,"yearCount":4,"yearMonthCount":7,"yearMonthDayCount":10}}

6_AstraZeneca-Vaccine_2nd_Vaccine_AstraZeneca_1921-08-21

Recovery certificate
dataJsonNode:
{"external":{"validationClock":"2022-01-15T10:48:01.219+01:00","valueSets":{},"countryCode":"de","exp":"2022-07-30T15:02:01Z","iat":"2021-07-30T15:02:01Z","issuerCountryCode":"de","kid":"","region":""},"payload":{"issuer":"DE","validFrom":1627657321,"validUntil":1659193321,"nam":{"gn":"Recovery","fn":"RichyThree","gnt":"RECOVERY","fnt":"RICHYTHREE"},"dob":"1921-08-21","v":[],"t":[],"r":[{"tg":"840539006","fr":"2021-08-02","df":"2021-08-30","du":"2022-02-01","co":"DE","is":"Robert Koch-Institut","ci":"URN:UVCI:01DE/IBMT102/51VONE4URYN03AO7ID2N91#S"}],"ver":"1.3.0","dateTimeSeparator":"T","empty":0,"yearCount":4,"yearMonthCount":7,"yearMonthDayCount":10}}

9_Recovery_RichieTwo_RichyThree_Recovery_1921-08-21

BoosterNotification rules:
bnr.txt

On the first view, the logic is a little bit problematic. The rule describes an AND with two concurrent conditions. If a entry in recovery exists, the rule will calculate recovery entry r.0 and compares it with entry v.0 from a vaccination certificate. Both of them are not present in the same time. So far i see you inject r:[] and t:[] and v:[] but this is not enough. It must be minimum v:[{"dt":"..."}] otherwise the expression results to null and the exception is correct (not a string). What is the intention behind that mix of different certificates in one rule? Is there maybe a mistake in the line or any misspelling? Can you please check if this is the problem?:)

"and": [ {"if": [ {"var": "payload.r.0" },
{"after": [{"plusTime": [ {"var": "payload.r.0.df" },0,"day"]},
{"plusTime": [{"var": "payload.v.0.dt"},0,"day" ]}
]
},
false
]
},
{"before": [{ "plusTime": [{"var": "payload.r.0.df"},120,"day" ]},
{"plusTime": [{ "var": "external.validationClock"},0, "day"]
}]
}] }}

@pucherd the rule BNR-DE-4161 does indeed have a logical mistake. We will fix the rule and provide an updated one. (@SchulzeStTSI thanks for the analysis).

Regarding when we validate a Recovery certificate: BNRs should only be evaluated if a Vaccination Certificate is available. If there is a VC and RC, the JSON data structure should be merged to include v[0] and r[0]. If there is only a Recovery Certificate, BNRs should not be evaluated. Thus, the behavior that you are observing in that case (i.e. rules evaluate to open) is expected, as the rules try to access VC information which is not available.

@pucherd the updated rule should look like this:

Logic:
  and:
    - if:
        - var: payload.r.0
        - after:
            - plusTime:
                - var: payload.r.0.df
                - 0
                - day
            - plusTime:
                - var: payload.v.0.dt
                - 0
                - day
        - false
    - if:
        - var: payload.r.0
        - before:
            - plusTime:
                - var: payload.r.0.df
                - 120
                - day
            - plusTime:
                - var: external.validationClock
                - 0
                - day
        - false

We'll file a CR to change it on the server...

@pucherd, @mlenkeit, @SchulzeStTSI
New rule BNR-DE-5064 with the fix is available.

@pucherd can you check please and close the issue or comment.

Thank you. Can be closed