上記リンク先にアクセスして、loginをクリックすると、TypeKeyの認証ページに飛ぶ。そこでログインするとリダイレクトして戻ってきて、名前、ニックネーム、メールアドレス（通知する場合）が表示される。

#!/usr/bin/perl
use CGI;
use Authen::TypeKey;
print "Content-type: text/html\n\n";
print "<h1>TypeKey test</h1>";
my $q = CGI->new;
my $tk = Authen::TypeKey->new;
$tk->key_cache([公開鍵用キャッシュファイルのパス]);
$tk->token([TypeKeyトークン文字列]);
my $res = $tk->verify($q);
if (!$res) {
print "LOGIN FAILURE: ".$tk->errstr;
} else {
my $name = $q->param('name');
my $nick = $q->param('nick');
my $email = $q->param('email');
print 'Your Name: '.$name."<br>";
print 'Your Nickname: '.$nick."<br>";
print 'Your Email Address: '.$email.'<br>';
#以降、$nameと$emailを使って、ローカルの認証を行う
}

ちなみに上記段階は、あくまでもTypeKeyの認証が行われただけの話で、実際に各Webアプリケーション上でそのユーザーにどのような権限を与えるかは、$name（と$email）を使って別途処理する（というか権限データベースを作る）必要がある。あと認証状態の継続（セッション管理）も、自前でやらないといけない。まさかアクションごとにいちいちTypeKeyサーバーにとばすわけにもいかないしね。

これを使ったアクセス制御のパターンとしては、

1. 未認証
2. TypeKey認証済み
3. TypeKey認証済み＋メール通知有り
4. TypeKey認証済み＋ローカルユーザー権限あり

というユーザー権限に対して、それぞれ読み書き権限を振り分けていく感じになるんでしょう。実際には4の段階で、さらに細かい権限設定ができるけど、それはまあ適当に。

そういえば、やっぱり前に書いた微妙な動作はサーバーサイドの挙動に問題があるんだね。

「メールアドレスを通知しない」を選ぶと、最初の1回は確かに仕様通り、メールアドレスとしてSHA1ハッシュを返すんだけど、ブラウザの戻るボタンでTypeKeyの認証ページに戻ると、すでにTypeKeyサーバー上で認証済み（セッション）なんで、ログイン画面なしで自動的にリダイレクトがかかる。で、どうやら認証状態で自動リダイレクトがかかる場合には、無条件でメールアドレスを通知するらしい。

ちゃんと動作させるためには、ユーザー設定で「常時メールアドレスを通知する/しない」とかをつけつつ、後は各サーバーごとにこのセッション中に「する/しない」のどちらを選んだのか覚えておいて、リダイレクト時にはその組み合わせを見ながら、適切に処理する（メールアドレス通知リダイレクト、非通知リダイレクト、メールアドレスを通知するかのみを確認するフォーム表示）感じかなー。