JP2014519634A - 複数のｓｓｏ技術のためのｓｓｏフレームワーク - Google Patents

Abstract

ユーザは、クレデンシャルのプロビジョニングにおけるユーザ対話が最小に保たれ、さらには完全に解消される、インターネットサービスにアクセスするための使用可能なセキュリティまたはシームレスな手段を望む。シングルサインオンアイデンティティ管理概念は、所望のサービスへのアクセスのためのユーザアシスト型認証およびネットワークアシスト型認証を可能にする。ユーザへのシームレスな認証サービスを可能にするために、統合されたフレームワークと、複数の認証方法を管理するためのプロトコル層インターフェースとが使用される。ユーザ機器、ＵＥは、サービスプロバイダと通信して、サービスにアクセスするように構成されたユーザアプリケーション（２０２、２０４）と、複数のネットワークアシスト型認証モジュール（２０８ないし２１６）とを具え、各ネットワークアシスト型認証モジュールは、異なるネットワークアシスト型認証プロトコルに対応する。ＵＥは、ＵＥのユーザを、ＵＥおよび／またはネットワークにおいてユーザアシスト型認証情報に基づいて認証するように、および、ネットワークアシスト型認証モジュールのうちの１つを、もう１つのポリシーに基づいて選択するように構成された、シングルサインオンサブシステム（２０６）をさらに具える。

Description

本発明は、複数のＳＳＯ技術のためのＳＳＯフレームワークに関する。

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

モバイルユーザセキュリティ要件は、インターネットサービスへのスマートフォンアクセスの使用が増大しつつあるために、増大している。例えば、バンキングサービス、エンターテインメントイベントのための自動券売サービスなどは、完全性、機密性保護、およびユーザ認証を必要とする。そのような要件は、ユーザ名、ＰＩＮ、およびパスワードの形態で、認証の負担をユーザに直接かける。しかし、それぞれについて別々の、ユーザにより提供されたクレデンシャルを有する多数のアカウントを所有することは、ユーザに、例えばクレデンシャル疲労の点で過度の認証負担をかける。ユーザが、思い出すことが容易であるクレデンシャルを使用することによって、または、２つ以上のドメインにわたって同じクレデンシャルを再使用することによって、このプロセスを簡略化しようと試みた場合、そのユーザは、セキュリティ脆弱性を生み出す。

３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ （３ＧＰＰ） Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ （ＴＳ） ｎｕｍｂｅｒ ３３．２２０ （ｒｅｌｅａｓｅ １０） ３ＧＰＰ Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ （ＴＲ） ｎｕｍｂｅｒ ３３．９２４ （ｒｅｌｅａｓｅ ９） ３ＧＰＰ ＴＲ ３３．９１４ （ｒｅｌｅａｓｅ １１） Ａｌｃａｔｅｌ−Ｌｕｃｅｎｔ ｐＣＲ Ｓ３−１００７５７ ｉｎ ３ＧＰＰ ＳＡ３ ｈｔｔｐ：／／ｃｏｄｅ．ｇｏｏｇｌｅ．ｃｏｍ／ｉｎｔｌ／ｄｅ−ＤＥ／ａｐｉｓ／ｉｄｅｎｔｉｔｙｔｏｏｌｋｉｔ／ｖｌ／ｏｐｅｎｉｄ．ｈｔｍｌ

本発明では、ユーザにとって柔軟および／またはシームレスな体験を可能にする、総合的なシングルサインオン（ＳＳＯ）アーキテクチャを提供する。すなわち、統合されたユーザインターフェースを通して、モバイルユーザのための複数の認証方法を管理するための、統合されたフレームワークと、異なる認証プロトコルのためのプロトコル層インターフェースとを開示する。

この概要は、詳細な説明において以下でさらに説明される様々な概念を、簡略化された形態で導入するために提供される。この概要は、特許請求の範囲に記載された主題の主要な特徴または必須の特徴を識別するものでも、特許請求の範囲に記載された主題の範囲を限定するために使用されるものでもない。

本明細書で開示されるものは、統合されたユーザインターフェースを通して、モバイルユーザのための複数の認証方法を管理するための、統合されたフレームワークと、異なる認証プロトコルのためのプロトコル層インターフェースとである。統合されたフレームワークとプロトコル層は共に、エンドユーザへのシームレスな認証サービスを可能にする。さらに、複数のサービスプロバイダをサポートする複数のアクセスドメインを含む実施形態もまた開示される。

本明細書で説明される実施形態は、ユーザにとって柔軟および／またはシームレスな体験を可能にする、総合的なシングルサインオン（ＳＳＯ）アーキテクチャを提供する。ユーザ認証インターフェースは、ユーザ／アプリケーションエンティティ（例えば、ブラウザまたは非ブラウザアプリケーション）とＳＳＯサブシステムとの間の境界として働く。例示的実施形態では、ＳＳＯサブシステムは、移動体通信事業者（ＭＮＯ）によって制御される。ＳＳＯサブシステムは、例えば、バイオメトリクス、パスワード、ＰＩＮ、および／または他のユーザクレデンシャル入力など、様々なユーザ多要素クレデンシャル入力をサポートする。ユーザ認証インターフェースはまた、変化する認証強度レベルをも提供する。ネットワーク認証インターフェースは、ＳＳＯサブシステムと、単一の構造フレームワーク内にいくつかのＳＳＯ機構を収容することを可能にする数々のネットワークアシスト型認証技術またはプロトコルモジュールとの間の境界として働く。機能的構造は、例えば、ＯｐｅｎＩＤリライングパーティ（ｒｅｌｙｉｎｇ ｐａｒｔｉｅｓ）などサービスプロバイダと認証しながら、ネットワークアシスト型認証（例えば、ＳＳＯネットワークアシスト型認証）からのユーザアシスト型認証の分離を実現する。

例示的実施形態では、ユーザ機器（ＵＥ）は、サービスプロバイダと通信して、サービスにアクセスするように構成された、ユーザアプリケーションを具える。ＵＥは、複数のネットワークアシスト型認証モジュールをさらに具える。各ネットワークアシスト型認証モジュールは、異なるネットワークアシスト型認証プロトコルに対応する。例えば、ネットワークアシスト型認証モジュールは、サービスプロバイダとネットワークアシスト型認証を行って、サービスにアクセスするように構成される。ＵＥは、ＵＥのユーザを、ＵＥおよび／またはネットワークにおいてユーザアシスト型認証情報に基づいて認証するように構成された、シングルサインオン（ＳＳＯ）サブシステムをさらに具える。ＳＳＯサブシステムは、サービスプロバイダとネットワークアシスト型認証を行うために複数のネットワークアシスト型認証モジュールのうちのネットワークアシスト型認証モジュールを選択するようにさらに動作する。ＳＳＯサブシステムは、ユーザアシスト型認証を行い、ネットワークアシスト型認証モジュールを、もう１つのポリシーに基づいて選択するようにさらに構成される。別の例示的実施形態では、ＵＥは、サービスプロバイダの１または複数のデータフィールドを検出する。データフィールドを検出することに応答して、ＵＥのサプリカントは、データフィールドを、対応する認証データを用いて自動的にポピュレートする。

本明細書で説明されるシステム、方法、および手段の他の特徴は、以下の詳細な説明および添付の図面において提供される。

１または複数の開示された実施形態が実施される、例示的な通信システムのシステム図である。 図１Ａに示された通信システム内で使用される、例示的な無線送信／受信ユニット（ＷＴＲＵ）のシステム図である。 図１Ａに示された通信システム内で使用される、例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 複数のＳＳＯ技術の使用のためのアーキテクチャのフレームワークの例示的実施形態を示す図である。 ＳＳＯフレームワークアーキテクチャのためのプロトコルフローの例示的実施形態を示す図である。 ＳＳＯフレームワークアーキテクチャのためのプロトコルフローの例示的実施形態を示す図である。 複数のＳＳＯプロトコルの使用のためのアーキテクチャのフレームワークの別の例示的実施形態を示す図である。 例示的実施形態による、ＧＢＡインターワーキングを使用する例示的ＳＳＯサブシステムのブロック図である。 複数のＳＳＯプロトコルの使用を容易にするためのダウンロード可能コンポーネントを具える、アーキテクチャのフレームワークの例示的実施形態を示す図である。 インターフェースコンポーネントをもつＳＳＯシステムの例示的実施形態のブロック図を示す図である。 サプリカントを用いた、ＳＳＯフレームワークアーキテクチャのためのプロトコルフローの例示的実施形態を示す図である。 ローカルアサーションエンティティ（ｌｏｃａｌ ａｓｓｅｒｔｉｏｎ ｅｎｔｉｔｙ）（ＬＡＥ）を用いた、ＳＳＯフレームワークアーキテクチャのためのプロトコルフローの例示的実施形態を示す図である。 統合されたＯＰを用いた、ＳＳＯフレームワークアーキテクチャのためのプロトコルフローの例示的実施形態を示す図である。 プリフェッチングを用いた、ＳＳＯフレームワークアーキテクチャのためのプロトコルフローの例示的実施形態を示す図である。 サービスプロバイダにおいて記憶されたＪａｖａ（登録商標）アプレットを用いた、ＳＳＯフレームワークアーキテクチャのためのプロトコルフローの例示的実施形態を示す図である。 キャッシュされたＪａｖａアプレットを用いた、ＳＳＯフレームワークアーキテクチャのためのプロトコルフローの例示的実施形態を示す図である。 オンザフライプロビジョニングを用いた、ＳＳＯフレームワークアーキテクチャのためのプロトコルフローの例示的実施形態を示す図である。 統合されたツールキットを用いた、ＳＳＯフレームワークアーキテクチャのためのプロトコルフローの例示的実施形態を示す図である。

例えば、モバイルユーザなどのユーザは、クレデンシャルのプロビジョニングにおけるユーザ対話が最小限に抑えられ、さらには完全に解消される、インターネットサービスにアクセスするための使用可能なセキュリティおよび／またはシームレスな手段を望む。例示的実施形態では、シングルサインオン（ＳＳＯ）アイデンティティ管理（ＩｄＭ）は、様々な特徴をもつＳＳＯ実装形態を提供するための手段を含み、それによって、所望のサービスへのアクセスのためにユーザアシスト型認証およびネットワークアシスト型認証を可能にしながら、ユーザにはそのような使いやすさが与えられる。ユーザアシスト型認証は、ユーザからの入力が使用される認証を指す。そのようなユーザ入力は、半自動化され（例えば、ブラウザにおいて記憶され）、またはユーザによって入力される。例えば、ユーザアシスト型認証は、ユーザが知っているパラメータ（例えば、ユーザ名、パスワード）、および／または、ユーザの特徴（例えば、動的署名、虹彩スキャン、指紋、または他のバイオメトリック測定）に基づく。ネットワークアシスト型認証は、ユーザが所有するエンティティ（例えば、暗号鍵とプロトコルとを具えるＵＩＣＣ）に基づく、ユーザ認証を指す。例えば、ネットワークアシスト型認証は、ネットワークアクセスのためにネットワークオペレータによって提供されるファンクション（例えば、汎用ブートストラッピングアーキテクチャ（ＧＢＡ）プロトコル）の再使用による、ユーザのＳＳＯ認証を指す。例えば、ＧＢＡは、セルラネットワークおよび／またはＩＭＳへのアクセスを提供する、（例えば、ＵＩＣＣにおける）秘密鍵およびプロトコルの再使用に基づくＳＳＯ認証を生成する。各ユーザアシスト型認証入力およびネットワークアシスト型認証入力は、認証ファクタと呼ばれる。ＳＳＯ実装形態の様々な特徴は、例えば、シームレスな認証ファクタを用いたＳＳＯ、単一のクレデンシャルセットを用いたＳＳＯ、および完全なＳＳＯを含む。シームレスな認証ファクタを用いたＳＳＯは、成功したユーザアシスト型認証後、自動的に（例えば、ユーザ対話なしに）進行する、ネットワークアシスト型ユーザ認証を指す。単一のクレデンシャルセットを用いたＳＳＯは、ユーザが（例えば、ユーザアシスト型認証のための）単一のセットのクレデンシャルを使用して、複数のサービスプロバイダと認証する、実装形態を指す。例示的実施形態では、単一のセットのクレデンシャルは、ユーザが異なるサービスプロバイダにアクセスするたびに提供される。完全なＳＳＯ実装形態を使用する例示的実施形態では、ユーザは、サービスプロバイダへのアクセスのために認証され、続いて、再び認証するように促されることなく、他のサービスプロバイダへのアクセスを得る。例えば、完全なＳＳＯ実装形態は、シームレスな認証ファクタを用いたＳＳＯを含む。

本明細書で説明されるものは、統合されたユーザインターフェースを通して、モバイルユーザのための１または複数の認証方法を管理するための、統合されたフレームワークと、異なる認証プロトコルのためのプロトコル層インターフェースとである。統合されたフレームワークとプロトコル層は共に、エンドユーザに対するシームレスな認証サービスを可能にする。さらに、複数のサービスプロバイダをサポートする複数のアクセスドメインを含む実施形態もまた説明される。

本明細書で説明される実施形態は、ユーザにとって柔軟および／またはシームレスな体験を可能にする、総合的なＳＳＯアーキテクチャを提供する。ユーザ認証インターフェースは、ユーザ／アプリケーションエンティティ（例えば、ブラウザまたは非ブラウザアプリケーション）とＳＳＯサブシステムとの間の境界として働く。例示的実施形態では、ＳＳＯサブシステムは、移動体通信事業者（ＭＮＯ）によって制御される。ＳＳＯサブシステムは、例えば、バイオメトリクス、パスワード、ＰＩＮ、および／または他のユーザクレデンシャル入力など、様々なユーザ多要素クレデンシャル入力をサポートする。ユーザ認証インターフェースはまた、変化する認証強度レベルをも提供する。ネットワーク認証インターフェースは、ＳＳＯサブシステムと、単一の構造フレームワーク内にいくつかのＳＳＯ機構を収容することを可能にする数々のネットワークアシスト型認証技術またはプロトコルモジュールとの間の、境界として働く。機能的構造は、ネットワークアシスト型認証（例えば、ＳＳＯネットワークアシスト型認証）からのユーザアシスト型認証の分離を実現する。

ＳＳＯサブシステムは、ユーザクレデンシャルの記憶および／または処理を提供し、そこで、そのような記憶は、信頼されたコンピューティング環境（例えば、ＵＩＣＣ、スマートカード、または他の安全な信頼された環境）上であるか、またはそこから離れており、複数のセキュリティレベルを提供する。信頼されたコンピューティング環境上に含まれた記憶は、ユーザクレデンシャルの再使用をサポートする。ＳＳＯサブシステムは、実施するべきセキュリティレベルを決定すること、および、使用するべきＳＳＯプロトコルを判断することにおいて、外部利害関係者（例えば、ＭＮＯ）のファンクションおよび／またはポリシーを実行することにおいて、プロキシとして働く。実装形態の観点から、安全な信頼された環境（例えば、ＵＩＣＣ、スマートカード、または他の安全な信頼された環境）上に、またはそれから離れて位置するための、いかなるＳＳＯファンクションの間引きもない。

