JP2016511849A - 独立アイデンティティ管理システム - Google Patents

Abstract

ユーザおよび／またはユーザ機器（ＵＥ）を認証するための、システム、方法、および装置の実施形態が本明細書で説明される。例えば、ユーザおよび／またはＵＥは、サービスプロバイダ（ＳＰ）によって管理されるサービスへのアクセスを要求する。ユーザは、結果を生成するアイデンティティプロバイダ（ＩｄＰ）によって認証される。ユーザアサーションがＳＰに提供され、ユーザアサーションはユーザ認証結果を含む。ＵＥは、関連する結果を生成する別のＩｄＰを用いて認証される。デバイスアサーションがＳＰに提供され、デバイスアサーションはデバイス認証結果を含む。マスタＩｄＰはアサーションを一緒に結合し、統合されたアサーションはＳＰによって提供されるサービスへのアクセスをユーザ／ＵＥが受け取ることができるようにＳＰに提供される。

Description

本発明は、独立アイデンティティ管理システムに関し、特に、ユーザおよび／またはユーザ機器（ＵＥ）を認証するための、システム、方法、および装置に関する。

関連出願の相互参照
本出願は、２０１２年１２月１２日に出願された米国仮特許出願第６１／７３６４０７号、および２０１３年２月１５日に出願された米国仮特許出願第６１／７６５３５４号の利益を主張し、両出願の開示は、本明細書中でそれらの全体が説明されているかのように、参照により本明細書に組み込まれる。

多くのインターネットサービス（例えば、バンキング、マルチメディア、ゲームなど）は、サービスがアクセスされることができる前に、モバイルデバイスのユーザの認証を要求する。例えば、企業および「オーバザトップ」アプリケーションサービスプロバイダは、ユーザが認可されるために、ユーザのアイデンティティをアサートすることができる。サービスプロバイダは、しばしば、各サービスプロバイダによって提供されるサービスにアクセスするために、異なる登録プロファイルを作成することをユーザに要求する。したがって、ユーザは、しばしば、様々なサービスにアクセスするために、多くのパスワードおよびユーザ名を有し、それがユーザに大きな負担をかける。

認証のためにユーザパスワードを使用する代わりに、２要素認証が使用され、またはユーザＩＤ／パスワード証明書の使用に加えて、２要素認証が使用される。例示的な２要素認証は、第１の認証要素としてのユーザのＩＤ／パスワードと、第２の認証要素としてのハードウェア／ソフトウェアベースのトークンとに基づく。ユーザＩＤ／パスワードは、ユーザのプレゼンスを認証し、トークンは、トークンが機能的に存在するデバイスをユーザが所有していることを確認する。多要素認証とは、２以上の要素を使用する任意の認証のことである。例えば、ユーザＩＤ／パスワードおよびトークンに加えて、第３の要素が、ユーザのバイオメトリック（例えば、指紋、網膜スキャンなど）によって提供される。

３ＧＰＰ ＴＲ ３３．９２４： "Ｉｄｅｎｔｉｔｙ ｍａｎａｇｅｍｅｎｔ ａｎｄ ３ＧＰＰ ｓｅｃｕｒｉｔｙ ｉｎｔｅｒｗｏｒｋｉｎｇ； Ｉｄｅｎｔｉｔｙ ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｇｅｎｅｒｉｃ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ａｒｃｈｉｔｅｃｔｕｒｅ （ＧＡＡ） ｉｎｔｅｒｗｏｒｋｉｎｇ" ＴＲ ３３．８０４： "Ｓｉｎｇｌｅ Ｓｉｇｎ Ｏｎ （ＳＳＯ） ａｐｐｌｉｃａｔｉｏｎ ｓｅｃｕｒｉｔｙ ｆｏｒ Ｃｏｍｍｏｎ ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ （ＩＭＳ） ｂａｓｅｄ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＳＩＰ） Ｄｉｇｅｓｔ" ３ＧＰＰ ＴＳ ３３．２５９： "Ｋｅｙ Ｅｓｔａｂｌｉｓｈｍｅｎｔ ｂｅｔｗｅｅｎ ａ ＵＩＣＣ ｈｏｓｔｉｎｇ ｄｅｖｉｃｅ ａｎｄ ａ ｒｅｍｏｔｅ ｄｅｖｉｃｅ"

本発明は、ユーザおよび／またはユーザ機器（ＵＥ）を認証するための改善された、システム、方法、および装置を提供する。

ユーザおよび／またはユーザ機器（ＵＥ）を認証するための、システム、方法、および装置の実施形態が、本明細書で説明される。例示的な一実施形態では、マスタアイデンティティプロバイダ（Ｍ−ＩｄＰ）は、ユーザ機器（ＵＥ）を介するサービスへのアクセスを要求したユーザを認証するように求める要求をサービスプロバイダ（ＳＰ）から受信する。要求は、認証要件のインジケーションと、Ｍ−ＩｄＰに関連付けられたユーザのアイデンティティとを含む。認証要件のインジケーションは、必要とされる認証保証レベルを含む。あるいは、認証要件のインジケーションは、必要とされる認証要素の識別情報を含む。Ｍ−ＩｄＰは、認証要件を達成することが可能な複数の認証要素を決定する。Ｍ−ＩｄＰに関連付けられたユーザアイデンティティに基づいて、決定された認証要素のうちの選択されたいくつかと関連付けられた、ユーザまたはＵＥのアイデンティティが決定される。認証要素のうちの選択されたものと関連付けられたアイデンティティが使用されて、各選択要素についての認証を要求する。Ｍ−ＩｄＰは、各選択要素についての認証の結果を受信し、結果を組み合わせて、認証要件、例えば、必要とされる認証保証レベルに従って認証が成功したことを示す認証アサーションを生成する。認証アサーションは、サービスプロバイダに送信される。

別の実施形態では、マスタアイデンティティプロバイダ（Ｍ−ＩｄＰ）は、ユーザ機器（ＵＥ）を介するサービスへのアクセスを要求したユーザを認証するように求める要求をサービスプロバイダ（ＳＰ）から受信する。要求は、認証要件のインジケーションと、Ｍ−ＩｄＰに関連付けられたユーザのアイデンティティとを含む。Ｍ−ＩｄＰは、認証要件を達成することが可能な複数の認証要素を決定する。Ｍ−ＩｄＰは、選択要素についての認証を実行する。Ｍ−ＩｄＰは、選択要素についての認証の結果を獲得し、結果を組み合わせて、認証要件に従って認証が成功したことを示す認証アサーションを生成する。Ｍ−ＩｄＰは、直接的に、またはＵＥを介して間接的に、認証アサーションをＳＰに送信する。一実施形態では、Ｍ−ＩｄＰは、認証要件を達成することが可能な決定された複数の認証要素のうちのいくつかを選択する。選択は、一実施形態によれば、ユーザ選択に基づき、または選択は、事前構成された方針に基づく。

より詳細な理解は、添付の図面を併用して、例として与えられる、以下の説明から得られる。

実施形態による、複数のアイデンティティプロバイダ（ＩｄＰ）を使用する多要素認証についてのフロー図である。 認証要素の認証保証レベルへのマッピングの例を示す表である。 実施形態による、モバイル加入者証明書を使用するサービスへのアクセスについてのフロー図である。 別の実施形態による、モバイル加入者証明書およびサードパーティアイデンティティプロバイダ（ＩｄＰ）を使用するサービスへのアクセスについてのフロー図である。 例示的な実施形態による、サードパーティＩｄＰによって制御される２要素認証についてのフロー図である。 安全な２要素認証のための例示的なメッセージ交換を示すブロックシステム図である。 例示的な実施形態による、サードパーティＩｄＰおよびＭＮＯ認証サービスを使用するシングルサインオン（ＳＳＯ）プロトコルのフロー図である。 汎用ブートストラップアーキテクチャ（ＧＢＡ）デバイス認証の一環としてユーザ証明書が送信される、図６に示されたＳＳＯプロトコルのフロー図である。 ＩｄＰがデバイス認証とユーザ認証の両方を実行し、アイデンティティをサービスプロバイダ（ＳＰ）にアサートする、別の実施形態のフロー図である。 ＧＢＡが実施される多要素認証のためのフロー図である。 また別の例示的な実施形態による、２要素認証を使用するＳＳＯプロトコルのフロー図である。 １または複数の開示される実施形態が実施される例示的な通信システムのシステム図である。 図１２Ａに示される通信システム内で使用される例示的な無線送信／受信ユニット（ＷＴＲＵ）のシステム図である。 図１２Ａに示される通信システム内で使用される例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。

明確で詳細な説明が、例示的な実施形態を説明するために提供されるが、本発明の範囲、適用可能性、または構成を限定することは意図されていない。本発明の主旨および範囲から逸脱することなく、機能、要素の配置、およびステップに対して様々な変更が施される。

図１ないし図２を全体として参照すると、本明細書ではマスタＩｄＰまたはｍｙＩｄＰとも呼ばれるマスタアイデンティティプロバイダ（Ｍ−ＩｄＰ）は、ユーザ機器（ＵＥ）を介するサービスへのアクセスを要求したユーザを認証するように求める要求をサービスプロバイダ（ＳＰ）から受信する。要求は、認証要件のインジケーションと、Ｍ−ＩｄＰに関連付けられたユーザのアイデンティティとを含む。認証要件のインジケーションは、必要とされる認証保証レベルを含む。あるいは、認証要件のインジケーションは、必要とされる認証要素の識別情報を含み、したがって、要求は、必要とされる認証要素を明示的に識別する。Ｍ−ＩｄＰは、認証要件、例えば、必要とされる認証保証レベルを達成することが可能な複数の認証要素を決定する。Ｍ−ＩｄＰに関連付けられたユーザアイデンティティに基づいて、決定された認証要素のうちの選択されたものと関連付けられた、ユーザまたは関連するＵＥのアイデンティティが決定される。認証要素のうちの選択されたものと関連付けられたアイデンティティが使用されて、各選択要素についての認証を要求する。Ｍ−ＩｄＰは、各選択要素についての認証の結果を受信し、結果を組み合わせて、必要とされる保証レベルに従って認証が成功したことを示す認証アサーションを作成する。認証アサーションは、サービスプロバイダに送信される。一実施形態では、各選択要素についての各認証結果は、異なるアイデンティティプロバイダから受信される。別の実施形態では、少なくとも１ないしすべての要素についての少なくとも１ないしすべての認証は、Ｍ−ＩｄＰにおいて実行される。

ネットワークが、ユーザ機器（ＵＥ）、サービスプロバイダ（ＳＰ）、およびマスタアイデンティティプロバイダ（ＩｄＰ）を含む、別の例示的な実施形態では、マスタＩｄＰが、ユーザアサーションを求める要求を受信する。要求されるユーザアサーションは、ＵＥのユーザの少なくとも１つの認証の少なくとも１つの結果を示す。マスタＩｄＰは、例えば、ＳＰの方針要件に基づいて、またはユーザによる要求に基づいて、他のアイデンティティプロバイダに認証を委託する。マスタＩｄＰは、ＳＰによって提供されるサービスへのアクセスをユーザが受け取ることができるように、ユーザアサーションをＳＰに提供する。マスタＩｄＰは、ユーザアサーションを作成するために、少なくとも１つの他のＩｄＰと通信する。マスタＩｄＰが通信するアイデンティティプロバイダ（ＩｄＰ）は、マスタＩｄＰにおけるユーザのプロファイル内に事前構成される。あるいは、マスタＩｄＰによって信用されるＩｄＰは、（例えば、マスタＩｄＰによって）発見される。発見されたＩｄＰは、認証アサーションサービスを提供することができる。例えば、ＩｄＰは、認証アサーションサービスを含むサービスを広告する。ＩｄＰは、認証アサーションサービスの能力を広告する。例えば、ＩｄＰは、それが提供できる認証の特定の強度（保証レベル）、および／またはそれが提供できるユーザ認証の鮮度レベルを広告する。例示的な実施形態では、マスタＩｄＰは、ユーザが加入契約を結んでいるモバイルネットワークオペレータ（ＭＮＯ）によって実施され、ＭＮＯは、ユーザの加入契約に関連付けられた証明書に基づいて、ユーザを認証する。別の例示的な実施形態では、ユーザおよび／またはＵＥの多要素認証が実行され、異なるＩｄＰが、認証の複数の要素の各１つに責任を負う。そのような実施形態では、マスタＩｄＰは、ＩｄＰの各々からのアサーションの各々を結合して、ユーザおよび／またはＵＥの多要素認証をＳＰに提供する。また別の実施形態では、ＳＰが、多要素認証を実行し、および／またはマスタＩｄＰとして行為する。

