In teoria, su un sistema Windows, il servizio di propagazione dei certificati estrae automaticamente tutti i certificati da qualsiasi smart card inserita e li copia nel negozio "Il mio" dell'utente corrente. Ciascun certificato di questo tipo viene registrato con un collegamento alla corrispondente chiave privata, che si trova nella smart card. Quando si utilizza la smart card, l'applicazione cerca effettivamente un certificato corrispondente, potenzialmente chiedendo all'utente la scelta del certificato; una volta selezionato il certificato, l'applicazione tenta quindi di raggiungere la chiave privata, a quel punto (e solo a quel punto) viene richiamato il driver della smart card (internamente, l'applicazione parla al "CSP della Microsoft Base Smart Card" che a sua volta parla al "minidriver" specifico della carta).
L'idea principale è che le applicazioni non vedano "smart card"; usano chiavi private che individuano con il loro certificato . Se una data chiave privata si trova in una smart card o no, o se due chiavi provengono dalla stessa smart card, viene mantenuta negli interni del sistema operativo. L'applicazione può giocare direttamente con le smart card (usando winscard.dll ), ma la maggior parte no (ad es. Internet Explorer, quando si tratta di un server SSL che richiede certificati client, guarda solo ai certificati e non si preoccupa della smartcardness.
Le cose cambiano su altri sistemi operativi o con alcune applicazioni. Firefox, ad esempio, utilizza solo PKCS # 11 , un'API generica per "dispositivi crittografici", e ignora completamente il supporto del sistema operativo quando viene eseguito su Windows. Quindi, ciò che accade dipende interamente da come Firefox decide di gestire le smart card. Il principio principale è ancora attivo, tuttavia: le scelte dell'utente sono centrate su certificates .
