mercoledì, settembre 13

 

Identità digitale e web services

L'ultima sessione parallela del convegno è stata tenuta da Andy West su come rendere sicuri i web service usando l'identità digitale. Tema non nuovo, ma affrontato da una prospettiva tecnica per far capire meglio a cosa si va incontro.
West lavora per la Thomson Learning, una azienda specializzata nella formazione ad alto livello. Sul tema dell'uso dell'identità digitale nei web services hanno svolto un "esperimento" basandosi su un business case reale. E questo business case è lo stesso di ICAR: rendere possibile il trust tra diversi service provider coinvolti in una collaborazione.
Il pattern di interazione preso in considerazione è quello a scambio di messaggi. Naturalmente la base è l'esistenza di relazioni di trust tra le parti che si scambiano messaggi. La "sicurezza" del WS a cui si fa riferimento non ha nulla a che vedere con il fatto di scambiare messaggi su canali SSL. Si tratta di fare sì che un servente possa dare corso a richieste provenienti da un cliente perché conosce l'identità di chi sta usando il cliente. Per ottenere questo risultato sono ricorsi alle specifiche WS-Trust implementate dal prodotto PingTrust di PingID che è stato il loro partner tecnologico.
Il cliente correda la propria richiesta con un insieme di token SAML ottenuti dal proprio STS (Secure Token Service, parte di WS-Trust), il servente valida queste asserzioni. E' importante che il servente non abbia bisogno di usare il STS del cliente, ma possa usare il suo STS che giace nello stesso dominio di trust di quello del cliente, ed è in grado di validare in proprio l'asserzione. Nell'esempio proposto viene usat PingTrust. Come infilare le asserzioni nel messaggio? Nell'esempio che viene presentato, la chiamata tra il cliente e il servente è WS-Trust. AXIS provvede poi a infilare il token SAML nell'header e a passarlo.
Una domanda chiede se sia usato anche un token di identità per il servizio cliente. La risposta è affermativa, l'header contiene sia il token di identità della persona sia quella del cliente. Come da tempo proponiamo per INF-1...

 

Un topo di nome Higgins

