6. Datenschutzüberlegungen

Da das in dieser Spezifikation beschriebene Protokoll fast ausschließlich mit Informationen über Software und nicht über Personen zu tun hat, gibt es nur sehr wenige Datenschutzbedenken bei seiner Verwendung. Die bemerkenswerte Ausnahme ist das in Abschnitt 2 definierte Feld "contacts", das Kontaktinformationen für die Entwickler oder andere für die Client-Software verantwortliche Parteien enthält. Diese Werte sind dazu bestimmt, Endbenutzern angezeigt zu werden, und werden den Administratoren des Autorisierungsservers zur Verfügung stehen. Daher möchte der Entwickler möglicherweise eine E-Mail-Adresse oder andere Kontaktinformationen bereitstellen, die ausdrücklich dem Zweck der Unterstützung des Clients gewidmet sind, anstatt seine persönlichen oder beruflichen Adressen zu verwenden. Alternativ möchte der Entwickler möglicherweise eine kollektive E-Mail-Adresse für den Client bereitstellen, um eine fortlaufende Kontaktaufnahme und Unterstützung der Client-Software zu ermöglichen, nachdem der Entwickler weitergezogen ist und jemand anderes diese Verantwortung übernommen hat.

Im Allgemeinen sind die Metadaten für einen Client, wie z. B. der Client-Name und die Software-Kennung, für alle Instanzen einer Client-Software gemeinsam und stellen daher keine Datenschutzprobleme für Endbenutzer dar. Client-Identifikatoren hingegen sind oft eindeutig für eine bestimmte Instanz eines Clients. Für Clients wie Websites, die von vielen Benutzern verwendet werden, gibt es möglicherweise keine wesentlichen Datenschutzbedenken in Bezug auf den Client-Identifikator, aber für Clients wie native Anwendungen, die auf dem Gerät eines einzelnen Endbenutzers installiert sind, könnte der Client-Identifikator während OAuth 2.0 Transaktionen eindeutig verfolgt und seine Verwendung mit diesem einzelnen Endbenutzer verknüpft werden. Da die Client-Software jedoch immer noch von einem Ressourcenbesitzer durch eine OAuth 2.0 Autorisierungsgewährung autorisiert werden muss, kann diese Art der Verfolgung unabhängig davon erfolgen, ob der Client-Identifikator eindeutig ist, indem der authentifizierte Ressourcenbesitzer mit dem anfragenden Client-Identifikator korreliert wird.

Beachten Sie, dass es Clients durch diese Spezifikation verboten ist, ihren eigenen Client-Identifikator zu erstellen. Wenn der Client dies tun könnte, könnte eine einzelne Client-Instanz über mehrere kollaborierende Autorisierungsserver hinweg verfolgt werden, was zu Datenschutz- und Sicherheitsproblemen führt. Darüber hinaus werden Client-Identifikatoren im Allgemeinen eindeutig pro Registrierungsanfrage ausgegeben, selbst für dieselbe Softwareinstanz. Auf diese Weise könnte eine Anwendung den Datenschutz geringfügig verbessern, indem sie sich mehrmals registriert und als vollständig separate Anwendungen erscheint. Diese Technik verursacht jedoch erhebliche Benutzbarkeitsverluste in Form der Anforderung mehrerer Autorisierungen pro Ressourcenbesitzer und wird daher in der Praxis wahrscheinlich nicht verwendet.