Re: Can we remove the PSL dependency?

> On Fri, Jul 29, 2016 at 2:55 PM, Vijay Bharadwaj <vijaybh@microsoft.com>
wrote:
>> ...
>> 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

I agree with Vijay's reasoning/conclusions above.


Richard Barnes replied:
> We're not talking about a better origin model here, we're
> talking about not using something *worse* than the origin model :)

unfortunately there are multiple incongruent facets to the so-called "same
origin policy (SoP)" within browsers (and thus the Web at large) -- i.e.,
there is not a single monolithic "same origin policy" aka "origin model" --
rather, there are purpose-defined variations of the SoP, e.g. "the cookie SoP"
[1]. This is what Brad is arguing at the end of his message below.


> I actually disagree with your last point -- it might make sense
> to design something special here, because this is a special case.
>  ... I'm not really  hearing any use cases for going beyond
> same-origin + postMessage.

I disagree. WebAuthn does not provide state management per se, and so will be
used in conjunction with preset web state management facilities, i.e. cookies,
upon which vast swaths of web login/authn facilities presently rely (as noted
by Brad Hill below). We should, by default, compose with this present
practice.

When, and if, there is a general effort to define a well-reasoned, general
update to the so-called "cookie same origin policy" [1], and which has
interest & support on the part of browser vendors, then we can perhaps nudge
the world to migrate towards it.

HTH,

=JeffH

[1] http://identitymeme.org/http-cookie-processing-algorithm-etlds/


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

Received on Tuesday, 2 August 2016 09:31:00 UTC