NL1018494C2 - Methode en systeem voor het door een dienstproces aan een client leveren van een dienst. - Google Patents

Description

Methode en systeem voor het door een dienstproces aan een dient leveren van een dienst

ACHTERGROND

5 De uitvinding heeft betrekking op een methode resp. system voor het door een dienstproces aan een cliënt leveren van een dienst.

Het gebied van de uitvinding is de levering van diensten via computernetwerken.

Authenticatie en autorisatie van clients door servers is in theorie 10 'opgelost', maar in de praktijk is dit een weerbarstig onderwerp vol met voetangels en klemmen. Het resultaat in de praktijk is dat een veilige (=geauthenticeerde en geautoriseerde) dienstverlening nauwelijks voorkomt op internet, en dat het vertrouwen van gebruikers in bestaande diensten klein is.

15 Een veelheid van oorzaken kan hiervoor worden aangewezen, waaronder de volgende: - wanneer een dienst gebruik maakt van het SSL protocol voor het authenticeren van de klant en het beveiligen van de dienstverlening, dan moet het dienstverleningsprotocol door SSL getransporteerd (getu- 20 nneld) kunnen worden. Voor alle protocollen die op UDP zijn gebaseerd geldt dat dit niet kan. Eenvoudige op UDP gebaseerde protocollen zijn DNS (Domain Name Service), TFTP (Trivial File Transfer Protocol), SNMP (Simple Network Management Protocol), Syslog protocol, etc. Komplexere voorbeelden zijn video- en audio streaming (bijv. RealAudio, Real-25 Video), multi-user gaming protocollen, e.d.

- wanneer een dienst gebruik maakt van IPSEC, dan bestaat het volgende probleem. IPSEC zet een beveiligde verbinding op (een 'transport pijp') tussen twee machines (computers, routers, of combinaties daarvan), en dat staat los van de diensten (client/servers) die 30 daarvan gebruik maken. Er kunnen ook meerdere diensten van dezelfde IPSEC pijp gebruik maken. Het gebruiken van de IPSEC authenticatie als authenticatie voor de dienst is vergelijkbaar met dat men de afzender op een ansichtkaart voor echt houdt omdat de postbode zich kan legitimeren. Los daarvan is IPSEC een veel moeilijker protocol dan SSL 35 om te operationaliseren, zowel technisch als vanuit beveiligi ngsoogpunt.

- wanneer gebruik wordt gemaakt van een kombinatie van IPSEC en SSL voor eerdergenoemde doelen, dan wordt de verstuurde data dubbel vercijferd (lx door IPSEC, lx door SSL), hetgeen de transportsnelheid 1018494 -3- drastisch reduceert, en wordt het operationaliseren van de verbinding bemoeilijkt. Voorat voor real-time datatransporten (multimedia diensten) wordt dit al snel onacceptabel.

- als authenticate en autorisatie al gebeuren zijn ze doorgaans 5 vervlochten met een bestaande dienst, hetgeen grotere problemen geeft naarmate deze dienst zelf groter (complexer) is.

DE UITVINDING

De uitvinding beoogt de mogelijkheid te verschaffen om 10 1) bestaande diensten welke weinig of geen authenticiatie/autorisatie doen eenvoudig aan te passen, waarna ze over een sterke authenticatie/autorisatie beschikken, en 2) nieuwe diensten te ontwikkelen waarbij het authenticatie/autorisatie gedeelte gescheiden is van het feitelijke 15 dienstverlenende gedeelte.

De uitvinding omvat herbruikbare componenten voor het implementeren van authenticatie en autorisatie.

De uitvinding lost voornoemde problemen op door verantwoordelijkheden en processen te scheiden. Er wordt een protocol gedefinieerd dat 20 aangeeft hoe deze delen met elkaar communiceren zodanig dat een dienstverlener een geauthenticeerde en geautoriseerde klant zijn dienst kan verlenen.