例示的実装形態は、別々の、隔離されたＳＳＯクライアントを提供する。例示的実施形態では、各ＳＳＯクライアントは、異なるサービスプロバイダに、しかし、同じプロバイダによって同時に提供された複数の利用可能な接続プロトコルおよび／またはサービスの、ポリシーベースの管理を可能にする方法でサービスする。

別の例示的実装形態は、多数のローカルアサーションエンティティ（ＬＡＥ）を可能にする。ＬＡＥは、ＵＥ上に配置された機能的エンティティを指す。例えば、ＬＡＥは、ユーザアイデンティティおよび／または認証についての信頼されたアサーションをリモートエンティティに提供する。例示的実施形態では、ローカルＯＰは、ＯｐｅｎＩＤアサーションをＲＰに提供するためのＬＡＥのインスタンス化を指す。各ＬＡＥは、ＵＩＣＣ上でアクセス技術固有のドメインにおいて実装され、それぞれは、１つの隔離されたドメイン専用にされる。同じアクセス技術が異なるＬＡＥ間で多重化され、または、異なるアクセス技術がＬＡＥによって同時に使用される。実装形態に応じて、ＬＡＥとＳＳＯクライアントとの間の関係は１対１であり、または、そこで、１つのＳＳＯクライアントが複数のＬＡＥを制御し、またはそれら複数のＬＡＥによってサービスされる。

本明細書で説明される実施形態は、無線デバイスにおける認証プロトコルの実行を容易にする。例えば、サプリカントは、例えば、リライングパーティ（ＲＰ）またはＯｐｅｎＩＤアイデンティティプロバイダサーバ（ＯＰ）など、無線デバイスおよびネットワークエンティティのためのＯｐｅｎＩＤ認証プロセスの実行を容易にするために使用される。例示的実施形態によれば、サプリカントは、Ｊａｖａ（登録商標）アプレットとして実装される。サプリカントは、ＯｐｅｎＩＤ認証などの認証方式のために使用されるべき、非ブラウザアプリケーションまたはブラウザアプリケーションによってネイティブにサポートされない、ネットワークアシスト型認証機構を可能にする。例えば、サプリカントは、シングルサインオン（ＳＳＯ）サブシステムとインターフェースし、ＳＳＯサブシステムは次に、ＧＢＡ、ＡＫＡ、ＳＩＰダイジェスト、およびＥＡＰ−ＳＩＭなど、ネットワークアシスト型認証プロトコルにインターフェースする。例えば、スマートフォンプラットフォームなど、モバイルデバイス上で利用可能な、広範囲のプラットフォームプロセッサアーキテクチャ、オペレーティングシステム、およびソフトウェアが与えられると、サプリカントは、ネットワーク認証インターフェースを、ＳＳＯ認証ファンクションを実行するＳＳＯサブシステムに提供する。サプリカントは、例えば、アプリケーションおよび／またはブラウザが、ネットワークおよび／またはアクセス層認証モジュール（例えば、ＧＢＡモジュール、ＵＩＣＣ）と共に相互動作しながら、自動化されたおよび／またはシームレスな認証を容易にすることを、可能にする。ＲＰおよび／またはＯＰからサプリカント部分をダウンロードすることによって、例えば、サプリカントは、ＯｐｅｎＩＤ認証プロトコル中にシームレスにデバイス固有のソフトウェアを提供する。

本明細書で説明される実施形態は、ＯｐｅｎＩＤなど、連携型認証プロトコルと共に機能し、また、例えば、ＬＡＥと共に機能する。例えば、ＯｐｅｎＩＤは、ネットワークアシスト型認証にバインドされる。本明細書で説明される実施形態は、ブラウザおよび／または非ブラウザアプリケーションがどのようにアクセス層（例えば、ＵＩＣＣ／非ＵＩＣＣ）ネットワークアシスト型認証機構と通信するかを決定するために使用される。例えば、サプリカントおよびＳＳＯサブシステムは、ブラウザおよび／または非ブラウザアプリケーションと、ネットワークアシスト型認証機構とを用いた、自動化および／またはシームレスな動作を提供する。サプリカントは、統合されたインターフェースをＳＳＯサブシステムに提示し、様々な認証プロトコル（例えば、ＧＢＡ、ＡＫＡ、ＥＡＰ−ＳＩＭ）のために、ユーザに代わって、自動化された、および／またはシームレスな認証を行う。例えば、署名されたＪａｖａアプレットなど、ダウンロード可能なアプリケーションまたはコンポーネントが、（例えば、ＲＰおよび／またはＯＰから）ダウンロードされ、異なる非アプリケーション層および／またはアクセス層認証プロトコルと共に作動する。コンポーネントは、ＳＳＯサブシステムと、およびブラウザ／アプリケーションと、一定の方法でインターフェースする。

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

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

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

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

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

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

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

他の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、ワールドワイドインターオペラビリティフォーマイクロウェーブアクセス（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ（登録商標））、ＧＳＭ進化型高速データレート（ＥＤＧＥ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）など、無線技術を実装する。

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

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

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

通信システム１００におけるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部または全部は、マルチモード能力を含み、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンク上で異なる無線ネットワークと通信するための複数のトランシーバを含む。例えば、図１Ａに示されたＷＴＲＵ１０２ｃは、セルラベースの無線技術を採用する基地局１１４ａと、および、ＩＥＥＥ８０２無線技術を採用する基地局１１４ｂと通信するように構成される。

図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８と、トランシーバ１２０と、送信／受信素子１２２と、スピーカ／マイクロフォン１２４と、キーパッド１２６と、ディスプレイ／タッチパッド１２８と、非取外し式メモリ１３０と、取外し式メモリ１３２と、電源１３４と、全地球測位システム（ＧＰＳ）チップセット１３６と、他の周辺機器１３８とを含む。ＷＴＲＵ１０２は、実施形態と矛盾しないままで、前述の要素の任意の部分組み合わせを含むことが理解される。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、また、ＤＳＰコア、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態機械などに関連する、１または複数のマイクロプロセッサである。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入力／出力処理、および／または、ＷＴＲＵ１０２が無線環境において動作することを可能にする任意の他の機能性を行う。プロセッサ１１８は、トランシーバ１２０に結合され、それは、送信／受信素子１２２に結合される。図１Ｂは、プロセッサ１１８およびトランシーバ１２０を別々のコンポーネントとして示すが、プロセッサ１１８およびトランシーバ１２０は、電子パッケージまたはチップにおいて共に統合されることが理解される。

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

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

トランシーバ１２０は、送信／受信素子１２２によって送信されるべきである信号を変調するように、および、送信／受信素子１２２によって受信される信号を復調するように構成される。上記で述べられたように、ＷＴＲＵ１０２は、マルチモード能力を有する。したがって、トランシーバ１２０は、ＷＴＲＵ１０２が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１など、複数のＲＡＴを介して通信することを可能にするための、複数のトランシーバを含む。

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

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

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

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

図１Ｃは、実施形態によるＲＡＮ１０４およびコアネットワーク１０６のシステム図である。上記で述べられたように、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を採用して、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信する。ＲＡＮ１０４はまた、コアネットワーク１０６とも通信している。

ＲＡＮ１０４は、ｅノード−Ｂ１４０ａ、１４０ｂ、１４０ｃを含むが、ＲＡＮ１０４は、実施形態と矛盾しないままで、任意の数のｅノード−Ｂを含むことが理解される。ｅノード−Ｂ１４０ａ、１４０ｂ、１４０ｃは、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための、１または複数のトランシーバをそれぞれ含む。一実施形態では、ｅノード−Ｂ１４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯ技術を実装する。したがって、ｅノード−Ｂ１４０ａは、例えば、複数のアンテナを使用して、無線信号をＷＴＲＵ１０２ａへ送信し、無線信号をＷＴＲＵ１０２ａから受信する。

ｅノード−Ｂ１４０ａ、１４０ｂ、１４０ｃのそれぞれは、特定のセル（図示せず）に関連付けられ、無線リソース管理判断、ハンドオーバ判断、アップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを扱うように構成される。図１Ｃに示されるように、ｅノード−Ｂ１４０ａ、１４０ｂ、１４０ｃは、Ｘ２インターフェース上で互いに通信する。

図１Ｃに示されたコアネットワーク１０６は、モビリティ管理ゲートウェイ（ＭＭＥ）１４２と、サービングゲートウェイ１４４と、パケットデータネットワーク（ＰＤＮ）ゲートウェイ１４６とを含む。前述の要素のそれぞれは、コアネットワーク１０６の一部として示されるが、これらの要素のいずれか１つは、コアネットワークオペレータ以外のエンティティによって所有および／または操作されることが理解される。

ＭＭＥ１４２は、Ｓ１インターフェースを介して、ＲＡＮ１０４におけるｅノード−Ｂ１４２ａ、１４２ｂ、１４２ｃのそれぞれに接続され、制御ノードとして働く。例えば、ＭＭＥ１４２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの最初の取り付け中に特定のサービングゲートウェイを選択することなどを担う。ＭＭＥ１４２はまた、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなど、他の無線技術を採用する他のＲＡＮ（図示せず）との間で切り替えるための、制御プレーンファンクションをも提供する。

サービングゲートウェイ１４４は、Ｓ１インターフェースを介して、ＲＡＮ１０４におけるｅノードＢ１４０ａ、１４０ｂ、１４０ｃのそれぞれに接続される。サービングゲートウェイ１４４は一般に、ユーザデータパケットをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃへ／からルーティングおよび転送する。サービングゲートウェイ１４４はまた、ｅノードＢ間ハンドオーバ中のユーザプレーンのアンカリング、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのために利用可能であるときのページングのトリガリング、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストの管理および記憶など、他のファンクションをも行う。

サービングゲートウェイ１４４はまた、ＰＤＮゲートウェイ１４６にも接続され、それは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、インターネット１１０など、パケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にする。

コアネットワーク１０６は、他のネットワークとの通信を容易にする。例えば、コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、ＰＳＴＮ１０８など、回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の固定電話通信デバイスとの間の通信を容易にする。例えば、コアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ１０８との間のインターフェースとして働くＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含み、または、それと通信する。さらに、コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、ネットワーク１１２へのアクセスを提供し、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運用される、他の有線または無線ネットワークを含む。

図２は、複数のＳＳＯプロトコルおよび／またはモジュールの使用のためのアーキテクチャのフレームワークの一実施形態を示す。図２に示されるように、ＳＳＯサブシステム２０６は、ブラウザアプリケーション２０２および／または非ブラウザアプリケーション２０４など、サービスプロバイダからのサービスにアクセスするように構成されたアプリケーションと通信している。アプリケーション（ブラウザアプリケーション２０２および非ブラウザアプリケーション２０４）は、ユーザがそれと対話するアプリケーションである。ブラウザアプリケーション２０２および／または非ブラウザアプリケーション２０４を使用して、ユーザは、様々なサービス（例えば、ウェブサイト、バンキングサービス、エンターテインメントイベントのための自動券売サービス、および／またはサービスプロバイダによって提供された他のサービス）へのアクセスを有する。

ＳＳＯサブシステム２０６は、ＳＳＯプロセスのためのハブとして働く。例示的実施形態では、ＳＳＯサブシステム２０６は、オペレータによって制御される。ＳＳＯサブシステム２０６は、ユーザ認証（例えば、ユーザアシスト型、および／またはネットワークアシスト型）を行うことによって、ネットワークプロキシとして働く。さらに、ＳＳＯサブシステム２０６は、ネットワークアシスト型認証のために、署名されたかまたは別法により信用できる、ユーザアイデンティティアサーションおよび／または認証アサーションの、後続の作成、および／または、サービスプロバイダおよび／またはアイデンティティプロバイダへの提出を行う。安全な記憶および処理など、ＳＳＯサブシステム２０６のファンクションのうちのいくつかは、安全な信頼された環境２１８内で実行される。

図２に示されたアーキテクチャは、ユーザアシスト型認証経験を、数々の個々の内蔵されたネットワークアシスト型認証技術（例えば、ＳＳＯ技術またはＳＳＯプロトコルまたはＳＳＯプロキシとも呼ばれる）と共に統合し、それらのうちのいくつかは、ネットワークアシスト型認証を使用して、認証および鍵交換のためのブートストラッピング機構を行う。例えば、ＳＳＯサブシステム２０６は、複数の認証モジュール２０８、２１０、２１２、２１４、および／または２１６と通信しており、それぞれは、異なるネットワークアシスト型認証プロトコルを使用して、サービスプロバイダとネットワークアシスト型認証を行うことが可能である。これらのネットワークアシスト型認証モジュール２０８、２１０、２１２、２１４、および／または２１６は、デジタル証明書などのプレインストールされたクレデンシャル、共有されたマスター秘密、または異なるサポートされた認証方式を用いた登録の任意の他の方法に基づいて、所望のサービスへの安全なユーザアクセスを提供するために使用される。例示的実施形態によれば、認証モジュールは、ＯｐｅｎＩＤ／ＳＩＰダイジェストモジュール２０８、別のＯｐｅｎＩＤモジュール２１０、ＯｐｅｎＩＤ／ＧＢＡモジュール２１２、ＯｐｅｎＩＤ／ＩＳＩＭモジュール２１４、および／またはＯｐｅｎＩＤ／ＡＫＡモジュール２１６を含む。図２に示されたネットワークアシスト型認証モジュールは、ＯｐｅｎＩＤネットワークアシスト型認証プロトコルをそれぞれ実装するが、他のタイプのネットワークアシスト型認証プロトコルも同じく、または、あるいは実装される。

ネットワークアシスト型認証モジュールのうちの１または複数は、所与のサービスプロバイダおよび／またはアイデンティティプロバイダによってサポートされる。各ネットワークアシスト型認証モジュールは、例えば、認証アルゴリズムを使用することによってなど、その対応する認証プロトコルを実装することによって、ネットワークアシスト型認証を行うように構成される。ＯｐｅｎＩＤ／ＧＢＡモジュール２１２、ＯｐｅｎＩＤ／ＩＳＩＭモジュール２１４、および／またはＯｐｅｎＩＤ／ＡＫＡモジュール２１６は、安全な信頼された環境２１８と通信している。安全な信頼された環境２１８は、例えば、ＵＩＣＣ、スマートカード、または他の安全な信頼された環境を含む。例示的実施形態では、安全な信頼された環境２１８は、ＵＥ上のハードウェアベースのエンティティであり、機密データ（例えば、暗号鍵、加入者クレデンシャル）を安全に記憶すること、および、機密ファンクション（例えば、暗号計算）の安全な処理を実行することを担う。

