6. Considérations relatives à la vie privée

Comme le protocole décrit dans cette spécification traite presque exclusivement d'informations sur les logiciels et non sur les personnes, il y a très peu de préoccupations en matière de vie privée pour son utilisation. L'exception notable est le champ "contacts" tel que défini dans la Section 2, qui contient les coordonnées des développeurs ou d'autres parties responsables du logiciel client. Ces valeurs sont destinées à être affichées aux utilisateurs finaux et seront disponibles pour les administrateurs du serveur d'autorisation. En tant que tel, le développeur peut souhaiter fournir une adresse e-mail ou d'autres coordonnées expressément dédiées au support du client au lieu d'utiliser ses adresses personnelles ou professionnelles. Alternativement, le développeur peut souhaiter fournir une adresse e-mail collective pour le client afin de permettre un contact et un support continus du logiciel client après que le développeur soit parti et que quelqu'un d'autre reprenne cette responsabilité.

En général, les métadonnées d'un client, telles que le nom du client et l'identifiant logiciel, sont communes à toutes les instances d'un logiciel client et ne posent donc aucun problème de confidentialité pour les utilisateurs finaux. Les identifiants client, en revanche, sont souvent uniques à une instance spécifique d'un client. Pour les clients tels que les sites Web qui sont utilisés par de nombreux utilisateurs, il peut ne pas y avoir de préoccupations importantes en matière de confidentialité concernant l'identifiant client, mais pour les clients tels que les applications natives installées sur l'appareil d'un seul utilisateur final, l'identifiant client pourrait être suivi de manière unique pendant les transactions OAuth 2.0 et son utilisation liée à cet utilisateur final unique. Cependant, comme le logiciel client doit toujours être autorisé par un propriétaire de ressource via une autorisation OAuth 2.0, ce type de suivi peut se produire que l'identifiant client soit unique ou non en corrélant le propriétaire de ressource authentifié avec l'identifiant client demandeur.

Notez que les clients sont interdits par cette spécification de créer leur propre identifiant client. Si le client était capable de le faire, une instance de client individuelle pourrait être suivie sur plusieurs serveurs d'autorisation complices, entraînant des problèmes de confidentialité et de sécurité. De plus, les identifiants client sont généralement émis de manière unique par demande d'enregistrement, même pour la même instance de logiciel. De cette façon, une application pourrait légèrement améliorer la confidentialité en s'enregistrant plusieurs fois et en apparaissant comme des applications complètement distinctes. Cependant, cette technique entraîne un coût d'utilisabilité important sous la forme d'exigence de multiples autorisations par propriétaire de ressource et est donc peu susceptible d'être utilisée en pratique.