Re: Coming back to CREDENTIAL.

On 18 August 2015 at 16:49, Dave Longley <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>> wrote:
>>
>> On 07/31/2015 06:35 AM, Adrian Hope-Bailie wrote:
>>
>>
>> Question 1: Origin bound federated credentials
>>
>> The fundamental question here is whether these credentials should be
>> origin-bound. In my opinion making them so renders this part of the
>> spec fairly pointless because I still need to login (using my
>> federated credential) on each relying-party site and only then can
>> the RP site store the federated credential (or at least link it to
>> the new origin that it is now useful for).
>>
>> Suggestion:
>>
>> When a user establishes a session at an identity provider that
>> identity provider already has knowledge of which RP sites the user
>> has authorised with the IdP. So when the IdP stores the federated
>> credential why can't it also specify the origins that the credential
>> is valid for? This could even be a user-mediated step.
>>
>>
>> One problem with this is that it would further build tracking into
>> the Web where it can easily be avoided. In this scenario, the IdP has
>> full knowledge of every site you're logging into; there's no
>> privacy.
>>
>>
>> True. But that is the case today for all all of the most widely used
>>  federated identity protocols. I fully support the goal of optionally
>>  blinding this data to prevent IdP's knowing who every RP is that a
>> user approves for access to their federated credentials but that will
>> require a whole new protocol. I realise that is what the Credentials
>> CG is designing but this standard should be accommodating of what is
>> currently in use widely on the Web first and foremost.
>>
>
> 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.

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.

Changing the UX is the biggest hurdle to adoption of any new technology and
a standard baked into the browser that is protocol agnostic is the best way
to level the playing field for all protocols.


>
>> Also, bare in mind that not all IdP and user relationships demand
>> privacy and in some cases it may be desireable (for both the user and
>> the IdP) for the IdP to know which RPs have been authorised to access
>> some or all of the user's identity. Are we designing a standard that
>> we don't want to be useful in an enterprise scenario where company
>> credentials may be used to login to a variety of partner applications
>> and the company is entitled to know which and when etc?
>>
>
> Blinding should be optional.
>

As should choice of federation protocol.


>
>
>> I'd prefer we take this privacy-enhancing approach vs. further
>> enabling super providers to track every website a user logs into by
>> mere virtue of the protocols or standards involved.
>>
>>
>> As I have tried to explain, we are not further enabling anyone.
>>
>
> 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.


>
>
>> I want to reiterate my earlier point that I don't like the idea of a
>>  standard that takes away user's choice because we somehow feel we
>> know better than users what they should be doing with their personal
>>  data.
>>
>
> 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?


> Rather, it would encourage IdPs to come into compliance with it.
> IdPs can always opt to go around the standard and continue to provide
> the same non-standard choices they offer to their users today.


Which is the likely scenario if the standard avoids support of the
protocols they use.


> But if
> the standard offers people an opportunity to keep more of their
> interactions on the Web private, it will place pressure on IdPs to
> comply in order to keep and continue to grow their user base.
>

If the current IdPs are actively competing with the standard it's chances
of adoption are fairly slim. Like it or not many of the browser vendors are
the same companies that offer IdP services (and contribute to the
development of the existing federated protocols).


>
>> If I trust an IdP to hold my data and I also trust them to know all
>> of the RPs/clients that request that data then why should Web
>> standards make it harder for that IdP to deliver me a good service.
>> Me trusting that IdP is my own choice.
>>
>
> Which is perfectly fine, IMO. Let's just not standardize the use of
> services that, by nature, can't protect a user's privacy -- with no
> clear alternative or path to one through the same mechanism. I don't
> think we're helping by just looking at the state of the art and saying
> "let's just standardize on that" here. I think it will further entrench
> protocols that do not enhance privacy.
>

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.

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.


>
> To be clear, I'm not saying that you are advocating that particular
> position; I'm just saying that it is that position that I'm explicitly
> opposed to.
>
> Trying to do this in steps can be problematic. If step 1 is: "Build
> login with super providers X, Y, and Z into the browser", I think that
> will make any step 2 more difficult to accomplish.
>

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

If the developer and user experience is protocol agnostic we have a
situation where widespread adoption of a new privacy preserving protocol
will be that much easier.


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

Consider the scenario where you land on a sign-up page with a bunch of
"Login with X" buttons but before you even click one your browser prompts
you to use one of the stored credentials you have saved when visiting the
various IdP's you use. This would not be because the browser recognised the
RP site's origin but because the RP site advertised support for a bunch of
federation protocols and the browser knows that some of the credentials you
have stored can be used with those protocols. You pick one and that kicks
of that particular federation protocol or you decline and the RP site's
call to the credentials.get() returns null.

Very soon having "Login with X" badges becomes fairly meaningless.

When new IdP's arrive on the market offering privacy preservation and
portabaility as differentiators from the existing market leaders then
adoption by user's will be driven by demand for those features (as it
should be) and adoption by RPs will be driven by both demand for those
features and demand by their customers to support them.

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


>
> I'd much rather see something that supports a privacy-enhancing
> alternative or paints a clear path to one over a step-based approach
> that only supports the status quo in its first step.
>
>
If that's your desire then until that privacy-enhancing protocol is
standardised or at least in wide use I don't see any option but removing
federation from the standard entirely.


>
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
> http://digitalbazaar.com
>