図２に示されたコンポーネントのうちの１または複数は、モバイル通信デバイスに常駐する。図２は、説明されるアーキテクチャ内の機能的モジュールを示すが、図２は、安全な信頼された環境２１８上にあるか、またはそれから離れているような、いかなる非アプリケーションファンクションの常住を必要とするようにも意図されない。コンポーネントおよびそれらの対話は、本明細書でより詳細に説明される。認証がＯｐｅｎＩＤプロトコルに関して説明されるが、同じ概念は、例えば、リバティアライアンスなど、他の認証プロトコルに適用される。

ユーザは、アプリケーション（例えば、ブラウザアプリケーション２０２および／または非ブラウザアプリケーション２０４）を使用して、例えば、ネットワークアプリケーションサービスプロバイダなど、サービスプロバイダ（例えば、リライングパーティ（ＲＰ））への最初の訪問を行う。サービスプロバイダ（例えば、ＲＰ）は、例えば、ＯｐｅｎＩＤユーザ識別子である可能性がある、ユーザ識別を受信する。ＯｐｅｎＩＤの場合、ユーザは、ＲＰにより開始されたディスカバリに続いて、例えば、ＯＰである、ネットワークベースのアイデンティティ管理エンティティにリダイレクトされる（例えば、ディスカバリ機構は、ＯｐｅｎＩＤプロバイダ（ＯＰ）アイデンティティを使用して、ＯＰのインターネットアドレスを決定する）。例示的実施形態では、ＯＰアイデンティティが使用されて、ＯＰのインターネットアドレスがＲＰに提供される。認証プロセスが、次いで開始する。

ＳＳＯサブシステム２０６は、アプリケーション側で、ユーザがそれと対話するアプリケーションとの通信を可能にするためのユーザ認証インターフェースと、ネットワークアシスト型認証モジュール２０８、２１０、２１２、２１４、および／または２１６のためのネットワーク認証インターフェースとを提供する。したがって、異なるアプリケーション（例えば、ブラウザアプリケーション２０２および／または非ブラウザアプリケーション２０４）が、ユーザ入力に基づいて、入力をＳＳＯサブシステム２０６に提供するか、または、ＳＳＯサブシステム２０６が、認証画面をユーザに提示して、サービスプロバイダとのユーザのネットワークアシスト型認証、および／または、ＵＥでのローカルユーザアシスト型認証を可能にする。異なるネットワークアシスト型認証モジュール２０８、２１０、２１２、２１４、および／または２１６（例えば、ＳＳＯプロトコル）は、ＳＳＯサブシステム２０６と対話するように設計される。ポリシー管理もまた、ＳＳＯサブシステム２０６によって行われる。

ＳＳＯサブシステム２０６認証構造は、２つのタイプのユーザ認証、ユーザアシスト型認証およびネットワークアシスト型認証を所有する。これらのタイプは共に、一方が他方から独立して発生可能であるように分離されるが、２つは、（例えば、ＳＳＯサブシステムによって作成されるアサーションを介して）互いにバインドされ、互いと対話する（例えば、ユーザアシスト型認証は、ネットワークアシスト型認証をトリガし、逆もまた同様である）。ユーザのユーザアシスト型認証と、（ユーザアシスト型認証のための）ユーザからＳＳＯサブシステム２０６へのクレデンシャルのプロビジョニングとは、独立して発生し、ネットワークアシスト型認証プロトコルから分離される。ユーザは、ネットワークアシスト型認証プロトコルから遮蔽される。この透明性は、単一のセットのユーザクレデンシャルがサービスプロバイダから独立しているという事実と共に、ユーザにとってシームレスなＳＳＯ経験を生じる。その上、２つの認証タイプは、バイオメトリック、パスワード、ＰＩＮ、トークン、別のユーザクレデンシャル、またはそれらの組み合わせであるかにかかわらず、そのクレデンシャルを通した、ユーザにより主張されたアイデンティティの、ＩＭＳＩまたはＩＭＰＩなど、ＵＩＣＣにおいて保持された加入者クレデンシャル、またはデバイスアイデンティティとのバインディングを提供する。そのようなバインディングは、両タイプの認証をアーキテクチャ上分離することと共に、中間層として働くＳＳＯサブシステム２０６によって達成される。ＳＳＯサブシステムは、それ自体で、または、本明細書で説明されるような下位層認証プロトコルのうちの１つへのコールによって、暗号バインディングを行う。

ＳＳＯサブシステム２０６は、例えば、ＭＮＯなど、外部利害関係者のネットワークアシスト型認証ファンクションのためのプロキシとして機能し、プロビジョニングされたポリシーファンクションに関する情報を外部利害関係者に提供する。ユーザが（例えば、ＵＲＬをウェブブラウザ上で入力するか、またはアプリケーションを開始することを通して）サービスへのアクセスを開始するとき、ユーザアシスト型認証プロセスが開始される。例えば、ユーザは、バイオメトリッククレデンシャルなどのユーザクレデンシャル、および／または、例えば、ＰＩＮなどのパスワードを入力するように要求される。例示的実施形態では、モバイル通信デバイスは、ユーザクレデンシャル情報の一部でもある、デバイス自体へのアクセスのためのＰＩＮ機能を所有する。例えば、ＵＥのユーザインターフェースは、ユーザアシスト型認証クレデンシャル情報、（例えば、ウェブＵＲＬ、またはアクティブ化されたアプリケーションの形態での）アクセスされているサービス、および／または、使用されるべきサービスに関係付けられた他の情報を、ＳＳＯサブシステム２０６へ、特定のインターフェースを通して搬送する。そのような搬送は、提供された情報およびプロビジョニングされたポリシーに基づいて、ユーザを認証するためにＳＳＯサブシステム２０６内のファンクションをアクティブ化する。例えば、ユーザアシスト型認証からのパラメータが、ネットワークアシスト型認証プロトコルに供給される。そのようなパラメータは、例えば、ユーザアシスト型認証の信頼レベル、ユーザアシスト型認証の結果（例えば、通過または失敗）、および、ユーザにより割り当てられた認証の時間を含む。ＳＳＯサブシステム２０６は、例えば、サービスがアクセスされるために適切であると見なされる認証の信頼（保証）レベル、および、認証の最低鮮度（例えば、完了された時間）など、様々な認証に関連したパラメータを具える、ポリシーファンクションを実行する。例えば、ユーザは、支払いをする目的で、バンキングサービスを使用することを望む。このシナリオでは、プロビジョニングされたポリシーは、強い形態のユーザアシスト型認証（例えば、多要素）を必要とし、プロビジョニングされたポリシーは、ユーザをサービスにナビゲートする直前に認証が実行されることを必要とする。低レベルのセキュリティがサービス（例えば、電子メールアクセス）のために所望される場合、ポリシーは、ユーザアシスト型認証要件を緩和する。例えば、ＰＩＮは、低レベルのセキュリティでのユーザアシスト型認証のために使用される。例示的実施形態では、ユーザ認証を駆動するポリシーは、外部利害関係者および／またはサービスプロバイダによって行われる。例えば、ポリシーファンクションは、サービスプロバイダで（例えば、ネットワーク上で）、ＵＥで（例えば、ローカルで）、または、それらの組み合わせ（例えば、分散ファンクション）で行われる。

例示的実施形態では、ＳＳＯサブシステム２０６によって従われるべきポリシーが、どのＳＳＯ認証プロトコル（例えば、ネットワークアシスト型認証モジュール２０８、２１０、２１２、２１４、および／または２１６）がネットワークアシスト型認証のために選択されるべきであるかを決定する。ネットワークアシスト型認証モジュール（例えば、ＳＳＯ認証プロトコル）選択のための基準は、利用可能なリソース、および／または、アクセスされるべきサービスのセキュリティ要件に基づく。内部ポリシー機構は、外部利害関係者（例えば、ＭＮＯ）により提供された、好ましい認証モジュール（例えば、ＳＳＯプロトコル）の優先リストを含む。ポリシー判断が行われると、ＳＳＯサブシステム２０６は、どの特定のネットワークアシスト型認証モジュールがプロトコル交換のために選択されたかを外部利害関係者（例えば、ＭＮＯ）に通信するための機構を提供する。あるいは、ＳＳＯサブシステムは、能力をネゴシエートし、使用されるべき認証モジュールについて同意する。

図３Ａおよび図３Ｂは、ＳＳＯフレームワークアーキテクチャを使用して実装されたプロトコルの例示的実施形態を示す。ＯｐｅｎＩＤのコンテキストにおいて、ＳＳＯサブシステムは、あるファンクションを安全な方法で行い、そのうちのいくつかが、図３Ａおよび３Ｂにおけるコールフローを参照して本明細書で説明される。

図３Ａおよび図３Ｂに示されるように、３１４で、ユーザアシスト型認証が行われる。例えば、ユーザクレデンシャルが認証および／または処理される。ユーザクレデンシャルは、ユーザＰＩＮ、パスワード、ユーザ識別子、バイオメトリック情報、またはダイジェストなど、ユーザ３０２に関連付けられた一意の認証パラメータ、および／または、他の形態のユーザアシスト型認証パラメータを含む。ユーザ３０２は、ローカルで、デバイス３０４で、または、外部利害関係者（例えば、ＭＮＯ）またはアイデンティティプロバイダ（ＩｄＰ）（例えば、ＯｐｅｎＩＤプロバイダ３１２）など、リモートエンティティと組み合わせて認証される。

ＳＳＯサブシステム３０８は、ユーザ３０２の認証を行うように構成されたユーザデバイス３０４上のローカルエンティティである。ＳＳＯサブシステム３０８は、様々な実施形態によれば、ＬＡＥを用いてまたは用いずに認証を行う。例えば、図３Ａは、本明細書で説明されるように、ＳＳＯサブシステムが認証をローカルで行うことを可能にする、例示的なプロビジョニングプロトコルフローを示す。ユーザアシスト型認証が完了すると、ＳＳＯサブシステム３０８は、３１６で、例えば、認証アサーションなど、認証結果を生成する。認証アサーションは、例えば、ユーザアシスト型認証が完了された時間、および認証の信頼レベルなどのデータを具える。信頼のレベルは、リモートパーティがユーザまたはＵＥの認証に置く保証のレベルを指す。ユーザアシスト型認証結果（例えば、通過または失敗）は、デバイス３０４で安全およびローカルに記憶され、および／またはネットワークアシスト型認証プロトコルと共に使用される。ユーザアシスト型認証に関連付けられた他のパラメータもまた記憶され、および／またはネットワークアシスト型認証において使用される。例えば、これらのパラメータは、認証の時間、認証の強度、および／または（１または複数の）認証パラメータのタイプを含む。これらのパラメータは、認証結果と共に記憶されるか、またはネットワークアシスト型認証において使用される。例えば、ＳＳＯサブシステムは、情報を使用して、認証データをサービスプロバイダへ中継し、サービス提供は、認証データがサービスへのユーザアクセスを提供するために十分であるかどうかを判定する。３１４でのユーザアシスト型認証は、任意の時間に、および、例えば、所望のセキュリティ強度など、様々な認証ポリシーに基づいて示唆されるのと同様に頻繁またはまれに発生する。例示的実施形態では、有効なユーザアシスト型認証結果が記憶される場合、ＳＳＯサブシステムは、ユーザレベル認証が行われる必要がないと決定する。そのようなシナリオは、ユーザが、認証プロセスにおけるさらなるユーザ関与なしに、複数のサービスプロバイダ（例えば、ＲＰ）にアクセスすることを可能にする。ポリシーが、特定のサービスプロバイダでの特定のサービスへのアクセスのために新しい認証を必要とする場合、例えば、既存の認証情報のそのような再使用は可能にされない。

３１８で、共有秘密鍵が、ＲＰ３１０とＯＰ３１２との間で確立される。例えば、ユーザにより供給された識別子を含む、ユーザのＯＰログオンリクエストが、アプリケーション３０６（例えば、ブラウザまたは非ブラウザアプリケーション）からＲＰ３１０へ渡され、アプリケーション３０６は、共有秘密鍵のアソシエーションおよび／または確立をトリガする。１つの例示的実施形態によれば、ユーザがネットワークベースのサービスにアクセスしようと最初に試みるとき、ログオンリクエストがＲＰ３１０に渡される。受信されたログオンリクエストに基づいて、ＯＰ３１２とＲＰ３１０との間で共有秘密鍵を確立する、アソシエーションが行われる。例示的実施形態では、３２０で、鍵（例えば、ＯＰ３１２およびＲＰ３１０により共有された鍵から導出された鍵、および／または、ネットワークアシスト型認証中に導出された鍵）、および／または他のクレデンシャルが、ＳＳＯサブシステム３０８にプロビジョニングされる。プロビジョニングされたクレデンシャルは、本明細書で説明されるように、サービスでのさらなる認証において使用される。

例えば、ネットワークアシスト型認証は、図３Ｂに示されるように、プロビジョニング後に行われる。例えば、ネットワークアシスト型認証は、ＲＰ３１０によるＯＰ３１２へのリダイレクションの後に続く。リダイレクトは、アプリケーション３０６（例えば、ブラウザアプリケーションまたは非ブラウザアプリケーション）によって受信され、それは、３２１で、ネットワークアシスト型認証モジュールおよび／またはプロトコルの選択のために、メッセージをＳＳＯサブシステム３０８へリダイレクトする。ネットワークアシスト型認証モジュール／プロトコル（例えば、ＳＳＯプロトコル）は、ポリシー実装を介して、ＳＳＯサブシステム３０８によって選択および使用される。このプロセスは、本明細書でさらに説明されるように、ブートストラッピングおよび共有鍵確立を含む。

図２に示されるように、いくつかのネットワークアシスト型認証プロトコル方法は、ネットワークアシスト型認証モジュール（例えば、ＳＳＯプロトコル）のスイートによって暗示される。図３Ｂを再び参照すると、例示的実施形態によれば、ＯｐｅｎＩＤ／ＳＩＰダイジェストおよび／またはＯｐｅｎＩＤ／ＧＢＡは、ＧＢＡ構造を所有していると見なされ、非特許文献１に指定された機構を採用する。ＯｐｅｎＩＤ ＧＢＡにおいて、ＵＩＣＣ加入者クレデンシャルが使用されて、ネットワークと共有されるべきマスターセッション鍵（例えば、Ｋｓと示される）がブートストラップされる。ネットワークアシスト型認証は、Ｋｓから導出され、ＯＰ３１２とユーザデバイス３０４との間で共有されたアプリケーション固有の鍵、Ｋｓ＿ＮＡＦを生じる。アプリケーション固有の鍵は、ＯＰ３１２と認証するとき、ユーザデバイス３０４によってパスワードとして使用される。例えば、それは、例えば、非特許文献２に記載されるように、ユーザデバイス３０４によってパスワードとして使用される。

