There is no auth panacea. There's too many different use cases, too many players involved. You cannot create one "thing" that solves all the problems for all the people. It was hubris.
Instead, if "the industry" wants to solve "the problem", they need to write down all the use cases. Then we can argue about how to do that, and the result will probably be a couple different things that solve a couple different groups of use cases.
But what will always suck is letting "the industry" dictate to us "tech peons" how that should happen. They always come up with bloated standards that are a pain in the balls. So rather than let "the industry" solve the problem, I think we need a loose confederation of open source contributors and corporate goons to meet on some forum somewhere and hash it out. Let the solutions (plural) come organically without a single player controlling the conversation.
Sure - the problem isn't really on a technical level, it's the social problem of getting everyone to agree to adhere to one standard and then we can implement that in a single set of formats and tools.
Open Source and Open Standards have always been the solutions to these problems, and remain so. Necessary rather than sufficient requirements though, I suppose.
I’d rather have the companies fighting for the user. What is the purpose of a standard anyway, other than to serve the users? The idea is counterproductive if it results in a worse UX, even if just in the medium term.
In this case, getting those companies to fix their broken code is unrealistic. Less realistic than just providing a whitelist anyway.
With a lot of these things, if people can't agree to make a standard system to do all of it just as well then there's going to be a big company that does so. We have had this with e-mail, signed exchanges, DDOS protection and will probably have it with many other things unless people pull themselves together at least after these proprietary solutions are created and create better alternatives.
I agree - though I don't know which solution would be better (standardization of industry APIs as I propose, or a FOSS project to build and maintain a system that could hit all of these systems).
I think a mix of both would be best, though both are also wrought with many more difficulties than we have gone into here. For example, just a couple that come up off the top of my head:
* API Standardization issues
- Many of these companies likely have custom sets of data that they expect, validation rules, their own auth procedures that they'd be hesitant to let go of etc...
- Smaller companies (such as in my ECSI example) would likely shy away from the costs of creating such an API for their own services, thus still resulting in the need for custom solutions
- Larger companies would also hesitate to change - either due to their own org/system complexity, or just a desire to not spend money on something that doesn't feel core to their business. Healthcare integration standardization is severely hampered by this, for example.
- Many of these companies may actually be charging for access to their data backend, which would still thwart the use of standardized APIs even after they were adopted.
* FOSS System Issues
- To create the integrations, companies would have to actually both expose it to you and allow you access. The creators of the FOSS system would have to somehow convince these companies to essentially open up their systems to the world. That would be fantastic I think, but it would be very tough to convince companies.
- You'd need a large number of dedicated people to the cause - and not just developers to create and maintain the integrations, but also people with the skills needed to negotiate with the businesses for whatever kinds of back-end deals have to occur to keep the integration online and functional on the financial institution's side. So far, we've been good at finding an army of excellent developers to drive FOSS - for this kind of integration pursuit, the FOSS movement would also need to be good at finding an army of excellent businessmen, lawyers, etc... that would be as dedicated and available as the software development force (I'd be all for such an expansion of scope in the Open Source movement)
- The "charging for access" issue above would still be a problem here.
Now, none of these are reasons not to do it - merely a statement of risks and a peek into the scope and effort needed for such an approach. It's not something I'd ever have the time or energy to lead the charge on personally, but kudos to whoever could rally the army (and the political will) needed to make it happen.
Agree with both the comment above, but do we really have a solution?
It is a trade off between Cross Platform, time to market and development resources. And unlike any other scientific and engineering industry, Software Development doesn't even agree on a few industry standards, instead everything is hyped up every 2 years and something new come around and becomes a new "standard". And we keep wasting resources reinventing the flat tire.
When we let "the industry" set our standards, we get a mess of crap that works for the specific use cases of the giant companies that created it. Meanwhile, actually using these things ourselves leaves out a lot of use cases, adds complexity, and becomes burdensome, to the point you don't even want to use it.
We need the international software development community to have its own standards body outside of massive corporations and creaking old institutions with outsized influence. Standards should represent the majority of people writing and using the code.
If everyone's going to accept a single standard (which would be helpful for inter-car telemetry), it can't be controlled by Google. We can't let our cars become another one of Google's monopolies.
We should also strongly consider the merits of open source with many vendors contributing and a good governance model. Ideally there'd be some sort of foundation (or government-sponsored group) in charge of such an effort.
The last thing we need is to have our screaming metal death traps buzzing around controlled by black box software by a single developer.
What would you feel a simple solution be? Maybe you know something that others don't... or maybe it is just really hard to have a standard across millions of different ways of deploying and running software systems.
Every issue system has its own API and today there's no standard for interchange. It would be interesting to see an attempt to try to build a reusable standard, but I don't know what sort of standards agency exists with the guts to try something like, I don't envy the political battle that would entail, and having seen some of the horrors of bespoke Jira and TFS configurations I'm mostly such a standard would either be too minimalist and disappoint too many people or too maximalist and impossible to build.
The alternative is to support multiple platforms. Standardizing on a single platform is as foolhardy as standardizing on a single company. Even open platforms have defacto owners/controllers (Java anyone?).
Or we can build a system that just works and doesn't rely on adoption by other clients. Yes if we had a header that everybody used and respected it would work. But that's a lot harder.
That might be a problem, but looking for better tools or waiting for them to adopt the standard seems an easier solution than inventing another standard.
I agree we need to attack this problem, but is another proprietary service to connect via proprietary APIs to your other proprietary services really the best answer? This looks like even more complexity than before (when something breaks, who do I go to for help?), except now I'm paying yet someone else to stand between me and my data.
We didn't get where we are today, in any field, using this approach. We don't have 30 different measurement systems, and a company whose job it is to coordinate conversions between them. We don't have 30 different text file encodings (any more!), and a company whose job it is to automatically convert them as necessary. We say: here's the standard, and now you can use it or be ostracized in the market.
If writing custom adapters to interface with GitHub/GitLab/Jira/... is anything other than a temporary solution, while you work on some grand plan to get issue-trackers all on the same page, then it's just a money-grab on the road to failure. Someone will cut off API access, or drive up your costs, or refuse to offer an API, and users will be stuck with "one command center (for the 3 most popular services they use), plus 3 oddballs", and it's just not going to be worth the hassle.
It's a band-aid. Normally you stick a band-aid on something that will heal itself, and then rip it off tomorrow. This particular problem is getting worse. This is a very pretty band-aid, but you've applied it to a sucking chest wound.
Instead, if "the industry" wants to solve "the problem", they need to write down all the use cases. Then we can argue about how to do that, and the result will probably be a couple different things that solve a couple different groups of use cases.
But what will always suck is letting "the industry" dictate to us "tech peons" how that should happen. They always come up with bloated standards that are a pain in the balls. So rather than let "the industry" solve the problem, I think we need a loose confederation of open source contributors and corporate goons to meet on some forum somewhere and hash it out. Let the solutions (plural) come organically without a single player controlling the conversation.
reply