Localisation support for VC schema attributes and value about aries-mobile-agent-react-native HOT 12 CLOSED

I don't think we would ever want to localize values, but we would want to localize the schema attributes -- the labels for the values.

I don't think the intention of 0043 was to be used in this way, but it's an interesting idea. Somehow the holders and verifiers have to get the "schema localization" file and know it was from the issuer.

The issue of localizing the schema attributes (including the Credential Type) should be kept separate from the more straight forward issue of localizing the rest of the wallet. The latter is a well known issue and we should use the best practices for mobile apps for that.

The BC Team talked about this issue and decided to start with the following:

• Have a default set of presentation rules for the schema metadata based on what is available with any VC (particularly for Indy AnonCred VCs). For example, the rule might be to extract the tag part of the credential definition, convert "_" and "-" to spaces and capitalize the name. The precise rules would be determined by looking at real examples in use in production and define best practices for the existing credentials. Similar rules for attribute names.
• Define a mechanism to localize a schema that an issuer could implement. E.g. given a Schema ID or a CredDef ID, get a "bundle" (format TBD) of l18n data to apply to the presentation of the schema to localize it. For that we will look for work already done, or if we don't find anything define that ourselves. For example, perhaps we can use the work on "Overlay Capture Architecture" in ToIP to do this.
• With the format and processing rules of the bundle defined, define a mechanism for the issuer to publish a "bundle" for a given credential type, so that the wallet has a way to discover, retrieve and use the bundle for a given VC. For example, it might be published by the issuer to a .well-known location on their web site.

Note that for JSON-LD credentials, I've heard that their is a localization mechanism that can be used when defining the context of a context, but I've not seen exactly how it works. If that is in the JSON-LD spec, issuers could use that for l18n of the VCs.

Lots of ideas and questions to work through for this issue.

from aries-mobile-agent-react-native.

Further to @swcurran 's comment about localizing the credential type and attribute labels (as opposed to the attribute values), I don't think it makes sense to include these in the credential, or in the DIDcom messages. The issuer may not know, at the time of issue, what languages need to be supported. If we implement a separate "bundle" as @swcurran suggests, then this can be updated as new languages are added. For example when the credential is issued possibly the bundle only contains English and French, but later on support is added for Chinese and other languages.

Another consideration is standardization of attributes across credentials, for example standard attribute names for things like First Name, Last Name, Address, Birth Date, etc. This is supported in JSON-LD credentials but not Indy. If we adopt some kind of standardized attribute names, then this would help with the localization issue (the attribute names could have standardized translations as well) and also facilitate requesting proofs across different credentials.

from aries-mobile-agent-react-native.

Regarding translations of attribute values, I think the internationalization RFC could support that, as it would be the issuer that would have to provide these values when the credential is issued (and only the issuer would know which values could be translated)

from aries-mobile-agent-react-native.

Have a default set of presentation rules for the schema metadata based on what is available with any VC (particularly for Indy AnonCred VCs). For example, the rule might be to extract the tag part of the credential definition, convert "_" and "-" to spaces and capitalize the name. The precise rules would be determined by looking at real examples in use in production and define best practices for the existing credentials. Similar rules for attribute names.

We also do that! May be good to write down some rules for it so we can be consistent across apps

Note that for JSON-LD credentials, I've heard that their is a localization mechanism that can be used when defining the context of a context, but I've not seen exactly how it works. If that is in the JSON-LD spec, issuers could use that for l18n of the VCs.

From the Aries RFC on JSON-LD compatibility:

It doesn’t support localization of keys--only values. There are corner cases where key localization is desirable.

from aries-mobile-agent-react-native.

Consider linking Indy credential attributes to schema.org-defined properties? Apparently there is a plan to provide translations at some point:

https://schema.org/docs/faq.html

Q: Is schema.org available in multiple languages? When is that coming? What languages is the markup available in?

Schema.org markup can be used on web pages written in any language. The site is currently available in English only, but we plan to translate to other languages soon. The markup, like HTML, is in English.

from aries-mobile-agent-react-native.

Are we talking here about localizing the credential attribute names or how they appear on various devices? Imagine the most trivial "name" credential:

{ "name":"Darrell O'Donnell" }

and, en francais
{ "nom":"Darrell O'Donnell" }

Those, data-wise, are two different credential types, with different credential schemas.

OR - are we talking about how I learn how to render those?

NAME: Darrell O'Donnell
NOM: Darrell O'Donnell

and in Canada:

Name/Nom: Darrell O'Donnell
or
Nom/Name: Darrell O'Donnell

from aries-mobile-agent-react-native.

How they are displayed in the UI

I.e. a credential can contain { "name":"Darrell O'Donnell" } or { "name_nomme":"Darrell O'Donnell" } (the latter because Quebec is very fussy about using French), then the UI may display one of:

NAME: Darrell O'Donnell
NOMME: Darrell O'Donnell
Name/Nomme: Darrell O'Donnell

... or whatever

from aries-mobile-agent-react-native.

mDL (ISO 18013-3) is quite explicit about its attribute names (e.g. family_name, given_name, birth_date, issue_date). The rendering of that data is application-specific and PERHAPS there can be a data dictionary with well-known translations. For rich data ecosystems that would be a good thing to have.

from aries-mobile-agent-react-native.

If we have a standard set of attribute names then we should be able to have a standard set of translations. It would be nice if the attribute names were standard across different credentials (for example does a Health Card also have a family_name and given_name?)

Just on the topic of names, when the BC Health folks were issuing the PoV cards, they had to re-issue twice to make sure to include all name information. The first time they just included given and family names, but had to include middle names because these are required for some non-english names. I notice that mDL has only 2 attributes for given and family names, I guess this means all given names are jammed into one attribute?

from aries-mobile-agent-react-native.

mDL uses given_name for multiple names.

"First name(s), other name(s), or secondary identifier of the license holder"

from aries-mobile-agent-react-native.

I suggest we look to create a Label Overlay, per OCA.

https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0013-overlays#label-overlay

from aries-mobile-agent-react-native.

I think this is being dealt with as part of OCA. Quebec has done a PoC already and BC will do it. What can be contributed back to Bifold will be.

Closing stale issues as per July 19 Bifold UG call. Please re-open if unresolved or if its still relevant.

from aries-mobile-agent-react-native.