ＯｐｅｎＩＤ／ＳＩＰダイジェストでは、同様の鍵構造が、同様のＧＢＡプロセスを通して生じる。このネットワークアシスト型認証のための手法は、非ＵＩＣＣベースであり、例えば、ＵＩＣＣクレデンシャルではなく、ＳＩＰダイジェストクレデンシャルが使用される。ＯｐｅｎＩＤ／ＳＩＰダイジェストの１つの例示的実施形態は、非特許文献３に記載されている。

ＯｐｅｎＩＤ／ＡＫＡでは、ネットワークアシスト型認証は、非ＧＢＡベースであり、ユーザデバイス３０４およびＯＰ３１２は、３ＧＰＰ ＡＫＡを直接採用して、鍵を認証および共有する。ＯｐｅｎＩＤ／ＡＫＡの１つの例示的実施形態は、非特許文献４に記載されている。

従来のＯｐｅｎＩＤでは、ＳＳＯサブシステム３０８は、ネットワークアシスト型認証プロトコルにおいて、受信されたユーザクレデンシャルを供給する。

ＯｐｅｎＩＤ／ＧＢＡ、ＯｐｅｎＩＤ／ＳＩＰダイジェスト、およびＯｐｅｎＩＤ／ＡＫＡは、構造上の相違点を有するが、ネットワークホーム加入サーバ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｓｅｒｖｅｒ）（ＨＳＳ）から受信された、あるタイプまたは別の、認証ベクトル（ＡＶ）の適用が、それぞれのプロトコルの中心となる。さらに、ポリシーおよび所望のセキュリティ強度に応じて、ネットワークアシスト型認証が行われるとき、ユーザの再認証（ユーザアシスト型認証）が実行される。例示的実施形態では、そのようなネットワークアシスト型認証中に、デバイスがネットワーク接続を確立しており、ネットワークアシスト型認証が、サービスプロバイダとＵＥを認証するために使用されると、仮定される。

成功したネットワークアシスト型認証の後、ＳＳＯサブシステム３０８は、ネットワークアシスト型認証が成功したという指示を、アプリケーション３０６に与える。例えば、ＳＳＯサブシステムは（例えば、ＬＡＥを介して）、３２２で、認証アサーション（例えば、アイデンティティアサーション）に署名し、３２４で、アサーションメッセージをＲＰ３１０へ送る。ＳＳＯサブシステム３０８からＲＰ３１０への署名されたアサーションメッセージは、認証に成功したことを示し、ＳＳＯサブシステム３０８によって、（例えば、図３Ａの３２０で示された）以前にプロビジョニングされたクレデンシャルを用いて、自律的に署名される。この成功したネットワークアシスト型認証の通知は、ユーザ３０２がＲＰ３１０で所望のサービスへのアクセスを得る前に行われる。認証プロセス（例えば、ＳＳＯプロセス）において早期に、ＯＰ３１２とＲＰ３１０との間で共有秘密鍵を確立する、アソシエーションが行われている。１つの例示的態様では、アサーションメッセージは、この共有秘密鍵、および／または鍵の導出を用いて署名される。ＲＰ３１０および／またはユーザデバイス３０４が、（例えば、アプリケーション３０６を介して）ネットワークアシスト型認証が成功したという指示を受信すると、ユーザデバイス３０４は、（例えば、アプリケーション３０６を介して）それがログオンされる先のＲＰ３１０におけるサービスにアクセスする。

ＲＰ３１０に与えられたアサーションメッセージは、ネットワークへの、およびサービスへの、両方の認証が完了すること、および、ユーザアシスト型認証において実装された、ユーザにより主張されたアイデンティティが、例えば、ネットワークアシスト型認証において実装されたＩＭＳＩまたはＩＭＰＩなど、加入者クレデンシャルにバインドされることを示す。例えば、それは、バインディングが、ユーザにより供給されたクレデンシャルとＵＩＣＣベースの（または、ＳＩＰダイジェスト）クレデンシャルとの間の接続を見る機構を介して行われるという、選択されたＳＳＯ機能性の一部である。アサーションメッセージは、バインディングをＳＳＯプロトコル全体の一部として示す情報を具える。また、例示的実施形態では、アサーションメッセージは、認証強度または信頼レベル（例えば、低、中、高、超高）を提供する。例えば、アサーションメッセージにおける低認証強度は、ＯＰ３１２が、アサートされたアイデンティティ（例えば、パスワードのフォーマットのための最小限のルールでの、ユーザ名／パスワードの自動挿入）における信頼をほとんどまたはまったく有していないことを示し、中認証強度は、ＯＰ３１２が、アサートされたアイデンティティ（例えば、パスワードのフォーマットに適用されたルールでの、ユーザ名／パスワードの手動の使用）においてある信頼を有することを示し、アサーションメッセージにおける高認証強度は、ＯＰ３１２が、アサートされたアイデンティティ（例えば、バイオメトリックまたは暗号ネットワーク−アクセストークンおよびユーザ名／パスワードの使用）において高いレベルの信頼を有することを示し、超高認証強度は、ＯＰ３１２が、アサートされたアイデンティティ（例えば、バイオメトリックおよび暗号トークン）において超高レベルの信頼を有することを示す。例示的実施形態では、「低」および「中」レベルは、ユーザクレデンシャルのみが使用されることを示し、「高」および「超高」レベルは、ネットワークアシスト型対話が行われることを必要とし、バイオメトリックおよびパスワードなど、より強い形態の認証を必要とする。

再び図２を参照すると、図２は、ネットワークにより制御されたブートストラッピングおよび鍵確立のために利用可能である、例示的なＳＳＯ技術（プロトコル）を示す。例えば、ＯｐｅｎＩＤ／ＩＳＩＭ２１４およびＯｐｅｎＩＤ／ＡＫＡ２１６は、ＵＩＣＣベースであり、ＵＩＣＣ上に安全に常駐する、ネットワークとの共有された秘密などのクレデンシャルを利用する。ＯｐｅｎＩＤ／ＧＢＡ２１２は、例えば、ネットワークと共有されたクレデンシャルに応じて、ＵＩＣＣベースであっても、そうでなくてもよい。例示的実施形態では、ＯｐｅｎＩＤ／ＳＩＰダイジェスト２０８は、ＵＩＣＣベースではない。例えば、従来のユーザにより供給されたＯｐｅｎＩＤアイデンティティおよびパスワードが収容される。ＳＳＯサブシステムのネットワーク認証インターフェースは、様々なＳＳＯプロトコル（例えば、図２におけるモジュール２０８、２１０、２１２、２１４、２１６）が単一のアーキテクチャのフレームワーク内に収容されることを可能にする。

例示的実施形態によれば、ユーザは、２認証タイプバインディングを用いて検証される。ユーザ検証がＯｐｅｎＩＤプロトコルに関して説明されるが、同じ概念は、例えば、リバティアライアンスなど、他の認証プロトコルに適用される。ＵＥに電源投入すると、例えば、ユーザアシスト型認証が発生する。例えば、ユーザは、ユーザアシスト型認証クレデンシャル（例えば、ＰＩＮ、バイオメトリクス）を提供して、デバイスファンクションへのアクセスを得る。例えば、ユーザは、ＰＩＮを提供して、ｉＰｈｏｎｅへのアクセスを得る。そのような認証機構は、電源投入時に一度、または、セッション全体を通して間欠的に提供される。ユーザを認証するための頻度要件は、ポリシー駆動である。ＳＳＯサブシステムは、ユーザにより提供されたＰＩＮを検証し、結果を保存し、結果は、アサーションの形態で、ＰＩＮが入力および検証されていることを確認する。そのようなアサーションが、ユーザアシスト型認証を確立する。ユーザアシスト型認証が確立された後、ユーザは、例えば、ウェブブラウザをＲＰウェブページにダイレクトすることによって、ＯｐｅｎＩＤプロトコルをサポートする、サービスプロバイダ（例えば、ＲＰ）のログインを試みる。ＳＳＯサブシステムは、ユーザアシスト型認証の状況をチェックし、状況が有効である場合、ユーザアイデンティティをＲＰに供給する。ＲＰは、ＯｐｅｎＩＤプロバイダ（ＯＰ）のディスカバリを行い、２つのエンティティは、アソシエーションを確立する。そのようなアソシエーションは、共有鍵を生じる。デバイスは、ＬＡＥにリダイレクトされ、それは、ＳＳＯサブシステムによって実行される、ＵＥ上のローカルＯｐｅｎＩＤプロキシファンクションである。例示的実施形態では、ＳＳＯによって実行された（例えば、外部利害関係者の）ポリシーは、強いネットワークアシスト型認証（例えば、ＧＢＡ、ＳＩＰ、ＡＫＡ）が行われることを必要とする。認証モジュール（例えば、ＳＳＯプロトコル）が選択される。そのような選択は、例えば、ＳＳＯサブシステムによって認証プロトコルにおいて、ＭＮＯにレポートされる。ＵＥの認証は、選択されたネットワークアシスト型認証モジュール（例えば、ＳＳＯプロトコル）を使用して行われる。例示的実施形態では、選択された認証プロトコルは、ネットワークアシスト型認証ファンクションとＵＥとの間で共有されたアプリケーション固有の鍵のブートストラップを生じる。そのような鍵は、ＵＥを認証するために使用される。

ＵＥは、認証完了の指示を受信し、ＬＡＥは、強い認証が行われたことを示す、ＲＰへのアサーションメッセージに署名する。アサーションは、ユーザアシスト型認証（例えば、最初のユーザＰＩＮ入力を介して）と後続のネットワークアシスト型認証（例えば、選択されたＳＳＯ認証プロトコルを介して）との間のバインディングを示す。アサーションは、本明細書で定義された認証信頼レベルのうちの１つを示す。アサーションメッセージは、ローカルＳＳＯプロキシ（例えば、ＬＡＥ）とＲＰとの間のアソシエーションを通して確立された鍵を使用して署名される。ＲＰおよびＬＡＥは、直接通信せず、そのため、ＯＰサービスファンクション（ＯＰＳＦ）がネットワーク上で作成されて、２つのエンティティ間の通信が容易にされる。例示的実施形態では、ＯＰＳＦは、それがＯＰであるかのように、このファンクションと通信するＲＰによって、公共のインターネットを介して到達可能である。ローカルＳＳＯ（ＬＡＥ）プロキシは、ＯＰＳＦ鍵配布機構を通してアソシエーション鍵を取得する。ＯＰＳＦはまた、ＬＡＥから発生する、署名されたアサーションに対して、ＲＰのための署名検証をもサポートする。ユーザは次いで、ＲＰウェブページにシームレスにダイレクトされる。例示的実施形態では、ユーザが後に異なるサービスプロバイダにアクセスすることを望むとき、ＳＳＯサブシステムは、ユーザアシスト型認証結果が既に記憶されているかどうか、および、その認証がなお有効であるかどうかを（例えば、ローカルで記憶されたポリシーに従って）チェックする。有効な記憶された結果がある場合、例えば、ＳＳＯサブシステムは、この時にユーザアシスト型認証を行わない。新しいサービスプロバイダが次いで、本明細書で説明されるように、アイデンティティプロバイダのディスカバリを行う。したがって、ユーザは、クレデンシャルをＵＥで入力することなく、新しいサービスプロバイダにアクセスし、ユーザは、ネットワークアシスト型認証に関与しない。そのようなシナリオは、実施形態による完全なＳＳＯ実装形態を構成する。

例示的実施形態では、ユーザは、好ましいサービスおよび／またはアプリケーションの登録を通して、好ましい（例えば、提携された）サービスにアクセスする。例えば、ウェブまたは他のオンラインアプリケーションサービスプロバイダ（例えば、リライングパーティ）は、サービスプロバイダの選択のＩｄＰを使用して、オペレータのネットワークベースのＳＳＯシステムに登録する。例えば、支払取引プロバイダは、ＯｐｅｎＩＤを使用して、委任された認証を特定のＩｄＰから取得し、それは、支払取引プロバイダが、提携されたサービスになる結果となる。登録は、サービスプロバイダ（例えば、ＲＰ）、選ばれたＩｄＰ、オペレータのＳＳＯシステム、またはサービスのエンドユーザによって開示される。さらに、登録は、ユーザがウェブページにアクセスすること、またはＵＥ常駐ＳＳＯサブシステムによって開始される。例えば、ＵＥ上に常駐するＳＳＯサブシステムは、ネットワークベースのＳＳＯサブシステムのデータベースに「同期される」ようになり、それによって、登録された、提携されたサービスおよびアプリケーションのリストおよびタイプに気づく。

ＲＰは、ＩｄＰを選択することが可能にされるが、ＳＳＯプロトコルを明示的に選択しない。例示的実施形態によれば、ＩｄＰの選択と、使用されるべきＳＳＯプロトコルとの間に、暗黙のアソシエーションがある。例えば、ＩｄＰは、ＯｐｅｎＩＤなど、特定のＳＳＯプロトコルをサポートするので、ＲＰは、特定のＩｄＰを選ぶ。

ユーザは次いで、ＵＥを使用することによって、ＳＳＯ（例えば、ＯｐｅｎＩＤ）によりサポートされたウェブベースのアプリケーションサービスにアクセスする。ＵＥ常駐ＳＳＯサブシステムは、オペレータによりプロビジョニングされたポリシーに準拠し、登録された提携されたサービス／アプリケーション、および／または好ましいサービス／アプリケーションを選択する。ＵＥ常駐ＳＳＯサブシステムはまた、例えば、ユーザが彼または彼女の好ましいサービスを（例えば、ＵＲＬでのタイピングを介して）示した後、インターセプト（介入）し、ユーザによりタイプされたＵＲＬを、同じサービスの登録された、提携されたバージョンに対応する代替サービスのＵＲＬで変換または置換する。そのような置換サービスは、同じプロバイダによって提供されるが、優先的な、提携されたベースによって提示およびアクセスされる。例えば、アクセスは、前述のサービス／アプリケーション（例えば、および、そのようなサービス／アプリケーションを提供するＩｄＰおよびＲＰ）への前述の登録ベースの提携を有するオペレータによってサービスされたＵＥのユーザに制限される。

