JP6189953B2 - 無線ユニットのユーザを認証するための方法およびシステム - Google Patents

Description

本発明は、無線ユニットのユーザを認証するための方法およびシステムに関する。

関連出願の相互参照
本出願は、その内容の全体が参照により本明細書に組み込まれる、２０１２年７月１３日に出願された米国特許仮出願第６１／６７１４１９号の利益を主張する。

モバイルデバイス（例えば、モバイルフォン）の認証は、デバイスの汎用集積回路カード（ＵＩＣＣ）内に記憶された共有秘密を利用し得る、チャレンジアンドレスポンスメカニズムをしばしば含む。認証には、ユーザエクスペリエンスをシームレスにするために、ユーザを関与させないものがある。そのような認証は、デバイス内に格納されたＵＩＣＣを所有しているのが正当な所有者であると仮定している。例えば、デバイスが紛失した、または盗まれた場合でも、ネットワークは、デバイス（またはサービス）のユーザ（または加入者）ではなく、利用契約を認証しようとするので、依然としてそれの使用が可能である。無認可ユーザによるデバイスの使用は、認証を必要とする各セッションにユーザを関与させることによって緩和され得る。例えば、セッションは、パスワードおよび／またはｐｉｎの入力をユーザに要求することがある。そのようなセッションは、ユーザの認証エクスペリエンスをしばしば煩わしいものにし、ユーザは、脆弱なパスワードおよび／またはｐｉｎ（例えば、１２３４またはａａａａ）を用いて応答する可能性がある。そのようなｐｉｎおよびパスワードは、覚えやすく、入力しやすいが、パスワードを推測しやすくする。脆弱なパスワードおよびｐｉｎは、ユーザに対するセキュリティを付加することなく、ユーザがサービスまたはアプリケーションにアクセスするための認証負荷をしばしば増加させる。加えて、サービスは、セキュリティリスクの観点からは、取り扱いが必ずしも同等ではなく、したがって、サービスは、異なるレベルのセキュリティを必要とし得る。

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

無線送受信ユニット（ＷＴＲＵ）、これはユーザ機器（ＵＥ）と呼ばれることがあるが限定されるものではない、のユーザを認証するためのシステム、方法、および装置の実施形態が、本明細書で説明される。例えば、ＷＴＲＵは、ユーザ認証の強度の度合いを獲得し、ユーザ認証強度の度合いに基づいて、アサーションを生成し得る。アサーションに基づいて、ＷＴＲＵのユーザは、ＷＴＲＵを介するリソースへのアクセスを受信し得る。アサーションは、ユーザ認証の鮮度の表示を含み得る。ＷＴＲＵは、ＷＴＲＵ（例えば、ユーザが所有するデバイス）認証の強度の度合いをさらに獲得し得、ＷＴＲＵ認証強度の度合いにさらに基づいて、アサーションを生成し得る。加えて、アサーションは、ＷＴＲＵ認証の鮮度の表示を含み得る。アサーションは、複数のユーザ認証ファクタ、または複数のＷＴＲＵ（もしくは他のデバイス）認証ファクタを含み得る。さらに、アサーションは、否定的アサーションであり得、したがって、否定的アサーションに基づいて、受信したアクセスは、制限され得る。

一実施形態では、ユーザは、ＷＴＲＵを介して、アクセス制御エンティティ（ＡＣＥ：ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｅｎｔｉｔｙ）によって制御される、サービスへのアクセスを要求する。ユーザは、ユーザ識別およびアサーション機能（ＵＡＡＦ：ｕｓｅｒ ａｕｔｈｅｎｔｉｃａｔｏｒ ａｎｄ ａｓｓｅｒｔｉｏｎ ｆｕｎｃｔｉｏｎ）を用いて認証され、結果が生成される。ユーザ認証結果と、ユーザ認証に関連付けられたユーザ保証レベルとを含む、ユーザアサーションがＡＣＥに提供される。ユーザアサーションは、ユーザ認証に対応するユーザ鮮度レベルをさらに含み得る。ＷＴＲＵは、デバイス識別およびアサーション機能（ＤＡＡＦ：ｄｅｖｉｃｅ ａｕｔｈｅｎｔｉｃａｔｏｒ ａｎｄ ａｓｓｅｒｔｉｏｎ ｆｕｎｃｔｉｏｎ）を用いて認証され、関連付けられたデバイス認証結果が生成される。デバイス認証結果と、デバイス認証に関連付けられたデバイス保証レベルとを含む、デバイスアサーションがＡＣＥに提供され得る。デバイスアサーションは、デバイス認証に対応するデバイス鮮度レベルをさらに含み得る。アサーションは、一緒に結合されて、有界アサーションを生成し得る。有界アサーションは、ユーザが、ＷＴＲＵを介して、要求したサービスへのアクセスを受信するように、ＡＣＥに提供され得る。

別の例示的な実施形態では、アサーションは、否定的アサーションを含み得る。否定的アサーションは、認証が失敗したことを示し得る。例えば、否定的ユーザアサーションは、ユーザとＵＡＡＦの間の認証の結果が否定的であることを示し得る。否定的アサーションに応答して、ユーザおよび／またはＷＴＲＵは、サービスへの制限付きアクセス、またはサービスへのアクセス不可を受信し得る。制限付きアクセスは、記憶された保証レベルおよび鮮度レベルに基づいて承諾され得る。制限付きアクセスは、アクセス不可よりも勝るが、無制限アクセスよりは劣るアクセスのことを指すことがある。肯定的アサーションは、認証が成功したことを示し得る。例えば、肯定的ユーザアサーションは、ユーザがＵＡＡＦを用いて認証されたことを示し得、肯定的結果が生成される。ユーザとＵＡＡＦの間の認証の結果は、複数の認証ファクタに基づき得る。例えば、認証ファクタは、ユーザの知識、ユーザの１もしくは複数の生理学的特徴、および／またはユーザの１もしくは複数の行動特徴を示す情報を含み得る。認証ファクタは、ＵＥの特徴も含み得る。

また別の例示的な実施形態では、ユーザおよび／もしくはＵＥは、保証レベルおよび／もしくは鮮度レベルが許容可能範囲内にない場合、サービスへの制限付きアクセスを受信し得、またはユーザおよび／もしくはＷＴＲＵは、鮮度レベルが許容不可である（例えば、資格証明書が満了している可能性がある）ので、再認証され得る。各レベルの許容可能範囲（または閾値）は、サービスを提供するサービスプロバイダによって決定される１または複数のポリシーに基づき得る。サービスプロバイダは、ＡＣＥによって制御され得、ユーザ／ＷＴＲＵにサービスを提供し得る。別の例示的な実施形態では、ＵＡＡＦとＤＡＡＦは、単一のＡＡＦとして機能し得る。ＵＡＡＦとＤＡＡＦは、互いに同一場所に配置され得、または離して配置され得る。例えば、ＵＡＡＦは、ＷＴＲＵ上に存在し得、ＤＡＡＦは、ネットワークのサーバ上の同一場所にＡＣＥとともに配置され得る。ＡＡＦは、ＵＡＡＦから受信されたユーザ認証結果とＤＡＡＦから受信されたデバイス認証結果とを組み合わせた、単一のアサーションをＡＣＥに送信し得る。別の例示的な実施形態では、ＡＡＦは、ＵＡＡＦおよびＤＡＡＦから離れて存在し得、ユーザおよびデバイスの識別情報を管理およびマッピングし、ユーザ認証およびデバイス認証を実行するために、それぞれ、ＵＡＡＦおよびＤＡＡＦを起動する。ＡＡＦは、マスタ識別情報プロバイダ（ＩｄＰ）に類似する役割を果たすように機能し得、それは、様々な識別情報プロバイダからの認証結果を組み合わせ得るＩｄＰに相当する。したがって、ＡＡＦは、ＵＡＡＦおよびＤＡＡＦから受信された認証の結果を組み合わせ、対応する保証レベルおよび鮮度レベルとともに単一のアサーションをＡＣＥに提供し得る。

より詳細な理解は、添付の図面を併用する、例として与えられた、以下の説明から得られ得る。
例示的な実施形態による、マッチオンサーバ（ｍａｔｃｈ−ｏｎ−ｓｅｒｖｅｒ）認証を実施するシステムのブロック図である。 例示的な実施形態による、マッチオンサーバベースの認証とマッチオンデバイス（ｍａｔｃｈ−ｏｎ−ｄｅｖｉｃｅ）ベースの認証の組み合わせを実施するシステムのブロック図である。 例示的な実施形態による、ユーザおよびデバイス認証を必要とし得るサービスにアクセスするためのフロー図である。 別の例示的な実施形態による、ユーザおよびデバイス認証を必要とし得るサービスにアクセスするための別のフロー図である。 例示的な実施形態による、汎用ブートストラップアーキテクチャ（ＧＢＡ）認証およびアサーションを用いてマッチオンサーバ実施を実施するシステムのブロック図である。 別の例示的な実施形態による、図４に示されたＧＢＡ認証およびアサーションの説明を用いてマッチオンデバイス実施を実施するシステムのブロック図である。 例示的な実施形態による、ＧＢＡとローカルユーザ認証の組み合わせを説明するフロー図である。 例示的な実施形態による、ユーザ認証資格証明書をＧＢＡと結合するためのフロー図である。 １または複数の開示される実施形態が実施され得る例示的な通信システムのシステム図である。 図８Ａにおいて説明される通信システム内で使用され得る例示的な無線送受信ユニット（ＷＴＲＵ）のシステム図である。 図８Ａにおいて説明される通信システム内で使用され得る例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。

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

本明細書で説明されるように、認証または再認証のために、セキュリティアソシエーション（ｓｅｃｕｒｉｔｙ ａｓｓｏｃｉａｔｉｏｎ）の特徴が、サービスプロバイダ（ＳＰ）とも呼ばれ得る、サービス提供エンティティに提供され得る。そのような特徴は、ローカルに決定されるプロセスおよび／またはネットワークに支援されるプロセスを使用することによって提供され得る。実施形態では、ユーザ機器（ＵＥ）がＳＰに再認証されるために、かつ／またはＳＰとの間で鍵を変更するために、セキュリティアソシエーションの現存する特徴または満了した特徴が利用され得る。ユーザ機器（ＵＥ）という用語は、本明細書で使用される場合、限定することなく、任意の適切な無線送受信ユニット（ＷＴＲＵ）、またはネットワークサービスに接続されるデバイスのことを指し得る。そのような再認証または鍵変更は、ＳＰによって提供されるサービスへの制限付きアクセスまたは無制限アクセスをＵＥに提供し得る。サービスは、限定することなく、リソースと呼ばれることもあり、したがって、ＳＰは、リソースプロバイダと呼ばれることもある。

本明細書で説明される例示的な実施形態では、セキュリティアソシエーションを説明する、パラメータまたはセキュリティ属性と呼ばれることもある特徴が、生成され、記憶され、取り出され、通信される。セキュリティアソシエーションは、ネットワークエンティティの間の安全な通信をサポートするために、少なくとも２つのネットワークエンティティの間で共有されるセキュリティ属性のことを指し得る。例えば、ＵＥとＳＰ（例えば、ウェブサイト）は、互いの間に特定のセキュリティアソシエーションを有し得る。セキュリティアソシエーションの例示的なパラメータは、限定することなく、セキュリティアソシエーションの鮮度を示すパラメータ、セキュリティアソシエーションの保証レベルを示すパラメータ、セキュリティアソシエーションを生成する際に使用される認証ファクタを示すパラメータ、ならびにセキュリティアソシエーションの記憶および／または取り出しを説明するパラメータを含む。本明細書で説明されるように、特徴（パラメータ）は、導出され得、かつ／またはＵＥ上でローカルに記憶され得る。例示的な実施形態では、特徴（パラメータ）の導出は、ネットワークによって支援される。本明細書で説明される別の例示的な実施形態では、（例えば、サービスへの）制限付きアクセスを提供するために使用される否定的アサーションは、保証レベルおよび／または鮮度レベルに基づき得る。

