BE1024035B1 - Mobiel authenticatiesysteem - Google Patents

Abstract

Deze uitvinding heeft betrekking op een systeem voor het verstrekken van geauthenticeerde toegang tot internet gesteunde diensten, die merkwaardig is doordat het een verenigd identiteitsbeheersysteem (2) vormt, dat gecentreerd is op de gebruiker (3) om een verenigd identiteitsmiddel (23) te creëren bedoeld voor gebruikers (3) binnen een bepaald gebied, zodat die gebruiker hiermee bij machte is om eenzelfde rekening aan te wenden om zichzelf kenbaar te maken en dit te authenticeren voor verscheidene toepassingen (31, 32, 33, 34; 61) desgevallend uitgaande van verschillende toepassingshouders (63), i.h.b. waarbij een mobiele authenticatie gebruikt wordt.

Description

Mobiel authenticatiesysteem

Onderhavige uitvinding heeft in eerste instantie betrekking op een mobiel authenticatiesysteem.

Mobiele toestellen zijn alomtegenwoordig en ze worden overal en altijd bij zich gedragen. Dit maakt dat mobiele toestellen goede kandidaten zijn om in te schakelen in een 2-factor authenticatiemechanisme. De gebruiker moet immers geen extra toestel meedragen.

Toestanden waarbij een gebruiker in het bezit is van een veelvuldigheid aan paswoorden om een toegang te kunnen hebben tot een grote waaier aan zogenaamde websites is wel bekend om een probleem te vormen voor de gebruiker, doordat het op de duur enigszins moeilijk wordt voor de gebruiker om al die paswoorden passend te onthouden om correct te worden aangewend tegenover een gewenste website. Om hieraan te verhelpen werden een aantal beheersystemen ontwikkeld die een toegang verschaffen tot een veelvuldigheid aan computers via het internet door één enkel authenticatieproces.

Een dergelijk systeem is gekend waarin een zogenaamde single-sign-on gebruiker account bekend als SSO beschreven wordt, evenals een stel websites met beveiligde toegang die gekoppeld zijn met voornoemde SSO gebruikers account, verscheidene gebruikers identificaties ID en paswoordcombinaties die gekoppeld zijn met voornoemd stel van toegangsbeveiligde websites. Een computerprogramma dat geïnstalleerd wordt op een lokale computer is geconfigureerd om de zogenaamde log-in en paswoord bedoeld voor de toegangsbeveiligde websites op voorhand meteen in te vullen.

Ook is een verder systeem gekend waarin een getruste platformmodule verwezen met TPN beschreven is die samenwerkt met een zogenaamde PROXY SSO eenheid en met toegangstoepassingen tot het web om paswoorden te generen, op te slaan en op te zoeken in zogenaamde SSO credentials. Hierin wordt opnieuw hetzelfde probleem aangekaart dat de gebruiker geconfronteerd is met een alsmaar groeiend aantal paswoorden telkens dat hij een toegang wil krijgen tot een nieuwe website of een bepaalde website wil heractiveren.

Bij het steeds toenemen van elektronische transacties en allerhande verrichtingen in het kader van het internet, is het beveiligd gebruik van een passende identificatie hierbij tijdens de verrichtingen op het internet een cruciaal probleem geworden dat aanleiding gaf tot het instellen van internet modellen voor het identiteitsbeheer van de gebruiker die gewoonlijk geregistreerd wordt met een welbepaalde gebruikersnaam en paswoord gebonden aan een bepaald domein, bedoeld om diefstal of zelfs ieder ongeoorloofd gebruik van de identificatie van een derde te bemoeilijken van site tot site. Dergelijke modellen, hier verwezen als toepassingsgerichte identiteitsmodellen, zijn gekenmerkt door een sterke ondersteuning voor domeinbeheer, maar vertonen echter schalings- en flexibiliteit beperkingen van zodra dat deze geconfronteerd zijn met ruimere identiteitsvereisten van internet scenario’s.

Gekende authenticatiesystemen zijn veeleer gericht op toepassingsbasis die het nadeel vertonen om sterke beperkingen in zich te houden, en dit zowel voor gebruikers als voor agenten of dienstverleners van de bedoelde toepassingen. Laatstgenoemden blijven immers opgesloten in één authenticatiemethode, respectievelijk -technologie waartoe zij beperkt zijn. Bovendien hebben zij een toenemende totale eigendomskost TCO aan voorziening, voor het onderhouden van een zogenaamde helpdesk, e.d. Ook hebben laatstgenoemden te kampen met de kwaliteit van de gebruikersgegevens, zoals problemen van dubbel gebruik, valse gegevens, of nog gegevens die niet meer actueel zijn. Daarbij komt nog dat zij slechts weinig of zelfs helemaal geen onderlinge wisselwerking hebben onder de toepassingen, geen kruismarketing of -kost bekend als TCO. Verder moeten zij een onderhoud voorzien voor privacy conformiteit.

Wat de gebruikers betreft, zijn deze dan ergens gedwongen om specifieke authenticatiemiddelen te gebruiken eigen aan de toepassing. Bovendien ondervinden zij moeilijkheden bij het op niveau houden van hun credentials. Evenmin kunnen zij genieten van een meervoudige onderlinge wisselwerking authenticatie/toepassing. Tenslotte vertonen zij een toenemende zorg rond de controle en het beheer van zowel hun identiteit, hun credentials als hun privacy.

In het bijzonder geval van een mobiel toestel heeft dit ook een toetsenbord en scherm dat mogelijk verschillend is van het toetsenbord en scherm waar de hoofdtoepassing op draait. Het gescheiden scherm kan context tonen over hetgeen aan het gebeuren zou moeten zijn op het hoofdscherm. Het wekt vertrouwen door de gebruiker te verzekeren dat het hoofdscherm wel degelijk doet wat het beweert en dat het dus niet om een frauduleuze toepassing gaat.

Het gescheiden toetsenbord zorgt voor een veilige invoer voor de kennisfactor. Gebruikers moeten dus niet het toetsenbord gebruiken van het andere, mogelijk niet-vertrouwde, toestel waarop de hoofdtoepassing draait.

De huidige generatie van mobiele toestellen hebben een uitstekende camera aan boord die geschikt is om snel QR codes te kunnen en bovendien hebben ze vaak een permanente Internetverbinding. Beide kunnen gebruikt worden om een heel vlotte en veilige gebruikerservaring te creëren. Het scannen van een QR code zorgt voor snelle en foutloze synchronisatie van de hoofdtoepassing en de mobiele toepassing.

In andere 2-factor authenticatiemethoden wordt de bezitfactor vaak geïmplementeerd door een zogenaamd “veilig element” -zoals een smart card bijvoorbeeld- dat enkel kan ontsloten worden door de kennisfactor, vaak een PIN code. De bezitfactor bij de mobiele authenticatiemethode volgens de uitvinding daarentegen is volledig in software geïmplementeerd omdat zo’n veilige elementen niet wijd verspreid zijn in de huidige mobiele toestellen.

Het doel van deze uitvinding bestaat erin om bovenvermelde nadelen, resp. problemen op te lossen op een meer gesofistikeerde manier die gesteund is op een innoverende combinatie van een aantal elementen, met als resultaat een krachtiger systeem dankzij hetwelk vrij praktische en vernufte toepassingen bij het gebruik van de internet mogelijkheden bewerkstelligd worden dankzij een gebruikers gericht identiteitsbeheersysteem.

Aldus wordt volgens deze uitvinding een systeem voorgesteld zoals bepaald in de bijliggende conclusies, met name in de hoofdconclusie waarbij samengevat de gelinkte mobiele authenticatiemethode volgens de uitvinding een 2-factor authenticatie implementeert. Het is gebaseerd op zowel een kennis- als bezitfactor. Het gebruikt QR codes en een 2-phase commit mechanisme om een veilige, stabiele en vlotte gebruikerservaring te creëren.

Een veilig element kan niet gekopieerd worden binnen redelijke, betaalbare grenzen. De gelinkte bezitfactor volgens de uitvinding daarentegen kan gekopieerd worden door vijandige code die op het mobiele toestel draaien of door onveilige backup procedures. Om het verlies van deze bescherming te compenseren is het gelinkte authenticatiemechanisme volgens de uitvinding zo gebouwd dat het kan detecteren of er 2 kopijen van dezelfde mobiele registratie actief zijn en actie neemt indien dit het geval zou zijn.

De hierbij toegepaste gebruikerservaring bestaat uit 2 grote stappen omvattende het scannen van een zogenaamde QR tag en het bevestigen van de context door een PIN code in te geven.

Het proces in hetwelk de gebruiker zijn mobiele toestel aan gebruikersaccount koppelt noemt men het registratieproces. Aldus bestaat de registratie in de volgende stappen: - de gebruiker is aangemeld of werd aangemaakt door een ander vertrouwd proces - de gebruiker installeert de linklD applicatie op zijn mobiele toestel □

- het systeem toont een QR code aan de gebruikerD - de gebruiker scant de QR code - de gebruiker verifieert de context die nu wordt getoond door zijn mobiele toestel

- de gebruiker kiest en bevestigd zijn PIN codeD - het systeem koppelt het mobiele toestel aan de gebruikersaccount.

Wat de hierop aansluitende authenticatie betreft tracht het systeem tijdens het authenticatieproces de persoon die toegang probeert te krijgen te identificeren en te authentiseren als volgt : - de gebruiker probeert toegang te krijgen tot een toepassing! - het systeem toont een QR code aan de onbekende gebruiker! - de gebruiker scant de QR code! - de gebruiker verifieert de context die nu wordt getoond door zijn mobiele toestel - de gebruiker voert zijn PIN code in - het systeem geeft de gebruiker toegang tot de toepassing.

De voorgestelde oplossing volgens de uitvinding met name gesteund op een algoritme bestaat uit een mobiele toepassing en een servertoepassing. De gebruiker heeft een mobiel toestel met daarop de mobiele toepassing en staat in contact met de servertoepassing via een ander scherm, zoals de browser op zijn PC bijvoorbeeld.

Zowel de mobiele toepassing als de servertoepassing hebben een persistente staat. De staat van beide toepassingen verandert tijdens de interactie tussen de mobiele toepassing en de server- toepassing. Hiernavolgend zijn deze interacties en hun invloed op de staat van beide toepassingen uiteengezet.

Bij voornoemde persistente staat is de staat van de mobiele toepassing vrij simpel. Het bevat 2 zaken:

De registatielD, dit is een DUID die wordt aangemaakt tijdens de registratie. Het is de link tussen het geregistreerde mobiele toestel en de gebruikersaccount op de servertoepassing; en De OTP, dit is een UUID die dienst doet als een eenmalig wachtwoord om dit mobiel toestel aan te melden bij de servertoepassing. Het kan slechts één maal worden gebruikt.

De staat van de servertoepassing bestaat in registraties en sessies. Een registratie bevat volgende velden voornoemd RegistratielD. Dit refereert naar een voorgenoemd geregistreerd mobiel toestel; een PIN, dit is een 4-cijferig getal. Het wordt gekozen door de gebruiker tijdens de registratie; OTP1 als eerste kandidaat-OTP zoals die mogelijk in de mobiele toepassing is opgeslagen; OTP2 als tweede kandidaat-OTP zoals die mogelijk in de mobiele toepassing is opgeslagen;

Teller, is een waarde die het aantal opeenvolgende mislukte authenticatiepogingen door een foute PIN telt;

Geblokkeerd, wat aanduidt of een registratie geblokkeerd is en dus niet kan worden gebruikt voor authenticatie;

Geactiveerd, waarbij dit veld aanduidt of een registratie volledig is afgewerkt;!

Toestelnaam, wat een leesbare naam is van het registreerde toestel. Deze naam wordt getoond tijdens het beheer van een gebruikérsaccount;

Huidige sessie, wat de SessielD is van de huidige authenticatie- of registratiesessie voor deze mobiele registratie.

De sessie van de servertoepassing bevat: QRhash, wat een waarde is die de zogenaamde hash is van de QR tag die werd gegenereerd voor deze sessie;

SessielD, wat een referentie is naar deze sessie die wordt gebruikt tijdens client/servercommunicatie en in de registratiedata;

Status, wat een veld is dat vertelt of de sessie succesvol werd beëindigd.DStart tijdstip Dit vertelt wanneer de sessie werd gestart; het wordt gebruikt om oude sessies te laten vervallen;

RegistratielD wat de sessie linkt aan een specifieke registratie.

De registratie begint met een gebruiker die reeds geauthentiseerd is door de servertoepassing door middel van een voldoende vertrouwd proces. Deze authenticatie stelt de gebruiker in staat om het registratieproces op de servertoepassing op te starten. De volgende secties tonen wat er gebeurt op de client- en serverzijde. Figuur 1 toont een diagram van het complete registratieproces.