例示的実施形態によれば、サービス／アプリケーションの選択の後に、ＵＥは、ユーザに代わって、透過的および／またはシームレスな方法で、好ましいアクセスネットワークアシスト型認証機構および適切なクレデンシャルを選択する。例えば、ＵＥは、ＳＳＯ認証プロトコル内で、選択されたアクセスネットワークアシスト型認証機構を示す。ネットワークは、選択された好ましいアクセスネットワークアシスト型認証機構を認識し、ユーザを認証する。認証に成功した時に、ＳＳＯ動作の残り（例えば、サービスを取得するための、ＲＰへのＵＥリダイレクション）が行われる。

本明細書で説明されるように、オペレータのＳＳＯシステムを介してオペレータの信用インフラストラクチャに接続することによって、加入された、提携されたサービスは、オペレータによって与えられたネットワークアシスト型認証強度を有効に獲得する。

より一般的には、本明細書で説明されるＳＳＯアーキテクチャは、より形式化された機能的階層を組み込んでいると見なされる。例えば、ＳＳＯサブシステムは、１または複数のＳＳＯクライアント（例えば、または、ローカルＳＳＯプロキシ）を管理する。基礎をなすデバイス技術が、マルチサービスプロバイダ構成をサポートする場合、多数のＳＳＯクライアントが、ＳＳＯサブシステム内でマルチサービスマネージャへのサブファンクションとして実行する。この一般化されたアーキテクチャは、潜在的に独立したポリシーを用いて、複数のサービスをサポートするために使用される、分離を実現する。

そのようなフレームワーク内の各ＳＳＯクライアントは、いくつかの下位のサブファンクションを管理する。例えば、ローカルアサーションサブファンクションは、ローカルアサーションエンティティ（ＬＡＥ）によって行われる。ＬＡＥは、ローカルアサーションを行うサブファンクションの形式的な名称を指す。１または複数のＬＡＥは、例えば、実装形態に応じて、ＳＳＯクライアントによって制御される。例えば、構成は、ＳＳＯクライアント−ＬＡＥ対（１対１）、または、複数のＬＡＥを制御する１つのクライアントを含む。いずれの構成でも、ＳＳＯクライアントは、制御エンティティである。ＳＳＯ認証プロトコルはまた、本明細書でＳＳＯ技術とも呼ばれる。例えば、ＳＳＯクライアントは、選択されたＳＳＯ認証プロトコルによって実行された機構の処理を制御する。ＳＳＯクライアントは、どの認証方法が使用されるかを決定するポリシー実施アクションを管理する。例えば、適用されたポリシーは、ＭＮＯなど、外部利害関係者の制御下にある。

別の実施形態によれば、ＵＥは、マルチサービスマネージャ内でサブファンクションとして実行する複数のＳＳＯクライアントの実装形態をサポートする。そのような実装形態は、異なるサービスプロバイダが、同じプロバイダによって同時に提供された複数の利用可能な接続技術およびサービスの、ポリシーベースの管理を可能にしながら、その特定のプロバイダに排他的にサービスする別個の隔離されたＳＳＯクライアントを必要とする環境において、機能すると見なされる。例えば、ＭＥは、ＳＳＯクライアントＡおよびＳＳＯクライアントＢを有し、これらのＳＳＯクライアントのそれぞれは、別々に、互いに隔離されて制御される。ＳＳＯ態様は、プロバイダに固有である。

複数のＳＳＯクライアントと共に、例示的実施形態では、多数のＬＡＥがある。例えば、各ＬＡＥは、ＵＥ上でアクセス技術固有のドメインにおいて実装される。ＳＳＯクライアント隔離のために、隔離されたドメインごとに１つのＬＡＥがある。また、例えば、ＬＡＥは、デバイスによってサポートされた利用可能なアクセス技術に従って構築される。同じアクセス技術が、異なるＬＡＥ間で多重化され、または、異なるアクセス技術が、ＬＡＥによって同時に使用される。したがって、ＵＥは、複数のＬＡＥをサポートする。実装形態に応じて、例えば、ＬＡＥとＳＳＯクライアントとの間の関係は、１対１であり、または、１つのＳＳＯクライアントが複数のＬＡＥを制御し、またはそれらによってサービスされる。

本明細書で説明されるように、ＳＳＯサブシステム内で行われるファンクションは、様々な方法で構成される。ＵＥにおいて、例えば、ＵＩＣＣベースのアーキテクチャと、非ＵＩＣＣ（または、あるいは安全な環境）ベースのアーキテクチャとの間の分割がある。また、ＵＥとＭＮＯネットワークとの間のファンクションの間引きもある。以下は、様々な実施形態によるいくつかの可能な構成である。

暗号ＡＫＡファンクションは、非ＵＩＣＣスマートカード上に常駐する。そのようなファンクションは、Ｇ＆ＤのＭＳＣなど、完全にプログラム可能な、非ＵＩＣＣスマートカード上で行われ、ネットワークアシスト型認証（例えば、ＡＫＡ）と同様であるが、カードは取外し式であり、ユーザ制御下にある。暗号ファンクションは、ＵＩＣＣ上に常駐する。そのようなファンクションは、例えば、鍵導出およびアサーション署名など、ＵＩＣＣ上で実装されたＬＡＥの基本的暗号ファンクションを含む。機能性は、ネットワークアシスト型認証（ＡＫＡ）と同様である。さらに、ＩＭＳＩへのバインディング、およびＭＮＯへのユーザ登録が実現される。

例示的実施形態によれば、ＬＡＥファンクションは、ＵＩＣＣまたは安全な信頼された環境上に常駐する。例えば、ＬＡＥは、スマートカードウェブサーバ（ＳＣＷＳ）または他のウェブブラウザアプリケーション上のＯｐｅｎＩＤの完全な実装形態である。例示的実施形態では、ネットワークアシスト型認証構成は、ＬＡＥ（例えば、ローカルアサーション）認証を、任意の形態の強いネットワークアシスト型認証（例えば、ローカルＯｐｅｎＩＤ／ＧＢＡ）にバインドすることである。強い認証が、バイオメトリクスまたは同様のローカル認証を追加することによって、追加のファクタとして、強いローカルユーザアシスト型認証に適用される。例えば、任意の形態の強いローカル認証が、ネットワークアシスト型認証と組み合わせられ、それにバインドされる。

図４は、複数のＳＳＯプロトコルおよび／またはモジュールの使用のためのアーキテクチャのフレームワークの別の例示的実施形態を示す。図４に示されるように、ＵＥ４０２のＳＳＯサブシステム４００は、ウェブサービス４０６（例えば、ＲＰ）など、サービスプロバイダからのサービスにアクセスするように構成されたアプリケーション（例えば、ブラウザアプリケーション４０４）と通信している。ＳＳＯサブシステム４００は、ユーザのためのＳＳＯ機能性を提供し、認証サービスへのサインオンプロセスにおける自動化をもたらす。例えば、自動化機能は、ユーザ識別子をウェブサービス４０６へ、および／または、クレデンシャルをアイデンティティプロバイダ（例えば、ＯｐｅｎＩＤプロバイダ（ＯＰ）４０８）へ、ユーザ対話なしに提供するファンクションを含む。自動化はまた、ＯＰ４０８のオーセンティケータ４１０への認証クレデンシャルの自動プロビジョニング、のみならず、認証モジュール（例えば、認証方法）の自動選択およびネゴシエーションをも特徴とする。例示的実施形態によれば、認証モジュールは、ＯｐｅｎＩＤ／ＳＩＰダイジェストモジュール４１８、ＯｐｅｎＩＤ／ＧＢＡモジュール４１２、ＥＡＰ／ＳＩＭモジュール４１６、および／またはＯｐｅｎＩＤ／ＡＫＡモジュール４１４を含む。例えば、図５は、ＧＢＡモジュール４１２がＳＳＯサブシステム４００によって選択される例示的実施形態を示す。図４に示されたネットワークアシスト型認証モジュールは、ＯｐｅｎＩＤネットワークアシスト型認証プロトコルをそれぞれ実装するが、他のタイプのネットワークアシスト型認証プロトコルも同じく、または、あるいは実装される。ＳＳＯサブシステム４００によって提供される自動化は、無線デバイス（例えば、ＵＥ４０２）上に記憶され、例えば、ＯＰ４０８によってプロビジョニングされた、以前に定義された（１または複数の）ポリシーに基づいて実行される。そのような自動化は、クッキー（例えば、ブラウザ４０４に記憶される）、Ｊａｖａアプレット、フォームデータを記憶するブラウザキャッシュなどによって提供される。例示的実施形態では、自動化は、例えば、埋められるべきフォームを自動的に検出する、スクレイピングファンクションを与えられる。

Ｊａｖａアプレットを使用する例示的実施形態では、例えば、自動化機能は、Ｊａｖａアプレットに組み込まれ、それは、認証プロセス中にダウンロードされる。本明細書で論じられる自動化機能は、Ｊａｖａアプレットによって実装されるが、本明細書で説明される実施形態は、そのように限定されない。いくつかの実施形態では、例えば、アプレットがブラウザキャッシュから除去されるので、永続的な機能（例えば、ユーザログイン状態）は、Ｊａｖａアプレットに配置されない。さらに、本明細書で説明されるように、Ｊａｖａアプレットは、プロトコルにより実行されたプロセスにおけるダウンロード後、利用可能になる。Ｊａｖａアプレットを利用するファンクションは、アプレットがＵＥなどのデバイスにダウンロードされた後、行われる。Ｊａｖａアプレット自体は、例えば、ＪａｖａアプレットがＯＰにリダイレクトされた後、ＯＰからダウンロードされる場合、スクレイピング機能を提供しない。

図６は、複数のＳＳＯ技術および／またはモジュールの使用を容易にするためのダウンロード可能コンポーネントを具える、アーキテクチャのフレームワークの例示的実施形態を示す。例示的ダウンロード可能コンポーネント（例えば、サプリカント６２２）は、ブラウザアプリケーションおよび／または非ブラウザアプリケーション（例えば、アプリケーション６０４）のためのインターフェースを、例えば、認証モジュール、プロトコル、およびＡＰＩ（例えば、モジュール６１２、６１４、６１６、６１８、および６２０）など、ネットワークアシスト型モジュールに提供する。例示的実施形態では、ダウンロード可能コンポーネント（例えば、サプリカント６２２）は、ＵＥ６０２上で完全なＳＳＯサブシステム６００の存在にバインドされない。例えば、コンポーネント（例えば、サプリカント６２２）は、それが無線デバイス（例えば、ＵＥ６０２）上の完全なＳＳＯサブシステム６００機能ありでまたはなしで使用されるという点で、独立している。サプリカント６２２の例示的機能を説明する目的で、図６は、サプリカント６２２をＳＳＯサブシステムとは別個のコンポーネントとして示すが、サプリカントは、ＳＳＯサブシステム６００内に含まれる。さらに、本明細書で説明される実施形態は、ＳＳＯサブシステムのサブセットありまたはなしのサプリカントの変形形態を含む。

例示的実施形態では、サプリカント６２２は、Ｊａｖａアプレットなどを用いて実装される。例えば、Ｊａｖａアプレットは、認証プロセス中にダウンロードされ、ＵＥ６０２において、ブラウザ（または、アプリケーション６０４）と、ネットワークアシスト型認証モジュール（例えば、ＧＢＡモジュール６１２、ＡＫＡモジュール６１４、ＥＡＰ ＳＩＭモジュール６１６、ＳＩＰダイジェストモジュール６１８、ローカルＯＰモジュール６２０）との間に、層を作成する。そのような層は、例えば、ネイティブブラウザがいくつかの認証機構をサポートしないので、認証モジュールとのネットワーク認証インターフェースを可能にするソフトウェア層である。

サプリカント６２２（例えば、Ｊａｖａアプレット）は、ダウンロードされると実行され、ＨＴＴＰリクエストを発行および／または処理するという意味において、ブラウザから独立している。例えば、Ｊａｖａアプレットは、ＯＰ６０８へ、認証チャレンジを取り出すようにリクエストを発行する。Ｊａｖａアプレットは、認証モジュール（例えば、ＧＢＡモジュール６１２、ＡＫＡモジュール６１４、ＥＡＰ ＳＩＭモジュール６１６、ＳＩＰダイジェストモジュール６１８、ＬＡＥモジュール）のみならず、ＳＳＯサブシステム６００ともインターフェースする。例えば、ＵＥ６０２は、階層化アクセスを提供し、そこで、認証モジュールへのアクセスは、ＳＳＯサブシステム６００を通して利用可能にされる。ＳＳＯサブシステム６００と認証モジュールとの間のネットワーク認証インターフェースが使用されて、認証が容易にされる。例えば、Ｊａｖａアプレットは、チャレンジをアイデンティティプロバイダ（例えば、ＯＰ６０８）からネットワークアシスト型認証モジュールへ送り、認証モジュールは、ダイジェストレスポンスを計算し、Ｊａｖａアプレットは、レスポンスをＯＰ６０８へ直接、またはブラウザを介してＯＰ６０８へ送る。

図６に示されるように、ＬＡＥ（例えば、ローカルＯＰ６２０）は、（例えば、ＳＳＯサブシステム６００によって）別の認証モジュールと見なされるが、ＬＡＥ６２０は、認証に加えてファンクションを行う。例えば、ＬＡＥは、純粋な認証方法よりも多くのファンクションを含むので、ＬＡＥに対するＪａｖａアプレットの役割は、認証モジュールに対するＪａｖａアプレットの役割とは異なる。例えば、ＬＡＥは、認証レスポンスを計算せず、それは、認証をアクティブに行う。結果として、ＬＡＥは、検証のために、ウェブサービス６０６（例えば、ＲＰ）など、サービスプロバイダへ直接送られるアサーションメッセージを作成する。ＬＡＥに対して、サプリカント６２２（例えば、Ｊａｖａアプレット）は、アプリケーション６０４（例えば、ブラウザ）からＬＡＥへの通信を可能にする。例示的実施形態によれば、ＳＳＯサブシステム６００は、例えば、ＳＩＭＡｌｌｉａｎｃｅによって規格化された、ＯｐｅｎＭｏｂｉｌｅ ＡＰＩなど、ソフトウェアミドルウェアコンポーネントを含み、それに基づく。そのようなソフトウェアミドルウェアコンポーネントは、例えば、ユーザ／ＯＳレベルアプリケーションからＳＩＭカードアプリケーションへの通信を容易にする。