In een voorkeursuitvoering van de uitvinding kunnen vier processen onderscheiden worden: 25 - een cliënt proces, bijvoorbeeld een standaard browser zoals

Microsoft Internet Explorer, hieronder ook aangeduid met "cliënt". Dit proces zit in het beveiligingsdomein van de dienst-gebruiker.

- een authenticatatie proces. Dit proces zit in het beveiligingsdomein van ofwel de dienstverlener ofwel een Trusted Third Party; 30 - een Dienst Autorisatie Proces (DAP). Dit proces -het eigenlijke autorisatieproces waarin wordt nagegaan of een bepaalde dienst al dan niet aan een bepaalde cliënt kan of mag worden geleverd- zit in het beveiligingsdomein van de dienstverlener.

- een Dienst Proces (DP). Dit proces zit in het beveiligingsdomein van 35 de dienstverlener.

Volgens de uitvinding kan ook een subset (tenminste één) van de 1 01 849 4 ^ -4- processen gebruikt worden. De methode volgens de uitvinding omvat tenminste één van de volgende stappen: a. De cliënt zet een beveiligde sessie -bijvoorbeeld een SSL sessie-op naar een authenticatieproces en stuurt een cliënt identifier 5 -bijvoorbeeld een X.509 Public Key certificaat- en een service request waarin wordt aangegeven welke dienst wordt gevraagd.

b. Het authenticatieproces verifieert de dient identifier en stuurt de geverifieerde cliënt identifier (bij voorkeur) met een “mate-van-zekerheid”-aanduiding betreffende de authenticiteit van die client- 10 identifier, en het service request naar een autorisatieproces; het autorisatieproces weet hiermee (1) welke dienst wordt gevraagd en (2) door wie en (3) heeft (bij voorkeur) een bepaalde mate van zekerheid (bijvoorbeeld aangeduid met klasse I, II of III certificaten) omtrent de identiteit van de cliënt.

15 c. Het autorisatieproces onderzoekt of de in het service request aangegeven dienstverlening aan de dient kan en mag worden geleverd, en zendt het onderzoeksresultaat in de vorm van een geautoriseerd service request, voorzien van een bepaalde geldigheidsperiode, terug naar de authenticatieproces: het geautoriseerde service request vormt 20 de autorisatie om, binnen de geldigheidsperiode, met het leveren van de dienst aan de cliënt te beginnen.

d. Het authenticatieproces genereert een token en associeert dat met de in de vorige stap afgegeven autorisatie (het geautoriseerd service request).

25 e. Het authenticatieproces stuurt vervolgens het adres van het betreffende dienstproces en het token naar de cliënt, bijvoorbeeld door middel van een HTML pagina die als hyperlink dat adres en token omvat, waarbij de browser van de cliënt naar het (hyperlink) adres van het dienstproces wordt ge-"redirect".

30 f. De cliënt treedt (door middel van de hyperlink) in verbinding met het dienstproces en stuurt het van het authenticatieproces ontvangen token (de sessie tussen de cliënt en het verificatieproces kan getermineerd worden).

g. Het dienstproces stuurt het van de cliënt ontvangen token naar het 35 authenticatieproces.

h. Het authenticatieproces haalt het aan het token geassocieerde 1018494 -5- geautoriseerde service request (de "autorisatie") op, controleert of de geldigheidsperiode accoord is, en stuurt vervolgens het geautoriseerde service request naar het dienstproces. Merk op dat deze situatie precies dezelfde is als wanneer er geen authenticate en 5 autorisatie had plaatsgevonden en het cliënt proces rechtstreeks het service request aan het dienstproces had gestuurd. Immers: de sessie tussen cliënt en het dienstproces is gestart door het cliënt proces en het protocol dat gebruikt wordt is hetzelfde protocol dat het dienstproces daar in andere gevallen voor zou hebben gebruikt.

10 i. Het dienstproces levert vervolgens de door de cliënt gevraagde dienst.