Een QR code wordt door de server gegenereerd. Deze QR code is een geëncodeerde URL die als volgt gedefinieerd is: URL = <urlhandler>://reg/<versie>/<RegistratielD>/<context> QR = encode(URL).

De URLhandler is een string die ervoor zorgt dat deze URL zal worden geopend door de mobiele zogenaamde linkID toepassing volgens de uitvinding in het geval de QR werd gescand door een algemene QR scanner.

De letterlijke reg string vertelt de mobiele toepassing dat het over een registratieproces gaat i.p.v. een authenticatieproces.

De versie toont de versie van het authenticatieprotocol zodat de cliënt gepast kan reageren indien een QR code van een ander protocol wordt gescand.

Het RegistratielD is een willekeurig getal in het UUID formaat dat zal dienen als identificatie van dit geregistreerde toestel tijdens de verdere registratie of een latere authenticatie.

De context is een tekst die getoond zal worden na het scannen vah de QR code zodat de gebruiker kan verifiëren dat de tag die hij net scande inderdaad overeenkomt met hetgeen hij momenteel ziet op de hoofdtoepassing.

De serverstaat wordt aangepast door het toevoegen van een sessie die eruit ziet als weergegeven in de volgende tabel 1 :

Tabel 1

Terzelfdertijd voegt de server een registratie toe zoals weergegeven in de volgende tabel 2

Tabel 2 waarbij QRhash = securehash(URL). □ Deze securehash functie is een zogenaamde hashing functie die gekend is als SHA1. De SessielD is een willekeurige UUID.

De QR tag wordt nu getoond aan de gebruiker binnen de voorheen geauthentiseerde context. Registratiedata worden ingediend als volgt:

De mobiele toepassing van de gebruiker scant de QR code, decodeert en verwerkt de URL. Alternatief kan de QR code gescand worden door een generieke QR scanner of, indien getoond in een webpagina, aangeklikt worden door de gebruiker. De specifieke URL handier in de QR code zal de linkID mobiele toepassing starten.

Omwille van de letterlijke reg string in de URL start de mobiele toepassing de registratieprocedure. De mobiele toepassing toont de context aan de gebruiker en vraagt de gebruiker om een kennisfactor -meestal een PIN- te kiezen en te bevestigen.

De mobiele toepassing haalt de ReglD uit de URL die zal dienen als identificatie voor dit geregistreerde toestel bij latere contacten met de server.

De mobiele toepassing verbindt dan met de server op een vastgelegde SSL-beveiligde URL en stuurt . volgende gegevens: ReglD, de gekozen PIN en de leesbare naam van het toestel.

De server controleert of de registratie (ReglD) bestaat, nog niet geactiveerd is en of de huidige sessie nog geldig is. Als alles in orde is wordt een OTP (een willekeurig getal in UUID vorm) gecreëerd en opgeslagen in de registratie. De PIN code wordt ook opgeslagen in de registratie zoals weergegeven in de volgende tabel 3:

Tabel 3

De server antwoord met de OTP naar de mobiele toepassing. DNa het ontvangen van de OTP past de mobiele toepassing haar staat aan zoals weergegeven in de volgende tabel 4:

Tabel 4

Het bevestigen van de registratie geschiedt als volgt: de mobiele toepassing stuurt nu de QRhash en de ReglD naar de server. De server valideert of deze hash overeenkomt met de hash van de huidige sessie van de registratie. De server controleert ook of de sessie niet vervallen is. Als alles in orde is past de server de registratie aan zoals weergegeven in de volgende tabel 5:

Tabel 5 alsook de sessie zoals weergegeven in de volgende tabel 6:

Tabel 6

Wat de authenticatie betreft begint ze met een gebruiker die niet gekend is door de servertoepassing.

Deze onbekende gebruiker start het authenticatieproces op de server. De volgende secties tonen wat er opeenvolgend gebeurt in de mobiele toepassing en de servertoepassing. Figuur 2 toont een diagram van het volledige authenticatieproces.

De server genereert een QR code op ongeveer dezelfde manier als tijdens de registratie volgens : URL = <urlhandler>://auth/<vërsie>/<seed>/<context> QR = encode(URL).

De seed is een willekeurige string om de URL en QR verschillend te maken voor elke sessie. De serverstaat wordt aangepast door een sessie toe te voegen. De sessie ziet eruit zoals weergegeven in de volgende tabel 7:

Tabel 7 waarbij QRhash op dezelfde manier wordt gegenereerd als tijdens de registratie. De QR tag wordt nu getoond aan de gebruiker.

Het indienen van authenticatiedata geschiedt dan als volgt: de mobiele toepassing van de gebruiker scant de QR code, decodeert en verwerkt de URL. Zoals tijdens de registratie kan de QR code gescand worden door een generieke QR scanner of kan de URL geopend worden door op de tag te klikken. Omwille van de letterlijke auth string in de URL zal de mobiele toepassing de authenticatieprocedure starten. De mobiele toepassing toont de context aan de gebruiker en vraagt deze om zijn kennisfactor, meestal een PIN, in te geven.

De mobiele toepassing verbindt dan met de server op een vastgelegde SSL-beveiligde URL en stuurt: ReglD, PIN, QRhash en de OTP, waarbij ReglD en OTP uit de lokale staat van de mobiele toepassing worden gehaald.

De server controleert of de sessie (QRhash) bestaat en nog geldig is.DDe server controleert of de registratie (ReglD) geactiveerd en niet geblokkeerd is. Indien geblokkeerd dan stopt de server het authenticatieproces.

De server controleert of de OTP overeenkomt met één van de OTP waarden die opgeslagen zijn in de registratie. Indien geen van OTP waarden overeenkomt met de ingediende waarde, dan wordt de registratie als geblokkeerd gemarkeerd. Dit verhindert elke toekomstige authenticatiepoging tot wanneer de blokkade wordt opgeheven door een voldoende vertrouwde procedure.

De server controleert ook of de PIN code overeenkomt met de PIN code die is opgeslagen in de registratie. Indien de ingediende PIN niet overeenkomt met de opgeslagen PIN code dan verhoogt de server de teller. Als de teller een vooraf bepaalde drempel overschrijdt dan wordt de registratie als geblokkeerd gemarkeerd. De teller wordt terug op 0 gezet bij elke succesvolle authenticatiepoging.

Als alle controles achter de rug zijn genereert de server een nieuwe OTP (OTP’) en slaat deze op in het niet-overeenkomende OTP veld van de registratie. De resulterende serverstaat voor de registratie is dan zoals weergegeven in de volgende tabel 8:

Tabel 8 en die voor de sessie zoals weergegeven in de volgende tabel 9:

Tabel 9

De OTP’ en SessielD waarden worden teruggestuurd naar de mobiele toepassing.

Na het ontvangen van de OTP’ en SessielD waarden past de mobiele toepassing zijn staat aan zoals weergegeven in de volgende tabel 10:

Tabel 10

Ter bevestiging van de authenticatie stuurt de mobiele toepassing vervolgens een laatste bericht naar de server binnen dezelfde sessie. De niet-overeenkomende OTP waarde van de vorige interactie wordt verwijderd. De serverstaat ziet er nu uit zoals weergegeven in de volgende tabel 11 :

Tabel 11

Pas nu markeert de server de sessie als geauthentiseerd zoals weergegeven in de volgende tabel 12:

Tabel 12

Het algoritme ingezet voor het systeem volgens de' uitvinding is zo ontworpen om twee belangrijke neveneffecten te hebben. Het eerste neveneffect is dat indien de staat van de mobiele toepassing succesvol zou worden gekopieerd en worden gebruikt, dan zal bij het eerst volgende gebruik van de originele staat de registratie door de server worden geblokkeerd. Dit is omwille van het feit dat de originele staat een OTP zal bevatten die niet meer op de server aanwezig is. De server blokkeert registraties waarvoor een ongeldige OTP is ingediend.

Een tweede neveneffect is dat de mobiele toepassing nooit gedesynchroniseerd kan raken met de server omwille van netwerkproblemen of problemen met het mobiele toestel. In andere woorden, om het even hoe, waar of wanneer de mobiele toepassing het contact met de server verliest tijdens de authenticatie, de mobiele toepassing zal terug werken nadat de tijdelijke connectieproblemen zijn opgelost. De reden hiervoor is dat de OTP vervangen wordt in een 2-phase commit; de OTP’s worden slechts doorgeschoven nadat de mobiele toepassing zeker de nieuwe OTP heeft opgeslagen.

Hieronder volgen enkele scenario’s waarin de zogenaamde linkID mobiele authenticatie volgens de uitvinding kan worden gebruikt. Elk scenario gaat uit van gebruiker die zich reeds heeft geregistreerd.

Voor een authenticatie op een web site volgt gebruiker de volgende systeemstappen 1. een gebruiker gaat naar een web site 2. de gebruiker klikt op aanmelden 3. de web site toont een QR code 4. de gebruiker scant de QR code met zijn linkID mobiele toepassing 5. de gebruiker herkent de context op zijn mobiele toepassing “aanmelden bij site X” 6. de gebruiker voert zijn PIN code in in de linkID mobiele toepassing 7. de web site leest de succesvolle sessiestatus en laat de gebruiker toe tot het beschermde gedeelte van de web site.

Voor een betaling op een web site volgt gebruiker de volgende Systeemstappen: 1. een gebruiker gaat naar een web site en stelt een bestelling samen 2. de gebruiker klikt op betalen 3. de web site toont een QR code 4. de gebruiker scant de QR code met zijn linkID mobiele toepassing 5. de gebruiker herkent de context op zijn mobiele toepassing “X euro betalen op site Y” 6. de gebruiker voert zijn PIN code in in de linkID mobiele toepassing 7. de web site leest de succesvolle sessiestatus en gebruikt de opgeslagen betaalgegevens van de gebruiker om de bestelling te betalen.

Voor een betaling in een fysieke winkel volgt gebruiker de volgende Systeemstappen: 1. een gebruiker gaat naar een winkelkassa 2. de kassierster klikt op betalen in het kassasysteem 3. het kassasysteem toont een QR code 4. de gebruiker scant de QR code met zijn linkID mobiele toepassing 5. de gebruiker herkent de context op zijn mobiele toepassing “X euro betalen in winkel Y” 6. de gebruiker voert zijn PIN code in in de linkID mobiele toepassing 7. het kassasysteem leest de succesvolle sessiestatus en gebruikt de opgeslagen betaalgegevens van de gebruiker om de bestelling te betalen.

Voor een toegangscontrole tot een evenement volgt gebruiker de volgende Systeemstappen: 1. een gebruiker gaat naar de toegangscontrole 2. het controlesysteem toont een QR code 3. de gebruiker scant de QR code met zijn linkID mobiele toepassing 4. de gebruiker herkent de context op zijn mobiele toepassing “binnengaan op evenement X” 5. de gebruiker voert zijn PIN code in in de linkID mobiele toepassing 6. het controlesysteem leest de succesvolle sessiestatus en verifieert in zijn databank of deze gebruiker inderdaad het recht heeft om binnen te gaan.

Ook wordt volgens deze uitvinding een systeem voorgesteld zoals bepaald in de bijliggende systeemconclusies van hogere orde die gesteund is op een combinatie van validatiemiddelen zoals overeenkomsten vastgelegd tussen de dienstverlener van dit systeem en eigenaars of uitbaters van betrokken internet sites in hun hoedanigheid van leveranciers -zoals banken, shopping sites en zogenaamde utility bedrijven- die tot doel hebben de gebruiker de mogelijkheid tot toegang te verschaffen wanneer hij een internet site bezoekt die aangesloten is op het betrokken centraal beheersysteem aangewezen als “LinkID”, wat onderworpen is aan een aansluiting aan het bedoelde beheersysteem.

Het eigene bij gebruikers gecentreerde elektronische identificatie, is dat de gebruiker in de mogelijkheid gesteld wordt om één ID te gebruiken die zowel transparant als flexiebei kan zijn, in de plaats van meerdere koppels gebruikersnaam/paswoorden te moeten gebruiken om zich in de gewenste websites te kunnen laten registreren. Dit biedt immers het groot voordeel dat deze bewerkingen dan ook veel vlotter worden en het risico op vergetelheid of vergissing tot een minimum herleid.wordt. Gebruikers gerichte elektronische ID modellen worden veeleer toegespitst op de gebruiker zelf, en niet rond een directory. Dit vergt evenwel geïdentificeerde transacties tussen gebruikers enerzijds en zogenaamde agenten van de websites anderzijds die dan ook controleerbare gegevens aanwenden, waardoor beter traceerbare verrichtingen verschaft worden. Dit gebruikers gecentreerd model berust op de zorg om de gebruikers een controlemiddel te geven over de manier waarop hun identiteitsgegevens doorgegeven worden aan dienstverleners of agenten, waarbij deze bovendien de gebruikers toelaten om een flexibele wisselwerking te hebben met een grote verscheidenheid aan diensten.

