- From: Adam Langley via GitHub <sysbot+gh@w3.org>
- Date: Fri, 16 Feb 2018 20:41:19 +0000
- To: public-webauthn@w3.org
> So I'll venture that assuring that protecting against the "origin context ... manipulat[ing] the request" is/was at least an implicit goal. I'm happy with any coherent stance although I will note that not worrying about a compromised origin context makes things simpler. Also, the user fundamentally interacts via the DOM so, if there's attacker Javascript running in the origin, it can wait until the user has authenticated and then simulate whatever actions it wishes on behalf of the authenticated user. Thus protecting against it in webauthn doesn't clearly translate to any obvious practice gain. (Unless someone has something in mind?) > agreed, though might necessity of "echoing" of input options fields be assessed on a field-by-field basis? Yep, although looking at [the list](https://w3c.github.io/webauthn/#dictdef-publickeycredentialcreationoptions) I'm not sure that I can point to any of the fields and say "certainly no need to worry about that one". > do you actually mean to say "WebIDL to Javascript" mapping? Yes, thanks. I think I probably do. > Our understanding (from browser spec folk, e.g., @jyasskin) is that this is addressed by implicit conversion. Cool, although I'll have to ask him about how we actually implement that in Chromium if the group goes this route. (While it's just plumbing to do it for extensions that we understand, I believe that browsers have to echo all extension inputs if the purpose is to verify fidelity of transmission.) -- GitHub Notification of comment by agl Please view or discuss this issue at https://github.com/w3c/webauthn/issues/803#issuecomment-366352353 using your GitHub account
Received on Friday, 16 February 2018 20:41:21 UTC