Closed martin-lindstrom closed 3 years ago
Does 9bcbc70b52b0a70160ad8ec3cf6ca86812eddd3d work for you @martin-lindstrom ?
So this is getting a bit messy with spec in README.md and wiki - one of the reasons I wanted to keep it all in one place and didn't choose for wiki.
Does 9bcbc70 work for you @martin-lindstrom ?
doesn't work for me -> SHOULD -> SHALL
Decision from eHN meeting 2021-05-07: CBOR timestamp is ISO8601.
doesn't work for me -> SHOULD -> SHALL
Was later on fixed in 59ed31c72f06dd4e5278da7ccd038635a3080c17. Complete text for next release is currently as below. Timestamps encoded as defined in RFC 3339, i.e. a profile of ISO8601, something that was already enforced by the JSON schema.
Concise Binary Object Representation (CBOR), specified in RFC7049, defines a number of major data types. The following types are REQUIRED to be used by parties creating electronic health certificates payloads:
Timestamps (defined by JSON type string
and format date-time
) MUST be encoded as CBOR major type 3, a text string, and formatted per RFC 3339, section 5.6, with tag 0 as specified by RFC 8949, section 3.4.1.
CBOR can represent a time stamp both as an int and as a string. However, the schema states that timestamps should be strings:
For the sake of interoperability and to smoothen the differences between JSON and CBOR I think that we need to have a writing (in the wiki or somewhere else) that clarifies this. My suggestion is to be clear that date-time fields should be CBOR encoded using the string representation. Otherwise we'll introduce completely unnecessary interop-problems when going from CBOR to JSON and back.
Also, see https://github.com/eu-digital-green-certificates/dgc-testdata/issues/30.