Tegenover bovenvermelde nadelen van de bekende stand der techniek biedt het zogenaamde gelinkte identiteitsbeheersysteem volgens de uitvinding dat gecentreerd is op de gebruiker geen enkel van de hierboven omschreven beperkingen van de tóepassingsgecentreerde modellen van beheersystemen. In de plaats hiervan opent dit nieuwe dienstmogelijkheden voor de applicatiehouders of -uitbaters en biedt een gebruikersvriendelijke toegang tot waardevollere toepassingen in hoofde van de gebruikers.

Voor de agenten of toepassingsaanbieders betekent dit dat zij verscheidene, zowel huidige als toekomstige authenticatiemethoden, respectievelijk -technologieën kunnen gebruiken tegen een beduidend lagere TCO kost. Ook voorzien zij geen investering in infrastructuur of uitrustingen. Verder genieten zij van een verhoogde kwaliteit van de gebruikersgegevens, met name eliminatie van dubbel gebruik, geactualiseerde correctie der gegevens en dergelijke. Bovendien is er een volkomen onderlinge wisselwerking der attributen onderling, met inbegrip van kruismarketing en kruisverkoop met als voordeel dat er een groter aantal gebruikers on lijn zijn met meer werkzaamheid. De vertrouwelijkheidsvereisten worden perfect onderhouden en nageleefd. Ook is er een schaalvaardigheid voorhanden, evenals een ingebouwde helpdesk en auditing.

Wat de gebruikers betreft, hebben zij een gemakkelijkere en ook betrouwbaardere toegang tot on-lijn toepassingen met inbegrip van betalingsverrichtingen die gebruik maken van authenticatiemiddelen naar hun keuze. Bovendien beschikken zij over een bedrijfzekere en eenvoudige multi authenticatie/toepassings wisselwerking onderling. Tenslotte genieten zij nog van een volle controle en eigen beheer van zowel hun identiteit, credentials en vertrouwlijkheid.

Volgens een voordelige uitvoeringsvorm van de uitvinding kunnen uiteenlopende authenticatiemiddelen worden aangewend zoals een kaartlezer of een mobiele telefoon om de toegang tot voornoemde internet site aangesloten op het beheersysteem volgens de uitvinding te bewerkstelligen. Hiermee verschaft dit systeem een uiterst bedrijfszekere dienst die een flexibele en sterke authenticatie biedt met meerdere middelen, evenals de validatie van gegevens en verrichtingen bedoeld voor ondertekening of betalingen. Deze dienstmiddelen die uitsluitend gesteund zijn op standaardmiddelen passen in alle soepelheid met eenieders bestaande en toekomstige on-line toepassingen.

Volgens een bijkomende uitvoeringsvorm van de uitvinding zijn een aantal beheermiddelen voorzien van zogenaamde attributen die bedoeld zijn om het profiel van de gebruiker te bepalen, zoals adres, geboortedatum en geslacht, waarbij beheermiddelen hiervan voorzien zijn in het systeem volgens de uitvinding om voornoemde attributen uit te nemen en op te slaan tijdens het verloop van een routinematig gebruik van de uitvinding. Dankzij het aldus voorgesteld systeem volgens de uitvinding wordt het probleem opgelost bestaande uit de verbeteringswerkwijze van de beveiliging van SSO gebruikers accounts.

Aldus kan een gebruiker een aantal attributen koppelen als een deel van zijn/haar gebruikersprofiel. Dit attribuut kan om het even welk informatie-elèment vormen over de gebruiker. Toegangscontrole wordt vaak uitgevoerd door voornoemde attributen meegedeeld door een gebruiker in verbinding te brengen of te laten afwegen tegenover een stel regels die bepaald zijn door de dienstverlener of agent. In dit opzicht kunnen voornoemde attributen weliswaar op willekeurige wijze bepaald worden, op voorwaarde evenwel dat zij passend en analoog verstaan en geïnterpreteerd worden zowel door de gebruiker als de dienstverlener of agent bij een verrichting.

Aldus vormt het systeem volgens de uitvinding een standaard gesteund beheersysteem voor het beheren van een standaard gesteunde gebruikers gerichte elektronische identiteit en credential.

Het identiteitsgelinkt systeem volgens de uitvinding is een betrouwbaar en beveiligd gebruikers gericht beheersysteem van zijn elektronische identiteit en credential middel, waarmee de gebruikers in volle controle geplaatst worden van hun identiteit en privacy terwijl deze tegelijkertijd ook de mogelijkheid verschaffen aan toepassingsuitbaters, grote merkhouders en lidmaatschappijen om diepere, meer relevante, en uiteindelijk voordeligere relaties op te bouwen met de gebruikers van hun diensten.

Het systeem volgens de uitvinding opent verder ook nog de deur tot veelvuldige toepassingen evenals kruisverkoop en -marketing met vergrote inkomsten. Dezelfde rekening kan immers gebruikt worden voor alle werkzaamheden, gaande van gewoon lidmaatschap tot een forum werkzaamheid en aankopen of toetredingen.

Deze uitvinding heeft eveneens betrekking op een inrichting bedoeld voor het uitvoeren van de desbetreffende werkwijze zoals hierboven uiteengezet, bestaande uit de basis uitvoeringsvorm voor het uitvoeren van de Link-ID werkwijze.

Verdere kenmerken en bijzonderheden zijn bepaald in de desbetreffende bijliggende onderconclusies. Verdere details en bijzonderheden worden nader toegelicht in de hiernavolgende beschrijving dewelke geïllustreerd is met behulp van de bijliggende tekeningen.

Figuur 1 toont een diagram van het complete registratieproces bij een eerste hoofduitvoeringsvorm van het beheersysteem van de uitvinding.

Figuur 2 toont een diagram van het volledige authenticatieproces bij voornoemde basis hoofduitvoeringsvorm van het beheersysteem van de uitvinding.

Figuur 3 toont een blokdiagram van een gangbaar applicatie gericht identiteitsmodel beheersysteem uit de bekende stand der techniek.

Figuur 4 toont een blokdiagram van een gangbaar gebruikers gericht identiteitsmodel volgens een verdere hoofduitvoeringsvorm van het beheersysteem van de uitvinding.

Figuur 5 toont een blokdiagram van een variante van identiteitsmodel uit de bekende stand der techniek. Figuur 6 toont een blokdiagram van een variante van gebruikersgericht identiteitsmodel beheersysteem volgens de uitvinding.

Figuur 7 is een schematische voorstelling van de in het beheersysteem volgens de uitvinding aangewende identiteitscomponenten.

Figuur 8 is een schematische voorstelling van de in het beheersysteem volgens de uitvinding betrokken partijen.

Figuur 9 is een vloeidiagram als schematische weergave van de werking van het beheersysteem volgens de uitvinding.

Figuur 10 toont een blokdiagram van een gangbaar applicatiegericht identiteitsmodel volgens een bijzonder toepassingsvoorbeeld van de uitvinding.

Figuur 11 is een schematische voorstelling van een uitvoeringsvoorbeeld van de werkwijze volgens de uitvinding.

Figuur 12 toont een blokdiagram van een applicatiegericht identiteitsmodel volgens een bijkomend toepassingsvoorbeeld van de uitvinding.

In het algemeen heeft voornoemde verdere uitvoeringsvorm van de uitvinding betrekking op eigen gerichte authenticatiesystemen die zich onderscheiden van de gekende systemen 1 doordat deze laatste gericht zijn op toepassingsbasis met het nadeel om sterke beperkingen in zich te houden, en dit zowel voor gebruikers 3 als voor agenten of dienstverleners van de bedoelde toepassingen, zoals getoond in figuur 3. Hierin is de toestand weergegeven waarbij een gebruiker 3 één bepaalde identiteit 13, 14, 15 bezit voor iedere on-lijn toepassing a, b, c al dan niet uitgebaat door dezelfde houder, waarbij de respectievelijk opgegeven identiteiten 13, 14, 15 in bepaalde gevallen ook verschillend kunnen zijn. Hier zijn dus drie identiteitsvelden 13, 14, 15 te beschouwën.

Hiertegenover biedt het gelinkte identiteitsbeheersysteem 2 volgens de uitvinding die gecentreerd is op de gebruiker 3 getoond in figuur 4 geen enkel van de hierboven omschreven beperkingen van de toepassingsgecentreerde modellen van beheersysteem 1. In de plaats hiervan opent dit nieuwe dienstmogelijkheden voor de applicatiehouders of uitbaters en biedt een gebruikersvriendelijke toegang tot meer waardevolle toepassingen in hoofde van de gebruikers 3.

Het beheersysteem 2 volgens de uitvinding vormt een verenigd identiteitsbeheersysteem, dat gecentreerd is op de gebruiker 3 en waarvan het doel erin bestaat om een verenigd identiteitsmiddel 23 te creëren bedoeld voor gebruikers binnen een bepaald gewest of industrie. Hiermee is die gebruiker bij machte om dezelfde rekening aan te wenden teneinde zichzelf kenbaar te maken en dit te authenticeren voor verscheidene toepassingen a, b, c, waarbij deze toepassingen kunnen uitgaan van verschillende toepassingshouders. Dit is schematisch weergegeven in figuur 4 met verwijzing naar de schematische weergave van de huidige toestand weergegeven in figuur 3.

In het bijkomend voorbeeld weergegeven in figuur 5, zijn toepassingen 31 en 32 uitgebaat door dezelfde houder AA, waarbij deze dan eenzelfde identiteit 35 gemeen kunnen hebben. Hierin bezit de gebruiker 30 één bepaalde identiteit 35, 36, 37 voor iedere on-lijn toepassing 31, 32, 33, 34 ateonderlijk, al dan niet uitgebaat door dezelfde houder AA, resp. BB, waarbij de respectievelijk opgegeven identiteiten 35, 36, 37 onderling verschillend kunnen zijn. Wat er ook van zij, is met dit voorbeeld een minimum van drie identiteitsvelden 35, 36 en 37 te beschouwen.

Welnu biedt het gebruikersgecentreerd beheermiddel L volgens de uitvinding een vereenvoudiging van het bestaande systeem door een verenigd identiteitsveld 40 te bieden dat zodoende aangewend kan worden voor voornoemde toepassingen 31, 32, 33, 34 tegelijk die bovendien ook uitgebaat kunnen worden door meerdere voornoemde toepassingshouders AA, resp. BB zoals getoond in figuur 4.

Aldus kan de hoofduitvoeringsvorm van de uitvinding bepaald worden als een beheersysteem L van de identiteitsvelden 40 van een gebruiker 3 die vereenzelvigd is door één globaal verenigde identiteit 40 wat hij moet inbrengen om toegang te kunnen hebben tot zijn gewenste toepassingen 31, 32, 33, 34 die uitgebaat worden door agenten AA, BB, die merkwaardig is doordat dit beheersysteem 2 gericht is op de gebruiker 3 waarbij laatstgenoemde toegang kan krijgen tot alle voornoemde toepassingen 31, 32, 33, 34 t * die onderling verschillend zijn en dit via één enkel identiteitsveld 40 dat voornoemde gebruiker eenduidig identificeert.

Het voordeel hiervan is duidelijk dat aldus een globaal verenigd identiteitsveld 40 bekomen wordt dankzij het systeem 2 volgens de uitvinding. Hierbij optredende identiteitsbestanddelen 51, 52, 53, 54 komen tussen in de verenigde identiteit 40 die door dit systeem 2 gecreëerd wordt en bestaan uit vier verschillende componenten die allen verbonden worden via het kernelement L volgens de uitvinding, wat schematisch weergegeven is in figuur 7.

De eerste component bestaat in zogenaamde attributen 52, bestaande. in stukken gegevens die toegewezen zijn aan de fysische persoon die de desbetreffende identiteit bezit in zijn hoedanigheid van gebruiker 3, zoals naam, leeftijd, geslacht, plaats, e.d. Een verdere component bestaat in abonnementen 51 die bepalen in welke toepassingen 31, 32, 33, 34 de desbetreffende identiteit 40 gebruikt kan worden. Deze toetredingen 51 vormen de link tussen een toepassing en een identiteit. Deze regelen eveneens de legale en vertrouwelijkheidvoldoening tussen een gebruiker en een toepassing die laatstgenoemde wenst te richten.

Verder is er de component der authenticatiemiddelen 53 die bedoeld zijn om geregistreerd en aangewend te worden door een gebruiker 3 om zichzelf te authenticeren. Hierbij kan één bepaalde identiteit 40 meerdere authenticatiemiddelen geregistreerd hebben en voorbeelden hiervan zijn het duo gebruikersnaam met paswoord, identiteitskaart, een klassieke creditkaart, een mobiele telefoon, e.a.

