Re: Coming back to CREDENTIAL.

Hi Mike,

I think that's a good summary of where we are.

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

> As it turns out, it's a bad idea to start a thread before going on
> vacation. :)
>
> I'd like to pull back a bit and try to tease out the concrete things that
> need to be done to ship a minimum viable API that solves the broad problems
> I noted in
> https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0201.html.
> In this thread, I see some convergence on the following topics:
>
> 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.


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


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


>
> Is that a fair summary?
>
> There's less convergence on Federations. I see concern from Adrian and
> Dave about the baby step proposed for federated credentials. In particular,
> the suggestion is that the currently defined step would lock in "super
> providers"'s dominance, and that we could fix that by simply tweaking the
> API to focus on protocols rather than origins.
>

+1 - While it feels like a subtle difference the impact is quite
significant.

Today the super-provider IdPs leverage their large user-base to encourage
RP sites to have them as a "Login with X" option.  This would be fine if
they used standard federation protocols to do this but they have all
adapted the existing protocols slightly so that RP sites have to use IdP
supplied code libraries for the integration (and display separate "Login
with X" buttons for each IdP), effectively tying them to that IdP for every
user that has established an account at the RP. User portability is almost
impossible and therefor user's are locked in to an IdP based on the large
number of RP services they already use with their super-provider ID.

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.

There is no problem with super-providers having a large user base or using
that to their commercial advantage but making it difficult for users to
exercise their choice of IdP is a problem. Many of the issues being raised
on this list such as portability and privacy come down to user choice. We
shouldn't force users to do anything but we should create an environment
where exercising their choice is easy and one choice is not unnecessarily
easier than another. If you want to use an IdP that is privacy preserving
and makes it easy to port your identity that should be as easy as using
your email provider as your IdP (if that's what you are happy to do).


>
> To this point:
>
> 1. Does anyone else care? :) Specifically, I'd like to get some feedback
> from folks who might at some point implement the API. CCing people from
> Opera, Microsoft, Mozilla, and Apple.
>


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.


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


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

In the OpenID Connect scenario this would be the equivalent of the user
typing in an OpenID Connect URI.

>
> -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.)
>
> On Fri, Aug 21, 2015 at 7:11 PM, Dave Longley <dlongley@digitalbazaar.com>
> wrote:
>
>> On 08/21/2015 03:25 AM, Adrian Hope-Bailie wrote:
>>
>>> Dave, you are conflating support for super-provider login with support
>>> for existing open protocols.
>>>
>>> I am advocating for support of existing open protocols, not a system
>>> that allows super-providers to continue running their own proprietary
>>> federation protocols.
>>>
>>
>> I understand what you are advocating. Both at a high-level and the API
>> change you've requested. I'm trying to make sure we take note that a "baby
>> steps" approach has dangers -- and this isn't a message that is strictly
>> for you, it's for the list in general.
>>
>> I'm saying that how we go about creating the first step or two of a login
>> standard can have negative effects on the success of the subsequent steps.
>>
>> If we're going to take a long approach and build out a whole federated
>> login standard that supports existing open protocols and has a mechanism
>> for easily experimenting with new ones, that's great. If, to get there, we
>> take "baby steps" that involve effectively supporting "all the existing
>> providers really need today", then we may end up making it more difficult
>> to actually ever get the other steps into the standard.
>>
>> I don't think it's that hard to imagine creating a "baby step" where we
>> just synthesize credentials for existing providers. Then, sites just place
>> the providers that people are likely to use in a list when they request
>> credentials. Then, boom! It works for the super providers and the user
>> experience is great. Do we really need to do anything else?
>>
>> You may say "Of course!" (and you have). But a company that is behind
>> both a popular browser and a popular super provider may have a different
>> position. Now the politics of getting a better standard done have been made
>> more complicated.
>>
>> It *doesn't matter* if the goal is supporting open protocols, if the
>> chosen steps to get there throw tar on the road or stop progress entirely.
>> This is the danger of "just making incremental improvements to the status
>> quo". We must reject certain "baby steps".
>>
>>
>>> We have the same goals; not allowing this API to entrench the status quo
>>> of super-providers leveraging their positions as providers of other
>>> services to capture the market for identity. I also think we have the
>>> same motivations; protecting the privacy and private data of users by
>>> affording them other options from IdPs who do not make their money out
>>> of harvesting personal information.
>>>
>>> My approach to this is to push that this API is open and supports open
>>> protocols so that any IdP who wishes to implement these protocols get's
>>> an equal chance of being used as the IdP at a RP site as any of the
>>> super-providers.
>>>
>>
>> +1
>>
>>
>>> I recognize your concern that if is this is done in steps that future
>>> integration of new privacy-enhancing protocols may never happen. I think
>>> you have two options in resolving this: 1) try to ensure that the
>>> protocol support is flexible enough to accommodate future protocols OR
>>> 2) advocate that support for federation is not a part of the API at all
>>> until more privacy enhancing protocols are standardised.
>>>
>>
>> +1
>>
>>
>>> To be clear, what I am asking for is a simple change to the existing API
>>> that favours indexing federation options by protocol as opposed to
>>> provider.
>>>
>>
>> I understand. Your change is simple at the API level, but it's unclear
>> how complex it is at the implementation level. Some might argue that it
>> could considerably push out a delivery date on the first implementations of
>> this API. I'd argue that it's worth it for the reasons listed above.
>>
>>
>>> I.e. As an RP site I should be asking the browser "Does this user have
>>> federated credentials that can be used under the following protocols?"
>>> not "Does this user have federated credentials issued by the following
>>> providers?"
>>>
>>
>> +1
>>
>>
>>
>> --
>> Dave Longley
>> CTO
>> Digital Bazaar, Inc.
>> http://digitalbazaar.com
>>
>
>