また別の例示的な実施形態では、マスタＩｄＰは、認証要素のサブセットを使用して、認証のサブセットを実行する。例えば、マスタＩｄＰは、他のＩｄＰから獲得された個々のアサーションを互いに結合し、またマスタＩｄＰによって実行された認証から得られた認証結果と結合する。したがって、組み合わされたアサーションが作成される。マスタＩｄＰは、組み合わされたアサーションをＳＰに転送することができる。多要素認証が実施される代替実施形態では、マスタＩｄＰは、個々のアサーションを受信し、個々のアサーションをＳＰに転送し、ＳＰは、多要素認証結果を決定し、結合する。

トークンは、しばしば、ハードウェアベースであり、認証サーバとペアにされる。トークン機能は、専用トークンハードウェアプラットフォームの外部に存在する。例えば、トークン機能は、専用アプリケーションまたはスマートフォンアプリケーションを介して提供される。アプリケーション（ａｐｐ）ベースのトークン機能は、専用ハードウェアベースのトークン機能ほどは信用できないが、そのわけは、例えば、アプリケーションベースの実施におけるトークン固有コードが、改ざん防止ハードウェアにおいて、セキュアモードで動作しないことがしばしばあるからである。

本明細書で説明されるように、ユーザ機器（ＵＥ）（例えば、スマートフォン）が、ユニバーサル集積回路カード（ＵＩＣＣ）を含む場合、ＵＥは、高度な認証保証を獲得するための、信用されることができる改ざん防止ハードウェア要素（ＵＩＣＣ）を含む。したがって、様々な実施形態では、ＵＩＣＣは、モバイルネットワークオペレータ（ＭＮＯ）と相互に認証される。第２の認証要素（例えば、所有の証明）としてのユーザのＵＩＣＣの再使用は、ＭＮＯがアイデンティティ（ＩＤ）プロバイダ（ＩｄＰ）になることを可能にし、例えば、ソフトウェアベースのトークン実施など、他の形態または方法よりも大きなセキュリティを提供する。ＭＮＯによって提供される第２の要素の認証は、ユーザまたはオーバザトップ（ＯＴＴ）アプリケーションサービスからはシームレスである。例えば、ユーザは、例えば、パスワードなどの情報をＵＥに手入力する必要がない。加えて、連合アイデンティティプロトコルを使用して、例えば、ＭＮＯなどの、信用できるアイデンティティプロバイダに認証サービスを委託することは、ユーザ認証を安全なものにするための有用でスケーラブルなソリューションを提供する。

様々な例示的な実施形態では、多要素認証は、モバイルネットワークオペレータの認証インフラストラクチャを利用することによって容易化される。例示的な実施形態では、多要素認証をサポートするために、複数のＩｄＰ加入契約が対処される。例えば、ＩｄＰの間に動的アソシエーションが作成され、ＩｄＰ間でアサーションが送信される。ＩｄＰ識別子の使用には融通性がある。例えば、ＩｄＰのためのＩｄＰ識別子が、異なるＩｄＰに適用され、１つの識別子を他のＩｄＰと共用することを可能にする。この融通性は、例えば、ＳＰと１または複数のＩｄＰとの間の既存のインタワーキング合意の適用を通して可能にされる。加えて、本明細書で説明される実施形態は、認証結合を暗号化して作成することができ、認証結合をプロトコルに基づいて作成することができる。ＧＢＡおよびＥＡＰ−ＳＩＭなどのプロトコルを用いるＭＮＯによって制御されるフレームワークを使用する認証、ならびにＧＢＡおよびＥＡＰなどの様々なフレームワークを用いるＯｐｅｎＩＤ認証を使用する認証を含む、多要素認証の様々な実施が本明細書で説明される。

本明細書で説明されるシングルサインオン（ＳＳＯ）のための様々な手法は、ユーザにかかる認証負担を軽減する。例示的な構成では、ユーザは、音声、ＳＭＳ、およびデータなどのサービスを提供するモバイル加入契約を所有している。そのようなモバイル加入契約は、ＳＳＯについての規定を定める。例えば、モバイルオペレータのＳＳＯサービスは、Ｆａｃｅｂｏｏｋ、Ｇｏｏｇｌｅ、またはＹａｈｏｏなど、１または複数の他の独立エンティティによって提供されるＳＳＯサービスと協調的に動作する。ＳＳＯサービスを提供するエンティティは、本明細書ではアイデンティティプロバイダ（ＩｄＰ）と呼ばれる。例えば、ＳＳＯサービスを提供するモバイルネットワークオペレータ（ＭＮＯ）、およびＳＳＯサービスを提供する独立エンティティは、ともにＩｄＰと呼ばれる。独立ＩｄＰは、本明細書ではサードパーティＩｄＰとも呼ばれる。例えば、オーバザトップ（ＯＴＴ）ＩｄＰ（例えば、Ｆａｃｅｂｏｏｋ、Ｇｏｏｇｌｅなど）の観点からは、ＭＮＯは、サードパーティＩｄＰと見なされ、ＭＮＯの観点からは、ＯＴＴ ＩｄＰは、サードパーティＩｄＰと見なされる。

例示的な構成では、ユーザは、モバイルオペレータによって提供されるＳＳＯサービスに登録され、また少なくとも１つの独立エンティティによって提供されるＳＳＯサービスに登録される。例えば、ユーザは、選択したＳＳＯサービスに関連付けられたアイデンティティ／ＩｄＰ識別子を使用する融通性を有することを望む。ユーザは、ユーザがアクセスするサービス（例えば、バンキング、マルチメディアなど）に関係なく、特定のＩｄＰ識別子を使用することを望む。複数のＳＳＯサービス（例えば、モバイルオペレータ、独立ＩｄＰなど）に登録し、多くのサービスと加入契約を結んだ後、ユーザは、各ＳＳＯサービスについての個人的なプロファイルを有する。ユーザは、他の識別情報を提供することなく、好ましいＩｄＰ識別子を提供することによって、アプリケーションおよび／または非ＳＳＯサービスにアクセスすることを望む。したがって、ユーザは、アプリケーションおよび／または非ＳＳＯサービスによって提供される様々なサービスへのアクセスを獲得するために、異なる（ログイン）証明書を記憶しなければならない負担から解放される。アプリケーションおよび非ＳＳＯサービスは、本明細書では、一般に、サービスプロバイダ（ＳＰ）と呼ばれる。

サービスにアクセスするため、ユーザは、サービスを提供するＳＰの認証要件を満たさなければならない。認証要件は、様々なサービスの認証方針に基づく。例えば、ＳＰの方針は、サービスがアクセスされる前に、認証が所定の保証レベル（例えば、認証強度）を満たすことを要求する。別の例として、ＳＰは、多要素認証を実行するために、特定の認証要素が使用されることを要求する。したがって、認証要件のインジケーションは、必要とされる認証保証レベルを含み、またはそれは、必要とされる認証要素の識別情報を含む。図２を参照すると、保証レベルは認証の強度を示し、高い保証レベルは認証の複数の要素を必要とする。例えば、保証レベルとはユーザが認証される保証のレベルのことであり、保証レベルは当局によって定義される。保証レベルは、認証プロトコル、認証の要素の数、認証の鮮度、および／または補足条件に基づく。例示的な実施形態では、所望の保証レベルは、様々な外部当局によって決定される。例えば、サービスプロバイダは、要求されたサービスをユーザに提供するためにそれが要求する保証レベルを決定する。外部当局は、様々な基準に基づいて保証レベルを指定する。そのような基準は、アプリケーション自体についてのセキュリティ要件、またはサービスをホストする会社のセキュリティ方針などを含む。

別の例として、ＳＰは、サービスへのアクセスを許可する前に、認証の鮮度レベルが満たされることを要求する。例えば、限定することなく、ＳＰは、最近３０秒以内に認証が実施されたことを要求する。別の例として、図２を参照すると、ＳＰは、少なくとも「７０」の保証レベルを要求し、認証要素の組み合わせ、例えば、ユーザパスワード、デバイス認証、およびバイオメトリック認証の組み合わせが、必要とされる認証保証レベルである７０を達成することを可能にする。ＳＰの認証方針に準拠するために、多要素認証が対処されなければならない。ＳＰの様々な方針に基づいて、例えば、ＳＰは、各ＩｄＰが異なる認証要素に対応するような、複数のＩｄＰを利用する。例えば、各認証プロトコルのセキュリティは、ネットワーク上の、認証エンドポイント（ＡＥＰ）と呼ばれる、それぞれのＩｄＰにおいて安全に自己完結している。別の実施形態によれば、ＳＰは、２以上の認証要素に対処するＩｄＰを利用する。本明細書で説明されるように、ユーザのホームＭＮＯは、ＩｄＰサービスを提供し、ＭＮＯは、認証に関与する。１または複数のサードパーティＩｄＰエンティティも、認証に関与する。

図１を参照すると、ＵＥ／ユーザ１０２、サービスプロバイダ（ＳＰ）１０４、およびマスタＩｄＰ１０６を含むネットワーク１００において、ユーザは、１１０において、ＳＰ１０４によって提供されるサービスへのアクセスを求める初期要求を行う。１１２において、要求は、ＳＰ１０４によってマスタＩｄＰ１０６にリダイレクトされる。ユーザの好ましい識別子を決定することによって、ＩｄＰは、マスタＩｄＰとして指定され、したがって、マスタＩｄＰは、本明細書では、限定することなく、ｍｙＩｄＰとも呼ばれる。例示的な実施形態では、マスタＩｄＰ１０６は、ＳＰ１０４とのインタワーキング合意を通して、ユーザおよび／またはＵＥを認証することに責任を負う。例えば、マスタＩｄＰ１０６は、認証が１要素であるか、それとも多要素であるかに関わらず、認証自体を実行するためのアセットを備える。あるいは、マスタＩｄＰ１０６は、自らのアセットに加えて、またはその代わりに、例えば、ＩｄＰ１０８など、他のＩｄＰのアセットも利用する。

図１の参照を続けると、１１２において、マスタＩｄＰ１０６は、ＵＥ１０２を介するサービスへのアクセスを要求したユーザを認証するように求める要求をＳＰ１０４から受信する。要求は、必要とされる保証レベルのインジケーションと、ユーザのアイデンティティとを含む。要求内のアイデンティティは、マスタＩｄＰ（例えば、ｘｙｚ＠ｍｙＩｄＰ．ｃｏｍ）と関連付けられる。例えば、１１２におけるマスタＩｄＰ１０６へのＳＰのリダイレクションメッセージにおいて、ＳＰ１０４は、強いデバイス認証が必要とされることを伝える。

