Ce billet s’inscrit à la suite de celui-ci qui introduisait la notion d’Identity Provider.
S’enregistrer et s’identifier
Un interlocuteur A qui souhaite envoyer un message à un interlocuteur B doit s’identifier auprès de l’IDP de B (IDP2 par exemple). Il peut s’être enregistré auprès d’IDP2 au moyen d’un identifiant et d’un mot de passe qui lui sont propres, il doit alors fournir ces informations au moment de l’identification. Dans ce cas cependant B n’est pas en mesure lui même de répondre à A. Pour ce faire A pourrait avoir fourni une adresse de réponse (parfois au travers de l’identifiant).
Pour les mêmes raisons que B, A peut toutefois refuser de fournir une adresse dont l’accès en émission est libre. Il lui faut alors, pour pouvoir engager une communication à double sens avec B, se créer lui aussi un profil auprès d’un IDP. Lorsque A s’enregistre auprès de l’IDP de B (IDP2), A doit fournir un lien vers son profil chez son IDP. Il utilise un identifiant (A@idp1.com) auquel IDP2 associera les droits accordés à A par B.
Se libérer du dernier identifiant ?
Le système d’identification décrit ci-dessus nécessite de communiquer un identifiant, qui est associé à son utilisateur de manière univoque. Alors, bien sûr on communique un identifiant plutôt qu’une adresse, mais imaginons que je m’enregistre auprès de deux site de commerce sur internet avec cet identifiant, il leur sera possible de croiser leurs données me concernant, sans enfreindre les lois sur le fichage informatique, comme le souligne Hubert Guillaud, puisque l’identifiant ne permet pas de remonter à l’identité.
Tout comme il est possible en l’absence d’IDP de différencier ses adresses suivant les interlocuteurs en utilisant des adresses aliasées, il est possible de différencier ses identifiants en utilisant des pseudonymes. Imaginons que A et B veulent s’accorder des droits réciproques leur permettant de communiquer. Ils s’échangent des alias pseudoa@idp1.com et pseudob@idp2.com. L’identifiant « source », c’est-à-dire l’identifiant unique auquel sont rattachés les alias d’un profil a pour unique objet de constituer une référence stable dans le système d’information de l’IDP. Il reste privé et n’a pas vocation à être publié.
Dans le cas d’un identifiant unique il suffisait à chacun de mémoriser dans son profil l’identifiant de l’interlocuteur et d’y associer des droits. Avec l’utilisation d’alias il faut enregistrer le pseudonyme de l’interlocuteur et les droits qui lui sont accordés mais il faut aussi y accoler l’alias par lequel l’interlocuteur nous connaît. En effet l’instauration d’une communication nécessite que chacun des interlocuteurs fournisse les deux informations : qui je veux contacter et qui je suis. Cette seconde information est évidente dans le cas d’un identifiant unique mais ne l’est plus dans le cas de l’utilisation d’alias.
Ce billet ainsi que le précédent illustrent l’utilité des protocoles de gestion d’identité : ils permettent de préserver son identité (et son anonymat) et de contrôler les droits d’accès accordés à ses interlocuteurs. Et l’utilisation de pseudonymes permet de conserver la possibilité existante sans IDP de posséder plusieurs identités sans avoir à multiplier les profils chez un IDP.
30 Nov, 07 at 4:34
[…] de nos données personnelles, dont il fut question dans ce billet, permet de limiter notre exposition. Cette encapsulation connait pourtant une limite : ne sont […]
5 Déc, 07 at 7:02
[…] personnelles en sont absentes, mais est-ce vraiment une surprise ? Après avoir écrit sur la protection de l’anonymat, il eût été pour le moins curieux que je les […]