Tenslotte de historiek component 54 waarin de gebruiker 3 een spoor kan overhouden van alle handelingen rond zijn identiteit 40.

Het beheersysteem 2 kan de uniciteit van de gebruiker 3 garanderen door middel van zijn devices 53, met dien verstande dat de kern L niet zal toelaten dat een fysische device gebruikt wordt voor twee verschillende rekeningen, wat de identiteiten in dit beheersysteem 2 bijzonder sterk maakt.

Attributen 52 vormen de substantie van de identiteit 40 van de gebruiker 3, en maken van de gebruiker wat hij uiteindelijk is. De essentie bij attributen bestaan in hun herhaald gebruik tussen verschillende applicaties 31, 32, 33, 34 in, waarbij de gebruiker op ieder ogenblik kan nagaan welke applicatie toegang geeft tot welk attribuut.

Attributen 52 bezitten bepaalde datatypes, zoals bijvoorbeeld Boolse of zogenaamde string karakters, en kunnen met enkelvoudige of ook meervoudige waarden gekoppeld zijn. De attributen kunnen eveneens worden samengesteld om nieuwe datatypes te vormen, zoals bijvoorbeeld een straat gecombineerd met een stad vormen samen het adres. Er valt op te merken dat attributen niet hard gecodeerd zijn maar toegevoegd kunnen worden door de operator op verzoek van zijn klanten, t.w. de applicatiehouders.

In de algemene opbouw van het systeem 2 is er het merkwaardige kernelement L hiervan dat een centrale plaats inneemt hierin, waarbij dit communiceert met verscheidene partijen die als volgt bepaald worden, zoals weergegeven in de figuur 8. Eindgebruikers 3 zijn gevormd door fysische personen die een rekening bezitten en die applicaties 61 willen gebruiken die gekoppeld zijn aan de kern L van het beheersysteem 2. De eindgebruikers zijn in wisselwerking met de systeemkern L door middel van een interface 62, bijvoorbeeld een web interface, waarbij integratie ook kan met niet web systemen.

Een verdere partij is gevormd door de applicaties 61 die bedoeld.zijn om 'functies te vervullen bestaande in bepaalde diensten die aan voornoemde eindgebruikers 3 geboden zijn. Qm hun gebruikers 3 te kunnen identificeren maken zij dan gebruik van voornoemde kern L. Om met de kern L te communiceren, maken zij gebruik van webdiensten 62.

Daarbij komen nog applicatiehouders of -uitbaters 63 die voornoemde applicaties in bezit hebben en uitbaten. Het zijn zij die de effectieve klanten zijn van een zogenaamde kemoperator 64. Zij treden in wisselwerking met de kern L door middel van een webapplicatie die statistieken en boekhouding verschaft over de applicaties die ze bezitten.

Verder zijn er ook nog de operatoren 65 die de systeemsoftware beheren in zogenaamde datacenters en die de verschillende systeemfuncties en -diensten verkopen aan voornoemde applicatiehouders 63. Zij werken hierbij samen met voornoemde applicatiehouders om hun applicaties 61 te laten aansluiten op het beheersysteem L.

Tenslotte zijn er ook nog de device aflevers die de nodige authenticatiemiddelen 53 afleveren aan de gebruikers 3. Deze kunnen hun device 53 laten dragen door het beheersysteem 2 waaronder het wel te verstaan is dat dit gevormd is door het zogenaamde LinkID systeem.

Attribuutwaarden kunnen verschaft worden door de gebruiker zelf 3, door een applicatie 61, door een device 53, een systeem op afstand zoals een database, een webservice, LDAP, of ook nog vertrekkende van een berekening van andere attributen. Een attribuut kan ingelezen worden door een applicatie 61 wanneer de volgende condities voldaan zijn, met name dat de operator aan de applicatie toegang geeft tot het attribuut, de gebruiker 3 toelating geeft aan de applicatie 61 om het attribuut te gebruiken en tenslotte dat het attribuut een waarde bezit. Een verder voordelig kenmerk van attributen is dat zij aangeduid kunnen worden als zijnde anoniem. In dat geval kunnen applicaties 61 de specifieke waarde van een attribuut niet inlezen vanuit een bepaalde gebruiker, maar ze zijn wel in staat om statistieken hierover te ontvangen. Zo bijvoorbeeld wanneer locatie als anoniem aangeduid was voor een applicatie, i ' ' kan deze applicatie de locatie van een bepaalde persoon X niet inlezen, maar ze kan wel een statistiek ontvangen van het type “20 % van uw gebruikers wonen in een stad Y”, wat een bijzonder nuttige informatie vormt voor de applicatiehouder 63, en dan ook een troef is van dit beheersysteem L.

Verschillende functies kunnen hierbij door het systeem 2 volgens de uitvinding vervuld worden tegenover de toepassingen, met name eerst een authenticatiefünctie : wanneer een applicatie deze functie oproept, wordt de gebruiker geauthenticeerd door het systeem 2 bij het gebruik van één van zijn geconfigureerde devices 53. Op voorwaarde dat dit met succes verloopt, wordt de applicatie verwittigd en zal op dit ogenblik toegang geven aan de gebruiker 3.

Verder is er de attributenfunctie : een applicatie kan de attributen 52 van de gebruiker opvragen en de waarden hiervan gebruiken in zijn zakelijke bewerkingen. Attributen kunnen hierbij enkel worden ingelezen op voorwaarde dat de gebruiker 3 zijn uitdrukkelijke toestemming hiertoe gegeven heeft.

Ook is er nog de datafunctie waarbij het zo is dat een applicatie 31 attributen 52 kan duwen naar het profiel van de gebruiker 3. In dat geval kunnen deze attributen door andere applicaties 32, 33, 34 gebruikt worden, op voorwaarde dat dit toegestaan wordt door de gebruiker en de afleverende applicatie.

Voor de eindgebruiker zijn de voordelen bij het gebruik van het beheersysteem 2 een merkwaardige versterking van zijn rekeningen, de functies zijn de attributen en ook nog een sterkere controle over zijn identiteit 40, zowel gezien vanuit een beheer-, vertrouwelijkheid- en zekerheidsstandpunten.

In hoofde van die applicatie, meer bepaald de houder 63 ervan, zijn de voordelen in hoofdzaak device zelfstandigheid, sterkere identiteiten met hogere kwaliteitsprofielen, vereenvoudigde registratie en gebruikersbeheer, vereenvoudigde legale en vertrouwelijkheids compliance. Dit laat verder ook nog een nieuw gebruik toe van de partner van de gebruiker van de applicatie. Bovendien laat dit eveneens een verlaging toe van de toegangsdrempel tot de applicatie. Verder onderbouwt dit marketingschema’s door het inlezen en verschaffen van attributen aan of van partner applicaties.

In het authenticatieproces vindt er een authenticatiestroom 71 plaats die zich voortplant volgens pijlrichting F via een authenticatieweg gevisualiseerd in figuur 9 onder de vorm van een zogenaamde authenticatie pijplijn 70. Om geauthenticeerd te worden, evolueert de gebruiker 3 doorheen verschillende stadia van de stroom 71, waarbij ieder stadium bepaalde waarborgen aflevert aan de agent of customer applicatie. De opeenvolgende stappen van het authenticatieproces worden hiernavolgend uiteengezet.

In een eerste stap verwezen als device selectie A wordt de gebruiker 3 geboden om het authenticatiemiddel 53 uit te kiezen die hij wenst te gebruiken voor authenticatie doeleinden. Op deze manier kan de gebruiker dit middel 53 uitkiezen dat hij bij de hand heeft of dat hem het best past op dat ogenblik en op deze plaats. Deze middelselectie A kan echter op verzoek van de applicatie beperkt worden, zo bijvoorbeeld enkel maar sterkere authenticatiemiddelen voor verrichtingen van hoge waarde. Vervolgens vindt de authenticatie plaats B zoals vereist door de desbetreffende device 53.

De volgende stap die deze is van de overeenkomsten C wordt een algemene legale conformiteit bekrachtigd door aan de gebruiker 3 te vragen om zijn akkoord uit te drukken tegenover een gebruiksovereenkomst C. Deze stap komt alleen voor wanneer een nieuwe versie van de gebruiksovereenkomst beschikbaar is.

Verder vraagt het beheersysteem 2 aan de gebruiker 3 of hij akkoord is met de desbetreffende applicatie 61 onder gebruik van bepaalde attributen 52. Dit is dus de confirmatiestàp D der attributen die bepaald worden door de voornoemde operator 65. De kern L vraagt dit slechts één keer, zodat in latere authenticatie gebeurtenissen deze stap D niet zal voorkomen, behalve indien de applicatie attributen vereisten inmiddels gewijzigd zijn.

Tenslotte is er de vergelijkingstap E waar de kern L de gebruikersattributen vergelijkt met de attributen die door de desbetreffende applicatie 61 opgevraagd zijn. Sommige attributen kunnen aangeduid zijn zoals gevraagd. Ingeval de gebruiker over deze attributen echter nog niet beschikt, zal het beheersysteem L eerst vragen aan de gebruiker 3 om de attributen te verschaffen.

De hierboven omschreven authenticatiestroom 70 kan opgenomen worden in verscheidene protocols. Zonder andere melding is dit voor onderhavig beheersysteem het protocol SAML versie 2.0

Wat de authenticatiemiddelen 53 betreft, worden er verscheidene hiervan op een dynamische wijze ondersteund door het beheersysteem 2. Deze elementen 53 worden niet hard gecodeerd in het beheersysteem 2 zodat nieuwe authenticatie-elementen 53 toegevoegd kunnen worden zonder de nood aan een nieuwe software voor het beheersysteem 2. Voor ieder authenticatie-element 53 kent het beheersysteem 2 de locatie van de registratie/update/verwijdering en authenticatie werkstroom 70. Deze werkstromen worden samen bepaald door de beheersysteem operator 65 en de device verlener 64. Deze werkstromen 70 verschillen voor ieder device 53 aangezien er verschillen zijn zowel in technologie als afleveringsprocedures.

De software die deze werkstromen implementeert kunnen ondergebracht en bewerkt worden door de beheersysteem operator 65 of door de Apparatuur Houder 64. Deze keuze hangt af van een aantal factoren zoals veiligheid, kosten en ervaring. Hoe dan ook kan het beheersysteem werkstromen van afstandselementen gebruiken, wat afzonderlijk ontwikkeld en onderhouden kan worden.

Voor een aantal sterk gereglementeerde authenticatie elementen vergt de operator 65 van het beheersysteem 2 niet veel samenwerking van de elementverlener. Een goed voorbeeld hiervan is de grote PKI gebaseerde elektronische identiteitskaart.

Bij wijze van voorbeeld worden hiernavolgend een aantal technische keuzes toegelegd inzake aangewende gereedschappen en middelen, dewelke' evenwel niet als beperkend aanzien mogen worden in het kader van deze aanvraag. Het beheersysteem 2 aangewezen als LinkID wordt geïmplementeerd in JAVA EE 5 en is onafhankelijk van zowel uitbatingssysteem als database.

Dit beheersysteem gebruikt enkel open standaarden, om een maximale compatibiliteit te verzekeren met de klantenapplicaties, met name SOAP, WS-Security, Liberty Alliance; SAML, X.509, e.a. Een JAVA SDK wordt samen ontwikkeld met het beheersysteem om de integratie tussen applicaties en het beheersysteem te vergemakkelijken. Dit betekent echter niet dat applicaties die in andere talen geschreven zijn ter zijde gelaten worden. Aangezien alle communicatie op open standaarden loopt, is het gemakkelijk de SDK uit te breiden tot andere talen, waarbij deze enkel te aanzien is als een.referentie implementatie.

Het beheersysteem volgens de uitvinding was gebouwd op een uiterst flexibele architectuur om dit onafhankelijk te maken van technologie. Alle technologie-afhankelijke onderdelen zijn plug-ins en kunnen uitgebreid worden. De volgende kenmerken zijn op deze manier ontwikkeld en kunnen zodoende uitgebreid worden: onder de authenticatiemiddelen 53, mobiele authenticatie, EMV kaarten, OTP tokens enz. Wat authenticatieprotocols betreft : Cardspace, OpenlD, Windows live ID protocol, Shibolleth.

Op voordelige wijze is de implementatie van een handtekening service eveneens voorzien. Wanneer deze service gebruikt wordt kan een applicatie 61 het beheersysteem 2 vragen om een gebruiker een bepaald document of verrichting te laten ondertekenen met het gebruik van zijn authenticatie-elementen 53. Op deze wijze kan een applicatie het beheersysteem 2 gebruiken om verrichtingen sterk te verzegelen op een technologie-onafhankelijke wijze in perfecte overeenstemming met legale conformiteit.