Tra le sessioni parallele del pomeriggio ho scelto questa intitolata "On a long-tailed mouse named Higgins". Higgins, oltre che il nome del roditore-mascotte, è il nome di un progetto ospitato dalla Eclipse Foundation. Il progetto nasce in una piccola azienda che voleva dare agli utenti più controllo sulle loro informazioni personali. Higgins ha le sue fondamenta nel fatto di supportare molti "contesti" (modi d'uso delle identità digitali) e di supportare profili multipli per gli utenti.
Higgins è un framework per la user-centric identity che non si propone di rivoluzionare i protocolli, ma di usare quelli del mercato. Non definisce nulla di nuovo come protocolli e standard, ma fornisce una base di codice e di API che, attraverso diversi plug-in, afferma di supportare tutti i principali protocolli e tecnologie.
L'uso di Higgins ha un impatto sulla la user experience dell'autenticazione. L'utente sceglie una delle sue "i-card" con cui sceglie quali informazioni rendere visibili. Esiste anche un meccanismo di "link & sync" in cui Higgins aiuta a compilare i form sui siti delle relying party, introduce user e password, ecc.
Higgins sembra essere molto attento alla privacy. Le informazioni nella card, per esempio, non possono essere semplicemente "lette" dalla relying party con una query del tipo "dimmi il valore di questo attributo", ma solo con "claims" del tipo "dimmi se questo attributo ha questo valore".
Arriva dal pubblico una domanda da parte di una persona di Sun/Liberty. Dal momento che Liberty ha già fatto tutto quanto serve all'IdM e ha un notevole successo, perché reinventare tutto? Qual è il fattore differenziante? La risposta è che Liberty è un insieme di specifiche, Higgins è codice ed essendo agnostico rispetto a protocolli e sistemi di autenticazione ci si aspetta che userà anche Liberty. In realtà la domanda, che viene chiarita poco dopo, è più un'osservazione: per quale motivo è nata la user-centric identity per proteggere la privacy dell'utente? non bastava Liberty? a questo non viene fornita risposta.
Ragionandoci, questo modo di intendere la user-centric identity sembra basarsi proprio sulla sfiducia dei "commons" nel fatto che le grandi aziende dietro Liberty e SAML tengano nel giusto conto la privacy. Microsoft sembra cavalcare questa sfiducia con Cardspace, in raltà per incatenare il client a Windows e per incentivare l'acquisto di Vista, ma il concetto delle "InfoCards", "i-Cards" o "Personae" si ritrova in tante iniziative.

 

PingID presenta Cardspace

Curiosamente, la presentazione su Cardspace è introdotta da Patrick Harding, CTO di Ping Identity, e solo il secondo e terzo sub-intervento provengono da Redmond.
Secondo Harding la guerra dei protocolli è finita il mondo converge su SAML 2.0 e WS-Federation. Il profili SAML 2.0 WebSSO e WS-Fed sono però una federazione "passiva". Cardspace, Higgins e il profilo ECP di SAML 2.0 sono invece una federazione "attiva".
Cardspace prevede l'uso di informazioni di identità auto-asserite, e prevede che l'individuo decida se federare la propria identità e come farlo.
La federazione passiva, secondo Harding, gestisce male la selezione o la discovery dell'IdP. Cardspace permette una selezione dell'IdP controllata dall'utente in modo più efficace. Cardspace, secondo Harding, permetterebbe un controllo più efficace del phishing perché le procedure d autenticazione sono graficamente distinte (e anche qualcosa di più... sono addirittura inglobate in Windows, come se questo fosse mai stata una garanzia di sicurezza fino ad ora).
Il concetto di "card" rappresenta un insieme di ruoli. Scegliendo una diversa Card scegli di presentarti con un diverso ruolo. Anche questo sembra molto simile alle LLP di Lewis e ai profili di INF3, speriamo che MS non abbia brevettato l'idea!
Mi pare però di capire che il problema del Cardspace e delle InfoCards sta nel fatto che sono radicate in profondità in Windows Vista. Se non hai Vista, non hai alcuna delle funzioni di federazione possibili con Cardspace. Inoltre le card sono gestite dal tuo PC; se vai su un altro PC, o su un chiosco, non puoi più godere della federazione. Mi pare anche di capire che ci siano nuovi metadati scambiati tra web server e client, quindi bisognerà vedere se usando altri sisemi operativi o addirittura solo altri browser sarà ancora possibile autenticarsi.
Uno degli aspetti interessanti di Cardspace è che MS afferma che sarà possibile avere un "trust model" deciso da chi offre ciascuna risorsa e non dall'IT dell'azienda. ovviamente in un mondo, come quello delle relazioni tra aziende, in cui non esiste un dominio sovraordinato in cui far valere accordi di trust come quelli di INF3, capire di chi puoi fidarti è un problema.

 

Jamie Lewis, l'evoluzione dell'identity management

Jamie Lewis è il CEO del Burton Group. Secondo Lewis ci troviamo ad un "ginocchio" della curva di crescita dell'IdM. Nel giro di breve tempo vedremo cambiare molte cose verso la completa decentralizzazione e internetizzazione dell'identità.
Anche secondo Lewis la contrapposizione tra federazione e identità user-centrica è forzata, confonde il disegno generale. La federazione dovrebbe ssere un insimee di accordi, standard e tecnologie in grado di garantire la portabilità delle asserzioni di identità. E' una caratteristica architetturale che permette la costruzione di reti loosely-coupled di sistemi.
La reazione che ha portato all'identità user-centrica deriva probabilente dal fatto che disegni e casi d'uso delle federazioni esistenti sono state fatte senza che l'utente avesse voce in capitolo. Lewis dice che dovremmo avere non tanto sistemi di IdM "user-centric" ma "reality-centric". L'autonomia e l'autodeterminazione dell'utente sono giuste preoccupazioni, ma bisogna prestare attenzione a un fatto: qualunque sistema che sia "centrico" su una delle sue parti non è in grado di scalare fino alle dimensioni di Internet.
Lewis spiega la sua posizione su come superare questo impasse artificioso parafrasando il sottotitolo del "Dottor Stranamore": "how I learned to stop worrying and love the paradox". Singifica che il mondo dell'IdM può funzionare se combiniamo un insieme di domini (contesti) ciascuno con regole interne, ID locali, casi d'uso propri, e un tessuto connettivo tra i domini. Ma con quali servizi? Lewis cita l'idea di un sistema di meta-identità (meta-identity system) di Bob Blakley, e incoraggia la platea a informarsi su questa idea.
Per gli utenti, Lewis suggerisce di intendere l'identità come una "Limited Liability Persona" (in inglese). Ogni LLP è un contenitore per un insieme limitato di informazioni sull'identità. Sono illuminato dalla rivelazione: la LLP è l'equivalente del "profilo" di INF-3, è esattamente la nostra idea! E l'idea nasce esattamente dalla stessa esigenza: porre sotto il controllo dell'individuo la propria rappresentazione digitale. Significa che non ci siamo sbagliati!

martedì, settembre 12

 

Identità digitale nella Columbia Britannica

Oggi pomeriggio ho seguito un interessante intervento dal titolo "Citizen-centric Identity" tenuto dal CIO e dal Chief Architect dell'amministrazione provinciale della Columbia Britannica (Canada).
La BC ha deciso di darsi una filosofia che prescrive la costruzione di "servizi centrati sui cittadini". Al di là del marketing, questo significa che al cittadino non è richiesto di sapere come sia organizzato al proprio interno il governo locale e chi eroghi quali servizi (can you spell "portale per la semplificazione amministrativa"?)
Partendo da un insieme di casi d'uso di cittadini-tipo, è stata costruita una mappa di quali parti dei servizi a disposizione vengono intercetttati dal "percorso" che il cittadino compie per completare ciascun caso d'uso. Questa mappa non coinvolge solo i servizi dei ministeri provinciali, ma anche quelli di altri attori del servizio publico e anche soggetti appartenenti al settore privato.
I servizi sono quindi forniti da diversi soggetti. L'identità ha bisogno un modo per fluire da un service provider all'altro mantenendo il proprio significato (can you spell "cooperazione applicativa"?).
La BC gestisce un identity provider aperto anche ai soggetti privati che vogliono fare business con i cittadini. L'identità digitale in BC segue due macro-scenari, uno destinato ai cittadini che usano servizi elettronici e uno destinato agli utilizzatori che agiscono per conto di aziende stesse.
Nel primo scenario il cittadino che tenta di accedere ad un servizio senza avere una identità digitale compila una richiesta di concessione di un BCeID (credenziali digitali), e ottiene una coppia user/pw non verificata. Per ottenere credenziali verificate deve quindi confermare la propria identità recandosi ad un ufficio di registrazione con la richiesta e un documento di identità. Ci sono diversi uffici di registrazione a disposizione per questi servizi. Un funzionario verifica la corrispondenza tra le informazioni introdotte e i documenti presentati e quindi attiva l'account.
Un processo simile è in funzione anche per le aziende. La registrazione deve essere eseguita da un legale rappresentante, che poi può conferire ad altre persone che lavorano nell'azienda la possibilità di agire per conto dell'azienda in ruoli specifici.
La BC ha quindi un proprio IdP e una AA (per usare la terminologia ICAR-INF3). Ci sono però delle iniziative federali canadesi in cui sarebbe desiderabile fare interoperare le identità della BC con quelle delle altre province canadesi. Al momento sono stanno conducendo una survey per cercare soluzioni di interoperabilità sul mercato. I protocolli usati tra IdP e SP sono per ora proprietari, e al momento non c'è uno schema chiaro per garantire la "quality assurance" (can you spell "imputabilità"?) delle identità tra le diverse province.

 

Sessioni parallele

Ho preso parte a due delle sessioni parallele. La prima, che ho trovato interessante, riuniva diversi esperti, tra cui Dick Hardt, attorno al tema della URL-based identity. Si tratta di una delle tecnologie abilitanti alla user-centric identity, e si basa su identificativi individuali sotto forma di URI come gli i-names. Da tutti traspariva come si trattasse di una tecnologia molto promettente ma ancora giovane. Mentre parlavano ho recuperato il mio i-name che avevo acquistato, bloccato per 50 anni, alla edizione 2004 della Digital ID World Conference. Ho provato a collegarmi e ho scoperto che non esiste più. Ok, non ho pagato l'hosting per il 2006, ma il nome è bloccato fino al 2054 e la forza degi i-name è proprio quella di essere persistenti. Vado quindi su un registrar e provo il mio i-name e... sorpresa! non risulta registrato, ed è disponibile per chi lo vuole. Con buona pace del mio contratto che doveva durare 50 anni, degli identificativi persistenti e della possibilità di costruire una vera identità digitale, con una reputazione e tutto il resto, che mi segua per la vita. Cercherò di scoprire qualcosa di più rivolgendomi al banco del registrar che ho visto nell'area espositori.
La seconda parallela a cui ho assistito riguardava le limitazioni dovute all'attuale carattere peer-to-peer delle federazioni. Da questo panel porto con me l'idea che l'approccio point-to-point alla federazione delle identità digitale è ottimo per una proof-of-concept ma se il numero di partner cresce bisogna studiare un altro sistema. Se si potesse estrapolare questo discorso alla realtà in cui lavoro, bisognerebbe dire che forse il modello di interazione P2P previsto da SPCoop può non essere la migliore scelta, anche se qualunque altra topologia che si basi sulle entità della PA risulta difficilmente praticabile in quanto tenderebbe a creare una situazione de facto in cui, per esempio, le regioni sono tecnicamente sovraordinate alle province e queste ai comuni ecc.
Ragionando invece nel cortile di INF3 mi viene da pensare che il nostro sistema è stato pensato in modo abbastanza flessibile. Esiste un ambito fiduciario comune, materializzato dal garante e dalle firme elettroniche che appone alle asserzioni che accreditano le diverse sub-autorità, ma ciascuna della parti di INF3 può tecnicamente scegliere, all'interno del proprio dominio, di pensare P2P e magari ripudiare le asserzioni emesse da una particolare parte assertiva. Non sarebbe desiderabile, e costituirebbe un vulnus per la federazione ICAR, ma è tecnicamente possibile. Ciò mi fa pensare che abbiamo un disperato bisogno di mettere un punto fermo alla modellazione organizzativa di INF3.
Uno dei problemi che gli americani hanno, quando vogliono federare le pere con le mele (identità provenienti da ambiti di business diversi, come PayPal e Skype e Google ecc.) è che la "forza" (livello di imputabilità) di queste identità, prima ancora che la forza del sistema di autenticazione, è enormemente diversa. Per foruna in INF3 abbiamo detto sin dall'inizio che bisogna aderire a un insieme di regole comuni per garantire lo stesso livello di imputabilità tra diversi IdP.

 

Lo stato dell'identità digitale secondo Phil Becker

Phil Becker ripercorre la storia degli sforzi fatti per rendere sicura la rete. Firewall, proxy, sicurezza perimetrale della rete hanno condotto a risultati contraddittori e soprattutto hanno condotto alla perdita di controllo su chi fa che cosa. Su questo si sono inserite le novità della legislazione USA come la legge Sarbanes-Oxley che invce pretendevano che ciascuna organizzazione sapesse esattamente cosa fa chi. Ciò ha spostato l'attenzione dalla sicurezza del perimetro (che aveva condotto ad una mentalità "da assedio") all'identificazione di chi opera su dati e applicazioni entro il perimetro della rete (noi diremmo "dominio").
L'identità digitale diventa il paradigma organizzativo dei sistemi distributi, che permette di gestire dinamicamente le necessità degli utenti mantenendo il controllo sulle policy degli organismi che gestiscono dati ed applicazioni.
Phil vede tre principali attori che guidano l'evoluzione della IT e dell'identità digitale: le imprese e i governi, i produttori e venditori di IT e i consumatori di IT. Trovo interessante lo spostamento linguistico da "utenti" a "consumatori".
Ovviamente quando si parla di internet e non solo delle reti aziendali la situazione peggiora ulteriormente. L'aumento di scala rende evidente che occorrono soluzioni modulari basate su standard di interoperabilità, perché l'esigenza di interconnettere diversi sistemi di identità digitale è ineludibile. A questa esigenza si è dapprima risposto con la "virtualizzazione" dei sistemi e più recentemente con la lor federazione. Lo stato dell'arte attuale è tale per cui tra i nuovi dispiegamenti di sistemi di identità digitale sono più quelli che hanno successo di quelli che falliscono (fa un po' paura... immagino che questo dato in passato non lo raccontassero).
Phil viene quindi al tema del convegno: "managing the decentralization of identity". Secondo Phil i dati che formano l'identità digitale di una persona sono decentralizzati per loro natura, dal momento che hanno origine in diversi contesti. I tentativi di centralizzare questi dati sono stati fatti e hanno fallito.
Phil prevede che nei prossimi anni vedremo:Per le aziende e i governi, i prossimi passi sarannno la ridefinizione della sicurezza come sistema di risk management basato sull'identità digitale, l'uso dell'identità come primo fattore di compliance con la normativa, la capacità di offrire una migliore user experience senza cedere terreno in termini di sicurezza e gestione del rischio.
Per i venditori, i prossimi passi saranno l'aumento di importanza dell'interoperabilità e dell'integrazione tra prodotti, l'integrazione verticale tra i layer, il miglioramento della facilità di deployment, amministrazione e manutenzione, di nuovo la capacità di migliorare la user experience e la riduzione dei costi
Per i consumatori, si avvicina un momento in cui ci saranno nuove possibilità e user experience basate sull'identità. I consumatori dovranno rendersi conto dell'importanza di avere sistemi di protezione e privacy all'interno dei loro sistemi di identità digitale.
In sostanza, quello che accadrà nel complesso sarà:

