JP4668610B2 - サービスプロバイダのサービスに対するユーザ認証の方法 - Google Patents

Description

本発明は認証の分野に関し、特に、サービスプロバイダのサービスに対するユーザ認証の方法に関するものである。

インターネット上のウェブサイトや電子商取引のような多くの電子的に利用できるサービスは、多くの目的のためにユーザの識別(identification)や認証(authentication)を必要とする。例えば、Ｗｅｂメールへのアクセスやオンラインバンキングのような、秘密情報やサービスや情報源へのアクセスを提供したり、ユーザプロファイルに応じて個別化されるサービスを提供したり、データマイニングすなわち、例えば顧客としてのユーザの振る舞いのプロファイルを作成することにより、ユーザとサービスの間の多数のやりとりから結論を引き出したり、例えばユーザが常に請求金額を支払っているかを確認するようなことによって、電子商取引アプリケーションにおいてユーザのクレジットカードの有効性を検証したり、という目的のためである。また、ユーザの特定と認証は、例えば乗り物や会社ビルのドアや、ハンドルのような物理的な設備にアクセスするような、他の形態のサービスへのアクセスを許可するためにも必要となりうる。

識別(identification)とは、ある特定のユーザやユーザグループを明白に識別(identify)する、ＩＤ(identity)の特定(specification)のことを意味する。識別されたＩＤは、特定の人又は人々のグループを追跡することができる場合もあるし、できない場合もある。すなわち、ＩＤはユーザの名前の明瞭なテキストの場合もあるが、任意に選択されたログイン名の場合もある。唯一の要件は、単一の人、又は、グループログインの場合は特定の人々のグループに属する人が、登録されたユーザの特定が可能な基礎となる特定のユーザＩＤで登録したということである。例えば一例として、サービスプロバイダのサービスにアクセスするユーザのログイン名を考える。認証は、ＩＤの検証、例えばある特定のＩＤを示しているユーザが最初に同一のＩＤで登録したユーザと本当に同一のユーザであるかの検証、として定義される。

認証は、ユーザ証明を検証することにより行なわれる。ユーザ証明には、主に３種類ある。第１に、ユーザの所有する何か、例えば、鍵、ＩＣカード、パスポート、社員証、などがある。第２に、ユーザが知っている何か、例えば、パスワード、個人識別番号（ＰＩＮ）、母親の旧姓、などがある。第３に、ユーザの身体的特徴、例えば、虹彩（アイリス）、声、指紋、顔の特徴、筆跡、などがある。

ユーザ認証は、単一の又は複数の種類の証明の検証からなるようにしてもよい。例えば、パスワードのみでもよいし、社員証の所有とＰＩＮコードを知っていることとの組み合わせからなるようにしてもよい。ユーザＩＤ、例えばユーザ名は、認証時にユーザから収集されたユーザ証明を、登録されたユーザＩＤに対応するユーザ証明と関係付ける、同一性確認ステップ(identification step)で用いられる。収集されたユーザ証明と登録されたユーザ証明が一致することを検証することにより、ユーザＩＤの検証とそれに伴う認証は達成されうる。したがって、認証は一般的に、必要条件として認証の要求されるエンティティの同一性を含み、ユーザ登録は一般的に、認証に必要である。

従来、各々のサービスプロバイダは一般的には、独自にユーザの識別と認証を行なっていた。例えば、最も一般的にはユーザ名とパスワードによるものであろうし、安全（セキュア）な転送プロトコルを使用する可能性もある。また、独自にユーザプロファイルデータベースを管理していた。ユーザにとっての欠点は、ユーザは一般的に、ユーザＩＤとパスワードの異なる組み合わせ、あるいはより一般的には、ユーザＩＤと証明の異なる組み合わせを、異なるサービスプロバイダごとに記憶しなければならないことであり、これは不便で、かつ、ほとんどの場合、ユーザが自分の異なるユーザＩＤとそれに対応する個々のパスワード（証明）を書き留めておくと、あまり安全ではない。ユーザが異なるサービスプロバイダに対し同一の又は類似する組み合わせを使用すると、セキュリティはさらに危険にさらされる。サービスプロバイダにとっての欠点は、独自のデータベースを維持しなければならず、かつ、認証のためのすべてのステップを自分自身で実行しなければならないということである。さらに、サービスプロバイダによる認証は一般的に、技術的・経済的理由により、単一の又は極めて限られた数のユーザ証明の種類に基づいている。なぜなら、異なる種類のユーザ証明を収集し処理する適切なインフラを構築するにはコストがかかるからであり、このことは、バイオメトリックスに基づく方法や携帯電話の加入者識別モジュール（ＳＩＭ）カードのようなＩＣカードに基づく方法といった先進の認証方法を導入することの深刻な障害である。

最近、例えばMicrosoft（登録商標）Passport（例えばMicrosoft Passport Technical White Paper, March 2001, http://www.passport.com参照）のような、認証を実際のサービスから分離することを目的とする、数多くの技術が登場してきている。この場合、「アイデンティティプロバイダ(Identity Provider, ＩｄＰ)」がユーザ登録に責任を持ち、ユーザがサービスにアクセスすることを欲するときはいつも、ＩｄＰがユーザ認証に責任を持つ。ユーザ登録とユーザ認証は単一のエンティティに実装することもできるし、分離して実装することもできる。実際のサービスのプロバイダ(Service Provider, ＳＰ)は、アイデンティティプロバイダと同一であってもよいし、同一でなくてもよい。アイデンティティプロバイダはそれ自身でいくつかのサービスのプロバイダとして機能しうるし、さらに、外部のサービスプロバイダに対してアイデンティティサービスを提供することもできる。Microsoft（登録商標）Passportでは、ユーザ認証は常にユーザ名／パスワード方式によりなされ、ＳＳＬによって転送され、Microsoft（登録商標）Passportに登録されているあらゆる種類のサービスにアクセスする際は、パスワードを変更する合間という制約が一切ない。

アイデンティティプロバイダとサービスプロバイダの機能の分離には、多くの利点がある。すなわち、サービスプロバイダは必ずしも独自のユーザ登録と認証を扱う必要はなく、この作業をアイデンティティプロバイダに「委託(outsource)」することができる。しかし、さらに重要なことに、ユーザは異なるサービスにわたって単一の一貫したログイン手続きをするだけで用が足りる。前述のように、現在ユーザは各々のサービスプロバイダごとに独立した認証証明を記憶し、かつ／又は、所有する必要があり、さもなければ、ユーザはパスワードのような証明を使いまわし(re-use)、その結果もちろんセキュリティを危険にさらすことになる。例えば、ユーザがＷｅｂポータルサイトで入力する暗号化されていないパスワードを攻撃者が盗み見ると、攻撃者はそれを用いてユーザの同じパスワードのオンライン銀行口座にアクセスを試みることができる。

しかし、有名なアイデンティティプロバイダソリューションであるMicrosoft（登録商標）Passportは異なるサービスやサービスプロバイダごとの異なるセキュリティ要求を区別しない。サービスプロバイダによるセキュリティ要求は認証が必要である目的に強く依存しうる。単に個別化されたＷｅｂポータルサイトを提供するためには、銀行口座へのオンラインアクセスや重要な金銭取引の認証に比べて、一般的に低いセキュリティレベルで十分である。むしろ、Microsoft（登録商標）Passportは、単一の証明の種類に基づいて、認証されているか認証されていないかというような、２値に決まる認証を考慮し、ユーザ名−パスワードの組み合わせに基づく固定的な認証手法はアイデンティティプロバイダとサービスプロバイダの双方に馴染みがあり、事前に明示的／黙示的に合意していると想定している。これには明らかに数多くの欠点があり、そもそも、異なるサービス／情報源ごとに異なる種類のセキュリティ要求を扱うことができず、時間の経過に伴うセキュリティ要求の変化を扱えないということを含む。もしPassportのようなアイデンティティプロバイダが認証プロセスを変更すると決定すると、各々のサービスプロバイダに別個に帯域外の(out-of-band)方法を使って連絡を取る必要があり、そうでなければ、サービスプロバイダは単純に、アイデンティティプロバイダが行なうあらゆる変更が「合理的であること」を希望しなければならない。

ＷＯ ０１／１１４５０ は、複数の情報源に対して単一の符号で認証するシステムアーキテクチャ及び方法を開示している。セキュリティアーキテクチャは、信用レベル(trust-level)の要求を情報源と結び付け、パスワード、証明、バイオメトリック技術、ＩＣカードに基づく認証の仕組みは、信用レベルと結び付けられる。十分な信用レベルでの事前の認証無しに情報源へのアクセス要求を受け取ると、クライアントエンティティと情報源の間に置かれたゲートキーパー(gatekeeper)は、十分な信用レベル及び適切な証明の種類の組み合わせの間で通信を確立するためのマッピングルールに応じて、クライアントエンティティのログイン証明を取得するために証明収集サービスを利用する。

ＷＯ ０１／１１４５０ Ａ１ に記載されているシステムには、数多くの制限がある。そもそも、それは、情報源と信用レベルとの関係、信用レベルと認証に使われる証明の種類との間のマッピングルールに依存しており、共に、アイデンティティプロバイダの機能を提供するエンティティと情報源との間の関係とマッピングルールについて事前の知識と事前の合意を必要とする。さらに、同じ信用レベルに関係付けられるすべての情報源は、同じ方法で扱われる。このことは、アイデンティティプロバイダが関連付け及び／又はマッピングルールを変更することを決めるときはいつも、特に問題となる。なぜなら、変更の影響を受ける情報源（又はそれぞれの情報源のプロバイダ）は必ずしも全てが、例えばセキュリティ、技術、ビジネスに関する理由により、変更を受け入れ可能であるとは限らないからである。それゆえ、結局は、情報源のプロバイダ又は情報源そのものではなく、アイデンティティプロバイダが認証プロセスを決定する。すなわち、どの特定の証明を特定の認証に使用するかを決定する。

しかし、アイデンティティプロバイダによって行なわれるこれらの種類の方針決定は、多くのサービスプロバイダは受け入れることができない。関連付け又はマッピングルールの更新はそれゆえ、サービスプロバイダとの争いを引き起こしうる。固定的な又は事前に定義された関連付けやマッピングルールは関連するエンティティの要求を満たせるほど柔軟ではない。加えて、特に増加しつつある多量多様な認証方法と、時には急速に変化するサービスプロバイダの要求という観点から、すべてのサービスプロバイダとすべての種類のサービスの多様なセキュリティ要求を満足させるには、事前に定義された関係付けとマッピングルールによる認証の仕組みと証明の種類の、可能性のあるすべての組み合わせを表現することは、さらに複雑である。極めて多様な可能性について事前に定義された関係付けやマッピングルールは本来的に柔軟性に欠けるため、新しいセキュリティ要求に従った認証がなされうる前に、可能であるなら、わずらわしい関係付けとマッピングルールの更新作業が行なわれなければならない。この柔軟性に欠けることは、例えば新たに導入された、いかなるものにも関連付けられていないサービスにアクセスしようとするときや、確かな信用レベルが要求されるときのような、特別な状況では特に欠点である。さらなる制限は、クライアントとアクセスされた情報源との間のセッションにおける要求と応答を含むすべての情報の流れは、中継コンポーネントとしてのゲートキーパー(gatekeeper)を通るということである。しかし、ユーザクライアントとサービスプロバイダとの間のすべての情報の流れの中継コンポーネントとしてアイデンティティプロバイダを使用すると、不必要にアイデンティティプロバイダの負荷が増加する。

Microsoft（登録商標）PassportとＷＯ ０１／１１４５０ Ａ１ に共通する他の制限は、単一のアイデンティティプロバイダが認証目的に使用されることである。この制限は、ユーザとサービスプロバイダに、単一のアイデンティティプロバイダを信用することを強制する。しかし、集中化された認証実体はしばしば、プライバシーや信用性、ビジネス、コストの理由から、ユーザとサービスプロバイダにとって受け入れることができない。例えば、不要なデータの集合や詐欺を防止するために、ユーザは、異なる種類の証明のようなユーザに関係する情報が、単一のアイデンティティプロバイダに集められることを望まないかもしれない。
ＷＯ ０１／１１４５０

本発明の目的は、サービスプロバイダのサービスに対するユーザ認証をより安全で柔軟性のある方法で提供する方法、装置、コンピュータプログラムを提供することである。

この目的は、請求１乃至９に記載の方法で達成される。さらに、本発明は請求項１５、２１、２７及び３４に記載の装置並びに請求項３６及び３７に記載のコンピュータプログラムにより、実装される。有効な実装がさらなる請求項に記載されている。

サービスプロバイダのサービスに対するユーザ認証の方法を開示する。

本方法は、サービスプロバイダのサービスに対するユーザのアクセス要求により開始する。要求はユーザの装置からサービスプロバイダに送られ、サービスプロバイダが以下のステップを進めるきっかけとなりうる。代わりに、要求は事前に設定され、例えば事前に定められた時間や間隔でサービスプロバイダに到達することもできる。

アクセス要求に触発され、サービスプロバイダは、そのサービスに対するユーザ認証の認証セキュリティ要求を特定する、１つ以上の認証セキュリティプロファイルを選択する。

本方法は、アイデンティティプロバイダによるユーザ認証を要求するために、１つ以上の選択された認証セキュリティプロファイルと、ユーザを特定するユーザＩＤの指示を、アイデンティティプロバイダに送信することにより処理が進行する。すなわち、サービスプロバイダは、例えばサービスプロバイダにより遠隔からアクセスできる、対応する装置又は装置のようなものから、指示の１形態として示すための１つ以上の選択された認証セキュリティプロファイルを、認証の実行されるものの１つに基づく１つ以上の認証セキュリティプロファイルの形態で認証セキュリティ要求を示すためにアイデンティティプロバイダに送信する。さらに、ユーザＩＤは認証ステップにおけるユーザの識別のために、アイデンティティプロバイダに送られる。

次に、ユーザＩＤと、１つ以上の選択された認証セキュリティプロファイルのうちの１つに基づいて、ユーザは、アイデンティティプロバイダによって認証される。認証は、例えば事前にアイデンティティプロバイダに登録されたユーザを識別し、１つの認証セキュリティプロファイルに従ったユーザＩＤに基づくユーザを検証することにより、達成されうる。

