<前の日記(2003年08月16日) 次の日記(2003年08月19日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 2135   昨日: 2967

2003年08月17日

「固有ID」の問題なのか「固定ID」の問題なのか

8月16日の「辺境から戯れ言」に次の主張がある。

「固有 ID」という言い回しは誤解を生みやすく取り扱いが難しいように思う。

私も、「固有ID」という呼び方を避けている。この日記では初日の5月5日の日記でだけ「固有ID」と書いてしまったが、これはミスで、その後は「固定ID」と書くようにしている。4月のネット時評でも、「固定ID」と書いていて、「固有ID」とは書いていない。「固有のID」という表現は出てきているが、問題ありという文脈では使っていない。

両者はどう違うのか。

まずひとつは、IDを(時間的に)固定にしないことによる解決策があるという含みを持たせるためだ。

具体的なことはこれまでの日記にたびたび書いてきた。下の1つ目のように一時的なIDを使う方法と、2つ目のようにIDにスクランブルをかける方法がある。

  • IPv6の匿名アドレスはどう運用されるのか, 5月25日

    アプリケーションレベルの識別子は、一時的なID(セッションID)とすることができる。Webアプリケーションでは一般的な方法だ。最初に何らかの方法でユーザ認証を行った後は、一時的なIDを使って個体識別を継続する。この場合、最初のユーザ認証の時点で、ユーザの意思により個体識別を許しているので、プライバシーの問題は生じない。

  • 「これはいたずらな不安の煽りである」という合理化, 6月29日

    RFIDチップ内に、単純増加カウンタと公開鍵暗号の演算回路と公開鍵を内蔵させる。スキャナからアクセスがある毎に、カウンタの値を1増やしながら、カウンタの値と固定IDの連接ビット列を公開鍵で暗号化してスキャナへの応答とする。スキャナ側は、スキャンする毎に異なるビット列が返ってくるので、そのままでは個人追跡には使えない。チップ内の公開鍵に対応する秘密鍵を保有している者だけが、固定IDを取り出すことができる。

これらでは、仮のID(変化するID)が外に見えているだけで、真のIDが関係者にしか見えないところに存在しており、それは固定IDである。

もうひとつは、IDのドメインを可能な限り狭くすべきだという含みを持たせるためだ。

「IDのドメインが広い」とは、例えば、「どこのサイトに行っても使えるユーザ名」がそれで、具体的には、Microsoft Passportのユーザ名や、NTTドコモのFirstPassのクライアント証明書のcommon name、EZwebの「サブスクライバID」、J-PHONEの「ユーザID」などがそれに該当する。

  • 通信キャリアの独占型PKIは安全なのか

    これは、「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」として働いてしまう、という話だ。

そして、技術的解決方法は存在するのだが、一部の応用分野では、低コスト化が最優先されているため、対策せずに導入されるのではないか、という懸念が出ているという話だ。

*1 ことになっている。

*2 ただし、本当にドメイン範囲が必要最小限になっているかという議論の余地は残る。

検索

<前の日記(2003年08月16日) 次の日記(2003年08月19日)> 最新 編集

最近のタイトル

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|
<前の日記(2003年08月16日) 次の日記(2003年08月19日)> 最新 編集