本明細書で使用される場合、保証レベルは、認証強度の度合いのことを指し得る。例えば、保証レベルは、ユーザ認証および／またはデバイス認証に対応し得、保証レベルは、数々の認証ファクタによって少なくとも部分的に決定され得る。鮮度レベルは、認証鮮度の表示のことを指し得る。例えば、鮮度レベルは、認証が発生した時間に基づき得る。鮮度レベルは、ユーザ認証および／またはデバイス認証に対応し得る。

例として、パスワードを覚えたくないまたは入力したくないユーザは、ブラウザベースのアプリケーション認証のために、パスワード（例えば、ユーザ名パスワード）をブラウザに記憶し得る。そのような記憶されたパスワードは、ユーザではなく、ブラウザを認証し得る。シングルサインオン（ＳＳＯ）実施では、識別情報プロバイダ（ＩｄＰ）サービスが、利用可能でない場合、またはリソースプロバイダ側もしくはユーザ側から到達可能でない場合、（１または複数の）サービスへのユーザのアクセスは縮小され得る。

本明細書で説明される様々な実施形態では、１または複数の識別情報プロバイダ（ＩｄＰ）は、（例えば、ユーザが何を知っており、ユーザが何を有しており、かつ／またはユーザが何であるかを使用して）ユーザを認証するために必要とされる、識別およびアサーション機能（ＡＡＦ）を実行し得る。サービスへのアクセスを承諾する旨のサービスプロバイダの決定は、ＳＰによって管理されるポリシーに基づき得る。そのようなＳＰは、例えば、ネットワークアプリケーション機能（ＮＡＦ）、またはリライングパーティ（ＲＰ）／クライアントなどの、アクセス制御エンティティ（ＡＣＥ）によって制御され得る。サービスプロバイダは、認証の複数のファクタ、および／または認証の可能なファクタのサブセットを必要とし得る。

例示的な実施形態では、ユーザおよび／またはＵＥは、ユーザおよび／またはＵＥ認証についての何らかの特徴（例えば、保証レベル、鮮度レベル、または結果のセキュリティアソシエーションなど）を、ＡＣＥに提供するように要求され得る。そのような実施形態は、例えば、ユーザおよび／またはＵＥが、完全な認証を経なくてよいことがあり、適切な鮮度レベルおよび／または保証レベルを含む、先に実行された認証をアサートし得るので、柔軟性を提供し得る。

本明細書で説明されるのは、識別情報をアサートする認証プロトコルを実行する識別およびアサーション機能（ＡＡＦ）である。ＡＡＦは、また、認証プロトコルに対応する、保証レベルおよび鮮度レベルを、（例えば、ＡＣＥに）提供し得る。例示的な実施形態によれば、ＡＡＦは、限定することなく、ユーザが知り得る情報（例えば、知識ベースの認証）、ユーザの生理学的特徴、ユーザの行動特徴、およびユーザの所有物（例えば、デバイス、ＵＥ、ハードウェアトークン、またはＵＩＣＣなど）などのファクタを使用して、認証を行うことを可能にする。ＡＣＥがサービスへのユーザおよび／またはＵＥのアクセスを承諾するために、上述の認証ファクタまたはそれらの組み合わせが実行され得、各認証に関連付けられた保証レベルおよび鮮度レベルが、ＡＡＦによってＡＣＥに伝達され得る。

認証およびアサーションは、デバイスの能力またはサービングネットワークの能力に基づいて、異なって実施され得る。例えば、「マッチオンサーバ」実施および「マッチオンデバイス」実施が、本明細書で説明される。他の実施形態は、「マッチオンデバイス」実施と「マッチオンサーバ」実施の組み合わせに基づく。マッチオンサーバは、ウェブベースの認証またはリモート認証が実施される方法のことを指す。ウェブサーバに対する認証およびメールサーバに対する認証は、マッチオンサーバ実施の例である。

マッチオンサーバ実施を実施する例示的な実施形態では、ＡＡＦは、ネットワーク上（例えば、サーバ上）に配置される。マッチオンデバイス実施を実施する実施形態では、ＡＡＦは、無線送受信ユニット（ＷＴＲＵ）またはＵＥと呼ばれることがある、デバイス上にローカルに配置される。別の実施形態では、ローカル認証機能は、ネットワークサーバエンティティによって準備供給されるネットワークサーバベースの機能のためのプロキシであり得る。例示的な実施形態では、ＡＡＦによる認証が成功した場合、ＡＡＦは、ＡＣＥに対して、エンティティ（例えば、ユーザまたはデバイス）の識別情報をアサートする。ＡＡＦは、認証に対応する保証レベルおよび／または鮮度レベルを、（例えば、ＡＣＥに）提供し得る。認証が成功しなかった場合、例えば、認証不成功の結果が、ＡＣＥに伝達され得る。ＡＣＥは、そのような結果を使用して、エンティティ（例えば、ユーザまたはデバイス）による成功しなかった試みを記録し得、そのエンティティからの将来のサービス要求は、記録された成功しなかった試みに基づき得る。

図１は、例示的な実施形態による、マッチオンサーバ認証を実施するシステム１００のブロック図である。図１を参照すると、サービスへのアクセスをＡＣＥ１０６に要求するために、ユーザデバイス１０２がユーザ１０４によって使用され得る。ＡＣＥ１０６は、サービスアクセスが承諾される前に、ユーザ１０４およびデバイス１０２が認証されることを要求し得る。

説明される実施形態によれば、ＡＣＥ１０６に対してユーザの識別情報を認証およびアサートするために、ユーザ識別およびアサーション機能（Ｕ＿ＡＡＦ）１０８が使用される。例えば、１１０を参照すると、ユーザ１０４は、デバイス１０２によってホストされるユーザ資格証明書入力フォーム１１２にユーザ名／パスワードを入力する。１１４において、ユーザ１０４は、ユーザ資格証明書入力フォーム１１２に入力された資格証明書に基づいて、Ｕ＿ＡＡＦ１０８によって認証される。１１６において、ＡＣＥ１０６に対して、ユーザ認証がアサートされる。加えて、１１６において、ユーザ認証に対応する鮮度レベルおよび／または保証レベルが、Ｕ＿ＡＡＦ１０８を介してＡＣＥ１０６に伝達され得る。例示的な実施形態では、Ｕ＿ＡＡＦ１０８は、例えば、ＯｐｅｎＩＤ識別情報プロバイダ（ＯＰ）などのＩｄＰによって実施されるが、望ましければ、Ｕ＿ＡＡＦは他のエンティティによって実施され得ることが理解されよう。例えば、Ｕ＿ＡＡＦ１０８は、例えば、ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍ、またはｗｗｗ．ｆａｃｅｂｏｏｋ．ｃｏｍなどのＯＰ内のエンティティによって実施され得る。別の例示的な実施形態では、モバイルネットワークオペレータ（ＭＮＯ）（例えば、ＡＴ＆Ｔ、Ｄｅｕｔｓｃｈｅ Ｔｅｌｅｃｏｍなど）が、ＩｄＰとして機能し、Ｕ＿ＡＡＦ１０８をホストする。

説明される実施形態によれば、ＡＣＥ１０６に対してデバイス１０２の識別情報を認証およびアサートするために、デバイス識別およびアサーション機能（Ｄ＿ＡＡＦ）１１８が使用され得る。例えば、１２０を参照すると、デバイス１０２は、１または複数のデバイス／ＵＩＣＣ資格証明書１２２を使用して、Ｄ＿ＡＡＦ１１８を用いて認証される。説明されるように、デバイス１０２は、汎用ブートストラップアーキテクチャ（ＧＢＡ）プロトコルまたは証明書を使用して認証されるが、望ましければ、デバイス１０２は、他の認証プロトコルを使用して認証され得ることが理解されよう。１２４において、ＡＣＥ１０６に対して、デバイス認証がアサートされる。加えて、１２４において、デバイス認証に対応する保証レベルおよび／または鮮度レベルが、Ｄ＿ＡＡＦ１１８を介してＡＣＥ１０６に伝達され得る。汎用ブートストラップアーキテクチャ（ＧＢＡ）の一部として定義される、ブートストラップサーバ機能（ＢＳＦ）またはネットワークアプリケーション機能（ＮＡＦ）が、Ｄ＿ＡＡＦ１１８を実施し得るが、実施形態はそのように限定されないことが理解されよう。例示的な実施形態では、Ｄ＿ＡＡＦ１１８は、オペレータネットワーク（例えば、ＡＴ＆Ｔ、Ｖｅｒｉｚｏｎ、またはＤｅｕｔｓｃｈｅ Ｔｅｌｅｃｏｍなど）内に配置される。別の例示的な実施形態では、デバイスＩｄＰ（例えば、Ａｐｐｌｅ）が、Ｄ＿ＡＡＦ１１８をホストおよび提供し、デバイス１０２（例えば、ｉＰｈｏｎｅ）の識別情報を保証する。例えば、デバイスＩｄＰとデバイス１０２の間、およびデバイスＩｄＰとＡＣＥ１０６の間に信用が存在する場合、デバイスＩｄＰは、Ｄ＿ＡＡＦ１１８をホストおよび提供し得る。

単一のエンティティが、Ｕ＿ＡＡＦ１０８およびＤ＿ＡＡＦ１１８を実施し得、したがって、そのエンティティは、識別およびアサーション機能（ＡＡＦ）と呼ばれることがある。ＡＡＦは、複数の認証（例えば、知識ベース、デバイスベース、生理学的、または行動など）を実行し得る。例示的な実施形態によれば、ＡＡＦは、Ｕ＿ＡＡＦ１０８およびＤ＿ＡＡＦ１１８を実行し、ＡＡＦは、機能を一緒に結合して、単一のアサーション、保証レベル、および鮮度レベルを提供する。本明細書で説明される例示的な実施形態では、Ｕ＿ＡＡＦ１０８およびＤ＿ＡＡＦ１１８は、互いに同じネットワークの一部である。代替的実施形態では、Ｕ＿ＡＡＦ１０８は、Ｄ＿ＡＡＦ１１８を含むネットワークとは異なるネットワークの一部である。ＡＡＦは、ＵＡＡＦから受信されたユーザ認証結果とＤＡＡＦから受信されたデバイス認証結果の両方を組み合わせた単一のアサーションを、ＡＣＥに送信し得る。別の実施形態では、ＡＡＦは、ＵＡＡＦおよびＤＡＡＦから離れて存在し、ユーザ識別情報およびデバイス識別情報を管理およびマッピングし、ユーザ認証およびデバイス認証を実行するために、それぞれ、ＵＡＡＦおよびＤＡＡＦを起動する。ＡＡＦは、マスタ識別情報プロバイダ（ＩｄＰ）のように機能し得る。例えば、ＡＡＦは、ＵＡＡＦおよびＤＡＡＦから受信された認証の結果を組み合わせて、単一のアサーションをＡＣＥに提供し得る。アサーションは、関連付けられた保証レベルおよび鮮度レベルを提供され得る。別の例示的な実施形態では、Ｕ＿ＡＡＦ１０８およびＤ＿ＡＡＦ１１８は、同じエンティティ内に配置される。さらに、Ｕ＿ＡＡＦ１０８およびＤ＿ＡＡＦ１１８は、ＡＣＥ１０６と同じネットワークの一部であり得る。本明細書で説明される様々な例示的な実施形態では、Ｕ＿ＡＡＦ１０８およびＤ＿ＡＡＦ１１８は、ＡＣＥ１０６によって信用されたエンティティである。代替的実施形態では、ＡＡＦは、ＡＣＥ１０６によって信用された唯一のエンティティであり得、一方、ＡＡＦは、Ｕ＿ＡＡＦ１０８およびＤ＿ＡＡＦ１１８と信用関係を有する。ＡＡＦとＡＣＥ１０６の間で通信される、図１の１１６および１２４におけるアサーションメッセージなどのアサーションメッセージは、保護され得、または、セキュリティ保護なしに送信され得る。

