Re: Coming back to CREDENTIAL.

On Fri, Jul 31, 2015 at 10:22 PM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:
>
> Question 1: Origin bound federated credentials
>>>
>>> The fundamental question here is whether these credentials should be
>>> origin-bound. In my opinion making them so renders this part of the spec
>>> fairly pointless because I still need to login (using my federated
>>> credential) on each relying-party site and only then can the RP site store
>>> the federated credential (or at least link it to the new origin that it is
>>> now useful for).
>>>
>>
>> Well, yes, except insofar as the browser can synthesize potential
>> connections for a user based on its knowledge of the user's browsing
>> history and stored accounts (as described in
>> https://w3c.github.io/webappsec/specs/credentialmanagement/#synthesis).
>>
>
> True, but in this and your subsequent response you are simply moving trust
> from the IdP to the browser.
>

Well, yes. The browser is the user agent. If we can't trust the browser, we
can't trust anything at all, right? It's somewhat axiomatic that the
browser is going to be afforded more trust than any specific origin.


> Instead of a allowing an IdP to define which origins are appropriate for
> it's credentials you allow the browser to do it through fuzzy logic that is
> not clearly laid out in the spec.
>

I've attempted to document the logic at
https://w3c.github.io/webappsec/specs/credentialmanagement/#synthesis. I'm
totally willing to believe that it's both fuzzy and unclear, so specific
critique would be helpful. :)

I would trust the IdP ahead of the "intelligent synthesis" of the
> user-agent. I have explicitly granted a list of RPs permission to use my
> profile at this IdP for authentication. That trust is clear to me as a user
> because for each RP I made an explicit grant. If I visit some other site
> and suddenly get auto-logged in via my IdP I know that IdP can't be trusted.
>

At that point, it's too late isn't it? You've already been identified
against your will, trust has already been violated.


> Realistically any IdP could already do this today. If I visit an RP site
> and have an existing session with an IdP the two sites could log me in
> without getting my consent but that would be a contravention of the
> standard they are following (usually OAuth).
>

Yes. Two cooperating sites can do this today. We're talking about adding a
cooperating browser into the mix, which removes the necessity for the RP to
opt-into the dangerous world of trusting the specific IdP. That seems like
a pretty relevant difference.

1. Origins are trivial to support, and probably handle the 80% case. It
>> seems pretty straightforward to include them in the API, and
>> straightforward to understand their function.
>>
>
> This is because the IdP market has been cornered by a small group of
> providers. I'm not in favour of a standard that simply re-enforces that
> uneven market.
>

It is both good and right to aim for a better world, but I'd suggest that
doing so by ignoring the practicalities of the world that exists today. If
working in terms of origins satisfies a large chunk of the use case, then
supporting them seems reasonable.


> 2. Protocols require user agents to bake in support for the protocol and
>> its variants, as well as an understanding of the protocols specific origins
>> support. That's certainly interesting for us to support, but is equally
>> certainly more work. Given the sluggish pace thus far, I'd encourage the
>> group to cut features in order to get something into developers hands that
>> we can gain experience with and build upon. As I note at the top, these are
>> things I want to support, I'm just not sure we ought to block on them.
>>
>
> Yes, but there are a small number protocols and they could be relatively
> easily in-corproated directly into the browser. Baking these into the
> browser would light a fire under these initiatives and do much more for
> getting rid of passwords than anything else in this spec.
>

But baking them into the browser requires a deep discussion of UI/UX that I
don't think anyone is prepared to invest in at the moment. I can't speak
for any browser other than Chrome, but I don't think that I can reasonably
expect folks internally to really sit down and work through the flows this
year. I mean, we've been kicking around this smaller variant of the spec
for almost a year already, and I don't feel like we've made significant
progress in that time. Do you? :)

Also, while there are a small number of protocols, my understanding is that
there is significant variation in dialect. OAuth2 != OAuth2 != OAuth2,
right?


> Without this I would argue it's not worth trying to push federation into
> the first version of this spec.
>

That's a reasonable argument. I hope the WG doesn't agree with you. :)

Assuming it does agree with you, and the MVP for v1 is just passwords, what
would you expect the API to look like? One option would be to do something
like `navigator.passwords.{get,store}` so that we don't stomp on the more
generic namespace; in v2, we'd end up with duplication, but that wouldn't
be horrible, I suppose.

-mike