Papierloos informatie over digitale identiteit elektronische handtekening en betrouwbare uitwisseling

Benelux Regional Interest Group Meeting Amsterdam, Netherlands

4 november is er in Amsterdam een regionale bijeenkomst van de EEMA over Federated e-Identity.

Meer informatie op de website van de eema.

Inlogscherm voor Identity 2.0

Met de opkomst van authenticatie providers als DigiD, OpenID en EazyID wordt er ook steeds meer discussie gevoerd over het loginscherm bij een dienstverlener.Tenslotte hebben we de protocollen zo langzaam aan wel onder control (SAML, WS-*, OpenID etc., maar ontbreekt er nog veel duidelijkheid rondom de user experience.

Normaal gesproken is het loginscherm van een dienstverlener vrij standaard. Je vraagt om een username, password en eventueel nog wat linkjes voor wachtwoord of gebruikernaam vergeten.

Huidige stijl:

Steeds vaker worden dienstverleners geconfronteerd met aanvullende inlog methodes en moet je dus ook gaan vaststellen hoe een gebruiker zichzelf gaat authenticeren. Zo zijn er al gemeentes of provincies waarbij je kan kiezen voor inloggen met DigiD of inloggen met een ambtenaar login. Als de trend van identity 2.0 zich doorzet dan krijg je binnen de kortste keren een wachtlijst van keuzemogelijkheden voor de eindgebruiker (inloggen met infocard, inloggen met openid, inloggen met digid etc. etc.)

De identity community heeft dit onderkent en Google heeft onderzoeksresultaten vrijgegeven over het meest geschikte loginscherm voor de toekomst van identity 2.0. In samenwerking met verschillende grote dienstverleners is gesproken over de verschillende mogelijkheden.

Nieuwe stijl:

Je moet het artikel doorlezen om te begrijpen waar de fundementele verschillen zitten met de huidige benadering.

Een zeer interessant stuk voor dienstverleners die zich afvragen hoe ze in de toekomst moeten omgaan met de verschillende authenticatiemogelijkheden die op hun pad gaan komen.

Dit scherm is naar mijn idee nog niet optimaal. Zo zal een gebruiker wellicht in het wachtwoord veld het wachtwoord van zijn identityprovider gaan intypen, dat is natuurlijk niet de bedoeling.

Ik ben zelf meer een voorstander van een 1e stap waar we vragen om een gebruikersnaam. Vervolgens weet de dienstverlener welke authenticatiemethode deze klant gebruikt (DigiD, OpenID, DienstverlenerID)

Webservice Security en PKI

Steeds meer organisaties communiceren onderling via webservices. Een goede algemene presentatie over SOA, Webservices en security las ik van Arthur Donkers.

Rondom webservice security zijn ondermeer de volgende zaken van belang:

1. Identiteit van de webservice requestor ( Proces/ organisatie dat de webservice aanroept)
2. Identiteit van de webservice provider (Proces/ organisatie dat de webservice aanbiedt)
3. Vertrouwelijkheid van het webservice verzoek

Er zijn verschillende niveau’s waar PKI ingezet wordt om bovenstaande zaken te waarborgen.

In veel gevallen beschikt de webservice provider over een SSL servercertificaat om de webservice over https:// aan te bieden. Zo gaan de webservice calls over een beveiligde lijn en zijn de volgende twee zaken gewaarborgd:

1. Identiteit van de webservice provider
2. Beveiliging/ vertrouwelijkheid van  de webservice verzoeken

In 9 van de 10 gevallen is het alleen mogelijk om een webservice aan te roepen door “geautoriseerde” requestors. Soms wordt dit afgedwongen door een shared secret/ wachtwoord in de webservice call, maar in veel gevallen dient de requestor te beschikken over een Client certificaat om zich te authenticeren, waarop de requestor de autorisatie kan afhandelen.

Er bestaat nog weleens verwarring over het type certificaat dat noodzakelijk is voor de requestor.

Indien de requestor ook zelf een webservice provider is dan kan hij een SSL servercertificaat gebruiken voor zowel het beveiligen/ authenticeren van zijn eigen webservice als het gebruik voor client authenticatie richting een andere webservice provider.

In veel gevallen heeft de requestor niet een eigen webservice of is het niet praktisch om beide processen te combineren. Probleem is ook vaak dat de requestor geen domeinnaam/ extern IP adres tot zijn beschikking heeft dat ALTIJD opgegeven moet worden bij een SSL server aanvraag. In veel gevallen volstaat dan de aanvraag van een organisatiegebonden client certificaat. Hierbij identificeer je alleen de organisatie en de applicatie en is verder geen extern IP adres noodzakelijk. Voorbeelden van dergelijke certificaten zijn het PKIOverheid organisatieservices certificaat of een organisatieservices certificaat.

Voor het bewaken van de integriteit van het bericht en vertrouwelijkheid is het ook nog mogelijk om op bericht niveau PKI toe te passen. Op deze wijze worden XML bestanden digitaal ondertekend of versleuteld met het certificaat van de WS provider. Dit gebeurd vaak alleen indien er hoge beveiligingseisen gesteld worden aan de webservice transacties en discussies over inhoud en tijd een rol kunnen spelen.

Elektronische handtekening en zijn context

Vandaag las ik een goed verhaal van Bruce Schneier over het gebruik van de “fax handtekening” en het feit dat deze nog altijd door veel organisaties en personen gebruikt wordt.  Het artikel geeft een prachtig voorbeeld waarom de context van het zetten van een handtekening essentieel is.

Ik denk dat iedereen wel eens een bestelling of ander type document waar een handtekening vereist is over de fax heeft verstuurd. Dit terwijl het kinderlijk eenvoudig is om een dergelijke handtekening te kopiëren. Veel mensen hebben zelfs een ingescand plaatje van hun handtekening, zodat ze direct vanachter de PC kunnen faxen. Toch gaat het gebruik binnen zijn context toch vaak zonder problemen.

In vergelijking met de elektronische handtekening speelt hier hetzelfde fenomeen. De zwaarte en gebruik van een elektronische handtekening  is sterk afhankelijk van zijn context.

Afhankelijk van de toepassing is het belangrijk om te kijken welk niveau van elektronische handtekening gewenst is. Is het mogelijk om een elektronische handtekening op basis van een username, wachtwoord of is een PKIOverheid handtekening gewenst. Uiteraard is in veel gevallen het risico van de transactie een belangrijke graadmeter.

In dit kader verscheen er 12 juni een artikel in het FD over het toepassen van een elektronische handtekening op een elektronische factuur. De auteurs pleiten ervoor dat een simpele PDF ook als rechtsgeldige factuur aangemerkt kan worden.  Persoonlijk denk ik dat de manier van elektronische ondertekening op facturen eenvoudiger moet, maar dat het weglaten een brug te ver gaat.

Primair aandachtspunt is het opnemen van de functionaliteit in de bestaande facturatie en andere financiele pakketen. De praktijk is dat veel softwareleveranciers nog zeer traag zijn met het inbouwen van deze oplossing.

Identity 2008

Op 7 en 8 oktober vindt de 5e editie van het Identity platform in Nederland plaats.

Meer informatie op www.identityforum.nl

DigiD verplicht, voor wie…..?

Het grote nieuws…DigiD verplicht voor de overheid:

Op regering.nl een persbericht dat het kabinet Balkenende vrijdag besloten heeft dat alle overheidsinstanties voortaan verplicht Digid moeten gaan gebruiken. Hierdoor moet de dienstverlening naar de burger toe verbeteren.

Mijn grote vraag is dan voor wie en wat is dit dan verplicht.

1. In veel persberichten zie je regel: De belastingdienst stelde DigID al eerder verplicht.. Gaat het er dus om dat de burger alleen nog maar met een geldige DigiD zijn zaken met de overheid kan regelen. Kortom overheidsinstanties moeten hun klanten “de burger” verplichten om een DigiD te hebben omdat ze anders geen elektronische zaken meer kunnen doen.

OF….

2. De overheidsinstanties moeten verplicht DigiD voeren als het gaat om het aanbieden van vertrouwde online diensten. Dus geen eigen authenticatie methoden meer gebruiken en verplicht een DigiD implementatie als het risico van de dienst een bepaald niveau heeft.

Uit de huidige berichtgeving kan je dit niet direct halen. In het geval van 2. dan ben ik erg benieuwd over welke niveau’s van risico er wel of geen DigiD gebruikt moet worden. Ik hoop hier de komende tijd iets meer over te lezen, iemand anders een idee?

Why organisations should implement user-centric authentication…

Now that developments of User Centric Authentication(UCA) are taking off quickly, I think the Identity Community needs to convince their “customers” to start implementing. The “customers” of UCA are organizations that offer Internet applications like Google, MySpace, Banks, Accountants and many others. Within the identity community these organizations are defined as relying party’s (RP’s).

Although I like tools like http://demand.openid.net to put a little pressure, I think we should help the RP’s with a fact sheet to show the pro’s of UCA. The sheet should also help ambassadors of UCA to convince their general management to prioritize User Centric Authentication.

I couldn’t find any fact sheet so I started to collect the facts myself, please help to make this list complete so in the end the Relying Party’s will see the benefits themselves.

Why relying party’s should implement User Centric Authentication

Pro’s

• Outsourcing authentication saves costs. As a relying party you don’t have to worry about lost user names, passwords, a costly infrastructure, upgrading to new standards and devices. You can just focus on your core. From research the average costs per user for professional authentication are approximately 34 euro a year. In the future you will pay a few cent per authentication request (transaction based). Report from gartner, Any other calculation reports available on this?
• Your customers are demanding user centric authentication. User centric authentication gives your customers comfort. No registration hassle and low barriers of entry to your service. Offering UCA to your customers can be a unique selling point and stimulate user participation.
• Open up your service to a large group of potential customers. You are probably more interested in the potential customers you don’t know, versus the customers you already service. UCA makes this possible. If you can trust the identity of new customers you can start offering services in a minute.
• The identity provider follows new developments. When a new authentication token or protocol is introduced you don’t have to replace your whole infrastructure.
• Time to market. Due to legislation you are suddenly confronted with an obligation to offer two factor authentication. UCA is very easy to integrate and you are up and running a lot quicker
• Data sharing. If the identity provider also offers the option to provide additional (allowed) attributes of the end-user you don’t have to store all this data yourself. If for example I go on holidays for a few weeks I just update my temporarily address in stead of calling the customer service of my local newspaper!
• Quickly offer new services under your brand . If you take over a company or want to offer a third party service under your brand/ infrastructure UCS makes it much easier to manage shared users. How much time does this take at the moment…
• Corporate image. As SourceForge states they also offer openid support to join the web 2.0 space and benefit from the first mover buzz. Besides adding a good authentication mechanism provided by a trusted identity provider could add value to your own service. Like adding a trust seal of your SSL certificate provider.

Potential Con arguments

• I still have to manage the authorization. Although the authentication is outsourced, I still have to bind the identity to my internal authorization rules/ roles/ structure. So the registration process is still time consuming. (At least it is less time consuming if you outsource the identification process)
• Bulk introduction. If i introduce a new service where authentication is required I just do a mass introduction sending all my customers new authentication credentials and preregister them within my authorization DB. With UCA I have to be sure everybody is able to authenticate and I can’t preregister. (It’s just a matter of time before all of your users are familiar with UCA, what about the costs off rolling out yourself…)
• Support stays. I still get support calls because my customers need to follow a procedure to register and bind their identity to my authorization roles. If my customers can’t login it is unclear that I can’t solve this and that they should call their identity provider (UCA will be as common as the availability of water, electricity or Internet. Everybody knows they need to call their Internet provider if they don’t have Internet access)
• A Christmas tree of login frames. How many login frames do I have to display. Please login to my site if you have an infocard click here, if you have an OpenID click here, if you use higgens click here, if you still use our account click here. (UCA standards will merge. Besides you will probably only select a few identity providers you trust. What about just asking the username first…this makes it possible to have only one login frame)
• My authentication is my identity. Providing your customers a smartcard, OTP token or password makes it possible to promote your brand. With a user centric token I don’t have any marketing visibility anymore. (New authentication tokens make it possible to show your brand during the user centric authentication process)
• What if the identity provider is not available. My service is off line if my customers can’t authenticate.. (Do you implement your own water system, electricity generator, Internet backbone? User centric authentication is the core competence of the identity provider, they will do better than offering your own)

FactuurCongres 2008

Het Factuurcongres 2008 richt zich op gebruikers, dienstverleners en anderen die betrokken zijn bij of nieuwsgierig zijn naar de ontwikkelingen en de mogelijkheden op het gebied van elektronisch factureren en geautomatiseerde factuurverwerking.

Het Factuurcongres 2008 richt zich ook op degenen die met elektronisch factureren en geautomatiseerde factuurverwerking hun concurrentiepositie kunnen verstevigen, hun dienstverlening willen verbeteren en besparingen willen realiseren.

Het Factuurcongres 2008 richt zich op de volgende doelgroep:
- financieel directeur, manager en financieel specialist
- hoofd (financiële) administratie, hoofd informatie & administratie
- IT-directeur, IT manager, hoofd IT
- beleidsmaker
- controller, accountant
- hoofd facturering & incasso
- manager eBusiness, manager eBilling of eInvoicing
- hoofd informatievoorziening, hoofd automatisering
- directeur betalingsverkeer
- hoofd internal audit, audit manager

DonorRegister Online

Vandaag las ik een goed voorbeeld van een toepassing waarbij identiteit en elektronische handtekening worden ingezet om een volledige stap van papier naar elekronisch te maken.

DigiD en de UZI Pas helpen mee om het DonorRegister 100% papierloos te maken.

Volgende stap is natuurlijk om ook de artsen met de UZI pas aan te sluiten en zelf het register te laten doorzoeken. Ook de extra papieren beschikking die iemand ontvangt als hij zich inschrijft zie ik liever verdwijnen.

Het volledige artikel lees je terug op digitaalbestuur.nl

Duidelijkheid over de digitale polis

De eisen voor het gebruik van de elektronische polis zijn inmiddels duidelijk; verzekeraars kunnen aan de slag.

Het wetsvoorstel voor de elektronische polis ligt nu bij de Tweede Kamer; de eisen waar aan verstrekkers van verzekeringen moeten voldoen zijn inmiddels duidelijk. Er kunnen misschien nog wat kleine aanpassingen komen, maar verzekeraars kunnen in ieder geval aan de slag. Naast het afsluiten van polissen, wordt het ook mogelijk mededelingen zoals poliswijzigingen elektronisch te verzenden. Nederland is het eerste land in Europa waar straks polissen op elektronische wijze kunnen worden afgesloten.

Eén van de vereisten voor de elektronische polis is het gebruik van een gekwalificeerde elektronische handtekening. De certificaten waarmee dergelijke handtekeningen gezet worden, kunnen niet zomaar door elke organisatie worden geleverd; de organisatie dient bij de OPTA geregistreerd te zijn. DigiNotar biedt als OPTA gekwalificeerd bedrijf meerdere oplossingen die het gebruik van de elektronische polis mogelijk maken.

Dat de interesse voor de elektronische polis groot is, bleek wel uit de opkomst bij de bijeenkomt van het Verbond van Verzekeraars op 15 april 2008. Dick Batenburg van DigiNotar heeft hier een presentatie gegeven over de mogelijkheden en eisen aan de elektronische polis, en de rol van DigiNotar in dit geheel. Bekijk hier de presentatie.