Re: Can we remove the PSL dependency?

One more thing came to mind:

  We didn’t want to assume any important properties depended on validation data staying secret, because we assumed data breaches do and will continue to happen.

   A data breach _should_ be a non-event for these kinds of credentials.

  But if a breach suddenly allows any bad actor in possession of the data to start tracking and cross-linking (with 100% cryptographic assurance!) your users without your or their consent, then you still have to invalidate and re-issue all those credentials, even if you have precautions to prevent them being used to gain privileges at your own service.  Avoiding this kind of pain was one of the top-line design goals of FIDO.

 -Brad

On 7/28/16, 1: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.
    
    -Brad Hill

Received on Thursday, 28 July 2016 21:12:03 UTC