図２は、例示的な実施形態による、マッチオンサーバベースの認証とマッチオンデバイスベースの認証の組み合わせを実施するシステム２００のブロック図である。システム２００がシステム１００に類似していることを示すため、図２の参照番号は、図１のものが踏襲されるが、システム２００のＵ＿ＡＡＦ１０８Ａは、図１に示されるシステム１００においてそうであるようにネットワーク上に存在する代わりに、デバイス１０２上に存在する。図２に示される説明的な実施形態（システム２００）を参照すると、Ｄ＿ＡＡＦ１１８は、ネットワーク上に存在する。１１４Ａにおいて、Ｕ＿ＡＡＦ１０８Ａは、ユーザ１０４を認証するローカル認証を実行する。ユーザ１０４は、制限することなく、ユーザ名および／もしくはパスワード、ユーザの生理学的特徴、またはユーザの行動特徴など、様々なファクタに基づいて認証され得る。１１６において、１１４Ａにおいて実行されたユーザ認証の結果が、Ｕ＿ＡＡＦ１０８Ａによってアサートされる。結果は、関連付けられた鮮度レベルおよび保証レベルとともにアサートされ得る。Ｕ＿ＡＡＦ１０８Ａは、ネットワークベースのＡＡＦのためのプロキシ機能として実施され得、Ｕ＿ＡＡＦ１０８ＡがネットワークベースのＡＡＦの代わりにローカル認証機能として行為するように、プロビジョニングプロセスを使用してＵＥ１０２上で準備供給され得る。説明される実施形態によれば、システム２００の１２４において、Ｄ＿ＡＡＦ１１８は、Ｕ＿ＡＡＦアサーションとは独立に、デバイス認証結果を、それらの関連付けられた保証レベルおよび鮮度レベルとともにアサートする。あるいは、ＡＡＦは、Ｕ＿ＡＡＦおよびＤ＿ＡＡＦから受信された結果を組み合わせ、単一のアサーションを、対応する保証レベルおよび鮮度レベルとともに、ＡＣＥ１０６に提供し得る。

アサーションは、肯定的アサーションまたは否定的アサーションであり得る。肯定的アサーションは、エンティティの識別情報を確認および保証するアサーションのことを指し得る。肯定的アサーションは、識別情報の認証が成功した（肯定的である）ことを示唆し得る。そのような識別情報は、ユーザ、デバイス、またはＵＩＣＣなどを表し得る。肯定的アサーションは、マスタセッション鍵（ＭＳＫ）を取り出すために使用される１または複数のトークンを搬送し得る。あるいは、アサーション自体が、ＭＳＫを搬送し得る。例えば、トークンは、ＭＳＫを含み得る。Ｕ＿ＡＡＦ１０８から肯定的アサーションが受信された場合、提供された鍵は、図１および図２に示されるＭＳＫ＿ｕ１２６のように、ユーザマスタセッション鍵（ＭＳＫ＿ｕ）と呼ばれ得る。肯定的アサーションを用いるデバイス認証では、提供された鍵は、図１および図２に示されるＭＳＫ＿ｄ１２８のように、デバイスマスタセッション鍵（ＭＳＫ＿ｄ）と呼ばれ得る。以下でさらに説明されるように、ユーザ認証およびデバイス認証は、結合されて、認証結合鍵（ＡＢＫ：ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｂｉｎｄｉｎｇ ｋｅｙ）を生成し得る。例えば、図１および図２を引き続き参照すると、ＭＳＫ＿ｕ１２６とＭＳＫ＿ｄ１２８は、結合されて、ＡＢＫ１３０を生成する。ＡＢＫ１３０に基づいて、１３２において、ユーザ１０４およびＵＥ１０２は、サービスへのアクセスを承諾され、それを受信する。

ＡＢＫ１３０は、ＭＳＫ＿ｄ１２８およびＭＳＫ＿ｕ１２６の生成に依存するプロセスを介して生成され得、したがって、ＡＢＫ１３０は、ＭＳＫ＿ｄ１２８およびＭＳＫ＿ｕ１２６に結合され得る。例えば、ＭＳＫ＿ｄ１２８を生成する場合、Ｄ＿ＡＡＦ１１８を用いて実行されるプロトコルにおいて、ノンスが使用され得る。Ｕ＿ＡＡＦ１０８を用いて実行されるプロトコルにおいても、同じノンスが使用され得る。ＡＢＫは、ＭＳＫ＿ｄおよびＭＳＫ＿ｕの両方を入力として取得する鍵導出関数から導出され得る。

例示的な実施形態では、認証が成功した場合、それぞれのＡＡＦが、ＡＣＥ１０６に対して認証結果をアサートする。アサーションは、認証の強度を定量化するために、様々な保証レベルを含み得る。例えば、ユーザ認証保証レベルを生成する際、パスワードベースの認証は、バイオメトリックス指紋ベースの認証よりも当然低い保証レベルであり得る。認証結果は、認証保証レベル、鮮度レベル（例えば、認証がいつ実行されたかを示す時間値）、および／または他のパラメータを含み得る、アサーショントークン内にカプセル化され得る。アサーショントークンは、ＡＣＥ１０６がアサーショントークン内の情報の真正性を検証し得るように、それぞれのＡＡＦによって署名され得る。別の例示的な実施形態では、Ｕ＿ＡＡＦ１０８およびＤ＿ＡＡＦ１１８は、ＡＡＦと呼ばれることがある、同じエンティティ上で同一場所に配置され、１つのアサーショントークンが生成され、ＡＡＦがＡＢＫ１３０を生成する。したがって、ＡＣＥ１０６は、アサーショントークン内の情報の検証が成功した場合、ユーザ１０４に対するサービスを準備供給し得る。ＡＢＫ１３０は、ＡＣＥ１０６によってＡＡＦから取り出され得る。あるいは、ＡＢＫ１３０は、ＭＳＫ＿ｄ１２８およびＭＳＫ＿ｕ１２６から生成され得る。１３２において、ＡＢＫ１３０は、ＵＥ１０２とＡＣＥ１０６の間の通信を安全にするために使用される。ＡＡＦがＵＥ１０２上またはネットワーク上に配置され得ることが理解されよう。

否定的アサーションは、エンティティの認証が失敗したことを伝達するアサーションのことを指し得る。否定的アサーションは、サービスへの制限付きアクセスまたはアクセス不可をそのようなエンティティに提供するために使用され得る。否定的アサーションは、例えば、エンティティによるサービスへのアクセスを求める将来の要求、および／またはエンティティによる将来の認証の試みが、記録された情報に基づき得るように、記録され得る。例えば、認証失敗の後、制限付きアクセスをユーザ／ＵＥに提供するために、記録された（記憶された）保証レベルおよび鮮度レベルが使用され得る。否定的アサーションは、その関連付けられた保証レベル値および／または鮮度レベル値を含む、以前の肯定的アサーションを含み得る。

電子ユーザ認証との関連では、保証は、ユーザがその主張通りユーザ当人であることに対する信頼の度合いとして定義され得る。いくつかの実施では、ユーザの主張は、ユーザに対して発行される資格証明書において立証される。したがって、ユーザ保証レベルは、資格証明書を使用する個人が、資格証明書が発行された個人であることに対する信頼の度合いに基づき得る。本明細書で説明される実施形態によれば、保証の度合いは、「保証レベル」を決定する様々なファクタに基づく。保証レベルは、実行されるべき認証プロトコルに基づいて、アサート機関からＡＣＥに対して通信され得る。あるいは、ＡＣＥは、ＳＰが提供するサービスにアクセスするために必要とされる最小認証保証レベルを指定し得る。認証に関連付けられる保証レベルは、例えば、認証の特徴（例えば、パスワードベースの認証が実行されたか、バイオメトリックベースの認証が実行されたか、それともユーザ認証および／またはデバイス認証の組み合わせが実行されたか）、認証資格証明書および／またはアサーションがどのように伝達されるか、認証資格証明書の記憶およびアクセスの特徴、登録の特徴（例えば、登録がどのように行われたか、登録が脆弱／安全でないプロトコルを使用したか、それとも強力／安全なプロトコルを使用したか、登録が認証の複数のファクタを使用したかなど）、ならびに認証に関与するエンティティのセキュリティに対する態度など、様々な変数に基づき得る。保証レベルを決定する助けとなり得る、認証変数とも呼ばれ得る、認証の特徴は、例えば、限定することなく、どの認証プロトコルが実施されたか（例えば、ＧＢＡ＿ＵはＧＢＡ＿ＭＥよりも高い保証値を有し得、ＧＢＡ＿ＭＥはＧＢＡ＿Ｄｉｇｅｓｔよりも高い保証値を有し得る）、使用されたアルゴリズムの強度、鍵の長さ、鍵が共有鍵であったか、それとも公開鍵であったか、認証が完全前方秘匿性（ＰＦＳ）および／または完全後方秘匿性（ＰＢＳ）を提供したかどうか、認証において使用された認証ファクタ（例えば、パスワードまたはバイオメトリックスなど）、ならびに再認証が認証プロトコルを危険にさらし得るかどうかを含む。例えば、最初は強力な認証プロトコルが使用されるが、再認証プロトコルが初期認証プロトコルよりも安全性が小さい場合、再認証は、認証プロトコルを危険にさらし得る。

例示的な実施形態では、認証資格証明書および／またはアサーションが通信される方法は、保証レベルに影響する。したがって、保証レベルは、認証アサーションまたは認証資格証明書がどのように送信および受信されるかに基づき得る。例えば、保証レベルは、資格証明書および／もしくはアサーションを通信するために使用されるメッセージングおよびプロトコル、メッセージングが機密性および完全性のために保護されるかどうか、通信の保護のレイヤ（例えば、アプリケーションレイヤおよび他のより低いレイヤの保護）、任意のネゴシエーションおよび鍵生成プロセスのためのセキュリティ保護のレベル、または通信プロトコルが中間者（ＭＩＴＭ）攻撃に対して安全であるかどうかなどに基づき得る。

例示的な実施形態では、保証レベルは、認証資格証明書が記憶およびアクセスされる方法に依存する。したがって、保証レベルは、認証資格証明書の記憶およびアクセスの特徴に基づき得る。例えば、保証レベルは、認証資格証明書が専用ハードウェア内に記憶されるかどうか、資格証明書へのアクセスが認可されたプロセスを必要とするかどうか（例えば、資格証明書にアクセスするために、どの規格が使用されるか）、共有秘密鍵もしくはプライベート鍵が安全な領域に記憶されるかどうか、または危険にさらされたデバイス（例えば、ＵＥ）が共有秘密鍵もしくはプライベート鍵にアクセスするかどうか、および／もしくはそれらを暴露するかどうかなどによって少なくとも部分的に決定され得る。資格証明書が専用ハードウェア内に記憶される例示的な実施形態では、保証レベルは、専用ハードウェアが準拠するスマートカード規格に基づく。

認証の様々な形態（実施）と保証レベルの間の関連付けは、ユーザデバイス上に（例えば、マッチオンデバイス）、またはサーバ上のＡＡＦ上に（例えば、マッチオンサーバ）記憶され得る。保証レベルは、定量値または定性値として通信され得る。そのような値は、上述された認証変数を加重方式で組み合わせ得る。例示的な実施形態では、最も高いレベルの保証（例えば、最強の認証）は、直交認証の様々なファクタとして、「ユーザが誰であるか」、「ユーザが何を有するか」、および「ユーザが何を知っているか」についての最強の形態を組み合わせることによって達成され得る。例えば、強力な高エントロピパスワード、ユーザが所有する電話内のＵＩＣＣ、およびバイオメトリックファクタを使用して、ユーザおよび電話が認証される場合、上述された各認証ファクタの重み（例えば、強度）は、高くなり得、それが、高い保証レベルをもたらす。例えば、各認証ファクタの重みは、互いに等しくし得る。別の例として、ユーザのパスワードがいくぶん脆弱である場合、パスワード認証の重みが、全体的な保証レベルを引き下げ得る。また別の例として、試みられたサービスへのアクセスに対応する時間のファクタ（鮮度）、およびアクセスがどこから試みられているかについての場所のファクタの追加は、より高い信頼の度合いをもたらし得、全体的な保証レベルを引き上げ得る。

