ちょっと仕事で Janino を使うことにしたので、イロイロと検索して調べていたのですけどね....

Janino Oro

いいでしょこれ。オープンソースの Java のライブラリ・プロジェクトが２つですよ！　曲はどうやらマケドニアのフォークダンス音楽で「Jana（女性名）の踊り(oro)」という意味みたいです。タダの偶然ですけども、一方は正規表現ライブラリ(Apache)、一方はミニJavaコンパイラ(Codehaus)と、とりあわせが妙なあたりが気に入ります。こういう偶然って和みますね。

ホントはね、「Janino ORO」でググると私が昔書いた Log4j の解説もひっかかります。偶然 Janino と ORO を同じページで扱っていたんです。ヘンなご縁です...ちなみに 没になったLog4j 1.3 のSMTPAppender の送信基準で、jakarta-ORO を使っていて、1.3 のその後である Logback では Janino に変わってるんです。私コレで Janino を憶えましてね....意外な相性？

とはいえ、Janino は Java6が普及したらどうなるんだろ....あっちは標準ですしね。まあ今回 Java5 なので Janino なのが順当なところですけどね。

私は関心があるので、注目してたりするのですが、一般には Codehaus の知名度って（傘下プロジェクトの知名度に比して）メチャ低いようにも感じます....プロジェクトで使う時に、「Apache だから大丈夫です！」と言う（タダの説得のレトリックに過ぎません）みたいに、「Apache が大丈夫なら、Codehaus だって大丈夫ですよ！」と....言って、みたいな！（ちなみに、Codehaus 傘下は、Jetty, Groovy, Castor, Jaxen, Woodstox, JRuby...etc,etc,etc... とJava 専門ですけども、凄いでしょ）

ちょっと例の Fiat-Shamir 認証のデモプログラムを土日に書いていたのですが、この Fiat-Shamir 認証のキモというのは、

平方剰余問題は、法が合成数の場合、とっても難しい....

ということにあります。ですから、

x2 = 巨大数 (mod 巨大素数同士の積)

のとき、巨大数が判っても、x は判らない....ということになるわけです。ですから、この２つの巨大数（法と自乗値）を公開してもＯＫなのです。この２つの巨大数を使って、証明者が提示する証明を、証明者から渡された自乗の値と、認証者が自分で計算する自乗の値とが一致することで確認できますが、それでも、

絶対に証明者の秘密の数である x は判らない

ことが保証されるわけです。

まあ、まず最初のデモは、とりあえず巨大数じゃなくていいです。そっちの方が簡単にチェックできるでしょ。しかし、ここにちょっとしたトラップがあります。

x2 の桁数は？

という問題なのですね。モダンな言語を使い慣れていると、

int x = getInt();
int x2 = x * x;

なんて、気楽に書いてしまいがちですが、このコードに潜む危険性をしっかり理解してないと、ハマりますよ.....それはですね、当然、

x が √Integer.MAX_VALUE を超えていたらどうするの？

という問題ですよね！ 私なんかの世代はアセンブリの経験があったりしますから、

MOV AH, byte ptr [BX]; 掛ける数は byte
MUL AH, AH
MOV result, AX ; 結果は word

と、

byte × byte ＝ word(2byte)
word × word = dword(4byte)

と「掛け算だったら結果格納にメモリは２倍必要！」というイメージがそもそもあるわけですけどもね....そういう視点で、

じゃあこの Fiat-Shamir 認証のサービスを記述するのは、どの言語でやればいいだろう？

というのが、実は大問題になるわけです。早速結論を言ってしまいますが、それは

Ruby か Python

です。この手のスクリプト言語なんて

本質的にはドレもコレも同じ....

という印象を持ちがちですが、ここで Ruby(or Python) を強力に推薦する理由がアルのですね。それは、

数値型は、それが FixNum(31bit or 63bit の固定長)の表現範囲を超える場合、自動的に BigNum(無限多倍長整数)に拡張される

という、非常に都合のイイ性質を持っているのです！