lunedì, settembre 11

 

Commento a margine

Quando ho visto che il convegno avrebbe avuto inizio l'11 settembre, ho immediatamente pensato che si sarebbe aperto con commemorazioni e che una buona parte delle parole degli oratori sarebbe stata spesa nel tentativo di dimostrare che l'identità digitale rende il paese più sicuro. Non è stato così. Non una volta è stato nominato il "9/11". Il secondo keynote, particolarmente brillante, è stato addiruttura tenuto da un lobbista per le libertà civili, contro le ansie di controllo dell'amministrazione. Mi pare un segnale interessante.

 

Resoconto delle sessioni del pomeriggio

Phil Becker, coordinatore del convegno, propone di fare un passo indietro per avere una visione di prospettiva. Dapprima la sicurezza è stato il motivo principale per l'adozione della identità digitale, e poi il focus si è spostato sulla gestione del rischio e sull'aderenza alla normativa. Ora acquisiscono importanza i "nuovi usi" che si fanno sul web dell'identità digitale.
In ogni caso tutto è cominciato con la sicurezza. Di questo parla il CTO di Symantec, Rob Clyde. Symantec si sta riposizionando, non è solo più sicurezza, e trova molto interessante il tema dell'identity management. Il focus rimane comunque la protezione (del PC, delle infrastrutture, ecc.) dalle minacce che arrivano in rete. L'identità è un pezzo fondamentale in questo schema (qualcuno direbbe "l'imputabilità dell'identità"), soprattutto per estendere il concetto di "protezione" a quello di "tranquillità" (confidence) nell'uso dell'IT. E anche la protezione non riguarda più solo l'infrastruttura, ma anche la protezione dele interazioni in rete.
Da un punto di vista della determinazione di "chi è dentro e chi è fuori", la tendenza che vede Clyde è che anche gli "insiders" vengono ormai considerati come esterni al perimetro di sicurezza, e quindi equiparati da un punto di vista della loro identità digitale agli utenti esterni. Sono le policy a essere diverse, non le identità. Mi pare una visione molto vicina a quanto stiamo portando avanti con ICAR-INF3.
Il secondo intervento è di Jim Harper del Cato Institute, autore di un libro intitolato "Identity Crisis" e titolare di un sito dedicato alla privacy. Il tema è "quante volte sono costretto a identificarmi per permettere l'attuazione di una corretta policy di autorizzazione?". Il libro ha origine due anni fa in una momento in cui il congresso americano stava pensando all'introduzione di uno schema di carte di identità nazionale. Nello scrivere questo libro, Harper ha scoperto che non esiste uno schema teorico (negli USA, immagino) su quando è necessario identificare qualcuno. Quali sono le caratteristiche di una carta di identità? 1) permette la sorveglianza dell'individuo 2) concede a chi emette la carta un grande potere sulle persone 3) facilita il furto di identità. Harper, che lavora in una organizzazione di ispirazione libertaria, è ovviamente molto scettico sul rapporto costi-benefici di una carta di identità emessa dal governo federale.
Parlando di autorizzazione, Harper pensa che l'autorizzazione, che normalmente è considerata "qualcosa che viene dopo", sia in realtà da collocarsi all'inizio di qualunque processo di accesso. L'autorizzazione risponde alla domanda "deve questa cosa avvenire o no?". E' per rispondere a questa domanda che tutti gli altri processi (identity management, autenticazione, identificazione) hanno luogo.
Harper ritiene che l'identificazione delle persone sia utilizzata troppo e anche a sproposito. Il costo dell'identificazione è molto elevato (costo in termini di rinuncia a libertà civili).
Il terzo intervento viene introdotto da Dick Hardt. Dick presenta una presentazione dal titolo "Identity in Big Sites" che riassume l'uso dell'identità digitale in grandi siti come Google, Yahoo!, Microsoft e eBay con il suo tipico stile che aveva già impiegato nella presentazione "Identity 2.0". Segue un panel, moderato da Dan Farber, raccoglie il CISO di PayPal oltre a due altre persone che non sono riuscito a identificare (una di Microsoft, una di Verisign), in cui si discute dei dettagli e prospettive dell'identity management nella visione di questi tre colossi.

 

