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

On Wed, Jun 8, 2016 at 9:56 AM Hodges, Jeff <jeff.hodges@paypal.com> wrote:

> 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..
>

I'm not talking about "bad" authenticators here. Bad authenticators will be
able to subvert user privacy and security no matter what we do. (I think
other people made this point on another thread.) For that it's important to
have legal/reputational recourses (in addition to technical solutions), and
as Rolf points out, users are always free to switch to another
platform/authenticator. So I'm not discounting those recourses.

What I'm saying here is that we need some technical solution for clients
and authenticators who *want* to protect user privacy. What should they do?
How is an authenticator that's implemented in TrustZone, has no UI, and no
way to communicate with the user agent other than through the webauthn APIs
supposed to do the right thing? And how is a user agent that *wants to*
protect user privacy (let's say, by obtaining user consent before
disclosing the user's location) supposed to achieve that assuming that the
authenticators want the same thing?


> [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.
>

This line of reasoning is relying completely on reputation/legal recourse
and ignores technical solutions. :-) We don't sue developers who trample on
other apps' memory space - we built virtual memory instead. We don't try
and stay away from websites with a bad reputation for sniffing passwords -
we built the some-origin policy instead. When there are compelling use
cases, we allow for them (shared memory APIs, CORS, etc.), but we do it
carefully and without jeopardizing security/privacy. Let's do the same
thing here.

Dirk.


>
> 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
>
>
>
>
>