強い認証が必要とされる例示的な実施形態において、例えば、必要とされる高い保証レベルがマスタＩｄＰによって受信された場合、マスタＩｄＰは、ユーザが加入契約を結んでいるＭＮＯを関与させる。マスタＩｄＰは、ＳＰの要件を満たすために、汎用ブートストラップアーキテクチャ（ＧＢＡ）能力を利用するように、ＭＮＯに指図する。例示的な代替構成では、ＳＰ方針は、エンドユーザにシームレスなログインエクスペリエンスを提供するために、ＧＢＡを介するデバイス認証を必要とする。あるいは、ＳＰは、別の例示的な方針に従って、プレゼンスのユーザ証明およびデバイスレベル認証を必要とする。例えば、２つ（例えば、デバイスとユーザ）の認証要素が、マスタＩｄＰに登録されている場合、マスタＩｄＰ自体が、認証要件に対処する。また別の構成では、マスタＩｄＰは、集約エージェントとして行為し、認証を他のＩｄＰにリダイレクトする。別の例として、ＭＮＯは複数の認証要素を処理し、または認証要素は２以上のＩｄＰの間に分配される。

例示的な実施形態では、ＩｄＰは、例えば、マスタＩｄＰから委託されて、認証をローカルに実行する助けをするローカルプロキシ機能をＵＥ上に有する。ＩｄＰが証明書の特定のセットに関してユーザ（またはＵＥ）を認証することが可能であるとして本明細書で説明される場合、ユーザは、それらの証明書をそのＩｄＰサービスに事前に登録してある。

図１を全体として参照すると、ユーザは、識別子（例えば、ｘｙｚ＠ｍｙＩｄＰ．ｃｏｍ）を提供する、ＳＳＯサービス（例えば、ＦａｃｅｂｏｏｋまたはＧｏｏｇｌｅなど）と結んだ加入契約を有する。そのような識別子は、ユーザが加入契約を結んでいる複数のサービスへのアクセスを獲得するために使用される。１１１において、ＳＳＯサービス（マスタＩｄＰ１０６）は、ＳＰ１０４によって発見され、例えば、要求時に、ＳＳＯサービスは、ユーザを認証し、そのような認証をＳＰ１０６にアサートする。ＳＰ１０６は、アサーションを評価し、ユーザへのサービスを承認または拒否する。例示的な実施形態では、複数のＩｄＰ１０８は、一緒に協調的に動作し、本明細書でマスタと呼ばれるＩｄＰの１つ（例えば、マスタＩｄＰ１０６）は、認証およびアサーションをトリガする。例えば、Ｆａｃｅｂｏｏｋ、Ｇｏｏｇｌｅ、またはＹａｈｏｏなどのＳＳＯサービスは、ＩｄＰサービスを提供し、マスタＩｄＰの任務を実行する。図１を参照すると、例示的な実施形態では、マスタＩｄＰ１０６はＳＰ１０４の中に組み込まれ、したがって、ＳＰがマスタＩｄＰになることができる。したがって、ＳＰ１０４は１または複数の要素を認証することができ、ＳＰ１０４は追加の要素については他のＩｄＰ１０８に委託することができる。例えば、そのようなシナリオは安全なＶＰＮセットアップ使用事例に適用される。

図１に示されるように、ユーザは、マスタＩｄＰ１０６に加えて、ＩｄＰ１０８とも関連付けられた証明書を有する。多要素認証がＳＰ１０４によって必要とされる例示的なシナリオでは、複数のユーザ証明書／デバイス証明書を使用する認証が必要である。例えば、１１２における要求は、必要とされる保証レベルなど、認証要件のインジケーションを含む。認証要件に基づいて、マスタＩｄＰ１０６は、認証要件を達成することが可能な複数の認証要素を決定する。例えば、やはり図２を参照すると、必要とされる保証レベルに応じて、様々な認証要素または認証要素の様々な組み合わせが、サービスにアクセスするためにＳＰ１０４によって要求される保証レベルを達成する。マスタＩｄＰ１０６と関連付けられたユーザアイデンティティ（例えば、図１におけるｘｙｚ＠ｍｙＩｄＰ．ｃｏｍ）に基づいて、マスタＩｄＰ１０６は、決定された認証要素のうちの選択されたいくつかと関連付けられた、ユーザまたはＵＥ１０２のアイデンティティを決定する。したがって、マスタＩｄＰに対応するアイデンティティは、他のアイデンティティプロバイダに対応するアイデンティティと関連付けられる。そのような他のアイデンティティプロバイダは、各々が、特定の認証要素を使用する認証に責任を負う。例示的な実施形態では、マスタＩｄＰ１０６は、ＩｄＰ１０８と関連付けられたアイデンティティを決定する。例えば、図１を特に参照すると、ＩｄＰ１０８ａは、パスワードなどのユーザ情報を記憶する。ＩｄＰ１０８ｂは、例えば、バイオメトリック情報を所有する。ＩｄＰ１０８ｃは、ＩｄＰサービスを提供するような、ユーザのモバイル加入者証明書を所有するＭＮＯである。例示的な構成では、別のＩｄＰは、プレゼンスのユーザ証明を目的として、基本ユーザプロファイル情報を含む。

依然として図１を参照すると、１１０において、ユーザは、自身の識別子（ｘｙｚ＠ｍｙＩｄＰ．ｃｏｍ）をＳＰ１０４に送信する。１１４ａないしｃにおいて、マスタＩｄＰ１０６は、認証をＩｄＰ１０８ａないしｃにそれぞれ委託し、それらにアサーションを要求する。したがって、１１４ａないしｃにおいて、認証要素のうちの選択されたものと関連付けられたアイデンティティを使用して、各選択要素についての認証が選択される。マスタＩｄＰ１０６が、１または複数の認証要素を使用して認証を実行し、それによって、１または複数の認証結果を獲得することが理解されよう。マスタＩｄＰ１０６とＩｄＰ１０８は、データベースおよび／または対応するマッピング取り決めによって容易化される、静的または動的なインタワーキング合意を有する。そのような合意は、委託された認証責任がＳＰ１０４のセキュリティ方針に従って機能することを保証する。さらに、マッピング取り決めは、マスタＩｄＰ１０６と関連付けられたアイデンティティを、他のＩｄＰ１０８と関連付けられたアイデンティティに関連付ける。例示的な実施形態によれば、１１６ａにおいて、マスタＩｄＰ１０６は、記憶された証明書を使用して、ＵＥ／ユーザ１０２の認証を実行する。１１６ｂないしｄにおいて、ＩｄＰ１０８ａないしｃは、それぞれ、それぞれの記憶された証明書（例えば、バイオメトリックまたはユーザ名とパスワードなど）を使用して、ユーザまたはＵＥの認証を実行する。ＩｄＰ１０８ａないしｃは、各認証要素についての結果を暗号化し、ＩｄＰ１０８ａないしｃは、各認証要素の結果に署名する。１１８ａないしｃにおいて、ＩｄＰ１０８ａないしｃは、それぞれ、それぞれの認証の結果をマスタＩｄＰ１０６にアサートする。したがって、マスタＩｄＰ１０６は、各選択要素についての認証の結果を受信する。１２０において、認証要件、例えば、必要とされる保証レベルに従って、認証が成功したことを示す認証アサーションを作成するために、マスタＩｄＰ１０６によって、認証結果（アサーション）が組み合わされる。組み合わされたまたは統合された認証アサーションは、１１１からのアソシエーション秘密を使用して、マスタＩｄＰ１０６によって署名される。組み合わされた認証アサーションは、暗号化される。例えば、委託先ＩｄＰ１０８ａないしｃから得られた独立の認証アサーションは、一緒に結合される。図１には３つの委託先ＩｄＰ１０８ａないしｃが示されているが、それが望ましい場合は、任意の数の、例えば、３よりも少ないまたは多いＩｄＰが使用されることが理解される。１２２において、マスタＩｄＰ１０６は、署名された認証アサーションをＳＰ１０４に送信する。１２４において、ＳＰ１０４は、認証要件、例えば、必要とされる保証レベルに従って、ユーザおよびＵＥが認証されたことを示すインジケーションをＵＥ１０２に送信し、したがって、ユーザおよびＵＥは要求されたサービスへのアクセスを受け取る。

依然として図１を参照すると、例示的な構成において、ユーザ／ＵＥ１０２は、多要素認証のための能力を、ＳＰ１０４および／またはマスタＩｄＰ１０６に登録してある。代替実施形態では、そのような発見情報は、ユーザ／ＵＥ１０２によってＳＰ１０４および／またはＩｄＰ１０６に送信される情報要素内に含まれる。また別の実施形態では、能力が、発見され、以降の認証のためにネゴシエートされ／合意される。ユーザ／ＵＥ１０２は、ＳＰ１０４および／またはＩｄＰ１０６とネゴシエートし、および／または合意に達する。

発見および認証を容易化するために、マスタＩｄＰと他のＩｄＰとの間にインタワーキング関係が確立されている。代替実施形態では、発見情報は、例えば、１１０において送信される識別子内に含まれる。他の情報要素は、ＳＰ１０４からのサービスが開始するときに、ユーザ／ＵＥ１０２によって渡される。そのような集約識別子の例は、修飾された識別子である。

ユーザは、ＩｄＰ１０８の各々と関連付けられた識別子を有する。例示的な実施形態では、ＩｄＰ１０８の各々は、マスタＩｄＰ１０６の機能を実行する。図１には示されていないが、ＩｄＰのサブセットは、委託元ＩｄＰ１０８ａないしｃによって、認証アサーションを提供するように要求される。したがって、ＩｄＰ１０８ａないしｃの少なくとも１つは、認証を実行するように求める要求を、別のＩｄＰに送信し、他のＩｄＰは、少なくとも１つのＩｄＰ１０８ａないしｃの代わりに、認証を実行する。

図１を参照して説明されたＩｄＰアーキテクチャのいくつかの例示的な変形が、本明細書で説明される。本明細書で説明される様々な例示的な構成は、ユーザによって選択されるマスタＩｄＰ（例えば、ｍｙＩｄＰ）を利用する。例えば、ユーザは、マスタＩｄＰの識別子（例えば、ｘｙｚ＠ｍｙＩｄＰ．ｃｏｍ）を、サービス要求メッセージを用いて、ＳＰに供給する。ユーザは、構成決定権を有する。例えば、ユーザは、どのＩｄＰがマスタであるかを決定する。構成決定権は、例示的な実施形態に従って制約される。例えば、例示的な実施形態によれば、ユーザがＩｄＰに登録されており、ＩｄＰが所望のＳＰとインタワーキング関係を有する場合、そのＩｄＰがマスタになる。例えば、ユーザが加入契約を結んでいるモバイルオペレータがマスタになることをユーザが望む場合、サービス要求メッセージは、例えば、ｘｙｚ＠ｍｙｍｎｏ．ｃｏｍなどの、ＭＮＯ識別子を含む。識別子を受け入れる前に、ＳＰは、ＩｄＰが提携関係に属して、認証目的ではインタワーキング関係だけで十分であるかどうか、を決定するためにチェックを行う。例えば、ＳＰは、ＩｄＰが信用できることを検証する。あるいは、ユーザによって選択されたアイデンティティに基づいてマスタＩｄＰが暗示される。例えば、ユーザがサービスにアクセスするために自身のＧｏｏｇｌｅアイデンティティを選択した場合、例示的な実施形態によれば、Ｇｏｏｇｌｅが暗示を介してマスタＩｄＰになる。