Wanneer verscheidene LinkID instanties in productie zijn in verscheidene gewesten of industrieën, mogelijks onder bewerking door verschillende operatoren, zal het beheersysteem 2 de mogelijkheid hebben om gebruikers 3 tussen deze instanties te laten evolueren. Gebruikers die aangesloten zijn op één beheersysteem 2 zullen in staat zijn om applicaties te gebruiken die aangesloten zijn op een andere LinkID instantie.

Hiernavolgend een overzicht van de voordelen voortgebracht door het LinkID beheersysteem 2. Dankzij dit systeem kan de agent of de dienstaanbieder meer ondernemen met de gebruikers. In dit opzicht hebben applicatie-aanbieders een behoefte aan beheersystemen die een groter aantal gebruikers betrekken, met meer toepassingen en uiteindelijk meer inkomsten. Dit beheersysteem biedt een betrouwbare authenticatie die al deze vereisten dekt, door aan hun gebruikers een identificatiebeheer te bieden waarin zij vertrouwen kunnen hebben.

Dit geschiedt door diepere en ruimere niveaus van verbintenis te verwerven vanwege zijn gebruiker basis, door vertrouwen en controle te laten toenemen. Ook lidmaatschapsniveaus met gemakkelijk beheer en verrichtingen in één klik bedoeld voor een migratie naar eerste rangsdiensten komen hierbij in aanmerking. Bovendien nemen verkeer en gebruik toe, aangezien gebruikers het gemakkelijker en meer productief vinden om hun gebruik te beheren door middel van één enkele ID die zij beter controleren en kunnen betrouwen.

Een voorbeeld van systeemopstelling is beschreven op basis van de desbetreffende figuur 10 waarin een identiteits service voorgesteld is, met één enkel identiteitsnummer 80 dat bekrachtigd wordt door het systeem 2 volgens de uitvinding. Deze systeemdienst breidt het inwendige identiteitsbeheer van de dienstaanbieder uit tot uitwendige partners. Deze dienst laat de gebruikers toe om vrij te verkeren tussen de agent of dienstverlener en zijn partners toepassingen, en laat verder ook nog eenvoudig delen toe van persoon- en marketing gegevens.

Deze identiteitsnummer dienst elimineert de nood bij bepaalde gebruikers om voordeel te halen uit hun partnerschap tussen dienstverleners. Dit laat eveneens blootstelling toe van dienstverleners applicaties en klantgegevens aan uitwendige partijen.

Toepassingsvoorbeelden die de verdeling van de voordelen of winsten kan verschaffen zijn zogenaamde co-branded diensten vanuit de fysische wereld, of de mogelijkheid voor het delen van vergoeding of trouwheid systemen tussen toepassingen.

Het systeem biedt enkele belangrijke kenmerken ingeval de klanten zich buiten het dienstverlenergebied bevindt, met name op gebied van gebruikersgemak: geen nood meer om zich opnieuw te laten registreren op gebied van vertrouwelijkheidcontrole, kan de klant beslissen over welke data door uitwendige partijen kunnen worden ingelezen op gebied van standaard interfaces voor partner toepassingen; en verder op gebied van eenvoudige en betrouwbare authenticatie, waarbij de klant mag kiezen onder de passende of betrouwbare devices zonder het minste integratieprobleem voor de partner toepassing. Ook kunnen bestaande uitwendige authenticatiemiddelen 53, zoals reeds aangewende elD’s of paren gebruikersnaam/paswoorden 82 resp., opnieuw gebruikt worden 83.

Voornoemd identiteitsysteem wordt aldus het integratiepunt voor uitwendige toepassingen zoals duidelijk voorgesteld in figuur 10 waar dit identiteitsnummer systeem 80 een centrale positie inneemt in de grafiek waarrond alles draait en hiermee als een soort centrale verwerkingseenheid fungeert voor het voorgaande. Dit zou echter zelfs gebruikt kunnen worden voor nieuwe of bestaande toepassingen.

Een sterke authenticatie is dan als het voordeel van het systeem volgens de uitvinding te aanzien, waarbij de toegang tot een rekening van een beheersysteem 2 beschermd kan worden met gebruik van meerdere authenticatiemiddelen 53 die verschillen in complexiteit en betrouwbaarheid. Dit biedt een groot aantal voordelen.

Vooreerst kan een on-lijn toepassing een sterke authenticatie vergen in geval van nood, bijvoorbeeld wanneer deze gesteund js op een verrichtingswaarde. Wanneer een sterke beveiliging echter niet strikt vereist is kunnen meer eenvoudige authenticatiemethodes worden aangewend, m.a.w. kan het betrouwbaarheidsniveau van de authenticatiemiddelen 53 worden aangepast aan de gewenste toepassing 31, 32,...; 61.

Verder kunnen gebruikers 3 een authenticatiemethode aanwenden als back-up voor een verdere methode: in geval één methode onbeschikbaar zou zijn, kan de gebruiker terugvallen op een andere methode dankzij deze eigenschap.

Bovendien is het authenticatiesysteem L volkomen inzetbaar: dit kan immers eender welk voorgesteld authenticatiemechanisme ondersteunen en kan dit dan ook als een authenticatiemethode bieden aan zijn rekeninghouders.

Authenticatiemethodes zijn bijvoorbeeld een mobile telefoon, waarbij verscheidene technologieën beschikbaar zijn, met name SMS, software op de telefoon of PKI op de zogenaamde SIMkaart; met paswoord 82 waarbij het beheersysteem 2 eveneens gewone gebruikersnaam/paswoord combinaties ondersteunt, en dit ofwel als een alleenstaande database of ook gekoppeld tot een bestaande gebruikersbasis; verder ook nog een elektronische identiteitskaart, waarbij het beheersysteem 2 reeds de zogenaamde PKI elektronische identiteitskaarten ondersteunt, dit is tegenwoordig de Belgische elektronische identiteitskaart; en tenslotte nog een zogenaamde digipas 86 waarbij nu al het beheersysteem 2 geïmplementeerde digipass oplossingen ondersteunt. Dit digipass middel 86 is voor gebruikers beschikbaar om alle toepassingen te waarmerken of een beperkt aantal toepassingen, in functie van de politiek die hierbij gevolgd wordt door de uitbater van de met digipass geïnstalleerde basis. Voor de gebruikersinschrijving kunnen klanten op twee manieren een rekening verwerven. Ofwel kunnen zij hun eigen rekening zelf creëren, ofwel wordt een rekening automatisch geconverteerd of gespiegeld vanaf een bestaand identiteitsysteem.

In beide gevallen zal de rekening van het beheersysteem 2 aangroeien met de tijd. De klant, de agent of dienstverlener en zijn partners zullen gegevens inbrengen in de rekening. Ook worden nieuwe authenticatiemiddelen 53 onderweg opgenomen doordat zij beschikbaar worden of dat zij opgeëist worden voor een bepaalde toepassing 61.

Het eindresultaat is dan een bijzonder rijke rekening dat gebruikt kan worden in om het even welke zakelijke toestand zolang alle informatie rond de gebruiker 3 aanwezig is en hij geïdentificeerd kan worden in de mate dat de nieuwe toepassing vraagt De rekening kan dan uitgebreid worden in nieuwe toepassingen zonder uitstel wegens technische interfacing kwesties of gebruikersregistratie hinders.

Kortom is het beheersysteem volgens de uitvinding een doeltreffende manier om de informatiewaarde van het klantenbestand op te vangen en efficiënt opnieuw gebruiken hiervan.

Hiernavolgend is een bijkomende uitbreiding van de functionaliteit van het LinkID beheersysteem volgens de uitvinding aangewezen met L uiteengezet bestaande in de ontwikkeling van een bijkomend vernuft aangewezen als de “rode knop”. Het gaat in wezen om een activeringsmiddel van een bepaalde toepassing als speciaal uitgewerkt formaat dat hiernavolgend beschreven wordt in het licht-van een toepassingsvoorbeeld bij een televisie uitzending.

In dit formaat wordt een LinkID applicatie geïnstalleerd op een mobiel toestel van de gebruiker, wat eender welk mobiele apparatuur kan zijn die in staat is om applicaties van derde partijen te laten lopen. Voorbeelden hiervan zijn een Iphone, een Ipad, androïde apparaten, enz...

Voornoemde applicatie bezit een onderscheidend logo en merk, die een identiteitsverlener identificeert. In de TV wereld kan laatstgenoemde een zender zijn, een kabel/netwerk, een mediagroep, of een adverteerder, e.d.

Wanneer dit logo verschijnt in een LinkID of “L”-geadiveerde televisie uitzending of advertentie, kan de gebruiker dit logo activeren door dit in te drukken op zijn mobiel toestel.

De L-applicatie schiet in gang en downloadt interactieve inhoud met betrekking tot voornoemde advertentie of TV uitzending vanuit een L server, die dan beslist over welke inhoud uit te zenden, gesteund op het tijdstip waarop de interactieve inhoud opgevraagd was.

Deze inhoud omvat gewone multimedia informatiemateriaal, maar eveneens acties die de gebruiker kan ondernemen. Een deel van deze acties en inhoud kan desgevallend exclusief en eigen zijn aan de gebruiker van de L-applicatie en zou, anders gezegd, niet verkregen kunnen worden door bijvoorbeeld te surfen op de zender, het televisiestation of de adverterende website.

Een typisch voorbeeld van exclusieve actie bestaat in een afprijzing die aan de toeschouwer aangeboden wordt.

De exclusieve inhoud of voorrechten kunnen onmiddellijk verbruikt worden via de L-mobiele applicatie, of kunnen ook later verbruikt worden eveneens via de L-mobiele applicatie, of via een website, of nog een verkoopspunt bekend als POS.

Om voornoemde mobiele applicatie te installeren vergt het desbetreffende L-formaat de installatie van een telefoonapplicatie op het telefoontoestel van de gebruiker.

Een marketing campagne moet de gebruikers ervan overtuigen om de applicatie gratis down te loaden vanuit hun mobiele winkel.

Wanneer de LinkID applicatie de eerste keer wordt opgestart, kan de gebruiker een rekening creëren, met inbegrip van een gekozen rekeningnaam en mag hierbij een PIN code optioneel kiezen, allemaal via de mobiele L-applicatie. Het mobiele apparaat wordt gekoppeld aan de zonet gecreëerde rekening, zodat iedere actie die verricht wordt via het mobiele toestel in rekening gebracht wordt.

De synchronisatie van de inhoud geschiedt als volgt : wanneer de gebruiker het bedoelde logo indrukt op zijn mobiel toestel, wordt specifieke inhoud voor de gebruiker afgebeeld erop gelet dat de applicatiehouder in kennis moet zijn van de inhoud die verschijnt wanneer een gebruiker het bedoelde logo indrukt op zijn mobiel toestel, moet de Link-ID applicatie gesynchroniseerd worden met de televisie inhoud. Aangezien er een samenwerking plaatsvindt tussen de producers van de televisie uitzending of adverteerders en het beheersysteem 2, weet men ongeveer wanneer deze beginnen.

De synchronisatie wordt verkregen met het benaderde televisieprogramma en ten minste één van de volgende technieken : de kern L wordt automatisch door de uitzender, het televisiestation of de adverteerder ingelicht wanneer de met de kern geactiveerde programma’s of advertenties beginnen; de kern L detecteert zelf het begin van een televisie uitzending of advertentie die met de kern L geactiveerd is via een rakeling van het scherm; en/of de kern L wordt manueel geconfigureerd door een operator.

In het geval dat er verscheidene televisie uitzendingen of advertenties geactiveerd met de kern L tegelijk voorkomen, zal de kern L eenvoudigweg aan de gebruiker vragen om te kiezen welke inhoud hij wil zien, of welk kanaal hij aan het kijken was.

De opvolging van de inhoud geschiedt als volgt : wanneer een gebruiker een Link-ID applicatie geactiveerd heeft door het indrukken van het hiertoe voorziene selectiemiddel tijdens een geactiveerde of uitgeruste televisie uitzending of -advertentie beschikt hij over de mogelijkheid om een bepaalde inhoud te visualiseren of bepaalde acties te verrichten.

Bijkomend zal de kern de rekening van de gebruiker aanduiden dat hij het desbetreffende selectiemiddel of knop heeft ingedrukt in een bepaalde uitzending of advertentie. Vervolgens kan de gebruiker overgaan naar een website van een producer of adverteerder mits gebruik van zijn PC of mobiel middel en hij kan dan verder inloggen met gebruik van zijn mobiele applicatie.

Daarna kan de website de rekening van de gebruiker vragen en nagaan of hij in de lopende systeemcampagne getreden is. Indien dit zo is, kan de website speciale yoorrechten geven aan de gebruiker.

Tegelijkertijd worden alle vereiste persoonlijke bijzonderheden van de gebruiker gedeeld met de producer/adverteerder. Indien privacy wetgevingen en -regelingen dit vergen, kan deze gegevensdeling zodanig uitgevoerd worden dat de gebruiker dit uitdrukkelijk moet bevestigen.

