Meeting minutes
Issue 101
https://
Proposal: support data URIs for card art icons
Stephen: To simplify Account Provider support, can use data URI for icon instead of running a web server.
… so proposal is that we hash the data URL.
… works for both https and data URLs
AdrianHB: What if merchant is given 100 logos by the RP? (Even if out of scope for SPC)
Stephen: Technically, an RP could keep a set of hashes around.
AdrianHB: Anything needed re: hashing?
… specifics about (complicated) hashing?
AdrianHB: The browser needs to do the hash since it needs to be sure the hash corresponds to the image
… can we name the hash method?
… look at CSP
Stephen: Hash collision attack is possibly but unlikely
Doug: A downside of this approach: images change over time; hash of image at time of authentication may not be same at validation time
… and images are cached by merchants
… one mitigation strategy is for the RP to provide fresh images (e.g., via ACS)
Stephen: I think data URL is a reasonable compromise -- the RP passes the data URL to the merchant
… we have advised to the 3DS WG that all the information required for the SPC call is passed at the time of the request
Doug: Are we also talking about display of the issuer logo?
Stephen: At the moment, no. Just one icon for now ('for the instrument')
Stephen: It's reasonable to look into another icon
Ian: Is it important to tell the user to whom they are authenticating (the RP)?
Doug: Our UX experiments show that it's important to show the user to whom they are authenticating.
Ian: This may also be true in open banking context
Doug: When SPC fails, we'd also like to have some continuity (in UI) to fallback authentication
… so I think having extra UI about RP would be important to the consumer
AdrianHB: I think there's no harm to show origin of RP. We should allow the RP to say what icon to show (for them)
… they may choose through their own experimentation that showing a network logo is effective, or a combo logo, or whatever
… this is a mechanism for the RP to show the user some graphical clue about what the user is about to do, and a hash of the bytes would be part of the assertion.
… maybe a single logo suffices if the RP gets to say what it is
Issue 84
https://
Ian: Can we close this one with "No UX in v1"
Action: Stephen to close issue 84 with explanation about v1 status and reopen later if needed.
FPWD
Ian: Ready?
Stephen: Coming soon - tx confirmation requirements
Ian: I will aim for 25 August
next call
30 August
No meeting 6 September
Any origin trial changes?
Stephen: See https://
Ian: Note in particular:
* 0 credential match UX
* No enrollment UX