識別子とプライバシーの関係〜識別子の持つべき性質
超、久しぶりにエントリする機会ができました。
経緯
@_natさんが下記のエントリを英語で書きました。
Identifier and Privacy @ =nat
http://nat.sakimura.org/2010/12/09/identifier-and-privacy/
意外にこういう記事って、日本語になっていないだけでスルーされることが多い気がするので、
下記みたいな経緯で、大したことではないですがエントリに書き起こします。
これで@masason的に「できました。」とか言えます。
この@_natさんのエントリで言っていることは、国民IDとか市民IDといった分野で使われるべきIDが備えるべき要件ってなんだろうね、という話です。
IDといっても、識別子、当人確認、身元確認、、、色々意味の異なることがありますが、ここでは識別子(Identifier)の話に限定します。
なにやら国民IDの世界では、識別子を新しく発行すれば全てが解決するという乱暴な議論がされている？というウワサですが、私はそんなに深く関わっていないのでコメントしません。
とりあえず、個人的には、特に番号に関係する下記は分けて論じられるべきテーマだと思っているという立場表明のみしておきます。
- 税と社会保障の共通番号（いつのまにか枕詞が取れたのは番号万能説のせい？）
- 国民コード（分野ごとに異なる共通番号を束ねるところ？身元確認とかどうするんでしょ。）
- ポータル（スマートカードとリーダ準備しないと使えない仕組みって、、、）
各企業に落ちてくる何兆円とも言われる国家予算の思惑もありますが、正論を言い続ける人の手伝いはしようと思います。
本題
そろそろ本題を。私の解釈で書きます。
’At Identity.Next yesterday, we had some discussion as to the desirable characteristics of the identifiers, especially in the context of National or Citizen IDs. In most cases, the use of such identifier seems to be restricted in a way that it can be used in some particular purposes. However, enforcement seems to be an issue.
普通は目的に応じた（使用できる範囲が予め決まっている）識別子があるけれども、それがちゃんと目的のみに利用されているかどうかを考え出すと監査やら色々煩わしいことがあるのではないでしょうか、ということですかね。
’The breach of the privacy can happen in various ways but we have discussed two particular form of it:
プライバシー侵害にも色々あるけど、議論が発散するので論点絞りました、と。
’1) breach by multi-party collusion/linking- two pieces of information at different locations linked together to extract an information that the person did not wish.
１）複数の関係者の結託、情報結合による侵害：
複数の関係者（主に事業者）が、あるユーザの識別子が色々なところで利用されていると、その識別子を元にユーザを相互に紐付け、本来意図していない、複合的なよりその個人を表すデータの収集が可能になってしまう。
良く言われる、サイト横断的に同じ値になる識別子を使うと、サイトごとが結託して名寄して、プライバシー侵害が起きますよ、という話ですね。
’2) breach by inter-temporal linking- two pieces of information now and past to extract an information that the person did not wish.
２）時系列な結合による侵害：
過去と現在の２つの情報を結びつけ、情報の所有者が意図しない情報を抽出するすること。
こちらは、あまり意識しない場合が多そうです。同一のサイトに対してユーザは常に同一の識別子を提示していると、過去と現在の情報をリンクされ、ユーザが望まない時系列データを生成されてしまいます。通常それを回避するときは、ユーザは別の識別子になる別アカウントをわざわざ取り直しますが、それは煩わしいですよね。
自然に理解でき、一般的にプライバシー保護、名寄せ防止などの観点で語られているものは、１）の話である場合が殆どではないでしょうか。
１）は、Federation用語で言えば「SPごとの仮名(PPID)を返す」ことで対処可能です。
PPID生成のアルゴリズムや、ドメインの変化などへの耐性はここでは論じません。ShibbolethのeduPersonTargetedIDとか、SAMLの仮名とか、Identity Metasystem InteroperabilityのPPIDとか仕様組み込みの仮名生成ロジックは沢山ありますので、参照すると良いのではないでしょうか。その他、仕様組み込みの仮名生成アルゴリズムとは別に、ユースケースにあった方法を使っているサービスは様々あります。
一方、２）に対する保護についても少し記載があります。
’As humans makes a lot of mistakes (esp. when young), some protection against 2) should be put in place as well.
The typical way of dealing with 2) is use temporal (not-permanent) identifiers such as Germans do in their new eID scheme that started this November 1, 2010.
先日スタートしたドイツのeIDでは、１）、２）ともに考慮されているとのことですが、具体的な仕様については確認していません。ちなみに、Federation仕様で仮名を考慮している場合、２）への考慮もなされている場合もあります。（例えばSAMLでは同じSPに対する仮名の洗い替えが仕様で規定されている）
’In any case, 360 degree identifier (the identifier that is permanent and that can be used for any purpose) seems to be a bad idea from the point of view of the privacy protection. From time to time such an identifier seems to be proposed to improve “efficiency” but it probably is best to avoid. It would be worthwhile to consider such a scheme that has “visible but sectoral and temporary identifiers” coupled with “invisible and strictly controlled persistent identifier”.
これは私は基本的に同意です。全てのユースケースにおいて統一的に利用出来る万能かつ永続的な識別子がもし存在するとして、大は小を兼ねるのはわかりますが、用途ごとに異なる識別子を使い分けるほうが実際は好都合な場面も多いのではないでしょうか。（とはいえ、少なくともプライバシーを犠牲して万能な永続的識別子を作ってしまう方が、実は運用は楽かもしれません。）
理想的には、識別子は用途に応じて次の２種類の性質を使い分けることが出来ればよさそうです。
- 空間的に有効な識別子（例えば様々なサービスのあるグループにおいては有効だが、別のグループでは意味を成さない識別子）
- 時間的に有効な識別子（例えばある時点では有効だが、時間が経つと意味を成さなくなる識別子）
そして当然、識別子の発行主体だけが知りうる永続的な識別子と、上記2つの性質を持つ外部に提示される識別子のマッピングが正しく行われる必要があります。
完全に一致するわけではないですが、上記の識別子の性質を考慮した仕様があります。発行主体の単位で一意な識別子ではなく、この世の全てのリソースに永続的な識別子を割り当て、システムでは永続的な識別子に対応する空間的には一意だが永続的ではない識別子を利用することを目的としたXRIという仕様です。XRIでは既存のDNSの仕組みも利用して、非常にセキュアに詐称困難な形で動的に時間的な識別子から空間的な識別子を識別子解決(XRI Resolution)できたりします。
最近少々盛り上がりを欠く印象がありますが、そろそろこういった識別子に関する議論が改めて取り上げられる時代が来たのかもしれませんね。
’It will require “identifier rotation” per the systems because they only see the temporary identifiers, but it would be a good design to do so in any case to improve the robustness of the system, just like we MUST take care of the key rotation in the systems.
最後の部分は私はあまり詳しくないので断言しにくいのですが、識別子の洗い替えを考えることは新しいことではなく、ルートCAの鍵管理などでのノウハウが転用可能ではないかということですね。
以上、意訳＋αでした。
