Re: Coming back to CREDENTIAL.

Yes. You may notice some similarities between Chrome's behind-a-flag UI and
Account Chooser.

-mike

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Wed, Aug 12, 2015 at 2:41 PM, <Axel.Nennker@telekom.de> wrote:

> Speaking of UI/UX …: The OpenID Foundation’s Working Group accountchooser
> has done a ton of this work in the past with heave involvement by Google.
>
>
>
> http://accountchooser.net/
>
> https://www.accountchooser.biz/learnmore.html
> https://www.accountchooser.com/learnmore.html
>
> https://sites.google.com/site/oauthgoog/
>
>
>
> Would be great to apply these results to the browser.
>
>
>
> -Axel
>
>
>
>
>
> *From:* Mike West [mailto:mkwst@google.com]
> *Sent:* Montag, 10. August 2015 08:30
> *To:* Adrian Hope-Bailie
> *Cc:* public-webappsec@w3.org; Dave Longley; Manu Sporny; Brad Hill;
> timeless
> *Subject:* 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
>