Re: Can we remove the PSL dependency?

On Fri, Jul 29, 2016 at 2:55 PM, Vijay Bharadwaj <vijaybh@microsoft.com>
wrote:

> eTLD+1 is just the best choice that exists today. We can try to invent a
> better replacement for it, but WebAuthn seems to not be the right place for
> that. Others have taken similar approaches – for instance, Credential
> Management also takes an eTLD+1 dependency:
> http://www.w3.org/TR/credential-management/#body-extraction (they call it
> registerable domain, but it means the same thing).
>
>
>
> Dirk has commented on one concrete use case in the TAG review thread (
> https://github.com/w3ctag/spec-reviews/issues/97 ) - again, this can be
> done a different way but it seems like scope creep for us to be trying to
> build a better origin model.
>

So these arguments seem pretty weak.  Alex responded to the
performance/security concerns about postMessage further down that thread
[1], and there's not really anything about the Credential spec that has
real, broad consensus.

In fact, it seems to me like Dirk's comment is a good example of why eTLD+1
is so terrible.  There are 20 hosts in that list, vs thousands of "*.
google.com" hostnames [2].  Why should we introduce a vulnerability to XSS
on "randomname.app.ddl-autopush.sandbox.google.com" [2] in order to save
this handful of hosts a little effort?



> In the past I have wondered if we could use some piece of Manifest
> functionality (
> http://www.w3.org/TR/appmanifest/#related_applications-member ) and that
> might also work but may require implementers to adopt Manifest instead.
>
>
>
> So, to recap the way I look at this:
>
> -          There’s a real problem here that needs solving
>
> -          eTLD solves it, mostly, but also has drawbacks
>
> -          Better solutions are welcome but should not be one-off
> inventions within WebAuthn
>
We're not talking about a better origin model here, we're talking about not
using something *worse* than the origin model :)

I actually disagree with your last point -- it might make sense to design
something special here, because this is a special case.  WebAuthn is pretty
different from most APIs, at two levels: On the one hand, most web APIs
aren't connecting you to some hardware device that you expect to be
enforcing anti-tracking guarantees.  On the other hand, most web APIs don't
expect to be creating some artifact that you can pass from one browser to
another that encodes security policies in a way they can't be tampered with.

By way of example: If you look at WebRTC, perhaps the best precedent we
have here, it has origin based permissions for access to hardware, and when
it requires things to work across browsers, it requires a special consent
mechanism [3].

But to be honest, I'm not really hearing any use cases for going beyond
same-origin + postMessage.

--Richard

[1] https://github.com/w3ctag/spec-reviews/issues/97#issuecomment-203355418
[2] https://crt.sh/?dNSName=%25.google.com&exclude=expired
[3]
https://crt.sh/?q=272c2917aedf8fc1e841d97d7c36da719f9766458b9734f78019b709784f14d4
[4] https://tools.ietf.org/html/rfc7675


>
> *From:* Richard Barnes [mailto:rbarnes@mozilla.com]
> *Sent:* Thursday, July 28, 2016 3:20 PM
> *To:* Brad Hill <hillbrad@fb.com>
> *Cc:* public-webauthn@w3.org
> *Subject:* Re: Can we remove the PSL dependency?
>
>
>
>
>
>
>
> On Thu, Jul 28, 2016 at 4:57 PM, Brad Hill <hillbrad@fb.com> wrote:
>
> As a guest on the list, I won’t suggest what should be done, but I can
> tell you why this is a bad idea without breaking the IPR rules.
>
> As Alexei Czeskis pointed out, this makes the credential ID into a
> cross-origin supercookie.
>
> There were many important considerations around privacy, consent, etc. in
> the original FIDO design that were based on the credentials being origin
> scoped.
>
> This makes the credential much more like a client certificate, with many
> of the same negative privacy, user management and consent properties.
>
> You can’t look at such a credential in a management interface and
> understand to where it will reply / be sent.  You can’t know what the
> impact of deleting it is, what accounts it is linked to, etc.
>
> This also puts it in direct competition with the existing ecosystem of
> protocols and systems for doing truly federated authentication.  We wanted,
> for a variety of reasons, to have a clear goal of building a system for
> strong initial authentication, and not impose all the design constraints
> and competitive headwinds of also being a federation system on top.
>
> As a federation protocol, this design is troubling because it
> de-encapsulates the identifier exchange that typically happens at a
> security token service in today’s federated model.  Once a foreign party
> learns your ID, you can’t change or revoke it, or use it to assert
> different, unlinkable identifiers, without also destroying your credential
> for the primary identity provider.
>
> We went with eTLD+1 because it is the model used by cookies,
> document.domain and elsewhere in constructs like “same site” cookies or
> internal process based isolation boundaries.  It is better to re-use an
> existing construct in wide use than to add yet another special case
> exception.
>
>
>
> Thanks to you and Alexei for reminding me about the tracking risk.  I had
> been focused on the risks of bad assertions being generated.
>
> Given those risks, I can agree that some mechanism for scoping credentials
> is needed.  That doesn't necessarily imply eTLD+1.  In the simplest case,
> credentials could be same-origin; the cross-origin cases could be addressed
> with postMessage and the like (also existing constructs).  If developers
> can't deal with that for some reason, then we could add some whitelisting
> mechanism in this spec.
>
> In other words, I would be fine with any mechanism where sharing is
> explicit and by origin.  What's the use case that drives toward eTLD+1
> instead?
>
> --Richard
>
>
>
>
>
> -Brad Hill
>
>
>