図３を参照すると、ネットワーク３００は、ＵＥ３０２と、ＳＰ３０４と、マスタＩｄＰ３０６と、ＭＮＯ３０８とを含む。２以上の図に出現する参照番号は、各図において同じまたは同様の特徴を参照することが理解される。例示的な実施形態によれば、ユーザ／ＵＥ３０２は、ＭＮＯ３０８と加入契約を結んでいる。ＭＮＯ３０８は、特に、ＭＮＯ加入者証明書は、サービスへの自動アクセスをユーザに提供するための、要素の１つを使用する認証用に利用される。３１０において、ユーザは、事前確立されたユーザ名および／または共通のユーザ名を使用して、ＳＰ３０４によって提供されるサービスにログインすることを望む。例えば、ユーザは、インターネットアイデンティティサービスプロバイダによって提供されるアイデンティティを使用する。アイデンティティは、一意的なユーザアカウント名である。そのようなアカウント名の例は、ＦａｃｅｂｏｏｋアイデンティティおよびＧｏｏｇｌｅ電子メールアドレスを含む。例示的な実施形態によれば、ＳＰ３０４は、ユーザ／ＵＥ３０２の認証が、３１０においてユーザが提供したものとは異なるオーセンティケータによって提供されることを要求する。例えば、ＳＰ３０４は、ユーザ／ＵＥ３０２を認証するために、ＵＩＣＣの認証を使用するＭＮＯ３０８を使用することを望む。

依然として図３を参照すると、１要素デバイス認証が実施される。そのような認証は、例えば、文献（例えば、非特許文献１参照）で説明されているような、ＭＮＯインフラストラクチャおよびＧＢＡを使用して実施される。３１１において、ＳＳＯサービス（マスタＩｄＰ３０６）が、ＳＰ３０４によって発見され、アソシエーション鍵（Ｋ_myIdP）が作成される。例示的な実施形態によれば、ＳＰ３０４の認証方針に基づいて、３１２において、ＳＰ３０４は、ＭＮＯ３０８によって実行される強いデバイス認証（例えば、高い保証レベルを有する認証）が必要とされることを、マスタＩｄＰ３０６に示す。認証要件のそのようなインジケーションは、ＭＮＯ３０８にデバイス認証を要求するように命じるマスタＩｄＰ３０６への指図を表す。３１４において、マスタＩｄＰ３０６は、認証をＭＮＯ３０８に委託し、ＭＮＯ３０８にアサーションを要求する。ＩｄＰとして機能することができるのに加えて、ＭＮＯ３０６は、ＵＥ３０２がＧＢＡを使用して認証される場合は、ネットワークアプリケーション機能（ＮＡＦ）、ブートストラップサーバ機能（ＢＳＦ）、および／またはホーム加入者サーバ（ＨＳＳ）として機能する。例示的な実施形態によれば、３１６において、ＭＮＯ３０８は、記憶された加入者証明書を使用して、ＵＥ３０２の認証を実行する。３１８において、ＭＮＯ３０８は、認証の結果をマスタＩｄＰ３０６にアサートする。３２０において、認証結果（アサーション）が、マスタＩｄＰ１０６によって検証される。アサーションは、３１１において得られたアソシエーション鍵（Ｋ_myIdP）を使用して署名される。３２２において、マスタＩｄＰ３０６は、署名されたアサーションをＳＰ３０４に送信する。３２４において、ＳＰ３０４は、ＵＥ３０２が認証要件に従って認証され、これにより、ＵＥ３０２が要求されたサービスへのアクセスを受け取ることを示すインジケーションを、ＵＥ３０２に送信する。

別の例示的な実施形態では、１要素ユーザ認証が実施される。ユーザ認証は、求められているサービスを使用するために合法的に登録されているユーザのプレゼンスの証明を提供することを含む。そのような証明は、例えば、ユーザ名およびパスワード、もしくはバイオメトリック（例えば、指紋）など、またはそれらの任意の適切な組み合わせなどの、ログイン証明書によって提供される。プレゼンスの証明とともに、ＳＰは、何らかの必要とされる保証レベルを主張する。図２を参照すると、保証レベルは、使用するパスワードのタイプ（例えば、強いパスワード対弱いパスワード）に影響し、および／または例えば、バイオメトリックを必要とする。ＳＰは、認証の一定の鮮度レベルを必要とする。例えば、ＳＰは、認証が３０分前より以降に行われた場合は、認証が許容可能であり、それが３０分前より以前に行われた場合は、認証が許容不能であることを決定する。３０分という時間は、例示的なものにすぎず、鮮度レベルは、それが望ましい場合は、任意の適切な時間を規定する。マスタＩｄＰは、必要とされる保証レベルおよび鮮度レベルを含む必要とされる認証自体を、それが提供できるかどうかを決定する。マスタＩｄＰは、認証の提供を助けるために、別のＩｄＰの助けを要請することを決定する。ユーザがＩＭＳ加入契約を有し、モバイルスマートカード（例えば、ＵＩＣＣ）にアクセスしない代替実施形態では、文献（例えば、非特許文献２参照）において説明されているような、ＳＩＰダイジェストが使用される。例えば、ユーザが自身のＳＩＰ証明書またはＩＭＳ証明書を入力した場合、それは、要素１の認証（例えば、ユーザが知っているもの）と呼ばれることができる。ＵＥ内のＩＭＳアプリケーションがＳＩＰ証明書を記憶している場合、それは、要素２の認証（例えば、ユーザが有するまたは所有するもの）と呼ばれることができる。

別の例示的な実施形態では、多要素認証、例えば、２要素認証が実施される。多要素認証は、例えば、バンキングサービスおよび金融サービスなどのサービスを提供するサービスプロバイダによって必要とされる。例えば、ＳＰは、デバイスを使用する人がサービスの正当な登録者であることが保証されることを望む。ＳＰとマスタＩｄＰとの間のインタワーキング合意のために、例えば、マスタＩｄＰは、認証要件が満たされることを保証するように指図される。マスタＩｄＰは、ユーザのＭＮＯ加入契約を利用して、デバイスを認証する。オペレータのインフラストラクチャがＧＢＡアウェアである場合、ＧＢＡ認証で十分である。マスタＩｄＰは、そうすることが可能な場合、ユーザを認証する。あるいは、マスタＩｄＰは、別のサードパーティＩｄＰにアサーションを要求する。

例えば、事業分野におけるサービスなど、他のサービスプロバイダは、ハードウェア／ソフトウェアＲＳＡトークンベースの認証の形態を取る、ユーザ認証の形態を利用する。そのようなトークンは、別々のキーフォブデバイスを使用して提示されることができ、またはそれらは、例えば、モバイル端末上もしくはモバイルデバイスのスマートカード上のソフトウェアで生成されることができる。ユーザのパスワードの拡張としてのトークン情報の使用は、あるレベルの保証を認証に追加する。あるいは、（例えば、ユーザ入力のパスワードを使用する）ユーザ認証と、デバイスのユニバーサル加入者アイデンティティモジュール（ＵＳＩＭ）内で動作するアプリケーションとの組み合わせは、ユーザおよびデバイスを認証するような方法で実施される。例示的な実施形態では、ＭＮＯは、２要素認証を実施するために、（例えば、ネットワークからＵＥへの、およびＵＥからネットワークＡＫＡまたはＧＢＡへの）チャレンジレスポンスメカニズムがセットアップされるように動作する、対応するプロセスを有する。（例えば、ユーザ入力のパスワードを使用する）ユーザ認証とＵＩＣＣ上で生成されるトークン情報との、例えば、暗号化された、結合は、チャレンジに対するデバイスレスポンスを含む。例えば、ＭＮＯは、ユーザが認証されたことを確認した場合、デバイスレスポンスを検証する。例として、パスワードベースのユーザ認証の場合、ユーザによって供給されたパスワード、またはユーザによって供給されたパスワードから導出される情報（例えば、パスワードダイジェスト）を使用する、ユーザのローカル認証が成功した場合に、証明書は発行される。さらに、ローカルユーザ認証は、証明書（例えば、鍵）が発行されたことによって暗示される。したがって、証明書の発行は、ＭＮＯの観点からは、ユーザがローカルに認証されたことを確認する。ＭＮＯは、ＵＳＩＭアプリケーションベースの認証と同期している。

例示的な２要素認証シナリオでは、マスタＩｄＰは、例えば、ＳＰに返されるリダイレクトされたアサーションにおいて、アサーションを組み合わせる。例えば、マスタＩｄＰは、デバイスについてのアサーションとユーザについてのアサーションとを組み合わせて、両方の認証が成功したことを示す。組み合わされたアサーションは、両方の認証が別々のプロセスとして成功したこと、または一緒に暗号化して結合されたプロセスとして成功したことを示すインジケーションを含む。ユーザのパスワードの拡張としてのＵＩＣＣベースの認証の使用は、認証に保証を追加する。サービスプロバイダは、ＵＩＣＣ上のＵＳＩＭアプリケーションを使用して、この形態の認証を利用する。

別の例示的な変形では、ＳＰは、初期サービス要求メッセージをＵＥから受信したとき、ＵＥ上にローカルに存在するプロキシマスタＩｄＰに認証をリダイレクトする。マスタプロキシＩｄＰにアサーションを返す、ターゲットＩｄＰへの認証およびアサーションの委託は、本明細書で説明されるように実行される。マスタプロキシＩｄＰは、安全な方法で、ＵＥを介して、組み合わされた／統合されたアサーションをＳＰにリダイレクトする。認証が成功した場合、例えば、サービスがユーザに対して許可される。

以下で説明される様々な例は、モバイルデバイス上に記憶されるＭＮＯによって準備された証明書を用いて、ＭＮＯによって制御される認証インフラストラクチャを利用する例示的なメカニズムについて説明する。例はＧＢＡを使用するメカニズムについて説明するが、それが望ましい場合は、ＭＮＯによって準備された証明書への結合を可能にするＥＡＰ（例えば、ＳＩＭ、ＡＫＡ、ＡＫＡ’）および（例えば、ＳＩＭ、ＡＫＡ、ＡＫＡ’を用いる）ＯｐｅｎｌＤ−ＥＡＰ実施形態が実施されることができることが理解される。

図３を再び参照すると、ＭＮＯ認証サービスは、例えば、ＯｐｅｎＩＤ ＧＢＡプロトコル（例えば、非特許文献１参照）、またはＯｐｅｎＩＤと組み合わされるＭＮＯによる認証のための他の任意の指定されたプロトコルに準拠して動作する。ユーザＩｄＰプロキシは、ＯｐｅｎＩＤ機能（例えば、ＯｐｅｎＩＤ ２．０）、およびリライングパーティ（ＲＰ）機能を包含する。サービスプロバイダおよびユーザＩｄＰプロキシは、ＯｐｅｎＩＤ ２．０に準拠して機能する。ＩｄＰ間でインタワーキング取り決めが確立される。

図４を参照すると、ネットワーク４００は、ＵＥ４０２と、ＳＰ４０４と、ユーザＩｄＰ（例えば、ＯｐｅｎＩＤ ＩｄＰ）プロキシ４０６と、ＩｄＰとして機能することができ、これによりＩｄＰ４０８とも呼ばれる、ＭＮＯ４０８とを含む。例示的な実施形態では、ＵＥ４０２のユーザは、ＭＮＯ４０８と加入契約を結んでいる。４１０において、ユーザは、サービスにログインすることを望み、これによりオリジナルのユーザアイデンティティ（ＩＤ＿Ｕ）を使用して、ＳＰ４０４によって提供されるサービスへのアクセスを要求する。４１１において、アソシエーション鍵（Ｓ＿Ｕ）が、ＳＰ４０４とユーザＩｄＰプロキシ４０６との間で共有される。４１２および４１４において、ＵＥ４０２は、ユーザＩｄＰプロキシ４０６にリダイレクトされる。例示的な実施形態では、４１６において、４１０において提供されたオリジナルのユーザアイデンティティＩＤ＿Ｕ（例えば、ｘｙｚ＠ｍｙＩｄＰ．ｃｏｍ）が、ＭＮＯ４０８によって知られている識別子ＩＤ＿Ｍにマッピングされる。例えば、ＭＮＯ４０８によって知られる識別子は、電話番号または国際モバイル加入者識別番号（ＩＭＳＩ）などである。識別子ＩＤ＿Ｍは、４１８において、ユーザＩｄＰ４０６とＭＮＯ４０８との間のアソシエーションおよびプロビジョニングのために必要とされる。

