- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Fri, 21 Aug 2015 13:11:30 -0400
- To: Adrian Hope-Bailie <adrian@hopebailie.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 08/21/2015 03:25 AM, Adrian Hope-Bailie wrote: > Dave, you are conflating support for super-provider login with support > for existing open protocols. > > I am advocating for support of existing open protocols, not a system > that allows super-providers to continue running their own proprietary > federation protocols. I understand what you are advocating. Both at a high-level and the API change you've requested. I'm trying to make sure we take note that a "baby steps" approach has dangers -- and this isn't a message that is strictly for you, it's for the list in general. I'm saying that how we go about creating the first step or two of a login standard can have negative effects on the success of the subsequent steps. If we're going to take a long approach and build out a whole federated login standard that supports existing open protocols and has a mechanism for easily experimenting with new ones, that's great. If, to get there, we take "baby steps" that involve effectively supporting "all the existing providers really need today", then we may end up making it more difficult to actually ever get the other steps into the standard. I don't think it's that hard to imagine creating a "baby step" where we just synthesize credentials for existing providers. Then, sites just place the providers that people are likely to use in a list when they request credentials. Then, boom! It works for the super providers and the user experience is great. Do we really need to do anything else? You may say "Of course!" (and you have). But a company that is behind both a popular browser and a popular super provider may have a different position. Now the politics of getting a better standard done have been made more complicated. It *doesn't matter* if the goal is supporting open protocols, if the chosen steps to get there throw tar on the road or stop progress entirely. This is the danger of "just making incremental improvements to the status quo". We must reject certain "baby steps". > > We have the same goals; not allowing this API to entrench the status quo > of super-providers leveraging their positions as providers of other > services to capture the market for identity. I also think we have the > same motivations; protecting the privacy and private data of users by > affording them other options from IdPs who do not make their money out > of harvesting personal information. > > My approach to this is to push that this API is open and supports open > protocols so that any IdP who wishes to implement these protocols get's > an equal chance of being used as the IdP at a RP site as any of the > super-providers. +1 > > I recognize your concern that if is this is done in steps that future > integration of new privacy-enhancing protocols may never happen. I think > you have two options in resolving this: 1) try to ensure that the > protocol support is flexible enough to accommodate future protocols OR > 2) advocate that support for federation is not a part of the API at all > until more privacy enhancing protocols are standardised. +1 > > To be clear, what I am asking for is a simple change to the existing API > that favours indexing federation options by protocol as opposed to provider. I understand. Your change is simple at the API level, but it's unclear how complex it is at the implementation level. Some might argue that it could considerably push out a delivery date on the first implementations of this API. I'd argue that it's worth it for the reasons listed above. > > I.e. As an RP site I should be asking the browser "Does this user have > federated credentials that can be used under the following protocols?" > not "Does this user have federated credentials issued by the following > providers?" +1 -- Dave Longley CTO Digital Bazaar, Inc. http://digitalbazaar.com
Received on Friday, 21 August 2015 17:12:06 UTC