Ci sono più blog tra cielo e terra di quanti ne sogna la nostra filosofia

Credevo che bloggare il convegno fosse un'idea originale. Niente di più sbagliato: di fronte a me e di fianco a me ci sono due persone che stanno facendo esattamente la stessa cosa.

 

User group meetings

Il primo intervento che ho seguito è stato quello di Andre Durand della PingID, a cui alcuni attribuiscono il merito di avere coniato l'espressione "federated digital identity". L'ho trovato molto interessante, soprattutto perché cercava di sintetizzare alcuni movimenti in corso sul tema dell'identità digitale. In particolare, Andre sosteneva che l'identità digitale federata come è nota oggi (in base ai casi d'uso di Liberty e di SAML 2) non è necessariamente antitetica con l'approccio "user-centric identity". Non so quasi nulla sul tema user-centric ID, a parte avere visto una celebre presentazione che Dick Hardt (di Sxip) alla Open Source Conference dell'anno passato, e sono qui anche per imparare qualcosa su questo. Da quanto finora ho capito l'approccio UCID mette l'accento sul fatto che l'utente diventa parte attiva del circle-of-trust tra IDP e SP; questo è un caso d'uso un po' lontato da quelli di e-government italiano di mio interesse, ma nondimeno è interessante.
Durand sostiene che il dualismo irriducibile tra la FDID e UCID sia un falso mito. Secondo Durand l'obiettivo ultimo è un sistema di identità digitale che possa funzionare sulla scala di internet, in grado di accontentare tutti i casi d'uso (intranet/extranet/internet per impiegati/clienti/consumatori).
Secondo Durand in questo momento siamo in una situazione in cui si riescono bene a fare federazioni di 3-6 parti, dopodiché non si scala più e tutto diventa complicato. Bisogna raggiungere un punto in cui l'aggiunta di un partner non richieda più di 1 giorno, e sia supportato da sistemi di auditing federato, di provisioning federato, e a quel punto il raggiungimento di un trust model condiviso genererà un balzo in avanti. Non si potrà, secondo Durand, andare avanti a lungo con un approccio alla federazione di tipo hub-and-spoke come è adesso.
Ovviamente tutte queste affermazioni vanno filtrate dal marketing: Ping Identity sostiene di avere un prodotto con cui raggiunge un deployment molto semplificato, una federazione di nuovi partner con un solo click e anche d avere aggiunto i casi d'uso user-centrici tipici del nuovo approccio al problema. Secondo me non è tanto questo ad avere bisogno di verifica, ma il fatto che un prodotto tecnologico possa superare la distanza tra le due visioni.
Dopo Durand ha parlato Patrick Harding, CTO di PingID, che ha dato alcuni spunti interessanti circa il fatto che per aiutare le federazioni a scalare bene su larga scala occorrono meccanismi di scambio dei metadati "fuori banda". Sarà possibile arrivare a meccanismi di "federazione attiva" da parte dell'utente, coinvolto nel processo di propagazione del trust (come in Microsoft CardSpace e SAML 2.0 ECP profile). Anche in questo caso per la mia area di interesse specifica l'applicabilità potrebbe non essere immediata.
Dopo pranzo mi sono trasferito nella sala accanto dove si parlava, in un ambiente affettatamente informale e non-marketing, del movimento degli Identity Commons. Identity commons è una organizzazione che mira a stabilire uno spazio comune per la costruzione di un layer di identità digitale su Internet tenendo in gran conto le necessità di privacy e di controllo da parte dell'utente. L'organismo è formato da diversi gruppi di lavoro.
Uno di questi gruppi di lavoro è la "Identity Gang" . Attorno a questo ruota una galassia di blog di individui impegnati sul tema dell'identità digitale ad ampio spettro (non solo geek).
Identity Commons ha un proprio charter costituito da 7 principi a cui è richiesto ai working group di uniformarsi. A parte questo, ogni WG ha una governance propria. Sembra interessante, e merita sicuramente approfondimento.
L'ultimo intervento della sessione "informale" ha riguardato le attività del gruppo OpenID. OpenID si basa su concetti come XRI e i-Names. XRI è nato come standard per la standardizzazione di un sistema di identificatori "puri", persistenti, in linea di principio per qualuqnue cosa. Un identificatore XRI può "risolvere" a diversi altri identificatori, per esempio URI. La sintassi degli identificatori XRI è un superset della sintassi degli URI, quindi stiamo parlando di qualcosa che software e utenti sono già "abituati" a trattare, più o meno.
Sullo standard XRI (che è un standard Oasis) è stato costruito il concetto di i-Name. Un i-Name è un identificativo XRI che "punta" ad una persona o una organizzazione. Essendo costruito su XRI che è un identificativo persistente, un i-Name può "seguire" una persona nei suoi spostamenti di azienda, di provider di posta, di provider internet, ecc.
Su questi concetti viene presentato un progetto ospitato da Eclipse, denominato Higgins, che si propone di costruire un framework che permetta di integrare le informazioni sull'identità, il profilo utente, ecc. provenienti da diverse piattaforme, creando una vista unificata su queste informazioni. Detta così ricorda alcuni aspetti del progetto IRIDE (l'unificazione di attributi provenienti da fonti diverse, e il fatto di essere una API per scrivere applicazioni) e anche del progetto ICAR-INF3 (mi sembra infatti che il concetto di "context" di Higgins ricordi il "profilo" di INF3).

 

Cominciamo (bene?)

Primo giorno del convegno. Stamattina ci sono gli "user group meetings", sessioni organizzate dagli sponsor, e io sono iscritto alla sessione della Ping Identity con cui ho avuto diversi contatti nei mesi scorsi. Alle 3 del pomeriggio ci sarà invece il keynote di apertura del convegno vero e proprio.

domenica, settembre 10

 

Digital Identity World 2006

Sono appena arrivato in albergo a Santa Clara, dove domani avrà inizio la Digital Identity World Conference 2006. Sono qui per conto dell'azienda per cui lavoro, viste le molteplici attività che abbiamo in corso sul tema dell'identità digitale.
Il mio viaggio è cominciato Misty mountains in Switzerlandieri con un breve passo da Torino a Francoforte, dove ho passato la notte in attesa del balzo intercontinentale. Il volo da Francoforte a San Francisco è stato lungo ma tranquillo, in un 747 stipato come un uovo. Pesanti misure di sicurezza in Germania, mentre qui sono state molto più "leggere" e discrete.
Per fare colore posto subito una foto ripresa ieri durante il viaggio da Torino, che linka all'album fotografico su Flickr che ho attivato per l'occasione.

This page is powered by Blogger. Isn't yours?