Meeting minutes
SPC user journey improvements
smcgruer_[EST]: Thanks to our designer David! This is draft, we hope to understand underlying needs through this exercise.
[Stephen walks through slides]
Stephen: In the slide we refer to "issuer"; is that too card-specific? Is there are more general term we could use?
… we have not yet figured out a way to put the RP origin in the dialog. The concern is that it might not make sense to the user.
… in many cases the RP origins are opaque.
… and sometimes the service is provided by an entity who is not the bank, for example.
Tomasz: Thanks for sharing this. Definitely an improvement.
… good that there is a change in the language. I have doubts about whether the end user will understand who the issuer is.
… I think "Issuer" is not the write term (and many not translate well into other languages)
… in terms of showing the RP origin, the chances the user will understand are even slimmer.
… but maybe a domain name can go into the sentence.
… I agree that "credentials verified" is not the best term. Perhaps "Authentication completed"
Gerhard: Context would be valuable. Could we have a display context. LIke "This is a card payment" or "This is a bank payment."
"This is an open banking payment"
This might help us solve the generic problem.
Stephen: I'm not opposed to having context information provided (in a controlled fashion).
dougf: +1 to the direction of the new design
… in terms of important additions, one of the things that we've found in our pilot is people not being clear who is authenticating them.
… it will need more discussion how to communicate who is authenticate.
IJ: Is it a deeper challenge understanding what's going on?
dougf: The question is when you create a credential, with what entity and how it will be used. Can the user understand why an entity is able to do an authentication. Understanding the process is difficult.
… in our pilot we found perhaps an equal split between people thinking its the issuer or merchant or browser.
… the browser could help, even if we don't know how exactly yet.
… the successful authentication message is MOST important at credential creation time.
… during authentication the success was clear to people; so we found more need at creation time.
Tony: Is there an opportunity to pull in a single icon (e.g., bank + network together).
… the customer might recognize particular imagery.
smcgruer_[EST]: The card icon is up to the caller. It's a good note to us that this string might be long. It interests me that there might be 2 icons combined into one.
Tony: That's the case in the token space.
… from a customer experience perspective they just want to know they are using the correct product.
Fahad: Are these icon fields (going to be) optional?
smcgruer_[EST]: This is an open question. What do we need to add to make this work?
… Gerhard's proposal is to provide a "context". We were thinking that kind of bundle.
… but there are combinatorial complexity issues.
Fahad: The new UX makes a lot of sense for a 3DS flow.
… but in Tony's use case (which is also pertinent), we could skip issuer and have a composite icon
smcgruer_[EST]: That scenario should be easy to support.
… I'd love to see if people have example UIs of other payment flows. What are people showing users today?
Ian: Check out Open Banking Customer Experience Guidelines
Gerhard: Also Brazil open banking has UX guidance
tomasz: It would be good for the RP to indicate who is doing the authentication.
… the sentence in the UX could say "citibank has requested to authenticate you to confirm your purchase."
… this is the valuable context.
… this could be done generically (not just 3DS)
… eg., the cardholder could be authenticating to the merchant (or their service)
… so "Store.com wants to authenticate you"
smcgruer_[EST]: We are open an interested in putting the origin of the RP. That is the more trusted string.
smcgruer_[EST]: The credential is exactly for the RPID.
Juliana: There are guidelines for 3DS with clear language definitions and so on
… that consumers are familiar with, and the closer we stick to that, the better.
… that would include difference between authentication and authorization.
<Gerhard> question: Could the Common Name of the URL in the HTTPS certificate be used?
smcgruer_[EST]: We rely on origin because other strings might be lies.
Ian: Maybe show both: the string and the origin
[Moving on to the fallback screen]
smcgruer_[EST]: Reminder - this fallback screen is important for privacy protection.
… but nobody likes this screen.
smcgruer_[EST]: Ian presented some ideas a few months ago. We run with that here -- when no credentials are found, the dialog looks the same. And "Continue" sends a signal to the caller that further authentication is required.
Gerhard: Yes, I agree. :) The button intention could be "Verify" rather than "Continue"
… in my slides (for next meeting) I propose some additional language
smcgruer_[EST]: Also in this proposal there are three signals through the API (instead of 2 signals in the current approach).
The signals are: (1) continue with FIDO (2) cancel (3) try another way
smcgruer_[EST]: we are also looking at an idea where, if you choose to authenticate another way, what should happen with the SPC dialog? Should it say "Verifying" and stick around, for example?
… this is an interesting idea for me, but I think this will be challenging if 3DS is happening in an iframe and therefore appears behind the SPC dialog
smcgruer_[EST]: I like this idea but it may not work and it may be preferable for the browser to "just get out of the way"
smcgruer_[EST]: We have some questions (in the deck).
* "Store" field. Is it always a store? Is "merchant" more common? should there be an enumeration?
smcgruer_[EST]: Regarding the needs for icons to be larger. Is this a regulatory requirement? is this for "glanceability"?
smcgruer_[EST]: We don't want to tie too closely to card payments. I like Gerhard's idea of providing context
Gerhard: Is Netflix a merchant? Is a gym a merchant? There is no universal word.
… some systems say "pay" "charge" "subscribe"
… enumeration might help
… merchant might like to choose how they would like to be called.
… regarding "icons" they are not really icons, they are "visual representations of cards"
… for recognizability.
smcgruer_[EST]: Autofill has customized card art and we've seen users appreciate the detailed identification of cards. SPC should support that level of detail.
… we are more interested in the size and positioning of card beyond the card art
dougf: The card art increases trust. Fraudsters are not perceived to have that kind of information. It needs also to be large enough for accessibility reasons.
IJ: What about hover or click to enlarge?
smcgruer_[EST]: That idea was not well-received.
smcgruer_[EST]: I agree for custom card art. I'm mostly focused on custom bank / network logo.
tomsasz: The reason for the issuer logo (in 3DS land) is to let the user identify the card issuer. This helps identify which card.
tomasz: It's valuable to bring SPC closer to 3DS screen (for 3DS flows)
dougf: We don't have a specific UI for credential creation; we might potentially want good practices.
… but when there is continuity of experience, there's greater association in terms of who is authenticating.
smcgruer_[EST]: Maybe creation screen could add confidence if done right.
Gregoire: One thing bothers me a bit, the details on the transaction. There's an increasing need for precise information for some types of transaction (e.g., recurrence)
… I am afraid that this could be a limiting factor for markets where precision is required
smcgruer_[EST]: I agree. I am worried that browsers may not be able to keep up with all regulatory requirements ...
… having said that, I am more optimistic about some spaces where EMVCo has already done work on this!
… therefore I'm more optimistic we can find a way to address this without taking arbitrary strings as input.
Next meeting
29 February