代替実施形態では、４１０において、ＭＮＯ４０８によって知られている識別子ＩＤ＿Ｍが、オリジナルのユーザアイデンティティＩＤ＿Ｕに追加され、ＳＰに提供される。そのような実施形態では、ＳＰ４０４、特に、ＳＰ４０４のリライングパーティ（ＲＰ）機能は、識別子の組み合わせを認識する。別の実施形態では、４１１において、オリジナルのユーザアイデンティティＩＤ＿ＵからＭＮＯに知られているアイデンティティＩＤ＿Ｍへのマッピングが、アソシエーション要求時に行われる。例えば、ＳＰ４０４は、マッピングのローカルデータベースを検索する。したがって、各サービスプロバイダは、例示的な実施形態によれば、対応するマッピングデータベースを維持する。また別の実施形態によれば、４１１において、ＳＰ４０４においてアソシエーション要求を受信した後に、マッピングが行われる。あるいは、例えば、４１４においてリダイレクトに従う前に、ＵＥ４０２は、ユーザ識別子ＩＤ＿ＵをＭＮＯ４０８に知られている識別子ＩＤ＿Ｍにマッピングする。４２０において、ＵＥ４０２は、ＭＮＯ４０８にリダイレクトされる。４２２において、ＭＮＯ４０８は、加入者証明書を使用して、ＵＥ４０２を認証する。認証を実行した後、４２４において、ＭＮＯ４０８は、認証アサーションを作成し、署名する。４２６および４２８において、ＵＥ４０２は、ユーザＩｄＰプロキシ４０６にリダイレクトされる。４３０において、ユーザＩｄＰプロキシ４０６は、認証アサーションを検証する。４３２において、ユーザＩｄＰプロキシは、第２の認証アサーションを作成し、署名し、４３４および４３６において、それが、ＵＥ４０２を介して、ＳＰ４０４に提供される。４３８において、ＳＰ４０４は、認証成功メッセージをＵＥ４０２に提供し、それによって、ＳＰ４０４によって提供されるサービスへのアクセスをＵＥ４０２に許可する。

本明細書で説明される様々な例示的な実施形態では、ＳＰは、必要とされる保証レベルをＩｄＰに提供することによって、または必要とされる認証要素を明示的に識別することによって、認証についての特定の要件を伝える。マスタＩｄＰは、要素の２以上の組み合わせがＳＰの認証要件を達成することが可能であり、ＳＰによって許可されている場合、認証要素を選択する。図４を参照すると、ＳＰ４０４は、ＵＥ４０２を介して、認証要件をＭＮＯ４０８に伝える。例えば、そのような信号は、ユーザＩｄＰプロキシ４０６において、ローカル方針によって解釈され、実施される。あるいは、明示的な信号が４１２においてプロトコルフローに含まれる（例えば、ＯｐｅｎＩＤメッセージのＰＡＰＥ拡張）。図４に示される例示的な実施形態は１要素認証について説明しているが、説明される呼フローは多要素認証のために拡張されることができることが理解される。例えば、ＵＥおよびユーザ４０２は２要素を使用して認証され、ＭＮＯ４０８はＵＥ４０２を認証し、ユーザはユーザＩｄＰプロキシ４０６によって認証される。

図５を参照すると、例示的な実施形態によれば、２要素認証が実行される。ネットワーク５００は、ＵＥ５０２と、ＳＰ５０４と、マスタＩｄＰ５０６と、ＭＮＯ５０８とを含む。５１０において、ユーザは、２要素認証を必要とする、オーバザトップアプリケーションサービス（例えば、Ｆａｃｅｂｏｏｋ）、または企業ネットワークサービスを提供するＳＰ５０４に、ログインしようと試みる。５１０において、ユーザは、サードパーティアイデンティティ（例えば、Ｆａｃｅｂｏｏｋアイデンティティ）を使用して、サービスへのアクセスをＳＰ５０４に要求する。サードパーティアイデンティティは、ユーザを識別し、ＩｄＰ、例えば、ＩｄＰ５０６（例えば、Ｆａｃｅｂｏｏｋ）と関連付けられる。ユーザは、認証のためのマスタＩｄＰとして行為するＦａｃｅｂｏｏｋにリダイレクトされる。サードパーティアイデンティティプロバイダ（例えば、Ｆａｃｅｂｏｏｋ）は、２要素認証を必要とする強い認証を実行することを望む。Ｆａｃｅｂｏｏｋは、例えば、ＧＢＡ（またはＥＡＰ−ＳＩＭ）を利用して、Ｆａｃｅｂｏｏｋによるユーザの認証とは別に、ＵＥ５０２のブートストラップされた認証を実行する。

依然として図５を参照すると、例示的な実施形態によれば、５１２において、ＳＰ５０４とマスタＩｄＰ５０６は、互いにアソシエートされる。５１４において、ＳＰ５０４は、２要素認証、特に、ＵＥ５０２の認証とＵＥ５０２のユーザの認証を要求する。５２２における、オーバザトップアプリケーションサービス（例えば、マスタＩｄＰ５０６）による第１の認証要素の検証時に、オーバザトップアプリケーションプロバイダ（例えば、マスタＩｄＰ５０６）は、５１８において、ユーザのＭＮＯ５０８を用いる（例えば、トークンベースの）第２の要素の認証を開始する。５２０において、第２の要素の認証が完了されたとき、５２６において、２つの認証の結果が一緒に結合される。そのような認証結合は、例えば、暗号化されて、またはプロトコルレベルで達成される。５２８において、ＭＮＯ５０８は、組み合わされた認証の署名されたアサーションをＳＰ５０４に送信する。５３０において、ＳＰ５０４は、署名されたアサーションの署名を検証する。５３２において、ＳＰ５０４は、ＵＥ５０２およびＵＥ５０２のユーザの認証が成功したことを示すインジケーションを、ＵＥ５０２に提供する。

図６は、例示的な実施形態による、安全な２要素認証のためのＧＢＡを説明するブロック図である。図６を参照すると、ネットワーク６００は、ＵＥ６０２と、ＳＰ６０４と、ラップトップ６０６と、ＭＮＯ４０８とを含む。図７も参照すると、６１０において、ユーザ識別子（ＵＩＤ）および／またはユーザパスワードが、ＳＰ６０４によって認証される。したがって、ＳＰ６０４は、第１の要素の認証を確立する。例示的な実施形態によれば、ＳＰ６０４は、例えば、その方針に基づいて、第２の認証要素の認証に着手するかどうかを決定する。６１０において、認証が成功して完了すると、６１２において、ＳＰ６０４は、ノンスＮ_SPを生成し、それをラップトップ６０６に転送する。ラップトップ６０６は、それが望ましい場合は、任意の適切なコンピューティングデバイスによって置き換えられることができ、したがって、パーソナルコンピュータ（ＰＣ）６０６ａまたはモバイル端末６０６ａとも呼ばれることができることが理解されよう。特に、モバイル端末６０６ａの機能は、モバイル端末６０６ａ上のブラウジングエージェントまたはモバイルアプリケーションによって実行されることができる（図７参照）。６１４において、ラップトップ６０６は、パスワードを用いてノンスＮ_SPを暗号化し、ＳＰ６０４とラップトップ６０６によって共有される（例えば、ＨＴＴＰダイジェストに類似した）ダイジェストを生成することができ、パスワードまたはそのハッシュもしくはダイジェストを、ＵＩＣＣ６０２ａとも呼ばれることができるＵＥ６０２に転送する（図７参照）。例示的な実施形態では、ＵＥ６０２とラップトップ６０６の間のインターフェースは、（例えば、ＢｌｕｅｔｏｏｔｈまたはＵＳＢを介して）ラップトップ６０６をＵＥ６０２に接続する分割端末構成を表す。別の例示的な実施形態では、ＵＥ６０２ａとラップトップ６０６の間のインターフェースは、ブラウジングエージェント（例えば、ブラウザまたはモバイルアプリケーション）と認証エージェント（例えば、ＵＩＣＣまたはＩＭＳまたはＳＩＰエージェント）の間の論理的分割を表す。代替実施形態では、ラップトップ６０６は、ＵＥ６０２上のスマートカード／端末インターフェースが組み込まれたバージョンを表す。分割端末インターフェースは、例えば、文献（例えば、非特許文献３参照）で説明される鍵配信サービスを介して保護されることができる。

６１６において、ＡＫＡに基づいた、またはＩＭＳ／ＳＩＰダイジェスト証明書に基づいたＧＢＡ交換が行われる。６１６において、交換が成功して完了すると、ＵＥ６０２は、６１７において（図７参照）、暗号化されたノンスＮ_SPを転送する。例えば、ノンスＮ_SPは、従来のＧＢＡ交換内の情報要素（ＩＥ）を使用して、ＭＮＯ６０８に転送されることができる。あるいは、そのようなＩＥをサポートするために、ＧＢＡコアプロトコルが拡張または変更される。６１８において、ＭＮＯ６０８は、暗号化されたノンスＮ_SPをＳＰ６０４に転送する。６２０において、ＳＰ６０４は、ＭＮＯ６０８から受信された暗号化されたノンスＮ_SPを暗号解除し、それを交換の開始時に発行されたＮ_SPと比較し、したがって、例示的な実施形態による、プロトコル結合を使用する２要素認証の例を完了する。

セキュリティ脆弱性を回避するために、例えば、プロトコルの保護および結合が、認証フローに含まれる様々なエンティティ間の別々の通信経路に沿って、認証プロトコルにおいて使用されるパラメータを送信することによって達成される。例えば、ノンスＮ_SPの使用は、提案される交換の鮮度を保証し、リプレイ攻撃を受けにくくする。プロトコルおよび／またはパラメータを分割するための他のメカニズムが実施される。図７に示される例示的な実施形態によれば、ステップ６１２、６１４、６１７、６１８、および６２０が、「所有の証明」を作成する。例えば、上述されたステップは、第１の認証要素（例えば、ＵＩＤ／パスワード）と、第２の認証要素（例えば、ＵＩＣＣ上のＡＫＡ証明書）とを結合し、したがって、ＵＥ６０２とコンピューティングデバイス６０６が結合されること、または同じデバイスであることを保証し、したがって、ステップは、「分割アイデンティティ」攻撃を防止する。暗号化されたノンスＮ_SPは、上述の交換における中間者攻撃を防止するために、平文の同じノンスの代わりに使用される。加えて、機密性保護の使用は、ステップ６１６におけるＧＢＡ交換における機密性要件を緩和する。

例示的な代替実施形態では、図６に示されるラップトップ６０６およびＵＥ６０２の構成は、モバイルフォンなどの単一のエンティティ内に組み込まれる。また別の実施形態では、図７に示されるように、ＵＥ６０２は、ＵＩＣＣ６０２ａによって実施され、ラップトップ６０６の機能は、モバイルフォンまたはセルラ機能を有するラップトップによって実施され、したがって、ラップトップ６０６は、モバイル端末６０６ａとも、またはより具体的には、ブラウジングエージェントもしくはモバイルアプリケーションとも呼ばれる（図７参照）。モバイル端末６０６ａは、ローカル通信リンクを介して、ＵＩＣＣ６０２ａに接続される。

図８を参照すると、図７のフローの例示的な変形が示されており、ユーザ認証は、後のステージで実行され、デバイス認証プロセスと組み合わされる。例えば、ノンスだけを送信する代わりに、デバイス認証の一環として、ハッシュされたユーザ名／パスワードまたはダイジェストを送信することによって、ユーザ認証とデバイス認証の間で、緊密な結合（例えば、プロトコル結合）が達成されることができる。

