W3C home > Mailing lists > Public > public-webauthn@w3.org > May 2016

wrt client filtering of extensions (was: 05/24/2016 WebAuthn Summary

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>
Message-ID: <D36E4C3F.BEAFD%jehodges@paypalcorp.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:18 UTC