language and direction metadata needed?

[aphillips]

https://www.w3.org/TR/secure-payment-confirmation

Many places in the spec use fields that we've previously discussed as potentially needing language and direction metadata. This issue serves to collect these comments in the most recent review request.

section 1.2.1 https://www.w3.org/TR/secure-payment-confirmation/#sctn-sample-registration example 1 relying party (rp) name field has no lang/dir user field displayName has no lang/dir

section 1.2.2 https://www.w3.org/TR/secure-payment-confirmation/#sctn-sample-authentication example 2 similar comments about displayName in instrument the label for the record total (which says "Total") has no lang/dir

section 4.1.3 https://www.w3.org/TR/secure-payment-confirmation/#sctn-securepaymentconfirmationrequest-dictionary The fields payeeName and payeeOrigin are natural language strings and do not have lang/dir.

section 4.1.7 https://www.w3.org/TR/secure-payment-confirmation/#sctn-transaction-confirmation-ux This section allows alternate UX to be shown by the user agent. This is a use case where the consumer would need lang/dir

We expect to discuss how to progress this issue at TPAC as previously agreed. There is also a tracking issue for working groups to keep track of our work with ECMA-402 and TC39 on getting a data type here

[aphillips]

As discussed at TPAC, I18N has no objection to secure payment confirmation proceeding to CR on the understanding that was progress is made with TC39 (etc) changes can be picked up before PR. Thank you for your help. [This is i18n's action-1204]

[aphillips]

In our recently completed update review, we suggested:

The I18N WG reviewed this in our 2023-01-26 teleconference (sorry that the notes are very sparse) and concluded that going to CR with this unresolved feels like a problem. Rather than referring to the open issue (which is your self-review), it would be better to make a positive statement about the current specification and future direction. Instead of the above note I would suggest instead:

NOTE: internationalization of the displayName via the inclusion of language and direction metadata remains an open issue. Implementations are encouraged to use locale-negotiation to return values in the language requested and to provide display names that do not result in bidirectional text issues. For more information see: (link to follow)

I will provide the missing link shortly.

[ianbjacobs]

@aphillips,

I have some questions about your suggested text. You write that implementations are "encouraged...to provide display names ...". Display names are provided as input to the API; they are not provided by the implementation.

You also say implementations are "encouraged to use local-negotiation to return values in the language requested". The API does not return displayName as a value. However, it does pass the instrument (including displayName) to the authenticator to be signed. I imagined that once we have input on I18N improvements, that data might be enhanced, but today we don't have a mechanism to communicate language information in the clientData passed to the authenticator.

Thus, I'm not sure to understand the advice of the Note.

[aphillips]

@ianbjacobs Thanks. You're right that the advice isn't quite right given the usage of SPC. Perhaps:

NOTE: Currently there is no way to indicate the language or direction of display values such as the displayName. To ensure a consistent user experience, callers should localize these values to match their UI and communicate the locales they prefer the authenticator (??right term??) to use for display strings in the SecurePaymentConfirmationRequest. Any display strings should avoid bidirectional text issues (such as by including appropriate bidi controls). For more information see: (link still to follow)

This note feels a bit awkward, buried as it is in the section on the PaymentCredentialInstrument dictionary, since it could also apply to other text values. Perhaps we should move it somewhere central, such as an I18N considerations section. (We don't generally like those, but this might be a good use for one vs. littering your specs with notes)

[ianbjacobs]

Hi @aphillips,

1) How do callers localize these values (e.g., displayName) to match the Website's UI? These values are provided in JavaScript. I'm not sure what guidance to provide to callers of the API since I don't think they have any way to localize the values.

2) Regarding guidance to callers to avoid bidirectional text issues, is the guidance really "Until the API provides greater support for localization, there may be issues when implementations render bidirectional text." I'm not sure that we should tell people to avoid using bidirectional text; people don't use it unless they need to.

I do understand the point about these issues being relevant to multiple text values; let's work out the best formulated guidance then figure out where to express it.

[ianbjacobs]

Hi @aphillips,

With the merge of pull request #232, I am closing this issue. (Feel free to remove the label. :)

Thank you, Ian