InfoCard, sélecteur d'identité dans un méta- système d'identité Philippe Beraud Consultant Principal Microsoft France.

Présentation au sujet: "InfoCard, sélecteur d'identité dans un méta- système d'identité Philippe Beraud Consultant Principal Microsoft France."— Transcription de la présentation:

1 InfoCard, sélecteur d'identité dans un méta- système d'identité Philippe Beraud Consultant Principal Microsoft France

2 Identité sur lInternet aujourdhui LInternet sest construit sans fournir les moyens de connaître sur QUI et QUOI vous êtes en train de vous connecter Les menaces vis-à-vis de la sécurité en ligne ne cessent de croître Vol didentité: phishing, pharming, fraudes, etc. « Fatigue » des mots de passe Considérations relatives au respect de la vie privée Nous avons oublié la « Couche Identité » pour lInternet Tout ce qui est actuellement en service peut être considéré comme un contournement Aucune solution simpliste nest réaliste La résolution du problème de lidentité bénéficie à chacun – y compris Microsoft - et cela est essentiel si nous voulons libérer le potentiel des services de Web

3 Les leçons tirées de Passport Passport a été conçu pour résoudre deux problèmes Fournisseur didentité sur MSN +250 millions dutilisateurs, 1 milliard de logons par jour Fournisseur didentité sur Internet Un échec La leçon : la solution aux problèmes de la gestion des identités doit être différente de Passport

4 Méta-système didentité Nous avons besoin dun « méta-système didentité » pour Protéger et isoler les applications de la complexité de lidentité Permettre aux utilisateurs dutiliser leur(s) identité(s) dans un monde hétérogène Plusieurs technologies didentité Plusieurs opérateurs Plusieurs implémentations Ce nest pas la première fois où nous voyons lémergence dun tel besoin dans linformatique Emergence de TCP/IP unifiant Ethernet, Token Ring, Frame Relay, X.25, et même les protocoles Wifi pas encore inventés

5 Une nouvelle définition de lidentité numérique Un ensemble de claims qui caractérise une personne ou une « chose » (sujet numérique) dans le monde numérique Un claim est une déclaration faite sur quelquun/quelque chose par quelquun/quelque chose Un claim constitue une assertion de la vérité de quelquun/quelque chose Les claims sont exigés pour les transactions dans le monde réel et en ligne Les claims sont véhiculés dans des jetons de sécurité qui transitent entre les frontières de processus, de machines, dorganisation et de sécurité

6 Acteurs dun méta-système didentité Le méta-système didentité permet à une organisation de consommer les identités émises par une autre Dans les modèles « traditionnels », les fournisseurs et les consommateurs didentité sont confinés dans le même domaine Consommateur didentité (Relying Party ou RP) Exprime sous forme de Politique les exigences en termes didentité Une liste de claims Une liste de fournisseurs didentité admissibles Une liste des formats de jetons de sécurité recevable Fournisseur didentité (Identity Provider ou IP) Produit les jetons de sécurité au travers dun Service de Jetons de Sécurité (Security Token Service ou STS) Un service qui échange un jeton de sécurité pour un autre Les entrées et les sorties dun jeton de sécurité peuvent différer (claims, nombre de claims, émetteur, type de jeton) Définit sous forme de Politique les conditions pour produire le jeton Les crédentiels nécessaires Si le consommateur didentité doit être connu

7 Caractéristiques clés dun méta-système Négociation Permet au consommateur didentité, au sujet et au fournisseur didentité de négocier les exigences en termes de politiques techniques Encapsulation Mécanisme agnostique déchange des politiques et des claims didentités entre fournisseur et consommateur didentité Transformation des claims Mécanisme de confiance pour échanger un jeu de claims didentité en un autre indépendamment du format des jetons didentité Expérience utilisateur Interface homme – machine cohérente quels que soient les systèmes et les technologies Respect des 7 « lois de lidentité » établies au travers dune dialogue avec lindustrie…