例示的な実施形態では、全体的な保証レベルは、様々な認証ファクタによって達成される最低の保証レベルによって決定される。別の例示的な実施形態では、保証レベルが所定の閾値を下回る場合、制限付きアクセスが、ユーザおよび／またはデバイスに提供される。バイオメトリックスを使用する認証では、例えば、使用されるバイオメトリックスのタイプおよび／もしくは関連するテンプレートデータ、環境ファクタ、ならびに／またはセンサデバイスにおける誤差が、認証の保証レベルに影響し得る。新しい認証が可能ではない例示的な実施形態では、新しい認証アサーションまたは鍵材料を導出するために、現存するまたは以前のセキュリティアソシエーションの特徴が使用され得る。そのような鍵材料は、制限された能力を有し得る。

例示的な実施形態によれば、認証鮮度レベルは、タイムスタンプを含み、伝達し得る。例えば、セキュリティアソシエーションのエイジを推測するために、タイムスタンプが使用され得る。あるいは、セキュリティアソシエーションのエイジは、ＡＡＦからＡＣＥに直接伝達され得る。鮮度レベルは、ユーザデバイス上に（例えば、マッチオンデバイス実施）、またはサーバ上のＡＡＦ上に（例えば、マッチオンサーバ実施）記憶され得る。例えば、保証レベルおよび鮮度レベルは、認証履歴を確立するために、ある期間にわたって、（例えば、ＡＣＥ、サーバ、ＡＡＦ、またはＵＥなどによって）記憶され得る。例示的な実施形態では、記憶されたレベルは満了し得、その時点で、再認証が行われ得る。例えば、ユーザ／ＵＥは、再認証されて、新しい鮮度レベルになり得る。記憶された保証レベルおよび鮮度レベルは、例えば、認証が失敗した場合に、ユーザおよび／またはＵＥにサービスへの制限付きアクセスまたはアクセス不可を提供するために再使用され得る。制限付きアクセスは、サービスへの無制限アクセスまたは完全アクセスよりも狭い任意のアクセスのことを指し得る。例えば、サービスへの制限付きアクセスは、認証が過去のある時点で成功したことを、サービスプロバイダが（例えば、記憶された情報を介して）知っているために承諾され得る。例として、サービスプロバイダがバンキングウェブサイトである場合、制限付きアクセスは、ユーザが取引を行わずに口座を見ることができることを意味し得る。したがって、上述されたバンキングの例では、無制限アクセスまたは完全アクセスは、ユーザが口座を見、取引を行うことができることを意味し得る。制限付きアクセスは、提供されているサービスに依存し得る様々なレベルのアクセスのことを指し得る。例えば、サービスアクセスは、低い保証レベルが低リスクサービスへのアクセスを可能にするような、リスクベースであり得る。バンキングの例では、低リスクサービスは、高々１０ドルの支払いのための認証を含み得るが、高リスクサービスは、１０００ドルの支払いのための認証を含み得る。したがって、サービスアクセスは、保証レベルの範囲に基づいて格付けされ得、最高レベルの保証が達成される場合は、完全アクセスが可能にされ、一方、達成される保証が最低レベルの場合は、可能なサービスは最小に抑えられ（またはサービス不可にされ）る。

例示的な実施形態では、ＡＣＥに伝達される様々な認証の結果および／またはアサーションは、一緒に結合され得る。例えば、結果またはアサーションの結合は、サービスへのアクセスを、特定のデバイスを使用する特定のユーザに制限し得る。結合は、例えば、結合鍵へのアクセスがＡＣＥならびにユーザおよび／またはユーザデバイスに制限されるように、暗号結合であり得る。認証結合鍵（ＡＢＫ）は、認証（ＭＳＫ＿ｕ）およびデバイス認証（ＭＳＫ＿ｄ）の暗号化入力もしくは非暗号化入力または暗号化出力もしくは非暗号化出力を入力として取得し得る、鍵導出関数（ＫＤＦ）に基づいて導出され得る。例えば、結合鍵は、ＡＢＫ＝ＫＤＦ（ＭＳＫ＿ｕ，ＭＳＫ＿ｄ，ランダムデータ，．．．）のように計算され得る。

複数の認証が、一緒に結合され得る。結合は、ユーザ（知識ベース）認証とデバイス認証の結合に限定されない。例えば、ユーザの生理学的特徴（例えば、出力：ＭＳＫ＿ｐ）および行動特徴（例えば、ＭＳＫ＿ｂ）に基づいた認証は、知識ベース認証およびデバイス認証の結果と組み合わされ得る。そのような認証結合鍵は、ＡＢＫ＝ＫＤＦ（ＭＳＫ＿ｕ，ＭＳＫ＿ｄ，ＭＳＫ＿ｐ，ＭＳＫ＿ｂ，．．．）の形式で導出され得る。様々な結合が例として本明細書で説明されるが、望ましければ、他の認証結果およびアサーションが結合され得ることが理解されよう。

例示的な実施形態では、認証結果は連鎖的である。例えば、ネットワークエンティティが、Ｕ＿ＡＡＦおよびＤ＿ＡＡＦを実行することが可能である場合、認証は連鎖的であり得る。例えば、ユーザマスタセッション鍵（ＭＳＫ＿ｕ）およびデバイスマスタセッション鍵（ＭＳＫ＿ｄ）は、同じエンティティにおいて導出され、ネットワーク側における連鎖的な認証が終了すると、ＡＣＥに伝達され得る。そのような連鎖性は、例えば、拡張認証プロトコル（ＥＡＰ）連鎖的プロセスを使用し得、ＥＡＰ−ＴＴＬＳは、ＥＡＰ−ＡＫＡとともに使用され得、またはＧＢＡは、ＧＢＡ ＳＩＰダイジェストもしくは認証プロセスの組み合わせとともに使用され得る。

図３Ａおよび図３Ｂは、例示的な実施形態による、ユーザおよびデバイス認証を必要とし得るサービスにアクセスするためのフロー図である。図３Ａおよび図３Ｂに示される例示的な呼フローでは、ユーザは、少なくとも２ファクタ認証（例えば、パスワード／ＰＩＮを伴うユーザ名およびデバイス／ＵＩＣＣベースの認証）を必要とするサービスにアクセスすることを望む。

図３Ａおよび図３Ｂに示される説明的な実施形態を参照すると、システム３００は、ネットワークを介して互いに通信する、ＵＥ３０１と、ＡＣＥ３０２と、Ｕ＿ＡＡＦ３０４と、Ｄ＿ＡＡＦ３０６とを含む。ＵＥ３０１は、ＵＥ３０１を操作するユーザを有する。したがって、ＵＥ３０１は、ＵＥがユーザを有することを示すために、ユーザ／ＵＥ３０１と呼ばれることがある。３０８において、ユーザは、ＵＥ３０１を介して、ＡＣＥ３０２によって制御される、サービスへのアクセスを要求する。ＡＣＥ３０２は、３ＧＰＰ ＧＢＡにおいて定義される、ＯｐｅｎＩＤ／ＯｐｅｎＩＤ接続プロトコルにおいて定義される、ネットワークアプリケーション機能（ＮＡＦ）もしくはサービスプロバイダ、リライングパーティ（ＲＰ）／クライアント、またはアクセス制御機能を実行し得る他の任意のエンティティと呼ばれることがあることが理解されよう。３０８における要求は、ＨＴＴＰ接続上で、または望ましければ他の接続上で通信され得る。

３１０において、ＡＣＥ３０２は、サービス要求のタイプに基づいて、かつサービスを管理するポリシーに基づいて、そのユーザ識別情報または利用契約識別情報、およびそのデバイス識別情報またはデバイス利用契約識別情報を提供するようにＵＥ／ユーザ３０１に要求する。ユーザ識別情報は、ユーザが利用契約を結んでおり、ユーザ資格証明書の入力を求められ得る、アプリケーションまたはサービスに結び付けられ得る。デバイス識別情報は、サービスにアクセスするために使用されているデバイス（例えば、ＵＥ３０１、ＵＩＣＣ）に結び付けられ得る。さらに、３１０において、ＵＥ３０１は、ユーザ認証の強度の度合い、および／またはデバイス認証の強度の度合いを獲得し得る。したがって、ユーザ認証またはデバイス認証は、強度の獲得された度合いに基づき得る。

３１２において、ユーザ識別情報およびデバイス識別情報が提供される。例えば、ユーザ識別情報は、ローカル識別情報、またはユーザのサードパーティ識別情報（例えば、ＳＳＯ識別情報）であり得る。そのような識別情報の例は、ｘｙｚ＠ｇｍａｉｌ．ｃｏｍである。利用契約識別情報は、デバイス／ＵＩＣＣ／スマートカード（例えば、ＵＥ３０１）に結び付けられ得、共有秘密または証明書を用いて表され得る。そのような識別情報の例は、ＩＭＳＩ＠ａｔｔ．ｃｏｍであり得る。説明される実施形態によれば、両方の識別情報が、ＵＥ３０１によってＡＣＥ３０２に送信される。３１４において、ユーザ／ＵＥ３０１の識別情報が受信され、ＡＣＥ３０２は、識別情報を解決して、例えば、ユーザ識別およびアサーション機能（Ｕ＿ＡＡＦ）３０４、およびデバイス識別およびアサーション機能（Ｄ＿ＡＡＦ）３０６を発見する。３１６において、ＡＣＥ３０２は、例えば、ＵＥ３０１がＵ＿ＡＡＦ３０４を用いてユーザ認証を開始し得るように、ＵＥ３０１をＵ＿ＡＡＦ３０４にリダイレクトする。同様に、３１８において、ＡＣＥ３０２は、Ｄ＿ＡＡＦ３０６を用いてデバイス認証を開始するように、ＵＥ３０１をリダイレクトする。

図３Ａおよび図３Ｂに示される説明的な実施形態によれば、３２０において、例えば、相互認証プロトコル（例えば、ＥＡＰ−ＴＴＬＳ、ＥＡＰ−ＴＬＳ、またはＧＢＡ ＳＩＰダイジェストなど）を使用することによって、かつクライアント認証メカニズム（例えば、Ｏｐｅｎ Ｉｄユーザ名／パスワード）を使用することによって、ユーザ認証が実行される。ユーザ認証の終了時に、ユーザおよびＵ＿ＡＡＦ３０４に結合され得る、共有ユーザマスタセッション鍵（ＭＳＫ＿ｕ）３２１が導出される。例示的な実施形態では、ステップ３２０は、ユーザとＵ＿ＡＡＦ３０４の間に有効な認証アソシエーションが存在する場合、スキップされる。有効な認証アソシエーションは、ユーザとＵ＿ＡＡＦ３０４の間で実施された先行する認証のエイジまたは鮮度が、ＡＣＥ３０２によって要求される必要な認証鮮度を満たす場合に、ＡＡＦによって決定され得る。３２２において、デバイス認証が、ＵＥ３０１とＤ＿ＡＡＦ３０６の間で実施される。特に、デバイス認証は、ＵＥ３０１上に存在するＵＩＣＣとＤ＿ＡＡＦ３０６の間で実施され得る。ＵＥ３０１の認証（デバイス認証）は、相互認証プロトコル（例えば、ＧＢＡ、ＥＡＰ−ＳＩＭ／ＡＫＡなど）を使用することによって、かつ／またはデバイス証明書に基づいたデバイス認証を使用することによって実行され得る。デバイス認証の終了時に、ＵＥ／ＵＩＣＣエンティティおよびＤ＿ＡＡＦエンティティに結合され得る、共有鍵（例えば、ＭＳＫ＿ｄ３２３）が導出され得る。例示的な実施形態では、ステップ３２３は、ＵＥ３０１（例えば、ＵＩＣＣ）とＤ＿ＡＡＦ３０６の間に有効な認証アソシエーションが存在する場合、スキップされる。有効な認証アソシエーションは、ＵＥ３０１とＤ＿ＡＡＦ３０６の間で実施された先行する認証のエイジまたは鮮度が、ＡＣＥ３０２によって要求される必要な認証鮮度を満たす場合に、ＡＡＦによって決定され得る。

