Alleen voor bedrijven blijkbaar want ik kan als particulier gewoon mijn gegevens in een bestand downloaden. Ze vertellen op hun website dat de Aspera Client nodig is om het beveiligingsniveau te verhogen.

Misschien dat er wat bijzondere authenticatie nodig is (SSL client certificaten ? )
In een aantal gevallen _kan_ dat ook wel met de browser, maar dan kan ik me voorstellen dat ze alle uitgewerkte handleidingen hoe dat in te stellen niet zo snel omgooien naar tig (drie, vier ? ) webbrowsers, als ze begonnen zijn met een universele client .

Maar - aangezien jij de ervaring hebt - wat moet je of kun je extra doen in Aspera voor die download bij de BD ?


Opmerkelijke naam trouwens : Aspera is Latijn voor 'moeilijkheden'. ('Per aspera ad astra')

Tja het is een generiek programma wat iedereen kan downloaden en je hoeft er zelf geen eigen client certificaten in
te installeren dus ik kan me niet voorstellen dat dit nou zoveel veiliger is dan een browser https sessie.
Zeker ook omdat er ook nog een browserplugin geinstalleerd wordt waarmee je door het klikken op een link in een
mail die ze je toesturen het betreffende bestand meteen kunt downloaden. (in die link zitten 2 unique ID's).

Leuker kunnen we het niet maken - wel moeilijker.

Op zich kan deze omgeving ook file UPLOADs afhandelen maar daar doen we helemaal niks mee. Dus wellicht veel
andere gebruikers ook niet. Maar ook uploaden kan best in een browser omgeving geimplementeerd worden natuurlijk.

Ze geven een mail adres voor vragen mbt dit gedoe maar na 24 uur nog geen antwoord gehad.

Oeps? Ik hoop niet dat de webbrowser daadwerkelijk de opdracht krijgt om een verbinding te maken met de lokaal geïnstalleerde Aspera Client via local.connectme.us (dat, bij een betrouwbaar DNS antwoord, 127.0.0.1 luidt - maar DNS is zelden betrouwbaar) op - kennelijk- poort 43003, zoals getoond in "Stap 2" van de presentatie in https://filetransfer.belastingdienst.nl/info/pages/connectclientdetail.html.nl?ver=2.3.

En mocht dit toch zo zijn, dan hoop ik dat er iets in place is om een MitM te detecteren...

Uit https://gpltech.zendesk.com/hc/en-us/articles/360027677631-I-m-having-trouble-with-my-Aspera-on-Cloud-Connection maak ik op dat het wel zo veilig is om 127.0.0.1 local.connectme.us in je hosts file te zetten.

Ik snap niet zo goed waarom deze kermis veiliger is dan gewoon direct downloaden met de browser van een ffile
met een ingewikkelde URL. Immers iemand die die URL weet te achterhalen en die file perse wil hebben die kan
gewoon die client installeren en hem downloaden. Waarom is dat dan beter?
Ik denk dat de belastingdienst zich er gewoon in heeft laten tillen door de verkopers van IBM cq Asperasoft.
Aan zo'n managerstafel kun je heel makkelijk beweren dat iets veiliger is...

Waarschijnlijk omdat er hier een compleet framework achterzit? Het is niet alleen even een file upload.
En kun je je browser vertrouwen?

Al is dit wel een hele complexe en gebruikers onvriendelijke oplossing.

Ja maar het interesseert "ons als gebruiker" toch helemaal niet wat er voor framework achter zit?
Natuurlijk moet er een hele inrichting zijn waardoor men files voor verschillende klanten kan klaarzetten, URL's kan aanmaken
die men naar die klanten kan mailen, zorgen dat ze niet bij elkaar files kunnen (maar dat is volgens mij alleen afhankelijk
van het bekend zijn van die URL's) enz enz.
Maar dat betekent toch niet dat er dan meteen ook maar client-side software moet zijn?
Volgens mij kun je het client deel prima met een browser doen, en kan al die complexiteit aan de server(website) kant
blijven.

Inderdaad heel vervelend dit. Gebruikers kunnen bij ons gewoon geen software installeren, en wijzelf ook nauwelijks.
Ja een oud laptopje erbij pakken en daar zo'n pakketje op zetten dat kan uiteraard. Maar dat moet je als leverancier
toch niet willen om dat van je klanten te eisen?

Tja, complicatie is natuurlijk dat in dit geval de leverancier de belastingdienst is en wij dus wel gedwongen zijn om klant
van hen te zijn en te pikken wat ze ons voorschotelen. Maar ik neem niet aan dat dit pakket specifiek voor de
belastingdienst en/of voor andere belastingdiensten is dus is mijn idee nog steeds dat het archaisch is en niet meer
van deze tijd. Als je zo iets wilt van een ander dan moet dat gewoon zonder software installatie kunnen tegenwoordig.

"Framework" is een buzzword voor (een zeker slag) developers en middle managers. Lijkt me volstrekt irrelevant en onnuttig voor de (gedwongen) gebruiker.

Dit is een gigantische drogreden. "Mischien kun je je browser mogelijk eventueel niet vertrouwen dus dwingen wij je maar om code van onze keuze te gebruiken." Het mist het punt, namelijk dat ik redelijk eenvoudig van client kan wisselen als ik open protocollen kan gebruiken, en bijvoorbeeld een command-line client vanuit cron aanroepen zodat de boekhouder iedere maand automatisch het nieuwste bestand van de eigen fileserver kan vissen. Dat kan met ongedocumenteerde proprietary rommel veel minder, en andermans favoriete "frameworks" zijn al snel (technische term) "hell on wheels" om zomaar even in te zetten op systemen van mijn keuze.

Niet dat "http" zo geweldig is. Maar het is tenminste open, en redelijk bekende koek, zelfs met ssl erbij.

Mijn netwerk, mijn regels. De belastingdienst heeft er niets te zeggen. Dus zorgen ze maar dat ze de overbrugging tussen hun en mijn netwerk netjes mogelijk maken, namelijk met open protocollen. Niet met "frameworks".

Nodeloos complex. En de verkeerde "oplossing" op de verkeerde manier op de verkeerde plek.

Op zo'n moment ben ik blij dat ik maar gewoon burger ben en (nog) de mogelijkheid heb om tegen de belastingdienst te zeggen "stuur maar een briefje".

En, niet te vergeten: Als ze het goed gedaan hebben dan is het triviaal om meerdere protocollen te ondersteunen, desnoods met door de gebruiker te kiezen (en dus per gebruikersnaam verschillende) restricties over welke van de beschikbare protocollen ze wel en niet wensen te gebruiken, om niet-gewenste protocollen uit te zetten uit veiligheidsoverwegingen.

Dat idee van "is te moeilijk, iedereen moet precies gebruiken wat wij voorschrijven" zie je iedere keer weer in "automatisering" en voor mij is dat een automatisch brevet van onvermogen voor de "automatiseerder". Zorg maar dat je biedt wat je (hier zelfs verplichte!) gebruikers nodig hebben, in plaats van ze uit eigen gemakszucht de wet voor te schrijven.

De overheid is hierin echt niet de enige, maar als natuurlijk en habitueel monopolist wel een der ergelijksten.

Ik snap wel waarom een ingewikkelde url niet aan de eisen voldoet, maar particulieren en bedrijven kunnen aanloggen op de website van de belastingdienst, en boekhouders als vertegenwoordigers van hun klanten ongetwijfeld ook. Als de beveiliging daarvan goed genoeg is om een belastingaangifte te doen (en goed genoeg voor bijvoorbeeld ggz-instellingen om zeer vertrouwelijke informatie met cliënten uit te wisselen), dan zie ik niet in waarom die niet goed genoeg is voor file up- en downloads, gewoon over https binnen een aanlogsessie.
Dat snap ik ook niet.
Dat is een mogelijkheid die bij mij ook is opgekomen. Niet de enige mogelijkheid, maar het zou kunnen.

Nee. Maar waarom 'stimuleert' de overheid dan het gebruik van DigiD?

Mag ik daaraan toevoegen, dat toen de belastingdienst dit bericht eruit stuurde, ALLE adressen van de "getroffen" bedrijven van deze (vreselijke) tool in het AAN: veld te lezen waren ...

Ën een aantal van onze klanten, daar weinig enthousiast over waren.
Je weet dus precies welke bedrijven met deze (vreselijke) tool aan het werk zijn.

Om je nog beter te kunnen negeren. Je weet wel, "digitaal getransformeerd" enzo. Ze kunnen je ook beter de schuld geven van niet tijdig in "jouw" digitale postvakje bij hunnie kijken, en je daar extra boetes voor geven enzo. Handig!

Dit gebeuren werkt niet via DigiD. Dat is voor particulieren.
Ze wilden net invoeren dat je moest inloggen met EherkenninG maar dat is er nog niet doorheen geloof ik.
Ik zal straks eens navragen wat er nou precies aan beveiliging omheen zit maar in ieder geval komt de https link die
hij heeft direct uit bij de bestanden, dus die URL is super-geheim. Beetje vreemd eigenlijk.

Hangt er ook allemaal weer vanaf. Vaak zit hier een complexe infrastructuur achter. Middelware of een Enterprise Service Bus. Daarin wordt alle communicatie uitgevoerd. Immers wegens alle AVG en GPDR regels moet alleen traceerbaar zijn. Dus wil je dat alles centraal geregeld is/wordt. Ander krijg je straks weer vragen hoe dit zo fout heeft kunnen gaan, als het ergens fout gaat.
Juist niet overal een eigen systeemje voor bouwen, maar standaardisatie.

Nu durf ik niet te zeggen of dit allemaal geautomatiseerd kan worden. Maar als dit geen eis was bij het bouwen, dan hoeft men daar ook geen rekening mee te houden. Misschien heeft men daar namelijk wel een hele andere koppeling voor liggen. Die wel geautomatiseerd kan worden. Dat jij iets gebouwd hebt ergens omheen wat daar niet voor gemaakt is, is niet een probleem van de belastingdienst.

Das leuk, maar daar bereik je alleen niets mee.

En wie mag dit allemaal gaan ondersteunen als het niet werkt?


Maar het is een drama product. Niet standaard porten is al een ramp in een Enterprise. Java 2de grote fail. DNS afhankelijkheden.
Wie heeft dit ooit bedacht?

Ik snap heel goed dat er aan de kant van de belastingdienst een standaard framework met allerlei complexiteit
nodig is om dit allemaal in goede banen te leiden. Maar wat ik niet snap is waarom de greep daarvan zich moet
uitstrekken tot de systemen van de klant. Als ik iets bij bol.com bestel hoef ik toch ook geen bol.com client te
installeren??
Laten ze zorgen dat het gewoon werkt in een moderne browser. Dat moet die Asperasoft / IBM toch kunnen?
Dan kunnen ze die Java zut ook zelf runnen.


Inderdaad. Een bedrijfje wat in een niche markt gestapt is in 2000 en later door IBM is overgenomen gok ik.
En wat nu te laat is meegegaan met de moderne tijd.
(of ze hebben wel wat beters maar de belastingdienst moet dat nog invoeren)

Heeft helemaal niets te maken met "En kun je je browser vertrouwen?", en mist nog steeds compleet het punt.

Ten eerste heb ik als (gedwongen) gebruiker helemaal niets te maken met wat de belastingdienst er allemaal achter wenst te plakken aan bergen "enterprise", "frameworks", en wat daar allemaal nog meer aan buzzwords rondzwerft. GDBR en AVG compliance binnen overheidssystemen? Hun probleem, niet het mijne.

Ten tweede was het argument nu juist "standaardiseer op open protocollen, niet op software".

En ten derde moet je als automatiseerder meerdere toegangsmogelijkheden kunnen ondersteunen, dat is een kerntaak van "over de grens werken". Mischien is er maar een gangbaar protocol maar dat doet niet af aan het principe dat je op protocol standaardiseert, niet op software, en dat je je software zo ontwerpt dat je relatief eenvoudig een protcol kan toevoegen mocht dat nodig zijn. Dat is helemaal geen onredelijke eis voor software die wellicht dertig jaar mee moet gaan, wat voor infrastructuur geen onredelijke tijdsduur is.

"Het was geen eis tijdens het bouwen dat het ook bruikbaar moest zijn voor de buitenwacht." Zo ken ik er ook nog wel een paar.

Wat mij betreft ontslagwaardig. En ja, dat betekent dat als ik het voor het zeggen zou hebben die faalbende dat hele hordes aan "architecten" en "managers" subiet de WW in verdwijnen.

Oh, dus is het maar prima dat de belastingdienst mij iets opdringt waar ik dan maar tegenaan moet gaan proberen te "bouwen"? Hoepel toch op zeg.

Vertel eens, waarom mag de belastingdienst mij vertellen wat ik op mijn netwerk moet doen en ik hen niet vertellen wat zij op hun netwerk moeten doen? Ik betaal tenslotte belasting en wie betaalt, bepaalt!

Je komt iedere keer met idiote omkeringen die nergens op slaan. Sterker, je ageert tegen het voorstel "laten we netjes afspreken wat we doen op de grens tussen beide netwerken en laten we verder ieder ons eigen ding doen op elk ons eigen netwerk." "Daar bereik je niets mee", zeg jij. Hallo, hoe dacht je dat het dan wel werkte?

Zorg maar dat het wel werkt, dan hoef je niet van die domme vragen te stellen.

Gezien je argumentatie hierboven, mensen zoals jij. Met de beste bedoelingen, natuurlijk.

File downloads worden al van begin af aan ondersteund in HTML, dat gaat simpelweg met een hyperlink naar het bestand. File uploads worden sinds 1995 ondersteund (met <input type='file'> in een HTML-formulier). Het werkt aan de client-klant met kaal HTML, het heeft zelfs geen JavaScript nodig. Op de server moet gezorgd worden dat de upload wordt afgehandeld, maar dat stelt geen eisen aan de client.

Niets nieuws onder de zon dus, ze hoeven niet eens iets te implementeren waar je een moderne browser bij nodig hebt, het zit al vijfentwintig jaar in de basis-gereedschapskist. En het kan gewoon ingebed worden in een https-sessie waarbij de ondernemer is ingelogd, zodat beveiliging en authenticatie geregeld zijn. Het loggen van de interacties is ook al niet moeilijker dan wat ze nu al doen in hun website, op zijn minst logt de webserver het zelf en doen ze daar wat mee.

Het zou een non-probleem moeten zijn in mijn ogen. Ze hebben IBM helemaal niet nodig hiervoor, ze hebben hun webontwikkelaars nodig. Maar misschien kennen die allang geen HTML en HTTP meer, maar alleen nog een of ander fancy framework. Of hebben ze de misschien hele website aan IBM uitbesteed?

En wat zou er mis zijn met Java? Een ronduit superieure programmeertaal die grootschalig gebruikt wordt. De hier gekozen oplossing met een apart te downloaden en starten cliënt programma snap ik ook niet maar het Java de zwartepiet toespelen is gewoon onterecht.

Is het ook mogelijk om het HTML meerdere grote files up/downloaden over onstabiele verbindingen, dus ook iets met resume mogelijkheden? Denk eens aan meerdere 10Gb files of nog groter.

Dit is namelijk waar wat deze tool mogelijk maakt en kan best best wel eens een eis geweest zijn waaraan het product moet voldoen.

Misschien niet nodig voor deze files, maar wel voor overige diensten die misschien gebruik maken van deze filetransfer mogelijkheid.

Jij noemt nu iets een non probleem, zonder dat je weet welke eisen de oplossing moet voldoen.

Doordat het in Java geschreven is ziet de user-interface er niet uit, en is het altijd lastig om te installeren op een
complexe omgeving (waar iedereen zijn eigen eisen aan de Java versie heeft).
Inmiddels heb ik van de belastingdienst vernomen dat ze er wel naar streven dit gedrocht uit te faseren.

En ook heb ik met wat googlen begrepen dat dit programma en het gebruikte protocol speciaal bedoeld is om gigantisch
grote bestanden snel te kunnen transferren (het maakt gebruik van UDP met een eigen selective retransmissie laag)
wat totaal irrelevant is voor de toepassing. Ik denk nog steeds dat ze zich erin hebben laten tillen.

Ik heb het niet volledig doorgenomen. Aspera wordt aangeduid als een MFT managed File Transfer.
https://www.ibm.com/products/aspera/collaborate best wat meer en anders dan via een website iets doen.

En nee logging via een webserver is iets wat niet echt lekker loopt. Daarom zijn alle die trackers ingevoerd omdat loggegevens vanuit de kant slecht gedeeld worden als belangrijk voor de "applicatie"

Is dat relevant voor dit onderwerp? Het ging over "iets van de belastingdienst over de loonbelasting binnenhalen" en dat je zoveel werknemers hebt dat je maandelijkse of zelfs jaarlijkse bestand meer dan "10Gb" (1 1/4 GB, bit vs. Byte, dankuwel) is, en laten we aannemen zonder compressie en alles.

Wat op zich een rare aanname is want als je hele frameworks kan installeren kun je je bestandje ook even door een compressor halen. Daarnaast hebben de meeste browsers en webservers inline-gzip-ondersteuning dus als dat netjes geconfigureerd is dan hoef je niets te doen en je tekstbestandje kost "als vanzelf" een kleine fractie van het verkeer om te versturen.

Suspend/resume zit wel ingebakken in http (tenminste, je stopt de download en later vraag je om hetzelfde bestandje maar zegt dat je de eerste N bytes al hebt--dan moet er achter dezelfde bestandsnaam niet ineens een ander bestand zitten natuurlijk, en dat is een taak van het back-end, niet van http), en een maximumgrootte zit er niet van zichzelf in, dus als zulke limieten er zijn zitten ze ergens anders, in het bestandssysteem ofzo (bv. FAT) en daar helpt een berg extra code in een "framework" niet tegen.

Hoeveel data per bedrijf? Keer hoeveel bedrijven, hoeveel data denkt de belastingdienst in z'n geheel dan nodig te hebben?

Oftewel, een mooi voorbeeld van "one size fits none"-"denken". "Omdat ik mischien ooit wel grote bestandjes moet verplaatsen, moet iedereen met een hopeloos over-engineerded proprietary 'oplossing' in de weer".

Dit. Werkt. Niet.

En weet jij het dan wel en dat je het ook uit kan leggen?

Het ging erover dat niemand hier een valide reden kan zien om met zo'n proprietary berg ellende in de weer te gaan. Als de belastingdienst denkt dat het wel ergens nuttig voor is dan moeten ze dat maar aannemelijk maken, en bovendien zorgen dat iedereen die niet mee wil of kan nog alternatieven heeft. Anders zijn we weer terug bij "verkapte belasting", zij het in de vorm van "nodeloos moeilijk doen met ibm rommel", wellicht in de vorm van licenties.

Let wel, het is niet "de belastingdienst is vrij om te doen en wij moeten maar laten zien waarom dat echt niet kan". Het is "de belastingdienst moet maar laten zien waarom dit echt een goed idee is en dan nog steeds werkbare open alternatieven bieden."

Heeft de Belastingdienst je gevraagd om de IBM Aspera Desktop Client of de Connect software te installeren?

Alles op de site van de Belastingdienst, o.a. https://filetransfer.belastingdienst.nl/info/pages/installissues.html.nl?ver=2.3, verwijst naar laatstgenoemde Connect software, die je (klik op de link achter de onderste bullet op laatstgenoemde pagina) kunt downloaden vanaf http://downloads.asperasoft.com/en/documentation/8.

Ik heb dat gedaan (zowel de Windows als de Linux versie) en deze bekeken. Geen van beide lijkt ook maar iets met Java te maken te hebben. Ik heb niet naar de Desktop Client gekeken (dat de Belastingdienst je vraagt om die te installeren ligt niet voor de hand, want daar heb je een licentie voor nodig volgens (PDF) https://asperasoft.com/software/clients/).

Geen idee waarom ze dit onzinnige localhost record gebruiken. Blijkbaar komt het bij Amazon vandaan:
connectme.us. 584 IN SOA ns-821.awsdns-38.net. awsdns-hostmaster.amazon.com.

Het zal mij ook niet verbazen als de belastingdienst ook cloudservers bij Amazon heeft draaien.

De file die wij moesten ophalen was een .csv van 111kB. Wij zijn een bedrijf met zo'n 1600 medewerkers.
En een .csv door zip heen halen zal em meestal wel een factor 3 verkleinen ook nog.
Kortom voor DEZE toepassing is het in ieder geval zwaar overkill.

Als wij zelf zo iets moeten versturen gebruiken we een zip file met password wat we apart communiceren, of een
mailservice die daar speciaal voor bedoeld is die mails voorziet van een password wat per SMS verstuurd wordt.
Geen exotische software nodig.

Voor de uitwisseling van gegevens met belastingplichtigen?

Voor de uitwisseling van gegevens met belastingplichtigen?

Waarom moeten die eisen verweven zijn met de eisen die hieraan gesteld worden? Bedenk dat ze vereisen dat iets bij een derde wordt geïnstalleerd, zonder rekening te houden met welke eisen die aan zijn omgeving stelt. Als je daar wel even bij stilstaat wordt een heel voor de hand liggende eis voor deze toepassing dat er geen bijzondere eisen aan de client mogen worden gesteld.

Ik ken inderdaad het eisenpakket niet, maar als je bedenkt dat het allemaal onderdeel uitmaakt van de communicatie tussen belastingdienst en belastingplichtige dan ligt het erg voor de hand dat alle eisen die aan de up- en downloads gesteld worden, qua authenticatie, vertrouwelijkheid, integriteit, logging, noem maar op, precies dezelfde zijn die gelden voor de diverse belastingaangiftes en andere zaken die in de webinterface geïmplementeerd zijn. En HTML en HTTP(S) bevatten al sinds jaar en dag alle mogelijkheden die je ervoor nodig hebt. Een download is gewoon een hyperlink als alle andere hyperlinks, en een upload is een formulierveldje als alle andere formuliervelden. Op het niveau van HTML en HTTP(S) is het gewoon een onderdeel van dezelfde verzameling mogelijkheden die allang gebruikt worden voor dingen waar dezelfde eisen aan gesteld worden.

Ik zeg overigens niet dat hele bestanden op de webserver afhandelen terwijl dat eerst niet werd gedaan geen voeten in de aarde heeft, ik zeg dat alle technieken die je nodig hebt om dat te kunnen doen gewoon in de webgereedschapskist voor webontwikkelaars zitten.

Ik kan me trouwens zomaar voorstellen dat, als Apsera een knip voor zijn neus waard is, het mogelijk is om op de webserver een Aspera-API aan te roepen zodat de up- en downloads nog steeds in en uit dat systeem komen en de werkwijze voor medewerkers van de belastingdienst niet of nauwelijks anders hoeft te worden dan hij nu is.

(a) Blijkbaar nooit van Swing of het modernere JavaFX gehoord? Of je weet niet hoe dat goed te gebruiken. Als de user interface er niet uit ziet dan is er blijkbaar van eeen verouderd GUI-framework gebruik gemaakt.
(b) Het is in professionele omgevingen gebruikelijk om de benodigde JRE mee te bundelen, zodat je 'versieverschillen' ondervangt (Java is backwards compatible dus ik weet eigenlijk niet hoe je bij 'benodigde versie' uitkomt).
(c) Er is juist recent zwaar ingezet op de Java EE omgeving en terecht want er is geen bruikbaar alternatief. Het ASP platform is Microsoft (...), loopt achter en is ronduit inferieur.


Lijkt me inderdaad overkill voor deze toepassing.

Belastingdienst heeft een bestands uitwisseldienst die gebruikt wordt.

Leuk voor downloads, maar minder geschikt voor uploads.

Niet de meest stabiele manier om bestanden goed over te krijgen. Maar dit zijn dingen waar je helemaal zelf niet over wilt nadenken.

Weet jij waarvoor deze dienst allemaal gebruikt wordt?

Laten we vooral het wiel iedere keer opnieuw uitvinden voor iedere oplossing en iedere afdeling.
En dan maar hopen dat we geen italiaanse spaghetti infrastrctuur krijgen.

Zonder wat je weet waaraan iets moet voldoen, kun je alleen een bierviltje oplossing bedenken.

Misschien omdat ik een stapje terug doe en niet in technische oplossing denk, en daarom er iets meer van bepaalde keuzes en eigenschappen de relatie kan maken?

Dit bedoel ik dus met beste kapiteins. Weten het altijd beter, zonder dat ze maar weten waaraan een oplossing aan moet voldoen.

Voor jouw file size zeker. Maar er zit veel meer achter waar de meeste helemaal geen kennis en kunde van hebben.

Email... leuk medium, mits het aan komt en slecht te automatiseren.
Niet echt geschikt voor dit soort data.

Jij weet exact waarvoor deze dienst gebruikt wordt bij de belastingdienst?

Jij weet exact waarvoor deze dienst gebruikt wordt bij de belastingdienst?

Is ook een heel goed punt, ik zeg ook niet dat dit de mooiste oplossing is.

Maar ik heb meer omgevingen waarmee je met een speciale VPN client data moet uitwisselen. Ben ik ook meestal niet blij mee.
Ik heb ook applicaties waar speciale drivers geïnstalleerd moeten worden voor smartcards of HASP keys. Ben ik ook niet blij mee.

Dan is de rest eigenlijk niet van belang, want je weet niet waaraan iets moet voldoen. Commentaar leveren is altijd gemakkelijk zonder de verantwoordelijkheid te nemen.
Ook dit zie je steeds vaker. Iedereen weet het beter.

Heb je hier ook een product voor? Want custom code of hand geschreven applicaties zit een organisatie namelijk niet op te wachten.
Het is niet alleen een file/upload systeem. Dit integreert in verschillende belastingdienst applicaties/systemen, waarbij security en traceability van groot belang zijn.
Je wilt niet voor iedere uitwisseling iets nieuws bedenken.

Ik zou zeggen stap naar de belastingdienst toe, en zeg ze dat je "de" oplossing hebt voor deze oplossing.

Maar doe eerst eens een paar stapjes terug en denk eens in een enterprise strategie.

Als dat waar was dan was deze hele methode ook geen oplossing.
Immers men stuurt de URL van het te downloaden bestand apart op dmv een e-mail met een link waar je op moet klikken.
(intypen is een optie omdat deze link erg lang is)

Die downloads bekeken, niet uitgevoerd. Er werden xlsx en pdf aangeboden voor de loon tabellen in vele variaties.
Nergens aspera tegengekomen. Het doen van de aangifte gaat via XBRL en de digikoppeling. Ook daar mis ik het noemen van aspera. Een digiloppeling mag jij overkill noemen. Het is een verplichte open standaard met redenen.

De hele website van de belastingdienst is maatwerk voor de belastingdienst, met koppelingen naar achterliggende systemen, en de belastingdienst heeft al sinds jaar en dag een forse eigen automatiseringsafdeling. Dit valt echt wel binnen de grenzen van wat die horen te kunnen.
De FAQ erover legt uit wat je moet doen als een medewerker het systeem niet kent, dus ik vermoed dat het juist niet diep geïntegreerd is met wat die medewerkers wel kennen maar er los van staat. Maar een webinterface kan prima met verschillende backend-systemen praten, een interface naar het systeem dat ze voor gedeelde bestanden gebruiken moet dan ook haalbaar zijn.
Geweldig idee dan om dat wel te eisen van iedereen met wie die uitwisselingen worden gedaan. Voor al die bedrijven is juist dit iets nieuws, en is de website van de belastingdienst de bekende interface.

Doe ik. Een enterprisestrategie die gebaseerd is op een eigen automatiseringsafdeling en/of een leverancier die al websites heeft gebouwd die aan alle eisen voldoen en die al gekoppeld zijn aan verschillende backend-systemen. Dat zou toch een andere uitkomst op moeten kunnen leveren dan van externe partijen te eisen dat zij zich in bochten gaan wringen om met jou te kunnen praten.

Die enterprisestrategie zou trouwens ook gebaseerd moeten zijn op het beleid dat de overheid over open standaarden heeft. Er moet onder meer gestreefd worden naar interoperabiliteit en leveranciersonafhankelijkheid. Heb je de indruk dat dat hier goed gedaan wordt?
https://www.digitaleoverheid.nl/overzicht-van-alle-onderwerpen/standaardisatie/open-standaarden/

Kennelijk lees je antwoorden niet die je eerder hebt gehad:

Het gaat NIET over bestanden die je tegenkomt als je willekeurig gaat rondneuzen op de belastingdienst site!
Het gaat over bestanden die je van iemand bij de belastingdienst ontvangt na een direct contact met die persoon,
en met betrekking tot een bedrijf. Je krijgt een mail met een link er in en na aanklikken van die link krijg je het
bestand. Alleen niet meteen, daarvoor moet je eerst die Aspera software installeren, anders lukt het niet.