I've been working with the various EUDI libraries and I've run into an issue around the validation of the digest on presentation using the EUDI verifier app.
What I discovered was that the digests do in fact not match and the issue seems to come from CBORObject.toDigestIdMapping(). The key value pairs inside the generated Map are not in the same order as the original MDL, which causes the Digest check to fail when the Issued MDL is used in a presentation request later on.
Returned Map:24(<< {"random": h'60935A4F5222D1EF280A1835605DE872', "digestID": 1488939443, "elementValue":"Name", "elementIdentifier": "family_name"} >>)
The function seems to use CBORObject.NewMap, which is an unordered Map. Should the returned Map not align with whatever order the order of keys were in the original MDL? While I don't believe ISO 18013-5 dictates the order of the keys, it lists an IssuerSignedItem having key order of:
IssuerSignedItem = {
"digestID" : uint, ; Digest ID for issuer data authentication
"random" : bstr, ; Random value for issuer data authentication
"elementIdentifier" : DataElementIdentifier, ; Data element identifier
"elementValue" : DataElementValue ; Data element value
}
Worth noting that the MDL that is generated as part of the 'Load Sample Data' feature of the test Wallet provided by EUDI verifies properly because it also do not adhere to the order that is presented in the ISO 18013-5 spec.
@icarboneaq Thank you for bringing this to our attention and for the detailed feedback. We have identified the issue, and it will be addressed in the upcoming release.
I've been working with the various EUDI libraries and I've run into an issue around the validation of the digest on presentation using the EUDI verifier app.
What I discovered was that the digests do in fact not match and the issue seems to come from CBORObject.toDigestIdMapping(). The key value pairs inside the generated Map are not in the same order as the original MDL, which causes the Digest check to fail when the Issued MDL is used in a presentation request later on.
Our MDL IssuerSignedItem:
24(<< {"digestID": 1488939443, "random": h'60935A4F5222D1EF280A1835605DE872', "elementIdentifier": "family_name", "elementValue":"Name"} >>)
Returned Map:
24(<< {"random": h'60935A4F5222D1EF280A1835605DE872', "digestID": 1488939443, "elementValue":"Name", "elementIdentifier": "family_name"} >>)
The function seems to use CBORObject.NewMap, which is an unordered Map. Should the returned Map not align with whatever order the order of keys were in the original MDL? While I don't believe ISO 18013-5 dictates the order of the keys, it lists an IssuerSignedItem having key order of:
Worth noting that the MDL that is generated as part of the 'Load Sample Data' feature of the test Wallet provided by EUDI verifies properly because it also do not adhere to the order that is presented in the ISO 18013-5 spec.