Use HTTP Accept-Language Header to request Issuer Metadata

[paulbastian]

I propose to extend 10.2.2. Credential Issuer Metadata Retrieval with the recommendation for the Holder/Wallet to pass an HTTP Accept-Language Header according to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language

This would save both Wallet and Issuer a lot of traffic, if the issuer supports many languages for the display properties. The Issuer may pre-generate language-specific issuer metadata files for individual languages. If the Wallet does not send an Accept-Language header, the Issuer may choose to send any language (e.g. english or all).

[c2bo]

Do you think it is smarter to do the language selection via some form of a HTTP parameters or directly separate on a path level? We could for example separate using language-specific metadata files in the .well-known path.

Using the Accept-Language header would force some logic on the endpoint side, whereas if we split on a path level, it would make things easier on the issuer side but might require more than 1 call from the holder (if you want more than 1 language).

[paulbastian]

We thought about that as well. I think it would be possible, e.g. in nginx, to map to static files based on header parameters, but it might not be as simple.

In general we see three possibilities:

• HTTP Accept-Language Header
• Path component .well-known/openid-credential-issuer/DE-de
• Query parameter .well-known/openid-credential-issuer?lang=en

[Sakurann]

Issue #42 related

[Sakurann]

agreed on accept-header
https://docs.google.com/document/d/1q_vcI7PGJLtM3j0jvpLfmiBsj69jCilTzDQCjKRT2xY/edit

[c2bo]

Answer should provide Content-Language Header

[peppelinux]

WDYT about having refs to external json definition instead of configuring an http routing based on http headers?
Would it be good having it as a json object with refs, in a specialized claim?

"i18n_display_uris": {
    "it-IT": "https://that.it/credential-offer/display/it-it.json",
    "de-DE": "https://that.de/credential-offer/display/de-de.json"
}

where a single json would contain

          {
              "name": "PID Provider Italiano di esempio",
              "locale": "it-IT",
              "logo": {
                "url": "https://pid-provider example.org/public/logo.svg",
                "alt_text": "logo di questo PID Provider"
              },
              "background_color": "#12107c",
              "text_color": "#FFFFFF"
            }

this allow us to work by refs and not duplicating the same content over multiple files or using a template system for rendering all the localized display object. I would propose to have the default display in english and the optional i18n within the display or as refs.

A similar approach could be used for credential_definition.credentialSubject.x.display

[peppelinux]

the value of the previous proposal is that if a user wants to inspect the supported langs she doesn't have to guess by sending multiple http requests with different HTTP Accept-Language Header, the localization catalogue is always available within a single metadata.

In addition to this the i18n jsons could be easily served in CDN