Re: Coming back to CREDENTIAL.

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

Received on Tuesday, 18 August 2015 20:52:59 UTC