最後に、アイデンティティプロバイダによる認証の結果についての情報が、サービスプロバイダに送信されうる。特に、ユーザ認証を示すアサーションが、例えばユーザ認証がサービスプロバイダによる認証セキュリティプロファイルに特定される認証セキュリティ要求に従って達成されたということを示すために、サービスプロバイダに送られる。実装や実施形態によって、そのアサーションは、例えば認証のための１つの認証プロファイルを特定するものであってもよいし、単に「認証が成功した」ことを示すものであってもよい。それ以外のアサーションについての実装も可能である。

この方法は、サービスプロバイダのサービスに対するユーザ認証を改良し、特に、サービスプロバイダにとって認証方法を極めて安全にする。なぜなら、最終的にはアイデンティティプロバイダではなくサービスプロバイダが、ユーザ認証をするアイデンティティプロバイダにより充足されるべきセキュリティ要求を、サービスプロバイダによって選択された認証セキュリティプロファイルの１つに従って決定するからである。この方法はアイデンティティプロバイダにとっても、より安全である。なぜなら、それは明らかに、そしてリアルタイムに(on-the-fly)、サービスプロバイダのどの認証要求が現在適用されているかを示され、それは現在のユーザ認証のために充足されなければならないからである。サービスプロバイダの認証セキュリティ要求は変化するかもしれない。この場合、サービスプロバイダは他の認証セキュリティプロファイルを選択することにより変化したセキュリティ要求に直ちに対応するかもしれず、そのため、この方法をサービスプロバイダにとってより安全にするだけでなく、柔軟性に富むものとする。したがって、特に特別な(ad-hoc)筋書きで、サービスプロバイダの認証セキュリティ要求がさらに変化する状況や環境においても、サービスプロバイダは柔軟に振る舞うことができ、アイデンティティプロバイダによる認証を要求するときに、１つ以上の選択された認証プロファイルによる変化した認証要求を、直ちに特定し、アイデンティティプロバイダに伝えることができる。さらに、この方法はサービスプロバイダが特定の単一のアイデンティティプロバイダを使用することを要求しない。代わりに、いかなるアイデンティティプロバイダでも認証のために使用することができる。加えて、アイデンティティプロバイダが中継コンポーネントとしてサービスプロバイダとクライアントの間に介入することも必要としない。

好ましい実施形態によれば、１つ以上の認証セキュリティプロファイルは少なくとも１つのセキュリティ属性を、例えばより正確には、認証セキュリティ要求を特定するために、含む。サービスプロバイダは、セキュリティ属性を特定することにより１つ以上の認証セキュリティプロファイルを積み重ねることができる。自身による特定を行なうことにより、サービスプロバイダは、認証セキュリティプロファイルを正確に自身のセキュリティ要求に合わせることができる。サービスプロバイダは、代わりに又は加えて、事前に定義された方法により用意される１つ以上のセキュリティ属性を含む、事前に定義された認証セキュリティプロファイルを選択することができる。アイデンティティプロバイダ及び／又はユーザの認証能力は、１つ以上のセキュリティ属性に基づく認証セキュリティプロファイルを特定し、かつ／又は選択する際に、考慮される可能性がある。セキュリティ属性の例としては、証明、トランスポート層セキュリティ、ネットワークセキュリティ、リンク層セキュリティ、タイミング情報、ポリシー、詐欺検知基準、信頼性かつ／又は保証、その他のセキュリティ上の特徴、のグループからなる項目を記述する特徴がある。セキュリティ属性は、例えばパスワード又はバイオメトリックスのような証明の種類の特定と、特定の種類に対応する値、例えばパスワードに対応するパスワード長やバイオメトリックスに対応する指紋の解像度の値の特定を含む。セキュリティ属性を使用することにより、アイデンティティプロバイダはセキュリティを特徴付ける基礎となるサービスプロバイダによって、正確に指示されうる。サービスプロバイダの要求に従い、ユーザ認証はアイデンティティプロバイダによって実行されなければならない。

他の好ましい実施形態によれば、サービスプロバイダは、認証のためのアイデンティティプロバイダによってサポートされると示されている１つ以上のセキュリティプロファイルのグループから、１つ以上の認証セキュリティプロファイルを選択する。１つ以上のサポートされる認証セキュリティプロファイルのグループから１つ以上の認証セキュリティプロファイルを選択することは、認証成功の可能性を高める。

他の好ましい実施形態によれば、サービスプロバイダは、例えばサポートされる認証セキュリティプロファイルのリストを送ることにより、アイデンティティプロバイダから、１つ以上のサポートされるセキュリティプロファイルのグループの指示を受け取る。指示はまた、どこのサーバから、例えばサービスプロバイダからのダウンロードによって、グループが得られるかを示すＵＲＩ(Uniform Resource Identifier)であってもよい。他の方法による指示も可能である。望ましくは、アイデンティティプロバイダの認証能力の変化が起きたとき、例えば、アイデンティティプロバイダがサポートされていた証明の種類及び／又は証明の値のようなあるセキュリティ属性を破棄（例えば４文字以下のパスワード長は以後サポートしないなど）したり、アイデンティティプロバイダが新しく導入された証明の種類や値を提供（例えば指紋が以後サポートされるなど）したりしたときに、グループ又は指示の一形態としてのグループそのものの指示は、サービスプロバイダに送られる。

他の好ましい実施形態によれば、認証が実行される基礎となる前記１つの認証セキュリティプロファイルは、アイデンティティプロバイダによって、１つ以上の認証セキュリティプロファイルの中から選択される。そうすることにより、アイデンティティプロバイダは、選択された認証セキュリティプロファイルのどれに基づいて認証が実行されるべきであるかをサービスプロバイダに尋ねずにすむ。代わりに、アイデンティティプロバイダは、すべての選択され表示された認証セキュリティプロファイルはサービスプロバイダの認証セキュリティ要求を満たすと想定でき、例えばアイデンティティプロバイダ及び／又は認証されなければならないユーザの要求又は能力に最も適したものを選ぶことができる。さらに、サービスプロバイダとアイデンティティプロバイダの間の、ユーザ認証が実際に行なわれる基礎となる認証セキュリティプロファイルについて交渉するためのやりとりを、最小限にすることができ、それゆえ、スピード及び認証成功の可能性は増加する。

他の好ましい実施形態によれば、１つ以上の選択された認証セキュリティプロファイルは、１つ以上の関係により１つ以上のさらなる認証セキュリティプロファイルと関係付けられうる。これらの関係はそれぞれ、認証セキュリティ強度に関して、１つ以上の選択された認証セキュリティプロファイルの、１つ以上の他の認証セキュリティプロファイルに対する順位を表現する。関係の例は、二つの認証セキュリティプロファイルの関係で、より強い又は同等に強いということを表現する強度により、関係付けられる。選択された認証セキュリティプロファイルは、お互いにも関係付けられうる。１つ以上の選択された認証セキュリティプロファイルと１つ以上の他の認証セキュリティプロファイルの関係、すなわち、選択されたものと他の認証プロファイルとそれぞれの関係の集合に関する情報に基づいて、１つ以上の選択された認証セキュリティプロファイルの１つに基づくユーザ認証ステップは、アイデンティティプロバイダにより１つ以上の他の認証セキュリティプロファイルの１つを選択されることによって実行されうる。１つ以上の他の認証セキュリティプロファイルの１つは、認証セキュリティ強度に関して１つ以上の選択された認証セキュリティプロファイルと比べて同等かそれ以上に強いものとして関係付けられており、アイデンティティプロバイダによって選択された他の認証セキュリティプロファイルに基づいてユーザを認証する。それゆえ、サービスプロバイダの認証セキュリティ要求を満たす認証セキュリティプロファイルの多様性と数は大きくなる。多様性と数が大きくなった認証セキュリティプロファイルから、アイデンティティプロバイダは認証のための１つの認証プロファイルを、例えば前述のある能力に最も適したものなど、柔軟に選ぶことができる。それゆえ、認証成功の可能性と認証のスピードが増加する。

他の好ましい実施形態によれば、サービスプロバイダは１つ以上の他の認証セキュリティプロファイルに対する１つ以上の関係を特定することができ、サービスプロバイダは１つ以上の他の認証セキュリティプロファイルに対する１つ以上の関係の指示をアイデンティティプロバイダに送ることができる。そうすることにより、１つ以上の選択されたものと１つ以上の他の認証セキュリティプロファイルの間の関係は、サービスプロバイダの認証セキュリティ要求をより正確に反映し、それにより、認証に実際に使われる認証セキュリティプロファイルの交渉のためのやりとりがより少なく、より速い認証に結びつく。

他の好ましい実施形態によれば、アサーションは、認証が実行される基礎となる認証セキュリティプロファイルの指示によって補足され、示された認証セキュリティプロファイルはサービスプロバイダが受理できるかチェックされる。サービスプロバイダに認証が実行される基礎となる認証セキュリティプロファイルに関する情報を提供することは、サービスプロバイダにとってセキュリティをさらに向上させ、サービスプロバイダに例えば認証に実際に使用されている認証セキュリティプロファイルが現在の認証セキュリティ要求を充足するかどうかチェックする可能性を提供する。

サービスプロバイダのサービスに対するユーザ認証の方法を開示する。その方法は、ユーザに対してサービスプロバイダのサービスに対するアクセスを要求し、ユーザを識別するユーザＩＤをアイデンティティプロバイダによるユーザ認証を要求するためにアイデンティティプロバイダに送信し、ユーザＩＤと認証セキュリティプロファイルに基づいてユーザを認証し、ユーザ認証を示すアサーションであって認証セキュリティプロファイルの指示によって補足されるものをサービスプロバイダに送信し、サービスプロバイダが示された認証セキュリティプロファイルを受理できるかチェックするステップを含む。

ここで、サービスプロバイダは認証に先立ってセキュリティ認証要求をアイデンティティプロバイダに提供はせず、これはいくつかの実装にあっては利点となりうる。しかし、サービスプロバイダは依然として、ユーザ認証が実行される基礎となる表示された認証セキュリティプロファイルとサービスプロバイダのセキュリティ要求を比較することにより、サービスに対するユーザ認証がサービスプロバイダの認証セキュリティ要求に適合するかを検証することができる。さらに、アイデンティティプロバイダにとっての柔軟性は、アイデンティティプロバイダにサポートされるあらゆる認証セキュリティプロファイルに基づく認証は、証明の検証が必要であれば望ましくはユーザの認証能力に適合する認証のために用いられうるという事実のために、増加しうる。結局、ユーザが十分に認証されたか否かを決定する権限が与えられているのは、サービスプロバイダである。

どちらの方法もさらに、サービスプロバイダにおいてユーザデバイスから、ユーザＩＤと、サービスプロバイダからユーザデバイスに送られた認証要求に応じてアイデンティティプロバイダについての参照を受信するステップを含みうる。ユーザデバイスとのやりとりは、極めて一般的で、実装を容易にしうる。

受信したアサーションに基づいて、アサーションに基づくサービスへのアクセスが許可されうる。代わりに、サービスに対するアクセスは、アサーションと受理できるかのチェック、例えば表示された認証セキュリティプロファイルがサービスプロバイダの認証セキュリティ要求に適合しているかのチェックに基づいて許可されうる。そのため、特にサービスプロバイダにとっての認証のセキュリティは向上する。

他の好ましい実施形態によれば、その方法は認証を改良するステップを含みうる。認証の改良は、他の認証セキュリティプロファイルに基づくさらなる認証を実行することにより行なわれうる。選択とさらなる認証は、前述のサービスプロバイダのサービスに対するユーザ認証のための方法の選択と認証に関連するいかなるステップに従っても、実行されうる。例えば、サービスプロバイダは１つ以上の認証セキュリティプロファイルを選択し、ユーザ認証のためにこれらの１つを選択するアイデンティティプロバイダにこれらを送信してもよい。アイデンティティプロバイダは関係に基づいて１つの認証セキュリティプロファイルを選択し、認証の実行される基礎となる選択された認証セキュリティプロファイルをサービスプロバイダに示してもよく、サービスプロバイダは例えば示された認証セキュリティプロファイルが認証のための認証セキュリティ要求に適合するかをチェックすることができる。もしより強力な認証セキュリティ要求を伴うサービスにアクセスされても、改良された機能はユーザとサービスプロバイダがセッションを継続することに資することができる。

他の好ましい実施形態によれば、認証の改良は、他の認証セキュリティプロファイルに基づいてさらなるユーザ認証を実行するために他のアイデンティティプロバイダへの変更を含みうる。それゆえ、例えば前のアイデンティティプロバイダがサービスプロバイダのより強力な認証セキュリティ要求に従う他の認証プロファイルをサポートできない場合でもサービスセッションを継続することができる。

本発明はさらに、装置にも実装される。以下に、サービスプロバイダに対応する装置とアイデンティティプロバイダに対応する装置を記述する。

サービスプロバイダに対応する装置を開示する。サービスプロバイダに対応する装置は、メッセージを受信する受信ユニットと、メッセージを送信する送信ユニットと、メッセージと情報を処理する処理ユニットを含む。サービスプロバイダに対応する装置は、サービスプロバイダのサービスに対するユーザのアクセス要求を受信し、サービスに対するユーザ認証のための認証セキュリティ要求を特定する１つ以上の認証セキュリティプロファイルを選択し、１つ以上の選択された認証セキュリティプロファイルの指示とユーザを特定するユーザＩＤをアイデンティティプロバイダによるユーザ認証を要求するためにアイデンティティプロバイダに送信し、アイデンティティプロバイダによるユーザ認証を示すアサーションを受信するように、なされる。

好ましい実施形態によれば、サービスプロバイダに対応する装置は認証セキュリティ要求を特定する少なくとも１つのセキュリティ属性を含む１つ以上の認証セキュリティプロファイルを選択するようになされうる。

他の好ましい実施形態によれば、サービスプロバイダに対応する装置は認証のためのアイデンティティプロバイダにサポートされると示されるセキュリティプロファイルのグループから１つ以上の認証セキュリティプロファイルを選択するようになされうる。