３２４において、説明される実施形態によれば、ＵＥ３０１は、ＭＳＫ＿ｕ３２１およびＭＳＫ＿ｄ３２３をセッションに結合し、認証結合鍵（ＡＢＫ）が導出される。ＡＢＫは、例えば、ＭＳＫ＿ｕ３２１、ＭＳＫ＿ｄ３２３、セッション情報、およびランダムデータに適用される、鍵導出関数（ＫＤＦ）を使用して導出され得る。ＡＢＫは、チャネルまたはチャネルパラメータと認証メカニズムを一緒に結合し得る。チャネルパラメータは、ＴＬＳマスタ鍵、またはＡＡＦとＵＥ／ユーザ３０１の間で確立された各チャネルに特有であると決定される他の値などの値であり得る。

ユーザが認証されると、３２６において、例えば、Ｕ＿ＡＡＦ３０４は、例えば、３１０において獲得されたユーザ認証強度の度合いに基づいて、アサーションを生成する。アサーションは、ユーザに関連付けられるので、ユーザアサーションと呼ばれることがある。ユーザアサーションは、（３２０からの）ユーザとＵ＿ＡＡＦ３０４の間の認証の結果を示す。３２０において、成功のうちにユーザが認証された場合、ユーザアサーションは、肯定的アサーションであり得る。例えば、アサーションは、（例えば、３２０において実行される複数ファクタユーザ認証からの）複数のユーザ認証ファクタの結果を含み得る。さらに、図３Ａに示されるように、ユーザアサーションは、ＡＣＥ３０２に提供され得る。ユーザアサーションは、ユーザ識別情報、およびユーザ認証に対応するユーザ認証保証レベルを含み得る。ユーザアサーションは、ユーザ認証の鮮度の表示をさらに含み得る。ユーザ認証の鮮度の表示は、ユーザとＵ＿ＡＡＦ３０４の間のセキュリティアソシエーションの鮮度レベルと呼ばれることがある。３２６において、ＭＳＫ＿ｕ３２１が、アサーションメッセージを使用してトランスポートされ得、または３２６において、トークンが、アサーションメッセージに収めて送信され得る。例えば、トークンは、ＭＳＫ＿ｕ３２１を取り出すために使用され得る。

図３Ａおよび図３Ｂを参照すると、ＵＥ３０１が認証されると、それぞれ３２８および３２９において、例えば、Ｄ＿ＡＡＦ３０６は、３１０において獲得されたデバイス認証強度の度合いに基づいて、アサーションを生成する。アサーションは、ＵＥ３０１に関連付けられるので、デバイスアサーションと呼ばれることがある。デバイスアサーションは、（３２２からの）ＵＥ３０１とＤ＿ＡＡＦ３０６の間の認証の結果を示す。３２２において、成功のうちにＵＥ３０１が認証された場合、デバイスアサーションは、肯定的アサーションであり得る。例えば、アサーションは、（例えば、３２２において実行される複数ファクタデバイス認証からの）複数のデバイス認証ファクタを含み得る。さらに３２８（図３Ａ）において、デバイスアサーションは、ＡＣＥ３０２に提供される。あるいは、３２７（図３Ｂ）において、デバイスアサーションは、Ｕ＿ＡＡＦ３０４に提供され、マスタセッション鍵（ＭＳＫ）アクセストークンとともに送信される。デバイスアサーションは、デバイス識別情報、およびデバイス認証に対応するデバイス認証保証レベルを含み得る。デバイスアサーションは、デバイス認証の鮮度の表示をさらに含み得る。デバイス認証の鮮度の表示は、ＵＥ３０１とＤ＿ＡＡＦ３０６の間のセキュリティアソシエーションの鮮度レベルと呼ばれることがある。３２８において、ＭＳＫ＿ｄ３２３が、アサーションメッセージを使用してトランスポートされ得、または３２８において、トークンが、アサーションメッセージに収めて送信され得る。例えば、トークンは、ＭＳＫ＿ｄ３２３を取り出すために使用され得る。

図３Ａを参照すると、説明される実施形態によれば、３３０において、ユーザアサーションは、ＡＣＥ３０２において、デバイスアサーションに結合され、有界アサーションを生成する。あるいは、図３Ｂを参照すると、説明される実施形態によれば、３３１において、ユーザアサーション（ユーザ認証結果）は、Ｕ＿ＡＡＦ３０４において、デバイスアサーション（デバイス認証結果）に結合される。アサーションは、認証されたユーザ識別情報（例えば、ユーザ名など）をＵＥ３０１の識別情報（例えば、ＩＭＳＩ）と照合し得る、様々なエンティティにおいて結合され得ることが理解されよう。したがって、Ｄ＿ＡＡＦ３０６も、アサーションを結合し得る。さらに、ＡＡＦはＵＥ３０１上に存在し得るので、例示的な実施形態によれば、認証アサーションは、ＵＥにおいて結合され得ることが理解されよう。さらに、結合は、ネットワークベースのＡＡＦのプロキシ機能として、ＵＥ３０１に委任され得る。図３Ｂを再び参照すると、３１７において、Ｕ＿ＡＡＦ３０４は、ユーザの識別情報をデバイスの識別情報にマッピングする。したがって、３３１において、ユーザ認証とデバイス認証が結合されて、単一の有界アサーションを生成し得る。

図３Ａおよび図３Ｂを引き続き参照すると、有界アサーションは、ユーザ認証保証レベルとデバイス認証保証レベルの結合結果を含み得る。例示的な実施形態では、肯定的なユーザアサーションおよびデバイスアサーションが受信された場合、アサーションは、一緒に結合される。別の例示的な実施形態では、デバイスアサーションは、デバイス認証保証レベルおよびデバイス認証鮮度レベルが、それぞれの許容可能範囲内にある場合、肯定的である。そのような範囲は、サービスまたはリソースを提供するサービスプロバイダのポリシーによって決定され得る。同様に、例えば、ユーザアサーションは、ユーザ認証保証レベルおよびユーザ認証鮮度レベルが、サービスを提供するサービスプロバイダのポリシーによって決定され得る、それぞれの許容可能範囲内にある場合、肯定的であり得る。したがって、セキュリティアソシエーションの保証レベルおよび鮮度レベルが、許容可能範囲内にある場合、アサーションは、セッションと一緒に結合され得る。図３Ａを参照すると、同じ鍵導出が、ＡＣＥ３０２において実施されて、ＡＢＫを導出し得る。例えば、ＡＢＫの知識は、ＡＣＥ３０２およびＵＥ３０１に制限され得る。図３Ｂを参照すると、３３３において、Ｕ＿ＡＡＦ３０４は、有界アサーションに関連付けられる保証レベルおよび鮮度レベルを含み得るリダイレクトメッセージを介して、ＭＳＫアクセストークンをＡＣＥ３０２に提供し、ＡＣＥ３０２に対して結合認証アサーションをアサートするために、（例えば、ブラウザリダイレクトを介して）ＵＥ３０１をリダイレクトする。３３５（図３Ｂ）において、認証アサーション（結果）をアサートするＵＥ３０１は、ＡＣＥ３０２にリダイレクトされる。

図３Ａを参照すると、説明される実施形態によれば、３３２において、ＡＣＥ３０２は、３３０から得られた結合を確認するために、ＵＥ３０１に問い合わせる。３３４において、ＵＥ３０１は、結合を確認する。確認は、例えば、ＡＢＫの所有を推測するために使用され得る、暗号化応答であり得、またはＡＢＫは、（例えば、ＨＴＴＰダイジェストに類似するメカニズムを使用して）パスワードとしてＡＣＥ３０２に送信され得る。ＵＥ３０１から結合確認を獲得した後、ＡＣＥは、導出したＡＢＫを検証し得る。例示的な実施形態では、結合の検証に成功すると、ＵＥ３０１は、認証され、３３６において、認証成功メッセージが、ＵＥに送信される。ＡＢＫは、サービスにアクセスするために使用されるセッション鍵を導出するために、マスタ鍵として使用され得る。図３Ａおよび図３Ｂを参照すると、３３８において、ＵＥ３０１は、サービスまたはリソースにアクセスし得る。したがって、ＵＥ３０１は、３３０（図３Ａ）または３３１（図３Ｂ）におけるアサーションに基づいて、特に、ユーザアサーションおよびデバイスアサーションに基づいて、サービスまたはリソースへのアクセスを受信し得る。そのようなアクセスは、完全アクセスまたは無制限アクセスと呼ばれることがある。

別の例示的な実施形態では、（例えば、３２６における）ユーザアサーションは、（例えば、３２０における）ユーザとＵ＿ＡＡＦ３０４の間の認証の結果が否定的であることを示す、否定的ユーザアサーションを含む。そのような否定的ユーザアサーションに応答して、ユーザ／ＵＥ３０１は、サービスへの制限付きアクセスまたはアクセス不可を受信し得る。同様に、（例えば、３２８または３２７における）デバイスアサーションは、（例えば、３２２における）ＵＥ３０１とＤ＿ＡＡＦ３０６の間の認証の結果が否定的であることを示す、否定的デバイスアサーションを含み得る。そのような否定的デバイスアサーションに応答して、ユーザ／ＵＥは、サービスへの制限付きアクセスまたはアクセス不可を受信し得る。さらに、（例えば、３３０または３３１における）有界アサーションは、ユーザとＵ＿ＡＡＦ３０４の間の認証の結果、またはＵＥ３０１とＤ＿ＡＡＦ３０６の間の認証の結果のうちの少なくとも一方が否定的であることを示す、否定的有界アサーションを含み得る。否定的有界アサーションに応答して、ユーザ／ＵＥ３０１は、サービスへの制限付きアクセスまたはアクセス不可を受信し得る。したがって、デバイス認証保証レベル、デバイス認証鮮度レベル、ユーザ認証保証レベル、またはユーザ認証鮮度レベルのうちの少なくとも１つが、それぞれの許容可能範囲内にない場合、ユーザ／ＵＥ３０１は、サービスへの制限付きアクセスまたはアクセス不可を受信する。また別の実施形態によれば、デバイス認証保証レベルおよびデバイス認証鮮度レベルのうちの少なくとも一方が、それぞれの許容可能範囲内にない場合、ＵＥ３０１は、Ｄ＿ＡＡＦ３０６を用いて再認証される。同様に、ユーザ認証保証レベルおよびユーザ認証鮮度レベルのうちの少なくとも一方が、それぞれの許容可能範囲内にない場合、ユーザは、Ｕ＿ＡＡＦ３０４を用いて再認証され得る。

例示的な実施形態では、認証の強力な保証レベルは、デバイスの利用契約の認証を含み、その特定のサービス利用契約に対してユーザを認証する。例えば、一実施形態では、ユーザは、ユーザｐｉｎ／パスワード、またはバイオメトリックスなどを使用して、デバイスに対して認証され、ユーザ認証の結果は、デバイスのＵＩＣＣ上に記憶され、ネットワークに対して通信される。認証をシームレスにするために、例えば、ユーザは、サービスアクセス要求毎に認証されなくてもよい。ユーザは、定期的に認証され得、関連付けられた鮮度レベルおよび保証レベルが、以前の認証が実行された時、および実行された認証のタイプを示すために使用され得る。

サービスは、鮮度レベルおよび保証レベルに対する異なる要件を有し得る。そのような要件は、サービスを提供するサービスプロバイダのポリシーに基づき得る。例えば、鮮度レベルもしくは保証レベルまたは両方が不満足であることをサービスプロバイダが要求する場合、ユーザ認証は、再び実行されなければならないことがある。レベルは、それがユーザ認証のためのサービスの基準を満たさない場合、不満足であり得る。

