In questo interessantissimo articolo, Brian esamina alcuni aspetti della “big picture” di OpenID.

Alcuni di questi aspetti riguardano:

• Qual’è la differenza tra il riconoscimento di una persona tramite una email e quello di un OpenID? Perché l’email deve considerato un mezzo di validazione debole, ma è comunque così tanto usato?
• Come funziona il meccanismo di trust di OpenID?
• Quali considerazioni dobbiamo fare sulla (potenziale) poca sicurezza dei provider? White list o Black List? E perché non considerare di estendere i DNS, tale per cui possa esistere un “record OpenID”, così come esiste un record “MX” per le email?
• Quante identità (ID OpenID) diverse ci potremmo aspettare dalla stessa persona?
• Quali potrebbero essere i problemi della privacy derivanti da una vasta adozione di OpenID?
• Infine, quali prospettive di business si possono immaginare sull’utilizzo di OpenID?

Un paio di settimane fa AOL ha deciso di fornire automaticamente a tutti suoi utenti (oltre 63 milioni di persone!) il proprio URL OpenID. Ognuno di essi ha già dunque da adesso http://openid.aol.com/username. Se si usa nel browser direttamente quell’url, si viene portati alla pagina del profilo AIM di quell’utente.

Altre risorse sull’argomento

• Readwriteweb
• Somewhat Frank
• Dal blog di AOL

Come ci ha raccontato Claudio, David Heinemeier Hansson ha iniziato ad interessarsi ad OpenID e un paio di giorni fa ha parlato di nuovo, proponendo un modo per semplificare l’integrazione dell’autenticazione OpenID dal punto di vista dell’utente.

Secondo DHH, se si usassero URL completi come OpenID (secondo la specifica non sono obbligatori), si potrebbe semplificare la procedura di autenticazione, perché le applicazioni potrebbero accorgersi di quando l’utente sta scrivendo un OpenID invece che un normale username. In questo modo sarebbe possibile presentare una sola form per l’autenticazione (normalmente ora i servizi che offrono la doppia possibilità hanno una form doppia) che si trasforma a seconda di quello che fa l’utente.

A questa proposta risponde Bernie Thompson, che, pur riconoscendo i vantaggi indicati da David, indica anche alcuni svantaggi:

• Obbliga gli utenti a scrivere il prefisso http://
• Viene meno la possibilità di sfruttare la convenzione di chiamare sempre il campo openid_url per approfittare del completamento automatico dei browser
• Potrebbe confondere sia gli utenti OpenID che quelli “tradizionali” e sarebbe problematico includere il logo OpenID
• Lo username dell’utente diventa un URL e l’applicazione non dispone più di un nome da visualizzare
• Gli OpenID sono più direttamente associabili ad una persona rispetto ad uno username
• Il codice per i due metodi di autenticazione diventa ancora più accoppiato

Per quanto alcuni di questi punti possano essere soggetti a dibattito sono tutti validi e degni di considerazione. Inoltre, mi sento di aggiungere un altro paio di commenti: modificare l’interfaccia utente sotto il naso dell’utente mentre non se l’aspetta è potenzialmente pericoloso e una form di questo tipo ha bisogno di una spiegazione più dettagliata perché l’utente possa capire come usarla.

In conclusione posso dire di essere d’accordo con Bernie, la soluzione corrente, per i servizi che hanno bisogno della doppia autenticazione, è il compromesso migliore. Le nuove applicazioni possono usare OpenID fin dall’inizio ed evitare di doversi porre questo problema.

La notizia non è freschissima, è del 6 febbraio, prima che questo blog nascesse, ma è comunque piuttosto importante e va riportata. Microsoft pare che abbia deciso di inserire l’autenticazione OpenID in alcuni dei suoi prodotti integrandolo con il suo CardSpace (il cui supporto client è già inserito in Vista ed è disponibile anche per XP, via patch). L’annuncio è stato dato all’RSA Conference a San Francisco.

