RE: Coming back to CREDENTIAL.

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<mailto: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