8 Les 7 lois de lidentité 1.Contrôle et consentement de lutilisateur 2.Divulgation minimale pour un usage défini 3.Présence justifiée des parties en présence 4.Support didentités publiques et privées 5.Pluralisme des opérateurs et des technologies 6.Prise en compte de lhumain 7.Expérience cohérente entre les contextes Rejoindre les discussions sur http://www.identityblog.com http://www.identityblog.comhttp://www.identityblog.com

9 Contrôle daccès basé sur les claims Consommateur didentité Client « Passer une commande » requiert le claim {Acheteur} 1.Lecture de la politique pour « Passer une commande » 2.Appel de « Passer une commande » avec un jeton de sécurité comprenant le claim {Acheteur=True} {Acheteur=True}

10 Contrôle daccès basé sur les claims Client Consommateur didentité FournisseurdidentitéSTS_A « Passer une commande » requiert le claim {Rôle} émis par STS_A 1.Lecture de la politique pour « Passer une commande » 2.Lecture de la politique pour demander un jeton de sécurité {Rôle} requiert comme crédentiel [Nom/Mot de passe] 3.Demande dun jeton de sécurité en passant [Jean,****]

11 Contrôle daccès basé sur les claims Client Consommateur didentité FournisseurdidentitéSTS_A « Passer une commande » requiert le claim {Rôle} émis par STS_A {Rôle} requiert comme crédentiel [Nom/Mot de passe] Mappage : [Jean,****] {Rôle=Acheteur} 5.Appel de « Passer une commande » avec un jeton de sécurité 4.Demande dun jeton de sécurité en passant [Jean,****] {Rôle=Acheteur} signé par STS_A

12 Contrôle daccès basé sur les claims Client Consommateur didentité « Passer une commande » requiert {Passer une commande} émis par STS_AuthZ Fournisseur de claims didentité Fournisseur didentité STS_Identité {Rôle} requiert comme crédentiel [jeton Kerberos] ou [Nom/Mot de passe] Consommateur didentité STS_AuthZ Fournisseur de claims dautorisation {Passer une commande} requiert un claim {Rôle} émis par STS_Identité 1.Lecture de la politique pour « Passer une commande » 2.Lecture de la politique pour demander un jeton de sécurité 3.Lecture de la politique pour demander un jeton de sécurité 4.Demande dun jeton de sécurité en passant [jeton Kerberos de Jean]

13 Contrôle daccès basé sur les claims Client Consommateur didentité {Passer une commande=Vrai} signé par STS_AuthZ « Passer une commande » requiert {Passer une commande} émis par STS_AuthZ {Passer une commande} requiert {Rôle} émis par STS_Identité Consommateur didentité STS_AuthZ Mappage : {Rôle=Acheteur} {Passer une commande=Vrai} Mappage : Jean {Rôle=Acheteur} Fournisseur didentité STS_Identité {Rôle=Acheteur} signé par STS_Identité {Passer une commande=Vrai} signé par STS_AuthZ Appel de « Passer une commande »

14 Quelques scénarios dutilisation… 1 Prénom, Nom, @ mèl Carte auto- générée jeux-en-ligne.com bouquins.com RP RP IP Internaute 2 IP RP Fabrikam, Inc. Contoso Corp. Employé Fabrikam, Inc. Identité signée par Fabrikam, Inc. 4 IP RP Membre Soleil Club Membre de Soleil Club ? bon-plans.com 3 IP RP Citoyen Plus de 18 ans ? Gouvernement permis.com

