(57)【要約】【課題】  本発明は一般に、認証、許可、およびアクセス制御に関し、より詳細には、ユーザがすべてのサービスに安全にアクセスするために１つの電子ＩＤのみを有することができるようにする一般的な公開鍵インフラストラクチャ・ベースの認証のための方法およびシステムを提供すること。【解決手段】  本システムは、一般的なＰＫＩベースの認証を提供することにより、最新技術を進歩させるものである。妥当性検査とおそらく許可サービスも他のサービス・プロバイダに提供することにより、本システムは一般的なＰＫＩベースの認証のためのインフラストラクチャを提供することができ、原則としてこのような任意の発行者からの電子ＩＤを処理する。
2005521279.tif 000002
【特許請求の範囲】
【請求項１】
サービス・プロバイダからの少なくとも１つのサービスへのセキュア・サービス・アクセスをユーザに提供するためのシステムであって、共通コンピュータ・ネットワークに接続するための手段が前記ユーザおよび前記サービス・プロバイダに提供されるシステムにおいて、
１つまたは複数の妥当性検査サービス・ユニットであって、
アクセス・サーバからユーザ証明書内の名前を受信するステップと、
前記ユーザ証明書の妥当性を制御するステップと、
前記ユーザの証明書が有効である場合に、ユーザ名に変換するために許可サービス・ユニットに前記ユーザの証明書名を送信し、前記許可サービス・ユニットから返される前記ユーザ名を前記アクセス・サーバに渡すか、または前記ユーザの証明書名を前記アクセス・サーバに渡すステップと、
前記ユーザの証明書が有効ではない場合に、前記サービスへの前記ユーザ・アクセスを否定するステップと
を実行するために配置された１つまたは複数の妥当性検査サービス・ユニットと、
１つまたは複数の許可サービス・ユニットであって、
妥当性検査サービス・ユニットまたはアクセス・サーバからユーザの証明書名を受信するステップと、
前記ユーザの証明書名をデータベースに送信するステップと、
前記データベースからユーザ名およびプロファイルを受信するステップと、
名前付きユーザＩＤを前記妥当性検査サービス・ユニットまたは前記アクセス・サーバに渡すステップと、
アクセス・サーバからアクセス権に関する照会を受信するステップと、
前記データベースからの加入情報について照会するステップと、
前記データベースから加入情報を受信するステップと、
前記加入情報に基づいてアクセス権を決定するステップと、
アクセス権を前記アクセス・サーバに渡すステップと
を実行するために配置された１つまたは複数の許可サービス・ユニットと、
１つまたは複数の許可役割ユニットおよび隣接データベースであって、
許可サービス・ユニットからユーザの証明書を受信するステップと、
前記データベース内の前記ユーザの名前およびプロファイルを突き止めるステップと、
ユーザの名前およびプロファイルを前記許可サービス・ユニットに送信するステップと、
許可サービス・ユニットから加入情報に関する照会を受信するステップと、
加入情報を前記許可サービス・ユニットに送信するステップと
を実行するために配置された１つまたは複数の許可役割ユニットおよび隣接データベースと
を有するシステム。
【請求項２】
少なくとも１つのアクセス・サーバであって、
前記ユーザから要求を受信するステップと、
ユーザに対して認証し、クライアント許可を要求するステップと、
呼掛け／応答シーケンスを実行するステップと、
証明書および秘密鍵の所有の証拠を前記ユーザから要求するステップと、
前記証明書内の前記名前を妥当性検査サービス・ユニットに渡すステップと、
有効なユーザ証明書の場合に、名前付きユーザＩＤを許可サービス・ユニットから受信するステップと、
アクセス権について許可サービス・ユニットに照会するステップと、
前記許可サービス・ユニットからアクセス権を受信するステップと、
適切なサービス・メニューを突き止めるステップと、
前記サービス・メニューを前記ユーザに提示するステップと、
前記ユーザと前記サービス・プロバイダとの間で情報を転送するステップと
を実行するために配置された少なくとも１つのアクセス・サーバをさらに有する、請求項１に記載のシステム。
【請求項３】
前記アクセス・サーバが、
ＨＴＴＰＳまたは通信チャネルを保護するための他の手段をサポートし、
好ましくはＰＫＩ技術の使用によりクライアント／ユーザに対して前記アクセス・サーバを認証し、
前記妥当性検査サービスおよび前記許可サービス・ユニットと通信するために必要なプロトコルをサポートし、
ＰＫＩベースのクライアント／ユーザ認証のために１つまたは複数のプロトコルをサポートし、
前記ユーザに対して情報を表示し、ユーザ入力を処理するために必要な機能性を実現し、
前記ユーザとサービスとの間のプロキシ・サーバとして動作する
ための手段を有する、請求項１または２に記載のシステム。
【請求項４】
前記ユーザから証明書および秘密鍵を要求するステップが、ディレクトリ・ルックアップを使用することにより実行可能である、請求項１または２に記載のシステム。
【請求項５】
前記アクセス・サーバが、シングル・サインオン方式で前記サービスへの直接アクセスを仲介するために適合される、請求項１または２に記載のシステム。
【請求項６】
前記ユーザ名およびプロファイルを記憶する前記データベースが、他のユーザ関連情報も記憶する、請求項１または２に記載のシステム。
【請求項７】
前記アクセス・サーバが、前記通信チャネルを保護するための他の手段を使用するときに、前記サーバ認証のみによりＳＳＬ／ＴＬＳセッションを確立し、前記確立した安全なチャネル上で前記ユーザ認証プロトコルを実行する、請求項３に記載のシステム。
【請求項８】
認証方法について複数の代替策がある場合に、前記ユーザに対して前記代替策が提示され、前記アクセス・サーバが、選択したクライアント認証の方法によりＳＳＬ／ＴＬＳセッションを確立する、請求項３に記載のシステム。
【請求項９】
前記サービス・プロバイダが、前記システムに含まれ、前記許可サービス・ユニットにアクセスして前記許可サービス・ユニットと情報を交換するために適合される、請求項５に記載のシステム。
【請求項１０】
前記妥当性検査サービス・ユニット、前記許可サービス・ユニット、および前記許可役割ユニットがコンピュータで実現される、請求項１ないし９のうちの一項に記載のシステム。
【請求項１１】
ビデオ・オン・デマンドなどの付加価値サービスへの認証、許可、およびアクセスを提供するための請求項１または２に記載のシステムの使用法。
【請求項１２】
前記情報が暗号化によって保護される、請求項１０に記載の使用法。
【請求項１３】
サービス・プロバイダからの少なくとも１つのサービスへのセキュア・サービス・アクセスをユーザに提供するための方法であって、共通コンピュータ・ネットワークに接続するための手段が前記ユーザおよび前記サービス・プロバイダに提供される方法において、
１つまたは複数の妥当性検査サービス・ユニットにより、
アクセス・サーバからユーザ証明書内の名前を受信するステップと、
前記ユーザ証明書の妥当性を制御するステップと、
前記ユーザの証明書が有効である場合に、ユーザ名に変換するために許可サービス・ユニットに前記ユーザの証明書名を送信し、前記許可サービス・ユニットから返される前記ユーザ名を前記アクセス・サーバに渡すか、または前記ユーザの証明書名を前記アクセス・サーバに渡すステップと、
前記ユーザの証明書が有効ではない場合に、前記サービスへの前記ユーザ・アクセスを否定するステップと、
１つまたは複数の許可サービス・ユニットにより、
妥当性検査サービス・ユニットまたはアクセス・サーバからユーザの証明書名を受信するステップと、
前記ユーザの証明書名をデータベースに送信するステップと、
前記データベースからユーザ名およびプロファイルを受信するステップと、
名前付きユーザＩＤを前記妥当性検査サービス・ユニットまたは前記アクセス・サーバに渡すステップと、
アクセス・サーバからアクセス権に関する照会を受信するステップと、
前記データベースからの加入情報について照会するステップと、
前記データベースから加入情報を受信するステップと、
前記加入情報に基づいてアクセス権を決定するステップと、
アクセス権を前記アクセス・サーバに渡すステップと、
１つまたは複数の許可役割ユニットおよび隣接データベースにより、
許可サービス・ユニットからユーザの証明書を受信するステップと、
前記データベース内の前記ユーザの名前およびプロファイルを突き止めるステップと、
ユーザの名前およびプロファイルを前記許可サービス・ユニットに送信するステップと、
許可サービス・ユニットから加入情報に関する照会を受信するステップと、
加入情報を前記許可サービス・ユニットに送信するステップと
を有する方法。
【請求項１４】
少なくとも１つのアクセス・サーバによって実行されるステップであって、
前記ユーザから要求を受信するステップと、
ユーザに対して認証し、クライアント許可を要求するステップと、
呼掛け／応答シーケンスを実行するステップと、
証明書および秘密鍵の所有の証拠を前記ユーザから要求するステップと、
前記証明書内の前記名前を妥当性検査サービス・ユニットに渡すステップと、
有効なユーザ証明書の場合に、名前付きユーザＩＤを許可サービス・ユニットから受信するステップと、
アクセス権について許可サービス・ユニットに照会するステップと、
前記許可サービス・ユニットからアクセス権を受信するステップと、
適切なサービス・メニューを突き止めるステップと、
前記サービス・メニューを前記ユーザに提示するステップと、
前記ユーザと前記サービス・プロバイダとの間で情報を転送するステップと
をさらに有する、請求項１３に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、認証、許可、およびアクセス制御に関し、より詳細には、ユーザがすべてのサービスに安全にアクセスするために１つの電子ＩＤのみを有することができるようにする一般的なＰＫＩ（公開鍵インフラストラクチャ）ベースの認証のための方法およびシステムに関する。
【背景技術】
【０００２】
認証、許可、およびアクセス制御は、たいていの（通信）サービス・プロバイダにとって不可欠な３つの分野である。唯一の例外は、完全公開サービスと匿名ペイパーユース・サービスである。本明細書では、特定のサービスの使用に対して名前付きユーザが許可される通常の状況を扱う。認証が成功すると、ユーザは、アクセス制御手順を条件として、これらのサービスにアクセスすることができる。
【０００３】
ＩＰ（インターネット・プロトコル）ベースの通信インフラストラクチャのＩＳＰ（インターネット・サービス・プロバイダ）または他のプロバイダに対する現在の認証ソリューションは主にユーザ名およびパスワードに基づくものである。ＲＡＤＩＵＳ（遠隔認証ダイヤルイン・サービス）プロトコル（およびＴＡＣＡＣＳ（端末アクセス・コントローラ・アクセス制御システム）のような他のプロトコル）は、（認証済み）ユーザ名に割り当てられた認証情報と許可の両方の集中管理および妥当性検査を行うサービスへのアクセスを可能にする。ＩＥＴＦ（インターネット技術タスク・フォース）における作業は、ＤＩＡＭＥＴＥＲ作業部会により次世代のこのようなプロトコルに向けて進行中である。
【０００４】
通常、ユーザは、サービスごとに個別のパスワードを備えている必要がある。特に、各サービスは通常、個別のパスワード認証を必要とするので、より一層多くのサービスが提供されるにつれて、パスワードベースの認証が複雑なものになる。この複雑さを管理するために、ユーザは概して、覚えやすいパスワードを選択し、同じ（ユーザ名および）パスワードを何度も使用する。
【０００５】
より一層多くの付加価値サービスがインターネットにより提供されるにつれて、公開ＰＫＩ（公開鍵インフラストラクチャ）ベースのユーザ認証をユーザに提供して、パスワードベースの認証の複雑さおよび弱点を置き換え、サービスの窃盗からユーザを保護し、ログイン手順を単純にする（すべてのサービスにアクセスするために１つの電子ＩＤ）ことは重要なことである。また、詐欺から顧客およびサービス・プロバイダを保護するために、強力な認証も必要になる。
【０００６】
ＰＫＩ分野の最新技術はまだこのレベルの一般性に到達していない。その代わりに、現在、ユーザは、異なるサービスにアクセスするために異なるＰＫＩソリューション（異なるユーザ名およびパスワードの代わり）の使用に直面する場合が多い。また、現在、「ＰＫＩ使用可能」であるサービスはあまり多くないが、この機能性は、ＳＳＬ／ＴＬＳ（セキュア・ソケット層／トランスポート層セキュリティ）クライアント認証手順の形で多くのサービスにとって潜在的なものである可能性がある。上記のシステムは、一般的なＰＫＩベースの認証を提供することにより、最新技術を進歩させるものである。妥当性検査とおそらく許可サービスも他のサービス・プロバイダに提供することにより、このシステムは一般的なＰＫＩベースの認証のためのインフラストラクチャを提供することができる。
【０００７】
本明細書では、証明書およびＰＫＩ技術の使用ならびにコンピュータ・ネットワークにより提供される支払サービスのメカニズムを使用可能にすることにより、認証、許可、およびアクセス制御のための改良されたソリューションについて記載する。ＰＫＩソリューションの主な美点は、一般性と、スケーラビリティと、機能性の増加（暗号化のための鍵管理、ディジタル署名）である。将来、ユーザは、ユーザの電子ＩＤを形成する秘密鍵と証明書を収容する１つの鍵容器（たとえば、スマート・カード）を持たなければならない。電子ＩＤは、通常、異なる目的のための２つまたは３つの異なる秘密鍵／証明書のペアからなる。たいていのソリューションでは２つのペアを使用し、１つは暗号化用であり（この特定の秘密鍵のみのバックアップを可能にする）、もう１つは他のすべての目的用である。ディジタル署名機能が個別の第３のペアに起因することは往々にして推奨されることであるが、これは製品またはサービスの点で広範なサポートを達成していない。
【０００８】
ユーザは、電子ＩＤの発行者（証明書サービス・プロバイダ）を自由に選択できなければならない。ユーザがアクセスを希望するサービスは、特定の証明書発行者の使用を義務づけてはならない。ユーザは、所望通りの数の電子ＩＤを自由に入手できなければならない。
【０００９】
現在、ユーザのＰＫＩベースの認証を使用するサービス・プロバイダは概して、１つまたはいくつかの証明書発行者のみから証明書を受け入れることができる。複数の証明書サービスはそれぞれ異なるので、サービス・プロバイダは、ある程度、すべての発行者に対して個別に統合されなければならない。２〜３以上の発行者からの証明書を受け入れることになっている場合、これは直ちに有用ではなくなるほど複雑すぎるものになる。
【００１０】
同時に、世界には少なくとも数百の公開証明書サービス・プロバイダが存在し、さらに多くのものが現れる。また、サービス・プロバイダは、種々雑多な企業の内部証明書サービス（イントラネット使用では通常のもの）からの証明書を受け入れることを希望する可能性もある。
【００１１】
上記のアーキテクチャは、多数の証明書発行者に対する統合の複雑さを専用コンポーネントに分割し、したがって、サービス自体からこの複雑さを取り除く。ユーザは、そのユーザが使用することを希望する電子ＩＤ（複数も可）（すなわち、証明書（複数も可））を登録しなければならない。証明書内の名前と、その品質レベルのような他の特徴は、ユーザのサービス・プロファイルにリンクされる。
【００１２】
サービス・プロファイルは単一箇所で維持される。所与のサービスは、アクセスを可能にするために高品質の電子ＩＤを要求する可能性もある。
【００１３】
証明書内の名前はユーザの実名である必要はない。ポリシーを条件として、これは、仮名、役割名、組織のＩＤ、加入名などにすることができる。
【００１４】
電子ＩＤを使用すると、ユーザは、その後、ネットワークにログオンし、ユーザが加入したすべてのサービスにアクセスすることができる。上記のシステムは、このために用意されたサービスに対するシングル・サインオンを可能にすることができる。それ専用の認証を必要とするサービスに対するこのシステムの美点は、各サービスごとに異なるパスワードを維持する必要性の代わりに、ユーザの電子ＩＤを再利用できることである。ユーザは、何度も正当性を証明しなければならないが、いつでも同じ方法を使用する。これは、上記の妥当性検査サービスの可用性と、ある程度は許可サービスも当てにしている。
【００１５】
このシステムの柔軟性により、ユーザは、オペレーティング・システムを自由に選択することもできる。電子ＩＤソリューション用のソフトウェアは往々にしてプラットフォーム依存である。公開ＰＫＩソリューションでは、ユーザは、好みのオペレーティング・システムによってサポート可能な電子ＩＤを選択することができる。
【００１６】
クレジット・カード会社はインターネットによる支払についてユーザ認証を要求し始めており、パスワード認証は短期的に受入れ可能になるだけであろう。一般的なＰＫＩを確立すると、クレジット・カード会社は、支払を行う際に使用するために個別の電子ＩＤを発行する必要性の代わりに、すでにユーザ（それが資格を与えていることを条件とする）が所有している電子ＩＤを受け入れることができるようになる。
【発明の開示】
【発明が解決しようとする課題】
【００１７】
上記のシステムは、ビデオ・オン・デマンド（ＶＯＤ）などの付加価値サービスのための認証、許可、およびアクセス制御を保護するための手段を提供するとともに、支払を保護するための手段を提供することになる。
【課題を解決するための手段】
【００１８】
本発明は一般に、認証、許可、およびアクセス制御に関し、より詳細には、ユーザがすべてのサービスに安全にアクセスするために１つの電子ＩＤのみを有することができるようにする一般的な公開鍵インフラストラクチャ・ベースの認証のための方法およびシステムに関する。上記のシステムは、一般的なＰＫＩベースの認証を提供することにより、最新技術を進歩させるものである。妥当性検査とおそらく許可サービスも他のサービス・プロバイダに提供することにより、このシステムは一般的なＰＫＩベースの認証のためのインフラストラクチャを提供することができる。
【００１９】
本発明は、特許請求の範囲の独立請求項１に記載されたシステムに関する。さらに、本発明は、特許請求の範囲の独立請求項１１に記載された使用法に関する。また、本発明は、特許請求の範囲の独立請求項１３に記載された方法に関する。本発明の有利な諸実施形態は従属請求項に記載されている。
【発明を実施するための最良の形態】
【００２０】
図１は本発明によるシステム・アーキテクチャを示している。ユーザは、概してＳＳＬ／ＴＬＳクライアント認証により認証され、加入した１組のサービスに関するメニューを備えたウェブ・インターフェースに対し、アクセス・サーバ上でアクセスすることができる。クライアントとアクセス・サーバとの通信は暗号により保護しなければならない。これはウェブ（ＨＴＴＰ）通信を保護する通常の方法であり、ユーザ認証を組み込むことができるので、ＳＳＬ／ＴＬＳは好ましいオプションである。２つの部分間のＩＰＳｅｃ／ＶＰＮ（インターネット・プロトコル・セキュリティ／仮想プライベート・ネットワーク）に基づくソリューションは１つの代替策にすることができる。
【００２１】
適用される認証プロトコル（クライアントおよびサーバ認証の両方を備えたＳＳＬ／ＴＬＳなど）は暗黙のうちに、プロトコルの一部としてアクセス・サーバに渡されるユーザの証明書内の名前によってユーザを識別する。また、ユーザは、秘密鍵の所有を証明する呼掛け／応答シーケンスに署名するために、対応する秘密鍵も使用しなければならない。
【００２２】
ユーザの証明書と署名が与えられると、アクセス・サーバはユーザ認証プロセスを完了することができる。しかし、種々の証明書発行者からの種々の証明書を可能にするように取消しチェックにより適切に実行されると、証明書妥当性検査は各アクセス・サーバ上で実行するにははるかに過重なプロセスである。このアーキテクチャでは、証明書処理（の一部）の責任（および負荷）を負うために、個別コンポーネントである妥当性検査サービスが導入されている。妥当性検査サービスは、必要であれば、複製することができる。最終的に、アクセス・サーバは、単にユーザの証明書を抽出し、それを妥当性検査サービスに送り出すことができる。戻りは、証明書の妥当性に関するＹＥＳ／ＮＯ回答、その品質レベル（授与可能な許可に関して関連性のあるものである可能性がある）、ユーザの証明書内の名前から導出されるユーザ名、およびおそらく所望であれば、より多くの情報である。しかし、たとえば、アクセス・サーバ上でローカルにたいていの証明書処理を実行し、主に取消しチェックの（通常はリソースを消費する）タスクを妥当性検査サービスに任せることにより、アクセス・サーバと妥当性検査サービスとの間でその負荷をそれぞれ異なるように分割することもできる。
【００２３】
ユーザのプロファイルは一箇所に、すなわち、許可サービスに保持しなければならない。ユーザの証明書名から対応するユーザ名へのマッピングはプロファイルの一部であり、その結果として、証明書から名前を抽出した後でこのマッピングを入手するために妥当性検査サービスは許可サービスを呼び出す。別法として、妥当性検査サービスはアクセス・サーバに証明書名を返すことができ、次にそのサーバが許可サービスへの個別呼出しにより名前マッピングを実行することができる。この場合、妥当性検査サービスと許可サービスとの間のインターフェースはまったく存在しない。
【００２４】
図２は、認証、許可チェック、およびサービス・アクセス・プロセスの流れ図を示している。妥当性検査サービスに対して、いくつかのプロトコルを使用することができる。妥当性検査サービスを個別サービスとしてサービス・プロバイダに提供することになっている場合、プロトコルは標準タイプのものでなければならない。ＯＣＳＰｖ１（オンライン証明書状況プロトコル、バージョン１）は、証明書の取消し状況をチェックし、ユーザ名のような何らかの追加情報を返すことを可能にする代替策である。しかし、非指定「拡張」の使用のみにより、標準化した方法で妥当性検査サービスに完全な証明書を回すことは不可能である。ＯＣＳＰｖ２は、高度なドラフトＲＦＣに含まれており、完全な証明書を送信する可能性を提供することになる。ＳＣＶＰ（単純証明書妥当性検査プロトコル）は、ＯＣＳＰｖ２と同じ状況を有し、同じ機能性を提供する。ＸＫＭＳ（ＸＭＬ鍵管理サービス）は、たとえば、ＳＯＡＰ（単純オブジェクト・アクセス・プロトコル）を使用する他のＸＭＬベースのメカニズムと同様に、もう１つの代替策である。
【００２５】
認証済みユーザＩＤが与えられると、アクセス・サーバは、名前付きユーザに授与すべきアクセス権について許可サービスに照会する。この照会は、ユーザの認証手順の品質のような追加情報と、ユーザの現在位置、時刻などのようなコンテキスト情報によって増強することができる。許可サービスへのアクセスは標準のプロトコルに基づくものでなければならず、そのプロトコルはＬＤＡＰ（軽量ディレクトリ・アクセス・プロトコル）、ＲＡＤＩＵＳ、その計画後継プロトコルＤＩＡＭＥＴＥＲ、またはその他の何らかのプロトコルにすることができる。
【００２６】
また、許可サービスに対するルックアップを妥当性検査サービスに委任することも可能である。この場合、アクセス・サーバは、妥当性検査サービスへの呼出しのみを実行し、ユーザ名および上記の通りの認証手順に関連するその他の情報と、ユーザに授与されることになっている許可の両方を取り戻すことになる。
【００２７】
この手順に従うと、ユーザは、正しいサービス・メニューが提示されることになる。下記の通り、次のステップはサービス選択である。
【００２８】
図２の流れ図は、認証、許可チェック、およびサービス・アクセス手順で実行される諸ステップを示している。
【００２９】
以下に、サービスに対する典型的な接続セットアップおよびアクセスについて説明する。ユーザの機器またはホーム・ネットワークは、ある種のアクセス・ポイントを介してネットワーク・オペレータによって提供されるインフラストラクチャに接続され、そのアクセス・ポイントは概して、データ・リンクまたはアクセス層およびネットワーク層におけるプロトコル、すなわち、ＩＰプロトコルを提供する。アクセス・ポイントは、ユーザからアクセス・サーバへのウェブ・アクセスに関するルータとしてのみ動作するので、図１には示されていない。アクセス・ポイントは２つのコンポーネントに分割することができ、一方はデータ・リンク／アクセス層でサービスを提供し、もう一方はＩＰルータになる。
【００３０】
ユーザ機器がネットワーク・インフラストラクチャに接続すると、その機器は概して、デフォルトの最小限の許容通信経路セットにアクセスできるようになる。図示のアーキテクチャでは、アクセス・サーバに対するルートは使用可能になっていなければならず、通常、ドメイン・ネーム・サービス（ＤＮＳ）も使用可能になる。さらに複数のサービス／経路をこの最小構成に追加することができる。
【００３１】
ユーザがユーザの機器上でブラウザを開くと、これは、ユーザがサービスにアクセスするために、アクセス・サーバにおいてあるＵＲＬに向けられなければならない。次にユーザは、認証手順および許可チェックを通過しなければならず、サービス・メニューにアクセスできるようになる。
【００３２】
基本的に、通信サービス、ウェブベース・サービス、マルチメディアを含むメディア・サービスという３つのタイプのサービスが使用可能である。第３のカテゴリは、他の２つの組み合わせとして説明することができる。それぞれのカテゴリについて行われるアクションについては以下に説明する。
【００３３】
通信サービス：ユーザが通信サービスを選択すると、選択した宛先に対するルートを使用可能にするために、この要求をユーザのアクセス・ポイントに仲介する必要がある。このルートは、ユーザのＩＰアドレス（複数も可）（の範囲）から所与の宛先（複数も可）（の範囲）へのトラフィックのために開放され、ＩＰ層で使用可能にすることができる。また、このルートは、たとえば、ＡＴＭ（非同期転送モード）仮想回線の確立により、データ・リンク層でも使用可能にすることができる。
【００３４】
通信サービスの一例は、ＩＳＰによる一般的なインターネット・アクセスにすることができる。サービス・メニュー内でインターネット・アクセスを選択すると、ユーザからＩＳＰのアクセス・ノード（ボーダ・ルータ）へのルートが使用可能になり、そのノードからアクセスを続行することができる。
【００３５】
アクセス・サーバは、要求された通信サービスを使用可能にするために、ユーザのアクセス・ポイントに正しいコマンドを仲介する必要がある。この目的のためにいくつかのプロトコルを使用することができ、ＲＡＤＩＵＳは最も一般的な代替策である。ＤＩＡＭＥＴＥＲはＲＡＤＩＵＳの計画後継プロトコルである。
【００３６】
アクセス・サーバ上のサービス・メニューからウェブベース・サービスへのユーザ・アクセスについては３通りのシナリオが存在する。
【００３７】
第１のシナリオでは、アクセス・サーバは、シングル・サインオン・トークンをサービスに渡すことにより、シングル・サインオン方式でサービスへの直接アクセスを仲介する。最も単純な形式では、これはＨＴＴＰポスト操作におけるサービス用のユーザ名およびパスワードであり、したがって、そのサービスに対して透過的にユーザをログオンする。その場合、ユーザがサービスにリダイレクトされるか、またはアクセス・サーバがＨＴＴＰプロキシ媒介として操作を続行する。シングル・サインオン用のいくつかの製品および技術が使用可能であり、このような技術によるトークンを使用することができる。おそらく、アクセス・サーバはユーザのブラウザにクッキーを書き込むこともでき、それは、ユーザがサービスに直接アクセスするときにシングル・サインオン・トークンとして認識され受け入れられることになる。サービスは、たとえば、サービス利用に関連するより詳細な特権をチェックするために、許可サービスにアクセスできる可能性がある。
【００３８】
第２のシナリオでは、サービスは、上記のシステムのドメイン内で提供されるが、個別の認証を必要とする。ユーザの電子ＩＤ（秘密鍵および証明書）はサービスに対して使用され、すなわち、ユーザは単一メカニズムを有する。サービスは妥当性検査サービスにアクセスでき、許可サービスも使用することができる。
【００３９】
第３のシナリオでは、サービスは上記のシステムのドメイン外で提供される。このような認証についてサービスが使用可能になっている場合、ユーザの電子ＩＤ（秘密鍵および証明書）が使用され、すなわち、ユーザは単一メカニズムを有する。サービスは妥当性検査サービスにアクセスできるが、それはシステムのドメイン内にないので、通常、許可サービスにアクセスできなくなる。
【００４０】
妥当性検査サービスは一般的なサービスであり、これはシステムのドメイン内外両方の協働当事者に提供することができる。妥当性検査サービスは、それを呼び出すサービスに依存する異なる情報（たとえば、異なるユーザ名）を返すように構成することができる。これは、ＰＫＩベースの認証の一般的性質の直接の結果である。パスワードが外部当事者に漏れる恐れがあるので、パスワードベースの認証に関してこの種のアクセスを許可することはできない。
【００４１】
しかし、許可サービスは、通常、システムのドメイン内でのみアクセス可能でなければならない。ドメイン内部許可情報へのアクセスを外部当事者に許可することまたは同じサービスにより許可情報を管理することは、たいていの場合、受け入れられないものになる。
【００４２】
メディア／マルチメディア・サービス：  上述の通り、（マルチ）メディア・サービスは、通信サービスとウェブベース・サービスの組み合わせと見なすことができる。いくつかのメディア・サービスは完全にウェブベースまたは通信として実現することができるが、通常のシナリオは、サービス・セットアップのためのウェブベース・インターフェースを提供するサービスであり、ネットワーク内の機能性を当てにするサービス実現である。
【００４３】
アクセス・サーバがユーザとメディア・サービスとの間のプロキシとして動作する場合、それは通信をインターセプトし、両者間のＶＰＮの開始またはマルチキャスト・メンバシップ・システムへの情報提供のようなサポート・アクションを実行することができる。
【００４４】
図３は、ユーザ証明書の妥当性をチェックする代替方法を示している。ユーザの証明書名を許可サービスに送信する代わりに、その証明書名はアクセス・サーバに送信され、次にアクセス・サーバは許可サービスから名前付きユーザＩＤを受信する。
【００４５】
図４は、ビデオ・オン・デマンド（ＶＯＤ）ならびにセキュア・ペイメント（ペイパーユース・ベース）などの付加価値サービスへの認証、許可、およびアクセスの一例を示している。
【００４６】
ユーザは、図１に記載した認証アーキテクチャを使用して認証される。コンテンツはセッションの全期間の間、暗号化によって保護され、支払はペイパーユース・ベースで保証される。コンテンツは、電子ＩＤによって提供されるユーザ鍵を使用して暗号化することができる。ユーザは、支払方法、たとえば、送り状またはクレジット・カードを選択し、認証のために使用する電子ＩＤを使用してトランザクションに署名することができる。別法として、ユーザは、支払のためならびにトランザクションを保護するために使用すべき外部メカニズムを選択することができる。
【００４７】
次に、図２に関連して本発明についてより詳細に説明する。アクセス・サーバは、ユーザを認証し、ユーザに適切なサービス・メニューを提供することにより、サービスへのユーザのアクセス・ポイントとして動作する。システム内でその役割を果たすために、アクセス・サーバは以下の通りでなければならない。
【００４８】
ＨＴＴＰＳ（ＳＳＬ／ＴＬＳによるＨＴＴＰ）をサポートするか、または別法として、他の安全な通信チャネル手段を提供することができる。
【００４９】
好ましくはＰＫＩ技術（たとえば、ＳＳＬ／ＴＬＳサーバ認証）の使用により、クライアント／ユーザに対してサーバ自体を認証することができる。
【００５０】
妥当性検査サービスおよび許可サービスと通信するために必要なプロトコルをサポートする。
【００５１】
ＰＫＩベースのクライアント／ユーザ認証のための１つまたは複数のプロトコル、通常はクライアント認証を備えたＳＳＬ／ＴＬＳをサポートする。
【００５２】
ユーザに対して必要な情報（サービス・メニューなど）を表示し、ユーザ入力を処理するために必要な機能性を実現する。
【００５３】
ユーザとサービスとの間のプロキシとして動作し、すなわち、両者間で透過的に情報を仲介することができる。
【００５４】
ユーザは、サービスにアクセスするために、アクセス・サーバによって提供されるウェブ・インターフェースにブラウザを向けなければならない。通常、ユーザは、上記の通り、クライアント認証を備えたＳＳＬ／ＴＬＳにより直ちに認証されることになる。
【００５５】
２つの代替方法が存在する。すなわち、もう１つのＰＫＩベース認証方法が使用される場合、ＳＳＬ／ＴＬＳセッションはサーバ認証のみによって確立することができ、次にユーザ認証プロトコルはこの安全なチャネル上で実行することができる。認証方法のためにいくつかの代替策が存在する場合、ユーザは方法の選択のためにクリアテキスト（すなわち、純粋ＨＴＴＰ）ページに直面する可能性がある。選択後、たとえば、クライアント認証を備えたＳＳＬ／ＴＬＳセッションの確立により、認証が続行される。
【００５６】
上記の通り、アクセス・サーバは、ユーザからユーザの証明書を入手することを当てにしている。証明書を入手するための他の手段、たとえば、ディレクトリ・ルックアップを追加として実現することができる。
【００５７】
以下のセクションに記載する通り、妥当性検査サービスに関しては、できるだけ多くのローカル証明書処理は、アクセス・サーバで使用不能にし、その代わりに妥当性検査サービスに任せなければならない。アクセス・サーバは、妥当性検査サービスによりユーザの証明書の妥当性を検査し、認証プロトコルの呼掛け部分でユーザの署名を検証し、この認証の成功または失敗に応じて動作しなければならない。呼掛けの作成および呼掛けに関する署名の検証は、アクセス・サーバの外部で実行することができる。アクセス・サーバはユーザからの攻撃に曝されているので、このようなセキュリティ上重要な操作のためにさらに保護されたコンピュータの使用を希望する場合もある。
【００５８】
ユーザ認証後の第１のアクションは通常、これがすでに妥当性検査サービスから入手されていない場合に、許可サービスからユーザのサービス・リストをフェッチすることになる。その後、アクセス・サーバは、実施中のポリシーに従い、しかもユーザ・プロファイルと照らし合わせたチェックを必要とするアクションのために許可サービスと協働して、ユーザ入力に応じて動作する。図１に記載した通り、シングル・サインオン・メカニズムを実現することができる。
【００５９】
妥当性検査サービスは証明書処理のために最適化される。これは、証明書、または証明書およびその発行者のＩＤを受信し、以下の通りに実行する。
【００６０】
発行者の名前を読み取る。
【００６１】
「良好な」鍵の事前評価リストから発行者の公開鍵をフェッチする。すべての相互認証体制または階層はすでに前処理されており、すべての発行者公開鍵は直接信頼され、すなわち、証明書チェーンの処理は一切不要である。
【００６２】
好ましくはＣＲＬ（証明書取消しリスト）の定期的なプリフェッチによって入手される前処理済み取消し情報へのローカル呼出しにより、取消しチェックを実行する。
【００６３】
完全な証明書がすでに受信されている場合、証明書を解析し、署名および有効期間をチェックし、コンテンツを導出する。これは、異なる証明書プロファイルについて個々に処理する必要がある。
【００６４】
証明書内の名前から導出されるユーザ名、品質レベル（当該証明書ポリシーの分析に基づいて事前決定されたもの）などのような証明書情報からマッピングされた情報を導出する。情報は、一般的なものであるか、または具体的に証明書妥当性検査を要求したエンティティをターゲットにしたものである可能性がある。
【００６５】
これらの操作は、必要な迅速応答時間を提供し、妥当性検査サービスで最適化することができる。特に、証明書チェーンの処理と取消しチェックは、通常、サーバに対して重い負荷を課すものである。このため、現在のＰＫＩ使用可能サービスでは往々にして適切な取消しチェックが抑制される。妥当性検査サーバは、このプロセスを加速するために、取消し情報の前処理を当てにしている。
【００６６】
妥当性検査サービスに対するいくつかのプロトコルを使用することができる。ＯＣＳＰ（オンライン証明書状況プロトコル）バージョン１は現在、使用可能であるが、完全な証明書を転送する標準的な方法をまったく備えていない。ＯＣＳＰバージョン２は、インターネット・ドラフトとして開発中であり、この可能性を加えるものである。ＯＣＳＰを補うかまたは置き換えることができる代替プロトコルは、インターネット・ドラフト・プロトコルであるＳＣＶＰ（単純証明書妥当性検査プロトコル）と、ＸＫＭＳ（ＸＭＬ鍵管理システム）である。また、プロトコルは、ＳＯＡＰ（本質的にＨＴＴＰによるＸＭＬである、単純オブジェクト・アクセス・プロトコル）または同様の技術に基づくものにすることもでき、あるいは何らかのプロプラエタリ・プロトコルを設計することもできる。これらのプロトコルはいずれも、妥当性検査要求自体に対するＹＥＳ／ＮＯ／不明の回答とともに、呼出し側に追加情報を返す可能性を提供する。
【００６７】
ＯＣＳＰは主に、１つの認証局からのＣＲＬ発行の置換えとしてターゲットになっている。ＣＲＬの代わりにまたはＣＲＬに加えて、証明書発行者は、この認証局のみによって発行された証明書の妥当性に関する要求に回答するＯＣＳＰインターフェースを提供する。これに関連して、妥当性検査サービスは、サポートしているすべての認証局に１つのＯＣＳＰサービスを提供することになる。
【００６８】
ＯＣＳＰｖ１は、ＯＣＳＰサービスの唯一の機能性として取消しチェックについて記載している。これは狭すぎるものであり、これを強化することが提案されている。まず第一に、妥当性検査サービスは、証明書が取り消されたかどうかをチェックするだけでなく、それがその有効期間内であるかどうかと、証明書上の発行者の署名が正しいこともチェックしなければならない。さらに、妥当性検査サービスは、証明書を解析し、品質レベルとユーザ名、おそらくさらに多くの情報も決定することによりコンテンツに作用しなければならない。
【００６９】
ＯＣＳＰは、呼出し側に要求（の一部）にディジタル署名させる可能性により、要求のクライアント認証と保全性保護を行うものである。これに対応して、妥当性検査サーバは応答に署名することができる。また、これは、他のプロトコル代替策についても実現することができる。偽造または改竄した応答は重大な脅威を構成する可能性があるので、署名付き応答は非常に重要なものになる可能性がある。呼出し側が他の方法で認証されていない場合、呼出し側固有の情報を返すために署名付き要求が必要になる場合もある。
【００７０】
しかし、署名処理（通常は証明書処理も暗示するもの）はかなり時間のかかるものなので、妥当性検査サービスへの呼出しが安全なチャネル、たとえば、ＶＰＮソリューションにより行われることを保証する方がより効果的である可能性がある。これは、確かに、アクセス・サーバと妥当性検査サーバとの間のチャネルのケースであるはずであり、おそらく他のドメイン内部サービスから妥当性検査サービスに対するチャネルのケースでもあるはずである。外部当事者に対して妥当性検査サービスが提供される場合、多分このような外部当事者すべてについてＶＰＮまたは同様のものを要求することはできないので、署名付き要求および応答のための備えを実現しなければならない。
【００７１】
以下の説明では、妥当性検査サービスを使用するサーバに関する要件を扱う。特に、これはアクセス・サーバである。
【００７２】
とりわけ、このようなサービスはアクセス・サーバに常駐する。妥当性検査サービスを使用するために、証明書処理（の一部）はこれらのサービスで「短絡」されるはずである。サーバ内での処理に関するいくつかのシナリオについて以下に説明する。
【００７３】
ＳＳＬクライアント認証：  サーバにおけるＳＳＬ処理は、クライアントの証明書を抽出し、それ以上処理せずにこれを妥当性検査サービスに転送するかまたは完全な証明書またはそれから導出される情報を転送する前に何らかの処理をローカルで実行しなければならない。その応答に基づいて、ＳＳＬセットアップは続行されるかまたは打ち切られる。
【００７４】
ディジタル署名付きメッセージの受信：クライアント（送信側）の証明書は、メッセージから抽出（または他の手段により入手）し、妥当性検査サービスに送信することができる。別法として、証明書またはそれから導出される情報が妥当性検査サービスに送信される前に、何らかの証明書処理をローカルで実行することができる。妥当性検査が成功した後、メッセージ自体に関する署名をローカルで検証することができる。また、妥当性検査サービスは、メッセージならびに証明書に関するシステム内のすべての署名処理を処理するように強化することもできる。
【００７５】
その後、所与の相手先に対するメッセージまたはチャネルの暗号化（のための鍵管理）に使用されることになる証明書の妥当性検査：処理はディジタル署名付きメッセージ内の証明書の受信に類似したものになる。
【００７６】
ＶＰＮの確立：  処理はＳＳＬクライアント認証シナリオにほぼ等しいものになる。
【００７７】
その他のＰＫＩベースの認証プロトコル：サーバは、クライアントの証明書を入手し、次に上記のシナリオに示す通りに妥当性検査サービスを呼び出さなければならない。証明書処理が完全に妥当性検査サービスに任される場合もあれば、何らかのローカル処理が実行される場合もある。
【００７８】
妥当性検査サービスへの呼出し（上記でリストしたプロトコル代替策）を実現するために、サーバ・ソフトウェアに対する変更が必要である。「短絡」可能なローカル処理の量は、特定のサーバ・プラットフォームについて可能な変更に依存する。最適パフォーマンスのために、妥当性検査サービスへの呼出しは、サーバ内の他の処理とインターリーブし、すでにたいていのサーバ・プラットフォーム内の所定の位置にある機能性（ローカル証明書処理）を部分的にまたは完全に置き換えなければならない。このような変更は通常、かなり複雑なものであり、プラットフォームの開放性に依存する。この代替策は使用可能な公開インターフェースの上に余分な機能性を追加することであり、ローカル証明書処理は構成パラメータにより可能な範囲で短絡されるだけである。
【００７９】
妥当性検査サービスに対するインターフェースをユーザ（クライアント）に提供することも可能である。この場合、ユーザのブラウザ（概して、ユーザの機器内の他のソフトウェアである可能性がある）内の証明書処理は、ローカル証明書処理の代わりに、妥当性検査サービスへの呼出しによって完全にまたは部分的に置き換えられる。これはサーバのケースに類似している。このようなインターフェースの主たる使用法はＳＳＬサーバ証明書の処理になるが、ＶＰＮセットアップ、ディジタル署名付きメッセージの受信、相手先に対するメッセージ／トラフィックの暗号化に使用されることになる証明書の妥当性検査に関連する使用法も存在する。この場合、妥当性検査サービスからの応答は署名付きにすることができ、ユーザからの要求は署名付きにすることができる。妥当性検査サービスがユーザに代わって証明書上の署名を検証する場合、標準のブラウザ（および、たとえば、マイクロソフトのＯＳの新バージョン）内に事前構成された（現在は約１５０通りの）証明書発行者公開鍵のリストをユーザの機器から除去することができる。ユーザによるこのような発行者公開鍵（に対する信頼）の管理はＰＫＩの使用にとって重大な障害である。
【００８０】
種々の証明書発行者のサポートに関して、妥当性検査サービスの導入の後ろには２通りの基本的な考え方が存在する。  
・証明書処理のためにこのサービスを最適化すること、特に証明書チェーンの処理を免れること、およびＣＲＬ処理の代わりにローカル・データベース・ルックアップにより取消しをチェックすることによる効率。  
・２つ以上の証明書発行者からの証明書を受け入れることを希望するサービスに関する単一統合点を提供すること。
【００８１】
現在、ＰＫＩベースの認証を使用するサービスは、それが受入れを希望する証明書を発行する各証明書発行者に対して個々に統合しなければならない。特に、統合の複雑さは、種々の証明書フォーマット、種々の命名方式、取消し情報のための種々のアクセス・ポイント、および発行者公開鍵の管理を扱わなければならない。したがって、あるサービスは、いくつかの選択した証明書発行者と直接統合できるだけである。妥当性検査サービスはこの複雑さをサービスから除去する。
【００８２】
しかし、多くの証明書発行者をサポートすることになっている場合、妥当性検査サービスでさえ複雑さの問題に直面する。主な複雑さは、次のセクションで説明するように、品質レベルの決定である。発行者の公開鍵の管理は、信頼できるものでなければならず、取消しおよびその他の更新のために連続的にモニターしなければならない。種々の発行者からの証明書フォーマットは、特定のパーサによって補償しなければならない（ただし、標準化したプロファイルはある程度までそのタスクを容易にするが、当該プロファイルを決定する必要がある）。妥当性検査サービスは技術的観点から見るとあまり複雑ではないが、サービスの管理はリソースを必要とする。しかし、多くのコンテキストでは、各サービスごとに個別にそれと取り組まなければならないのではなく、この複雑さを集中させる方がより効果的である。
【００８３】
これは、このサービスによっていくつの証明書発行者およびどの証明書発行者をサポートすることを希望しているかという問題を指している。世界中には数百の公開証明書発行者サービスが存在し、さらに多くのものが現れる。追加として、ますます法人（イントラネット）システムに気付くことになるが、これは、誰でも証明書発行サービスを確立できるようにする、たとえばマイクロソフトまたはＩＢＭ／ロータスからの標準的な製品に基づくものである可能性がある。これらのサービスの大部分は非常に不十分な品質および信頼レーティングを達成することになり（たとえば、いずれのポリシーにも裏打ちされずに発行される）、その企業のイントラネットの外部では実質的に無用なものになるが、ある協働企業または法人顧客からの証明書を受け入れられることを希望する状況が発生する可能性がある。
【００８４】
妥当性検査サービスの実現例のスケーリング特性が十分なものである限り、この問題に関する決定は、技術的性質より管理的性質の強いものになる。
【００８５】
決定的な要件の１つは、証明書はさらに処理するために必要な情報、とりわけアクセス制御および会計に使用可能な名前を直接的または間接的に提供しなければならないことである。
【００８６】
証明書および品質レベルのカテゴリ化に関して、証明書発行サービスは以下のコンポーネントによって定義される。  
・法律上のフレームワークおよび合意
・サービスに関連する手順に関する要件を示し、通常、法律上のフレームワークおよび合意の諸局面の多くを扱う証明書ポリシー（しかし、往々にして明示的なものでなければならず、したがって、個別のポイントを保証するもの）
・ポリシーの要件がこの特定の証明書発行サービスによってどのように満足されるかを説明し、内部手順書と呼ばれる場合もある証明書実施声明
・証明書フォーマット、特に命名規則
・他の行為者に対する信頼モデル、特に階層構造および相互認証体制に対する態度
・証明書、取消し情報、ポリシー情報、およびその他の関連情報に関する情報／ディレクトリ・サービス。
【００８７】
証明書サービスの品質局面は主に証明書ポリシーから導出される。このポリシーは、証明書を入手するためにユーザが通過しなければならない登録手順に関する要件（たとえば、電子申請対物理的認証を伴う本人出頭など）、エラーが発生した場合に発行者が負うことに同意した責任、サービスの運用に課せられるセキュリティ要件などの概略を示すものである。幸いなことに、ポリシーを作成するための標準的なフレームワークがいくつか存在し、たいていの証明書発行者はそのうちの１つを遵守する。したがって、複数の証明書ポリシーはポイントごとに比較することができる。
【００８８】
しかし、証明書ポリシーのカテゴリ化は、何らかの専門技術を要する重要な手動タスクである。カテゴリ化のためにカテゴリ化基準および方法論的基礎が必要である。所与の品質レベルに達するために、どの基準を満たさなければならないか。外国語で作成されたポリシー、外国からの法律および規制の参照など、さらに複雑さを追加する。誰かがポリシーのカテゴリ化／分類に関する独立サービスを考案していない場合、すべての発行者について独立して評価プロセスを通過せざるを得ない。これは、いくつかの決定的な発行者から始めて、後で必要に応じてこれを拡張しなければならないことを意味する。
【００８９】
サポートされるポリシーの連続モニターを実行しなければならない。しかし、ポリシーは通常、変動する手順を記載することになり、多くの発行者は、ポリシーの実質的な変更が行われた場合に他の当事者について積極的に通知することをサポートすることになる。
【００９０】
品質カテゴリ化は、単純な数値、たとえば、１〜４にすることができ、１を最上位レベル、４を不十分な品質レベルにすることができる。このようなレベルの標準化に関する作業は、これまでほとんど行われていない。欧州連合内では、「適格証明書」レベルは正式なディジタル署名をサポートするための高品質インジケータとして（多かれ少なかれ）確立されている。米国内では、「連邦ブリッジ認証局」が何らかの品質レベルを定義する。連邦セクタに対するサービスを提供する証明書発行者は、それ自体のポリシーとブリッジによって定義された適切な品質レベルとのポリシー・マッピングを示し、ブリッジと相互認証しなければならない。ＥＴＳＩは現在、「不適格ポリシー・フレームワーク」について作業しており、これはポリシーのカテゴリ化のために考慮に入れなければならない何らかのインジケータを定義することになる。
【００９１】
品質カテゴリ化は、単なるレベル・インジケータよりかなりきめ細かいものである可能性もある。ポリシー・フレームワークとＥＴＳＩの現在の作業に基づいて、ポリシーから呼出し側に返すことができる構造にいくつかのパラメータを導出することができる。一例として、証明書発行者が喜んで負う責任は、その発行者からの証明書に基づく認証によって裏打ち可能なトランザクションの価値に影響を及ぼす可能性がある。ポリシーが示す管轄権はもう１つの重要なパラメータである。
【００９２】
もう１つの問題は、品質レベル（ポリシーおよび関連慣行）が証明書発行者によって単純に請求されているかどうか、またはその請求が第三者の証拠によって裏打ちされているかどうかであることに留意されたい。多くの証明書ポリシーは、実際の操作がポリシー、実施声明、および内部手順に従っていることを保証するために、サービスの第三者監査を必要とする。このような監査報告書はおそらく、より高品質のレーティングまたは少なくともレーティングに関するより高い確実性を暗示することになる。この場合、ＩＳＯ９０００またはＩＳＯ１７７９９のような証明書も物の数に入ることになる。
【００９３】
最終的に、サービスの品質は必ずしも信頼を暗示しないことに留意されたい。（想像上の）「マフィアＣＡ」は高品質のレーティングを達成することができるが、その証明書が受け入れられるはずであることは依然として明確ではない。
【００９４】
証明書ポリシーおよび品質レベルに加えて、証明書発行サービスの他の局面を考慮に入れなければならない。特に、存在しなければならないかまたは存在してはならない所与の分野、属性、または拡張など、証明書フォーマットに関する要件を課す可能性がある。命名は個別の問題であり、現在定義されているシステムの場合、証明書内の名前から有効なユーザ名へ変換することが可能でなければならない。場合によっては発生する可能性のあるもう１つの要件は、名前が仮名ではなく「実」名でなければならないことである。
【００９５】
図５は、妥当性検査サービスの提案されたアーキテクチャを示している。これは以下の部分からなるものである。  
・このプロトコルに関連する構文およびセマンティクスを処理するＯＣＳＰサーバ。尚、点線として示すように他のプロトコルのためのフロントエンドを後でさらに追加することができる。  
・証明書を処理し、妥当性をチェックし、情報を導出する妥当性検査エンジン。  
・妥当性検査サービスによって処理されるすべての認証局からのＣＲＬをプリフェッチし処理するための個別プロセス。尚、ＯＣＳＰクライアントは、ＣＲＬをサポートしない証明書発行者からの取消し情報にアクセスするために必要になる可能性がある。  
・証明書発行者に関する情報、その公開鍵、ポリシーおよび関連品質レベル、前述のプロセスによって更新された取消し情報、証明書から導出可能な追加情報を保持するデータベース。  
・証明書内の名前からシステムのドメイン用の有効なユーザ名への変換と、おそらく他のドメイン用の他の名前形式への変換を導出するために、許可サービスに対するインターフェース（多分ＬＤＡＰ）。このインターフェースは、前に述べた通り、妥当性検査サービスの代わりにアクセス・サーバからのものである可能性がある。尚、サービスはほぼ確実に暗号ハードウェア（図５には示されていない）を必要とすることになる。
【００９６】
操作、要求、および応答に関して、ＯＣＳＰサーバおよび他のフロントエンドは、妥当性検査サービスに関連するプロトコル依存処理を実行する。これは、ディジタル署名付き要求および応答上の署名の妥当性検査および生成を含む。
【００９７】
フロントエンドは、妥当性検査エンジンに対するＡＰＩを有する。妥当性検査エンジンは、証明書が含まれる場合にその証明書を解析するか、またはサブミットされた証明書情報についてその他の動作を行わなければならない。
【００９８】
次に、証明書について、署名がＯＫか、証明書フォーマットがＯＫか、有効期間内か、取消しまたは一時停止されていないかという妥当性検査チェックが実行される。これらのチェックのうちのいくつかは、完全な証明書を当てにしており、証明書の抜粋のみサブミットされた場合には実行することができない。品質レベルは、証明書に示されているポリシーに基づいて（または、発行者がその証明書に推奨ポリシー識別子拡張部を含めないという不可思議なケースでは、事前構成された知識から）フェッチされる。次に、導出される情報はデータベースからフェッチされ、すべてがＡＰＩによって指定された形式でＡＰＩによりＯＣＳＰサーバ（または他のフロントエンド）に返される。
【００９９】
ＣＲＬプリフェッチ・コンポーネントが必要な情報（下記の通り）を収集することになっているので、取消しチェックは通常、単なるローカル・データベース・ルックアップになる。しかし、証明書発行者が取消しチェックのためにＯＣＳＰインターフェースのみを提供し、ＣＲＬ発行サービスを提供しない場合、妥当性検査エンジンは実際に発行者のＯＣＳＰサービスを呼び出さなければならない。
【０１００】
複数の妥当性検査サービスをチェーン化可能な状況も想像することができるが、その場合、遠隔妥当性検査サービスのフロントエンドによってサポートされるプロトコル（必ずしもＯＣＳＰではない）を使用して呼出しが実行される。
【０１０１】
我々の知る限りでは、現在、たいていの認証局は、署名付きＣＲＬを使用して、証明書の取消しおよび一時停止を通知する。ＣＲＬは通常、定期的に発行され、各ＣＲＬは次のバージョンの計画発行時期を含む。しかし、必要であれば、そのスケジュールより前にＣＲＬを発行することができる。完全なＣＲＬが通例であり、すなわち、１つのＣＲＬは取り消されたすべての証明書の通し番号を含む。次のＣＲＬの発行時期がある証明書の正規の満了時期の後である場合、その証明書は将来のＣＲＬから除去される。あるＣＲＬが前のＣＲＬ以降の新しい項目のみを含む場合、増分ＣＲＬとも呼ばれるデルタＣＲＬを使用することができる。デルタＣＲＬの場合、完全なＣＲＬが定期的に発行されるが、その頻度は完全なＣＲＬのみを使用する場合よりかなり低い。
【０１０２】
したがって、ＣＲＬプリフェッチ・コンポーネントの通常のケースは、サポートされる各証明書発行者ごとにデーモンプロセスを実行し、スケジュールされた発行時期の後の非常に接近した時期に発行者の完全なＣＲＬをフェッチし処理することである。この処理の結果はデータベースに記憶される。しかし、サポートが必要になるいくつかの変形例が存在し、妥当性検査サービスは、それぞれのポリシーに文書化されている通り、種々の証明書発行者のＣＲＬ戦略を把握する必要がある。当然のことながら、妥当性検査サービスは、ＣＲＬの配布点も把握する必要があり、これらの点にアクセスできる必要がある。ＣＲＬは公然と使用可能なものでなければならないが、発行者によっては、フェッチについて請求することを希望する場合があり、その場合、そのコストは呼出し側に転送されるか、または他の何らかの方法で補償されなければならない。
【０１０３】
ある発行者がデルタＣＲＬをサポートする場合、各フェッチ操作ごとにダウンロードする必要があるデータの量は完全なＣＲＬの場合よりかなり小さくなるので、これは、ＣＲＬプリフェッチ・コンポーネントによって使用されなければならない。
【０１０４】
ある発行者がＣＲＬ間の長い間隔を指定している場合、これはむしろ「必要なときにＣＲＬを発行する」という戦略を暗示する可能性がある。この場合、ＣＲＬプリフェッチ・コンポーネントは、スケジュールされた次の発行を待つ代わりに、定期的に新しいＣＲＬについてポーリングしなければならない。妥当性検査サービスがＣＲＬ間で喜んで受け入れなければならない間隔は、妥当性検査サービスの品質に影響を及ぼすチューニング・パラメータである。この間隔はポーリング時間に等しいものでなければならず、ＣＲＬ頻度がその間隔より大きいすべての発行者に対しポーリングしなければならない。
【０１０５】
大規模な国際運用の場合、潜在的に非常に大きいＣＲＬをすべての発行者からフェッチする集中設備は明らかに非効率的なものになる。１時間ごとに世界中の何百もの発行者から大量ＭＢの情報をフェッチする必要があるノルウェー内のある設備は役に立つ可能性があるが、非効率的なものになり、取消し情報の伝搬は遅くなる。したがって、分散アーキテクチャはＣＲＬプリフェッチ・コンポーネントにより適したものであるが、これについてさらに記載することは本明細書の範囲外である。
【０１０６】
結局、ＣＲＬをまったく使用せず、取消しチェックのためにＯＣＳＰインターフェースのみを当てにする発行者がいくつか存在する可能性がある。この場合、ＣＲＬプリフェッチ・コンポーネントは何も実行することができず、妥当性検査エンジンは、必要な場合に必ず適切なＯＣＳＰインターフェース（または、上記の通り、他の妥当性検査サービス）を呼び出さなければならない。
【０１０７】
前述のものより多くのパラメータがその結果に影響を及ぼすことになるので、ＣＲＬプリフェッチ・コンポーネントが使用する戦略はより詳細にチューニングしなければならない。主な要件は、取消し情報の伝搬に関して導入するために受入れ可能な遅延の量である。これは、必然的に、ＣＲＬの発行とこのＣＲＬがＣＲＬプリフェッチ・コンポーネントによって処理される時間との間の「ギャップ」になる。このギャップ中に妥当性検査サービスに到着する要求は、ＣＲＬプリフェッチ・コンポーネントがそのジョブを実行するのを妥当性検査サービスが待つ場合に遅延応答を受信しなければならないか、または古い取消し情報に基づいて妥当性検査サービスが直ちに応答する場合に回答を誤るというリスクを冒さなければならない。
【０１０８】
また、多くの当事者が同時に新しいＣＲＬをローカル・キャッシュにダウンロードしようと試みるので、スケジュールされたＣＲＬが発行されるたびに要求によって発行者のＣＲＬ配布サービスが過負荷になるというリスクも存在する。これに対処するため、発行者によっては「過大発行」戦略を実現する。ＣＲＬは、ポリシーが示す以上の頻度で発行される。ＣＲＬプリフェッチ・コンポーネントは、このような考慮事項を考慮に入れなければならない。
【０１０９】
データベースは、各証明書発行者およびそのポリシーに関する情報と、取消し情報を記憶することになる。ユーザ関連情報も記憶することは可能であるが、上記のシステム・コンテキストでは、ユーザ情報の記憶および管理を許可サービスに任す方がより効果的である。
【０１１０】
発行者情報は、前に述べた通り、発行者名（証明書の発行者名フィールドに指定されたもの）、当該ポリシーのＩＤ（ポリシーのＯＩＤ（オブジェクト識別子）は証明書に（ほぼ）必ず含まれる）、証明書を妥当性検査するために使用しなければならない公開鍵または公開鍵のリスト（妥当性間隔および鍵識別子／ハッシュ値を含む）、ポリシーおよび発行者に関連する品質属性からなるであろう。
【０１１１】
これは必ず信頼できる証明書発行者およびその鍵のローカル・リストの形になっており、往々にして自己署名付き証明書（認証ではなく保全性保護を提供するもの）の形になっているので、発行者公開鍵の管理は現在、頭の痛い問題である。上記のシステムでは、発行者鍵管理は好ましくは妥当性検査サービスに集中化されている。これは、完全な証明書が妥当性検査サービスに渡される場合にのみ可能であり、証明書上の発行者の署名のローカル・チェックは呼出し側システムでは短絡することができる。
【０１１２】
発行者の鍵は、部分的に手動であり（品質保証のため）、部分的に自動であるプロセスで妥当性検査され、データベースに記憶される。発行者の鍵の取消しは非常に稀な事象であるが、これは非常に厳格な事象でもある。このような取消しが取り込まれることを保証するために、情報チャネルをモニターしなければならない。場合によっては、取消しは階層のより高いレベルにある発行者からのＣＲＬによるものになる。他の場合には、当該証明書発行者がいずれの信頼構造のメンバーにもならず、独力で取消しを手配しなければならない。しかし、取消し通知は必ずポリシーに記載されるものとする。
【０１１３】
その発行者の鍵ロールオーバは通常、古い公開鍵が依然として証明書妥当性検査に有効であるが、その秘密鍵が新しい証明書の署名に有効ではないというオーバラップを暗示することになることを除き、発行者によっては、いつでも使用中の鍵ペアを１つだけ有することになる。他の発行者は頻繁な鍵変更に関するポリシーを採用することができ、その場合、同時に多くの鍵が（少なくとも証明書妥当性検査に）有効になる可能性がある。多分、発行者の公開鍵のデータベースを最新の状態に保持するための手動手順が必要である。
【０１１４】
取消し情報の管理はＣＲＬプリフェッチ・コンポーネントによって実行される。取消しチェックは、当該証明書の通し番号が取消し済みとしてリストされているかどうかを確認するためにデータベース・サーチによってローカルで実行される。取消し情報には、現行情報のフェッチ操作の時間および次のフェッチについてスケジュールされた時間というタイムスタンプを付けなければならない。
【０１１５】
許可サービスの主な動機付けは、単一箇所におけるユーザ関連情報の管理と保護である。現在、各サービスごとにまたは少なくとも各サービス・プラットフォームごとに個別の認証および許可システムを有することは通例のことである。したがって、加入／ユーザ情報の管理、すなわち、新しい情報の入力、情報の変更または削除は、厄介で、間違いの影響を受けやすいものになる。
【０１１６】
許可サービスは、１つのデータベース内に各ユーザに関連する情報を保持する。このサービスとデータベースは複製することができる。「ユーザ」は通常、個人になるが、加入者ＩＤ、グループ名、またはその他の何らかの名前付きエンティティにすることもできる。情報は認証および許可に関連するものである。会計情報は容易にシステムに追加することができるが、これについては本明細書で説明しない。情報は機密性および保全性に関して敏感なものになり、許可サービスおよびデータベースは十分に保護しなければならない。
【０１１７】
現在、許可サービスはＬＤＡＰおよびＲＡＤＩＵＳという２つの標準プロトコルをサポートしなければならない。ＤＩＡＭＥＴＥＲプロトコルは、仕様の準備ができたときにサポートしなければならない。他のプロトコルをサポートすることもできる。許可サービスは敏感な情報を処理するので、情報が返される前にそれを呼び出すエンティティに関して認証およびアクセス制御を実行しなければならない。これは、使用するプロトコルの一部にするか、下にあるプロトコル（ＳＳＬ、ＴＬＳ、ＩＰＳｅｃ、またはその他のＶＰＮ技術など）に基づくものになるか、または相手先に対する専用通信チャネル（物理的または論理的）を当てにすることができる。種々のプロトコルを使用するので、妥当性検査サービスについて上記したものと同じように、プロトコル固有のフロントエンドが必要になる。
【０１１８】
許可サービスは、認証およびサービス・アクセスのために名前のマッピングを実行する。使用するＰＫＩベースの認証プロトコルは証明書内の名前を認証することになる。この名前は許可サービスに送り出すことができ、許可サービスは対応するユーザ名を返すことになる。ユーザは異なるサービスに対して異なるユーザ名を有することができるので、そのためにユーザ名が必要であるサービスの名前は呼出しのパラメータでなければならない。必要であり要求される場合、ユーザ名とともにパスワードを返すことができる。
【０１１９】
あるセッションのその後の諸ステージでは、必要なときにより多くのユーザ名を入手するために許可サービスが呼び出される場合がある。許可サービスは、ユーザ名／サービスのペアを引き渡され、他のサービスにアクセスするためにこれを他のユーザ名／サービスのペアに変換するよう要求される場合がある。許可サービスは、名前付きユーザのために最後に使用した認証メカニズムの強さを記録し、情報を返すかどうかによってサービスへのアクセスを授与または否定するときに、それに応じて動作しなければならない。
【０１２０】
システム内の第１のレベルの許可は、そのようにサービスにアクセスするためのものである。許可は、十分な品質の認証メカニズムの使用、許容位置、所与の機器のみの使用、時刻などのような所与の条件にリンクすることができる。もう１つの条件は会計および保証された支払であり、これは現在、個々のサービス次第であるが、後で許可サービスに追加することもできる。アクセスを授与するために、このような条件はすべて満たさなければならない。
【０１２１】
追加として、サービス固有の許可をデータベースに記憶することができる。この場合、許可サービスは、アクセス要求を許可すべきかどうかを決定するために、特定のオブジェクト（コンテンツの一部分など）へのアクセスを試行したときにそのサービス自体から呼び出される場合もある。
【０１２２】
許可サービスに対する今後の拡張機能は以下の通りである。  
・許可の証拠として暗号で保護された「トークン」を発行すること。これは、署名付き特権（属性）証明書、ケルベロス・チケット、または同様の技術に基づくものにすることができる。  
・あるユーザ／行為者から他のユーザ／行為者への許可の委任を処理すること。  
・アクセス決定のために数人のユーザ／行為者からの許可を構成すること。  
・これらの事項については、本明細書ではこれ以上説明しない。
【０１２３】
上記のシステムは、使用可能な商用（または非商用）証明書サービスに基づいて認証を行う。登録、命名、発行、および取消しのような、すべての証明書管理は、証明書サービス・プロバイダによって処理されるものとする。
【０１２４】
許可サービスは、ユーザ名および関連特権のデータベースを維持する必要がある。証明書内の名前は、このコンテキストでは直接使用可能なものにならない。したがって、ユーザ名と、そのユーザが認証のために使用することを希望する証明書（複数も可）内の名前（複数も可）との間に、マッピングを確立する必要がある。これは、認証メカニズムとしてユーザ名／パスワードのみをサポートするサービスに対してアクセス・サーバが透過的にユーザをログオンできるようにするために、他のサービスに対するより多くのユーザ名によって、また、おそらくパスワードまたはその他の認証情報によって、さらに拡張することができる。証明書に加えて、システムは、ユーザ名／パスワードのような他の認証メカニズムに対応するように拡張することができる。
【０１２５】
特定の証明書発行者が使用する命名フォーマットを自動的にユーザ名に変換できる場合が存在する可能性がある。しかし、たいていの場合、証明書名からユーザ名へのマッピングは、データベース内に明示的に構成しなければならない。管理上のオーバヘッドを回避するために、主要部分については、これはそのユーザのためのセルフサービス・インターフェースとして実現しなければならない。しかし、データベースへの拡張アクセス権を備えたオペレータの定義と管理インターフェースも必要になる。
【０１２６】
ユーザは、証明書名を登録させ、ユーザ名にリンクさせるために、自分の加入に関する証明書および詳細をサブミットできるセルフサービス・インターフェースにアクセスできなければならない。この２つの名前形式間のリンクは、当然のことながら、安全に確立しなければならない。以下のように２つの代替策が新しいユーザに与えられる可能性がある。
【０１２７】
第１の代替策は、アカウントについて契約し、同時にシステム所有者の好ましいパートナからまたは代替証明書発行者のリストから電子ＩＤを注文することである。証明書発行者のポリシーに応じて、電子ＩＤは、直ちに使用可能になる場合もあれば、その後のステージで（たとえば、ユーザがスマート・カードを入手する必要がある場合に）活動化する必要がある場合もある。しかし、許可サービスの場合、証明書に現れる名前は重要な情報である。
【０１２８】
第２の代替策は、アカウントについて契約し、ユーザを認証するために使用されることになる既存の証明書を指定することである。（セキュリティ）要件に照らし合わせて証明書の適用性をチェックしなければならず、証明書が事実上、新しいユーザに属することを検証しなければならない。１つの証明書を登録し、後でより多くの証明書をユーザに追加させるためには、それで十分であるものとする。
【０１２９】
既存のユーザは、追加の証明書の登録またはすでに登録された証明書の置換えの登録を行えなければならない。これは、ウェブベース・サービスとして使用可能になる可能性のある自己管理手順にすることができる。登録される新しい方法（新しい証明書）に関連する受入れ可能な認証方法に関する規則を用意する必要があることに留意されたい。たとえば、最初に低品質の証明書を導入し、次にこれを使用して高品質証明書を新しい認証方法として登録することはできない。この場合、高品質証明書は、低品質証明書に基づく認証と同じセキュリティを効果的に提供することになるが、所与の構成では、（この場合に表面上は）高品質の認証についてアクセスを可能にしながら、低品質方法についてアクセスを制限する可能性がある。その結果として、ある認証方法は、同じセキュリティ・レベルまたはそれ以下の新しい方法を導入するためにしか使用することができない。
【０１３０】
より強力な認証方法にアップグレードするために、新しいユーザについて辿る筋道に沿った手順を適用しなければならない。何らかの自己管理が可能であるが、所与の程度まで手動手順を含めなければならない場合も考えられる。
【０１３１】
管理者は、他のユーザに関する情報の追加、削除、または変更を行えなければならない。管理者は、許可サービスを実行する組織に対して内部的に、システムを介して到達可能なサービス（のプロバイダ）に対して相対的に、またはたとえば複数のユーザに関する加入を管理する必要がある法人顧客に対して相対的に定義することができる。管理者は、普通のユーザと同じインターフェースまたはより適している場合には他のインターフェースを使用することができる。たとえば、１回の操作で多くのユーザに関する情報を追加するために、情報のバッチ処理の可能性も必要である。
【０１３２】
たいていの場合、加入（すなわち、サービスに対する許可）の管理を個々のユーザに任せることは費用効果の高いことである。したがって、認証情報の管理に関して記載したセルフサービスは、ユーザに関する他の情報も扱わなければならない（実際には、このような使用法は多分、認証情報の管理にとって一般的なものになる）。
【０１３３】
第１のレベルの許可は、そのようなサービス、すなわち、サービスへの加入または加入の終了に対するものである。よりきめ細かいレベルでは、そのサービスから許可サービスに委任されている場合、個々のサービスの特徴に関する許可を管理することができる。一例としては、ある通信サービスのために加入した帯域幅の変更が考えられる。
【０１３４】
ユーザがこのような管理手順を実行する場合、許可およびその他の制約事項に従わなければならない。一例として、あるユーザのために十分な品質の証明書が登録されていない場合、そのユーザは強力な認証手順を必要とするサービスに加入することができない。もう１つの例はサービス内のコンテンツ購読に関するものであり、これは所与の年齢以上の人に制限される可能性がある。
【０１３５】
また、許可を管理するためにも管理者は必要である。一例として、ポリシーでは、定義された人だけが法人ユーザ用の所与のサービスへのアクセス権を管理できることを指図することができる。単一操作で多くのユーザに関する情報を管理するために、バッチ指向のインターフェースが必要である。
【図面の簡単な説明】
【０１３６】
【図１】認証および許可アーキテクチャの概要を示す図である。
【図２】ユーザ証明書の妥当性をチェックするための代替方法を示す図である。
【図３】認証、許可チェック、およびサービス・アクセス・プロセスの流れ図である。
【図４】付加価値サービスへのアクセスを示す図である。
【図５】妥当性検査サービスの概要を示す図である。
【図１】
2005521279.tif 000003
【図２】
2005521279.tif 000004
【図３】
2005521279.tif 000005
【図４】
2005521279.tif 000006
【図５】
2005521279.tif 000007
【国際調査報告】
2005521279.tif 000008
2005521279.tif 000009