(57)【要約】【課題】  多数のサービス提供者が存在し頻繁に信用確立が起きうるネットワーク環境において、ユーザおよびサービス提供者ともに利便性良くサービスを提供できる信用確立方法を提供する。【解決手段】  サービス提供者３０及びユーザ端末１０から独立した信用管理サーバ２０をネットワーク５０上に設ける。信用管理サーバ２０はユーザ端末の信用を複数のサービス提供者で共有された信用定義に従って記述し返信する。各ユーザ端末は、信用管理サーバから受信した信用記述を用いて各サービス提供サーバに対して自己の信用を確立する。ユーザ端末１０は外部の証明書発行部４０１が発行したデジタル証明書を保持し、デジタル証明書を信用管理サーバ２０へ提示して信用要求を行う。信用管理サーバ２０は、ユーザ端末から提示されたデジタル証明書を検証し、信用管理ポリシに従って信用を決定し、信用記述デジタル証明書をユーザ端末へ送信する。【選択図】      図１
2006004314.tif 000002
【特許請求の範囲】
【請求項１】
複数のサービス提供装置および複数のユーザ装置が混在するネットワーク環境でユーザ装置の信用を確立する方法において、
デジタル証明書から信用を判定するための信用管理ポリシを格納し、
サービスを受けようとするユーザ装置から少なくとも１つのデジタル証明書を含む信用要求を受信し、
前記ユーザ装置からの信用要求に応じて、前記信用管理ポリシに基づき、前記複数のサービス提供装置および／または前記複数のユーザ装置で共有された信用定義に従って記述した当該ユーザ装置の信用情報を生成し、
前記生成された信用情報を前記ユーザ装置へ返送し、
前記ユーザ装置は前記信用情報を用いて前記複数のサービス提供装置および／または他のユーザ装置に対して自己の信用を確立することを特徴とする信用確立方法。
【請求項２】
前記ユーザ装置が提示したデジタル証明書は、外部の証明書発行部に要求して有効性を検証することを特徴とする請求項１に記載の信用確立方法。
【請求項３】
前記信用情報は前記提示された少なくとも１つのデジタル証明書の信頼性を表す信頼度を含み、前記信頼度は、当該デジタル証明書の証明する情報、当該デジタル証明書の発行後の経過時間、前記ユーザ装置から提示されたデジタル証明書の数、および／または、当該デジタル証明書を発行した発行者、に依存して決定されることを特徴とする請求項１に記載の信用確立方法。
【請求項４】
前記信用情報の生成に使用されるデジタル証明書は、前記ユーザ装置のユーザに対して権限を与える譲渡可能な権限証明書、および／または、前記ユーザが特定の組織に依存しない属性を有することを証明する譲渡不可の属性証明書であることを特徴とする請求項１に記載の信用確立方法。
【請求項５】
前記信用情報は前記権限証明書の信頼性を表す信頼度を含み、前記信頼度は、当該権限証明書の証明する権限の内容、当該権限証明書の発行後の経過時間、前記ユーザ装置から提示されたデジタル証明書の数、当該デジタル証明書を発行した発行者、および／または、当該権限証明書の譲渡回数、に依存して決定されることを特徴とする請求項４に記載の信用確立方法。
【請求項６】
前記信用情報は前記属性証明書の信頼性を表す信頼度を含み、前記信頼度は、当該属性証明書の証明する属性の内容、当該属性証明書の発行後の経過時間、前記ユーザ装置から提示されたデジタル証明書の数、および／または、当該デジタル証明書を発行した発行者に依存して決定されることを特徴とする請求項４に記載の信用確立方法。
【請求項７】
あるユーザ装置が保持する権限証明書を他のユーザ装置へ譲渡することで当該他のユーザ装置へ権限委任を行うことを特徴とする請求項４に記載の信用確立方法。
【請求項８】
前記属性証明書が証明する属性は、前記ユーザ装置および／または当該ユーザ装置のユーザの状態を示すコンテキスト情報であることを特徴とする請求項４に記載の信用確立方法。
【請求項９】
前記コンテキスト情報は、前記ユーザ装置の位置情報を含む物理的情報および前記ユーザ装置の使用状態を示す機能的情報の少なくとも一方を含むことを特徴とする請求項８に記載の信用確立方法。
【請求項１０】
前記コンテキスト情報は、外部のコンテキストサーバに要求して受け取ることを特徴とする請求項８または９に記載の信用確立方法。
【請求項１１】
複数のサービス提供装置および複数のユーザ装置が混在するネットワーク環境でユーザ装置の信用を確立する信用管理サーバにおいて、
デジタル証明書から信用を判定するための信用管理ポリシを格納する信用管理ポリシ記憶手段と、
サービスを受けようとするユーザ装置から少なくとも１つのデジタル証明書を含む信用要求を受信すると、前記信用管理ポリシに基づき、前記複数のサービス提供装置および／または前記複数のユーザ装置で共有された信用定義に従って記述した当該ユーザ装置の信用情報を生成し、信用記述デジタル証明書として前記ユーザ装置へ返送する証明書検証手段と、
を有することを特徴とする信用管理サーバ。
【請求項１２】
前記証明書検証手段は、前記ユーザ装置から提示されたデジタル証明書を外部の証明書発行部に要求して有効性を検証することを特徴とする請求項１１に記載の信用管理サーバ。
【請求項１３】
前記信用情報の生成に使用されるデジタル証明書として前記ユーザが特定の組織に依存しない属性を有することを証明する属性証明書を外部のコンテキストサーバに要求して取り寄せる外部証明書取得手段をさらに有することを特徴とする請求項１１に記載の信用管理サーバ。
【請求項１４】
複数のサービス提供装置が混在するネットワーク環境に接続されたユーザ装置において、
所定の信用管理ポリシに基づき、前記複数のサービス提供装置および／または前記複数のユーザ装置で共有された信用定義に従って記述した信用情報を生成し信用記述デジタル証明書として出力する信用管理サーバに対して、少なくとも１つのデジタル証明書を提示して信用要求を行い、その応答として自己の信用を示す信用記述デジタル証明書を取得する信用取得手段と、
前記取得した信用記述デジタル証明書を所望のサービスを提供するサービス提供装置または他のユーザ装置へ提示してサービスを要求するサービス要求手段と、
を有することを特徴とするユーザ装置。
【請求項１５】
信用に応じたサービスを提供するためのアクセス制御ポリシを格納したアクセス制御ポリシ記憶手段と、
他のユーザ装置から提示された信用記述デジタル証明書の信用情報と前記アクセス制御ポリシとを照合するポリシ照合手段と、
前記照合結果に従って前記信用情報に応じたサービスを前記他のユーザ装置へ提供するサービス提供手段と、
をさらに有することを特徴とする請求項１４に記載のユーザ装置。
【請求項１６】
自己が保持する譲渡可能なデジタル証明書を他のユーザ装置へ譲渡することで当該他のユーザ装置へ権限委任を行う権限委任手段をさらに有することを特徴とする請求項１４に記載のユーザ装置。
【請求項１７】
複数のユーザ装置と、ユーザ装置が少なくとも１つのデジタル証明書を提示して行った信用要求に対して所定の信用管理ポリシに基づいて共通の信用定義に従って記述された信用情報を生成し信用記述デジタル証明書として出力する信用管理サーバと、を含むネットワーク環境でユーザ装置の信用に基づいてサービスを提供するサービス提供装置において、
前記共通の信用定義に従って記述された信用情報に応じたサービスを提供するためのアクセス制御ポリシを格納したアクセス制御ポリシ記憶手段と、
あるユーザ装置から信用記述デジタル証明書を含むサービス要求を受けると、当該信用記述デジタル証明書の信用情報と前記アクセス制御ポリシとを照合するポリシ照合手段と、
前記照合結果に従って前記信用情報に応じたサービスを前記信用記述デジタル証明書を提示したユーザ装置へ提供するサービス提供手段と、
を有することを特徴とするサービス提供装置。
【請求項１８】
複数のサービス提供装置および複数のユーザ装置が混在するネットワーク環境でユーザ装置の信用に基づいてサービス提供を制御するサービス制御システムにおいて、
前記ネットワーク環境に信用管理サーバを設け、
前記信用管理サーバは、
デジタル証明書から信用を判定するための信用管理ポリシを格納する信用管理ポリシ記憶手段と、
サービスを受けようとするユーザ装置から少なくとも１つのデジタル証明書を含む信用要求を受信すると、前記信用管理ポリシに基づき、前記複数のサービス提供装置および／または前記複数のユーザ装置で共有された信用定義に従って記述した当該ユーザ装置の信用情報を生成し、信用記述デジタル証明書として前記ユーザ装置へ返送する証明書検証手段と、
を有し、
前記複数のユーザ装置の各々は、
前記信用管理サーバに対して、少なくとも１つのデジタル証明書を提示して信用要求を行い、その応答として自己の信用を示す信用記述デジタル証明書を取得する信用取得手段と、
前記取得した信用記述デジタル証明書を所望のサービスを提供するサービス提供装置へ提示してサービスを要求するサービス要求手段と、
を有し、
前記複数のサービス提供装置の各々は、
信用情報に応じたサービスを提供するためのアクセス制御ポリシを格納したアクセス制御ポリシ記憶手段と、
ユーザ装置から提示された信用記述デジタル証明書の信用情報と前記アクセス制御ポリシとを照合するポリシ照合手段と、
前記照合結果に従って前記信用情報に応じたサービスを前記ユーザ装置へ提供するサービス提供手段と、
を有する、
ことを特徴とするサービス制御システム。
【請求項１９】
複数のサービス提供装置および複数のユーザ装置が通信可能に接続されたネットワークでユーザの信用に基づいてサービス提供を制御する方法において、
サービスを受けようとするユーザ装置は、
外部の証明書発行者の発行したデジタル証明書を少なくとも１つ保持し、
あるサービスを利用する前に、前記デジタル証明書の少なくとも１つを前記ネットワーク上の信用管理サーバに提示し、
前記信用管理サーバは、
前記ユーザ装置の信用情報を前記複数のサービス提供装置および／または前記複数のユーザ装置で共有された信用定義に従って記述し、
その信用情報を信用記述デジタル証明書として前記ユーザ装置へ返送し、
前記ユーザ装置は、
所望のサービス提供サーバに対して前記信用記述デジタル証明書を提示し、
前記信用記述デジタル証明書を受け取ったサービス提供サーバは、
信用情報に基づいてサービスアクセスを制御するアクセス制御ポリシを保持し、
前記ユーザ装置が提示した信用記述デジタル証明書の信用情報と前記アクセス制御ポリシとに基づいて当該ユーザ装置へのサービス提供を制御する、
ことを特徴とするサービス制御方法。
【請求項２０】
コンピュータに、複数のサービス提供装置および複数のユーザ装置が混在するネットワーク環境でユーザ装置の信用を確立する信用管理を実行させるプログラムにおいて、
デジタル証明書から信用を判定するための信用管理ポリシを格納するステップと、
サービスを受けようとするユーザ装置から少なくとも１つのデジタル証明書を含む信用要求を受信するステップと、
前記ユーザ装置からの信用要求に応じて、前記信用管理ポリシに基づき、前記複数のサービス提供装置および／または前記複数のユーザ装置で共有された信用定義に従って記述した当該ユーザ装置の信用情報を生成するステップと、
前記生成された信用情報を信用記述デジタル証明書として前記ユーザ装置へ返送するステップと、
を有することを特徴とする信用管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワーク環境でユーザの信用を確立する技術に係り、特にユビキタス環境のような多数のサービス提供者およびユーザが混在するネットワーク環境における信用確立方法とその信用に基づいたサービス制御システムに関する。
【背景技術】
【０００２】
計算機ネットワーク上で提供されるサービスの拡大に伴い、ネットワーク上を流れる情報のセキュリティ保護のためにユーザへ提供するサービスを制御する技術が益々重要となっている。このようなサービス制御を実現する従来の方法としては、データベース等で代表的に用いられるアクセス制御が知られている(非特許文献１)。この従来のアクセス制御では、ＡＣＬ（アクセス制御リスト）を用いて、あらかじめ登録されたユーザに、どのデータに対してどのような操作(サービス)を許可(制御)するかを設定している。
【０００３】
また、特開２００１−１８４２６４号公報（特許文献１）には、アクセス制御のためのポリシ記述にアクセス許可のための条件を更に付加しておき、条件の応じた柔軟性のあるアクセス許可を可能にするアクセス制御システムが開示されている（特許文献１の段落０００８、００２７参照）。
【０００４】
またサービスを利用するユーザの信用に基づくサービス制御方式として、信用管理(Trust Management)方法がある。公開鍵暗号基盤（Public-Key Infrastructure、以下適宜ＰＫＩと略記する。）に基づく信用管理方法の一例が、非特許文献２に記載されている。この従来の信用管理方法によれば、サービスを受けようとするユーザがPKIに基づくデジタル証明書、具体的にはユーザに付随する属性のデジタル証明書(属性証明書)をシステムに提示する。システムは、システム外の証明書発行局（Certification Authority, 以下適宜ＣＡと略記する。）に問い合わせ、提示を受けたデジタル証明書の検証を行い、あらかじめシステムで保持する信用付与のためのポリシに従って、ユーザに対して一定の役割(信用)を割り当てる。ユーザは割り当てられた役割に応じて、特定のアクセス権を得て、サービスを受けることができる。
【０００５】
【非特許文献１】情報処理ハンドブック、オーム社、pp.507-508、1995
【非特許文献２】A.Herzberg, Y.Mass, J.Mihaeli, D.Naor and Y.Ravid, Access control meets public key infrastructure, or, assigning roles to strangers, IEEE Securityand Privacy, pp.2-14,2000
【特許文献１】特開２００１−１８４２６４号公報（段落０００８、００２７参照）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、非特許文献１に記載されたアクセス制御方法では、多数のサービス提供者およびユーザが混在するユビキタス環境において、個々のサービス提供者は全ユーザをあらかじめシステムに登録して提供するサービスを制御しなければならない。
【０００７】
特許文献１に記載されたアクセス制御システムでは、特定のアクセス制御サービスに依存したアクセス許可の評価方法を提供しており、汎用性や柔軟性の点で十分とはいえない。
【０００８】
また、非特許文献２に記載されたサービス制御方式では、ユビキタス環境において色々な機関が独自にデジタル証明書を発行し、世の中に通用させていくことが考えられる。この場合、デジタル証明書の発行および検証のために必ず証明書発行局ＣＡへ問い合わせを行う必要があると、ＣＡとサービスシステムとの連携が必須となり、連携できないと利用できない。
【０００９】
また、ユビキタス環境では、物品売買等の金銭が絡む硬い信用が必要なサービスと、共通の趣味や興味を持つユーザ間のコミュニティ形成のようなそれほど硬い信用が必要でないサービスとが混在する。一般に信用は硬くなりがちだが、それはユーザにとって不便であるし、逆に信用なくしてサービスを提供すればサービス提供者が損をする。
【００１０】
いずれにしても、上記従来技術では、必要とする信用を得るために、ユーザは利用するサービスごとに信用の対価として提示すべきデジタル証明書を取捨選択する必要があった。しかしながら、ユーザはいつもサービスの対価に相応しいだけの情報量を持つデジタル証明書群を選択できるとは限らず、過不足が生じてしまうことがある。サービス数が限られた範囲の少数であれば問題として表面化しなかったが、サービス数が膨大になると、サービスごとにいちいち信用確立をやり直す必要があり、そのたびに生じる提示情報の過不足が、サービスの利便性に関わる問題とユーザプライバシに関わる問題とを表面化させる。
【００１１】
また、サービス提供者にとっても、ユーザに信用を割り当てる際に、ユーザから提示されるデジタル証明書を個々に検証する必要があり、ユーザ数が膨大になるとシステムの負荷が大きくなる。その結果、サービス提供時のレスポンス低下などを招き、ユーザの利便性が低下する。
【００１２】
さらに、サービス提供者側で、ユーザから提示される情報に過不足があるとき、割り当てる信用の信頼の度合いを変化させることができなかった。例えば、十分な情報を提示されたときのみ、１００％信頼できる信用を割り当て、提示情報が不足する場合には８０％程度しか信頼のおけない信用を割り当てる、といった柔軟性のある運用はできなかった。また、ユーザが８０％信頼できる信用を割り当てられたとき、このようなユーザに対して、サービス提供者はその信用を元にサービスの提供の可否を判断することができなかった。
【００１３】
本発明の目的は、上記の問題点に鑑みてなされたものであり、膨大なサービス提供者が存在し、頻繁に信用確立が起きうるネットワーク環境において、ユーザおよびサービス提供者の両者にとって利便性良くサービスを提供できる信用確立方法、信用管理サーバ、その信用に基づくサービス制御方法およびシステムを提供することにある。
【課題を解決するための手段】
【００１４】
本発明によれば、複数のサービス提供装置および複数のユーザ装置が混在するネットワーク環境において、デジタル証明書から信用を判定するための信用管理ポリシを格納し、サービスを受けようとするユーザ装置から少なくとも１つのデジタル証明書を含む信用要求を受信し、前記ユーザ装置からの信用要求に応じて、前記信用管理ポリシに基づき、前記複数のサービス提供装置および／または前記複数のユーザ装置で共有された信用定義に従って記述した当該ユーザ装置の信用情報を生成し、前記生成された信用情報を前記ユーザ装置へ返送することで、前記ユーザ装置が前記信用情報を用いて前記複数のサービス提供装置および／または他のユーザ装置に対して自己の信用を確立することを特徴とする。
【００１５】
好ましくは、前記信用情報は前記提示された少なくとも１つのデジタル証明書の信頼性を表す信頼度を含み、前記信頼度は、当該デジタル証明書の発行後の経過時間、前記ユーザ装置から提示されたデジタル証明書の数、および／または、当該デジタル証明書を発行した発行者、に依存して決定される。
【００１６】
本発明の一実施形態では、前記信用情報の生成に使用されるデジタル証明書は、前記ユーザ装置のユーザに対して権限を与える譲渡可能な権限証明書、および／または、前記ユーザが特定の組織に依存しない属性を有することを証明する譲渡不可の属性証明書である。その属性証明書が証明する属性として、前記ユーザ装置および／または当該ユーザ装置のユーザの状態を示すコンテキスト情報を用いることができる。コンテキスト情報は、前記ユーザ装置の位置情報を含む物理的情報および前記ユーザ装置の使用状態を示す機能的情報の少なくとも一方を含むことができる。前記コンテキスト情報は、外部のコンテキストサーバに要求して受け取ることができる。
【００１７】
本発明による信用管理サーバは、デジタル証明書から信用を判定するための信用管理ポリシを格納する信用管理ポリシ記憶手段と、サービスを受けようとするユーザ装置から少なくとも１つのデジタル証明書を含む信用要求を受信すると、前記信用管理ポリシに基づき、前記複数のサービス提供装置および／または前記複数のユーザ装置で共有された信用定義に従って記述した当該ユーザ装置の信用情報を生成し信用記述デジタル証明書として前記ユーザ装置へ返送する証明書検証手段と、を有することを特徴とする。
【００１８】
本発明によるユーザ装置は、信用管理サーバに対して、少なくとも１つのデジタル証明書を提示して信用要求を行い、その応答として自己の信用を示す信用記述デジタル証明書を取得する信用取得手段と、前記取得した信用記述デジタル証明書を所望のサービスを提供するサービス提供装置あるいは他のユーザ装置へ提示してサービスを要求するサービス要求手段と、を有することを特徴とする。
【００１９】
さらに、ユーザ装置は、信用情報に応じたサービスを提供するためのアクセス制御ポリシを格納したアクセス制御ポリシ記憶手段と、他のユーザ装置から提示された信用記述デジタル証明書の信用記述と前記アクセス制御ポリシとを照合するポリシ照合手段と、前記照合結果に従って前記信用記述に応じたサービスを前記他のユーザ装置へ提供するサービス提供手段と、を設けてもよい。
【００２０】
本発明によるサービス提供装置は、共通の信用定義に従って記述された信用情報に応じたサービスを提供するためのアクセス制御ポリシを格納したアクセス制御ポリシ記憶手段と、あるユーザ装置から信用記述デジタル証明書を含むサービス要求を受けると、当該信用記述デジタル証明書の信用情報と前記アクセス制御ポリシとを照合するポリシ照合手段と、前記照合結果に従って前記信用情報に応じたサービスを前記信用記述デジタル証明書を提示したユーザ装置へ提供するサービス提供手段と、を有することを特徴とする。なお、本発明によるサービス制御システムは、前記信用管理サーバ、前記複数のユーザ装置、前記複数のサービス提供装置からなる。
【発明の効果】
【００２１】
このような構成を採用することで、ユーザは、サービス利用時、あるいはサービス利用前に信用管理サーバに自ら取得したデジタル証明書を提示し、信用管理サーバは、ユーザから提示されたデジタル証明書と、必要に応じて外部から取得したコンテキスト情報と、に基づいてユーザの信用を共通の定義に従った電子的なデータ（信用情報）として導出することができる。好ましくは、信用情報は信用記述デジタル証明書として信用管理サーバからユーザ装置へ送信される。サービス提供サーバはこの共通定義に従って記述された信用情報からユーザのサービス利用を制御することができる。このようにして、ユビキタス環境において利便性の高いサービス制御を行うことができる。より詳細には、本発明により以下の効果を得ることができる。
【００２２】
第１の効果は、ユーザが所持するデジタル証明書群を用いて共通の信用定義に従った信用情報（具体的にはデジタル証明書）を得ることができ、この信用情報を用いて、異なるサービス提供サーバやユーザ装置に対して信用を確立することができる、ことである。従って、Ｗｅｂサービスのように、複数サーバが同一ユーザに対してサービス連携するような場面で有効である。すなわち、ユーザが信用管理サーバの出力である信用情報をサービス提供者に提示するだけで、連携するサーバそれぞれからサービスを受けることができ、サービス提供サーバごとに信用管理をやり直す必要がない。
【００２３】
第２の効果は、サービスが証明書発行局ＣＡと独立に運用できることにある。その理由は、デジタル証明書には、個々のサービスに依存したユーザ属性、例えば特定の組織のアクセス制御で用いられる権限、を記述する必要はないからである。
【００２４】
第３の効果は、RFC2828(http://rfc.net/rfc2828.html)に記述されているMandatory Access Control（MAC）に従うアクセスコントロールとの親和性が高いことにある。その理由は、信用管理サーバの出力である信用に対して、その信頼度を付与することができるからである。ここで、MACに従うアクセスコントロールとは、あるリソースへのアクセスの際に最低限必須な条件を設定したアクセスコントロールである。
【００２５】
第４の効果は、サービス提供サーバが直接、ユーザの提示するデジタル証明書を検証する必要がなく、サービス提供サーバ側の処理の軽量化を期待できることにある。その理由は、信用管理サーバの出力であるユーザの信用のみを検証すれば良く、この信用の数はユーザ提示証明書数よりも少ないことが期待できるからである。
【発明を実施するための最良の形態】
【００２６】
１．第１実施形態
図１は本発明の第１実施形態によるサービス制御システムの全体構成を示すブロック図である。本実施形態によるシステムは、複数のユーザ機器１０、信用管理サーバ２０、複数のサービス提供サーバ３０、および、外部機関４０がネットワーク５０により通信可能に接続されている。ネットワーク５０としては、インターネット、ローカルアリアネットワーク（ＬＡＮ）、無線通信ネットワークなどの任意のネットワークを用いることができる。
【００２７】
なお、本実施形態における複数のユーザ機器およびサービス提供サーバの内部構成は、それぞれ共通しているので、図１においては各々１つのユーザ機器１０およびサービス提供サーバ３０の構成のみを図示している。
【００２８】
（ユーザ機器）
ユーザ機器１０は、パーソナルコンピュータ、携帯電話端末、携帯情報端末など、ネットワーク５０に接続可能な通信機能を有する端末装置であり、本発明に関係する機能的構成要素として信用取得部１０１、サービス要求部１０２、権限委任部１０３および証明書記憶部１０４を有する。なお、信用取得部１０１、サービス要求部１０２および権限委任部１０３は、図示されていないマイクロプロセッサ上でそれぞれのプログラムを実行することにより実現することも可能である。
【００２９】
ユーザ機器１０は、証明書記憶部１０４に複数のデジタル証明書を保持している。これらデジタル証明書は、証明書発行者４０１やコンテキストサーバ４０２などの外部機関４０により発行されたもの、あるいは、他のユーザ機器から権限委任により譲り受けたものも含まれる。デジタル証明書としては、後述するように、アクセス権や役割(Role)を与える権限証明書（図２参照）と、特定の組織に依存しない属性を有することを証明する属性証明書（図３参照）とがある。
【００３０】
信用取得部１０１は、あるサービスを利用するに当たって、サービスの利用前に、保持するデジタル証明書の全部または一部を信用管理サーバ２０へ送信し、信用の割り当てを要求する。
【００３１】
サービス要求部１０２は、信用管理サーバ２０から付与された信用（具体的には、信用が記述されたデジタル証明書）をサービス提供サーバ３０に提示し、サービスを要求する。
【００３２】
権限委任部１０３は、他のユーザ機器へ権限委任を実行するために、必要に応じて、権限証明書を他のユーザ機器に対して発行する。このような委任機能を使えば、例えば、ある社内の資産データへのアクセス権について、資産管理者は部署長のみに権限を与え、各部署長が自分の部下のうち必要ある者に自分の権限を委任することが可能となる。ただし、ユーザ機器に権限委任部１０３を設けなくてもよい。
【００３３】
（信用管理サーバ）
信用管理サーバ２０は、信用管理ポリシ記憶部２０３に信用管理ポリシを記憶している。信用管理ポリシは、ユーザが提示したデジタル証明書に対してどのレベルの信用を与えるかという信用管理の判定基準を宣言的に記述した推論規則、具体的には確定ホーン節形式の推論規則の集合である。この確定ホーン節で用いられる述語は、予約述語（四則演算、大小比較など）、デジタル証明書が存在することを表す述語、信用があることを表す述語からなる。推論規則では、予約述語とデジタル証明書があることに対応する述語に基づき、信用があることを表す述語を再帰的に定義する。
【００３４】
ここでホーン節とは、どのような論理的問題を記述するのにも本質的に十分な一階述語論理式のサブセットであり、確定ホーン節は、
条件１ ∧ 条件２ ∧ ... ∧ 条件ｎ → 結論
という形をした論理式である。この論理式は、Prologでは、
結論 :- 条件１, ..., 条件ｎ
と記述されるので、本明細書ではポリシを記述する際はPrologの表記に準じるものとする。
【００３５】
証明書検証部２０１は、ユーザ機器１０から提示されたデジタル証明書および必要であればコンテキスト情報を前提条件として、信用管理ポリシに従って当該ユーザの信用があることを表す述語の真偽を出力し、所定の共通した記述方式により信用を表現してユーザ機器１０へ返す。なお、後述するように、この信用判定処理に先立って、提示されたデジタル証明書の検証が行われるが、このデジタル証明書の検証は外部の証明書発行部４０１に問い合わせる周知の方式を採用することができる。
【００３６】
外部証明書取得部２０２は、信用要求を行ったユーザ機器の現在の状況に関する情報、すなわちコンテキスト情報を取得することができる。具体的には、システム外のコンテキストサーバ４０２に問い合わせ、必要に応じて該当ユーザ機器のコンテキスト情報を取得する。コンテキスト情報は、属性証明書で証明される情報の一種であると考えることができる。
【００３７】
コンテキスト情報としては、ユーザ機器の位置情報などの物理的な周辺環境に関する物理的情報の他に、ユーザ機器の使用状態（通信中、電話中など）などユーザの行動に関する機能的情報、あるいは、必要があればユーザの心拍数などの身体的状態を示す生理的情報などを含めることも可能である。ユーザ機器の位置情報は、携帯通信端末であれば通信中の基地局の位置から得ることができ、必要があればユーザ機器にＧＰＳ等の位置検出手段を設けてもよい。また、生理的情報は、ユーザの身体にモニタを取り付けて、その出力情報をコンテキストサーバ４０２へネットワークを通して送信すればよい。
【００３８】
また、ユーザのコンテキスト情報は、ユーザ自らコンテキストサーバ４０２から属性証明書として取得して信用管理サーバ２０に提示してもよい。
【００３９】
（サービス提供サーバ）
サービス提供サーバ３０は、アクセス制御ポリシ記憶部３０３にアクセス制御ポリシを記憶している。アクセス制御ポリシは、信用管理サーバ２０が付与した信用に基づいて当該ユーザにサービス提供を許可するか否かを判定する判定基準を宣言的に記述した推論規則の集合である。ポリシ照合部３０１は、アクセス制御ポリシに従って、当該ユーザのサービル利用権限の行使を許可するか否かを決定する。
【００４０】
サービス提供部３０２は、ポリシ照合部３０１によってサービス利用の行使を許可されたユーザ機器に対し、許可されたサービスを提供する。後述するように、ユーザ機器の持つ信用の信頼度の大小に応じてサービス提供内容を変えることもできる。
【００４１】
（デジタル証明書）
上述したように、デジタル証明書としては、権限証明書および／または属性証明書を用いる。権限証明書は内容を委任できる(他人に譲れる)が、属性証明書は内容を委任できない(他人に譲れない)という性質を持つ。
【００４２】
図２は権限証明書の一例を示す模式図である。権限証明書は、発行者i、対象者(権利を与える対象主体)s、権利(アクセス権)a、および、委任可能回数dを内容として含む。さらに、証明書本体に記載されるものではないが、証明書のセキュリティパラメタsp(署名鍵の鍵長や発行日の古さから決まる値)も証明書の内容と考える。一方、有効期限が過ぎていないかどうかなどの検証は、外部の証明書発行部４０１に問い合わせることで行われると考え、信用管理ポリシでは考慮しない。上記i, s, a, dおよびspを内容とする権限証明書が存在するか否かの判断は、以下、述語c_certを用いてc_cert(i, s, a, d, sp)で表す。
【００４３】
また、権限証明書の委任とは、たとえば次のような場合をいう。すなわち、ｘが発行した「ｙに権限ａを与える」権限証明書とｙが発行した「ｚに権限ａを与える」権限証明書とが存在するならば、ｘが発行した「ｚに権限ａを与える」権限証明書が存在するものとみなし、ｚにaの行使を許可する、ということである。より一般的には、権限の委任は、ｘがｙに与えた権限ａ１に対し、ｙはｚにａ１の一部のみ委任すること、すわわち、ｘがｙに権限ａ１を、ｙがｚに権限ａ２を与えた場合、ｚは権限ａ１とａ２の最小上界が与えられると考える。
【００４４】
また権限証明書発行部が権限の委任を禁止したり、委任の連鎖回数を制限したりする場合も考えられる。委任回数の制御に関しては、連鎖回数の上限を指定することで行う。委任可能回数を０あるいは無限大に限定することで、委任の禁止または許可のどちらかを指定することもできる。
【００４５】
図３は属性証明書の一例を示す模式図である。図３を参照すると、属性証明書の内容は、発行者i、対象者s、属性名at、属性値v、および、セキュリティパラメタspを含む。i, s, at, v, spを内容とする属性証明書が存在するか否かの判断は、以下、述語v_certを用いてv_cert(i, s, at, v, sp)で表す。
【００４６】
（信用）
図４は権限証明書に付与される信用情報の一例を示す模式図である。この信用情報は、発行者i、対象者s、権限a、委任可能回数d、セキュリティパラメタsp、委任の連鎖回数(深さ)dp、および、信頼度rから構成される。このような信頼度rを含む信用情報は、発行者i、対象者s、権限a、委任可能回数d、セキュリティパラメタsp、委任の連鎖回数(深さ)dpであるような権限証明書が存在するのと同じだけの信用を、信頼度rで対象者sに与えることを意味している。以下、この信用を述語c_belを用いてc_bel(i, s, a, d, sp, dp, r)で表す。
【００４７】
c_belの信頼度rとは、対象者sが不正(サービス提供者にとって不都合な行為)をする危険性が少ないことを表す値である。例えば、spが低い場合、デジタル証明書は偽造品である可能性があり、従って対象者は攻撃者である可能性がある。この場合、信頼度rが低い信頼しか与えられない傾向がある。一方、対象者sは未知のユーザだが発行者iは信用できる場合、対象者sもある程度信用できると考えられる。この場合、信頼度rが高い信頼を与えられると考える。どのような場合にどのような信頼度を与えるかは、ポリシ記述者が、推論規則中で適当な関数を組み合わせて定義する。
【００４８】
図５は、属性証明書に付与される信用情報の一例を示す模式図である。この信用情報は、対象者s、属性at、属性値v、および、信頼度rから構成され、対象者sの属性atの値がvであることを信頼度rで信用することを表す。以下、この信用を述語v_belを用いてv_bel(s, at, v, r)で表す。
【００４９】
v_belの信頼度rは、デジタル証明書の内容(対象者がその属性値をもつこと)が正しいことを表す値である。例えば、複数の証明書発行者が同じ属性値を証明していれば信頼度が高い、Ａ機関のデジタル証明書の発行者なら、信頼度が高い、Ｂ機関なら信頼度は１／３、などのようにポリシ記述者の考えに基づいて、推論規則中で自由に定義することができる。もちろん、上記の述語を必ず使用しなければいけないわけではなく、信用があることを表す述語としてどのようなものを使うかを、信用管理サーバとサービス提供者との間で取り決めてもかまわない。このように信用c_belあるいはv_belに信頼度ｒを含めることで、Mandatory Access Control (MAC)に従ったアクセスコントロールとの親和性が高くなるという利点がある。
【００５０】
このようにして信用管理サーバ２０が割り当てる信用の記述式は、サービス提供サーバで共通に認識可能である。すなわち、サービス提供サーバ３０のポリシ照合部３０１は、アクセス制御ポリシを参照し、対象者ｓが権限aを有するかどうか（以下、c_belの真偽という。）、および、その信頼度ｒの大小に基づいて、aの行使を許可するかどうか決定することができる。例えば、c_bel(i, u, a, d, sp, dp, r)が真で、かつ信頼度ｒ＞０．９ならば、対象者uが権限aを行使することを許すというように判断する。また、権限の行使を許可するかどうかを決める際、v_belが真かどうか、およびその信頼度の大小に基づいて、ユーザの属性を利用することもできる。例えば、Ａ社の社員であれば許可する、Ａ社の社屋内に居れば許可する、などである。この場合、社屋内にいるか否かはコンテキスト情報として得ることができる。
【００５１】
なお、c_belおよびv_belが予め決められた信頼できる信用管理サーバ２０によって与えられたものである否かは、信用管理サーバ２０の公開鍵を利用した署名検証処理によって判定することができる。ただし、c_belおよびv_belが信用管理サーバ２０の秘密鍵で署名されること、サービス提供サーバ３０があらかじめ信用管理サーバ２０の公開鍵を保持していること、が前提である。この署名検証処理に関しては広く知られているのでその詳細な方法については省略する。
【００５２】
（システム動作）
図６は、図１に示すシステムの全体的動作を示すシーケンス図である。まず、ユーザ機器１０は、サービス提供サーバ３０にサービスを要求するに先立って、信用管理サーバ２０に対して自己の信用の割り当てを要求する。すなわち、ユーザ機器１０は、自身が一般に複数所持するデジタル証明書のうちの全部または一部を選択して(Ｓ６０１)、ネットワーク５０を介して信用管理サーバ２０に送信し、信用確立要求を行う(Ｓ６０２)。
【００５３】
信用管理サーバ２０は、ユーザ機器１０からデジタル証明書を受信すると、システム外の証明書発行部４０１に対して当該デジタル証明書の有効性の検証を要求する(Ｓ６０３)。
【００５４】
外部の証明書発行部者４０１は、信用管理サーバ２０の検証要求に応じて、当該デジタル証明書の検証、具体的にはデジタル証明書の有効期限を過ぎていないか、改ざんされていないかなどの検証を行う（Ｓ６０４）。検証結果は、当該検証要求を行った信用管理サーバ２０に返す。
【００５５】
また、信用管理サーバ２０が、ユーザ機器１０の現在のコンテキストを知り得るコンテキストサーバ４０２と通信できるのであれば、ユーザのコンテキスト情報をコンテキストサーバ４０２に対して要求する（Ｓ６０５）。コンテキストサーバ４０２は、その要求に対する応答として、当該ユーザのコンテキスト情報を信用管理サーバ２０へ返す（Ｓ６０６）。信用管理サーバ２０は、コンテキストサーバ４０２から取得したコンテキスト情報をユーザ機器１０の属性証明書として扱う。
【００５６】
こうして、証明書発行部４０１によってユーザ端末１０から受け取ったデジタル証明書が有効であると検証され、必要に応じてコンテキストサーバ４０２からユーザ機器１０の属性証明書を受信すると、信用管理サーバ２０は、有効なデジタル証明書が存在することを表す述語を真に置き換え、それを公理化する。そして、信用管理サーバ２０は、信用管理ポリシ記憶部２０３の信用管理ポリシの推論規則を再帰的に適用し、信用があることを表す述語の真偽を求める（Ｓ６０７）。信用があることを表す述語の真偽を全て導出できたら、信用管理サーバ２０は、真偽が導出された述語からなる信用記述デジタル証明書を当該ユーザ機器１０の信用としてユーザ機器１０に応答する（Ｓ６０８）。この信用記述式は、複数のサービス提供サーバあるいは所定のサービス提供サーバ群で共通に認識可能であることが必要である。
【００５７】
ユーザ機器１０は、サービスの利用を要求するサービス提供サーバ３０に対して、信用管理サーバ２０から受け取った信用記述デジタル証明書を提示する。サービス提供サーバ３０は、信用管理サーバ２０によって割り当てられた信用、すなわち信用があることを表す述語の真偽に対して、アクセス制御ポリシ中の推論規則を再帰的に適用し、サービスの提供を許可することを表す述語の真偽を求める（Ｓ６１０）。サービスの提供が許可されるならば、当該ユーザ機器１０に当該サービスを提供する（Ｓ６１１）。
【００５８】
なお、本実施形態では、ユーザ機器１０がサービス提供サーバ３０へサービス要求する前に、信用管理サーバ２０から信用を取得し、その信用をサービス提供サーバ３０に提示してサービスを要求する場合を示したが、信用管理サーバ２０が代理してサービス要求を行ってもよい。すなわち、信用管理サーバ２０がユーザ機器１０からのサービス要求をＷｅｂサーバにおけるプロキシ（proxy）サーバのように代理的に受け、サービス提供サーバ３０に対してユーザ機器１０の代わりにユーザ機器１０の信用を提示し、サービス要求を行ってもよい。このとき、サービス提供サーバ３０と信用管理サーバ２０との間に信頼関係が結ばれていれば、提示する信用の検証処理を省略することもできる。
【００５９】
また、本実施形態では、信用管理サーバ２０がユーザ機器１０から提示されたデジタル証明書に基づいて当該ユーザ機器１０の信用を導出したが、ユーザ機器１０以外から当該ユーザのデジタル証明書を取得してもよい。たとえば、ユーザのデジタル証明書を管理するレポジトリが外部に存在し、信用管理サーバ２０がそこからユーザに係わるデジタル証明書を取得できるのであれば、その取得したデジタル証明書を信用の導出に利用することができる。
【００６０】
あるいは、あるサービス提供サーバ３０がユーザの信用を元にサービスを提供した事実をデジタル証明書として取り扱うことも可能である。すなわち、サービスを提供した事実をデジタル証明書として上記レポジトリに保存しておき、信用管理サーバ２０が、そこから対応するデジタル証明書を取得し、それに基づいて信用を導出してもよい。
【００６１】
また、本実施形態では、信用管理サーバ２０がどのデジタル証明書が必要かをユーザに知らせること、あるいは、ユーザがデジタル証明書を入手する手段をユーザに知らせることについては考慮しなかったが、信用管理サーバ２０がこれを行うことで、信用管理サーバ２０、さらには信用管理サーバ２０と信頼関係のあるサービス提供サーバ群と、ユーザ機器１０との間での信用交渉が可能である。
【００６２】
たとえば、サービス提供側が、ユーザに対して、提示されるデジタル証明書によって得られる信用とそれによって受けられるサービスとの対応を示すことで、ユーザは提供するデジタル証明書のレベルと要求するサービスとを比較することができ、ユーザが提供する情報とそれによって得られる情報とがマッチした最適なサービスの提供が可能となる。
【００６３】
次に、信用管理ポリシの記述例をもとに本発明の実施例について説明する。ただし、記載を簡略化するために、述語c_cert, c_bel, v_cert, v_belは記述例に関係する引数だけを記載し、それ以外は省略している。
【００６４】
（実施例１）
本発明の第１実施例として、ユーザから提示されたデジタル証明書の存在やコンテキストに応じて顧客へのサービスを変化させるような電子商取引を説明する。ここでは、次のポリシを考える：
支店Sは、自分から距離D以内に居るポイントC点以上の顧客uに対し、割引率を高くする。ただし、ポイントはSの本社ｃが認定した機関ｘが発行したものでなければならない。
【００６５】
このとき、信用管理サーバ２０は、顧客uが割引率discountという属性値に、割引率が高いことを示すhighという値が設定されているかどうかを信用v_bel(u, discount, high)の真偽として出力するものとすると、信用管理ポリシは図７のように記述される。
【００６６】
図７は本発明の第１実施例における信用管理ポリシの記述例を示す図である。図７の第１行目の記述は、uがC点以上のポイントv1点を持つことを、属性pointの値がv1であることを証明する属性証明書が存在することとして表している。第２行目の記述は、この属性証明書の発行者xは、本社cから認定証、すなわち、属性authに関する属性証明書を発行されていなければならないが、属性authに関する属性証明書でも、authの属性値v2に90以上の数値を持たなければ認定しない、ことを意味している。なお、branch(S, c)は、Sがｃの支店であることを表す述語である。第３行目の記述において、コンテキストサーバ４０２から発行された属性証明書に基づいて導出された信用であるv_bel(S, pos, d1), v_bel(u, pos, d2)によってSやuの地理的位置を表わし、dist(d1, d2)がＤ以下である条件により、顧客ｕの支店Ｓからの距離の条件を示している。なお、dist(d1, d2)は、２地点d1、d2の間の距離を表す関数であり、予め定義されているものとする。
【００６７】
（実施例２）
次に、社内で管理されているファイルに対するアクセス制御の例を考える。ここでは、次のポリシを考える：
X社社員は自由にアクセス可。外部職員はX社内に居るときのみアクセス可。
【００６８】
このとき、信用管理サーバ２０は、ユーザuにアクセス権aを与えるべきかどうかを信用c_bel(sv, u, a)の真偽として出力するものとすると（ただし、svはサービス提供者、すなわちファイル管理者である）、信用管理ポリシは図８のように記述される。
【００６９】
図８は本発明の第２実施例における信用管理ポリシの記述例を示す図である。uが社員または外部社員であるときは、属性roleに関するX社が発行した属性証明書が信用管理サーバ２０に入力されるものとしている。ここで、属性roleが属性値fullという値である属性証明書は正社員であることを示すデジタル証明書である。属性roleがadjunctという属性値である属性証明書は、外部社員であることを示すデジタル証明書である。region(sv)はsvの社内の地理的範囲を表す関数、in(d,re)は地点dが範囲re内にあることを表す述語である。
なお、この実施例では、社内で管理されているファイルに対するアクセス制御に関して述べたが、社外から社内のネットワークにＶＰＮ技術を用いてアクセスする際のアクセス制御ポリシも、もちろん同様な一階述語論理で表現できる。
【００７０】
（実施例３）
次に、「X社社員は自由にアクセス可。社員から委任された共同作業者、及び、共同作業者から委任された協力者は、社員が２名以上近くに居るときだけアクセス可」というポリシを考える。このとき、信用管理ポリシは図９のように記述される。
【００７１】
図９は本発明の第３実施例における信用管理ポリシの記述例を示す図である。第１行目において、社員から共同作業者および協力者への権限の委任を表現するため、svから属性roleの値がfullであることを証明する属性証明書(たとえば社員証)を発行されたユーザuは、委任回数２回までの権限証明書に相当する信用c_bel(sv, u, a', 2)を持つものとして扱われる。アクセス権a'は信用管理ポリシ中での作業用に導入したもので、ｕがa'に関する権限証明書を持ち、かつ、社員である(４行目)または社員２名ｘ、ｙが近くに居る(６〜８行目)という条件を満たすときのみ、ｕに権限aを許可するようにしている。
【００７２】
（実施例４）
次に、「社内からのアクセス許可は、部長→課長→・・・と委任できる。このとき、委任の深さに応じて信頼度を下げる。社外からアクセスする場合は、社内からのアクセスが許可されていると同時に、部長が直接発行した許可証を持っていなければならない。また、コンテキストに依存して、例えば社外の公衆の面前では信頼度・アクセス権を下げ、他者との打ち合わせなどでは信頼度・アクセス権を上げる」というポリシを考える。このとき、信用管理ポリシは図１０のように記述される。
【００７３】
図１０は本発明の第４実施例における信用管理ポリシの記述例を示す図である。まず、部長に、委任回数H回、信頼度１００の権限証明書を与えている(１行目)。そして、委任を許すと同時に、委任の深さが１深くなるごとに信頼度を０．９倍している(２行目)。３行目から８行目では、作業用に導入したアクセス権a', a"を使って、aに関する信用c_bel(sv, u, a, 0, r)の真偽を定義している。uが社外に居る場合、部長が発行したデジタル証明書v_bel(x, u, auth, use_outside)が必要である(５行目)。また、打ち合わせ中であるというコンテキストv_bel(u, situation, meeting)が得られた場合(６行目)は、信頼度を下げないが、公衆のアクセスポイントに居る場合は信頼度を０．６倍する(７〜８行目)。アクセス制御ポリシでは、信用管理サーバが出力した信用c_bel(sv, u, a, d, r)中の信頼度rを使って、実際にアクセスを許可するかどうかを決める。
【００７４】
（実施例５）
上述した実施例では信用管理ポリシについて述べたが、アクセス制御ポリシも同様な一階述語論理で表現できる。
【００７５】
図１１は本発明の第５実施例におけるアクセス制御ポリシの記述例を示す図である。アクセス制御ポリシの目的は、信用管理サーバ２０が出力したc_belおよびv_belの真偽および信頼度ｒに基づいて、アクセス権aの行使を許すかどうか決めることである。サービス提供者Ｓがユーザｘに権限ａの行使を許すことをpermit(x, a)と書くとすると、例えば図１１のようにアクセス制御ポリシを定義できる。ただし、thres1()、thres2()、thres3()は、ポリシ記述者が定義する信頼度のしきい値関数である。
【００７６】
たとえば、第１行目において、c_bel(S, x, a, d, sp1, dp, r1)が真であり、かつ、その信頼度r1がしきい値thres1(a)以上であるならば、ユーザｘは権限ａの行使を許可される。
【００７７】
なお、信用管理ポリシやアクセス制御ポリシを確定ホーン節で記述し推論する例を示したが、ユーザが提示したデジタル証明書というような事実を公理として、信用を推論できる形式であれば、他の形式でもよい。
【００７８】
２．第２実施形態
図１２は本発明の第２実施形態によるサービス制御システムの全体構成を示すブロック図である。本実施形態によるシステムでは、複数のユーザ機器１１（１１ａ、１１ｂ、１１ｃ・・・）が相互にサービスを提供することが可能である点が第１実施形態とは異なっている。その他、ユーザ端末１０、信用管理サーバ２０、サービス提供サーバ３０、外部機関４０およびネットワーク５０などは図１の第１実施形態と同様であるから説明は省略する。なお、複数のユーザ機器１１の内部構成は共通しているので、図１２においては１つのユーザ機器１１の構成のみを図示している。
【００７９】
ユーザ機器１１は、パーソナルコンピュータ、携帯電話端末、携帯情報端末など、ネットワーク５０に接続可能な通信機能を有する端末装置であり、本発明に関係する機能的構成要素として信用取得部１０１、サービス要求部１０２、権限委任部１０３、証明書記憶部１０４、ポリシ照合部１０５、サービス提供部１０６、および、アクセス制御ポリシ記憶部１０７を有する。なお、信用取得部１０１、サービス要求部１０２、権限委任部１０３、ポリシ照合部１０５、および、サービス提供部１０６は、図示されていないマイクロプロセッサ上でそれぞれのプログラムを実行することにより実現することも可能である。
【００８０】
信用取得部１０１、サービス要求部１０２、権限委任部１０３、および、証明書記憶部１０４は、図１に示す第１実施形態のユーザ機器１０と同じ機能を有するので同じ参照番号を付している。ポリシ照合部１０５、サービス提供部１０６、および、アクセス制御ポリシ記憶部１０７は、図１に示す第１実施形態のサービス提供サーバ３０におけるポリシ照合部３０１、サービス提供部３０２、および、アクセス制御ポリシ記憶部３０３と同様の機能を有する。
【００８１】
このような構成を有することで、各ユーザ機器は信用管理サーバ２０に対して上述したように信用要求を行い、その信用応答によって信用を確立することができる。たとえば、ユーザ機器１１ａが信用管理サーバ２０から信用を割り当てられると、その信用記述デジタル証明書を他のユーザ機器１１ｂに提示して、ユーザ機器１１ｂから所望のサービスの提供を受けることが可能である。サービス要求やサービス応答は、第１実施形態で説明した通りであるから詳しくは省略する。
【図面の簡単な説明】
【００８２】
【図１】本発明の第１実施形態によるサービス制御システムの全体構成を示すブロック図である。
【図２】本実施形態における権限証明書の一例を示す模式図である。
【図３】本実施形態における属性証明書の一例を示す模式図である。
【図４】権限証明書に付与される信用情報の一例を示す模式図である。
【図５】属性証明書に付与される信用情報の一例を示す模式図である。
【図６】図１に示すシステムの全体的動作を示すシーケンス図である。
【図７】本発明の第１実施例における信用管理ポリシの記述例を示す図である。
【図８】本発明の第２実施例における信用管理ポリシの記述例を示す図である。
【図９】本発明の第３実施例における信用管理ポリシの記述例を示す図である。
【図１０】本発明の第４実施例における信用管理ポリシの記述例を示す図である。
【図１１】本発明の第５実施例におけるアクセス制御ポリシの記述例を示す図である。
【図１２】本発明の第２実施形態によるサービス制御システムの全体構成を示すブロック図である。
【符号の説明】
【００８３】
１０  ユーザ機器
１０１  信用取得部
１０２  サービス要求部
１０３  権限委任部
１０４  証明書記憶部
１０５  証明書検証部
１０６  外部証明書取得部
１０７  信用管理ポリシ記憶部
２０  信用管理サーバ
２０１  証明書検証部
２０２  外部証明書取得部
２０３  信用管理ポリシ記憶部
３０  サービス提供サーバ
３０１  ポリシ照合部
３０２  サービス提供部
３０３  アクセス制御ポリシ記憶部
４０  外部機関
４０１  証明書発行者
４０２  コンテキストサーバ
５０  ネットワーク
【図１】
2006004314.tif 000003
【図２】
2006004314.tif 000004
【図３】
2006004314.tif 000005
【図４】
2006004314.tif 000006
【図５】
2006004314.tif 000007
【図６】
2006004314.tif 000008
【図７】
2006004314.tif 000009
【図８】
2006004314.tif 000010
【図９】
2006004314.tif 000011
【図１０】
2006004314.tif 000012
【図１１】
2006004314.tif 000013
【図１２】
2006004314.tif 000014