Re: Coming back to CREDENTIAL.

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

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

I'd recommend adding KeePass although I don't have any contacts I'm afraid


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

Yes. I think fetching FederatedCredential objects indexed by provider will
not encourage the use of standards by IdPs it will just entrench the
existing super-providers.


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

I agree that it is important that future versions of the spec could
accommodate the needs of new standards (and thanks for all the work on
that) but my point was specifically about what is released today to support
the existing federation standards.


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

Absolutely. I expect all IdPs to offer a variety of additional services to
both RPs and users as a way to attract their business but that should be on
top of a standardised authentication system.

The status quo (coupling authentication with the other services) is fine
for super-provider IdPs and RPs but not for users.


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

I hope my comments didn't come across as implying any bias from you as a
Google employee. That wasn't my intent at all, I think you're position has
been very neutral.

The reality is that this is a topic with far reaching impacts for companies
like Google, Facebook, LinkedIn, Twitter and any others who have built
businesses on collection of personal information for the sake of being
better at delivering the services they charge money for.


> To be blunt: if a "super provider" handles a billion percent of sign in
> activity on the web, then browsers should probably streamline it.
>

I disagree :)

If a super-provider has already cornered the market for sign-in activity
then they don't need browsers to make their lives any easier at maintaining
that market position.

All standardisation efforts will affect some stakeholders positively and
others less so. There will always be those who have developed a competitive
edge built upon their ability to abstract away some complexity and
standards risk eroding that advantage by making the whole ecosystem less
complex.


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

In the authentication domain Google, Facebook, Twitter, LinkedIn have all
provided a service to RP sites which they gladly accepted because it solved
a pain point for them, dealing with authentication (among others).

They could have done this by using a standard and encouraging their users
and RPs to do the same but that would have made portability too easy so
they didn't. To be fair, some, like Google have implemented standards like
OpenID Connect and Twitter with OAuth2 but user's are still encouraged to
"Login with Google+" not "Login with OpenID Connect using your Google+
account".

That was an issue with user education. We can't put all the blame on the
super-providers. But, if this pre-login negotiation is baked into the
browser the user education friction is removed. There is no excuse then for
forcing RP's to support explicit IdPs when simply support the most common
protocols and benefit from the interoperability that should come from this.


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

+1


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

Isn't it the RP that needs to assert that they support logins via a
specific protocol? I would imagine that in a world where browsers remove a
lot of friction for federated authentication protocols that IdPs would try
to support as many as possible (not that there are that many to choose
from).

Does this flow make sense:

1. Bob logs in at IdP site, SecureIdP
2. SecureIdP stores a FederatedCredential for each protocol it supports
(indexed by some protocol identifier).
3. Bob logs in at IdP site, OtherIdP
4. OtherIdP stores a FederatedCredential for each protocol it supports
(indexed by some protocol identifier).
3. User visits RP site, SomeService, that supports login via protocols A, B
and C (in order of preference).
4. RP site calls API.get({"protocols":["A","B","C"]});
5. User is prompted with account chooser dialogue:

RP site supports federated login.
Do you want to login with one of the following accounts:
1. Account: Bob
    Provider: SecureIdP
    Protocol: A
2. Account: The Bobster
    Provider: OtherIdP
    Protocol: C

6. User selects one of these and the credential object is returned to
SomeService and that kicks of the appropriate auth protocol using that
credential.

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

Did the flow above explain or am I missing piece still?


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