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.
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.
Kijken of hier iemand snapt wat die fout is.
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.
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 .
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.
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'
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.
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.
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.
Dat bedrijf heeft met al zijn databases voor bijna ieder nederlander van de wieg tot de dood de relevante gegevens.
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
Deze posting is gelocked. Reageren is niet meer mogelijk.
Information Security Officer (2fte)
Een uitdagende rol waarbij jij, op basis van security, de vertaalslag maakt tussen business en IT en direct bijdraagt aan de veiligheid van informatie binnen de gemeente Almere. Dat is in een notendop waar jij als Information Security Officer mee bezig bent. Interesse gewekt? Door groei van de organisatie zijn we op zoek naar twee nieuwe collega’s.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
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.
