6. プライバシーに関する考慮事項

この仕様で説明されているプロトコルは、人ではなくソフトウェアに関する情報をほぼ独占的に扱うため、その使用に関するプライバシーの懸念はほとんどありません。注目すべき例外は、セクション 2 で定義されている "contacts" フィールドで、これにはクライアントソフトウェアの開発者またはその他の責任者の連絡先情報が含まれています。これらの値はエンドユーザーに表示されることを意図しており、認可サーバーの管理者が利用できるようになります。そのため、開発者は、個人または専門のアドレスを使用する代わりに、クライアントのサポートを目的として明示的に専用の電子メールアドレスまたはその他の連絡先情報を提供することをお勧めします。あるいは、開発者は、開発者が離れて別の人がその責任を引き継いだ後も、クライアントソフトウェアの継続的な連絡とサポートを可能にするために、クライアントの集団電子メールアドレスを提供することをお勧めします。

一般に、クライアント名やソフトウェア識別子などのクライアントのメタデータは、クライアントソフトウェアのすべてのインスタンスで共通であるため、エンドユーザーにとってプライバシーの問題を引き起こしません。一方、クライアント識別子は、クライアントの特定のインスタンスに対して一意であることがよくあります。多くのユーザーが使用する Web サイトなどのクライアントの場合、クライアント識別子に関する重大なプライバシーの懸念はないかもしれませんが、単一のエンドユーザーのデバイスにインストールされているネイティブアプリケーションなどのクライアントの場合、クライアント識別子は OAuth 2.0 トランザクション中に一意に追跡され、その使用がその単一のエンドユーザーに関連付けられる可能性があります。ただし、クライアントソフトウェアは OAuth 2.0 認可グラントを通じてリソース所有者によって認可される必要があるため、クライアント識別子が一意であるかどうかにかかわらず、認証されたリソース所有者と要求しているクライアント識別子を相関させることにより、このタイプの追跡が発生する可能性があります。

この仕様では、クライアントが独自のクライアント識別子を作成することは禁止されています。クライアントがそれを行うことができた場合、個々のクライアントインスタンスは複数の共謀する認可サーバー間で追跡される可能性があり、プライバシーとセキュリティの問題につながります。さらに、クライアント識別子は、通常、同じソフトウェアのインスタンスであっても、登録リクエストごとに一意に発行されます。このようにして、アプリケーションは、複数回登録し、完全に別個のアプリケーションとして表示されることにより、わずかにプライバシーを向上させることができます。ただし、この手法は、リソース所有者ごとに複数の認可を必要とするという形で大幅な使いやすさのコストを伴うため、実際には使用される可能性は低いです。