図６に示された例示的アーキテクチャをさらに参照すると、サプリカント６２２（例えば、署名されたＪａｖａアプレット）は、ブラウザを介してダウンロードされ、各デバイス（例えば、ＵＥ６０２）タイプについてカスタマイズされる。サプリカントは、例えば、Ｓｙｍｂｉａｎ、ｉＯＳ、Ａｎｄｒｏｉｄなどなど、様々なデバイスタイプについてカスタマイズされる。サプリカント６２２は、ブラウザから、例えば、ＧＢＡモジュール６１２、ＡＫＡアプリケーション６１４、およびＳＩＰダイジェストオーセンティケータ６１８など、ＳＳＯサブシステム６２２のコンポーネントへの通信を可能にする。サプリカント６２２は、アイデンティティプロバイダのサーバ（例えば、ＯＰサーバ６０８）、および／またはウェブサービス６０６（例えば、ＲＰ）によって提供される。サプリカント６２２は、自動化された、および／またはシームレスなユーザ認証を行うために使用される、インターフェースファンクションを提供する。例示的実施形態では、ＳＳＯサブシステム６００は、アプリケーション６０４（例えば、ブラウザ）がネットワークアシスト型認証モジュール６１２、６１４、６１６、６１８、および６２０と通信することを可能にする。サプリカント６２２は、例えば、アプリケーション６０４（例えば、ブラウザ）がＳＳＯサブシステム６００の機能を使用することを可能にする。サプリカント６２２は、ＬＡＥ６２０のディスカバリ、および、例えば、ＬＡＥがＵＥ６０２上で利用可能である場合、ＬＡＥへの接続において役立つ。サプリカント６２２は、ユーザをアイデンティティプロバイダのローカルまたはリモート変形形態（例えば、ＬＡＥまたはリモートＯＰ６０８）へ、およびウェブサービス６０６（例えば、ＲＰ）へ戻るように、リダイレクトする。サプリカント６２２は、認証モジュールとしてのＳＳＯサブシステム６００の使用を可能にし、例えば、署名されたアサーションを直接生成するための、ＳＳＯサブシステム６００のＬＡＥ部分（例えば、ローカルＯＰ６２０）の使用を可能にする。ＳＳＯサブシステム６００は、モバイルデバイス（例えば、ＵＥ６０２）においてプリロードされ、および／または、他の機構を介してデバイスにダウンロードされる。例示的実施形態では、ＳＳＯサブシステム６００は、サービスにわたって永続的であるが、サプリカント６２２は、ユーザがウェブサービス６０６（例えば、ＲＰ）を訪問するたびにリロードされる。

一実施形態では、図６におけるサプリカント６２２などのサプリカントは、Ｊａｖａアプレットなどとして実装され、限定された動作環境（例えば、「サンドボックス」）において実行する。そのようなサプリカントは、システムリソースへの制限されたアクセスを有する。例示的実施形態では、サプリカントは、認証が行われた後（例えば、ブラウザがサービスウェブサイトを離れるとき）、アンロードされる。図７を参照すると、シングルサインオン（ＳＳＯ）機能は、異なるサービス間のユーザ認証に及ぶので、ＳＳＯファンクションの永続的な態様は、ＳＳＯサブシステム７００の非サプリカント部分によって提供される。図７は、ＳＳＯサブシステム７００の例示的インターフェースコンポーネントを用いた、図６のアーキテクチャのフレームワークの例示的実施形態を示す。図７に示されるように、ＳＳＯサブシステムは、サプリカントを含み、ＳＳＯサブシステム７００は、例えば、ユーザ７０４、リモートサーバ７０８、バイオメトリックユニット７１０、および様々な他のデバイス７０６など、様々なコンポーネントとインターフェースする。ＳＳＯサブシステム７００のサプリカント部分のインターワーキング機能性が、以下で例として説明される。

図７をさらに参照すると、サプリカントは、一般に認証ファンクションへの直接アクセスを有しておらず、または、ＬＡＥ（例えば、ローカルＯＰ６２０）によって提供された認証ファンクションへのアクセスを有する。そのような場合、ネットワークアシスト型認証方法を使用するいくつかの認証リクエストが、ＳＳＯサブシステム７００を介してコールされる。そのようなコールは、ＳＳＯサブシステム７００へのサプリカントの適切な認可および／または以前の確認（例えば、コード署名をチェックすることによる）を含む。サプリカントは、様々なインターフェースを提供する。例えば、サプリカントは、特定のサービスプロバイダ（例えば、ＲＰ）と共に使用されるべき識別子を選択するために、インターフェースをＳＳＯサブシステム７００に提供することによって、認証プロセスの自動化を可能にするための機能性を提供する。サプリカントは、アイデンティティプロバイダ（例えば、ＯＰ６０８）での認証のためのクレデンシャルを提供するために、インターフェースをＳＳＯサブシステム７００に提供する。サプリカントはまた、ネットワークアシスト型認証モジュールまたは機構の、選択および／またはネゴシエーションのために、インターフェース（例えば、ネットワーク認証インターフェース）をＳＳＯサブシステム７００に提供する。１つの例示的態様では、サプリカントは、例えば、認証のためのウェブサービス６０６（例えば、ＲＰ）からアイデンティティプロバイダ（例えば、ＯＰ６０８）へのリダイレクトメッセージ、および、認証後のウェブサービス６０６からＯＰ６０８へのリダイレクトメッセージなど、リダイレクトメッセージを置換するファンクションを提供する。

上記で説明されたように、ＳＳＯサブシステム７００は、ユーザアシスト型認証のためのユーザ認証インターフェース（例えば、図６におけるユーザインターフェース６２４）を提供し、このインターフェースを通してユーザアシスト型認証を行う。ユーザ認証インターフェースは、例えば、ＯＰ６０８によって、ＯＰサプリカントファンクションの一部として提供されるか、または、ＳＳＯサブシステム７００の永続的なファンクションの一部である。ＳＳＯサブシステム７００は、アイデンティティプロバイダ（例えば、ＯＰ６０８）とインターフェース（例えば、通信）して、ユーザアシスト型認証ポリシーの情報を収集する。そのようなポリシーの情報は、例えば、アイデンティティプロバイダまたはサービスプロバイダによって必要とされる鮮度（例えば、認証が実行された時間）、および認証強度レベル（例えば、バイオメトリックまたはユーザ名／パスワード）など、ユーザアシスト型認証パラメータを含む。ＳＳＯサブシステムはまた、ＯＰ６０８とインターフェースして、ネットワークアシスト型認証モジュールおよび／またはインターフェースの選択を容易にする。ユーザインターフェースを介して、および／または、選択されたネットワークアシスト型認証方法（例えば、ＧＢＡモジュール６１２、ＡＫＡモジュール６１４、ＥＡＰ ＳＩＭ６１６、ＳＩＰダイジェスト６１８）を使用して、ユーザ７０４および／またはユーザ機器（ＵＥ）６０２の認証に成功した後、ＳＳＯサブシステム７００は、時間期間（例えば、有効期間）にわたってユーザ認証の永続的な状態を設定する。（例えば、ローカルトリガによる、またはネットワークによる）再認証リクエストを受信すると、ＳＳＯサブシステム７００は、ユーザ７０４を再認証する。例示的実施形態では、そのような再認証は、シームレスなログオン経験をユーザ７０４に提供する。

ＳＳＯサブシステム７００は、ＵＥ６０２の外部のコンポーネント（例えば、他のデバイス７０６）へのインターフェースを使用して、例えば、ＵＥ６０２への無線インターフェースを介して接続されたトークンから認証情報を取得する。ＳＳＯサブシステム７００は、認証のために、バイオメトリックユニット７１０への、またはリモートサーバ７０８への２次通信チャネルを確立する。

図８は、サプリカント（例えば、Ｊａｖａアプレット）のダウンロードをトリガする、認証フローを示すフロー図である。図８に示された例示的フローは、本明細書で説明されたＳＳＯフレームワークアーキテクチャ内で実装される。図における例示的実施形態は、ＯｐｅｎＩＤ用語を使用して説明されるが、例示的フローは、例えば、リバティアライアンスなど、任意の数のシングルサインオンセキュリティプロトコルに適用される。

図８を参照すると、８０８で、ＵＥ８０２は、ユーザのＯＰログオンリクエストをＲＰ８０４へ送る。ログオンリクエストは、ユーザにより供給された識別子を含み、ＲＰ８０４に渡され、それは、８１０で、ＲＰ８０４とＯＰ８０６との間の、アソシエーションおよび／または共有秘密鍵の確立をトリガする。ネットワークアシスト型認証は、８１０の後に行われる。例えば、ネットワークアシスト型認証は、ＲＰ８０４によるＯＰ８０６へのリダイレクションの後に続く。リダイレクトは、ステップ８１２で、ＵＥ８０２によって受信される。８１４で、ＵＥは、リクエストをＯＰ８０６へ、サプリカントを使用した認証のために送る。リクエストは、例えば、非ブラウザアプリケーションのアイデンティティ、または、ＵＥ８０２によって使用されるブラウザエージェントのアイデンティティなど、アプリケーションのアイデンティティを具える。例示的実施形態では、Ｊａｖａアプレットが、リクエストにおけるブラウザエージェントのタイプに従ってマッチさせられる。例えば、複数のおよび／または異なるＪａｖａアプレットが異なるデバイスに対して使用されるので、Ｊａｖａアプレットが、例えば、プロセッサ、ＯＳ、および／またはブラウザなど、ＵＥ８０２の様々なコンポーネントに従って選択されるようになる。リクエストに応答して、８１６で、ＵＥ８０２は、サプリカント８２０（例えば、Ｊａｖａアプレット）をＯＰ８０６からダウンロードする。

Ｊａｖａアプレットは、ＯＰ８０６によって署名される。Ｊａｖａアプレットのための発行者証明書は、ブラウザによって、例えば、ＵＥシステム証明書ストアを使用してチェックされる。例えば、変更されたシステムまたはブラウザ証明書ストア実装形態は、ＵＥ８０２の安全な要素（例えば、ＵＩＣＣ）上に記憶された証明書／鍵と共にＪａｖａアプレット署名をチェックする。Ｊａｖａアプレットは、どのネットワークアシスト型認証モジュール８００をＲＰ８０４で使用するべきかを判断するための論理を具える。Ｊａｖａアプレットはまた、ＯＰ８０６に、どの認証モジュール／機構がＵＥ８０２において利用可能であるかを示すための論理をも含む。例示的実施形態では、Ｊａｖａアプレットは、１つの単一の認証モジュール８００に固有であり、ＯＰ８０６は、どのＪａｖａアプレットをＵＥ８０２に提供するべきかを選択する。例示的実施形態では、８１４で、ＨＴＴＰリクエストが送られる。ＨＴＴＰリクエストは、ブラウザエージェントを含み、（８１６で）ＵＥ８０２のＯＳが識別されること、および、対応するアプレットバージョンがＯＰ８０６によって選択され、ＵＥ８０２へ送られることを可能にする。

ネットワークアシスト型認証が、８１８で行われる。本明細書で図３に関して説明されるように、ネットワークアシスト型認証は、ＲＰ８０４によるＯＰ８０６へのリダイレクションの後に続く。リダイレクトは、サプリカント８２０によって受信され、それは、ネットワークアシスト型認証モジュールおよび／またはプロトコル（例えば、認証モジュール８００）の選択のために、メッセージをＳＳＯサブシステム３０８にリダイレクトする。ネットワークアシスト型認証モジュール／プロトコル（例えば、ＳＳＯプロトコル）は、ポリシー実装を介してＳＳＯサブシステムによって選択および使用される。このプロセスは、本明細書でさらに説明されるように、ブートストラッピングおよび共有鍵確立を含む。

図２、図４、図６、および図７に示されるように、いくつかのネットワークアシスト型認証プロトコルモジュールは、ネットワークアシスト型認証モジュール（例えば、ＳＳＯプロトコル）のスイートによって暗示される。再び図８を参照すると、８２２で、８１８での認証からの認証結果が、サプリカント８２０からＯＰ８０６へ送られる。例えば、認証結果は、ＵＥ８０２とＯＰ８０６との間で共有された、アプリケーション固有の鍵などを具える。成功したネットワークアシスト型認証の後、ＯＰ８０６は、ＲＰ８０４に、ネットワークアシスト型認証が成功したという指示を与える。例えば、ＯＰ８０６は、８２４でアイデンティティアサーションに署名し、８２４でアサーションメッセージを送る。成功したネットワークアシスト型認証の、署名された通知は、ＵＥ８０２がＲＰ８０４における所望のサービスへのアクセスを得る前に行われる。ＲＰ８０４および／またはＵＥ８０２が（例えば、アプリケーションを介して）ネットワークアシスト型認証が成功したという指示を受信すると、ＵＥ８０２は（例えば、アプリケーションを介して）（８２６で）ＲＰ８０４にログオンし、（８２８で）ＲＰ８０４におけるサービスにアクセスする。

図９は、アイデンティティプロバイダのファンクションがＵＥ８０２のローカルで行われる、例示的実施形態を示す。例えば、ＵＥ８０２は、ＳＳＯサブシステムおよびＬＡＥ（例えば、ローカルＯＰ９００）を具える。ステップ８０８、８１０、８１４、および８１６は、図８に関して説明されたように進む。９０２および９０４で、署名されたアサーションが、サプリカント９０８とＳＳＯサブシステム９００との間、および、ＳＳＯサブシステム９００と１または複数の認証モジュール８００との間の対話を介して作成される。ＵＥ８０２は、９０６で、署名されたアサーションをＲＰ８０４へ送る。ＲＰが、署名されたアサーションを受信した後、ＵＥ８０２のユーザは、（８２４で）ＲＰ８０４によって提供されたサービスにアクセス可能である。図１０は、ＳＳＯサブシステムがＪａｖａアプレット１００２において実装される、例示的実施形態を示す。図１０を参照すると、ＳＳＯサブシステム１００２は、ＵＩＣＣ上のローカルＯＰ暗号１０００を使用して、ネットワークアシスト型認証を行う。成功したネットワークアシスト型認証の後、署名されたアサーションが作成され、ＲＰ８０４にリダイレクトされる。

本明細書（例えば、図１１ないし図１５）で説明されるように、ＬＡＥ（例えば、ローカルＯＰ）は、Ｊａｖａアプレットにおいて統合されるか、またはＪａｖａアプレットから分離している。代替の例示的実施形態では、ＯｐｅｎＩＤプロトコルは、例えば、ローカルＯＰコンポーネントなしで実装される。そのような実施形態では、プロトコルフローの第１の部分は、ＬＡＥを有する実施形態と同じに、または類似しているように見えるが、認証および／またはアサーション生成は、（例えば、図１６に示された）ＵＥとＯＰとの間の通信によって行われる。