15 Une architecture pour un méta-système didentité La pile de spécification/protocoles WS-répond aux besoins dun méta- système didentité STAR pour Secure, Transactional, Asynchronous, Reliable « An Introduction to the Web Services Architecture and Its Specifications » http://msdn.microsoft.com/library/en-us/dnwebsrv/html/introwsa.asp Large participation de lindustrie à sa définition Actional, BEA, CA, IBM, Layer 7, Microsoft, Oblix, OpenNetwork, Ping Identity, Reactivity, RSA, SAP, Sun, VeriSign, WebMethods, etc. Architecture ouverte et disponible sans royalties « Web Services Protocol Workshops Process Overview » http://msdn.microsoft.com/library/en-us/dnwebsrv/html/wkshopprocess.asp Neutralité par rapport aux formats de jetons de sécurité La spécification OASIS WS-Security constitue la base Agnosticité par rapport aux jetons x509, Kerberos, SAML 1.1, 1.2, 2.0, XrML, etc.

16 Une architecture pour un méta-système didentité Protocole dencapsulation et transformation des claims La spécification « Web Services Trust Language » (WS-Trust) Définit une composante clé, le Service de Jetons de Sécurité (Security Token Services ou STS) Ainsi quun mécanisme simple pour demander des claims dans des jetons de sécurité à laide de SOAP et de XML Request for Security Token (RST) Request for Security Token Response (RSTR) Est extensible Peut être « profilé » pour supporter tout jeton de sécurité répondant au modèle basé sur les claims Permet de connecter des systèmes dissemblables Définit les moyens par lesquels un jeu de claims peut être transformé en un autre jeu de claims Les fournisseurs et les consommateurs peuvent sappuyer sur un nombre N de STS

17 Une architecture pour un méta-système didentité Système dynamique pour échanger des claims La spécification « Web Services Security Policy Language » (WS- SecurityPolicy) permet dexprimer des exigences de sécurité à travers lexpression dune politique de sécurité La spécification « Web Services Metadata Exchange » (WS- MetadataExchange) permet notamment de consulter une politique de sécurité Toutes ces spécifications sont des standards de lOASIS ou en cours de standardisation au niveau de lOASIS

18 Sélecteur didentité InfoCard Permet à lutilisateur de participer dans le méta-système didentité Abstraction utilisateur simple pour lidentité numérique sous forme de cartes Fondé sur la métaphore du monde réel des cartes physiques Carte didentité, permis de conduire, carte bancaire, carte de membre, etc. InfoCard est un sélecteur didentité pour lutilisateur Plus sûr Dialogue de crédentiels Windows commun Sélection aisée des crédentiels - indépendamment de la technologie de sécurité sous-jacente Implémenté comme sous-système Windows sécurisé Interface protégée et « Durci » contre les altérations et les intrusions Usage de la cryptographie pour atténuer le risque de fraude et dattaques de phishing Quand et où ? Composant de WinFX, utilisable par nimporte quelle application (Smart client et Browser) Support dans Windows Vista et IE 7.0 Protocoles publics que chacun peut consulter Ping Identity et dautres ont annoncé le support sur Linux, Unix, Apache, et dautres plateformes

19 Expérience utilisateur Deux types dInfoCard Cartes « auto-émises » signées par lutilisateur Cartes « gérées » signées par une autorité externe Représentation visuel dune identité numérique Une carte nest PAS un jeton de sécurité Une carte contient des métadonnées pour lobtention dun jeton de sécurité auprès dun fournisseur didentité Le jeton de sécurité émis par le fournisseur didentité est soumis au consommateur didentité par lutilisateur Fait de lutilisateur un participant actif de lutilisation didentité

20 Démonstration Microsoft eCompany Store

21 Bénéfices Expérience utilisateur cohérente en termes de contrôle vis-à-vis de la communication à des tiers dinformation personnelle A travers les cartes « auto-émises » et « gérées » A travers les scénarios « A la maison » et « Au travail » (domaine et no- domaine) Aider les utilisateurs à évaluer les risques et à réduire lexposition Valider lidentité du site/service, la réputation du site/service (optionnel) Distinguer une première visite dune visite de retour Établir la confiance mutuelle entre les utilisateurs et les sites/services Authentification du site/service auprès de l'utilisateur, de l'utilisateur auprès du site/service Atténuer le phishing et le vol didentité Solution commune, basée sur la plateforme Eviter la litanie des barres doutils par-site ou des solutions spécifiques à une application Prédictible, expérience utilisateur côté client non sous le contrôle de lattaquant – Augmente la barre en termes de difficultés dattaque