他の好ましい実施形態によれば、サービスプロバイダに対応する装置は、アイデンティティプロバイダから、１つ以上のサポートされるセキュリティプロファイルのグループの指示を受信するようになされうる。

他の好ましい実施形態によれば、サービスプロバイダに対応する装置は、１つ以上の選択された認証セキュリティプロファイルを１つ以上の他の認証セキュリティプロファイルに関係付けるようになされうる。それぞれの関係は、認証セキュリティ強度に関して、１つ以上の他の認証セキュリティプロファイルに対する１つ以上の選択された認証セキュリティプロファイルの順位を表現する。そしてその装置はさらに、認証強度に関して、同等又はより強い関係である１つ以上の他の認証セキュリティプロファイルに対する少なくとも１つ以上の関係を、認証のためのアイデンティティプロバイダに送信するようになされうる。

他の好ましい実施形態によれば、サービスプロバイダに対応する装置は、アイデンティティプロバイダによるユーザ認証が実行される基礎となる認証セキュリティプロファイルの指示を受信するようになされうる。そしてその装置はさらに、示された認証セキュリティプロファイルを受理できるかチェックするようになされうる。

代わりに又は加えて、サービスプロバイダに対応する装置は、サービスプロバイダのサービスに対するユーザのアクセス要求を受信し、アイデンティティプロバイダによるユーザ認証を要求するためにユーザを識別するユーザＩＤをアイデンティティプロバイダに送信し、ユーザ認証を示すアサーションであって認証セキュリティプロファイルの指示により補足されるものをアイデンティティプロバイダから受信し、示された認証セキュリティプロファイルを受理できるかチェックするようになされうる。

他の好ましい実施形態によれば、サービスプロバイダに対応する装置は、ユーザＩＤと、サービスプロバイダに対応する装置からユーザデバイスに送信された認証要求に応じてユーザデバイスからのアイデンティティプロバイダへの参照を受信するように、なされうる。

他の好ましい実施形態によれば、サービスプロバイダに対応する装置はアサーションに基づいてサービスへのアクセスを許可するようになされうる。

他の好ましい実施形態によれば、サービスプロバイダに対応する装置は、アサーションと受理できるかのチェックに基づいてサービスへのアクセスを許可するようになされうる。

他の好ましい実施形態によれば、サービスプロバイダに対応する装置は他の認証セキュリティプロファイルに基づくさらなる認証に基づいて認証の改良を実行するようになされうる。

他の好ましい実施形態によれば、サービスプロバイダに対応する装置はさらなる認証を実行するために他のアイデンティティプロバイダに対する認証の改良のために変化するようになされうる。

アイデンティティプロバイダに対応する装置を開示する。アイデンティティプロバイダに対応する装置は、メッセージを受信する受信ユニットと、メッセージを送信する送信ユニットと、メッセージと情報を処理する処理ユニットを含む。アイデンティティプロバイダに対応する装置は、ユーザ認証の要求を受信するようになされうる。その要求は、アイデンティティプロバイダ、例えばアイデンティティプロバイダに対応する装置、に対してユーザを識別するユーザＩＤと、サービスプロバイダのサービスに対するユーザ認証のためのサービスプロバイダの認証セキュリティ要求を特定する１つ以上の認証セキュリティプロファイルの指示を含む。アイデンティティプロバイダに対応する装置はさらに、ユーザＩＤと１つ以上の認証セキュリティプロファイルの１つに基づいてユーザを認証し、サービスプロバイダに対しユーザ認証を示すアサーションを送信するようになされうる。

好ましい実施形態によれば、アイデンティティプロバイダに対応する装置は認証の実行される基礎となる１つの認証セキュリティプロファイルに含まれる少なくとも１つのセキュリティ属性に基づいてユーザを認証するようになされうる。

他の好ましい実施形態によれば、アイデンティティプロバイダに対応する装置はアイデンティティプロバイダによって認証のためにサポートされる１つ以上のセキュリティプロファイルのグループの指示をサービスプロバイダに送信するようになされうる。

他の好ましい実施形態によれば、アイデンティティプロバイダに対応する装置は１つ以上の認証セキュリティプロファイルから、認証が実行される基礎となる前記一つの認証セキュリティプロファイルを選択するようになされうる。

１つ以上の認証セキュリティプロファイルは、１つ以上の関係によって、１つ以上の他の認証セキュリティプロファイルに関係付けられうる。１つ以上の関係はそれぞれ、認証強度に関して、１つ以上の認証セキュリティプロファイルの、１つ以上の他の認証セキュリティプロファイルに対する順位を表現する。アイデンティティプロバイダに対応する装置は認証セキュリティ強度に関して、１つ以上の認証セキュリティプロファイルと比較して、同等又はより強く関係付けられている１つ以上の他の認証プロファイルの１つを選択し、選択された他の認証セキュリティプロファイルに基づいてユーザを認証することによって、ユーザ認証を実行するようになされうる。

他の好ましい実施形態によれば、アイデンティティプロバイダに対応する装置はサービスプロバイダから、１つ以上の他の認証セキュリティプロファイルに対する１つ以上の関係の指示を受信するようになされうる。

他の好ましい実施形態によれば、アイデンティティプロバイダに対応する装置は認証が実行される基礎となる認証セキュリティプロファイルの指示を伴うアサーションを補足するようになされうる。

代わりに又は加えて、アイデンティティプロバイダに対応する装置はユーザ認証の要求を受信するようになされうる。その要求は、アイデンティティプロバイダ、例えばアイデンティティプロバイダの装置、に対してユーザを識別するユーザＩＤを含む。アイデンティティプロバイダに対応する装置はユーザＩＤと認証セキュリティプロファイルに基づいてユーザを認証し、サービスプロバイダにユーザ認証を示すアサーションを送信するようになされうる。そのアサーションは、認証が実行される基礎となる認証セキュリティプロファイルの指示によって補足される。

他の好ましい実施形態によれば、アイデンティティプロバイダに対応する装置は他の認証セキュリティプロファイルに基づくさらなる認証に基づいて認証の改良を実行するようになされうる。

本発明はさらに、１つ以上のコンピュータプログラムによっても実装されうる。１つ以上のコンピュータプログラムは、認証方法のあらゆるステップを実行するための装置に取り込み可能な(loadable)ソフトウェアコードの部分を含む。１つ以上のコンピュータプログラムは、コンピュータが読み取り可能な媒体に記録されうる。コンピュータが読み取り可能な媒体は、装置中又は外部に存在する永久又は書き換え可能なメモリにすることができる。コンピュータプログラムはまた、例えばケーブルやワイヤレス接続を介して信号のシーケンスとして装置に転送されうる。

特に、サービスプロバイダに対応する装置に取り込み可能なコンピュータプログラムを開示する。そのコンピュータプログラムは、サービスプロバイダのサービスに対するユーザのアクセス要求を処理し、サービスに対するユーザ認証のための認証セキュリティ要求を特定するための１つ以上の認証セキュリティプロファイルを選択し、１つ以上の選択された認証セキュリティプロファイルの指示とユーザを識別するユーザＩＤをアイデンティティプロバイダによるユーザ認証を要求するためにアイデンティティプロバイダに対して送信することを開始し、アイデンティティプロバイダによるユーザ認証を示すアサーションを処理するようになされたコードを含む。

代わりに、そのコンピュータプログラムは、１つ以上の認証セキュリティプロファイルの選択と、アイデンティティプロバイダに対する１つ以上の認証セキュリティプロファイルの指示の送信に関係するソフトウェア部分が、含まれても飛ばされてもいない形態であるかもしれず、代わりに又は加えて、そのコンピュータプログラムはユーザ認証が実行される基礎となる示された認証セキュリティプロファイルを受理できるかチェックするようになされたコードを含み、示された認証プロファイルはアサーションと併せてコンピュータプログラムに入力される。

さらに、アイデンティティプロバイダに対応する装置が取り込み可能なコンピュータプログラムを開示する。そのコンピュータプログラムは、ユーザ認証の要求を処理し、ユーザＩＤとサービスプロバイダから受信した１つ以上の認証セキュリティプロファイルの１つに基づくユーザ認証を実行し、サービスプロバイダに対してユーザ認証を示す表示の送信を開始するようになされたコードを含み、その要求は、アイデンティティプロバイダに対してユーザを識別するユーザＩＤと、サービスプロバイダのサービスに対するユーザ認証のためのサービスプロバイダの認証セキュリティ要求を特定する１つ以上の認証セキュリティプロファイルの指示を含む。

コンピュータプログラムによる本発明の方法のさらに別の方法による実装が可能である。特に、コンピュータプログラムは前述のように方法のあらゆる実施形態を実装することができる。

以下に、本発明の詳細な実施形態を、添付図面を参照して記載する。

認証方法は、以下の３つの要素から構成されうる。第１は、１つ以上の認証セキュリティプロファイル(Authentication Security Profiles, ASProfs)と、構造化され、拡張性があり、機械が読み取り可能な組(set)としてのASProfs間の可能な関係を記述するデータ構造である。データ構造の記述には、異なるASProfs間の関係、例えば「〜と同等かそれより強い(≧)」、を表現するために、有向グラフ(directed graph)が用いられる。このグラフでは、それぞれのノードはASProfであり、それぞれの有向端(directed edge)は２つのASProfsの間の関係を表現する。第２は、サービスプロバイダのサービスに対するユーザ認証に用いられるASProfについて合意する方法である。サービスプロバイダは「欲しいものリスト(wish list)」という意味の１つ以上の必要なASProfsをアイデンティティプロバイダに送信することができ、アイデンティティプロバイダが今度は、応じられるかどうか及び１つ以上の使用できるASProfsについて代替案を作成するか決定する。ASProfs全部を往復して送信するのではなく、参照(reference)と更新(update)を使用することにより、交換されるデータを減らすことができる。もし最初のアイデンティティプロバイダがサービスプロバイダの要求に答えられない場合、他のアイデンティティプロバイダがコンタクトを受けるかもしれない。第３は、セッション中のASProfを改良する方法である。セッション中にASProfを改良することは、ASProfを再度交渉することを含み、ユーザ証明の新たな検証をも要するかもしれない。もしアイデンティティプロバイダが改良されたASProfに対応できないと、サービスプロバイダは改良のために代わりのアイデンティティプロバイダにコンタクトするだろう。

ＩＤ”Ｘ”を持つと主張するユーザが本当にこのＩＤに対応するユーザであるかの確実性は、連続する尺度(continuous scale)で見られ、以下の要素を含む（それのみに限定されるわけではない）数多くの要素に依存する。
・認証のために検証される１種類以上のユーザ証明、例えば、パスワードはＰＩＮコードを伴う会社ＩＤに比べて安全でないとみなされるだろう。
・クライアントとサーバの間で認証情報（例えばパスワード）をやりとりする際に用いられるトランスポート、ネットワーク、リンク層のセキュリティ特性、例えば、ＴＬＳやＩＰｓｅｃなど。
・最も最近に認証した時、例えば、１０秒前に入力されたＰＩＮは一般的に３日前に入力されたＰＩＮよりも安全である。なぜなら、攻撃者はその間にクライアントデバイスに対して不正アクセス(unauthorized access)を成しえているかもしれないからである。
・ユーザ証明の長さと複雑さ、例えばパスワードやＰＩＮの長さ、文字のみを含むパスワードと最低２つの数字と最低２つの特殊文字(special characters)を含むパスワード、秘密鍵の長さ、など。
・秘密のユーザ証明の扱いに関する方針、例えば、どれくらい頻繁にパスワードが変更されるか、何回変更した後に古いパスワードが再利用されてもよいか、いかにしてアイデンティティプロバイダは秘密のユーザ証明データの機密性と完全性を守るか、など。
・公開鍵基盤（ＰＫＩ）が使われる場合、鍵の扱いに関する方針、例えば、証明の取り消しがどう扱われるか、どのルート認証局を信用するか、など。
・詐欺を検出した場合の証明の取り消し処理及び取り消しに要する時間のみならず、詐欺を検出するのに取られる基準。
・詐欺の場合の、アイデンティティプロバイダのサービスプロバイダに対する責任と保証。
・アイデンティティプロバイダに登録されているユーザの「真の」ＩＤを検証することに関する方針、例えば、Ｗｅｂページで名前や個人情報を入力することはパスポートの確認に比べて安全でないとみなされるだろう。

この文章では、これら及びユーザ認証の確実性のレベルに影響を与える他の属性の集合体を、「認証セキュリティプロファイル」(”ASProf”)と呼ぶ。

ASProfは、属性の組、例えば、前述の属性に、属性値を伴って又は伴わずに、記述される。例えば、空又は標準のASProfは、属性に割り当てられる属性値を伴わない属性を持つだろう。ASProfは、どの認証証明が扱われ、更新され、取り消されるかなどによる処理を記述する方針を含むように、着想(conceive)されうる。ASProfの記述は、望ましくは、変更可能で、拡張可能で、機械が読み取り可能である。望ましくは、ＸＭＬ(eXtensible Markup Language)が内在するメタ言語として用いられる。拡張可能性は重要である。なぜなら、ASProfは一般的にデータの閉集合(closed set)ではなくバイオメトリックスのような認証技術の出現や暗号技術のような新規のセキュリティ技術に適応する必要があるからである。拡張可能性は、将来的な属性がASProfに含まれうることを保証し、所定のASProfの属性を置き換える要求という変更可能性も含む。異なる属性間の関係も存在するだろう。

図１ａは、ＰＩＮ（Ｂ０１）、ＩＣカードＢ０２、バイオメトリックスＢ０３、トランスポートセキュリティＢ０４、そして方針Ｂ０５のような異なる属性を伴う、ASProf（Ａ０１）の例を示す図である。ASProfは、例えば認証のための将来技術Ｂ０６を含むような、さらなる属性により拡張されうる。

属性値はASProfの属性に割り当てられうる。例えば、属性の組は数字かもしれない、すなわち、「鍵の長さ」＝「１２８」、「最低パスワード長」＝「１０」、など。あるいは、記述的なものかもしれない、すなわち、「トランスポートセキュリティ」＝「ＴＬＳトンネリング」又は「トランスポートセキュリティ」＝「ＷＴＬＳ」など（ＴＬＳはTransport Layer Security、ＷＴＬＳはWireless ＴＬＳのことである）。図１ａを参照すると、属性値は次のように割り当てられうる。