図８を参照すると、例示的な実施形態によれば、８１０において、ユーザは、ＯＴＴサービスプロバイダ（ＳＰ）８０６によって提供されるサービスへのアクセスを要求する。８１２において、ＯＴＴ ＳＰ８０６は、ノンスΝ_OTTを生成し、ノンスΝ_OTTを使用してユーザ認証を実行するように、モバイル端末８０４とも呼ばれることができる、ＵＥ８０４に要求する。ＯＴＴ ＳＰ８０６は、例えば、ＧＢＡに基づいて、デバイス認証を実行するように、ＵＥ８０４に命令する。８１４において、ＵＥ８０４上のユーザアプリケーションは、Ν_OTTとともにパスワードおよび／またはユーザ名を使用して、ダイジェストを作成する。８１６において、モバイル端末（ＭＴ）８０４は、ダイジェストをＵＩＣＣ８０２に転送する。ブラウジングエージェントと認証エージェントが異なる物理エンティティ上に存在している分割端末構成では、分割端末は、図８に示されるＭＴ８０４のステップを実施する。例えば、デバイス認証を実行するための認証プロセスとして、ＧＢＡが使用される場合、ＭＴ８０４は、また、ＧＢＡプロセスを開始するように、ＵＩＣＣ８０２に命令する。８１８において、ＵＩＣＣ８０２およびＢＳＦ／ＮＡＦ（例えば、ＭＮＯ８０８）は、ＧＢＡブートストラッププロトコルを実行する。プロトコルの一環として、ＵＩＣＣ８０２は、ユーザ認証の一環として導出されたダイジェストを送信する。ダイジェストは、追加のメッセージとしてＵＩＣＣ８０２によって送信され、またはそれは、ブートストラップメッセージング内に組み込まれる。８２０において、例えば、ＵＥ８０４が認証されることに成功した場合、ＢＳＦ／ＮＡＦは、ＵＥ８０４が認証されたことを示す肯定的なアサーションを送信する。あるいは、例えば、認証が失敗した場合、ＢＳＦ／ＮＡＦは、否定的なアサーションを送信する。肯定的または否定的なアサーションを用いて、ＢＳＦ／ＮＡＦは、ユーザ認証の一環としてＵＩＣＣ８０２によってそれに送信されたダイジェストを送信する。８２２において、ＯＴＴ ＳＰ８０６は、受信されたダイジェストを検証し、例えば、ダイジェストが予想されたダイジェストである場合、ユーザは、限定的なアクセスまたは完全なアクセスを提供される。アクセスのレベル（例えば、限定的または完全）は、ＳＰ８０６の方針によって決定される。例えば、例示的な実施形態によれば、予想されたダイジェストが受信され、否定的なデバイスアサーションが受信された場合、ユーザは、ＯＴＴ ＳＰ８０６によって提供されるサービスへの限定的なアクセスを提供され、肯定的なデバイスアサーションが受信され、予想されたダイジェストも受信された場合、ユーザは、ＯＴＴ ＳＰ８０６によって提供されるサービスへの完全なアクセスを提供される。例示的な実施形態によれば、予想されたダイジェストの受信は、ユーザの認証が成功したことを示し、否定的なデバイスアサーションの受信は、デバイスの認証が成功しなかったことを示す。

例として、図８に示される実施形態の代替的な変形では、ユーザは、Ν_OTTを使用して計算されたパスワードのダイジェストおよびパスワード自体を、ＯＴＴ ＳＰに提示する。ユーザは、ユーザ名もＯＴＴ ＳＰに提示する。ＵＩＣＣは、ダイジェストを、ＧＢＡプロセス（図８のステップ８１８）を介して、ＭＮＯを通してＯＴＴに送信する（図８の８２０参照）。その後、ＯＴＴ ＳＰは、ユーザから受信されたダイジェストを、ＭＮＯから受信されたものと比較し、ダイジェストが一致した場合、ユーザが認証される。

図９は、ＯＰ／ＮＡＦ９０８が、ノンス（Ｎ_OP）を生成し、認証を実行し、アイデンティティをＯＴＴ ＳＰ９０６にアサートする、例示的な実施形態を示している。図９に示される例示的な呼フローは、ＯｐｅｎＩＤ／ＧＢＡ統合呼フローに基づいている。図９に示される例示的な呼フローは、多要素認証を可能にし、認証を結合し、ＯＰ／ＮＡＦ９０８が、ユーザのアイデンティティおよびデバイスのアイデンティティの両方をＯＴＴ ＳＰ９０６にアサートすることを可能にする。

図９を参照すると、９１２において、ＯＰ／ＮＡＦ９０８は、ノンスＮ_OPを生成する。ＯＰ／ＮＡＦ９０８は、（９１４において）Ｎ_OPをＯＴＴ ＳＰ９０６を介してＵＥ９０４に転送し、またはそれは、直接的にＵＥ９０４に送信される。これは、ＯＴＴ ＳＰ９０６がノンスを生成する、他の実施形態とは異なる。９１６において、ＵＥ９０４上のユーザアプリケーションは、Ｎ_NOPとともにパスワードおよび／またはユーザ名を使用して、ダイジェストを作成する。９１８において、モバイル端末（ＭＴ）９０４は、ダイジェストをＵＩＣＣ９０２に転送する。ブラウジングエージェントと認証エージェントが異なる物理エンティティ上に存在している分割端末構成では、分割端末は、図９に示されるＭＴ９０４のステップを実施する。例えば、ＧＢＡが、デバイス認証を実行するための認証プロセスとして使用される場合、ＭＴ９０４は、また、ＧＢＡプロセスを開始するように、ＵＩＣＣ９０２に命令する。９２０において、ＵＩＣＣ９０２およびＢＳＦ９１０は、ＧＢＡブートストラッププロトコルを実行する。プロトコルの一環として、ＵＩＣＣ９０２は、ユーザ認証の一環として導出されたダイジェストを送信する。ダイジェストは、追加のメッセージとしてＵＩＣＣ９０２によって送信され、またはそれは、ブートストラップメッセージング内に組み込まれる。９２２において、ＵＥ９０４は、Ｂ−ＴＩＤおよびＫｓ＿ＮＡＦをＯＰ／ＮＡＦ９０８に転送する。９２４において、ＯＰ／ＮＡＦ９０８は、Ｂ−ＴＩＤをＢＳＦ９１０に送信する。９２６において、ＢＳＦ９１０は、Ｋｓ＿ＮＡＦおよびパスワードのダイジェストをＯＰ／ＮＡＦ９０８に転送する。ＯＰ／ＮＡＦ９０８は、ユーザのパスワードのダイジェストを計算し、それを、ＢＳＦ９１０を介して送信された、ＵＥ９０４から受信されたダイジェストと比較する。例えば、ダイジェストが同じであり、Ｋｓ＿ＮＡＦが同じである場合、９２８において、ＯＰ／ＮＡＦ９０８は、ＵＥ９０４およびＵＥ９０４のユーザを認証する。９３０において、ＯＰ／ＮＡＦ９０８は、ＵＥ９０２およびそのユーザのそれぞれのアイデンティティを、ＯＴＴ ＳＰ９０８にアサートする。

また別の例示的な実施形態では、Ｋｓ＿ＮＡＦおよびユーザのパスワードのダイジェストは、暗号化されて結合され、または組み合わされる。そのような結合は、鍵を生成する関数ＫＤＦ（Ｎ_OP，ＫＳ＿ＮＡＦ，パスワードのダイジェスト）、またはＫＤＦ（Ｋｓ＿ＮＡＦ，パスワードのダイジェスト）によって実施される。鍵は、通信を保護するための他の鍵を生成するために、またはサービスにアクセスするためのパスワードとして使用されることができる。

図１０は、ＭＮＯ１００６がＩｄＰであり、サードパーティＩｄＰが含まれない、ＧＢＡを使用する多要素認証の例示的な一実施形態を示している。例示的な実施形態に示されるように、ＭＮＯ１００６によってホストされるサービスは、多要素認証を必要とし、サービスは、認証の要素を結合する。ＧＢＡが実施されるので、ＭＮＯ１００６は、ＮＡＦ１００６と呼ばれることができる。

図１０を参照すると、例示的な実施形態によれば、１０１０において、モバイル端末（ＭＴ）１００４は、ネットワークアクセス機能（ＮＡＦ）１００６によって提供されるサービスへのアクセスを要求する。１０１２において、ＮＡＦ１００６は、ノンス（Ｎ_NAF）を作成し、ユーザ認証が実行されることができるように、それをＭＴ１００４に転送する。ＮＡＦ１００６は、ＭＴ１００４が多要素認証を実行することを要求し、またはそれは、例えば、デバイス１００４内において方針ドリブンである。例えば、ＮＡＦ１００６による多要素認証を要求するための通知は、必要とされる認証要素を含むようにＨＴＴＰヘッダ値を変更することによって実施される。１０１４において、ＭＴ／ＵＥ１００４上のユーザアプリケーション／ＧＢＡアプリケーションまたはＧＢＡ ＡＰＩは、Ｎ_NAFを使用し、ユーザのパスワードのダイジェストを作成する。例示的な実施形態では、ダイジェストを作成するために、パスワードと併せて、ユーザ名も使用される。ダイジェストは、安全なハードウェア内で生成される。１０１６において、アプリケーションは、ダイジェストをＵＩＣＣ１００２に転送し、ＧＢＡ認証プロセスを実行するためにＵＩＣＣ１００２を起動する。１０１８において、ＵＩＣＣ１００２およびＢＳＦ１００８は、ＧＢＡブートストラップ手順を実行する。ＧＢＡの一環として、例えば、ＵＥ１００４は、Ｎ_NAFを使用して作成された（ユーザのパスワードの）ダイジェストを送信する。１０２０において、ＧＢＡプロセスが完了すると、例えば、ＭＴ１００４は、ブートストラップＩＤ（Ｂ−ＴＩＤ）をＮＡＦ１００６に送信する。ＭＴ１００４は、Ｂ−ＴＩＤとともにＫｓ＿ＮＡＦを送信する。１０２２において、ＮＡＦ１００６は、例えば、ＵＥの証明書およびユーザの証明書を獲得するために、Ｂ−ＴＩＤをＢＳＦ１００８に提示する。１０２４において、ＢＳＦ１００８は、ＧＢＡプロセスの一部としてＵＩＣＣ１００２によって送信されたＫｓ＿ＮＡＦおよびパスワードのダイジェストを転送する。１０２６において、ＮＡＦ１００６は、ＮＡＦ１００６によってＵＥ１００４に送信されたＮ_NAFを使用して、ＵＥのパスワードのダイジェストを検証する。ＮＡＦ１００６は、また、ＢＳＦ１００８から獲得されたＫｓ＿ＮＡＦを検証し、それをＵＥ１００４によって送信されたＫｓ＿ＮＡＦと比較する。そのような比較は、加入契約の認証を検証する。ＮＡＦ１００６は、認証を暗号化して、またはプロトコルレベルで結合する。

図１１は、図５に示されるようなサードパーティ制御の代わりに、ＭＮＯ制御（マスタＩｄＰとしてのＭＮＯ）を用いる２要素認証を実施する、例示的な実施形態の呼フローである。そのような実施形態では、ＭＮＯ ＩｄＰ５０８がマスタである場合、サードパーティＩｄＰのためのユーザアイデンティティは、ＳＰ５０４から、ＭＮＯによって準備されるＩｄＰサービスにリダイレクトされる。例えば、１１０２において、識別子（ｘｙｚ＠ｍｙＩｄＰ．ｃｏｍ）は、それがユーザによってＳＰ５０４に送信されたとき、サードパーティＩｄＰ５０６（ｍｙＩｄＰ）と初期的に関連付けられる。ＭＮＯ５０８またはユーザとの先の合意のため（１１０４参照）、例えば、１１０６において、ＳＰ５０４は、「アサーション要求」メッセージを、ｍｙＩｄＰ５０６にリダイレクトする代わりに、識別子を認識するＭＮＯ５０８にリダイレクトする。方針に従って、またはＳＰ５０４からの暗黙的もしくは明示的な要求に応答して、ＭＮＯ５０８は、２要素認証を実行する。１つの要素は、ユーザを認証し、１つの要素は、ＵＥ５０２を認証する。ＭＮＯ５０８は、コントローラとして機能し、ユーザを認証するようにｍｙＩｄＰ５０６に指図する。ＵＥ５０２は、ＭＮＯ５０８によって別途認証される。

