Re: Can we remove the PSL dependency?

+1k to what Brad eloquently relates below:  the use of eTLD+1 as the  
scoping basis for WebAuthn credentials was a carefully considered  
decision which we should only reconsider when and if there is a  
comprehensive and tranparent effort to coalesce the multiple extant   
Same-Origin-Policies.

Also, the WebAuthn spec does not normatively reference [PSL] -- it  
only mentions it definitionally  in passing.  See also the "NOTE:"  
following step 5 at https://tools.ietf.org/html/rfc6265#section-5.3 --  
the WebAuthn spec is essentially following this ethos, tho we perhps  
should borrow the language from the aforementioned NOTE:.

=JeffH

Quoting Brad Hill <hillbrad@fb.com>:
>
> 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:56:39 UTC