22 Quest-ce quune carte ? FournisseurdidentitéSTS Fabrikam, Inc. Les valeurs des preuves sont détenues par le fournisseur didentité Name: Duponts Id Card Expires: 9/15/2006 Image Issuer: Fabrikam Supported Claims: { GivenName LastName AddressCity … } Issuer Token Service EPRs Supported Token Type: { SAML 1.1 } … Duponts Id Card Exp 9/15/2006 Jean Dupont 1306 - 2523 Fabrikam, Inc.

23 InfoCard …http://www.w3.org/2000/09/xmldsig# http://schemas.microsoft.com/ws/2005/05/identity … … …Mmq95KmzT=ZxVp… … … … [EPR][,[Auth]]… … http://schemas.microsoft.com/ws/2005/05/identity/xxx Inclus le certificat et la valeur de la signature Limage de la carte image apparaît dans « InfoCard » EPRs STS et comment sauthentifier

24 Comment tout cela fonctionne-t-il ? Applicationcliente Consommateur didentité Politique Fournisseurdidentité Service de jetons de sécurité Politique 2 Lecture de la politique définissant les preuves requises et les fournisseurs didentité : « Je souhaiterais recevoir un jeton contenant givenName et lastName dont le tokenType est SAML 1.1, émis par nimporte qui » 6 Le fournisseur didentité produit le jeton de sécurité contenant les preuves requises Jeton 1 Accès à la Ressource 7 Lapplication relaye le jeton de sécurité au consommateur didentité 4 Lutilisateur sélectionne une carte depuis la liste des identités appropriées dans le sélecteur didentité 3 Filtrage des cartes qui pourraient satisfaire les exigences du consommateur didentité 5 Le sélecteur didentité présente les crédentiels au fournisseur didentité et demande un jeton de sécurité Crédentiels

25 Protocoles utilisés FournisseurdidentitéSTS Consommateur didentité Politique Applicationcliente WS-SecurityPolicy WS-SecurityPolicy WS-MetadataExchange,WS-Security WS-MetadataExchange, WS-Security, WS-Trust

26 Implémentation Microsoft Complètement interopérable avec les protocoles publiés Avec dautres implémentations de sélecteur didentité Consultation de la politique exposée par le consommateur didentité à laide de WS-MetadataExchange Demande de jetons au fournisseur didentité à laide de WS-Trust Avec dautres implémentations de consommateur didentité Définition dune politique à laide de WS-SecurityPolicy Support du protocole WS-MetadataExchange pour la consultation de la politique Support du protocole WS-Security pour véhiculer les jetons de sécurité Avec dautres implémentations de fournisseur didentité Support du protocole WS-Trust et implémentation dun service de jetons de sécurité (STS) Co-publication avec Ping Identity dun guide de mise en œuvre détaillé « A Guide to Integrating with InfoCard v1.0 » http://download.microsoft.com/download/6/c/3/6c3c2ba2-e5f0-4fe3-be7f- c5dcb86af6de/infocard-guide-beta2-published.pdf http://download.microsoft.com/download/6/c/3/6c3c2ba2-e5f0-4fe3-be7f- c5dcb86af6de/infocard-guide-beta2-published.pdf « A Technical Reference for InfoCard v1.0 in Windows » http://download.microsoft.com/download/5/4/0/54091e0b-464c-4961-a934- d47f91b66228/infocard-techref-beta2-published.pdf http://download.microsoft.com/download/5/4/0/54091e0b-464c-4961-a934- d47f91b66228/infocard-techref-beta2-published.pdf « A Platform-Independent Guide to Supporting InfoCard v1.0 within Web Applications and Browsers » Bientôt publié sur http://msdn.microsoft.com/winfx/building/infocard http://msdn.microsoft.com/winfx/building/infocard