Het systeem volgens de uitvinding omvat de middelen waarmee de bovenstaande methode-stappen kunnen worden uitgevoerd.

De onderhavige uitvinding heeft de volgende voordelen: 15 1) De uitvinding maakt gebruik van standaard protocollen.

2) De uitvinding hoeft uitsluitend aan de server-kant (dat wil zeggen daar waar het authenticatieproces, het autorisatieproces en het dienstproces geactiveerd is) te worden geïmplementeerd. Voor de client-kant kunnen gangbare browsers (Microsoft Internet Explorer, 20 Netscape Navigator e.d.) zonder modificaties worden gebruikt.

3) Er is dus ook geen extra support (bijv. helpdesk) nodig voor eindgebruikers.

4) Elke electronische dienst die (nog) geen authenticatie/autorisatie doet, kan met minimale aanpassingen gebruik maken van de uitvinding - 25 ongeacht het protocol dat deze dienst gebruikt.

5) De uitvinding maakt geen gebruik van sessies die door een server worden opgezet, en vereist derhalve (a) geen speciale aanpassingen aan firewalls, en (b) kan ook gebruikt worden wanneer de cliënt in een netwerk zit dat via Netwerk Adres Translatie (NAT) aan het Internet 30 zit.

6) De uitvinding maakt dat business processen en operationele processen eenvoudig gescheiden kunnen worden, terwijl ook de interfaces tussen de verschillende processen zeer eenvoudig zijn. Dit maakt het gemakkelijk om te voorkomen dat een dienst opgezet wordt als 35 een log monolitisch geheel.

101 848 4"! -6-

REFERENCES