一番最初、私はこのサービスを、Perl で書いた（一番慣れてるし）のですが、これ、

値を自乗すると、微妙に渡された正しい値と違う...

という現象に出くわして、「！」となったわけです。つまり、Perl は、

数値をウラでは浮動小数点値として計算する

という仕様にひっかかっているわけです。他の p言語と合わせて表にすると、

Ruby	FixNum と BigNum を自動で使い分ける
Perl	すべてウラではFloat
PHP	31bit固定
Python	整数型と長整数型を自動で使い分ける

ですから、Ruby か Python がよろしい....という結果になるわけです。ですから、本番の巨大数(256bitくらいは必要)を扱う場合でも、BigNum な値を透過的に変換する言語ならば、

一切コードの変更も要らない！

となるわけです...こういう言語選択の基準もあるわけですよ。

って意外に意識してるのかもしれません。というのは、特に rel-tag マイクロフォーマットかな？

rel-tag はタグを付けるものなのですが、rel="tag" とアンカータグにでも付けるだけで、マイクロフォーマット的には「rel-tag マイクロフォーマット」と認識されてしまいます。このブログもタグクラウドに実は rel="tag" と入るデザインになっているのですが、rel-tag が「この話題に関連のあるタグ」を示すという用途のマークアップですから、たかが「このブログの筆者が他の話題についてつけた（かもしれない）タグ」とは意味が違うわけです.....つまり、

タグクラウドには rel-tag マイクロフォーマットを付けるな

というのが正しい使い方になるわけです。

とはいえ、このパソナブログでのタグクラウドは、単にこのブログ内部での、このキーワードを検索するためのインターフェイスである search.php へのアンカーになっているに過ぎません。で、この search.php は

REST なんて知らないよ...

という（古いというか逆説的にうまい）設計になっています（苦笑）。で、

rel-tag マイクロフォーマットをちゃんと動かすためには、そのアンカーが指す URL （href属性値）が、RESTful な URL であること

というのが、暗黙の前提になっています。言い換えると、rel-tag マイクロフォーマットでは、

href属性値の、URL のスラッシュ区切りで、パスの最後の部分だけが、「タグ」として認識される

ことになっています。ですから、このブログのような

/search.php?tag=microformats&blog_id=48

のような RESTless なURLは、たとえ rel="tag" でマークアップされていたとしても、正しく rel-tag として扱われることはなく（「search.php」をタグだと誤認します）て、たとえば、

<a href="/search.php/microformats" rel="tag">マイクロフォーマット</a>

とマークアップされていた時に限って、

microformats というタグ（「マイクロフォーマット」というタグではなくて）を示している

と認識されるわけです.....

ですから、逆に言えば、

たとえ日本語のタグであっても、RESTful に URL に明示的に畳み込んで（勿論マイクロフォーマット的に正しいエンコーディングで）構築するような、RESTful なサービス

が、rel-tag マイクロフォーマットとの親和性がいい、ということになるわけですよね。

まあそういう仕様になっているものというと、例によって、

• Technorati
• Frickr
• Wikipedia

というあたりになってくるわけです（amazon はタギング兼用を考えると少し使い勝手が悪そう）....としてみると、Wikipedia へのリンクを私は多用してますが、結構これ、

このページのタギングを、実質上 Wikipedia へのリンクに与える

というのは、使えるタギングの方法論かもしれません。

まあどうせ、URL で日本語が使うことがそのうち当たり前になり、特にエンコーディングを気にしなくて透過的に扱えるようになるでしょうから、見た目的にも判りやすいタギングの手段ということになるかもしれませんね！

さらに、自分で何かのサービスを立ち上げる時に、このような

マイクロフォーマットへの親和性を理由にして、RESTfulな設計を心がける

というモチベーションになるのかもしれません...普及こそまだイマイチですけども、立ち位置という面で、マイクロフォーマット＆REST の重要性は見逃せないという印象を強く受けます。

マイクロフォーマットに関心のある方には結構有名な話ですが、

