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

Re: extensions, continued.. (was: 05/24/2016 WebAuthn Summary

From: Hodges, Jeff <jeff.hodges@paypal.com>
Date: Wed, 8 Jun 2016 16:56:46 +0000
To: Dirk Balfanz <balfanz@google.com>
CC: "public-webauthn@w3.org" <public-webauthn@w3.org>
Message-ID: <D37D903D.C37E5%jehodges@paypalcorp.com>
inline below..

> On Tue, Jun 7, 2016, 9:34 AM Rolf Lindemann <rlindemann@noknok.com>
>wrote:
>> I agree, FIDO wants and (IMHO) should be privacy preserving.  And I
>> think we all agree on that.
>> 
>> So the Œwhatı (IMHO) is undisputed.
>> 
>> So we need to discuss the Œhowı.
>> 
>>> Because clients must be able to drop extensions they don't
>>> understand, all extensions must be requested by the RP.
>> 
>> I donıt think clients have to.
>> 
>> What is the threat model here?  A user agent (or client) CANNOT
>> repair a broken platform.  In other words: If the underlying platform
>> violates userıs privacy (e.g. by directly sending GPS location to
>> some server), the user agent cannot protect against that.
>> 
>> The user agent (IMHO) can and should protect against Apps/JavaScripts
>> that try to violate userıs privacy.
>> 
>> Similar to a user needing to trust the user agent, the user (to at
>> least the same extent) needs to trust the underlying platform ­ or
>> use a different one.
> 
> Agreed. 
>
>
>> The user agent/client should be able to drop requests from the RP for
>> privacy violating extensions (according to the userıs preferences).
>> So if the user configures the platform to not expose the location,
>> then I would also expect the authenticator to respect that setting.
> 
> Exactly! 
> 
> Now, how would the authenticator know about the user's preference?
> It's not like the authenticator can turn around and ask the user. Also,
> we don't have CTAP messages that would allow the platform to tell the
> authenticator about the user preferences. The only mechanism we *do*
> have is for the platform (or user agent, or client, or whatever you want
> to call it) to help the authenticator out here and not forward the
> location extension argument if the user doesn't want the location
> exposed, and do forward it if the user is ok with the location exposure.
> That's the mechanism that we have to signal to the authenticator the
> user's intention.
> 
> So when you say that you expect the authenticator to respect your
> wishes, and we have an authenticator that *wants to* respect those
> wishes (and lets agree that we only want to support those kinds of
> authenticators),..
> 
> ..what other mechanism do we have to do that, other than
> the RP signaling the extension, the client/platform *understanding* the
> extension, and then - depending on the user setting - asking or not
> asking the authenticator to including the corresponding data?

This line of reasoning is relying completely on a technology-based
solution and ignores leveraging the reputational/legal recourse, as well
as certification testing, as described here..

[1] wrt client filtering of extensions
    https://lists.w3.org/Archives/Public/public-webauthn/2016May/0306.html

The UVI extension is an extant, real example of an originally proprietary
authnr-produced extension (impl'd by a UAF authnr sdk & server vendor)
that adds data to the authenticatorData, and in original fielded practice
is passed through to the RP in authn assertions, and if the RP's backend
understands it, great, and if it doesn't the data is simply ignored.  RPs
do not have to update their front-end code to take advantage of it, nor do
they have to wait for the platform stack (which in the webauthn api case
includes the UA) to add support for it.

If an authnr vendor is caught abusing this capability, eg by certification
testing, there is reputational/legal recourse.

I agree with Johan's analysis of added friction to the ecosystem..

[2] https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0065.html

..which is congruent with [1].


> Rolf continued..
>> And this is my recollection of where we ended the discussion in the
>> last W3C call, i.e. allowing authenticators to add extensions (in the
>> response) 

agreed, that was also my understanding.


>> and allowing the user agent/client to drop extensions in
>> the request in order to reflect the userıs preferences.
>> 
>> I still trust the Authenticator vendors to only add privacy
>> preserving extensions which are added by default (similar to me
>> trusting the platform vendors to not violating my privacy in the
>> platform itself).

agreed, and here the reputational/legal recourse + certification provides
support for your trust.


HTH,

=JeffH
Received on Wednesday, 8 June 2016 16:57:16 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:21 UTC