Criticality of data elements

[davidz25]

It would be good to clarify the semantics of an RP requesting multiple data elements. For example, for the request in README.md

let mDLCredentialRequest = new CredentialRequest(certificate, {
    documentType: "org.iso.18013.5.1.mDL",
    requestedElements: [
        { namespace: "org.iso.18013.5.1", name: "document_number" },
        { namespace: "org.iso.18013.5.1", name: "portrait" },
        { namespace: "org.iso.18013.5.1", name: "driving_privileges" },
        { namespace: "org.iso.18013.5.1.aamva", name: "organ_donor" },
        { namespace: "org.iso.18013.5.1.aamva", name: "hazmat_endorsement_expiration_date" },
    ],
    desiredStorageDuration: {
        days: 7,
    },
})

is the expectation that the user will see this request in their wallet app if the mDL they have doesn't have the org.iso.18013.5.1.aamva namespace? For example, if I have a non-US mDL in my wallet app what should I see it? Or should the request fail with an error?

Of course this depends on how the request is routed and there's likely an OS component which will help route this particular credential request to the appropriate application.

For 18013-5 the answer is cut and dry, 8.3.2.1.2.1 Device retrieval mdoc request says the following: The mdoc shall ignore all unknown data elements in a device retrieval mdoc request when processing the request. ... which opens the possibility that an RP can make requests such as the following

let mDLCredentialRequest = new CredentialRequest(certificate, {
    documentType: "org.iso.18013.5.1.mDL",
    requestedElements: [
        { namespace: "org.iso.18013.5.1", name: "driving_privileges" },
        { namespace: "org.iso.18013.5.1.aamva", name: "domestic_driving_privileges" },
        { namespace: "org.iso.18013.5.1.da", name: "denmark_specific_driving_privileges" },
        [...]
    ],
    desiredStorageDuration: {
        days: 7,
    },
})

to e.g. make a request where the response always contain driving_privileges (b/c it's a mandatory data element according to 18013-5) and if it's an US license they always get domestic_driving_privileges from the AAMVA namespace (b/c it's mandatory according to [1]) and if it's a Denmark license they also always get denmark_specific_driving_privileges (b/c it would be mandatory according to a Denmark-specific profile), and so on.

In other words, this kind of request is expressly permitted by 18013-5 and it will work as the paragraph above explains. Since 18013-7 specifically is built on top of 18013-5 and this browser API is intended to be compliant to 18013-7, then it makes sense to specify that any implementation of this browser API must also provide these guarantees (however the browser ends up routing the request to the underlying wallet).

One proposal I've seen is where all wallet apps register their MDOCs with the OS, including which data elements each MDOC has. And then the OS only forwards the request to a wallet app if, and only if, the MDOC in question has all requested elements. That is, the OS layer interprets all data elements as "critical". In the example above with the RP requesting org.iso.18013.5.1, org.iso.18013.5.1.aamva, and org.iso.18013.5.1.da namespaces such a request would never be fulfilled since no real-world mDL would have all three namespaces.

I would like if we could include language so it's clear that any of the intermediate processing of the request (like "OS" in the above paragraph) should not try and interpret the request in such a way that the request is ever dropped. At most such layers should only do routing and selection, they should not pretend that the RP thinks that all data elements are critical.

I think this is important because I really would like a world where requests in 18013-5 and requests to this browser API are 100% isomorphic and have the same semantics. The other reason it's important is that down the road we want to build query languages w/ concepts of criticality (and other features!) that ideally work across credential shapes and also in-person, in browsers, and in app-to-app APIs in operating systems.

[1] : https://www.aamva.org/getmedia/c4fe2a21-91ff-449d-9df3-5a7e33cf3a8e/mDL-Implementation-Guidelines-1-1_2022.pdf