マイクロフォーマットを扱う Firefox のアドオンである Operator が、Firefox3 だと、

Firefox3 で導入された、新しいマイクロフォーマット対応のための JavaScript インターフェイスの使い方でちょっとばかり問題がある...

ために、一部のマークアップが動かなかったのですね。

まあ、このマイクロフォーマット機構を、ブラウザとしてキッチリ対応するかどうかで、結構もめてたようです。ですから、とりあえず Firefox 3 （の初回リリース）では対応しないことになって、結局そのための JavaScript インターフェイスだけが実装されて...という中途半端になったわけで、

中途半端にはバチが当たる

という経験則を実証しちゃったことになりました。まあ、それ知ってたこともあって、Firefox3 に乗り換えるのを私は後回しにしていたのですが、どうやら今の分(3.01)では直っているようです。ふう....ちょっとした情報まで。

参考：Firefox3でもmicroformat Operator や hFeed を有効にする方法

そういや Firefox3 って、日本語URL が URLエンコーディングの % でエスケープされた格好じゃなくて、日本語で表示されるんだ.... 何か気持ちが悪いです。ネットで2バイト文字を使うな！で育ちましたから....
http://www.ittworks.co.jp/hibilog/2008/07/firefox3でようやくurlに日本語が使えるか/

 

って、知ってる人は知ってるでしょ、数独（あるいはナンプレ）です。

私ってペンシルパズルは大好きなクチです（というか私の母も好きなんです...血筋かな？） こういうのを見ると、

4	2	7	1	5	9	8	6	3
8	3	5	7	6	4	2	1	9
1	9	6	3	8	2	4	7	5
6	4	9	5	7	8	1	3	2
3	8	1	9	2	6	7	5	4
7	5	2	4	1	3	9	8	6
5	7	4	6	9	1	3	2	8
9	1	8	2	3	5	6	4	7
2	6	3	8	4	7	5	9	1

とついつい数独なのは、

数に毒されてる？

のかもしれませんが、実はこういうかたちで、直交表を作っても別にいいじゃない...ということなんですね。要するに数独も直交表も、数理的にはラテン方格なのですから

数独の正解を 9**3 = 729 通りの組み合せを 81 通りで済ます実験の組み合せ

と見て悪いわけがないのです....これで実験計画してもＯＫですよ（まあ、そういう実験があれば、の話ですが...）！

ラテン方格の数理自身は例によって

どこでも出てくるオイラー

が最初に考えたものですが、実験計画法として採用したのが、一般知名度が低いのが私個人としてはかなり残念なロナルド・フィッシャーです。フィッシャーというとこの実験計画法と分散分析が統計学での重要な業績になります。統計学というと、

巨大なデータを集積して「客観的な事実としての現象」をあらわにして、結論するのが統計学だ！

というイメージ（ゴールトン＆ピアスン的なイメージですが）がありますが、フィッシャーの方法論がその逆方向というか、

可能な限り少ないデータからでも、正確な推計が可能なようにやり方を考える

という方法論なのがとても面白いあたりです。統計対象の客観的実在性（というかそれの認知可能性）にこだわらないあたり、ベイズ統計に哲学が近い感じかな。この人統計学意外にも多彩な業績があって面白いです。たとえば、

フィッシャーの情報行列

これシャノンの情報理論のエントロピーと似たような概念を、シャノンの２０年前に見つけていたりします...

ランナウェイ仮説

集団遺伝学の仮説の一つで、何か有利な形質と偶然結びついた雌雄選択の上での指標となる形質があったとき、その結びつきが一度雌雄選択の基準となってしまうと、有利な形質と指標の形質の結びつきが解かれた場合でさえも、指標となる形質を選好する傾向が暴走することがある、という説。明らかに生存競争上では不利に働くような性質が、種によって独自に発達しているケースがこれによって説明される。

