Re: Coming back to CREDENTIAL.

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.

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

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

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.

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. Whatever gets built into the browser must not make it 
more difficult to get alternative approaches adopted.

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.


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

Received on Tuesday, 18 August 2015 14:49:46 UTC