図１１は、アソシエーションをプリフェッチするためのプロトコルフローの例示的実施形態を示す。例えば、アソシエーションがプリフェッチされ、それは、ユーザからの認証試行に先立って、ＲＰがアソシエーション（例えば、アソシエーションハンドルおよび／またはアソシエーション秘密）を取り出すことを可能にする。これは、例えば、ＯｐｅｎＩＤの識別子選択モードを使用することによって実装される。ＲＰは、完全なＯｐｅｎＩＤ識別子ＵＲＬを知る必要はないが、いくつかの知られているＯＰのためのアソシエーションを、例えば、それらのＯＰエンドポイントＵＲＬに基づいてプリフェッチする。図１１を参照すると、ＲＰ８０４は、８１０で、ＵＥ８０２の識別子を知る前にアソシエーションを得る。ＲＰ８０４は、８１２で、例えば、プリフェッチされたアソシエーションのうちの１つを使用することによって、ＵＥ８０２をＯＰ８０６に直接リダイレクトする。そのような実施形態では、ＵＥ８０２は、Ｊａｖａアプレット１１００をＯＰ８０６からダウンロードし、それは、ＵＥ８０２とＯＰ８０６との間のインターフェース上でトラフィックを生じる。例示的実施形態では、ＵＥ８０２からＯＰ８０６へのインターフェースは、エアインターフェースであるが、ＲＰ８０４とＯＰ８０６との間のインターフェースは、固定されたインターネットである。

プリフェッチステップの例示的実施形態では、Ｊａｖａアプレットは、図１２に示されるように、ＲＰによって記憶される。ＲＰ８０４は、ＯＰ８０６によって署名されるＪａｖａアプレット１２０２のセットを受信する。ＲＰ８０４は、８１０からのアソシエーションと共にＪａｖａアプレット１２０２を記憶する。ＵＥ８０２が、１２０４で、認証することを望むとき、例えば、ＲＰ８０４は、１２０６で、対応するＪａｖａアプレット１２０２をＵＥ８０２に提供する。複数のおよび／または異なるＪａｖａアプレットが異なるデバイスに対して使用され、例えば、それらが、非ブラウザアプリケーションまたはブラウザエージェントのプロセッサおよびＯＳにマッチするようになる。

例示的実施形態によれば、ＯｐｅｎＩＤライブラリは、例えば、ＯＰにアウトソーシングされる。例えば、ＯＰは、ＲＰがＲＰのためのＯｐｅｎＩＤ固有の動作を扱うためのＡＰＩを提供する。Ｇｏｏｇｌｅ Ｉｄｅｎｔｉｔｙ Ｔｏｏｌｋｉｔは、ＲＰの機能性をＵＥ上で一般化し、同じサプリカントを使用する複数のＲＰのための共通フレームワークを提供する例示的実装形態である。ＲＰは、ＡＰＩに、ＯｐｅｎＩＤ認証を開始するように要求し、ＡＰＩ（ＯＰによって提供／ホストされる）は、ＵＥ認証を開始するために、ＲＰからＵＥへ送られるべきコードを返す。その後、ＵＥ結果がＲＰへ送り戻され、それは、認証結果を（例えば、単独で、またはＯＰの助けと共に）検証する。例示的実施形態では、アソシエーションのプリフェッチは、ＵＥとＯＰとの間の通信を省き（減らし）、オフラインシナリオを可能にする。

図１３は、キャッシュされたＪａｖａアプレットのためのプロトコルフローの別の実施形態を示す。例えば、Ｊａｖａアプレット１３０６などは、スマートフォンなど、ＵＥ８０２上に記憶される。例示的実施形態では、Ｊａｖａアプレット１３０６は、以前の実行からＵＥ８０２のブラウザキャッシュに記憶される。そのような実施形態では、記憶されたＪａｖａアプレットがコールされる。例えば、アプレットがブラウザキャッシュにおいて利用可能ではないと仮定される場合、ブラウザは、ダウンロードされたＪａｖａアプレットを予告なしに削除する。以前にダウンロードされたＪａｖａアプレットは、例えば、アプレットが同じ起点（例えば、同じＲＰ）からコールされるとき、コールされる。ＯＰによって提供されたＡＰＩは、１３００でコードを返し、それは、以前にダウンロードされた（および、キャッシュされた）Ｊａｖａアプレットへのコールを発行する。１３０２で、例えば、Ｊａｖａアプレット１３０６へのコールがＲＰ８０４に提供される。１３０４で、コールがＵＥ８０２に提供される。本明細書で説明される実施形態は、ＪａｖａＳｃｒｉｐｔ（登録商標）など、代替の実装形態を使用する。

図１４は、Ｊａｖａアプレットがオンザフライでプロビジョニングされる、例示的実施形態を示す。例示的実施形態によれば、ブラウザは、Ｊａｖａアプレットをキャッシュに記憶しない。そのような実施形態では、アプレット１４０２は、（１４００で）ＯＰ８０６によってＲＰ８０４に提供され、ＲＰ８０４は、１４０４で、それをＵＥ８０２に渡す。ＨＴＴＰリクエストは、ブラウザエージェントを含むので、ＵＥ８０２のＯＳが識別され、対応するアプレットバージョンがＵＥ８０２へ送られる。ここで、ＲＰ８０４は、例えば、正しいＪａｖａアプレットバージョンを選択するために、ＵＥ文字列（例えば、ＯＳおよび／またはブラウザエージェントを具える）をＯＰ８０６へ、ＯＰ８０６のためのＡＰＩコール１３００において伝える。

本明細書で説明されるように、様々な実施形態は、ＯｐｅｎＩＤなどを使用して、ブラウザアプリケーションを用いてサービスにアクセスする。ＯｐｅｎＩＤは、ＨＴＴＰプロトコルに基づいており、および／または、Ｊａｖａアプレットは、Ｊａｖａ Ｒｕｎｔｉｍｅを実装する。例示的実施形態では、ブラウザは、ＨＴＴＰプロトコルとＪａｖａ Ｒｕｎｔｉｍｅ環境の両方を使用する。本明細書で提示されたＯｐｅｎＩＤおよび／または他の概念の使用は、ブラウザアプリケーションに限定されるものではない。本明細書で説明されるように、様々な実施形態は、非ブラウザアプリケーションを使用して、ＯｐｅｎＩＤプロトコルなどを実装する。それらのアプリケーションでは、同じ概念が適用される。非ブラウザアプリケーションを用いた実施形態は、Ｊａｖａアプレットのダウンロードおよび実行をサポートするためのインターフェースおよび／または方法を提供する。本明細書における説明は、様々なプロトコルフローの説明のためにブラウザという用語を使用するが、フローはそのように限定されず、非ブラウザアプリケーションを含む。

様々な実施形態がＪａｖａアプレットを実装するとして説明されるが、そのような実施形態は、そのように限定されない。本明細書で説明されるＪａｖａアプレットは、サービスアクセスアプリケーション（例えば、ブラウザ／非ブラウザ）と認証モジュール（例えば、ＯＰ、ローカルＯＰ、ＧＢＡ、ＡＫＡ）との間のデバイスの内部の認証通信を容易にする、コンポーネント（例えば、サプリカント）のダウンロードのための単一の実装変形形態を表す。例えば、本明細書で説明される実施形態は、無線デバイスにアウトオブバンドでロードされ、または動的にダウンロードされる、ライブラリまたはＡＰＩなどのコンポーネントによって実装される。ダウンロードされたコンポーネント（例えば、アプレット、ライブラリ）は、アプリケーションが、コンポーネントをどのように扱うべきか（例えば、それをどのようにロードするべきか、どのファンクションをコールするべきか）を知っているという意味で、アプリケーションについて固有である。

Ｇｏｏｇｌｅ Ｉｄｅｎｔｉｔｙ Ｔｏｏｌｋｉｔ（ＧＩＴｋｉｔ）は、いくつかの能力および機能を提供し、それらは、ＲＰファンクションの統合および／または実装の容易さを可能にする。ネットワーク側では、ＲＰファンクションは、例えば、ネットワーク側サプリカントファンクションロールアウト機能を含むことによって、サービスプロバイダによる、ＯｐｅｎＩＤ連携型アイデンティティプロトコルの選定の容易さのために、さらに強化される。クライアント側では、Ｊａｖａスクリプトは、サプリカントファンクションを一般化し、それらをＧＩＴｋｉｔと整合させるために使用される要素のうちのいくつかを提供し、例えば、スクレイピングを使用して、ユーザ自動化を行う実施形態などである。

本明細書で説明される様々な実施形態は、ＬＡＥ（例えば、ローカルＯＰ）の概念をＧｏｏｇｌｅ Ｉｄｅｎｔｉｔｙ Ｔｏｏｌｋｉｔと統合するが、ＧＩＴｋｉｔのユーザによって与えられる通常のコールフローに準拠したままである。例えば、本明細書で説明されるものは、ローカルＯＰがコールされ、ブラウザがローカルＯＰにリダイレクトされる、いくつかの異なる方法である。例示的実施形態では、デバイスがどこでローカルＯＰに到達するべきか知りたいと望むＯＰのＵＲＬに、リダイレクションが適用される。別の例示的実施形態では、ＧＩＴｋｉｔ ＡＰＩによって提供されたウェブサイトは、例えば、ブラウザをローカルＯＰにリダイレクトすることなく、ローカルＯＰ認証プロセスをトリガするＯＳ ＡＰＩへのコールを（例えば、ＪａｖａＳｃｒｉｐｔを介して）提供する。さらに別の例示的実施形態では、ブラウザプラグインが、ＯＳ ＡＰＩの代わりにコールされる。

図１５は、ＧＩＴｋｉｔ１５００がローカルＯＰ９００およびＪａｖａアプレット１５０８と統合される、例示的実施形態を示す。例示的統合ステップが以下にリストされるが、例えば、非ブラウザアプリケーションの要求に応えるものを含む、他の実装形態が使用されるので、本明細書で説明される実施形態は、そのように限定されない。

図１５を参照すると、ユーザは、ＲＰ８０４を訪問し、および／または、自分のＩｄＰを選択、または自分の電子メールアドレス識別子を入力する。１つの例示的実施形態では、識別子は、例えば、認証プロセスの自動化を提供するために、（例えば、ブラウザにより記憶されたフォームデータまたはクッキーなど、既存の技術を使用して）事前に埋め込まれ、ユーザがＵＲＬをブラウザに入力することによってトリガされる。ＧＩＴｋｉｔライブラリ関数「ｃｒｅａｔｅＡｕｔｈＵｒｌ」が、コールされる。ＧＩＴｋｉｔライブラリは、ＩｄＰディスカバリを行う。ＧＩＴｋｉｔは、ＩｄＰの認可エンドポイントＵＲＬ（例えば、ＯＰ８０６のＵＲＬ）を返す。ＪａｖａＳｃｒｉｐｔウィジェットは、ログインウィンドウをポップアップし、ユーザをそのエンドポイントにリダイレクトする。そのポップアップウィンドウにおけるリダイレクションは、ユーザを、デバイス上で実行しているローカルＯＰインスタンスへ連れて行く。ローカルＯＰインスタンスは、例えば、ＳＩＭカード、または、そこでローカルＯＰの暗号ファンクションが実行される他の安全な要素へのインターフェースを統合しながら、ブラウザのための能力のようなＨＴＴＰインターフェースおよびウェブサーバを提供する、アプリケーションからなる。代替的実施形態では、ＪａｖａＳｃｒｉｐｔは、リダイレクトを使用しないが、（１５０２で）ＯＳ ＡＰＩをコールして、スクリプトから直接、ローカルＯＰ認証をトリガすることが可能である。例えば、ローカルＯＰアプリケーションがＳＩＭカード上に常駐する場合、ＪａｖａＳｃｒｉｐｔは、ＯＳ ＡＰＩ（例えば、Ｓｉｍａｌｌｉａｎｃｅ ＯｐｅｎＭｏｂｉｌｅ ＡＰＩ）を潜在的にコールして、スマートカード上でローカルＯＰアプリケーションと直接通信する。他の実施形態は、純粋なＪａｖａＳｃｒｉｐｔソリューションを使用しない。これらの実施形態では、ブラウザはプラグインを含み、それがＪａｖａＳｃｒｉｐｔによってコールされて、ローカルＯＰ認証がトリガされる。このプラグインは、例えば、ＯＳアプリケーション層および／または安全な要素上のローカルＯＰアプリケーションの間の通信のために、トランスポート層論理を提供する、あるＯＳ ＡＰＩを利用する。他の実施形態では、ＧＩＴｋｉｔ ＡＰＩは、ＲＰに、第１のコールの後、ＵＥへのＪａｖａアプレットのダウンロードを可能にするコードを提供する。Ｊａｖａアプレットは、本明細書で説明されるように、ローカルＯＰを使用して認証を行う。実施形態は、クレデンシャルを（例えば、ブラウザにより記憶されたフォームデータ、クッキー、その他など、既存の技術を使用して）事前に埋め込んで、ＵＥがローカルＯＰへのリダイレクトを受信することによってトリガされた認証プロセスの自動化を提供する。

１１０２で、ユーザは、ローカルＯＰにローカルで認証される。ローカルＯＰは、ネットワークにおけるＯＰ（ＳＦ）との長期共有された秘密からＯｐｅｎＩＤ署名秘密を導出し、アソシエーションハンドルを鍵導出関数への第２の入力として使用して、ＯｐｅｎＩＤのための署名鍵を作成する。ローカルＯＰ／ＪａｖａＳｃｒｉｐｔ／プラグインは、署名されたアサーションメッセージを作成し、ブラウザを、ＲＰにおける以前に作成された「ｃｏｎｔｉｎｕｅＵＲＬ」にリダイレクトし、それは、「ｃｒｅａｔｅＡｕｔｈＵｒｌ」ＧＩＴｋｉｔライブラリコールによって作成されている。ＲＰは、（９０６で）署名されたアサーションメッセージを受信し、１５１０で、それを検証のためにＧＩＴｋｉｔライブラリに渡す。ＧＩＴｋｉｔ１５００は、１５１２で、「ｖｅｒｉｆｙＡｓｓｅｒｔｉｏｎ」ＡＰＩを使用して、ＯＰ（ＳＦ）でアサーションメッセージを確認する。ＧＩＴｋｉｔライブラリは、Ｇｏｏｇｌｅによってホストされるので、ＧＩＴｋｉｔライブラリは、署名検証のためにＯＰＳＦを使用する。ＯＰＳＦは、アイデンティティ情報（電子メール、または、例えば、ＯｐｅｎＩＤの属性交換方法によって定義されるような他の属性など）を返す。そのアカウント／電子メールが既に存在する場合、ユーザがログインされる。そうでない場合、ＲＰは、アサートされた電子メールアドレスを、ユーザのための変更不可能な識別子として使用して、新しいアカウントを作成する。追加の属性は、属性交換機構を用いて受信された情報に基づいて、自動で埋め込まれる。