属性 属性値

ＰＩＮ １０文字
ＩＣカード 無し
バイオメトリックス（例えば指紋） 高解像度（２００キロバイト）
トランスポートセキュリティ ＷＴＬＳ
ポリシー 無し

ＸＭＬによりコーディングされた属性を伴うASProfの他の例を、後述の文章による注記を伴って下の表Ａに示す。
いくつかの属性間の関係は下の例に存在する。

表Ａについての注記：
ＡＡ１：ユーザ認証には、最低５文字、最高１０文字のパスワードが用いられる。再度認証が必要になるまでの最大セッション時間は、８時間である。パスワードは大文字小文字を区別し、特殊文字を含む必要はないが、少なくとも１つの数字を含む必要がある。

ＡＡ２：ＴＬＳは、トランスポート層を安全にするために使用され、許されるメッセージ認証アルゴリズムはＭＤ５(Message Digest Algorithm No.5)とＳＨＡ(Security Hash Algorithm)であり、許される暗号化アルゴリズムはＤＥＳ(Data Encryption Standard)と３ＤＥＳ(triple-DES)である。ＴＬＳの代わりにＳＳＬもトランスポート層のセキュリティプロトコルとして許される。

ＡＡ３：パスワードは少なくとも６ヶ月ごとに変更されなければならず、旧パスワードは少なくとも１０の他のパスワードが使用されるまでは再度使用することができない。ユーザデータの取り扱いに関するプライバシーポリシーの詳細は記載のＵＲＬで見ることができる。

ＡＡ４：Verisign、ＲＳＡ、Thawteがルート認証局として信用される。

ＡＡ５：アイデンティティプロバイダは詐欺やＩＤ窃取に対して責任を負わない($0.00)。

ＡＡ６：登録において、ユーザのＥメールアドレスに送られる確認メールを用いて、ユーザＩＤは確認される。アカウントが６ヶ月間使用されないと、登録は消滅する。定期的な登録の更新は要求されない。

ＡＡ７：詐欺や証明の漏洩が検知された場合、アカウントは３０分以内にブロックされる（無効にされる）ことが保証される。

複数のASProfsは望ましくは、認証セキュリティ強度に関して関係付けられる。ASProfsの順位や順序を表す関係は、有向グラフの手段により記述される。このグラフでは、各々のノードはASProfである。グラフは「ルートノード」を持ち、それは、空のASProf、すなわち一切セキュリティがないもの、であっても構わない。各々の有向端は、２つのASProfs間の関係、例えば”≧”の関係、を特定する。ASProfsの組の記述とASProfs間の関係は望ましくは、変更可能で、拡張可能で、機械で読み取り可能である。望ましくは、ＸＭＬは内在するメタ言語として用いられる。

特殊な場合、例えばグラフが（ｎ個の属性の場合に）ｎ次元グリッドになる場合を想定することができる。この場合、各々の属性には独立した関係があり、２つのASProfsの比較は各々の属性を分離した比較に相当する。”≧”関係を持つ２つのASProfs間の比較の例は、次のものである。

もし、
鍵の長さ１≧鍵の長さ２ かつ パスワード長１≧パスワード長２
ならば、
ASProf1≧ASProf2


しかし、より一般的なグラフの表記法は、ずっと複雑な仕様、例えば、鍵の長さが６４である指紋認識は鍵の長さが２５６のパスワードよりも安全である、ということを許可する。「りんごをみかんと比較する」というような事例は、完全に異なる認証機構が単一のシステムで用いられる場合に重要になる。グラフの概念は、個々の属性が独立して扱われる他の概念よりも一般的であり、異なる認証方法と技術の間の優先度を表現することを許可する。

このグラフは、原則として各々のサービスプロバイダによって生成されうるもので、異なるサービスプロバイダは異なるグラフを使うかもしれない。サービスプロバイダは、例えば、異なるユーザやアイデンティティプロバイダやサービスに応じて複数のグラフを持つかも知れない。このことは、各々のサービスプロバイダは望ましくは認証セキュリティ特徴に関して自分自身の希望と優先付けを定義できるという要求を反映している。最初のサービスプロバイダは、アイリススキャン（虹彩走査）はキーワードよりも安全であると考えるかもしれない。次のサービスプロバイダは、キーワードのほうが安全であると考えるかもしれない。このことはもちろん、もしサービスプロバイダがそうしたいと望むなら、「規定値(default)」のグラフを再利用することを排除はしない。

図１ｂには、ASProfのグラフの例が描かれている。このグラフは、点で表現され、２つのASProfs間の”≧”関係を表す矢印でつながれているASProfs Ａ１、Ａ２、Ａ３、Ａ４、Ａ５、Ａ６、Ａ７、Ａ８、Ａ９を含む。図１ｂのグラフの描写に用いられている矢印表記は、２つのASProfsをつなぐ矢印は、２つのASProfsのうち矢印の頭のある１つが、２つのASProfsのもう一方と比べて”≧”であることを示す。すなわち、ASProf1→ASProf2は、ASProf2≧ASProf1を意味する。ASProfs間の”≧”関係を表現する矢印１２、１３、１６、２４、３５、４７、５８、６８、７９、８９が、グラフ中に見られるだろう。

ＩＣカード、ＰＩＮ、バイオメトリックスの属性と属性値は、ASProfsに関係するものとして描写されている。特に、ASProf Ａ４は、５６ビットのＩＣカード属性Ｂ４を含み、ASProf Ａ７は、１２８ビットのＩＣカード属性Ｂ７を含み、ASProf Ａ６は、４桁のＰＩＮ属性Ｂ６を含み、ASProf Ａ８は１０桁のＰＩＮ属性Ｂ８を含み、ASProf Ａ９は虹彩認識属性Ｂ９を含む。さらなる属性や属性の組み合わせが、図１中のASProfsに関係付けられることもできる。加えて、「一切のセキュリティ無し」を意味するルートノードASProf Ａ１が定義され、ASProfsに関係付けられるかもしれない。例えば、図１ｂの関係１２、１３、１６を介してASProfs Ａ２、Ａ３、Ａ６に対して。さらなるASProfsや関係がグラフに含まれてもよいし、既存のASProfsや関係が置き換えられたり削除されてもよい。

１０桁のＰＩＮを知っていることは、４桁のＰＩＮを知っていることよりも”≧”であると定義されている。この”≧”の関係は、４桁のＰＩＮ属性Ｂ６を含むASProf Ａ６から始まり１０桁のＰＩＮ属性Ｂ８を含むASProf Ａ８を指し示す矢印６８により描写されている。１２８ビットの秘密鍵を持つＩＣカードを所有していることは５６ビットの秘密鍵を持つＩＣカードを所有していることよりも”≧”であると定義されている。
同様に、ASProf Ａ７とASProf Ａ４の間の”≧”関係は、５６ビットＩＣカードから１２８ビットＩＣカードを指し示す矢印４７により表現されている。さらに、虹彩認識方法は１０桁のパスワードよりも”≧”であり、ＩＣカード上の１２８ビットの秘密鍵よりも”≧”であると定義されており、それぞれ矢印８９、７９がそれぞれの”≧”関係を表現している。しかし、１０桁のパスワードがＩＣカード上の１２８ビットの秘密鍵よりも”≧”であるかどうかを決めようとすることは、大して意味をなさない。２つのASProfs間の”≧”関係が可能でなかったり望まれていない場合は、対応する矢印はグラフから消える。

図１ｂに描写されるグラフのＸＭＬ表現の例を、以下に示す。有向グラフを表現するのに一般的に使用される２つのデータ構造がある。（ａ）隣接リスト(adjacency list)を使うこと、それは各々の組が有向端（矢印や関係と呼ばれることもある）を表現しており、組の最初の要素がそれぞれの有向端の起点のASProfを特定し２番目の要素が終点のASProfを特定する、組のリストである。（ｂ）発生率行列(incidence matrix)を使うこと、それは各々の起点ノードに対しグラフ中に存在する端の終点ノードのリストを含む。下の表Ｂの例では、発生率行列が使われている。他の表現も可能である。

表Ｂについての注記：
ＢＢ１：Ａ１はグラフのルートノードであり、空のASProfを意味する。すなわち、セキュリティ特徴がまったくない。

ＢＢ２：グラフ中にルートノードＡ１からノードＡ２、Ａ３、Ａ６への有向端がある。ノードの”successor”は、起点ノード「より強いかまたは同等に強い」と定義される。

ＢＢ３：図１ｂによれば、属性値「５６ビット」を伴う属性Ｂ４「ＩＣカード」はASProf Ａ４に関係付けられている。

ＢＢ４：図１ｂによれば、属性値「４桁」を伴う属性Ｂ６「ＰＩＮ」はASProf Ａ６に関係付けられている。

ＢＢ５：図１ｂによれば、属性値「１２８ビット」を伴う属性Ｂ７「ＩＣカード」はASProf Ａ７に関係付けられている。

ＢＢ６：図１ｂによれば、属性値「１０桁」を伴う属性Ｂ８「ＰＩＮ」はASProf Ａ８に関係付けられている。

ＢＢ７：図１ｂによれば、属性値「虹彩認識」を伴う属性Ｂ９「バイオメトリックス」はASProf Ａ９に関係付けられている。

ASProfの属性はまた、階層構造を持つこともできる。例えば、「鍵の長さ」属性は、次にくる上位の属性が「ＴＬＳトンネリング」か「ＷＴＬＳ」かにより、異なる解釈を持ちうる。それゆえ、「鍵の長さ」属性の数字値は、最初に次にくる上位の属性を比較すること無しには、お互いを直接比較することが必ずしもできない。

数字属性値の場合、属性値と認証セキュリティ強度の間の関係は、例えばより長い鍵の長さは常により強い認証セキュリティ強度を意味するというような、単調な関係である必要はない。図２は、単調でない関係の例を示す図である。この例では、９文字前後のパスワード長が、認証セキュリティ強度という点で最適であると考えられている。短いパスワードは、例えば極めて短い場合は総当たり攻撃(brute-force attack)で、比較的長いパスワードに対しては辞書攻撃(vocabulary attack)で、破られやすいので、それほど安全でないと考えられる。しかし、９文字よりもずっと長いパスワードも、ユーザが記憶するのが極めて困難であるためユーザに書き留められる傾向があるので、それほど安全でないと考えられる。属性値「パスワード長」と対応する認証セキュリティ強度の関係が、図２上部に表されている。下部は、この関係(mapping)がどのように有向グラフという手段で表現されうるかを示す（他の表現も考えられるが）。パスワード長属性を持つ１番目のASProfとパスワード長属性を持つ２番目のASProfの関係は同様に、今はより強い(”＞”)関係を表現する矢印によって表現される。すなわち、１番目のASProfは、２番目のASProfから始まり１番目のASProfに先端を向けて終わる矢印によって、２番目のASProfよりも強い(”＞”)ことが示されている。１番目のASProfから始まる追加の矢印が２番目のASProfに先端を向けて終わっている場合は、１番目のASProfと２番目のASProfは同じ強さ(”=”)であることを示す。例えば、２つのパスワード長の強さは等しいと主張する”=”関係は、１つの矢印が１番目のパスワード長から２番目のパスワード長を指し、もう一つの矢印が２番目のパスワード長から１番目のパスワード長を指すという、２つの矢印によって表現される。この例では、１１−２０文字のパスワードは３−６文字のパスワードと等しい認証セキュリティ強度であると定義されている。

実際、好みと優先度の決定は、完全にサービスプロバイダに任せることができる。例えば、１番目のサービスプロバイダは単調なマッピングに従うと決めるかもしれないし、次のサービスプロバイダは図２に従うマッピングを使うと決めるかもしれないし、３番目のサービスプロバイダはマッピングの詳細を気にすることなくアイデンティティプロバイダによる標準のグラフを受け入れるかもしれない。

図２の例は、単調でない関係がどのように有向グラフの中で表現されるかを説明する。これはさらに、属性値の範囲、例えば「７−９文字」、がグラフ表現の中でどのように一つのノードに落とし込まれるかを説明している。すなわち、各々の許可された数字値がグラフの中で分離したノードを形成しなければならないという要求はない。

以下には、１つ以上のアイデンティティプロバイダによる、サービスプロバイダＳＰのサービスに対するユーザ認証が記述されている。

図３によれば、クライアントはメッセージ１ａを介してサービス要求を送信することにより、ユーザが呼び出しを望むサービスプロバイダＳＰに提供されるサービスに、コンタクトする。サービスはユーザ認証を要求し、サービスプロバイダＳＰはメッセージ１ｂを介してユーザ認証要求をクライアントに送信する。クライアントはメッセージ１ｃを介してユーザＩＤをサービスプロバイダＳＰに送り、サービスプロバイダＳＰはユーザＩＤを検証することができる。もしクライアント認証のためのアイデンティティプロバイダＩｄＰ１がサービスプロバイダＳＰにとって未知なら、クライアントはメッセージ１ｃを介してアイデンティティプロバイダＩｄＰ１への参照、例えばＵＲＩ(Uniform Resource Identifier)をＳＰに送信する。あるいは、アイデンティティプロバイダＩｄＰ１への参照はデフォルトでクライアントからサービスプロバイダＳＰに送られることとしてもよい。

サービスプロバイダＳＰは、メッセージ２を介してサービスの認証セキュリティ要求を特定して希望するASProfとユーザＩＤをアイデンティティプロバイダＩｄＰ１に送信することにより、ユーザ認証を要求する。一般的に、サービスプロバイダＳＰとアイデンティティプロバイダＩｄＰ１は、サービスプロバイダＳＰとアイデンティティプロバイダＩｄＰ１の間の一方的又は相互の認証をすると共に、交換する情報の秘密性、完全性、信頼性を提供する安全なセッションを（例えばＴＬＳを使って）立ち上げる。提案される認証方法に含まれるあらゆる種類のエンティティ間のあらゆる種類の暗号化に必要な処理とメッセージが、図３やそれ以降の図で網羅して描かれているわけではない。