図４は、例示的な実施形態による、汎用ブートストラップアーキテクチャ（ＧＢＡ）認証およびアサーションを用いてマッチオンサーバ実施を実施するシステム４００のブロック図である。システム４００は、ネットワークを介して通信する、ユーザデバイス４０２（例えば、ＷＴＲＵ）と、ブートストラップサーバ機能（ＢＳＦ）４０６と、ＮＡＦ４０４とを含む。説明されるＧＢＡメカニズムは、認証のために、かつＵＥ４０２をＮＡＦ４０６にブートストラップするために使用され得る。図４に示される説明的な実施形態を参照すると、ＢＳＦ４０６は、４０８からのユーザ認証と４１０からのデバイス認証を結合して、４１２において、有界アサーションをＮＡＦ４０４に提供する。説明される実施形態によれば、ＢＳＦ４０６は、Ｕ＿ＡＡＦ４１４と、Ｄ＿ＡＡＦ４１６とを含む。有界アサーションに関連付けられる保証レベルは、４１２において、提供され得る。さらに、有界アサーションに関連付けられる鮮度レベルは、４１２において、提供され得る。ユーザ資格証明書（例えば、ユーザ名／パスワード）は、４１０において行われ得るＵＩＣＣベースのＡＫＡデバイス認証の一環として導出され得る、Ｋｓ＿ＮＡＦ４１８に結合され得る。図１も参照すると、ＢＳＦ４０６は、ＡＡＦとして機能し得、ＮＡＦ４０４は、ＡＣＥ１０６として機能し得る。ＡＢＫ４２０は、ユーザ資格証明書（例えば、ユーザ名（ＵＮ）／パスワード（ＰＷ）４１７）とＫｓ＿ＮＡＦ４１８との暗号化を施した合併（結合）を行って、ＡＢＫ４２０を形成することによって、導出され得る。あるいは、ＮＡＦ４０４は、ユーザ認証とデバイス認証の両方についての組み合わされたアサーションを生成し、アサーションを、対応する保証レベルおよび鮮度レベルとともに、ＡＣＥ（例えば、リライングパーティ（ＲＰ）またはサービスプロバイダ（ＳＰ）によって実施され得る、図１に示されるＡＣＥ１０６）に送信する、ＡＡＦとして機能し得、ＢＳＦ４０６は、（図４において説明されるように）Ｕ＿ＡＡＦ４１４もしくはＤ＿ＡＡＦ４１６または両方として機能し得る。

本明細書で説明されるように、複数ファクタ認証は、（例えば、ＵＩＣＣ内に記憶される）ユーザ資格証明書およびモバイル加入者資格証明書を利用し得る。３ＧＰＰの汎用認証アーキテクチャ（ＧＡＡ）は、様々な実施形態にフレームワークを提供する。例示的な構成では、ＵＥは、スマートカード（ＵＩＣＣ／ＳＩＭ）と、モバイル環境（ＭＥ）（例えば、ＧＢＡ対応ブラウザ）と、オペレータのネットワーク上のブートストラップエンティティと通信するためのクライアントモジュールとを含む。ＵＩＣＣは、ＵＥがネットワークと共有する強力な秘密（例えば、加入者資格証明書）、ならびに（例えば、ユーザ名およびパスワードの形式の）ユーザ資格証明書などの、加入者レベルおよびユーザレベルの資格証明書のためのストレージを提供し得る。

図５は、別の例示的な実施形態による、図４に示されたＧＢＡ認証およびアサーションを用いてマッチオンデバイス実施を実施するシステム５００のブロック図である。図４に示される説明的な実施形態によれば、ユーザ認証およびアサーションは、ユーザデバイス４０２Ａ上で実施され、ＢＳＦ４０６は、ＵＩＣＣベースのＡＫＡに基づいて、Ｄ＿ＡＡＦ４１６を実行する。４１３において、ユーザデバイス４０２Ａ上のＵ＿ＡＡＦ４１４Ａは、ＢＳＦ４０６に対して、ユーザの認証をアサートし得る。ＢＳＦ４０６は、ユーザ認証の結果を、４１０におけるデバイス認証の一環として導出されるＫｓ＿ＮＡＦ４１８と結合し得る。

図４および図５において参照されるＧＢＡ実施などの、ＧＢＡ実施に関して、ＮＡＦ４０４は、ＡＣＥを含み得る。ユーザ識別およびアサーション機能（Ｕ＿ＡＡＦ）４１４は、ネットワークと関わりをもたない（例えば、マッチオンデバイス）ユーザデバイス４０２を含み得る。ＢＳＦ４０６は、ネットワークが関与する場合（例えば、マッチオンサーバ）、ＡＡＦとして機能し得る。デバイス識別およびアサーション機能（Ｄ＿ＡＡＦ）４１６は、ＢＳＦ４０６によって含まれ得る。デバイス認証を介して導出されるマスタセッション鍵（ＭＳＫ＿ｄ）は、Ｋｓと表され得、それは、秘匿鍵（ＣＫ）と完全性鍵（ＩＫ）を連結することによって導出され得る。ＣＫおよびＩＫは、ネットワーク内のＨＳＳから獲得される認証ベクトル（ＡＶ）の一部であり得、ＧＢＡ中にブートストラッププロセスの一環として、ＵＥ４０２において導出され得る。ユーザ認証を介して導出され得るマスタセッション鍵（ＭＳＫ＿ｕ）は、「通常の」ＧＢＡが実行される場合は、存在し得ない。ＧＢＡ＿Ｄｉｇｅｓｔが実行される場合、Ｋｓは、文献（例えば、非特許文献１参照）に示される公式、すなわち、Ｋｓ＝ＫＤＦ（Ｈ（Ａ１），“ＧＢＡ＿Ｄｉｇｅｓｔ＿Ｋｓ”，ＴＬＳ＿ＭＫ＿Ｅｘｔｒ，ＲＥＳＰ）に従って導出され得、ここで、Ｈ（Ａ１）は、文献（例えば、非特許文献２参照）に従ったＳＩＰ ＤｉｇｅｓｔのためのＩＭＳにおいて、また文献（例えば、非特許文献３参照）に示されるレルムにおいて、ユーザによって使用されるユーザ名およびパスワードのハッシュであり、ＲＥＳＰは、ＵＥからＢＳＦへの認証応答であり、ＴＬＳ＿ＭＫ＿Ｅｘｔｒは、文献（例えば、非特許文献４参照）に従ってＴＬＳマスタ鍵から抽出され、“ＧＢＡ＿Ｄｉｇｅｓｔ＿Ｋｓ”は、文字列である。ＳＩＰダイジェスト資格証明書が使用されるこのケースでは、Ｋｓは、ユーザ認証鍵ＭＳＫ＿ｕであり得る。例えば、ネットワーク支援のユーザ認証がＧＢＡと組み合わされる場合、結合鍵は、本明細書で説明されるように利用され得る。文献（例えば、非特許文献５参照）は、その全体が参照により本明細書に組み込まれ、あたかも説明がなされたかのように見なされる。あるいは、ＢＳＦ４０６は、Ｄ＿ＡＡＦ４１６もしくはＵ＿ＡＡＦ４１４または両方として機能し得、一方、ＮＡＦは、ＡＡＦとして機能し、したがって、Ｕ＿ＡＡＦ４１４およびＤ＿ＡＡＦ４１６からそれぞれ受信されるユーザ認証結果およびデバイス認証結果の両方についての有界アサーションを生成する。その後、有界アサーション、ならびに有界アサーションに関連付けられる鮮度レベルおよび保証レベルは、ＡＣＥに送信される。ＡＣＥはＳＰまたはＲＰであり得ることが理解されよう。

図６は、例示的な実施形態による、ＧＢＡとローカルユーザ認証の組み合わせを説明する、サービスへのユーザアクセスについてのフロー図である。本明細書で説明されるように、様々な実施形態は、図６において説明されるフロー図の変更された部分を含む。図６を参照して説明されるプロトコルは、ＭＮＯおよびＮＡＦのポリシーの制約内で柔軟性を提供し得る。

図６を参照すると、システム６００は、ネットワークを介して通信する、ＵＩＣＣ／ＳＩＭ６０２と、ＧＢＡモジュール６０４と、ブラウザ６０６と、ＨＳＳ／ＨＬＲ６１０と、ウェブサーバ（例えば、ＮＡＦ）６１２とを含む。ＵＩＣＣ／ＳＩＭ６０２、ＧＢＡモジュール６０４、およびブラウザ６０６は、限定することなく、本明細書でＵＥまたはＷＴＲＵと呼ばれることがある、ユーザデバイス内に存在し得る。

説明的な実施形態によれば、６１６において、サービスメッセージを求めるＨＴＴＰ要求は、ＮＡＦウェブサーバ６１２宛てである。メッセージは、例えば、ＨＴＴＰを使用する場合は、ダイジェストヘッダなしに送信され得る。ＵＥウェブブラウザ６０６は、そのＦＱＤＮを含み得るＮＡＦ６１２の識別情報（ＩＤ）を知っていると仮定され得る。要求において、ブラウザ６０６は、「ユーザエージェント」ヘッダフィールドに「プロダクト」トークンを追加し得る。例えば、プロダクトトークンは、それがＧＢＡ対応である（例えば、３ｇｐｐ−ｇｂａで表される）ことを示し得、プロダクトトークンは、それがＳＳＯサブシステムを所有することを示し得る。ＳＳＯサブシステムは、様々な他の機能のうち、ユーザ認証を実行する、ＵＥ上のネットワークプロキシのことを指し得る。ＳＳＯサブシステムは、（例えば、６１４において）ユーザが積極的に認証されたことの証拠を提供し得、保証レベル（ＡＬ）および関連付けられた認証鮮度（ＡＦ）に関する情報を提供し得る。ＡＦは、本明細書では、限定することなく、鮮度レベルと呼ばれることがある。ブラウザ６０６を介するＵＥによるサービスを求める初期要求に続いて、ＮＡＦ６１２は、ユーザが再認証を求められるかどうかを示し得る。そのような決定は、６１６における初期要求においてＵＥによって提供されたＡＬおよびＡＦに基づき得る。例えば、ＧＢＡが、実行され得、ユーザ認証（例えば、要求された場合は、再認証）が、ユーザデバイス上でローカルに実行され得る。

６１８において、ＮＡＦ６１２は、要求内のＵＲＬが、認証を必要とし得るサービスを識別していることに気づき得る。例えば、ＮＡＦ６１２は、ユーザエージェントヘッダを検査し得、ＵＥのＧＢＡ能力を決定し得る。ＮＡＦ６１２は、ＵＥに応答（例えば、４０１ 無認可「ダイジェストチャレンジ」）を送信し得る。そのような応答は、認証が必要とされることを示し得る。その応答内に、ＮＡＦ６１２は、例えば、「３ｇｐｐ−ｂｏｏｔｓｔｒａｐｐｉｎｇ＠ｗｗｗ．ｎａｆ．ｏｒｇ」形式のレルム値を追加し得る。プレフィックス値「３ｇｐｐ−ｂｏｏｔｓｔｒａｐｐｉｎｇ＠」は、必要とされるプロトコルとして、ブートストラップがＧＢＡを用いて実行されることを示し得る。例示的な実施形態では、ＮＡＦ６１２は、ユーザ認証保証レベルおよび鮮度レベルを検査して、それらの妥当性を決定する。レベルが妥当ではない、例えば、レベルがそれぞれの許容可能範囲内にない、またはレベルがそれぞれの許容可能閾値を下回ると決定された場合、ユーザ再認証が必要とされ得る。例示的な実施形態では、ＮＡＦ６１２は、どの認証レベルが許容可能であるかを示す。

