- From: Adrian Hope-Bailie <adrian@hopebailie.com>
- Date: Mon, 17 Aug 2015 22:37:10 +0200
- 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>
- Message-ID: <CA+eFz_L291-+_mJwsOfyTQWSi=vFnrZyCNHFTdKGoo442Tm1TQ@mail.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