アイデンティティプロバイダＩｄＰ１はプロセス３ａで、ＳＰから受信したASProfの中に示される要求を満たすことができるかをチェックする。もし要求が満たされるなら、アイデンティティプロバイダＩｄＰ１はプロセス３ａでさらに、ユーザ証明の検証が要求されているかをチェックする。もし証明の検証が必要なら、ユーザ証明の要求３ｂがクライアントに送られ、クライアントはメッセージ３ｃを介して要求されたユーザ証明を提供することによりその要求３ｂに応答しうる。帯域内外どちらの通信も、要求３ｂと対応する応答３ｃには可能である。ASProfの要求と任意の証明の検証のチェックについての肯定的な結果に基づいて、アイデンティティプロバイダＩｄＰ１はメッセージ３ｄを介してユーザ認証の表示をＳＰに送信する。その表示に基づいて、サービスプロバイダＳＰはクライアントがアクセスを要求したサービスセッションにアクセスすることを認める。

ユーザ証明の検証の例としては次のものがある。ユーザはＩｄＰを介して午前９時に好みのポータルサイトに対して、ユーザ名／パスワード機構を用いて認証を行なった。午前１１時にユーザは、インターネット書籍販売のサービスを提供するサービスプロバイダの自分のプロファイルにアクセスすることを欲し、前記サービスプロバイダは同じＩｄＰからの認証の表明を受け入れる。もし前記サービスプロバイダが、ASProf中で、パスワード入力は１時間以上前であってはならないと要求すれば、ＩｄＰはユーザに、ユーザが前記サービスプロバイダに対して認証される前にパスワードの再入力を求める必要がある。一方、もし前記サービスプロバイダが２４時間までのパスワード入力を受け入れるなら、パスワードを再入力する必要はない。

図３と、図３の記述によれば、１つのASProfのみがサービスプロバイダＳＰからアイデンティティプロバイダＩｄＰ１に送られている。しかし、提案する方法は容易に、複数の望ましいASProfsがサービスプロバイダＳＰからアイデンティティプロバイダＩｄＰ１に送信される場合に対応しうる。この場合サービスプロバイダＳＰは、サービスプロバイダＳＰがクライアント認証に十分だと考えるASProfsの「欲しいものリスト」を送信する。アイデンティティプロバイダＩｄＰ１は欲しいものリストをチェックする。もし欲しいものリスト中のASProfsのうち１つ以上がアイデンティティプロバイダＩｄＰ１にサポートされていれば、アイデンティティプロバイダＩｄＰ１は、アイデンティティプロバイダＩｄＰ１に最もよくサポートされているASProfsの１つ、例えば証明検証が必要ないものや、欲しいものリスト中の他のサポートされるASProfsと比べてそれほど困難でないものを選択するだろう。

図３と共に記述されている方法は「裏ルート(back channel)」のメッセージの流れを使う。それは、アイデンティティプロバイダＩｄＰ１とＳＰの間の直接のメッセージ交換を含む。代わりに、本方法は「表ルート(front channel)」通信を使用しても実装されうる。すなわち、アイデンティティプロバイダＩｄＰ１とサービスプロバイダＳＰの間のあらゆる通信は、望ましくは適切なセキュリティ警戒を使用してクライアントにより中継され、クライアントは前後に流れる情報に干渉することはできない。異なるメッセージに対する裏ルートと表ルートの組み合わせも同様に可能である。

表ルート通信の例が、図３に対応する認証として図４に描かれている。表ルート通信では、望ましいASProfと、任意でユーザＩＤが、メッセージ４２ａを介してサービスプロバイダＳＰからクライアントへ送信される。クライアントはメッセージ４２ｂを介して望まれたASProfとユーザＩＤをアイデンティティプロバイダＩｄＰ１に送信する。ユーザＩＤがサービスプロバイダＳＰによって提供されなければ、クライアントはユーザＩＤを取得し、メッセージ４２ｂを介してそれをアイデンティティプロバイダＩｄＰ１に送信する。図３のように、アイデンティティプロバイダＩｄＰ１はプロセス３ａで、受信したASProfと、証明の検証が必要であるかを、チェックすることができる。もしそうならば、アイデンティティプロバイダＩｄＰ１はメッセージ３ｂと３ｃを用いてユーザ証明を検証しうる。図３のように、メッセージ３ｂと３ｃは任意のものであり、帯域内又は帯域外の通信が利用されうる。アイデンティティプロバイダＩｄＰ１によって与えられたセキュリティアサーションはメッセージ４３ｄと４３ｅを介して、クライアントを経てサービスプロバイダＳＰに送信される。この場合、セキュリティアサーションは認証の証書(token)又は切符(ticket)とみなされうる。

モバイルクライアントの場合、裏ルート実装は、サービスプロバイダＳＰとアイデンティティプロバイダＩｄＰ１の間で、クライアントの電波インタフェースでの通信を避けるという利点がある。表ルート通信では、サービスプロバイダＳＰとアイデンティティプロバイダＩｄＰ１の間で情報を通過させるという目的のためだけに、電波インタフェース上で余分な帯域が使用され、余分な待ち時間が発生する。

表ルートアプローチはインターネットのような固定されたネットワークでは一般的であり、実装の手間を減らすために裏ルートアプローチよりも好まれるだろう。それはまた、セッションのリダイレクトが発生するという利点がある。すなわち、図４の１ｃでのサービスプロバイダＳＰに対する要求はメッセージ４２ａでサービスプロバイダＳＰからの応答により答えられ、裏ルートの場合のように、アイデンティティプロバイダＩｄＰ１の応答によるわけではない。このことは認証に要求される全体の時間を裏ルート通信よりも短くするだろう。

例えばプロキシサーバを用いるような混合実装も、サービスプロバイダＳＰとアイデンティティプロバイダＩｄＰ１間の通信の表ルートを真似て(emulate)、クライアントを介したトラフィックを避けるために、可能であろう。混合実装はそれゆえ、モバイルクライアントにはとても便利である。

図３に伴って描かれているようにアイデンティティプロバイダＩｄＰ１は、サービスプロバイダＳＰからアイデンティティプロバイダＩｄＰ１に送信された望まれる１つ以上のASProfsをサポートしない場合は、アイデンティティプロバイダＩｄＰ１はサービスプロバイダＳＰに１つ以上の望まれるASProfsの代替案を提供する。図５によれば、サービスプロバイダＳＰはメッセージ２を介してアイデンティティプロバイダＩｄＰ１に、望ましいASProfとユーザＩＤを含む認証要求を送る。アイデンティティプロバイダＩｄＰ１は受信した望まれるASProfをチェックし、その望まれるASProfはサポートされていないことに気づく。１つ以上の代替ASProfsが決定され、メッセージ４を介して代替案ASProfsとしてアイデンティティプロバイダＩｄＰ１からＳＰに送信される。サービスプロバイダＳＰはプロセス５ａで少なくとも１つの代替案ASProfsを受け入れ可能であるかチェックする。もし受信した代替案ASProfsの一つも受け入れることができなければ、サービスプロバイダＳＰは他の１つ以上の望ましいASProfsをアイデンティティプロバイダＩｄＰ１に送信するか、他のアイデンティティプロバイダＩｄＰ１に認証を求めてコンタクトを取るか、認証を終了させるかもしれない。もし少なくとも１つ以上の代替案ASProfsを受け入れることが可能ならば、サービスプロバイダＳＰはメッセージ５ｂを介してアイデンティティプロバイダＩｄＰ１に対し、少なくとも１つの代替案ASProfsに対する同意を送信する。もし複数の代替案ASProfsを受け入れ可能であれば、サービスプロバイダＳＰは選択したASProfに対する同意を送信する前に複数のASProfsの１つを選択するかもしれない。例えば、サービスプロバイダＳＰは受信した１つ以上の代替案ASProfsをチェックし、最初にASProfが受け入れ可能と判明した後はチェックを停止するかもしれない。このASProfはサービスプロバイダＳＰによって同意され、ASProfに対する同意の指示がアイデンティティプロバイダＩｄＰ１に送信される。同意されたASProfに従い、アイデンティティプロバイダＩｄＰ１は、図３に伴って描写されるように、３ａ乃至３ｄのプロセスとメッセージを処理する。

図３乃至５に伴って上に述べられているように、サービスプロバイダＳＰは１つ以上のASProfsが、望まれる１つ以上のASProfsがアイデンティティプロバイダＩｄＰ１に送信されるという意味で、アイデンティティプロバイダＩｄＰ１に使用されるように望む。しかし、サービスプロバイダＳＰは必ずしも認証要求の中でアイデンティティプロバイダＩｄＰ１に１つ以上のASProfsを送信しなければならないわけではない。代わりに、サービスプロバイダＳＰはアイデンティティプロバイダＩｄＰ１からサポートされるASProfsのリストを要求することができる。このことが図６に示されている。サービスプロバイダＳＰはメッセージ６２ａを介してユーザＩＤをアイデンティティプロバイダＩｄＰ１に送信し、認証を要求する。アイデンティティプロバイダＩｄＰ１はメッセージ６２ｂを介してアイデンティティプロバイダＩｄＰ１にサポートされるASProfsのリストをもって応答する。そのリストはプロセス６２ｃでサービスプロバイダＳＰにチェックされ、受け入れ可能なASProfがリストの中から選択される。選択されたASProf（指示の一例としての）又は選択されたASProfの指示はメッセージ６２ｄを介してアイデンティティプロバイダＩｄＰ１に送信される。選択されたASProf（指示の一例としての）又は指示の送信は、選択されたASProfとメッセージ６２ａを介して送信される認証要求を相互に関係付けるために、ユーザＩＤによって補足される。アイデンティティプロバイダＩｄＰ１はプロセス６３ａで証明の検証が選択されたASProfに必要かをチェックし、図３と共に描かれるように３ｂ−３ｄに従ってプロセスとメッセージを処理する。

ASProfsの送信は個々のASProfsを、セキュリティ強度のレベルを明らかにする関係を伴って又は伴わずに、送信することにより達成されうる。個々のASProfs又はASProfs及びASProfs間の関係の情報が送信されうる。例えば、図１及び図２と共に描写されるように、グラフ表記に関連して、グラフ全体又はASProfsと矢印のようなグラフの部分が送信されうる。例えばサービスプロバイダＳＰのような、ASProfsの送り手は、どのASProfsが例えばアイデンティティプロバイダＩｄＰ１のような受け手に使用されることを望むかを特定することができる。特に、受け手が望まれるASProfをいずれもサポートしていない場合は、受け手は望まれるASProfsから始まるグラフを通して、もしASProfs間の関係の情報が受け手で利用可能ならば、望まれるASProfと同等又はそれより強いと認識されるASProfをサポートできるかどうか探してまわる。受け手が知っているグラフ又はグラフの部分を通して探しているときに、受け手は送り手に望まれるようなASProfの強度に関する要求を満たす、同等又はそれより強い、少なくとも１つのASProfを選択しうる。

探索(navigation)に対応する例が図７に描かれている。そこでは、サービスプロバイダＳＰはメッセージ７２を介してASProfグラフの一部または全部、望まれるASProfの指示、そしてユーザＩＤを、認証のためのアイデンティティプロバイダＩｄＰ１に送信する。グラフ全体を送信する代わりに、サービスプロバイダＳＰは、例えば転送の手間を減らしたりアイデンティティプロバイダＩｄＰ１にこの認証では使えない情報を提供したりしないために、望まれるASProfと同等又はそれより強いASProfsを含む、グラフの部分のみを送信することもできる。アイデンティティプロバイダＩｄＰ１はプロセス７３ａで、望まれるASProfがサポートされているかをチェックする。もしそれがサポートされていなければ、アイデンティティプロバイダＩｄＰ１はプロセス７３ａで、より強いASProf（図７に描かれているような）又は同等の強度のASProfがサポートされているかどうかを、ＳＰから受信したグラフを探索することによりチェックする。もしサポートされていない望まれるASProfと異なるがそれより強い又は同等の強さのASProfが少なくとも１つ、アイデンティティプロバイダＩｄＰ１にサポートされていれば、アイデンティティプロバイダＩｄＰ１はプロセス７３ａでユーザ証明の検証のためのチェックを行ない、図３と共に（プロセスとメッセージ３ａ−３ｃ）描写されるように、必要ならばそれらをユーザから要求する。もし同等又はそれより強いASProfが使用され、任意で、ユーザ証明が検証されるならば、アイデンティティプロバイダＩｄＰ１はメッセージ７３ｄを介して、望ましくは使用されている同等又はそれより強いASProfの指示によって補足されるユーザ認証のアサーションを、アイデンティティプロバイダＩｄＰ１に送信する。クライアントのサービスに対するアクセスを認める前に、サービスプロバイダＳＰはプロセス７３ｅで、使用されるASProfがサービスプロバイダＳＰにとって受け入れ可能か、例えばサービスプロバイダＳＰの認証セキュリティ要求に従っているか、をチェックすることができる。

前述のようなグラフ又はグラフの部分の転送は、もしサービスプロバイダＳＰとアイデンティティプロバイダが、何がASProfを他のASProfsと比べてより強く又は同等に強くするかについて似た考えを（少なくともある程度）共有している、すなわち、ASProfsと認証セキュリティ強度に関するASProfs間の関係についての情報を共有しているならば、メッセージの往復回数という点で提案される方法をはるかに効率的にする。加えて、グラフの転送は、サービスプロバイダＳＰとアイデンティティプロバイダの間のメッセージの往復回数を最小化するという利点があり、それゆえ、ＳＰのセキュリティの好みと優先順位が守られることを保証しつつ、認証サービスをはるかに迅速にする。

例えば、もしサービスプロバイダＳＰが１２８ビットの鍵の長さを要求し、アイデンティティプロバイダが６４ビット又は２５６ビットのどちらかのみを提供可能であれば、サービスプロバイダＳＰとアイデンティティプロバイダが、２５６ビットの鍵は１２８ビットの鍵よりも強いものとしてサービスプロバイダに受け入れられるという考えを共有することは、有益である。もしこの考えが共有されていなければ、サービスプロバイダＳＰとアイデンティティプロバイダが適用されるASProfについて同意できるまでさらにメッセージが交換される必要がある。２５６ビットの鍵は１２８ビットの鍵よりも強いという関係についての知識が無ければ、アイデンティティプロバイダは例えば１２８ビットの鍵はサポートされていないという表示をサービスプロバイダＳＰに送信する。この場合、サービスプロバイダＳＰはサポートされる２５６ビットの代替ASProfで応答することができる。

