note: beaucoup de ces questions du côté WebID sont traitées dans la FAQ Foaf + ssl.
BrowserID contre WebID: la distinction est-elle réelle?
BrowserId ( spec détaillée) est une expérience chez Mozilla labs, est très nouvelle, pas entièrement définie ( la manière exacte de trouver la clé publique des serveurs de messagerie n'est pas spécifiée par exemple) et n'est pas complètement implémentée (elle nécessite le support du navigateur pour être réellement distribuée). Le protocole WebId est en cours de développement dans un groupe d'incubateurs du W3C, en s'appuyant sur le protocole anciennement connu sous le nom de foaf + ssl. Il évolue donc également. Ces deux protocoles ont été présentés lors de l'atelier W3C Identity in the Browser Workshop au bureau de Mozilla en Californie en mai 2011
De plus, il n'est pas clair que les deux projets soient incompatibles - ou plutôt n'est qu'une question de sémantique si elles le sont. On peut distinguer deux dimensions dans lesquelles elles diffèrent: une authentification et une sérialisation.
- vérification d'identité : vérification de la signature de certificat (BrowserId) ou vérification de la clé publique du sujet (WebId / foaf + ssl)
- format de certificat : formats JSON (BrowserId) ou X509 (foaf + ssl) pour les certificats
Actuellement, BrowserId a été défini par la paire (vérification de la signature du certificat, certificat JSON) et WebID / foaf + ssl par la paire (vérification de la clé publique de l'utilisateur, certificat X509) comme décrit dans cet e-mail
Mais il n'y a pas de raison logique pour que l'on ne puisse pas aussi avoir les deux autres combinaisons:
- (vérification de signature de certificat, cert X509) - c'est-à-dire une authentification BrowserId faite avec TLS
- (vérification de la clé publique de l'utilisateur, certificat JSON) - c.-à-d. authentification WebID effectuée avec des certificats JSON.
On pourrait également avoir les deux stratégies pour chaque type de certificat. C'est-à-dire que l'on pourrait d'abord vérifier la signature du certificat, puis, si nécessaire, également vérifier le WebID. Cela peut être utile pour obtenir plus d'informations sur l'utilisateur (un échange d'attributs RESTful) et il peut également être utile de vérifier que la clé n'a pas été révoquée.
La question que nous traitons ici est vraiment: quels sont les avantages et les inconvénients de l'authentification BrowserId "pure" par rapport à un WebID "pur" - également appelé authentification foaf + ssl. Veuillez garder cela à l'esprit pour le reste de cette réponse.
Comparaison de Pure BrowserId et WebId / foaf + ssl
Réponse en indiquant la situation en juillet 2011.
Comment les clés compromises sont-elles invalidées?
Dans WebID, elles sont supprimées de la page de profil. Une bonne interface utilisateur en ferait une affaire en un seul clic. L'utilisateur accède à son réseau social après s'être connecté - peut-être avec une clé unique qui lui est envoyée via son téléphone portable - et supprime la clé publique compromise, qu'il pourrait reconnaître par son nom, l'ordinateur sur lequel il l'a générée ou un autre manière qui rend les choses faciles à retenir.
BrowserId utilise actuellement un certificat JSON avec une période de validité, que le protocole souhaite actuellement limiter à très court terme. La raison pour laquelle le certificat | (JSON) doit être de très courte durée est que la partie de confiance dans la spécification BrowserID actuelle ne peut vérifier le certificat qu'en vérifiant sa signature avec la clé publique du fournisseur de messagerie. Plus le certificat est valide, plus il est probable que quelque chose ait mal tourné dans le sens - par exemple, l'ordinateur de l'utilisateur aurait pu être volé.
Mais si BrowserId devait être combiné avec WebID (ie : le certificat JSON devait contenir un nom de sujet http (s)), alors des clés plus durables pourraient être utilisées: les parties utilisatrices pouvaient vérifier que les clés n'avaient pas été compromises en vérifiant le profil public de l'utilisateur.
Comment fonctionne la prise en charge des navigateurs multi-appareils?
WebID et BrowserId peuvent avoir plusieurs clés publiques.
Avec WebID / foaf + ssl, chaque clé publique est publiée dans la page de profil, comme on peut le voir dans la vidéo "Création et utilisation de WebId en 4 minutes". Chaque appareil / navigateur peut avoir son propre certificat pour le même WebID. L'authentification de l'utilisateur se fait en vérifiant que la clé publique dans le certificat correspond à l'une des clés publiques publiées sur la page de profil WebID.
BrowserId enregistrera la clé dans le trousseau du navigateur / OS une fois que cette partie sera intégré dans le navigateur. La partie utilisatrice vérifie un certificat en vérifiant que l'émetteur a vraiment signé le certificat, et non par une comparaison octet par octet des certificats. Ainsi, n'importe quel certificat peut être utilisé, tant que la signature est authentique.
Si ceux-ci aboutissent à plusieurs clés publiques, comment sont-elles liées?
Dans BrowserId, la clé publique de l'utilisateur Le certificat est uniquement utilisé pour vérifier que le client dispose de la clé privée correspondante dans le processus d'authentification. Il n'y a pas de lien en cours.
Avec WebID, les différentes clés publiques peuvent être publiées sur la page Profil et peuvent-elles y être liées. Certaines de ces clés pourraient être décrites comme durables et donc également utilisées pour la signature et le décryptage.
Le lien doit-il être fait pour chaque consommateur?
Dans le WebID pur, chaque profil a besoin pour publier chaque clé publique. Le profil peut n'être rien de plus que la publication de cette clé.
BrowserID ne nécessite que le serveur de messagerie pour publier sa clé publique.
Comment est le support dans les navigateurs actuels?
Tous les navigateurs de bureau supportent la sélection de certificat X509 depuis 1998 environ. (à quelques exceptions près comme les premières versions de Chrome) Les téléphones portables sont plus inégaux. page wiki
Pour que BrowserId fonctionne de manière décentralisée, il a besoin du support du navigateur. Ceci est actuellement absent, mais il a une chance d'être déployé car il est pris en charge dans les laboratoires Mozilla.
L'interface utilisateur est-elle suffisamment simple pour être comprise par les utilisateurs moyens (y compris la création, la sélection, la révocation de l'ordinateur actuel et la révocation globale d'une identité)?
- Création : Dans les deux cas, c'est une affaire d'un seul clic. Avec WebID X509, les certificats peuvent être générés à l'aide de l'élément keygen html5 et d'une solution de contournement IE ActiveX. L'utilisateur a juste besoin de cliquer sur un gros bouton - voir la vidéo WebID & Browsers ou celle ci-dessus "création et utilisation d'un identifiant Web". Les interfaces utilisateur pourraient être améliorées bien sûr avec de meilleurs concepteurs Web.
- Sélection :
- WebId: la sélection est excellente sur Chrome, Safari, Opera et IE mais moche - mais pas impossible à utiliser dans Firefox. Pourquoi ils ne se donnent pas la peine de résoudre ce problème est un mystère. Veuillez voter pour le bug 396441 - Amélioration de l’interface utilisateur d’authentification client SSL. Il y a beaucoup à faire pour améliorer l'interface utilisateur, mais des navigateurs imparfaits n'ont jamais empêché les internautes créatifs de l'utiliser de manière créative.
- BrowerId: la sélection peut être conçue par le site Web, bien que cela puisse en créer davantage. risques de sécurité, et ne fournira pas une interface utilisateur d'authentification cohérente sur tous les sites (d'où un risque de physching possible)
- Révocation de l'ordinateur actuel
- WebID: la suppression des certificats X509 de l'ordinateur actuel est quelque chose qui devrait être évité, et l'interface utilisateur devrait certainement être améliorée.
- BrowserId: la révocation de l'ordinateur actuel n'est pas encore définie comme elle l'a fait pas été mis en œuvre.
- Révocation globale de l'identité
- WebID: cela nécessite simplement que la page de profil renvoie l'un des codes d'erreur HTTP si le l'identité doit être complètement supprimée, ou une redirection HTTP si le profil est déplacé, ou une relation d'identité sémantique entre l'ancienne et la nouvelle identité, ou simplement la suppression d'une des clés publiques du profil si un certificat a été volé.
- BrowserId se protège avec des certificats de courte durée (basés sur JSON)
Existe-t-il une organisation centralisée capable de suivre les utilisateurs?
- WebID: il peut être complètement décentralisé. Vous pouvez placer votre WebId sur votre FreedomBox, ainsi que tous vos amis. Vous pouvez également le placer sur un serveur anonyme si vous avez fait confiance à ce service.
- BrowserId: lorsque le magasin de certificats JSON est intégré au navigateur - et que l'on n'a plus besoin d'utiliser browserid.org, chaque e-mail le fournisseur pourrait participer. Comme les Freedom Boxes peuvent également être des fournisseurs de messagerie électronique, elles peuvent également être des autorités.
Existe-t-il des organisations décentralisées qui peuvent suivre les utilisateurs?
Des exemples de ce à quoi cela ressemblerait ?
Dans quelle mesure le suivi peut-il être détaillé?
Avec BrowserId, la partie utilisatrice récupère la clé publique du fournisseur de messagerie. Tout ce que le fournisseur doit savoir, c'est qu'un serveur a fait une requête GET. C'est quelque chose qui peut valoir la peine d'être intégré dans WebID. D'un autre côté, la partie utilisatrice se retrouve avec une adresse e-mail qui pourrait être utilisée à des fins de spam.
Avec WebID - une demande de la partie utilisatrice est effectuée sur la page de profil. Cette demande peut être effectuée de manière anonyme, via un proxy ou même un proxy IP.
Est-il facile pour un consommateur d'obtenir la bonne implémentation?
WebID sur TLS nécessite plus pour configuré pour la partie de confiance, y compris un serveur SSL. Ce serveur ne doit pas effectuer l'authentification habituelle des certificats côté client. En revanche, il est plus sûr, car il force TLS. Il existe de nombreux outils TLS qui ont été testés au fil du temps, et qui continuent à être testés.
BrowserId ne nécessite pas TLS sur la partie de confiance, il est donc plus facile à configurer. D'autre part, il y a des attaques de l'homme au milieu possibles si TLS n'est pas configuré.
(Mais à ce stade, il faut remarquer qu'il n'y a aucune raison profonde pour laquelle BrowserID et WebID ne peuvent pas à la fois utiliser le nouveau format de certificat JSON proposé et combiner leurs forces. > Comment ça marche sur les terminaux Internet sur lesquels vous ne disposez pas des autorisations pour installer le logiciel (en supposant que vous acceptiez le risque de compromission)?
Les terminaux Internet sont toujours dangereux. Seules les clés cryptographiques pourraient rendre le risque acceptable. En plaçant complètement la clé dans le matériel, le risque de vol de la clé privée est supprimé. voir WebId et le Crypto Stick. Sinon, les clés de très courte durée sont une solution de limitation des dommages si WebID ou BrowserId doit être utilisé. Les deux protocoles peuvent fonctionner avec des clés à court terme.
Peut-être qu'OpenId est mieux combiné ici avec des mots de passe uniques transmis par un téléphone portable.