Rationale for limiting claims description path for mdoc to only namespace and element?

[TimoGlastra]

mDOC supports nested claims (e.g. driving_privileges), however the claims description path as defined in Appendix B & C only allows the path array to have a length of two.

It would be useful to also enable setting claim descriptions for nested entries in mDOC credentials, especially since there is no vct with additional metadata that can be fetched for mDOC.

There's probably some complexity involved in mapping CBOR structure to a claims path, but for straighforward CBOR types such as object/map/array it would be quite easy to define.

I tried looking into the discussion of PR #276, but it's quite big and couldn't directly find a rationale for limiting the mDOC type.

[Sakurann]

mdocs' nested claim driving_privileges does not allow to selectively disclose the claims inside the object AFAIK (CDDL does allow deeper nesting, but mdoc spec does not). so for mdoc, 2-layers is the deepest it can go. for driving_privileges, it would be doctype.namespace.driving_privileges. no more.
if this has changed it is a big breaking change for VP spec as well, but otherwise, it's by design

[TimoGlastra]

Yes the query in DCQL only allowing two entries makes sense to me, but this is about the claims description for issuance.

For SD-JWT (or other JSON-based credential formats) I can do:

{
  "path": ["driving_privileges", null, "vehicle_category_code"],
  "display": [
     {
        "name": "Vehicle Category Code",
     },
     {
        "name": "Fahrzeugklassencode"
    },
    {
       "name": "Voertuigcategoriecode" 
    }
  ]
}

But with the current mDOC limitations that's not possible, best I can do is add a claim description for driving_privileges:

{
  "path": ["org.iso.18013.5.1", "driving_privileges"],
  "display": [
     {
        "name": "Driving Privileges",
     },
     // ...
  ]
}

How is a wallet supposed to render labels and translations for nested mDOC attributes?

I'd like to do:

{
  "path": ["org.iso.18013.5.1", "driving_privileges", null, "vehicle_category_code"],
  "display": [
    {
        "name": "Vehicle Category Code",
     },
     {
        "name": "Fahrzeugklassencode"
    },
    {
       "name": "Voertuigcategoriecode"
    }
  ]
}

[Sakurann]

oh thank you for the explanation. yes, i think for VCI it would make sense to relax this 2 entries rule

[Sakurann]

WG discussion

• agreed solving this makes sense
• this could work since it is not a generic mechanism, but with in a defined structure
  @davidz25 would you agree and can help define the above as a CBOR expert?

[Sakurann]

WG discussion:

• discussion centered whether we want a wallet to be able to save a credential doc type it doesn't know about
• agreement this is useful, no strong opposition
• PeterS volunteered to poke holes :)

[TomCJones]

this looks like what i called a bug in putting display information into VC 2.0. It is really counterproductive. Especially when there are 20 different languages.