とか、学者としての魅力十分じゃないかな...などと思ってます....まあ、統計学自体２０世紀前半では心理学とも生物学とも応用数学とも社会政策学ともつかない、微妙に学際的な立場にあったあたりの面白みが出ているわけですね（逆に優生学という陰の部分も強烈にあるわけですが....）。

ゼロ知識証明で、情報が漏れない根拠をごく単純に言うのならば、

ランダムに選択された e ∈{0,1} を認証者が送りつけ、それに応じて証明者が送るべき値が決まること

ということになります。言い換えると、

認証者が送りつける e の値が予測不可能だから

ということなのです。コンピュータにおいて、

ランダムさ、というのは実は非常にポジティブな働きを持つことがある

という可能性が面白い...と思ったりしませんか？ 勿論、これをうまく活用しているのはセッションキーとかRSA暗号（の巨大数の素数はたくさんあるので、「どれか」がランダムに近い）ですし、あるいは

ハッシュ値はランダムに近いほど、ハッシュテーブルの利用効率が高くなる

とか、いろいろあるわけですが、これもそういう「ポジティブなランダムさ」の一つです。

しかし逆にコンピュータは状態機械ですから、それ自体の中にランダムさを持つことが実質難しいわけです。何か外部に「ランダムさの発生源」が要るわけです。ＣＰＵにこれを内蔵する...という設計もあるくらいですが、一般的には

キーボードを打って、その間隔をランダムのソースとして使う

ことをランダムネスの発生源にするケースがほとんどです。

しかし、たとえば「ゼロ知識証明を使った認証システムを作る」となったとき、

ランダムさのクォリティが高ければ高いほど、安全である

というのもまた事実です。そうしてみると、

外付けユニットとして、「ランダム・リソース・ジェネレータ」とか（苦笑）

が現実に出てきてもいいのかな？ これ固く言うと

タダのチューリングマシン＋ランダムオラクル＝神託機械

になって、「機械としての理論的なモデル」が変わります... ですからたとえば、

ごく少量の放射性物質を内部に持ち、その崩壊による放射線を検出して、その間隔をランダム値とする

というユニットだと、実現は簡単で理屈はバッチリ通るのですが、放射性物質の管理は困りものです（困った）。だったら、

宇宙から飛来する宇宙線を検出して、それをランダムのリソースとする

ってどうでしょう？ 宇宙線をネタにしたアートだってあります（逢坂卓郎）から、不可能ではないですよね....

そういえばゼロ知識証明の話で...

実は最初にゼロ知識証明を定式化して報告した論文

Shafi Goldwasser, Silvio Micali, Charles Rackoff, "The Knowledge Complexity of Interactive Proof-Systems (Extended Abstract)",

の筆頭者の Shafi Goldwasser は女性だったりします（ご本人のHP）....MITの教授で凄い人（ゲーデル賞２回受賞）です。コンピュータ科学というと、勿論グレース・ホッパーという女性著名人もいたりしますから、意外に女性が参入しやすい分野なのかもしれませんね。

女性科学者って私尊敬している人がいたりします....やはり理論面で凄い業績を挙げている人だと、

女性に理論家は....

という偏見を打ち壊す重要な貢献でもありますしね。そういう意味だと、たとえば、物理学だと実験のキュリー夫人よりも、その直後の世代で

リーゼ・マイトナー：核分裂の機構を最初に解明。核分裂によるエネルギーの放出をアインシュタインの式 E=mc2 に関連付けて最初に説明した人。

がいますし、あるいは生物学で非常に理論的に重要な業績を挙げたというと、

リン・マーギュリス：細胞内共生進化説を提唱し、真核生物は他の細菌を細胞内に取り込むことで、機能アップしたとする説（現在ほぼ証明済）。葉緑体やミトコンドリアはかつて自由生活をしていた細菌のなごりである。

がいます...ここらへんの人だと科学史に完璧に残るレベルの業績でしょ。

まあたまにはこういう気楽なエントリもいいかなぁ。

 

