Zorgverzekeraar laat klanten via bank op account inloggen
Zorgverzekeraar ONVZ biedt klanten naast DigiD ook ook de mogelijkheid om via iDIN op hun account in te loggen, een door de banken ontwikkelde inlogdienst. Wanneer een gebruiker op de website van een webwinkel of instelling er voor kiest om zich te identificeren of in te loggen met iDIN, wordt hij doorgestuurd naar de iDIN-pagina van zijn eigen bank.
Nadat de gebruiker bij zijn bank goedkeuring heeft gegeven voor het versturen van persoonsgegevens, stuurt de bank hem weer terug naar de website. In het geval van ONVZ krijgen gebruikers toegang tot hun persoonlijke online omgeving waarmee ze hun zorgadministratie kunnen beheren. Via deze omgeving kunnen gebruikers nota's indienen en declaraties inzien. Ook wordt de huidige stand van het eigen risico weergegeven. In eerste instantie kon er alleen via DigiD worden ingelogd, maar na een pilot is nu ook iDIN als inlogmiddel toegevoegd. Volgens de zorgverzekeraar is het hierdoor minder afhankelijk van één inlogmethode.
Op de vraag welke gegevens de bank aan ONVZ verstrekt laat de verzekeraar het volgende weten: "Banken verstrekken bij activeren éénmalig de persoons- en adresgegevens die bij de bank zijn geregistreerd. Deze gegevens controleert ONVZ met de gegevens in onze backoffice. U doet geen betaling, ONVZ heeft geen inzicht in uw betaalgegevens en de bank heeft geen inzicht in uw gegevens bij ONVZ." Ook de Belastingdienst ondersteunt inloggen via iDIN, maar die blijkt daar nog weinig populair te zijn.
Reacties (21)
Leuk, maar uiteindelijk dezelfde fout als alle andere systemen die de gebruiker als consument neerzetten.
Kijken of hier iemand snapt wat die fout is.
Kijken of hier iemand snapt wat die fout is.
Door Anoniem: Leuk, maar uiteindelijk dezelfde fout als alle andere systemen die de gebruiker als consument neerzetten.
Kijken of hier iemand snapt wat die fout is.
Kijken of hier iemand snapt wat die fout is.
Waarom geeft u niet gewoon kort en goed uw oordeel? Het is hier toch geen puzzelrubriek? Het valt immers niet uit te sluiten dat uw begrip van "de fout" op een misvatting berust.
Door Anoniem:
Oh help, denken is toch weer teveel moeite.Door Anoniem: Leuk, maar uiteindelijk dezelfde fout als alle andere systemen die de gebruiker als consument neerzetten.
Kijken of hier iemand snapt wat die fout is.
Waarom geeft u niet gewoon kort en goed uw oordeel? Het is hier toch geen puzzelrubriek? Het valt immers niet uit te sluiten dat uw begrip van "de fout" op een misvatting berust.Kijken of hier iemand snapt wat die fout is.
23-05-2017, 13:54 door
[Account Verwijderd]
-
Bijgewerkt: 23-05-2017, 13:57
[Verwijderd]
Door Anoniem:
Door Anoniem:
Oh help, denken is toch weer teveel moeite.Door Anoniem: Leuk, maar uiteindelijk dezelfde fout als alle andere systemen die de gebruiker als consument neerzetten.
Kijken of hier iemand snapt wat die fout is.
Waarom geeft u niet gewoon kort en goed uw oordeel? Het is hier toch geen puzzelrubriek? Het valt immers niet uit te sluiten dat uw begrip van "de fout" op een misvatting berust.Kijken of hier iemand snapt wat die fout is.
De gebruiker is toch de consumt (als afnemer van een bepaalde dienst)? Het lijkt een beetje op die internpostings die eindigen met "denk daar maar eens over na!", alsof de berichtenplaatser een magistrale en unieke conclusie heeft getrokken. Geef gewoon aan wat die fout is, zodat iedereen er van kan leren en waar nodig verbeteringen of denkfouten aangegeven kunnen worden.
Door Rinjani:
Voor het Banken verstrekken bij activeren éénmalig de persoons- en adresgegevens die bij de bank zijn geregistreerd. Deze gegevens controleert ONVZ met de gegevens in onze backoffice. is IMHO geen technische noodzaak. (Want de authentication gaat via de site van de bank en voor de authorization bij de verzekeraar kan een andere oplossing worden gebruikt, waarbij persoons- en adresgegevens zelf niet over internet hoeven worden verzonden.)
Door Anoniem: Leuk, maar uiteindelijk dezelfde fout als alle andere systemen die de gebruiker als consument neerzetten.
Kijken of hier iemand snapt wat die fout is.
Kijken of hier iemand snapt wat die fout is.
Voor het Banken verstrekken bij activeren éénmalig de persoons- en adresgegevens die bij de bank zijn geregistreerd. Deze gegevens controleert ONVZ met de gegevens in onze backoffice. is IMHO geen technische noodzaak. (Want de authentication gaat via de site van de bank en voor de authorization bij de verzekeraar kan een andere oplossing worden gebruikt, waarbij persoons- en adresgegevens zelf niet over internet hoeven worden verzonden.)
Hoe koppel je de de verzekeringsklant aan de juiste klant-entiteit van de juiste bank ?
Namen, inlognamen en zelfs naam+geboortedatum zijn bepaald niet uniek - en zelfs niet stabiel.
Mensen die trouwen of scheiden veranderen (soms) van naam. En met het gezeur van de transgenders is zelfs het M/V veld niet bevroren.
Verzekeringsklant wjansen authenticeert wellicht als wgjansen58@rabo bank, niet te verwarren met wim.jansen@abn .
Ik stel me voor de de verzekeraar voor z'n klanten iets van een uniek kenmerk heeft, en daaraan wil koppelen een uniek klant-kenmerk van een bepaalde bank als acceptable authenticatie .
Ergens moet heel goed gecontroleerd worden dat die twee klant-kenmerken op dezelfde persoon slaan .
Het feit dat de persoon het ingetikt op opgelezen of opgeschreven heeft zegt nou niet zo veel . Mensen kunnen letterlijk hun naam verkeerd schrijven - of geven niet hun bank inlog naam maar gmail of digid naam, of de inlog naam van de andere bank dan degene die ze noemen om aan te koppelen of noem maar op.
Ik zie toch even geen ander model dan het vergelijken van naam+geb datum+bsn+adres op het moment van koppelen .
Veel te ingewikkeld. Dat is toch niet meer te onthouden of te overzien, 34 manieren om te betalen en 15 manieren om her en der in te loggen. Elke website z'n eigen inlog- en verificatieprotocol. De menselijke maat is al 20 jaar zoek.
maar na een pilot is nu ook iDIN als inlogmiddel toegevoegd. Volgens de zorgverzekeraar is het hierdoor minder afhankelijk van één inlogmethode.
Het zal wel aan mij liggen maar hoe meer mogelijkheden om een doel te bereiken er zijn, hoe groter de risico's dat bij toeval/per ongeluk aspecten onderling verwisseld worden. Maarrrr.... om het veilig te houden wordt bij drie inlogpogingen (bijvoorbeeld) een verdere poging tot inlog geweigerd.
idin digid blibid, voor mijn part rigid.... we tuimelen steeds verder de digitale afgrond in.
23-05-2017, 20:50 door
[Account Verwijderd]
-
Bijgewerkt: 23-05-2017, 20:51
[Verwijderd]
Ik had niet gedacht hier in een anonieme puzzelrubriek te belanden.
Het is voor mij niet geheel duidelijk wat DIGID deelt met de verzekeraar, maar ik denk dat dat minder is dan wat de bank deelt.. kortom, het lijkt erop dat de ' gebruiker' weer het gratis produkt is. ik bedank vooralsnog voor deze ' service'
Het is voor mij niet geheel duidelijk wat DIGID deelt met de verzekeraar, maar ik denk dat dat minder is dan wat de bank deelt.. kortom, het lijkt erop dat de ' gebruiker' weer het gratis produkt is. ik bedank vooralsnog voor deze ' service'
aah, tof. mijn bank (ik verklap niet dat het de Rabobank is), kan in mijn betaalinfo al zien bij welke verzekeraar ik hoeveel betaal, nu kunnen ze ook nog bijhouden hoe vaak ik inlog bij mijn verzekeraar. Met een beetje hocuspocus bigdata manipulatie weten ze waarschijnlijk ook wat ik declareer en vergoed krijg. Voor Interpolis de verzekeraar onder de Rabo paraplu is dit natuurlijk goud waard. Formeel staat er natuurlijk een ' chinese muur' tussen bank en verzekeraar. Ik maak me sterk dat een muur stand houdt in de cloud. Geen auditor die dat doorheeft
23-05-2017, 22:14 door
karma4
Digid kent je bsn, het is er op gebaseerd. Elke overheidsdienst is gebaseerd op je bsn op de achtergrond.
De digid dienst hoeft alleen iets door te geven dat de autenticatie voor de achterliggende bsn geslaagd is.
Het zelfde geld voor je bank ook die kent je bsn, zelfde verhaal voor de autenticatie.
De bsn is ook het achterliggende gegeven bij de zorgverzekeraar. Het enige wat dan nodig is dat die bsn gebruiker gevalideerd is. Een hash etc en je hebt de basis.
De digid dienst hoeft alleen iets door te geven dat de autenticatie voor de achterliggende bsn geslaagd is.
Het zelfde geld voor je bank ook die kent je bsn, zelfde verhaal voor de autenticatie.
De bsn is ook het achterliggende gegeven bij de zorgverzekeraar. Het enige wat dan nodig is dat die bsn gebruiker gevalideerd is. Een hash etc en je hebt de basis.
Door Anoniem: Veel te ingewikkeld. Dat is toch niet meer te onthouden of te overzien, 34 manieren om te betalen en 15 manieren om her en der in te loggen. Elke website z'n eigen inlog- en verificatieprotocol. De menselijke maat is al 20 jaar zoek.
Je draait je standaard klacht te pas en te onpas af zonder het topic te lezen ?
Dit topic gaat nu juist over een deel oplossing , waarbij NIET elke website z'n eigen inlog/verificatie protocol gebruikt maar de inlog verificatie van een vertrouwde derde partij (digid, of de bank) accepteert.
Eh... Een bank deed toch wat met je geld verkwanselen? Nou, laat ze zich lekker daarmee bezig houden en nergens anders mee.
Door Rinjani:
Mijn punt is dat je die gegevens niet over internet hoeft uit te wisselen. De verzekeraar verwijst naar een inlogpagina bij de bank, waar authenticatie plaatsvindt. Bij succesvolle authenticatie zou je bv. met een afgesproken secure hash functie op de bij de bank bekende persoons- en adresgegevens een hash kunnen berekenen. En dan hoef je alleen die hash over internet uit te wisselen met de verzekeraar. Die daarmee de koppeling naar een specifieke klant kan maken, door dezelfde afgesproken secure hash functie op de bij hen bekende persoons- en adresgegevens toe te passen en hashes te vergelijken.
Door Anoniem: Ik zie toch even geen ander model dan het vergelijken van naam+geb datum+bsn+adres op het moment van koppelen .
Mijn punt is dat je die gegevens niet over internet hoeft uit te wisselen. De verzekeraar verwijst naar een inlogpagina bij de bank, waar authenticatie plaatsvindt. Bij succesvolle authenticatie zou je bv. met een afgesproken secure hash functie op de bij de bank bekende persoons- en adresgegevens een hash kunnen berekenen. En dan hoef je alleen die hash over internet uit te wisselen met de verzekeraar. Die daarmee de koppeling naar een specifieke klant kan maken, door dezelfde afgesproken secure hash functie op de bij hen bekende persoons- en adresgegevens toe te passen en hashes te vergelijken.
Nergens is gezegd dat de eerste uitwisseling "over internet" gaat - daar kan een heel gesloten VPN voor opgetuigd zijn - dat lijkt me ook logisch, en voor het doel prima haalbaar.
Je idee van een hash is aardig, maar gaat mis op de vele manieren waarop naam- en adresgegevens opgeslagen kunnen worden.
Dr J.W. van der Smalstraat 10-4 hoog , vdSmalstr 10 4 h , Johannes van der Smalstraat 10 4H .
Evenzeer voor de naam - omgaan met v/d , Mw. A. 't Schip-Smit (misschien net gescheiden, en wil bij de verzekeraar ABSOLUUT Anneke Smit heten ,geen letter meer van die ex, maar de tennaamstelling bij de bank is nog niet omgezet ).
Om nog maar te zwijgen over de accenten in namen en straatnamen.
Kortom een hash over een stel velden in twee onafhankelijke databases die grosso modo inhoudelijk ongeveer equivalent zijn
gaat het niet worden als vergelijkingsmethode .
Dit soort fuzzy vergelijkingen zijn gewoon erg moeilijk om automatisch goed te doen, met alle randgevallen erom heen.
Gebruiken ze het BSN? Dat is zowel bij bank als zorgverzekeraar bekend en uniek voor de persoon. Digid gebruikt dat toch ook?
Hier wordt veel over verbanden gesproken. Is het bij niemand hier dan al bekend dat er een private partij is die bijna alle overheidsgegevens, zorg gegevens en bank gegevens in beheer heeft: Topicus. Google daar maar eens op.
Dat bedrijf heeft met al zijn databases voor bijna ieder nederlander van de wieg tot de dood de relevante gegevens.
Dat bedrijf heeft met al zijn databases voor bijna ieder nederlander van de wieg tot de dood de relevante gegevens.
Het is niet zo moeilijk om een adres van een naamgenoot bij je bank op te geven. Geboorte datum icm naam is in heel veel gevallen uniek. Helaas weet de zorgverzekeraar niet welke gevallen niet uniek zijn. Als de zorgverzekeraar alleen een idin authenticatie van een (bij de zorgverzekeraar) bekend rekeningnummer accepteert en voor de zekerheid ook nog een brief naar het postadres stuurt, dan heb je een redelijke zekerheid. Ik denk wel dat veel namen lastig te vergelijken zijn (schrijfwijze, buitenlandse letters, naamwisseling etc) dus veel false negatieves. Tenzij de vergelijking heel coulant is, maar dat verhoogd de kans op false positieves.
Prima toch die bsn nummers bij banken zorgverzekeraars en studie. Elke verwisseling is uitgesloten en omdat een bsn iet vervangen kan worden ook in de tijd zekerheid.
Dat is nu net waarvoor dat ding bedacht is.
Topicus ken ik niet ziet er ook niet uit als big data. Logius ken ik wel maar dat is de overheid valt onder bzk. Niet door elkaar gehaald?
Dat is nu net waarvoor dat ding bedacht is.
Topicus ken ik niet ziet er ook niet uit als big data. Logius ken ik wel maar dat is de overheid valt onder bzk. Niet door elkaar gehaald?
Door karma4: Prima toch die bsn nummers bij banken zorgverzekeraars en studie. Elke verwisseling is uitgesloten en omdat een bsn iet vervangen kan worden ook in de tijd zekerheid.
Dat is nu net waarvoor dat ding bedacht is.
Topicus ken ik niet ziet er ook niet uit als big data. Logius ken ik wel maar dat is de overheid valt onder bzk. Niet door elkaar gehaald?
Dat is nu net waarvoor dat ding bedacht is.
Topicus ken ik niet ziet er ook niet uit als big data. Logius ken ik wel maar dat is de overheid valt onder bzk. Niet door elkaar gehaald?
Nee die haal ik niet door elkaar.
Kijk maar eens op www.topicus.nl of www.topicusoverheid.nl of www.topicusfinance.nl of bij 1 van hun producten www.parnassys.nl
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