L’autenticazione CardSpace consentirà ad OpenID di fregiarsi del supporto per il web service standard WS-Trust. Microsoft supporterà OpenID aggiungendolo alle sue future versioni di identity server. Inoltre, ma questo è un dettaglio valido solo per coloro che potranno usare CardSpace, il fatto di avere integrato nel sistema operativo un sistema di autenticazione potrà ridurre (se non eliminare) i problemi derivati dai possbili attacchi di phishing, uno dei punti deboli di OpenID.

I dettagli precisi, però, non sono stati detti (da qui la scelta del titolo di questo articolo).

Altri articoli sull’argomento:

• ReadWriteWeb
• Thomas Hawk
• O’Reilly Radar (dove si può leggere l’annuncio ufficiale)

Simon Willison ha appena reso disponibile la sua presentazione Future of Web Apps. La presentazione può essere divisa in tre parti. L’inizio è una efficace introduzione a cos’è OpenID, perché è utile e come si usa.

La seconda parte descrive alcune possibili applicazioni rese possibili da OpenID che non erano possibili senza, che poi ha riportato anche nel suo articolo:

1. Account rapidi e leggeri, per tutte quelle applicazioni per cui normalmente non si ha voglia di crearsi un account, ad esempio tutti quei nuovi servizi “Web 2.0” che nascono ogni giorno abbasserebbero notevolmente la barriera d’ingresso usando OpenID. O anche solo per commentare su un blog, come in quello di Simon stesso.
2. Account pre-compilati, in cui ad esempio si può assegnare ad alcune persone fidate la possibilità di cancellare i commenti di spam dal proprio blog, senza dovergli chiedere che password vogliono usare.
3. Single-Sign-on aziendale, dove è possibile restringere l’accesso a solo gli OpenID appartenenti al dominio dell’azienda anche sul sito pubblico.
4. Servizi specifici per siti, riconoscendo alcuni tipi di OpenID, ad esempio quelli di AOL
5. Whitelist sociali, condividendo la propria lista di OpenID fidati, è possibile costruire una rete di fiducia globale, disaccoppiata da qualsiasi servizio e decentralizzata.
6. Reti sociali decentralizzate, l’identificatore unico e globale di OpenID può riunire in un unico punto tutti i profili utente sparsi per i diversi siti di aggregazione sociale.

L’ultima invece ci spiega quali sono i problemi di OpenID, in alcuni casi proponendo soluzioni, in altre cercando aiuto:

1. Phishing, siccome l’autenticazione dell’utente avviene su un sito diverso da quello in cui si vuole autenticare, è facile che l’utente si confonda e venga mandato ad una copia della pagina del suo identity provider che gli può catturare la password. Questo è il problema maggiore di OpenID, alcune soluzioni sono già state proposte e implementate, altre sicuramente verranno.
2. Cosa succede se il mio identity provider muore?
3. Privacy, dato che ogni account è collegato al mio OpenID e l’OpenID è direttamente collegabile a me, è più facile che venga riconosciuto. La soluzione in questo caso è banale: usare un altro OpenID quando non voglio farmi riconoscere.
4. OpenID è difficile da spiegare, bisogna renderlo semplice, farlo conoscere, farlo apprezzare e creare innovazione.

Dan Webb ha scritto delle istruzioni pratiche e dettagliate su come integrare OpenID nelle nostre applicazioni.

Dan è una personalità piuttosto conosciuta nell’ambito Ruby on Rails, quindi la sua spiegazione si riferisce in modo specifico a quella piattaforma, ma le librerie OpenID per PHP o Python funzionano in maniera analoga ed è abbastanza semplice adattare la sua spiegazione al proprio linguaggio preferito.

In particolare l’articolo chiarisce il flusso di informazioni tra l’applicazione, la libreria OpenID e l’identity provider, che in questi casi di interazioni decentralizzate a volte può far confondere.