あるASProfが他と同等又はより強いかについての共有される考えは、黙示的であっても明示的であってもよい。黙示的な同意の一例は、前述の２５６ビットは一般的に１２８ビットよりも強いと理解されるという、１２８ビット対２５６ビットの場合である。１２８ビットを提供できないアイデンティティプロバイダは、サービスプロバイダＳＰが１２８ビットを要求したときは２５６ビットは受け入れ可能であると想定して、代わりに２５６ビットを使い、ASProfの中でサービスプロバイダＳＰにこの事実を通信する。しかし、もしサービスプロバイダＳＰがASProfの強度についてアイデンティティプロバイダと異なる定義を使用している場合、アイデンティティプロバイダの誤った想定は追加の交渉と追加のメッセージ又は認証の終了を引き起こす。サービスプロバイダＳＰとアイデンティティプロバイダの間で明示的に共有される考えは黙示的に共有される考えと比べて好ましいという例が、図２に示されており、そこではサービスプロバイダＳＰは、数字属性と考えられている認証セキュリティ強度の間で、単調でなく、一般に同意されていない関係を定義している。

図８は、サービスプロバイダＳＰがメッセージ２を介して、望ましいASProfとユーザＩＤを含むがＳＰのグラフについてそれ以上の情報を送信しない認証要求を送信する、認証を示す図である。アイデンティティプロバイダＩｄＰ１は望まれるASProfをサポートしておらず、アイデンティティプロバイダＩｄＰ１はプロセス８３ａに示すように代替ASProfを選択する。アイデンティティプロバイダは、証明の認証がプロセス８３ａで必要かどうかをチェックする。図３と共になされた説明に従ってメッセージ３ｂと３ｃを使用してユーザ証明の任意の検証をした後、ユーザ認証のアサーションと使用される代替ASProfの指示がメッセージ８３ｄを介してＳＰに送信される。サービスプロバイダＳＰはプロセス８３ｅで代替ASProfを受け入れ可能かチェックする。もしそのASProfが受け入れ可能であれば、サービスセッションが始まる。代替ASProfを選択するために、ASProfは、例えば自身のグラフを使用したり明示的な表示(notation)を想定することにより、自身の考えを使用するかもしれない。しかし、サービスプロバイダＳＰが代替ASProfを受け入れられないと思うことを避けるために、アイデンティティプロバイダＩｄＰ１は望ましくは、サービスプロバイダＳＰとアイデンティティプロバイダＩｄＰ１とに共有される考えを用いる。サービスプロバイダＳＰに従う順位付けを反映するグラフは、サービスプロバイダＳＰをアイデンティティプロバイダＩｄＰ１に提供される認証サービスに登録するときに、提供されるだろう。しかし、アイデンティティプロバイダＩｄＰ１において、望まれるASProfとユーザＩＤ以上の情報が入手できない特別な筋書きにおいては、アイデンティティプロバイダＩｄＰ１は望ましくは自身の考え、例えば自身のグラフを使用するか、１つ以上のサポートされるASProfsを、例えばグラフの形態で、アイデンティティプロバイダから要求する。

ASProfを関係と関連付けることにより、ASProfsのグループが生成されうる。例えば、ある数のASProfsは”=”関係により前記数のASProfのそれぞれの組に関係付けることにより、関係付けられるかもしれず、その結果、同等の認証セキュリティ強度を持つASProfsのグループを形成する。例えば、図２に示されるように３−６と１１−２０文字のASProfsは同等の認証セキュリティ強度のクループを形成するように。サービスプロバイダは、そのグループに属す１つ以上のASProfsを選択することによりユーザ認証にあるグループに属すあらゆるASProfsを使用し、選択したASProfの指示をユーザ認証のためにアイデンティティプロバイダに送信するように、アイデンティティプロバイダに指示することができる。もしアイデンティティプロバイダが示されたグループを、例えばグループの特徴に関する情報すなわちASProfsとその関係がサービスプロバイダＳＰからＩｄＰに、又はその逆に、提供されるという事実のために、知っているならば、アイデンティティプロバイダは認証のために指示に基づくグループから１つのASProfを選択することができる。グループ識別子(identifier)は、もしサービスプロバイダとアイデンティティプロバイダがグループの同じ指示を共有しているならば、アイデンティティプロバイダに対するグループの表示のために使用されるだろう。個々のグループは階層的に順位付けられており、例えば１番目のグループはASProfsの１番目の数字はASProfsの２番目のグループに関係付けられるものを含み、アイデンティティプロバイダは認証のためにグループからグループへと探索する。認証が実行される基礎となるASProfがサービスプロバイダの認証セキュリティ要求に適合するかをチェックするために、前記認証セキュリティプロファイルの関係付けられているグループの指示は十分である可能性がある。グループを形成することは、比較可能な証明の種類又は比較可能な作成や有効性の期間のような、比較可能な特徴を伴う認証セキュリティプロファイルのより良い拡張性と管理性という利点がある。

代替認証方法として、サービスプロバイダＳＰは一切ASProfを特定せずに認証を求めることができる。対応する筋書きが図９に描かれている。サービスプロバイダＳＰはメッセージ６２ａを介して、アイデンティティプロバイダＩｄＰ１に、ユーザＩＤを含む認証要求を送信する。アイデンティティプロバイダＩｄＰ１は、プロセス９３ａに示されるように、自身の選択したASProfを使用し、任意で、例えば図３と共に説明されるようにメッセージ３ｂ、３ｃを活用することにより、選択したASProfに従って証明の検証を実行する。それから、アイデンティティプロバイダＩｄＰ１はメッセージ９３ｄを介して、サービスプロバイダＳＰに、使用されるASProfの指示又は、指示の代わりの形態として、使用されるASProfそのものを、認証のアサーションと併せて送信する。サービスプロバイダＳＰはそれから認証を受け入れるかどうか決める。すなわち、プロセス９３ｅで、使用されるASProfが受け入れ可能かチェックする。

サービスセッションの間にアイデンティティプロバイダによってサービスプロバイダＳＰのユーザ認証を改良する方法が次の２つの図、図１０と図１１に描かれている。図１０によれば、クライアントはサービスセッションに参加する。サービスプロバイダのサービスに対する最初のユーザ認証によるサービスセッションの確立は、図３乃至図９の描写に従って達成されるだろう。サービスセッションの間、クライアントは、確立したセッションよりも高いセキュリティレベルを要求するサービスにアクセスする。より高いセキュリティレベルの例は、５桁のＰＩＮコードの手段によりユーザがオンラインバンクの口座にアクセスできることである。しかし、もしユーザがさらに銀行口座からの金融取引を許可することを望むと、追加の使い捨て(one-time)パスワードやＴＡＮが要求される。他の例では、ユーザはパスワードという手段で個別化されたＷｅｂポータルサイトにアクセスできる。ポータルサイトのサービスには、費用が必要なものもある。ユーザがそのようなサービスをクリックすると、ユーザのＰＣに接続されたＩＣカードリーダーを使用した認証が必要かもしれない。

サービスプロバイダＳＰはメッセージ１０２ａを介してクライアントからサービスプロバイダＳＰに送信されたサービス要求を検知し、より厳しい要求に適合する次の修正されたASProf、すなわち修正されたASProfは最初の認証に使用されたASProfよりも強い、に要求される、ASProfを選択する。サービスプロバイダＳＰはメッセージ１０２ｂを介して、最初の認証に使用されたアイデンティティプロバイダと必ずしも同一でなくてもよいアイデンティティプロバイダに対し、修正されたASProfとユーザＩＤを含む認証要求を送信する。アイデンティティプロバイダＩｄＰ１はプロセス１０３ａで、より強いASProf要求を満たすことができるかチェックする。もしできれば、アイデンティティプロバイダＩｄＰ１はプロセス１０３ａで、このより強いASProfが新たなユーザ証明の検証を要求するかをチェックし、必要ならば、メッセージ１０３ｂと１０３ｃを介してこの検証を実行する。図３のように、任意のメッセージ１０３ｂ、１０３ｃは、帯域内又は帯域外の通信を介して交換されうる。そして、メッセージ１０３ｄを介してアイデンティティプロバイダＩｄＰ１からサービスプロバイダＳＰに送信されるユーザ認証のアサーションに関して図３と共に描かれるように、処理される。アサーションに基づいて、サービスプロバイダＳＰは、改良されたASProfを要求するサービスへのアクセスを許可し、サービスセッションは継続しうる。選択されたASProf（指示の１形態としての）を送信する代わりに、例えば選択されたASProfがアイデンティティプロバイダＩｄＰ１にとって既知又はアクセス可能な時は、選択されたASProfのＵＲＩのような指示が送信されることも可能である。もし最初の認証に使用されたASProfがアイデンティティプロバイダＩｄＰ１にとって既知ならば、サービスプロバイダＳＰは代わりに最初の認証に使用されたASProfよりも強いASProfの使用の指示を送信するかもしれない。この場合、アイデンティティプロバイダＩｄＰ１は修正されたASProfの選択を、例えばグラフを探索することにより、実行できる。望ましくは、この改良された認証に使用される修正されたASProfは、サービスプロバイダＳＰに対して指示され、ＳＰによって表改良された認証のために同意される。

図１１は、認証とサービスセッションが最初のアイデンティティプロバイダＩｄＰ１によって確立され、クライアントが確立されたセッションよりも高いセキュリティレベルを要求するサービスへのサービスアクセスを要求する場合を示す図である。サービスプロバイダＳＰはそれに応じてメッセージ１１２ａを介して送信されるより高いセキュリティレベルを要求するサービス要求を検知し、メッセージ１１２ｂを介して最初のＩｄＰに、修正されたASProfとユーザＩＤを含む認証要求を送信する。最初のアイデンティティプロバイダＩｄＰ１はプロセス１１３ａ１で受信した修正されたASProfをチェックし、修正されたASProfはサポートされていないことを検知する。したがって、最初のアイデンティティプロバイダＩｄＰ１はメッセージ１１３ｂを介して、修正されたASProfに対する拒絶と、任意で最初のアイデンティティプロバイダＩｄＰ１にサポートされる代替ASProfを送信する。サービスプロバイダＳＰはプロセス１１３ｃで、代替ASProfsをチェックし、受け入れ不可能であると考えるかもしれない。拒絶に対する応答が、最初のアイデンティティプロバイダＩｄＰ１に、認証は最初のアイデンティティプロバイダＩｄＰ１に関しては終了することを示して、送信されるかもしれない。ここでサービスプロバイダＳＰは、認証の改良を終了することもできるし、２番目のアイデンティティプロバイダＩｄＰ２を認証の改良のために選択することもできる。もし２番目のアイデンティティプロバイダＩｄＰ２が利用可能ならば、さらなる認証要求がメッセージ１１２ｂを介して、２番目のアイデンティティプロバイダＩｄＰ２に送信される。さらなる要求は、修正されたASProfと、最初のアイデンティティプロバイダＩｄＰ１で最初の認証に使用されたユーザに固有の又は固有でないユーザＩＤを含む。２番目のアイデンティティプロバイダＩｄＰ２はプロセス１１３ａ２で、修正されたASProfがサポートされているかチェックする。もし修正されたASProfがサポートされていれば、例えば帯域内又は帯域外の通信を介したメッセージ１１３ｂ、１１３ｃを活用することにより、必要ならユーザ証明の検証が実行されうる。ユーザ認証のアサーションはメッセージ１１３ｄを介してＳＰに送信される。アサーションに基づいて、サービスプロバイダＳＰはより厳しいセキュリティ要求を持つサービスへのアクセスを許可することができ、サービスセッションは継続しうる。

さらなる典型的な改良の筋書きは次の通りである。ユーザは、時にインターネットアクセスプロバイダとも呼ばれるインターネットサービスプロバイダ（ＩＳＰ）によって、パスワードを介して認証される。ある時点で、ユーザは費用がかかり、例えば認証証書としての携帯電話（サブスクライバアイデンティティモジュール／ワイヤレスアイデンティフィケイションモジュール、ＳＩＭ／ＷＩＭ）を介するより強い認証を要求するビデオストリーミングサービスにアクセスすることを望む。サービスプロバイダすなわちビデオストリーミングサービスのプロバイダは、認証の改良のために最初にＩＳＰにコンタクトを取る。ＩＳＰは一般的にＳＩＭや携帯電話を管理しないので、多分単純なパスワードリストのみではより厳しいASProfに適合することができない。ＩＳＰはサービスプロバイダにより弱いASProfを提案するかもしれないが、サービスプロバイダは拒絶する。そしてサービスプロバイダは、潜在的なアイデンティティプロバイダとして最初のサービス要求の中でクライアントに特定されうるユーザの携帯オペレータにコンタクトする。アイデンティティプロバイダとしての携帯オペレータは特定のASProfに適合することができる。すなわち、特定のＳＩＭ／ＷＩＭを所有し、ＰＩＮコードを知っていることを要求する。それは、サービスプロバイダに対してより強い認証の表示を送信するので、ユーザはストリーミングサービスの使用を続行することができる。

ASProfがアイデンティティプロバイダからサービスプロバイダに、又はその逆に送信されるときはいつでも、完全なASProfの属性の組を明示的に示す必要があるわけではない。したがって、ASProfs間の関係又は完全なグラフですら、全体として送信される必要はない。代わりに、参照（ＵＲＩ）が最新情報と共に、後述のように交換されるデータ量を減少させるために、使用されうる。

ASProfは一連の部分から成り、各々が属性を示す。例えば、表ＡによるＸＭＬでの記述を、＜user_credentials＞、＜transport_layer_security＞、＜security_policies＞、＜user_registration＞に関係する部分と比較する。個々の部分からなる属性は互いに補足し合う。すなわち、もしそれらが一つの部分にのみ存在するならば。又は、お互いを無効にする。すなわち、もしそれらが双方の部分に存在するならば。無効にする場合、部分の順位に基づく優先順位の決まりが特定される必要がある。すなわち、それに続く部分は前の部分を無効にするし、その逆もまた然りである。

