RE: Can we remove the PSL dependency?

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.

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

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