Introduce UX guidelines documentation #311
Conversation
stephenmcgruer
force-pushed
the
smcgruer-nonnormativeUXGuidelines
branch
from
a6c7888 to
777d29f
Compare
stephenmcgruer
changed the title
stephenmcgruer
force-pushed
the
smcgruer-nonnormativeUXGuidelines
branch
2 times, most recently
from
5f3bd63 to
9dce038
Compare
stephenmcgruer
force-pushed
the
smcgruer-nonnormativeUXGuidelines
branch
from
9dce038 to
e0be04f
Compare
Great catch, fixed! |
|
|
||
| - Google Chrome's (and other Chromium-based browsers) implementation currently | ||
| supports zero, one, or two payment entity logos. If more than two logos are | ||
| provided, Chrome currently discards the third logo onwards. Logos are placed |
There was a problem hiding this comment.
comment: I think silently ignoring context and proceeding is reasonable. As a counterpoint, I could also see this being a privacy concern, where partners this sensitive payment data is being shared with are not represented in the experience unbeknownst to the caller. It could be beneficial for this to fail in a noisy way and push the responsibility onto clients to understand early what the User Agent supports and give them the ability to compensate for this with alternative UX if needed, assuming we continue to have no strict requirement on number of entities supported in the API.
On this topic, the easiest way to do this would be to just set an explicit number that should be met by all User Agents implementing. I.E. [0, 1, 2] is what all parties must support, and don't offer 3+ if it doesn't make sense for any User Agent to really implement that (I imagine if the chrome team didn't feel good implementing 3+, no other User Agent will).
Maybe this is context you've already discussed and I am just behind 😄
There was a problem hiding this comment.
Consolidating this discussion into the other comment: https://github.com/w3c/secure-payment-confirmation/pull/311/files#r2307301608
| passed within `paymentEntityLogos`, and may ignore extra logos beyond what | ||
| they support displaying, but it is recommended that they support up to two | ||
| logos being shown. |
There was a problem hiding this comment.
question: does this mean the UserAgent actually does not have to implement this part of the spec at all, and could just drop all entity data? Although we do not need to dictate how they do it, I am opinionated that this privacy context is important and we should demand a minimum bar be met.
This is also conflicting with the information presented in the current spec: the User Agent MUST ensure that the following is communicated to the user https://w3c.github.io/secure-payment-confirmation/#sctn-information-presented
There was a problem hiding this comment.
Currently by spec the user agent can drop all of the payment entity logos if it wanted, yes. See step 3 of https://w3c.github.io/secure-payment-confirmation/#sctn-steps-to-check-if-a-payment-can-be-made
We made that choice to avoid restricting User Agent UX and because we foresaw browser implementors not always being happy to show logos from other entities. However I could see an argument that this is a core feature of SPC and so perhaps like you say here and below, we should change SPC to require a User Agent support at least N={0, 1, 2} logos. Wdyt @pejic and @ianbjacobs ?
Note that the relying party will know which logos are shown (or not), because only the shown logos are included in the output cryptogram. So when verifying the cryptogram you know if the user saw the logos before signing. However that is post-call, of course.
| While web specifications do not generally make recommendations about how User | ||
| Agents implement UX, both integrators of SPC (e.g., financial organizations) | ||
| and implementors of SPC (i.e., User Agents) have requested general guidance | ||
| about what information can be provided to the API and how it is likely to be | ||
| displayed to the user. The non-normative guidance in this document is based on | ||
| implementor experience and payment industry feedback. |
There was a problem hiding this comment.
nit: is this important context for the audience reading this, or just us? Might be possible to compact this down to a single sentence like: While web specifications do not generally make recommendations about how User Agents implement UX, we wanted to offer general guidance about how the API's information will likely be displayed to the user. or just remove it entirely.
Feel free to ignore my nits if you are confidant 😄
There was a problem hiding this comment.
I think that's a great point - wdyt @ianbjacobs ?
See #309