参照、例えば望ましくはＵＲＩは、そのASProfや部分の全属性を明示的に示す代わりに、ASProfや、望ましくは完全なASProfの意味上の部分集合を意味する部分を参照するために使用されうる。参照の使用により、取得（フェッチング、fetching）と保持（キャッシング、caching）が可能になり、実質的に往復して送信されるデータ量を減らすことができる。例えば、サービスプロバイダがある期間に同一のASProfを使用するあるアイデンティティプロバイダを頻繁に使用する場合、新たなユーザが前記ある期間に認証されるたびにサービスプロバイダとアイデンティティプロバイダの間でASProfが明示的に交換される必要はない。

ASProfsの最新のものを使用することは、既存のASProfsと新しいASProfsの間の違いに関するデルタ更新という意味で、さらに交換されるデータ量を減らすことができる。最新のASProfは、既存のASProfを補足し、又は属性のいくつかを置き換える新しいASProfである。また、最新の部分又は最新の属性も可能である。例えば、ユーザはパスワードの検証を用いてアイデンティティプロバイダによってサービスプロバイダに対して認証されてきた。あるユーザのやりとりで、認証の改良が要求され、前に使用していたASProfとの唯一の違いはパスワードの検証についてより短い有効期間(time-to-live)が特定されている。この場合、前に使用していたASProfへの参照と、加えて、変化した有効期間属性を特定する単一の属性を送信することが、受信部分が完全に取得して保持する必要のある新しいASProfへの参照を送信することに比べて、明らかに効率的である。

提案する方法は、サービスプロバイダやアイデンティティプロバイダ、プロキシに対応するサーバのような装置やクライアントデバイスでも実装される。そのような装置は少なくとも、メッセージＭ２を受信する受信ユニットＲ、メッセージＭ１を送信する送信ユニットＴ、メッセージや情報を処理する処理ユニットＰ、そして望ましくは情報を格納するデータベースＤを含む。そのような装置の例が図１２に描かれており、ユニットＲ、Ｔ、Ｐ、ＤとメッセージＭ１、Ｍ２、個々のユニットＲ、Ｔ、Ｐ、Ｄ間で情報やメッセージを交換するための相互接続ＰＲ、ＰＴ、ＰＤを示している。装置ＤＥＶは、サービスプロバイダ、アイデンティティプロバイダ、クライアントデバイスとしてのユーザによって、本方法を実装するために配置されうる装置の例である。

装置と、認証方法を実行する装置間でのメッセージと情報の交換の接続の例が、図１３、１４、１５にあり、それぞれ裏ルート、表ルート、裏表混合ルート通信である。装置は図１２と共に説明され描かれているようになされうる。

図１３はクライアントＤ１２、サービスプロバイダＤ１０、アイデンティティプロバイダＤ１１、表ルート通信によるサービスプロバイダＤ１０に対するクライアントＤ１２の認証のための３つのパーツ間の接続ＣＯＮ１０、ＣＯＮ１１、ＣＯＮ１２を示す。クライアントＤ１２とサービスプロバイダＤ１０の間の通信は接続ＣＯＮ１０を介して行なわれ、サービスプロバイダＤ１０とアイデンティティプロバイダＤ１１の間の通信は接続ＣＯＮ１１を介して行なわれ、アイデンティティプロバイダＤ１１とクライアントＤ１２の間の通信は接続ＣＯＮ１２を介して行なわれる。３つのパーツ間の接続ＣＯＮ１０、ＣＯＮ１１、ＣＯＮ１２を介して交換される情報とメッセージの例は、例えば図３の例に見られる。すなわち、サービス要求（メッセージ１ａ）、認証要求（メッセージ１ｂ）、ユーザＩＤとアイデンティティプロバイダの参照（メッセージ１ｃ）と接続ＣＯＮ１０を介したサービスセッションの関係、望ましいASProfとユーザＩＤ（メッセージ２）と、接続ＣＯＮ１１を介したユーザ認証のアサーション（メッセージ３ｄ）の関係、ユーザ証明の要求（メッセージ３ｂ）と接続ＣＯＮ１２を介したユーザ証明の配布（メッセージ３ｃ）の関係である。接続ＣＯＮ１０、ＣＯＮ１１、ＣＯＮ１２は静的接続であってもよいが、その必要はない。例えば、接続ＣＯＮ１２はもしクライアントＤ１２が携帯電話ならばショートメッセージサービス（ＳＭＳ）を介して達成されてもよい。

図１４はクライアントＤ２２、サービスプロバイダＤ２０、アイデンティティプロバイダＤ２１、表ルート通信によるサービスプロバイダＤ２０に対するクライアントＤ２２の認証のための３つのパーツ間の接続ＣＯＮ２０、ＣＯＮ２１を示す。図１３と対照的に、サービスプロバイダＤ２０とアイデンティティプロバイダＤ２１の間に直接の接続が存在しない。代わりに、サービスプロバイダＤ２０とアイデンティティプロバイダＤ２１の間の通信は、サービスプロバイダＤ２０とアイデンティティプロバイダＤ２０の間で交換される情報はクライアントＤ２２によって中継されるという意味で、クライアントＤ２２を介して達成される。接続ＣＯＮ２０とＣＯＮ２１を介した３つのパーツ間で交換される情報とメッセージの例が、図４に見られる。すなわち、サービス要求（メッセージ１ａ）、認証要求（メッセージ１ｂ）、ユーザＩＤとアイデンティティプロバイダの参照（メッセージ１ｃ）とサービスセッションは、接続ＣＯＮ２０を介して送信される。同様に、ユーザ証明の要求（３ｂ）とユーザ証明は接続ＣＯＮ２１を介して送信される。しかし、認証要求（メッセージ４２ａ、４２ｂ）に含まれる望ましいASProfとユーザＩＤは、クライアントＤ２２を介して、サービスプロバイダＤ２０からアイデンティティプロバイダＤ２１に、接続ＣＯＮ２０とＣＯＮ２１を介して送信される。同様の中継は、クライアントＤ２２を介し、接続ＣＯＮ２１とＣＯＮ２０を介してアイデンティティプロバイダＤ２１からサービスプロバイダＤ２０に送信されるユーザ認証のアサーション（メッセージ４３ｄ、４３ｅ）でも達成されうる。

図１５は、表ルート実装を真似る(emulate)ためのプロキシＤ３１を使用する混合実装を示す。サービスプロバイダＤ３０のサービスに対するクライアントＤ３３のユーザ認証のために、クライアントＤ３３は接続ＣＯＮ３０を介してサービスプロバイダＤ３０にサービス要求を送信する。サービスプロバイダＤ３０は接続ＣＯＮ３０を介してクライアントにユーザ認証の要求で応じ、クライアントＤ３３はサービスプロバイダＤ３０に、接続ＣＯＮ３０を介してユーザＩＤと任意にアイデンティティプロバイダＤ３２の参照を提供する。サービスプロバイダＤ３０とアイデンティティプロバイダＤ３２の間の通信のため、例えば、ユーザＩＤと望まれるASProfの送信やユーザ認証のアサーションのために、プロキシＤ３１はサービスプロバイダＤ３０とアイデンティティプロバイダＤ３２の間に置かれる。サービスプロバイダＤ３０からアイデンティティプロバイダＤ３２へ、及びその逆への情報は、接続ＣＯＮ３１とＣＯＮ３２を用いてプロキシＤ３１を介して送信されうる。ユーザ証明の要求とユーザ証明の配布のために、接続ＣＯＮ３５が使用されうる。代わりに、接続ＣＯＮ３２とＣＯＮ３４がユーザ証明の要求と配布のために使用されてもよい。プロキシＤ３１とクライアントＤ３３の間で接続ＣＯＮ３４を介してさらなる情報が交換されうる。

本発明による方法は、サービスプロバイダ、アイデンティティプロバイダ、プロキシ、クライアントに対応する装置に取り込み可能な１つ以上のコンピュータプログラムでも実装される。１つ以上のコンピュータプログラムは、上述の方法を実装するためのソフトウェアコードの部分を含む。１つ以上のコンピュータプログラムはコンピュータが読み取り可能な媒体に保存されうる。コンピュータが読み取り可能な媒体は、サーバ内やサーバ外に設置される永久又は書き換え可能なメモリにすることができる。コンピュータプログラムは例えばケーブルや無線接続を介した信号列としてもサーバに転送されうる。

提案する方法はＧＰＲＳやＵＭＴＳのような２世代や３世代の移動体通信システムでもそれぞれ適用されうる。それは、インターネットのような固定されたネットワークや、固定とワイヤレスローカルエリアネットワーク（ＷＬＡＮ）の組み合わせにおけるサービスに対する認証にも応用されうる。移動体及び固定的なクライアント端末は、ユーザによって設置されうる。サービスプロバイダ、アイデンティティプロバイダ、プロキシに対応するサービスは一般的に、ネットワーク中で固定的なものである。しかし、提案する方法は移動する、固定的でないサービスにも応用可能である。サーバの例は、パーソナルコンピュータ（ＰＣ）やラップトップコンピュータである。

以下に、本発明のいくつかの利点をまとめる。

サービスプロバイダと固定的な認証セキュリティーポリシーを持つアイデンティティプロバイダの間の固定された関係を持つのに対して、本発明は特別な交渉と認証セキュリティプロファイルの改良を提供することができる。特別な交渉のために、サービスプロバイダとアイデンティティプロバイダの間でASProfについての事前の同意は必要ない。

さらに、異なる種類のサービスと取引が、ユーザが自分がそのユーザであると主張していることを知ることの確実性について極めて異なる要求を持つことができる。同様に、異なる認証機構とセキュリティ設備が異なるレベルの確実性を提供する。提案する方法はこれらの異なるレベルの確実性をサポートし、それゆえ、２値的な認証概念に共通する制約を克服する。

他の利点は、本発明は、サービスプロバイダとアイデンティティプロバイダの双方の側でリアルタイムの(on-the-fly)ポリシーの変更を許可する柔軟性に富むモデルを提供する。もしポリシーとセキュリティ特徴が変化しても、サービスプロバイダとアイデンティティプロバイダの間の帯域外の通信は最小限にされうる。

さらに、認証方法はASProfsの複雑な特徴を扱うことを許可する。すなわち、指紋認識とパスワードのような異なる属性が認証セキュリティ強度に関して比較されうる。さらに、異なる属性の組み合わせが、提案する方法はさらに融通が利くようにして、交渉されうる。

また、認証方法はサービスプロバイダそれぞれに、ポリシーの決定と、結局は認証でポリシーの実行点を決定するように、サービスが振る舞う権限を与える。このサービスプロバイダに親切な場合では、提案する発明は、アイデンティティプロバイダがユーザ証明の有効性を確認するサービスを提供するように実装され、アイデンティティプロバイダは望ましくはセッションの確立又は認証の更新にのみ関わる。セッションの間にアイデンティティプロバイダをそれ以上必要としないため、結果として、アイデンティティプロバイダの負担とそのセッション管理の複雑さを減少させ、間に入るアイデンティティプロバイダを持つ従来技術の認証方法に比べて拡張性が向上する。

（ａ）属性を持つ認証セキュリティプロファイルの一例を示す図である。 （ｂ）認証セキュリティプロファイル及びその認証セキュリティ強度に関する順位付けの一例を示す図である。 数字属性値と認証セキュリティ強度の間のマッピングの例を示す図である。 認証に関する１番目の典型的なメッセージの流れを示す図である。 認証に関する２番目の典型的なメッセージの流れを示す図である。 認証に関する３番目の典型的なメッセージの流れを示す図である。 認証に関する４番目の典型的なメッセージの流れを示す図である。 認証に関する５番目の典型的なメッセージの流れを示す図である。 認証に関する６番目の典型的なメッセージの流れを示す図である。 認証に関する７番目の典型的なメッセージの流れを示す図である。 認証の改良に関する１番目の典型的なメッセージの流れを示す図である。 認証の改良に関する２番目の典型的なメッセージの流れを示す図である。 本方法を実装する装置の一例を示す図である。 本方法を実施するための装置及び装置間の接続に関する１番目の例を示す図である。 本方法を実施するための装置及び装置間の接続に関する２番目の例を示す図である。 本方法を実施するための装置及び装置間の接続に関する３番目の例を示す図である。

Claims (27)

1. サービスプロバイダ（ＳＰ）のサービスに対するユーザ認証の方法であって、
   クライアントによって前記ユーザのために前記サービスプロバイダ（ＳＰ）の前記サービスへのアクセスを要求する工程と、
   前記サービスプロバイダ（ＳＰ）によって前記サービスに対する前記ユーザ認証のための少なくとも１つの認証スキームを指定する１つ以上の認証セキュリティプロファイルを選択する工程と、
   アイデンティティプロバイダ（ＩｄＰ１）での前記ユーザ認証を要求するために、前記サービスプロバイダ（ＳＰ）によって前記１つ以上の選択された認証セキュリティプロファイルを指し示す情報と前記ユーザを特定するユーザＩＤとを前記アイデンティティプロバイダ（ＩｄＰ１）に送信する工程と、
   前記アイデンティティプロバイダ（ＩｄＰ１）によって前記ユーザＩＤと前記１つ以上の認証セキュリティプロファイルの中の１つの認証セキュリティプロファイルとに基づいて前記ユーザを認証する工程と、
   前記アイデンティティプロバイダ（ＩｄＰ１）によって前記ユーザ認証を示すアサーションを前記サービスプロバイダ（ＳＰ）に送信する工程と、
   を備えることを特徴とする方法。
2. 前記サービスプロバイダ（ＳＰ）は、前記アイデンティティプロバイダ（ＩｄＰ１）から、前記アイデンティティプロバイダ（ＩｄＰ１）によってサポートされる１つ以上の認証セキュリティプロファイルのグループを指し示す情報を受信し、
   前記サービスプロバイダ（ＳＰ）は、１つ以上の認証セキュリティプロファイルを選択する前記工程において、当該１つ以上の認証セキュリティプロファイルを前記グループから選択することを特徴とする、請求項１に記載の方法。
