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

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

From: Dirk Balfanz <balfanz@google.com>
Date: Wed, 08 Jun 2016 00:26:06 +0000
Message-ID: <CADHfa2B1+zz14tmWWKtQtb8Ng_P9P0nkbAspV8xUxR_ORWsS_Q@mail.gmail.com>
To: "Hodges, Jeff" <jeff.hodges@paypal.com>
Cc: "public-webauthn@w3.org" <public-webauthn@w3.org>
On Tue, Jun 7, 2016, 10:42 AM Hodges, Jeff <jeff.hodges@paypal.com> wrote:

> On 6/6/16, 9:45 PM, "Dirk Balfanz" <balfanz@google.com> wrote:
> >[...] In fact, FIDO historically
> > draws the line even more conservatively than the rest of the web does
> >(not even considering DRM). Let me give you an example of that: when we
> >first introduced app IDs and facets, it was technically possible for two
> >origins, let's say
> >google.com <http://google.com> and youtube.com <http://youtube.com>, to
> >collaborate and access the same key on an authenticator (something that
> >could come in quite handy for those two origins, as you can imagine).
> >Note that absent app IDs and FIDO, any two origins on the web, if they
> >choose to collaborate, can already track a user and agree on a common
> >identifier (by iframing each other, run federation protocols, etc). FIDO
> >at that point decided that we didn't want to introduce an *additional*
> >channel for different origins to track users; so we changed the app id
> >spec to no longer make it possible for exampleA.com and exampleB.com to
> >have access to the same keys from an authenticator.
> I do not think this is actually a correct example because we specified
> that particular aspect of the appid-and-facet spec -- i.e., not making
> exampleA.com and exampleB.com equivalent -- in order to not violate the
> Web's crucial, well-established "cookie same origin policy" [1], which
> does have both security and privacy connotations, but we (at least I and
> Brad) were focusing on the security aspects.

If I remember correctly, this spec was shot down in the *Privacy* WG. Also,
the spec didn't change anything about how cookie processing works: It
didn't make exampleA.com and exampleB.com "equivalent" with respect to
cookie rules - or anyting else, for that matter, *except* for access to
FIDO keys.

But even if you look at it from a security point-of-view, the point still
stands that traditionally we have been very conservative in this area.
Privacy (and security) considerations have trumped expediency and
ease-of-implementation arguments.


Effectively, the
> appid-and-facet approach /adheres/ to the cookie same origin policy.
> [1] http://identitymeme.org/http-cookie-processing-algorithm-etlds/
> HTH,
> =JeffH
> >
Received on Wednesday, 8 June 2016 00:26:48 UTC

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