私は大学時代には心理学でしたから、いわゆる「実験計画法」というのにはそれなりに馴染んでいたわけです。プログラマをしだして、それが本業というわけではないのですが、やはり成り行きで、

ある程度は系統的なテストをしなきゃならない時

というのはあるわけです。勿論全部のカバレッジするようなテストができればいいのですが、スケジュールの都合でできないこともあるわけです....そうすると、

実験計画法のアイデアを活用して、最小限のテスト回数でやりゃあいいじゃん！

と思うのは経歴から見て当然です。私は開発ですから、どっちか言えば厳格な意味でのソフトウェアテスト業界にはうといのですが、

きっと実験計画法をうまく応用したテスト手法があるに違いないよね...

とずっと昔から思い続けていたのです。

で勿論実験計画法を応用したテスト方法論というのはあって、特に

直交表法とかタグチメソッドとかHAYST法とか

あるようです。まあ、これがあるのは当たり前で期待通りなのですが、しかしどうやら、これ、意外なことに最近の流行のようです....私なんぞは一番最初にプログラムを書いたのが、心理学実験用の統計処理だったくらいですから、

統計学とプログラミング

というのは経験上すごく近くにあるもののようにイメージするのですが、どうやら世の中はそうではないようです。しかし、最近の「集合知プログランミング」とかそういう話題が流行するようになってきて、ちょいと世の中が私の方に近づいてきたのかも....ちょっと知識を仕入れてみよ！たとえばこんなのかな？

ソフトウェアテスト入門（技評）

たとえば、テストファーストで開発するときに、ランダムにいくつかの直交表を選んでその都度違う内容でテストされる、ってどうかな？カヴァレッジ率が上がるじゃん...

 

 

、といいのですが（苦笑）。このエントリでは、ゼロ知識証明によるログイン認証のやり方（たとえば Fiat-Shamir 認証　このPDFの２８ページ以降にきっちりした説明があります）を紹介します。このやり方で認証すれば、

たとえ認証の全プロセスが盗聴されていたとしても、一切パスワードが漏れず、盗聴者が所有者に成り代わってログインすることができない

という魔法のようなことが出来てしまうのですよ、実は。

ただし、このゼロ知識証明は、「対話証明」と呼ばれるやり方で、

一度パスワードを提示して終わり

というものではないのです。何回かのやり取り（ＩＤのビット数分の回数で充分ですが）を行って、全体で「知識がない場合、これをすべてパスする確率は極めて小さい...」となるというものです。けど、皆さんそういわれても

信じれない！

という方がほとんどじゃないでしょうか？？ そういう方はまず Wikipedia のゼロ知識証明の項をお読みになるといいのでは。

ゼロ知識証明の研究は、ある人が秘密の知識（パスワードなど）を所持していることをもって本人であることを他の人に示したいがこの秘密自体は誰にも開示しなくてよい認証方式を実現することが動機である。（略）ゼロ知識証明の応用例には、公開鍵暗号、デジタル署名、ユーザ認証などがある。（略）個人情報を用いてユーザ認証を行う場合、ユーザはゼロ知識証明のプロトコルに従い、個人情報を入力する。健全性があるので、ユーザは真正な入力でないと正しさを証明できず、そしてゼロ知識性があるため、個人情報そのものは漏れることはないことになる。

と書かれてます....このページにもある「洞窟の問題」を読むとイメージが沸くと思います。どうです、納得していただいけました？

ですから、ゼロ知識証明を応用したプロトコルを使えば、見せ掛けの偽 Web サイトを使った「パスワード盗み」は事実上不可能になるわけです....だったらフィッシング詐欺は怖くないでしょ。ここでのやり取りをいくら記録したところで、その情報を元に真正な Web サイトにログインできるわけがないのですから。実はOpenID でも、

ひょっとして、サービス提供者がホントに認証サーバにリダイレクトしているのではなくて、見せ掛けの偽認証サーバに送ってるとか、あるいはプロキシ動作をして、送られるリクエストを横取りしてる？

とか、心配しませんか？ これら、全部手口としてアリです。ですから、

