- From: Arshad Noor <arshad.noor@strongauth.com>
- Date: Thu, 9 Mar 2017 04:51:24 -0800
- To: public-webauthn@w3.org
On 03/08/2017 11:56 PM, Mike West via GitHub wrote: > We locked the credential management API to top-level contexts because we > have no idea how to inform a user about the origin of frames. That is, > it's difficult to explain to users what's going on when > `doubleclick.net` asks for credentials (or asks to store credentials) > from inside `example.com`. They see `example.com` in the address bar, > that's the origin with which they're creating a trust relationship, but > they're handing credentials to someone else. *shrug* It isn't at all a > deep, philosophical opposition to the idea, but a practical "We don't > know how to do this" feature we punted to The Distant Future(tm). I'm not a browser expert, Mike, but in the past[1] I've suggested that the WebAuthentication group should consider putting some standardized chrome or other embellishment to the UIX when FIDO authentication is activated (so users can recognize what is going on - much like the SSL/TLS lock symbol). I'm not sure if people in the WG feel such chrome is unnecessary, irrelevant, or if they're indifferent to it, but if such embellishment existed, the iFrame could be embellished with the chrome and origin displayed somewhere to identify who is challenging the user for a signature. This would allow the top-level document to show a different origin in the address bar while it would be apparent to the user who is asking for the strong-authentication artifact. Whether a user should trust such an iFrame (coming from a different origin) demanding for strong-authentication is a different matter. Today, its "invisible" to them; should it become explicit, it might open up a can of worms that may or may not be desirable. Arshad Noor StrongAuth, Inc. [1] https://alesa.website/2016/05/21/not-all-biometric-authentication-is-equal/
Received on Thursday, 9 March 2017 12:51:56 UTC