8月16日の「辺境から戯れ言」に次の主張がある。
「固有 ID」という言い回しは誤解を生みやすく取り扱いが難しいように思う。
私も、「固有ID」という呼び方を避けている。この日記では初日の5月5日の日記でだけ「固有ID」と書いてしまったが、これはミスで、その後は「固定ID」と書くようにしている。4月のネット時評でも、「固定ID」と書いていて、「固有ID」とは書いていない。「固有のID」という表現は出てきているが、問題ありという文脈では使っていない。
両者はどう違うのか。
まずひとつは、IDを（時間的に）固定にしないことによる解決策があるという含みを持たせるためだ。
具体的なことはこれまでの日記にたびたび書いてきた。下の1つ目のように一時的なIDを使う方法と、2つ目のようにIDにスクランブルをかける方法がある。
アプリケーションレベルの識別子は、一時的なID（セッションID）とすることができる。Webアプリケーションでは一般的な方法だ。最初に何らかの方法でユーザ認証を行った後は、一時的なIDを使って個体識別を継続する。この場合、最初のユーザ認証の時点で、ユーザの意思により個体識別を許しているので、プライバシーの問題は生じない。
RFIDチップ内に、単純増加カウンタと公開鍵暗号の演算回路と公開鍵を内蔵させる。スキャナからアクセスがある毎に、カウンタの値を1増やしながら、カウンタの値と固定IDの連接ビット列を公開鍵で暗号化してスキャナへの応答とする。スキャナ側は、スキャンする毎に異なるビット列が返ってくるので、そのままでは個人追跡には使えない。チップ内の公開鍵に対応する秘密鍵を保有している者だけが、固定IDを取り出すことができる。
これらでは、仮のID（変化するID）が外に見えているだけで、真のIDが関係者にしか見えないところに存在しており、それは固定IDである。
もうひとつは、IDのドメインを可能な限り狭くすべきだという含みを持たせるためだ。
「IDのドメインが広い」とは、例えば、「どこのサイトに行っても使えるユーザ名」がそれで、具体的には、Microsoft Passportのユーザ名や、NTTドコモのFirstPassのクライアント証明書のcommon name、EZwebの「サブスクライバID」、J-PHONEの「ユーザID」などがそれに該当する。
これは、「Webのあらゆるログインサービスで、ユーザ名が唯一の機関によって定められている」という状況に近いと言える。つまり、たとえば、Microsoftの「Passport」サービスが独占的に普及した世界を想像すればよい。Windowsを購入すると、無料でPassportサービスにアカウントを作ってもらうことができ、どこのネットショップに行ってもPassportの同じアカウントでログインするという世界だ。さらに、勤務先のイントラネットに外出先からアクセスする際にも、MicrosoftのPassportのアカウントでログインするという世界だ。
このときの「ドメイン」は、そのIDの使えるサイト全域に広がっていることになる。これは「共通ID」と呼ぶこともできる。共通IDは、どこのサイトに行っても同じ、つまり固定であるから、「固定ID」という表現は、そのような「共通ID」のことも指す意味を含ませているつもりだ。（ただこれはいまいちな表現だと思っている。きっと定着したもっとよい専門用語があるのだろうが、不勉強なのでまだ知らない。）
必要最小限のドメインで独立した固有IDが、時刻によって変化しない意味で固定のIDだとしても、それは直ちに問題ありとはならない。例えば、ネットショップなどで、その店のことを信用してユーザ登録し、自分の固有IDでログインしてサービスを受けるシステムのことを、プライバシーの問題があると言う人は少ないだろう。
必要最小限のドメインで独立した固有IDの例としては、ネットショップのユーザ名の他に、日本の住民基本台帳の住民票コードもそれに該当する。住民票コードは、民間での利用が禁じられており、行政機関における法で定められた範囲での利用しかできない*1。これは固有IDであるが「共通ID」（=「固定ID」）ではない*2。
昨日の日記で第三者cookieのことを書いた。本来、cookieは、DNSのドメインごとに名前空間が仕切られており、必要最小限のドメインで独立したものとなるよう設計されたが、第三者cookieのサイト横断的使用という予測できなかった利用形態により、「共通ID」的な利用がされるようになってしまったという話だと言える。
固有IDのドメインが、サービス提供サイトごとに独立していると、ユーザはその都度、IDを使い分け（さらにはパスワードを使い分け）なくてはならず、それが不便すぎるという話がある。だからといって、ここで共通IDを使うことにするのは、技術的に安直な方法だということを認識しておきたい。
Liberty AllianceのID-Federation Frameworkでは、サービス提供サイトごとに独立した固有IDがあることを前提とし、ユーザが自らの意思によって、自身がそれぞれのサイトに持つ固有IDを、必要に応じてそれらが同じ人のものであることを第三者機関（アイデンティティプロバイダ）に登録（アイデンティティ連携）することで、シングルサインオンを実現する。こうした仕組みを導入することで、プライバシーレベルは保たれることになる。
携帯電話のWebにとっては、ID-Federationのような仕組みを導入するのは、複雑すぎて現実的でないという議論があるかもしれない。しかし、簡略化したシステムを導入することはできるのではなかろうか。
簡略化したアイデンティティプロバイダを携帯電話事業者が担い、認証を携帯電話事業者が行う。サービスプロバイダはそれぞれに独立した固有IDの空間を持ち、ユーザとその各サービスプロバイダ用の固有IDとの対応付けを携帯電話事業者が行う。
対応付けの簡単な実現方法としては、DNSのドメインを基にして、ドメイン毎に異なるサブスクライバIDを携帯電話事業者が決めて、それをサービスプロバイダに送信するようにすることが考えられる。サービスプロバイダ側から見ると、ユーザの固有ID（= サブスクライバID）は携帯電話事業者から与えられることとなり、そのIDは別のサイトでは通用しないものであるから、「共通IDのプライバシー問題」は生じない。サービスプロバイダは、認証機構の実装を省略でき、簡単な実装でサービスを提供できるのではなかろうか。
このように、固定IDの問題は技術的に解決可能な方法が存在している場合が多い。利便性を捨てよと言っているわけではないことは、言うまでもない。
今話題となっている、固定ID単純応答型RFIDタグのプライバシーの議論は、固有IDのドメインが制限されていないところに問題の本質があるといえる。供給側の意図として特定のドメインでだけ使う固有IDのつもりであっても、それ以外のところでも使えてしまうのでは「共通ID」として働いてしまう、という話だ。
そして、技術的解決方法は存在するのだが、一部の応用分野では、低コスト化が最優先されているため、対策せずに導入されるのではないか、という懸念が出ているという話だ。