Validity timestamp truncation

[dalebowie]

As a caller to the library I can addValidityInfo that includes specific timestamps. It appears during encoding these timestamps are truncated. Whilst one could interpret this truncation as broadly in alignment with the standard's guidance around linkability (see second-last paragraph on page 51 of ISO/IEC 18013-5:2021(E)), should that truncation really be done when the caller's input is specifying their own values?

I admit it is a limited window where this is problematic, but in the current implementation, I can:

1. At GMT 9am get a certificate signed for intended use with this library
2. At GMT 3pm use this library to generate an mdoc with current timestamp and the certificate obtained above.
3. The produced mdoc then fails to validate because its signed date is truncated to GMT midnight, well before the GMT 9am when the certificate is valid for.

My thought on a fix might be two-fold:

1. If timestamps are specified via addValidityInfo, then no truncation should occur.
2. At signing time, the timestamps are auto-generated and truncated if not previously supplied via addValidityInfo. Whatever timestamps are present (either auto-generated or caller-specified) are validated against the certificate timestamps to ensure an invalid mdoc isn't produced.

[siacomuzzi]

Let me investigate this further, given that we are using an external library for cbor encoding.

[dalebowie]

I figured it might have been related to the custom extension logic here for dates: https://github.com/auth0-lab/mdl/blob/main/src/cbor/index.ts#L15-L25

[siacomuzzi]

Let me explain why we are using that CBOR tag for Dates...

ISO 18013-5 (section 7.2.1) defines the following data elements for mDL:

Identifier	Encoding format
birth_date	full-date
issue_date	tdate or full-date
expiry_date	tdate or full-date

And it specifies "full-date" as full-date = #6.1004(tstr), where tag 1004 is specified in RFC 8943. Which is the CBOR tag for a text string representing a date without a time:

"issue_date": 1004("2018-08-09"),
"expiry_date": 1004("2024-10-20")

[siacomuzzi]

I guess we could include an option to use the tdate encoding format instead of full-date for issue_date and expiry_date elements.

[siacomuzzi]

Now, for validityInfo structure, you are right... the signed, validFrom, validUntil and expectedUpdate attributes must be tdate (Tag 0), instead of full-date:

"validityInfo": {
  "signed": 0("2022-04-15T06:23:56Z"),
  "validFrom": 0("2022-04-15T06:23:56Z"),
  "validUntil": 0("2027-01-02T00:00:00Z")
},

We have to fix that.

[github-actions]

🎉 This issue has been resolved in version 1.5.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