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