- SSL (ftp://ds.internic.net/internet-drafts/draft-freier-ssl-version3 -02.txt): Dit is een internet-draft van 18 november 1996. Het SSLv3 protocol is niet formeel gestandaardiseerd, maar wel een de facto 5 standaard. Het protocol biedt privacy en betrouwbaarheid tussen twee communicerende applicaties (processen). Het staat client/server applicaties toe te communiceren op een manier die is ontworpen om te voorkomen dat derden het berichtenverkeer afluisteren, berichten veranderen, of berichten toevoegen. In de protocol-stack verwacht SSL 10 een betrouwbaar transport protocol (bijv. wel TCP, maar niet UDP) onder zich.

- IPSEC (http://www.ietf.org/rfc/rfc2401.txtl: Het doel van IPSEC is om verschillende security-services aan te bieden voor verkeer op de IP laag, zowel in IPv4 als IPv6 omgevingen. Hoewel IPSEC dus onderdeel 15 van dienst-beveiliging kan zijn. kan het niet een dienst in zijn geheel beveiligen omdat de IPSEC op IP niveau opereert, en de beveiliging van diensten ook op hogere niveaus moet kunnen worden gegarandeerd.

- Gesloten systemen zijn er ook voor authenticatie/autorisatie. Zie 20 bijv. de RABO bank voor electronisch bankieren, het Easy Pay systeem van Shell, Digitale Postzegels van PTT Post e.d. Dit soort systemen hebben het nadeel dat de klant additionele hardware moet hebben voordat ze deze diensten kunnen gebruiken.

25 IMPLEMENTATIE

Een implementatie van de uitvinding wordt voorgesteld door figuur 1, voorstellende een systeem met vier processen, dat wil zeggen, vier hardware/software modules (computers, servers, terminals etc.) waarop die processen draaien en die via een netwerk (zoals het internet) met 30 elkaar in verbinding kunnen treden.

Figuur 1 toont een cliënt proces C, geïmplementeerd door middel van een webbrowsers als MS Internet Explorer etc. op een gebruikers PC, een Client Authenticatie Proces, CAP, geïmplementeerd met behulp van procedures uit standaard libraries, een Dienst Autorisatie Proces, 35 DAP, en een Dienst Proces, DP, die een dienst kan leveren die door de gebruiker, via zijn/haar client C, gewenst wordt.

1 01 84 9 4 ’ -7-

Elk proces valt binnen één security-domain, d.w.z. dat er één persoon of instantie is die het proces beheert en de gevolgen draagt van wat dit proces doet of nalaat. Het proces C valt zo onder het security domain van de gebruiker, de CAP valt onder het security domain van de 5 betreffende dienstenleverancier ("Service Provider") SP of een "Trusted Third Party” terwijl de processen DAP en DP vallen onder het security domain van de dienstenleverancier SP.

Onder 'protocol' wordt hier verstaan een methode om twee (computer) processen met elkaar te laten communiceren. Dit kunnen dus 10 internetprotocollen zijn, maar ook procedure calls (wanneer de processen op dezelfde machine draaien), of andere protocollen.

De getoonde implementatie van de uitvinding gebruikt de volgende communicatie protocollen: - SSL (Secure Sockets Layer Protocol) of TLS (Transport Layer Security 15 protocol). Dit zijn bekende en goed gedocumenteerde protocollen (zie referenties); - DSP (Domain Secure Protocol). Dit is geen bestaand protocol, maar een 'placeholder' naam voor ieder protocol dat hetzij (1) communicatie verzorgt tussen twee processen binnen een 20 enkel security domain, en (2) door de beheerder van dat security domain is bestempeld als 'veilig' voor gebruik binnen dat security domain, hetzij (1) communicatie verzorgt tussen een proces in het security domain van een TTP en een proces in het security domain van de 25 betreffende dienstenleverancier SP, en (2) door beide beheerders van deze security domains wordt bestempeld als 'veilig' voor gebruik tussen deze security domains; - DSP1 een DSP protocol dat wordt gebruikt tussen de processen CAP en DAP; 30 - DSP2 een DSP protocol dat wordt gebruikt tussen de processen CAP en DP.

- AP (Applicatie Protocol). Dit is geen bestaand protocol, maar een ’placeholder1 naam voor het protocol tussen het clientproces C en het DP. Dit protocol dient te voldoen aan de veiligheidseisen (en andere 35 eisen) die de dienstenleverancier SP daaraan stelt.

De procedure verloopt alsvolgt: 1018494 -8- - Een verbinding wordt opgezet tussen proces C en CAP. Deze verbinding gebruikt het SSL of TLS protocol. Het protocol wordt zodanig ingesteld dat bij het opzetten van deze verbinding: (a) C de CAP authenticeert aan de hand van een door de CAP te sturen 5 server certificaat welke is uitgegeven door een bij C bekende partij ("Trusted Third Party"): (b) de CAP een lijst van door de CAP geaccepteerde cliënt certificaat uitgevers naar C stuurt. Voorts heeft de CAP voor elk certificaattype en -uitgever de beschikking over de mate van zekerheid welke de 10 dienstenleverancier SP stelt bij authenticatie van certificaten van dat type en uitgever.

- Het CAP initieert een verbinding tussen het CAP en DAP, gebruikmakend van het DSP1 protocol (zie hierboven).

- C initieert een verbinding tussen C en DP. gebruikmakend van het AP 15 protocol (zie hierboven).

- Een verbinding wordt opgezet tussen proces DP en het CAP. Deze· verbinding gebruikt het DSP2 protocol (zie hierboven). Deze verbinding kan worden opgezet door DP of door het CAP.

De uitvinding vooronderstelt het bestaan van een (electronisch) 20 'contract' tussen gebruikers en dienstenleveranciers SP, waarin staat welke diensten door het DP aan de gebruiker geleverd mogen worden en onder welke condities. Zulke condities kunnen mogelijk eisen stellen aan het soort certificaat dat een client ter authenticatie mag aanbieden, parameters welke de dienst kunnen beïnvloeden, de 25 vergoeding die SP van C verlangt voor het verlenen van de gevraagde dienst, etc.

De genoemde 'service requests' bestaan uit een verzameling dienst-parameters en hebben de vorm van een parameter lijst welke kan worden toegevoegd aan een URL.

30 Waar gesproken wordt over "autorisatie", omvat dit (1) de identiteit van de gebruiker (via de cliënt C) voor welke de autorisatie is bedoeld, (2) een service request voor welke de autorisatie is uitgegeven, (3) een geldigheidsinterval (i.e. een tijdsinterval binnen welke de autorisatie geldig is) en (4) een IP-adres van waaruit om de 35 autorisatie werd gevraagd. Het service request heeft de vorm van een parameter lijst die wordt toegevoegd aan een URL. Voorts heeft de 1018494 -9- autorisatie de eigenschap dat dienstenleverancier SP er in voldoende mate zeker van is dat een cliënt voor wie.deze autorisatie werd gemaakt, in staat is toegang te verkrijgen tot de dienst binnnen het geldigheidsinterval.

5 Het "token" waarover gesproken werd, bestaat uit een rij bits, door de CAP wordt gemaakt aan de hand van een autorisatie, en wel zodanig dat het token de volgende eigenschappen heeft: (a) de CAP kan de autorisatie (welke heeft geleid tot het maken van het token) reproduceren aan de hand van dat token, althans gedurende 10 het tijdsinterval binnen welk de autorisatie geldig is.

(b) het token is geldig zolang de autorisatie geldig is.

(c) de kans dat een geldig token door een derde, partij geraden kan worden is verwaarloosbaar klein (bijvoorbeeld kleiner dan 2'50) (d) er geen twee of meer verschillende (geldige) autorisaties 15 tegelijkertijd zijn geassocieerd met eenzelfde token.

Omdat dit token zowel wordt gemaakt als geïnterpreteerd door het CAP, kan het CAP de data in het token zelf bepalen. De grootte van het token wordt (in theorie niet, maar in praktijk waarschijnlijk wel) begrensd door

20 - de grootte van de URL van de DP

- de voor het token toegestane characterset (ASCII), en de door de cliënt browser maximaal toegestane lengte van de URL.

De naar ASCII omgezette secure hash (of een gedeelte daarvan) van een autorisatie zou een goed token kunnen zijn.

25 De werking van het getoonde systeem wordt geïllustreerd in het diagram van figuur 2: [1] De gebruiker surft naar de gewenste dienst door in de browser (cliënt) het adres (URL) in te voeren (bijvoorbeeld www.service.com), waardoor de browser C een SSL verbinding gaat opzetten met de 30 betreffende CAP server, waarbij de dient C en de CAP server elkaar wederzijds authenticeren (zie hierboven bij het Opzetten van SSL/TLS verbinding). Als gevolg hiervan beschikt de CAP dan over de identiteit van de gebruiker C (ld), het (public key) certificaat van C waaraan de ld is getoetst, Alvl (een parameter die de mate aangeeft waarin deze 35 toetsing wordt vertrouwd door de SP), en het IP-adres IP van waaruit C de verbinding heeft opgezet.

1018494 -10- [2] C stuurt een service request sreq naar de CAP (via door de zojuist opgezette SSL verbinding).

[3] De CAP stuurt sreq, ld, Alvl, en IP naar het DAP proces (gebruik makend van het DSP1 protocol).

5 [4] Wanneer het DAP vaststelt dat de gebruiker C geen recht heeft op de door C gewenste dienst (bijvoorbeeld omdat de gevraagde dienstverlening niet door een contract wordt beschreven), dan eindigt het protocol. Wanneer de DAP vaststelt dat er wel recht op dienstverlening bestaat, dan stelt DAP een alternatief service request 10 sreq' vast dat (a) door een contract wordt afgedekt, (b) zoveel mogelijk lijkt op sreq als mogelijk is. Tevens bepaalt de DAP een tijdsinterval TI (geldigheidsinterval) binnen welke met dienstverlening moet worden begonnen.

[5] Het DAP stuurt autorisatie A (bestaande uit sreq', TI, ld, en IP ) 15 naar de CAP (gebruik makend van het DSP1 protocol).

[6] De CAP maakt een token aan de hand van de door het DAP opgeleverde autorisatie A, met alle eigenschappen van een token (zie hierboven).

[7] het CAP proces stuurt (in de reeds opgezette SSL sessie) een HTML pagina naar de cliënt , met daarin een hyperlink naar de server DP, in 20 welke hyperlink het token als parameter wordt meegegeven, en dit alles zodanig dat de browser na een wachttijd van nul seconden overschakelt naar deze hyperlink. Hierna termineert de SSL sessie tussen C en CAP (het uitgevonden protocol termineert nog niet).

[8] Door het interpreteren van deze HTML pagina zet de client browser 25 een sessie op naar de server DP volgens het CAP-protocol zoals gespecificeerd in de hyperlink. Bovendien wordt het token middels dit protocol naar DP gestuurd.

[9] Het DP proces stuurt het token naar de CAP, alsmede het IP-adres IP’ van de cliënt die de sessie heeft opgestart (gebruik makend van 30 het DSP2 protocol).

[10] De CAP gaat na of er een geldige autorisatie bij het token hoort. Is dat niet het geval, dan termineert het protocol. Bovendien vergewist de CAP zich ervan dat - IP’ hetzelfde is als het in de autorisatie vermelde ip-adres IP; 35 - de huidige tijd valt binnen het in de autorisatie vermelde tijdsinterval TI.

1 01 849 4 ’ -11-

Indien een van deze zaken niet klopt, dan termineert het protocol.

[11] De CAP stuurt het in de autorisatie vermelde service request sreq’ naar DP (gebruik makend van het DSP2 protocol) .

[12] DP start nu de dienstverlening naar C volgens het service request 5 sreq', gebruik makend van het AP protocol, en tegelijk eindigt het uitgevonden protocol.

Tenslotte worden nog de volgende opmerkingen gemaakt: 1. Wanneer een proces in het beveiligingsdomein van een (rechts)persoon zit, betekent dit dat de (rechts)persoon 10 verantwoordelijk is voor de beveiligingskanten van dit proces (d.w.z. hij beheert de beveiliging van dit proces, en draagt de gevolgen van wat dit proces - al dan niet bedoeld - doet of nalaat m.b.t. beveiliging).

2. De 'mate van zekerheid' Alvl geeft aan hoeveel vertrouwen de 15 business heeft in het statement 'de klant heet ld'. Immers, dit vertrouwen kan afhangen van de mate waarin de certificaat-uitgever de identiteit heeft gecontroleerd, en dat is anders voor bijvoorbeeld Class I, II, en III certificaten.

3. Hoewel de standaard spreekt van certificaat uitgevers, is de 20 praktijk dat een certificaat uitgever meerdere typen certificaten uitgeeft (bijvoorbeeld class I, II, III certificaten), waarbij de condities onder welke een certificaat type wordt uitgegeven anders zijn dan bij een ander certificaat type. Derhalve kan het vertrouwen dat een dienstverlener stelt in verschillende certificaat typen 25 eveneens verschillen, en hoort bij elk certificaat type een 'mate van zekerheid' Alvl. Echter, de 'distinguished name' van de uitgever zoals die in het certificaat voorkomt wordt ook gebruikt voor het aangeven van dit soort certificaat typeringen. Derhalve kan hier volstaan worden met het versturen van een lijst van certificaat uitgevers.

1018494 '

Claims (4)

1. Methode voor het door een dienstproces aan een cliënt leveren van een dienst, gekenmerkt door de volgende stappen: a. de dient zet een beveiligde sessie op naar een 5 authenticatieproces en stuurt een cliënt identifier en een service request waarin wordt aangegeven welke dienst wordt gevraagd; b. het authenticatieproces verifieert de cliënt identifier en stuurt de geverifieerde cliënt identifier en het service 10 request naar een autorisatieproces; c. het autorisatieproces onderzoekt of de in het service request aangegeven dienstverlening aan de dient kan en mag worden geleverd, en zendt het onderzoeksresultaat in de vorm van een geautoriseerd service request voorzien van 15 een geldigheidsperiode terug naar de authenticatieproces: d. het authenticatieproces genereert een token, geassocieerd met het geautoriseerd service request; e. het authenticatieproces stuurt via de beveiligde sessie het adres van het betreffende dienstproces en het token 20 naar de cliënt; f. de cliënt treedt in verbinding met het dienstproces en stuurt het van het authenticatieproces ontvangen token naar het dienstproces; g. het dienstproces stuurt het van de cliënt ontvangen token 25 naar het authenticatieproces: h. het authenticatieproces haalt het aan het token geassocieerde geautoriseerd service request op, controleert of de geldigheidsperiode accoord is, en stuurt vervolgens het geautoriseerde service request naar het 30 dienstproces; i. het dienstproces levert vervolgens de door de dient gevraagde dienst.

2. Methode volgens conclusie 1, met het kenmerk dat het authenticatieproces in de onder b. genoemde stap behalve de 35 geverifieerde cliënt identifier, eveneens een “mate-van- zekerheid”-aanduiding betreffende de authenticiteit van die 1018494 i -13- client-identifier naar het autorisatieproces stuurt.

3. Systeem voor het door een dienstserver aan een cliënt leveren van een dienst, met het kenmerk dat 5 a. de cliënt middelen omvat voor het opzetten van een beveiligde sessie naar een authenticatieserver en het naar die authenticatieserver sturen van een cliënt identifier en een service request waarin wordt aangegeven welke dienst wordt gevraagd; 10 b. de authenticatieserver middelen omvat voor het verifiëren van de van de cliënt ontvangen client identifier en het sturen van de geverifieerde cliënt identifier en het service request naar een autorisatieserver; c. de autorisatieserver middelen omvat voor het onderzoeken 15 of de in het service request aangegeven dienstverlening aan de cliënt kan en mag worden geleverd, en middelen voor het naar de authenticatieserver terugzenden van het onderzoeksresultaat in de vorm van een geautoriseerd service request voorzien van een door de autorisatieserver 20 vastgestelde geldigheidsperiode; d. de authenticatieserver middelen omvat voor het genereren van een token, geassocieerd met de geautoriseerd service request; e. de authenticatieserver middelen omvat voor het via de 25 beveiligde sessie naar de cliënt sturen vanhet adres van de betreffende dienstserver en het token; f. de cliënt middelen omvat voor het naar de dienstserver zenden van het ontvangen token; g. de dienstserver middelen omvat voor het naar de 30 authenticatieserver sturen van het van de dient ontvangen token; h. de authenticatieserver middelen omvat voor het ophalen van het aan het token geassocieerde geautoriseerd service request, het controleren of de geldigheidsperiode accoord 35 is, en het vervolgens naar de dienstserver sturen van het geautoriseerd service request; 1018494 . -14- i. de dienstserver middelen omvat voor het vervolgens aan de client leveren van de gevraagde dienst.

4. Systeem volgens conclusie 3, met het kenmerk dat de authenticatieserver behalve de onder b. genoemde middelen voor 5 het verifiëren van de van de cliënt ontvangen cliënt identifier en het sturen van de geverifieerde cliënt identifier en het service request naar een autorisatieserver, bovendien middelen omvat voor het berekenen van een "mate-van-zekerheid”-aanduiding betreffende de authenticiteit van die client-identifier en voor 10 het naar het autorisatieserver sturen van die “mate-van- zekerheid”-aanduiding. 1018494·