3. 前記認証する工程の前に、前記サービスプロバイダ（ＳＰ）が、前記１つ以上の選択された認証セキュリティプロファイル及び１つ以上の他の認証セキュリティプロファイルの、各々の認証セキュリティプロファイルの間での、相互の認証セキュリティ強度の強さの関係を指し示す情報を前記アイデンティティプロバイダ（ＩｄＰ１）に送信する工程を更に備え、
   前記ユーザを認証する工程は、前記１つ以上の選択された認証セキュリティプロファイルのいずれもが前記アイデンティティプロバイダ（ＩｄＰ１）によってサポートされない場合に、
   前記アイデンティティプロバイダ（ＩｄＰ１）によって、前記関係を指し示す情報に基づいて、前記１つ以上の他の認証セキュリティプロファイルの中の、前記１つ以上の選択された認証セキュリティプロファイルと比較して同等又はより強い認証セキュリティ強度を持つ１つの認証セキュリティプロファイルを選択することと、
   前記選択された１つの認証セキュリティプロファイルに基づいて前記ユーザを認証することと、
   によって実行されることを特徴とする、請求項１又は２に記載の方法。
4. 前記アサーションは、前記ユーザを認証する工程において前記認証の実行のために基づかれた認証セキュリティプロファイルを指し示す情報を伴い、前記サービスプロバイダ（ＳＰ）は、当該指し示された認証セキュリティプロファイルを受け入れ可能かチェックすることを特徴とする、請求項１乃至３のいずれか１項に記載の方法。
5. サービスプロバイダ（ＳＰ）のサービスに対するユーザ認証の方法であって、
   クライアントによって前記ユーザのために前記サービスプロバイダ（ＳＰ）の前記サービスに対するアクセスを要求する工程と、
   アイデンティティプロバイダ（ＩｄＰ１）での前記ユーザ認証を要求するために、前記サービスプロバイダ（ＳＰ）によって前記ユーザを特定するユーザＩＤを前記アイデンティティプロバイダ（ＩｄＰ１）に送信する工程と、
   前記アイデンティティプロバイダ（ＩｄＰ１）によって前記ユーザＩＤと少なくとも１つの認証スキームを指定する認証セキュリティプロファイルとに基づいて前記ユーザを認証する工程と、
   前記アイデンティティプロバイダ（ＩｄＰ１）によって、前記ユーザ認証を示すアサーションであって前記ユーザを認証する工程において前記認証の実行のために基づかれた前記認証セキュリティプロファイルを指し示す情報を伴うものを前記サービスプロバイダ（ＳＰ）に送信する工程と、
   前記サービスプロバイダ（ＳＰ）によって、前記指し示された認証セキュリティプロファイルを受け入れ可能かチェックする工程と、
   を備えることを特徴とする、方法。
6. さらに、前記サービスプロバイダ（ＳＰ）によって前記１つ以上の選択された認証セキュリティプロファイルを指し示す情報と前記ユーザを特定するユーザＩＤとを送信する前記工程の前に、前記サービスプロバイダ（ＳＰ）において、前記クライアントから前記ユーザＩＤと前記アイデンティティプロバイダ（ＩｄＰ１）を特定する情報とを、前記サービスプロバイダ（ＳＰ）から前記クライアントに送られた認証要求に応じて受信する工程を備えることを特徴とする、請求項１乃至５のいずれか１項に記載の方法。
7. さらに、前記サービスプロバイダ（ＳＰ）が前記アサーションに基づいて前記サービスに対するアクセスを許可する工程を備えることを特徴とする、請求項１乃至６のいずれか１項に記載の方法。
8. さらに、前記サービスプロバイダ（ＳＰ）が、前記アサーションと前記指し示された認証セキュリティプロファイルを受け入れ可能であるという前記受け入れ可能かのチェックの結果とに基づいて前記サービスへのアクセスを許可する工程を備えることを特徴とする、請求項４乃至６のいずれか１項に記載の方法。
9. さらに、前記ユーザを認証する工程の後で当該認証を改良する工程を備え、前記認証の改良は、前記サービスプロバイダが少なくとも１つの他の認証セキュリティプロファイルを指し示す情報と前記ユーザＩＤとを前記アイデンティティプロバイダ（ＩｄＰ１）に送信し、前記アイデンティティプロバイダ（ＩｄＰ１）が前記少なくとも１つの他の認証セキュリティプロファイルと前記ユーザＩＤとに基づいて前記ユーザのさらなる認証を行ない、当該ユーザのさらなる認証を示すアサーションを前記アイデンティティプロバイダ（ＩｄＰ１）が前記サービスプロバイダ（ＳＰ）に送信することにより実行されることを特徴とする、請求項１乃至８のいずれか１項に記載の方法。
10. さらに、前記ユーザを認証する工程の後で当該認証を改良する工程を備え、前記認証の改良は、前記サービスプロバイダが少なくとも１つの他の認証セキュリティプロファイルを指し示す情報と前記ユーザＩＤとを前記アイデンティティプロバイダ（ＩｄＰ１）とは別のアイデンティティプロバイダ（ＩｄＰ２）に送信し、前記別のアイデンティティプロバイダ（ＩｄＰ２）が前記少なくとも１つの他の認証セキュリティプロファイルと前記ユーザＩＤとに基づいて前記ユーザのさらなる認証を行ない、当該ユーザのさらなる認証を示すアサーションを前記別のアイデンティティプロバイダ（ＩｄＰ２）が前記サービスプロバイダ（ＳＰ）に送信することにより実行されることを特徴とする、請求項１乃至８のいずれか１項に記載の方法。
11. サービスプロバイダ（ＳＰ）に対応する装置であって、
    メッセージを受信する受信ユニットと、
    メッセージを送信する送信ユニットと、
    メッセージと情報を処理する処理ユニットと、
    を備え、該装置は、
    前記サービスプロバイダ（ＳＰ）のサービスに対するユーザのアクセス要求を、前記受信ユニットがクライアントから受信するメッセージを介して受信し、
    前記サービスに対するユーザ認証のための少なくとも１つの認証スキームを指定する１つ以上の認証セキュリティプロファイルを選択し、
    アイデンティティプロバイダ（ＩｄＰ１）での前記ユーザ認証を要求するために、前記１つ以上の選択された認証セキュリティプロファイルを指し示す情報と前記ユーザを特定するユーザＩＤとを前記アイデンティティプロバイダ（ＩｄＰ１）に送信し、
    前記アイデンティティプロバイダ（ＩｄＰ１）から、前記ユーザ認証を示すアサーションを受信する、
    ようになされることを特徴とする、装置。
12. 前記装置は、前記アイデンティティプロバイダ（ＩｄＰ１）から、前記アイデンティティプロバイダ（ＩｄＰ１）によってサポートされる１つ以上の認証セキュリティプロファイルのグループを指し示す情報を受信し、
    前記装置は、前記サービスに対する前記ユーザ認証のための少なくとも１つの認証スキームを指定する１つ以上の認証セキュリティプロファイルを選択する際に、前記１つ以上の認証セキュリティプロファイルを前記グループから選択するようになされることを特徴とする、請求項１１に記載の装置。
13. 前記装置は、前記ユーザ認証を示す前記アサーションを受信する前に、前記１つ以上の選択された認証セキュリティプロファイル及び１つ以上の他の認証セキュリティプロファイルの、各々の認証セキュリティプロファイルの間での、相互の認証セキュリティ強度の強さの関係を指し示す情報を前記アイデンティティプロバイダ（ＩｄＰ１）に送信するようになされることを特徴とする、請求項１１又は１２に記載の装置。
14. 前記装置は前記アイデンティティプロバイダ（ＩｄＰ１）が前記ユーザ認証を実行する際に基づいた認証セキュリティプロファイルを指し示す情報を受信し、前記装置はさらに、前記指し示された認証セキュリティプロファイルを受け入れ可能かチェックするようになされることを特徴とする、請求項１１乃至１３のいずれか１項に記載の装置。
15. サービスプロバイダ（ＳＰ）に対応する装置であって、
    メッセージを受信する受信ユニットと、
    メッセージを送信する送信ユニットと、
    メッセージ及び情報を処理する処理ユニットと、
    を備え、該装置は、
    前記サービスプロバイダ（ＳＰ）のサービスに対するユーザのアクセス要求を、前記受信ユニットがクライアントから受信するメッセージを介して受信し、
    アイデンティティプロバイダ（ＩｄＰ１）でのユーザ認証を要求するために、前記ユーザを特定するユーザＩＤを前記アイデンティティプロバイダ（ＩｄＰ１）に送信し、
    前記アイデンティティプロバイダ（ＩｄＰ１）から、前記ユーザ認証を示すアサーションであって、少なくとも１つの認証スキームを指定する認証セキュリティプロファイルを指し示す情報を伴うものを受信し、
    前記指し示された認証セキュリティプロファイルを受け入れ可能かチェックする、
    ようになされることを特徴とする、装置。
16. 前記装置は、当該装置からクライアントに送られた認証要求に応じて前記クライアントから前記ユーザＩＤと前記アイデンティティプロバイダ（ＩｄＰ１）を特定する情報とを受信するようになされることを特徴とする、請求項１１乃至１５のいずれか１項に記載の装置。
17. 前記装置は前記アサーションに基づいて前記サービスに対するアクセスを許可するようになされることを特徴とする、請求項１１乃至１６のいずれか１項に記載の装置。
18. 前記装置は前記アサーションと前記指し示された認証セキュリティプロファイルを受け入れ可能であるという前記受け入れ可能かのチェックの結果とに基づいて前記サービスに対するアクセスを許可するようになされることを特徴とする、請求項１４乃至１６のいずれか１項に記載の装置。
19. 前記装置は、前記ユーザ認証を示すアサーションを受信した後で、
    少なくとも１つの他の認証セキュリティプロファイルを指し示す情報と前記ユーザＩＤとを前記アイデンティティプロバイダ（ＩｄＰ１）に送信し、
    前記アイデンティティプロバイダ（ＩｄＰ１）から、前記ユーザのさらなる認証を示すアサーションを受信する、
    ことにより前記ユーザ認証の改良を実行するようになされることを特徴とする、請求項１１乃至１８のいずれか１項に記載の装置。
20. 前記装置は、前記ユーザ認証を示すアサーションを受信した後で、
    少なくとも１つの他の認証セキュリティプロファイルを指し示す情報と前記ユーザＩＤとを前記アイデンティティプロバイダ（ＩｄＰ１）とは別のアイデンティティプロバイダ（ＩｄＰ２）に送信し、
    前記別のアイデンティティプロバイダ（ＩｄＰ２）から、前記ユーザのさらなる認証を示すアサーションを受信する、
    ことにより前記ユーザ認証の改良を実行するようになされることを特徴とする、請求項１１乃至１８のいずれか１項に記載の装置。
21. アイデンティティプロバイダ（ＩｄＰ１）に対応する装置であって、
    メッセージを受信する受信ユニットと、
    メッセージを送信する送信ユニットと、
    メッセージ及び情報を処理する処理ユニットと、
    を備え、該装置は、
    前記アイデンティティプロバイダ（ＩｄＰ１）に対してユーザを特定するユーザＩＤとサービスプロバイダ（ＳＰ）の前記サービスに対するユーザ認証のための少なくとも１つの認証スキームを指定する１つ以上の認証セキュリティプロファイルを指し示す情報とを含む、前記ユーザ認証の要求を受信し、
    前記ユーザＩＤと前記１つ以上の認証セキュリティプロファイルの中の１つの認証セキュリティプロファイルとに基づいて前記ユーザを認証し、
    前記サービスプロバイダ（ＳＰ）に前記ユーザ認証を示すアサーションを送信する、
    ようになされることを特徴とする、装置。
22. 前記装置は前記アイデンティティプロバイダ（ＩｄＰ１）によって前記認証のためにサポートされる１つ以上の認証セキュリティプロファイルのグループを指し示す情報を前記サービスプロバイダ（ＳＰ）に送信するようになされることを特徴とする、請求項２１に記載の装置。
23. 前記装置は、前記１つ以上の認証セキュリティプロファイル及び１つ以上の他の認証セキュリティプロファイルの、各々の認証セキュリティプロファイルの間での、相互の認証セキュリティ強度の強さの関係を指し示す情報を前記サービスプロバイダ（ＳＰ）から受信し、
    前記装置は、前記１つ以上の認証セキュリティプロファイルのいずれもが前記アイデンティティプロバイダ（ＩｄＰ１）によってサポートされない場合に、前記関係を指し示す情報に基づいて、前記１つ以上の他の認証セキュリティプロファイルの中の、前記１つ以上の認証セキュリティプロファイルと比較して同等又はより強い認証セキュリティ強度を持つ１つの認証セキュリティプロファイルを選択し、前記選択された１つの認証セキュリティプロファイルに基づいて前記ユーザを認証することによって、前記ユーザ認証を実行するようになされることを特徴とする、請求項２１又は２２に記載の装置。
24. 前記装置は前記アサーションに、前記ユーザ認証を実行する際に基づいた認証セキュリティプロファイルを指し示す情報を伴わせるようになされることを特徴とする、請求項２１乃至２３のいずれか１項に記載の装置。
25. アイデンティティプロバイダ（ＩｄＰ１）に対応する装置であって、
    メッセージを受信する受信ユニットと、
    メッセージを送信する送信ユニットと、
    メッセージ及び情報を処理する処理ユニットと、
    を備え、該装置は、
    前記アイデンティティプロバイダ（ＩｄＰ１）に対してユーザを特定するユーザＩＤを含む、ユーザ認証の要求を、クライアント又はサービスプロバイダ（ＳＰ）から受信し、
    前記ユーザＩＤと少なくとも認証スキームを指定する認証セキュリティプロファイルとに基づいて前記ユーザを認証し、
    前記ユーザ認証を示すアサーションであって、前記装置が前記ユーザ認証を実行する際に基づいた認証セキュリティプロファイルを指し示す情報を伴うものを前記サービスプロバイダ（ＳＰ）に送信する、
    ことを特徴とする、装置。
26. コンピュータを請求項１１乃至２０のいずれか１項に記載の装置として機能させるためのコンピュータプログラム。
27. コンピュータを請求項２１乃至２５のいずれか１項に記載の装置として機能させるためのコンピュータプログラム。

Images