Localization for display values should not be implemented with an array

[Dindexx]

Currently, the spec defines the localization of display values with an array.

For example:

"display": [
    {
        "name": "Example University",
        "locale": "en-US"
    },
    {
        "name": "Example Université",
        "locale": "fr-FR"
    }
] 

This forces us to iterate over the array in order to find the respective localization. It would be easier if we would change this to a JSON object.

For example:

"display": {
    "en-US": {
        "name": "Example University"
    },
    "fr-FR": {
        "name": "Example Université"
    }
}

For implementers, this would mean we can go from this:

// Pseudocode

foreach(display in displays) {
    if (display.locale == "en-US") {
        result = display
    }
}

to this

// Pseudocode

result = display["en-US"]

Alternatively, if no extra fields are needed in the object, we could also just define it as a field, which would make it even more easier but also more difficult to extend for the future:

"display": {
    "en-US": "Example University",
    "fr-FR": "Example Université"
}

[paulbastian]

I support this

[peppelinux]

yes, it is more smart, this enables interesting code generalizations like display.get($user-agent-lang, {})].get("name") I love. It definitively simplifies the implementations according to the way we access to each element, even if it is less correct from a formal point of view (as it was before)... it is definitively more smart for who develop the product.

[jogu]

I just want to point out that the code examples are, I think, over simplified. E.g. if the user's language is "en-us" then they won't return a value tagged as "en", but I believe they should.

Perhaps the conclusion is the same anyway...

[Sakurann]

I agree this change makes sense. who is willing to volunteer to do a PR?

[selfissued]

No matter which representation we choose, we may want to say something about the ability to use language identifiers without a country designator, and how they interact in this context. For instance, the following language identifiers could all be used together:

• fr
• fr-CA
• en
• en-NZ

[selfissued]

As I described at https://github.com/openid/OpenID4VCI/pull/198#pullrequestreview-1800714880, this would lose the ability to use the array order to express preferences among languages, which other OpenID specs do. We should not make this change.

[Sakurann]

@selfissued As @jogu pointed out in the PR comment, there is no need for the Issuer to express a language preference in its metadata.

Also I am not convinced that the fact that OIDC has a list of preferred locales, which is a different structure in a different place is a good argument not to do this change in VCI.

[Sakurann]

Jan-11-2024 WG call agreed to close this PR and the issue and if there is an appetite to discuss this further, a new issue would be needed.