追加の背景として、ＧＩＴｋｉｔプロトコルフローの概要が、非特許文献５において見いだされる。通常のＧＩＴｋｉｔプロトコルフローは、次のように要約される。

ユーザは、ＲＰウェブサイトを訪問し、自分のＩｄＰのボタンをクリックする。ＲＰは、ＧＩＴｋｉｔサービスＡＰＩへのコールを構築し、それは、次にディスカバリステップを行い、ＲＰがユーザの戻りを待機するためにセットアップしなければならないコールバックＵＲＬを返し、ＧＩＴｋｉｔは、ＩｄＰと認証するためにユーザに表示されるべきであるＨＴＭＬコードを返す。このＨＴＭＬコードは、ＩｄＰの認証ＵＲＬへのリダイレクションを含む。このコードはまた、ＲＰのための同じユーザインターフェースをも作成する。ユーザは、自分のＩｄＰに対して認証する。ユーザは、ＲＰにおけるコールバックＵＲＬにリダイレクトされる。ＲＰは、コールバックＵＲＬで受信されたパラメータ（ＩｄＰレスポンス）を使用して、ＧＩＴｋｉｔ ＡＰＩ（ｖｅｒｉｆｙＡｓｓｅｒｔｉｏｎ）へのコールを行う。ＧＩＴｋｉｔ ＡＰＩは、ＩｄＰレスポンスを検証し、結果（検証された電子メール＋追加の属性）をＲＰへ送る。

ＧＩＴｋｉｔは、ＲＰが以下に示される２つのステップでコールする、少なくとも２つのＡＰＩを提供することによって、ＯｐｅｎＩＤ／ＯＡｕｔｈプロトコルを公開する。

１つのステップは、ｃｒｅａｔｅＡｕｔｈＵｒｌ ＡＰＩコールを含む。このＡＰＩコールは、ユーザがＩＤＰアイコン（すなわち、Ｇｍａｉｌ、Ｙａｈｏｏボタン）をクリックするか、または、例えば、電子メールアドレスを直接入力するとき、発生する。ＧＩＴｋｉｔバックエンドは、例えば、ＯｐｅｎＩＤ ２．０プロトコルに従って、ＩＤＰディスカバリを行う。ＩＤＰが実際にＯＡｕｔｈプロトコルを使用する場合、ＧＩＴｋｉｔは、事前定義されたＩＤＰエンドポイントを直接使用する。最終結果は、ＧＩＴｋｉｔが、ＩＤＰの認可エンドポイントを表すＵＲＩ（パラメータ「ａｕｔｈＵｒｉ」）を返し、ＧＩＴｋｉｔログインウィジェットが、そのエンドポイントにリダイレクトするログインウィンドウをポップアップすることである。（このステップは、通常のＯｐｅｎＩＤプロトコルの第１のリダイレクトに対応し、そこで、ブラウザがＯＰにリダイレクトされる。ローカルＯＰと共に以前と同じ機構を使用することによって、ユーザのブラウザは、この段階で代わりにローカルＯＰへリダイレクトされる）。ｃｒｅａｔｅＡｕｔｈＵｒｌをコールするとき、ＲＰは、ユーザが対応するＩＤＰによって認証が成功した後にリダイレクトされるＵＲＬである、「ｃｏｎｔｉｎｕｅＵｒｌ」（すなわち、コールバックＵＲＬ）を提出する。「レルム」は、ＯｐｅｎＩＤのレルムを識別する随意のパラメータであるが、「識別子」は、どのＩＤＰを使用するべきかを指定する。

別のステップは、ｖｅｒｉｆｙＡｓｓｅｒｔｉｏｎを含む。ＩＤＰがユーザの認証に成功した後（これは、ローカルＯＰが使用される場合、ローカルで行われる、実際のユーザ認証を指す）、それは、ブラウザを、その秘密鍵を用いて署名されたユーザのアイデンティティ情報と共に、ｃｒｅａｔｅＡｕｔｈＵｒｌの「ｃｏｎｔｉｎｕｅＵｒｌ」パラメータにおいて指定されるＵＲＬにリダイレクトする。実施形態によれば、これは、処理されないバイナリブロブに類似しており、それは、確認のためにＧＩＴｋｉｔへ送り戻される。これは、ＯＰからＲＰへのＯｐｅｎＩＤにおける第２のリダイレクトである。これは、ローカルＯＰと共に使用される。コールバックＵＲＬのためのＨＴＴＰリクエストは、ＲＰのバックエンドにおいてＧＩＴｋｉｔクライアントライブラリによって取り込まれ、クライアントライブラリは、「ｒｅｑｕｅｓｔＵｒｉ」（ＩＤＰが返すＵＲＩ）および「ｐｏｓｔＢｏｄｙ」（ＩＤＰによる署名されたブロブ）と共に、ＧＩＴｋｉｔのｖｅｒｉｆｙＡｓｓｅｒｔｉｏｎＡＰＩをコールする。ＧＩＴｋｉｔバックエンドは、ＯｐｅｎＩＤプロトコルを使用してＩＤＰレスポンスを確認し、アイデンティティ情報（また、例えば、ＡＸが使用される場合、そのアイデンティティに関連付けられた属性も）をＲＰのバックエンドに返す。このステップは、通常のＯｐｅｎＩＤのアサーション署名検証に対応する。これは、例えば、ＯｐｅｎＩＤのステートレスモードに類似している。ＧＩＴｋｉｔライブラリは、（例えば、ネットワークにおいて）ＯＰに再び接触して、署名を検証し、追加の属性（例えば、電子メールアドレス）を要求する。ＲＰは、「ｖｅｒｉｆｉｅｄＥｍａｉｌ」フィールドを検査し、それに応じてアクションを行う。例えば、その電子メールアドレスをもつアカウントが有効である場合、ユーザがログインされ、および／または、ＪａｖａＳｃｒｉｐｔウィジェットがログインウィンドウを閉じ、および／または、ユーザのブラウザをＲＰのホームページにリダイレクトする。その電子メールについて発見されたアカウントがない場合、ＲＰは、ユーザを、例えば、埋め込まれたアカウントについての他の属性と共に、事前に埋め込まれた編集不可能な電子メールフィールドをもつ、アカウント作成ページにリダイレクトする。

ＯＡｕｔｈベースのＩＤＰ認証では、ＲＰは、同じまたは類似のコールを使用し、ＧＩＴｋｉｔから戻された同じまたは類似のレスポンスを得る。しかし、ＧＩＴｋｉｔは、ＯＡｕｔｈプロトコルをそのバックエンドにおいて使用して、ＩＤＰと通信し、例えば、アクセストークンとの交換など、正しい処理を行う。ＧＩＴｋｉｔ ＡＰＩエンドポイントは、ＧＩＴｋｉｔ ＡＰＩコールを求めるリクエストを受信し、ユーザを（通常は、ＡＰＩ Ｋｅｙを使用して）認証し、正しいパラメータと共にＧＩＴｋｉｔサーバをコールする。ＧＩＴｋｉｔサーバは、対応するＩＤＰに接触して、ＯｐｅｎＩＤ／ＯＡｕｔｈコールを完了する。

本明細書で説明された例示的実施形態は、ＯｐｅｎＩＤのコンテキストにおいて実行され、上記で説明された技法は、リバティアライアンスなど、任意の数のシングルサインオンセキュリティプロトコルに適用される。さらに、様々な実施形態が様々な図に関連して説明されたが、他の同様の実施形態が使用され、または、説明された実施形態に、様々な実施形態の同じファンクションを行うために、それから逸脱することなく変更および追加が行われることが理解される。したがって、実施形態は、任意の単一の実施形態に限定されるべきではなく、むしろ、添付の特許請求の範囲による広さおよび範囲において解釈されるべきである。

その上、特徴および要素は、特定の組み合わせにおいて上記で説明され、各特徴または要素は、単体で、または他の特徴および要素との任意の組み合わせにおいて使用される。本明細書で説明されたシステム、方法およびプロセスのいずれかまたはすべては、コンピュータ可読記憶媒体上に記憶された、コンピュータ実行可能命令またはプロセッサ実行可能命令（すなわち、プログラムコード、ソフトウェアおよび／またはファームウェア）の形態で実施され、それらの命令は、プロセッサなどのマシンによって実行されるとき、本明細書で説明されたシステム、方法およびプロセスを行い、および／または実装することが理解される。詳細には、上記で説明されたステップ、動作またはファンクションのいずれかが、そのような実行可能命令の形態で実装される。コンピュータ可読記憶媒体は、情報の記憶のための任意の方法または技術において実装された、揮発性および不揮発性、取外し式および非取外し式媒体を両方とも含む。コンピュータ可読記憶媒体は、限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶または他の磁気記憶デバイス、または、所望の情報を記憶するために使用でき、コンピュータまたはプロセッサによってアクセスできる、任意の他の媒体を含む。

Claims (18)

1. ユーザ機器（ＵＥ）であって、
   サービスプロバイダと通信して、サービスにアクセスするように構成されたユーザアプリケーションと、
   複数のネットワークアシスト型認証モジュールであって、各ネットワークアシスト型認証モジュールは異なるネットワークアシスト型認証プロトコルに対応し、および前記複数のネットワークアシスト型認証モジュールのうちの１または複数はサービスプロバイダとネットワークアシスト型認証を行って、前記サービスにアクセスするように構成された、複数のネットワークアシスト型認証モジュールと、
   当該ＵＥのユーザをユーザアシスト型認証情報に基づいて認証するように、および、前記サービスプロバイダと前記ネットワークアシスト型認証を行うために前記複数のネットワークアシスト型認証モジュールのうちのネットワークアシスト型認証モジュールを選択するように構成された、シングルサインオン（ＳＳＯ）サブシステムと
   を具え、前記ＳＳＯサブシステムは、前記ユーザアシスト型認証を行い、および前記ネットワークアシスト型認証モジュールを１または複数のポリシーに基づいて選択するようにさらに構成されたことを特徴とするユーザ機器（ＵＥ）。
2. 前記ユーザアシスト型認証情報はユーザアイデンティティまたはユーザクレデンシャルのうちの少なくとも１つを具え、前記ＳＳＯサブシステムは前記ユーザアイデンティティを使用して前記ユーザアシスト型認証を行うように構成され、ＵＥはＵＥアイデンティティを使用して前記ネットワークアシスト型認証を行うように構成されたことを特徴とする請求項１記載のＵＥ。
3. 前記ネットワークアシスト型認証ポリシーは、前記ユーザアシスト型認証に関連付けられたユーザアシスト型認証強度、または、前記ネットワークアシスト型認証に関連付けられたネットワークアシスト型認証強度のうちの少なくとも１つを示すことを特徴とする請求項１記載のＵＥ。
4. 前記ネットワークアシスト型認証は、前記サービスプロバイダへ、前記ユーザが認証されることを示すアサーションメッセージを送ることによって行われることを特徴とする請求項１記載のＵＥ。
5. 前記ＳＳＯサブシステムは、前記ユーザアシスト型認証から生じる少なくとも１つのパラメータを使用して、前記ネットワークアシスト型認証を行うようにさらに構成されたことを特徴とする請求項１記載のＵＥ。
6. 前記ユーザアシスト型認証から生じる前記少なくとも１つのパラメータは、ユーザアシスト型認証状況、ユーザアシスト型認証時間、またはユーザアシスト型認証強度を具えたことを特徴とする請求項５記載のＵＥ。
7. 前記ＳＳＯサブシステムは、前記ネットワークアシスト型認証のために使用されるべきアイデンティティプロバイダの選択を受信するようにさらに構成され、前記アイデンティティプロバイダは、前記複数のネットワークアシスト型認証モジュールのうちの認証モジュールに関連付けられたことを特徴とする請求項１記載のＵＥ。
8. 当該ＵＥは複数のサービスプロバイダによって提供されたサービスをサポートするように構成され、各サービスプロバイダは異なるセットのポリシーに関連付けられたことを特徴とする請求項１記載のＵＥ。
9. 前記アプリケーションから前記複数のネットワークアシスト型認証モジュールへの前記通信を可能にするサプリカントをさらに具えたことを特徴とする請求項１記載のＵＥ。
10. 前記サプリカントは、前記ＳＳＯサブシステムに含まれることを特徴とする請求項９記載のＵＥ。
11. 前記サプリカントは、前記サービスプロバイダまたはアイデンティティプロバイダのうちの少なくとも１つからダウンロードされることを特徴とする請求項９記載のＵＥ。
12. 前記サプリカントは、前記ユーザアプリケーションが前記ＳＳＯサブシステムの１または複数の特徴を使用することを可能にするように構成されることを特徴とする請求項９記載のＵＥ。
13. 前記サプリカントは、前記サプリカントが前記ユーザアプリケーションおよび前記ＳＳＯサブシステムと通信することができるように、前記ユーザアプリケーションに対応することを特徴とする請求項９記載のＵＥ。
14. 複数のネットワークアシスト型認証モジュールを具えるユーザ機器（ＵＥ）であって、各ネットワークアシスト型認証モジュールは異なるネットワークアシスト型認証プロトコルに対応し、および前記複数のネットワークアシスト型認証モジュールのうちの１または複数はサービスプロバイダとネットワークアシスト型認証を行ってサービスにアクセスするように構成された、ＵＥにおいて、
    当該ＵＥのユーザをユーザアシスト型認証情報に基づいて認証するステップと、
    前記サービスプロバイダと前記ネットワークアシスト型認証を行うために前記複数のネットワークアシスト型認証モジュールのうちのネットワークアシスト型認証モジュールを選択するステップと、
    前記ユーザアシスト型認証を行い、前記ネットワークアシスト型認証モジュールを１または複数のポリシーに基づいて選択するステップと
    を具えたことを特徴とする方法。
15. 前記ＵＥによって、前記サービスプロバイダの１または複数のデータフィールドを検出するステップと、
    前記検出に応答して、前記１または複数のデータフィールドを対応する認証データを用いてポピュレートするステップと
    をさらに具えたことを特徴とする請求項１４記載の方法。
16. 前記ネットワークアシスト型認証を、前記ユーザアシスト型認証からの少なくとも１つのパラメータに基づいて行うステップ
    をさらに具えたことを特徴とする請求項１４記載の方法。
17. 前記ユーザアシスト型認証から生じる前記少なくとも１つのパラメータは、ユーザアシスト型認証状況、ユーザアシスト型認証時間、またはユーザアシスト型認証強度を具えたことを特徴とする請求項１６記載の方法。
18. 前記ユーザアシスト型認証に応答して、前記サービスプロバイダと前記ユーザを認証するためのサプリカントをダウンロードするステップをさらに具え、
    前記サプリカントは、前記ＵＥのユーザアプリケーションにマッチすることを特徴とする請求項１４記載の方法。

Images