W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2015

Re: Coming back to CREDENTIAL.

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Mon, 17 Aug 2015 22:37:10 +0200
Message-ID: <CA+eFz_L291-+_mJwsOfyTQWSi=vFnrZyCNHFTdKGoo442Tm1TQ@mail.gmail.com>
To: Dave Longley <dlongley@digitalbazaar.com>
Cc: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Manu Sporny <msporny@digitalbazaar.com>, Brad Hill <hillbrad@gmail.com>, timeless <timeless@gmail.com>
On 17 August 2015 at 18:55, Dave Longley <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.

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?


> In the Credentials CG work, we've tried to take a different direction,
> turning the browser into a blinding agent. If the user so desires, their
> browser can obscure the sites they are presenting their credentials to
> from their IdP. In other words, your IdP doesn't have to know which
> sites you're logging into and federated login still works just fine.
>

That sounds similar to what Mike is advocating, that the browser is
responsible for making the connection between a RP site and a federated
credential from an IdP that may be usable there. i.e. Only the browser
knows that the credential from facebook.com can be used to login at
example.com.

While I see the appeal of this as a privacy enhancing mechanism it doesn't
actually improve the privacy for any user that is using any existing IdP
today, it's just a hindrance to developers and users. If I use facebook.com
to login at example.com then Facebook (my IdP) is aware that I use
example.com. If I then use facebok.com to login to anothersite.com the same
applies. If facebook.com is not able to assert to the browser that fact
then it just makes this API far less useful for anyone that has implemented
existing federated login standards like OpenID Connect, OAuth etc or other
proprietary federations like Facebook.


> 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. The
existing id providers already track all of this data. All we'd be doing by
not allowing IdP's to store credentials for the RPs they already know about
is making this more of a pain in the ass for developers and users as they'd
still have to login to each one despite the fact that the IdP already knows
they use it.

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.

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.

If the concern is that users are too foolish to know what they are doing
then that's a very different problem that we shouldn't solve by taking away
choices we think are dangerous to them.

I support the idea of a browser making smart inferences about the sites at
which it can use my federated credential based on my browsing behaviour. I
don't support inferences from the browser taking preference over assertions
by me the user. If I assert to an IdP that I wish to use that IdP's
credentials to login to an RP site then that should be the final decision
on the matter and the browser should honour that (i.e. Allow the IdP to
store that credential for use at that RP).


>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
> http://digitalbazaar.com
>
Received on Monday, 17 August 2015 20:37:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:14 UTC