Re: Coming back to CREDENTIAL.

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.

A native browser API that supports federation protocols sets a very
powerful precedent. If either a new protocol is developed and becomes a
recommendation of the W3C or the supported protocols evolve to support
better privacy enhancing features then browsers will be expected to upgrade
their native support to include support for these new protocols or protocol
features.

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.

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.

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

On 18 August 2015 at 22:52, Dave Longley <dlongley@digitalbazaar.com> wrote:

> On 08/18/2015 03:53 PM, Adrian Hope-Bailie wrote:
> > On 18 August 2015 at 16:49, Dave Longley <dlongley@digitalbazaar.com
> > <mailto:dlongley@digitalbazaar.com>> wrote:
> >
> > On 08/17/2015 04:37 PM, Adrian Hope-Bailie wrote:
> >
> > On 17 August 2015 at 18:55, Dave Longley <dlongley@digitalbazaar.com
> > <mailto:dlongley@digitalbazaar.com>
> > <mailto:dlongley@digitalbazaar.com
> > <mailto:dlongley@digitalbazaar.com>>> wrote:
> >
> > On 07/31/2015 06:35 AM, Adrian Hope-Bailie wrote:
> >
> >
> > While that's the case today, there is no standard in the browser that
> > further entrenches the use of these protocols and that offers no
> > alternative. I think creating one would be a step in the wrong
> > direction.
> >
> >
> > There is nothing wrong with these protocols. They have their place
> > in the ecosystem just like any others. The fact that there isn't
> > already a good privacy preserving protocol that is widely used isn't
> > an excuse to not support the ones that are.
>
> What I don't want to see is a step-based approach to this
> problem where the steps are:
>
> 1. Native code is added to the browser that *only* supports super
> provider login. There's no easy way an alternative login mechanism
> can leverage the feature directly or transparently through a polyfill.
>
> 2. Native code gets updated to support alternatives.
>
> I see accomplishing #2 after #1 as difficult. In fact, as you mention
> yourself, some browsers vendors are the same companies that run IdP
> services -- which may present non-technical hurdles for alternative
> mechanism adoption.
>
> Why would this approach be taken? Well, it could be if the philosophy is
> *simply* to support what's out there now and deal with any new stuff
> later. I think that's too simple of an approach.
>
> >
> > I fully support the objectives of the Credentials protocol but I
> > disagree that supporting others will entrench them. In contrast I
> > think that if there is a standard for federated login irrespective
> > of protocol it will be easier for new protocols to get traction
> > because the user experience is the same across protocols.
>
> If whatever gets built into the browser is extensible from day 1 for
> alternative mechanisms, that's great. My assertion is that, if, instead,
> alternative mechanisms can't be easily tied into the native API, it will
> cause existing mechanisms to become more entrenched. That means a
> decent bit of attention must be paid to alternative mechanisms *up front*.
>
> >
> > I think if we create a standard API that encourages and/or builds
> > their use into the browser (with no alternative), we're making it
> > more difficult to get away from these bad practices.
> >
> >
> > I disagree, as explained above. A standardised UX makes it easier
> > for users to switch between different underlying protocols.
>
> So long as you can use the same underlying API. If the new mechanism has
> to go around it and/or differences can't be easily hidden from the user,
> it will greatly hinder adoption.
>
> >
> > Having a standard wouldn't take away a user's choice; there isn't one
> > now.
> >
> >
> > But what you are advocating is a standard that intentionally ignores
> > the majority of choices that are already available in favour of one
> > that isn't available yet?
>
> No. I want to ensure that we don't build something into the browser that
> makes it even more difficult for privacy-enhancing login mechanisms
> to get adopted. If we create a standard that doesn't consider
> extensibility or favors super provider use, then once developers adopt
> that standard API as *the way* to do login, something new that is
> incompatible with that approach will be hard pressed to get traction.
>
> If we build something into the browser that *assumes*, for example, that
> IdPs have information on all of the RPs that you've logged into, that
> may make it more difficult for login-mechanisms that don't work that
> way. What if the native code and screens are set up such that this is a
> core assumption and a change in the flow is required to blind the RP
> information from the IdP? What if this new flow can't be polyfilled? I
> don't want to see a situation where browsers will have to implement the
> new flow before it can see wide adoption. I'd rather ensure we can
> polyfill these things so people can experiment with alternatives and
> gain adoption prior to requiring browser vendors to take action.
>
> >
> > If we don't like the state of the art we should try to develop a
> > standard that both accomodates the state of the art and has the
> > flexibility to cater for the future vision. The alternative is; not
> > standardising until the status quo changes.
>
> +1
>
> >
> > My argument against this approach is the same as against the
> > approach of half-baked federation support in the API. A standard
> > should support all federation protocols equally or not support
> > federation.
>
> +1
>
> >
> > I am advocating step 1: "Build login with protocols X, Y and Z into
> > the browser in such a way that the user and developer experience is
> > protocol agnostic. If possible cater for protocols A and B that are
> > still under development." (This should also encourage the
> > super-providers that use customised versions of these standardised
> > protocols to be more compliant.)
>
> +1 - where I'd say the standard must make it possible to easily
> experiment with protocols that are still under development. I think that
> kind of "catering" should be a minimum requirement.
>
> >
> > Even if step 1 makes it possible for other providers to be used,
> > their adoption is unlikely because the nature of the protocols and
> > the nascar problem strongly encourage the continued dominance of
> > privacy-eschewing super providers.
> >
> >
> > I don't agree that this is the case. The standard being developed
> > here will potentially eliminate the Nascar problem entirely
> > (although that is dependent on a concession from Mike on allowing the
> > IdP to load multiple credentials into the browser that are for use at
> > a number of RP sites).
>
> I agree that this API should be used to eliminate the Nascar problem,
> I'm just not convinced it should be done the way that is being
> suggested. Instead, for example, IdPs could simply register themselves
> (with user permission) with the browser so when the login API is called,
> the browser can display to you a set of preregistered IdPs. We have a
> similar mechanism in the Credentials CG work where preregistration with
> a particular browser is not necessary (you just remember an email +
> passphrase instead).
>
> >
> > Whatever gets built into the browser must not make it more difficult
> >  to get alternative approaches adopted.
> >
> >
> > +1 - Why is support for the existing protocols mutually exclusive
> > with this goal?
>
> It's not, but hopefully my explanations above address how supporting
> existing protocols *could* create roadblocks for new ones.
>
>
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
> http://digitalbazaar.com
>