1. 1. アドレスバーに表示されるURLを真剣に確認する
2. 2. SSL証明書の発行先を確認する（出来れば本来の発行者を記憶しておくといいのでは？　ベリサインだと法人登記による証明が必要ですから、少なくとも「実在する法人である」ことの証明力はありますよ）

というあたり、実は

OpenID を使う上での必須項目

じゃないかと思うのです（たとえばYahoo! でも「Yahoo! JAPANのログインページが正しいかを確認するには」でちゃんと警告しています）が....が、ちゃんと実践してます？

しかし、ゼロ知識証明を使ったログイン認証が普及したら、

ログインのプロセスをどう監視しても、パスワードを取得できない

ということになるわけです。ですから、これ

個人の注意力とか、警戒心に訴えるのではなくて、システム的に悪事を働くことを極めて難しくする

という「正しいアプローチ」なのでは..と私は思うのです。

まあ、ゼロ知識証明によるログイン認証の普及という面では

1. 1. ブラウザでBigDecimal な重い計算をさせる必要がある。
2. 2. 対話認証なのでリクエスト・レスポンスが一回で済まず、トラフィックが増える（Ajaxでやればいいのかな？）。
3. 3. 安全性を考えると、やや長いパスワードである方がいいから、手で入力するのが難しいか？ できればブラウザで保持したくないよね...
4. 4. レガシーなアカウント・パスワードのやり方とは全然違うので、ユーザに心理的な抵抗感があるか？
5. 5. 普通のブラウザを使う場合は、自前の「パスワードを直接は絶対送らない」ページからログインすることになるから、少し使い方が違うなぁ....

というあたりが問題かもしれませんが....とはいえ、OpenID が流行するのならば、いっそこと「ゼロ知識証明もあります、どう？」というのを広める必要があるのかもしれません。

 

ひょっとしたら常識？かもしれませんが...

同僚の質問：
Tomcat ＆ struts で URL が
http://www.domain.jp:8080/con/enter/login.do
のとき、/con は ContextPath です。では、/enter/login.do は何と呼ぶのでしょう？

というものでした...あれ？

確かに ContextPath はしょっちゅう使うのでおなじみです。ついつい

var URL = "<%=request.getContextPath()%>/next/next.do%>";

とか書いちゃいますから、これを知らないことはないのですが....その後半は？

まあ、ContextPath という概念自体、Tomcat（というか、Java の Application Server ）の独自の仕様です。要するに Tomcat へデプロイするための単位ですからね。非Java の Web サービスではこういうのはありえないです....ですから、Tomcat でこれを使わなければ、ほぼ

独自に名を呼ばれる価値

はないわけです....が、一応名前は調べるとありました。別に凄い名前じゃなくて、ありふれた

ServletPath

という名前です（request.getSErvletPath() でアクセスできます）。ふう、使用頻度が低いものって、知らないものですね....

とはいえ、調べる前は、

ひょっとしてこれ、PathInfo では？？？

などと思ってしまいました。というのは、これは

Tomcat を大きなサービスと捉えると、アプリケーションの実体は ContextPath で表されるものなので、その残りはサービスの詳細を特定する PathInfo（みたいなもの..）なのかな？

なんて考えちゃったんですね。まあこれ、最近の REST の流行で PathInfo を活用して

URL の中でどれがサービスでどれがパラメータなのか、そういう実装は気にしないように！

というスタイルに慣れてきている...ことにも影響を受けている、のかな？などと。

以前も取り上げたことがあるのですが、Java の M(X)Bean による管理(JMX)の話です。

非同期なタスクを専門で処理させるプロセスを立てて、Web アプリ側ではその処理の依頼をするだけ....という格好で構築しているのですが、この非同期処理を java.util.concurrent.ExecutorService が実現するワーカスレッドで動かしています.....で、以前はこのワーカスレッドを

どうやって、graceful に終了させるか？

という問題を解決するために、M(X)Bean を使ってみたわけです。