27 Dialogue Réputation, Identité, Politique (RIP) Lutilisateur prend la décision de faire confiance au consommateur didentité ou au fournisseur didentité Cas du consommateur didentité : lorsque lutilisateur visite le consommateur didentité pour la première fois Cas du fournisseur didentité : lorsque lutilisateur importe une carte « gérée » émise par le fournisseur didentité Données présentées à lutilisateur Sujet et émetteur du certificat, qui peuvent inclure des logos Déclaration dusage des données utilisateur Lutilisateur peut faire les choix suivants Ne pas faire confiance au consommateur didentité Faire confiance au consommateur didentité Annuler la transaction

28 Consommateur didentité Dialogue Réputation, Identité, Politique (RIP) Client HTTP/GET 2 Web Site Site(s) Web Obtention de la politique Politique 1 Vérification des condensés 3 Affichage du dialogue RIP 4 Logo du sujet Logo de lémetteur …1.3.6.1.5.5.7.1.12: http://.../ecstore.gifhttp://.../ecstore.gif + condensé http://.../ecstore.gif http://.../verisign.gifhttp://.../verisign.gif + condensé http://.../verisign.gif… Certificat inclus comme composante de la politique

29 Données InfoCard InfoCard nest PAS un jeton de sécurité mais un artefact qui représente la relation de délivrance dun jeton entre lutilisateur et le fournisseur didentité correspondant Données stockées avec chaque carte Information représentant la carte pour laffichage dans linterface Nom, ID, logo, noms des preuves disponibles (pas les valeurs) Liste des références vers les fabriques de jetons Adresse du fournisseur didentité, type dauthentification Données stockées au niveau du fournisseur didentité Local pour les cartes « auto-émises » Nom, adresse, adresse mèl, téléphone, âge, sexe Lutilisateur doit participer Données stockées au niveau de lhistorique de navigation (ledger) Relation Carte-vers-site et enregistrement des PII communiqués Données InfoCard non visibles des applications Stockées dans des fichiers chiffrés avec une clé système Exécution de linterface utilisateur dans un bureau distinct Les fournisseurs didentité sont susceptibles de stocker linformation nécessaire à la génération des claims

30 Sécurité InfoCard Objectif : empêcher la révélation de données et de clés personnelles à du code malveillant sexécutant sur le client Implémentation Service système sexécutant à un privilège élevé Stockage chiffré des données InfoCard accessible uniquement par le service système Agent de session utilisateur sexécutant sur un bureau distinct non invocable directement Affichage des secrets utilisateurs gérés par le système uniquement dans linterface de lagent de session Interaction utilisateur requise pour « libérer » des informations personnelles Lutilisateur est pleinement conscient de lutilisation faite de ses données personnelles

31 Fournisseur didentité Local Composante dInfoCard pour les cartes « auto-émises » Service de jetons de sécurité local Permet aux utilisateurs dauto-revendiquer une identité sous la forme de jetons de sécurité auto-émis dans les contextes dinteractions où cela est recevable Les données sont fournies par lutilisateur Support dun jeu limité de claims comme givenName, LastName, emailAddress, phoneNumber, etc. Les données sont stockées et chiffrées sur le disque dur local La carte « auto-émise » peut facilement être itinérante Recours à une authentification basée sur la cryptographie asymétrique Lutilisateur ne divulgue pas de mots de passe aux consommateurs didentité La clé utilisée pour la signature intègre une fonction de respect de la vie privée

32 Clé de signature des cartes « auto-émises » Clé Maître par carte Bi-Clé unique dérivée pour chaque site/service (aucun suivi possible) A et B ne peuvent pas sentendre sur la base de la clé de signature + = Graine Clé Maître + = Graine Consommateur didentité A Consommateur didentité B Paire de clés Certificat X509 utilisée pour la signature du Jeton Jeton