De gebruiker kan ook nog zijn voordelen opeisen op een verkoopspunt POS op voorwaarde dat de POS software on-line verbonden is. Om zichzelf te identificeren, kan de gebruiker zijn kernsysteem, usemame -door hem gekozen bij de registratie- meedelen aan de POS operator, of kan hij een systeem mobile applicatie een barcode e.d. laten genereren.

Vervolgens kan de POS software deze barcode of TAG scannen en verder gebruiken om de gebruiker in de systeem server te identificeren.

Toepassingsvoorbeelden van de systeemknop zijn in de volgende mogelijke toestanden met name door indrukken van de systeemknop tijdens een advertentie dankzij wat de gebruiker van een exclusieve afprijzing op de webshop van de adverteerder kan genieten.

Verder kan door het verscheidene keren indrukken van de knop de gebruiker een voordeel halen indien hij alle gelijklopende advertenties van een bepaald product bekijkt. Ook laat dit middel toe om tijdens een televisie uitzending een stem uit te brengen in het kader hiervan, bij een polling bvb. Tenslotte kan het indrukken van de systeemknop tijdens een televisie-uitzending extra inhoud geven bekend als een bonus, of nog bijkomende achtergrond informatie over het betrokken voorwerp.

In het kader van een nog verdere uitbreiding van de functionaliteit van het beheersysteem volgens de uitvinding wordt ook nog een verdere ontwikkeling van de mogelijkheden der attributen hiernavolgend uiteengezet en voorgesteld in fig. 12.

I K

Groothandelaar Deal Community case

De hiernavolgende uiteenzetting dient te worden beschouwd als aanzet en input tot het opzetten van een "Groothandelaar Deal” service gebaseerd op de hierboven voorgestelde L oplossing, waar verwezen wordt naar de referentie “Mobile Groothandelaars, de community-operator die ‘deals’ faciliteert”.

Hiernavolgend wordt een beknopt overzicht weergegeven van de mogelijke configuratie, use cases, ontwikkeling alsook werkwijze en planning om tot het opzetten, implementeren en gebruik van de Groothandelaar Deal service te komen. Hierbij hanteren wij het L 4 stappenplan zoals aangegeven. 1. Groothandelaar Deal configuratie

Omwille van de duidelijkheid worden in het principeschema voorgesteld in figuur 10 alleen de belangrijkste functionele verbindingen weergegeven.

Groothandelaar Deal web site

Dit is de Groothandelaar Deal community web site waar users zich ondermeer kunnen registreren, deals en aanbiedingen opzoeken alsook kopen of verwerven.

Van zodra een voucher wordt gekocht op deze site wordt dit doorgegeven aan de L promo web service. Ook crédits die tijdens deze aankoop, of andere acties op deze site, worden verdiend, worden doorgegeven aan de L promo web service.

Partner shop (POS)

Dit is een lokale handelaar in een Point of Sales (POS), een fysieke winkel dus. Deze handelaar kan vouchers en crédits claimen en toekennen via de linkID promo web site, linkID promo web service, bvb. gekoppeld aan het kassasysteem, of via een mobile merchant app.

Partner web site

Dit is een web shop die deelneemt aan Groothandelaar Deal. Deze kan vouchers en crédits claimen en toekennen via de L promo web service of de L promo web site. ook de Mobile Groothandelaars web site wordt als een partner beschouwd die deelneemt aan Groothandelaar deal. linkID is de identity provider die ondermeer instaat voor authenticatie en identificatie van gebruikers in alle andere componenten, beheer van attributen, gebruikers registratie, profile/attribute sharing, logging, auditing,...

linkID Promo attribute provider IF

Dit is de interface tussen de promoties en deals en het L attributen systeem. De attributen die kunnen afgeleid worden uit de “deals” situatie van de gebruiker zijn bijvoorbeeld: “kredietwaardigheid” in termen van deals of crédits en loyalty levels. linkID Promo model

Dit L programma implementeert verschillende vormen van promoties gebaseerd op geven en nemen. Het houdt bij welke partijen kunnen geven en welke partijen kunnen nemen, en hoeveel. Het houdt ook bij hoeveel “crédits” van welke promoties iemand heeft.

Het L promo model is een model voor virtuele cash. Er worden aantallen van bepaalde munteenheden per gebruiker bijgehouden. De munteenheden zijn dan ondermeer vouchers, punten..... Het linkID promo model heeft ook weet van welke munteenheden, t.w. vouchers of punten, van toepassing zijn in welke applicaties, alsook welke toepassingen deze munteenheden kunnen toekennen of consumeren en of daar · interactie of bevestiging van de gebruiker bij nodig is.

In het linkID Promo model kunnen credit systemen worden uitgedrukt zoals universele crédits en lokale crédits, maar ook vouchers voor allerhande deals.

linkID Promo transactie WWW

Deze website heeft een dubbele functie, t.w. Website waar handelaars/merchants in een POS crédits kunnen toekennen indien een gebruiker deze heeft verdiend of claimen indien de gebruiker deze heeft verbruikt. Deze web site kan ook gebruikt worden tijdens een transactie op een webshop. De webshop stuurt de gebruiker dan door naar deze promo site waar dan de “betaling” gebeurt met behulp van crédits.

linkID Promo transactie WS

Deze web service laat toe dat handelaars, web shops en de Groothandelaar Deal web site promo’s kunnen toekennen of claimen vanuit andere systemen. linkID Promo mobile merchant app

Dit is mobile device app die door de handelaar kan gebruikt worden ipv. de promo transactie web site voor het claimen en toekennen van promoties. linkID mobile app

De linkID mobile app heeft meerdere functies: een 2 factor authenticatie voor linkID, selectie en gebruik van vouchers, en tot slot ook een interface naar de Groothandelaar Deal web site.

De 2 factor authenticatie betekent dat de gebruiker zich met behulp van zijn smart Phone kan authentiseren op heel veilige manier bij alle aangesloten online partners alsook op de Groothandelaar Deal web site.

De applicatie wordt ook gebruikt tijdens het claimen van vouchers, de gebruiker selecteert er de vouchers die hij aan de handelaar wil aanbieden. De app is hier dan een native GUI voor de eindgebruiker aspecten van de linkID Promo WS, nl. het gebruiken van vouchers.

Optioneel kan de app ook gebruikt worden om vouchers aan te kopen, de app functioneert dan als een native GUI voor de Groothandelaar Deal web site.

Mobile Groothandelaar web site en API

Mobile Groothandelaar biedt een API aan waardoor Mobile Groothandelaargebruikers makkelijk kunnen ingezet worden in de Groothandelaar Deal community.

Voornamelijk het username/wachtwoord van de Mobile Groothandelaarsite wordt daarbij herbruikt. Daarnaast kan ook het hergebruik van enkele persoonsgegevens de migratie bevorderen. Dit biedt de mogelijkheid aan Mobile Groothandelaars gebruikers om via hun Mobile Groothandelaars UN/PW ook aan te loggen aan de Groothandelaar Deal site.

Echter nieuwe gebruikers van Groothandelaar Deal dienen zich opnieuw te registreren en telkens te authentiseren naar de Mobile Groothandelaars site. Indien de “integratie of interoperabiliteit” tussen de -Mobile Groothandelaars en linkID verder wordt uitgewerkt zoals aangegeven in het document linkID/Mobile Groothandelaars set up, dan kunnen nieuwe gebruikers van Groothandelaar Deal met hun Groothandelaar Deal ID ook aanloggen aan de Mobile Groothandelaarsite, gebruik makende van meerdere authenticatiemiddelen zoals hoger reeds aangegeven.

Payment Service Provider (PSP)

De PSP is de partij die de betaling verzorgt. Indien mogelijk gebruikt ook deze de Groothandela,ar Deal ID van de gebruiker om snel vorige betaalgegevens op te halen en zo in het ideale geval een one click betaling mogelijk te maken. 2. Use Cases

Hierin worden als voorbeeld enkele typische use cases voor het Groothandelaar Deal systeem kort beschreven. Voor elk van deze use cases wordt aangegeven welke onderdelen welke rol vervullen. Deze use cases geven slechts enkele mogelijkheden van gebruik van de Groothandelaar Deal service weer. Verdere mogelijkheden zijn ondermeer het sharen van “crédits” tussen gebruikers, gebruik van promoties tussen aangesloten partners,... De basis use cases voor de Groothandelaar Deal service worden verder vastgelegd en gespecifieerd zoals aangegeven in Werkwijze (stap 1 en 2).

Use Case “Kopen van een restaurant voucher”

Op de Groothandelaar Deal web site wordt een voucher voor een etentje aangeboden tegen een interessante prijs.

De Groothandelaar Deal gebruiker logt in. Daarvoor wordt hij naar de linkID service gestuurd die hem authentiseert met behulp van een mobile device, SMS, elD of wachtwoord. Na de authenticatie wordt de gebruiker teruggestuurd naar de Groothandelaar Deal web site. Aan de hand van de meegestuurde informatie kan de Groothandelaar Deal site de gebruiker herkennen.

De Groothandelaar Deal gebruiker klikt op de “koop nu” optie naast de voucher.

De gebruiker wordt doorgestuurd naar de Payment Service Provider om de betaling te voldoen. De PSP krijgt daarbij ook de linklD identiteit van de gebruiker door. Op basis van deze identiteit haalt de PSP vorige betaalgegevens op en biedt hij de gebruiker de kans om met 1 klik de betaling te bevestigen.

De gebruiker wordt met een betaalbevestiging terug naar de Groothandelaar Deal site gestuurd. De Groothandelaar Deal site contacteert de Promo backend via de Promo transactie WS, en voegt via deze weg 1 restaurant voucher toe aan het account van de gebruiker.

De gebruiker gaat naar het restaurant en geniet van het etentje. Bij de betaling laat hij weten dat hij met een voucher betaalt. De gebruiker neemt zijn mobile device en start de Promo app op. In de promo app zoekt hij de voucher op en klikt op “aanbieden”. Op de LIN.K-Groothandelaar Deal Community smartphone verschijnt een referentie. De gebruiker toont deze referentie aan de restaurant medewerker. De medewerker opent de Promo transactie web site, de Promo mobile merchant app of de Promo transactie WS, via zijn POS, en ziet alle “hangende, actieve” restaurant vouchers, dit zullen er over het algemeen slechts een paar zijn, afkomstig van alle personen die op dat moment in dat restaurant met de voucher willen afrekenen. Hij zoekt de voucher met dezelfde referentie als diegene die wordt getoond door de klant. Hij klikt op “aanvaarden” bij de juiste voucher.

In deze use casé heeft de gebruiker uiteraard ook nog andere mogelijkheden naast zijn mobile om de voucher aan te bieden, bvb. print out.

Use case “Online korting via crédits”

Bij het aankopen van producten bij Groothandelaar Deal partners kan de gebruiker crédits verdienen. Hij kan deze ook verdienen bij aankopen op de Groothandelaar Deal site zelf.

De web shop A die de credit toekent stelt via linklD de identiteit vast van de gebruiker.

De web shop A contacteert de Promo backend via de Promo transactie WS en voegt de crédits toe aan de account van de gebruiker.

De gebruiker gaat naar web shop B en selecteert daar een product. Bij het betalen van het product krijgt de koper de mogelijkheid om gedeeltelijk of volledig via crédits te betalen.

Web shop B stuurt de gebruiker naar de Promo transactie web site. Deze site herkent de gebruiker en vraagt enkel een bevestiging aan de gebruiker voor het gebruik van X crédits.

Na de bevestiging stuurt de Promo transactie web site de gebruiker terug naar web shop B. Het openstaande saldo wordt verder afgerekend via een betaalproces bij de PSP, dat in het ideale geval ook slechts 1 klik omvat.

Claims (40)

