Re: Coming back to CREDENTIAL.

On 31 July 2015 at 15:18, Mike West <mkwst@google.com> wrote:

> On Fri, Jul 31, 2015 at 12:35 PM, Adrian Hope-Bailie <
> adrian@hopebailie.com> wrote:
>
>> Great to pick this up again. A point of clarity, I am a member of the
>> Credentials CG but have not a particularly active one and I have only a
>> very shallow understanding of the technical work the group is doing so
>> please consider my input as mine and not a voice of the CG.
>>
>
> By the same token, I'm not the WebAppSec WG. If other folks have opinions
> (as I know Brad does), I do hope they feel encouraged to pipe up.
>
>
>> On 31 July 2015 at 11:00, Mike West <mkwst@google.com> wrote:
>>
>>> 1. I want to make it easy for users to use password managers, as they
>>> have significant advantage over other methods. Likewise, I want it to be
>>> easy for password managers to help users sign in.
>>>
>>
>> This scope may be a good place to stop. This is a quick win and solves
>> the biggest issue, passwords. Perhaps federation can be dealt with in v2?
>>
>
> Maybe. Federations are an interesting part of the value proposition for
> browser-based password managers, however. We currently don't understand
> them at all (nor does any extension I'm aware of), and that's unfortunate.
>

+1 for having federations if we can do a complete job of it. I worry based
on your comments below regarding support for federation protocols that we
won't.


>
>
>>
>>
>>> 2. I want to encourage usage of federated sign in mechanisms, as they
>>> have interesting properties in relation to passwords. They're certainly not
>>> perfect, but in various cases they can be a big step up in terms of
>>> security. The first baby step is giving the browser an understanding of
>>> what's going on by allowing a site to store federated credentials. The next
>>> obvious step would be to natively support some set of protocols (OpenID,
>>> etc).
>>>
>>
>> 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. 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.


>
>
>> When a user establishes a session at an identity provider that identity
>> provider already has knowledge of which RP sites the user has authorised
>> with the IdP. So when the IdP stores the federated credential why can't it
>> also specify the origins that the credential is valid for? This could even
>> be a user-mediated step.
>>
>
> Why would I trust the IdP's interpretation of the world? That is, I could
> imagine a world in which Google+ would "helpfully" pre-populate your
> credential manager with credentials for the Alexia top 500k. That doesn't
> seem like something we'd want to support.
>

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

As I say, this could have a user mediation step that is triggered whenever
the IdP attempts to save a credential with new RP origins attached.
Something like: Would you like to automatically login on the following
sites with your facebook.com account: example.com <checkbox>,
anothersite.net <checkbox> <yes button> <no button>.


>
> Question 2:
>>
>> How will we address getting credentials for federation protocols (like
>> OpenID Connect) as opposed to for named IdPs? A standard should promote the
>> use of other standards. If IdPs are using their own flavours of federated
>> login protocols then support for them should not be baked into this
>> standard at the expense of support for an open standard or protocol.
>>
>> i.e. Support for get({protocols : ["openidconnect", "saml2"]}) or similar
>> should be prioritized over get({providers : ["facebook.com", "google.com
>> "]});
>>
>
> 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.


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

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


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