6. Considerazioni sulla privacy

Poiché il protocollo descritto in questa specifica tratta quasi esclusivamente di informazioni sul software e non sulle persone, ci sono pochissime preoccupazioni sulla privacy per il suo utilizzo. L'eccezione notevole è il campo "contacts" come definito nella Sezione 2, che contiene le informazioni di contatto per gli sviluppatori o altre parti responsabili del software client. Questi valori sono destinati a essere visualizzati agli utenti finali e saranno disponibili agli amministratori del server di autorizzazione. In quanto tale, lo sviluppatore potrebbe desiderare di fornire un indirizzo email o altre informazioni di contatto espressamente dedicate allo scopo di supportare il client invece di utilizzare i propri indirizzi personali o professionali. In alternativa, lo sviluppatore potrebbe desiderare di fornire un indirizzo email collettivo per il client per consentire il contatto e il supporto continui del software client dopo che lo sviluppatore si sia spostato e qualcun altro abbia assunto tale responsabilità.

In generale, i metadati per un client, come il nome del client e l'identificatore software, sono comuni a tutte le istanze di un software client e quindi non pongono problemi di privacy per gli utenti finali. Gli identificatori client, d'altra parte, sono spesso univoci per un'istanza specifica di un client. Per i client come i siti web che sono utilizzati da molti utenti, potrebbero non esserci preoccupazioni significative sulla privacy riguardo all'identificatore client, ma per i client come le applicazioni native installate sul dispositivo di un singolo utente finale, l'identificatore client potrebbe essere tracciato in modo univoco durante le transazioni OAuth 2.0 e il suo utilizzo collegato a quel singolo utente finale. Tuttavia, poiché il software client deve comunque essere autorizzato da un proprietario di risorse tramite una concessione di autorizzazione OAuth 2.0, questo tipo di tracciamento può verificarsi indipendentemente dal fatto che l'identificatore client sia univoco o meno correlando il proprietario di risorse autenticato con l'identificatore client richiedente.

Si noti che ai client è vietato da questa specifica creare il proprio identificatore client. Se il client fosse in grado di farlo, una singola istanza client potrebbe essere tracciata attraverso più server di autorizzazione collusi, portando a problemi di privacy e sicurezza. Inoltre, gli identificatori client sono generalmente emessi in modo univoco per richiesta di registrazione, anche per la stessa istanza di software. In questo modo, un'applicazione potrebbe migliorare marginalmente la privacy registrandosi più volte e apparendo come applicazioni completamente separate. Tuttavia, questa tecnica comporta un costo di usabilità significativo sotto forma di richiesta di multiple autorizzazioni per proprietario di risorse ed è quindi improbabile che venga utilizzata nella pratica.