33 Jetons de sécurité Une collection de claims sur un sujet signée par un émetteur Dans lenvironnement InfoCard, le jeton soumis au consommateur didentité est chiffré InfoCard est agnostique en termes de jetons Il ninterprète jamais un jeton émis par un fournisseur didentité Peut inclure une preuve de possession (clé du confirmation du sujet) pour le client afin de démontrer la possession du jeton Le consommateur didentité peut spécifier dans sa politique ses exigences en termes de type de jeton, de taille de la clé, de jeu de claims Member ID: MS-62A-8421 MS-62A-8421Since: May 1998 May 1998 Expiration May 2006 Expiration May 2006 Member Level Platinum Platinum Accumulated Points: 7,901 Jeton – Chiffré à destination du consommateur didentité

34 Révélation de lidentité du consommateur didentité Jeton ouvert sans périmètre (Unscoped Token) Lidentité du consommateur didentité nest PAS révélée au fournisseur didentité Comportement par défaut Jeton avec périmètre (Scoped Token) Le consommateur didentité (ou un autre fournisseur didentité) peut demander à ce que son identité soit communiquée à un fournisseur didentité dans le schéma InfoCard dans le schéma InfoCard Le fournisseur didentité est alors en position de suivre les usages des jetons pour lutilisateur Lutilisateur est notifié que lidentité du consommateur didentité sera transmise au fournisseur didentité De façon indifférente, le jeton est chiffré à destination du consommateur didentité

35 Jeton ouvert sans périmètre Fournisseurdidentité Demande dun jeton de sécurité (RST) Consommateur didentité Génère un message de réponse (RSTR) Chiffré avec la clé du client Réponse pour le jeton de sécurité Déchiffre Jeton Jeton Chiffré avec la clé du RP Génère un message Envoie le message au consommateur didentité Exigences jeton Génère un jeton Jeton Jeton Signé avec la clé de lémetteur. Le jeton nest PAS chiffré; la clé du RP nétant pas connue

36 Jeton avec périmètre Peuvent avoir établi une relation OOB Fournisseurdidentité Identité du RP incluse dans la requête Demande dun jeton de sécurité (RST) Réponse pour le jeton de sécurité Génère un message Déchiffre Chiffré avec la clé du client Génère un message de réponse (RSTR) Génère un jeton Jeton Jeton Signé avec la clé de lIP. Le jeton EST chiffré avec la clé du RP; la clé du RP est connue Exigences jeton RequireAppliesTo Consommateur didentité Envoie le message au consommateur didentité

37 Clé preuve Clé de confirmation du sujet Le propriétaire du jeton (client) doit prouver la propriété légitime au destinataire (consommateur didentité) Clé symétrique Le fournisseur didentité génère aléatoirement une clé symétrique, lintègre dans le jeton et la transmet au client avec le jeton Le client, après obtention du jeton et de la clé symétrique, envoie un message contenant le jeton signé avec la clé preuve au consommateur didentité Clé asymétrique Le client génère une paire de clés Le client inclut une clé comme partie du message RST Le fournisseur didentité intègre cette clé dans le jeton et transmet le jeton au client Le client, après obtention du jeton, envoie un message contenant le jeton signé avec lautre clé au consommateur didentité

38 Génère un message Signé avec la clé preuve Jeton preuve : Clé symétrique Réponse pour le jeton de sécurité Vérifie la signature Fournisseurdidentité Consommateur didentité Demande dun jeton de sécurité (RST) Génère une clé (128 bits) Déchiffre Exigences jeton Type de clé: Symétrique Longueur de clé: 128 Type de jeton : SAML1.1 Génère un jeton (SAML) Inclus dans le jeton Jeton Jeton Génère un message de réponse (RSTR) Inclus comme preuve de possession dans le message Chiffré avec la clé du Client Envoie le message au consommateur didentité

