Re: Coming back to CREDENTIAL.

Thanks Adrian!

On Mon, Aug 31, 2015 at 3:18 PM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> On 31 August 2015 at 11:31, Mike West <mkwst@google.com> wrote:
>
>> 1. I see very little debate about password management use cases. Could we
>> agree that the API as defined (perhaps modulo naming) is a reasonable first
>> stab at solving that particular problem? Coincidentally, This is the piece
>> I'm most interested in shipping quickly.
>>
>
> +1 - Password management has very few stakeholders that might have an
> opinion on the API (vendors of password managers are the only ones I can
> think of) so I see little danger in forging ahead with that recommendation
> as is.
>

Hooray.

I have emailed the generic addresses I could find at LastPass and
1Password, by the way. If you (or anyone else?) happen to know folks there,
help me out. :)

2. I see agreement that the current `get()` API is robust enough to support
>> extension in another WG with (something like) an IdentityCredential object
>> which could "assert certain properties and values about an identity".
>>
>
> I am "taking the 5th" on this. I need to go back to the spec again with
> fresh eyes. I do think that get() filtered by provider is a dangerous and
> irreversible step. I can't think of any other browser API which allows the
> caller to list protocol implementations by vendor as a means of discovering
> which protocol to use. That feels like anti-standardisation to me.
>

You're talking specifically about FederatedCredential, though, right?

Here, I'm only suggesting (and I think Dave agreed in
https://lists.w3.org/Archives/Public/public-webappsec/2015Aug/0081.html)
that a theoretical `IdentityCredential` and `navigator.credentials.get({
"identity": { "filter-key": "value", "filter-key1": "value1", ... } });`
pattern could meet the needs of the folks who wish to define those things.

That is, I want to make room for other people to work on the things they
care about, the core objections from the Credentials CG and Web Payments IG
were about the API's deficiencies in extensibility, and we've worked hard
to address those objections. I think the current API model is generic
enough to do so.


> 3. I didn't see any discussion about future protocols like FIDO, so I'll
>> simply assume that everyone agrees that the current model is extensible
>> enough. :)
>>
>
> Don't know enough about this domain to comment other than to say this
> probably shouldn't be pushed through in a vacuum. There is work being done
> at W3C related to hardware-based security and perhaps some
> cross-pollination of ideas is a good idea.
>

Yes. My point wasn't to suggest that we had a solid FIDO-supporting API,
but instead to suggest that the API as-defined is generic enough to support
things like FIDO if they choose to use it as a basic framework. It would be
lovely if FIDO folks would officially hop into the W3C so we could openly
discuss the proposals that have been floated in more closed contexts.


> If, on the other hand, all of these IdPs were implementing a standardised
> federated identity protocol it would be possible for RP's to implement a
> single protocol that benefits their users irrespective of IdP. If those
> users switch IdP the migration at each RP would be simple and the market
> becomes more efficient.
>

Except insofar as those IdPs you're worried about generally provide
significant services above and beyond authentication (e.g. graph
information). It's unclear that offering an authentication protocol in the
browser will be enough to move RP away from them in anything like
significant numbers, because they're not simply authentication systems.
They're ecosystems in and of themselves.

Clearly there is commercial value in being a super-provider IdP if that
> position gives you data about your users that has value. As a browser
> vendor that also provides IdP services I could see why this proposal is
> unappealing.
>

>
Conversely, if you don't have a business that is built around that need for
> data but provide a browser to your user's I wonder if the indirect value of
> pushing your user's toward better privacy is appealing enough.
>

Come on. Ad hom
<https://en.wikipedia.org/wiki/Ad_hominem#Circumstantial>! Appeal
to motive <https://en.wikipedia.org/wiki/Appeal_to_motive>! :)

Note: I work for Google. I'm not actually on Google's
identity/login/whatever team. I feel like I'm engaging in good faith, and
though I'd very much appreciate everyone signing into Google (and, hey, why
not Doubleclick, while we're at it?!) so as to ensure steady increases in
my monthly paycheck, I am actually interested in the impacts on users and
the ecosystem, and I do appreciate the concerns you're raising.

To be blunt: if a "super provider" handles a billion percent of sign in
activity on the web, then browsers should probably streamline it. Because
it's super and it would make users lives better (especially on mobile where
redirects are _expensive_). Yes, that support would have (positive and
negative) impacts on the ecosystem. Yes, it would be nice to find ways to
increase competition. So let's do that.


> 2. I sincerely doubt that I can find resource inside Google to implement a
>> reasonable UI on top of a variety of protocols in anything like the near
>> future. That worries me, because the "NASCAR" picker is something that I'd
>> like to be able to deal with in the short term, and it seems like the
>> current proposal does that simply, without requiring changes for either the
>> RP or IDP.
>>
>
> The browser chrome should be as simple as the one already proposed. As a
> user selecting which identity to use I can choose between my Facebook
> hosted identity, self-hosted etc but the RP site should simply advertise
> the protocols it supports.
>
> Does the full protocol need to be implemented in the browser? I don't
> think so. This could be done through client libraries or polyfills with
> some standard hooks for the parts that need to be done in the browser
> chrome such as selection of an identity.
>
> OpenID Connect already has an account chooser polyfill that would benefit
> greatly from first-class support in the browser (especially if account
> selection was done in the browser chrome) and the ability to leverage some
> of the more privacy enhancing features of OpenID Connect such as
> self-issuance.
>

I think we agree that increasing federated sign in has interesting (and
generally positive?) security and privacy implications for users. Where
we're currently disagreeing is on the ways in which the browser should
support those sign in mechanisms.

I agree with you that we should support a site's ability to ask for "OpenID
Connect" (though I disagree that that should be the only option). I'll
blindly assert that doing so will require some investment on the part of
both RPs and IdPs, and that the "super providers" you're worried about
bolstering will be uninterested in doing that work for the reasons you've
outlined below. This is why I was asking about discovery mechanisms below.
If the browser can discover on its own that certain origins support certain
protocols, that's one thing. If the IdP needs to proactively assert it in
some way, that's quite another.


> 3. Do you have a proposal for discovery? That is, how do I know what
>> protocols a particular origin supports? Do all the protocols you care about
>> support something like `
>> https://accounts.google.com/.well-known/openid-configuration`? Would we
>> need to request X files from a server every time we save a password? (Note:
>> I'm a bit concerned about proposals that require the IDP to do some work,
>> as it doesn't appear that there's significant incentive for the IDP to do
>> so.)
>>
>>
> Shouldn't discovery be part of the get() API? The RP site calls get()
> providing the list of protocols it supports and the browser looks in it's
> internal registry of stored identity credentials for those that support
> this protocol. These are the identities presented to the user for selection
> and when the user selects one this is returned to the RP site to initiate
> some protocol specific flow that the RP is then in control of.
>

I mean an earlier phase of discovery that enables the protocol-based
`get()` you've outlined here. How does the browser create an internal
registry of stored identity credentials that support a protocol? That is,
how does it know that a PasswordCredential stored for `example.com` is
actually capable of underlying a synthesized FederatedCredential? I think
there's a disconnect in our mental models here that I hope you can help me
understand. :)

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