- From: Hodges, Jeff <jeff.hodges@paypal.com>
- Date: Sat, 28 May 2016 21:01:42 +0000
- To: "public-webauthn@w3.org" <public-webauthn@w3.org>
I offer the below in hopes of helping to coalesce the recent list discussions regarding "client filtering of extensions"... On 5/27/16, 10:45 AM, "Wendy Seltzer" <wseltzer@w3.org> wrote: >On 05/27/2016 01:13 PM, Mandyam, Giridhar wrote: >>Sam wrote: >>>If the client has made some editorial judgements on what extensions it >>>will support and what user permissions it will ask for, does it also >>>have to examine the reply to that extension from the authenticator in >>>any way? Or for that matter, *can* it even examine the reply sensibly >>>in all cases? >> >> Given that all extensions are optional for the client, it seems that >>this would be a decision that each browser vendor must make on their own >>independent of the specification. I personally donšt think we need to >>answer these questions for the specification to go forward. But I look >>forward to other responses. > >I could see it being a choice for the client: > >Some clients might choose to accept only extensions whose formats or >contents they understand. > >Other clients might accept extensions whose authors made assertions >(textual, not cryptographic) about what they were doing. Even if the >client couldn't understand the response, at least if they learned later >that the extension/authenticator were misrepresenting the communication, >they'd have some grounds for complaint. I agree with Wendy -- basically, the overall "client filtering of extensions" questions do not seem amenable to being solved entirely technologically, especially if we want to foster an innovative low-friction Bring Your Own Device ecosystem. The 1st client choice -- UAs honoring only certain extensions -- applies to "RP-requested extensions" (to coin a term). Here, clients (aka user agents) have a natural means to filter them. The 2nd client choice -- reputational/legal recourse -- applies to both RP-requested extensions and "authenticator-produced extensions" (to coin another term), the latter which are not terribly feasible for clients to actively filter out (for ecosystem biz reasons, see below). Authenticator-produced extensions, though, are overall manageable in the context of the 2nd client choice: if they are caught misrepresenting their actual behavior, then there are grounds for complaint and there may be consequences. Also, FIDO is (and will be) offering authenticator certification programs of various kinds which will ostensibly bolster this (e.g., through certification agreements and trademark licensing terms). Regarding authenticator-produced extensions and ecosystem biz reasons, if clients were to filter returned WebAuthnAttestation or WebAuthnAssertion objects based on whether the RP explicitly requested any extensions whose data is returned therein, then RPs have to update code on both their front- and back-ends to utilize such extensions. Also, there is slightly more complexity for authenticator implementations. If the authenticator-produced extension data is simply returned to the RP, per present design, the RP only needs to update their back-end to utilize the data. Additionally, it would place the client in the gatekeeper position for all extensions in that once the RP must explicitly request any and all extensions, including authenticator-produced extensions, the 1st client choice applies in all cases. This will add friction to the ecosystem in that now for some new authenticator-produced extension to be generally useful to RPs, both "extn filtering clients" and RP front-ends must become explicitly aware of it before the authenticator-produced extensions' data will become available at RP backends (except for any clients who do not generally filter extensions). An additional observation: the spec presently lacks privacy considerations overall, and for extensions in particular, which ostensibly would outline the privacy-oriented responsibilities of the various entities, e.g., in which cases ought clients request user permission, authenticators must not emit the same uniquely-indentifying information to different RPs, etc. Such statements would help provide a basis for the reputation/legal recourse backstop and we should endeavor to add privacy (and security) considerations to the spec. HTH, =JeffH
Received on Saturday, 28 May 2016 21:02:13 UTC