[Openstandaarden] verslag meeting eID 2005-02-26 Brussel

[Kristoff Bonne]

Gegroet,


JanC schreef:

> De oplossing daarvoor is een reeks APIs/layers die elk met een eigen 
> key toegankelijk zijn, maar ik vrees dat je dan mogelijk een custom 
> (niet-standaard) smartcard zou moeten ontwikkelen, en dat zou wel eens 
> erg duur kunnen worden.  Maar iemand als Peter Strickx kan dat 
> misschien beter verduidelijken?

Wel, ik ben deze discussie al een tijdje aan het volgen en ik eigenlijk 
kom ik ongeveer tot de volgende conclussie:
1/ Elk informatie-veld op de kaart moet appart beveiligd worden met een 
eigen sleutel. Elke toepassing krijgt enkel de sleutel voor deze 
specifieke velden indien ze t.o.v. een controlerende overheid kan 
aantonen waarom ze die informatie nodig heeft.

Indien men het voorbeeld neemt van het zwembad; dan kan men bepalen dat 
deze specifieke toepassing toegang krijgt tot (ik zeg maar) de leeftijd 
en de postcode van de gemeente waar men gedomincilieerd is; maar niet 
(ik zeg maar) de naam van de persoon of de rest van het adres.

Ik vermoed dat dit wel mogelijk moet zijn met de bestaande e-id kaarten.

2/ Bepaalde informatie-velden op de kaart zijn niet gewoon puur 
informatie; maar eigenlijk "functies". Ik leg uit.

-> Er zou een bepaald veld kunnen zijn die betekent "leeftijd van 
persoon in jaren". Dit is niet iets dat vast ligt (want die verandert 
elk jaar op je verjaardag) maar -als men dat veld leest- dat er dan door 
de kaart dan zelf de berekening doet (op basis van de geboortedatum).

Op die manier kan men een toepassing maken die vraagt hoeveel jaar 
iemand is (bv. de "zwembad" toepassing); maar dat zo wel GEEN toegang 
heeft tot de precies geboortedatum van iemand.

-> Ook interessant zou zijn dat men velden maakt die eigenlijk een 
vragen stellen, bv. "is de postcode van de gemeente waar de persoon 
gedomisilieerd is 9000, 9xxx, 9yyy of 9zzz" of "is de leeftijd van de 
persoon minder dan x jaar?"
Terug, als men dit toepast op de zwembad-toepassing kan de toepassing 
kijken als iemand afkomstig is uit Gent of één van dienst deelgemeenten 
of als die een kind is; maar zonder de precieze postcode te weten te 
komen van de persoon.


3/ Een laatste mogelijkheid die m.i. zeker moet voorzien zijn is het 
feit dat alle "queries" op de kaart gelogd worden in de kaart zelf; 
inclusief informatie
- wat precies opgevraagd werd (welke velden).
- een identifitcatie van de terminal die de querie gedaan heeft; en een 
identificatie van de persoon (of toepassing) die de informatie opvraagt.

Een interessante optie zou zijn dat jij -als bezitter van de kaart- je 
je kaart zou kunnen "configureren" om alleen informatie vrij-te-geven 
als niet alleen jij JOU kaart inbrengt; maar als de persoon die de 
informatie opvraagt ook ZIJN/HAAR kaart inbrengt. Geen identificatie van 
de gebruiker aan hun kant; geen informatie uit jouw kaart.


M.a.w. als je naar het gemeentehuis gaat voor iets en ze vragen daar de 
informatie uit je e-id; dan je dan niet alleen kan zien welke informatie 
ze precies opgevraagd hebben; maar ook welke terminal en een 
identificatie van de gemeentje-bediende die de informatie opgevraagd heeft.
Op die manier heeft dit jou een goede beveilinging tegen het misbruik 
van de gegevens op jouw kaart; omdat het laatste wat iemand die slechte 
bedoelingen heeft wil; is dat zijn/haar "id" staat in elke verrichting 
die bij iedereen gebeurd is.
Het feit dat de persoon zelf verplicht wordt om zich te identificeren 
heeft ook tot gevolg dan men zich niet kan "wegsteken" achter "de 
terminal van dienst bevolking van de gemeente"

(Het spreekt voor zich dat de "id" van de opvrager natuurlijk enkel een 
nummer is en dat enkel het gerecht die kan "opzetten" in een echte naam 
van een persoon).



Zo, tot zover mijn "wish-list"; maar -aangezien die e-id kaarten nu toch 
al in omloop zijn- vermoed ik dat dit eigenlijk allemaal vijgen na pasen is.



Cheerio! Kr. Bonne.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3210 bytes
Desc: S/MIME Cryptographic Signature
Url : http://openstandaarden.be/pipermail/openstandaarden/attachments/20050303/4457405e/smime-0003.bin