....結構これ好評でした（Thanks）。で、その延長線上として、

1. 1. 今処理が忙しいかどうか問い合わせて、忙しかったら予約実行・忙しくなかったら即時実行...とできるというのもいいな。
2. 2. 管理の補助手段として、イマの JVM の状態をモニターできたらいいな。

というようなネタが上がってきました。で、これらもやっぱり

M(X)Bean で行こう

というのが今回のネタです。

まあ、1. は実際には現在の処理中スレッドをモニタする問い合わせを新規に作るわけですから、以前のシャットダウンと同じような話です。でも、実装するとリアルタイムに処理状況をモニタできて、すごく楽しいです（笑）。

問題は 2. ですね。実はですね、これうまくやれば、

• 空き物理メモリの量
• 最後に GC してからの経過秒
• ヒープのサイズと使用率
• デッドロックしているスレッドがあるか
• メモリPool の個別(Eden/Suvivor/Tenured/CodeCache/PermGen)の割り当て量と利用率

というような、管理＆チューン項目が、ごく簡単に手に入ってしまうのです。

これらの項目は、JDK1.5 以降に付属する jconsole というツールで確認できるものなのですが、

運営サーバはファイアウォールに守られたドメインの奥深くだから...

でも、通常の Webサーバに管理を追加して、あるいは、HtmlAdaptorServer を使えばそのままで...で HTTP による管理が出来ちゃうわけです。結構コレ凄い..というか、そもそも、

jconsole は単なる MXBean のブラウザに過ぎない

という設計の良さが光りますね。まだ、jconsole を使ったことがない方は一度使ってみると、

....この機能を Web アプリから見れたらイイな！

と思うのではないかと思います。それ、すごく簡単です。ぜひぜひやってご覧あれ。

 

openID ネタです....結構 openID がらみのサービスが増えてるようですが、以前のエントリでも紹介しましたが、openID には、

勝手に認証サーバ(IdP)を立てることができるが、その認証サーバが厳格でまっとうな認証をしてくれるかどうかの保証がない！

というちょっと厄介な性質があります。ですから

1. 1. 「悪い」認証サーバの情報を公開し、それに従って判断する（ブラックリストタイプ）
2. 2. 一部の有名で信用できる認証サーバ以外は、サービス(Consumer)が利用しない（ホワイトリストタイプ）

....でまあ、どうやら openID の「現実の利用」は 2. になりそうです....

前者ならばやはりOpenIDアプリの側でOpenID URLごとにアクセスコントロールする必要があります。繰り返しになりますがアプリ制作者側の 支持はあまり得られないように思います。後者ならば長期的に見て資金力がありブランディングに成功したプレイヤーにidentity provider が集約され得るということです。それはプロトコルの策定過程がオープンだったというだけでMicrosoft PassportやGoogle AuthSub APIと変わりありません。 （opeID-ja のディスカッションの中から..）

そうなるとオトナな事情を主な原因として、

「すべて」のＩＤ・パスワードを単一にする

というのが実現できなさそうな雰囲気が漂っている（まあ、それでも使う人はいるわけですが....）というのが現実、なのですね。

ちょっといろいろと考えたのですが、この openID って、実は本質は、

サービス(Consumer) に、認証サーバ(IdP)の認証情報を提供するが、しかし、一切の認証情報がサービス側には漏れない

という状態であれば、全然問題がないわけです。Delegate のややこしい仕組みに何か惑わされがちですが、実際

○○のアカウントでログインできます

を謳う「パチモンOpenID対応サービス」も世の中にはあって（「OpenIDの普及がフィッシングサイトを助長する？」）、それだと「本当の○○のアカウント」を要求し、サービスが開示されたアカウント情報を使って、○○のサービスに実際にログインを試行して、自身のサービスへのログインを許可する...というものだってあるわけです。

勿論この「パチモンOpenID対応サービス」は、そのアカウント情報を「内部で保持しない」という紳士協定で動いているものですから、悪用しようと思えばいっくらでも出来てしまうわけです....勿論コレはまずいですが、ちょっとこれをヒネると、

