ユーザ情報管理システム
【課題】ＩＤ及びパスワードによるユーザ認証システムと、公開鍵証明書を用いるユーザ認証システムが共存する環境において、ＩＤ管理と証明書管理を同時に行い、ＩＤ管理において本来解決すべきユーザやシステム管理者の作業の効率化を図る。
【解決手段】ユーザＩＤ等のアカウントや属性情報を登録・変更・削除等する際にユーザからＩＤ管理装置１１０に対して入力されたユーザ情報３６１を、サービス提供装置１５０への登録要求Ｔ１によるアカウントプロビジョニングと、認証局装置１３０への証明書発行要求Ｔ２による証明書(属性証明書含む)管理の両方に使用する。これにより、利用者やシステム管理者が必要な入力や操作の量を減らし、効率化を実現する。
【解決手段】ユーザＩＤ等のアカウントや属性情報を登録・変更・削除等する際にユーザからＩＤ管理装置１１０に対して入力されたユーザ情報３６１を、サービス提供装置１５０への登録要求Ｔ１によるアカウントプロビジョニングと、認証局装置１３０への証明書発行要求Ｔ２による証明書(属性証明書含む)管理の両方に使用する。これにより、利用者やシステム管理者が必要な入力や操作の量を減らし、効率化を実現する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＴ（Information Technology）システムにおけるＩＤ（identifier）管理技術を用いたユーザ情報管理システムに関するものである。例えば、ユーザアカウントの登録、変更、削除等を行う際に、ユーザが入力する情報を活用して、プロビジョニングの一環として証明書の発行や失効を行い、利用者やシステム管理者の利便性を向上させる場合に好適である。
【背景技術】
【０００２】
近年のＩＴの普及により、様々なサービスがネットワーク上で提供されている。これらのサービスでは、システム個別にユーザのアカウントを管理している場合がある。ユーザのアカウントとは、例えば、ＩＤ及びパスワードなどである。ある１人のユーザが、このようなサービスを複数利用するには、複数のＩＤやパスワードを覚えていなければならない。
【０００３】
また、システム毎に別々のＩＤ及びパスワードを使用するようなシステムが存在している。このようなシステムを複数管理している企業内のシステム管理者などは、新入社員が入ってくる度に、複数のシステムに対してアカウント登録作業を行わなければならない。複数のシステムが乱立することで、利用者や管理者は不便を強いられるという状況が発生している。
【０００４】
このような問題を解決するために、シングルサインオン技術というものが用いられてきている。シングルサインオン技術とは、複数のアカウントを効率的に管理するＩＤ管理技術や、複数のシステムを利用する際にもユーザの認証操作を１回で済ませられるような技術である。特に、ＩＤ管理技術では、あるサーバのユーザ情報が更新等された場合に、他のサーバについても自動的に更新等するというプロビジョニング技術が提案されている（例えば、特許文献１参照）。
【０００５】
また、ＩＤ管理の一環で、一定のワークフローシステムも提案されている。このワークフローシステムは、例えば、ユーザＩＤの登録申請があった際に、企業のビジネスプロセスやセキュリティを考慮して、承認者による審査をパスしないとＩＤの登録が行われないようにする（例えば、特許文献２参照）。
一方、システムによっては、ＩＤ及びパスワードによってユーザを認証する代わりに、公開鍵証明書によってユーザを認証する方法も提案されている（例えば、非特許文献１参照）。
【特許文献１】特開2003-162509号公報
【特許文献２】特開2002-245010号公報
【非特許文献１】International Telecommunication Union著「Information technology - Open systems interconnection - The Directory: Public-key and attribute certificate frameworks (ITU-T Recommendation X.509)」、（スイス）、International Telecommunication Union、２０００年３月３１日、ｐ．１−１２９
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上述した特許文献１、２に記載の技術のように、ＩＤ及びパスワードによってユーザを識別及び認証するシステムと、公開鍵証明書を用いてユーザを識別及び認証するシステムとが共存しているような環境においては、以下のような不都合が生ずる。
【０００７】
例えば、ユーザの登録を行うためのＩＤ及びパスワードの登録と公開鍵証明書の発行を連続して又は関連つけて行おうとした場合、特許文献１に記載の方法や特許文献２に記載の方法だけでは、公開鍵証明書の発行までは実現することができないという不都合があった。これは、特許文献１に記載の方法や特許文献２に記載の方法に、ＩＤ及びパスワードの登録から公開鍵証明書の発行に至る技術が開示されていないためである。
【０００８】
また、これらの特許文献１に記載の方法や特許文献２に記載の方法と非特許文献１とを組み合わせた場合には、以下のような不都合が生ずる。例えば、ＩＤ及びパスワードの登録と公開鍵証明書の発行をそれぞれ単独で行うことは可能である。しかし、両者の処理を単純に組み合わせただけでは、それぞれのシステムに対して個別にアカウント登録を行うことになる。このため、ＩＤ管理において本来解決すべきユーザやシステム管理者の作業の効率化を図ることができないという不都合があった。
【０００９】
そこで、本発明は、ＩＤ及びパスワードによってユーザを識別及び認証するシステムと、公開鍵証明書を用いてユーザを識別及び認証するシステムとが共存しているような環境において、ユーザの登録を行うためのＩＤ及びパスワードの登録を公開鍵証明書の発行にも用いることができるユーザ情報管理システムの提供を目的とするものである。
【課題を解決するための手段】
【００１０】
本発明は、上記目的を達成するために、本発明は、利用者のＩＤに基づいてサービスを提供するシステムと、利用者の電子的な証明書に基づいてサービスを提供するシステムとが共存する環境において、利用者のＩＤ管理と証明書管理を一括して行うユーザ情報管理システムである。
【００１１】
このユーザ情報管理システムは、ＩＤ管理を一元的に行うＩＤ管理部と、ＩＤ管理部に対してＩＤ管理の操作を行う管理者操作部と、利用者のＩＤに基づいてＩＤを利用したサービスの提供を行う１つ以上のサービス提供部と、利用者の証明書及び失効情報の生成を行う認証局部と、サービス提供部を利用するユーザが操作する利用者操作部とを備えている。
【００１２】
ここで、管理者操作部は、管理者によって指定された、利用者のＩＤを管理するために必要なユーザ情報を含むＩＤ管理要求を、ＩＤ管理部に送信する。
ＩＤ管理部は、受信したＩＤ管理要求に基づいて、要求されたＩＤ管理の実施のためにサービス提供部毎に必要とするユーザ情報を含むプロビジョニング要求を、全てのサービス提供部に送信するとともに、要求されたＩＤ管理の実施のために認証局部が必要とするユーザ情報を含む証明書管理要求を、認証局部に送信する。
【００１３】
そこで、サービス提供部は、受信したプロビジョニング要求に応じて、サービス提供部が管理しているユーザ情報データベースを更新する。
一方、認証局部は、受信した証明書管理要求に応じて、証明書関連情報を生成し、証明書関連情報内に存在する各種構成情報を含む生成結果情報を、ＩＤ管理部に送信する。
また、ＩＤ管理部は、受信した生成結果情報に基づいて、ＩＤ管理部が管理しているユーザ情報データベースを更新する。
【００１４】
このようにして、本発明により、ＩＤ及びパスワードによってユーザを識別及び認証するシステムと、公開鍵証明書を用いてユーザを識別及び認証するシステムとが共存しているような環境において、ユーザの登録を行うためのＩＤ及びパスワードの登録を公開鍵証明書の発行にも用いることができる。
【００１５】
すなわち、ユーザのアカウントや属性情報を登録・変更・削除等する際にユーザから入力された情報を、各システムへのプロビジョニングのためのアカウント管理（アカウントプロビジョニング）と証明書(属性証明書含む)管理の両方に使用する。これにより、利用者やシステム管理者が必要な情報入力や操作の量を減らし、効率化をはかることができる。
【発明の効果】
【００１６】
本発明によれば、アカウント管理の際にユーザが入力する情報を活用し、プロビジョニングのためのアカウント管理（アカウントプロビジョニング）の一環で証明書(属性証明書含む)の管理も行うことができるという効果を奏する。これにより、利用者の入力作業や操作回数を減らすことができ、また、システム管理者の操作回数も減らすことができる。結果として、利用者やシステム管理者の利便性を向上させる効果をもたらすことができる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明による好適な一実施の形態を、図１〜３４の図面を用いて説明する。なお、以下で説明する図面において、同一の番号は同様の部品・要素を表すものとする。また、これにより本発明が限定されるものではない。
【００１８】
図１は、本実施の形態例を適用するためのシステム構成を示す図である。
図１において、このシステムはＩＤ管理装置１１０と、メールサーバ装置１２０と、認証局装置１３０と、リポジトリ装置１４０と、サービス提供装置１５０と、管理者装置１６０と、利用者装置１７０と、承認者装置１８０とを備えている。
【００１９】
ＩＤ管理装置１１０は、システム全体のユーザ情報を一元的に管理する装置である。メールサーバ装置１２０は、各人員に対して通知等を行うための装置である。認証局装置１３０は、証明書を発行あるいは失効する装置である。リポジトリ装置１４０は、証明書やその失効情報を保管及び公開するための装置である。
【００２０】
サービス提供装置１５０は、勤務関係や経理関係等の様々な業務サービスを提供するための装置である。管理者装置１６０は、システムを管理する人（以下、管理者）が操作するコンピュータである。利用者装置１７０は、様々な業務を行うために一般の人（以下、利用者）が操作するコンピュータである。承認者装置１８０は、業務権限の付与やアカウントの変更等を承認する人（以下、承認者）が操作するコンピュータである。
【００２１】
これら各装置１１０〜１８０がネットワーク１９０を介して接続されているものとする。本実施例においては、簡単のため、サービス提供装置１５０を１台として説明を行うが、サービス提供装置１５０は、複数台設置され、業務毎にユーザのアカウントを保有しているような場合も想定している。
【００２２】
図２は、各装置のハードウェア構成を示す図である。
図1に示したＩＤ管理装置１１０、メールサーバ装置１２０、認証局装置１３０、リポジトリ装置１４０、サービス提供装置１５０、管理者装置１６０、利用者装置１７０及び承認者装置１８０は、共通のハードウェアで構成されている。
【００２３】
これら各装置１１０〜１８０は、入力装置２１０と、表示装置２２０と、ＣＰＵ（Central Processing Unit）２３０と、メモリ２４０と、記憶装置２５０と、通信装置２６０と、これらを接続するバス２７０とから構成されている。本実施の形態例では、利用者や承認者への通知手段として電子メールを使用する例を示しているため、メールサーバ装置１２０が構成要素として存在している例を示している。しかし、電子メールは通知手段の１つの実施形態であって、本実施の形態としては通知手段を電子メールに限定するものではない。
【００２４】
入力装置２１０は、装置を利用する人が、データや命令等を入力するために操作されるものであり、キーボード、マウス、生体情報の入力装置、その他認証に必要な装置等で構成される。
表示装置２２０は、装置を利用する人に対してメッセージ等を表示するために用いられるものであり、ＣＲＴ（Cathode Ray Tube）や液晶ディスプレイ等で構成される。
【００２５】
ＣＰＵ２３０は、メモリ２４０や記憶装置２５０に格納されたプログラムを実行することで、装置の各構成要素を制御したり、様々な演算処理を行ったりして、以下に説明する様々な処理を実現する。
メモリ２４０は、図３から図７に示すようなプログラムや、処理に必要なデータが一時的に格納されるものであり、ＲＡＭ（Random Access Memory）等の揮発性記憶媒体で構成することが多い。
【００２６】
記憶装置２５０は、装置内で使用されるプログラムやデータを永続的に記憶するために用いられるものであり、ハードディスク等の不揮発性記憶媒体で構成される。
通信装置２６０は、ネットワーク１９０を介して他の装置とデータの送受信を行うために必要な物理的インタフェースであり、ＬＡＮ（Local Area Network）ボードや無線ＬＡＮカード等で構成される。
【００２７】
図３は、ＩＤ管理装置１１０のソフトウェア構成を示す図である。
ＩＤ管理装置１１０のメモリ２４０には、オペレーティングシステム３１０と、ユーザ認証プログラム３２０と、ＩＤ管理プログラム３３０と、プロビジョニングプログラム３４０と、メール送信プログラム３５０がロードされている領域がある。これらのプログラムは、必要に応じて、ＣＰＵ２３０により実行され、後に説明する機能を実現する。
また、記憶装置２５０には、アクセス制御データ３６０と、ユーザ情報データベース３７０とが格納されている。
【００２８】
次に、各プログラムの機能を説明する。各プログラムは、それぞれが格納されている装置内で読み出されＣＰＵ２３０によって実行されることにより、その機能が実現されるものであるが、説明の便宜上、各プログラムを実行主体として説明する。
図３において、オペレーティングシステム３１０は、装置全体の制御を行うために、ファイル管理、プロセス管理、デバイス管理といった機能を実現するためのプログラムである。
【００２９】
ユーザ認証プログラム３２０は、他の装置からネットワークを介してアクセス要求があった場合などに、アクセス要求してきたユーザが誰であるかを認証する機能を実現する。さらに、要求されたリソースへのアクセスや操作に対して、アクセス権限のあるユーザだけがアクセスもしくは操作を可能とするための機能を実現する制御プログラムである。
すなわち、当該プログラムでは、ユーザ側が入力してきた情報と、アクセス制御データ３６０に記録されている情報とを用いて認証を行う。ここでの例は、認証はＩＤとパスワードの組み合わせによって認証を実現するものとするが、認証方法についてはこの限りではない。
【００３０】
ＩＤ管理サービスプログラム３３０は、管理者、利用者もしくは承認者が、サービス提供装置１５０やメールサーバ装置１２０等を使うために必要なＩＤの管理をする機能を実現する。すなわち、ＩＤの管理として、登録、変更、削除、利用停止、利用停止解除の他、当該ＩＤに付随する属性情報の追加、変更、削除等の申請や承認等を行うために提供されるサービスプログラムである。例えば、Ｗｅｂベースの画面によってＩＤ管理に関する各種手続きをインタラクティブに処理していき、申請や承認を受け付けるプログラムに相当する。
【００３１】
プロビジョニングプログラム３４０は、いわばアカウントプロビジョニングを行うためのプログラムである。すなわち、ＩＤ管理サービスプログラム３３０にて受け付けたＩＤ管理業務の内容に応じて、サービス提供装置１５０、認証局装置１３０及びメール送信プログラム３５０との連携を行う機能を実現する。
【００３２】
そして、様々なシステムで使用されるＩＤやその付随情報を登録、変更、削除、同期等を行ったりする機能を実現する。さらに、予め設定されたビジネスプロセスに基づいて、申請された内容をワークフローで承認者に流す等の制御を行ったりする機能を実現する。
【００３３】
具体的には、ＩＤの登録、変更、削除、当該ＩＤに付随する属性情報の追加、変更あるいは削除等を要求する。これらＩＤ管理のための要求は、ＩＤ管理サービスプログラム３３０にて受け付けたＩＤ管理業務に応じて、サービス提供装置１５０のＩＤ管理形態に適した形で実現される。サービス提供装置１５０が複数存在する場合は、それらの装置に対して同様の処理を繰り返す。また、利用者や承認者に通知が必要な場合は、メール送信プログラム３５０に対して、ユーザへの通知を要求する。さらには、申請や承認の内容に応じて、証明書の発行や失効を要求する。
【００３４】
メール送信プログラム３５０は、プロビジョニングプログラム３４０からの要求に応じて、メールサーバ装置１２０に、電子メールを送信するプログラムである。
アクセス制御データ３６０は、ユーザ認証プログラム３２０にて、ユーザの認証を行う際の正当性を確認するために用いるデータである。すなわち、ユーザの認証を行う際の正当性を確認するために必要な情報及び認証されたユーザがどのようなアクセス権限を有しているかを示す情報を記録したデータである。例えば、アクセス制御データ３６０には、ＩＤ、パスワード、管理者、利用者、あるいは承認者などの役割等が、ユーザ毎に記録されているものとする。
【００３５】
ユーザ情報データベース３７０は、ＩＤ管理サービスプログラム３３０によって受け付けた情報を管理するデータベースである。すなわち、サービス提供装置１５０や認証局装置１３０に対してプロビジョニングする際のマスタとなるデータ群である。例えば、ユーザ情報データベース３７０は、ＩＤ、パスワード、所属部署名、役職、メールアドレス等の属性情報のデータを管理している。
【００３６】
図４は、メールサーバ装置１２０のソフトウェア構成を示す図である。
メールサーバ装置１２０のメモリ２４０には、オペレーティングシステム４１０と、ユーザ認証プログラム４２０と、アカウント管理プログラム４３０と、メール管理プログラム４４０がロードされている領域がある。これらのプログラムは、必要に応じて、ＣＰＵ２３０により実行され、後に説明する機能を実現する。
また、記憶装置２５０には、アクセス制御データ４５０と、ユーザ情報データベース４６０と、アカウント別メールボックス４７０とが格納されている。
【００３７】
次に、各プログラムの機能を説明する。各プログラムは、それぞれが格納されている装置内で読み出されＣＰＵ２３０によって実行されることにより、その機能が実現されるものであるが、説明の便宜上、各プログラムを実行主体として説明する。
図４において、オペレーティングシステム４１０は、装置全体の制御を行うために、ファイル管理、プロセス管理、デバイス管理といった機能を実現するためのプログラムである。
【００３８】
ユーザ認証プログラム４２０は、アクセス権限のあるユーザだけがアクセスもしくは操作を可能とするための制御プログラムである。すなわち、他の装置からネットワークを介してアクセス要求があった場合などに、アクセス要求してきたユーザが誰であるかを認証する機能を実現する。そして、要求されたリソースへのアクセスや操作に対して、アクセス権限のあるユーザだけがアクセスもしくは操作を可能とする機能を実現する。
【００３９】
当該プログラムでは、ユーザ側が入力してきた情報と、アクセス制御データ４５０あるいはユーザ情報データベース４６０に記録されている情報とを用いて認証を行う。ここでの例は、認証はＩＤとパスワードの組み合わせによって認証を実現するものとするが、認証方法についてはこの限りではない。
【００４０】
アカウント管理プログラム４３０は、電子メールを利用するユーザのメールアカウントやそれに付随する情報（例えばパスワード等）を登録、変更、削除等するプログラムである。登録された情報は、ユーザ情報データベース４６０として管理される。ここでの例では、利用者及び承認者のメールアカウントとパスワードが登録されているものとする。
【００４１】
メール管理プログラム４４０は、メールサーバ装置１２０に送信されてきたメールを、アカウント別メールボックス４７０に振り分けて保存しておく機能を有するプログラムである。また、メールの取得要求があった場合に、ユーザ認証プログラム４２０を通じて要求元のユーザの認証を行なった上で、認証されたユーザのメールアカウントに対応したメールボックスに保存されているメールを、要求元のユーザに送信する機能等を有する。
【００４２】
アクセス制御データ４５０は、ユーザがどのようなアクセス権限を有しているかを示す情報（例えば、メールアカウントを登録する権限があること等を示す情報）を記録したデータである。すなわち、ユーザ認証プログラム４２０にて、ユーザの認証を行う際の正当性を確認するために必要な情報及び認証された例えば、ＩＤ、パスワード、権限などが、ユーザ毎に記録されているものとする。
【００４３】
ユーザ情報データベース４６０は、アカウント管理プログラム４３０によって登録・管理されているメールアカウントやそれに付随する情報を管理するデータベースであり、例えば、メールアカウント及びパスワード等のデータを管理している。
アカウント別メールボックス４７０は、メール管理プログラム４４０によって受け付けたメールのデータを、メールアカウント別に保存したものである。保存されたメールは、そのメールを保管しているメールアカウントの正当なユーザしか取得できないようにアクセス制御設定が行われているものとする。
【００４４】
図５は、認証局装置１３０のソフトウェア構成を示す図である。
認証局装置１３０のメモリ２４０には、オペレーティングシステム５１０と、ユーザ認証プログラム５２０と、証明書管理プログラム５３０と、リポジトリ登録プログラム５４０がロードされている領域がある。また、認証局装置１３０側で利用者の鍵ペアを生成するモデルである場合、認証局装置１３０のメモリ２４０には、さらに利用者鍵ペア生成プログラム５４５がロードされる。これらのプログラムは、必要に応じて、ＣＰＵ２３０により実行され、後に説明する機能を実現する。
また、記憶装置２５０には、アクセス制御データ５５０と、証明書情報５６０と、失効情報５７０と、認証局の秘密鍵５８０と、認証局の公開鍵証明書５９０とが格納されている。
【００４５】
次に、各プログラムの機能を説明する。各プログラムは、それぞれが格納されている装置内で読み出されＣＰＵ２３０によって実行されることにより、その機能が実現されるものであるが、説明の便宜上、各プログラムを実行主体として説明する。
図５において、オペレーティングシステム５１０は、装置全体の制御を行うために、ファイル管理、プロセス管理、デバイス管理といった機能を実現するためのプログラムである。
【００４６】
ユーザ認証プログラム５２０は、アクセス権限のあるユーザだけがアクセスもしくは操作を可能とするための制御プログラムである。すなわち、他の装置からネットワークを介してアクセス要求があった場合などに、アクセス要求してきたユーザが誰であるかを認証し、要求されたリソースへのアクセスや操作に対して、 アクセス権限のあるユーザだけがアクセスもしくは操作を可能とする。
【００４７】
当該プログラムでは、ユーザ側が入力してきた情報と、アクセス制御データ５５０に記録されている情報をと用いて認証を行う。ここでの例は、認証はＩＤとパスワードの組み合わせによって認証を実現するものとするが、認証方法についてはこの限りではない。
証明書管理プログラム５３０は、主に、公開鍵証明書の発行要求や失効要求を受け付ける機能と、公開鍵証明書や失効情報を生成する機能と、発行した公開鍵証明書のステータスを管理する機能等を有するプログラムである。
【００４８】
利用者側で鍵を生成させる場合には、利用者からのアクセスを受け付けて、利用者用鍵生成プログラムを送付し、利用者側で生成された公開鍵を受信するサービス機能も有する。
また、属性証明書の使用を想定している場合には、属性証明書の発行要求や失効要求を受け付ける機能と、属性証明書や属性証明書失効情報を生成する機能と、発行した属性証明書のステータスを管理する機能等も有する。
リポジトリ登録プログラム５４０は、証明書管理プログラム５２０で生成された公開鍵証明書、失効情報、属性証明書、属性証明書失効情報等を、リポジトリ装置１４０に登録するためのプログラムである。
【００４９】
利用者鍵ペア生成プログラム５４５は、利用者の公開鍵及び秘密鍵のペアを生成するプログラムである。
アクセス制御データ５５０は、ユーザがどのようなアクセス権限を有しているかを示す情報（例えば、証明書を発行する権限があること等を示す情報）を記録したデータである。すなわち、ユーザ認証プログラム５２０にて、ユーザの認証を行う際の正当性を確認するために必要な情報及び認証された例えば、ＩＤ、パスワード、権限などが、ユーザ毎に記録されているものとする。
【００５０】
証明書情報５６０は、証明書管理プログラム５３０によって生成された公開鍵証明書群である。証明書管理プログラム５３０にて属性証明書の発行も行う場合には、属性証明書群も証明書情報５６０に含まれる。
失効情報５７０は、証明書情報５６０が失効されているか否かを確認するためのデータであり、証明書管理プログラム５３０によって生成された失効情報群である。証明書管理プログラム５３０にて属性証明書の発行も行う場合には、属性証明書失効情報群も失効情報５７０に含まれる。
【００５１】
認証局の秘密鍵５８０は、証明書管理プログラム５３０によって生成される各種証明書や各種失効情報に対し、認証局としての電子署名を付与するために用いるデータである。
認証局の公開鍵証明書５９０は、認証局の秘密鍵５８０に対応した公開鍵証明書である。
【００５２】
図６は、リポジトリ装置１４０のソフトウェア構成を示す図である。
リポジトリ装置１４０のメモリ２４０には、オペレーティングシステム６１０と、ユーザ認証プログラム６２０と、リポジトリプログラム６３０とがロードされている領域がある。これらのプログラムは、必要に応じて、ＣＰＵ２３０により実行され、後に説明する機能を実現する。
また、記憶装置２５０には、アクセス制御データ６４０と、証明書情報６５０と、失効情報６６０とが格納されている。
【００５３】
次に、各プログラムの機能を説明する。各プログラムは、それぞれが格納されている装置内で読み出されＣＰＵ２３０によって実行されることにより、その機能が実現されるものであるが、説明の便宜上、各プログラムを実行主体として説明する。
図６において、オペレーティングシステム６１０は、装置全体の制御を行うために、ファイル管理、プロセス管理、デバイス管理といった機能を実現するためのプログラムである。
【００５４】
ユーザ認証プログラム６２０は、アクセス権限のあるユーザだけがアクセスもしくは操作を可能とするための制御プログラムである。すなわち、他の装置からネットワークを介してアクセス要求があった場合などに、アクセス要求してきたユーザが誰であるかを認証し、要求されたリソースへのアクセスや操作に対して、アクセス権限のあるユーザだけがアクセスもしくは操作を可能とする。
【００５５】
当該プログラムでは、ユーザ側が入力してきた情報と、アクセス制御データ６４０に記録されている情報をと用いて認証を行う。ここでの例は、認証はＩＤとパスワードの組み合わせによって認証を実現するものとするが、認証方法についてはこの限りではない。
リポジトリプログラム６３０は、認証局装置１３０のリポジトリ登録プログラム５４０からの要求に応じて各種証明書や失効情報を保存する機能と、保存している各種証明書や失効情報を、要求に応じて公開する機能等を有するプログラムである。
【００５６】
アクセス制御データ６４０は、ユーザがどのようなアクセス権限を有しているかを示す情報（例えば、証明書を登録する権限があること等を示す情報）を記録したデータである。すなわち、ユーザ認証プログラム６２０にて、ユーザの認証を行う際の正当性を確認するために必要な情報及び認証された例えば、ＩＤ、パスワード、権限などが、ユーザ毎に記録されているものとする。
【００５７】
証明書情報６５０は、リポジトリプログラム６３０によって保存された公開鍵証明書群である。認証局装置１３０の証明書管理プログラム５３０にて属性証明書の発行も行う場合には、属性証明書群も証明書情報６５０に含まれる。
失効情報６６０は、リポジトリプログラム６３０によって保存された失効情報群である。認証局装置１３０の証明書管理プログラム５３０にて属性証明書の発行も行う場合には、属性証明書失効情報群も失効情報６６０に含まれる。
【００５８】
図７は、サービス提供装置１５０のソフトウェア構成を示す図である。
サービス提供装置１５０のメモリ２４０には、オペレーティングシステム７１０と、ユーザ認証プログラム７２０と、アカウント管理プログラム７３０と、業務サービス管理プログラム７４０とがロードされている領域がある。これらのプログラムは、必要に応じて、ＣＰＵ２３０により実行され、後に説明する機能を実現する。
また、記憶装置２５０には、アクセス制御データ７５０と、ユーザ情報データベース７６０とが格納されている。
【００５９】
次に、各プログラムの機能を説明する。各プログラムは、それぞれが格納されている装置内で読み出されＣＰＵ２３０によって実行されることにより、その機能が実現されるものであるが、説明の便宜上、各プログラムを実行主体として説明する。
図７において、オペレーティングシステム７１０は、装置全体の制御を行うために、ファイル管理、プロセス管理、デバイス管理といった機能を実現するためのプログラムである。
【００６０】
ユーザ認証プログラム７２０は、アクセス権限のあるユーザだけがアクセスもしくは操作を可能とするための制御プログラムである。すなわち、他の装置からネットワークを介してアクセス要求があった場合などに、アクセス要求してきたユーザが誰であるかを認証し、要求されたリソースへのアクセスや操作に対して、アクセス権限のあるユーザだけがアクセスもしくは操作を可能とする。
【００６１】
当該プログラムでは、ユーザ側が入力してきた情報と、アクセス制御データ７５０あるいはユーザ情報データベース７６０に記録されている情報とを用いて認証を行う。ここでの例は、認証はＩＤとパスワードの組み合わせによって認証を実現するものとするが、認証方法についてはこの限りではない。
【００６２】
アカウント管理プログラム７３０は、サービス提供装置１５０の業務サービスプログラム７４０を利用するユーザのＩＤやそれに付随する情報（例えば、パスワードのような認証情報や、役職・部門名などの属性情報）を登録、変更、削除等するプログラムである。登録された情報は、ユーザ情報データベース７６０として管理される。ここでの例では、利用者のＩＤとパスワードが登録されているものとする。
【００６３】
業務サービスプログラム７４０は、ある業務を行うためのサービスを提供するプログラムである。例えば、勤務状況を管理する業務サービスや、経理情報を管理する業務サービス、資材調達を行うための業務サービスなどである。本実施の形態例では、利用者装置１７０のＷｅｂブラウザプログラム９２０とインタラクティブに業務処理を進めていくようなＷｅｂベースのシステムであり、このサービスを利用するためには、ユーザの認証に成功していること、かつ、アクセス権があることが必要である。
【００６４】
アクセス制御データ７５０は、ユーザがどのようなアクセス権限を有しているかを示す情報（例えば、ＩＤを登録する権限があること等を示す情報）を記録したデータである。すなわち、ユーザ認証プログラム７２０にて、ユーザの認証を行う際の正当性を確認するために必要な情報及び認証された例えば、ＩＤ、パスワード、権限などが、ユーザ毎に記録されているものとする。
【００６５】
ユーザ情報データベース７６０は、アカウント管理プログラム７３０によって登録・管理されているＩＤやそれに付随する情報を管理するデータベースであり、例えば、ＩＤ、パスワード等のデータを管理している。
【００６６】
図８は、管理者装置１６０のソフトウェア構成を示す図である。
管理者装置１６０のメモリ２４０には、オペレーティングシステム８１０と、Ｗｅｂブラウザプログラム８２０とがロードされている領域がある。これらのプログラムは、必要に応じて、ＣＰＵ２３０により実行され、後に説明する機能を実現する。
【００６７】
次に、各プログラムの機能を説明する。各プログラムは、それぞれが格納されている装置内で読み出されＣＰＵ２３０によって実行されることにより、その機能が実現されるものであるが、説明の便宜上、各プログラムを実行主体として説明する。
図８において、オペレーティングシステム８１０は、装置全体の制御を行うために、ファイル管理、プロセス管理、デバイス管理といった機能を実現するためのプログラムである。
【００６８】
Ｗｅｂブラウザプログラム８２０は、ネットワーク上のＷｅｂサーバに公開されたＨＴＭＬ（HyperText Markup Language）ファイル、画像ファイル、音楽ファイル等をダウンロードし、レイアウトを解析して表示あるいは再生するプログラムである。すなわち、フォームを使用してユーザがデータをＷｅｂサーバに送信することや、Ｊａｖａ（登録商標）等で記述されたプログラムを動作することも可能なプログラムである。
【００６９】
図９は、利用者装置１７０のソフトウェア構成を示す図である。
利用者装置１７０のメモリ２４０には、オペレーティングシステム９１０と、Ｗｅｂブラウザプログラム９２０と、メーラープログラム９３０と、鍵管理プログラム９４０とがロードされている領域がある。これらのプログラムは、必要に応じて、ＣＰＵ２３０により実行され、後に説明する機能を実現する。
また、記憶装置２５０には、利用者の秘密鍵９５０と、利用者の公開鍵証明書９６０と、利用者の属性証明書９７０とが格納される場合がある。
【００７０】
次に、各プログラムの機能を説明する。各プログラムは、それぞれが格納されている装置内で読み出されＣＰＵ２３０によって実行されることにより、その機能が実現されるものであるが、説明の便宜上、各プログラムを実行主体として説明する。
図９において、オペレーティングシステム９１０は、装置全体の制御を行うために、ファイル管理、プロセス管理、デバイス管理といった機能を実現するためのプログラムである。
【００７１】
Ｗｅｂブラウザプログラム９２０は、ネットワーク上のＷｅｂサーバに公開されたＨＴＭＬファイル、画像ファイル、音楽ファイル等をダウンロードし、レイアウトを解析して表示あるいは再生するプログラムである。すなわち、フォームを使用してユーザがデータをＷｅｂサーバに送信することや、Ｊａｖａ（登録商標）等で記述されたプログラムを動作することも可能なプログラムである。
【００７２】
メーラープログラム９３０は、電子メールの作成、ネットワーク上のメールサーバとの電子メールの送受信、受信した電子メールの保存や管理を行うプログラムである。
鍵管理プログラム９４０は、秘密鍵と公開鍵のペアの生成、暗号化、復号、署名、署名検証機能、秘密鍵や証明書のインポートや管理等を行うプログラムである。
【００７３】
利用者の秘密鍵９５０は、利用者装置１７０の鍵管理プログラム９４０によって生成された秘密鍵もしくは認証局装置１３０によって生成された利用者用の秘密鍵をインポートしたものである。
利用者の公開鍵証明書９６０は、認証局装置１３０によって生成された利用者用の公開鍵証明書をインポートしたものである。
利用者の属性証明書９７０は、認証局装置１３０によって生成された利用者用の属性証明書をインポートしたものである。
【００７４】
図１０は、承認者装置１８０のソフトウェア構成を示す図である。
承認者装置１８０のメモリ２４０には、オペレーティングシステム１０１０と、Ｗｅｂブラウザプログラム１０２０と、メーラープログラム１０３０とがロードされている領域がある。これらのプログラムは、必要に応じて、ＣＰＵ２３０により実行され、後に説明する機能を実現する。
【００７５】
次に、各プログラムの機能を説明する。各プログラムは、それぞれが格納されている装置内で読み出されＣＰＵ２３０によって実行されることにより、その機能が実現されるものであるが、説明の便宜上、各プログラムを実行主体として説明する。
図１０において、オペレーティングシステム１０１０は、装置全体の制御を行うために、ファイル管理、プロセス管理、デバイス管理といった機能を実現するためのプログラムである。
【００７６】
Ｗｅｂブラウザプログラム１０２０は、ネットワーク上のＷｅｂサーバに公開されたＨＴＭＬファイル、画像ファイル、音楽ファイル等をダウンロードし、レイアウトを解析して表示あるいは再生するプログラムである。すなわち、フォームを使用してユーザがデータをＷｅｂサーバに送信することや、Ｊａｖａ（登録商標）等で記述されたプログラムを動作することも可能なプログラムである。
【００７７】
メーラープログラム１０３０は、電子メールの作成、ネットワーク上のメールサーバとの電子メールの送受信、受信した電子メールの保存や管理を行うプログラムである。
図１１から図３４では、本実施の形態例におけるデータの管理形態や処理フローをユーザ情報管理のイベント別に図示したが、本実施の形態例において想定したイベントは以下のとおりである。
ＩＤに関して、（ａ）ＩＤの登録、（ｂ）ＩＤの削除、（ｃ）ＩＤの利用停止、（ｄ）ＩＤの利用停止解除、（ｅ）ＩＤの変更がある。また、属性に関して、（ｆ）属性の追加、（ｇ）属性の削除、（ｈ）属性の変更がある。
【００７８】
図１１は、ＩＤもしくは属性の登録時におけるデータの管理形態を例示する図である。
後述する図１３から図２４に示すメニュー選択・ＩＤ指定ステップＳ２１００にて、ＩＤの登録もしくは属性の登録が実施されると、ユーザに関するユーザ情報３６１はＩＤ管理装置１１０内のユーザ情報データベース３６０に登録される。図１１の例において、メニュー選択・ＩＤ指定ステップＳ２１００で登録されるユーザ情報３６１は、ＩＤ及び様々な属性情報（属性Ａ、・・・、属性Ｚ）となる。
【００７９】
また、ＩＤ管理装置１１０によって後述する図１３、図１５、図１９、図２２に示す鍵生成ステップＳ２７００が実施された場合には、ユーザ情報３６１として公開鍵もユーザ情報データベース３６０に登録される。ここで、ＩＤは利用者を一意に示す情報であり、属性情報は、例えば、パスワード、役職、部署名など、ＩＤに紐づく様々な情報である。また、公開鍵は、ＰＫＩ（Public Key Infrastructure）ベースの認証を必要とするサービス提供装置を利用する際に利用者が使用する公開鍵のことである。
【００８０】
次に、後述する図１３から図２４に示すプロビジョニングステップＳ２２００では、サービス提供装置１５０内に対して、Ｔ１で示すＩＤあるいは属性の登録要求が行われる。これにより、サービス提供装置１５０内のユーザ情報データベース７６０に要求されたＩＤあるいは属性が登録される。また、サービス提供装置１５０が複数ある場合、ＩＤ管理装置１１０は、各サービス提供装置１５０に対して、各サービス提供装置１５０が必要とするＩＤもしくは属性を登録するものとする。
【００８１】
図１１の例では、ＩＤ管理装置１１０のユーザ情報データベース３６０をマスタのデータベースとし、本データベースの情報をもとに、サービス提供装置１５０内のユーザ情報データベース７６０に対してＩＤと属性Ａから属性Ｘまでを登録する。すなわち、ＩＤがｕｓｅｒ（１）、属性ＡがａＡ（１）、・・・、属性ＸがａＸ（１）となるようにユーザアカウントを登録する。
【００８２】
前記図１３から図２４に示すプロビジョニングステップと併せて実施される後記証明書発行要求ステップＳ２３００では、ＩＤ管理装置１１０は、認証局装置１３０に対して、Ｔ２で示す公開鍵証明書あるいは属性証明書の発行を要求することになる。図１１の例では、ＩＤ管理装置１１０のユーザ情報データベース３６０をマスタのデータベースとし、本データベースの情報をもとに、認証局装置１３０に対してＩＤ、公開鍵、各種属性を送信する。
【００８３】
公開鍵証明書１３１の生成においては、様々な記載項目を決めなければならない。主体者名、公開鍵情報、属性を格納する拡張項目以外の項目は、認証局のポリシーによって決めることが可能な値である。このため、これらの項目については本実施の形態例ではシステムが自動的に割り当てるものとしている。同様に、属性証明書１３２の生成においても、様々な記載項目を決めなければならない。保有者情報、属性以外の項目は、属性認証局のポリシーによって決めることが可能な値である。このため、これらの項目については本実施の形態例ではシステムが自動的に割り当てるものとしている。
【００８４】
公開鍵証明書１３１の発行に関しては、ＩＤ管理装置１１０におけるＩＤの命名体系と、認証局装置１３０における主体者名の命名体系が異なる場合がある。その場合のＩＤ管理装置１１０から送信されるＩＤは、ＩＤ管理装置１１０内のユーザ情報データベース３６０で管理されているＩＤの値そのものではなく、認証局装置１３０の主体者名の命名体系に適合するよう変換された値が送信されるものとする。
【００８５】
また、公開鍵証明書１３１に結びつく属性証明書１３２の発行に関しても、属性証明書１３２に記載する保有者情報は当該公開鍵証明書１３１の発行者名及び当該公開鍵証明書１３１のシリアル番号の組み合わせで指定されることが多い。このことから、本実施の形態例におけるＩＤ管理装置１１０から送信されるＩＤは、ＩＤ管理装置１１０内のユーザ情報データベース３６０で管理されているＩＤの値そのものではない。
【００８６】
すなわち、ＩＤ管理装置１１０は、当該データベース３６０内で管理している証明書情報３６２からＩＤをキーにして検索し、該当するレコードの中から公開鍵証明書１３１を発行した発行者名の値とそのレコードに記録されているシリアル番号の値の組み合わせがＩＤ管理装置１１０から送信されるものとする。
【００８７】
但し、本実施の形態における保有者情報の記載方法は公開鍵証明書１３１の発行者名及びシリアル番号の組み合わせとは限らない。図１１の例で、ＩＤ管理装置１１０は、ＩＤが「ｕｓｅｒ（１）」であり、かつ、発行者名が「ＣＡ」であるレコードを検索し、認証局装置１３０に対して送付するＩＤとして、発行者名が「ＣＡ」、シリアル番号が「ｓｎ１１」というデータを送付する。
【００８８】
認証局装置１３０では、ＩＤ管理装置１１０から送信された証明書発行要求Ｔ２をもとに、公開鍵証明書１３１もしくは属性証明書１３２を生成する。その後認証局装置１３０は、ＩＤ管理装置１１０に対して証明書発行完了通知Ｔ３を返信する。証明書発行完了通知Ｔ３には、発行した証明書に記載されている発行者名、シリアル番号、記載属性型のデータを含むものとし、これらのデータを受信したＩＤ管理装置１１０は、ユーザ情報データベース３６０の証明書情報３６２にＩＤと結びつけて記録する。
【００８９】
図１１の例における公開鍵証明書１３１の発行完了通知Ｔ３としては、発行者名が「ＣＡ」、シリアル番号が「ｓｎ１１」、記載属性型が「ａＡ、ａＢ」となり、これらのデータが、「ｕｓｅｒ（１）」というＩＤに結び付けられてユーザ情報データベース３６０に記録される。
【００９０】
同様に、図１１の属性証明書１３２の発行完了通知Ｔ３としては、発行者名が「ＡＡ」、シリアル番号が「ｓｎ１２」、記載属性型が「ａＣ」となり、これらのデータが、「ｕｓｅｒ（１）」というＩＤに結び付けられてユーザ情報データベース３６０に記録される。ここで記録したデータは、属性証明書１３２の発行時のＩＤの指定の他、ＩＤの削除、利用停止、利用停止解除、変更、属性の追加、削除、変更のイベントにて活用される。
【００９１】
図１２は、ＩＤもしくは属性の削除時等におけるデータの管理形態を例示する図である。
後述する図１３から図２４に示すメニュー選択・ＩＤ指定ステップＳ２１００にて、ＩＤの削除、利用停止、利用停止解除、変更、属性の追加、削除、変更が実施されると、ＩＤ管理装置１１０内のユーザ情報データベース３６０の内容が変更もしくは削除される。図１２の例では、メニュー選択・ＩＤ指定ステップでｕｓｅｒ（１）のＩＤ及び属性の削除が指定された場合を示しており、ＩＤが「ｕｓｅｒ（１）」であるレコードが削除対象となる。
【００９２】
次に、後述する図１３から図２４に示すプロビジョニングステップＳ２２００では、サービス提供装置１５０内に対して、Ｔ１１で示すＩＤ及び属性の削除要求が行われ、サービス提供装置１５０内のユーザ情報データベース７６０に要求されたＩＤ及び属性が削除される。また、サービス提供装置１５０が複数ある場合、ＩＤ管理装置１１０は、各サービス提供装置１５０に対して、各サービス提供装置１５０が必要とするＩＤ及び属性を削除するものとする。
【００９３】
図１２の例では、ＩＤ管理装置１１０のユーザ情報データベース３６０をマスタのデータベースとし、本データベースの情報をもとに、サービス提供装置１５０内のユーザ情報データベース７６０に対してＩＤと属性Ａから属性Ｘまでを削除する。すなわち、ＩＤがｕｓｅｒ（１）であるユーザアカウントを削除する。
【００９４】
前記図１３から図２４に示すプロビジョニングステップと併せて実施される後記証明書失効要求ステップＳ３０００では、ＩＤ管理装置１１０は、認証局装置１３０に対して、Ｔ１２で示す公開鍵証明書あるいは属性証明書の失効を要求することになる。図１２の例では、ＩＤ管理装置１１０は、ユーザ情報データベース３６０をマスタのデータベースとし、本データベースの情報をもとに、認証局装置１３０に対してＩＤから導き出された証明書の発行者名及びシリアル番号を送信する。
【００９５】
公開鍵証明書の失効情報１３３の生成においては、様々な記載項目を決めなければならない。失効する公開鍵証明書のシリアル番号以外の項目は、認証局のポリシーによって決めることが可能な値である。このため、これらの項目については本実施の形態例ではシステムが自動的に割り当てるものとしている。同様に、属性証明書の失効情報１３４の生成においても、様々な記載項目を決めなければならないが、失効する属性証明書のシリアル番号以外の項目は、属性認証局のポリシーによって決めることが可能な値である。このため、これらの項目については本実施の形態例ではシステムが自動的に割り当てるものとしている。
【００９６】
公開鍵証明書の失効や属性証明書の失効に関しては、ＩＤ管理装置１１０は、ユーザ情報データベース３６０より、ＩＤをキーにして検索される発行者名とシリアル番号を認証局装置１３０に送信することになる。図１２の例で、ＩＤ管理装置１１０は、ＩＤが「ｕｓｅｒ（１）」であるレコードを全て検索し、認証局装置１３０に対して、発行者名が「ＣＡ」、シリアル番号が「ｓｎ１１」というデータを送信することで公開鍵証明書が失効される。そして、発行者名が「ＡＡ」、シリアル番号が「ｓｎ１２」というデータを送信することで属性証明書が失効されることになる。
【００９７】
認証局装置１３０では、ＩＤ管理装置１１０から送信された証明書失効要求Ｔ１２をもとに、公開鍵証明書の失効情報１３３もしくは属性証明書の失効情報１３４を生成する。その後認証局装置１３０は、ＩＤ管理装置１１０に対して証明書失効完了通知Ｔ１３を返信する。
【００９８】
上記の例はＩＤ及び属性の削除の場合について説明したが、一部の属性のみ削除する場合については、証明書情報３６２の記載属性型に削除対象となる属性型が記録されていれば、そのレコードに記載された証明書の発行者名とシリアル番号を送信することになる。図１２の例において、ｕｓｅｒ（１）に関する属性Ｃの削除イベントが発生したとすると、ＩＤがｕｓｅｒ（１）で、かつ、記載属性型に「ａＣ」を含むレコードを検索し、検索されたレコードに記載されている発行者名とシリアル番号、すなわち、「ＡＡ」と「ｓｎ１２」を認証局装置１３０に送信することで、属性証明書が失効される。
【００９９】
図１３から図２４は、イベント別に、各装置間で実施される処理フローの概要を例示する図である。特に、図１３から図１７は、例えば企業における人事部門のシステムを操作できるような管理者が、利用者のＩＤを強制的に指定する場合の処理フローの例を示したものである。
【０１００】
また、図１８から図２４は、利用者自身が申請を行い、当該申請を承認できる権限をした承認者が承認することでＩＤに対する操作が実施されるという場合の処理フローの例を示したものである。また、これら図１３から図２４で用いている各ステップの詳細な手順を図２５から図３４の詳細な処理フローで示す。
【０１０１】
図１３は、管理者が利用者のＩＤを登録する場合の処理フローの概要を例示する図である。
はじめに、メニュー選択・ＩＤ指定ステップを実施する（ステップ２１００、以下、ステップをＳと略して記す）。すなわち、管理者が管理者装置１６０のＷｅｂブラウザプログラム８２０を使用してＩＤ管理装置１１０にアクセスし、ＩＤの登録を行うためのメニューを選択し、登録するＩＤを入力する（さらに必要に応じて各種属性も入力する）。本ステップの詳細は、図２５にて例示する。
【０１０２】
次に、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を、サービス提供装置１５０のユーザ情報データベース７６０に反映するためのＩＤ及び属性の登録要求をＩＤ管理装置１１０が送信する。本ステップの詳細は、図２６にて例示する。また、プロビジョニングの対象として、メールサーバ装置１２０のメールアカウントも含まれるのであれば、メールサーバ装置１２０のユーザ情報データベース４６０に対するＩＤ及び属性の登録要求も、本ステップで行うものとする。
【０１０３】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容をもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信する。本ステップの詳細は、図２７にて例示する。なお、プロビジョニングステップＳ２２００と証明書発行要求ステップＳ２３００の順序性は問わない。
【０１０４】
プロビジョニングステップＳ２２００及び証明書発行要求ステップＳ２３００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して証明書発行手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０１０５】
一方、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤは、管理者から利用者に通知されないと、利用者はＩＤを利用して業務サービスを享受することができない。このため、管理者は、ＩＤを記載した紙を利用者に送付するなどして、利用者にＩＤを通知するといったＩＤ通知ステップを実施する（Ｓ２５００）。また、ＩＤの他にパスワード等の認証に関する属性も通知する必要がある場合は、ＩＤと併せて通知する。但し、利用者へのＩＤ通知方法は、既知の方法を使えばよく、ＩＤの通知方法を紙での送付に限定するものではない。
【０１０６】
メール送信ステップＳ２４００及びＩＤ通知ステップＳ２５００が完了すると、メール受信ステップを実施する（Ｓ２６００）。すなわち、利用者はメールを利用できるようになり、かつ、当該利用者のメールアカウント宛に証明書発行手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０及びＩＤ通知ステップＳ２５００にて通知されたＩＤ及びパスワードを利用してメールサーバ装置１２０にアクセスし、当該利用者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０１０７】
前記メール受信ステップＳ２６００において証明書発行手続きを行うためのアクセス先が記載されたメールを受信した利用者は、鍵生成ステップを実施する（Ｓ２７００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザを用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスして鍵生成用の画面を取得する。そして、利用者装置１７０の鍵管理プログラム９４０を用いて利用者の秘密鍵及び公開鍵のペアを生成して公開鍵を認証局装置１３０に送信する。認証局装置１３０は、当該公開鍵を用いて当該利用者のＩＤに基づく公開鍵証明書を生成する。本ステップの詳細は、図３０にて例示する。
【０１０８】
前記鍵生成ステップＳ２７００において認証局装置１３０で利用者の公開鍵証明書の生成が完了したら、証明書取得ステップを実施する（Ｓ２８００）。すなわち、当該ステップに続けて、利用者は、利用者装置１７０のＷｅｂブラウザプログラムを用いて、認証局装置１３０から当該公開鍵証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０１０９】
前記鍵生成ステップＳ２７００において認証局装置１３０で利用者の公開鍵証明書の生成が完了したら、証明書登録ステップを実施する（Ｓ２９００）。すなわち、即時もしくは一定期間後に、認証局装置１３０はリポジトリ装置１４０に対して、当該公開鍵証明書の登録要求を送信し、リポジトリ装置１４０内で当該公開鍵証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０１１０】
また、前記証明書登録ステップＳ２９００と並行してもしくは当該ステップの実施後即時にもしくは当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）を送信する。そして、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。本ステップの詳細は、図３３にて例示する。
【０１１１】
以上の手順によって、管理者が指定したＩＤをサービス提供装置１５０に登録する処理と、当該ＩＤに基づく公開鍵証明書を発行する処理を、一連の流れで実施することが可能となり、管理者におけるＩＤ登録および公開鍵証明書発行に係る手間を軽減することが可能となる。
【０１１２】
図１３を用いて、上記とは別の、管理者が利用者のＩＤを登録する場合の処理フローの概要の実施例を例示する。ここでは、認証局装置１３０側で、利用者の鍵ペアを生成するモデルを前提とする。この例では、上述した図１３の処理と異なる点のみを説明し、共通の処理の説明を省略する。
【０１１３】
まず、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容をもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信し、認証局装置１３０が要求に応じた利用者の鍵ペア及び公開鍵証明書を生成する。利用者の鍵ペアについては、認証局装置１３０で利用者鍵ペア生成プログラム５４５を用いて生成される。本ステップの詳細は、図２７にて例示する。なお、プロビジョニングステップＳ２２００と証明書発行要求ステップＳ２３００の順序性は問わない。
【０１１４】
次に、前記メール受信ステップＳ２６００において証明書取得手続きを行うためのアクセス先が記載されたメールを受信した利用者は、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザを用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスし、認証局装置１３０から利用者の鍵ペア及び公開鍵証明書をダウンロードし、利用者装置１７０内に保存する。ここで、ダウンロードされる利用者の鍵ペアは、暗号化されるものとする。本ステップの詳細は、図３１にて例示する。
【０１１５】
以上の手順によって、管理者が指定したＩＤをサービス提供装置１５０に登録する処理と、認証局装置１３０側で利用者の鍵ペアを生成すると共に当該ＩＤに基づく公開鍵証明書を発行する処理を、一連の流れで実施することが可能となり、管理者におけるＩＤ登録および公開鍵証明書発行に係る手間を軽減することが可能となる。
【０１１６】
図１４は、管理者が利用者のＩＤを削除、利用停止もしくは利用停止解除する場合の処理フローの概要を例示する図である。
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、管理者が管理者装置１６０のＷｅｂブラウザプログラム８２０を使用してＩＤ管理装置１１０にアクセスし、ＩＤの削除、利用停止もしくは利用停止解除を行うためのメニューを選択し、削除、利用停止もしくは利用停止解除するＩＤを入力する。本ステップの詳細は、図２５にて例示する。
【０１１７】
次に、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤに対して、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、サービス提供装置１５０のユーザ情報データベース７６０に反映するためのＩＤの削除要求、利用停止要求もしくは利用停止解除要求をＩＤ管理装置１１０が送信する。本ステップの詳細は、図２６にて例示する。また、プロビジョニングの対象として、メールサーバ装置１２０のメールアカウントも含まれるのであれば、メールサーバ装置１２０のユーザ情報データベース４６０に対するＩＤの削除要求、利用停止要求もしくは利用停止解除要求も、本ステップで行うものとする。
【０１１８】
また、前記プロビジョニングステップＳ２２００と併せて、証明書失効要求ステップを実施する（Ｓ３１００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤをもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の失効要求、利用停止要求もしくは利用停止解除要求を送信し、認証局装置１３０にて証明書の失効情報を生成する。但し、失効情報の開示形態として、オンラインで証明書のステータスを回答するような形態をとる場合には、証明書の失効情報を生成する処理が、証明書のステータスを変更する処理に置き換わるものとする。本ステップの詳細は、図２７にて例示する。なお、プロビジョニングステップＳ２２００と証明書失効要求ステップＳ３１００の順序性は問わない。
【０１１９】
前記証明書失効ステップＳ３１００において認証局装置１３０で失効情報の生成が完了したら、失効情報登録ステップを実施する（Ｓ３２００）。すなわち、即時もしくは一定期間後に、認証局装置１３０はリポジトリ装置１４０に対して、当該失効情報の登録要求を送信し、リポジトリ装置１４０内で当該失効情報を保存する。本ステップの詳細は、図３２にて例示する。
【０１２０】
また、前記失効情報登録ステップＳ３２００と並行してもしくは当該ステップの実施後即時にもしくは当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を失効した旨の完了通知（削除、利用停止もしくは利用停止解除の対象となったＩＤを含む）を送信し、ＩＤ管理装置１１０内で完了通知時に送付された情報をもとに、ユーザ情報データベース３６０を削除もしくは変更等する。本ステップの詳細は、図３３にて例示する。
【０１２１】
以上の手順によって、管理者が指定したＩＤをサービス提供装置１５０に削除、利用停止もしくは利用停止解除する処理と、当該ＩＤに基づく公開鍵証明書を失効、利用停止もしくは利用停止解除する処理を、一連の流れで実施することが可能となる。これにより、管理者におけるＩＤの削除、利用停止もしくは利用停止解除、および、公開鍵証明書の失効、利用停止もしくは利用停止解除に係る手間を軽減することが可能となる。
【０１２２】
図１５は、管理者が利用者のＩＤを変更する場合の処理フローの概要を例示する図である。また、公開鍵証明書に属性情報を記載する場合の属性の登録、変更、削除についても本処理フローに従うものとする。
【０１２３】
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、管理者が管理者装置１６０のＷｅｂブラウザプログラム８２０を使用してＩＤ管理装置１１０にアクセスし、ＩＤの変更を行うためのメニューを選択し、変更する前と後のＩＤを入力する。本ステップの詳細は、図２５にて例示する。属性の登録、変更もしくは削除時は、属性の登録、変更もしくは削除を行うためのメニューを選択し、登録、変更もしくは削除対象となるＩＤと属性を入力する。
【０１２４】
次に、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤに対して、サービス提供装置１５０のユーザ情報データベース７６０に反映するためのＩＤもしくは属性の変更要求をＩＤ管理装置１１０が送信する。本ステップの詳細は、図２６にて例示する。また、プロビジョニングの対象として、メールサーバ装置１２０のメールアカウントも含まれるのであれば、メールサーバ装置１２０のユーザ情報データベース４６０に対するＩＤの変更要求も、本ステップで行うものとする。
【０１２５】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力された変更後のＩＤもしくは属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信する。
【０１２６】
ここで、変更前のＩＤに対応した公開鍵証明書の公開鍵と変更後のＩＤに対応した公開鍵証明書の公開鍵を同じ値にする場合には、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信する情報の中に、変更前のＩＤに対応した公開鍵証明書の公開鍵を含める。これによって、本ステップ内で公開鍵証明書を生成できる。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、後記証明書失効要求ステップＳ３１００と、本証明書発行要求ステップＳ２３００の順序性は問わない。
【０１２７】
さらに、前記プロビジョニングステップＳ２２００と併せて、証明書失効要求ステップを実施する（Ｓ３１００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力された変更前のＩＤをもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の失効要求を送信し、認証局装置１３０にて証明書の失効情報を生成する。
【０１２８】
但し、失効情報の開示形態として、オンラインで証明書のステータスを回答するような形態をとる場合には、証明書の失効情報を生成する処理が、証明書のステータスを変更する処理に置き換わるものとする。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、前記証明書発行要求ステップＳ２３００と、本証明書失効要求ステップＳ３１００の順序性は問わない。
【０１２９】
前記証明書失効ステップＳ３１００において認証局装置１３０で失効情報の生成が完了したら、失効情報登録ステップを実施する（Ｓ３２００）。すなわち、即時もしくは一定期間後に、認証局装置１３０はリポジトリ装置１４０に対して、当該失効情報の登録要求を送信し、リポジトリ装置１４０内で当該失効情報を保存する。本ステップの詳細は、図３２にて例示する。
【０１３０】
プロビジョニングステップＳ２２００、証明書発行要求ステップＳ２３００及び証明書失効要求ステップＳ３１００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して変更後のＩＤに対応した証明書発行手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０１３１】
一方、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力された変更後のＩＤは、管理者から利用者に通知されないと、利用者はＩＤを利用して業務サービスを享受することができない。このため、管理者は、ＩＤを記載した紙を利用者に送付するなどして、利用者にＩＤを通知するといったＩＤ通知ステップを実施する（Ｓ２５００）。
【０１３２】
また、ＩＤの他にパスワード等の認証に関する属性も通知する必要がある場合は、ＩＤと併せて通知する。但し、利用者へのＩＤ通知方法は、既知の方法を使えばよく、ＩＤの通知方法を紙での送付に限定するものではない。属性の登録、変更もしくは削除時であって変更前のＩＤと変更後のＩＤが同じ場合には、本ステップは省略される。
【０１３３】
メール送信ステップＳ２４００及びＩＤ通知ステップＳ２５００が完了すると、メール受信ステップを実施する（Ｓ２６００）。すなわち、利用者は変更後のＩＤを用いてメールを利用できるようになり、かつ、当該利用者のメールアカウント宛に証明書発行手続きを行うためのアクセス先が記載されたメールが届いている状態になる。
【０１３４】
このため、利用者は、利用者装置１７０のメーラープログラム９３０及びＩＤ通知ステップＳ２５００にて通知されたＩＤ及びパスワードを利用してメールサーバ装置１２０にアクセスし、当該利用者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０１３５】
前記メール受信ステップＳ２６００において証明書発行手続きを行うためのアクセス先が記載されたメールを受信した利用者は、鍵生成ステップを実施する（Ｓ２７００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザを用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスして鍵生成用の画面を取得し、利用者装置１７０の鍵管理プログラム９４０を用いて利用者の秘密鍵及び公開鍵のペアを生成して公開鍵を認証局装置１３０に送信する。
そして、認証局装置１３０は当該公開鍵を用いて当該利用者のＩＤに基づく公開鍵証明書を生成する。但し、前記証明書発行要求ステップ２３００において既に公開鍵証明書を生成している場合、本ステップは省略される。本ステップの詳細は、図３０にて例示する。
【０１３６】
前記鍵生成ステップＳ２７００もしくは前記証明書発行要求ステップ２３００において認証局装置１３０で利用者の公開鍵証明書の生成が完了したら、証明書取得ステップを実施する（Ｓ２８００）。すなわち、当該ステップに続けて、利用者は、利用者装置１７０のＷｅｂブラウザプログラム９２０を用いて、認証局装置１３０から当該公開鍵証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０１３７】
前記鍵生成ステップＳ２７００もしくは前記証明書発行要求ステップ２３００において認証局装置１３０で利用者の公開鍵証明書の生成が完了したら、証明書登録ステップを実施する（Ｓ２９００）。すなわち、即時もしくは一定期間後に、認証局装置１３０はリポジトリ装置１４０に対して、当該公開鍵証明書の登録要求を送信し、リポジトリ装置１４０内で当該公開鍵証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０１３８】
また、前記証明書登録ステップＳ２９００と並行して、もしくは、当該ステップの実施後即時に、もしくは、当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、変更後のＩＤに対する証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）及び変更前のＩＤに対する証明書を失効した旨の通知（失効の対象となったＩＤを含む）を送信し、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。
【０１３９】
また、本ステップは、証明書の登録の完了通知と証明書の失効の完了通知を兼ねているが、これらは別々に実施してもよい。すなわち、前記証明書失効ステップＳ３２００と並行して、もしくは、当該ステップの実施後即時に、もしくは、当該ステップの実施後一定期間後に、変更前のＩＤに対する証明書を失効した旨の通知（失効の対象となったＩＤを含む）を送信してもよい。本ステップの詳細は、図３３にて例示する。
【０１４０】
以上の手順によって、管理者が指定した変更前のＩＤをサービス提供装置１５０から削除する処理と、変更前のＩＤに基づく公開鍵証明書を失効する処理と、管理者が指定した変更後のＩＤをサービス提供装置１５０に登録する処理と、変更後のＩＤに基づく公開鍵証明書を発行する処理を、一連の流れで実施することが可能となる。これにより、管理者におけるＩＤ変更および公開鍵証明書再発行に係る手間を軽減することが可能となる。
【０１４１】
図１５を用いて、上記とは別の、管理者が利用者のＩＤを変更する場合の処理フローの概要の実施例を例示する。また、公開鍵証明書に属性情報を記載する場合の属性の登録、変更、削除についても本処理フローに従うものとする。ここでは、認証局装置１３０側で、利用者の鍵ペアを生成するモデルを前提とする。この例では、上述した図１５の処理と異なる点のみを説明し、共通の処理の説明を省略する。
【０１４２】
まず、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力された変更後のＩＤもしくは属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信し、認証局装置１３０が要求に応じた利用者の鍵ペア及び公開鍵証明書を生成する。利用者の鍵ペアについては、認証局装置１３０の利用者鍵ペア生成プログラム５４５を用いて生成される。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、後記証明書失効要求ステップＳ３１００と、本証明書発行要求ステップＳ２３００の順序性は問わない。
【０１４３】
次に、証明書取得ステップを実施する（Ｓ２８００）。すなわち、前記メール受信ステップＳ２６００において証明書取得手続きを行うためのアクセス先が記載されたメールを受信した利用者は、利用者装置１７０のＷｅｂブラウザを用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスする。そして、認証局装置１３０から利用者の鍵ペア及び公開鍵証明書をダウンロードし、利用者装置１７０内に保存する。ここで、ダウンロードされる利用者の鍵ペアは、暗号化されるものとする。本ステップの詳細は、図３１にて例示する。
【０１４４】
前記証明書発行要求ステップ２３００において認証局装置１３０で利用者の鍵ペア及び公開鍵証明書の生成が完了したら、証明書登録ステップを実施する（Ｓ２９００）。すなわち、即時もしくは一定期間後に、認証局装置１３０はリポジトリ装置１４０に対して、当該公開鍵証明書の登録要求を送信し、リポジトリ装置１４０内で当該公開鍵証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０１４５】
以上の手順によって、管理者が指定した変更前のＩＤをサービス提供装置１５０から削除する処理と、認証局装置１３０側で利用者の鍵ペアを生成すると共に変更前のＩＤに基づく公開鍵証明書を失効する処理と、管理者が指定した変更後のＩＤをサービス提供装置１５０に登録する処理と、認証局装置１３０側で利用者の鍵ペアを生成すると共に変更後のＩＤに基づく公開鍵証明書を発行する処理を、一連の流れで実施することが可能となる。これにより、管理者におけるＩＤ変更および公開鍵証明書再発行に係る手間を軽減することが可能となる。
【０１４６】
図１６は、管理者が利用者の属性情報を登録する場合の処理フローの概要を例示する図である。但し、図１６は属性情報の表現に属性証明書を用いる場合を想定しており、属性情報の表現に公開鍵証明書を用いる場合は、図１５の手順に従うものとする。
【０１４７】
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、管理者が管理者装置１６０のＷｅｂブラウザプログラム８２０を使用してＩＤ管理装置１１０にアクセスし、属性の追加を行うためのメニューを選択し、その対象となるＩＤと追加する属性情報を入力する。本ステップの詳細は、図２５にて例示する。
【０１４８】
次に、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性に対して、サービス提供装置１５０のユーザ情報データベース７６０に反映するための属性追加要求をＩＤ管理装置１１０が送信する。本ステップの詳細は、図２６にて例示する。
【０１４９】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に属性証明書の発行要求を送信する。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、本証明書発行要求ステップＳ２３００の順序性は問わない。
【０１５０】
前記証明書発行ステップＳ２３００において認証局装置１３０で利用者の属性証明書の生成が完了したら、証明書登録ステップを実施する（Ｓ２９００）。すなわち、即時もしくは一定期間後に、認証局装置１３０はリポジトリ装置１４０に対して、当該属性証明書の登録要求を送信し、リポジトリ装置１４０内で当該属性証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０１５１】
プロビジョニングステップＳ２２００、証明書発行要求ステップＳ２３００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して証明書取得手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。但し、属性証明書の利用形態として、以下の場合は本ステップは省略してもよい。すなわち、属性証明書の保有者から属性証明書の検証者に属性証明書を提示するというプッシュ型ではなく、属性証明書の検証者がリポジトリ等の公開サーバに属性証明書を取りにいくというプル型の場合である。本ステップの詳細は、図２８にて例示する。
【０１５２】
メール送信ステップＳ２４００が実施された場合には、メール受信ステップを実施する（Ｓ２６００）。すなわち、利用者は自身のメールアカウント宛に証明書取得手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０を利用してメールサーバ装置１２０にアクセスし、当該利用者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０１５３】
前記メール受信ステップＳ２６００において証明書取得手続きを行うためのアクセス先が記載されたメールを受信した利用者は、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザを用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスし、認証局装置１３０から属性証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０１５４】
一方、前記証明書登録ステップＳ２９００と並行して、もしくは、当該ステップの実施後即時に、もしくは、当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）を送信し、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。本ステップの詳細は、図３３にて例示する。
【０１５５】
以上の手順によって、管理者が指定したＩＤに対してサービス提供装置１５０に属性を追加する処理と、当該ＩＤに基づく属性証明書を発行する処理を、一連の流れで実施することが可能となり、管理者における属性追加および属性証明書発行に係る手間を軽減することが可能となる。
【０１５６】
図１７は、管理者が利用者の属性情報を変更もしくは削除する場合の処理フローの概要を例示する図である。但し、図１７は属性情報の表現に属性証明書を用いる場合を想定しており、属性情報の表現に公開鍵証明書を用いる場合は、図１５の手順に従うものとする。
【０１５７】
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、管理者が管理者装置１６０のＷｅｂブラウザプログラム８２０を使用してＩＤ管理装置１１０にアクセスし、属性の変更もしくは削除を行うためのメニューを選択し、その対象となるＩＤと変更もしくは削除する属性情報を入力する。本ステップの詳細は、図２５にて例示する。
【０１５８】
次に、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性に対して、ＩＤ管理装置１１０がサービス提供装置１５０のユーザ情報データベース７６０に反映するための属性変更要求もしくは属性削除要求を送信する。本ステップの詳細は、図２６にて例示する。
【０１５９】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に属性証明書の発行要求を送信する。但し、属性の変更もしくは削除の内容に応じて、新たに属性証明書を発行する必要がない場合、本ステップは省略される。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、後記証明書失効要求ステップＳ３１００と、本証明書発行要求ステップＳ２３００の順序性は問わない。
【０１６０】
さらに、前記プロビジョニングステップＳ２２００と併せて、証明書失効要求ステップを実施する（Ｓ３１００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に属性証明書の失効要求を送信し、認証局装置１３０にて属性証明書失効情報を生成する。但し、失効情報の開示形態として、オンラインで証明書のステータスを回答するような形態をとる場合には、属性証明書失効情報を生成する処理が、属性証明書のステータスを変更する処理に置き換わるものとする。
【０１６１】
ここで、どの属性証明書を失効するかは、メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性と、図１２の説明にて記載したＩＤ管理装置１１０内のユーザ情報データベース３６０内の証明書情報３６２である証明書のＩＤとその記載属性型を比較して合致したものが選択されるものとする。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、前記証明書発行要求ステップＳ２３００と、本証明書失効要求ステップＳ３１００の順序性は問わない。
【０１６２】
前記証明書発行ステップＳ２３００が実施され、認証局装置１３０で利用者の属性証明書の生成が完了した場合には、即時もしくは一定期間後に、証明書登録ステップを実施する（Ｓ２９００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該属性証明書の登録要求を送信し、リポジトリ装置１４０内で当該属性証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０１６３】
また、前記証明書失効ステップＳ３１００において認証局装置１３０で属性証明書失効情報の生成が完了したら、即時もしくは一定期間後に、失効情報登録ステップを実施する（Ｓ３２００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該失効情報の登録要求を送信し、リポジトリ装置１４０内で当該失効情報を保存する。本ステップの詳細は、図３２にて例示する。
【０１６４】
プロビジョニングステップＳ２２００、証明書発行要求ステップＳ２３００及び証明書失効要求ステップＳ３１００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して証明書取得手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。
【０１６５】
但し、属性証明書の利用形態として、以下の場合には本ステップは省略してもよい。すなわち、属性証明書の保有者から属性証明書の検証者に属性証明書を提示するというプッシュ型ではなく、属性証明書の検証者がリポジトリ等の公開サーバに属性証明書を取りにいくというプル型の場合である。本ステップの詳細は、図２８にて例示する。
【０１６６】
メール送信ステップＳ２４００が実施された場合には、メール受信ステップを実施する（Ｓ２６００）。すなわち、利用者は自身のメールアカウント宛に証明書取得手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０を利用してメールサーバ装置１２０にアクセスし、当該利用者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０１６７】
前記メール受信ステップＳ２６００において証明書取得手続きを行うためのアクセス先が記載されたメールを受信した利用者は、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザを用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスし、認証局装置１３０から属性証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０１６８】
一方、前記証明書登録ステップＳ２９００と並行して、もしくは、当該ステップの実施後即時に、もしくは、当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）を送信し、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。本ステップの詳細は、図３３にて例示する。
【０１６９】
以上の手順によって、管理者が指定したＩＤに対してサービス提供装置１５０に属性を変更もしくは削除する処理と、当該ＩＤに基づく属性証明書を失効もしくは再発行する処理を、一連の流れで実施することが可能となり、管理者における属性変更もしくは削除および属性証明書失効もしくは再発行に係る手間を軽減することが可能となる。
【０１７０】
図１８は、利用者がＩＤを登録する場合の処理フローの概要を例示する図である。
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を使用してＩＤ管理装置１１０にアクセスし、ＩＤの登録を行うためのメニューを選択し、登録するＩＤを入力する（さらに必要に応じてパスワード等の各種属性も入力する）。本ステップの詳細は、図２５にて例示する。
【０１７１】
前記メニュー選択・ＩＤ指定ステップＳ２１００にてＩＤの入力が完了した後、続けて、鍵生成ステップを実施する（Ｓ２７００）。すなわち、利用者はＷｅｂの画面遷移に従ってＩＤ管理装置１１０もしくは認証局装置１３０にアクセスする。これにより鍵生成用の画面を取得し、利用者装置１７０の鍵管理プログラム９４０を用いて利用者の秘密鍵及び公開鍵のペアを生成する。そして公開鍵をアクセス先である当該ＩＤ管理装置１１０もしくは当該認証局装置１３０に送信する。公開鍵の送信先が認証局装置１３０の場合には、その後の画面遷移でＩＤ管理装置に戻るものとする。本ステップの詳細は、図３０にて例示する。
【０１７２】
次に、前記鍵生成ステップＳ２７００が実施された後、承認者宛メール送信ステップを実施する（Ｓ２４５０）。すなわち、ＩＤ管理装置１１０は、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を承認者に承認してもらう必要がある。このために、承認者のメールアドレスに対して承認手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０１７３】
前記承認者宛メール送信ステップＳ２４５０が完了すると、承認者宛メール受信ステップを実施する（Ｓ２６５０）。すなわち、承認者のメールアカウント宛には承認手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、承認者は、承認者装置１８０のメーラープログラム１０３０を利用してメールサーバ装置１２０にアクセスし、当該承認者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０１７４】
前記承認者宛メール受信ステップＳ２６５０において承認手続きを行うためのアクセス先が記載されたメールを受信した承認者は、承認ステップを実施する（Ｓ３３００）。すなわち、承認者は、承認者装置１８０のＷｅｂブラウザプログラム１０２０を用いて、メールに記載されたアクセス先であるＩＤ管理装置１１０にアクセスして承認内容を確認し、承認可否をＩＤ管理装置１１０に送信する。本ステップの詳細は、図３４にて例示する。
【０１７５】
前記承認ステップＳ３３００が完了したら、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を、ＩＤ管理装置１１０がサービス提供装置１５０のユーザ情報データベース７６０に反映するためのＩＤ及び属性の登録要求を送信する。本ステップの詳細は、図２６にて例示する。また、プロビジョニングの対象として、メールサーバ装置１２０のメールアカウントも含まれるのであれば、メールサーバ装置１２０のユーザ情報データベース４６０に対するＩＤ及び属性の登録要求も、本ステップで行うものとする。
【０１７６】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容をもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信し、認証局装置１３０が要求に応じた利用者の公開鍵証明書を生成する。本ステップの詳細は、図２７にて例示する。なお、プロビジョニングステップＳ２２００と証明書発行要求ステップＳ２３００の順序性は問わない。
【０１７７】
前記証明書発行要求ステップＳ２３００において認証局装置１３０で利用者の公開鍵証明書の生成が完了したら、即時もしくは一定期間後に、証明書登録ステップを実施する（Ｓ２９００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該公開鍵証明書の登録要求を送信し、リポジトリ装置１４０内で当該公開鍵証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０１７８】
プロビジョニングステップＳ２２００及び証明書発行要求ステップＳ２３００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して証明書取得手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０１７９】
メール送信ステップＳ２４００が完了すると、メール受信ステップを実施する（Ｓ２６００）。すなわち、利用者はメールを利用できるようになり、かつ、当該利用者のメールアカウント宛に証明書取得手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０及びメニュー選択・ＩＤ指定ステップＳ２１００にて入力したＩＤ及びパスワードを利用してメールサーバ装置１２０にアクセスし、当該利用者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０１８０】
前記メール受信ステップＳ２６００において証明書取得手続きを行うためのアクセス先が記載されたメールを受信した利用者は、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザプログラム９２０を用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスし、認証局装置１３０から当該利用者の公開鍵証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０１８１】
また、前記証明書登録ステップＳ２９００と並行してもしくは当該ステップの実施後即時にもしくは当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）を送信し、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。本ステップの詳細は、図３３にて例示する。
【０１８２】
以上の手順によって、利用者が指定したＩＤを承認者が承認する処理と、当該ＩＤをサービス提供装置１５０に登録する処理と、当該ＩＤに基づく公開鍵証明書を発行する処理を、一連の流れで実施することが可能となる。これにより、利用者と承認者におけるＩＤ登録および公開鍵証明書発行に係る手間を軽減することが可能となる。
【０１８３】
図１９は、利用者がＩＤを登録する場合の処理フローの概要を別の実施例にて例示する図である。
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を使用してＩＤ管理装置１１０にアクセスし、ＩＤの登録を行うためのメニューを選択し、登録するＩＤを入力する（さらに必要に応じてパスワード等の各種属性も入力する）。本ステップの詳細は、図２５にて例示する。
【０１８４】
前記メニュー選択・ＩＤ指定ステップＳ２１００にてＩＤの入力が完了した後、続けて、鍵生成ステップを実施する（Ｓ２７００）。すなわち、利用者はＷｅｂの画面遷移に従ってＩＤ管理装置１１０もしくは認証局装置１３０にアクセスすることで鍵生成用の画面を取得する。そして、利用者装置１７０の鍵管理プログラム９４０を用いて利用者の秘密鍵及び公開鍵のペアを生成して公開鍵をアクセス先である当該ＩＤ管理装置１１０もしくは当該認証局装置１３０に送信する。公開鍵の送信先が認証局装置１３０の場合には、その後の画面遷移でＩＤ管理装置に戻るものとする。本ステップの詳細は、図３０にて例示する。
【０１８５】
次に、前記鍵生成ステップＳ２７００が実施された後、承認者宛メール送信ステップを実施する（Ｓ２４５０）。すなわち、ＩＤ管理装置１１０は、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を承認者に承認してもらう必要がある。このために、承認者のメールアドレスに対して承認手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０１８６】
前記承認者宛メール送信ステップＳ２４５０が完了すると、承認者宛メール受信ステップを実施する（Ｓ２６５０）。すなわち、承認者のメールアカウント宛には承認手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、承認者は、承認者装置１８０のメーラープログラム１０３０を利用してメールサーバ装置１２０にアクセスし、当該承認者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０１８７】
前記承認者宛メール受信ステップＳ２６５０において承認手続きを行うためのアクセス先が記載されたメールを受信した承認者は、承認ステップを実施する（Ｓ３３００）。すなわち、承認者は、承認者装置１８０のＷｅｂブラウザプログラム１０２０を用いて、メールに記載されたアクセス先であるＩＤ管理装置１１０にアクセスして承認内容を確認し、承認可否をＩＤ管理装置１１０に送信する。本ステップの詳細は、図３４にて例示する。
【０１８８】
前記承認ステップＳ３３００が完了したら、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を、ＩＤ管理装置１１０がサービス提供装置１５０のユーザ情報データベース７６０に反映するためのＩＤ及び属性の登録要求を送信する。本ステップの詳細は、図２６にて例示する。また、プロビジョニングの対象として、メールサーバ装置１２０のメールアカウントも含まれるのであれば、メールサーバ装置１２０のユーザ情報データベース４６０に対するＩＤ及び属性の登録要求も、本ステップで行うものとする。
【０１８９】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容をもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信する。本ステップの詳細は、図２７にて例示する。なお、プロビジョニングステップＳ２２００と証明書発行要求ステップＳ２３００の順序性は問わない。
【０１９０】
プロビジョニングステップＳ２２００及び証明書発行要求ステップＳ２３００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して証明書発行手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０１９１】
メール送信ステップＳ２４００が完了すると、利用者はメールを利用できるようになり、かつ、当該利用者のメールアカウント宛に証明書発行手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０及びメニュー選択・ＩＤ指定ステップＳ２１００にて入力したＩＤ及びパスワードを利用してメールサーバ装置１２０にアクセスし、当該利用者のメールアカウント宛に送信されたメールを取得する。メール受信ステップを実施する（Ｓ２６００）。本ステップの詳細は、図２９にて例示する。
【０１９２】
前記メール受信ステップＳ２６００において証明書発行手続きを行うためのアクセス先が記載されたメールを受信した利用者は、鍵生成ステップを実施する（Ｓ２７００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザプログラム９２０を用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスすることで鍵生成用の画面を取得する。そして、利用者装置１７０の鍵管理プログラム９４０を用いて利用者の秘密鍵及び公開鍵のペアを生成して公開鍵をアクセス先である認証局装置１３０に送信する。そして、認証局装置１３０では当該利用者の公開鍵証明書を生成する。本ステップの詳細は、図３０にて例示する。
【０１９３】
前記鍵生成ステップＳ２７００において利用者の公開鍵証明書の生成が完了した後、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は利用者装置１７０のＷｅｂブラウザプログラム９２０を用いて、認証局装置１３０から当該利用者の公開鍵証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０１９４】
前記証明書発行要求ステップＳ２３００において認証局装置１３０で利用者の公開鍵証明書の生成が完了したら、即時もしくは一定期間後に、証明書登録ステップを実施する（Ｓ２９００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該公開鍵証明書の登録要求を送信し、リポジトリ装置１４０内で当該公開鍵証明書を保存する。本ステップの詳細は、図３２にて例示する。但し、証明書発行要求ステップＳ２３００を省略した場合は、本ステップも省略する。
【０１９５】
また、前記証明書登録ステップＳ２９００と並行してもしくは当該ステップの実施後即時にもしくは当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）を送信し、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。本ステップの詳細は、図３３にて例示する。
【０１９６】
以上の手順によって、利用者が指定したＩＤを承認者が承認する処理と、当該ＩＤをサービス提供装置１５０に登録する処理と、当該ＩＤに基づく公開鍵証明書を発行する処理を、一連の流れで実施することが可能となり、利用者と承認者におけるＩＤ登録および公開鍵証明書発行に係る手間を軽減することが可能となる。
【０１９７】
図２０は、利用者がＩＤを削除、利用停止もしくは利用停止解除する場合の処理フローの概要を例示する図である。
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を使用してＩＤ管理装置１１０にアクセスし、ＩＤの削除、利用停止もしくは利用停止解除を行うためのメニューを選択し、削除、利用停止もしくは利用停止解除するＩＤを入力する。本ステップの詳細は、図２５にて例示する。
【０１９８】
前記メニュー選択・ＩＤ指定ステップＳ２１００にてＩＤの入力が完了した後、承認者宛メール送信ステップを実施する（Ｓ２４５０）。すなわち、ＩＤ管理装置１１０は、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を承認者に承認してもらう必要がある。このために、承認者のメールアドレスに対して承認手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０１９９】
前記承認者宛メール送信ステップＳ２４５０が完了すると、承認者宛メール受信ステップを実施する（Ｓ２６５０）。すなわち、承認者のメールアカウント宛には承認手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、承認者は、承認者装置１８０のメーラープログラム１０３０を利用してメールサーバ装置１２０にアクセスし、当該承認者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０２００】
前記承認者宛メール受信ステップＳ２６５０において承認手続きを行うためのアクセス先が記載されたメールを受信した承認者は、承認ステップを実施する（Ｓ３３００）。すなわち、承認者は、承認者装置１８０のＷｅｂブラウザプログラム１０２０を用いて、メールに記載されたアクセス先であるＩＤ管理装置１１０にアクセスして承認内容を確認し、承認可否をＩＤ管理装置１１０に送信する。本ステップの詳細は、図３４にて例示する。
【０２０１】
前記承認ステップＳ３３００が完了したら、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤに対して、ＩＤ管理装置１１０がサービス提供装置１５０のユーザ情報データベース７６０に反映するためのＩＤの削除要求、利用停止要求もしくは利用停止解除要求を送信する。
【０２０２】
本ステップの詳細は、図２６にて例示する。また、プロビジョニングの対象として、メールサーバ装置１２０のメールアカウントも含まれるのであれば、メールサーバ装置１２０のユーザ情報データベース４６０に対するＩＤの削除要求、利用停止要求もしくは利用停止解除要求も、本ステップで行うものとする。
【０２０３】
また、前記プロビジョニングステップＳ２２００と併せて、証明書失効要求ステップを実施する（Ｓ３１００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤをもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の失効要求、利用停止要求もしくは利用停止解除要求を送信し、認証局装置１３０にて証明書の失効情報を生成する。但し、失効情報の開示形態として、オンラインで証明書のステータスを回答するような形態をとる場合には、証明書の失効情報を生成する処理が、証明書のステータスを変更する処理に置き換わるものとする。本ステップの詳細は、図２７にて例示する。なお、プロビジョニングステップＳ２２００と証明書失効要求ステップＳ３１００の順序性は問わない。
【０２０４】
前記証明書失効ステップＳ３１００において認証局装置１３０で失効情報の生成が完了したら、即時もしくは一定期間後に、失効情報登録ステップを実施する（Ｓ３２００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該失効情報の登録要求を送信し、リポジトリ装置１４０内で当該失効情報を保存する。本ステップの詳細は、図３２にて例示する。
【０２０５】
また、前記失効情報登録ステップＳ３２００と並行してもしくは当該ステップの実施後即時にもしくは当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を失効した旨の完了通知（削除、利用停止もしくは利用停止解除の対象となったＩＤを含む）を送信する。そして、ＩＤ管理装置１１０内で完了通知時に送付された情報をもとに、ユーザ情報データベース３６０を削除もしくは変更等する。本ステップの詳細は、図３３にて例示する。
【０２０６】
以上の手順によって、利用者が指定したＩＤを承認者が承認する処理と、当該ＩＤをサービス提供装置１５０に対して削除、利用停止もしくは利用停止解除する処理と、当該ＩＤに基づく公開鍵証明書を失効、利用停止もしくは利用停止解除する処理を、一連の流れで実施することが可能となる。これにより、利用者と承認者におけるＩＤの削除、利用停止もしくは利用停止解除、および、公開鍵証明書の失効、利用停止もしくは利用停止解除に係る手間を軽減することが可能となる。
【０２０７】
図２１は、利用者がＩＤを変更する場合の処理フローの概要を例示する図である。また、公開鍵証明書に属性情報を記載する場合の属性の登録、変更、削除についても本処理フローに従うものとする。
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を使用してＩＤ管理装置１１０にアクセスし、ＩＤの変更を行うためのメニューを選択し、変更する前と後のＩＤを入力する。本ステップの詳細は、図２５にて例示する。属性の登録、変更もしくは削除時は、属性の登録、変更もしくは削除を行うためのメニューを選択し、登録、変更もしくは削除対象となるＩＤと属性を入力する。
【０２０８】
前記メニュー選択・ＩＤ指定ステップＳ２１００にてＩＤの入力が完了した後、続けて、鍵生成ステップを実施する（Ｓ２７００）。すなわち、利用者はＷｅｂの画面遷移に従ってＩＤ管理装置１１０もしくは認証局装置１３０にアクセスすることで鍵生成用の画面を取得する。そして、利用者装置１７０の鍵管理プログラム９４０を用いて利用者の秘密鍵及び公開鍵のペアを生成して公開鍵をアクセス先である当該ＩＤ管理装置１１０もしくは当該認証局装置１３０に送信する。公開鍵の送信先が認証局装置１３０の場合には、その後の画面遷移でＩＤ管理装置に戻るものとする。
【０２０９】
本ステップの詳細は、図３０にて例示する。但し、変更前のＩＤに対応した公開鍵証明書の公開鍵と変更後のＩＤに対応した公開鍵証明書の公開鍵を同じ値にする場合には、後記証明書発行要求ステップＳ２３００において、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信する情報の中に、変更前のＩＤに対応した公開鍵証明書の公開鍵を含めることによって、本ステップを省略できる。
【０２１０】
次に、前記鍵生成ステップＳ２７００が実施された後、承認者宛メール送信ステップを実施する（Ｓ２４５０）。すなわち、ＩＤ管理装置１１０は、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を承認者に承認してもらう必要がある。このために、承認者のメールアドレスに対して承認手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０２１１】
前記承認者宛メール送信ステップＳ２４５０が完了すると、承認者のメールアカウント宛には承認手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、承認者は、承認者装置１８０のメーラープログラム１０３０を利用してメールサーバ装置１２０にアクセスする。そして、当該承認者のメールアカウント宛に送信されたメールを取得するといった承認者宛メール受信ステップを実施する（Ｓ２６５０）。本ステップの詳細は、図２９にて例示する。
【０２１２】
前記承認者宛メール受信ステップＳ２６５０において承認手続きを行うためのアクセス先が記載されたメールを受信した承認者は、承認ステップを実施する（Ｓ３３００）。すなわち、承認者は、承認者装置１８０のＷｅｂブラウザプログラム１０２０を用いて、メールに記載されたアクセス先であるＩＤ管理装置１１０にアクセスして承認内容を確認し、承認可否をＩＤ管理装置１１０に送信する。本ステップの詳細は、図３４にて例示する。
【０２１３】
前記承認ステップＳ３３００が完了したら、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤに対して、ＩＤ管理装置１１０がサービス提供装置１５０のユーザ情報データベース７６０に反映するためのＩＤもしくは属性の変更要求を送信する。本ステップの詳細は、図２６にて例示する。また、プロビジョニングの対象として、メールサーバ装置１２０のメールアカウントも含まれるのであれば、メールサーバ装置１２０のユーザ情報データベース４６０に対するＩＤの変更要求も、本ステップで行うものとする。
【０２１４】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力された変更後のＩＤもしくは属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信する。そして、認証局装置１３０では要求された利用者の公開鍵証明書を生成する。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、後記証明書失効要求ステップＳ３１００と、本証明書発行要求ステップＳ２３００の順序性は問わない。
【０２１５】
さらに、前記プロビジョニングステップＳ２２００と併せて、証明書失効要求ステップを実施する（Ｓ３１００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力された変更前のＩＤをもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の失効要求を送信する。そして、認証局装置１３０にて証明書の失効情報を生成する。
【０２１６】
但し、失効情報の開示形態として、オンラインで証明書のステータスを回答するような形態をとる場合には、証明書の失効情報を生成する処理が、証明書のステータスを変更する処理に置き換わるものとする。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、前記証明書発行要求ステップＳ２３００と、本証明書失効要求ステップＳ３１００の順序性は問わない。
【０２１７】
前記証明書発行要求ステップＳ２３００において認証局装置１３０で利用者の公開鍵証明書の生成が完了したら、即時もしくは一定期間後に、証明書登録ステップを実施する（Ｓ２９００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該公開鍵証明書の登録要求を送信し、リポジトリ装置１４０内で当該公開鍵証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０２１８】
また、前記証明書失効ステップＳ３１００において認証局装置１３０で失効情報の生成が完了したら、即時もしくは一定期間後に、失効情報登録ステップを実施する（Ｓ３２００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該失効情報の登録要求を送信し、リポジトリ装置１４０内で当該失効情報を保存する。本ステップの詳細は、図３２にて例示する。
【０２１９】
プロビジョニングステップＳ２２００、証明書発行要求ステップＳ２３００及び証明書失効要求ステップＳ３１００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して変更後のＩＤに対応した証明書取得手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０２２０】
メール送信ステップＳ２４００が完了すると、利用者は変更後のＩＤを用いてメールを利用できるようになり、かつ、当該利用者のメールアカウント宛に証明書取得手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０及びメニュー選択・ＩＤ指定ステップＳ２１００にて入力したＩＤ及びパスワードを利用してメールサーバ装置１２０にアクセスする。そして、当該利用者のメールアカウント宛に送信されたメールを取得するといったメール受信ステップを実施する（Ｓ２６００）。本ステップの詳細は、図２９にて例示する。
【０２２１】
前記メール受信ステップＳ２６００において証明書取得手続きを行うためのアクセス先が記載されたメールを受信した利用者は、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザプログラム９２０を用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスする。そして、認証局装置１３０から当該利用者の公開鍵証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０２２２】
また、前記証明書登録ステップＳ２９００と並行してもしくは当該ステップの実施後即時にもしくは当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０は、ＩＤ管理装置１１０に変更後のＩＤに対する証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）及び変更前のＩＤに対する証明書を失効した旨の通知（失効の対象となったＩＤを含む）を送信する。
【０２２３】
そして、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。また、本ステップは、証明書の登録の完了通知と証明書の失効の完了通知を兼ねているが、これらは別々に実施してもよい。すなわち、前記証明書失効ステップＳ３２００と並行して、もしくは、当該ステップの実施後即時に、もしくは、当該ステップの実施後一定期間後に、変更前のＩＤに対する証明書を失効した旨の通知（失効の対象となったＩＤを含む）を送信してもよい。本ステップの詳細は、図３３にて例示する。
【０２２４】
以上の手順によって、利用者が指定したＩＤを承認者が承認する処理と、利用者が指定した変更前のＩＤをサービス提供装置１５０から削除する処理と、変更前のＩＤに基づく公開鍵証明書を失効する処理と、利用者が指定した変更後のＩＤをサービス提供装置１５０に登録する処理と、変更後のＩＤに基づく公開鍵証明書を発行する処理を、一連の流れで実施することが可能となる。これにより、利用者と承認者におけるＩＤ変更および公開鍵証明書再発行に係る手間を軽減することが可能となる。
【０２２５】
図２２は、利用者がＩＤを変更する場合の処理フローの概要を別の実施例にて例示する図である。また、公開鍵証明書に属性情報を記載する場合の属性の登録、変更、削除についても本処理フローに従うものとする。
【０２２６】
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を使用してＩＤ管理装置１１０にアクセスし、ＩＤの変更を行うためのメニューを選択し、変更する前と後のＩＤを入力する。本ステップの詳細は、図２５にて例示する。属性の登録、変更もしくは削除時は、属性の登録、変更もしくは削除を行うためのメニューを選択し、登録、変更もしくは削除対象となるＩＤと属性を入力する。
【０２２７】
前記メニュー選択・ＩＤ指定ステップＳ２１００にてＩＤの入力が完了した後、承認者宛メール送信ステップを実施する（Ｓ２４５０）。すなわち、ＩＤ管理装置１１０は、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を承認者に承認してもらう必要がある。このために、承認者のメールアドレスに対して承認手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０２２８】
前記承認者宛メール送信ステップＳ２４５０が完了すると、承認者宛メール受信ステップを実施する（Ｓ２６５０）。すなわち、承認者のメールアカウント宛には承認手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、承認者は、承認者装置１８０のメーラープログラム１０３０を利用してメールサーバ装置１２０にアクセスし、当該承認者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０２２９】
前記承認者宛メール受信ステップＳ２６５０において承認手続きを行うためのアクセス先が記載されたメールを受信した承認者は、承認ステップを実施する（Ｓ３３００）。すなわち、承認者は、承認者装置１８０のＷｅｂブラウザプログラム１０２０を用いて、メールに記載されたアクセス先であるＩＤ管理装置１１０にアクセスして承認内容を確認し、承認可否をＩＤ管理装置１１０に送信する。本ステップの詳細は、図３４にて例示する。
【０２３０】
前記承認ステップＳ３３００が完了したら、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤに対して、ＩＤ管理装置１１０がサービス提供装置１５０のユーザ情報データベース７６０に反映するためのＩＤもしくは属性の変更要求を送信する。本ステップの詳細は、図２６にて例示する。また、プロビジョニングの対象として、メールサーバ装置１２０のメールアカウントも含まれるのであれば、メールサーバ装置１２０のユーザ情報データベース４６０に対するＩＤの変更要求も、本ステップで行うものとする。
【０２３１】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力された変更後のＩＤもしくは属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信する。
【０２３２】
ここで、変更前のＩＤに対応した公開鍵証明書の公開鍵と変更後のＩＤに対応した公開鍵証明書の公開鍵を同じ値にする場合には、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信する情報の中に、変更前のＩＤに対応した公開鍵証明書の公開鍵を含めることによって、本ステップ内で公開鍵証明書を生成できる。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、後記証明書失効要求ステップＳ３１００と、本証明書発行要求ステップＳ２３００の順序性は問わない。
【０２３３】
さらに、前記プロビジョニングステップＳ２２００と併せて、証明書失効要求ステップを実施する（Ｓ３１００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力された変更前のＩＤをもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の失効要求を送信する。そして、認証局装置１３０にて証明書の失効情報を生成する。
【０２３４】
但し、失効情報の開示形態として、オンラインで証明書のステータスを回答するような形態をとる場合には、証明書の失効情報を生成する処理が、証明書のステータスを変更する処理に置き換わるものとする。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、前記証明書発行要求ステップＳ２３００と、本証明書失効要求ステップＳ３１００の順序性は問わない。
【０２３５】
前記証明書失効ステップＳ３１００において認証局装置１３０で失効情報の生成が完了したら、即時もしくは一定期間後に、失効情報登録ステップを実施する（Ｓ３２００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該失効情報の登録要求を送信し、リポジトリ装置１４０内で当該失効情報を保存する。本ステップの詳細は、図３２にて例示する。
【０２３６】
プロビジョニングステップＳ２２００、証明書発行要求ステップＳ２３００及び証明書失効要求ステップＳ３１００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して変更後のＩＤに対応した証明書発行手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０２３７】
メール送信ステップＳ２４００が完了すると、利用者は変更後のＩＤを用いてメールを利用できるようになり、かつ、当該利用者のメールアカウント宛に証明書発行手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０及びメニュー選択・ＩＤ指定ステップＳ２１００にて入力したＩＤ及びパスワードを利用してメールサーバ装置１２０にアクセスする。そして、当該利用者のメールアカウント宛に送信されたメールを取得するといったメール受信ステップを実施する（Ｓ２６００）。本ステップの詳細は、図２９にて例示する。
【０２３８】
前記メール受信ステップＳ２６００において証明書発行手続きを行うためのアクセス先が記載されたメールを受信した利用者は、鍵生成ステップを実施する（Ｓ２７００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザプログラム９２０を用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスすることで鍵生成用の画面を取得する。
【０２３９】
そして、利用者装置１７０の鍵管理プログラム９４０を用いて利用者の秘密鍵及び公開鍵のペアを生成して公開鍵をアクセス先である認証局装置１３０に送信する。そして、認証局装置１３０では当該利用者の公開鍵証明書を生成する。但し、前記証明書発行要求ステップ２３００において既に公開鍵証明書を生成している場合、本ステップは省略される。本ステップの詳細は、図３０にて例示する。
【０２４０】
前記鍵生成ステップＳ２７００もしくは前記証明書発行要求ステップ２３００において利用者の公開鍵証明書の生成が完了した後、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は利用者装置１７０のＷｅｂブラウザプログラム９２０を用いて、認証局装置１３０から当該利用者の公開鍵証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０２４１】
前記鍵生成ステップＳ２７００もしくは前記証明書発行要求ステップ２３００において認証局装置１３０で利用者の公開鍵証明書の生成が完了したら、即時もしくは一定期間後に、証明書登録ステップを実施する（Ｓ２９００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該公開鍵証明書の登録要求を送信し、リポジトリ装置１４０内で当該公開鍵証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０２４２】
前記証明書登録ステップＳ２９００と並行してもしくは当該ステップの実施後即時にもしくは当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０からＩＤ管理装置１１０へ変更後のＩＤに対する証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）及び変更前のＩＤに対する証明書を失効した旨の通知（失効の対象となったＩＤを含む）を送信する。
【０２４３】
そして、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。また、本ステップは、証明書の登録の完了通知と証明書の失効の完了通知を兼ねているが、これらは別々に実施してもよい。すなわち、前記証明書失効ステップＳ３２００と並行して、もしくは、当該ステップの実施後即時に、もしくは、当該ステップの実施後一定期間後に、変更前のＩＤに対する証明書を失効した旨の通知（失効の対象となったＩＤを含む）を送信してもよい。本ステップの詳細は、図３３にて例示する。
【０２４４】
以上の手順によって、利用者が指定したＩＤを承認者が承認する処理と、利用者が指定した変更前のＩＤをサービス提供装置１５０から削除する処理と、変更前のＩＤに基づく公開鍵証明書を失効する処理と、利用者が指定した変更後のＩＤをサービス提供装置１５０に登録する処理と、変更後のＩＤに基づく公開鍵証明書を発行する処理を、一連の流れで実施することが可能となり、利用者と承認者におけるＩＤ変更および公開鍵証明書再発行に係る手間を軽減することが可能となる。
【０２４５】
図２３は、利用者が属性情報を登録する場合の処理フローの概要を例示する図である。
但し、図２３は属性情報の表現に属性証明書を用いる場合を想定しており、属性情報の表現に公開鍵証明書を用いる場合は、図２１もしくは図２２の手順に従うものとする。
【０２４６】
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を使用してＩＤ管理装置１１０にアクセスし、属性の追加を行うためのメニューを選択し、その対象となるＩＤと追加する属性情報を入力する。本ステップの詳細は、図２５にて例示する。
【０２４７】
前記メニュー選択・ＩＤ指定ステップＳ２１００にてＩＤの入力が完了した後、承認者宛メール送信ステップを実施する（Ｓ２４５０）。すなわち、ＩＤ管理装置１１０は、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を承認者に承認してもらう必要がある。このために、承認者のメールアドレスに対して承認手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０２４８】
前記承認者宛メール送信ステップＳ２４５０が完了すると、承認者宛メール受信ステップを実施する（Ｓ２６５０）。すなわち、承認者のメールアカウント宛には承認手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、承認者は、承認者装置１８０のメーラープログラム１０３０を利用してメールサーバ装置１２０にアクセスし、当該承認者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０２４９】
前記承認者宛メール受信ステップＳ２６５０において承認手続きを行うためのアクセス先が記載されたメールを受信した承認者は、承認ステップを実施する（Ｓ３３００）。すなわち、承認者は、承認者装置１８０のＷｅｂブラウザプログラム１０２０を用いて、メールに記載されたアクセス先であるＩＤ管理装置１１０にアクセスして承認内容を確認し、承認可否をＩＤ管理装置１１０に送信する。本ステップの詳細は、図３４にて例示する。
【０２５０】
前記承認ステップＳ３３００が完了したら、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性に対して、ＩＤ管理装置１１０がサービス提供装置１５０のユーザ情報データベース７６０に反映するための属性追加要求を送信する。本ステップの詳細は、図２６にて例示する。
【０２５１】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に属性証明書の発行要求を送信する。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、本証明書発行要求ステップＳ２３００の順序性は問わない。
【０２５２】
前記証明書発行ステップＳ２３００において認証局装置１３０で利用者の属性証明書の生成が完了したら、即時もしくは一定期間後に、証明書登録ステップを実施する（Ｓ２９００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該属性証明書の登録要求を送信し、リポジトリ装置１４０内で当該属性証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０２５３】
プロビジョニングステップＳ２２００、証明書発行要求ステップＳ２３００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して証明書取得手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。
【０２５４】
但し、属性証明書の利用形態として、以下の場合には本ステップは省略してもよい。すなわち、属性証明書の保有者から属性証明書の検証者に属性証明書を提示するというプッシュ型ではなく、属性証明書の検証者がリポジトリ等の公開サーバに属性証明書を取りにいくというプル型の場合である。本ステップの詳細は、図２８にて例示する。
【０２５５】
メール送信ステップＳ２４００が実施された場合には、利用者は自身のメールアカウント宛に証明書取得手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０を利用してメールサーバ装置１２０にアクセスする。そして、当該利用者のメールアカウント宛に送信されたメールを取得するといったメール受信ステップを実施する（Ｓ２６００）。本ステップの詳細は、図２９にて例示する。
【０２５６】
前記メール受信ステップＳ２６００において証明書取得手続きを行うためのアクセス先が記載されたメールを受信した利用者は、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザを用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスする。そして、認証局装置１３０から属性証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０２５７】
一方、前記証明書登録ステップＳ２９００と並行して、もしくは、当該ステップの実施後即時に、もしくは、当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）を送信する。そして、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。本ステップの詳細は、図３３にて例示する。
【０２５８】
以上の手順によって、利用者が指定したＩＤに対する属性の追加を承認者が承認する処理と、当該ＩＤに対してサービス提供装置１５０に属性を追加する処理と、当該ＩＤに基づく属性証明書を発行する処理を、一連の流れで実施することが可能となり、利用者と承認者における属性追加および属性証明書発行に係る手間を軽減することが可能となる。
【０２５９】
図２４は、利用者が属性情報を変更もしくは削除する場合の処理フローの概要を例示する図である。但し、図２４は属性情報の表現に属性証明書を用いる場合を想定しており、属性情報の表現に公開鍵証明書を用いる場合は、図２１もしくは図２２の手順に従うものとする。
【０２６０】
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を使用してＩＤ管理装置１１０にアクセスし、属性の変更もしくは削除を行うためのメニューを選択し、その対象となるＩＤと変更もしくは削除する属性情報を入力する。本ステップの詳細は、図２５にて例示する。
【０２６１】
前記メニュー選択・ＩＤ指定ステップＳ２１００にてＩＤの入力が完了した後、承認者宛メール送信ステップを実施する（Ｓ２４５０）。すなわち、ＩＤ管理装置１１０は、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を承認者に承認してもらう必要がある。このために、承認者のメールアドレスに対して承認手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０２６２】
前記承認者宛メール送信ステップＳ２４５０が完了すると、承認者のメールアカウント宛には承認手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、承認者は、承認者装置１８０のメーラープログラム１０３０を利用してメールサーバ装置１２０にアクセスし、当該承認者のメールアカウント宛に送信されたメールを取得する承認者宛メール受信ステップを実施する（Ｓ２６５０）。本ステップの詳細は、図２９にて例示する。
【０２６３】
前記承認者宛メール受信ステップＳ２６５０において承認手続きを行うためのアクセス先が記載されたメールを受信した承認者は、承認ステップを実施する（Ｓ３３００）。すなわち、承認者は、承認者装置１８０のＷｅｂブラウザプログラム１０２０を用いて、メールに記載されたアクセス先であるＩＤ管理装置１１０にアクセスして承認内容を確認し、承認可否をＩＤ管理装置１１０に送信する。本ステップの詳細は、図３４にて例示する。
【０２６４】
前記承認ステップＳ３３００が完了したら、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性に対して、ＩＤ管理装置１１０がサービス提供装置１５０のユーザ情報データベース７６０に反映するための属性追加要求を送信するといった本ステップの詳細は、図２６にて例示する。
【０２６５】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に属性証明書の発行要求を送信する。但し、属性の変更もしくは削除の内容に応じて、新たに属性証明書を発行する必要がない場合、本ステップは省略される。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、後記証明書失効要求ステップＳ３１００と、本証明書発行要求ステップＳ２３００の順序性は問わない。
【０２６６】
さらに、前記プロビジョニングステップＳ２２００と併せて、証明書失効要求ステップを実施する（Ｓ３１００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に属性証明書の失効要求を送信する。そして、認証局装置１３０にて属性証明書失効情報を生成する。但し、失効情報の開示形態として、オンラインで証明書のステータスを回答するような形態をとる場合には、属性証明書失効情報を生成する処理が、属性証明書のステータスを変更する処理に置き換わるものとする。
【０２６７】
ここで、どの属性証明書を失効するかは、メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性と、図１２の説明にて記載したＩＤ管理装置１１０内のユーザ情報データベース３６０内の証明書情報３６２である証明書のＩＤとその記載属性型を比較して合致したものが選択されるものとする。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、前記証明書発行要求ステップＳ２３００と、本証明書失効要求ステップＳ３１００の順序性は問わない。
【０２６８】
前記証明書発行ステップＳ２３００が実施され、認証局装置１３０で利用者の属性証明書の生成が完了した場合には、即時もしくは一定期間後に、証明書登録ステップを実施する（Ｓ２９００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該属性証明書の登録要求を送信し、リポジトリ装置１４０内で当該属性証明書を保存する。本ステップの詳細は、図３２にて例示する。但し、証明書発行要求ステップＳ２３００を省略した場合は、本ステップも省略する。
【０２６９】
また、前記証明書失効ステップＳ３１００において認証局装置１３０で属性証明書失効情報の生成が完了したら、即時もしくは一定期間後に、失効情報登録ステップを実施する（Ｓ３２００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該失効情報の登録要求を送信し、リポジトリ装置１４０内で当該失効情報を保存する。本ステップの詳細は、図３２にて例示する。
【０２７０】
プロビジョニングステップＳ２２００、証明書発行要求ステップＳ２３００及び証明書失効要求ステップＳ３１００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して証明書取得手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。但し、属性証明書の利用形態として、以下の場合には本ステップは省略してもよい。すなわち、属性証明書の保有者から属性証明書の検証者に属性証明書を提示するというプッシュ型ではなく、属性証明書の検証者がリポジトリ等の公開サーバに属性証明書を取りにいくというプル型の場合である。本ステップの詳細は、図２８にて例示する。
【０２７１】
メール送信ステップＳ２４００が実施された場合には、利用者は自身のメールアカウント宛に証明書取得手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０を利用してメールサーバ装置１２０にアクセスし、当該利用者のメールアカウント宛に送信されたメールを取得するメール受信ステップを実施する（Ｓ２６００）。本ステップの詳細は、図２９にて例示する。
【０２７２】
前記メール受信ステップＳ２６００において証明書取得手続きを行うためのアクセス先が記載されたメールを受信した利用者は、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザを用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスし、認証局装置１３０から属性証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０２７３】
一方、前記証明書登録ステップＳ２９００と並行して、もしくは、当該ステップの実施後即時に、もしくは、当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）を送信する。そして、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。本ステップの詳細は、図３３にて例示する。
【０２７４】
以上の手順によって、利用者が指定したＩＤに対する属性の変更もしくは削除を承認者が承認する処理と、当該ＩＤに対してサービス提供装置１５０に属性を変更もしくは削除する処理と、当該ＩＤに基づく属性証明書を失効もしくは再発行する処理を、一連の流れで実施することが可能となる。これにより、管理者における属性変更もしくは削除および属性証明書失効もしくは再発行に係る手間を軽減することが可能となる。
【０２７５】
図２５は、メニュー選択・ＩＤ指定ステップにおける処理フローの詳細を例示する図である。ここでは、メニューの選択やＩＤの指定を行う側である管理者装置１６０もしくは利用者装置１７０と、選択されたメニューや指定されたＩＤを受け付ける側のＩＤ管理装置１１０との間の処理手順について示す。
【０２７６】
はじめに、メニューの選択やＩＤの指定を行う者が管理者である場合は、管理者が管理者装置１６０のＷｅｂブラウザプログラム８２０を起動する。メニューの選択やＩＤの指定を行う者が利用者である場合は、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を起動する（Ｓ２１０１）。
【０２７７】
次に、管理者もしくは利用者は、前記ステップＳ２１０１において起動したＷｅｂブラウザプログラムに、ＩＤ管理装置１１０が提供するＩＤ管理サービスのＵＲＬ（Uniform Resource Locator）を入力し、ＩＤ管理装置１１０にアクセスする（Ｓ２１０２）。
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ２１０２において送信されたアクセス要求を受信する（Ｓ２１０３）。
【０２７８】
続けて、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、アクセス要求を送信してきた管理者装置１６０もしくは利用者装置１７０に対して、ＩＤ管理サービスのトップ画面データを返信する（Ｓ２１０４）。トップ画面データには、ＩＤ及びパスワード等の認証情報を入力する欄が含まれているものとする。
【０２７９】
本実施の形態例では、ＩＤ及びパスワードを用いた認証方法について例示するが、当該認証方法は既知の認証方法に置き換えてもよく、認証方法をＩＤ及びパスワードに限定するものではない。また、利用者がＩＤ管理を行うシステムとする場合、トップ画面データには、利用者がＩＤを登録するためのメニューも存在するものとする。
【０２８０】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１０４においてＩＤ管理装置１１０が送信してきたトップ画面データを受信し、管理者もしくは利用者に対してトップ画面を表示する（Ｓ２１０５）。この後、利用者がＩＤの登録を行う場合は、利用者がＩＤを登録するためのメニューを選択することで、後記Ｓ２１１２に遷移する。利用者がＩＤの登録を行う場合以外については、管理者もしくは利用者が、ＩＤ及びパスワード等の認証情報を入力することで、次のステップＳ２１０６に遷移する。
【０２８１】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２１０５にて入力された認証情報をＩＤ管理装置１１０に送信する（Ｓ２１０６）。
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ２１０６において送信された認証情報を受信する（Ｓ２１０７）。
【０２８２】
ＩＤ管理装置１１０のユーザ認証プログラム３２０は、前記ステップＳ２１０７において受信した認証情報と、アクセス制御データ３６０もしくはユーザ情報データベース３７０内に保存されている認証情報とを用いて、ユーザの認証を行う（Ｓ２１０８）。Ｓ２１０８でユーザの認証に失敗した場合は、認証に失敗した旨の表示を行う画面データを管理者装置１６０もしくは利用者装置１７０に送信し、後記Ｓ２１０９に遷移する。Ｓ２１０８でユーザの認証に成功した場合には、そのまま後記Ｓ２１１０に遷移する。
【０２８３】
Ｓ２１０８でユーザ認証に失敗した場合、管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１０８においてＩＤ管理装置１１０が送信してきた画面データを受信し、管理者もしくは利用者に対して認証に失敗した旨の表示を行い、処理を中断する（Ｓ２１０９）。
【０２８４】
Ｓ２１０８ユーザ認証に成功した場合、当該ユーザに応じたメニュー画面データを管理者装置１６０もしくは利用者装置１７０に送信する（Ｓ２１１０）。認証したユーザが管理者権限であった場合には、管理者用のＩＤ管理メニューが表示され、認証したユーザが利用者権限であった場合には、利用者用のＩＤ管理メニューが表示されるものとする。メニュー画面には、ＩＤの登録、ＩＤの削除、ＩＤの利用停止、ＩＤの利用停止解除、ＩＤの変更、属性の追加、属性の削除、属性の変更といったメニューの全部もしくは一部が存在するものとする。
【０２８５】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１０８においてＩＤ管理装置１１０が送信してきたメニュー画面データを受信し、管理者もしくは利用者に対してメニュー画面を表示する（Ｓ２１１１）。この後、管理者もしくは利用者がメニューを選択することで、後記Ｓ２１１２に遷移する。
【０２８６】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１１１もしくは前記ステップＳ２１０５において、管理者もしくは利用者が選択したメニューの内容を、ＩＤ管理装置１１０に送信する（Ｓ２１１２）。
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ２１１２において送信されたメニューの内容を受信する（Ｓ２１１３）。
【０２８７】
続けて、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、管理者装置１６０もしくは利用者装置１７０に対して、前記ステップＳ２１１３にて受信したメニューの内容に応じた入力画面データを返信する（Ｓ２１１４）。入力画面データには、対象となるＩＤや当該ＩＤに付随する属性値等を入力する欄が含まれているものとする。
【０２８８】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１１４においてＩＤ管理装置１１０が送信してきた入力画面データを受信し、管理者もしくは利用者に対して入力画面を表示する（Ｓ２１１５）。この後、管理者もしくは利用者が入力画面に必要な情報を入力することで、後記Ｓ２１１６に遷移する。
【０２８９】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１１５において、管理者もしくは利用者が入力した各種情報を、ＩＤ管理装置１１０に送信する（Ｓ２１１６）。
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ２１１６において送信された入力情報を受信する（Ｓ２１１７）。
【０２９０】
続けて、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ２１１７にて受信した入力情報に基づく確認画面データを生成し、管理者装置１６０もしくは利用者装置１７０に対して、当該確認画面データを返信する（Ｓ２１１８）。
【０２９１】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１１８においてＩＤ管理装置１１０が送信してきた確認画面データを受信し、管理者もしくは利用者に対して確認画面を表示する（Ｓ２１１９）。この後、管理者もしくは利用者が確認画面に対する内容の是非を判断した結果を入力することで、後記Ｓ２１２０に遷移する。
【０２９２】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１１９において、管理者もしくは利用者が入力した確認結果情報を、ＩＤ管理装置１１０に送信する（Ｓ２１２０）。
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ２１２０において送信された確認結果情報を受信する（Ｓ２１２１）。
【０２９３】
続けて、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ２１２１にて受信した確認結果情報を判定する（Ｓ２１２２）。Ｓ２１２２の判定結果が確認画面の内容を了承した旨のものであった場合には、後記ステップＳ２１２３に遷移する。Ｓ２１２２の判定結果が確認画面の内容を了承しない旨のものであった場合には、管理者装置１６０もしくは利用者装置１７０に対して、前記ステップＳ２１１５における入力画面を返信する。当該入力画面には、前記ステップＳ２１１７で受信した入力情報を入力欄に含めて修正画面データのような形態でデータを返信してもよい。
【０２９４】
Ｓ２１２２の判定結果で確認画面の内容が了承されたと判断した場合、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、図１３から図２４におけるメニュー選択・ＩＤ指定ステップＳ２１００の次のステップに処理を遷移させるとともに、前記ステップＳ２１１７にて受信した入力情報に基づく受付結果等の画面データを生成し、管理者装置１６０もしくは利用者装置１７０に対して、当該画面データを返信する（Ｓ２１２３）。
【０２９５】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１１８においてＩＤ管理装置１１０が送信してきた受付結果等が記載された画面データを受信し、管理者もしくは利用者に対して当該画面を表示する（Ｓ２１１９）。
以上で、管理者装置１６０もしくは利用者装置１７０と、ＩＤ管理装置１１０との間で実施されるメニュー選択・ＩＤ指定ステップＳ２１００の処理が完了する。
【０２９６】
図２６は、プロビジョニングステップにおける処理フローの詳細を例示する図である。ここでは、ユーザ情報の展開元であるＩＤ管理装置１１０と、ユーザ情報の展開先であるサービス提供装置１５０との間の処理手順について示す。プロビジョニングの対象となるサービス提供装置１５０が複数存在する場合には、サービス提供装置１５０毎に本処理手順が実施される。
【０２９７】
はじめに、ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、プロビジョニングの対象となるサービス提供装置１５０に対して、接続要求を送信する（Ｓ２２０１）。
サービス提供装置１５０のアカウント管理プログラム７３０は、前記ステップＳ２２０１において送信された接続要求を受信する（Ｓ２２０２）。
【０２９８】
続けて、サービス提供装置１５０のアカウント管理プログラム７３０は、接続要求を送信してきたＩＤ管理装置１１０に対して、認証情報を要求するメッセージを返信する（Ｓ２２０３）。本実施の形態例では、ＩＤ及びパスワードを用いた認証方法を採用するものとし、ここではＩＤ及びパスワードを要求するメッセージを返信する。但し、ここでの認証方法は既知の認証方法に置き換えてもよく、認証方法をＩＤ及びパスワードに限定するものではない。
【０２９９】
ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、前記ステップＳ２２０３においてサービス提供装置１５０が送信してきた認証要求を受信する（Ｓ２２０４）。
続いて、ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、サービス提供装置１５０にアクセスするための認証情報であるＩＤ及びパスワードを、サービス提供装置１５０に送信する（Ｓ２２０５）。ここで、サービス提供装置１５０にアクセスするための認証情報は、あらかじめＩＤ管理装置１１０内に設定されているものとする。
【０３００】
サービス提供装置１５０のアカウント管理プログラム７３０は、前記ステップＳ２２０５において送信された認証情報を受信する（Ｓ２２０６）。
サービス提供装置１５０のユーザ認証プログラム７２０は、前記ステップＳ２２０６において受信した認証情報と、アクセス制御データ７５０内に保存されている認証情報とを用いて、ユーザの認証を行う（Ｓ２２０７）。Ｓ２２０７でユーザの認証に失敗した場合は、認証に失敗した旨の結果をＩＤ管理装置１１０に送信し、後記Ｓ２２０８に遷移する。Ｓ２２０７でユーザの認証に成功した場合には、そのまま後記Ｓ２２０９に遷移する。
【０３０１】
Ｓ２２０７でユーザ認証に失敗した場合、ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、前記ステップＳ２２０７においてサービス提供装置１５０が送信してきた結果を受信し（Ｓ２２０８）、認証に失敗した旨の判断を行い、処理を中断する。
Ｓ２２０７でユーザ認証に成功した場合、サービス提供装置１５０のアカウント管理プログラム７３０は、サービス提供装置１５０側で実行するためのコマンドを要求するために、ＩＤ管理装置１１０にコマンド要求を送信する（Ｓ２２０９）。
【０３０２】
ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、前記ステップＳ２２０９においてサービス提供装置１５０が送信してきたコマンド要求を受信する（Ｓ２２１０）。
ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、上述したメニュー選択・ＩＤ指定ステップＳ２１００において選択されたメニューに応じて適切なコマンドをサービス提供装置１５０に送信する（Ｓ２２１１）。例えば、メニュー選択・ＩＤ指定ステップＳ２１００においてＩＤの登録が選択された場合には、ＩＤを登録する旨のコマンドと登録するＩＤの値等を送信する。
【０３０３】
サービス提供装置１５０のアカウント管理プログラム７３０は、前記ステップＳ２２１１において送信されたコマンドを受信する（Ｓ２２１２）。
次に、サービス提供装置１５０のアカウント管理プログラム７３０は、前記ステップ２２１２において受信したコマンドを実行する（Ｓ２２１３）。例えば、前記ステップ２２１２においてＩＤを登録する旨のコマンドと登録するＩＤの値等が送信されてきた場合、サービス提供装置１５０内のユーザ情報データベース７６０に、送信されてきたＩＤを登録し、当該ＩＤを用いて業務サービスプログラム７４０が利用できるようにする。
【０３０４】
続けて、サービス提供装置１５０のアカウント管理プログラム７３０は、前記ステップＳ２２１３においてコマンドを実行した結果を、ＩＤ管理装置１１０に対して返信する（Ｓ２２１４）。
ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、前記ステップＳ２２１４においてサービス提供装置１５０が送信してきたコマンド実行結果を受信する（Ｓ２２１５）。
以上で、ＩＤ管理装置１１０とサービス提供装置１５０との間で実施されるプロビジョニングステップＳ２２００の処理が完了する。
【０３０５】
図２７は、証明書発行要求ステップあるいは証明書失効要求ステップにおける処理フローの詳細を例示する図である。ここでは、証明書の発行あるいは失効の要求元であるＩＤ管理装置１１０と、証明書の発行あるいは失効を実施する認証局装置１３０との間の処理手順について示す。証明書の発行あるいは失効の対象となる認証局装置１３０が複数存在する場合には、認証局装置１３０毎に本処理手順が実施される。
【０３０６】
はじめに、ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、証明書の発行あるいは失効の対象となる認証局装置１３０に対して、接続要求を送信する（Ｓ２３０１）。
認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ２３０１において送信された接続要求を受信する（Ｓ２３０２）。
【０３０７】
続けて、認証局装置１３０の証明書管理プログラム５３０は、接続要求を送信してきたＩＤ管理装置１１０に対して、認証情報を要求するメッセージを返信する（Ｓ２３０３）。本実施の形態例では、ＩＤ及びパスワードを用いた認証方法を採用するものとし、ここではＩＤ及びパスワードを要求するメッセージを返信する。但し、ここでの認証方法は既知の認証方法に置き換えてもよく、認証方法をＩＤ及びパスワードに限定するものではない。
【０３０８】
ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、前記ステップＳ２３０３において認証局装置１３０が送信してきた認証要求を受信する（Ｓ２３０４）。
続いて、ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、認証局装置１３０にアクセスするための認証情報であるＩＤ及びパスワードを、認証局装置１３０に送信する（Ｓ２３０５）。ここで、認証局装置１３０にアクセスするための認証情報は、あらかじめＩＤ管理装置内に設定されているものとする。
【０３０９】
認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ２３０５において送信された認証情報を受信する（Ｓ２３０６）。
認証局装置１３０のユーザ認証プログラム５２０は、前記ステップＳ２３０６において受信した認証情報と、アクセス制御データ５５０内に保存されている認証情報とを用いて、ユーザの認証を行う（Ｓ２３０７）。Ｓ２３０７でユーザの認証に失敗した場合は、認証に失敗した旨の結果をＩＤ管理装置１１０に送信し、後記Ｓ２３０８に遷移する。Ｓ２３０７でユーザの認証に成功した場合には、そのまま後記Ｓ２３０９に遷移する。
【０３１０】
Ｓ２３０７でユーザ認証に失敗した場合、ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、前記ステップＳ２３０７において認証局装置１３０が送信してきた結果を受信し（Ｓ２３０８）、認証に失敗した旨の判断を行い、処理を中断する。
Ｓ２３０７でユーザ認証に成功した場合、認証局装置１３０の証明書管理プログラム５３０は、認証局装置１３０で実行するためのコマンドを要求するために、ＩＤ管理装置１１０にコマンド要求を送信する（Ｓ２３０９）。
【０３１１】
ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、前記ステップＳ２３０９において認証局装置１３０が送信してきたコマンド要求を受信する（Ｓ２３１０）。
ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、上述したメニュー選択・ＩＤ指定ステップＳ２１００において選択されたメニューに応じて適切なコマンドを認証局装置１３０に送信する（Ｓ２３１１）。例えば、メニュー選択・ＩＤ指定ステップＳ２１００においてＩＤの登録が選択された場合には、公開鍵証明書を発行する旨のコマンドと公開鍵証明書の発行に必要なユーザ情報（ＩＤ、属性、公開鍵等）を送信する。
【０３１２】
認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ２３１１において送信されたコマンドを受信する（Ｓ２３１２）。
次に、認証局装置１３０の証明書管理プログラム５３０は、前記ステップ２３１２において受信したコマンドを実行する（Ｓ２３１３）。例えば、前記ステップ２３１２において公開鍵証明書を発行する旨のコマンドと発行に必要なユーザ情報が送信されてきた場合、当該ユーザ情報を保存しておき、公開鍵が送付されてきた時点で公開鍵証明書を生成できるように準備する。ユーザ情報内に公開鍵が含まれている場合には、当該ユーザ情報を用いて利用者の公開鍵証明書を生成までを行う。
【０３１３】
続けて、認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ２３１３においてコマンドを実行した結果を、ＩＤ管理装置１１０に対して返信する（Ｓ２３１４）。
ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、前記ステップＳ２３１４において認証局装置１３０が送信してきたコマンド実行結果を受信する（Ｓ２３１５）。
【０３１４】
以上で、ＩＤ管理装置１１０と認証局装置１３０との間で実施される証明書発行要求ステップＳ２３００もしくは証明書失効要求ステップＳ３１００の処理が完了する。なお、証明書発行要求ステップＳ２３００と証明書失効要求ステップＳ３１００が連続して実施される場合、後で実施されるステップは、先に実施されたステップに続けて、Ｓ２３１１に遷移するものとし、Ｓ２３０１からＳ２３１０までの認証を行う処理を省略してもよい。
【０３１５】
図２８は、メール送信ステップにおける処理フローの詳細を例示する図である。ここでは、メールの送信元であるＩＤ管理装置１１０と、メールの管理先であるメールサーバ装置１２０との間の処理手順について示す。
はじめに、ＩＤ管理装置１１０のメール送信プログラム３５０は、メールサーバ装置１２０に対して、接続要求を送信する（Ｓ２４０１）。
メールサーバ装置１２０のメール管理プログラム４４０は、前記ステップＳ２４０１において送信された接続要求を受信する（Ｓ２４０２）。
【０３１６】
続けて、メールサーバ装置１２０のメール管理プログラム４４０は、接続要求を送信してきたＩＤ管理装置１１０に対して、認証情報を要求するメッセージを返信する（Ｓ２４０３）。本実施の形態例では、ＩＤ及びパスワードを用いた認証方法を採用するものとし、ここではＩＤ及びパスワードを要求するメッセージを返信する。但し、ここでの認証方法は既知の認証方法に置き換えてもよく、認証方法をＩＤ及びパスワードに限定するものではない。また、但し、メール送信に使用するプロトコルにおいて認証を必要としないものを採用する場合には、本ステップＳ２４０３からＳ２４０７までの手順が省略され、後記ステップＳ２４０９に遷移するものとする。
【０３１７】
ＩＤ管理装置１１０のメール送信プログラム３５０は、前記ステップＳ２４０３においてメールサーバ装置１２０が送信してきた認証要求を受信する（Ｓ２４０４）。
続いて、ＩＤ管理装置１１０のメール送信プログラム３５０は、メールサーバ装置１２０にアクセスするための認証情報であるＩＤ及びパスワードを、メールサーバ装置１２０に送信する（Ｓ２４０５）。ここで、メールサーバ装置１２０にアクセスするための認証情報は、あらかじめＩＤ管理装置内に設定されているものとする。
【０３１８】
メールサーバ装置１２０のメール管理プログラム４４０は、前記ステップＳ２４０５において送信された認証情報を受信する（Ｓ２４０６）。
メールサーバ装置１２０のユーザ認証プログラム４２０は、前記ステップＳ２４０６において受信した認証情報と、アクセス制御データ４５０もしくはユーザ情報データベース４６０内に保存されている認証情報とを用いて、ユーザの認証を行う（Ｓ２４０７）。Ｓ２４０７でユーザの認証に失敗した場合は、認証に失敗した旨の結果をＩＤ管理装置１１０に送信し、後記Ｓ２４０８に遷移する。Ｓ２４０７でユーザの認証に成功した場合には、そのまま後記Ｓ２４０９に遷移する。
【０３１９】
Ｓ２４０７でユーザ認証に失敗した場合、ＩＤ管理装置１１０のメール送信プログラム３５０は、前記ステップＳ２４０７においてメールサーバ装置１２０が送信してきた結果を受信し（Ｓ２４０８）、認証に失敗した旨の判断を行い、処理を中断する。
Ｓ２４０７でユーザ認証に成功した場合、メールサーバ装置１２０のメール管理プログラム４４０は、メールサーバ装置１２０側で実行するためのコマンドを要求するために、ＩＤ管理装置１１０にコマンド要求を送信する（Ｓ２４０９）。
【０３２０】
ＩＤ管理装置１１０のメール送信プログラム３５０は、前記ステップＳ２４０９においてメールサーバ装置１２０が送信してきたコマンド要求を受信する（Ｓ２４１０）。
ＩＤ管理装置１１０のメール送信プログラム３５０は、上述したメニュー選択・ＩＤ指定ステップＳ２１００において選択されたメニュー及び本メール送信ステップＳ２４００を実施する以前のステップにおいて実施された処理内容に応じて適切な、メール送信用のコマンド群をメールサーバ装置１２０に送信する（Ｓ２４１１）。
【０３２１】
例えば、メニュー選択・ＩＤ指定ステップＳ２１００において管理者がＩＤの登録を選択し、利用者による鍵生成ステップＳ２７００が実施されていない場合には、利用者のメールアカウント宛にメールを送信する一連のコマンド群と、当該メールの本文に、公開鍵証明書の発行手続きを行うための手順及びＵＲＬ等を記載した内容を送信する。また、ＵＲＬの一部等に、ユーザを認証するための情報（例えば、ユーザのＩＤに結びつくように割りあてられた乱数）を付与し、ユーザのＩＤとユーザを認証するための情報は、ＩＤ管理装置１１０に保存しておく。
【０３２２】
メールサーバ装置１２０のメール管理プログラム４４０は、前記ステップＳ２４１１において送信されたコマンドを受信する（Ｓ２４１２）。
次に、メールサーバ装置１２０のメール管理プログラム４４０は、前記ステップ２４１２において受信したメール送信コマンド群に基づいて、指定されたメールアカウントにメールを送信する（Ｓ２４１３）。
【０３２３】
本実施の形態例では、簡単のため、当該メールサーバ装置１２０内に指定されたメールアカウントがあるものとした。例えば、前記ステップ２４１２において利用者のメールアカウント宛にメールを送信する一連のコマンド群と、当該メールの本文に、公開鍵証明書の発行手続きを行うための手順及びＵＲＬ等を記載した内容が送信されてきたとする。この場合、メールサーバ装置１２０内のアカウント別メールボックス４７０に、送信されてきたメールを保存する。
【０３２４】
続けて、メールサーバ装置１２０のメール管理プログラム４４０は、前記ステップＳ２４１３においてメール送信のコマンドを実行した結果を、ＩＤ管理装置１１０に対して返信する（Ｓ２４１４）。
ＩＤ管理装置１１０のメール送信プログラム３５０は、前記ステップＳ２４１４においてメールサーバ装置１２０が送信してきたコマンド実行結果を受信する（Ｓ２４１５）。
以上で、ＩＤ管理装置１１０とメールサーバ装置１２０との間で実施されるメール送信ステップＳ２４００もしくは承認者宛メール送信ステップＳ２４５０の処理が完了する。
【０３２５】
図２９は、メール受信ステップにおける処理フローの詳細を例示する図である。ここでは、メールの受信先である利用者装置１７０もしくは承認者装置１８０と、メールの管理先であるメールサーバ装置１２０との間の処理手順について示す。
【０３２６】
はじめに、利用者装置１７０のメーラープログラム９３０もしくは承認者装置１８０のメーラープログラム１０３０（以下、メール受信側のメーラープログラムと呼ぶ）は、メールサーバ装置１２０に対して、接続要求を送信する（Ｓ２６０１）。
メールサーバ装置１２０のメール管理プログラム４４０は、前記ステップＳ２６０１において送信された接続要求を受信する（Ｓ２６０２）。
【０３２７】
続けて、メールサーバ装置１２０のメール管理プログラム４４０は、接続要求を送信してきた利用者装置１７０もしくは承認者装置１８０（以下、メール受信側の装置と呼ぶ）に対して、認証情報を要求するメッセージを返信する（Ｓ２６０３）。本実施の形態例では、ＩＤ及びパスワードを用いた認証方法を採用するものとし、ここではＩＤ及びパスワードを要求するメッセージを返信する。但し、ここでの認証方法は既知の認証方法に置き換えてもよく、認証方法をＩＤ及びパスワードに限定するものではない。
【０３２８】
メール受信側のメーラープログラム１０３０は、前記ステップＳ２６０３においてメールサーバ装置１２０が送信してきた認証要求を受信する（Ｓ２６０４）。
続いて、メール受信側のメーラープログラム１０３０は、メールサーバ装置１２０にアクセスするための認証情報であるＩＤ及びパスワードを、メールサーバ装置１２０に送信する（Ｓ２６０５）。ここで、メールサーバ装置１２０にアクセスするための認証情報は、あらかじめメール受信側の装置内に設定されているものとする。
【０３２９】
メールサーバ装置１２０のメール管理プログラム４４０は、前記ステップＳ２６０５において送信された認証情報を受信する（Ｓ２６０６）。
メールサーバ装置１２０のユーザ認証プログラム４２０は、前記ステップＳ２６０６において受信した認証情報と、ユーザ情報データベース４６０内に保存されている認証情報とを用いて、ユーザの認証を行う（Ｓ２６０７）。Ｓ２６０７でユーザの認証に失敗した場合は、認証に失敗した旨の結果をメール受信側の装置に送信し、後記Ｓ２６０８に遷移する。Ｓ２６０７でユーザの認証に成功した場合には、そのまま後記Ｓ２６０９に遷移する。
【０３３０】
Ｓ２６０７でユーザ認証に失敗した場合、メール受信側のメーラープログラム１０３０は、前記ステップＳ２６０７においてメールサーバ装置１２０が送信してきた結果を受信し（Ｓ２６０８）、認証に失敗した旨の判断を行い、処理を中断する。
Ｓ２６０７でユーザ認証に成功した場合、メールサーバ装置１２０のメール管理プログラム４４０は、メールサーバ装置１２０側で実行するためのコマンドを要求するために、メール受信側の装置にコマンド要求を送信する（Ｓ２６０９）。
【０３３１】
メール受信側のメーラープログラム１０３０は、前記ステップＳ２６０９においてメールサーバ装置１２０が送信してきたコマンド要求を受信する（Ｓ２６１０）。
メール受信側のメーラープログラム１０３０は、メール受信用のコマンド群をメールサーバ装置１２０に送信する（Ｓ２６１１）。
メールサーバ装置１２０のメール管理プログラム４４０は、前記ステップＳ２６１１において送信されたコマンドを受信する（Ｓ２６１２）。
【０３３２】
次に、メールサーバ装置１２０のメール管理プログラム４４０は、メールをメール受信側の装置に対して返信する（Ｓ２６１３）。このメールは、前記ステップＳ２６１２において受信したメール受信コマンド群を受けて、アカウント別メールボックス４７０内で保存されている、前記ステップＳ２６０７において認証されたユーザのメールアカウント宛のメールである。
【０３３３】
メール受信側のメーラープログラム１０３０は、前記ステップＳ２６１３においてメールサーバ装置１２０が送信してきたコマンド実行結果を受信する（Ｓ２６１４）。
以上で、メール受信側の装置とメールサーバ装置１２０との間で実施されるメール受信ステップＳ２６００もしくは承認者宛メール受信ステップＳ２６５０の処理が完了する。
【０３３４】
図３０は、鍵生成ステップにおける処理フローの詳細を例示する図である。ここでは、鍵ペアの生成を行う側である利用者装置１７０と、利用者の公開鍵を受け付ける側のＩＤ管理装置１１０もしくは認証局装置１３０との間の処理手順について示す。
はじめに、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を起動する（Ｓ２７０１）。但し、本鍵生成ステップの直前に上述したメニュー選択・ＩＤ指定ステップＳ２１００を実施しており、既にＷｅｂブラウザプログラム９２０が起動している場合には、本ステップＳ２７０１は省略される。
【０３３５】
次に、利用者は、起動したＷｅｂブラウザプログラム９２０を用いて、ＩＤ管理装置１１０もしくは認証局装置１３０（以下、公開鍵を受け付ける装置）が提供する鍵生成用のＵＲＬにアクセスする。この、アクセス要求には、ユーザを認証するための情報（例えば、ユーザのＩＤに結びつくように割りあてられた乱数）も含まれているものとする（Ｓ２７０２）。
【０３３６】
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０もしくは認証局装置１３０の証明書管理プログラム５３０（以下、公開鍵を受け付ける装置側のプログラムと呼ぶ）は、前記ステップＳ２７０２において送信されたアクセス要求を受信する（Ｓ２７０３）。
【０３３７】
公開鍵を受け付ける装置側のユーザ認証プログラムは、前記ステップＳ２７０３において受信した要求内に含まれる認証情報と、図２８の説明におけるステップＳ２４１１において保存した認証情報とを用いて、ユーザの認証を行う（Ｓ２７０４）。Ｓ２７０４でユーザの認証に失敗した場合は、認証に失敗した旨の表示を行う画面データを利用者装置１７０に送信し、後記Ｓ２７０５に遷移する。Ｓ２７０４でユーザの認証に成功した場合には、そのまま後記Ｓ２７０６に遷移する。
【０３３８】
Ｓ２７０４でユーザ認証に失敗した場合、利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２７０４において公開鍵を受け付ける装置が送信してきた画面データを受信し（Ｓ２７０５）、利用者に対して認証に失敗した旨の表示を行い、処理を中断する。
【０３３９】
Ｓ２７０４でユーザ認証に成功した場合、当該ユーザに応じた鍵生成用画面データを利用者装置１７０に送信する（Ｓ２７０６）。鍵生成用画面データには、利用者装置１７０の鍵管理プログラム９４０を呼び出すためのスクリプトもしくはプログラムが含まれているものとする。
【０３４０】
利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２７０６において公開鍵を受け付ける装置が送信してきた鍵生成画面データを受信し、利用者に対して鍵生成画面を表示する（Ｓ２７０７）。
【０３４１】
次に、利用者は、利用者装置１７０のＷｅｂブラウザプログラム９２０に表示された鍵生成画面を操作することで、鍵管理プログラム９４０による利用者の鍵ペアの生成を行う（Ｓ２７０８）。本実施の形態例では、ここで生成された鍵ペアのうちの秘密鍵は、利用者の秘密鍵９５０として利用者装置１７０内に保存するものとする。但し、利用者の鍵ペアの生成場所や秘密鍵９５０の保存場所は、利用者装置１７０の代わりにＩＣカード等を用いてもよく、本実施の形態においては利用者の鍵の管理場所を制限するものではない。
【０３４２】
続いて、利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２７０８において生成した鍵ペアのうちの公開鍵とその暗号アルゴリズムの識別子等を含む公開鍵情報を、公開鍵を受け付ける装置に送信する（Ｓ２７０９）。
公開鍵を受け付ける装置側のプログラムは、前記ステップＳ２７０９において送信された公開鍵情報を受信する（Ｓ２７１０）。
【０３４３】
次に、公開鍵を受け付ける装置側のプログラムは、前記ステップＳ２７１０にて受信した公開鍵に応じた確認画面データを生成し、利用者装置１７０に対して、当該確認画面データを返信する（Ｓ２７１１）。確認画面データには、公開鍵を送信してきたユーザのＩＤや送信された公開鍵に関する情報が含まれているものとする。
【０３４４】
利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２７１１において公開鍵を受け付ける装置が送信してきた確認画面データを受信し、利用者に対して確認画面を表示する（Ｓ２７１２）。この後、管理者もしくは利用者が確認画面に対する内容の是非を判断した結果を入力することで、後記Ｓ２７１３に遷移する。
【０３４５】
利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２７１２において、利用者が入力した確認結果情報を、公開鍵を受け付ける装置に送信する（Ｓ２７１３）。
公開鍵を受け付ける装置側のプログラムは、前記ステップＳ２７１３において送信された確認結果情報を受信する（Ｓ２７１４）。
【０３４６】
続けて、公開鍵を受け付ける装置側のプログラムは、前記ステップＳ２７１４にて受信した確認結果情報を判定する（Ｓ２７１５）。Ｓ２７１５の判定結果が確認画面の内容を了承した旨のものであった場合には、後記ステップＳ２７１６に遷移する。Ｓ２７１５の判定結果が確認画面の内容を了承しない旨のものであった場合には、利用者装置１７０に対して、前記ステップＳ２７０６における鍵生成画面を返信する。
【０３４７】
Ｓ２７１５で確認画面の内容が了承されたと判断した場合、公開鍵を受け付ける装置側のプログラムは、前記ステップＳ２７１０にて受信した公開鍵情報の受付結果等の画面データを生成し、利用者装置１７０に対して、当該画面データを返信する（Ｓ２７１６）。
利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２７１６において公開鍵を受け付ける装置が送信してきた受付結果等が記載された画面データを受信し、利用者に対して当該画面を表示する（Ｓ２７１７）。
以上で、利用者装置１７０と、ＩＤ管理装置１１０もしくは認証局装置１３０との間で実施される鍵生成ステップＳ２７００の処理が完了する。
【０３４８】
図３１は、証明書取得ステップにおける処理フローの詳細を例示する図である。ここでは、利用者の証明書の取得を行う側である利用者装置１７０と、利用者の証明書を管理している側である認証局装置１３０との間の処理手順について示す。
はじめに、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を起動する（Ｓ２８０１）。但し、本証明書取得ステップの直前に上述した鍵生成ステップＳ２７００を実施しており、既にＷｅｂブラウザプログラム９２０が起動している場合には、本ステップＳ２８０１は省略される。
【０３４９】
次に、利用者は、起動したＷｅｂブラウザプログラム９２０を用いて、認証局装置１３０が提供する証明書取得用のＵＲＬにアクセスする（Ｓ２８０２）。この、アクセス要求には、ユーザを認証するための情報（例えば、ユーザのＩＤに結びつくように割りあてられた乱数）も含まれているものとする。
【０３５０】
認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ２８０２において送信されたアクセス要求を受信する（Ｓ２８０３）。
認証局装置１３０のユーザ認証プログラム５２０は、前記ステップＳ２８０３において受信した要求内に含まれる認証情報と、図２８の説明におけるステップＳ２４１１において保存した認証情報とを用いて、ユーザの認証を行う（Ｓ２８０４）。Ｓ２８０４でユーザの認証に失敗した場合は、認証に失敗した旨の表示を行う画面データを利用者装置１７０に送信し、後記Ｓ２８０５に遷移する。Ｓ２８０４でユーザの認証に成功した場合には、そのまま後記Ｓ２８０６に遷移する。
【０３５１】
Ｓ２８０４でユーザ認証に失敗した場合、利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２８０４において認証局装置１３０が送信してきた画面データを受信し、利用者に対して認証に失敗した旨の表示を行い、処理を中断する（Ｓ２８０５）。
【０３５２】
Ｓ２８０４でユーザ認証に成功した場合、当該ユーザに応じた証明書取得用画面データを利用者装置１７０に送信する（Ｓ２８０６）。
利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２８０６において認証局装置１３０が送信してきた証明書取得画面データを受信し、利用者に対して証明書取得画面を表示する（Ｓ２８０７）。
【０３５３】
次に、利用者は、利用者装置１７０のＷｅｂブラウザプログラム９２０に表示された証明書取得画面を操作することで、前記ステップＳ２８０４において認証されたユーザに関する証明書をダウンロードするための証明書取得要求を、認証局装置１３０に送信する（Ｓ２８０８）。
認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ２８０８において送信された公開鍵情報を受信する（Ｓ２８０９）。
【０３５４】
次に、認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ２８０９にて受信した証明書発行要求に応じて、利用者装置１７０に対して、利用者の証明書（公開鍵証明書もしくは属性証明書）を返信する（Ｓ２８１０）。
利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２８１０において認証局装置１３０が送信してきた証明書を受信する（Ｓ２８１１）。
【０３５５】
続いて、利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２８１１において受信した証明書を利用者装置１７０内に保存する（Ｓ２８１２）。これによって、証明書を使った業務サービスプログラムを利用することができるようになる。
以上で、利用者装置１７０と、認証局装置１３０との間で実施される証明書取得ステップＳ２８００の処理が完了する。
【０３５６】
図３２は、証明書登録ステップあるいは失効情報登録ステップにおける処理フローの詳細を例示する図である。ここでは、証明書の発行あるいは失効を実施する認証局装置１３０と、証明書や失効情報の公開を行うリポジトリ装置１４０との間の処理手順について示す。
はじめに、認証局装置１３０のリポジトリ登録プログラム５４０は、証明書や失効情報を公開するリポジトリ装置１４０に対して、接続要求を送信する（Ｓ２９０１）。
リポジトリ装置１４０のリポジトリプログラム６３０は、前記ステップＳ２９０１において送信された接続要求を受信する（Ｓ２９０２）。
【０３５７】
続けて、リポジトリ装置１４０のリポジトリプログラム６３０は、接続要求を送信してきた認証局装置１３０に対して、認証情報を要求するメッセージを返信する（Ｓ２９０３）。本実施の形態例では、ＩＤ及びパスワードを用いた認証方法を採用するものとし、ここではＩＤ及びパスワードを要求するメッセージを返信する。但し、ここでの認証方法は既知の認証方法に置き換えてもよく、認証方法をＩＤ及びパスワードに限定するものではない。
【０３５８】
認証局装置１３０のリポジトリ登録プログラム５４０は、前記ステップＳ２９０３においてリポジトリ装置１４０が送信してきた認証要求を受信する（Ｓ２９０４）。
続いて、認証局装置１３０のリポジトリ登録プログラム５４０は、リポジトリ装置１４０にアクセスするための認証情報であるＩＤ及びパスワードを、リポジトリ装置１４０に送信する（Ｓ２９０５）。ここで、リポジトリ装置１４０にアクセスするための認証情報は、あらかじめ認証局装置１３０内に設定されているものとする。
【０３５９】
リポジトリ装置１４０のリポジトリプログラム６３０は、前記ステップＳ２９０５において送信された認証情報を受信する（Ｓ２９０６）。
リポジトリ装置１４０のユーザ認証プログラム６２０は、前記ステップＳ２９０６において受信した認証情報と、アクセス制御データ６４０内に保存されている認証情報とを用いて、ユーザの認証を行う（Ｓ２９０７）。Ｓ２９０７でユーザの認証に失敗した場合は、認証に失敗した旨の結果を認証局装置１３０に送信し、後記Ｓ２９０８に遷移する。Ｓ２９０７でユーザの認証に成功した場合には、そのまま後記Ｓ２９０９に遷移する。
【０３６０】
Ｓ２９０７でユーザ認証に失敗した場合、認証局装置１３０のリポジトリ登録プログラム５４０は、前記ステップＳ２９０７においてリポジトリ装置１４０が送信してきた結果を受信し（Ｓ２９０８）、認証に失敗した旨の判断を行い、処理を中断する。
Ｓ２９０７でユーザ認証に成功した場合、リポジトリ装置１４０のリポジトリプログラム６３０は、リポジトリ装置１４０で実行するためのコマンドを要求するために、認証局装置１３０にコマンド要求を送信する（Ｓ２９０９）。
【０３６１】
認証局装置１３０のリポジトリ登録プログラム５４０は、前記ステップＳ２９０９においてリポジトリ装置１４０が送信してきたコマンド要求を受信する（Ｓ２９１０）。
認証局装置１３０のリポジトリ登録プログラム５４０は、図３２のステップを実施する直前のステップでの証明書や失効情報の生成状況に応じて適切なコマンドをリポジトリ装置１４０に送信する（Ｓ２９１１）。例えば、図３２のステップを実施する直前に、証明書の生成までを行う証明書発行要求ステップＳ２３００が実施されている場合には、前記証明書発行要求ステップＳ２３００において生成された証明書をリポジトリに登録する旨のコマンドと当該証明書のデータを送信する。
【０３６２】
リポジトリ装置１４０のリポジトリプログラム６３０は、前記ステップＳ２９１１において送信されたコマンドを受信する（Ｓ２９１２）。
次に、リポジトリ装置１４０のリポジトリプログラム６３０は、前記ステップＳ２９１２において受信したコマンドを実行する（Ｓ２９１３）。例えば、前記ステップＳ２９１２において証明書を登録する旨のコマンドと証明書が送信されてきた場合、当該証明書をリポジトリ装置１４０内に保存しておき、リポジトリを利用しようとする者から証明書の開示要求があった場合に、証明書を提供できるように準備する。
【０３６３】
続けて、リポジトリ装置１４０のリポジトリプログラム６３０は、前記ステップＳ２９１３においてコマンドを実行した結果を、認証局装置１３０に対して返信する（Ｓ２９１４）。
認証局装置１３０のリポジトリ登録プログラム５４０は、前記ステップＳ２９１４においてリポジトリ装置１４０が送信してきたコマンド実行結果を受信する（Ｓ２９１５）。
【０３６４】
以上で、認証局装置１３０とリポジトリ装置１４０との間で実施される証明書登録ステップＳ２９００もしくは失効情報登録ステップＳ３２００の処理が完了する。なお、証明書登録ステップＳ２９００と失効情報登録ステップＳ３２００が連続して実施される場合、後で実施されるステップは、先に実施されたステップに続けて、Ｓ２９１１に遷移するものとし、Ｓ２９０１からＳ２９１０までの認証を行う処理を省略してもよい。
【０３６５】
図３３は、完了通知ステップにおける処理フローの詳細を例示する図である。ここでは、証明書の発行あるいは失効を実施する認証局装置１３０と、証明書や失効情報の情報をユーザ情報に結びつけるためのＩＤ管理装置１１０との間の処理手順について示す。
はじめに、認証局装置１３０の証明書管理プログラム５３０は、ＩＤ管理装置１１０に対して、接続要求を送信する（Ｓ３００１）。
【０３６６】
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３００１において送信された接続要求を受信する（Ｓ３００２）。
続けて、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、接続要求を送信してきた認証局装置１３０に対して、認証情報を要求するメッセージを返信する（Ｓ３００３）。本実施の形態例では、ＩＤ及びパスワードを用いた認証方法を採用するものとし、ここではＩＤ及びパスワードを要求するメッセージを返信する。但し、ここでの認証方法は既知の認証方法に置き換えてもよく、認証方法をＩＤ及びパスワードに限定するものではない。
【０３６７】
認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ３００３においてＩＤ管理装置１１０が送信してきた認証要求を受信する（Ｓ３００４）。
続いて、認証局装置１３０の証明書管理プログラム５３０は、ＩＤ管理装置１１０にアクセスするための認証情報であるＩＤ及びパスワードを、ＩＤ管理装置１１０に送信する（Ｓ３００５）。ここで、ＩＤ管理装置１１０にアクセスするための認証情報は、あらかじめ認証局装置１３０内に設定されているものとする。
【０３６８】
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３００５において送信された認証情報を受信する（Ｓ３００６）。
ＩＤ管理装置１１０のユーザ認証プログラム３７０は、前記ステップＳ３００６において受信した認証情報と、アクセス制御データ３６０内に保存されている認証情報とを用いて、ユーザの認証を行う（Ｓ３００７）。Ｓ３００７でユーザの認証に失敗した場合は、認証に失敗した旨の結果を認証局装置１３０に送信し、後記Ｓ３００８に遷移する。Ｓ３００７でユーザの認証に成功した場合には、そのまま後記Ｓ３００９に遷移する。
【０３６９】
Ｓ３００７でユーザ認証に失敗した場合、認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ３００７においてＩＤ管理装置１１０が送信してきた結果を受信し（Ｓ３００８）、認証に失敗した旨の判断を行い、処理を中断する。
Ｓ３００７でユーザ認証に成功した場合、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、ＩＤ管理装置１１０で実行するためのコマンドを要求するために、認証局装置１３０にコマンド要求を送信する（Ｓ３００９）。
【０３７０】
認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ３００９においてＩＤ管理装置１１０が送信してきたコマンド要求を受信する（Ｓ３０１０）。
認証局装置１３０の証明書管理プログラム５３０は、図３３のステップを実施する前に生成した証明書や失効情報の内容に応じて適切なコマンドをＩＤ管理装置１１０に送信する（Ｓ３０１１）。例えば、図３３のステップを実施する前に証明書の生成を行っている場合には、ＩＤ管理装置１１０内のユーザ情報データベース３７０を更新する旨のコマンドと、更新内容である当該証明書に記載されたＩＤ、発行者名、シリアル番号、記載した属性の型等の値を送信する。
【０３７１】
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３０１１において送信されたコマンドを受信する（Ｓ３０１２）。
次に、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３０１２において受信したコマンドを実行する（Ｓ３０１３）。例えば、当該ＩＤ、当該発行者名、当該シリアル番号、当該記載属性型等の値をＩＤ管理装置１１０内のユーザ情報データベース３７０に反映する。この場合、前記ステップＳ３０１２においてＩＤ管理装置１１０内のユーザ情報データベース３７０を更新する旨のコマンドと、更新内容である当該証明書に記載されたＩＤ、発行者名、シリアル番号、記載した属性の型等の値が送信されてくる。
【０３７２】
続けて、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３０１３においてコマンドを実行した結果を、認証局装置１３０に対して返信する（Ｓ３０１４）。
認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ３０１４においてＩＤ管理装置１１０が送信してきたコマンド実行結果を受信する（Ｓ３０１５）。
以上で、認証局装置１３０とＩＤ管理装置１１０との間で実施される完了通知ステップＳ３０００の処理が完了する。
【０３７３】
図３４は、承認ステップにおける処理フローの詳細を例示する図である。ここでは、利用者からの申請内容を承認する側である承認者装置１８０と、利用者の申請情報を管理する側であるＩＤ管理装置１１０との間の処理手順について示す。
はじめに、承認者が承認者装置１８０のＷｅｂブラウザプログラム１０２０を起動する（Ｓ３３０１）。
【０３７４】
次に、承認者は、起動したＷｅｂブラウザプログラム１０２０を用いて、ＩＤ管理装置１１０が提供する承認用のＵＲＬにアクセスする（Ｓ３３０２）。この、アクセス要求には、ユーザを認証するための情報（例えば、ユーザのＩＤに結びつくように割り当てられた乱数）も含まれているものとする。
【０３７５】
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３３０２において送信されたアクセス要求を受信する（Ｓ３３０３）。
ＩＤ管理装置１１０のユーザ認証プログラム３２０は、前記ステップＳ３３０３において受信した要求内に含まれる認証情報と、図２８の説明におけるステップＳ２４１１において保存した認証情報とを用いて、ユーザの認証を行う（Ｓ３３０４）。Ｓ３３０４でユーザの認証に失敗した場合は、認証に失敗した旨の表示を行う画面データを承認者装置１８０に送信し、後記Ｓ３３０５に遷移する。Ｓ３３０４でユーザの認証に成功した場合には、そのまま後記Ｓ３３０６に遷移する。
【０３７６】
Ｓ３３０４でユーザ認証に失敗した場合、承認者装置１８０のＷｅｂブラウザプログラム１０２０は、前記ステップＳ３３０４においてＩＤ管理装置１１０が送信してきた画面データを受信し、利用者に対して認証に失敗した旨の表示を行い、処理を中断する（Ｓ３３０５）。
【０３７７】
Ｓ３３０４でユーザ認証に成功した場合、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、当該ユーザに応じた承認画面データを承認者装置１８０に送信する（Ｓ３３０６）。
承認者装置１８０のＷｅｂブラウザプログラム１０２０は、前記ステップＳ３３０６においてＩＤ管理装置１１０が送信してきた承認画面データを受信し、承認者に対して承認画面を表示する（Ｓ３３０７）。この後、承認者は、承認の可否を選択することで、後記ステップＳ３３０８に遷移する。
【０３７８】
続いて、承認者装置１８０のＷｅｂブラウザプログラム１０２０は、前記ステップＳ３３０７において選択した承認の可否に関する承認可否情報を、ＩＤ管理装置１１０に送信する（Ｓ３３０８）。
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３３０８において送信された承認可否情報を受信する（Ｓ３３０９）。
【０３７９】
次に、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３３０９にて受信した承認可否情報に応じた確認画面データを生成し、承認者装置１８０に対して、当該確認画面データを返信する（Ｓ３３１０）。
承認者装置１８０のＷｅｂブラウザプログラム１０２０は、前記ステップＳ３３１０においてＩＤ管理装置１１０が送信してきた確認画面データを受信し、承認者に対して確認画面を表示する（Ｓ３３１１）。この後、承認者が確認画面に対する内容の是非を判断した結果を入力することで、後記Ｓ３３１２に遷移する。
【０３８０】
承認者装置１８０のＷｅｂブラウザプログラム１０２０は、前記ステップＳ３３１１において、承認者が入力した確認結果情報を、ＩＤ管理装置１１０に送信する（Ｓ３３１２）。
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３３１２において送信された確認結果情報を受信する（Ｓ３３１３）。
【０３８１】
続けて、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３３１３にて受信した確認結果情報を判定する（Ｓ３３１４）。Ｓ３３１４の判定結果が確認画面の内容を了承した旨のものであった場合には、後記ステップＳ３３１５に遷移する。Ｓ３３１４の判定結果が確認画面の内容を了承しない旨のものであった場合には、承認者装置１８０に対して、前記ステップＳ３３０６における承認画面を返信する。
【０３８２】
Ｓ３３１４で確認画面の内容が了承されたと判断した場合、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、図１３から図２４における承認ステップＳ３３００の次のステップに処理を遷移させるとともに、前記ステップＳ３３０９にて受信した公開鍵情報の受付結果等の画面データを生成し、承認者装置１８０に対して、当該画面データを返信する（Ｓ３３１５）。
【０３８３】
承認者装置１８０のＷｅｂブラウザプログラム１０２０は、前記ステップＳ３３１５においてＩＤ管理装置１１０が送信してきた受付結果等が記載された画面データを受信し、承認者に対して当該画面を表示する（Ｓ３３１６）。
以上で、承認者装置１８０と、ＩＤ管理装置１１０との間で実施される承認ステップＳ３３００の処理が完了する。
【０３８４】
なお、上述した本実施の形態例に限らず、本発明の要旨を逸脱しない限り、適宜変更しうることは言うまでもない。
【図面の簡単な説明】
【０３８５】
【図１】本発明の一実施の形態によるシステム構成例を示す説明図である。
【図２】ＩＤ管理装置、メールサーバ装置、認証局装置、リポジトリ装置、サービス提供装置、管理者装置、利用者装置及び承認者装置のハードウェア構成を例示する図である。
【図３】ＩＤ管理装置のソフトウェア構成を例示する図である。
【図４】メールサーバ装置のソフトウェア構成を例示する図である。
【図５】認証局装置のソフトウェア構成を例示する図である。
【図６】リポジトリ装置のソフトウェア構成を例示する図である。
【図７】サービス提供装置のソフトウェア構成を例示する図である。
【図８】管理者装置のソフトウェア構成を例示する図である。
【図９】利用者装置のソフトウェア構成を例示する図である。
【図１０】承認者装置のソフトウェア構成を例示する図である。
【図１１】ＩＤもしくは属性の登録時におけるデータの管理形態を例示する図である。
【図１２】ＩＤもしくは属性の削除時等におけるデータの管理形態を例示する図である。
【図１３】管理者が利用者のＩＤを登録する場合の処理フローの概要を例示する図である。
【図１４】管理者が利用者のＩＤを削除、利用停止もしくは利用停止解除する場合の処理フローの概要を例示する図である。
【図１５】管理者が利用者のＩＤを変更する場合の処理フローの概要を例示する図である。
【図１６】管理者が利用者の属性情報を登録する場合の処理フローの概要を例示する図である。
【図１７】管理者が利用者の属性情報を変更もしくは削除する場合の処理フローの概要を例示する図である。
【図１８】利用者がＩＤを登録する場合の処理フローの概要を例示する図である。
【図１９】利用者がＩＤを登録する場合の別の処理フローの概要を例示する図である。
【図２０】利用者がＩＤを削除、利用停止もしくは利用停止解除する場合の処理フローの概要を例示する図である。
【図２１】利用者がＩＤを変更する場合の処理フローの概要を例示する図である。
【図２２】利用者がＩＤを変更する場合の別の処理フローの概要を例示する図である。
【図２３】利用者が属性情報を登録する場合の処理フローの概要を例示する図である。
【図２４】利用者が属性情報を変更もしくは削除する場合の処理フローの概要を例示する図である。
【図２５】メニュー選択・ＩＤ指定ステップにおける処理フローの詳細を例示する図である。
【図２６】プロビジョニングステップにおける処理フローの詳細を例示する図である。
【図２７】証明書発行要求ステップあるいは証明書失効要求ステップにおける処理フローの詳細を例示する図である。
【図２８】メール送信ステップにおける処理フローの詳細を例示する図である。
【図２９】メール受信ステップにおける処理フローの詳細を例示する図である。
【図３０】鍵生成ステップにおける処理フローの詳細を例示する図である。
【図３１】証明書取得ステップにおける処理フローの詳細を例示する図である。
【図３２】証明書登録ステップあるいは失効情報登録ステップにおける処理フローの詳細を例示する図である。
【図３３】完了通知ステップにおける処理フローの詳細を例示する図である。
【図３４】承認ステップにおける処理フローの詳細を例示する図である。
【符号の説明】
【０３８６】
１１０…ＩＤ管理装置、１２０…メールサーバ装置、１３０…認証局装置、１４０…リポジトリ装置、１５０…サービス提供装置、１６０…管理者装置、１７０…利用者装置、１８０…承認者装置、１９０…ネットワーク、２１０…入力装置、２２０…表示装置、２３０…ＣＰＵ、２４０…メモリ、２５０…記憶装置、２６０…通信装置、２７０…バス、３１０…オペレーティングシステム、３２０…ユーザ認証プログラム、３３０…ＩＤ管理サービスプログラム、３４０…プロビジョニングプログラム、３５０…メール送信プログラム、３６０…アクセス制御データ、３７０…ユーザ情報データベース、４１０…オペレーティングシステム、４２０…ユーザ認証プログラム、４３０…アカウント管理プログラム、４４０…メール管理プログラム、４５０…アクセス制御データ、４６０…ユーザ情報データベース、４７０…アカウント別メールボックス、５１０…オペレーティングシステム、５２０…ユーザ認証プログラム、５３０…証明書管理プログラム、５４０…リポジトリ登録プログラム、５４５…利用者鍵ペア生成プログラム、５５０…アクセス制御データ、５６０…証明書情報、５７０…失効情報、５８０…認証局の秘密鍵、５９０…認証局の公開鍵証明書、６１０…オペレーティングシステム、６２０…ユーザ認証プログラム、６３０…リポジトリプログラム、６４０…アクセス制御データ、６５０…証明書情報、６６０…失効情報、７１０…オペレーティングシステム、７２０…ユーザ認証プログラム、７３０…アカウント管理プログラム、７４０…業務サービスプログラム、７５０…アクセス制御データ、７６０…ユーザ情報データベース、８１０…オペレーティングシステム、８２０…Ｗｅｂブラウザプログラム、９１０…オペレーティングシステム、９２０…Ｗｅｂブラウザプログラム、９３０…メーラープログラム、９４０…鍵管理プログラム、９５０…利用者の秘密鍵、９６０…利用者の公開鍵証明書、９７０…利用者の属性証明書、１０１０…オペレーティングシステム、１０２０…Ｗｅｂブラウザプログラム、１０３０…メーラープログラム
【技術分野】
【０００１】
本発明は、ＩＴ（Information Technology）システムにおけるＩＤ（identifier）管理技術を用いたユーザ情報管理システムに関するものである。例えば、ユーザアカウントの登録、変更、削除等を行う際に、ユーザが入力する情報を活用して、プロビジョニングの一環として証明書の発行や失効を行い、利用者やシステム管理者の利便性を向上させる場合に好適である。
【背景技術】
【０００２】
近年のＩＴの普及により、様々なサービスがネットワーク上で提供されている。これらのサービスでは、システム個別にユーザのアカウントを管理している場合がある。ユーザのアカウントとは、例えば、ＩＤ及びパスワードなどである。ある１人のユーザが、このようなサービスを複数利用するには、複数のＩＤやパスワードを覚えていなければならない。
【０００３】
また、システム毎に別々のＩＤ及びパスワードを使用するようなシステムが存在している。このようなシステムを複数管理している企業内のシステム管理者などは、新入社員が入ってくる度に、複数のシステムに対してアカウント登録作業を行わなければならない。複数のシステムが乱立することで、利用者や管理者は不便を強いられるという状況が発生している。
【０００４】
このような問題を解決するために、シングルサインオン技術というものが用いられてきている。シングルサインオン技術とは、複数のアカウントを効率的に管理するＩＤ管理技術や、複数のシステムを利用する際にもユーザの認証操作を１回で済ませられるような技術である。特に、ＩＤ管理技術では、あるサーバのユーザ情報が更新等された場合に、他のサーバについても自動的に更新等するというプロビジョニング技術が提案されている（例えば、特許文献１参照）。
【０００５】
また、ＩＤ管理の一環で、一定のワークフローシステムも提案されている。このワークフローシステムは、例えば、ユーザＩＤの登録申請があった際に、企業のビジネスプロセスやセキュリティを考慮して、承認者による審査をパスしないとＩＤの登録が行われないようにする（例えば、特許文献２参照）。
一方、システムによっては、ＩＤ及びパスワードによってユーザを認証する代わりに、公開鍵証明書によってユーザを認証する方法も提案されている（例えば、非特許文献１参照）。
【特許文献１】特開2003-162509号公報
【特許文献２】特開2002-245010号公報
【非特許文献１】International Telecommunication Union著「Information technology - Open systems interconnection - The Directory: Public-key and attribute certificate frameworks (ITU-T Recommendation X.509)」、（スイス）、International Telecommunication Union、２０００年３月３１日、ｐ．１−１２９
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上述した特許文献１、２に記載の技術のように、ＩＤ及びパスワードによってユーザを識別及び認証するシステムと、公開鍵証明書を用いてユーザを識別及び認証するシステムとが共存しているような環境においては、以下のような不都合が生ずる。
【０００７】
例えば、ユーザの登録を行うためのＩＤ及びパスワードの登録と公開鍵証明書の発行を連続して又は関連つけて行おうとした場合、特許文献１に記載の方法や特許文献２に記載の方法だけでは、公開鍵証明書の発行までは実現することができないという不都合があった。これは、特許文献１に記載の方法や特許文献２に記載の方法に、ＩＤ及びパスワードの登録から公開鍵証明書の発行に至る技術が開示されていないためである。
【０００８】
また、これらの特許文献１に記載の方法や特許文献２に記載の方法と非特許文献１とを組み合わせた場合には、以下のような不都合が生ずる。例えば、ＩＤ及びパスワードの登録と公開鍵証明書の発行をそれぞれ単独で行うことは可能である。しかし、両者の処理を単純に組み合わせただけでは、それぞれのシステムに対して個別にアカウント登録を行うことになる。このため、ＩＤ管理において本来解決すべきユーザやシステム管理者の作業の効率化を図ることができないという不都合があった。
【０００９】
そこで、本発明は、ＩＤ及びパスワードによってユーザを識別及び認証するシステムと、公開鍵証明書を用いてユーザを識別及び認証するシステムとが共存しているような環境において、ユーザの登録を行うためのＩＤ及びパスワードの登録を公開鍵証明書の発行にも用いることができるユーザ情報管理システムの提供を目的とするものである。
【課題を解決するための手段】
【００１０】
本発明は、上記目的を達成するために、本発明は、利用者のＩＤに基づいてサービスを提供するシステムと、利用者の電子的な証明書に基づいてサービスを提供するシステムとが共存する環境において、利用者のＩＤ管理と証明書管理を一括して行うユーザ情報管理システムである。
【００１１】
このユーザ情報管理システムは、ＩＤ管理を一元的に行うＩＤ管理部と、ＩＤ管理部に対してＩＤ管理の操作を行う管理者操作部と、利用者のＩＤに基づいてＩＤを利用したサービスの提供を行う１つ以上のサービス提供部と、利用者の証明書及び失効情報の生成を行う認証局部と、サービス提供部を利用するユーザが操作する利用者操作部とを備えている。
【００１２】
ここで、管理者操作部は、管理者によって指定された、利用者のＩＤを管理するために必要なユーザ情報を含むＩＤ管理要求を、ＩＤ管理部に送信する。
ＩＤ管理部は、受信したＩＤ管理要求に基づいて、要求されたＩＤ管理の実施のためにサービス提供部毎に必要とするユーザ情報を含むプロビジョニング要求を、全てのサービス提供部に送信するとともに、要求されたＩＤ管理の実施のために認証局部が必要とするユーザ情報を含む証明書管理要求を、認証局部に送信する。
【００１３】
そこで、サービス提供部は、受信したプロビジョニング要求に応じて、サービス提供部が管理しているユーザ情報データベースを更新する。
一方、認証局部は、受信した証明書管理要求に応じて、証明書関連情報を生成し、証明書関連情報内に存在する各種構成情報を含む生成結果情報を、ＩＤ管理部に送信する。
また、ＩＤ管理部は、受信した生成結果情報に基づいて、ＩＤ管理部が管理しているユーザ情報データベースを更新する。
【００１４】
このようにして、本発明により、ＩＤ及びパスワードによってユーザを識別及び認証するシステムと、公開鍵証明書を用いてユーザを識別及び認証するシステムとが共存しているような環境において、ユーザの登録を行うためのＩＤ及びパスワードの登録を公開鍵証明書の発行にも用いることができる。
【００１５】
すなわち、ユーザのアカウントや属性情報を登録・変更・削除等する際にユーザから入力された情報を、各システムへのプロビジョニングのためのアカウント管理（アカウントプロビジョニング）と証明書(属性証明書含む)管理の両方に使用する。これにより、利用者やシステム管理者が必要な情報入力や操作の量を減らし、効率化をはかることができる。
【発明の効果】
【００１６】
本発明によれば、アカウント管理の際にユーザが入力する情報を活用し、プロビジョニングのためのアカウント管理（アカウントプロビジョニング）の一環で証明書(属性証明書含む)の管理も行うことができるという効果を奏する。これにより、利用者の入力作業や操作回数を減らすことができ、また、システム管理者の操作回数も減らすことができる。結果として、利用者やシステム管理者の利便性を向上させる効果をもたらすことができる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明による好適な一実施の形態を、図１〜３４の図面を用いて説明する。なお、以下で説明する図面において、同一の番号は同様の部品・要素を表すものとする。また、これにより本発明が限定されるものではない。
【００１８】
図１は、本実施の形態例を適用するためのシステム構成を示す図である。
図１において、このシステムはＩＤ管理装置１１０と、メールサーバ装置１２０と、認証局装置１３０と、リポジトリ装置１４０と、サービス提供装置１５０と、管理者装置１６０と、利用者装置１７０と、承認者装置１８０とを備えている。
【００１９】
ＩＤ管理装置１１０は、システム全体のユーザ情報を一元的に管理する装置である。メールサーバ装置１２０は、各人員に対して通知等を行うための装置である。認証局装置１３０は、証明書を発行あるいは失効する装置である。リポジトリ装置１４０は、証明書やその失効情報を保管及び公開するための装置である。
【００２０】
サービス提供装置１５０は、勤務関係や経理関係等の様々な業務サービスを提供するための装置である。管理者装置１６０は、システムを管理する人（以下、管理者）が操作するコンピュータである。利用者装置１７０は、様々な業務を行うために一般の人（以下、利用者）が操作するコンピュータである。承認者装置１８０は、業務権限の付与やアカウントの変更等を承認する人（以下、承認者）が操作するコンピュータである。
【００２１】
これら各装置１１０〜１８０がネットワーク１９０を介して接続されているものとする。本実施例においては、簡単のため、サービス提供装置１５０を１台として説明を行うが、サービス提供装置１５０は、複数台設置され、業務毎にユーザのアカウントを保有しているような場合も想定している。
【００２２】
図２は、各装置のハードウェア構成を示す図である。
図1に示したＩＤ管理装置１１０、メールサーバ装置１２０、認証局装置１３０、リポジトリ装置１４０、サービス提供装置１５０、管理者装置１６０、利用者装置１７０及び承認者装置１８０は、共通のハードウェアで構成されている。
【００２３】
これら各装置１１０〜１８０は、入力装置２１０と、表示装置２２０と、ＣＰＵ（Central Processing Unit）２３０と、メモリ２４０と、記憶装置２５０と、通信装置２６０と、これらを接続するバス２７０とから構成されている。本実施の形態例では、利用者や承認者への通知手段として電子メールを使用する例を示しているため、メールサーバ装置１２０が構成要素として存在している例を示している。しかし、電子メールは通知手段の１つの実施形態であって、本実施の形態としては通知手段を電子メールに限定するものではない。
【００２４】
入力装置２１０は、装置を利用する人が、データや命令等を入力するために操作されるものであり、キーボード、マウス、生体情報の入力装置、その他認証に必要な装置等で構成される。
表示装置２２０は、装置を利用する人に対してメッセージ等を表示するために用いられるものであり、ＣＲＴ（Cathode Ray Tube）や液晶ディスプレイ等で構成される。
【００２５】
ＣＰＵ２３０は、メモリ２４０や記憶装置２５０に格納されたプログラムを実行することで、装置の各構成要素を制御したり、様々な演算処理を行ったりして、以下に説明する様々な処理を実現する。
メモリ２４０は、図３から図７に示すようなプログラムや、処理に必要なデータが一時的に格納されるものであり、ＲＡＭ（Random Access Memory）等の揮発性記憶媒体で構成することが多い。
【００２６】
記憶装置２５０は、装置内で使用されるプログラムやデータを永続的に記憶するために用いられるものであり、ハードディスク等の不揮発性記憶媒体で構成される。
通信装置２６０は、ネットワーク１９０を介して他の装置とデータの送受信を行うために必要な物理的インタフェースであり、ＬＡＮ（Local Area Network）ボードや無線ＬＡＮカード等で構成される。
【００２７】
図３は、ＩＤ管理装置１１０のソフトウェア構成を示す図である。
ＩＤ管理装置１１０のメモリ２４０には、オペレーティングシステム３１０と、ユーザ認証プログラム３２０と、ＩＤ管理プログラム３３０と、プロビジョニングプログラム３４０と、メール送信プログラム３５０がロードされている領域がある。これらのプログラムは、必要に応じて、ＣＰＵ２３０により実行され、後に説明する機能を実現する。
また、記憶装置２５０には、アクセス制御データ３６０と、ユーザ情報データベース３７０とが格納されている。
【００２８】
次に、各プログラムの機能を説明する。各プログラムは、それぞれが格納されている装置内で読み出されＣＰＵ２３０によって実行されることにより、その機能が実現されるものであるが、説明の便宜上、各プログラムを実行主体として説明する。
図３において、オペレーティングシステム３１０は、装置全体の制御を行うために、ファイル管理、プロセス管理、デバイス管理といった機能を実現するためのプログラムである。
【００２９】
ユーザ認証プログラム３２０は、他の装置からネットワークを介してアクセス要求があった場合などに、アクセス要求してきたユーザが誰であるかを認証する機能を実現する。さらに、要求されたリソースへのアクセスや操作に対して、アクセス権限のあるユーザだけがアクセスもしくは操作を可能とするための機能を実現する制御プログラムである。
すなわち、当該プログラムでは、ユーザ側が入力してきた情報と、アクセス制御データ３６０に記録されている情報とを用いて認証を行う。ここでの例は、認証はＩＤとパスワードの組み合わせによって認証を実現するものとするが、認証方法についてはこの限りではない。
【００３０】
ＩＤ管理サービスプログラム３３０は、管理者、利用者もしくは承認者が、サービス提供装置１５０やメールサーバ装置１２０等を使うために必要なＩＤの管理をする機能を実現する。すなわち、ＩＤの管理として、登録、変更、削除、利用停止、利用停止解除の他、当該ＩＤに付随する属性情報の追加、変更、削除等の申請や承認等を行うために提供されるサービスプログラムである。例えば、Ｗｅｂベースの画面によってＩＤ管理に関する各種手続きをインタラクティブに処理していき、申請や承認を受け付けるプログラムに相当する。
【００３１】
プロビジョニングプログラム３４０は、いわばアカウントプロビジョニングを行うためのプログラムである。すなわち、ＩＤ管理サービスプログラム３３０にて受け付けたＩＤ管理業務の内容に応じて、サービス提供装置１５０、認証局装置１３０及びメール送信プログラム３５０との連携を行う機能を実現する。
【００３２】
そして、様々なシステムで使用されるＩＤやその付随情報を登録、変更、削除、同期等を行ったりする機能を実現する。さらに、予め設定されたビジネスプロセスに基づいて、申請された内容をワークフローで承認者に流す等の制御を行ったりする機能を実現する。
【００３３】
具体的には、ＩＤの登録、変更、削除、当該ＩＤに付随する属性情報の追加、変更あるいは削除等を要求する。これらＩＤ管理のための要求は、ＩＤ管理サービスプログラム３３０にて受け付けたＩＤ管理業務に応じて、サービス提供装置１５０のＩＤ管理形態に適した形で実現される。サービス提供装置１５０が複数存在する場合は、それらの装置に対して同様の処理を繰り返す。また、利用者や承認者に通知が必要な場合は、メール送信プログラム３５０に対して、ユーザへの通知を要求する。さらには、申請や承認の内容に応じて、証明書の発行や失効を要求する。
【００３４】
メール送信プログラム３５０は、プロビジョニングプログラム３４０からの要求に応じて、メールサーバ装置１２０に、電子メールを送信するプログラムである。
アクセス制御データ３６０は、ユーザ認証プログラム３２０にて、ユーザの認証を行う際の正当性を確認するために用いるデータである。すなわち、ユーザの認証を行う際の正当性を確認するために必要な情報及び認証されたユーザがどのようなアクセス権限を有しているかを示す情報を記録したデータである。例えば、アクセス制御データ３６０には、ＩＤ、パスワード、管理者、利用者、あるいは承認者などの役割等が、ユーザ毎に記録されているものとする。
【００３５】
ユーザ情報データベース３７０は、ＩＤ管理サービスプログラム３３０によって受け付けた情報を管理するデータベースである。すなわち、サービス提供装置１５０や認証局装置１３０に対してプロビジョニングする際のマスタとなるデータ群である。例えば、ユーザ情報データベース３７０は、ＩＤ、パスワード、所属部署名、役職、メールアドレス等の属性情報のデータを管理している。
【００３６】
図４は、メールサーバ装置１２０のソフトウェア構成を示す図である。
メールサーバ装置１２０のメモリ２４０には、オペレーティングシステム４１０と、ユーザ認証プログラム４２０と、アカウント管理プログラム４３０と、メール管理プログラム４４０がロードされている領域がある。これらのプログラムは、必要に応じて、ＣＰＵ２３０により実行され、後に説明する機能を実現する。
また、記憶装置２５０には、アクセス制御データ４５０と、ユーザ情報データベース４６０と、アカウント別メールボックス４７０とが格納されている。
【００３７】
次に、各プログラムの機能を説明する。各プログラムは、それぞれが格納されている装置内で読み出されＣＰＵ２３０によって実行されることにより、その機能が実現されるものであるが、説明の便宜上、各プログラムを実行主体として説明する。
図４において、オペレーティングシステム４１０は、装置全体の制御を行うために、ファイル管理、プロセス管理、デバイス管理といった機能を実現するためのプログラムである。
【００３８】
ユーザ認証プログラム４２０は、アクセス権限のあるユーザだけがアクセスもしくは操作を可能とするための制御プログラムである。すなわち、他の装置からネットワークを介してアクセス要求があった場合などに、アクセス要求してきたユーザが誰であるかを認証する機能を実現する。そして、要求されたリソースへのアクセスや操作に対して、アクセス権限のあるユーザだけがアクセスもしくは操作を可能とする機能を実現する。
【００３９】
当該プログラムでは、ユーザ側が入力してきた情報と、アクセス制御データ４５０あるいはユーザ情報データベース４６０に記録されている情報とを用いて認証を行う。ここでの例は、認証はＩＤとパスワードの組み合わせによって認証を実現するものとするが、認証方法についてはこの限りではない。
【００４０】
アカウント管理プログラム４３０は、電子メールを利用するユーザのメールアカウントやそれに付随する情報（例えばパスワード等）を登録、変更、削除等するプログラムである。登録された情報は、ユーザ情報データベース４６０として管理される。ここでの例では、利用者及び承認者のメールアカウントとパスワードが登録されているものとする。
【００４１】
メール管理プログラム４４０は、メールサーバ装置１２０に送信されてきたメールを、アカウント別メールボックス４７０に振り分けて保存しておく機能を有するプログラムである。また、メールの取得要求があった場合に、ユーザ認証プログラム４２０を通じて要求元のユーザの認証を行なった上で、認証されたユーザのメールアカウントに対応したメールボックスに保存されているメールを、要求元のユーザに送信する機能等を有する。
【００４２】
アクセス制御データ４５０は、ユーザがどのようなアクセス権限を有しているかを示す情報（例えば、メールアカウントを登録する権限があること等を示す情報）を記録したデータである。すなわち、ユーザ認証プログラム４２０にて、ユーザの認証を行う際の正当性を確認するために必要な情報及び認証された例えば、ＩＤ、パスワード、権限などが、ユーザ毎に記録されているものとする。
【００４３】
ユーザ情報データベース４６０は、アカウント管理プログラム４３０によって登録・管理されているメールアカウントやそれに付随する情報を管理するデータベースであり、例えば、メールアカウント及びパスワード等のデータを管理している。
アカウント別メールボックス４７０は、メール管理プログラム４４０によって受け付けたメールのデータを、メールアカウント別に保存したものである。保存されたメールは、そのメールを保管しているメールアカウントの正当なユーザしか取得できないようにアクセス制御設定が行われているものとする。
【００４４】
図５は、認証局装置１３０のソフトウェア構成を示す図である。
認証局装置１３０のメモリ２４０には、オペレーティングシステム５１０と、ユーザ認証プログラム５２０と、証明書管理プログラム５３０と、リポジトリ登録プログラム５４０がロードされている領域がある。また、認証局装置１３０側で利用者の鍵ペアを生成するモデルである場合、認証局装置１３０のメモリ２４０には、さらに利用者鍵ペア生成プログラム５４５がロードされる。これらのプログラムは、必要に応じて、ＣＰＵ２３０により実行され、後に説明する機能を実現する。
また、記憶装置２５０には、アクセス制御データ５５０と、証明書情報５６０と、失効情報５７０と、認証局の秘密鍵５８０と、認証局の公開鍵証明書５９０とが格納されている。
【００４５】
次に、各プログラムの機能を説明する。各プログラムは、それぞれが格納されている装置内で読み出されＣＰＵ２３０によって実行されることにより、その機能が実現されるものであるが、説明の便宜上、各プログラムを実行主体として説明する。
図５において、オペレーティングシステム５１０は、装置全体の制御を行うために、ファイル管理、プロセス管理、デバイス管理といった機能を実現するためのプログラムである。
【００４６】
ユーザ認証プログラム５２０は、アクセス権限のあるユーザだけがアクセスもしくは操作を可能とするための制御プログラムである。すなわち、他の装置からネットワークを介してアクセス要求があった場合などに、アクセス要求してきたユーザが誰であるかを認証し、要求されたリソースへのアクセスや操作に対して、 アクセス権限のあるユーザだけがアクセスもしくは操作を可能とする。
【００４７】
当該プログラムでは、ユーザ側が入力してきた情報と、アクセス制御データ５５０に記録されている情報をと用いて認証を行う。ここでの例は、認証はＩＤとパスワードの組み合わせによって認証を実現するものとするが、認証方法についてはこの限りではない。
証明書管理プログラム５３０は、主に、公開鍵証明書の発行要求や失効要求を受け付ける機能と、公開鍵証明書や失効情報を生成する機能と、発行した公開鍵証明書のステータスを管理する機能等を有するプログラムである。
【００４８】
利用者側で鍵を生成させる場合には、利用者からのアクセスを受け付けて、利用者用鍵生成プログラムを送付し、利用者側で生成された公開鍵を受信するサービス機能も有する。
また、属性証明書の使用を想定している場合には、属性証明書の発行要求や失効要求を受け付ける機能と、属性証明書や属性証明書失効情報を生成する機能と、発行した属性証明書のステータスを管理する機能等も有する。
リポジトリ登録プログラム５４０は、証明書管理プログラム５２０で生成された公開鍵証明書、失効情報、属性証明書、属性証明書失効情報等を、リポジトリ装置１４０に登録するためのプログラムである。
【００４９】
利用者鍵ペア生成プログラム５４５は、利用者の公開鍵及び秘密鍵のペアを生成するプログラムである。
アクセス制御データ５５０は、ユーザがどのようなアクセス権限を有しているかを示す情報（例えば、証明書を発行する権限があること等を示す情報）を記録したデータである。すなわち、ユーザ認証プログラム５２０にて、ユーザの認証を行う際の正当性を確認するために必要な情報及び認証された例えば、ＩＤ、パスワード、権限などが、ユーザ毎に記録されているものとする。
【００５０】
証明書情報５６０は、証明書管理プログラム５３０によって生成された公開鍵証明書群である。証明書管理プログラム５３０にて属性証明書の発行も行う場合には、属性証明書群も証明書情報５６０に含まれる。
失効情報５７０は、証明書情報５６０が失効されているか否かを確認するためのデータであり、証明書管理プログラム５３０によって生成された失効情報群である。証明書管理プログラム５３０にて属性証明書の発行も行う場合には、属性証明書失効情報群も失効情報５７０に含まれる。
【００５１】
認証局の秘密鍵５８０は、証明書管理プログラム５３０によって生成される各種証明書や各種失効情報に対し、認証局としての電子署名を付与するために用いるデータである。
認証局の公開鍵証明書５９０は、認証局の秘密鍵５８０に対応した公開鍵証明書である。
【００５２】
図６は、リポジトリ装置１４０のソフトウェア構成を示す図である。
リポジトリ装置１４０のメモリ２４０には、オペレーティングシステム６１０と、ユーザ認証プログラム６２０と、リポジトリプログラム６３０とがロードされている領域がある。これらのプログラムは、必要に応じて、ＣＰＵ２３０により実行され、後に説明する機能を実現する。
また、記憶装置２５０には、アクセス制御データ６４０と、証明書情報６５０と、失効情報６６０とが格納されている。
【００５３】
次に、各プログラムの機能を説明する。各プログラムは、それぞれが格納されている装置内で読み出されＣＰＵ２３０によって実行されることにより、その機能が実現されるものであるが、説明の便宜上、各プログラムを実行主体として説明する。
図６において、オペレーティングシステム６１０は、装置全体の制御を行うために、ファイル管理、プロセス管理、デバイス管理といった機能を実現するためのプログラムである。
【００５４】
ユーザ認証プログラム６２０は、アクセス権限のあるユーザだけがアクセスもしくは操作を可能とするための制御プログラムである。すなわち、他の装置からネットワークを介してアクセス要求があった場合などに、アクセス要求してきたユーザが誰であるかを認証し、要求されたリソースへのアクセスや操作に対して、アクセス権限のあるユーザだけがアクセスもしくは操作を可能とする。
【００５５】
当該プログラムでは、ユーザ側が入力してきた情報と、アクセス制御データ６４０に記録されている情報をと用いて認証を行う。ここでの例は、認証はＩＤとパスワードの組み合わせによって認証を実現するものとするが、認証方法についてはこの限りではない。
リポジトリプログラム６３０は、認証局装置１３０のリポジトリ登録プログラム５４０からの要求に応じて各種証明書や失効情報を保存する機能と、保存している各種証明書や失効情報を、要求に応じて公開する機能等を有するプログラムである。
【００５６】
アクセス制御データ６４０は、ユーザがどのようなアクセス権限を有しているかを示す情報（例えば、証明書を登録する権限があること等を示す情報）を記録したデータである。すなわち、ユーザ認証プログラム６２０にて、ユーザの認証を行う際の正当性を確認するために必要な情報及び認証された例えば、ＩＤ、パスワード、権限などが、ユーザ毎に記録されているものとする。
【００５７】
証明書情報６５０は、リポジトリプログラム６３０によって保存された公開鍵証明書群である。認証局装置１３０の証明書管理プログラム５３０にて属性証明書の発行も行う場合には、属性証明書群も証明書情報６５０に含まれる。
失効情報６６０は、リポジトリプログラム６３０によって保存された失効情報群である。認証局装置１３０の証明書管理プログラム５３０にて属性証明書の発行も行う場合には、属性証明書失効情報群も失効情報６６０に含まれる。
【００５８】
図７は、サービス提供装置１５０のソフトウェア構成を示す図である。
サービス提供装置１５０のメモリ２４０には、オペレーティングシステム７１０と、ユーザ認証プログラム７２０と、アカウント管理プログラム７３０と、業務サービス管理プログラム７４０とがロードされている領域がある。これらのプログラムは、必要に応じて、ＣＰＵ２３０により実行され、後に説明する機能を実現する。
また、記憶装置２５０には、アクセス制御データ７５０と、ユーザ情報データベース７６０とが格納されている。
【００５９】
次に、各プログラムの機能を説明する。各プログラムは、それぞれが格納されている装置内で読み出されＣＰＵ２３０によって実行されることにより、その機能が実現されるものであるが、説明の便宜上、各プログラムを実行主体として説明する。
図７において、オペレーティングシステム７１０は、装置全体の制御を行うために、ファイル管理、プロセス管理、デバイス管理といった機能を実現するためのプログラムである。
【００６０】
ユーザ認証プログラム７２０は、アクセス権限のあるユーザだけがアクセスもしくは操作を可能とするための制御プログラムである。すなわち、他の装置からネットワークを介してアクセス要求があった場合などに、アクセス要求してきたユーザが誰であるかを認証し、要求されたリソースへのアクセスや操作に対して、アクセス権限のあるユーザだけがアクセスもしくは操作を可能とする。
【００６１】
当該プログラムでは、ユーザ側が入力してきた情報と、アクセス制御データ７５０あるいはユーザ情報データベース７６０に記録されている情報とを用いて認証を行う。ここでの例は、認証はＩＤとパスワードの組み合わせによって認証を実現するものとするが、認証方法についてはこの限りではない。
【００６２】
アカウント管理プログラム７３０は、サービス提供装置１５０の業務サービスプログラム７４０を利用するユーザのＩＤやそれに付随する情報（例えば、パスワードのような認証情報や、役職・部門名などの属性情報）を登録、変更、削除等するプログラムである。登録された情報は、ユーザ情報データベース７６０として管理される。ここでの例では、利用者のＩＤとパスワードが登録されているものとする。
【００６３】
業務サービスプログラム７４０は、ある業務を行うためのサービスを提供するプログラムである。例えば、勤務状況を管理する業務サービスや、経理情報を管理する業務サービス、資材調達を行うための業務サービスなどである。本実施の形態例では、利用者装置１７０のＷｅｂブラウザプログラム９２０とインタラクティブに業務処理を進めていくようなＷｅｂベースのシステムであり、このサービスを利用するためには、ユーザの認証に成功していること、かつ、アクセス権があることが必要である。
【００６４】
アクセス制御データ７５０は、ユーザがどのようなアクセス権限を有しているかを示す情報（例えば、ＩＤを登録する権限があること等を示す情報）を記録したデータである。すなわち、ユーザ認証プログラム７２０にて、ユーザの認証を行う際の正当性を確認するために必要な情報及び認証された例えば、ＩＤ、パスワード、権限などが、ユーザ毎に記録されているものとする。
【００６５】
ユーザ情報データベース７６０は、アカウント管理プログラム７３０によって登録・管理されているＩＤやそれに付随する情報を管理するデータベースであり、例えば、ＩＤ、パスワード等のデータを管理している。
【００６６】
図８は、管理者装置１６０のソフトウェア構成を示す図である。
管理者装置１６０のメモリ２４０には、オペレーティングシステム８１０と、Ｗｅｂブラウザプログラム８２０とがロードされている領域がある。これらのプログラムは、必要に応じて、ＣＰＵ２３０により実行され、後に説明する機能を実現する。
【００６７】
次に、各プログラムの機能を説明する。各プログラムは、それぞれが格納されている装置内で読み出されＣＰＵ２３０によって実行されることにより、その機能が実現されるものであるが、説明の便宜上、各プログラムを実行主体として説明する。
図８において、オペレーティングシステム８１０は、装置全体の制御を行うために、ファイル管理、プロセス管理、デバイス管理といった機能を実現するためのプログラムである。
【００６８】
Ｗｅｂブラウザプログラム８２０は、ネットワーク上のＷｅｂサーバに公開されたＨＴＭＬ（HyperText Markup Language）ファイル、画像ファイル、音楽ファイル等をダウンロードし、レイアウトを解析して表示あるいは再生するプログラムである。すなわち、フォームを使用してユーザがデータをＷｅｂサーバに送信することや、Ｊａｖａ（登録商標）等で記述されたプログラムを動作することも可能なプログラムである。
【００６９】
図９は、利用者装置１７０のソフトウェア構成を示す図である。
利用者装置１７０のメモリ２４０には、オペレーティングシステム９１０と、Ｗｅｂブラウザプログラム９２０と、メーラープログラム９３０と、鍵管理プログラム９４０とがロードされている領域がある。これらのプログラムは、必要に応じて、ＣＰＵ２３０により実行され、後に説明する機能を実現する。
また、記憶装置２５０には、利用者の秘密鍵９５０と、利用者の公開鍵証明書９６０と、利用者の属性証明書９７０とが格納される場合がある。
【００７０】
次に、各プログラムの機能を説明する。各プログラムは、それぞれが格納されている装置内で読み出されＣＰＵ２３０によって実行されることにより、その機能が実現されるものであるが、説明の便宜上、各プログラムを実行主体として説明する。
図９において、オペレーティングシステム９１０は、装置全体の制御を行うために、ファイル管理、プロセス管理、デバイス管理といった機能を実現するためのプログラムである。
【００７１】
Ｗｅｂブラウザプログラム９２０は、ネットワーク上のＷｅｂサーバに公開されたＨＴＭＬファイル、画像ファイル、音楽ファイル等をダウンロードし、レイアウトを解析して表示あるいは再生するプログラムである。すなわち、フォームを使用してユーザがデータをＷｅｂサーバに送信することや、Ｊａｖａ（登録商標）等で記述されたプログラムを動作することも可能なプログラムである。
【００７２】
メーラープログラム９３０は、電子メールの作成、ネットワーク上のメールサーバとの電子メールの送受信、受信した電子メールの保存や管理を行うプログラムである。
鍵管理プログラム９４０は、秘密鍵と公開鍵のペアの生成、暗号化、復号、署名、署名検証機能、秘密鍵や証明書のインポートや管理等を行うプログラムである。
【００７３】
利用者の秘密鍵９５０は、利用者装置１７０の鍵管理プログラム９４０によって生成された秘密鍵もしくは認証局装置１３０によって生成された利用者用の秘密鍵をインポートしたものである。
利用者の公開鍵証明書９６０は、認証局装置１３０によって生成された利用者用の公開鍵証明書をインポートしたものである。
利用者の属性証明書９７０は、認証局装置１３０によって生成された利用者用の属性証明書をインポートしたものである。
【００７４】
図１０は、承認者装置１８０のソフトウェア構成を示す図である。
承認者装置１８０のメモリ２４０には、オペレーティングシステム１０１０と、Ｗｅｂブラウザプログラム１０２０と、メーラープログラム１０３０とがロードされている領域がある。これらのプログラムは、必要に応じて、ＣＰＵ２３０により実行され、後に説明する機能を実現する。
【００７５】
次に、各プログラムの機能を説明する。各プログラムは、それぞれが格納されている装置内で読み出されＣＰＵ２３０によって実行されることにより、その機能が実現されるものであるが、説明の便宜上、各プログラムを実行主体として説明する。
図１０において、オペレーティングシステム１０１０は、装置全体の制御を行うために、ファイル管理、プロセス管理、デバイス管理といった機能を実現するためのプログラムである。
【００７６】
Ｗｅｂブラウザプログラム１０２０は、ネットワーク上のＷｅｂサーバに公開されたＨＴＭＬファイル、画像ファイル、音楽ファイル等をダウンロードし、レイアウトを解析して表示あるいは再生するプログラムである。すなわち、フォームを使用してユーザがデータをＷｅｂサーバに送信することや、Ｊａｖａ（登録商標）等で記述されたプログラムを動作することも可能なプログラムである。
【００７７】
メーラープログラム１０３０は、電子メールの作成、ネットワーク上のメールサーバとの電子メールの送受信、受信した電子メールの保存や管理を行うプログラムである。
図１１から図３４では、本実施の形態例におけるデータの管理形態や処理フローをユーザ情報管理のイベント別に図示したが、本実施の形態例において想定したイベントは以下のとおりである。
ＩＤに関して、（ａ）ＩＤの登録、（ｂ）ＩＤの削除、（ｃ）ＩＤの利用停止、（ｄ）ＩＤの利用停止解除、（ｅ）ＩＤの変更がある。また、属性に関して、（ｆ）属性の追加、（ｇ）属性の削除、（ｈ）属性の変更がある。
【００７８】
図１１は、ＩＤもしくは属性の登録時におけるデータの管理形態を例示する図である。
後述する図１３から図２４に示すメニュー選択・ＩＤ指定ステップＳ２１００にて、ＩＤの登録もしくは属性の登録が実施されると、ユーザに関するユーザ情報３６１はＩＤ管理装置１１０内のユーザ情報データベース３６０に登録される。図１１の例において、メニュー選択・ＩＤ指定ステップＳ２１００で登録されるユーザ情報３６１は、ＩＤ及び様々な属性情報（属性Ａ、・・・、属性Ｚ）となる。
【００７９】
また、ＩＤ管理装置１１０によって後述する図１３、図１５、図１９、図２２に示す鍵生成ステップＳ２７００が実施された場合には、ユーザ情報３６１として公開鍵もユーザ情報データベース３６０に登録される。ここで、ＩＤは利用者を一意に示す情報であり、属性情報は、例えば、パスワード、役職、部署名など、ＩＤに紐づく様々な情報である。また、公開鍵は、ＰＫＩ（Public Key Infrastructure）ベースの認証を必要とするサービス提供装置を利用する際に利用者が使用する公開鍵のことである。
【００８０】
次に、後述する図１３から図２４に示すプロビジョニングステップＳ２２００では、サービス提供装置１５０内に対して、Ｔ１で示すＩＤあるいは属性の登録要求が行われる。これにより、サービス提供装置１５０内のユーザ情報データベース７６０に要求されたＩＤあるいは属性が登録される。また、サービス提供装置１５０が複数ある場合、ＩＤ管理装置１１０は、各サービス提供装置１５０に対して、各サービス提供装置１５０が必要とするＩＤもしくは属性を登録するものとする。
【００８１】
図１１の例では、ＩＤ管理装置１１０のユーザ情報データベース３６０をマスタのデータベースとし、本データベースの情報をもとに、サービス提供装置１５０内のユーザ情報データベース７６０に対してＩＤと属性Ａから属性Ｘまでを登録する。すなわち、ＩＤがｕｓｅｒ（１）、属性ＡがａＡ（１）、・・・、属性ＸがａＸ（１）となるようにユーザアカウントを登録する。
【００８２】
前記図１３から図２４に示すプロビジョニングステップと併せて実施される後記証明書発行要求ステップＳ２３００では、ＩＤ管理装置１１０は、認証局装置１３０に対して、Ｔ２で示す公開鍵証明書あるいは属性証明書の発行を要求することになる。図１１の例では、ＩＤ管理装置１１０のユーザ情報データベース３６０をマスタのデータベースとし、本データベースの情報をもとに、認証局装置１３０に対してＩＤ、公開鍵、各種属性を送信する。
【００８３】
公開鍵証明書１３１の生成においては、様々な記載項目を決めなければならない。主体者名、公開鍵情報、属性を格納する拡張項目以外の項目は、認証局のポリシーによって決めることが可能な値である。このため、これらの項目については本実施の形態例ではシステムが自動的に割り当てるものとしている。同様に、属性証明書１３２の生成においても、様々な記載項目を決めなければならない。保有者情報、属性以外の項目は、属性認証局のポリシーによって決めることが可能な値である。このため、これらの項目については本実施の形態例ではシステムが自動的に割り当てるものとしている。
【００８４】
公開鍵証明書１３１の発行に関しては、ＩＤ管理装置１１０におけるＩＤの命名体系と、認証局装置１３０における主体者名の命名体系が異なる場合がある。その場合のＩＤ管理装置１１０から送信されるＩＤは、ＩＤ管理装置１１０内のユーザ情報データベース３６０で管理されているＩＤの値そのものではなく、認証局装置１３０の主体者名の命名体系に適合するよう変換された値が送信されるものとする。
【００８５】
また、公開鍵証明書１３１に結びつく属性証明書１３２の発行に関しても、属性証明書１３２に記載する保有者情報は当該公開鍵証明書１３１の発行者名及び当該公開鍵証明書１３１のシリアル番号の組み合わせで指定されることが多い。このことから、本実施の形態例におけるＩＤ管理装置１１０から送信されるＩＤは、ＩＤ管理装置１１０内のユーザ情報データベース３６０で管理されているＩＤの値そのものではない。
【００８６】
すなわち、ＩＤ管理装置１１０は、当該データベース３６０内で管理している証明書情報３６２からＩＤをキーにして検索し、該当するレコードの中から公開鍵証明書１３１を発行した発行者名の値とそのレコードに記録されているシリアル番号の値の組み合わせがＩＤ管理装置１１０から送信されるものとする。
【００８７】
但し、本実施の形態における保有者情報の記載方法は公開鍵証明書１３１の発行者名及びシリアル番号の組み合わせとは限らない。図１１の例で、ＩＤ管理装置１１０は、ＩＤが「ｕｓｅｒ（１）」であり、かつ、発行者名が「ＣＡ」であるレコードを検索し、認証局装置１３０に対して送付するＩＤとして、発行者名が「ＣＡ」、シリアル番号が「ｓｎ１１」というデータを送付する。
【００８８】
認証局装置１３０では、ＩＤ管理装置１１０から送信された証明書発行要求Ｔ２をもとに、公開鍵証明書１３１もしくは属性証明書１３２を生成する。その後認証局装置１３０は、ＩＤ管理装置１１０に対して証明書発行完了通知Ｔ３を返信する。証明書発行完了通知Ｔ３には、発行した証明書に記載されている発行者名、シリアル番号、記載属性型のデータを含むものとし、これらのデータを受信したＩＤ管理装置１１０は、ユーザ情報データベース３６０の証明書情報３６２にＩＤと結びつけて記録する。
【００８９】
図１１の例における公開鍵証明書１３１の発行完了通知Ｔ３としては、発行者名が「ＣＡ」、シリアル番号が「ｓｎ１１」、記載属性型が「ａＡ、ａＢ」となり、これらのデータが、「ｕｓｅｒ（１）」というＩＤに結び付けられてユーザ情報データベース３６０に記録される。
【００９０】
同様に、図１１の属性証明書１３２の発行完了通知Ｔ３としては、発行者名が「ＡＡ」、シリアル番号が「ｓｎ１２」、記載属性型が「ａＣ」となり、これらのデータが、「ｕｓｅｒ（１）」というＩＤに結び付けられてユーザ情報データベース３６０に記録される。ここで記録したデータは、属性証明書１３２の発行時のＩＤの指定の他、ＩＤの削除、利用停止、利用停止解除、変更、属性の追加、削除、変更のイベントにて活用される。
【００９１】
図１２は、ＩＤもしくは属性の削除時等におけるデータの管理形態を例示する図である。
後述する図１３から図２４に示すメニュー選択・ＩＤ指定ステップＳ２１００にて、ＩＤの削除、利用停止、利用停止解除、変更、属性の追加、削除、変更が実施されると、ＩＤ管理装置１１０内のユーザ情報データベース３６０の内容が変更もしくは削除される。図１２の例では、メニュー選択・ＩＤ指定ステップでｕｓｅｒ（１）のＩＤ及び属性の削除が指定された場合を示しており、ＩＤが「ｕｓｅｒ（１）」であるレコードが削除対象となる。
【００９２】
次に、後述する図１３から図２４に示すプロビジョニングステップＳ２２００では、サービス提供装置１５０内に対して、Ｔ１１で示すＩＤ及び属性の削除要求が行われ、サービス提供装置１５０内のユーザ情報データベース７６０に要求されたＩＤ及び属性が削除される。また、サービス提供装置１５０が複数ある場合、ＩＤ管理装置１１０は、各サービス提供装置１５０に対して、各サービス提供装置１５０が必要とするＩＤ及び属性を削除するものとする。
【００９３】
図１２の例では、ＩＤ管理装置１１０のユーザ情報データベース３６０をマスタのデータベースとし、本データベースの情報をもとに、サービス提供装置１５０内のユーザ情報データベース７６０に対してＩＤと属性Ａから属性Ｘまでを削除する。すなわち、ＩＤがｕｓｅｒ（１）であるユーザアカウントを削除する。
【００９４】
前記図１３から図２４に示すプロビジョニングステップと併せて実施される後記証明書失効要求ステップＳ３０００では、ＩＤ管理装置１１０は、認証局装置１３０に対して、Ｔ１２で示す公開鍵証明書あるいは属性証明書の失効を要求することになる。図１２の例では、ＩＤ管理装置１１０は、ユーザ情報データベース３６０をマスタのデータベースとし、本データベースの情報をもとに、認証局装置１３０に対してＩＤから導き出された証明書の発行者名及びシリアル番号を送信する。
【００９５】
公開鍵証明書の失効情報１３３の生成においては、様々な記載項目を決めなければならない。失効する公開鍵証明書のシリアル番号以外の項目は、認証局のポリシーによって決めることが可能な値である。このため、これらの項目については本実施の形態例ではシステムが自動的に割り当てるものとしている。同様に、属性証明書の失効情報１３４の生成においても、様々な記載項目を決めなければならないが、失効する属性証明書のシリアル番号以外の項目は、属性認証局のポリシーによって決めることが可能な値である。このため、これらの項目については本実施の形態例ではシステムが自動的に割り当てるものとしている。
【００９６】
公開鍵証明書の失効や属性証明書の失効に関しては、ＩＤ管理装置１１０は、ユーザ情報データベース３６０より、ＩＤをキーにして検索される発行者名とシリアル番号を認証局装置１３０に送信することになる。図１２の例で、ＩＤ管理装置１１０は、ＩＤが「ｕｓｅｒ（１）」であるレコードを全て検索し、認証局装置１３０に対して、発行者名が「ＣＡ」、シリアル番号が「ｓｎ１１」というデータを送信することで公開鍵証明書が失効される。そして、発行者名が「ＡＡ」、シリアル番号が「ｓｎ１２」というデータを送信することで属性証明書が失効されることになる。
【００９７】
認証局装置１３０では、ＩＤ管理装置１１０から送信された証明書失効要求Ｔ１２をもとに、公開鍵証明書の失効情報１３３もしくは属性証明書の失効情報１３４を生成する。その後認証局装置１３０は、ＩＤ管理装置１１０に対して証明書失効完了通知Ｔ１３を返信する。
【００９８】
上記の例はＩＤ及び属性の削除の場合について説明したが、一部の属性のみ削除する場合については、証明書情報３６２の記載属性型に削除対象となる属性型が記録されていれば、そのレコードに記載された証明書の発行者名とシリアル番号を送信することになる。図１２の例において、ｕｓｅｒ（１）に関する属性Ｃの削除イベントが発生したとすると、ＩＤがｕｓｅｒ（１）で、かつ、記載属性型に「ａＣ」を含むレコードを検索し、検索されたレコードに記載されている発行者名とシリアル番号、すなわち、「ＡＡ」と「ｓｎ１２」を認証局装置１３０に送信することで、属性証明書が失効される。
【００９９】
図１３から図２４は、イベント別に、各装置間で実施される処理フローの概要を例示する図である。特に、図１３から図１７は、例えば企業における人事部門のシステムを操作できるような管理者が、利用者のＩＤを強制的に指定する場合の処理フローの例を示したものである。
【０１００】
また、図１８から図２４は、利用者自身が申請を行い、当該申請を承認できる権限をした承認者が承認することでＩＤに対する操作が実施されるという場合の処理フローの例を示したものである。また、これら図１３から図２４で用いている各ステップの詳細な手順を図２５から図３４の詳細な処理フローで示す。
【０１０１】
図１３は、管理者が利用者のＩＤを登録する場合の処理フローの概要を例示する図である。
はじめに、メニュー選択・ＩＤ指定ステップを実施する（ステップ２１００、以下、ステップをＳと略して記す）。すなわち、管理者が管理者装置１６０のＷｅｂブラウザプログラム８２０を使用してＩＤ管理装置１１０にアクセスし、ＩＤの登録を行うためのメニューを選択し、登録するＩＤを入力する（さらに必要に応じて各種属性も入力する）。本ステップの詳細は、図２５にて例示する。
【０１０２】
次に、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を、サービス提供装置１５０のユーザ情報データベース７６０に反映するためのＩＤ及び属性の登録要求をＩＤ管理装置１１０が送信する。本ステップの詳細は、図２６にて例示する。また、プロビジョニングの対象として、メールサーバ装置１２０のメールアカウントも含まれるのであれば、メールサーバ装置１２０のユーザ情報データベース４６０に対するＩＤ及び属性の登録要求も、本ステップで行うものとする。
【０１０３】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容をもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信する。本ステップの詳細は、図２７にて例示する。なお、プロビジョニングステップＳ２２００と証明書発行要求ステップＳ２３００の順序性は問わない。
【０１０４】
プロビジョニングステップＳ２２００及び証明書発行要求ステップＳ２３００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して証明書発行手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０１０５】
一方、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤは、管理者から利用者に通知されないと、利用者はＩＤを利用して業務サービスを享受することができない。このため、管理者は、ＩＤを記載した紙を利用者に送付するなどして、利用者にＩＤを通知するといったＩＤ通知ステップを実施する（Ｓ２５００）。また、ＩＤの他にパスワード等の認証に関する属性も通知する必要がある場合は、ＩＤと併せて通知する。但し、利用者へのＩＤ通知方法は、既知の方法を使えばよく、ＩＤの通知方法を紙での送付に限定するものではない。
【０１０６】
メール送信ステップＳ２４００及びＩＤ通知ステップＳ２５００が完了すると、メール受信ステップを実施する（Ｓ２６００）。すなわち、利用者はメールを利用できるようになり、かつ、当該利用者のメールアカウント宛に証明書発行手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０及びＩＤ通知ステップＳ２５００にて通知されたＩＤ及びパスワードを利用してメールサーバ装置１２０にアクセスし、当該利用者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０１０７】
前記メール受信ステップＳ２６００において証明書発行手続きを行うためのアクセス先が記載されたメールを受信した利用者は、鍵生成ステップを実施する（Ｓ２７００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザを用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスして鍵生成用の画面を取得する。そして、利用者装置１７０の鍵管理プログラム９４０を用いて利用者の秘密鍵及び公開鍵のペアを生成して公開鍵を認証局装置１３０に送信する。認証局装置１３０は、当該公開鍵を用いて当該利用者のＩＤに基づく公開鍵証明書を生成する。本ステップの詳細は、図３０にて例示する。
【０１０８】
前記鍵生成ステップＳ２７００において認証局装置１３０で利用者の公開鍵証明書の生成が完了したら、証明書取得ステップを実施する（Ｓ２８００）。すなわち、当該ステップに続けて、利用者は、利用者装置１７０のＷｅｂブラウザプログラムを用いて、認証局装置１３０から当該公開鍵証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０１０９】
前記鍵生成ステップＳ２７００において認証局装置１３０で利用者の公開鍵証明書の生成が完了したら、証明書登録ステップを実施する（Ｓ２９００）。すなわち、即時もしくは一定期間後に、認証局装置１３０はリポジトリ装置１４０に対して、当該公開鍵証明書の登録要求を送信し、リポジトリ装置１４０内で当該公開鍵証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０１１０】
また、前記証明書登録ステップＳ２９００と並行してもしくは当該ステップの実施後即時にもしくは当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）を送信する。そして、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。本ステップの詳細は、図３３にて例示する。
【０１１１】
以上の手順によって、管理者が指定したＩＤをサービス提供装置１５０に登録する処理と、当該ＩＤに基づく公開鍵証明書を発行する処理を、一連の流れで実施することが可能となり、管理者におけるＩＤ登録および公開鍵証明書発行に係る手間を軽減することが可能となる。
【０１１２】
図１３を用いて、上記とは別の、管理者が利用者のＩＤを登録する場合の処理フローの概要の実施例を例示する。ここでは、認証局装置１３０側で、利用者の鍵ペアを生成するモデルを前提とする。この例では、上述した図１３の処理と異なる点のみを説明し、共通の処理の説明を省略する。
【０１１３】
まず、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容をもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信し、認証局装置１３０が要求に応じた利用者の鍵ペア及び公開鍵証明書を生成する。利用者の鍵ペアについては、認証局装置１３０で利用者鍵ペア生成プログラム５４５を用いて生成される。本ステップの詳細は、図２７にて例示する。なお、プロビジョニングステップＳ２２００と証明書発行要求ステップＳ２３００の順序性は問わない。
【０１１４】
次に、前記メール受信ステップＳ２６００において証明書取得手続きを行うためのアクセス先が記載されたメールを受信した利用者は、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザを用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスし、認証局装置１３０から利用者の鍵ペア及び公開鍵証明書をダウンロードし、利用者装置１７０内に保存する。ここで、ダウンロードされる利用者の鍵ペアは、暗号化されるものとする。本ステップの詳細は、図３１にて例示する。
【０１１５】
以上の手順によって、管理者が指定したＩＤをサービス提供装置１５０に登録する処理と、認証局装置１３０側で利用者の鍵ペアを生成すると共に当該ＩＤに基づく公開鍵証明書を発行する処理を、一連の流れで実施することが可能となり、管理者におけるＩＤ登録および公開鍵証明書発行に係る手間を軽減することが可能となる。
【０１１６】
図１４は、管理者が利用者のＩＤを削除、利用停止もしくは利用停止解除する場合の処理フローの概要を例示する図である。
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、管理者が管理者装置１６０のＷｅｂブラウザプログラム８２０を使用してＩＤ管理装置１１０にアクセスし、ＩＤの削除、利用停止もしくは利用停止解除を行うためのメニューを選択し、削除、利用停止もしくは利用停止解除するＩＤを入力する。本ステップの詳細は、図２５にて例示する。
【０１１７】
次に、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤに対して、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、サービス提供装置１５０のユーザ情報データベース７６０に反映するためのＩＤの削除要求、利用停止要求もしくは利用停止解除要求をＩＤ管理装置１１０が送信する。本ステップの詳細は、図２６にて例示する。また、プロビジョニングの対象として、メールサーバ装置１２０のメールアカウントも含まれるのであれば、メールサーバ装置１２０のユーザ情報データベース４６０に対するＩＤの削除要求、利用停止要求もしくは利用停止解除要求も、本ステップで行うものとする。
【０１１８】
また、前記プロビジョニングステップＳ２２００と併せて、証明書失効要求ステップを実施する（Ｓ３１００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤをもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の失効要求、利用停止要求もしくは利用停止解除要求を送信し、認証局装置１３０にて証明書の失効情報を生成する。但し、失効情報の開示形態として、オンラインで証明書のステータスを回答するような形態をとる場合には、証明書の失効情報を生成する処理が、証明書のステータスを変更する処理に置き換わるものとする。本ステップの詳細は、図２７にて例示する。なお、プロビジョニングステップＳ２２００と証明書失効要求ステップＳ３１００の順序性は問わない。
【０１１９】
前記証明書失効ステップＳ３１００において認証局装置１３０で失効情報の生成が完了したら、失効情報登録ステップを実施する（Ｓ３２００）。すなわち、即時もしくは一定期間後に、認証局装置１３０はリポジトリ装置１４０に対して、当該失効情報の登録要求を送信し、リポジトリ装置１４０内で当該失効情報を保存する。本ステップの詳細は、図３２にて例示する。
【０１２０】
また、前記失効情報登録ステップＳ３２００と並行してもしくは当該ステップの実施後即時にもしくは当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を失効した旨の完了通知（削除、利用停止もしくは利用停止解除の対象となったＩＤを含む）を送信し、ＩＤ管理装置１１０内で完了通知時に送付された情報をもとに、ユーザ情報データベース３６０を削除もしくは変更等する。本ステップの詳細は、図３３にて例示する。
【０１２１】
以上の手順によって、管理者が指定したＩＤをサービス提供装置１５０に削除、利用停止もしくは利用停止解除する処理と、当該ＩＤに基づく公開鍵証明書を失効、利用停止もしくは利用停止解除する処理を、一連の流れで実施することが可能となる。これにより、管理者におけるＩＤの削除、利用停止もしくは利用停止解除、および、公開鍵証明書の失効、利用停止もしくは利用停止解除に係る手間を軽減することが可能となる。
【０１２２】
図１５は、管理者が利用者のＩＤを変更する場合の処理フローの概要を例示する図である。また、公開鍵証明書に属性情報を記載する場合の属性の登録、変更、削除についても本処理フローに従うものとする。
【０１２３】
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、管理者が管理者装置１６０のＷｅｂブラウザプログラム８２０を使用してＩＤ管理装置１１０にアクセスし、ＩＤの変更を行うためのメニューを選択し、変更する前と後のＩＤを入力する。本ステップの詳細は、図２５にて例示する。属性の登録、変更もしくは削除時は、属性の登録、変更もしくは削除を行うためのメニューを選択し、登録、変更もしくは削除対象となるＩＤと属性を入力する。
【０１２４】
次に、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤに対して、サービス提供装置１５０のユーザ情報データベース７６０に反映するためのＩＤもしくは属性の変更要求をＩＤ管理装置１１０が送信する。本ステップの詳細は、図２６にて例示する。また、プロビジョニングの対象として、メールサーバ装置１２０のメールアカウントも含まれるのであれば、メールサーバ装置１２０のユーザ情報データベース４６０に対するＩＤの変更要求も、本ステップで行うものとする。
【０１２５】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力された変更後のＩＤもしくは属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信する。
【０１２６】
ここで、変更前のＩＤに対応した公開鍵証明書の公開鍵と変更後のＩＤに対応した公開鍵証明書の公開鍵を同じ値にする場合には、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信する情報の中に、変更前のＩＤに対応した公開鍵証明書の公開鍵を含める。これによって、本ステップ内で公開鍵証明書を生成できる。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、後記証明書失効要求ステップＳ３１００と、本証明書発行要求ステップＳ２３００の順序性は問わない。
【０１２７】
さらに、前記プロビジョニングステップＳ２２００と併せて、証明書失効要求ステップを実施する（Ｓ３１００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力された変更前のＩＤをもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の失効要求を送信し、認証局装置１３０にて証明書の失効情報を生成する。
【０１２８】
但し、失効情報の開示形態として、オンラインで証明書のステータスを回答するような形態をとる場合には、証明書の失効情報を生成する処理が、証明書のステータスを変更する処理に置き換わるものとする。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、前記証明書発行要求ステップＳ２３００と、本証明書失効要求ステップＳ３１００の順序性は問わない。
【０１２９】
前記証明書失効ステップＳ３１００において認証局装置１３０で失効情報の生成が完了したら、失効情報登録ステップを実施する（Ｓ３２００）。すなわち、即時もしくは一定期間後に、認証局装置１３０はリポジトリ装置１４０に対して、当該失効情報の登録要求を送信し、リポジトリ装置１４０内で当該失効情報を保存する。本ステップの詳細は、図３２にて例示する。
【０１３０】
プロビジョニングステップＳ２２００、証明書発行要求ステップＳ２３００及び証明書失効要求ステップＳ３１００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して変更後のＩＤに対応した証明書発行手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０１３１】
一方、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力された変更後のＩＤは、管理者から利用者に通知されないと、利用者はＩＤを利用して業務サービスを享受することができない。このため、管理者は、ＩＤを記載した紙を利用者に送付するなどして、利用者にＩＤを通知するといったＩＤ通知ステップを実施する（Ｓ２５００）。
【０１３２】
また、ＩＤの他にパスワード等の認証に関する属性も通知する必要がある場合は、ＩＤと併せて通知する。但し、利用者へのＩＤ通知方法は、既知の方法を使えばよく、ＩＤの通知方法を紙での送付に限定するものではない。属性の登録、変更もしくは削除時であって変更前のＩＤと変更後のＩＤが同じ場合には、本ステップは省略される。
【０１３３】
メール送信ステップＳ２４００及びＩＤ通知ステップＳ２５００が完了すると、メール受信ステップを実施する（Ｓ２６００）。すなわち、利用者は変更後のＩＤを用いてメールを利用できるようになり、かつ、当該利用者のメールアカウント宛に証明書発行手続きを行うためのアクセス先が記載されたメールが届いている状態になる。
【０１３４】
このため、利用者は、利用者装置１７０のメーラープログラム９３０及びＩＤ通知ステップＳ２５００にて通知されたＩＤ及びパスワードを利用してメールサーバ装置１２０にアクセスし、当該利用者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０１３５】
前記メール受信ステップＳ２６００において証明書発行手続きを行うためのアクセス先が記載されたメールを受信した利用者は、鍵生成ステップを実施する（Ｓ２７００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザを用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスして鍵生成用の画面を取得し、利用者装置１７０の鍵管理プログラム９４０を用いて利用者の秘密鍵及び公開鍵のペアを生成して公開鍵を認証局装置１３０に送信する。
そして、認証局装置１３０は当該公開鍵を用いて当該利用者のＩＤに基づく公開鍵証明書を生成する。但し、前記証明書発行要求ステップ２３００において既に公開鍵証明書を生成している場合、本ステップは省略される。本ステップの詳細は、図３０にて例示する。
【０１３６】
前記鍵生成ステップＳ２７００もしくは前記証明書発行要求ステップ２３００において認証局装置１３０で利用者の公開鍵証明書の生成が完了したら、証明書取得ステップを実施する（Ｓ２８００）。すなわち、当該ステップに続けて、利用者は、利用者装置１７０のＷｅｂブラウザプログラム９２０を用いて、認証局装置１３０から当該公開鍵証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０１３７】
前記鍵生成ステップＳ２７００もしくは前記証明書発行要求ステップ２３００において認証局装置１３０で利用者の公開鍵証明書の生成が完了したら、証明書登録ステップを実施する（Ｓ２９００）。すなわち、即時もしくは一定期間後に、認証局装置１３０はリポジトリ装置１４０に対して、当該公開鍵証明書の登録要求を送信し、リポジトリ装置１４０内で当該公開鍵証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０１３８】
また、前記証明書登録ステップＳ２９００と並行して、もしくは、当該ステップの実施後即時に、もしくは、当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、変更後のＩＤに対する証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）及び変更前のＩＤに対する証明書を失効した旨の通知（失効の対象となったＩＤを含む）を送信し、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。
【０１３９】
また、本ステップは、証明書の登録の完了通知と証明書の失効の完了通知を兼ねているが、これらは別々に実施してもよい。すなわち、前記証明書失効ステップＳ３２００と並行して、もしくは、当該ステップの実施後即時に、もしくは、当該ステップの実施後一定期間後に、変更前のＩＤに対する証明書を失効した旨の通知（失効の対象となったＩＤを含む）を送信してもよい。本ステップの詳細は、図３３にて例示する。
【０１４０】
以上の手順によって、管理者が指定した変更前のＩＤをサービス提供装置１５０から削除する処理と、変更前のＩＤに基づく公開鍵証明書を失効する処理と、管理者が指定した変更後のＩＤをサービス提供装置１５０に登録する処理と、変更後のＩＤに基づく公開鍵証明書を発行する処理を、一連の流れで実施することが可能となる。これにより、管理者におけるＩＤ変更および公開鍵証明書再発行に係る手間を軽減することが可能となる。
【０１４１】
図１５を用いて、上記とは別の、管理者が利用者のＩＤを変更する場合の処理フローの概要の実施例を例示する。また、公開鍵証明書に属性情報を記載する場合の属性の登録、変更、削除についても本処理フローに従うものとする。ここでは、認証局装置１３０側で、利用者の鍵ペアを生成するモデルを前提とする。この例では、上述した図１５の処理と異なる点のみを説明し、共通の処理の説明を省略する。
【０１４２】
まず、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力された変更後のＩＤもしくは属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信し、認証局装置１３０が要求に応じた利用者の鍵ペア及び公開鍵証明書を生成する。利用者の鍵ペアについては、認証局装置１３０の利用者鍵ペア生成プログラム５４５を用いて生成される。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、後記証明書失効要求ステップＳ３１００と、本証明書発行要求ステップＳ２３００の順序性は問わない。
【０１４３】
次に、証明書取得ステップを実施する（Ｓ２８００）。すなわち、前記メール受信ステップＳ２６００において証明書取得手続きを行うためのアクセス先が記載されたメールを受信した利用者は、利用者装置１７０のＷｅｂブラウザを用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスする。そして、認証局装置１３０から利用者の鍵ペア及び公開鍵証明書をダウンロードし、利用者装置１７０内に保存する。ここで、ダウンロードされる利用者の鍵ペアは、暗号化されるものとする。本ステップの詳細は、図３１にて例示する。
【０１４４】
前記証明書発行要求ステップ２３００において認証局装置１３０で利用者の鍵ペア及び公開鍵証明書の生成が完了したら、証明書登録ステップを実施する（Ｓ２９００）。すなわち、即時もしくは一定期間後に、認証局装置１３０はリポジトリ装置１４０に対して、当該公開鍵証明書の登録要求を送信し、リポジトリ装置１４０内で当該公開鍵証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０１４５】
以上の手順によって、管理者が指定した変更前のＩＤをサービス提供装置１５０から削除する処理と、認証局装置１３０側で利用者の鍵ペアを生成すると共に変更前のＩＤに基づく公開鍵証明書を失効する処理と、管理者が指定した変更後のＩＤをサービス提供装置１５０に登録する処理と、認証局装置１３０側で利用者の鍵ペアを生成すると共に変更後のＩＤに基づく公開鍵証明書を発行する処理を、一連の流れで実施することが可能となる。これにより、管理者におけるＩＤ変更および公開鍵証明書再発行に係る手間を軽減することが可能となる。
【０１４６】
図１６は、管理者が利用者の属性情報を登録する場合の処理フローの概要を例示する図である。但し、図１６は属性情報の表現に属性証明書を用いる場合を想定しており、属性情報の表現に公開鍵証明書を用いる場合は、図１５の手順に従うものとする。
【０１４７】
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、管理者が管理者装置１６０のＷｅｂブラウザプログラム８２０を使用してＩＤ管理装置１１０にアクセスし、属性の追加を行うためのメニューを選択し、その対象となるＩＤと追加する属性情報を入力する。本ステップの詳細は、図２５にて例示する。
【０１４８】
次に、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性に対して、サービス提供装置１５０のユーザ情報データベース７６０に反映するための属性追加要求をＩＤ管理装置１１０が送信する。本ステップの詳細は、図２６にて例示する。
【０１４９】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に属性証明書の発行要求を送信する。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、本証明書発行要求ステップＳ２３００の順序性は問わない。
【０１５０】
前記証明書発行ステップＳ２３００において認証局装置１３０で利用者の属性証明書の生成が完了したら、証明書登録ステップを実施する（Ｓ２９００）。すなわち、即時もしくは一定期間後に、認証局装置１３０はリポジトリ装置１４０に対して、当該属性証明書の登録要求を送信し、リポジトリ装置１４０内で当該属性証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０１５１】
プロビジョニングステップＳ２２００、証明書発行要求ステップＳ２３００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して証明書取得手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。但し、属性証明書の利用形態として、以下の場合は本ステップは省略してもよい。すなわち、属性証明書の保有者から属性証明書の検証者に属性証明書を提示するというプッシュ型ではなく、属性証明書の検証者がリポジトリ等の公開サーバに属性証明書を取りにいくというプル型の場合である。本ステップの詳細は、図２８にて例示する。
【０１５２】
メール送信ステップＳ２４００が実施された場合には、メール受信ステップを実施する（Ｓ２６００）。すなわち、利用者は自身のメールアカウント宛に証明書取得手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０を利用してメールサーバ装置１２０にアクセスし、当該利用者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０１５３】
前記メール受信ステップＳ２６００において証明書取得手続きを行うためのアクセス先が記載されたメールを受信した利用者は、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザを用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスし、認証局装置１３０から属性証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０１５４】
一方、前記証明書登録ステップＳ２９００と並行して、もしくは、当該ステップの実施後即時に、もしくは、当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）を送信し、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。本ステップの詳細は、図３３にて例示する。
【０１５５】
以上の手順によって、管理者が指定したＩＤに対してサービス提供装置１５０に属性を追加する処理と、当該ＩＤに基づく属性証明書を発行する処理を、一連の流れで実施することが可能となり、管理者における属性追加および属性証明書発行に係る手間を軽減することが可能となる。
【０１５６】
図１７は、管理者が利用者の属性情報を変更もしくは削除する場合の処理フローの概要を例示する図である。但し、図１７は属性情報の表現に属性証明書を用いる場合を想定しており、属性情報の表現に公開鍵証明書を用いる場合は、図１５の手順に従うものとする。
【０１５７】
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、管理者が管理者装置１６０のＷｅｂブラウザプログラム８２０を使用してＩＤ管理装置１１０にアクセスし、属性の変更もしくは削除を行うためのメニューを選択し、その対象となるＩＤと変更もしくは削除する属性情報を入力する。本ステップの詳細は、図２５にて例示する。
【０１５８】
次に、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性に対して、ＩＤ管理装置１１０がサービス提供装置１５０のユーザ情報データベース７６０に反映するための属性変更要求もしくは属性削除要求を送信する。本ステップの詳細は、図２６にて例示する。
【０１５９】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に属性証明書の発行要求を送信する。但し、属性の変更もしくは削除の内容に応じて、新たに属性証明書を発行する必要がない場合、本ステップは省略される。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、後記証明書失効要求ステップＳ３１００と、本証明書発行要求ステップＳ２３００の順序性は問わない。
【０１６０】
さらに、前記プロビジョニングステップＳ２２００と併せて、証明書失効要求ステップを実施する（Ｓ３１００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に属性証明書の失効要求を送信し、認証局装置１３０にて属性証明書失効情報を生成する。但し、失効情報の開示形態として、オンラインで証明書のステータスを回答するような形態をとる場合には、属性証明書失効情報を生成する処理が、属性証明書のステータスを変更する処理に置き換わるものとする。
【０１６１】
ここで、どの属性証明書を失効するかは、メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性と、図１２の説明にて記載したＩＤ管理装置１１０内のユーザ情報データベース３６０内の証明書情報３６２である証明書のＩＤとその記載属性型を比較して合致したものが選択されるものとする。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、前記証明書発行要求ステップＳ２３００と、本証明書失効要求ステップＳ３１００の順序性は問わない。
【０１６２】
前記証明書発行ステップＳ２３００が実施され、認証局装置１３０で利用者の属性証明書の生成が完了した場合には、即時もしくは一定期間後に、証明書登録ステップを実施する（Ｓ２９００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該属性証明書の登録要求を送信し、リポジトリ装置１４０内で当該属性証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０１６３】
また、前記証明書失効ステップＳ３１００において認証局装置１３０で属性証明書失効情報の生成が完了したら、即時もしくは一定期間後に、失効情報登録ステップを実施する（Ｓ３２００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該失効情報の登録要求を送信し、リポジトリ装置１４０内で当該失効情報を保存する。本ステップの詳細は、図３２にて例示する。
【０１６４】
プロビジョニングステップＳ２２００、証明書発行要求ステップＳ２３００及び証明書失効要求ステップＳ３１００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して証明書取得手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。
【０１６５】
但し、属性証明書の利用形態として、以下の場合には本ステップは省略してもよい。すなわち、属性証明書の保有者から属性証明書の検証者に属性証明書を提示するというプッシュ型ではなく、属性証明書の検証者がリポジトリ等の公開サーバに属性証明書を取りにいくというプル型の場合である。本ステップの詳細は、図２８にて例示する。
【０１６６】
メール送信ステップＳ２４００が実施された場合には、メール受信ステップを実施する（Ｓ２６００）。すなわち、利用者は自身のメールアカウント宛に証明書取得手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０を利用してメールサーバ装置１２０にアクセスし、当該利用者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０１６７】
前記メール受信ステップＳ２６００において証明書取得手続きを行うためのアクセス先が記載されたメールを受信した利用者は、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザを用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスし、認証局装置１３０から属性証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０１６８】
一方、前記証明書登録ステップＳ２９００と並行して、もしくは、当該ステップの実施後即時に、もしくは、当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）を送信し、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。本ステップの詳細は、図３３にて例示する。
【０１６９】
以上の手順によって、管理者が指定したＩＤに対してサービス提供装置１５０に属性を変更もしくは削除する処理と、当該ＩＤに基づく属性証明書を失効もしくは再発行する処理を、一連の流れで実施することが可能となり、管理者における属性変更もしくは削除および属性証明書失効もしくは再発行に係る手間を軽減することが可能となる。
【０１７０】
図１８は、利用者がＩＤを登録する場合の処理フローの概要を例示する図である。
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を使用してＩＤ管理装置１１０にアクセスし、ＩＤの登録を行うためのメニューを選択し、登録するＩＤを入力する（さらに必要に応じてパスワード等の各種属性も入力する）。本ステップの詳細は、図２５にて例示する。
【０１７１】
前記メニュー選択・ＩＤ指定ステップＳ２１００にてＩＤの入力が完了した後、続けて、鍵生成ステップを実施する（Ｓ２７００）。すなわち、利用者はＷｅｂの画面遷移に従ってＩＤ管理装置１１０もしくは認証局装置１３０にアクセスする。これにより鍵生成用の画面を取得し、利用者装置１７０の鍵管理プログラム９４０を用いて利用者の秘密鍵及び公開鍵のペアを生成する。そして公開鍵をアクセス先である当該ＩＤ管理装置１１０もしくは当該認証局装置１３０に送信する。公開鍵の送信先が認証局装置１３０の場合には、その後の画面遷移でＩＤ管理装置に戻るものとする。本ステップの詳細は、図３０にて例示する。
【０１７２】
次に、前記鍵生成ステップＳ２７００が実施された後、承認者宛メール送信ステップを実施する（Ｓ２４５０）。すなわち、ＩＤ管理装置１１０は、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を承認者に承認してもらう必要がある。このために、承認者のメールアドレスに対して承認手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０１７３】
前記承認者宛メール送信ステップＳ２４５０が完了すると、承認者宛メール受信ステップを実施する（Ｓ２６５０）。すなわち、承認者のメールアカウント宛には承認手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、承認者は、承認者装置１８０のメーラープログラム１０３０を利用してメールサーバ装置１２０にアクセスし、当該承認者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０１７４】
前記承認者宛メール受信ステップＳ２６５０において承認手続きを行うためのアクセス先が記載されたメールを受信した承認者は、承認ステップを実施する（Ｓ３３００）。すなわち、承認者は、承認者装置１８０のＷｅｂブラウザプログラム１０２０を用いて、メールに記載されたアクセス先であるＩＤ管理装置１１０にアクセスして承認内容を確認し、承認可否をＩＤ管理装置１１０に送信する。本ステップの詳細は、図３４にて例示する。
【０１７５】
前記承認ステップＳ３３００が完了したら、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を、ＩＤ管理装置１１０がサービス提供装置１５０のユーザ情報データベース７６０に反映するためのＩＤ及び属性の登録要求を送信する。本ステップの詳細は、図２６にて例示する。また、プロビジョニングの対象として、メールサーバ装置１２０のメールアカウントも含まれるのであれば、メールサーバ装置１２０のユーザ情報データベース４６０に対するＩＤ及び属性の登録要求も、本ステップで行うものとする。
【０１７６】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容をもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信し、認証局装置１３０が要求に応じた利用者の公開鍵証明書を生成する。本ステップの詳細は、図２７にて例示する。なお、プロビジョニングステップＳ２２００と証明書発行要求ステップＳ２３００の順序性は問わない。
【０１７７】
前記証明書発行要求ステップＳ２３００において認証局装置１３０で利用者の公開鍵証明書の生成が完了したら、即時もしくは一定期間後に、証明書登録ステップを実施する（Ｓ２９００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該公開鍵証明書の登録要求を送信し、リポジトリ装置１４０内で当該公開鍵証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０１７８】
プロビジョニングステップＳ２２００及び証明書発行要求ステップＳ２３００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して証明書取得手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０１７９】
メール送信ステップＳ２４００が完了すると、メール受信ステップを実施する（Ｓ２６００）。すなわち、利用者はメールを利用できるようになり、かつ、当該利用者のメールアカウント宛に証明書取得手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０及びメニュー選択・ＩＤ指定ステップＳ２１００にて入力したＩＤ及びパスワードを利用してメールサーバ装置１２０にアクセスし、当該利用者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０１８０】
前記メール受信ステップＳ２６００において証明書取得手続きを行うためのアクセス先が記載されたメールを受信した利用者は、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザプログラム９２０を用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスし、認証局装置１３０から当該利用者の公開鍵証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０１８１】
また、前記証明書登録ステップＳ２９００と並行してもしくは当該ステップの実施後即時にもしくは当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）を送信し、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。本ステップの詳細は、図３３にて例示する。
【０１８２】
以上の手順によって、利用者が指定したＩＤを承認者が承認する処理と、当該ＩＤをサービス提供装置１５０に登録する処理と、当該ＩＤに基づく公開鍵証明書を発行する処理を、一連の流れで実施することが可能となる。これにより、利用者と承認者におけるＩＤ登録および公開鍵証明書発行に係る手間を軽減することが可能となる。
【０１８３】
図１９は、利用者がＩＤを登録する場合の処理フローの概要を別の実施例にて例示する図である。
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を使用してＩＤ管理装置１１０にアクセスし、ＩＤの登録を行うためのメニューを選択し、登録するＩＤを入力する（さらに必要に応じてパスワード等の各種属性も入力する）。本ステップの詳細は、図２５にて例示する。
【０１８４】
前記メニュー選択・ＩＤ指定ステップＳ２１００にてＩＤの入力が完了した後、続けて、鍵生成ステップを実施する（Ｓ２７００）。すなわち、利用者はＷｅｂの画面遷移に従ってＩＤ管理装置１１０もしくは認証局装置１３０にアクセスすることで鍵生成用の画面を取得する。そして、利用者装置１７０の鍵管理プログラム９４０を用いて利用者の秘密鍵及び公開鍵のペアを生成して公開鍵をアクセス先である当該ＩＤ管理装置１１０もしくは当該認証局装置１３０に送信する。公開鍵の送信先が認証局装置１３０の場合には、その後の画面遷移でＩＤ管理装置に戻るものとする。本ステップの詳細は、図３０にて例示する。
【０１８５】
次に、前記鍵生成ステップＳ２７００が実施された後、承認者宛メール送信ステップを実施する（Ｓ２４５０）。すなわち、ＩＤ管理装置１１０は、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を承認者に承認してもらう必要がある。このために、承認者のメールアドレスに対して承認手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０１８６】
前記承認者宛メール送信ステップＳ２４５０が完了すると、承認者宛メール受信ステップを実施する（Ｓ２６５０）。すなわち、承認者のメールアカウント宛には承認手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、承認者は、承認者装置１８０のメーラープログラム１０３０を利用してメールサーバ装置１２０にアクセスし、当該承認者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０１８７】
前記承認者宛メール受信ステップＳ２６５０において承認手続きを行うためのアクセス先が記載されたメールを受信した承認者は、承認ステップを実施する（Ｓ３３００）。すなわち、承認者は、承認者装置１８０のＷｅｂブラウザプログラム１０２０を用いて、メールに記載されたアクセス先であるＩＤ管理装置１１０にアクセスして承認内容を確認し、承認可否をＩＤ管理装置１１０に送信する。本ステップの詳細は、図３４にて例示する。
【０１８８】
前記承認ステップＳ３３００が完了したら、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を、ＩＤ管理装置１１０がサービス提供装置１５０のユーザ情報データベース７６０に反映するためのＩＤ及び属性の登録要求を送信する。本ステップの詳細は、図２６にて例示する。また、プロビジョニングの対象として、メールサーバ装置１２０のメールアカウントも含まれるのであれば、メールサーバ装置１２０のユーザ情報データベース４６０に対するＩＤ及び属性の登録要求も、本ステップで行うものとする。
【０１８９】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容をもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信する。本ステップの詳細は、図２７にて例示する。なお、プロビジョニングステップＳ２２００と証明書発行要求ステップＳ２３００の順序性は問わない。
【０１９０】
プロビジョニングステップＳ２２００及び証明書発行要求ステップＳ２３００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して証明書発行手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０１９１】
メール送信ステップＳ２４００が完了すると、利用者はメールを利用できるようになり、かつ、当該利用者のメールアカウント宛に証明書発行手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０及びメニュー選択・ＩＤ指定ステップＳ２１００にて入力したＩＤ及びパスワードを利用してメールサーバ装置１２０にアクセスし、当該利用者のメールアカウント宛に送信されたメールを取得する。メール受信ステップを実施する（Ｓ２６００）。本ステップの詳細は、図２９にて例示する。
【０１９２】
前記メール受信ステップＳ２６００において証明書発行手続きを行うためのアクセス先が記載されたメールを受信した利用者は、鍵生成ステップを実施する（Ｓ２７００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザプログラム９２０を用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスすることで鍵生成用の画面を取得する。そして、利用者装置１７０の鍵管理プログラム９４０を用いて利用者の秘密鍵及び公開鍵のペアを生成して公開鍵をアクセス先である認証局装置１３０に送信する。そして、認証局装置１３０では当該利用者の公開鍵証明書を生成する。本ステップの詳細は、図３０にて例示する。
【０１９３】
前記鍵生成ステップＳ２７００において利用者の公開鍵証明書の生成が完了した後、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は利用者装置１７０のＷｅｂブラウザプログラム９２０を用いて、認証局装置１３０から当該利用者の公開鍵証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０１９４】
前記証明書発行要求ステップＳ２３００において認証局装置１３０で利用者の公開鍵証明書の生成が完了したら、即時もしくは一定期間後に、証明書登録ステップを実施する（Ｓ２９００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該公開鍵証明書の登録要求を送信し、リポジトリ装置１４０内で当該公開鍵証明書を保存する。本ステップの詳細は、図３２にて例示する。但し、証明書発行要求ステップＳ２３００を省略した場合は、本ステップも省略する。
【０１９５】
また、前記証明書登録ステップＳ２９００と並行してもしくは当該ステップの実施後即時にもしくは当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）を送信し、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。本ステップの詳細は、図３３にて例示する。
【０１９６】
以上の手順によって、利用者が指定したＩＤを承認者が承認する処理と、当該ＩＤをサービス提供装置１５０に登録する処理と、当該ＩＤに基づく公開鍵証明書を発行する処理を、一連の流れで実施することが可能となり、利用者と承認者におけるＩＤ登録および公開鍵証明書発行に係る手間を軽減することが可能となる。
【０１９７】
図２０は、利用者がＩＤを削除、利用停止もしくは利用停止解除する場合の処理フローの概要を例示する図である。
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を使用してＩＤ管理装置１１０にアクセスし、ＩＤの削除、利用停止もしくは利用停止解除を行うためのメニューを選択し、削除、利用停止もしくは利用停止解除するＩＤを入力する。本ステップの詳細は、図２５にて例示する。
【０１９８】
前記メニュー選択・ＩＤ指定ステップＳ２１００にてＩＤの入力が完了した後、承認者宛メール送信ステップを実施する（Ｓ２４５０）。すなわち、ＩＤ管理装置１１０は、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を承認者に承認してもらう必要がある。このために、承認者のメールアドレスに対して承認手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０１９９】
前記承認者宛メール送信ステップＳ２４５０が完了すると、承認者宛メール受信ステップを実施する（Ｓ２６５０）。すなわち、承認者のメールアカウント宛には承認手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、承認者は、承認者装置１８０のメーラープログラム１０３０を利用してメールサーバ装置１２０にアクセスし、当該承認者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０２００】
前記承認者宛メール受信ステップＳ２６５０において承認手続きを行うためのアクセス先が記載されたメールを受信した承認者は、承認ステップを実施する（Ｓ３３００）。すなわち、承認者は、承認者装置１８０のＷｅｂブラウザプログラム１０２０を用いて、メールに記載されたアクセス先であるＩＤ管理装置１１０にアクセスして承認内容を確認し、承認可否をＩＤ管理装置１１０に送信する。本ステップの詳細は、図３４にて例示する。
【０２０１】
前記承認ステップＳ３３００が完了したら、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤに対して、ＩＤ管理装置１１０がサービス提供装置１５０のユーザ情報データベース７６０に反映するためのＩＤの削除要求、利用停止要求もしくは利用停止解除要求を送信する。
【０２０２】
本ステップの詳細は、図２６にて例示する。また、プロビジョニングの対象として、メールサーバ装置１２０のメールアカウントも含まれるのであれば、メールサーバ装置１２０のユーザ情報データベース４６０に対するＩＤの削除要求、利用停止要求もしくは利用停止解除要求も、本ステップで行うものとする。
【０２０３】
また、前記プロビジョニングステップＳ２２００と併せて、証明書失効要求ステップを実施する（Ｓ３１００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤをもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の失効要求、利用停止要求もしくは利用停止解除要求を送信し、認証局装置１３０にて証明書の失効情報を生成する。但し、失効情報の開示形態として、オンラインで証明書のステータスを回答するような形態をとる場合には、証明書の失効情報を生成する処理が、証明書のステータスを変更する処理に置き換わるものとする。本ステップの詳細は、図２７にて例示する。なお、プロビジョニングステップＳ２２００と証明書失効要求ステップＳ３１００の順序性は問わない。
【０２０４】
前記証明書失効ステップＳ３１００において認証局装置１３０で失効情報の生成が完了したら、即時もしくは一定期間後に、失効情報登録ステップを実施する（Ｓ３２００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該失効情報の登録要求を送信し、リポジトリ装置１４０内で当該失効情報を保存する。本ステップの詳細は、図３２にて例示する。
【０２０５】
また、前記失効情報登録ステップＳ３２００と並行してもしくは当該ステップの実施後即時にもしくは当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を失効した旨の完了通知（削除、利用停止もしくは利用停止解除の対象となったＩＤを含む）を送信する。そして、ＩＤ管理装置１１０内で完了通知時に送付された情報をもとに、ユーザ情報データベース３６０を削除もしくは変更等する。本ステップの詳細は、図３３にて例示する。
【０２０６】
以上の手順によって、利用者が指定したＩＤを承認者が承認する処理と、当該ＩＤをサービス提供装置１５０に対して削除、利用停止もしくは利用停止解除する処理と、当該ＩＤに基づく公開鍵証明書を失効、利用停止もしくは利用停止解除する処理を、一連の流れで実施することが可能となる。これにより、利用者と承認者におけるＩＤの削除、利用停止もしくは利用停止解除、および、公開鍵証明書の失効、利用停止もしくは利用停止解除に係る手間を軽減することが可能となる。
【０２０７】
図２１は、利用者がＩＤを変更する場合の処理フローの概要を例示する図である。また、公開鍵証明書に属性情報を記載する場合の属性の登録、変更、削除についても本処理フローに従うものとする。
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を使用してＩＤ管理装置１１０にアクセスし、ＩＤの変更を行うためのメニューを選択し、変更する前と後のＩＤを入力する。本ステップの詳細は、図２５にて例示する。属性の登録、変更もしくは削除時は、属性の登録、変更もしくは削除を行うためのメニューを選択し、登録、変更もしくは削除対象となるＩＤと属性を入力する。
【０２０８】
前記メニュー選択・ＩＤ指定ステップＳ２１００にてＩＤの入力が完了した後、続けて、鍵生成ステップを実施する（Ｓ２７００）。すなわち、利用者はＷｅｂの画面遷移に従ってＩＤ管理装置１１０もしくは認証局装置１３０にアクセスすることで鍵生成用の画面を取得する。そして、利用者装置１７０の鍵管理プログラム９４０を用いて利用者の秘密鍵及び公開鍵のペアを生成して公開鍵をアクセス先である当該ＩＤ管理装置１１０もしくは当該認証局装置１３０に送信する。公開鍵の送信先が認証局装置１３０の場合には、その後の画面遷移でＩＤ管理装置に戻るものとする。
【０２０９】
本ステップの詳細は、図３０にて例示する。但し、変更前のＩＤに対応した公開鍵証明書の公開鍵と変更後のＩＤに対応した公開鍵証明書の公開鍵を同じ値にする場合には、後記証明書発行要求ステップＳ２３００において、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信する情報の中に、変更前のＩＤに対応した公開鍵証明書の公開鍵を含めることによって、本ステップを省略できる。
【０２１０】
次に、前記鍵生成ステップＳ２７００が実施された後、承認者宛メール送信ステップを実施する（Ｓ２４５０）。すなわち、ＩＤ管理装置１１０は、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を承認者に承認してもらう必要がある。このために、承認者のメールアドレスに対して承認手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０２１１】
前記承認者宛メール送信ステップＳ２４５０が完了すると、承認者のメールアカウント宛には承認手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、承認者は、承認者装置１８０のメーラープログラム１０３０を利用してメールサーバ装置１２０にアクセスする。そして、当該承認者のメールアカウント宛に送信されたメールを取得するといった承認者宛メール受信ステップを実施する（Ｓ２６５０）。本ステップの詳細は、図２９にて例示する。
【０２１２】
前記承認者宛メール受信ステップＳ２６５０において承認手続きを行うためのアクセス先が記載されたメールを受信した承認者は、承認ステップを実施する（Ｓ３３００）。すなわち、承認者は、承認者装置１８０のＷｅｂブラウザプログラム１０２０を用いて、メールに記載されたアクセス先であるＩＤ管理装置１１０にアクセスして承認内容を確認し、承認可否をＩＤ管理装置１１０に送信する。本ステップの詳細は、図３４にて例示する。
【０２１３】
前記承認ステップＳ３３００が完了したら、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤに対して、ＩＤ管理装置１１０がサービス提供装置１５０のユーザ情報データベース７６０に反映するためのＩＤもしくは属性の変更要求を送信する。本ステップの詳細は、図２６にて例示する。また、プロビジョニングの対象として、メールサーバ装置１２０のメールアカウントも含まれるのであれば、メールサーバ装置１２０のユーザ情報データベース４６０に対するＩＤの変更要求も、本ステップで行うものとする。
【０２１４】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力された変更後のＩＤもしくは属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信する。そして、認証局装置１３０では要求された利用者の公開鍵証明書を生成する。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、後記証明書失効要求ステップＳ３１００と、本証明書発行要求ステップＳ２３００の順序性は問わない。
【０２１５】
さらに、前記プロビジョニングステップＳ２２００と併せて、証明書失効要求ステップを実施する（Ｓ３１００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力された変更前のＩＤをもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の失効要求を送信する。そして、認証局装置１３０にて証明書の失効情報を生成する。
【０２１６】
但し、失効情報の開示形態として、オンラインで証明書のステータスを回答するような形態をとる場合には、証明書の失効情報を生成する処理が、証明書のステータスを変更する処理に置き換わるものとする。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、前記証明書発行要求ステップＳ２３００と、本証明書失効要求ステップＳ３１００の順序性は問わない。
【０２１７】
前記証明書発行要求ステップＳ２３００において認証局装置１３０で利用者の公開鍵証明書の生成が完了したら、即時もしくは一定期間後に、証明書登録ステップを実施する（Ｓ２９００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該公開鍵証明書の登録要求を送信し、リポジトリ装置１４０内で当該公開鍵証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０２１８】
また、前記証明書失効ステップＳ３１００において認証局装置１３０で失効情報の生成が完了したら、即時もしくは一定期間後に、失効情報登録ステップを実施する（Ｓ３２００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該失効情報の登録要求を送信し、リポジトリ装置１４０内で当該失効情報を保存する。本ステップの詳細は、図３２にて例示する。
【０２１９】
プロビジョニングステップＳ２２００、証明書発行要求ステップＳ２３００及び証明書失効要求ステップＳ３１００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して変更後のＩＤに対応した証明書取得手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０２２０】
メール送信ステップＳ２４００が完了すると、利用者は変更後のＩＤを用いてメールを利用できるようになり、かつ、当該利用者のメールアカウント宛に証明書取得手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０及びメニュー選択・ＩＤ指定ステップＳ２１００にて入力したＩＤ及びパスワードを利用してメールサーバ装置１２０にアクセスする。そして、当該利用者のメールアカウント宛に送信されたメールを取得するといったメール受信ステップを実施する（Ｓ２６００）。本ステップの詳細は、図２９にて例示する。
【０２２１】
前記メール受信ステップＳ２６００において証明書取得手続きを行うためのアクセス先が記載されたメールを受信した利用者は、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザプログラム９２０を用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスする。そして、認証局装置１３０から当該利用者の公開鍵証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０２２２】
また、前記証明書登録ステップＳ２９００と並行してもしくは当該ステップの実施後即時にもしくは当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０は、ＩＤ管理装置１１０に変更後のＩＤに対する証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）及び変更前のＩＤに対する証明書を失効した旨の通知（失効の対象となったＩＤを含む）を送信する。
【０２２３】
そして、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。また、本ステップは、証明書の登録の完了通知と証明書の失効の完了通知を兼ねているが、これらは別々に実施してもよい。すなわち、前記証明書失効ステップＳ３２００と並行して、もしくは、当該ステップの実施後即時に、もしくは、当該ステップの実施後一定期間後に、変更前のＩＤに対する証明書を失効した旨の通知（失効の対象となったＩＤを含む）を送信してもよい。本ステップの詳細は、図３３にて例示する。
【０２２４】
以上の手順によって、利用者が指定したＩＤを承認者が承認する処理と、利用者が指定した変更前のＩＤをサービス提供装置１５０から削除する処理と、変更前のＩＤに基づく公開鍵証明書を失効する処理と、利用者が指定した変更後のＩＤをサービス提供装置１５０に登録する処理と、変更後のＩＤに基づく公開鍵証明書を発行する処理を、一連の流れで実施することが可能となる。これにより、利用者と承認者におけるＩＤ変更および公開鍵証明書再発行に係る手間を軽減することが可能となる。
【０２２５】
図２２は、利用者がＩＤを変更する場合の処理フローの概要を別の実施例にて例示する図である。また、公開鍵証明書に属性情報を記載する場合の属性の登録、変更、削除についても本処理フローに従うものとする。
【０２２６】
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を使用してＩＤ管理装置１１０にアクセスし、ＩＤの変更を行うためのメニューを選択し、変更する前と後のＩＤを入力する。本ステップの詳細は、図２５にて例示する。属性の登録、変更もしくは削除時は、属性の登録、変更もしくは削除を行うためのメニューを選択し、登録、変更もしくは削除対象となるＩＤと属性を入力する。
【０２２７】
前記メニュー選択・ＩＤ指定ステップＳ２１００にてＩＤの入力が完了した後、承認者宛メール送信ステップを実施する（Ｓ２４５０）。すなわち、ＩＤ管理装置１１０は、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を承認者に承認してもらう必要がある。このために、承認者のメールアドレスに対して承認手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０２２８】
前記承認者宛メール送信ステップＳ２４５０が完了すると、承認者宛メール受信ステップを実施する（Ｓ２６５０）。すなわち、承認者のメールアカウント宛には承認手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、承認者は、承認者装置１８０のメーラープログラム１０３０を利用してメールサーバ装置１２０にアクセスし、当該承認者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０２２９】
前記承認者宛メール受信ステップＳ２６５０において承認手続きを行うためのアクセス先が記載されたメールを受信した承認者は、承認ステップを実施する（Ｓ３３００）。すなわち、承認者は、承認者装置１８０のＷｅｂブラウザプログラム１０２０を用いて、メールに記載されたアクセス先であるＩＤ管理装置１１０にアクセスして承認内容を確認し、承認可否をＩＤ管理装置１１０に送信する。本ステップの詳細は、図３４にて例示する。
【０２３０】
前記承認ステップＳ３３００が完了したら、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤに対して、ＩＤ管理装置１１０がサービス提供装置１５０のユーザ情報データベース７６０に反映するためのＩＤもしくは属性の変更要求を送信する。本ステップの詳細は、図２６にて例示する。また、プロビジョニングの対象として、メールサーバ装置１２０のメールアカウントも含まれるのであれば、メールサーバ装置１２０のユーザ情報データベース４６０に対するＩＤの変更要求も、本ステップで行うものとする。
【０２３１】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力された変更後のＩＤもしくは属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信する。
【０２３２】
ここで、変更前のＩＤに対応した公開鍵証明書の公開鍵と変更後のＩＤに対応した公開鍵証明書の公開鍵を同じ値にする場合には、ＩＤ管理装置１１０が認証局装置１３０に証明書の発行要求を送信する情報の中に、変更前のＩＤに対応した公開鍵証明書の公開鍵を含めることによって、本ステップ内で公開鍵証明書を生成できる。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、後記証明書失効要求ステップＳ３１００と、本証明書発行要求ステップＳ２３００の順序性は問わない。
【０２３３】
さらに、前記プロビジョニングステップＳ２２００と併せて、証明書失効要求ステップを実施する（Ｓ３１００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力された変更前のＩＤをもとに、ＩＤ管理装置１１０が認証局装置１３０に証明書の失効要求を送信する。そして、認証局装置１３０にて証明書の失効情報を生成する。
【０２３４】
但し、失効情報の開示形態として、オンラインで証明書のステータスを回答するような形態をとる場合には、証明書の失効情報を生成する処理が、証明書のステータスを変更する処理に置き換わるものとする。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、前記証明書発行要求ステップＳ２３００と、本証明書失効要求ステップＳ３１００の順序性は問わない。
【０２３５】
前記証明書失効ステップＳ３１００において認証局装置１３０で失効情報の生成が完了したら、即時もしくは一定期間後に、失効情報登録ステップを実施する（Ｓ３２００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該失効情報の登録要求を送信し、リポジトリ装置１４０内で当該失効情報を保存する。本ステップの詳細は、図３２にて例示する。
【０２３６】
プロビジョニングステップＳ２２００、証明書発行要求ステップＳ２３００及び証明書失効要求ステップＳ３１００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して変更後のＩＤに対応した証明書発行手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０２３７】
メール送信ステップＳ２４００が完了すると、利用者は変更後のＩＤを用いてメールを利用できるようになり、かつ、当該利用者のメールアカウント宛に証明書発行手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０及びメニュー選択・ＩＤ指定ステップＳ２１００にて入力したＩＤ及びパスワードを利用してメールサーバ装置１２０にアクセスする。そして、当該利用者のメールアカウント宛に送信されたメールを取得するといったメール受信ステップを実施する（Ｓ２６００）。本ステップの詳細は、図２９にて例示する。
【０２３８】
前記メール受信ステップＳ２６００において証明書発行手続きを行うためのアクセス先が記載されたメールを受信した利用者は、鍵生成ステップを実施する（Ｓ２７００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザプログラム９２０を用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスすることで鍵生成用の画面を取得する。
【０２３９】
そして、利用者装置１７０の鍵管理プログラム９４０を用いて利用者の秘密鍵及び公開鍵のペアを生成して公開鍵をアクセス先である認証局装置１３０に送信する。そして、認証局装置１３０では当該利用者の公開鍵証明書を生成する。但し、前記証明書発行要求ステップ２３００において既に公開鍵証明書を生成している場合、本ステップは省略される。本ステップの詳細は、図３０にて例示する。
【０２４０】
前記鍵生成ステップＳ２７００もしくは前記証明書発行要求ステップ２３００において利用者の公開鍵証明書の生成が完了した後、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は利用者装置１７０のＷｅｂブラウザプログラム９２０を用いて、認証局装置１３０から当該利用者の公開鍵証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０２４１】
前記鍵生成ステップＳ２７００もしくは前記証明書発行要求ステップ２３００において認証局装置１３０で利用者の公開鍵証明書の生成が完了したら、即時もしくは一定期間後に、証明書登録ステップを実施する（Ｓ２９００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該公開鍵証明書の登録要求を送信し、リポジトリ装置１４０内で当該公開鍵証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０２４２】
前記証明書登録ステップＳ２９００と並行してもしくは当該ステップの実施後即時にもしくは当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０からＩＤ管理装置１１０へ変更後のＩＤに対する証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）及び変更前のＩＤに対する証明書を失効した旨の通知（失効の対象となったＩＤを含む）を送信する。
【０２４３】
そして、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。また、本ステップは、証明書の登録の完了通知と証明書の失効の完了通知を兼ねているが、これらは別々に実施してもよい。すなわち、前記証明書失効ステップＳ３２００と並行して、もしくは、当該ステップの実施後即時に、もしくは、当該ステップの実施後一定期間後に、変更前のＩＤに対する証明書を失効した旨の通知（失効の対象となったＩＤを含む）を送信してもよい。本ステップの詳細は、図３３にて例示する。
【０２４４】
以上の手順によって、利用者が指定したＩＤを承認者が承認する処理と、利用者が指定した変更前のＩＤをサービス提供装置１５０から削除する処理と、変更前のＩＤに基づく公開鍵証明書を失効する処理と、利用者が指定した変更後のＩＤをサービス提供装置１５０に登録する処理と、変更後のＩＤに基づく公開鍵証明書を発行する処理を、一連の流れで実施することが可能となり、利用者と承認者におけるＩＤ変更および公開鍵証明書再発行に係る手間を軽減することが可能となる。
【０２４５】
図２３は、利用者が属性情報を登録する場合の処理フローの概要を例示する図である。
但し、図２３は属性情報の表現に属性証明書を用いる場合を想定しており、属性情報の表現に公開鍵証明書を用いる場合は、図２１もしくは図２２の手順に従うものとする。
【０２４６】
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を使用してＩＤ管理装置１１０にアクセスし、属性の追加を行うためのメニューを選択し、その対象となるＩＤと追加する属性情報を入力する。本ステップの詳細は、図２５にて例示する。
【０２４７】
前記メニュー選択・ＩＤ指定ステップＳ２１００にてＩＤの入力が完了した後、承認者宛メール送信ステップを実施する（Ｓ２４５０）。すなわち、ＩＤ管理装置１１０は、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を承認者に承認してもらう必要がある。このために、承認者のメールアドレスに対して承認手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０２４８】
前記承認者宛メール送信ステップＳ２４５０が完了すると、承認者宛メール受信ステップを実施する（Ｓ２６５０）。すなわち、承認者のメールアカウント宛には承認手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、承認者は、承認者装置１８０のメーラープログラム１０３０を利用してメールサーバ装置１２０にアクセスし、当該承認者のメールアカウント宛に送信されたメールを取得する。本ステップの詳細は、図２９にて例示する。
【０２４９】
前記承認者宛メール受信ステップＳ２６５０において承認手続きを行うためのアクセス先が記載されたメールを受信した承認者は、承認ステップを実施する（Ｓ３３００）。すなわち、承認者は、承認者装置１８０のＷｅｂブラウザプログラム１０２０を用いて、メールに記載されたアクセス先であるＩＤ管理装置１１０にアクセスして承認内容を確認し、承認可否をＩＤ管理装置１１０に送信する。本ステップの詳細は、図３４にて例示する。
【０２５０】
前記承認ステップＳ３３００が完了したら、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性に対して、ＩＤ管理装置１１０がサービス提供装置１５０のユーザ情報データベース７６０に反映するための属性追加要求を送信する。本ステップの詳細は、図２６にて例示する。
【０２５１】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に属性証明書の発行要求を送信する。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、本証明書発行要求ステップＳ２３００の順序性は問わない。
【０２５２】
前記証明書発行ステップＳ２３００において認証局装置１３０で利用者の属性証明書の生成が完了したら、即時もしくは一定期間後に、証明書登録ステップを実施する（Ｓ２９００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該属性証明書の登録要求を送信し、リポジトリ装置１４０内で当該属性証明書を保存する。本ステップの詳細は、図３２にて例示する。
【０２５３】
プロビジョニングステップＳ２２００、証明書発行要求ステップＳ２３００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して証明書取得手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。
【０２５４】
但し、属性証明書の利用形態として、以下の場合には本ステップは省略してもよい。すなわち、属性証明書の保有者から属性証明書の検証者に属性証明書を提示するというプッシュ型ではなく、属性証明書の検証者がリポジトリ等の公開サーバに属性証明書を取りにいくというプル型の場合である。本ステップの詳細は、図２８にて例示する。
【０２５５】
メール送信ステップＳ２４００が実施された場合には、利用者は自身のメールアカウント宛に証明書取得手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０を利用してメールサーバ装置１２０にアクセスする。そして、当該利用者のメールアカウント宛に送信されたメールを取得するといったメール受信ステップを実施する（Ｓ２６００）。本ステップの詳細は、図２９にて例示する。
【０２５６】
前記メール受信ステップＳ２６００において証明書取得手続きを行うためのアクセス先が記載されたメールを受信した利用者は、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザを用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスする。そして、認証局装置１３０から属性証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０２５７】
一方、前記証明書登録ステップＳ２９００と並行して、もしくは、当該ステップの実施後即時に、もしくは、当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）を送信する。そして、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。本ステップの詳細は、図３３にて例示する。
【０２５８】
以上の手順によって、利用者が指定したＩＤに対する属性の追加を承認者が承認する処理と、当該ＩＤに対してサービス提供装置１５０に属性を追加する処理と、当該ＩＤに基づく属性証明書を発行する処理を、一連の流れで実施することが可能となり、利用者と承認者における属性追加および属性証明書発行に係る手間を軽減することが可能となる。
【０２５９】
図２４は、利用者が属性情報を変更もしくは削除する場合の処理フローの概要を例示する図である。但し、図２４は属性情報の表現に属性証明書を用いる場合を想定しており、属性情報の表現に公開鍵証明書を用いる場合は、図２１もしくは図２２の手順に従うものとする。
【０２６０】
はじめに、メニュー選択・ＩＤ指定ステップを実施する（Ｓ２１００）。すなわち、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を使用してＩＤ管理装置１１０にアクセスし、属性の変更もしくは削除を行うためのメニューを選択し、その対象となるＩＤと変更もしくは削除する属性情報を入力する。本ステップの詳細は、図２５にて例示する。
【０２６１】
前記メニュー選択・ＩＤ指定ステップＳ２１００にてＩＤの入力が完了した後、承認者宛メール送信ステップを実施する（Ｓ２４５０）。すなわち、ＩＤ管理装置１１０は、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び各種属性の内容を承認者に承認してもらう必要がある。このために、承認者のメールアドレスに対して承認手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。本ステップの詳細は、図２８にて例示する。
【０２６２】
前記承認者宛メール送信ステップＳ２４５０が完了すると、承認者のメールアカウント宛には承認手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、承認者は、承認者装置１８０のメーラープログラム１０３０を利用してメールサーバ装置１２０にアクセスし、当該承認者のメールアカウント宛に送信されたメールを取得する承認者宛メール受信ステップを実施する（Ｓ２６５０）。本ステップの詳細は、図２９にて例示する。
【０２６３】
前記承認者宛メール受信ステップＳ２６５０において承認手続きを行うためのアクセス先が記載されたメールを受信した承認者は、承認ステップを実施する（Ｓ３３００）。すなわち、承認者は、承認者装置１８０のＷｅｂブラウザプログラム１０２０を用いて、メールに記載されたアクセス先であるＩＤ管理装置１１０にアクセスして承認内容を確認し、承認可否をＩＤ管理装置１１０に送信する。本ステップの詳細は、図３４にて例示する。
【０２６４】
前記承認ステップＳ３３００が完了したら、プロビジョニングステップを実施する（Ｓ２２００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性に対して、ＩＤ管理装置１１０がサービス提供装置１５０のユーザ情報データベース７６０に反映するための属性追加要求を送信するといった本ステップの詳細は、図２６にて例示する。
【０２６５】
また、前記プロビジョニングステップＳ２２００と併せて、証明書発行要求ステップを実施する（Ｓ２３００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に属性証明書の発行要求を送信する。但し、属性の変更もしくは削除の内容に応じて、新たに属性証明書を発行する必要がない場合、本ステップは省略される。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、後記証明書失効要求ステップＳ３１００と、本証明書発行要求ステップＳ２３００の順序性は問わない。
【０２６６】
さらに、前記プロビジョニングステップＳ２２００と併せて、証明書失効要求ステップを実施する（Ｓ３１００）。すなわち、前記メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性をもとに、ＩＤ管理装置１１０が認証局装置１３０に属性証明書の失効要求を送信する。そして、認証局装置１３０にて属性証明書失効情報を生成する。但し、失効情報の開示形態として、オンラインで証明書のステータスを回答するような形態をとる場合には、属性証明書失効情報を生成する処理が、属性証明書のステータスを変更する処理に置き換わるものとする。
【０２６７】
ここで、どの属性証明書を失効するかは、メニュー選択・ＩＤ指定ステップＳ２１００において入力されたＩＤ及び属性と、図１２の説明にて記載したＩＤ管理装置１１０内のユーザ情報データベース３６０内の証明書情報３６２である証明書のＩＤとその記載属性型を比較して合致したものが選択されるものとする。本ステップの詳細は、図２７にて例示する。なお、前記プロビジョニングステップＳ２２００と、前記証明書発行要求ステップＳ２３００と、本証明書失効要求ステップＳ３１００の順序性は問わない。
【０２６８】
前記証明書発行ステップＳ２３００が実施され、認証局装置１３０で利用者の属性証明書の生成が完了した場合には、即時もしくは一定期間後に、証明書登録ステップを実施する（Ｓ２９００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該属性証明書の登録要求を送信し、リポジトリ装置１４０内で当該属性証明書を保存する。本ステップの詳細は、図３２にて例示する。但し、証明書発行要求ステップＳ２３００を省略した場合は、本ステップも省略する。
【０２６９】
また、前記証明書失効ステップＳ３１００において認証局装置１３０で属性証明書失効情報の生成が完了したら、即時もしくは一定期間後に、失効情報登録ステップを実施する（Ｓ３２００）。すなわち、認証局装置１３０はリポジトリ装置１４０に対して、当該失効情報の登録要求を送信し、リポジトリ装置１４０内で当該失効情報を保存する。本ステップの詳細は、図３２にて例示する。
【０２７０】
プロビジョニングステップＳ２２００、証明書発行要求ステップＳ２３００及び証明書失効要求ステップＳ３１００が完了すると、メール送信ステップを実施する（Ｓ２４００）。すなわち、ＩＤ管理装置１１０は、ＩＤの利用者のメールアドレスに対して証明書取得手続きを行うためのアクセス先が記載されたメールを、メールサーバ装置１２０に送信する。但し、属性証明書の利用形態として、以下の場合には本ステップは省略してもよい。すなわち、属性証明書の保有者から属性証明書の検証者に属性証明書を提示するというプッシュ型ではなく、属性証明書の検証者がリポジトリ等の公開サーバに属性証明書を取りにいくというプル型の場合である。本ステップの詳細は、図２８にて例示する。
【０２７１】
メール送信ステップＳ２４００が実施された場合には、利用者は自身のメールアカウント宛に証明書取得手続きを行うためのアクセス先が記載されたメールが届いている状態になる。このため、利用者は、利用者装置１７０のメーラープログラム９３０を利用してメールサーバ装置１２０にアクセスし、当該利用者のメールアカウント宛に送信されたメールを取得するメール受信ステップを実施する（Ｓ２６００）。本ステップの詳細は、図２９にて例示する。
【０２７２】
前記メール受信ステップＳ２６００において証明書取得手続きを行うためのアクセス先が記載されたメールを受信した利用者は、証明書取得ステップを実施する（Ｓ２８００）。すなわち、利用者は、利用者装置１７０のＷｅｂブラウザを用いて、メールに記載されたアクセス先である認証局装置１３０にアクセスし、認証局装置１３０から属性証明書をダウンロードし、利用者装置１７０内に保存する。本ステップの詳細は、図３１にて例示する。
【０２７３】
一方、前記証明書登録ステップＳ２９００と並行して、もしくは、当該ステップの実施後即時に、もしくは、当該ステップの実施後一定期間後に、完了通知ステップを実施する（Ｓ３０００）。すなわち、認証局装置１３０はＩＤ管理装置１１０に対して、利用者の証明書を発行した旨の完了通知（当該証明書の発行者名、シリアル番号および記載した属性の型等を含む）を送信する。そして、ＩＤ管理装置１１０内で完了通知時に送付された情報をユーザ情報データベース３６０に保存する。本ステップの詳細は、図３３にて例示する。
【０２７４】
以上の手順によって、利用者が指定したＩＤに対する属性の変更もしくは削除を承認者が承認する処理と、当該ＩＤに対してサービス提供装置１５０に属性を変更もしくは削除する処理と、当該ＩＤに基づく属性証明書を失効もしくは再発行する処理を、一連の流れで実施することが可能となる。これにより、管理者における属性変更もしくは削除および属性証明書失効もしくは再発行に係る手間を軽減することが可能となる。
【０２７５】
図２５は、メニュー選択・ＩＤ指定ステップにおける処理フローの詳細を例示する図である。ここでは、メニューの選択やＩＤの指定を行う側である管理者装置１６０もしくは利用者装置１７０と、選択されたメニューや指定されたＩＤを受け付ける側のＩＤ管理装置１１０との間の処理手順について示す。
【０２７６】
はじめに、メニューの選択やＩＤの指定を行う者が管理者である場合は、管理者が管理者装置１６０のＷｅｂブラウザプログラム８２０を起動する。メニューの選択やＩＤの指定を行う者が利用者である場合は、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を起動する（Ｓ２１０１）。
【０２７７】
次に、管理者もしくは利用者は、前記ステップＳ２１０１において起動したＷｅｂブラウザプログラムに、ＩＤ管理装置１１０が提供するＩＤ管理サービスのＵＲＬ（Uniform Resource Locator）を入力し、ＩＤ管理装置１１０にアクセスする（Ｓ２１０２）。
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ２１０２において送信されたアクセス要求を受信する（Ｓ２１０３）。
【０２７８】
続けて、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、アクセス要求を送信してきた管理者装置１６０もしくは利用者装置１７０に対して、ＩＤ管理サービスのトップ画面データを返信する（Ｓ２１０４）。トップ画面データには、ＩＤ及びパスワード等の認証情報を入力する欄が含まれているものとする。
【０２７９】
本実施の形態例では、ＩＤ及びパスワードを用いた認証方法について例示するが、当該認証方法は既知の認証方法に置き換えてもよく、認証方法をＩＤ及びパスワードに限定するものではない。また、利用者がＩＤ管理を行うシステムとする場合、トップ画面データには、利用者がＩＤを登録するためのメニューも存在するものとする。
【０２８０】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１０４においてＩＤ管理装置１１０が送信してきたトップ画面データを受信し、管理者もしくは利用者に対してトップ画面を表示する（Ｓ２１０５）。この後、利用者がＩＤの登録を行う場合は、利用者がＩＤを登録するためのメニューを選択することで、後記Ｓ２１１２に遷移する。利用者がＩＤの登録を行う場合以外については、管理者もしくは利用者が、ＩＤ及びパスワード等の認証情報を入力することで、次のステップＳ２１０６に遷移する。
【０２８１】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２１０５にて入力された認証情報をＩＤ管理装置１１０に送信する（Ｓ２１０６）。
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ２１０６において送信された認証情報を受信する（Ｓ２１０７）。
【０２８２】
ＩＤ管理装置１１０のユーザ認証プログラム３２０は、前記ステップＳ２１０７において受信した認証情報と、アクセス制御データ３６０もしくはユーザ情報データベース３７０内に保存されている認証情報とを用いて、ユーザの認証を行う（Ｓ２１０８）。Ｓ２１０８でユーザの認証に失敗した場合は、認証に失敗した旨の表示を行う画面データを管理者装置１６０もしくは利用者装置１７０に送信し、後記Ｓ２１０９に遷移する。Ｓ２１０８でユーザの認証に成功した場合には、そのまま後記Ｓ２１１０に遷移する。
【０２８３】
Ｓ２１０８でユーザ認証に失敗した場合、管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１０８においてＩＤ管理装置１１０が送信してきた画面データを受信し、管理者もしくは利用者に対して認証に失敗した旨の表示を行い、処理を中断する（Ｓ２１０９）。
【０２８４】
Ｓ２１０８ユーザ認証に成功した場合、当該ユーザに応じたメニュー画面データを管理者装置１６０もしくは利用者装置１７０に送信する（Ｓ２１１０）。認証したユーザが管理者権限であった場合には、管理者用のＩＤ管理メニューが表示され、認証したユーザが利用者権限であった場合には、利用者用のＩＤ管理メニューが表示されるものとする。メニュー画面には、ＩＤの登録、ＩＤの削除、ＩＤの利用停止、ＩＤの利用停止解除、ＩＤの変更、属性の追加、属性の削除、属性の変更といったメニューの全部もしくは一部が存在するものとする。
【０２８５】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１０８においてＩＤ管理装置１１０が送信してきたメニュー画面データを受信し、管理者もしくは利用者に対してメニュー画面を表示する（Ｓ２１１１）。この後、管理者もしくは利用者がメニューを選択することで、後記Ｓ２１１２に遷移する。
【０２８６】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１１１もしくは前記ステップＳ２１０５において、管理者もしくは利用者が選択したメニューの内容を、ＩＤ管理装置１１０に送信する（Ｓ２１１２）。
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ２１１２において送信されたメニューの内容を受信する（Ｓ２１１３）。
【０２８７】
続けて、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、管理者装置１６０もしくは利用者装置１７０に対して、前記ステップＳ２１１３にて受信したメニューの内容に応じた入力画面データを返信する（Ｓ２１１４）。入力画面データには、対象となるＩＤや当該ＩＤに付随する属性値等を入力する欄が含まれているものとする。
【０２８８】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１１４においてＩＤ管理装置１１０が送信してきた入力画面データを受信し、管理者もしくは利用者に対して入力画面を表示する（Ｓ２１１５）。この後、管理者もしくは利用者が入力画面に必要な情報を入力することで、後記Ｓ２１１６に遷移する。
【０２８９】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１１５において、管理者もしくは利用者が入力した各種情報を、ＩＤ管理装置１１０に送信する（Ｓ２１１６）。
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ２１１６において送信された入力情報を受信する（Ｓ２１１７）。
【０２９０】
続けて、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ２１１７にて受信した入力情報に基づく確認画面データを生成し、管理者装置１６０もしくは利用者装置１７０に対して、当該確認画面データを返信する（Ｓ２１１８）。
【０２９１】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１１８においてＩＤ管理装置１１０が送信してきた確認画面データを受信し、管理者もしくは利用者に対して確認画面を表示する（Ｓ２１１９）。この後、管理者もしくは利用者が確認画面に対する内容の是非を判断した結果を入力することで、後記Ｓ２１２０に遷移する。
【０２９２】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１１９において、管理者もしくは利用者が入力した確認結果情報を、ＩＤ管理装置１１０に送信する（Ｓ２１２０）。
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ２１２０において送信された確認結果情報を受信する（Ｓ２１２１）。
【０２９３】
続けて、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ２１２１にて受信した確認結果情報を判定する（Ｓ２１２２）。Ｓ２１２２の判定結果が確認画面の内容を了承した旨のものであった場合には、後記ステップＳ２１２３に遷移する。Ｓ２１２２の判定結果が確認画面の内容を了承しない旨のものであった場合には、管理者装置１６０もしくは利用者装置１７０に対して、前記ステップＳ２１１５における入力画面を返信する。当該入力画面には、前記ステップＳ２１１７で受信した入力情報を入力欄に含めて修正画面データのような形態でデータを返信してもよい。
【０２９４】
Ｓ２１２２の判定結果で確認画面の内容が了承されたと判断した場合、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、図１３から図２４におけるメニュー選択・ＩＤ指定ステップＳ２１００の次のステップに処理を遷移させるとともに、前記ステップＳ２１１７にて受信した入力情報に基づく受付結果等の画面データを生成し、管理者装置１６０もしくは利用者装置１７０に対して、当該画面データを返信する（Ｓ２１２３）。
【０２９５】
管理者装置１６０もしくは利用者装置１７０のＷｅｂブラウザプログラムは、前記ステップＳ２１１８においてＩＤ管理装置１１０が送信してきた受付結果等が記載された画面データを受信し、管理者もしくは利用者に対して当該画面を表示する（Ｓ２１１９）。
以上で、管理者装置１６０もしくは利用者装置１７０と、ＩＤ管理装置１１０との間で実施されるメニュー選択・ＩＤ指定ステップＳ２１００の処理が完了する。
【０２９６】
図２６は、プロビジョニングステップにおける処理フローの詳細を例示する図である。ここでは、ユーザ情報の展開元であるＩＤ管理装置１１０と、ユーザ情報の展開先であるサービス提供装置１５０との間の処理手順について示す。プロビジョニングの対象となるサービス提供装置１５０が複数存在する場合には、サービス提供装置１５０毎に本処理手順が実施される。
【０２９７】
はじめに、ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、プロビジョニングの対象となるサービス提供装置１５０に対して、接続要求を送信する（Ｓ２２０１）。
サービス提供装置１５０のアカウント管理プログラム７３０は、前記ステップＳ２２０１において送信された接続要求を受信する（Ｓ２２０２）。
【０２９８】
続けて、サービス提供装置１５０のアカウント管理プログラム７３０は、接続要求を送信してきたＩＤ管理装置１１０に対して、認証情報を要求するメッセージを返信する（Ｓ２２０３）。本実施の形態例では、ＩＤ及びパスワードを用いた認証方法を採用するものとし、ここではＩＤ及びパスワードを要求するメッセージを返信する。但し、ここでの認証方法は既知の認証方法に置き換えてもよく、認証方法をＩＤ及びパスワードに限定するものではない。
【０２９９】
ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、前記ステップＳ２２０３においてサービス提供装置１５０が送信してきた認証要求を受信する（Ｓ２２０４）。
続いて、ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、サービス提供装置１５０にアクセスするための認証情報であるＩＤ及びパスワードを、サービス提供装置１５０に送信する（Ｓ２２０５）。ここで、サービス提供装置１５０にアクセスするための認証情報は、あらかじめＩＤ管理装置１１０内に設定されているものとする。
【０３００】
サービス提供装置１５０のアカウント管理プログラム７３０は、前記ステップＳ２２０５において送信された認証情報を受信する（Ｓ２２０６）。
サービス提供装置１５０のユーザ認証プログラム７２０は、前記ステップＳ２２０６において受信した認証情報と、アクセス制御データ７５０内に保存されている認証情報とを用いて、ユーザの認証を行う（Ｓ２２０７）。Ｓ２２０７でユーザの認証に失敗した場合は、認証に失敗した旨の結果をＩＤ管理装置１１０に送信し、後記Ｓ２２０８に遷移する。Ｓ２２０７でユーザの認証に成功した場合には、そのまま後記Ｓ２２０９に遷移する。
【０３０１】
Ｓ２２０７でユーザ認証に失敗した場合、ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、前記ステップＳ２２０７においてサービス提供装置１５０が送信してきた結果を受信し（Ｓ２２０８）、認証に失敗した旨の判断を行い、処理を中断する。
Ｓ２２０７でユーザ認証に成功した場合、サービス提供装置１５０のアカウント管理プログラム７３０は、サービス提供装置１５０側で実行するためのコマンドを要求するために、ＩＤ管理装置１１０にコマンド要求を送信する（Ｓ２２０９）。
【０３０２】
ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、前記ステップＳ２２０９においてサービス提供装置１５０が送信してきたコマンド要求を受信する（Ｓ２２１０）。
ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、上述したメニュー選択・ＩＤ指定ステップＳ２１００において選択されたメニューに応じて適切なコマンドをサービス提供装置１５０に送信する（Ｓ２２１１）。例えば、メニュー選択・ＩＤ指定ステップＳ２１００においてＩＤの登録が選択された場合には、ＩＤを登録する旨のコマンドと登録するＩＤの値等を送信する。
【０３０３】
サービス提供装置１５０のアカウント管理プログラム７３０は、前記ステップＳ２２１１において送信されたコマンドを受信する（Ｓ２２１２）。
次に、サービス提供装置１５０のアカウント管理プログラム７３０は、前記ステップ２２１２において受信したコマンドを実行する（Ｓ２２１３）。例えば、前記ステップ２２１２においてＩＤを登録する旨のコマンドと登録するＩＤの値等が送信されてきた場合、サービス提供装置１５０内のユーザ情報データベース７６０に、送信されてきたＩＤを登録し、当該ＩＤを用いて業務サービスプログラム７４０が利用できるようにする。
【０３０４】
続けて、サービス提供装置１５０のアカウント管理プログラム７３０は、前記ステップＳ２２１３においてコマンドを実行した結果を、ＩＤ管理装置１１０に対して返信する（Ｓ２２１４）。
ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、前記ステップＳ２２１４においてサービス提供装置１５０が送信してきたコマンド実行結果を受信する（Ｓ２２１５）。
以上で、ＩＤ管理装置１１０とサービス提供装置１５０との間で実施されるプロビジョニングステップＳ２２００の処理が完了する。
【０３０５】
図２７は、証明書発行要求ステップあるいは証明書失効要求ステップにおける処理フローの詳細を例示する図である。ここでは、証明書の発行あるいは失効の要求元であるＩＤ管理装置１１０と、証明書の発行あるいは失効を実施する認証局装置１３０との間の処理手順について示す。証明書の発行あるいは失効の対象となる認証局装置１３０が複数存在する場合には、認証局装置１３０毎に本処理手順が実施される。
【０３０６】
はじめに、ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、証明書の発行あるいは失効の対象となる認証局装置１３０に対して、接続要求を送信する（Ｓ２３０１）。
認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ２３０１において送信された接続要求を受信する（Ｓ２３０２）。
【０３０７】
続けて、認証局装置１３０の証明書管理プログラム５３０は、接続要求を送信してきたＩＤ管理装置１１０に対して、認証情報を要求するメッセージを返信する（Ｓ２３０３）。本実施の形態例では、ＩＤ及びパスワードを用いた認証方法を採用するものとし、ここではＩＤ及びパスワードを要求するメッセージを返信する。但し、ここでの認証方法は既知の認証方法に置き換えてもよく、認証方法をＩＤ及びパスワードに限定するものではない。
【０３０８】
ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、前記ステップＳ２３０３において認証局装置１３０が送信してきた認証要求を受信する（Ｓ２３０４）。
続いて、ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、認証局装置１３０にアクセスするための認証情報であるＩＤ及びパスワードを、認証局装置１３０に送信する（Ｓ２３０５）。ここで、認証局装置１３０にアクセスするための認証情報は、あらかじめＩＤ管理装置内に設定されているものとする。
【０３０９】
認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ２３０５において送信された認証情報を受信する（Ｓ２３０６）。
認証局装置１３０のユーザ認証プログラム５２０は、前記ステップＳ２３０６において受信した認証情報と、アクセス制御データ５５０内に保存されている認証情報とを用いて、ユーザの認証を行う（Ｓ２３０７）。Ｓ２３０７でユーザの認証に失敗した場合は、認証に失敗した旨の結果をＩＤ管理装置１１０に送信し、後記Ｓ２３０８に遷移する。Ｓ２３０７でユーザの認証に成功した場合には、そのまま後記Ｓ２３０９に遷移する。
【０３１０】
Ｓ２３０７でユーザ認証に失敗した場合、ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、前記ステップＳ２３０７において認証局装置１３０が送信してきた結果を受信し（Ｓ２３０８）、認証に失敗した旨の判断を行い、処理を中断する。
Ｓ２３０７でユーザ認証に成功した場合、認証局装置１３０の証明書管理プログラム５３０は、認証局装置１３０で実行するためのコマンドを要求するために、ＩＤ管理装置１１０にコマンド要求を送信する（Ｓ２３０９）。
【０３１１】
ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、前記ステップＳ２３０９において認証局装置１３０が送信してきたコマンド要求を受信する（Ｓ２３１０）。
ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、上述したメニュー選択・ＩＤ指定ステップＳ２１００において選択されたメニューに応じて適切なコマンドを認証局装置１３０に送信する（Ｓ２３１１）。例えば、メニュー選択・ＩＤ指定ステップＳ２１００においてＩＤの登録が選択された場合には、公開鍵証明書を発行する旨のコマンドと公開鍵証明書の発行に必要なユーザ情報（ＩＤ、属性、公開鍵等）を送信する。
【０３１２】
認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ２３１１において送信されたコマンドを受信する（Ｓ２３１２）。
次に、認証局装置１３０の証明書管理プログラム５３０は、前記ステップ２３１２において受信したコマンドを実行する（Ｓ２３１３）。例えば、前記ステップ２３１２において公開鍵証明書を発行する旨のコマンドと発行に必要なユーザ情報が送信されてきた場合、当該ユーザ情報を保存しておき、公開鍵が送付されてきた時点で公開鍵証明書を生成できるように準備する。ユーザ情報内に公開鍵が含まれている場合には、当該ユーザ情報を用いて利用者の公開鍵証明書を生成までを行う。
【０３１３】
続けて、認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ２３１３においてコマンドを実行した結果を、ＩＤ管理装置１１０に対して返信する（Ｓ２３１４）。
ＩＤ管理装置１１０のプロビジョニングプログラム３４０は、前記ステップＳ２３１４において認証局装置１３０が送信してきたコマンド実行結果を受信する（Ｓ２３１５）。
【０３１４】
以上で、ＩＤ管理装置１１０と認証局装置１３０との間で実施される証明書発行要求ステップＳ２３００もしくは証明書失効要求ステップＳ３１００の処理が完了する。なお、証明書発行要求ステップＳ２３００と証明書失効要求ステップＳ３１００が連続して実施される場合、後で実施されるステップは、先に実施されたステップに続けて、Ｓ２３１１に遷移するものとし、Ｓ２３０１からＳ２３１０までの認証を行う処理を省略してもよい。
【０３１５】
図２８は、メール送信ステップにおける処理フローの詳細を例示する図である。ここでは、メールの送信元であるＩＤ管理装置１１０と、メールの管理先であるメールサーバ装置１２０との間の処理手順について示す。
はじめに、ＩＤ管理装置１１０のメール送信プログラム３５０は、メールサーバ装置１２０に対して、接続要求を送信する（Ｓ２４０１）。
メールサーバ装置１２０のメール管理プログラム４４０は、前記ステップＳ２４０１において送信された接続要求を受信する（Ｓ２４０２）。
【０３１６】
続けて、メールサーバ装置１２０のメール管理プログラム４４０は、接続要求を送信してきたＩＤ管理装置１１０に対して、認証情報を要求するメッセージを返信する（Ｓ２４０３）。本実施の形態例では、ＩＤ及びパスワードを用いた認証方法を採用するものとし、ここではＩＤ及びパスワードを要求するメッセージを返信する。但し、ここでの認証方法は既知の認証方法に置き換えてもよく、認証方法をＩＤ及びパスワードに限定するものではない。また、但し、メール送信に使用するプロトコルにおいて認証を必要としないものを採用する場合には、本ステップＳ２４０３からＳ２４０７までの手順が省略され、後記ステップＳ２４０９に遷移するものとする。
【０３１７】
ＩＤ管理装置１１０のメール送信プログラム３５０は、前記ステップＳ２４０３においてメールサーバ装置１２０が送信してきた認証要求を受信する（Ｓ２４０４）。
続いて、ＩＤ管理装置１１０のメール送信プログラム３５０は、メールサーバ装置１２０にアクセスするための認証情報であるＩＤ及びパスワードを、メールサーバ装置１２０に送信する（Ｓ２４０５）。ここで、メールサーバ装置１２０にアクセスするための認証情報は、あらかじめＩＤ管理装置内に設定されているものとする。
【０３１８】
メールサーバ装置１２０のメール管理プログラム４４０は、前記ステップＳ２４０５において送信された認証情報を受信する（Ｓ２４０６）。
メールサーバ装置１２０のユーザ認証プログラム４２０は、前記ステップＳ２４０６において受信した認証情報と、アクセス制御データ４５０もしくはユーザ情報データベース４６０内に保存されている認証情報とを用いて、ユーザの認証を行う（Ｓ２４０７）。Ｓ２４０７でユーザの認証に失敗した場合は、認証に失敗した旨の結果をＩＤ管理装置１１０に送信し、後記Ｓ２４０８に遷移する。Ｓ２４０７でユーザの認証に成功した場合には、そのまま後記Ｓ２４０９に遷移する。
【０３１９】
Ｓ２４０７でユーザ認証に失敗した場合、ＩＤ管理装置１１０のメール送信プログラム３５０は、前記ステップＳ２４０７においてメールサーバ装置１２０が送信してきた結果を受信し（Ｓ２４０８）、認証に失敗した旨の判断を行い、処理を中断する。
Ｓ２４０７でユーザ認証に成功した場合、メールサーバ装置１２０のメール管理プログラム４４０は、メールサーバ装置１２０側で実行するためのコマンドを要求するために、ＩＤ管理装置１１０にコマンド要求を送信する（Ｓ２４０９）。
【０３２０】
ＩＤ管理装置１１０のメール送信プログラム３５０は、前記ステップＳ２４０９においてメールサーバ装置１２０が送信してきたコマンド要求を受信する（Ｓ２４１０）。
ＩＤ管理装置１１０のメール送信プログラム３５０は、上述したメニュー選択・ＩＤ指定ステップＳ２１００において選択されたメニュー及び本メール送信ステップＳ２４００を実施する以前のステップにおいて実施された処理内容に応じて適切な、メール送信用のコマンド群をメールサーバ装置１２０に送信する（Ｓ２４１１）。
【０３２１】
例えば、メニュー選択・ＩＤ指定ステップＳ２１００において管理者がＩＤの登録を選択し、利用者による鍵生成ステップＳ２７００が実施されていない場合には、利用者のメールアカウント宛にメールを送信する一連のコマンド群と、当該メールの本文に、公開鍵証明書の発行手続きを行うための手順及びＵＲＬ等を記載した内容を送信する。また、ＵＲＬの一部等に、ユーザを認証するための情報（例えば、ユーザのＩＤに結びつくように割りあてられた乱数）を付与し、ユーザのＩＤとユーザを認証するための情報は、ＩＤ管理装置１１０に保存しておく。
【０３２２】
メールサーバ装置１２０のメール管理プログラム４４０は、前記ステップＳ２４１１において送信されたコマンドを受信する（Ｓ２４１２）。
次に、メールサーバ装置１２０のメール管理プログラム４４０は、前記ステップ２４１２において受信したメール送信コマンド群に基づいて、指定されたメールアカウントにメールを送信する（Ｓ２４１３）。
【０３２３】
本実施の形態例では、簡単のため、当該メールサーバ装置１２０内に指定されたメールアカウントがあるものとした。例えば、前記ステップ２４１２において利用者のメールアカウント宛にメールを送信する一連のコマンド群と、当該メールの本文に、公開鍵証明書の発行手続きを行うための手順及びＵＲＬ等を記載した内容が送信されてきたとする。この場合、メールサーバ装置１２０内のアカウント別メールボックス４７０に、送信されてきたメールを保存する。
【０３２４】
続けて、メールサーバ装置１２０のメール管理プログラム４４０は、前記ステップＳ２４１３においてメール送信のコマンドを実行した結果を、ＩＤ管理装置１１０に対して返信する（Ｓ２４１４）。
ＩＤ管理装置１１０のメール送信プログラム３５０は、前記ステップＳ２４１４においてメールサーバ装置１２０が送信してきたコマンド実行結果を受信する（Ｓ２４１５）。
以上で、ＩＤ管理装置１１０とメールサーバ装置１２０との間で実施されるメール送信ステップＳ２４００もしくは承認者宛メール送信ステップＳ２４５０の処理が完了する。
【０３２５】
図２９は、メール受信ステップにおける処理フローの詳細を例示する図である。ここでは、メールの受信先である利用者装置１７０もしくは承認者装置１８０と、メールの管理先であるメールサーバ装置１２０との間の処理手順について示す。
【０３２６】
はじめに、利用者装置１７０のメーラープログラム９３０もしくは承認者装置１８０のメーラープログラム１０３０（以下、メール受信側のメーラープログラムと呼ぶ）は、メールサーバ装置１２０に対して、接続要求を送信する（Ｓ２６０１）。
メールサーバ装置１２０のメール管理プログラム４４０は、前記ステップＳ２６０１において送信された接続要求を受信する（Ｓ２６０２）。
【０３２７】
続けて、メールサーバ装置１２０のメール管理プログラム４４０は、接続要求を送信してきた利用者装置１７０もしくは承認者装置１８０（以下、メール受信側の装置と呼ぶ）に対して、認証情報を要求するメッセージを返信する（Ｓ２６０３）。本実施の形態例では、ＩＤ及びパスワードを用いた認証方法を採用するものとし、ここではＩＤ及びパスワードを要求するメッセージを返信する。但し、ここでの認証方法は既知の認証方法に置き換えてもよく、認証方法をＩＤ及びパスワードに限定するものではない。
【０３２８】
メール受信側のメーラープログラム１０３０は、前記ステップＳ２６０３においてメールサーバ装置１２０が送信してきた認証要求を受信する（Ｓ２６０４）。
続いて、メール受信側のメーラープログラム１０３０は、メールサーバ装置１２０にアクセスするための認証情報であるＩＤ及びパスワードを、メールサーバ装置１２０に送信する（Ｓ２６０５）。ここで、メールサーバ装置１２０にアクセスするための認証情報は、あらかじめメール受信側の装置内に設定されているものとする。
【０３２９】
メールサーバ装置１２０のメール管理プログラム４４０は、前記ステップＳ２６０５において送信された認証情報を受信する（Ｓ２６０６）。
メールサーバ装置１２０のユーザ認証プログラム４２０は、前記ステップＳ２６０６において受信した認証情報と、ユーザ情報データベース４６０内に保存されている認証情報とを用いて、ユーザの認証を行う（Ｓ２６０７）。Ｓ２６０７でユーザの認証に失敗した場合は、認証に失敗した旨の結果をメール受信側の装置に送信し、後記Ｓ２６０８に遷移する。Ｓ２６０７でユーザの認証に成功した場合には、そのまま後記Ｓ２６０９に遷移する。
【０３３０】
Ｓ２６０７でユーザ認証に失敗した場合、メール受信側のメーラープログラム１０３０は、前記ステップＳ２６０７においてメールサーバ装置１２０が送信してきた結果を受信し（Ｓ２６０８）、認証に失敗した旨の判断を行い、処理を中断する。
Ｓ２６０７でユーザ認証に成功した場合、メールサーバ装置１２０のメール管理プログラム４４０は、メールサーバ装置１２０側で実行するためのコマンドを要求するために、メール受信側の装置にコマンド要求を送信する（Ｓ２６０９）。
【０３３１】
メール受信側のメーラープログラム１０３０は、前記ステップＳ２６０９においてメールサーバ装置１２０が送信してきたコマンド要求を受信する（Ｓ２６１０）。
メール受信側のメーラープログラム１０３０は、メール受信用のコマンド群をメールサーバ装置１２０に送信する（Ｓ２６１１）。
メールサーバ装置１２０のメール管理プログラム４４０は、前記ステップＳ２６１１において送信されたコマンドを受信する（Ｓ２６１２）。
【０３３２】
次に、メールサーバ装置１２０のメール管理プログラム４４０は、メールをメール受信側の装置に対して返信する（Ｓ２６１３）。このメールは、前記ステップＳ２６１２において受信したメール受信コマンド群を受けて、アカウント別メールボックス４７０内で保存されている、前記ステップＳ２６０７において認証されたユーザのメールアカウント宛のメールである。
【０３３３】
メール受信側のメーラープログラム１０３０は、前記ステップＳ２６１３においてメールサーバ装置１２０が送信してきたコマンド実行結果を受信する（Ｓ２６１４）。
以上で、メール受信側の装置とメールサーバ装置１２０との間で実施されるメール受信ステップＳ２６００もしくは承認者宛メール受信ステップＳ２６５０の処理が完了する。
【０３３４】
図３０は、鍵生成ステップにおける処理フローの詳細を例示する図である。ここでは、鍵ペアの生成を行う側である利用者装置１７０と、利用者の公開鍵を受け付ける側のＩＤ管理装置１１０もしくは認証局装置１３０との間の処理手順について示す。
はじめに、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を起動する（Ｓ２７０１）。但し、本鍵生成ステップの直前に上述したメニュー選択・ＩＤ指定ステップＳ２１００を実施しており、既にＷｅｂブラウザプログラム９２０が起動している場合には、本ステップＳ２７０１は省略される。
【０３３５】
次に、利用者は、起動したＷｅｂブラウザプログラム９２０を用いて、ＩＤ管理装置１１０もしくは認証局装置１３０（以下、公開鍵を受け付ける装置）が提供する鍵生成用のＵＲＬにアクセスする。この、アクセス要求には、ユーザを認証するための情報（例えば、ユーザのＩＤに結びつくように割りあてられた乱数）も含まれているものとする（Ｓ２７０２）。
【０３３６】
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０もしくは認証局装置１３０の証明書管理プログラム５３０（以下、公開鍵を受け付ける装置側のプログラムと呼ぶ）は、前記ステップＳ２７０２において送信されたアクセス要求を受信する（Ｓ２７０３）。
【０３３７】
公開鍵を受け付ける装置側のユーザ認証プログラムは、前記ステップＳ２７０３において受信した要求内に含まれる認証情報と、図２８の説明におけるステップＳ２４１１において保存した認証情報とを用いて、ユーザの認証を行う（Ｓ２７０４）。Ｓ２７０４でユーザの認証に失敗した場合は、認証に失敗した旨の表示を行う画面データを利用者装置１７０に送信し、後記Ｓ２７０５に遷移する。Ｓ２７０４でユーザの認証に成功した場合には、そのまま後記Ｓ２７０６に遷移する。
【０３３８】
Ｓ２７０４でユーザ認証に失敗した場合、利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２７０４において公開鍵を受け付ける装置が送信してきた画面データを受信し（Ｓ２７０５）、利用者に対して認証に失敗した旨の表示を行い、処理を中断する。
【０３３９】
Ｓ２７０４でユーザ認証に成功した場合、当該ユーザに応じた鍵生成用画面データを利用者装置１７０に送信する（Ｓ２７０６）。鍵生成用画面データには、利用者装置１７０の鍵管理プログラム９４０を呼び出すためのスクリプトもしくはプログラムが含まれているものとする。
【０３４０】
利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２７０６において公開鍵を受け付ける装置が送信してきた鍵生成画面データを受信し、利用者に対して鍵生成画面を表示する（Ｓ２７０７）。
【０３４１】
次に、利用者は、利用者装置１７０のＷｅｂブラウザプログラム９２０に表示された鍵生成画面を操作することで、鍵管理プログラム９４０による利用者の鍵ペアの生成を行う（Ｓ２７０８）。本実施の形態例では、ここで生成された鍵ペアのうちの秘密鍵は、利用者の秘密鍵９５０として利用者装置１７０内に保存するものとする。但し、利用者の鍵ペアの生成場所や秘密鍵９５０の保存場所は、利用者装置１７０の代わりにＩＣカード等を用いてもよく、本実施の形態においては利用者の鍵の管理場所を制限するものではない。
【０３４２】
続いて、利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２７０８において生成した鍵ペアのうちの公開鍵とその暗号アルゴリズムの識別子等を含む公開鍵情報を、公開鍵を受け付ける装置に送信する（Ｓ２７０９）。
公開鍵を受け付ける装置側のプログラムは、前記ステップＳ２７０９において送信された公開鍵情報を受信する（Ｓ２７１０）。
【０３４３】
次に、公開鍵を受け付ける装置側のプログラムは、前記ステップＳ２７１０にて受信した公開鍵に応じた確認画面データを生成し、利用者装置１７０に対して、当該確認画面データを返信する（Ｓ２７１１）。確認画面データには、公開鍵を送信してきたユーザのＩＤや送信された公開鍵に関する情報が含まれているものとする。
【０３４４】
利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２７１１において公開鍵を受け付ける装置が送信してきた確認画面データを受信し、利用者に対して確認画面を表示する（Ｓ２７１２）。この後、管理者もしくは利用者が確認画面に対する内容の是非を判断した結果を入力することで、後記Ｓ２７１３に遷移する。
【０３４５】
利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２７１２において、利用者が入力した確認結果情報を、公開鍵を受け付ける装置に送信する（Ｓ２７１３）。
公開鍵を受け付ける装置側のプログラムは、前記ステップＳ２７１３において送信された確認結果情報を受信する（Ｓ２７１４）。
【０３４６】
続けて、公開鍵を受け付ける装置側のプログラムは、前記ステップＳ２７１４にて受信した確認結果情報を判定する（Ｓ２７１５）。Ｓ２７１５の判定結果が確認画面の内容を了承した旨のものであった場合には、後記ステップＳ２７１６に遷移する。Ｓ２７１５の判定結果が確認画面の内容を了承しない旨のものであった場合には、利用者装置１７０に対して、前記ステップＳ２７０６における鍵生成画面を返信する。
【０３４７】
Ｓ２７１５で確認画面の内容が了承されたと判断した場合、公開鍵を受け付ける装置側のプログラムは、前記ステップＳ２７１０にて受信した公開鍵情報の受付結果等の画面データを生成し、利用者装置１７０に対して、当該画面データを返信する（Ｓ２７１６）。
利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２７１６において公開鍵を受け付ける装置が送信してきた受付結果等が記載された画面データを受信し、利用者に対して当該画面を表示する（Ｓ２７１７）。
以上で、利用者装置１７０と、ＩＤ管理装置１１０もしくは認証局装置１３０との間で実施される鍵生成ステップＳ２７００の処理が完了する。
【０３４８】
図３１は、証明書取得ステップにおける処理フローの詳細を例示する図である。ここでは、利用者の証明書の取得を行う側である利用者装置１７０と、利用者の証明書を管理している側である認証局装置１３０との間の処理手順について示す。
はじめに、利用者が利用者装置１７０のＷｅｂブラウザプログラム９２０を起動する（Ｓ２８０１）。但し、本証明書取得ステップの直前に上述した鍵生成ステップＳ２７００を実施しており、既にＷｅｂブラウザプログラム９２０が起動している場合には、本ステップＳ２８０１は省略される。
【０３４９】
次に、利用者は、起動したＷｅｂブラウザプログラム９２０を用いて、認証局装置１３０が提供する証明書取得用のＵＲＬにアクセスする（Ｓ２８０２）。この、アクセス要求には、ユーザを認証するための情報（例えば、ユーザのＩＤに結びつくように割りあてられた乱数）も含まれているものとする。
【０３５０】
認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ２８０２において送信されたアクセス要求を受信する（Ｓ２８０３）。
認証局装置１３０のユーザ認証プログラム５２０は、前記ステップＳ２８０３において受信した要求内に含まれる認証情報と、図２８の説明におけるステップＳ２４１１において保存した認証情報とを用いて、ユーザの認証を行う（Ｓ２８０４）。Ｓ２８０４でユーザの認証に失敗した場合は、認証に失敗した旨の表示を行う画面データを利用者装置１７０に送信し、後記Ｓ２８０５に遷移する。Ｓ２８０４でユーザの認証に成功した場合には、そのまま後記Ｓ２８０６に遷移する。
【０３５１】
Ｓ２８０４でユーザ認証に失敗した場合、利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２８０４において認証局装置１３０が送信してきた画面データを受信し、利用者に対して認証に失敗した旨の表示を行い、処理を中断する（Ｓ２８０５）。
【０３５２】
Ｓ２８０４でユーザ認証に成功した場合、当該ユーザに応じた証明書取得用画面データを利用者装置１７０に送信する（Ｓ２８０６）。
利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２８０６において認証局装置１３０が送信してきた証明書取得画面データを受信し、利用者に対して証明書取得画面を表示する（Ｓ２８０７）。
【０３５３】
次に、利用者は、利用者装置１７０のＷｅｂブラウザプログラム９２０に表示された証明書取得画面を操作することで、前記ステップＳ２８０４において認証されたユーザに関する証明書をダウンロードするための証明書取得要求を、認証局装置１３０に送信する（Ｓ２８０８）。
認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ２８０８において送信された公開鍵情報を受信する（Ｓ２８０９）。
【０３５４】
次に、認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ２８０９にて受信した証明書発行要求に応じて、利用者装置１７０に対して、利用者の証明書（公開鍵証明書もしくは属性証明書）を返信する（Ｓ２８１０）。
利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２８１０において認証局装置１３０が送信してきた証明書を受信する（Ｓ２８１１）。
【０３５５】
続いて、利用者装置１７０のＷｅｂブラウザプログラム９２０は、前記ステップＳ２８１１において受信した証明書を利用者装置１７０内に保存する（Ｓ２８１２）。これによって、証明書を使った業務サービスプログラムを利用することができるようになる。
以上で、利用者装置１７０と、認証局装置１３０との間で実施される証明書取得ステップＳ２８００の処理が完了する。
【０３５６】
図３２は、証明書登録ステップあるいは失効情報登録ステップにおける処理フローの詳細を例示する図である。ここでは、証明書の発行あるいは失効を実施する認証局装置１３０と、証明書や失効情報の公開を行うリポジトリ装置１４０との間の処理手順について示す。
はじめに、認証局装置１３０のリポジトリ登録プログラム５４０は、証明書や失効情報を公開するリポジトリ装置１４０に対して、接続要求を送信する（Ｓ２９０１）。
リポジトリ装置１４０のリポジトリプログラム６３０は、前記ステップＳ２９０１において送信された接続要求を受信する（Ｓ２９０２）。
【０３５７】
続けて、リポジトリ装置１４０のリポジトリプログラム６３０は、接続要求を送信してきた認証局装置１３０に対して、認証情報を要求するメッセージを返信する（Ｓ２９０３）。本実施の形態例では、ＩＤ及びパスワードを用いた認証方法を採用するものとし、ここではＩＤ及びパスワードを要求するメッセージを返信する。但し、ここでの認証方法は既知の認証方法に置き換えてもよく、認証方法をＩＤ及びパスワードに限定するものではない。
【０３５８】
認証局装置１３０のリポジトリ登録プログラム５４０は、前記ステップＳ２９０３においてリポジトリ装置１４０が送信してきた認証要求を受信する（Ｓ２９０４）。
続いて、認証局装置１３０のリポジトリ登録プログラム５４０は、リポジトリ装置１４０にアクセスするための認証情報であるＩＤ及びパスワードを、リポジトリ装置１４０に送信する（Ｓ２９０５）。ここで、リポジトリ装置１４０にアクセスするための認証情報は、あらかじめ認証局装置１３０内に設定されているものとする。
【０３５９】
リポジトリ装置１４０のリポジトリプログラム６３０は、前記ステップＳ２９０５において送信された認証情報を受信する（Ｓ２９０６）。
リポジトリ装置１４０のユーザ認証プログラム６２０は、前記ステップＳ２９０６において受信した認証情報と、アクセス制御データ６４０内に保存されている認証情報とを用いて、ユーザの認証を行う（Ｓ２９０７）。Ｓ２９０７でユーザの認証に失敗した場合は、認証に失敗した旨の結果を認証局装置１３０に送信し、後記Ｓ２９０８に遷移する。Ｓ２９０７でユーザの認証に成功した場合には、そのまま後記Ｓ２９０９に遷移する。
【０３６０】
Ｓ２９０７でユーザ認証に失敗した場合、認証局装置１３０のリポジトリ登録プログラム５４０は、前記ステップＳ２９０７においてリポジトリ装置１４０が送信してきた結果を受信し（Ｓ２９０８）、認証に失敗した旨の判断を行い、処理を中断する。
Ｓ２９０７でユーザ認証に成功した場合、リポジトリ装置１４０のリポジトリプログラム６３０は、リポジトリ装置１４０で実行するためのコマンドを要求するために、認証局装置１３０にコマンド要求を送信する（Ｓ２９０９）。
【０３６１】
認証局装置１３０のリポジトリ登録プログラム５４０は、前記ステップＳ２９０９においてリポジトリ装置１４０が送信してきたコマンド要求を受信する（Ｓ２９１０）。
認証局装置１３０のリポジトリ登録プログラム５４０は、図３２のステップを実施する直前のステップでの証明書や失効情報の生成状況に応じて適切なコマンドをリポジトリ装置１４０に送信する（Ｓ２９１１）。例えば、図３２のステップを実施する直前に、証明書の生成までを行う証明書発行要求ステップＳ２３００が実施されている場合には、前記証明書発行要求ステップＳ２３００において生成された証明書をリポジトリに登録する旨のコマンドと当該証明書のデータを送信する。
【０３６２】
リポジトリ装置１４０のリポジトリプログラム６３０は、前記ステップＳ２９１１において送信されたコマンドを受信する（Ｓ２９１２）。
次に、リポジトリ装置１４０のリポジトリプログラム６３０は、前記ステップＳ２９１２において受信したコマンドを実行する（Ｓ２９１３）。例えば、前記ステップＳ２９１２において証明書を登録する旨のコマンドと証明書が送信されてきた場合、当該証明書をリポジトリ装置１４０内に保存しておき、リポジトリを利用しようとする者から証明書の開示要求があった場合に、証明書を提供できるように準備する。
【０３６３】
続けて、リポジトリ装置１４０のリポジトリプログラム６３０は、前記ステップＳ２９１３においてコマンドを実行した結果を、認証局装置１３０に対して返信する（Ｓ２９１４）。
認証局装置１３０のリポジトリ登録プログラム５４０は、前記ステップＳ２９１４においてリポジトリ装置１４０が送信してきたコマンド実行結果を受信する（Ｓ２９１５）。
【０３６４】
以上で、認証局装置１３０とリポジトリ装置１４０との間で実施される証明書登録ステップＳ２９００もしくは失効情報登録ステップＳ３２００の処理が完了する。なお、証明書登録ステップＳ２９００と失効情報登録ステップＳ３２００が連続して実施される場合、後で実施されるステップは、先に実施されたステップに続けて、Ｓ２９１１に遷移するものとし、Ｓ２９０１からＳ２９１０までの認証を行う処理を省略してもよい。
【０３６５】
図３３は、完了通知ステップにおける処理フローの詳細を例示する図である。ここでは、証明書の発行あるいは失効を実施する認証局装置１３０と、証明書や失効情報の情報をユーザ情報に結びつけるためのＩＤ管理装置１１０との間の処理手順について示す。
はじめに、認証局装置１３０の証明書管理プログラム５３０は、ＩＤ管理装置１１０に対して、接続要求を送信する（Ｓ３００１）。
【０３６６】
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３００１において送信された接続要求を受信する（Ｓ３００２）。
続けて、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、接続要求を送信してきた認証局装置１３０に対して、認証情報を要求するメッセージを返信する（Ｓ３００３）。本実施の形態例では、ＩＤ及びパスワードを用いた認証方法を採用するものとし、ここではＩＤ及びパスワードを要求するメッセージを返信する。但し、ここでの認証方法は既知の認証方法に置き換えてもよく、認証方法をＩＤ及びパスワードに限定するものではない。
【０３６７】
認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ３００３においてＩＤ管理装置１１０が送信してきた認証要求を受信する（Ｓ３００４）。
続いて、認証局装置１３０の証明書管理プログラム５３０は、ＩＤ管理装置１１０にアクセスするための認証情報であるＩＤ及びパスワードを、ＩＤ管理装置１１０に送信する（Ｓ３００５）。ここで、ＩＤ管理装置１１０にアクセスするための認証情報は、あらかじめ認証局装置１３０内に設定されているものとする。
【０３６８】
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３００５において送信された認証情報を受信する（Ｓ３００６）。
ＩＤ管理装置１１０のユーザ認証プログラム３７０は、前記ステップＳ３００６において受信した認証情報と、アクセス制御データ３６０内に保存されている認証情報とを用いて、ユーザの認証を行う（Ｓ３００７）。Ｓ３００７でユーザの認証に失敗した場合は、認証に失敗した旨の結果を認証局装置１３０に送信し、後記Ｓ３００８に遷移する。Ｓ３００７でユーザの認証に成功した場合には、そのまま後記Ｓ３００９に遷移する。
【０３６９】
Ｓ３００７でユーザ認証に失敗した場合、認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ３００７においてＩＤ管理装置１１０が送信してきた結果を受信し（Ｓ３００８）、認証に失敗した旨の判断を行い、処理を中断する。
Ｓ３００７でユーザ認証に成功した場合、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、ＩＤ管理装置１１０で実行するためのコマンドを要求するために、認証局装置１３０にコマンド要求を送信する（Ｓ３００９）。
【０３７０】
認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ３００９においてＩＤ管理装置１１０が送信してきたコマンド要求を受信する（Ｓ３０１０）。
認証局装置１３０の証明書管理プログラム５３０は、図３３のステップを実施する前に生成した証明書や失効情報の内容に応じて適切なコマンドをＩＤ管理装置１１０に送信する（Ｓ３０１１）。例えば、図３３のステップを実施する前に証明書の生成を行っている場合には、ＩＤ管理装置１１０内のユーザ情報データベース３７０を更新する旨のコマンドと、更新内容である当該証明書に記載されたＩＤ、発行者名、シリアル番号、記載した属性の型等の値を送信する。
【０３７１】
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３０１１において送信されたコマンドを受信する（Ｓ３０１２）。
次に、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３０１２において受信したコマンドを実行する（Ｓ３０１３）。例えば、当該ＩＤ、当該発行者名、当該シリアル番号、当該記載属性型等の値をＩＤ管理装置１１０内のユーザ情報データベース３７０に反映する。この場合、前記ステップＳ３０１２においてＩＤ管理装置１１０内のユーザ情報データベース３７０を更新する旨のコマンドと、更新内容である当該証明書に記載されたＩＤ、発行者名、シリアル番号、記載した属性の型等の値が送信されてくる。
【０３７２】
続けて、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３０１３においてコマンドを実行した結果を、認証局装置１３０に対して返信する（Ｓ３０１４）。
認証局装置１３０の証明書管理プログラム５３０は、前記ステップＳ３０１４においてＩＤ管理装置１１０が送信してきたコマンド実行結果を受信する（Ｓ３０１５）。
以上で、認証局装置１３０とＩＤ管理装置１１０との間で実施される完了通知ステップＳ３０００の処理が完了する。
【０３７３】
図３４は、承認ステップにおける処理フローの詳細を例示する図である。ここでは、利用者からの申請内容を承認する側である承認者装置１８０と、利用者の申請情報を管理する側であるＩＤ管理装置１１０との間の処理手順について示す。
はじめに、承認者が承認者装置１８０のＷｅｂブラウザプログラム１０２０を起動する（Ｓ３３０１）。
【０３７４】
次に、承認者は、起動したＷｅｂブラウザプログラム１０２０を用いて、ＩＤ管理装置１１０が提供する承認用のＵＲＬにアクセスする（Ｓ３３０２）。この、アクセス要求には、ユーザを認証するための情報（例えば、ユーザのＩＤに結びつくように割り当てられた乱数）も含まれているものとする。
【０３７５】
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３３０２において送信されたアクセス要求を受信する（Ｓ３３０３）。
ＩＤ管理装置１１０のユーザ認証プログラム３２０は、前記ステップＳ３３０３において受信した要求内に含まれる認証情報と、図２８の説明におけるステップＳ２４１１において保存した認証情報とを用いて、ユーザの認証を行う（Ｓ３３０４）。Ｓ３３０４でユーザの認証に失敗した場合は、認証に失敗した旨の表示を行う画面データを承認者装置１８０に送信し、後記Ｓ３３０５に遷移する。Ｓ３３０４でユーザの認証に成功した場合には、そのまま後記Ｓ３３０６に遷移する。
【０３７６】
Ｓ３３０４でユーザ認証に失敗した場合、承認者装置１８０のＷｅｂブラウザプログラム１０２０は、前記ステップＳ３３０４においてＩＤ管理装置１１０が送信してきた画面データを受信し、利用者に対して認証に失敗した旨の表示を行い、処理を中断する（Ｓ３３０５）。
【０３７７】
Ｓ３３０４でユーザ認証に成功した場合、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、当該ユーザに応じた承認画面データを承認者装置１８０に送信する（Ｓ３３０６）。
承認者装置１８０のＷｅｂブラウザプログラム１０２０は、前記ステップＳ３３０６においてＩＤ管理装置１１０が送信してきた承認画面データを受信し、承認者に対して承認画面を表示する（Ｓ３３０７）。この後、承認者は、承認の可否を選択することで、後記ステップＳ３３０８に遷移する。
【０３７８】
続いて、承認者装置１８０のＷｅｂブラウザプログラム１０２０は、前記ステップＳ３３０７において選択した承認の可否に関する承認可否情報を、ＩＤ管理装置１１０に送信する（Ｓ３３０８）。
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３３０８において送信された承認可否情報を受信する（Ｓ３３０９）。
【０３７９】
次に、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３３０９にて受信した承認可否情報に応じた確認画面データを生成し、承認者装置１８０に対して、当該確認画面データを返信する（Ｓ３３１０）。
承認者装置１８０のＷｅｂブラウザプログラム１０２０は、前記ステップＳ３３１０においてＩＤ管理装置１１０が送信してきた確認画面データを受信し、承認者に対して確認画面を表示する（Ｓ３３１１）。この後、承認者が確認画面に対する内容の是非を判断した結果を入力することで、後記Ｓ３３１２に遷移する。
【０３８０】
承認者装置１８０のＷｅｂブラウザプログラム１０２０は、前記ステップＳ３３１１において、承認者が入力した確認結果情報を、ＩＤ管理装置１１０に送信する（Ｓ３３１２）。
ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３３１２において送信された確認結果情報を受信する（Ｓ３３１３）。
【０３８１】
続けて、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、前記ステップＳ３３１３にて受信した確認結果情報を判定する（Ｓ３３１４）。Ｓ３３１４の判定結果が確認画面の内容を了承した旨のものであった場合には、後記ステップＳ３３１５に遷移する。Ｓ３３１４の判定結果が確認画面の内容を了承しない旨のものであった場合には、承認者装置１８０に対して、前記ステップＳ３３０６における承認画面を返信する。
【０３８２】
Ｓ３３１４で確認画面の内容が了承されたと判断した場合、ＩＤ管理装置１１０のＩＤ管理サービスプログラム３３０は、図１３から図２４における承認ステップＳ３３００の次のステップに処理を遷移させるとともに、前記ステップＳ３３０９にて受信した公開鍵情報の受付結果等の画面データを生成し、承認者装置１８０に対して、当該画面データを返信する（Ｓ３３１５）。
【０３８３】
承認者装置１８０のＷｅｂブラウザプログラム１０２０は、前記ステップＳ３３１５においてＩＤ管理装置１１０が送信してきた受付結果等が記載された画面データを受信し、承認者に対して当該画面を表示する（Ｓ３３１６）。
以上で、承認者装置１８０と、ＩＤ管理装置１１０との間で実施される承認ステップＳ３３００の処理が完了する。
【０３８４】
なお、上述した本実施の形態例に限らず、本発明の要旨を逸脱しない限り、適宜変更しうることは言うまでもない。
【図面の簡単な説明】
【０３８５】
【図１】本発明の一実施の形態によるシステム構成例を示す説明図である。
【図２】ＩＤ管理装置、メールサーバ装置、認証局装置、リポジトリ装置、サービス提供装置、管理者装置、利用者装置及び承認者装置のハードウェア構成を例示する図である。
【図３】ＩＤ管理装置のソフトウェア構成を例示する図である。
【図４】メールサーバ装置のソフトウェア構成を例示する図である。
【図５】認証局装置のソフトウェア構成を例示する図である。
【図６】リポジトリ装置のソフトウェア構成を例示する図である。
【図７】サービス提供装置のソフトウェア構成を例示する図である。
【図８】管理者装置のソフトウェア構成を例示する図である。
【図９】利用者装置のソフトウェア構成を例示する図である。
【図１０】承認者装置のソフトウェア構成を例示する図である。
【図１１】ＩＤもしくは属性の登録時におけるデータの管理形態を例示する図である。
【図１２】ＩＤもしくは属性の削除時等におけるデータの管理形態を例示する図である。
【図１３】管理者が利用者のＩＤを登録する場合の処理フローの概要を例示する図である。
【図１４】管理者が利用者のＩＤを削除、利用停止もしくは利用停止解除する場合の処理フローの概要を例示する図である。
【図１５】管理者が利用者のＩＤを変更する場合の処理フローの概要を例示する図である。
【図１６】管理者が利用者の属性情報を登録する場合の処理フローの概要を例示する図である。
【図１７】管理者が利用者の属性情報を変更もしくは削除する場合の処理フローの概要を例示する図である。
【図１８】利用者がＩＤを登録する場合の処理フローの概要を例示する図である。
【図１９】利用者がＩＤを登録する場合の別の処理フローの概要を例示する図である。
【図２０】利用者がＩＤを削除、利用停止もしくは利用停止解除する場合の処理フローの概要を例示する図である。
【図２１】利用者がＩＤを変更する場合の処理フローの概要を例示する図である。
【図２２】利用者がＩＤを変更する場合の別の処理フローの概要を例示する図である。
【図２３】利用者が属性情報を登録する場合の処理フローの概要を例示する図である。
【図２４】利用者が属性情報を変更もしくは削除する場合の処理フローの概要を例示する図である。
【図２５】メニュー選択・ＩＤ指定ステップにおける処理フローの詳細を例示する図である。
【図２６】プロビジョニングステップにおける処理フローの詳細を例示する図である。
【図２７】証明書発行要求ステップあるいは証明書失効要求ステップにおける処理フローの詳細を例示する図である。
【図２８】メール送信ステップにおける処理フローの詳細を例示する図である。
【図２９】メール受信ステップにおける処理フローの詳細を例示する図である。
【図３０】鍵生成ステップにおける処理フローの詳細を例示する図である。
【図３１】証明書取得ステップにおける処理フローの詳細を例示する図である。
【図３２】証明書登録ステップあるいは失効情報登録ステップにおける処理フローの詳細を例示する図である。
【図３３】完了通知ステップにおける処理フローの詳細を例示する図である。
【図３４】承認ステップにおける処理フローの詳細を例示する図である。
【符号の説明】
【０３８６】
１１０…ＩＤ管理装置、１２０…メールサーバ装置、１３０…認証局装置、１４０…リポジトリ装置、１５０…サービス提供装置、１６０…管理者装置、１７０…利用者装置、１８０…承認者装置、１９０…ネットワーク、２１０…入力装置、２２０…表示装置、２３０…ＣＰＵ、２４０…メモリ、２５０…記憶装置、２６０…通信装置、２７０…バス、３１０…オペレーティングシステム、３２０…ユーザ認証プログラム、３３０…ＩＤ管理サービスプログラム、３４０…プロビジョニングプログラム、３５０…メール送信プログラム、３６０…アクセス制御データ、３７０…ユーザ情報データベース、４１０…オペレーティングシステム、４２０…ユーザ認証プログラム、４３０…アカウント管理プログラム、４４０…メール管理プログラム、４５０…アクセス制御データ、４６０…ユーザ情報データベース、４７０…アカウント別メールボックス、５１０…オペレーティングシステム、５２０…ユーザ認証プログラム、５３０…証明書管理プログラム、５４０…リポジトリ登録プログラム、５４５…利用者鍵ペア生成プログラム、５５０…アクセス制御データ、５６０…証明書情報、５７０…失効情報、５８０…認証局の秘密鍵、５９０…認証局の公開鍵証明書、６１０…オペレーティングシステム、６２０…ユーザ認証プログラム、６３０…リポジトリプログラム、６４０…アクセス制御データ、６５０…証明書情報、６６０…失効情報、７１０…オペレーティングシステム、７２０…ユーザ認証プログラム、７３０…アカウント管理プログラム、７４０…業務サービスプログラム、７５０…アクセス制御データ、７６０…ユーザ情報データベース、８１０…オペレーティングシステム、８２０…Ｗｅｂブラウザプログラム、９１０…オペレーティングシステム、９２０…Ｗｅｂブラウザプログラム、９３０…メーラープログラム、９４０…鍵管理プログラム、９５０…利用者の秘密鍵、９６０…利用者の公開鍵証明書、９７０…利用者の属性証明書、１０１０…オペレーティングシステム、１０２０…Ｗｅｂブラウザプログラム、１０３０…メーラープログラム
【特許請求の範囲】
【請求項１】
利用者のＩＤに基づいてサービスを提供するシステムと、利用者の電子的な証明書に基づいてサービスを提供するシステムとが共存する環境において、利用者のＩＤ管理と証明書管理を一括して行うユーザ情報管理システムであって、
前記ユーザ情報管理システムは、ＩＤ管理を一元的に行うＩＤ管理部と、前記ＩＤ管理部に対してＩＤ管理の操作を行う管理者操作部と、利用者のＩＤに基づいてＩＤを利用したサービスの提供を行う１つ以上のサービス提供部と、利用者の証明書及び失効情報の生成を行う認証局部と、前記サービス提供部を利用するユーザが操作する利用者操作部とを備え、
前記管理者操作部は、管理者によって指定された、利用者のＩＤを管理するために必要なユーザ情報を含むＩＤ管理要求を、前記ＩＤ管理部に送信し、
前記ＩＤ管理部は、受信した前記ＩＤ管理要求に基づいて、要求されたＩＤ管理の実施のために前記サービス提供部毎に必要とするユーザ情報を含むプロビジョニング要求を、全ての前記サービス提供部に送信するとともに、要求されたＩＤ管理の実施のために前記認証局部が必要とするユーザ情報を含む証明書管理要求を、前記認証局部に送信し、
前記サービス提供部は、受信した前記プロビジョニング要求に応じて、当該サービス提供部が管理しているユーザ情報データベースを更新し、
前記認証局部は、受信した前記証明書管理要求に応じて、証明書関連情報を生成し、当該証明書関連情報内に存在する各種構成情報を含む生成結果情報を、前記ＩＤ管理部に送信し、
前記ＩＤ管理部は、受信した前記生成結果情報に基づいて、前記ＩＤ管理部が管理しているユーザ情報データベースを更新する
ことを特徴とするユーザ情報管理システム。
【請求項２】
請求項１に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理要求及び前記プロビジョニング要求は、利用者の新しいＩＤ情報を含むＩＤ登録要求で実現され、
前記証明書管理要求は、利用者の新しいＩＤ情報を含む証明書発行要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれる新しいＩＤ情報等を、前記サービス提供部におけるユーザ情報データベースに登録することによって行われ、
前記認証局部における前記証明書関連情報の生成は、前記利用者操作部が、利用者の公開鍵を生成し、当該公開鍵を前記認証局部に送信し、前記認証局部が、受信した前記公開鍵と前記証明書発行要求とを用いて利用者の公開鍵証明書を生成することによって行われ、
前記生成結果情報は、生成した前記公開鍵証明書の発行者名、シリアル番号、利用者の公開鍵情報、記載属性型を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる生成した前記公開鍵証明書の発行者名、シリアル番号、利用者の公開鍵情報、記載属性型を、前記ＩＤ管理部におけるユーザ情報データベースに登録することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項３】
請求項１に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理要求及び前記プロビジョニング要求は、削除する利用者のＩＤ情報を含むＩＤ削除要求、利用停止するＩＤ情報を含むＩＤ利用停止要求、又は利用停止解除する利用者のＩＤ情報を含むＩＤ利用停止解除要求で実現され、
前記証明書管理要求は、削除、利用停止又は利用停止解除するＩＤをキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の発行者名、シリアル番号等を含む証明書失効要求、証明書利用停止要求又は証明書利用停止解除要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれるＩＤ情報を、前記サービス提供部におけるユーザ情報データベースに対して削除、利用停止又は利用停止解除することによって行われ、
前記認証局部における前記証明書関連情報の生成は、受信した前記失効情報の証明書失効要求に含まれる利用者の証明書の発行者名及びシリアル番号に合致する証明書を失効、利用停止又は利用停止解除することによって行われ、
前記生成結果情報は、失効、利用停止又は利用停止解除した前記証明書の発行者名及びシリアル番号等を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる失効、利用停止又は利用停止解除した証明書の発行者名及びシリアル番号に合致するユーザ情報を、前記ＩＤ管理部におけるユーザ情報データベースに対して削除、利用停止又は利用停止解除することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項４】
請求項１に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理要求及び前記プロビジョニング要求は、利用者の変更前のＩＤ情報と変更後の新しいＩＤ情報を含むＩＤ変更要求、又は利用者のＩＤ情報及び追加、変更もしくは削除する属性情報を含む属性変更要求で実現され、
前記証明書管理要求は、変更前のＩＤ情報をキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の発行者名、シリアル番号等を含む証明書失効要求と、利用者の新しいＩＤ情報を含む証明書発行要求、又はＩＤ情報をキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の発行者名、シリアル番号等を含む証明書失効要求と、利用者のＩＤ情報及び追加もしくは変更する属性情報を含む証明書発行要求、又は前記属性情報に対してさらに、ＩＤ情報をキーに前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の公開鍵情報を含む証明書発行要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれる変更前のＩＤ情報等を、前記サービス提供部におけるユーザ情報データベースから削除することと、受信した前記プロビジョニング要求に含まれる新しいＩＤ情報等を、前記サービス提供部におけるユーザ情報データベースに登録すること、又は受信した前記プロビジョニング要求に含まれるＩＤ情報及び追加、変更もしくは削除する属性情報をもとに、前記サービス提供部におけるユーザ情報データベース内の当該ＩＤ情報に関する属性情報を追加、変更もしくは削除することによって行われ、
前記認証局部における証明書関連情報の生成は、受信した前記証明書失効要求に含まれる利用者の証明書の発行者名及びシリアル番号に合致する証明書を失効することと、前記利用者操作部が、利用者の公開鍵を生成し、当該公開鍵を前記認証局部に送信し、前記認証局部が、受信した前記公開鍵と前記証明書発行要求とを用いて利用者の公開鍵証明書を生成すること、又は受信した前記公開鍵と前記証明書発行要求とを用いて、追加もしくは変更する属性情報を含んだ利用者の公開鍵証明書を生成すること、又は受信した前記証明書発行要求を用いて、追加もしくは変更する属性情報を含んだ利用者の公開鍵証明書を生成することによって行われ、
前記生成結果情報は、失効した前記証明書の発行者名及びシリアル番号等を含む情報と、生成した前記公開鍵証明書の発行者名、シリアル番号、利用者の公開鍵情報、記載属性型を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる失効した証明書の発行者名及びシリアル番号に合致するユーザ情報を、前記ＩＤ管理部におけるユーザ情報データベースから削除することと、受信した前記生成結果情報に含まれる生成した公開鍵証明書の発行者名、シリアル番号、利用者の公開鍵情報、記載属性型を、前記ＩＤ管理部におけるユーザ情報データベースに登録することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項５】
請求項１に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理要求及び前記プロビジョニング要求は、利用者のＩＤ情報及び追加する属性情報を含む属性追加要求で実現され、
前記証明書管理要求は、ＩＤ情報をキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の公開鍵証明書の発行者名、シリアル番号と、追加する属性情報を含む属性証明書発行要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれるＩＤ情報及び追加する属性情報をもとに、前記サービス提供部におけるユーザ情報データベース内の当該ＩＤ情報に関する属性情報を追加することによって行われ、
前記認証局部における証明書関連情報の生成は、受信した前記属性証明書発行要求を用いて利用者の属性証明書を生成することによって行われ、
前記生成結果情報は、生成した前記属性証明書の発行者名、シリアル番号、記載属性型を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる生成した属性証明書の発行者名、シリアル番号、記載属性型を、前記ＩＤ管理部におけるユーザ情報データベースに登録することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項６】
請求項１に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理要求及び前記プロビジョニング要求は、利用者のＩＤ情報及び変更もしくは削除する属性情報を含む属性変更要求、又は利用者のＩＤ情報及び削除する属性情報を含む属性削除要求で実現され、
証明書管理要求は、ＩＤ情報をキーに前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の記載属性型に変更もしくは削除する属性情報の型が包含される利用者の属性証明書の発行者名、シリアル番号を含む属性証明書失効要求と、ＩＤ情報をキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の公開鍵証明書の発行者名、シリアル番号と、変更する属性情報を含む属性証明書発行要求、又はＩＤ情報をキーに前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の記載属性型に削除する属性情報の型が包含される利用者の属性証明書の発行者名、シリアル番号を含む属性証明書失効要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれるＩＤ情報及び変更もしくは削除する属性情報をもとに、前記サービス提供部におけるユーザ情報データベース内の当該ＩＤ情報に関する属性情報を変更もしくは削除すること、又は受信した前記プロビジョニング要求に含まれるＩＤ情報及び削除する属性情報をもとに、前記サービス提供部におけるユーザ情報データベース内の当該ＩＤ情報に関する属性情報を削除することによって行われ、
前記認証局部における証明書関連情報の生成は、受信した前記属性証明書失効要求に含まれる利用者の属性証明書の発行者名及びシリアル番号に合致する属性証明書を失効することと、受信した前記属性証明書発行要求を用いて、変更する属性情報を含んだ利用者の属性証明書を生成すること、又は受信した前記属性証明書失効要求に含まれる利用者の属性証明書の発行者名及びシリアル番号に合致する属性証明書を失効することによって行われ、
前記生成結果情報は、失効した前記属性証明書の発行者名及びシリアル番号等を含む情報と、生成した前記属性証明書の発行者名、シリアル番号、記載属性型を含む情報、又は失効した前記属性証明書の発行者名及びシリアル番号等を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる失効した属性証明書の発行者名及びシリアル番号に合致する情報を、前記ＩＤ管理部におけるユーザ情報データベースから削除することと、受信した前記生成結果情報に含まれる生成した属性証明書の発行者名、シリアル番号、記載属性型を、前記ＩＤ管理部におけるユーザ情報データベースに登録すること、又は受信した前記生成結果情報に含まれる失効した属性証明書の発行者名及びシリアル番号に合致する情報を、前記ＩＤ管理部におけるユーザ情報データベースから削除することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項７】
利用者のＩＤに基づいてサービスを提供するシステムと、利用者の電子的な証明書に基づいてサービスを提供するシステムとが共存する環境において、利用者のＩＤ管理と証明書管理を一括して行うユーザ情報管理システムであって、
前記ユーザ情報管理システムは、ＩＤ管理を一元的に行うＩＤ管理部と、利用者のＩＤに基づいてＩＤを利用したサービスの提供を行う１つ以上のサービス提供部と、利用者の証明書及び失効情報の生成を行う認証局部と、前記サービス提供部を利用するユーザが前記ＩＤ管理部に対してＩＤ管理の申請操作を行う利用者操作部と、前記ＩＤ管理部に対して行われた申請に対して承認者が承認操作を行う承認者操作部とを備え、
前記利用者操作部は、利用者によって指定された、当該利用者のＩＤを管理するため必要なユーザ情報を含むＩＤ管理申請要求を、前記ＩＤ管理部に送信し、
前記ＩＤ管理部は、受信した前記ＩＤ管理申請要求に基づいて、要求されたＩＤ管理の実施に対する承認要求を、前記承認者操作部に前記承認者が知ることが可能な方法で通知し、
前記ＩＤ管理部からの通知を受けたことにより、前記承認者操作部は、前記承認要求に応じて、利用者から申請された前記ＩＤ管理申請要求に対する前記承認者の承認可否を含むＩＤ管理承認情報を、前記ＩＤ管理部に送信し、
前記ＩＤ管理部は、受信した前記ＩＤ管理申請要求及びＩＤ管理承認情報に基づいて、要求されたＩＤ管理の実施のために前記サービス提供部毎に必要とするユーザ情報を含むプロビジョニング要求を、全ての前記サービス提供部に送信するとともに、要求されたＩＤ管理の実施のために前記認証局部が必要とするユーザ情報を含む証明書管理要求を、前記認証局部に送信し、
前記サービス提供部は、受信した前記プロビジョニング要求に応じて、当該サービス提供部が管理しているユーザ情報データベースを更新し、
一方、前記認証局部は、受信した前記証明書管理要求に応じて、証明書関連情報を生成し、当該証明書関連情報内に存在する各種構成情報を含む生成結果情報を、前記ＩＤ管理部に送信し、
前記ＩＤ管理部は、受信した前記生成結果情報に基づいて、前記ＩＤ管理部が管理しているユーザ情報データベースを更新する
ことを特徴とするユーザ情報管理システム。
【請求項８】
請求項７に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理申請要求及び前記プロビジョニング要求は、利用者の新しいＩＤ情報を含むＩＤ登録申請要求で実現され、
証明書管理要求は、利用者の新しいＩＤ情報を含む証明書発行要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれる新しいＩＤ情報等を、前記サービス提供部におけるユーザ情報データベースに登録することによって行われ、
前記認証局部における証明書関連情報の生成は、前記利用者操作部が、利用者の公開鍵を生成し、当該公開鍵を前記認証局部に送信し、前記認証局部が、受信した前記公開鍵と前記証明書発行要求とを用いて利用者の公開鍵証明書を生成することによって行われ、
前記生成結果情報は、生成した前記公開鍵証明書の発行者名、シリアル番号、利用者の公開鍵情報、記載属性型を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる生成した公開鍵証明書の発行者名、シリアル番号、利用者の公開鍵情報、記載属性型を、前記ＩＤ管理部におけるユーザ情報データベースに登録することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項９】
請求項７に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理申請要求及び前記プロビジョニング要求は、削除する利用者のＩＤ情報を含むＩＤ削除要求、利用停止する利用者のＩＤ情報を含むＩＤ利用停止要求、又は利用停止解除する利用者のＩＤ情報を含むＩＤ利用停止解除要求で実現され、
証明書管理要求は、削除、利用停止又は利用停止解除するＩＤをキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の発行者名、シリアル番号を含む証明書失効要求、証明書利用停止要求又は証明書利用停止解除要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれるＩＤ情報等を、前記サービス提供部におけるユーザ情報データベースに対して削除、利用停止又は利用停止解除することによって行われ、
前記認証局部における証明書関連情報の生成は、受信した前記証明書失効要求、前記証明書利用停止要求又は前記証明書利用停止解除要求に含まれる利用者の証明書の発行者名及びシリアル番号に合致する証明書を失効、利用停止又は利用停止解除することによって行われ、
前記生成結果情報は、失効、利用停止又は利用停止解除した前記証明書の発行者名及びシリアル番号を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる失効、利用停止又は利用停止解除した証明書の発行者名及びシリアル番号に合致するユーザ情報を、前記ＩＤ管理部におけるユーザ情報データベースから削除することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項１０】
請求項７に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理申請要求及び前記プロビジョニング要求は、利用者の変更前のＩＤ情報と変更後の新しいＩＤ情報を含むＩＤ変更要求、又は利用者のＩＤ情報及び追加、変更もしくは削除する属性情報を含む属性変更要求で実現され、
証明書管理要求は、変更前のＩＤ情報をキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の発行者名、シリアル番号等を含む証明書失効要求と、利用者の新しいＩＤ情報を含む証明書発行要求、又はＩＤ情報をキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の発行者名、シリアル番号等を含む証明書失効要求と、利用者のＩＤ情報及び追加もしくは変更する属性情報を含む証明書発行要求、又は前記属性情報に対してさらに、ＩＤ情報をキーに前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の公開鍵情報を含む証明書発行要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれる変更前のＩＤ情報等を、前記サービス提供部におけるユーザ情報データベースから削除することと、受信した前記プロビジョニング要求に含まれる新しいＩＤ情報等を、前記サービス提供部におけるユーザ情報データベースに登録すること、又は受信した前記プロビジョニング要求に含まれるＩＤ情報及び追加、変更もしくは削除する属性情報をもとに、前記サービス提供部におけるユーザ情報データベース内の当該ＩＤ情報に関する属性情報を追加、変更もしくは削除することによって行われ、
前記認証局部における証明書関連情報の生成は、受信した前記証明書失効要求に含まれる利用者の証明書の発行者名及びシリアル番号に合致する証明書を失効することと、前記利用者操作部が、利用者の公開鍵を生成し、当該公開鍵を前記認証局部に送信し、前記認証局部が、受信した前記公開鍵と前記証明書発行要求とを用いて利用者の公開鍵証明書を生成すること、又は受信した前記公開鍵と前記証明書発行要求とを用いて、追加もしくは変更する属性情報を含んだ利用者の公開鍵証明書を生成すること、又は受信した前記証明書発行要求を用いて、追加もしくは変更する属性情報を含んだ利用者の公開鍵証明書を生成することによって行われ、
前記生成結果情報は、失効した前記証明書の発行者名及びシリアル番号を含む情報と、生成した前記公開鍵証明書の発行者名、シリアル番号、利用者の公開鍵情報、記載属性型を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる失効した証明書の発行者名及びシリアル番号に合致するユーザ情報を、前記ＩＤ管理部におけるユーザ情報データベースから削除することと、受信した前記生成結果情報に含まれる生成した公開鍵証明書の発行者名、シリアル番号、利用者の公開鍵情報、記載属性型を、前記ＩＤ管理部におけるユーザ情報データベースに登録することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項１１】
請求項７に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理申請要求及び前記プロビジョニング要求は、利用者のＩＤ情報及び追加する属性情報を含む属性追加要求で実現され、
前記証明書管理要求は、ＩＤ情報をキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の公開鍵証明書の発行者名、シリアル番号等と、追加する属性情報を含む属性証明書発行要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれるＩＤ情報及び追加する属性情報をもとに、前記サービス提供部におけるユーザ情報データベース内の当該ＩＤ情報に関する属性情報を追加することによって行われ、
前記認証局部における証明書関連情報の生成は、受信した前記属性証明書発行要求を用いて利用者の属性証明書を生成することによって行われ、
前記生成結果情報は、生成した前記属性証明書の発行者名、シリアル番号、記載属性型を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる生成した属性証明書の発行者名、シリアル番号、記載属性型を、前記ＩＤ管理部におけるユーザ情報データベースに登録することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項１２】
請求項７に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理申請要求及び前記プロビジョニング要求は、利用者のＩＤ情報及び変更もしくは削除する属性情報を含む属性変更要求、又は利用者のＩＤ情報及び削除する属性情報を含む属性削除要求で実現され、
前記証明書管理要求は、ＩＤ情報をキーに前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の記載属性型に変更もしくは削除する属性情報の型が包含される利用者の属性証明書の発行者名、シリアル番号を含む属性証明書失効要求と、ＩＤ情報をキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の公開鍵証明書の発行者名、シリアル番号と、変更する属性情報を含む属性証明書発行要求、又はＩＤ情報をキーに前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の記載属性型に削除する属性情報の型が包含される利用者の属性証明書の発行者名、シリアル番号を含む属性証明書失効要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれるＩＤ情報及び変更もしくは削除する属性情報をもとに、前記サービス提供部におけるユーザ情報データベース内の当該ＩＤ情報に関する属性情報を変更もしくは削除すること、又は受信した前記プロビジョニング要求に含まれるＩＤ情報及び削除する属性情報をもとに、前記サービス提供部におけるユーザ情報データベース内の当該ＩＤ情報に関する属性情報を削除することによって行われ、
前記認証局部における証明書関連情報の生成は、受信した前記属性証明書失効要求に含まれる利用者の属性証明書の発行者名及びシリアル番号に合致する属性証明書を失効することと、受信した前記属性証明書発行要求を用いて、変更する属性情報を含んだ利用者の属性証明書を生成すること、又は受信した前記属性証明書失効要求に含まれる利用者の属性証明書の発行者名及びシリアル番号に合致する属性証明書を失効することによって行われ、
前記生成結果情報は、失効した前記属性証明書の発行者名及びシリアル番号を含む情報と、生成した前記属性証明書の発行者名、シリアル番号、記載属性型を含む情報、又は失効した前記属性証明書の発行者名及びシリアル番号を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる失効した属性証明書の発行者名及びシリアル番号に合致する情報を、前記ＩＤ管理部におけるユーザ情報データベースから削除することと、受信した前記生成結果情報に含まれる生成した属性証明書の発行者名、シリアル番号、記載属性型を、前記ＩＤ管理部におけるユーザ情報データベースに登録すること、又は受信した前記生成結果情報に含まれる失効した属性証明書の発行者名及びシリアル番号に合致する情報を、前記ＩＤ管理部におけるユーザ情報データベースから削除することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項１】
利用者のＩＤに基づいてサービスを提供するシステムと、利用者の電子的な証明書に基づいてサービスを提供するシステムとが共存する環境において、利用者のＩＤ管理と証明書管理を一括して行うユーザ情報管理システムであって、
前記ユーザ情報管理システムは、ＩＤ管理を一元的に行うＩＤ管理部と、前記ＩＤ管理部に対してＩＤ管理の操作を行う管理者操作部と、利用者のＩＤに基づいてＩＤを利用したサービスの提供を行う１つ以上のサービス提供部と、利用者の証明書及び失効情報の生成を行う認証局部と、前記サービス提供部を利用するユーザが操作する利用者操作部とを備え、
前記管理者操作部は、管理者によって指定された、利用者のＩＤを管理するために必要なユーザ情報を含むＩＤ管理要求を、前記ＩＤ管理部に送信し、
前記ＩＤ管理部は、受信した前記ＩＤ管理要求に基づいて、要求されたＩＤ管理の実施のために前記サービス提供部毎に必要とするユーザ情報を含むプロビジョニング要求を、全ての前記サービス提供部に送信するとともに、要求されたＩＤ管理の実施のために前記認証局部が必要とするユーザ情報を含む証明書管理要求を、前記認証局部に送信し、
前記サービス提供部は、受信した前記プロビジョニング要求に応じて、当該サービス提供部が管理しているユーザ情報データベースを更新し、
前記認証局部は、受信した前記証明書管理要求に応じて、証明書関連情報を生成し、当該証明書関連情報内に存在する各種構成情報を含む生成結果情報を、前記ＩＤ管理部に送信し、
前記ＩＤ管理部は、受信した前記生成結果情報に基づいて、前記ＩＤ管理部が管理しているユーザ情報データベースを更新する
ことを特徴とするユーザ情報管理システム。
【請求項２】
請求項１に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理要求及び前記プロビジョニング要求は、利用者の新しいＩＤ情報を含むＩＤ登録要求で実現され、
前記証明書管理要求は、利用者の新しいＩＤ情報を含む証明書発行要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれる新しいＩＤ情報等を、前記サービス提供部におけるユーザ情報データベースに登録することによって行われ、
前記認証局部における前記証明書関連情報の生成は、前記利用者操作部が、利用者の公開鍵を生成し、当該公開鍵を前記認証局部に送信し、前記認証局部が、受信した前記公開鍵と前記証明書発行要求とを用いて利用者の公開鍵証明書を生成することによって行われ、
前記生成結果情報は、生成した前記公開鍵証明書の発行者名、シリアル番号、利用者の公開鍵情報、記載属性型を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる生成した前記公開鍵証明書の発行者名、シリアル番号、利用者の公開鍵情報、記載属性型を、前記ＩＤ管理部におけるユーザ情報データベースに登録することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項３】
請求項１に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理要求及び前記プロビジョニング要求は、削除する利用者のＩＤ情報を含むＩＤ削除要求、利用停止するＩＤ情報を含むＩＤ利用停止要求、又は利用停止解除する利用者のＩＤ情報を含むＩＤ利用停止解除要求で実現され、
前記証明書管理要求は、削除、利用停止又は利用停止解除するＩＤをキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の発行者名、シリアル番号等を含む証明書失効要求、証明書利用停止要求又は証明書利用停止解除要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれるＩＤ情報を、前記サービス提供部におけるユーザ情報データベースに対して削除、利用停止又は利用停止解除することによって行われ、
前記認証局部における前記証明書関連情報の生成は、受信した前記失効情報の証明書失効要求に含まれる利用者の証明書の発行者名及びシリアル番号に合致する証明書を失効、利用停止又は利用停止解除することによって行われ、
前記生成結果情報は、失効、利用停止又は利用停止解除した前記証明書の発行者名及びシリアル番号等を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる失効、利用停止又は利用停止解除した証明書の発行者名及びシリアル番号に合致するユーザ情報を、前記ＩＤ管理部におけるユーザ情報データベースに対して削除、利用停止又は利用停止解除することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項４】
請求項１に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理要求及び前記プロビジョニング要求は、利用者の変更前のＩＤ情報と変更後の新しいＩＤ情報を含むＩＤ変更要求、又は利用者のＩＤ情報及び追加、変更もしくは削除する属性情報を含む属性変更要求で実現され、
前記証明書管理要求は、変更前のＩＤ情報をキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の発行者名、シリアル番号等を含む証明書失効要求と、利用者の新しいＩＤ情報を含む証明書発行要求、又はＩＤ情報をキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の発行者名、シリアル番号等を含む証明書失効要求と、利用者のＩＤ情報及び追加もしくは変更する属性情報を含む証明書発行要求、又は前記属性情報に対してさらに、ＩＤ情報をキーに前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の公開鍵情報を含む証明書発行要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれる変更前のＩＤ情報等を、前記サービス提供部におけるユーザ情報データベースから削除することと、受信した前記プロビジョニング要求に含まれる新しいＩＤ情報等を、前記サービス提供部におけるユーザ情報データベースに登録すること、又は受信した前記プロビジョニング要求に含まれるＩＤ情報及び追加、変更もしくは削除する属性情報をもとに、前記サービス提供部におけるユーザ情報データベース内の当該ＩＤ情報に関する属性情報を追加、変更もしくは削除することによって行われ、
前記認証局部における証明書関連情報の生成は、受信した前記証明書失効要求に含まれる利用者の証明書の発行者名及びシリアル番号に合致する証明書を失効することと、前記利用者操作部が、利用者の公開鍵を生成し、当該公開鍵を前記認証局部に送信し、前記認証局部が、受信した前記公開鍵と前記証明書発行要求とを用いて利用者の公開鍵証明書を生成すること、又は受信した前記公開鍵と前記証明書発行要求とを用いて、追加もしくは変更する属性情報を含んだ利用者の公開鍵証明書を生成すること、又は受信した前記証明書発行要求を用いて、追加もしくは変更する属性情報を含んだ利用者の公開鍵証明書を生成することによって行われ、
前記生成結果情報は、失効した前記証明書の発行者名及びシリアル番号等を含む情報と、生成した前記公開鍵証明書の発行者名、シリアル番号、利用者の公開鍵情報、記載属性型を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる失効した証明書の発行者名及びシリアル番号に合致するユーザ情報を、前記ＩＤ管理部におけるユーザ情報データベースから削除することと、受信した前記生成結果情報に含まれる生成した公開鍵証明書の発行者名、シリアル番号、利用者の公開鍵情報、記載属性型を、前記ＩＤ管理部におけるユーザ情報データベースに登録することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項５】
請求項１に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理要求及び前記プロビジョニング要求は、利用者のＩＤ情報及び追加する属性情報を含む属性追加要求で実現され、
前記証明書管理要求は、ＩＤ情報をキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の公開鍵証明書の発行者名、シリアル番号と、追加する属性情報を含む属性証明書発行要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれるＩＤ情報及び追加する属性情報をもとに、前記サービス提供部におけるユーザ情報データベース内の当該ＩＤ情報に関する属性情報を追加することによって行われ、
前記認証局部における証明書関連情報の生成は、受信した前記属性証明書発行要求を用いて利用者の属性証明書を生成することによって行われ、
前記生成結果情報は、生成した前記属性証明書の発行者名、シリアル番号、記載属性型を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる生成した属性証明書の発行者名、シリアル番号、記載属性型を、前記ＩＤ管理部におけるユーザ情報データベースに登録することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項６】
請求項１に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理要求及び前記プロビジョニング要求は、利用者のＩＤ情報及び変更もしくは削除する属性情報を含む属性変更要求、又は利用者のＩＤ情報及び削除する属性情報を含む属性削除要求で実現され、
証明書管理要求は、ＩＤ情報をキーに前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の記載属性型に変更もしくは削除する属性情報の型が包含される利用者の属性証明書の発行者名、シリアル番号を含む属性証明書失効要求と、ＩＤ情報をキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の公開鍵証明書の発行者名、シリアル番号と、変更する属性情報を含む属性証明書発行要求、又はＩＤ情報をキーに前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の記載属性型に削除する属性情報の型が包含される利用者の属性証明書の発行者名、シリアル番号を含む属性証明書失効要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれるＩＤ情報及び変更もしくは削除する属性情報をもとに、前記サービス提供部におけるユーザ情報データベース内の当該ＩＤ情報に関する属性情報を変更もしくは削除すること、又は受信した前記プロビジョニング要求に含まれるＩＤ情報及び削除する属性情報をもとに、前記サービス提供部におけるユーザ情報データベース内の当該ＩＤ情報に関する属性情報を削除することによって行われ、
前記認証局部における証明書関連情報の生成は、受信した前記属性証明書失効要求に含まれる利用者の属性証明書の発行者名及びシリアル番号に合致する属性証明書を失効することと、受信した前記属性証明書発行要求を用いて、変更する属性情報を含んだ利用者の属性証明書を生成すること、又は受信した前記属性証明書失効要求に含まれる利用者の属性証明書の発行者名及びシリアル番号に合致する属性証明書を失効することによって行われ、
前記生成結果情報は、失効した前記属性証明書の発行者名及びシリアル番号等を含む情報と、生成した前記属性証明書の発行者名、シリアル番号、記載属性型を含む情報、又は失効した前記属性証明書の発行者名及びシリアル番号等を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる失効した属性証明書の発行者名及びシリアル番号に合致する情報を、前記ＩＤ管理部におけるユーザ情報データベースから削除することと、受信した前記生成結果情報に含まれる生成した属性証明書の発行者名、シリアル番号、記載属性型を、前記ＩＤ管理部におけるユーザ情報データベースに登録すること、又は受信した前記生成結果情報に含まれる失効した属性証明書の発行者名及びシリアル番号に合致する情報を、前記ＩＤ管理部におけるユーザ情報データベースから削除することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項７】
利用者のＩＤに基づいてサービスを提供するシステムと、利用者の電子的な証明書に基づいてサービスを提供するシステムとが共存する環境において、利用者のＩＤ管理と証明書管理を一括して行うユーザ情報管理システムであって、
前記ユーザ情報管理システムは、ＩＤ管理を一元的に行うＩＤ管理部と、利用者のＩＤに基づいてＩＤを利用したサービスの提供を行う１つ以上のサービス提供部と、利用者の証明書及び失効情報の生成を行う認証局部と、前記サービス提供部を利用するユーザが前記ＩＤ管理部に対してＩＤ管理の申請操作を行う利用者操作部と、前記ＩＤ管理部に対して行われた申請に対して承認者が承認操作を行う承認者操作部とを備え、
前記利用者操作部は、利用者によって指定された、当該利用者のＩＤを管理するため必要なユーザ情報を含むＩＤ管理申請要求を、前記ＩＤ管理部に送信し、
前記ＩＤ管理部は、受信した前記ＩＤ管理申請要求に基づいて、要求されたＩＤ管理の実施に対する承認要求を、前記承認者操作部に前記承認者が知ることが可能な方法で通知し、
前記ＩＤ管理部からの通知を受けたことにより、前記承認者操作部は、前記承認要求に応じて、利用者から申請された前記ＩＤ管理申請要求に対する前記承認者の承認可否を含むＩＤ管理承認情報を、前記ＩＤ管理部に送信し、
前記ＩＤ管理部は、受信した前記ＩＤ管理申請要求及びＩＤ管理承認情報に基づいて、要求されたＩＤ管理の実施のために前記サービス提供部毎に必要とするユーザ情報を含むプロビジョニング要求を、全ての前記サービス提供部に送信するとともに、要求されたＩＤ管理の実施のために前記認証局部が必要とするユーザ情報を含む証明書管理要求を、前記認証局部に送信し、
前記サービス提供部は、受信した前記プロビジョニング要求に応じて、当該サービス提供部が管理しているユーザ情報データベースを更新し、
一方、前記認証局部は、受信した前記証明書管理要求に応じて、証明書関連情報を生成し、当該証明書関連情報内に存在する各種構成情報を含む生成結果情報を、前記ＩＤ管理部に送信し、
前記ＩＤ管理部は、受信した前記生成結果情報に基づいて、前記ＩＤ管理部が管理しているユーザ情報データベースを更新する
ことを特徴とするユーザ情報管理システム。
【請求項８】
請求項７に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理申請要求及び前記プロビジョニング要求は、利用者の新しいＩＤ情報を含むＩＤ登録申請要求で実現され、
証明書管理要求は、利用者の新しいＩＤ情報を含む証明書発行要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれる新しいＩＤ情報等を、前記サービス提供部におけるユーザ情報データベースに登録することによって行われ、
前記認証局部における証明書関連情報の生成は、前記利用者操作部が、利用者の公開鍵を生成し、当該公開鍵を前記認証局部に送信し、前記認証局部が、受信した前記公開鍵と前記証明書発行要求とを用いて利用者の公開鍵証明書を生成することによって行われ、
前記生成結果情報は、生成した前記公開鍵証明書の発行者名、シリアル番号、利用者の公開鍵情報、記載属性型を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる生成した公開鍵証明書の発行者名、シリアル番号、利用者の公開鍵情報、記載属性型を、前記ＩＤ管理部におけるユーザ情報データベースに登録することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項９】
請求項７に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理申請要求及び前記プロビジョニング要求は、削除する利用者のＩＤ情報を含むＩＤ削除要求、利用停止する利用者のＩＤ情報を含むＩＤ利用停止要求、又は利用停止解除する利用者のＩＤ情報を含むＩＤ利用停止解除要求で実現され、
証明書管理要求は、削除、利用停止又は利用停止解除するＩＤをキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の発行者名、シリアル番号を含む証明書失効要求、証明書利用停止要求又は証明書利用停止解除要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれるＩＤ情報等を、前記サービス提供部におけるユーザ情報データベースに対して削除、利用停止又は利用停止解除することによって行われ、
前記認証局部における証明書関連情報の生成は、受信した前記証明書失効要求、前記証明書利用停止要求又は前記証明書利用停止解除要求に含まれる利用者の証明書の発行者名及びシリアル番号に合致する証明書を失効、利用停止又は利用停止解除することによって行われ、
前記生成結果情報は、失効、利用停止又は利用停止解除した前記証明書の発行者名及びシリアル番号を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる失効、利用停止又は利用停止解除した証明書の発行者名及びシリアル番号に合致するユーザ情報を、前記ＩＤ管理部におけるユーザ情報データベースから削除することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項１０】
請求項７に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理申請要求及び前記プロビジョニング要求は、利用者の変更前のＩＤ情報と変更後の新しいＩＤ情報を含むＩＤ変更要求、又は利用者のＩＤ情報及び追加、変更もしくは削除する属性情報を含む属性変更要求で実現され、
証明書管理要求は、変更前のＩＤ情報をキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の発行者名、シリアル番号等を含む証明書失効要求と、利用者の新しいＩＤ情報を含む証明書発行要求、又はＩＤ情報をキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の発行者名、シリアル番号等を含む証明書失効要求と、利用者のＩＤ情報及び追加もしくは変更する属性情報を含む証明書発行要求、又は前記属性情報に対してさらに、ＩＤ情報をキーに前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の公開鍵情報を含む証明書発行要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれる変更前のＩＤ情報等を、前記サービス提供部におけるユーザ情報データベースから削除することと、受信した前記プロビジョニング要求に含まれる新しいＩＤ情報等を、前記サービス提供部におけるユーザ情報データベースに登録すること、又は受信した前記プロビジョニング要求に含まれるＩＤ情報及び追加、変更もしくは削除する属性情報をもとに、前記サービス提供部におけるユーザ情報データベース内の当該ＩＤ情報に関する属性情報を追加、変更もしくは削除することによって行われ、
前記認証局部における証明書関連情報の生成は、受信した前記証明書失効要求に含まれる利用者の証明書の発行者名及びシリアル番号に合致する証明書を失効することと、前記利用者操作部が、利用者の公開鍵を生成し、当該公開鍵を前記認証局部に送信し、前記認証局部が、受信した前記公開鍵と前記証明書発行要求とを用いて利用者の公開鍵証明書を生成すること、又は受信した前記公開鍵と前記証明書発行要求とを用いて、追加もしくは変更する属性情報を含んだ利用者の公開鍵証明書を生成すること、又は受信した前記証明書発行要求を用いて、追加もしくは変更する属性情報を含んだ利用者の公開鍵証明書を生成することによって行われ、
前記生成結果情報は、失効した前記証明書の発行者名及びシリアル番号を含む情報と、生成した前記公開鍵証明書の発行者名、シリアル番号、利用者の公開鍵情報、記載属性型を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる失効した証明書の発行者名及びシリアル番号に合致するユーザ情報を、前記ＩＤ管理部におけるユーザ情報データベースから削除することと、受信した前記生成結果情報に含まれる生成した公開鍵証明書の発行者名、シリアル番号、利用者の公開鍵情報、記載属性型を、前記ＩＤ管理部におけるユーザ情報データベースに登録することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項１１】
請求項７に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理申請要求及び前記プロビジョニング要求は、利用者のＩＤ情報及び追加する属性情報を含む属性追加要求で実現され、
前記証明書管理要求は、ＩＤ情報をキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の公開鍵証明書の発行者名、シリアル番号等と、追加する属性情報を含む属性証明書発行要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれるＩＤ情報及び追加する属性情報をもとに、前記サービス提供部におけるユーザ情報データベース内の当該ＩＤ情報に関する属性情報を追加することによって行われ、
前記認証局部における証明書関連情報の生成は、受信した前記属性証明書発行要求を用いて利用者の属性証明書を生成することによって行われ、
前記生成結果情報は、生成した前記属性証明書の発行者名、シリアル番号、記載属性型を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる生成した属性証明書の発行者名、シリアル番号、記載属性型を、前記ＩＤ管理部におけるユーザ情報データベースに登録することによって行われる
ことを特徴とするユーザ情報管理システム。
【請求項１２】
請求項７に記載のユーザ情報管理システムにおいて、
前記ＩＤ管理申請要求及び前記プロビジョニング要求は、利用者のＩＤ情報及び変更もしくは削除する属性情報を含む属性変更要求、又は利用者のＩＤ情報及び削除する属性情報を含む属性削除要求で実現され、
前記証明書管理要求は、ＩＤ情報をキーに前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の記載属性型に変更もしくは削除する属性情報の型が包含される利用者の属性証明書の発行者名、シリアル番号を含む属性証明書失効要求と、ＩＤ情報をキーに、前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の公開鍵証明書の発行者名、シリアル番号と、変更する属性情報を含む属性証明書発行要求、又はＩＤ情報をキーに前記ＩＤ管理部が管理しているユーザ情報データベースから検索される利用者の証明書の記載属性型に削除する属性情報の型が包含される利用者の属性証明書の発行者名、シリアル番号を含む属性証明書失効要求で形成され、
前記サービス提供部におけるユーザ情報データベースの更新は、受信した前記プロビジョニング要求に含まれるＩＤ情報及び変更もしくは削除する属性情報をもとに、前記サービス提供部におけるユーザ情報データベース内の当該ＩＤ情報に関する属性情報を変更もしくは削除すること、又は受信した前記プロビジョニング要求に含まれるＩＤ情報及び削除する属性情報をもとに、前記サービス提供部におけるユーザ情報データベース内の当該ＩＤ情報に関する属性情報を削除することによって行われ、
前記認証局部における証明書関連情報の生成は、受信した前記属性証明書失効要求に含まれる利用者の属性証明書の発行者名及びシリアル番号に合致する属性証明書を失効することと、受信した前記属性証明書発行要求を用いて、変更する属性情報を含んだ利用者の属性証明書を生成すること、又は受信した前記属性証明書失効要求に含まれる利用者の属性証明書の発行者名及びシリアル番号に合致する属性証明書を失効することによって行われ、
前記生成結果情報は、失効した前記属性証明書の発行者名及びシリアル番号を含む情報と、生成した前記属性証明書の発行者名、シリアル番号、記載属性型を含む情報、又は失効した前記属性証明書の発行者名及びシリアル番号を含む情報で形成され、
前記ＩＤ管理部におけるユーザ情報データベースの更新は、受信した前記生成結果情報に含まれる失効した属性証明書の発行者名及びシリアル番号に合致する情報を、前記ＩＤ管理部におけるユーザ情報データベースから削除することと、受信した前記生成結果情報に含まれる生成した属性証明書の発行者名、シリアル番号、記載属性型を、前記ＩＤ管理部におけるユーザ情報データベースに登録すること、又は受信した前記生成結果情報に含まれる失効した属性証明書の発行者名及びシリアル番号に合致する情報を、前記ＩＤ管理部におけるユーザ情報データベースから削除することによって行われる
ことを特徴とするユーザ情報管理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【公開番号】特開２００８−２３４４５１（Ｐ２００８−２３４４５１Ａ）
【公開日】平成２０年１０月２日（２００８．１０．２）
【国際特許分類】
【出願番号】特願２００７−７５１２２（Ｐ２００７−７５１２２）
【出願日】平成１９年３月２２日（２００７．３．２２）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２０年１０月２日（２００８．１０．２）
【国際特許分類】
【出願日】平成１９年３月２２日（２００７．３．２２）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]