1. CONCLUSIES 1 Systeem omvattende een verenigd identiteitsbeheersysteem (2), dat gecentreerd is op de gebruiker (3) om een verenigd identiteitsmiddel (23) te creëren bedoeld voor gebruikers (3) binnen een bepaald gebied, zodat die gebruiker hiermee bij machte is om eenzelfde rekening aan te wenden om zichzelf kenbaar te maken en dit te authenticeren voor verscheidene toepassingen (31, 32, 33, 34; 61) desgevallend uitgaande van verschillende toepassingshouders (63), daardoor gekenmerkt dat het -authenticatieproces een 2-factor authenticatie implemènteert, die gebaseerd is op zowel een kennis- als bezitfactor, met gebruik van specifieke codes en een 2-fase mechanisme om een gebruikerservaring te bewerkstelligen, waarbij het gelinkte authenticatiemechanisme zo gebouwd is dat het kan detecteren of er 2 kopijen van dezelfde mobiele registratie actief zijn en actie neemt indien dit het geval is, waarbij voornoemde toegepaste gebruikerservaring bestaat uit 2 hoofdstappen omvattende het scannen van een zogenaamde QR tag en het bevestigen van de context door een PIN code in te geven.
2. 2. Systeem volgens conclusie 1, daardoor gekenmerkt dat een mobiele authenticatie gebruikt wordt.
3. 3. Systeem volgens één der vorige conclusies, daardoor gekenmerkt dat de gebruiker zijn mobiel toestel aan een gebruikersaccount koppelt volgens een registratieproces waardoor hij zich laat registreren, waarbij de registratie bestaat in de volgende stappen: - de gebruiker is aangemeld of werd aangemaakt door een ander vertrouwd proces - de gebruiker installeert de linklD applicatie op zijn mobiele toestelD - het systeem toont een QR code aan de gebruikerD - de gebruiker scant de QR code - de gebruiker verifieert de context die nu wordt getoond door zijn mobiele toestel - de gebruiker kiest en bevestigd zijn PIN codeü - het systeem koppelt het mobiele toestel aan de gebruikersaccount, waarbij een QR code een geëncodeerde URL is die door de server gegenereerd wordt, met een hierop aansluitende authenticatie, waarbij het systeem tijdens het authenticatieproces de persoon die toegang probeert te krijgen identificeert en authentiseert als volgt : - de gebruiker probeert toegang te krijgen tot een toepassingD - het systeem toont een QR code aan de onbekende gebruikerD - de gebruiker scant de QR codeD - de gebruiker verifieert de context die nu wordt getoond door zijn mobiele toestel - de gebruiker voert zijn PlN code in - het systeem geeft de gebruiker toegang tot de toepassing.
4. 4. Systeem volgens één der vorige conclusies, daardoor gekenmerkt dat het proces gesteund is op een algoritme bestaande uit een mobiele toepassing en een servertoepassing, waarbij de gebruiker over zijn mobiel toestel beschikt met daarop de mobiele toepassing en in contact staat met de servertoepassing via een ander scherm, waarbij zowel de mobiele toepassing als de servertoepassing een persistente staat hebben en de staat van beide toepassingen verandert tijdens de interactie tussen de mobiele toepassing en de servertoepassing.
5. 5. Systeem volgens de vorige conclusie, daardoor gekenmerkt dat voornoemde interacties en hun invloed op de staat van beide toepassingen bepaald worden doordat bij voornoemde persistente staat, . waarbij de staat van de mobiele toepassing de volgende twee items bevat: de registatielD, die aangemaakt wordt tijdens de registratie en de link vormt tussen het geregistreerde mobiele toestel en de gebruikersaccount op de servertoepassing; en de OTP, die dienst doet als een eenmalig wachtwoord om dit mobiel toestel aan te melden bij de servertoepassing, wat slechts één maal wordt gebruikt, en waarbij de staat van.de servertoepassing in registraties en sessies bestaat, waarin een registratie een aantal velden bevat, i.h.b. de volgende: voornoemd RegistratielD, wat refereert naar een voorgenoemd geregistreerd mobiel toestel; een PIN als een n-cijferig getal, dat door de gebruiker tijdens de registratie gekozen wordt; OTP1 als eerste kandidaat-OTP zoals die mogelijk in de mobiele toepassing is opgeslagen; OTP2 als verdere kandidaat-OTP zoals die mogelijk in de mobiele toepassing is opgeslagen; 'Teller” als waarde die het aantal opeenvolgende mislukte authenticatiepogingen door een foute PIN telt; ''Geblokkeerd” wat aanduidt of een registratie geblokkeerd is en dus niet kan worden gebruikt voor authenticatie; “Geactiveerd” waarbij dit veld aanduidt of een registratie volledig is afgewerkt; □ “Toestelnaam”, wat een leesbare naam is van het registreerde toestel, warbij deze naam getoond wordt tijdens het beheer van een gebruikersaccount; “Huidige sessie”, wat de SessielD is van de huidige authenticatie- of registratiesessie voor deze mobiele registratie, waarbij de sessie van de servertoepassing bevat: “QRhash”, wat een waarde is die de zogenaamde hash is van de QR tag die werd gegenereerd voor deze sessie; “SessielD”, wat een referentie is naar deze sessie die wordt gebruikt tijdens client/servercommunicatie en in de registratiedata; “Status”, wat een veld is dat vertelt of de sessie succesvol werd beëindigd; Start tijdstip wat vertelt wanneer de sessie werd gestart, en gebruikt wordt om oude sessies te laten vervallen; “RegistratielD” wat de sessie linkt aan een specifieke registratie; i.h.b. waarbij de registratie begint met een gebruiker die reeds geauthentiseerd is door de servertoepassing door middel van een voldoende vertrouwd proces, en waarbij deze authenticatie de gebruiker in staat stelt om het registratieproces op de servertoepassing op te starten. i ' I
6. 6. Systeem volgens de vorige conclusie, daardoor gekenmerkt dat de Registratiedata worden ingediend waarbij de mobiele toepassing van de gebruiker de QR code scant, de URL decodeert en verwerkt, of dat de QR code gescand wordt door een generieke QR scanner of, jndien getoond in een webpagina, aangeklikt wordt door de gebruiker, waarbij de specifieke URL handier in de QR code de linkID mobiele toepassing doet opstarten, waarbij de mobiele toepassing de registratieprocedure start, en de mobiele toepassing de context toont aan de gebruiker en hem vraagt om een kennisfactor, i.h.b. een PIN, te kiezen en te bevestigen; waarna de registratie bevestigd wordt.
7. 7. Systeem volgens één der vorige conclusies, daardoor gekenmerkt dat.de authenticatie begint met een gebruiker die niet gekend is door de servertoepassing, waarbij deze onbekende gebruiker het authenticatieproces op de server start, waarbij het authenticatieproces in de mobiele toepassing en de servertoepassing verloopt doordat de server een QR code genereert op analoge manier als tijdens de registratie, met het indienen van authenticatiedata als volgt, dat de mobiele toepassing van de gebruiker de QR code scant, decodeert en verwerkt de URL, waarbij de QR code gescand kan wordervdoor een generieke QR scanner of kan de URL geopend worden door op de tag te klikken, waarbij de mobiele toepassing de authenticatieprocedure start, en de mobiele toepassing toont de context aan de gebruiker en vraagt deze om zijn kennisfactor, i.h.b. een PIN, in te geven, waarbij de mobiele toepassing verbindt dan met de server op een vastgelegde beveiligde URL en de server controleert of de sessie bestaat en nog geldig is, de server controleert of de registratie geactiveerd en niet geblokkeerd is, en indien geblokkeerd dan stopt de server het authenticatieproces, waarbij de server verder controleert of de OTP overeenkomt met één van de OTP waarden die opgeslagen zijn in de registratie, waarbij indien geen van OTP waarden overeenkomt met de ingediende waarde, de registratie dan als geblokkeerd gemarkeerd wordt, en ter bevestiging van de authenticatie stuurt de mobiele toepassing vervolgens een laatste bericht naar de server binnen dezelfde sessie.
8. 8. Systeem volgens één der vorige conclusies, daardoor gekenmerkt dat indien de staat van de mobiele toepassing succesvol wordt gekopieerd en gebruikt, dan wordt bij het eerstvolgende gebruik van de originele staat de registratie door de server geblokkeerd, waarbij de server registraties blokkeert waarvoor een ongeldige OTP is ingediend.
9. 9. Systeem volgens één der vorige conclusies, i.h.b. 2 en 3 tot 8, waarin een linkID mobiele authenticatie gebruikt wordt, daardoor gekenmerkt dat de opeenvolgende stappen van het authenticatieproces die een gebruiker volgt voor een authenticatie op een web site de volgende zijn, waarbij de gebruiker zich reeds heeft geregistreerd : - een gebruiker gaat naar een web site - de gebruiker klikt op aanmelden - de web site toont een QR code 1 1 - de gebruiker scant de QR code met zijn linkID mobiele toepassing - de gebruiker herkent de context op zijn mobiele toepassing “aanmelden bij site X” - de gebruiker voert zijn PIN code in in de linkID mobiele toepassing - de web site leest de succesvolle sessiestatus en laat de gebruiker toe tot het beschermde gedeelte van de web site.
10. 10. Systeem volgens één der vorige conclusies, i.h.b. 2 en 3 tot 8, met gebruik van een linkID mobiele authenticatie, daardoor gekenmerkt dat de opeenvolgende stappen van het authenticatieproces die een gebruiker volgt voor een betaling op een web site de vólgende zijn : - een gebruiker gaat naar een web site en stelt een bestelling samen . - de gebruiker klikt op betalen - de web site toont een QR code - de gebruiker scant de QR code met zijn linkID mobiele toepassing - de gebruiker herkent de context op zijn mobiele toepassing “X euro betalen op site Y” - de gebruiker voert zijn PIN code in in de linkID mobiele toepassing ,> - de web site leest de succesvolle sessiestatus en gebruikt de opgeslagen betaalgegevens van de gebruiker om de bestelling te betalen.
11. 11. Systeem volgens één der vorige conclusies, i.h.b. 2 en 3 tot 8 met gebruik van een linkID mobiele authenticatie, daardoor gekenmerkt dat de opeenvolgende stappen van het authenticatieproces die een gebruiker volgt voor een betaling in een fysieke winkel de volgende zijn: - een gebruiker gaat naar een winkelkassa - de kassierster klikt op betalen in het kassasysteem - het kassasysteem toont een QR code - de gebruiker scant de QR code met zijn linkID mobiele toepassing - de gebruiker herkent de context op zijn mobiele toepassing “X euro betalen in winkel Y” - de gebruiker voert zijn PIN code in in de linkID mobiele toepassing - het kassasysteem leest de succesvolle sessiestatus en gebruikt de opgeslagen betaalgegevens van de gebruiker om de bestelling te betalen.
12. 12. Systeem volgens één der vorige conclusies, i.h.b. 2 en 3 tot 8 met gebruik van een linkID mobiele authenticatie, daardoor gekenmerkt dat de opeenvolgende stappen van het authenticatieproces die een gebruiker volgt voor een toegangscontrole tot een evenement site de volgende zijn: - een gebruiker gaat naar de toegangscontrole - het controlesysteem toont een QR code - de gebruiker scant de QR code met zijn linkID mobiele toepassing - de gebruiker herkent de context op zijn mobiele toepassing “binnengaan op evenement X” - de gebruiker voert zijn PIN code in in de linkID mobiele toepassing i ! - het controlesysteem leest de succesvolle sessiestatus en verifieert in zijn databank of deze gebruiker inderdaad het recht heeft om binnen te gaan.
13. 13. Systeem voor het verstrekken van geauthenticeerde toegang tot internet gesteunde diensten, i.h.b. volgens conclusie 1, desgevallend 2 tot 12, daardoor gekenmerkt dat het een verenigd identiteitsbeheersysteem (2) vormt, dat gecentreerd is op de gebruiker (3) om een verenigd identiteitsmiddel (23) te creëren bedoeld voor gebruikers (3) binnen een bepaald gebied, zodat die gebruiker hiermee bij machte is om eenzelfde rekening aan te wenden om zichzelf kenbaar te maken en. dit te authenticeren voor verscheidene toepassingen (31, 32, 33, 34; 61) desgevallend uitgaande van verschillende toepassingshouders (63).
14. 14. Systeem volgens de vorige conclusie, daardoor gekenmerkt dat het gebruikersgecentreerd beheermiddel (2) gesteund is op een combinatie van validatiemiddelen van overeenkomsten vastgelegd tussen een bepaalde dienstverlener en eigenaars vàn de betrokken internet sites in hun hoedanigheid van leveranciers, om de gebruiker (3) toegang te geven aan een internet site die hij bezoekt die onderworpen is aan het bedoelde beheersysteem (L) als hij aangesloten is op het betrokken beheersysteem (L).
15. 15. Systeem volgens één van beide vorige conclusies, daardoor gekenmerkt dat het beheersysteem (2) gericht is op de gebruiker (3) waarbij laatstgenoemde toegang kan krijgen tot alle voornoemde toepassingen (31, 32, 33, 34) die onderling verschillend zijn en dit via één enkel identiteitsveld (40) dat voornoemde gebruiker (3) eenduidig identificeert, waarbij voornoemd gecentreerde gelinkte identiteitsbeheersysteem (2) een verenigd identiteitsveld (40) biedt van de gebruiker (3) dat aangewend wordt voor voornoemde toepassingen (31, 32, 33, 34) tegelijk en die uitgebaat wordt door meerdere toepassingshouders (AA, BB).
16. 16. Systeem volgens één van de conclusies 13 tot 15, daardoor gekenmerkt dat het globaal verenigd identiteitsveld (40) ingebracht wordt door de gebruiker (3), die vereenzelvigd is door voornoemde ene globaal verenigde identiteit (40), om toegang te hebben tot zijn gewenste toepassingen (31, 32, 33, 34) die uitgebaat worden door agenten (AA, BB).
17. 17. Systeem volgens één van de conclusies 13 tot 16, daardoor gekenmerkt dat de verenigde identiteit (40) die door dit systeem (2) gecreëerd wordt uit vier verschillende componenten (51, 52, 53, 54) bestaat die allen verbonden worden via het kernelement (L), waarbij het eerste der voornoemde identiteitsbestanddelen (51, 52, 53, 54) bestaat in zogenaamde attributen (52), bestaande in stukken gegevens die toegewezen zijn aan de fysische persoon die de desbetreffende identiteit bezit in zijn hoedanigheid van gebruiker (3); waarbij een verdere component bestaat in toetredingen (51) die bepalen in welke toepassingen (31, 32, 33, 34) de desbetreffende identiteit (40) gebruikt kan worden en die (51) de link vormen tussen een toepassing (31, 32, 33, 34) en een identiteit (40), en die bepaalde legale en vertrouwelijkheidsvoorschriften regelen tussen een gebruiker (3) en een toepassing (31, 32, 33, 34) die laatstgenoemde wenst te richten; waarbij een nog verdere component bestaat in authenticatiemiddelen (53) om geregistreerd en aangewend te worden door de gebruiker (3) om zichzelf te authenticeren, waarbij één bepaalde identiteit (40) meerdere authenticatiemiddelen (53) geregistreerd hebben en tenslotte de historiek component (54) waarin de gebruiker (3) een spoor overhoudt van alle handelingen rond zijn identiteit (40).
18. 18. Systeem volgens de vorige conclusie, daardoor gekenmerkt dat de verscheidene authenticatiemiddelen (53) worden aangewend om de toegang tót voornoemde internet site aangesloten op het beheersysteem (L) te bewerkstelligen.
19. 19. Systeem volgens één van de conclusies 13 tot 18, daardoor gekenmerkt dat een aantal beheermiddelen voorzien zijn van attributen (52) bedoeld om het profiel van de gebruiker (3) te bepalen, waarbij beheermiddelen hiervan voorzien zijn in het beheersysteem (L) om voornoemde attributen (52) uit te nemen en op te slaan tijdens het verloop van het proces (70).
20. 20. Systeem volgens de vorige conclusie, daardoor gekenmerkt dat het systeem (L) een standaard gesteunde beheersysteem vormt voor het beheren van een standaard gesteunde gebruikers gerichte elektronische identiteit (40).
21. 21. Systeem volgens één van de conclusies 13 tot 20, daardoor gekenmerkt dat het beheersysteem (2) de uniciteit van de gebruiker (3) bewerkstelligt door middel van zijn devices (53), waarbij de kern (L) voorkomt dat een fysische device gebruikt wordt voor twee verschillende rekeningen i.v.m. de identiteiten (40) in dit beheersysteem (2).
22. 22. Systeem volgens één van de vorige conclusies 13 tot 21, daardoor gekenmerkt dat voomoemde attributen (52), die de substantie vormen van de identiteit (40) van de gebruiker (3), herhaaldelijk gebruikt worden tussen verschillende applicaties (31, 32, 33, 34) in, waarbij de gebruiker (3) op ieder ogenblik kan nagaan welke applicatie (31, 32, 33, 34) toegang geeft tot welk attribuut (52).
23. 23. Systeem volgens één van de vorige conclusies 13 tot 22, daardoor gekenmerkt dat voornoemde attributen (52) bepaalde datatypes bezitten, en met enkelvoudige, desgevallend ook meervoudige waarden gekoppeld zijn.
24. 24. Systeem volgens één van de conclusies 13 tot 23, daardoor gekenmerkt dat voornoemde attributen (52) samengesteld worden om nieuwe datatypes te vormen.
25. 25. Systeem volgens één van de conclusies 13 tot 24, daardoor gekenmerkt dat voornoemde attributen (52) toegevoegd worden door de operator (65) op verzoek van zijn klanten, t.w. de applicatiehouders (63).
26. 26. Systeem volgens één van de conclusies 13 tot 25, daardoor gekenmerkt dat in de opbouw van het systeem (2) het kernelement (L) hiervan een centrale plaats inneemt hierin, waarbij dit communiceert met verscheidene partijen die bepaald zijn als eindgebruikers (3) die gevormd zijn door fysische personen die een rekening bezitten en die applicaties (61) willen gebruiken die gekoppeld zijn aan de kern (L) van het beheersysteem (2), waarbij de eindgebruikers (3) in wisselwerking zijn met de systeemkern (L) door middel van een interface (62), waarbij een verdere partij gevormd is door de applicaties (61) die bedoeld zijn om functies te vervullen bestaande in bepaalde diensten die aan voornoemde eindgebruikers (3) geboden zijn, waarbij zij gebruik maken van voornoemde kern (L) om hun gebruikers (3) te identificeren, en van webdiensten (62) om met de kern (L) te communiceren, waarbij een nog verdere partij gevormd is door applicatiehouders of -uitbaters (63) die voornoemde applicaties (61) in bezit hebben en uitbaten, en de effectieve klanten zijn van een kernoperator (64), waarbij zij in wisselwerking treden met de kern (L) door middel van een webapplicatie die informatie verschaft over de applicaties die ze bezitten, waarbij een steeds verdere partij gevormd is door de operatoren (65) die de systeemsoftware beheren in datacenters en die de verschillende systeemfuncties en -diensten verkopen aan voornoemde applicatiehouders (63), en hierbij samenwerken met voornoemde applicatiehouders om hun applicaties (61) te laten aansluiten op het beheersysteem (L) en - tenslotte zijn er de device aflevers die de nodige authenticatiemiddelen (53) afleveren aan de gebruikers (3) die hun device (53) laten dragen door het beheersysteem (2).
27. 27. Systeem volgens één van de conclusies 13 tot 26, daardoor gekenmerkt dat door het systeem (2) verschillende functies vervuld worden tegenover de toepassingen (61), met name eerst een authenticatiefunctie, waarbij ingeval een applicatie deze functie oproept, de gebruiker (3) geauthenticeerd wordt door het systeem (2) bij het gebruik van één van zijn geconfigureerde devices (53), en als dit met succes verloopt, de applicatie verwittigd wordt en op dit ogenblik toegang geeft aan de gebruiker (3); verder een attributenfunctie, waarbij een applicatie de attributen (52) van de gebruiker (3) opvraagt en de waarden hiervan gebruikt in zijn zakelijke bewerkingen, waarbij de attributen enkel worden ingelezen op voorwaarde dat de gebruiker (3) zijn uitdrukkelijke toestemming hiertoe geeft; verder nog de datafunctie, waarbij een applicatie (31) attributen (52) duwt naar het profiel van de gebruiker (3), waarbij dan deze attributen door andere applicaties (32, 33, 34) gebruikt worden, op voorwaarde dat dit toegestaan wordt door de gebruiker en de afleverende applicatie. i 1
28. 28. Systeem voor het verstrekken van geauthenticeerde toegang tot internet gesteunde diensten, i.h.b. volgens één van de vorige conclusies waarin een linkID mobiele authenticatie gebruikt wordt, meer i.h.b. 2 tot 12, daardoor gekenmerkt dat in het authenticatieproces er een authenticatiestroom (71) plaatsvindt die zich voortplant volgens een authenticatieweg (F), waarbij om geauthenticeerd te worden, de gebruiker (3) doorheen verschillende stadia van de stroom (71) evolueert, waarbij ieder stadium bepaalde waarborgen aflevert aan de agent of customer applicatie.
29. 29. Systeem volgens de vorige conclusie, daardoor gekenmerkt dat de opeenvolgende stappen van . het authenticatieproces de volgende zijn: in een eerste stap van device selectie (A) wordt de gebruiker (3) geboden om het authenticatiemiddel (53) uit te kiezen die hij wenst te gebruiken voor authenticatie doeleinden, waarbij de gebruiker dit middel (53) uitkiest en waarbij deze middelselectie (A) op verzoek van de applicatie beperkt worden, vervolgens vindt de authenticatie plaats (B) zoals vereist door de desbetreffende device (53).
30. 30. Systeem volgens de vorige conclusie, daardoor gekenmerkt dat de volgende stap deze is van de overeenkomsten (C) waarbij een legale conformiteit bekrachtigd wordt door aan de gebruiker (3) te vragen om zijn akkoord uit te drukken tegenover een gebruiksovereenkomst (C), enkel wanneer een nieuwe versie van de gebruiksovereenkomst beschikbaar is.
31. 31. Systeem volgens de vorige conclusie, daardoor gekenmerkt dat de volgende stap deze is van de confirmatiestap (D) der attributen (52) die bepaald worden door voornoemde operator (65), waarbij het beheersysteem (2) aan de gebruiker (3) vraagt of hij akkoord is met de desbetreffende applicatie (61) onder gebruik van bepaalde attributen (52), waarbij de kern (L) dit slechts één keer vraagt, zodat in latere authenticatie gebeurtenissen deze stap (D) niet voorkomt, behalve indien de applicatie attributen vereisten inmiddels gewijzigd zijn.
32. 32. Systeem volgens één van de conclusies 29 tot 31, daardoor gekenmerkt dat de laatste stap deze is van de vergelijkingstap (E) waar de kern (L) de gebruikersattributen vergelijkt met de attributen die door de desbetreffende applicatie (61) opgevraagd zijn, waarbij sommige attributen aangeduid zijn zoals gevraagd, waarbij ingeval de gebruiker (3) over deze attributen niet beschikt, het beheersysteem (L) aan de gebruiker (3) eerst vraagt om de attributen te verschaffen.
33. 33. Systeem volgens één van de conclusies 29 tot 32, daardoor gekenmerkt dat de attribuutwaarden verschaft worden door de gebruiker zelf (3), door een applicatie (61), door een device (53), een systeem op afstand zoals een database, of ook nog vertrekkende van een berekening van andere attributen (52).
34. 34. Systeem volgens één van de conclusies 29 tot 33, daardoor gekenmerkt dat een attribuut ingelezen worden door een applicatie (61) wanneer de volgende condities voldaan zijn, met name dat de operator (65) aan de applicatie toegang geeft tot het attribuut, de gebruiker (3) toelating geeft aan de applicatie (61) om het attribuut te gebruiken en tenslotte dat het attribuut een waarde bezit.
35. 35. Systeem volgens één van de conclusies 29 tot 34, daardoor gekenmerkt dat er verscheidene authenticatiemiddelen (53) op een dynamische wijze ondersteund worden door het beheersysteem (2), waarbij nieuwe authenticatie-elementen (53) toegevoegd kunnen worden zonder de nood aan een nieuwe software voor het beheersysteem (2).
36. 36. Systeem volgens één van de conclusies 29 tot 35, daardoor gekenmerkt dat voor ieder authenticatie-element (53) het beheersysteem (2) de locatie kent van de registratie/update/verwijdering en authenticatie werkstroom (70), die samen bepaald worden door de beheersysteem operator (65) en de device verlener (64).
37. 37. Systeem volgens één van de conclusies 29 tot 36, daardoor gekenmerkt dat de implementatie van een handtekening service is voorzien, waarbij een applicatie (61) het beheersysteem (2) kan vragen om een gebruiker (3) een bepaald document of verrichting te laten ondertekenen met het gebruik van zijn authenticatie-elementen (53).
38. 38. Systeem volgens één van de conclusies 29 tot 37, daardoor gekenmerkt dat wanneer verscheidene L-instanties in productie zijn in verscheidene gebieden, mogelijks onder bewerking door verschillende operatoren, het beheersysteem (2) gebruikers (3) tussen deze instanties laat evolueren, waarbij gebruikers die aangesloten zijn op één beheersysteem (2) in staat zijn om applicaties te gebruiken die aangesloten zijn op een andere L-instantie.
39. 39. Systeem volgens één van de conclusies 29 tot 38, daardoor gekenmerkt dat het authenticatiesysteem (L) volkomen inzetbaar is.
40. 40. Systeem volgens één van de conclusies 29 tot 39, daardoor gekenmerkt dat een bijkomende uitbreiding van de functionaliteit van het beheersysteem (L) bestaat in een activeringsmiddel van een bepaalde toepassing als speciaal uitgewerkt formaat waarin een L-applicatie geïnstalleerd wordt op een mobiel toestel van de gebruiker, die in staat is om applicaties van derde partijen te laten lopen, waarbij voornoëmde applicatie een onderscheidend teken bezit, die een identiteitsverlener identificeert, waarbij wanneer dit teken verschijnt in een “L”-geactiveerde element, de gebruiker dit teken kan activeren door dit in te drukken op zijn mobiel toestel, wat de L-applicatie opstart en interactieve inhoud downloadt met betrekking tot voornoemd element.