認証サーバの認証情報を持っていることを、認証情報自体を開示することなしに、サービスに証明する

という魔法のようなことが.....実は出来ない話ではないのです。

これ、数学的には「ゼロ知識証明」のそのままの話です。これスゴク面白い話題ですよ！！ 一般向けだと「情報セキュリティの科学―マジック・プロトコルへの招待 (ブルーバックス) 」くらいしか書籍がないのがツラいところですが、簡単に言えば、公開鍵暗号の応用編（どっちか言えば電子署名かな）みたいな手法で、そういう

ちょっと魔法な認証とか情報伝達

をするやり方です。そういうツモリで、openID 風のやり方を考えるのならば、こんなプロトコルはどうでしょう？

1. 1. 認証サーバ(IdP)側で、アカウントを発行するときに、アカウント・パスワードと同時に、公開鍵暗号の公開鍵と秘密鍵を生成して、「アカウント・パスワード・秘密鍵」を保存する。そして、ユーザには「公開鍵・アカウント・自身の認証の「口」であるURL」のセットになったテキストを返す。
2. 2. 認証サーバ(IdP)が提供するサービスにログインするには、パスワードを公開鍵で暗号化してパスワード代わりに使う。勿論この時、ちょっとしたソルトを加えて毎回パスワードとして使われるテキストが同じでない...というのもGoodである。で、認証サーバでは受け取ったテキストを秘密鍵で解読し、保存されたパスワードと一致するか確認して認証する。
3. 3. 外部のサービス(Consumer)がこの認証サービスを利用して、自分用の認証をするには次のようにする。1. で提供された「公開鍵・アカウント・認証サーバのURL」をそのまま外部のサービスに開示する。認証を行いたいサービスは、提示された公開鍵によって、ランダムに生成された文字列を暗号化する。そして、それを認証サーバのURLに対してリクエストする。
4. 4. 認証サーバ(IdP)では、送られた暗号文を、内部で保持する秘密鍵で復号して単に返す。
5. 5. 外部のサービス(Consumer)は、認証サービスから送られた復号結果と、自身が選んだランダムな文字列とを比較し、一致すれば、開示された公開鍵に対応する秘密鍵を認証サーバのアカウントが保持することが（ほぼ完全に）証明できる。

このプロセスでは、外部のサービスには認証サーバのサービスにログインできる情報であるパスワードは開示されません。ただ公開鍵が提示されるだけです。認証サーバとのやり取りを通じては、要するにこれを悪意で観察すれば、いわゆる「選択平文攻撃」をしているのと同じ程度の危険性がある...という程度の問題です。これは、一般的な暗号メールで利用する場合の使い方と同様なので、暗号メールの安全性と同じくらい...という結論です。

で問題の、どんな認証リクエストも受け入れる、悪意ある認証サーバが作れるか...というとこれ、

送られてきた暗号文をどうにかして正しく復号してやらなくてはならない....

というとっても難しい（というか、できない）ことをしなければならなくなります。

まあ、ちょっと本来のパスワードと公開鍵と２つあるので、ダブルパスワードっぽい雰囲気もないではないですが、とはいえ、ソルトを使った「毎回違うテキストでログイン」というのもいいでしょ。

問題は...というと、悪意あるサービス(Consumer)が、内部に開示された情報をこっそり保存すると、同じようにこの認証サービス(IdP)を利用する別なサービス(Consumer)に、なりすましログインが出来てしまうことです。何かいい防御手段がないかなぁ....（ごめん）

まあ、このプロトコルはホントに「これぞ、ゼロ知識証明！」というようなものではなく、単なる公開鍵暗号の応用に過ぎないのですが、 ゼロ知識証明には驚くような面白いトピックが満載です。一度調べてみると完全に視野が広がりますよ！（関心を持ったら、「暗号と認証」もいかが？　この本はタイトルにそぐわず、内容はほとんどゼロ知識証明の話です）