jkiddo
commented
3 years ago You are not allowed to group mulitple types in a DGC. Either it is test, vaccination or recovery AFAIK
Closed vitorpamplona closed 3 years ago
jkiddo
commented
3 years ago You are not allowed to group mulitple types in a DGC. Either it is test, vaccination or recovery AFAIK
vitorpamplona
commented
3 years ago Can you point me to where on spec this restriction is written out?
Because the JSON I shared passes the Schema compliance test as defined today.
In other words, the schema doesn't say: oneOf ["v", "t", "r"]
jschlyter
commented
3 years ago The schema allows for more than policy, this is a deliberate design choice. There's also a discussion whether two vaccinations should be included or just the last one, not sure if it was resolved but @gabywh and @sondaica might know more.
gabywh
commented
3 years ago oneOf - correct, it does not. It also does not say - which is perhaps more the intent - anyOf. as there were reports of some validation issues with anyOf. I didn't look further into those validation issues (yet).gabywh
commented
3 years ago This is a valid DGC at the moment. It won't fit in the QR.
Here is a png version of the QR generated for your quoted payload:
QR params:
But as a verifier, I want to make sure I am supposed to expect massive payloads like the on below.
Could you please quantify "massive"?
Also, what happens when payloads don't fit in the QR?
Same protocol as has been established and used worldwide for decades for both HL7 and DICOM standards.
For the QR code there is an overall recommended max payload byte size. The final payload byte size depends on many factors, not least of which is the amount of repetition in the source data, since once stage of processing in the pipeline is LZMA compression.
If you add up the length of all fields in the JSON schema you may well exceed the max payload bytes in the end, depending on the data. This is no different to the HL7 and DICOM international standards and was an explicit and conscious choice made in conjunction with the eHealthNetwork Semantic sub-group. Moreover, since there is no max limit on the number of entries in an array, it is an arbitrarily trivial task to construct an artificial example that will exceed, at the end of all the processing, the max payload bytes.
Do issuers create many QRs?
Can we assume if the name + dob matches, it is the same person?
No need to assume: these are the two fields the proposed EU legislation contains for matching with e.g. passport documents.
gabywh
commented
3 years ago Short answer to original question: are multiple certificate types allowed in one payload? Yes.
vitorpamplona
commented
3 years ago Here is a png version of the QR generated for your quoted payload:
What is this QR? It does not start with "HC1:". This is not a valid HCERT since it's just a massive JSON string into a CBOR file. Where is the CWT? It's not following the spec. Did you just paste the text on a CBOR file?
Could you please quantify "massive"?
Anything over 500 bytes is massive and won't be printable/usable with ease. It creates major practical problems for printing and verifying QRs.
vitorpamplona
commented
3 years ago Here, I just made a one for you that actually follows the spec:
109x109 QR bits at 25% ECC, 1485 bytes. MINIMUM printable size is 55x55mm, which occupies 52% of the printable area of an A5-based card.
Thus MASSIVE.
gabywh
commented
3 years ago Here is a png version of the QR generated for your quoted payload:
What is this QR? It does not start with "HC1:". This is not a valid HCERT since it's just a massive JSON string into a CBOR file. Where is the CWT? It's not following the spec. Did you just paste the text on a CBOR file?
Sure. Point being I just took your payload verbatim and you see it reduce.
gabywh
commented
3 years ago Here, I just made a one for you that actually follows the spec:
109x109 QR bits at 25% ECC, 1485 bytes. MINIMUM printable size is 55x55mm, which occupies 52% of the printable area of an A5-based card.
Further point from above being: it is a simple task to construct sth that is arbitrarily big as payload, whether meaningful or not. That was my point.
dirkx
commented
3 years ago Is it just mee - I get 541 raw bytes / payload level (or as base45:
HC1:NCFN1U:9QMWQ/532LT9+B35EPZ15F8C:2K0TJ9SMZD PF-ZLTUTFTQ9ENSXTSGF03LCR4CLDW7RRIS+OT$:75S0Q34GR37BFIUS$Q8WL00XP2PGXKMI6HNLSI-AD747EMO4JF4K8M1PFVS*FOETGTG.GC-RSC2TG7QS8U7MUM T8:IYPGO0FMX2KEQCU9+ 9QFS8FEWBQOYK8QU6Y5PA3OMTWZIJ8B0TH*+692TAPKE:MQUH5ORTPK.O9IWR6.MO*A.WMB8A0H8I/QA2H:0L:8A9WL W9F1LPDJ4PL91U+ZK-70NZ2QQHXN5XDWAR4$:9798J$C-P3XNI4:BX55.VCH:S4F2X37ZB0O804Q0EQG65IXTD44QDFOEV06%8 V5435SQ2WVLEXVK.4+2BZ%U12UXFHHEJYYMFPAJ-AT3GY$K1538/L1ZF$*13+JQVJ$84.YEW0P2YJK-NDGHFEJ7ZCJI16LM3MOC-BX*I4ES5RQTNH/L5FK3BJ8KIBDD7.MVG0PKC91%8+7RF.0*VKX1ELYHU SXZA:LF9+O33WC628IDUHJZ8PQ*E66P M9RS3PLI2ECW0V9CPJDRT-EQG81163$A$O0X7OF8QWY1N4H:S5HJ4WOLK 5JX08MA6GI WER*OCP0:LI/ZF5K0 *5KB2EWF9NJS56XDQYUTV/OVRLOE7I9M56W$ZAD08ZONHLUABL*3EM8DTCU0OBIZR0ZQI8RS0P6AW8ZJA-LEDD4CW8/4//4I+7:XEU24/ VTQV+SIZ1O82D1*GOLNKZNBXFADF*UUW/LCWV8SR:6KUF3.4% or:
which seems pretty managable to me. Commands are
pbpaste | ./cose_sign.py | qrencode -o x.png
pbpaste | ./cose_sign.py -b | wc -cWith the above JSON as is in the 'pbpaste' command.
gabywh
commented
3 years ago Sure. I also got smaller by doing full serialize etc - but that wasn't the main point I was making, I thought I'd just stick to the OP text to prove the point, but I guess that message didn't arrive. Whether you serialize this down or not - it is a trivial task to keep adding to the source data until you get something that will no longer fit.
vitorpamplona
commented
3 years ago @dirkx also not following the SPEC. Missing CWT and structure is incorrect.
I am a little concerned that you folks are debating by presenting QRs that do not follow what is specified by yourselves.
I hope this is not how you are making specification decisions and that somebody has a full implementation to test things before making an opinion about it.
dirkx
commented
3 years ago Hmmm - that would be odd.
In your opinion - are the official test vectors in https://github.com/eu-digital-green-certificates/dgc-testdata (e.g. /NL/) correct ?
vitorpamplona
commented
3 years ago https://github.com/eu-digital-green-certificates/dgc-testdata
I have not tested them all yet, but the 3-4 countries that I tested were correct.
DK, for instance
[
{ "Map": [ [ 1, -7 ], [ 4, "uE7ViYTSegg=" ] ] }, <- unprotected COSE header
{}, <- protected COSE header
{
"Map": [
[ 1, "DK" ], <- CWT
[ 4, 1620909698 ], <- CWT
[ 6, 1620650498 ], <- CWT
[
-260, <- HCERT
{
"Map": [ <- HCERT v1
[
1,
{ <- Payload
"r": [],
"t": [],
"v": [
{
"ci": "urn:uuid:1c11e5a6-8008-4cf2-8e67-d5dac166e67a",
"co": "DK",
"dn": 2,
"dt": "2021-04-13",
"is": "Danish Health Data Authority",
"ma": "ORG-100030215",
"mp": "EU/1/20/1528",
"sd": 2,
"tg": "840539006",
"vp": "1119349007"
}
],
"dob": "1983-01-06",
"nam": {
"fn": "Klaus",
"gn": "Jørgensen",
"fnt": "KLAUS",
"gnt": "JOERGENSEN"
},
"ver": "1.0.0"
}
]
]
}
]
]
},
"S+aHxyGjTcmbUV1TaZDLmFNcLC+d0OgDsB/OICbXodn5tfcnpuu9oSq34fob0m0/LJgRxRsV46UlIfKne2Y2Lg=="
]As you can see, the lack of precision on what to put on the payload makes some countries add:
"r": [],
"t": [],and others not even include those fields. Should verifiers understand empty arrays as "There is no R and T for this person" as opposed to "We don't know if there is an R or T for this person" when fields are not present.
In other words, an empty array means something different than not including the field. But that difference is not clear on the spec.
dirkx
commented
3 years ago Ok - good. As that is the same code creating it. Thanks!
vitorpamplona
commented
3 years ago Ok - good. As that is the same code creating it. Thanks!
Then there is a bug somewhere, because your QR only contains this below. There is no CWT.
{
"tag": 18,
"value": [
{ "Map": [ [ 1, -7 ], [ 4, "1P87cFkLGLc=" ] ] },
{},
{
"ver": "1.0.0",
"nam": {
"fn": "d'Arsøns - van Halen",
"gn": "François-Joan",
"fnt": "DARSONS<VAN<HALEN",
"gnt": "FRANCOIS<JOAN"
},
"dob": "2009-01-28",
"t": [
{
"tg": "840539006",
"tt": "LP217198-3",
"tr": "260415000",
"ma": "1232",
"sc": "2021-04-13T14:20:00+00:00",
"dr": "2021-04-13T14:40:01+00:00",
"tc": "GGD Fryslân, L-Heliconweg",
"co": "NL",
"is": "Ministry of VWS",
"ci": "urn:uvci:01:NL:GGD/81AAH16AZ"
},
{
"tg": "840539006",
"tt": "LP217198-3",
"tr": "260415000",
"ma": "1232",
"sc": "2021-04-13T14:20:00+00:00",
"dr": "2021-04-13T14:40:01+00:00",
"tc": "GGD Fryslân, L-Heliconweg",
"co": "NL",
"is": "Ministry of VWS",
"ci": "urn:uvci:01:NL:GGD/81AAH16AZ"
},
{
"tg": "840539006",
"tt": "LP217198-3",
"tr": "260415000",
"ma": "1232",
"sc": "2021-04-13T14:20:00+00:00",
"dr": "2021-04-13T14:40:01+00:00",
"tc": "GGD Fryslân, L-Heliconweg",
"co": "NL",
"is": "Ministry of VWS",
"ci": "urn:uvci:01:NL:GGD/81AAH16AZ"
}
],
"r": [
{
"tg": "840539006",
"fr": "2021-04-21",
"df": "2021-05-01",
"du": "2021-10-21",
"co": "NL",
"is": "Ministry of VWS",
"ci": "urn:uvci:01:NL:LSP/REC/1289821"
}
],
"v": [
{
"tg": "840539006",
"vp": "1119349007",
"mp": "EU/1/20/1528",
"ma": "ORG-100030215",
"dn": 2,
"sd": 2,
"dt": "2021-05-07",
"co": "NL",
"is": "Ministry of VWS",
"ci": "urn:uvci:01:NL:PlA8UWS60Z4RZXVALl6GAZ"
},
{
"tg": "840539006",
"vp": "1119349007",
"mp": "EU/1/20/1528",
"ma": "ORG-100030215",
"dn": 1,
"sd": 2,
"dt": "2021-04-15",
"co": "NL",
"is": "Ministry of VWS",
"ci": "urn:uvci:01:NL:PlA8UWS60Z4RZXVALl6GAZ"
}
]
},
"vEcau6Lw//IgnMPVvDpm8r5kFaw6KVZb+zEOagypmpV9PDQG4tquv0ciRDke2jQeRkRbgjTliRcoufABt5dQvQ=="
]
}Ah yes -and no - user error - I had assumed your example had those - & blindly copied it - not realising it was a naked one without the 1,4,6 and -260 payload package:
HC1:NCFOXN%TSMAHN-H*ZSW7G7LG$/DN/TIF4NSR-363RV%CM5X4LDSH PW%I%7M6TMNO4*J8.79 %RWKP/HLIJL8JF8JF7LPMIH-O92UQ$H9V Q$SHT02XDP*/AKYA9Q9NRA699%E9EN95CQ8PENK9$O7XR7CUM39RM:7T/5+Y5R$K -OG75U9STER8+P0CQ:XO$BPT/5-Z7QT4KZ5QNQKOR.O6-5PCDST/5+V4YC52HP4EOHCR+9AODPQKMBFF5IAXMFU*GSHGRKMXGG6DB-B940JIBG1KKQJKM+GUEE4C9Q2LCIJ/HHDJLEFG.IAQKC6JKXIM0JAMLE9 K4HGZJK-GGK3M*FE/IK*+I8HGXGGI0NHAH+G9$I8OV6UKHWH8-O9CN5L-RNYBS*R1H5OOE*167WQ:JUH0VV0Q.V9P8Q61A31A32Q%Z0YIA3HEX3E1.BLEELEACI8PMJD8B:8E KEE%G6EDX0KEEDHJEKEQ1L5E.3EBKWRVL0HM/HQ:GS:HNVK*23M2OUR5OVBJTTR$MVS5BN6OQ17LAPBKEOA5F4+G9/-GPN1S68$GV6*I1XM5/4M58NHPCGBXHQESO4SO076VXLR 5HOP+MMBT16Y5+Z9XV7*$K8KG+9RR$F+ F%J00N8GJ4M6C09T./0FM0QW6936AJ7XQ6UX40C5O67795Y%KHLSISEN%54Z8ACAK1I%Y8QBF%GJQXI:6AAU82TKA1I9M7X LN%T4+8/:A/VK8WI.2M3BE$9K:Y584QS:LV/MO4J.%2JXNGRCFSL6DV EDM3V 0AJG4V:IA LSBO9*7O6D%+V*7KHFR*/METB6QEACA0K4*SR6$PHK7IWMT-R*-405M%/Gand:
should have the payload prefix:
Issuer : NL
Experation time : 1636555497
Issued At : 1621003497
Health payload : {"ver": "1.0.0", "nam....Z4RZXVALl6GAZ"}]}Should weight in at 570 bytes.
vitorpamplona
commented
3 years ago Your QR actually is:
vitorpamplona
commented
3 years ago Since the HCERT recommendation is to use ECC Q (which I definitely agree), you shouldn't report bytes sizes or print QRs in other levels (it just confuses everyone).
Here's the same QR with ECC Q, where half of my phones (I happen to have a phone test bench with 32 different models) have difficulty reading already.
dirkx
commented
3 years ago Thats quite ok - we generally use the raw full 8 bytes going in when comparing / colloquially. But thanks for this nice long example. It is good to see that something even this extreme is borderline workable.
vitorpamplona
commented
3 years ago I made a more realistic payload with a similar structure (2 vaxs, 1 recovery, 3 tests) merged from sources at testdata. The original one I assembled here had too many copy/pasted duplications (good for the Zlib).
This one is 129x129 bits, 2080 bytes (ECC Q), minimum printed size is 70x70mm.
{
"ver": "1.0.0",
"nam": {
"fn": "d'Arsøns - van Halen",
"gn": "François-Joan",
"fnt": "DARSONS<VAN<HALEN",
"gnt": "FRANCOIS<JOAN"
},
"dob": "2009-02-28",
"v": [{
"tg": "840539006",
"vp": "J07BX03",
"mp": "EU/1/20/1528",
"ma": "ORG-100030215",
"dn": 1,
"sd": 2,
"dt": "2021-02-16",
"co": "BG",
"is": "Ministry of Health",
"ci": "urn:uvci:10:BG:3P3K6F5GLW46LRZT#H"
}, {
"tg": "840539006",
"vp": "J07BX03",
"mp": "EU/1/20/1528",
"ma": "ORG-100030215",
"dn": 2,
"sd": 2,
"dt": "2021-03-09",
"co": "BG",
"is": "Ministry of Health",
"ci": "urn:uvci:10:BG:3P3K6F5GLW46LRZT#H"
}],
"r": [{
"tg": "840539006",
"fr": "2021-02-20",
"co": "AT",
"is": "BMSGPK Austria",
"df": "2021-04-04",
"du": "2021-10-04",
"ci": "urn:uvci:01:AT:858CC18CFCF5965EF82F60E493349AA5Y"
}],
"t": [{
"tg": "840539006",
"tt": "LP6464-4",
"sc": "2021-05-10T11:03:35Z",
"dr": "2021-05-11T10:03:35Z",
"tr": "260415000",
"tc": "Test Center DK",
"co": "DK",
"is": "Danish Health Data Authority",
"ci": "urn:uvci:01:DK:9835661370E6558FAB0D5EE0DAFF39C8#G"
}, {
"ci": "urn:uvci:01:HR:MZ0000000371",
"co": "HR",
"dr": "2021-04-25T00:00:00+02:00",
"is": "Ministry of Health",
"sc": "2021-04-25T00:00:00+02:00",
"tc": "KLINIÄŒKI BOLNIÄŒKI CENTAR RIJEKA",
"tg": "840539006",
"tr": "260415000",
"tt": "LP6464-4"
}, {
"ci": "urn:uvci:01:HR:MZ0000000378",
"co": "HR",
"dr": "2021-04-20T00:00:00+02:00",
"is": "Ministry of Health",
"ma": "1223",
"nm": "BIOSYNEX COVID-19 Ag BSS",
"sc": "2021-04-20T00:00:00+02:00",
"tc": "ZAVOD ZA JAVNO ZDRAVSTVO OSJEČKO-BARANJSKE ŽUPANIJ",
"tg": "840539006",
"tr": "260415000",
"tt": "LP217198-3"
}]
}HC1:6BF/-KVO9$P3VS3OXM:TSIPGD:NVB66OICI4WUNW2WA6UPD8Q1C7X7AWRIZE:1IPRGCRNA3D+P7% QJ/REUOXF4NYHZIS-UB4D2RJH*I5ROE.*O29GK:1VIF/$M-8NGDIUABE3MSYH965EB5WPLFGWAFUA F8-EGTPN3DR8Q.+QXSP8O3QYPWPAHUD./V7PVT9L48GC-HK8EEQ7%ST5WVTM4V4Q2IIGUN%-2ZIOHEJHVCQ/JWFTIPF.03T4S2HB 80EI2MMDR.A/LI5-KNJIV/N-DCFH1DDC1VQ.$C1UD4-8904.$MI8O2VO%8P9 V%X1R62A:AMX8Z/UBZV0%6G.2531Y80DNGOZ4/VPLB2Z8Q783+KIPHK-1PNZVW6BVBR:Q8-:2M JQ%CST5A%CC9H183/PGWXL:11045S72JS4*RET+PVE9F9FJ82KNBD-IFN8*+AB+B3TL+.PT-AIRG202RRN1+26R4I+76.CE7APR6DOE5E83YL7IAYLDV1ME*DAH460QSL27TLQZINNV729K50T5HIWIZ6E/%PUQTE15+G4*G1/9JU7ADZ6/0N830IDN22K6 L/-VVZP1KPA09LQ0UL71P1UVG.G6WVDFMH-CBGUMXVP VE+EESZ9W%A-GPCT4GJ7WPPQSO:MR33V3GR:VM.RPYT5UYKWMRIPJUW49VG535BPIW947IEUS3$$JEJV6NBKYA3M4U8PC7B$XSELPI0RNZL740WB6BSSM-BW6QH91M+DU4707CEU5FXG8QEL*SATF7JG2DTQL3M1M%NH8H41C0GZAFQ6IVJ**AU:0IGRIZ4BTQ9 AD7LH4AG2CWK12.Q+V79XK*OJQ9RP/D6SM%3D0MKKQ8I$FV.B/G4YFWX.8O*UMW6M*J8XRCNFW8NN2T9:8W/18F8EVC3C7.WHX32E*EOJG:PICT9SBVAGW$:7$ MBE00BW4WCMUCRO2SF8:TIIS9+9HWWF.V3TE8JSM2XKW RW+C+0Q$8WLC61/QICNGHRVQG2Y3D:V7ZE452HVK$W3$54LN7G9IRMGEMV:DAAD3OGRXFVB6E LBGFVR+1ZFS6TM$LK%PQZB818G%4PY4H6/H*-N* SI*1J2G*NTC16W-52-O11GY UFPBZ.1Y3KF9OILV:LOHCPT7W78TRN9U5CM-R54O1/523K5AVAK1V2MBBD.EU2488 RW3QUMJDebug
{
"tag": 18,
"value": [
{ "Map": [ [ 1, -7 ], [ 4, "Rjene8QvRwA=" ] ] },
{},
{
"Map": [
[ 6, 1621011766 ],
[ 4, 1684036800 ],
[
-260,
{
"Map": [
[
1,
{
"ver": "1.0.0",
"nam": {
"fn": "d'Arsøns - van Halen",
"gn": "François-Joan",
"fnt": "DARSONS<VAN<HALEN",
"gnt": "FRANCOIS<JOAN"
},
"dob": "2009-02-28",
"v": [
{
"tg": "840539006",
"vp": "J07BX03",
"mp": "EU/1/20/1528",
"ma": "ORG-100030215",
"dn": 1,
"sd": 2,
"dt": "2021-02-16",
"co": "BG",
"is": "Ministry of Health",
"ci": "urn:uvci:10:BG:3P3K6F5GLW46LRZT#H"
},
{
"tg": "840539006",
"vp": "J07BX03",
"mp": "EU/1/20/1528",
"ma": "ORG-100030215",
"dn": 2,
"sd": 2,
"dt": "2021-03-09",
"co": "BG",
"is": "Ministry of Health",
"ci": "urn:uvci:10:BG:3P3K6F5GLW46LRZT#H"
}
],
"r": [
{
"tg": "840539006",
"fr": "2021-02-20",
"co": "AT",
"is": "BMSGPK Austria",
"df": "2021-04-04",
"du": "2021-10-04",
"ci": "urn:uvci:01:AT:858CC18CFCF5965EF82F60E493349AA5Y"
}
],
"t": [
{
"tg": "840539006",
"tt": "LP6464-4",
"sc": "2021-05-10T11:03:35Z",
"dr": "2021-05-11T10:03:35Z",
"tr": "260415000",
"tc": "Test Center DK",
"co": "DK",
"is": "Danish Health Data Authority",
"ci": "urn:uvci:01:DK:9835661370E6558FAB0D5EE0DAFF39C8#G"
},
{
"ci": "urn:uvci:01:HR:MZ0000000371",
"co": "HR",
"dr": "2021-04-25T00:00:00+02:00",
"is": "Ministry of Health",
"sc": "2021-04-25T00:00:00+02:00",
"tc": "KLINIÄŒKI BOLNIÄŒKI CENTAR RIJEKA",
"tg": "840539006",
"tr": "260415000",
"tt": "LP6464-4"
},
{
"ci": "urn:uvci:01:HR:MZ0000000378",
"co": "HR",
"dr": "2021-04-20T00:00:00+02:00",
"is": "Ministry of Health",
"ma": "1223",
"nm": "BIOSYNEX COVID-19 Ag BSS",
"sc": "2021-04-20T00:00:00+02:00",
"tc": "ZAVOD ZA JAVNO ZDRAVSTVO OSJEČKO-BARANJSKE ŽUPANIJ",
"tg": "840539006",
"tr": "260415000",
"tt": "LP217198-3"
}
]
}
]
]
}
]
]
},
"pX3mE3XmSXF2huNV8NnkqJMZQRmJ3e0SgPPjuB7EguZf45gK884cACyTXlrSeaVpLuYemIcp7aSMRAKpxA7+"
]
}Ok - I get 808 bytes raw. Which is not fun - but still doable at 97 (H)or 129 (Q) pixels squared. Thanks for a nice example. And in the end of the day - this is the sort penalty you pay for having a fully off-line, no tracking sort of system v.s. how much do you really have to carry with you.
This is a valid DGC at the moment. It won't fit in the QR.
But as a verifier, I want to make sure I am supposed to expect massive payloads like the on below.
Also, what happens when payloads don't fit in the QR? Do issuers create many QRs? Do we merge them by name? Can we assume if the name + dob matches, it is the same person?
Or is there another digital way to transfer bigger credentials? Sending the HC1 in plain text?