例示的な代替構成では、ユーザによるＳＰへの初期サービス要求メッセージから、ユーザがＭＮＯ加入者であり、ｍｙＩｄＰに登録されたサードパーティアイデンティティを所有することが理解される。初期メッセージは、ＭＮＯの発見を可能にする、ｍｙＩｄＰのための識別子以外の情報を含む。そのような情報は、明示的であり、暗黙的であり、修飾された識別子の形態を取り、またはそれらの組み合わせである。

図１２Ａは、１または複数の開示される実施形態が実施される例示的な通信システム５０の図である。通信システム５０は、音声、データ、ビデオ、メッセージング、放送などのコンテンツを複数の無線ユーザに提供する、多元接続システムである。通信システム５０は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共用を通して、そのようなコンテンツにアクセスすることを可能にする。例えば、通信システム５０は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、およびシングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）など、１または複数のチャネルアクセス方法を利用する。

図１２Ａに示されるように、通信システム５０は、無線送信／受信ユニット（ＷＴＲＵ）５２ａ、５２ｂ、５２ｃ、５２ｄ、無線アクセスネットワーク（ＲＡＮ）５４、コアネットワーク５６、公衆交換電話網（ＰＳＴＮ）８０８、インターネット８１０、ならびに他のネットワーク８１２を含むが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図していることが理解される。ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄの各々は、無線環境において動作および／または通信するように構成された任意のタイプのデバイスである。例を挙げると、ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄは、無線信号を送信および／または受信するように構成され、ユーザ機器（ＵＥ）、移動局、固定もしくは移動加入者ユニット、ページャ、セルラ電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、および家電製品などを含む。

通信システム５０は、基地局６４ａおよび基地局６４ｂも含む。基地局６４ａ、６４ｂの各々は、コアネットワーク５６、インターネット６０、および／またはネットワーク６２などの１または複数の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄの少なくとも１つと無線でインターフェースを取るように構成された、任意のタイプのデバイスである。例を挙げると、基地局６４ａ、６４ｂは、基地トランシーバ局（ＢＴＳ）、ノードＢ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、および無線ルータなどである。基地局６４ａ、６４ｂは各々、単一の要素として示されているが、基地局６４ａ、６４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含むことが理解されよう。

基地局６４ａは、ＲＡＮ５４の部分とし、ＲＡＮ５４は、他の基地局、および／または基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどのネットワーク要素（図示されず）も含む。基地局６４ａおよび／または基地局６４ｂは、セル（図示されず）と呼ばれる特定の地理的領域内で、無線信号を送信および／または受信するように構成される。セルは、さらにセルセクタに分割される。例えば、基地局６４ａに関連付けられたセルは、３つのセクタに分割される。したがって、実施形態では、基地局６４ａは、送受信機を３つ、すなわち、セルのセクタ毎に１つずつ含む。実施形態では、基地局６４ａは、マルチ入力マルチ出力（ＭＩＭＯ）技術を利用し、したがって、セルのセクタ毎に複数の送受信機を利用する。

基地局６４ａ、６４ｂは、エアインターフェース６６上で、ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄの１または複数と通信し、エアインターフェース６６は、任意の適切な無線通信リンク（例えば、無線周波（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）である。エアインターフェース６６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立される。

より具体的には、上で言及されたように、通信システム５０は、多元接続システムであり、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、およびＳＣ−ＦＤＭＡなどの、１または複数のチャネルアクセス方式を利用する。例えば、ＲＡＮ５４内の基地局６４ａ、およびＷＴＲＵ５２ａ、５２ｂ、５２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインターフェース８１６を確立する、ユニバーサル移動体通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実施する。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含む。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含む。

実施形態では、基地局６４ａ、およびＷＴＲＵ５２ａ、５２ｂ、５２ｃは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用してエアインターフェース６６を確立する、進化型ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実施する。

他の実施形態では、基地局６４ａ、およびＷＴＲＵ５２ａ、５２ｂ、５２ｃは、ＩＥＥＥ８０２．１６（すなわち、マイクロ波アクセス用の世界的相互運用性（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、移動体通信用グローバルシステム（ＧＳＭ（登録商標））、ＧＳＭエボリューション用の高速データレート（ＥＤＧＥ）、およびＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実施する。

図１２Ａの基地局６４ｂは、無線ルータ、ホームノードＢ、ホームｅノードＢ、フェムトセル基地局、またはアクセスポイントであり、例えば、職場、家庭、乗物、およびキャンパスなどの局所的エリアにおける無線接続性を容易にするための、任意の適切なＲＡＴを利用する。実施形態では、基地局６４ｂ、およびＷＴＲＵ５２ｃ、５２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実施して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立する。実施形態では、基地局８１４ｂ、およびＷＴＲＵ５２ｃ、５２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実施して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立する。さらなる実施形態では、基地局６４ｂ、およびＷＴＲＵ５２ｃ、５２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立する。図１２Ａに示されるように、基地局６４ｂは、インターネット６０への直接的な接続を有する。したがって、基地局６４ｂは、コアネットワーク５６を介して、インターネット６０にアクセスする必要がない。

ＲＡＮ５４は、コアネットワーク５６と通信し、コアネットワーク５６は、音声、データ、アプリケーション、および／またはボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄの１または複数に提供するように構成された、任意のタイプのネットワークである。例えば、コアネットワーク５６は、呼制御、請求サービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続性、ビデオ配信などを提供し、および／またはユーザ認証など、高レベルのセキュリティ機能を実行する。図１２Ａには示されていないが、ＲＡＮ５４および／またはコアネットワーク５６は、ＲＡＮ５４と同じＲＡＴまたは異なるＲＡＴを利用する他のＲＡＮと直接的または間接的に通信することが理解されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用するＲＡＮ５４に接続するのに加えて、コアネットワーク５６は、ＧＳＭ無線技術を利用する別のＲＡＮ（図示されず）とも通信する。

コアネットワーク５６は、ＰＳＴＮ５８、インターネット６０、および／または他のネットワーク６２にアクセスするための、ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄのためのゲートウェイとしての役割も果たす。ＰＳＴＮ５８は、基本電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含む。インターネット６０は、ＴＣＰ／ＩＰインターネットプロトコルスイート内の伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）など、共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークとデバイスとからなるグローバルシステムを含む。ネットワーク６２は、他のサービスプロバイダによって所有および／または運営される有線または無線通信ネットワークを含む。例えば、ネットワーク６２は、ＲＡＮ５４と同じＲＡＴまたは異なるＲＡＴを利用する１または複数のＲＡＮに接続された、別のコアネットワークを含む。

通信システム８００内のＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄのいくつかまたはすべては、マルチモード機能を含み、すなわち、ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄは、異なる無線リンク上で異なる無線ネットワークと通信するための複数の送受信機を含む。例えば、図１２Ａに示されたＷＴＲＵ５２ｃは、セルラベースの無線技術を利用する基地局６４ａと通信するように、またＩＥＥＥ８０２無線技術を利用する基地局６４ｂと通信するように構成される。

図１２Ｂは、例示的なＷＴＲＵ５２のシステム図である。図１２Ｂに示されるように、ＷＴＲＵ５２は、プロセッサ６８と、送受信機７０と、送信／受信要素７２と、スピーカ／マイクロフォン７４と、キーパッド７６と、ディスプレイ／タッチパッド７８と、着脱不能メモリ８０と、着脱可能メモリ８２と、電源８４と、全地球測位システム（ＧＰＳ）チップセット８６と、他の周辺機器８８とを含む。ＷＴＲＵ５２は、実施形態との整合性を保ちながら、上記の要素の任意のサブコンビネーションを含むことが理解されよう。

プロセッサ６８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと連携する１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他の任意のタイプの集積回路（ＩＣ）、および状態機械などである。プロセッサ８１８は、信号符号化、データ処理、電力制御、入出力処理、および／またはＷＴＲＵ５２が無線環境で動作することを可能にする他の任意の機能を実行する。プロセッサ６８は、送受信機７０に結合され、送受信機７０は、送信／受信要素７２に結合される。図１２Ｂは、プロセッサ６８と送受信機７０を別々の構成要素として示しているが、プロセッサ６８と送受信機７０は、電子パッケージまたはチップ内に一緒に統合されることが理解されよう。プロセッサ６８は、アプリケーションレイヤプログラム（例えば、ブラウザ）、ならびに／または無線アクセスレイヤ（ＲＡＮ）プログラムおよび／もしくは通信を実行する。プロセッサ６８は、例えば、アクセスレイヤおよび／またはアプリケーションレイヤなどにおいて、認証、セキュリティ鍵合意などのセキュリティ動作、および／または暗号化動作を実行する。

送信／受信要素７２は、エアインターフェース６６上で、基地局（例えば、基地局６４ａ）に信号を送信し、または基地局から信号を受信するように構成される。例えば、実施形態では、送信／受信要素７２は、ＲＦ信号を送信および／または受信するように構成されたアンテナである。実施形態では、送信／受信要素７２は、例えば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成された放射器／検出器である。さらなる実施形態では、送信／受信要素７２は、ＲＦ信号と光信号の両方を送信および受信するように構成される。送信／受信要素７２は、無線信号の任意の組み合わせを送信および／または受信するように構成されることが理解される。

加えて、図１２Ｂでは、送信／受信要素７２は単一の要素として示されているが、ＷＴＲＵ５２は、任意の数の送信／受信要素７２を含む。より具体的には、ＷＴＲＵ５２は、ＭＩＭＯ技術を利用する。したがって、実施形態では、ＷＴＲＵ５２は、エアインターフェース６６上で無線信号を送信および受信するための２つ以上の送信／受信要素７２（例えば、複数のアンテナ）を含む。

送受信機７０は、送信／受信要素７２によって送信される信号を変調し、送信／受信要素７２によって受信された信号を復調するように構成される。上で言及されたように、ＷＴＲＵ５２は、マルチモード機能を有する。したがって、送受信機７０は、ＷＴＲＵ５２が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にするための、複数の送受信機を含む。

ＷＴＲＵ５２のプロセッサ６８は、スピーカ／マイクロフォン７４、キーパッド７６、および／またはディスプレイ／タッチパッド７８（例えば、液晶表示（ＬＣＤ）ディスプレイユニットもしくは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合され、それらからユーザ入力データを受信する。プロセッサ６８は、スピーカ／マイクロフォン７４、キーパッド７６、および／またはディスプレイ／タッチパッド７８にユーザデータを出力もする。加えて、プロセッサ８１８は、着脱不能メモリ８０および／または着脱可能メモリ８２など、任意のタイプの適切なメモリから情報を入手し、それらにデータを記憶する。着脱不能メモリ８０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、ハードディスク、または他の任意のタイプのメモリ記憶デバイスを含む。着脱可能メモリ８２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、およびセキュアデジタル（ＳＤ）メモリカードなどを含む。他の実施形態では、プロセッサ８１８は、ＷＴＲＵ５２上に物理的に配置されたメモリではなく、サーバまたはホームコンピュータ（図示されず）などの上に配置されたメモリから情報を入手し、それらにデータを記憶する。

プロセッサ６８は、電源８４から電力を受け取り、ＷＴＲＵ５２内の他の構成要素への電力の分配および／または制御を行うように構成される。電源８４は、ＷＴＲＵ５２に給電するための任意の適切なデバイスである。例えば、電源８４は、１または複数の乾電池（例えば、ニッケル−カドミウム（ＮｉＣｄ）、ニッケル−亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、および燃料電池などを含む。