39 Jeton preuve : Clé asymétrique Exigences jeton Type de clé: asymétrique Longueur de clé: 2048 Type de jeton : SAML1.1 Consommateur didentité Fournisseurdidentité Génère une paire de clés Inclus dans la demande Demande dun jeton de sécurité (RST) Génère un jeton (SAML) Inclus dans le jeton Jeton Jeton Réponse pour le jeton de sécurité Signé avec lautre clé comme preuve du jeton Génère un message Déchiffre Vérifie la signature Envoie le message au consommateur didentité Génère un message de réponse (RSTR) Chiffré avec la clé du Client

40 Autres composants Microsoft Implémentation Microsoft du service de jetons de sécurité Fournisseur didentité InfoCard pour les cartes « auto-émises » Futur : Service de jetons de sécurité gérés Active Directory Insérer les utilisateurs Active Directory dans le méta-système Ensemble complet de contrôle de politique afin de gérer lutilisation des identités simples et des identités Active Directory Windows Communication Foundation (Runtime) Pour le développement dapplications distribuées et limplémentation de services de jetons de sécurité et de services consommateurs didentité « Microsoft Federated Identity and Access Resource Kit for Sept 2005 Community Technology Preview » http://www.microsoft.com/downloads/details.aspx?familyid=66734401-4988-4ded- 9876-3dc10223052c&displaylang=en http://www.microsoft.com/downloads/details.aspx?familyid=66734401-4988-4ded- 9876-3dc10223052c&displaylang=en

41 Démonstration InfoCard Live « Hello World, InfoCard! »

42 Démonstration InfoCard Live Intégration dans Internet Explorer 7.0

43 En conclusion Les acteurs peuvent sinsérer dans le méta-système comme fournisseur, consommateur ou sélecteur didentité WS-* rend possible un méta-système didentité fondé sur des protocoles publiés largement adoptés Limplémentation Microsoft vise à fournir un support complet dun méta- système didentité ouvert dans Windows Microsoft nest pas en train de lancer le fils de Passport

44 Pour plus dinformations sur InfoCard Page daccueil InfoCard sur MSDN http://msdn.microsoft.com/windowsvista/building/infocard/default.aspx « The Laws of Identity » http://msdn.microsoft.com/library/en-us/dnwebsrv/html/lawsofidentity.asp « Microsoft's Vision for an Identity Metasystem » http://msdn.microsoft.com/library/en-us/dnwebsrv/html/identitymetasystem.asp « A Guide to Integrating with InfoCard v1.0 » http://download.microsoft.com/download/6/c/3/6c3c2ba2-e5f0-4fe3-be7f- c5dcb86af6de/infocard-guide-beta2-published.pdf http://download.microsoft.com/download/6/c/3/6c3c2ba2-e5f0-4fe3-be7f- c5dcb86af6de/infocard-guide-beta2-published.pdf « A Technical Reference for InfoCard v1.0 in Windows » http://download.microsoft.com/download/5/4/0/54091e0b-464c-4961-a934- d47f91b66228/infocard-techref-beta2-published.pdf http://download.microsoft.com/download/5/4/0/54091e0b-464c-4961-a934- d47f91b66228/infocard-techref-beta2-published.pdf « A Platform-Independent Guide to Supporting InfoCard v1.0 within Web Applications and Browsers » Bientôt publié sur http://msdn.microsoft.com/winfx/building/infocard http://msdn.microsoft.com/winfx/building/infocard « Using InfoCards for User-Centered Identity » http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20060209InfoCardK C/manifest.xml http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20060209InfoCardK C/manifest.xml Blog dAndy Harjanto sur InfoCard http://blogs.msdn.com/andyhar http://blogs.msdn.com/andyharhttp://blogs.msdn.com/andyhar R ejoignez les discussions sur http://www.identityblog.com R ejoignez les discussions sur http://www.identityblog.comhttp://www.identityblog.com

45

46 Microsoft France 18, avenue du Québec 91 957 Courtaboeuf Cedex www.microsoft.com/france 0 825 827 829 msfrance@microsoft.com