Re: Coming back to CREDENTIAL.

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.


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


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

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.

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.

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