説明的な実施形態によれば、例えば、ＮＡＦ６１２によって再認証が要求される場合、６２０において、ユーザは再認証される。再認証は、例えば、ユーザが積極的に入力を要求され得る、ユーザ名およびパスワードなどの、ユーザベースの資格証明書を利用し得る。複数ファクタユーザ認証が要求される例示的な実施形態では、バイオメトリックも使用され得る。ＵＥは、例えば、ＮＡＦによって示された最低の保証レベルをそれが満たさないと決定した場合、サービスを求める要求を停止することを決定し得る。あるいは、ＵＥは、それが最低の保証レベルを満たさないと決定した場合、制限付きサービス（アクセス）を要求し得る。例えば、サービスへの制限付きアクセスは、無制限（完全）アクセスよりも低い保証レベルを必要とし得る。したがって、制限付きアクセスは、ＮＡＦ６１２とネゴシエートされ得る。図６には示されていないが、入力されたユーザ資格証明書は、ＵＩＣＣ上の対応する情報を用いて検証され得ることが理解されよう。

６２２において、ブラウザ６０６は、ブートストラップされるＮＡＦ固有の鍵を求めて、ＮＡＦ６１２の識別情報（ＮＡＦ＿ＩＤ）を含み得る要求を、ＧＢＡモジュール６０４に送信する。６２４において、マスタセッション鍵Ｋｓを導出するためのブートストラップが、例えば、ＵＩＣＣベースの加入者資格証明書を使用して実行される。このプロセスに関与するエンティティは、ＵＥ内のＧＢＡモジュール６０４およびＵＩＣＣ６０２、ならびにＭＮＯドメイン内のＢＳＦ６０８およびＨＳＳ６１０を含み得る。例えば、ＧＢＡモジュール６０４は、ブートストラップを要求（それによって、特定のＮＡＦ＿ＩＤを使用してそれから導出されるアプリケーション固有の鍵を受信）するアプリケーションが、それを行うことを認可されているかどうかを決定するために検査を行い得る。

説明的な実施形態によれば、６２４において、ＧＢＡモジュール６０４は、ＮＡＦ固有の鍵（Ｋｓ＿ＮＡＦ）を導出し、それをブラウザ６０６に配送する。鍵の配送は、例えば、Ｂ−ＴＩＤ、鍵有効期限、および、例えば、ＧＢＡタイプを示す他の情報など、様々な情報を含み得る。６２６において、ＮＡＦ固有の（１または複数の）鍵は、例えば、Ｋｓ、ブラウザ６０６によって提供されるＮＡＦ＿ＩＤ、ならびにプライベート識別情報ＩＭＰＩおよびＲＡＮＤなどの他のパラメータから導出され得る。ＧＢＡ＿Ｕが実行される場合、例えば、Ｋｓ＿ｉｎｔ＿ＮＡＦおよびＫｓ＿Ｅｘｔ＿ＮＡＦが、ＵＩＣＣ６０２上で計算され得る。Ｋｓ＿Ｅｘｔ＿ＮＡＦは、ＧＢＡモジュール６０４に渡され得る。

説明的な実施形態によれば、ブートストラップされた資格証明書が、６２８において、ブラウザ６０６に送信される。ＧＢＡモジュール６０４からブートストラップされた材料を受信した後、６３０において、ブラウザは、ステップ６１８におけるチャレンジに対するダイジェスト応答を準備する。例えば、それは、元のサービス要求メッセージを、計算されたダイジェスト応答パラメータとともに、「認可」ヘッダ内で使用し得る。計算は、ユーザ名としてＢ−ＴＩＤを、またパスワードとしてＮＡＦ固有の鍵を使用し得る。応答は、文献（例えば、非特許文献６参照）に従って計算され得、それは、本明細書でＲＦＣ２６１７と呼ばれることがあり、その全体が参照により本明細書に組み込まれ、その内容があたかも説明されたかのように見なされる。したがって、例えば、ユーザ再認証がＮＡＦ６１２によって要求された場合、応答は、更新されたユーザ認証結果、ユーザ認証に対応する保証レベル、およびユーザ認証に対応する認証鮮度を含み得る。

６３２において、ＮＡＦ６１２は、更新された保証レベルおよび鮮度レベルを検査する。例えば、ＮＡＦは、どちらかのレベルまたは両方のレベルが不適切であると決定された場合、プロトコルを終了し得る。保証レベルまたは鮮度レベルは、それぞれの許容可能範囲外にある場合、またはそれぞれの閾値を下回る場合、不適切であり得る。６３２においてプロトコルが終了されなかった場合、例えば、６３４において、ＮＡＦ６１２は、（例えば、ステップ６３０において受信された）Ｂ−ＴＩＤ、およびそのＮＡＦ＿ＩＤを、ＢＳＦ６０８に送信して、ＮＡＦ固有の鍵を要求し得る。ＮＡＦ６１２は、ＧＡＡサービス識別子を用いてユーザセキュリティ設定（ＵＳＳ）を要求し得、かつ／またはそれがＧＢＡアウェアであることを示し得る。６３６において、ＢＳＦ６０８は、Ｂ−ＴＩＤを使用して、Ｋｓをフェッチし、それ、ＮＡＦ＿ＩＤ、および他のパラメータを使用して、ＮＡＦ固有の鍵を計算する。

説明的な実施形態によれば、６３８において、ＢＳＦ６０８は、ＮＡＦ６１２が、要求しているＮＡＦ固有の鍵の受信を認可されていることを検証するために検査を行う。ＮＡＦ６１２が認可されている場合、ＢＳＦ６０８は、Ｂ−ＴＩＤによって識別され得るマスタセッション鍵Ｋｓを見つけ得、（例えば、ステップ６２４におけるように）ＮＡＦ固有の鍵の計算に着手し得る。ＵＳＳは、例えば、オペレータポリシーによって指定されるような、鍵使用要件を含み得る。これは、ＮＡＦ６１２またはＵＥが要件を満たし得ない場合に、プロセスを終了し得る。例えば、そのような要件は、Ｋｓ＿ｉｎｔ＿ＮＡＦが使用されることを規定し得る。そのような要件を欠く例では、Ｋｓ＿ＮＡＦまたはＫｓ＿ｅｘｔ＿ＮＡＦが使用され得る。

６４０において、ＮＡＦ６１２は、６３０においてブラウザ６０６によって送信されたダイジェスト応答を（例えば、ＢＳＦ６０８から受信されたＮＡＦ固有の鍵を使用して）確認する。例えば、ユーザの認証が成功した場合、ＮＡＦ６１２は、認証成功とユーザがサービスにアクセスすることの認可とを示し得る、２００ ＯＫを、ブラウザに送信し得る。メッセージは、例えば、Ｂ−ＴＩＤおよびダイジェストレルムなどの認証情報を含み得る。例えば、ＮＡＦ固有の鍵の有効期限が満了した場合、６４２において、ＮＡＦ６１２は、新しいブートストラップを要求し得る。例示的な実施形態では、期限が満了すると、プレゼンスのユーザ証明が要求され、ＮＡＦ６１２は、プレゼンスの証明を提供するために、ユーザ再認証を要求する。

例示的な実施形態では、図６において説明される例示的なプロトコルフローは、ＵＥに対してローカルであり得るＮＡＦポリシーを使用し得る。例えば、様々なＮＡＦポリシーが、ＵＥ上で利用可能であり得る。そのようなポリシーは、ＵＲＬを介して分類され得る。例えば、ＵＥ上のＳＳＯサブシステムは、サービス要求メッセージが送信されるＮＡＦのＵＲＬを使用して、ＮＡＦ認証ポリシーのローカルバージョンを見つけ得る。そのようなポリシー検索は、サービス要求が行われる前に実行され得る。例えば、ポリシーによって述べられる要件に基づいて、ＵＥ ＳＳＯサブシステムは、最初にユーザをローカルで認証するかどうかを決定し得、かつ／またはどの認証強度が利用されるべきかを決定し得る。したがって、ＵＥは、認証保証レベルの度合いを獲得し得る。例示的な実施形態では、ＵＥは、図６のメッセージ６１６に示されるサービスメッセージを求める要求を送信する前に、ユーザを再認証し得る。ＵＥは保証レベル要件を満たさないとＳＳＯサブシステムおよびＮＡＦが決定した場合、ＵＥは、ＵＥが提供し得る最も高い保証に基づいて、制限付きサービスを求める要求を送信し得る。ＮＡＦは、そのような制限付きサービスを許可し得、またはサービスへのアクセスを完全に拒否し得る。

別の例示的な実施形態では、ＵＥは、ユーザ再認証を求めるＮＡＦ要求に対して、即座の応答を提供し得る。例えば、ＵＥは、図６のステップ６２０の直後に、ＮＡＦ６１２に再認証情報を送信し得る。そのような実施形態では、ＮＡＦ６１２は、ブートストラップを必要とし得るＵＥに対して、別の４０１ 無認可ダイジェストチャレンジを用いて応答し得る（例えば、ステップ６１８）。応答は、更新されたユーザ認証保証レベルおよび／または鮮度レベルが許容可能であることを示し得る。例えば、ＵＥは、ＮＡＦによってどの認証強度が期待されるかを知っており、期待される認証強度を提供し得ることが仮定され得る。ＵＥは、期待される認証強度を提供し得ない場合、アクセス要求を終了し得、またはサービスへの制限付きアクセスについてのネゴシエーションを行い得る。

ローカルユーザ認証の代替案として、例示的な実施形態によれば、ユーザは、最初にＮＡＦに直接ログインし得る。例えば、ユーザは、ログイン情報をＮＡＦに入力し得、ＵＥ上に存在するローカルＳＳＯサブシステムをバイパスし得る。例えば、ＮＡＦログイン資格証明書が十分である場合、ユーザは、サービスへのアクセスを獲得し得る。例示的な実施形態では、ユーザは、ログイン資格証明書をＮＡＦに事前に登録しておくことが仮定され得る。アクセス承諾の代替案では、ＮＡＦは、図６のステップ６１８のように、４０１ 無認可ダイジェストチャレンジを用いて応答し得、ＧＢＡを使用するブートストラップが実行されることを主張し得る。そのような例では、ユーザは、ＮＡＦがダイジェスト応答内のＫｓ＿ＮＡＦを確認するまで（例えば、図６のステップ６３８、６４０）、サービスへのアクセスを獲得し得ない。

別の例示的な実施形態では、ＧＢＡ認証は、分割端末シナリオにおいて、ローカルユーザログイン資格証明書と組み合わされる。例えば、ブラウジングエージェントは、モバイルデバイスを介して無線でネットワークへのアクセスを獲得し得るデスクトップコンピュータ内に存在し得る。モバイルデバイス（例えば、ＷＴＲＵ、ＵＥなど）は、コンピュータから物理的に分離され得る。例えば、エンティティは、（例えば、ＵＳＢケーブルまたはＢｌｕｅｔｏｏｔｈ接続を用いて確立された）ローカルリンク上で通信し得る。そのようなリンクは、（例えば、その全体が参照により本明細書に組み込まれ、あたかも説明がなされたかのように見なされる、文献（例えば、非特許文献７参照）において概説されているように）デスクトップとモバイルデバイスの間で共有秘密鍵（例えば、Ｋｓ＿ｌｏｃａｌ＿ｄｅｖｉｃｅ）を確立することによって、安全にされ得る。そのような安全なリンクがない場合、この構成は、中間者（ＭｉｔＭ）攻撃にさらされ得る。このプロトコル実施形態では、ユーザは、ＮＡＦに直接ログインし得る。ＮＡＦは、最初、（例えば、インターネット接続上で直接）デスクトップからユーザを登録し得る。分割端末構成では、モバイルデバイスを介してブラウザと通信するＮＡＦは、登録からクッキを見ることができず、かつ／または例えば、ユーザによって入力された資格証明書を介して「予備」認証が行われた場合であっても、より強力な認証を今では必要とし得る。例示的な分割端末シナリオは、その全体が参照により本明細書に組み込まれ、あたかも説明がなされたかのように見なされる、文献（例えば、非特許文献８参照）においてさらに説明される。

