Meeting minutes
Issue 269 on Limitations for showing transaction data
Issue 269: Limitations for showing transaction data
Stephen: We were contacted on this spec issue. We have multiple strings that can be displayed to the user. Question was "what are the limitations on this string" (e.g., newlines). We should specify this in some way. I looked at WebAuthn.
… WebAuthn has no normative spec text; it just specifies that the user agent may truncate the display (even if the full string is sent to the authenticator)
… I think we all expect essentially 1-liner text.
… I also plan to look at the FedCM spec
Ian: How does 3DS handle this sort of thing?
<JL> In 3DS: Length: Variable, maximum 40 characters. Type: String Same name used in the authorisation message as defined in ISO 8583-1
NickTR: I think field lengths are commonly defined in specifications.
Jean-Luc: One reason for 40 char length is downstream requirements (ISO) related to those strings
Doug: I wonder about the reverse: would SPC display (or truncate) something that is allowed by 3DS?
Stephen: For images, yes (e.g., resizing a 6K image)
Stephen: Does EMVCo spec say anything about newlines?
Doug: All ASCII characters are allowed (including NL)
Tomasz: SRC spec defines similar elements (e.g., names, etc.) and usually 255 characters long
… in WebAuthn there are name/display name. The spec is nice and specifies a minimum length that the authenticator is able to accept. But authorizes the authenticator to truncate.
… it's ok if the information is truncated.
<smcgruer_[EST]> https://
Ian: I would not support disparity between what is displayed and what is sent to the authenticator (unless there's a signal that something was truncated).
(We look more closely at the WebAuthn spec definitions.)
<smcgruer_[EST]> https://
<smcgruer_[EST]> "Authenticators MUST accept and store a 64-byte minimum length for a displayName member’s value. Authenticators MAY truncate a displayName member’s value so that it fits within 64 bytes. See § 6.4.1 String Truncation about truncation and other considerations."
Tomasz: When more data is provided, it's not an error, but gives authenticators a way to deal with it by truncating.
Ian: Does it suffice to point to WebAuthn?
Stephen: Not for some fields. At this point I am thinking of doing this: define a minimum that will be guaranteed, allow user agent to truncate; send truncated info to authenticator.
Jean-Luc: We may also need to look in to other downstream flows (e.g., ISO 20022)
nicktr: ISO 20022 is more verbose in general than 8583.
… 8583 would cover us for "old school" payments. 40 characters for payer, amount. 3 for currency
… I would advocate for going small to start an expending as the industry requires.
Stephen: What minimum would be acceptable? I'm hearing 40
NickTR: Let's reflect the lengths found in the 3DS integration.
… they've done the lifting.
<SameerT> Kudos to Nick on using the full version of the 3DS spec :)
ACTION: Stephen to create a pull request re: issue 269 leveraging EMVCO 3DS values.
Stephen: For PR API the currency is ISO 3-letter code
… value is a valid decimal monetary value.
[We pause to note that PR API does not allow commas in currency values]
Tomasz: UA should format according to localization preferences
Gustavo: EMVCo has solved for some of this.
<nicktr> The 3DS 2.3.1.1 specification can be downloaded from here
Chrome updates on SPC UX
Stephen McGruer slides on SPC UX iterations
Stephen: Here are some updates on design iterations.
… we are still looking for feedback. This is intended to be iterative!
… some feedback we've received is not yet in the deck I'm sharing today.
Stephen: We want to display issuer/network logos but without having them take over the UX
… the text copy shown in the deck is still a draft
… we are looking at "authenticate another way" in the footer. This is where "opt-out" appears today, but nobody is using opt-out actively today. Our current proposal is to remove opt-out concept from the spec.
… we need to hear from you whether opt-out experience is necessary.
nickTR: This is great; love the clean design.
… I want to wonder aloud about labels" Issuer" and "network"
… also, what are the implications for jurisdictions where there might be a choice of routing?
Stephen: Nick is right; this is some of the first feedback we heard (re labels); this needs to be more flexible.
… we do expect this information overall to be optional.
Sameer: The "network" and "issuer" labels may change in some markets; when it's optional and one logo is displayed, how would it appear?
… some logos may not appear as recognizable if you have a longer issuer name
Sameer: Going back to opt-out. We think that opt-out during authentication is confusing (from a 3DS WG perspective)
Gerhard: There are different use cases (e.g., card, open banking, generic) and might adjust labels based on the accepted terminology and even layout of the use case.
… there are probably 15-20 such layouts in the world.
… regarding authenticate another way, it's tied to the signals available from the dialog.
Gerhard: SPC can be used in 2 contexts: issuer-initiated and merchant-initiated. In the former case, if the user is already on the bank page, then saying "authenticate to your bank" is confusing.
…the display might need to change based on 1p or 3p call of SPC
Gerhard: Regarding opt-out, +1 to removing it from the dialog
<smcgruer_[EST]> Opt Out today https://
Hari: From end user perspective, I don't have a clear idea of who is authenticating me
… if we are bringing a PSP into the mix, how is that information shown?
Ian: (See issue 187 about understanding who is authenticating.)
Stephen: The problem we ran into with "who is doing the authenticating"
… the URLs are not often understandable to users.
Stephen: often 3DS challenge flows are done by ACS's on behalf of issuers.
… if we are talking about passkeys, what you want is the passkey owner name
gkok: What happens when transaction is tokenized?
Stephen: All the information comes from the caller and will be optional.
Sameer: Regarding ACS Url, in most implementations the cardholders want to see the URLs, even if different than the URL of the issuer.
… rearding Gustavo's point, in the 3DS structure, the SPC input is being provided by the issuer.
IJ: Is it preferable to show confusing URL v. nothing? In the past we've talked about the security model where the user agent is displaying the URL (which is then, in some sense, trustworthy information), but that providing a friendlier string might introduce threats. And yet we display lots of other information provided by the caller with the expectation that it will be validated downstream.
Stephen: The question is whether the "on behalf of" info info should be in the tx dialog in addition to the webauthn dialog.
<smcgruer_[EST]> Here, rsolomakhin.github.io is the relying party https://
Ian: what if tx dialog has clue that info will be on the next screen?
gkok: I am wondering how much of an issue this is; we may just need to test on this.
Stephen: We have not explored whether SPC should ping the RP directly during the flow at a .well-known URL. We could be much more confident what name to provide.
Ian: Maybe fetching information from the RP could be done in a lazy fashion (e.g., only if user wants to know by clicking on a "more" UX.)
(Stephen continues through the deck and talks about some UX options that were rejected.)
Stephen: e.g., logos from network and issuer at top were perceived as overly branded for browser-owned UX
Ideas on support for roaming authenticators
Ian: We only have a couple of minutes, but I created some slides related to integrating support for roaming authenticators into SPC. The essence of the idea is to flesh out the "authenticate another way" section of the fallback UX to leverage some of the patterns that WebAuthn implementations are adopting.
Nick: I think a longer discussion of this should happen at next call
Next meeting
9 May