Re: Can we remove the PSL dependency?

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.

-Brad Hill

Received on Thursday, 28 July 2016 20:58:12 UTC