プロセッサ６８は、ＧＰＳチップセット８６にも結合され、ＧＰＳチップセット８６は、ＷＴＲＵ５２の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成される。ＧＰＳチップセット８６からの情報に加えて、またはその代わりに、ＷＴＲＵ５２は、基地局（例えば、基地局６４ａ、６４ｂ）からエアインターフェース８１６上で位置情報を受信し、および／または２つ以上の近くの基地局から受信した信号のタイミングに基づいて、自らの位置を決定する。ＷＴＲＵ５２は、実施形態との整合性を保ちながら、任意の適切な位置決定方法を用いて、位置情報を獲得することが理解される。

プロセッサ６８は、他の周辺機器８８にさらに結合され、他の周辺機器８８は、追加的な特徴、機能、および／または有線もしくは無線接続性を提供する、１または複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含む。例えば、周辺機器８８は、加速度計、ｅコンパス、衛星送受信機、（写真またはビデオ用の）デジタルカメラ、ユニバーサルシリアルバス（ＵＳＢ）ポート、バイブレーションデバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、およびインターネットブラウザなどを含む。

図１２Ｃは、実施形態による、ＲＡＮ５４およびコアネットワーク８０６のシステム図である。上述したように、ＲＡＮ５４は、ＵＴＲＡ無線技術を利用して、エアインターフェース６６上でＷＴＲＵ５２ａ、５２ｂ、５２ｃと通信する。ＲＡＮ５４はコアネットワーク８０６とも通信する。図１２Ｃに示されるように、ＲＡＮ５４は、ノードＢ９０ａ、９０ｂ、９０ｃを含み、ノードＢ９０ａ、９０ｂ、９０ｃは各々、エアインターフェース６６上でＷＴＲＵ５２ａ、５２ｂ、５２ｃと通信するための１または複数の送受信機を含む。ノードＢ９０ａ、９０ｂ、９０ｃは各々、ＲＡＮ５４内の特定のセル（図示されず）に関連付けられる。ＲＡＮ５４は、ＲＮＣ９２ａ、９２ｂも含む。ＲＡＮ５４は、実施形態との整合性を保ちながら、任意の数のノードＢおよびＲＮＣを含むことが理解される。

図１２Ｃに示されるように、ノードＢ９０ａ、９０ｂは、ＲＮＣ９２ａと通信する。加えて、ノードＢ９０ｃは、ＲＮＣ９２ｂと通信する。ノードＢ９０ａ、９０ｂ、９０ｃは、Ｉｕｂインターフェースを介して、それぞれのＲＮＣ９２ａ、９２ｂと通信する。ＲＮＣ９２ａ、９２ｂは、Ｉｕｒインターフェースを介して、互いに通信する。ＲＮＣ９２ａ、９２ｂの各々は、それが接続されたそれぞれのノードＢ９０ａ、９０ｂ、９０ｃを制御するように構成される。加えて、ＲＮＣ９２ａ、９２ｂの各々は、アウタループ電力制御、負荷制御、アドミッションコントロール、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、およびデータ暗号化など、他の機能を実施および／またはサポートするように構成される。

図１２Ｃに示されるコアネットワーク８０６は、メディアゲートウェイ（ＭＧＷ）８４４、モバイル交換センタ（ＭＳＣ）９６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）９８、および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）９９を含む。上記の要素の各々は、コアネットワーク５６の部分として示されているが、これらの要素は、どの１つをとっても、コアネットワークオペレータとは異なるエンティティによって所有および／または運営されることが理解される。

ＲＡＮ５４内のＲＮＣ９２ａは、ＩｕＣＳインターフェースを介して、コアネットワーク５６内のＭＳＣ９６に接続される。ＭＳＣ９６は、ＭＧＷ９４に接続される。ＭＳＣ９６とＭＧＷ９４は、ＰＳＴＮ５８などの回線交換ネットワークへのアクセスをＷＴＲＵ５２ａ、５２ｂ、５２ｃに提供して、ＷＴＲＵ５２ａ、５２ｂ、５２ｃと従来の陸線通信デバイスとの間の通信を容易にする。

ＲＡＮ５４内のＲＮＣ９２ａは、ＩｕＰＳインターフェースを介して、コアネットワーク８０６内のＳＧＳＮ９８にも接続される。ＳＧＳＮ９８は、ＧＧＳＮ９９に接続される。ＳＧＳＮ９８とＧＧＳＮ９９は、インターネット６０などのパケット交換ネットワークへのアクセスをＷＴＲＵ５２ａ、５２ｂ、５２ｃに提供して、ＷＴＲＵ５２ａ、５２ｂ、５２ｃとＩＰ対応デバイスとの間の通信を容易にする。

上述したように、コアネットワーク５６は、ネットワーク６２にも接続され、ネットワーク６２は、他のサービスプロバイダによって所有および／または運営される他の有線または無線ネットワークを含む。

上記説明では、特徴および要素は特定の組み合わせとしたが、各特徴または要素は、単独で使用され、または他の特徴および要素との任意の組み合わせで使用されることができる。加えて、本明細書で説明された実施形態は、専ら例示の目的で提供された。例えば、本明細書では、実施形態は、ＯｐｅｎＩＤおよび／またはＳＳＯ認証エンティティおよび機能を使用して説明したが、類所の実施形態は、他の認証エンティティおよび機能を使用しても実施される。さらに、本明細書で説明された実施形態は、コンピュータまたはプロセッサによって実行される、コンピュータ可読媒体内に含まれる、コンピュータプログラム、ソフトウェア、またはファームウェアで実施される。コンピュータ可読媒体の例は、（有線または無線接続上で送信される）電子信号、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光媒体を含むが、それらに限定されない。ソフトウェアと連携するプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおける使用のための無線周波送受信機を実施するために使用される。

Claims (20)

1. 多要素認証を実行するための方法であって、
   マスタアイデンティティプロバイダ（Ｍ−ＩｄＰ）において、ユーザ機器（ＵＥ）を介するサービスへのアクセスを要求したユーザを認証するように求める要求をサービスプロバイダから受信するステップであって、前記要求は、認証要件のインジケーションと、前記Ｍ−ＩｄＰに関連付けられた前記ユーザのアイデンティティとを含む、ステップと、
   前記認証要件を達成することが可能な複数の認証要素を決定するステップと、
   前記Ｍ−ＩｄＰに関連付けられた前記ユーザアイデンティティに基づいて、前記決定された認証要素のうちの選択されたいくつかと関連付けられた、前記ユーザまたは前記ＵＥのアイデンティティを決定するステップと、
   前記認証要素のうちの前記選択されたいくつかと関連付けられた前記アイデンティティを使用して、各選択要素についての認証を要求するステップと、
   各選択要素についての前記認証の結果を受信し、前記結果を組み合わせて、前記認証要件に従って認証が成功したことを示す認証アサーションを生成するステップと、
   前記認証アサーションを前記サービスプロバイダに送信するステップと
   を備えたことを特徴とする方法。
2. 前記認証要件の前記インジケーションは、必要とされる認証保証レベルを備えたことを特徴とする請求項１に記載の方法。
3. 前記認証要件の前記インジケーションは、必要とされる認証要素の識別を備えたことを特徴とする請求項１に記載の方法。
4. 前記認証アサーションを暗号化するステップをさらに備えたことを特徴とする請求項１に記載の方法。
5. 各選択認証要素についての受信された前記結果は、暗号化されることを特徴とする請求項１に記載の方法。
6. 前記複数の選択認証要素の１つは、前記ユーザが加入契約を結んでいるモバイルネットワークオペレータによって認証される前記ＵＥの証明書を含むことを特徴とする請求項１に記載の方法。
7. 前記Ｍ−ＩｄＰは、前記ユーザが加入契約を結んでいるモバイルネットワークオペレータであることを特徴とする請求項１に記載の方法。
8. 各選択要素についての前記認証の各結果は、異なるアイデンティティプロバイダから受信されることを特徴とする請求項１に記載の方法。
9. 前記異なるアイデンティティプロバイダは、前記サービスプロバイダの方針に従って決定されることを特徴とする請求項８に記載の方法。
10. 前記結果を組み合わせる前記ステップは、前記結果を暗号化して一緒に結合するステップをさらに備えたことを特徴とする請求項１に記載の方法。
11. 各選択認証要素についての前記結果は、対応する保証レベルおよび対応する鮮度レベルを備えたことを特徴とする請求項１に記載の方法。
12. 前記サービスプロバイダは、前記Ｍ−ＩｄＰであることを特徴とする請求項１に記載の方法。
13. 少なくとも１つの選択事実についての少なくとも１つの認証は、前記Ｍ−ＩｄＰにおいて実行されることを特徴とする請求項１に記載の方法。
14. 多要素認証を実行するための方法であって、
    マスタアイデンティティプロバイダ（Ｍ−ＩｄＰ）において、ユーザ機器（ＵＥ）を介するサービスへのアクセスを要求したユーザを認証するように求める要求をサービスプロバイダから受信するステップであって、前記要求は、認証要件のインジケーションと、前記Ｍ−ＩｄＰに関連付けられた前記ユーザのアイデンティティとを含む、該ステップと、
    前記認証要件を達成することが可能な複数の認証要素を決定するステップと、
    選択要素についての認証を実行するステップと、
    前記選択要素についての前記認証の結果を獲得し、前記結果を組み合わせて、前記認証要件に従って認証が成功したことを示す認証アサーションを作成するステップと、
    前記認証アサーションを前記サービスプロバイダに送信するステップと
    を備えたことを特徴とする方法。
15. 前記複数の認証要素を互いに一緒に結合するステップ
    をさらに備えたことを特徴とする請求項１４に記載の方法。
16. 前記必要とされる認証保証レベルを達成することが可能な前記決定された複数の認証要素のうちのいくつかを選択するステップ
    をさらに備えたことを特徴とする請求項１４に記載の方法。
17. 前記選択するステップは、前記ＵＥから受信されたインジケーションに基づくことを特徴とする請求項１６に記載の方法。
18. 実行可能命令を含むメモリと、
    前記メモリと通信するプロセッサであって、前記命令が、前記プロセッサによって実行された場合、前記プロセッサに、
    マスタアイデンティティプロバイダ（Ｍ−ＩｄＰ）において、ユーザ機器（ＵＥ）を介するサービスへのアクセスを要求したユーザを認証するように求める要求をサービスプロバイダから受信することであって、前記要求は、認証要件のインジケーションと、前記Ｍ−ＩｄＰに関連付けられた前記ユーザのアイデンティティとを含む、該受信することと、
    前記認証要件を達成することが可能な複数の認証要素を決定することと、
    前記Ｍ−ＩｄＰに関連付けられた前記ユーザアイデンティティに基づいて、前記決定された認証要素のうちの選択されたいくつかと関連付けられた、前記ユーザまたは前記ＵＥのアイデンティティを決定することと、
    前記認証要素のうちの前記選択されたいくつかと関連付けられた前記アイデンティティを使用して、各選択要素についての認証を要求することと、
    各選択要素についての前記認証の結果を受信し、前記結果を組み合わせて、前記認証要件に従って認証が成功したことを示す認証アサーションを作成することと、
    前記認証アサーションを前記サービスプロバイダに送信することと
    を含む動作を達成させる、前記プロセッサと
    を備えたことを特徴とする装置。
19. 前記複数の選択認証要素の１つは、前記ユーザが加入契約を結んでいるモバイルネットワークオペレータによって認証される前記ＵＥの証明書を含むことを特徴とする請求項１８に記載の装置。
20. 各選択要素についての前記認証の各結果は、異なるアイデンティティプロバイダから受信されることを特徴とする請求項１８に記載の装置。