Sapete perché l’idea di Microsoft PassPort è fallita, o per lo meno, si è ridimensionata? Perché non a tutti andava giù di lasciare nelle mani della Microsoft tutti i dati dei propri clienti o dei propri utenti. In effetti, con PassPort, Microsoft ha tentato di diventare l’unico certificatore di indentità di internet. Il risultato è stato che, allo stato attuale, PassPort Network è uno strumento utilizzato per i soli servizi Microsoft.

Con queste parole ha esordito il Microsoft MSDN Regional Director allo scorso Microsoft Starting Innovation Tour con una sincerità quasi disarmante, come di chi già sapeva che avrebbe poi detto e mostrato qualcosa che avrebbe fatto dimenticare il mea culpa… e così è stato.

La questione dell’identità digitale è molto delicata, ormai non si può avere fiducia nemmeno del back-office della banca, questo perché le pratiche di phishing sono così sofisticate che non tutti gli utenti sono abbastanza smaliziati da rendersi conto della truffa in cui stanno cadendo.

In questo contesto si pone Windows CardSpace (WCS):

Windows CardSpace permette agli utenti di fornire le loro identità digitali in modo familiare, sicuro e facile. Nel mondo fisico usiamo le tessere d’affari, le carte di credito e la tessera sanitaria. Le riponiamo nel nostro porta tessere e scegliamo quella da utilizzare a seconda dell’utilizzo che ne dobbiamo fare. Allo stesso modo, con CardSpace, usiamo una varietà di schede virtuali per identificarci, ed utilizziamo quella giusta per l’utilizzo che ne dobbiamo fare.

CardSpace si basa su XML e non fa altro che - se implementato nell’HTML della pagina web e se il sistema operativo è in grado di elaborare i dati - far partire una applet dalla quale è possibile selezionare una delle nostre virtual-card, dalle quali recuperare i dati.

Una richiesta tipo implementata a livello di HTML è la seguente:

<form id="cardspacelogin" name="cardspacelogin" method="post">
<object id="xmlToken" type="application/x-informationcard" name="xmlToken">
<param name="privacyUrl" value="">
<param name="privacyVersion" value="">
<param name="issuer" value="">
<param name="issuerPolicy" value="">
<param name="tokenType" value="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1">
<param name="requiredClaims" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier">
<param name="optionalClaims" value="">
</object>
</form>

Nel parametro "requiredClaims" vengono elencati i campi che si desidera recuperare: nel nostro caso sono il nome, il cognome, l’e-mail ed il codice di identificazione.

Implementato il codice, l’applet evocata sarà più o meno simile a questa:

Per vedere questo codice in funzione occorre installare Framework .NET 3 (aka WinFX) e Internet Explorer 7. La community di .NET 3, chiamata Microsoft .NET Framework 3.0 Community" href="http://www.netfx3.com/" target=_blank>Microsoft .NET Framework 3.0 Community" href="http://www.netfx3.com/" target=_blank>Net3Fx, ha messo su una sandbox per testare questa nuova funzionalità.

Bisogna tener presente che, anche se al momento il solo sistema operativo e browser della Microsoft è in grado di interpretare la richiesta, essendo il protocollo OpenSource e basato completamente su XML e SOAP, si presume che sarà implementato anche su altri sistemi e browser.

Il compito dello sviluppatore web, quindi, è quello di rendere le proprie applicazioni ready-for-future.