別の例示的な分割端末実施形態によれば、ＮＡＦは、それがブラウザに送信するセッションＩＤを生成し得る。セッションＩＤは、ログインが行われたサービスを求める最初のＨＴＴＰ要求に続いて、送信され得る。例えば、セッションＩＤは、セッションを統合するのに役立ち得る（例えば、要求されるサービスへのアクセスが承諾される時までに、別々のエンティティが認証に関与させられ得る）。セッションＩＤは、例えば、ブラウザからモバイル（例えば、ＧＢＡクライアント）にローカルリンクを横断して転送され得るので、デスクトップとモバイルデバイスの両方に知られ得る。ＮＡＦは、ブートストラップが必要とされることを示し得る（例えば、ＧＢＡを使用し得る）。モバイルデバイスは、モバイルネットワークを用いてＧＢＡ認証を実行し得、その結果は、ブートストラップされたアプリケーション固有の鍵Ｋｓ＿ＮＡＦを含み得る。ＢＳＦ／ＨＳＳエンティティが、デスクトップを見ずに、モバイルデバイスを見ることができるように、ＧＢＡが実行され得る。ブラウザが、そのダイジェスト応答をＮＡＦに提供する場合、例えば、それは、セッションＩＤおよびＢ−ＴＩＤを含み得る。セッションＩＤは、ブラウザとＮＡＦの間で確立された元のセッションに、（例えば、モバイルデバイスを認証し得る）ＧＢＡを結び付ける効果を有し得る。例えば、ＮＡＦは、ネットワークからＫｓ＿ＮＡＦを取り出した後、ブラウザを認証し得る。

また別の例示的な実施形態では、セッションＩＤが、ＧＢＡプロセスに関与させられ得る。例えば、初期ログインは、ユーザを弱く認証し得、その後のダイジェスト応答が、ブラウザ（例えば、Ｂ−ＴＩＤおよびＫｓ＿ＮＡＦ／ダイジェストをＮＡＦに提供する責任があるエンティティ）をより強力に認証し得る。したがって、例えば、ＢＳＦは、ブートストラップを求める要求が行われた場合、モバイルデバイス（例えば、ＧＢＡモジュール）からセッションＩＤを受信し得る。ＮＡＦは、ＢＳＦにＫｓ＿ＮＡＦを要求する場合、セッションＩＤ、Ｂ−ＴＩＤ、およびＮＡＦ ＩＤを使用し得る。例えば、例示的なシナリオに従ってＧＢＡプロセスに関与させられたモバイルデバイスは、ＮＡＦとブラウザの間で確立されたセッションに結び付けられ得る。そのような実施形態におけるダイジェスト認証は、ブラウザのみを認証する代わりに、分割端末全体を認証し得る。

また別の例示的な実施形態では、ネットワークによって制御されるユーザ認証は、変更されたＧＢＡプロトコルに結合され得る。例えば、ユーザ認証資格証明書は、デバイススマートカード（例えば、ＵＩＣＣ）がモバイルネットワーク内のＨＳＳと共有し得る、利用契約資格証明書と統合され得る。図６のステップ６２４を参照すると、ネットワークは、ユーザの認証に参加し得る。そのようなユーザ認証は、ブートストラップに統合され得る。例えば、結果のブートストラッププロトコルは、ユーザ認証資格証明書がデバイス認証応答およびブートストラップされた鍵生成に結合される、変更されたＧＢＡプロトコルを説明し得る。例示的な実施形態では、この方法におけるユーザ認証へのネットワークの参加は、ＮＡＦ保証レベル要件によって促され得る。図７は、例示的なブートストラッププロトコルの詳細を説明している。他の詳細は、本明細書でＴＳ３３．２２０と呼ばれることがあり、その全体が参照により本明細書に組み込まれ、あたかも説明がなされたかのように見なされる、文献（例えば、非特許文献９参照）において提供される。

図７は、例示的な実施形態による、ユーザ認証資格証明書をＧＢＡと結合するためのシステム７００のフロー図である。図７を参照すると、システム７００は、ネットワークを介して通信する、ＵＥ７０２と、ＢＳＦ７０４と、ＨＳＳ／ＨＬＲ７０５とを含む。ＲＡＮＤ、ＡＵＴＮ、ＸＲＥＳ、ＲＥＳ ＣＫ、ＩＫとして表されるパラメータが、文献（例えば、非特許文献９参照）において定義される。説明的な実施形態によれば、７０６において、ＵＥ７０２は、ＨＴＴＰメッセージを用いて、ブートストラップするようにＢＳＦ７０４に要求する。そのようなメッセージは、加入者識別情報（ＩＭＰＩ）およびトークンを含み得る。トークンは、ユーザがローカルで（例えば、ＵＥ７０２で）認証された旨の表示をＢＳＦ７０４に提供し得る。７０８において、ＢＳＦ７０４は、ＩＭＰＩを使用して、ＨＳＳ７０５から認証ベクトル（ＡＶ）およびＧＢＡユーザセキュリティ設定を取り出し得る。ＡＶは、ＲＡＮＤ、ＡＵＴＮ、ＸＲＥＳ、ＣＫ、ＩＫ、ならびにユーザ入力識別情報（例えば、ユーザ名）およびユーザのＰＩＮまたはパスワードを含み得る。７１０において、ＢＳＦ７０４は、ＲＡＮＤ、ＡＵＴＮ、ならびに結合インジケータおよび結合アルゴリズム（例えば、ハッシュアルゴリズム）を、例えば、４０１メッセージに収めて、ＵＥ７０２に転送する。結合インジケータは、ブートストラップ応答が、ユーザ入力資格証明書（例えば、ＵＮおよびＰＷでそれぞれ表されるユーザ名およびパスワード）をＲＥＳと結合すべきことを、ＵＥ７０２に通知し得る。７１２において、ＵＥ７０２は、ＢＳＦ７０４からの結合要求を満たし得る、ＲＥＳ、ＣＫ、ＩＫ、およびハッシュｈ（ＲＥＳ、ＵＮ、ＰＷ）を計算し得る。７１４において、ＵＥは、ＲＥＳおよびｈ（ＲＥＳ、ＵＮ、ＰＷ）を含み得るＨＴＴＰ要求をＢＳＦ７０４に送信し得る。説明的な実施形態によれば、７１６において、ＢＳＦ７０４は、ＲＥＳをＸＲＥＳと比較し、一致するかどうかを決定することによって、ＵＥ７０２を認証し得る。ユーザ認証は、ハッシュ値ｈ（ＲＥＳ、ＵＮ、ＰＷ）とＢＳＦ７０４によって計算される対応するハッシュの間の一致を決定することによって、確認され得る。ステップ７１８、ステップ７２０、およびステップ７２２は、文献（例えば、非特許文献９参照）において説明されるように実施され得る。

例示的な実施形態では、Ｋｓは、ＣＫ、ＩＫ、およびユーザ資格証明書から導出される、認証結合鍵を含み得る。代替的実施形態では、認証結合鍵Ｋｓの導出において、ユーザ資格証明書および加入者資格証明書を必要とし得る、結合メカニズムが使用される。例えば、ＣＫ｜｜ＩＫ｜｜ＵＳＥＲ＿ＣＲＥＤＥＮＴＩＡＬＳなどの連結が、２５６ビットサイズを超え得る鍵を生成し得る。ＵＳＥＲ＿ＣＲＥＤＥＮＴＩＡＬＳは、ユーザ名およびパスワードの組み合わせであり得る。より大きなビット列を２５６ビットにまで圧縮するハッシュが、鍵を導出するために使用され得る。例えば、ＳＨＡ−２５６ハッシュ関数が使用され得る。関数の場合、導出される鍵のために、ＡＢＫ＝Ｋｓ＝ＳＨＡ−２５６（ＣＫ｜｜ＩＫ｜｜ＵＳＥＲ＿ＣＲＥＤＥＮＴＩＡＬＳ）が獲得され得る。ＢＳＦは、Ｋｓ＿ＮＡＦがそれから導出され得るＫｓが、ＣＫ、ＩＫ、およびユーザ資格証明書を利用する結合鍵を含むことを、ＮＡＦに示し得る。

別の例示的な変形では、ユーザ認証は、ＥＡＰに基づき得るが、デバイス認証のためには、ＧＢＡが使用され得る。例えば、ＭＳＫ＿ｕは、ＥＡＰ認証の一環として導出されるＭＳＫを含み得、５１２ビットの長さを含み得る。使用されるＥＡＰ認証プロトコルは、例えば、ＥＡＰ−ＴＴＬＳ、または知識ベースの認証を使用する他の任意のＥＡＰであり得る。デバイス認証は、ＧＢＡを使用して実施され得る。デバイス認証の一環として生成されるＫｓ＿ＮＡＦは、２５６ビット長であり得る。例示的な実施形態では、Ｋｓ＿ＮＡＦは、５１２ビットの長さを含むように暗号化して生成され得る。ＭＳＫ＿ｕとＭＳＫ＿ｄ＝Ｋｓ＿ＮＡＦが一緒に結合され得る。

また別の変形では、ユーザ認証は、ＧＢＡダイジェストに基づき得るが、デバイス認証のためには、ＥＡＰベースのプロトコルが使用され得る。例えば、デバイス認証は、ＥＡＰ−ＳＩＭ／ＡＫＡ／ＡＫＡ’、ＥＡＰ−ＴＬＳに基づき得、ＥＡＰ認証プロトコルとして、ＥＡＰ−ＦＡＳＴが使用され得る。そのような実施形態では、ＧＢＡダイジェストプロトコルの一環として、ＭＳＫ＿ｕ＝Ｋｓ＝ＫＤＦ（Ｈ（Ａ１），“ＧＢＡ＿Ｄｉｇｅｓｔ＿Ｋｓ”，ＴＬＳ＿ＭＫ＿Ｅｘｔｒ，ＲＥＳＰ）が生成され得、一方、ＥＡＰプロトコルの一環として、ＭＳＫ＿ｄ＝ＭＳＫが導出され得る。

また別の実施形態では、ユーザ認証は、ＥＡＰ−ＴＴＬＳ、および／またはユーザ認証のためにバイオメトリック値が使用され得る他のＥＡＰプロトコルを使用して実施され得、一方、ＥＡＰ−ＳＩＭ、ＥＡＰ−ＡＫＡ、ＥＡＰ−ＡＫＡ’、またはデバイス認証のために使用され得る他のＥＡＰ方法が、デバイス認証を実行するために使用され得る。

ユーザ認証のために、ＯｐｅｎＩＤまたはＯｐｅｎＩＤコネクトなどが使用され得、一方、デバイス認証は、デバイス認証のために使用されるＧＢＡまたはＥＡＰプロトコルに基づき得るが、実施形態は、望ましければ、変化し得ることが理解されよう。例示的な実施形態では、認証のために、ユーザｉｄおよびパスワードが、ＯｐｅｎＩＤ識別情報プロバイダ（ＯＰ）とともに使用されるが、デバイス認証のためには、ＧＢＡが使用される。ＥＡＰ−ＳＩＭ／ＡＫＡプロトコルを使用するＯｐｅｎＩＤに基づいた他の変形が、デバイスを認証し、別々のＯｐｅｎＩＤ／ＯｐｅｎＩＤコネクトプロトコルが、ユーザ認証を実行する。したがって、そのようなユーザ認証およびデバイス認証が実施され、２ファクタ認証のために一緒に結合され得る。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例示的な実施形態では、ＷＴＲＵ８０２は、プロセッサ８１８と、プロセッサに結合されたメモリとを含む。メモリは、プロセッサによって実行されたときに、オンデマンドの資格証明書の準備供給に関連付けられた操作をプロセッサに実施させる実行可能命令を含む。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. 前記アサーションは、否定的アサーションであり、および前記否定的アサーションに基づくアクセスは、前記リソースへの制限されたアクセス、または前記リソースへのアクセス不可であることを特徴とする請求項２４に記載のＷＴＲＵ。