Movable Type 3.0は、コメント管理において新しい機能群を提供しています。そのひとつに、外部のシステム経由で、ユーザーを認証するインタフェースがあります。 シックス・アパートの所有するTypeKeyシステムは、認証システムの一例ですが、他の認証システムをMovable Typeのために作ることも可能です。
このドキュメントは、TypeKeyの代わりになるカスタムの認証サービスを開発する場合に使うインタフェースを規定しています。
システムの核となる部分は、DSA（Digital Signature Algorithm [1]、デジタル署名アルゴリズム）とSHA1（Secure Hash Algorithm、セキュア・ハッシュ・アルゴリズム）関数から成ります。 認証サービスは秘密鍵を持ち、インストールしたMovable Typeはそれに対応した公開鍵を持ちます。 認証サービスは、1人のユーザーを認証すると、そのユーザーのプロファイル情報とその情報のデジタル署名を、インストールしたMovable Typeに送ります。 Movable Typeは公開鍵を使って、その署名を確認し、それが正しい場合はブラウザのCookieを、再び同じユーザーを確認できるようにセットします。
代替の認証サービスを作成するには、下記の呼び出しの規則に従ったHTTPハンドラ群が必要となります。 代替の認証サービスを使うには、「Movable Typeの設定」のセクションにあるMovable Typeのパラメータを設定する必要があります。
通常、ユーザーはMovable Type (MT)のコメント・ページから開始します。
未定
MTコメント・ページ -> 認証のためのログイン -> 認証のための登録 -> MTコメント・ページ -> 認証サービスからのログアウト -> MTコメント・ページ
認証サービスは、nameという固有のキーで同定される複数のユーザーのデータを保管しています。 nameは、50半角文字以下のテキストから成り、ASCIIでエンコードされ、文字セット[A-Za-z0-9_]を使っています。 認証サービスはまた、各ユーザーについて、以下のフィールドの情報を保管します。
外部の認証システムは、以下に記載するいくつかのmt.cfgの設定オプション使って、Movable Typeのインタフェースにアクセスします。
Movable Typeは、CGIパラメータの_returnを加えます。このパラメータの値は、ログインが完了したときに戻るURLです。 _returnパラメータは、認証サービスによって渡されたDSA署名[2]を復元(デコード)するMovable Typeのハンドラを指します。 認証サービスが渡すべき引数は、下記の「認証応答のパラメータ」を参照してください。
logoutリンクをクリックするときに、ユーザーのブラウザがアクセスするURLです。 認証サービスは、ユーザーのブラウザをログアウトの状態にリセットして、_returnパラメータ値にアクセスするため、必要なことを行います。
URLからロードされた値は、Movable Typeで24時間キャッシュされます。
<IdentityURL>/<username>
この<username>とはそのユーザーの固有の鍵で、認証サービスから供給されたnameパラメータから来ています(下記の「認証応答のパラメータ」を参照してください)。
認証サービスにユーザー・リンクを作成すると、Movable Typeはvという名前のCGIパラメータを含むようになります。このパラメータは、認証サービスが使うプロトコルのバージョンを指定します。 このパラメータがない場合は、1がセットされます。
かなり古いバージョンのTypeKeyプロトコルのリクエストがあった場合、認証サービスがそのサポートを拒否することはできますが、現在も使用されているMovable Typeの以前のバージョンでその認証サービスを使えなくなる可能性があります。
認証サービスは、ユーザーを認証すると、ブラウザを、CGIパラメータが追加された_returnアドレスにリダイレクトします。 それらのCGIパラメータは、クライアントからのvというCGIパラメータが含むプロトコルのバージョンによって区別されます。vがない場合は、1の値が使われます。
sigパラメータの値は、base64方式[4]のrとsをコロンでつないだ表示形式を取ります。
<r-base64>:<s-base64>
認証サービスによって署名される「メッセージ」は、数個の値をコロン2つでつないだ文字列から成ります。
<email>::<name>::<nick>::<ts>::<site token>
これらの値のすべては、上記のような形式で応答のcleartextにも与えられます。ただし、クライアントによって渡されたサイト・トークンは省かれます。 たとえば、ログインするユーザーが``Napoleon Bonaparte'' <napoleon@france.fr>で、'napster'というログイン名を持ち、2001-09-08 19:00:00 (エポックから1000000800秒後)にログインした場合、「sig」は以下の文字列の署名になります。
napoleon@france.fr::Napolon Bonaparte::napster::1000000800::6jTGQ2MF1focBR5vODfC
バージョン1のプロトコルは、サイト・トークンが応答署名に含まれないところを除いては、バージョン1.1とまったく同じです。 したがって、DSAアルゴリズムに渡される値は、以下のようになります。
<email>::<name>::<nick>::<ts>
DASの公開鍵は、p、q、g、およびpub_keyの4つのフィールドから成ります。 Movable Typeは、DSA鍵を検索するとき、10進法の数字から成る４つの各フィールドが1つのスペースで区切られ1行につらなっている値を探します。 各フィールドは、フィールド名と'='で始まります。 以下に例を挙げます。
p=11671236708387678327224206536086899180337891539414163231548040398520841845883184000627860280911468857014406210406182985401875818712804278750455023001090753 g=8390523802553664927497849579280285206671739131891639945934584937465879937204060160958306281843225586442674344146773393578506632957361175802992793531760152 q=1096416736263180470838402356096058638299098593011 pub_key=10172504425160158571454141863297493878195176114077274329624884017831109225358009830193460871698707783589128269392033962133593624636454152482919340057145639
Movable Type 3では、認証サービスで、投稿者のIDを提供しながら、かつ、その投稿者のメールアドレスを保護する機能が可能になりました。 この機能をオンにすると、認証サービスはメールアドレスをMovable Typeに渡さず、その代わりに、メールアドレスに基づき一方向性のハッシュ関数によって処理された値を渡します。
例を挙げてみましょう。 あなたは、ある投稿者（Luke）のメールアドレスを渡さない認証システムを使っているとします。 あるとき、あなたが知らないコメント投稿者があなたのサイトに来て、”Luke Skywalker”という名前を使いました。 あなたはそのコメントを読み、それがトピックに関連していたので、彼をコメント投稿者として承認したとします。 しばらくして、あなたは、別のコメントを受け取りました。その内容は、悪意に満ち、トピックにも外れていました。そしてLuke Skywalkerという名前がコメント投稿者に使われていました。 これは前のコメント投稿者と同じ人なのでしょうか？ それを調べるために、あなたはMovable Typeの「コメント」画面に行き、最近の"Luke Skywalker”によるコメントを検索します。 特定のユーザーのコメントをすべて検索するには、そのユーザーの名前の隣にある虫めがねアイコンをクリックします。 彼が時には異なる名前を使っていたとしても、そのアカウントから投稿されたコメントは、この検索の結果、すべて表示されます。
さて、別の一例です。あるとき、Groverという人があなたのサイトに投稿しました。そして、あなたはこの人があなたの友達（grover@sesamestreet.com）かどうか知りたいとします。 この場合は、コメント画面の検索ボックスにそのメールアドレスを入力すると、メールアドレスが保護され隠されていても、そのメールアドレスの持ち主のコメントを検索することができます。
これは魔法のように聞こえますが、可能なことです。一方向性の数学的な「ハッシュ」関数がメールアドレスを隠すと同時に、メールアドレスを検索可能にしてくれるからです。
この機能がオンになっていると、渡される値は、FOAF(Friend of a Friend)ファイルで使われる値と同一です。したがって、コメント投稿者が、FOAFファイルによって同定される人と同じであるかどうか、判定できます。
特に、ハッシュになったメールアドレスは、メールアドレスの前にmailto:を追加して、結果をハッシュすることで、形成されます。
認証サービスに保管されたnickフィールドは、HTMLのページでMovable Typeによって表示されます。そして、非常に大きな文字セットからのエンコード文字を含むことがあります。 ターゲットのページ（通常はウェブログ）で、認証サービスが認識できない様々なエンコードを使っている可能性があるため、nickフィールドをHTMLエンティティでエンコードするのが最も安全な方策です。
認証応答のnickCGIパラメータは、署名をコンピュータ処理するときに使う値と、1バイト1バイト同一である必要があります。 クエリー文字列のURLデコーディングを除き、Movable Typeは署名を確認するときにどんな再復元（リコーディング）も行いません。
だだし、nickの値は、US-ASCII文字セットに制約されません。そして認証サービスは必要な場合、特定のエンコーディングを自由に利用できます。
(訳注: 現在、シックス・アパートが提供している TypeKey では、UTF-8 を利用していて、Movable Type 3.1 日本語版では、UTF-8 の利用を前提としています。)