"依拠当事者RPがユーザを認証することを可能にするオープン管理セキュリティプロトコルを可能にするためのユーザ環境であって、前記RPによって提供されるサービスへのアクセスをユーザに代わって要求するために、シングルサインオンセキュリティプロトコルを使用して、前記RPと通信するユーザインタフェースであって、前記RPは、前記ユーザの認証を開始するために、シングルサインオン資格証明書のトラステッドプロバイダと通信する、ユーザインタフェースと、前記トラステッドプロバイダのために、前記ユーザ環境内において前記ユーザを認証するプロセッサであって、前記認証プロセス中に前記ユーザ環境の外部との通信を制限するために、シングルサインオン資格証明書の前記トラステッドプロバイダの少なくともいくつかの機能をローカルで実行するように構成されるプロセッサとを備えることを特徴とするユーザ環境。前記ユーザインタフェースは、前記RPが前記ユーザを認証することを望んでいる旨の通知を前記RPから受信することを特徴とする請求項1に記載のユーザ環境。前記ユーザインタフェースは、リダイレクションメッセージを前記RPから受信し、前記リダイレクションメッセージは、前記ユーザを認証するように前記ユーザインタフェースに命令することを特徴とする請求項1に記載のユーザ環境。前記ユーザインタフェースは、ユーザ資格証明書を前記ユーザから受け取ることを特徴とする請求項1に記載のユーザ環境。前記プロセッサは、トラステッドコンピューティング環境であることを特徴とする請求項1に記載のユーザ環境。前記ユーザインタフェースは、前記トラステッドコンピューティング環境によって全面的または部分的に保護されることを特徴とする請求項5に記載のユーザ環境。前記トラステッドコンピューティング環境は、前記ユーザが認証されたときに、認証応答を前記RPに送信することを特徴とする請求項5に記載のユーザ環境。前記トラステッドコンピューティング環境は、ユニバーサル集積回路カードUICC、加入者識別モジュールSIM、機器対機器M2Mデバイス、スマートカード、java登録商標カード、グローバルプラットフォームスマートカード、または安全な統合チップカードICCのうちの1つであることを特徴とする請求項5に記載のユーザ環境。前記トラステッドコンピューティング環境は、スマートカードウェブサーバSCWSを使用して実施されることを特徴とする請求項5に記載のユーザ環境。前記トラステッドコンピューティング環境は、OpenIDプロバイダと秘密を共有することを特徴とする請求項5に記載のユーザ環境。前記トラステッドコンピューティング環境は、シグネチャを計算し、前記RPが前記トラステッドコンピューティング環境の資格証明書を検証することが可能なように、前記シグネチャを、前記ユーザインタフェースを介して、前記RPに提供することを特徴とする請求項5に記載のユーザ環境。前記トラステッドコンピューティング環境は、シグネチャを計算し、前記OPが前記トラステッドコンピューティング環境の前記資格証明書を検証することが可能なように、前記シグネチャを、前記ユーザインタフェースを介して、前記OPに提供することを特徴とする請求項5に記載のユーザ環境。前記トラステッドコンピューティング環境は、前記秘密に基づいてシグネチャを計算し、前記RPが前記トラステッドコンピューティング環境の前記資格証明書を検証することが可能なように、前記シグネチャを、前記ユーザインタフェースを介して、前記RPに提供することを特徴とする請求項10に記載のユーザ環境。前記トラステッドコンピューティング環境は、前記秘密に基づいてシグネチャを計算し、前記OPが前記トラステッドコンピューティング環境の前記資格証明書を検証することが可能なように、前記シグネチャを、前記ユーザインタフェースを介して、前記OPに提供することを特徴とする請求項10に記載のユーザ環境。前記トラステッドコンピューティング環境は、前記ユーザインタフェースを介して、前記OPとともに共有秘密を確立することを特徴とする請求項5に記載のユーザ環境。前記ユーザインタフェースは、アソシエーションハンドルを含む認証要求を前記RPから受信し、前記アソシエーションハンドルを前記トラステッドコンピューティング環境に提供することを特徴とする請求項15に記載のユーザ環境。前記ユーザインタフェースは、アソシエーションハンドルを含むリダイレクトメッセージを前記トラステッドコンピューティング環境から受信し、前記アソシエーションハンドルを前記RPに提供することを特徴とする請求項15に記載のユーザ環境。前記トラステッドコンピューティング環境は、前記共有秘密に基づいてシグネチャを生成し、前記シグネチャと前記アソシエーションハンドルとを含む認証応答を生成することを特徴とする請求項16に記載のユーザ環境。前記ユーザインタフェースは、前記トラステッドコンピューティング環境によって生成された前記認証応答を前記RPに提供することを特徴とする請求項18に記載のユーザ環境。前記集積回路は、シグネチャを生成し、シグネチャアサーションメッセージを前記OPから受信することを特徴とする請求項1に記載のユーザ環境。前記集積回路は、シグネチャ応答メッセージを前記RPに送信することを特徴とする請求項20に記載のユーザ環境。前記ユーザインタフェースと前記集積回路は、同じデバイス上に存在することを特徴とする請求項1に記載のユーザ環境。前記ユーザインタフェースと前記集積回路は、別々のデバイス上に存在することを特徴とする請求項1に記載のユーザ環境。前記ユーザを認証するステップは、パスワード、PINコード、バイオメトリックアイデンティティ、トークン、またはそれらの組み合わせを用いて、前記ユーザを検証することによって実行されることを特徴とする請求項1に記載の方法。オープン管理セキュリティプロトコルにおいて依拠当事者RPのためにユーザを認証するユーザ環境および/またはローカルアサーションエンティティLAEを保護するための方法であって、前記RPが前記ユーザを認証することを望んでいる旨の通知を、ユーザインタフェースを介して、前記RPから受信するステップであって、前記RPは、シングルサインオンSSO資格証明書のトラステッドプロバイダと通信することが可能である、ステップと、ユーザ資格証明書を、前記ユーザインタフェースを介して、前記ユーザから受け取るステップと、前記受け取ったユーザ資格証明書を用いて前記RPのために前記ユーザを認証するステップであって、前記認証プロセス中に前記ユーザ環境の外部との通信を制限するために、SSO資格証明書の前記トラステッドプロバイダの少なくともいくつかの機能をローカルで実行する、ステップと、認証応答を、前記ユーザインタフェースを介して、前記RPに送信するステップとを含むことを特徴とする方法。前記LAEは、トラステッドコンピューティング環境内に存在することを特徴とする請求項25に記載の方法。前記通知は、リダイレクションメッセージであることを特徴とする請求項26に記載の方法。前記リダイレクションメッセージは、前記トラステッドコンピューティング環境を使用して前記ユーザを認証するように前記ユーザインタフェースに命令することを特徴とする請求項27に記載の方法。前記ユーザを認証するステップは、トラステッドコンピューティング環境を介して実行されることを特徴とする請求項27に記載の方法。前記トラステッドコンピューティング環境は、ユニバーサル集積回路カードUICC、加入者識別モジュールSIM、機器対機器M2Mデバイス、スマートカードもしくはjava登録商標カード、グローバルプラットフォームスマートカード、または安全な統合チップカードICCのうちの1つであることを特徴とする請求項29に記載の方法。前記認証応答は、前記ユーザが認証されたときに、送信されることを特徴とする請求項26に記載の方法。前記トラステッドコンピューティング環境を用いて前記ユーザを認証するステップは、セキュアウェブサーバなど、安全なウェブサーバを使用して行われることを特徴とする請求項26に記載の方法。モバイルネットワーク通信事業者MNOに関連付けられたオープン管理セキュリティプロバイダと秘密を共有するステップをさらに含むことを特徴とする請求項26に記載の方法。モバイルネットワーク通信事業者MNOに関連付けられたOpenIDプロバイダと秘密を共有するステップをさらに含むことを特徴とする請求項26に記載の方法。シグネチャを計算するステップと、前記RPが前記トラステッドコンピューティング環境の資格証明書を検証することが可能なように、前記シグネチャを、前記ユーザインタフェースを介して、前記RPに提供するステップとをさらに含むことを特徴とする請求項29に記載の方法。前記ユーザインタフェースを介して、前記RPとともに共有秘密を確立するステップをさらに含むことを特徴とする請求項35に記載の方法。アソシエーションハンドルを前記RPから受信するステップをさらに含むことを特徴とする請求項36に記載の方法。前記共有秘密に基づいてシグネチャを生成するステップと、前記シグネチャと前記アソシエーションハンドルとを含む認証応答を生成するステップとをさらに含むことを特徴とする請求項37に記載の方法。シグネチャアサーションメッセージを前記RPから受信するステップをさらに含むことを特徴とする請求項38に記載の方法。シグネチャ応答メッセージを前記RPに送信するステップをさらに含むことを特徴とする請求項39に記載の方法。シグネチャを計算するステップと、前記OPが前記トラステッドコンピューティング環境の前記資格証明書を検証することが可能なように、前記シグネチャを、前記ユーザインタフェースを介して、前記OPに提供するステップとをさらに含むことを特徴とする請求項29に記載の方法。前記ユーザインタフェースを介して、前記OPとともに共有秘密を確立するステップをさらに含むことを特徴とする請求項41に記載の方法。アソシエーションハンドルを前記トラステッドコンピューティング環境から受信するステップと、前記アソシエーションハンドルを前記OPに送信するステップとをさらに含むことを特徴とする請求項36に記載の方法。前記共有秘密に基づいてシグネチャを生成するステップと、前記シグネチャと前記アソシエーションハンドルとを含む認証応答を生成するステップとをさらに含むことを特徴とする請求項43に記載の方法。シグネチャアサーションメッセージを前記OPから受信するステップをさらに含むことを特徴とする請求項44に記載の方法。シグネチャ応答メッセージを前記OPに送信するステップをさらに含むことを特徴とする請求項45に記載の方法。前記ユーザを認証するステップは、パスワード、PINコード、バイオメトリックアイデンティティ、トークン、またはそれらの組み合わせを用いて、前記ユーザを検証することによって実行されることを特徴とする請求項25に記載の方法。しかしながら、SSOをウェブサービスとして実施する場合、いくつかの不都合が生じる。例えば、ユーザは、ウェブベースのSSOプロバイダへの安全なチャネルを有さないことがある。加えて、ユーザは、SSOプロバイダを限定的にしか制御することができない。さらに、SSOにおける認証は、無線インタフェース通信を生じさせることがあり、無線インタフェース通信では、増加したトラフィックが、ネットワークエンティティすなわち、OpenIDプロバイダOPまたはNAFとネットワーク自体の両方において、負荷を生じさせることがある。加えて、モバイルネットワーク通信事業者MNO:mobilenetworkoperatorが、この追加のトラフィックおよび処理のコストを負担しなければならないことがある。本出願では、発明者らは、スマートカード、無線スマートフォン、HeNB、または他のタイプのデバイスなどの、トラステッド環境において、ローカルおよび分散シングルサインオンSSOプロバイダを実施することを可能にするための実施形態について説明する。シングルサインオンプロバイダは、OpenIDプロバイダ、リバティアライアンスLibertyAllianceもしくはカンターライニシアティブKantaraInitiativeに基づいたアイデンティティのプロバイダ、セキュリティアサーションマークアップ言語SAML:SecurityAssertionMarkupLanguageを使用するアイデンティティプロバイダ、またはオープン認証OAUTH:OpenAuthenticationプロバイダなどとすることができる。本出願は、異なるシナリオの集まりと、それらの実施オプションを提供する。説明される概念は、OpenIDプロトコルに関連したものとすることができるが、そのアイデアは、他のシングルサインオンSSOプロトコルおよび/または連合アイデンティティプロトコルに拡張可能である。例示的な一実施形態では、依拠当事者RP:relyingpartyがユーザを認証することを可能にするオープン管理セキュリティプロトコルを可能にするためのユーザ環境を使用することができる。ユーザ環境は、以下のものを備えることができる。RPによって提供されるサービスへのアクセスをユーザに代わって要求するために、シングルサインオンセキュリティプロトコルを使用して、RPと通信するユーザインタフェースであって、RPは、ユーザ環境の外部に存在することができ、ユーザの認証を開始するために、シングルサインオン資格証明書singlesign-oncredentialのトラステッドプロバイダtrustedproviderと通信する、ユーザインタフェース;およびトラステッドプロバイダのために、ユーザ環境内においてユーザを認証する、トラステッドコンピューティング環境などの、プロセッサであって、認証プロセス中にユーザ環境の外部との通信を制限するために、シングルサインオン資格証明書のトラステッドプロバイダの少なくともいくつかの機能をローカルで実行するように構成されるプロセッサ。別の例示的な実施形態では、OpenIDなどのオープン管理セキュリティプロトコルにおいて依拠当事者RPのためにユーザを認証するユーザ環境および/またはローカルアサーションエンティティLAE:localassertionentityを保護するための方法を使用することができる。方法は、以下のステップを含むことができる。RPがユーザを認証することを望んでいる旨のリダイレクションredirectionを、ユーザインタフェースを介して、RPから受信するステップであって、RPは、OpenIDプロバイダOPなどの、シングルサインオンSSO資格証明書のトラステッドプロバイダと通信することが可能である、ステップ;ユーザ資格証明書usercredentialを、ユーザインタフェースを介して、ユーザから受け取るステップ;受け取ったユーザ資格証明書を用いてRPのためにユーザを認証するステップであって、認証プロセス中にユーザ環境の外部との通信を制限するために、OPなどの、SSO資格証明書のトラステッドプロバイダの少なくともいくつかの機能をローカルで実行する、ステップ;および認証応答を、ユーザインタフェースを介して、RPに送信するステップ。この課題を解決するための手段は、以下の発明を実施するための形態においてさらに説明される概念の抜粋を簡略化された形式で紹介するために提供された。この課題を解決するための手段は、特許請求される発明の主要な特徴または必須の特徴を識別することを意図しておらず、特許請求される発明の範囲を限定するために使用されることも意図していない。さらに、特許請求される発明は、本開示のいずれかの部分で言及されるいずれかまたはすべての不都合を解決する実施形態に限定されない。本出願では、発明者らは、ユーザ機器UE、スマートカード、スマートフォン、HeNB、または他のタイプのデバイスなどの、トラステッド環境において実施される、ローカルおよび分散シングルサインオンSSOプロバイダのアイデアおよび概念について説明する。シングルサインオンプロバイダは、OpenIDプロバイダ、リバティアライアンスプロバイダ、またはオープン認証OAUTHプロバイダなどとすることができる。本出願は、異なるシナリオの集まりと、それらの実施オプションを提供する。説明される概念はOpenIDプロトコルに関連したものとすることができるが、そのアイデアは、他のシングルサインオンSSOプロトコルおよび/または連合アイデンティティプロトコルに拡張可能である。ローカルモバイルOpenIDなどの、ローカルモバイルSSOプロトコルは、ローカルに配置されたモジュールまたはエンティティが、OpenIDプロトコルなどの、SSOまたはアイデンティティ管理プロトコルの一部として、アイデンティティ認証/アサーションassertion機能を実行することを可能にする概念である。ローカルに配置されたモジュールは、スマートカード、SIM、ユニバーサル集積回路カードUICC、Java登録商標カード、スマートカードウェブサーバSCWS:smartcardwebserver対応のスマートカード、またはスマートフォンなどの無線デバイスとすることができる。ローカルモバイルSSOは、従来はウェブベースのSSOサーバによって実行されたシングルサインオンSSOおよび関連するアイデンティティ管理機能の一部もしくは全部が、通信デバイス自体の一部もしくは全部であるローカルベースのエンティティおよび/もしくはモジュールによって代わりに実行される方法、またはそのようなエンティティ/モジュールが、通信デバイスおよび/もしくはそのユーザの近傍に物理的および/もしくは論理的に配置されるすなわちローカルに配置される方法を一括して指すために使用される用語である。例えば、エンティティ/モジュールは、デバイス内に組み込むこと、デバイスに取り付けること、またはローカルインタフェース、配線、もしくは短距離無線手段によってデバイスに接続することができる。ローカルOpenIDも、SSOまたはアイデンティティ管理の方法がOpenIDプロトコルに基づく、ローカルモバイルSSO方法のサブセットを指す用語として使用することができる。例えば、ローカルOpenIDは、ローカルに配置されたエンティティ/モジュールによって実行できる、OpenIDアイデンティティプロバイダ省略表記ではOPまたはOpenIDIdPの機能を指すために使用することができる。ローカルIdPは、OpenIDサーバの機能を実行するエンティティまたはモジュールを指すために使用される用語である。ローカルIdPを表すのに、頭字語OPlocを使用することができる。ローカルIdPの主要な機能の1つは、ユーザおよび/またはデバイスのアイデンティティについてのアサーションを通して、ユーザおよび/またはデバイスの認証を円滑化することとすることができる。そのようなアサーションは、ローカルIdPからデバイス上で動作するブラウザエージェントBAに送信することができ、その後、BAは、アサーションを外部の依拠当事者RPに転送することができる。ローカルIdPによって提供される機能が、主としてそのようなアイデンティティアサーションを提供することに限定される場合、ローカルIdPは、ローカルアサーションエンティティLAEと呼ばれることもある。ローカルIdPは、アサーションメッセージを処理し、生成し、管理し、または1つもしくは複数の外部の受信先に送信することができる。アサーションメッセージは、ユーザおよび/またはデバイスに関連する1つまたは複数のアイデンティティの検証の状態をアサートすることができる。例えば、OpenIDプロトコルでは、依拠当事者RPと呼ばれるサードパーティエンティティを、アサーションメッセージの受信先の1つとすることができる。ローカルIdPは、シグネチャ、暗号鍵、または暗号などを使用して、アサーションメッセージに署名することもできる。ローカルOpenID方法は、ルートセッション鍵など、1つまたは複数の暗号鍵を使用することができる。ルートセッション鍵は、Krpによって表すことができ、RPとOPの間で使用することを意図したセッション鍵とすることができる。Krpは、他の鍵を導出できる、RPとOPの間のルートセッション鍵としての役割を果たすこともできる。ローカルOpenID方法は、Kascによって表すことができる、アサーション鍵を使用することもできる。Kascは、ユーザの認証のためのアサーションメッセージの1つまたは複数に署名するために使用される署名鍵とすることができる。Kascは、Krpから導出することができる。ローカルOpenID方法は、OpenIDサーバ機能OPSF:OpenIDServerFunctionと呼ばれるサービスを使用することもでき、OPSFの役割は、ローカルIdPおよび/または依拠当事者RPによって使用できる秘密を生成し、共有し、分配することとすることができる。OPSFとローカルIdPは、外部のRPには単一のエンティティとして見えることがある。OPSFは、ローカルOpenIDによって発行されたシグネチャを検証することもできてよく、例えば、公衆インターネットを介して、RPから直接的に到達可能とすることができる。デバイス上のブラウザは、OPSFのアドレスがローカルIdPにマッピングされるように、デバイス上のローカルDNS解決キャッシュを変更することによって、ローカルIdPにリダイレクトすることができる。ローカルOpenID方法は、OP-aggによって表されるサービスを使用することもでき、OP-aggの役割は、RPに代わって、ローカルIdPの発見を円滑化することとすることができる。1通信システム図1Aは、1つまたは複数の開示される実施形態を実施できる例示的な通信システム100の図である。通信システム100は、音声、データ、ビデオ、メッセージング、放送などのコンテンツを複数の無線ユーザに提供する、多元接続システムとすることができる。通信システム100は、複数のユーザが、固定有線または無線通信帯域幅を含むシステムリソースの共用を通して、そのようなコンテンツにアクセスできるようにすることができる。例えば、通信システム100は、符号分割多元接続CDMA、時分割多元接続TDMA、周波数分割多元接続FDMA、直交FDMAOFDMA、およびシングルキャリアFDMASC-FDMAなど、1つまたは複数の固定有線または無線チャネルアクセス方法を利用することができる。図1Aに示されるように、通信システム100は、無線送受信ユニットWTRU102a、102b、102c、102d、無線アクセスネットワークRAN104、コアネットワーク106、公衆交換電話網PSTN108、インターネット110、および他のネットワーク112を含むことができるが、開示される実施形態は、任意の数のWTRU、基地局、ネットワーク、および/またはネットワーク要素を企図していることが理解されよう。WTRU102a、102b、102c、102dの各々は、無線または固定有線環境において動作および/または通信するように構成された任意のタイプのデバイスとすることができる。例を挙げると、WTRU102a、102b、102c、102dは、無線信号を送信および/または受信するように構成することができ、ユーザ機器UE、移動局、固定もしくは移動加入者ユニット、ページャ、セルラ電話、携帯情報端末PDA、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、および家電製品などを含むことができる。通信システム100は、基地局114aおよび基地局114bも含むことができる。基地局114a、114bの各々は、WTRU102a、102b、102c、102dの少なくとも1つと無線でインタフェースを取って、コアネットワーク106、インターネット110、および/またはネットワーク112などの1つまたは複数の通信ネットワークへのアクセスを円滑化するように構成された、任意のタイプのデバイスとすることができる。例を挙げると、基地局114a、114bは、送受信機基地局BTS、ノードB、eノードB、ホームノードB、ホームeノードB、サイトコントローラ、アクセスポイントAP、および無線ルータなどとすることができる。基地局114a、114bは各々、単一の要素として示されているが、基地局114a、114bは、任意の数の相互接続された基地局および/またはネットワーク要素を含むことができることが理解されよう。基地局114aは、RAN104の部分とすることができ、RAN104は、他の基地局、および/または基地局コントローラBSC、無線ネットワークコントローラRNC、中継ノードなどのネットワーク要素図示されずも含むことができる。基地局114aおよび/または基地局114bは、セル図示されずと呼ばれることがある特定の地理的領域内で、無線信号を送信および/または受信するように構成することができる。セルは、さらにセルセクタに分割することができる。例えば、基地局114aに関連付けられたセルは、3つのセクタに分割することができる。したがって、一実施形態では、基地局114aは、送受信機を3つ、すなわち、セルのセクタ毎に1つずつ含むことができる。別の実施形態では、基地局114aは、多入力多出力MIMO技術を利用することができ、したがって、セルのセクタ毎に複数の送受信機を利用することができる。基地局114a、114bは、エアインタフェース116を介して、WTRU102a、102b、102c、102dの1つまたは複数と通信することができ、エアインタフェース116は、任意の適切な無線通信リンク例えば、無線周波RF、マイクロ波、赤外線IR、紫外線UV、可視光などとすることができる。エアインタフェース116は、任意の適切な無線アクセス技術RATを使用して確立することができる。より具体的には、上で言及したように、通信システム100は、多元接続システムとすることができ、CDMA、TDMA、FDMA、OFDMA、およびSC-FDMAなどの1つまたは複数の固定有線または無線チャネルアクセス方式を利用することができる。例えば、RAN104内の基地局114a、およびWTRU102a、102b、102cは、広帯域CDMAWCDMAを使用してエアインタフェース116を確立できる、ユニバーサル移動体通信システムUMTS地上無線アクセスUTRAなどの無線技術を実施することができる。WCDMAは、高速パケットアクセスHSPAおよび/または進化型HSPAHSPAなどの通信プロトコルを含むことができる。HSPAは、高速ダウンリンクパケットアクセスHSDPAおよび/または高速アップリンクパケットアクセスHSUPAを含むことができる。別の実施形態では、基地局114a、およびWTRU102a、102b、102cは、ロングタームエボリューションLTEおよび/またはLTEアドバンストLTE-Aを使用してエアインタフェース116を確立できる、進化型UMTS地上無線アクセスE-UTRAなどの無線技術を実施することができる。他の実施形態では、基地局114a、およびWTRU102a、102b、102cは、IEEE802.16すなわちマイクロ波アクセス用の世界的相互運用性WiMAX、CDMA2000、CDMA20001X、CDMA2000EV-DO、暫定標準2000IS-2000、暫定標準95IS-95、暫定標準856IS-856、移動体通信用グローバルシステムGSM、GSM進化型高速データレートEDGE、およびGSMEDGEGERANなどの無線技術を実施することができる。図1Aの基地局114bは、例えば、無線ルータ、ホームノードB、ホームeノードB、またはアクセスポイントとすることができ、職場、家庭、乗物、およびキャンパスなどの局所的エリアにおける無線接続性を円滑化するための任意の適切なRATを利用することができる。一実施形態では、基地局114b、およびWTRU102c、102dは、IEEE802.11などの無線技術を実施して、無線ローカルエリアネットワークWLANを確立することができる。別の実施形態では、基地局114b、およびWTRU102c、102dは、IEEE802.15などの無線技術を実施して、無線パーソナルエリアネットワークWPANを確立することができる。また別の実施形態では、基地局114b、およびWTRU102c、102dは、セルラベースのRAT例えば、WCDMA、CDMA2000、GSM、LTE、LTE-Aなどを利用して、ピコセルまたはフェムトセルを確立することができる。図1Aに示されるように、基地局114bは、インターネット110への直接的な接続を有することがある。したがって、基地局114bは、コアネットワーク106を介して、インターネット110にアクセスする必要がないことがある。RAN104は、コアネットワーク106と通信することができ、コアネットワーク106は、音声、データ、アプリケーション、および/またはボイスオーバインターネットプロトコルVoIPサービスをWTRU102a、102b、102c、102dの1つまたは複数に提供するように構成された、任意のタイプのネットワークとすることができる。例えば、コアネットワーク106は、呼制御、請求サービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続性、ビデオ配信などを提供することができ、および/またはユーザ認証など、高レベルのセキュリティ機能を実行することができる。図1Aには示されていないが、RAN104および/またはコアネットワーク106は、RAN104と同じRATまたは異なるRATを利用する他のRANと直接的または間接的に通信できることが理解されよう。例えば、E-UTRA無線技術を利用できるRAN104に接続するのに加えて、コアネットワーク106は、GSM無線技術を利用する別のRAN図示されずと通信することもできる。コアネットワーク106は、PSTN108、インターネット110、および/または他のネットワーク112にアクセスするための、WTRU102a、102b、102c、102dのためのゲートウェイとしての役割を果たすこともできる。PSTN108は、基本電話サービスPOTSを提供する回路交換電話網を含むことができる。インターネット110は、TCP/IPインターネットプロトコルスイート内の伝送制御プロトコルTCP、ユーザデータグラムプロトコルUDP、およびインターネットプロトコルIPなど、共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークとデバイスとからなるグローバルシステムを含むことができる。ネットワーク112は、他のサービスプロバイダによって所有および/または運営される有線または無線通信ネットワークを含むことができる。例えば、ネットワーク112は、RAN104と同じRATまたは異なるRATを利用できる1つまたは複数のRANに接続された、別のコアネットワークを含むことができる。通信システム100内のWTRU102a、102b、102c、102dのいくつかまたはすべては、マルチモード機能を含むことができ、すなわち、WTRU102a、102b、102c、102dは、異なる無線リンクを介して異なる無線ネットワークと通信するための複数の送受信機を含むことができる。例えば、図1Aに示されたWTRU102cは、セルラベースの無線技術を利用できる基地局114aと通信するように、またIEEE802無線技術を利用できる基地局114bと通信するように構成することができる。図1Bは、例示的なWTRU102のシステム図である。図1Bに示されるように、WTRU102は、プロセッサ118と、送受信機120と、送信/受信要素122と、スピーカ/マイクロフォン124と、キーパッド126と、ディスプレイ/タッチパッド128と、着脱不能メモリ106と、着脱可能メモリ132と、電源134と、全地球測位システムGPSチップセット136と、他の周辺機器138とを含むことができる。WTRU102は、一実施形態との整合性を保ちながら、上記の要素の任意のサブコンビネーションを含むことができる。プロセッサ118は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサDSP、複数のマイクロプロセッサ、DSPコアと連携する1つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路ASIC、フィールドプログラマブルゲートアレイFPGA回路、他の任意のタイプの集積回路IC、および状態機械などとすることができる。プロセッサ118は、信号符号化、データ処理、電力制御、入出力処理、および/またはWTRU102が無線環境で動作できるようにする他の任意の機能を実行することができる。プロセッサ118は、送受信機120に結合することができ、送受信機120は、送信/受信要素122に結合することができる。図1Bは、プロセッサ118と送受信機120を別々のコンポーネントとして示しているが、プロセッサ118と送受信機120は、電子パッケージまたはチップ内に一緒に統合できることが理解されよう。送信/受信要素122は、エアインタフェース116を介して、基地局例えば基地局114aに信号を送信し、または基地局から信号を受信するように構成することができる。例えば、一実施形態では、送信/受信要素122は、RF信号を送信および/または受信するように構成されたアンテナとすることができる。別の実施形態では、送信/受信要素122は、例えば、IR、UV、または可視光信号を送信および/または受信するように構成された放射器/検出器とすることができる。また別の実施形態では、送信/受信要素122は、RF信号と光信号の両方を送信および受信するように構成することができる。送信/受信要素122は、無線信号の任意の組み合わせを送信および/または受信するように構成できることが理解されよう。加えて、図1Bでは、送信/受信要素122は単一の要素として示されているが、WTRU102は、任意の数の送信/受信要素122を含むことができる。より具体的には、WTRU102は、MIMO技術を利用することができる。したがって、一実施形態では、WTRU102は、エアインタフェース116を介して無線信号を送信および受信するための2つ以上の送信/受信要素122例えば複数のアンテナを含むことができる。送受信機120は、送信/受信要素122によって送信される信号を変調し、送信/受信要素122によって受信された信号を復調するように構成することができる。上で言及したように、WTRU102は、マルチモード機能を有することができる。したがって、送受信機120は、WTRU102が、例えばUTRAおよびIEEE802.11などの複数のRATを介して通信できるようにするための、複数の送受信機を含むことができる。WTRU102のプロセッサ118は、スピーカ/マイクロフォン124、キーパッド126、および/またはディスプレイ/タッチパッド128例えば、液晶表示LCDディスプレイユニットもしくは有機発光ダイオードOLEDディスプレイユニットに結合することができ、それらからユーザ入力データを受け取ることができる。プロセッサ118は、スピーカ/マイクロフォン124、キーパッド126、および/またはディスプレイ/タッチパッド128にユーザデータを出力することもできる。加えて、プロセッサ118は、着脱不能メモリ106および/または着脱可能メモリ132など、任意のタイプの適切なメモリから情報を入手することができ、それらにデータを記憶することができる。着脱不能メモリ106は、ランダムアクセスメモリRAM、リードオンリメモリROM、ハードディスク、または他の任意のタイプのメモリ記憶デバイスを含むことができる。着脱可能メモリ132は、加入者識別モジュールSIMカード、メモリスティック、およびセキュアデジタルSDメモリカードなどを含むことができる。他の実施形態では、プロセッサ118は、WTRU102上に物理的に配置されたメモリではなく、サーバまたはホームコンピュータ図示されずなどの上に配置されたメモリから情報を入手することができ、それにデータを記憶することができる。プロセッサ118は、アプリケーションレイヤプログラム例えばブラウザ、無線アクセスレイヤRANプログラム、および/または通信プログラムを実行することができる。プロセッサ118は、認証などのセキュリティ動作、セキュリティ鍵合意動作、および/または暗号化動作などを実行することができる。これらの動作は、アクセスレイヤまたはアプリケーションレイヤなどにおいて実行することができる。プロセッサ118は、電源134から電力を受け取ることができ、WTRU102内の他のコンポーネントへの電力の分配および/または制御を行うように構成することができる。電源134は、WTRU102に給電するための任意の適切なデバイスとすることができる。例えば、電源134は、1つまたは複数の乾電池例えば、ニッケル-カドミウムNiCd、ニッケル-亜鉛NiZn、ニッケル水素NiMH、リチウムイオンLi-ionなど、太陽電池、および燃料電池などを含むことができる。プロセッサ118は、GPSチップセット136に結合することもでき、GPSチップセット136は、WTRU102の現在位置に関する位置情報例えば経度および緯度を提供するように構成することができる。GPSチップセット136からの情報に加えて、またはその代わりに、WTRU102は、基地局例えば基地局114a、114bからエアインタフェース116を介して位置情報を受け取ることができ、および/または2つ以上の近くの基地局から受信した信号のタイミングに基づいて、自らの位置を決定することができる。WTRU102は、一実施形態との整合性を保ちながら、任意の適切な位置決定方法を用いて、位置情報を獲得できることが理解されよう。プロセッサ118は、他の周辺機器138にさらに結合することができ、他の周辺機器138は、追加的な特徴、機能、および/または有線もしくは無線接続性を提供する、1つまたは複数のソフトウェアモジュールおよび/またはハードウェアモジュールを含むことができる。例えば、周辺機器138は、加速度計、eコンパス、衛星送受信機、写真またはビデオ用のデジタルカメラ、ユニバーサルシリアルバスUSBポート、バイブレーションデバイス、テレビ送受信機、ハンズフリーヘッドセット、Bluetooth登録商標モジュール、周波数変調FMラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、およびインターネットブラウザなどを含むことができる。図1Cは、一実施形態による、RAN104およびコアネットワーク106のシステム図である。上で言及したように、RAN104は、E-UTRA無線技術を利用して、エアインタフェース116を介してWTRU102a、102b、102cと通信することができる。RAN104は、コアネットワーク106と通信することもできる。RAN104は、eノードB140a、140b、140cを含むことができるが、RAN104は、一実施形態との整合性を保ちながら、任意の数のeノードBを含むことができることが理解されよう。eノードB140a、140b、140cは、各々が、エアインタフェース116を介してWTRU102a、102b、102cと通信するための1つまたは複数の送受信機を含むことができる。一実施形態では、eノードB140a、140b、140cは、MIMO技術を実施することができる。したがって、eノードB140aは、例えば、複数のアンテナを使用して、WTRU102aに無線信号を送信し、WTRU102aから無線信号を受信することができる。eノードB140a、140b、140cの各々は、特定のセル図示されずに関連付けることができ、無線リソース管理決定、ハンドオーバ決定、ならびにアップリンクおよび/またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成することができる。図1Cに示されるように、eノードB140a、140b、140cは、X2インタフェースを介して互いに通信することができる。図1Cに示されるコアネットワーク106は、モビリティ管理ゲートウェイMME142、サービングゲートウェイ144、およびパケットデータネットワークPDNゲートウェイ146を含むことができる。上記の要素の各々は、コアネットワーク106の部分として示されているが、これらの要素は、どの1つをとっても、コアネットワーク運営体とは異なる主体によって所有および/または運営できることが理解されよう。MME142は、S1インタフェースを介して、RAN104内のeノードB140a、140b、140cの各々に接続することができ、制御ノードとしての役割を果たすことができる。例えば、MME142は、WTRU102a、102b、102cのユーザの認証、ベアラ活動化/非活動化、WTRU102a、102b、102cの初期接続中における特定のサービングゲートウェイの選択などを担うことができる。MME142は、RAN104とGSMまたはWCDMAなどの他の無線技術を利用する他のRAN図示されずとの間の交換のための制御プレーン機能を提供することもできる。サービングゲートウェイ144は、S1インタフェースを介して、RAN104内のeノードB140a、140b、140cの各々に接続することができる。サービングゲートウェイ144は、一般に、ユーザデータパケットをWTRU102a、102b、102cに/からルーティングおよび転送することができる。サービングゲートウェイ144は、eノードB間ハンドオーバ中におけるユーザプレーンのアンカリングanchoring、ダウンリンクデータがWTRU102a、102b、102cに利用可能な場合に行う一斉呼出のトリガ、ならびにWTRU102a、102b、102cのコンテキストの管理および記憶など、他の機能を実行することもできる。サービングゲートウェイ144は、PDNゲートウェイ146に接続することもでき、PDNゲートウェイ146は、インターネット110などのパケット交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cとIP対応デバイスの間の通信を円滑化することができる。コアネットワーク106は、他のネットワークとの通信を円滑化することができる。例えば、コアネットワーク106は、PSTN108などの回路交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cと従来の陸線通信デバイスの間の通信を円滑化することができる。例えば、コアネットワーク106は、コアネットワーク106とPSTN108の間のインタフェースとしての役割を果たすIPゲートウェイ例えばIPマルチメディアサブシステムIMSサーバを含むことができ、またはIPゲートウェイと通信することができる。加えて、コアネットワーク106は、ネットワーク112へのアクセスをWTRU102a、102b、102cに提供することができ、ネットワーク112は、他のサービスプロバイダによって所有および/または運営される他の有線または無線ネットワークを含むことができる。2.3アイデンティティ管理および使用可能なセキュリティユーザがモバイルデバイスにおいて情報へのアクセスに携わるようになるとユーザは、ウェブサービス別の多数のユーザ資格証明書を扱うというジレンマに直面する。ユーザは、これらの資格証明書を覚えておき、ウェブサービスにアクセスするたびに、ログイン情報およびパスワード情報を入力するという面倒な作業に直面する。デバイスがこれらの資格証明書を覚えておくこともできるが、デバイスは、紛失すること、または盗難にあうことがあり、悪者の手に渡ることもある。ローカルユーザ認証を透過的なネットワーク認証と組み合わせて、ユーザ資格証明書、およびウェブサービスへのアクセスを安全に管理する、堅牢な認証ソリューションを提供することができる。例えば、様々なパスワードもしくはトークンの入力、および/またはバイオメトリック認証技術を、ウェブサービスポータルとともに機能する無料のシームレスなネットワーク認証方式とともに使用することができる。これらの方式は、シングルサインオンSSOまたは連合アイデンティティと呼ばれることがある。UEを含むことができるモバイルプラットフォームは、様々な独自仕様のプロセッサアーキテクチャおよびオペレーティングシステムをサポートすることができる。これにより、ソフトウェア/ファームウェア開発業者について、断片化された市場が形成され、通信事業者は、アクセス制御および認証などの一般的な技術を組み込み、サポートするために、OEMと交渉することを強いられる。以下のセクションでは、モバイルプラットフォームにおいてSSOプロトコルを提供する実施形態について説明する。例示的な一実施形態では、依拠当事者RPがユーザを認証することを可能にするオープン管理セキュリティプロトコルを可能にするために、ユーザ環境を使用することができる。オープン管理セキュリティプロトコルは、OpenIDプロトコル、リバティアライアンスプロトコル、オープン認証OAUTHプロトコル、セキュリティアサーションマークアップ言語、またはアイデンティティ保証フレームワークなどの、シングルサインオンプロトコルSSOとすることができる。依拠当事者は、ユーザの資格証明書を認証または検証することを望んでいる当事者とすることができる。ユーザ環境は、ユーザインタフェース、および/またはトラステッドコンピューティング環境などのプロセッサから成ることができる。ユーザインタフェースは、UEとユーザの間のインタフェースを提供することができる。例えば、ユーザインタフェースは、ウェブブラウザ、ウェブページ、またはアプリケーションなどとすることができる。ユーザインタフェースは、ユーザ資格証明書を受け取ることもできる。ユーザ資格証明書は、ユーザ名、パスワード、PINコード、秘密鍵、トークン、またはバイオメトリックアイデンティティの組み合わせとすることができる。ユーザインタフェースは、インタフェースを提供することができ、および/またはRPによって提供されるサービスへのアクセスをユーザに代わって要求するために、OpenIDなどのSSOプロトコルを使用して、RPと通信することができる。例えば、ユーザは、ウェブブラウザなどのユーザインタフェースエージェントを使用して、RPを訪れることができ、OpenIDを使用してログインすることを選択することができる。ユーザインタフェースは、RPがユーザを認証することを望んでいる旨の通知をRPから受信することもできる。例えば、ユーザインタフェースは、トラステッドコンピューティング環境を使用してユーザを認証するようにユーザインタフェースに命令する、リダイレクションメッセージをRPから受信することができる。ユーザインタフェースは、ユーザの認証を開始するために、SSO資格証明書のトラステッドプロバイダと通信することもできる。例えば、RPは、ユーザインタフェースをトラステッドコンピューティング環境にリダイレクトすることができ、トラステッドコンピューティング環境は、トラステッドプロバイダに関連付けることができる。トラステッドプロバイダは、ユーザ資格証明書のプロバイダとすることができる。例えば、トラステッドプロバイダは、ユーザを知っていることができ、供給されたユーザ資格証明書を用いてユーザを認証することが可能である。プロセッサは、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサDSP、複数のマイクロプロセッサ、DSPコアと連携する1つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路ASIC、フィールドプログラマブルゲートアレイFPGA回路、他の任意のタイプの集積回路IC、および状態機械などとすることができる。加えて、プロセッサは。例示的な一実施形態では、プロセッサは、UMTS集積回路カードUICC、加入者識別モジュールSIM、機器対機器M2M:machinetomachineデバイス、スマートカード、Java登録商標カード、グローバルプラットフォームglobalplatformスマートカード、または安全な統合チップカードICCなどの、トラステッドコンピューティング環境とすることができる。トラステッドコンピューティング環境は、スマートカードウェブサーバSCWSを使用して実施することができる。トラステッドコンピューティング環境は、トラステッドプロバイダのために、ユーザ環境内においてユーザを認証することができる。ユーザを認証するため、トラステッドコンピューティング環境は、認証プロセス中にユーザ環境の外部との通信を制限するために、シングルサインオン資格証明書のトラステッドプロバイダの少なくともいくつかの機能をローカルで実行することができる。例えば、ユーザは、PINコード、バイオメトリックアイデンティティ、もしくはトークンなど、またはそれらの組み合わせすなわち、PINコードとバイオメトリックアイデンティティを用いて、トラステッドコンピューティング環境からローカルで認証を受けることができる。トラステッドコンピューティング環境は、認証応答を生成することができる。トラステッドコンピューティング環境は、ユーザが認証された旨のアサーションを含むことができるリダイレクトメッセージを用いて、ユーザインタフェースエージェントをRPにリダイレクトすることができる。その後、ユーザインタフェースは、RPにリダイレクトすることができ、ユーザは、RPがトラステッドコンピューティング環境からのアサーションを検証した後、ログインすることができる。例示的な一実施形態では、トラステッドコンピューティング環境は、base64符号化HMACシグネチャなどの、シグネチャを計算することができ、シグネチャを、ユーザインタフェースを介して、RPに提供することができる。これを行うことで、例えば、RPがトラステッドコンピューティング環境の資格証明書を検証することを可能にすることができる。トラステッド環境は、トラステッドコンピューティング環境と、MNOまたはOPに関連付けることができるトラステッドプロバイダとの間の共有秘密に基づいて、シグネチャを計算することができる。共有秘密は、ユーザインタフェースを介して、トラステッドコンピューティング環境とトラステッドプロバイダの間で確立することができる。シグネチャは、RPから受信したパラメータのリストに署名するために使用することができる。依拠当事者RPは、サービス、ウェブサイト、データベース、またはアプリケーションなどとすることができる。例示的な一実施形態では、RPは、ユーザ環境の外部に存在することができる。例えば、RPは、ウェブサイトにアクセスするためにユーザによって使用されているセルフォンまたは他のUEなどのユーザ環境の外部に存在する、サーバ上でホストされるウェブサイトとすることができる。RPは、例えば、モバイルネットワーク通信事業者MNOによって提供される、ウェブサービスエンティティへの公衆インターネット通信を使用して、接続を確立しなければならないことがある。これは、例えば、依拠当事者RPがトラステッドコンピューティング環境と直接的に通信できない場合に行うことができる。MNOは、トラステッドコンピューティング環境とのリモート管理インタフェースと、例えばSMSとしての、追加の通信チャネルとを有することができ、それらは、MNOが、UEおよび/またはトラステッドコンピューティング環境と通信することを可能にすることができる。MNOは、RPとトラステッドコンピューティング環境上のOPの間の交渉の橋渡しnegotiatingbridgeとしての役割を果たすことができる。別の例示的な実施形態では、RPは、ユーザ環境内に存在することができる。例えば、ユーザインタフェースおよびトラステッドコンピューティング環境を含むことができるUE内において、RPをホストすることができる。例示的な一実施形態では、RPは、RPがトラステッドコンピューティング環境の資格証明書を検証することが可能なように、認証要求を送信するように構成することができる。ユーザインタフェースは、RPから認証要求を受信することができる。認証要求は、アソシエーションハンドルassociationhandleを含むことができる。ユーザインタフェースは、トラステッドコンピューティング環境にアソシエーションハンドルを提供することができる。トラステッドコンピューティング環境は、共有秘密に基づいて、シグネチャを生成することができ、シグネチャおよびアソシエーションハンドルを含む認証応答を生成することができる。ユーザインタフェースまたはトラステッドコンピューティング環境は、トラステッド環境によって生成された認証応答をRPに提供することができる。例示的な一実施形態では、ユーザ環境は、ユーザ機器UE内に存在することができる。例えば、ユーザインタフェースおよびトラステッドコンピューティング環境を、単一のUE内に含むことができる。別の例示的な実施形態では、ユーザ環境は、ユーザインタフェースとトラステッドコンピューティング環境が別々のUE内に存在できる、分割端末構成で配備することができる。例えば、ユーザインタフェースは、ユーザに属するセルフォン上に存在することができ、一方、トラステッドコンピューティング環境は、ユーザに属する銀行カードまたはUICC上に存在することができる。別の例として、ユーザインタフェースは、ユーザに属するパーソナルコンピュータ上に存在することができ、一方、トラステッドコンピューティング環境は、ユーザに属するセルフォン上に存在することができる。例示的な一実施形態では、オープン管理セキュリティプロトコルにおいて依拠当事者RPのためにユーザを認証するユーザ環境および/またはローカルアサーションエンティティLAEを保護するための方法を提供することができる。例示的な一実施形態では、LAEは、トラステッドコンピューティング環境などのプロセッサ内に存在することができる。RPがユーザを認証することを望んでいる旨のRPからの通知を、ユーザインタフェースを介して受信することができる。RPは、ユーザ環境の外部に存在することができ、シングルサインオンSSO資格証明書のトラステッドプロバイダと通信可能とすることができる。ユーザ資格証明書を、ユーザインタフェースを介して、ユーザから受け取ることができる。受け取ったユーザ資格証明書を用いて、ユーザを認証することができる。例えば、トラステッドコンピューティング環境などのプロセッサは、受け取ったユーザ資格証明書を用いてRPのためにユーザを認証することができ、認証プロセス中にユーザ環境の外部との通信を制限するために、SSO資格証明書のトラステッドプロバイダの少なくともいくつかの機能をローカルで実行する。認証は、スマートカードウェブサーバSCWSを使用したものとすることができる。認証応答を、ユーザインタフェースを介して、RPに送信することができる。例えば、ユーザが認証されたときに、認証応答を送信することができる。RPから受信する通知は、リダイレクションメッセージとすることができる。リダイレクションメッセージは、トラステッドコンピューティング環境を使用してユーザを認証するようにユーザインタフェースに命令することができる。例えば、リダイレクションメッセージは、トラステッドプロバイダを用いて認証する代わりに、ユーザをローカルで認証するように、ブラウザに指示することができる。base64符号化HMACシグネチャなどの、シグネチャを計算することができ、シグネチャを、ユーザインタフェースを介して、RPに提供することができる。これを行うことで、例えば、RPがトラステッドコンピューティング環境の資格証明書を検証することを可能にすることができる。トラステッドコンピューティング環境は、トラステッドコンピューティング環境と、MNOに関連付けることができる、OpenIDプロバイダなどの、トラステッドプロバイダとの間の共有秘密に基づいて、シグネチャを計算することができる。共有秘密は、ユーザインタフェースを介して、トラステッドコンピューティング環境とトラステッドプロバイダの間で確立することができる。例示的な一実施形態では、RPがトラステッドコンピューティング環境の資格証明書を検証することを可能にすることができる認証要求をRPから受信することができる。例えば、ユーザインタフェースは、RPから認証要求を受信することができる。認証要求は、アソシエーションハンドルを含むことができる。ユーザインタフェースは、トラステッドコンピューティング環境にアソシエーションハンドルを提供することができる。共有秘密に基づいたシグネチャを生成することができる。シグネチャとアソシエーションハンドルとを含む認証応答を生成することもできる。その後、認証応答をRPに提供することができる。2.3.2OpenIDおよびSCWSを使用するシングルサインオンについての実施形態OpenIDは、通信事業者に軽減された役割を提供することができ、OpenIDプロバイダOPに対する信用を、最小の労力およびリスクで、依拠当事者RPに提供することができる。OpenIDは、既存の認証方法とともに機能することができ、したがって、通信事業者は、OP自身のAAA資格証明書およびUICC内の事前提供されたAKA資格証明書を使用して、またはPKI、事前共有鍵、SIPダイジェスト資格証明書、TLSなどを含むが、これらに限定されない、他の認証方法を使用して、OPに対して認証手順をサポートすることができる。OpenIDとスマートカードの組み合わせは、興味深い価値提案valuepropositionに至る道を提供する。スマートカードウェブサーバSCWSは、新しいIPベースのサービスを提供し、このサービスは、はるかに豊かで安全なウェブエクスペリエンスをユーザに提供することができる。ウェブサーバの基本機能は、HTTPプロトコルを使用した、ウェブページの配信である。これは、スマートカードまたはUICC上に存在するSCWSについても同じである。SCWSは、モバイルフォンプロバイダのIPネットワーク内のネットワークノードとしてUICCを統合する際の、最初のステップとすることができる。例示的な一実施形態では、UICCは、通信事業者のためのローカル信用センタおよびプロキシとして使用することができる。これを行うことで、例えば、認証トラフィックをローカルに保ち、通信事業者ネットワークに負担がかかるのを防止することができる。OPは、認証強度を増減させて、OpenID資格証明書を、UICCおよび/またはデバイスおよび/または加入者識別情報および/または加入者に結び付ける、多くの方法を可能にする。OpenIDは、例えば、UICCベースのUE認証AKA資格証明書もしくはGBAとともに、または証明書ベースの認証メカニズムなど、他の形態の認証メカニズムとともに相互動作することができる。本明細書で開示される実施形態では、UEは、デバイス上のOPプロキシに対する通信事業者の信用および評判を利用することができ、標準的なOpenIDプロトコルよりも高いセキュリティを提供する。2.3.3スマートカード上のOP以下のセクション4において説明されるいくつかの実施形態は、スマートカード上にOPを組み込むことについて説明する。例えば、一実施形態は、スマートカードウェブサーバSCWSが存在する、スマートカード上のOpenIDについて説明する。別の例示的な実施形態は、SCWS上のOpenIDに対する改良について説明する。本明細書で説明される実施形態から得られる利点は、以下のものを含むことができる。●OpenIDの使用におけるユーザ移動性。●必須情報が今ではクラウド内ではなくカード上に存在するので、この資格証明書に対するユーザ制御が改善されるセキュリティ保護が強化される。●GBAを使用する必要性が減少したことで、ネットワークリソースにかかる負荷の大幅な削減がもたらされる。●認証トラフィックは、いずれも無線を必要としないネットワークエンティティ間の公衆インターネット内に限定される。このことは、SCWS上のOpenIDのために改良されたプロトコルの場合は明らかである。3標準化の展望多くの正式標準およびデファクトスタンダード業界標準の標準化団体が、アイデンティティ管理IdMに取り組んでいるが、これらの団体のほとんどは、デスクトップ環境におけるIdMの使用に重点を置いている。本明細書で開示される実施形態は、スマートカードなどのトラステッド環境内で実施できる、またはトラステッドコンピューティング環境を含むことができる、スマートフォン、HeNB、もしくは他のタイプのデバイスなどのプラットフォーム上で実施できる、ローカルおよび/または分散SSOプロバイダを通してIdMを提供する。シングルサインオンプロバイダは、リバティアライアンスプロバイダ、SAMLプロバイダ、カンターライニシアティブプロバイダ、またはOpenIDプロバイダなど、標準化団体によって提供されるシングルサインオンプロバイダとすることができる。3.2リバティアライアンスリバティアライアンスは、BT、AOL、オラクル、インテル、NTT、CA、フィデリティインベストメンツ、NTT、およびサンマイクロシステムズなどの企業によって主導される業界フォーラムとして発足した。アライアンスは、IDフェデレーションID-FFおよびアイデンティティウェブサービスID-WSFを扱う仕様からなる、リバティアライアンスフレームワークシリーズをリリースしている。リバティアイデンティティフェデレーションID-FF仕様1.0は、インターネットベースのサービスおよびeコマースアプリケーションの消費者およびユーザが、一度いずれかのデバイスにおいて認証を受け、ネットワークまたはドメインにサインオンすれば、その後は複数のウェブサイトのサービスを訪れることを可能にし、それによって、ユーザが再度認証を受け、プライバシ問題を制御する必要性をバイパスする仕様である。リバティアライアンスは、さらに2つのバージョンのアイデンティティフェデレーション仕様をリリースしており、そのフェデレーション仕様を、セキュリティアサーションマークアップ言語SAML2.0の基礎を形成する、OASIShttp://www.oasis.orgに提供した。リバティアライアンスは、アイデンティティベースのウェブサービスを扱う、リバティアイデンティティウェブサービスフレームワークID-WSFも発表した。この仕様は、安全でプライバシに配慮した連合ソーシャルネットワークにおいて、ジオロケーション、連絡帳、カレンダ、モバイルメッセージングなど、様々なアイデンティティベースのウェブサービスを配備し、管理するためのオープンフレームワークである。本明細書で開示される実施形態は、セキュリティを強化するために使用できる新機軸、およびリバティアライアンス標準の他の態様を、UEとの関連において開示する。例えば、一実施形態は、トラステッドチケットサーバまたはTTverifierの機能など、開示される機能のいくつかを単独または集団でUE上においてホストできる、UICC、スマートカード、または統合トラステッド環境TrEなどの安全な環境を、着脱可能モジュールまたは統合モジュールとして有する、モバイルデバイスを開示する。これらの開示される機能は、単独または集団で、既存のリバティアライアンスクライアントプロトコルだけをサポートできる通常のUEにおいて現在利用可能なセキュリティおよび信用証明をさらに強化することができる。3.3OASISおよびSAML構造化情報標準促進協会OASIS:OrganizationfortheAdvancementofStructuredInformationStandardsは、eビジネスおよびウェブサービス標準の開発、収束、および採用のためのグローバルオープンコンソーシアムである。IdMとの関連では、OASISは、現在のバージョンが2.0の、セキュリティアサーションマークアップ言語SAMLを開発した。SAMLは、セキュリティドメイン間で、すなわち、アイデンティティプロバイダアイデンティティについてのアサーションの生成者とサービスプロバイダ前記アサーションの消費者の間で、認証および認可データを交換するための、XMLベースの標準である。SAMLは、従来のイントラネットベースのSSOソリューションをウェブのオープン環境に拡張して、ウェブブラウザシングルサインオンウェブSSOの問題を解決しようと試みる。SAMLは、XMLおよびXHTMLベースのオープン標準化プロトコルを使用して、相互運用不能な独自仕様の技術の急増がもたらした結果を克服しようと試みる。SAMLは、リクエストおよびアサーションを提供するために、ユーザエージェントに依存する点で、OpenIDなどの他のIdM技術とは異なる。図2は、アイデンティティプロバイダとサービスプロバイダの間で認証およびデータを交換するためのSAMLプロトコルを示している。本明細書で開示される実施形態は、セキュリティを強化するために使用できる新機軸、およびSAMLの他の態様を、UEとの関連において開示する。例えば、一実施形態は、トラステッドチケットサーバまたはTTverifierの機能など、開示される機能のいくつかを単独または集団でUE上においてホストできる、UICC、スマートカード、または統合トラステッド環境TrEなどの安全な環境を、着脱可能モジュールまたは統合モジュールとして有する、モバイルデバイスを開示する。これらの開示される機能は、単独または集団で、既存のSAMLクライアントプロトコルだけをサポートできる通常のUEにおいて現在利用可能なセキュリティおよび信用証明をさらに強化することができる。3.4カンターライニシアティブカンターライニシアティブは、BT、NTT、T-Mobile、AOL、およびフィデリティインベストメンツなど、リバティアライアンスの当初の後援企業のいくつかによって主導される、リバティアライアンスの後継組織である。カンターラの公告は勧告であり、アイデンティティ保証と相互運用性という2つの主要な技術的トピックに重点を置いているので、カンターラは、標準定義組織SDO:standarddefiningorganizationではない。カンターラは、最初に、アイデンティティ保証フレームワークIAPv2.0の仕様を規定したが、IAPv2.0は、リバティアライアンスによって行われたIAPv1.0仕様策定作業を拡張したものである。当初のIAP仕様は、共通の標準化されたルール、およびアイデンティティ保証の各レベルに関連付けられたセキュリティリスク評価に基づいて、トラステッドアイデンティティ対応の企業、ソーシャルネットワーキング、およびウェブ2.0アプリケーションを互いに結び付ける助けとなる、多くのアイデンティティ保証レベルを詳細に規定する。そのため、フレームワークは、アイデンティティ主張および評価に対する柔軟で粒度の細かい信用保証を可能にした。規定された保証レベルは、文献によって概説された例えば、非特許文献4参照、低いから非常に高いまでの信頼水準にわたる4つのレベルの保証に基づいている。本明細書で開示される実施形態は、セキュリティを強化するための新機軸、およびIAPの他の態様を、UEとの関連において開示する。例えば、一実施形態は、トラステッドチケットサーバまたはTTverifierの機能など、開示される機能のいくつかを単独または集団でUE上においてホストできる、UICC、スマートカード、または統合トラステッド環境TrEなどの安全な環境を、着脱可能モジュールまたは統合モジュールとして有する、モバイルデバイスを開示する。これらの開示される機能は、単独または集団で、既存のカンターライIAPクライアントプロトコルだけをサポートできる通常のUEにおいて現在利用可能なセキュリティおよび信用証明をさらに強化することができる。3.5OpenIDOpenIDは、アクセス制御のために使用できる、ユーザを認証するためのオープン標準であり、ユーザが、異なるサービスに同じデジタルアイデンティティを用いてログオンすることを可能にし、その際、これらのサービスは、認証機関を信用する。OpenIDは、従来のユーザログオンプロセスに取って代わり、それによって、ユーザが、ログインを一度行えば、複数のソフトウェアシステムのリソースにアクセスできるようにする。OpenIDという用語は、この標準において使用されるIDを指すこともある。OpenIDは、米国に本拠を置く非営利団体であるOpenID財団によって開発、維持されている。OpenID財団OIDFは、OpenID技術の実現、普及、および保護に携わる個人および企業から成る。OpenIDプロトコルによって使用されるIDを指す用語としては、OpenIDは、一意的なURLの形式を取り、ユーザのOpenIDプロバイダすなわち、OpenIDURLをホストするエンティティによって認証される。OpenIDプロトコルは、ユーザのアイデンティティを認証するために中央当局に依存することはなく、認証自体については特定の方法にも依存しない。OpenIDプロトコルも、本人確認を必要とするウェブサイトも、特定のタイプの認証を命じないので、スマートカード、バイオメトリックス、または通常のパスワードなど、多様な認証を使用することができる。本明細書で開示される実施形態は、セキュリティを強化するための新機軸、およびOpenIDの他の態様を、UEとの関連において開示する。例えば、一実施形態は、UICC、スマートカード、または統合トラステッド環境TrEなどの安全な環境を、着脱可能モジュールまたは統合モジュールとして有する、モバイルデバイスを開示する。本明細書で使用される場合、OpenIDは、例示的なプロトコルであり、そのプロトコルにおいて、トラステッドチケットサーバTTS、TTverifier、およびTCTicketなどの新たに開示される機能は、UE内の前記安全な環境によってホストすることができ、単独または集団で、UEをより安全で信頼できるものにすることができ、UEがOpenIDプロトコルに従ってユーザ本人確認クライアント機能を実行しているときに、これらの開示される方法を使用することによって、そのような強化されたセキュリティおよび信頼性を外部的に検証可能にすることもできる。3.63GPPSA3およびOpenIDにおけるその働き3GPPのセキュリティ標準化作業部会である3GPPSA3では、2G、3G、およびより上の世代のモバイルフォン、端末、およびシステムについてのセキュリティの広範な局面において、総合的なアプローチが取られている。IdMの分野では、現在、OpenIDと汎用ブートストラッピングアーキテクチャGBA:GenericBootstrappingArchitectureとの統合に関する1つの技術報告書例えば、非特許文献5参照が存在する。リバティアライアンスとGBAのインタワーキングに関する別の技術報告書例えば、非特許文献6参照も存在する。本明細書では、実施形態は、セキュリティを強化するための新機軸、ならびにOpenIDおよび/またはOpenIDとGBAもしくは他の認証メカニズムとの統合の他の態様を、UEとの関連において開示する。例えば、一実施形態は、トラステッドチケットサーバまたはTTverifierの機能など、開示される機能のいくつかを単独または集団でUE上においてホストできる、UICC、スマートカード、または統合トラステッド環境TrEなどの安全な環境を、着脱可能モジュールまたは統合モジュールとして有する、モバイルデバイスを開示する。これらの開示される機能は、単独または集団で、3Gネットワーク上でのOpenIDまたはリバティアライアンスのインタワーキングのための、既存の3GPPが仕様を規定したプロトコルだけをサポートできる通常のUEにおいて現在利用可能なセキュリティおよび信用証明をさらに強化することができる。4技術的概要このセクションは、アイデンティティ管理IdMソリューションを提供できる実施形態の技術的概要を提供する。例えば、実施形態は、モバイルローカルプラットフォーム内に、特にスマートカード内に、OpenIDプロバイダOPサーバ機能を配置するために使用することができる。セクション4.1では、OpenID序論を提供する。セクション4.2では、スマートカード上のOpenID、ならびにアーキテクチャ、実施オプション、変形、および3GPPGBA汎用ブートストラッピングアーキテクチャの統合を提供する実施形態について説明する。セクション4.3では、OpenIDプロバイダOP実施プラットフォームオプションについて考察する実施形態について説明する。加えて、セクション4.3では、Java登録商標Card商標準拠のスマートカードを実施する実施形態、およびスマートカードウェブサーバSCWS上でOPを実施する実施形態について説明する。セクション4.4では、ローカルユーザ認証を扱う実施形態について説明する。ローカルユーザ認証は、OpenIDおよび他のSSO技術に関連するトピックである。加えて、セクション4.4では、バイオメトリックスを使用する実施形態について説明する。セクション4.5では、OpenIDとの関連で開発できる、信用Trustおよび信用関係Trustrelationshipの方法を提供する実施形態について説明する。例えば、MNOの役割を開示するいくつかの実施形態が説明され、MNOがOpenIDプロトコルにおいて他のエンティティ/アクタと有することができる信用関係が詳細に扱われる。例示的な一実施形態では、MNOは、メインのアイデンティティプロバイダIdPと全く同一であり、スマートカード上のOPは、IDPの役割を果たすMNOのプロキシである。第2の例示的な実施形態では、スマートカード上のOPは、MNOによって所有または管理されず、MNOは、IdPではなく、サードパーティIdPが、スマートカード上のOPを所有および管理する。セクション4.6では、スマートカード以外のプラットフォーム上でOPを実施することを可能にできる実施形態について説明する。例えば、実施形態は、Java登録商標Card商標および組み込みセキュアエレメント上での実施の実現可能性について開示する。加えて、実施形態は、モバイルOPに非常に高いレベルの信用およびセキュリティを与えるために、トラステッドコンピューティングにおけるようなプラットフォーム信用の考えを、モバイルOPの概念とどのように統合できるかについて説明する。4.1OpenID序論OpenIDは、ユーザが、単一のOPを使用して、異なる依拠当事者サイトにログインすることを可能にする。OPは、ユーザのアイデンティティの中心的な記憶場所であり、ユーザのための単一の認証ポイントとしての役割を果たす。ユーザが自らのOPに認証されると、このOPは、依拠当事者RPにアサーションを発行することができ、その結果として、RPは、サービスへのアクセスをユーザに許可する。便利なように、OPは、ユーザプロファイルと同等の個人情報を記憶することも許可される。その後、この情報は、ログインプロセスの後、ユーザについてのより詳細な情報をRPに提供するために、OPとRPの間で交換することができる。図3は、ユーザが単一のOPを使用して、異なる依拠当事者サイトにログインすることを可能にするためのOpenIDプロトコルフローを示している。図3に示されるように、ユーザが、OpenIDログインを試みると、その後、OpenIDログインが、RPによるOpenIDURIの発見を起動する。共有秘密が確立されるオプションのセキュリティアソシエーションを、RPとOPの間で生成することができる。発見プロセスが完了すると、ユーザは、RPによって、ユーザ認証が試みられるOPにリダイレクトされる。OPは、ユーザにログインウェブページを提供し、ログインウェブページにおいて、適切な資格証明書を入力すると、ユーザは認証される。認証が成功すると、その後、ユーザは、RPにリダイレクトされ戻し、ウェブのサービスへのログインが、ユーザに示される。4.2スマートカード上のOpenIDOpenIDプロトコルでは、OPは、ユーザ資格証明書および他のユーザ個人情報のためのリポジトリとすることができる。そのため、OPは、OpenIDプロトコルにおいて、ほとんどの攻撃の標的となるが、それは、OPから認証を受けるためのユーザ資格証明書を盗むことで、攻撃者は、ユーザの名前で、すべてのOpenID対応サイトにアクセスすることが可能になるからである。攻撃者が、ログインユーザのブラウザセッションを利用する、例えば、ユーザが自らのOPから認証を受けた後で、ユーザに代わって隠れたアクションを実行する、より穏当な攻撃シナリオでは、攻撃者は、ユーザ資格証明書を獲得せず、したがって、ユーザ資格証明書を使用して、任意のサイトにログインすることはできない。しかし、OpenIDプロトコルの設計は、以前のブラウザセッションにおいてユーザがログインしたすべてのRPサイトに、攻撃者がログインすることを可能にする。攻撃者は、必ずしも、例えばマルウェアまたはMITMによって、ユーザのマシンにアクセスする必要はなく、そのような攻撃は、ウェブサイト内の隠されたフレームを用いるXSRF攻撃を使用することによって、任意のサイトサイトはRPサイトである必要はないによって実行することができる。攻撃者がマルウェアを注入すること、またはMITMとして振る舞うことができる場合、ログインプロセス全体をキャプチャすることができ、その後、別のブラウザセッションにおいて必要な場合はいつでも、それを再現することができる。加えて、ユーザが、OPに資格証明書を再び提供することを必要とせずに、以後のログインを可能にすることをOPにおいて決定し例えば、OPがユーザのブラウザ内に永続的なクッキを記憶し、サイトが、OpenIDプロトコルの要求即時認証requestimmediateauthenticationオプションを使用する場合、攻撃者は、ユーザを無断でログインさせることができる。したがって、OPセキュリティは、OpenID実施に関する主要な懸案事項である。OpenID自体は、ユーザが、自ら所有するウェブサイト、例えばブログ上に、自らのOPをインストールすることを可能にする。しかし、ユーザがホストを所有することは非常にまれである。したがって、ユーザは、自分のホストのプロバイダが健全に振る舞い、自分のプライベートデータを適切な方法で保護するものと信用する。ユーザ固有の設計を用いてカスタマイズされたOPは、容易な自動化された方法ではもはや攻撃を実行できないので、フィッシング攻撃を阻止することができるが、OP実施の脆弱性、およびユーザのブラウザとOPのインタフェースの脆弱性を利用するすべての攻撃MITM、マルウェアなどが、依然として可能である。例示的な一実施形態では、OPなどのSSOプロバイダの機能を、ユーザが制御および/または所有できるUEに与えることができる。これを行うことで、例えば、ユーザのアイデンティティを管理すると同時に、OpenIDプロトコルによって提供される認証の利点であるシームレス性と容易性を提供する、集中環境を提供することができる。ユーザが、自分で管理する安全なデバイス上に自らのOPを有することができる場合、攻撃のいくつかは、一般的な方法で実行することがより困難になる。ユーザのためにOPを保存および実行するそのようなデバイスは、ユーザが自分のモバイルデバイス内に収めて持ち運ぶ、スマートカードなどのトラステッドコンピューティング環境とすることができる。UICCまたはJava登録商標カードなどのほとんどのスマートカードは、強化された機能を実行することができ、ユーザと対話することができる。ユーザに属するスマートカード上でOPを実行することで、ユーザが、自分のプライベートデータに対するより多くの管理を維持することを可能にすることができる。RPがそのサービスに対して料金を請求する場合など、いくつかのシナリオについては、スマートカードベースのOPの信頼性についての情報を、MNOからRPに伝えると有益なことがある。これは、RPがMNOを介してユーザに請求することを可能にする、バックチャネルを含むことができる。ユーザは、例えばPINコードによって、OPから認証を受けるために、ローカルチャネルを使用することができる。OPは、MNOによってリモートからインストールすることができ、OPのための必要な資格証明書は、GBAプロトコルを介して、スマートカードにもたらすことができる。図4は、トラステッドコンピューティング環境上の統合OPを用いるSSOプロトコルを提供するためのプロトコルフローの例示的な一実施形態を示している。プロトコルフローは、例えば、スマートカード上の統合OPを用いるOpenIDを提供するために使用することができる。図4に示されるように、201において、ユーザは、ウェブブラウザなどのユーザインタフェースエージェントを使用して、RPを訪れることができ、OpenIDを使用してログインすることを選択することができる。202において、RPは、スマートカード、UICC、またはJava登録商標カードなどの、トラステッドコンピューティング環境内に含むことができるローカルOPに、ユーザインタフェースエージェントをリダイレクトすることができる。203において、ユーザは、PINコードまたはバイオメトリックアイデンティティなどを用いて、トラステッドコンピューティング環境上のOPからローカルで認証を受けることができる。204において、トラステッドコンピューティング環境内のOPは、認証応答を生成することができる。205において、OPは、ユーザインタフェースエージェントをRPにリダイレクトすることができ、ユーザが認証された旨のアサーションを含めることができる。206において、ユーザインタフェースエージェントをRPにリダイレクトすることができ、ユーザは、RPがOPからのアサーションを検証した後、ログインすることができる。RPは、OPがMNOによって提供される場合には例えば、MNOによって提供されるウェブサービスエンティティへの公衆インターネット通信を使用して、接続を確立しなければならないことがある。これは、例えば、RPがトラステッドコンピューティング環境上のOPと直接的に通信できない場合に行うことができる。MNOは、トラステッドコンピューティング環境とのリモート管理インタフェースと、例えばSMSとしての、追加の通信チャネルとを有することができ、それらは、MNOが、デバイスおよび/またはトラステッドコンピューティング環境と通信することを可能にする。MNOは、RPとトラステッドコンピューティング環境上のOPの間の交渉の橋渡しとしての役割を果たすことができる。図5は、スマートカード上の統合OPを用いるOpenIDを提供するためのプロトコルフローの例示的な一実施形態を示している。図5に示されるように、207において、ユーザは、RPを訪れ、OpenIDを使用してログインすることを選択することができる。208において、サービスは、ユーザユーザのブラウザをユーザのローカルOPにリダイレクトすることができる。209において、ユーザは、例えば、スマートカードインタフェースを介するPINコードおよび/またはバイオメトリックアイデンティティを使用することによって、OPからローカルで認証を受けることができる。210において、OPは、認証応答を生成することができる。211において、OPは、ブラウザをRPにリダイレクトすることができ、ユーザが認証された旨のアサーションを含めることができる。212において、ブラウザをRPにリダイレクトすることができ、ユーザは、RPがOPからのアサーションを検証した後、ログインすることができる。RPは、OPがMNOによって提供される場合には例えば、MNOによって提供されるウェブサービスエンティティへの公衆インターネット通信を使用して、接続を確立しなければならないことがある。これは、例えば、RPがスマートカード上のOPと直接的に通信できない場合に行うことができる。MNOは、スマートカードとのリモート管理インタフェースと、例えばSMSとしての、追加の通信チャネルとを有することができ、それらは、MNOが、デバイスおよび/またはスマートカードと通信することを可能にする。MNOは、RPとスマートカード上のOPの間の交渉の橋渡しとしての役割を果たすことができる。4.2.1アーキテクチャおよびプリファレンス4.2.1.1RPOP通信要件例示的な一実施形態では、スマートカードなどのトラステッドコンピューティング環境上で動作するOPからRPがアサーションを取得するために、RPは、OPと通信しなければならない。RPは、ユーザ識別子をOPにトランスポートすることができ、その後、認証の後で、OPは、認証の結果をRPに通知することができる。OpenIDプロトコルは、プロトコル中に2つの異なるタイプの通信を使用する。間接通信は、HTTPリダイレクトまたはHTML形式のサブミッションを介して実行される。通信がユーザのブラウザを通過するという意味で、通信は間接的である。間接通信は、RPからブラウザを介してOPに至る認証要求およびOPからブラウザを介してRPに至る認証応答のために使用される。直接通信は、RPとOPの間で直接的に実行され、アソシエーションを確立するため、およびOPを用いて直接的にアサーションを検証するために使用される。RPとOPの間でのアソシエーションのしたがって共有秘密の確立は、命令されてはいないので、OpenID認証について、2つのプロトコルフローが存在する。本明細書で説明される実施形態は、OpenID認証のためのどちらかのプロトコルフローを使用して実施することができる。4.2.1.1.1アソシエーションベース通信についての予備知識図6は、アソシエーションベース通信のためのOpenIDプロトコルフローを示している。図6に示されるように、OpenIDプロトコルにおけるOPとRPの間のアソシエーションは、OPとRPの間の事前共有秘密に依存しない。アソシエーションは、ユーザが自らのOpenID識別子をRPに提供し、OpenIDを使用してRPにログインすることを望んだ後に、RPによって実行される最初のステップである。215において、RPは、HTTPSを介してOPに接続し、OPとの短期の認証毎セッションの共有秘密kを確立するために、ディフィ-ヘルマン鍵交換を実行する。この共有秘密は、後で230において、元々はOPから来たものであるが、RPは間接通信を介してユーザのブラウザから受信するブラウザリダイレクト、アサーションメッセージ上のシグネチャを検証するために、RPによって使用される。アソシエーションがしたがって共有秘密kが、RPとOPの間で確立された場合、220において、アソシエーションハンドルが、間接通信を介する認証要求および認証応答に収めて渡される。225において、OPからの認証応答は、アソシエーションハンドルと、共有秘密kを使用したアサーション上のシグネチャとを含む。その後、RPは、kを使用して、シグネチャを自律的に検証することができる。アソシエーションハンドルの使用は、OPとRPの両方が、複数の同時セッションを追跡することを可能にする。4.2.1.1.2ステートレスなシグネチャ検証についての予備知識図7は、ステートレスなシグネチャ検証のためのOpenIDプロトコルフローを示している。図7に示されるように、RPとOPの間でアソシエーションが確立されない場合、240において、OPへのダイレクトメッセージとして、RPは、235に対する応答である受信した認証応答内のシグネチャを検証しなければならない。その後、245において、OPは、RPへのステートメントを発行しなければならず、ステートメントは、アサーションが有効なアサーションであり、実際にOPによって発行された場合にyesに設定される、is_validフィールドを含む。認証要求および認証応答は、HTTPリダイレクトによってユーザのブラウザを通過し、したがって、どのシナリオにおいても、RPとOPの間のいかなる直接通信チャネルも必要としないが、受信したアサーション上のシグネチャをRPが検証する方法が存在しなければならない。オリジナルのプロトコルが標準準拠であり続けなければならない場合、RPは、シグネチャ検証のために、アサーションを受信した後、少なくとも一度はOPとコンタクトを取ることができなければならない。その場合、アソシエーションの確立は必要ではない。4.2.1.2認証のためのローカルデバイス上のOPの発見についての実施形態OpenIDプロトコルを使用する場合、RPは、間接通信を実行するとき、必ずしもOPを発見する必要はない。例示的な一実施形態では、RPにアクセスするために使用されるブラウザは、スマートカード上のローカルOPを指し示すリダイレクトを取得する。ブラウザとRPの間のチャネルが使用されるので、RPは、OPのアドレスを知る必要すらないことがある。しかし、リダイレクトは、ブラウザをあるアドレスに向ける必要があることがある。このアドレスは、後でローカル認証に係わるブラウザによって認識される、ローカルホストを参照する、127.0.0.1に類似したデバイスローカルIPアドレスとして与えることができる。別の実施形態では、ローカルOPにリダイレクトして、ユーザ認証を続行する目的で、ブラウザによって変換される、特別な識別子を使用することができる。そのような識別子は、例えば、sc://openid/identifierという形式を取ることができ、これは、その識別子に対するスマートカード上のOPを用いる認証セッションに係わるようにブラウザに命じる。認証要求は、スマートカードなどのトラステッドコンピューティング環境にとって正しい通信フォーマットに変換することができる。その後、認証は、UICC機能に応じた適切なインタフェースを介して、ユーザとUICCの間で行うことができる。例えば、認証は、PINコードまたはバイオメトリック照合などを使用して行うことができる。この認証は、ユーザが認証に同意を与えたことを別途示すことができる。これを行うことで、例えば、スマートカードが攻撃者または無権限ユーザによって使用された場合に、ユーザが知らないうちに認証を受けることを可能にし得る攻撃を防ぐことができる。認証をユーザ対話と結合することで、ユーザは、起きているトランザクションを知ることができる。スマートカード機能に応じて、実際のトランザクション詳細を、すなわち、どのサイトがRPとしての役割を果たしているか、RPにおける戻り先URL、およびどのアイデンティティを使用すべきかを示すことが望ましいことがある。スマートカード上のOPが、複数のOpenIDアイデンティティをサポートする場合、OPは、このRPとともに使用するアイデンティティを選択してユーザに提示することさえできる。例えばPINコードを使用してOPからローカル認証を受けた後、OPからの肯定的アサーションを含めて、ブラウザは、RPにリダイレクトされる。例示的な一実施形態では、アサーションは、RPによって検証することができ、したがって、アソシエーションまたは先のセクションで説明されたような直接シグネチャ検証を介する、RPとOPの間の直接通信が必要とされる。アサーション検証のための方法は、実施に固有であり、以下のセクション4.2.2.1においてさらに説明される。4.2.1.3MNOアサートアイデンティティについての実施形態例示的な一実施形態では、スマートカードなどのトラステッドコンピューティング環境上のローカルOPが、ローカルユーザ認証のために使用される。MNOは、ユーザが正常に認証されたことを述べるトリガリングメッセージをスマートカード上のローカルOPから受信した後、必要なアサーションをRPに提供するエンティティとすることができる。この実施形態は、セクション4.2.2.1.2において分割OPシナリオとしてさらに説明される。4.2.2実施形態の実施オプションおよび変形本セクションは、本明細書で開示されるより一般的な概念と組み合わせることができる、実施形態の実施オプションおよび変形について説明することを意図している。4.2.2.1アサーション検証のためのRP-OP通信についての実施形態4.2.2.1.1BONDIの統合についての実施形態例示的な一実施形態では、RPとOPの間の直接通信チャネルを、少なくともアサーションシグネチャの検証のために使用することができる。そのような直接チャネルは、例えば、OPとRPの間のユーザのブラウザを介してトラフィックをトンネルさせることによって提供することができる。この概念は、ブラウザが、現在のセッション内で追加のリダイレクトを実行することを必要とすることがある。別の実施形態では、ブラウザは、RPとOPの間の通信チャネルを確立するために使用できる第2のプロセスについての、RPのための単一のコンタクトポイントとしての役割を果たすことができる。RPとOPの間の指定された通信プロトコルは、HTTPまたはHTTPSであるので、ブラウザは、すべてのトラフィックをトランスポートすることが可能とすることができる。スマートカードなどのトラステッドコンピューティング環境とのブラウザ通信を円滑化するため、OMTPBONDIAPIを使用することができる。BONDIAPIは、ブラウザが、スマートカードと、したがってOPと通信するために、JavaScript登録商標を使用することを可能にすることができる。BONDIを使用することによって、リダイレクトを減らすことさえできる。RPは、RPがブラウザに送信するウェブページ内に、適切なJavaScript登録商標コールを含める。このJavaScript登録商標コールは、BONDIAPIを起動し、スマートカードへのアクセスを可能にすることができる。その後、コールの結果は、RPへの応答メッセージ内に例えばHTTPPOSTメッセージ内に、同じJavaScript登録商標によってラップすることができる。RPがBONDIコールをいつ使用するかに応じて、RPは、RPが認証要求リダイレクトページ内のスマートカードコールを使用するときに、アソシエーションを確立することができ、またはRPは、RPがOPアサーションを受信した後で示されるページを使用することができ、これは、RPが、アソシエーションなしに直接検証を実行することを可能にする。図8は、BONDIとアソシエーションベースのOpenIDとの統合についての例示的な一実施形態を示している。図8に示されるように、245において、BONDIを使用して、OPとRPの間で、アソシエーションが確立される。BONDIは、ブラウザが、スマートカードなどのトラステッドコンピューティング環境、および/またはトラステッドコンピューティング環境内に存在できるOPと通信することを可能にすることができる。250において、認証要求が、OPにおいてRPから受信される。255において、認証応答が、RPに伝達され戻す。図9は、BONDIとステートレスなアソシエーションなしのシグネチャ検証との統合についての例示的な一実施形態を示している。図9に示されるように、260において、OPとRPは、BONDIおよびブラウザを介して通信する。265において、RPが、認証要求をOPに送信する。270において、OPが、認証応答をRPに送信する。4.2.2.1.2分割OPについての実施形態例示的な一実施形態では、RPは、分割OPを使用して、受信したアサーションを検証することができる。分割OPでは、OP機能をMNOとローカルOPの間で分割することができる。ローカルOPは、ユーザ認証を担うことができ、一方、MNOは、RPと通信して、スマートカードOPからのシグネチャを検証することができる。これは、RPとMNOの間でセットアップされるアソシエーションを用いて、またはステートレスなシグネチャ検証を介して行うことができる。図10は、分割OPを可能にするための例示的な一実施形態を示している。図10に示されるように、275において、RPとMNOの間でアソシエーションをセットアップすることができる。RPは、MNOとともに共有秘密を確立することができ、その後、共有秘密は、アサーションメッセージの署名プロセスにおいて、OPによって使用することができる。アサーションメッセージは、RPが異なるユーザと複数の同時接続を有する場合に、RPが正しい共有秘密を識別するための、アソシエーションハンドルを含まなければならないこともある。共有秘密は、RPが、OPと通信することを必要とせずに、アサーションシグネチャを検証することを可能にすることができる。このアソシエーションは、UEのブラウザのRPからの最初のリダイレクトが実行される前に、実行することができる。280において、OPは、認証要求をRPに送信することができる。285において、RPは、認証応答をOPに送信することができる。290において、OPは、MNOとともにアソシエーションハンドルおよび署名鍵を確立することができる。アソシエーションハンドルおよび署名鍵は、GBAを使用して確立することができる。RPとMNOの間でアソシエーションが確立されない場合、RPは、MNOにおけるエンティティとコンタクトを取ることによって、受信したシグネチャを検証できる必要が依然としてあることがある。このエンティティは、シグネチャの有効性についてのステートメントを発行するように求められることがある。例示的な一実施形態では、OPが、MNOによって発行されたOPに本当に属するかどうかをチェックすることはオプションである。そのようなチェックは、後でMNOに転送される、RPへの認証アサーションメッセージ内に、一意的な識別子を含めるようにOPに要求することがある。そのような識別子としてOPアドレスIMEI/IMSIを使用することが可能なことさえある。OPが、有効なOPとしてMNOに登録されている場合、MNOは、is_validフィールドがyesに設定されたメッセージをRPに返送し、その結果、RPは、アサーションメッセージアサーション検証を承認する。分割OPシナリオは、MNOが、すべての認証に要する負担をスマートカード上のローカルOPにオフロードする方法で、OpenIDプロセスに対する制御を保持することを可能にすることができる一方で、MNOは、noに設定されたis_validを用いて応答することによって、アイデンティティを無効にするためオプションを依然として有する。シグネチャ検証は、ユーザがRPにログインする前に、プロトコルの最後のステップとして実行するができる。図11は、分割OPを可能にするためのステートレスなアソシエーションなしの実施形態の一例を示している。295において、MNOとRPの間で、アサーション検証を行うことができる。300において、RPは、認証要求をOPに送信することができる。305において、OPは、認証応答をRPに送信することができる。310において、OPとMNOの間で、アソシエーションハンドルおよび署名鍵を確立することができる。アソシエーションハンドルおよび署名鍵は、GBAを使用して確立することができる。別の例示的な実施形態では、MNOがスマートカード上のOPと通信するため、MNOは、ベアラとして暗号化SMSを使用する、標準OTA管理手順が使用できるかどうかを探ることもできる。SMS内に含まれるコマンドは、SIMカードによって暗号解除し、文献において定義されているように例えば、非特許文献7参照実行することができる。別の例示的な実施形態では、ベアラ独立プロトコルBIP:BearerIndependentProtocolを、カードアプリケーションツールキットトランスポートプロトコルCAT_TP:CardApplicationToolkitTransportProtocolとともに使用することができる。BIPは、エンドツーエンドのデータチャネルをもたらす、ハンドセットからOTAサーバおよびUSIMカードへのデータチャネルを開くことを可能にする。1つのSMSが140バイトのサイズを有するSMSと比較して、BIPのためのデータパッケージは、1472バイトを含む。BIPは、より高速の接続のために、UEGPRS接続を使用することができる。BIPは、文献において標準化されており例えば、非特許文献8参照、CATTPは、文献において標準化されている例えば、非特許文献9参照。4.2.2.2スマートカード上のOPのための3GPPGBAの使用についての実施形態例示的な一実施形態では、本出願全体で説明されるUICC/HeNBベースのOPを組み込むために、GBAを使用することができる。例えば、GBAプロトコルは、多くのMNOによって使用および確立することができる。4.2.2.2.1GBA序論3GPPGBAプロトコル仕様例えば、非特許文献1参照は、ホームロケーションレジスタHLRまたはホーム加入者サーバHSS上のユーザの有効なアイデンティティを使用して、ユーザ認証を可能にするための技術である。GBA認証は、ネットワークコンポーネントに、UE内のSIMカードを誰何させ、返答がHLR/HSSによって予測される返答と同様であることを検証させることによって行われる。GBAは、共有鍵認証方法の代表である。ブートストラッピングサーバ機能BSF:BootstrappingServerFunctionでは、MNOネットワークエンティティは、2つのエンドポイントの間の仲介者としての役割を果たし、それらが存続期間中だけに限定できる共有秘密を確立することを可能にする。以下の図は、参考として含まれ、GBAアーキテクチャおよびその要素の概要を与える。図12は、GBAアーキテクチャにおいて使用するBSF機能を示している。図13は、GBAアーキテクチャ概要を示している。図14は、文献から引用した例えば、非特許文献1参照GBA参照モジュールを示している。図15は、文献から引用した例えば、非特許文献1参照訪問先ネットワークNAFのためのGBA参照モジュールを示している。4.2.2.2.2GBAとSSOの統合における従来技術GBAは、3GPP認証および鍵合意プロセスを利用して、アプリケーション固有の資格証明書を生成するために、SSOとの関連において使用することができる。そのような使用の一例が、文献において与えられており例えば、非特許文献6参照、その文献は、GBAとリバティアライアンスSSOプロトコルの間のインタワーキングシナリオについて説明している。別の例も、文献にあり例えば、非特許文献5参照、その文献は、GBAとOpenIDプロトコルの間のインタワーキングシナリオについて説明している。3GPPTRは、GBA鍵を使用して、アイデンティティプロバイダとしての共存NAF/OPとUE/ユーザのUICCとの間でユーザ認証を実行する。本セクションの残りでは、例を挙げて、GBAとOpenIDの間のインタワーキングについて重点的に説明する。UEは、Ubインタフェースを介して、これらのアプリケーションレイヤ資格証明書を生成するために、MNOHSSのBSFを使用する。その後、これらは、Znインタフェースを介して、OP/NAFと共有される。その後、UEクライアントは、これらの資格証明書を使用して、サービスプロバイダと直接的に通信することができる。図16は、MacDonald他によって書かれた文献に示されるような例えば、非特許文献10参照、リバティ/GBAのためのアーキテクチャ図式を示している。図16に示されるように、GBAは、リバティIdPを実施するショッピングモールを提供するために、リバティアライアンスプロトコルと統合することができる。リバティIdPを通して、ショッピングモールは、ユーザがショッピングサービスにおいて使用できるアイデンティティをユーザに提供する。IdPは、認証メカニズムとしてGBAプロトコルを使用する。図16は、以下のステップを示している。315。ひとたび登録されると、UEのユーザエージェントは、Ubを介して、BSFとともにGBAUを実行する。320。UICC内のユーザエージェントアプレットにUbパラメータが提供される。325。ユーザエージェントのUICCコンポーネントが、Ksを計算し、UEにサービスレイヤ資格証明書Ksint/extNAFを提供する。Ksは、常にUICC内に残っている。330。ユーザエージェントが、ショッピングモールアイデンティティを獲得するために、NAF/IdPとコンタクトを取る。335。ユーザエージェントに適したサービス資格証明書が、Znを介してNAF/IdPに伝達される。340。ショッピングモールのための認証トークンが、NAF/IdPからユーザエージェントに提供される。345。UEが、サービス資格証明書を使用してSPと通信し、サービスを要求する。350。SPが、UEのサービス資格証明書の有効性を確認する。4.2.2.2.3GBAおよびOpenIDの使用についての実施形態例示的な一実施形態では、UICCとNAFの間で共有秘密を確立するために、GBAを使用することができる。NAFは、他のサービス例えばIdPと共存することができ、MNOネットワーク内に存在する必要がないことがある。NAFは、MNOのネットワーク内のBSFへの接続を必要とすることがある。UE内のUICCとNAFの間の接続は、例えば、HTTPまたはHTTPS上のSOAPを介することができる。以下でさらに説明される他の実施形態では、OPとMNOの間の通信のために使用できるUICCベースのOPは、GBAプロトコルを使用することができる。4.2.2.2.3.1OPのための直接信用プロバイダとしてのMNO例示的な一実施形態では、MNOを使用して、RPとOPの間で信用を確立できるという意味で、MNOは、RP-OP通信に直接的に関与することができる。以下の実施形態は、セクション4.5.2.2.1において先に説明された実施形態と統合することができる。RPとMNOの間の直接接続についての実施形態図17は、MNO支援のアイデンティティアサーションのためのGBAの使用についての例示的な一実施形態を示している。図17に示されるように、370において、RPは、アソシエーションを確立するために、MNOのネットワークエンティティに接続することができる。このMNOエンティティは、UICCベースのOPのためのアサーションサポートとしての役割を果たすことができ、このエンティティは、OPsupと呼ばれることがある。OPsupは、統合NAF機能を有することができ、MNOネットワークの内部のしかし到達可能なエンティティ、または外部のしかしMNOによって操作もしくは保証されるエンティティとして実現することができる。365において、OPsupとUICC上のOPは、GAA/GBAを使用して共有秘密を確立するために、必要なブートストラッピングプロセスを実行することができる。355において、ユーザのブラウザは、RPからローカルOPにリダイレクトすることができる。360において、ブラウザとOPの間で通信を行うことができる。ユーザは、ローカルUICCOPから認証を受けることができる。例えばPINコードを使用する360におけるローカル認証の後、365において、OPは、Ks_NAFから導出される、RP固有の、また任意選択的にセッション固有の鍵Ks_NAF_RPを用いて署名された、セッション識別子または初期リダイレクトにおいてRPによって渡された追加のノンスを含むメッセージを、OPsupに送信することができる。370において、OPsupとRPの間の安全な接続がすでに確立されている場合、確立されたチャネルは、ソースの真正性とメッセージに対する完全性保護をすでに提供しているので、OPsupは、このメッセージをRPに転送することができる。しかし、OPsupは、公開鍵を用いてメッセージに署名することができ、したがって、通信チャネルから独立して、完全性保護および真正性を提供することができる。RPは、OPシグネチャを検証するために、Ks_NAFから導出される、RP固有の、また任意選択的にセッション固有の鍵Ks_NAF_RPを備えることができる。その場合、Ks_NAF_RPは、OPsupを介してRPに渡すことができる。別の実施形態では、シグネチャ生成および検証のために、KS_NAFを直接的に使用することができる。OPを介する間接通信についての実施形態例示的な一実施形態では、ノンスをRPからOPに伝達するために、間接通信を使用することができ、その後、OPは、ノンスをMNOに転送する。MNOは、アサーション内に含めることができるノンスに署名し、アサーションは、ローカル認証が成功した後、OPからRPに渡される。MNOがノンスに署名するので、OPがMNO発行のUICC上で動作していることについての保証が、RPに提供される。組み合わされた方法についての実施形態例示的な一実施形態では、直接通信例えばHTTPS接続を介してRPとMNOの間で確立される共有秘密を使用することができる。その場合、RPは、OPが、認証の完了時に、この秘密をアサーションメッセージに含めることを予期することができる。別の例示的な実施形態では、GBAを使用することができる。GBAプロトコルは、NAFとUICCの間で恣意的な共有秘密例えばRPの秘密を確立することを許容しないので、ここ例えば共存OPsupエンティティでは、インダイレクションindirectionを使用することができる。RPは、セッション識別子をOPsupに送信し、OPsupは、GBAを使用して、UICCとともに共有秘密を確立することができる。その後、OPsupは、UICCしたがってUICC上のOPとともに確立したのと同じ秘密を使用して、セッション識別子に署名し、署名されたセッション識別子をRPに返送することができる。RPは、この署名されたセッション識別子を参照として保持することができる。RPは、セッション識別子をリダイレクトメッセージに含め、それによって、OPが、GBA秘密を使用して、セッション識別子に署名することを可能にすることができる。その後、OPは、署名されたセッション識別子をRPへのアサーションメッセージに含めることができる。その後、RPは、OPからの署名されたメッセージとOPsupからの署名されたメッセージを比較することができる。それらがマッチした場合、RPは、OPがOPsupのMNOの加入者に属することの証拠を得る。この実施形態は、メッセージ保護を強化し、OpenID認証を確立する、シグネチャマッチングを用いるクローズドループプロセスを表すことができる。4.2.2.2.3.2OP機能がMNOとスマートカード上のOPの間で分割された場合分割OPのGBAの使用についての実施形態図18は、分割OPを可能にするための例示的な一実施形態を示している。図18に示されるように、375において、RPとMNOの間でアソシエーションをセットアップすることができる。RPは、MNOとともに共有秘密を確立することができ、その後、共有秘密は、アサーションメッセージの署名プロセスにおいて、OPによって使用することができる。アサーションメッセージは、RPが異なるユーザと複数の同時接続を有する場合に、RPが正しい共有秘密を識別するための、アソシエーションハンドルを含まなければならないこともある。共有秘密は、RPが、OPと通信することを必要とせずに、アサーションシグネチャを検証することを可能にすることができる。このアソシエーションは、UEのブラウザのRPからの最初のリダイレクトが実行される前に、実行することができる。380において、OPは、認証要求をRPに送信することができる。385において、RPは、認証応答をOPに送信することができる。390において、OPは、MNOとともにアソシエーションハンドルおよび署名鍵を確立することができる。アソシエーションハンドルおよび署名鍵は、GBAを使用して確立することができる。例示的な実施形態では、OP機能は、MNOとローカルOPの間で分割することができる。RPとMNOの間のアソシエーションが使用される場合、RPは、MNOとともに共有秘密を確立することができ、その後、共有秘密は、アサーションメッセージの署名プロセスにおいて、OPによって使用することができる。アサーションメッセージは、RPが異なるユーザと複数の同時接続を有する場合に、RPが正しい共有秘密を識別するための、アソシエーションハンドルを含むこともある。共有秘密は、RPが、OPと通信することを必要とせずに、アサーションシグネチャを検証することを可能にすることができる。GBAが行われると仮定すると、MNOとRPの間の共有鍵は、Ks_NAFによって保護して、OPに渡すことができる。したがって、OPは、アソシエーションを介して確立された共有鍵を使用して、アサーションメッセージに署名することができる。RPは、MNOとともにアソシエーションを確立することができ、その後、MNOは、MNOとOPの間の共有秘密を生成するGBA手順を実行する。MNOは、RPから到達可能なサーバにおいて、NAF機能を実施することができる。NAFは、UICC上のOPとともに共有秘密を確立することができ、RPは、共有秘密をNAFから受信する。NAFとRPに知られているアソシエーションハンドルも、MNOコンタクトポイントNAFからOPに送信することができる。その後、OPは、GBA共有秘密を使用して、アソシエーションハンドルを含む、RPに送信されるアサーションに署名することができる。RPは、NAFからアソシエーションリンクを介して同じ共有秘密を受信することができるので、OPシグネチャを検証することができる。アソシエーションハンドルの使用は、OPおよびRPが、複数の同時セッションを扱うことを可能にする。4.2.2.2.3.3分割端末の場合のモバイルOpenIDにおけるGBAの使用例示的な一実施形態では、GBAは、ブラウザとOP/UICCの組み合わせとが別個のデバイス内に存在する、分割端末構成において使用することができる。分割端末タイプ構成は、OPがユーザにとってローカルエンティティであり、先に説明したように、ユーザがOPを用いてローカルに認証を実行する場合に、まさに利用されると仮定することができる。図19は、分割端末/ローカルOpenIdを可能にするための例示的な実施形態を示している。図19に示されるように、2つのデバイス間のチャネルの保護は、例えばbluetoothセキュアリンクを使用して、または場合によっては、共有秘密鍵Ks_local_deviceが確立される、文献で説明されている手順例えば、非特許文献11参照を介するなどして、達成することができる。鍵は、UICCにおいて内部的に計算することができ、セキュアトンネルを介してブラウザに渡すことができる。共有秘密の確立は、GBAによってサポートすることができる。共有秘密鍵は、GBA生成鍵Ks_ext/int_NAFから導出することができる。例示的な一実施形態では、33.259を利用する場合、証明書ベースの相互認証を用い、HTTPSを使用して、NAFとリモートデバイスを接続するセキュアトンネルを確立することができる。例えば、ブラウザは、PCベースであり、インターネット/TCP接続の環境において動作するトンネルを用いることができる。トンネルのセキュリティは、信用メカニズムによって強化することができる。モバイルフォン仕様MPWGの要件の通り、ブラウザを含むリモートデバイスは、TCG準拠であると仮定することができる。HTTPSトンネル確立は、デバイスにおけるTPMの証明を通して、ブラウザデバイスの信用ステータスに結び付けることができる。したがって、このプロトコルに組み込まれた完全性チェックは、Ks_local_deviceをプラットフォームに結び付ける。別の例示的な実施形態では、手順の一環として、UICCホスティングデバイスは、ユーザのブラウザをホストするリモートデバイスによって、それにNAF_IDのリストを送信するように要求されることがある。MiTMは、そのような要求を容易に行い、要求されたIDを受信することができる。トンネルを保護する証明書および相互認証の態様は、適所において仮定される信用機能と一緒になって、分割端末構成内ではMiTM攻撃は行われていないこと、またはそのような攻撃が行われていても、それは検出されることを保証する。ひとたびこのセットアップが完了すると、トンネルを介して、Ks_local_device鍵をリモートデバイスに安全に送信することができ、その後、リモートデバイスブラウザは、デバイスをホストするUICC上でKs_local_deviceの計算を開始するために、完全性保護された鍵生成要求メッセージを送信することができる。分割端末タイプ構成のためのアイデンティティアサーションプロトコルが、本明細書で説明される。リモートプラットフォームブラウザ-PCとUICC/OPを含むデバイスUEとの間の共有秘密鍵Ks_local_deviceを確立する手順とともに、GBAがすでに行われていると仮定することができる。図19に示されるように、UEとNAF/OPsupを接続する405によって識別されるチャネルと、UEとPCを接続する400によって識別されるチャネルは、安全とすることができる。別の例示的な実施形態では、MNOは、UICCベースのOPのアイデンティティアサーションがここで適用されるのをサポートするのに役立つことがある。別の例示的な実施形態では、●ユーザは、OpenIDログインフォームを使用して、自分のOP識別子URLをRPに提供する395。●ユーザは、RPによって自分のOPにリダイレクトされ、リダイレクトメッセージは、ノンスまたはセッション識別子を含む。●RPとMNOは、セキュリティアソシエーション例えばHTTPS接続を確立する410。●RPも、セッション識別子をOPsupに送信し、このメッセージは、上述のセキュリティアソシエーションによって保護される410。●ユーザは、ブラウザを介して入力されるPINまたはパスワードを使用して認証を受ける。●この情報は、RPから獲得したセッション識別子も含むメッセージに収めて、400を介してPCからUICC/OPに伝達され、上で説明したように、このメッセージは、Ks_local_deviceを用いて保護される。●OPsupは、GBA鍵Ks_ext/int_NAFを使用して、セッション識別子に署名し、それをRPに返信し、RPは、このシグネチャを参照として保持する410。●OPは、やはりGBA鍵Ks_ext/int_NAFを使用して、今度はブラウザからOPに送信されたセッション識別子に署名し、このシグネチャをアサーションメッセージに含め、その後、アサーションメッセージは、RPに送信される395。●RPは、OPsupからの1つ410と、OPからのもう1つ395の、2つのシグネチャを比較し、それらがマッチした場合、RPは、OPがOPsupのMNOの加入者に属すると結論づける。4.3スマートカードウェブサーバ上のOPのための効率的なプロトコルについての実施形態本セクションは、本出願においてさらに説明される、効率的な改良を提供する実施形態に特に関して、SCWS上のOPによって提供される利益を明瞭化することを意図している。OpenIDプロトコルを実施する実施形態など、提案される実施形態の利益の1つは、認証トラフィックがローカルであり、エアインタフェースネットワークまたはネットワークサービスに、既存のHTTPメッセージフローのために必要とされるもの以外の負担をかけないことである。発見およびアソシエーショントラフィックは、エアインタフェースネットワークを介することはなく、通信事業者OPとRPの間の有線公衆インターネットを介して行われる。4.3.1標準的なOpenID図20は、標準的なOpenIDプロトコルを示している。このプロトコルの場合、ローカルトラフィックは存在せず、エアネットワークからオフロードされるトラフィックは、発見プロセスと、RPとOPの間のアソシエーション確立だけである。OPはウェブサービスであるので、ユーザ/ブラウザ/デバイスとOPの間のすべての通信は、エアインタフェースを介する。例えば、信号420、435、440、445、450、455、460、465は、無線通信上に発生し、無線通信は、一般にはデータトラフィック例えば、HTTP、IPベースの通信として、MNO/エアネットワーク上で実施される。これは、MNOネットワーク上に負荷をかけることを表す。加えて、信号425、430は、有線インターネット上で発生するトラフィックであり、既存のインフラストラクチャを使用することができる。4.3.2OpenID/GBA図21は、文献から引用した例えば、非特許文献2参照OpenID/GBAのためのトラフィックフローを示している。このプロトコル定義の場合、RPとMNOの間のアソシエーションステップにも係わらず、すべての通信は、エアネットワーク上で行われる。しかし、ウェブベースのOPと比較して、OpenID/GBAでは、認証のために472および474が必要とされ、それらは、エアデータネットワークばかりでなく、GBA認証のために必要とされるバックエンドサービス、すなわちBSFおよびNAFサブシステムにも負担をかけるので、トラフィックはさらに増加する。そのため、ここでは、エアネットワークトラフィックの増加と、ネットワークエンティティにおける負荷の増加を見る。4.3.3プロトコル改良についての実施形態図22は、無線トラフィックを減少させるためのプロトコルフローの例示的な一実施形態を示している。例えば、SCWS上のOpenIDのための効率的なプロトコルを使用することができる。この実施形態では、SCWSに関連付けられたOPとMNOの間に長期共有鍵が存在すると仮定することができる。図22に示されるように、無線トラフィックは、エアインタフェースネットワークトラフィックに減少するように、ローカルデバイスにオフロードすることができる。これを行うことで、例えば、認証トラフィックがローカルになることを可能にすることができ、その結果、認証トラフィックは、エアインタフェースネットワークまたはネットワークサービスにかかる負担を最小化する。加えて、発見および/またはアソシエーショントラフィックは、エアインタフェースネットワークを介して発生しなくてもよく、有線公衆インターネット上で行うことができる。480において、ユーザは、ブラウザなどのユーザインタフェースと対話することができ、RPを訪れることができ、OpenIDを使用してログインを要求することができる。485において、RPとOPMNOは、OpenIDアイデンティティに基づいて、OPサーバの発見を実行することができる。490において、RPは、アソシエーション要求をOPに送信することができる。OPは、ランダムで一意的なアソシエーションハンドルAを生成することができ、鍵Sを計算することができる。OPは、アソシエーション応答をRPに送信することができる。アソシエーション応答は、アソシエーションハンドルAと、鍵Sとを含むことができる。RPは、鍵SとアソシエーションハンドルAを保存することができる。495において、RPは、リダイレクトをブラウザに送信することができる。リダイレクトは、ブラウザをOPにリダイレクトすることができ、要求パラメータにアソシエーションハンドルAを含めることができる。OPは、SCWSに関連付けることができる。ブラウザは、リダイレクトを受信することができ、SCWSにマッピングするように変更されたローカルDNSルックアップを実行することができる。500において、ブラウザは、認証のためのローカル要求をOPに送信することができる。505において、認証をローカルに行うことができる。例えば、510において、OPは、長期共有秘密鍵KとアソシエーションハンドルAに基づいて、資格証明書を検証することができる。加えて、OPは、鍵Sを計算することができ、鍵Sを使用して、シグネチャを計算することができる。シグネチャは、アサーションメッセージに署名するために、ならびに/または戻り先URL、アイデンティティ、および/もしくはモードなどのパラメータに署名するために使用することができる。515において、OPは、ブラウザをRPにリダイレクトできるリダイレクトを、ブラウザに送信することができる。リダイレクトは、アソシエーションハンドルAと、署名されたパラメータとを含むことができる。520において、ブラウザは、OPからの署名されたアサーションメッセージを含むことができる要求を、RPに送信することができる。RPは、鍵Sを使用して、アサーションメッセージ上のシグネチャを検証することができる。その後、525において、RPは、ブラウザが、ログインページを表示することを可能にすることができ、サービスへのアクセスをブラウザに提供することができる。4.4スマートカードウェブサーバ上でのOP実施についての実施形態ユーザ機器UEがSIMカードと通信するために利用可能な標準化された方法が存在し、例えば、文献は、SIMアプリケーションによって使用できる、SIMアプリケーションツールキットSATインタフェースを定義しているが例えば、非特許文献12参照、どのようにすれば、異なるSIMベンダからの様々なSIMカードタイプにわたって統一された方法で、コマンドを利用できるかは定義していない。例示的な一実施形態では、SIMアプリケーションツールキットを使用して、SIMカードは、UEに対する一時的な制御プロアクティブproactiveを取得することができる。UEがSIMカードに要求を送信し、SIMが応答する場合と比較して、UEは、SIMからSATコマンドをフェッチすることができる。SIMカードは、UEに向けてSATコマンドを発行し、UEはしかるべく反応して、コマンドが正常に実行されてもされなくても、SIMに応答を返信する。4.4.1スマートカードウェブサーバ上のOPスマートカードウェブサーバSCWSは、USIMカード上で動作し、従来のウェブサーバのように振る舞う、ウェブサーバである。SCWSは、SIMツールキットの進歩と見なされ、現在のアプリケーションシナリオでは、ローカルUEブラウザを使用するHTMLインタフェースを介して、電話帳、追加のMNOサービスなどを表示するために使用される。SCWSは、標準的なHTTPプロトコルを使用して、そのコンテンツをブラウザに配信するが、従来のウェブサーバとは異なり、SCWSは、2つの異なるベアラを、すなわち、T=0のスマートカードプロトコルの上のBIP、またはUSBインタフェースの上のカード上で実施される完全なTCP/IPスタックを使用することができる。UEは、SCWSUSIMへのトラフィックおよびSCWSUSIMからのトラフィックのルーティングを担い、USIMをMNOおよびインターネットに接続するゲートウェイとしての役割を果たす。BIPインタフェースが使用される場合、ME内のルータが、ある種のHTTP要求をUEブラウザからローカルSCWSにリダイレクトする。決められたTCPポート上のHTTP要求は、USIM上のSCWSに送信され、応答内のHTMLページは、SCWSによって生成される。BIP専用のTCPポートを使用しないHTTP要求は、インターネット上のサーバに送られる。USBプロトコルが、USIM上の完全なTCP/IPスタックと組み合わせて使用される場合、UEは、イントラネットをインターネットに接続する他のコンピュータと同じIPゲートウェイ機能を有する。MEゲートウェイは、使用されるIPプロトコルバージョンにも、すなわち、IPv4か、それともIPv6かにも依存する。BIPと比較して、完全なTCP/IPスタックは、要求をUSIMからインターネットに回送する可能性も提供する。図23は、SCWS上のOPのための内部ルーティングについての例示的な一実施形態を示している。図23に示されるように、SCWSは、OPのための基盤として使用することができ、UEルーティング機能は、与えられた外部ポートに反応し、通信をSCWS上のOPに転送するように、変更することができる。これは、例えば、ブラウザを通るトンネルを用いずに、直接通信を生成するために行うことができる。トラフィックは、依然として同じデバイスを通過するが、異なる方法でリダイレクトすることができる。UEにおけるルーティング機能RFは、複数の通信経路を可能にすることができる。ユーザがブラウザを使用して最初にRPサイトを訪れたとき、RFは、利用可能なアウトバウンドTCP/IPインタフェース例えば3Gネットワーク接続を介して、要求をRPにリダイレクトすることができる。RPとブラウザは、この接続を介して共通のセッションを確立したので、今では、RPは、ブラウザのIPアドレスを知っている。RPは、ユーザ/ブラウザセッションにおけるのと同じアドレスを使用して、OPとコンタクトを取ることができる。RPは、ブラウザとのHTTPセッションにおけるものとは異なる、デバイス上の別の事前定義されたポートを使用することができる。RFは、このポートを、SCWS上のOPに回送すべきポートとして認識する。RFは、メッセージを直接的にOPにリダイレクトすることができ、それによって、RPが、OPとのアソシエーションを確立することを可能にすることができる。RPは、OpenID認証を実行するために、ブラウザにリダイレクトを発行することもできる。ブラウザは、SCWS上のOPにリダイレクトすることができる。RFは、ブラウザからのコールを、ローカルSCWSに回送できるコールとして認識することができる。OPは、ローカルユーザ認証を実行することができるローカルユーザ認証は、安全なUIを介することができ、一般にはPINコードを提供するようにユーザに要求することによって、デバイスを制御するUICC機能の一部として、SCWSによって提供することができる。認証の後、OPは、肯定的なアサーションとともに、ブラウザをRPにリダイレクトすることができる。RPとOPはアソシエーションを確立していることがあるので、RPは、アサーションを自律的に検証することができる。アソシエーションを生成することができない場合は、OpenIDの直接検証シナリオを実施することが可能なこともある。この場合、RPは、肯定的なアサーションを受信した後、事前定義されたポート上でUEとコンタクトを取ることができ、RFは、要求をOPに回送し、OPは、検証要求に回答することができる。例示的な一実施形態では、ローカルデバイスにおいて、OPへのアクセスを制限することができる。例えば、ローカルブラウザだけに、アイデンティティについてのアサーションを獲得することを許可することができる。こうすることで、攻撃者が、他のデバイスforeigndeviceからアイデンティティアサーションを取り出すことを防ぐことができる。RFは、OPへのインバウンドトラフィックのルーティングを、先行するブラウザ要求に結合することもできる。例えば、ルーティングは、ブラウザが通信する単一のRPに対して、限られた期間だけ、アクティブになることができる。RFは、それぞれSCWSおよびOPに対する管理タスクを実行するために、MNOによって使用することもできる。4.4.1.1.1一般的な要件以下は、OpenID仕様によって説明されている一般的な要件である。R-1OpenIDでは、RPは、ステートレス通信モードで動作するか、それともアソシエーションベース通信モードで動作するかを決定することができる。RPについてどんな仮定も行うことはできないので、両方のオプションがOP実施によってサポートされなければならない。R-2ステートレスモードでは、OPとRPの間で共有秘密は確立されず、OPは、RPがブラウザを介してOPからアサーションメッセージを受信した後、RPによって直接的にコンタクトされる。その後、RPは、OPへの直接HTTPS接続を確立し、アサーションメッセージ上のシグネチャを検証するようにOPに要求する。OpenID仕様は、160ビット鍵長のHMAC-SHA1と、256ビット鍵長のHMAC-SHA256の、2つの異なるタイプの対称シグネチャ方式を許容している。対称鍵は、アソシエーションがRPによって使用される場合、アソシエーション確立の際に、OPとRPの間で交換することができる。秘密の交換は、ディフィ-ヘルマン鍵交換を使用し、その後、DH-key-valueを用いて共有秘密を暗号化して保護され、またはディフィ-ヘルマンが使用されない場合、接続は、トランスポートレイヤセキュリティによって盗聴者から保護されなければならない。アサーションメッセージ上のOPによって発行されたすべてのシグネチャは、言及されたアルゴリズムの1つを使用する対称シグネチャである。例えばグローバルプラットフォームなどの、スマートカードの用語では、この暗号シグネチャ方式を言い表すのに、クリプトグラムcryptogramまたはより一般にデータ認証パターンDAP:DataAuthenticationPatternという用語を使用する。R-3アソシエーションベースのOpenIDでは、RPとOPは、アソシエーションハンドルによって識別される、共有秘密を確立する。RPは、ブラウザをOPにリダイレクトする最初のリダイレクトメッセージに、このアソシエーションハンドルを含める。その後、OPは、アソシエーションハンドルを使用して、このRPのための共有秘密を見つけることができ、その後、この秘密を使用して、アサーションメッセージに署名することができる。このメッセージを受信すると、RPは、受信したシグネチャを自律的に検証することができる。R-4R-1、R-2、R-3で説明された通信オプションはどちらも、RPから、公衆インターネットを介して到達できるエンティティE1への少なくとも1つの直接通信を必要とし、エンティティE1は、通常のOpenIDの場合は、OPサーバである。R-5R-4のエンティティE1は、アソシエーションベースモードでは、OPサーバとRPの間で共有秘密を確立できなければならない。ステートレスモードでは、この秘密は、メッセージに署名をするために、OPが知っていなければならず、またOPシグネチャを検証するために、RPによって後でコンタクトされる、この到達可能なエンティティE1が知っていなければならない。R-6OpenIDにおけるシグネチャは、通常はHMAC-SHA1ベースであり、OPおよび検証当事者は、データに署名し、適切なアルゴリズムを使用してシグネチャを検証できなければならない。R-7MNOは、OP発見を提供する、ネットワークエンティティE2を提供しなければならず、OP発見は、OpenID標準によれば、HTMLまたはXRDS発見によることができる。エンティティE2は、OpenID識別子の一部である、DNSアドレスにおいて動作しなければならず、例えば、識別子がhttp://openid.mno.com/idである場合、MNOは、http://openid.mno.comにおいてウェブサービスE2を実行しなければならず、すなわち、MNOは、発見サービスとして動作するために、ドメインおよびサーバを所有しなければならない。発見サービスは、公衆インターネットを介し、軽量とすることができる。エンティティE2は、R-4のエンティティE1と、両方の機能を提供する共通の物理エンティティ内に共存することができる。E2は、E1から分離することができ、その場合、発見プロセスは、OpenIDを使用してデバイスを渡り歩くためのオプションのためのエントリポイントを提供する。R-8R-7のE2のDNSアドレスは、ユーザに一貫した識別子を提供するために、変更すべきではない。R-9OPは、少なくともHTTPを介して、ユーザのブラウザによって到達可能でなければならない。R-10R-9におけるのと同じ接続は、HTTPの代わりに、HTTPSを使用することができる。R-11任意選択:OPは、認証ページとして使用されるHTMLページを作成し、表示できなければならない。実際の認証は規定されていないので、これは任意選択である。認証ページが使用されない場合、アイデンティティの隠れた使用を防ぐために、OPは、ユーザに、ユーザのOpenID識別子が使用されることを少なくとも通知すべきである。しかし、認証ページを表示しないことで、ユーザにより一貫性のあるSSO感を提供するのに役立つことがあり、例えば、ユーザは、1日につき1回だけ、SCWS上のOPから認証を受け、その後、すべての後続の認証は自律的に行われる。R-12任意選択:認証ページが使用され、認証ページが、例えば、ユーザ名およびパスワードなどのデータをユーザから受け取った場合、OPは、このデータを受け入れ、それを処理および検証し、しかるべく振る舞うことができなければならない。R-13任意選択:認証ページが使用される場合、認証ページは、RPによって受信された情報を使用して、例えば、RPの名前および使用される識別子を、テキストもしくはグラフィックアイコンまたは両方の組み合わせで表示するなど、理解しやすい方法で、ユーザに追加情報を表示することができる。R-14任意選択:認証ページが使用される場合、認証ページは、ユーザが合法的OPと通信していることを示す、ユーザ向けのインジケータとして使用される、視覚的秘密を含むことができる。4.4.1.1.2OpenIDにおいてSCWSを使用する実施についての実施形態先のセクションでは、OpenID標準によって定められた一般的な要件について説明した。本セクションでは、上で説明されたOpenID要件内で、SCWSを使用してローカルOPを実施するための実施形態について説明する。例示的な一実施形態では、SCWSは、公衆インターネットから直接的に到達可能でないことがあり、すなわち、RPは、SCWS上のOPと直接的にコンタクトを取ることができない。要件R-1、R-2、R-3を考えると、インダイレクションを使用することができる。例えば、MNOは、公衆インターネットを介して到達可能であり、SCWSに関連付けられたOPと秘密を共有することができる、ウェブサービスを提供することができる本文書の分割OPについてのセクションを参照。このウェブサービスは、この秘密をRPとも共有することができ、したがって、RPとSCWSに関連付けられたOPとの間の共有秘密を確立することができる。別の実施形態では、RFは、SCWS上のOPに要求を回送することができる。SCWSへの通信は、SCWSおよび関連アプレットのリモート更新など、リモート管理インタフェースを経由した、HTTPSを介する、MNOからのものと、ローカルHTTPSを介する、ハンドセットのブラウザからのものとすることができる。OpenID通信のために、ローカル接続インタフェースを使用することができる。加えて、ローカル接続は、SCWSおよびOPと通信するために使用できる、一般的なHTTPSインタフェースとしての機能を果たすこともできる。ETSISCPは、ローカルアクセスだけに制限しなくてよい、TCP/IP9を介するスマートカードへのアクセスを定義した。例えば、外部エンティティからSCWSへの制限されたアクセスは、技術的問題とはなり得ないが、代わりに、SCWSの現在の標準的な仕様によれば、デバイス内部のルーティング機能における制限となり得る。SCWSへの直接HTTPアクセスは、SCWSの将来のリリースにおいて実施されるであろう。そのようなアクセスは、管理アクセスとして意図されなくてよい。例えば、OpenID動作の場合、RPは、SCWSによってサービスされるウェブページOPサーバロジックを実施する動的アプレットにアクセスしなければならないことがある。4.4.1.2SCWSに関連付けられたOPを実施するための追加要件および導出要件を扱うための実施形態以下の実施形態は、OPがUICC上で実施され、SCWSに関連付けられる場合に、追加要件を生じさせることがある。RSCWS-1例示的な一実施形態では、MNOは、SCWSに関連付けられたローカルOPおよび任意選択的にRPとともに、OpenIDプロトコルのための秘密を生成し、共有し、分配することができる、サポートOPサーバ機能OPSFを実施しなければならない。サポートOP機能は、OpenIDアサーション上のシグネチャにおいて使用される共有秘密のための、RPとUE上のローカルOPエンティティとの間のネゴシエーショントラステッドパーティnegotiatingtrustedpartyとしての役割を果たさなければならないことがある。このサポート機能は、アソシエーションが使用される場合はアソシエーションプロセスを開始するために、またはRPから要求があったときはローカルOPからのシグネチャを確認するために、RPにHTTPSインタフェースを提供することができる。したがって、サポート機能は、公衆インターネットを介して到達可能とすることができ、加えて、この機能は、秘密を交換するために、ローカルOPと通信できなければならない。ローカルOPとのこの通信は、少なくとも、ユーザが訪れることを望むRP毎に1回、発生しなければならないことがある。例示的な一実施形態では、ローカルOPは、MNOによって管理および維持される。MNOは、共有秘密を更新するために、ローカルOP/SCWSと通信することができ、OMASCWS標準で十分とすることができる。非MNOのリモートOpenIDアイデンティティプロバイダサービスが、スマートカード上のローカルOPを管理し、それと通信する、別の例示的な実施形態では、グローバルプラットフォーム標準を使用することができる。通常、OPとRPの間で、RP毎に新しい対称秘密を確立することができる。ユーザがOpenIDログインを使用して訪れるRPを制限することは困難であるので、ユーザが将来訪れることを望むすべてのRPに、これらの共有秘密を事前提供することは非常に困難である。UICCにおいて、各RPのために例えば、シード値から秘密を導出することによって秘密が都度生成される場合、この秘密は、RPと共有することができるが、それについては、このオプションについて説明する、後のセクションにおけるプロトコルフローを参照されたい。RSCWS-2別の例示的な実施形態では、RSCWS-1のMNO運用のネットワークエンティティは、異なるチャネルおよび通信方法を使用して、SCWSに関連付けられたOPにおいて秘密を確立し、それらをRPに分配することができる。MNOからRPへの通信は、OpenIDプロトコルによって、HTTPベースの通信に限定される。MNOからSCWSに関連付けられたOPへの通信は、保護されたSMS-PPを使用することができ、または例えばGBAによってブートストラップすること、および/もしくはHTTPSSCWSリモート管理インタフェースなど、安全な通信プロトコルを使用することができる。RSCWS-3別の例示的な実施形態では、SCWSに関連付けられたローカルOPは、RSCWS-1のMNOエンティティとスマートカードの間で共有される秘密にアクセスしなければならない。これらの秘密は、ネットワーク固有の鍵ではないが、OpenIDプロトコルのためにだけ使用され、必要な場合には取り消して、OTA手法を介して再確立することができる。秘密は、対称鍵であり、RPから送信されたHTTPパラメータに署名するために、OPによって使用される。OPがローカルOPを所有する場合、OPは、GPおよび/またはOMAによる確認に従ってローカルOPに対する鍵を確立できるので、MNOがこれらの秘密を分配する必要がないことがある。しかし、MNOは、SCWSのリモート管理のために秘密を必要とすることがあり、そのため、MNOが、そのルートを介して、ローカルOPのための鍵を確立することも可能である。RSCWS-4別の例示的な実施形態では、RSCWS-3の秘密の保護は、ハンドセット上の他のアプリケーションから秘密を読み取ることができないような、また秘密がスマートカード環境内のそのアプリケーション空間の外部にさらされないように、秘密に基づいて動作するすべてのアルゴリズムが、スマートカードによって提供される安全な環境内で動作するようなものであるべきである。ローカルOPがグローバルプラットフォームアプリケーションである場合、鍵は、ローカルOPのセキュリティドメインによって保存することができ、ローカルOPのセキュリティドメインは、ローカルOPのための暗号操作を実行する。RSCWS-5別の例示的な実施形態では、SCWSに関連付けられたローカルOPは、OPによる将来の使用のために、秘密とアソシエーションハンドルを保存することができ、その結果、RPを再び訪れる場合、MNOからOPへの追加のOTAトラフィックを削減することができる。RSCWS-6別の例示的な実施形態では、SCWSに関連付けられたローカルOPは、合法的なローカルOPだけによって示すことができる、スマートカード内に安全に保存された秘密イメージなどの、追加のセキュリティ特徴を、ユーザに示される認証ページにおいて使用することができる。RSCWS-7別の例示的な実施形態では、SCWSに関連付けられたOPは、特にRPから来たパラメータに署名するために、HTTP要求の処理およびHTMLページの表示にとどまらない、いくつかのアプリケーションロジックを実施しなければならない。RSCWS-8別の例示的な実施形態では、SCWSに関連付けられたOPによって秘密が生成される、実施オプションが使用される場合、RSCWS-7のアプリケーションロジックは、対称秘密を生成でき、それらを安全にMNOネットワーク内のエンティティに伝達できなければならない。RSCWS-9別の例示的な実施形態では、RSCWS-7およびRSCWS-8のアプリケーションロジックは、java登録商標アプレットまたはサーブレットで実施することができ、java登録商標アプレットまたはサーブレットは、SCWSによって動的にコールされて、必要な動作を実行し、その後、制御をSCWSに戻す。アプレット/サーブレットは、UICC内の安全な環境において動作すべきである。RSCWS-10別の例示的な実施形態では、SCWSは、RPにわたってユーザのOpenIDアイデンティティ使用を追跡することによって生成できるユーザプロファイルに基づいて、例えば広告バナーなどの、MNOから取り出された情報を表示した、認証のための動的なウェブページを提供することができる。MNOは、SCWS上で、マーケティング/広告目的のウェブスペースをRPに提供することができる。これは、SCWS上のOPに別の価値をもたらす。RSCWS-11別の例示的な実施形態では、具体的なシナリオにおいて、SCWSでは制限が強すぎることが分かった場合、別のオプションは、SCWSの機能を模倣するJava登録商標Cardアプリケーションに基づいて、アプリケーションロジックを実施することである。アプリケーションは、着信HTTP要求を受け入れ、ユーザに認証インタフェースを提供し例えばPIN入力、シグネチャを計算し、HTTP応答を生成し、ブラウザに応答を返す。このシナリオにおいて、BONDIフレームワークが、ブラウザとSCWSに取って代わったスマートカードアプリケーションとの間の間接通信部分で役立ち得るかどうかを探ることができる。4.4.1.3命名規約エンティティに対して、以下の命名規約が適用される。●SCWSに関連付けられたOP:署名されたアサーションメッセージを発行し、それらをユーザのブラウザを介してRPに送信する、ローカルOpenIDアイデンティティプロバイダ。SCWSを、したがってOPをホストするスマートカードは、MNOと、したがってすべてのMNO関連のエンティティと関係を有すると仮定される。●RP:ユーザにOpenIDを使用したログインを提供する任意のウェブサイトとすることができる依拠当事者。RPは、他のすべてのエンティティから完全に独立であり、したがって、RPに追加の要件を課すことはできず、RPについてのOpenIDプロトコルフローに対する変更は生じることができない。OPは、RPが使用することを選んだ通信モードはステートレスまたはアソシエーションベースのどちらであれサポートしなければならない。MNOが、ユーザはあるRPを使用すべきではないと決定した場合、ユーザは依然として別のアイデンティティを使用できるので、MNOは、これらのRPに対するOpenIDアクセスを拒否することによって、これらのサイトへのアクセスを拒否することはできない。MNOは、一般に帯域幅消費サイトへのアクセスをブロックする追加の手段を使用して、RPへのアクセスを制限できるにすぎない。●OP-Agg:OP-Aggは、R-7のエンティティE2を実施し、RPに発見サービスを提供する。●OPSF:OPサーバ機能OPSFは、RSCWS-1のSCWSに関連付けられたOPおよび任意選択的にRPとともに、OpenIDプロトコルのための秘密を生成し、共有し、分配することができる、サポートOP機能を実施する。OPSFとSCWSに関連付けられたOPとは、RPの観点からは、それらが単一のエンティティであるかのように振る舞っている。OPSFは、SCWSに関連付けられたOPによって発行されたシグネチャを検証することができ、公衆インターネットを介してRPから直接的に到達可能である。デバイス上のブラウザは、OPSFのアドレスがSCWSに関連付けられたローカルOPにマッピングされるように、デバイス上のローカルDNS解決キャッシュを変更することによって、SCWSに関連付けられたOPにリダイレクトされる。●ブラウザ:SCWSに関連付けられたOPへの、およびSCWSに関連付けられたOPからのルーティングおよびメッセージング機能を明示的にするために、プロトコルフロー図内に示される。それ以外では、ブラウザは、ユーザ認証を表示し、受信するためのフロントエンドにすぎない。4.4.1.4SCWS/UICC上のOPを実施するための実施形態本セクションは、標準的なOpenID認証プロトコルに準拠したままであることを試みながら、上で説明した一般的な概念から導かれる実施形態を探求する。ステートレスモードのプロトコルとアソシエーションベースモードのプロトコルの2つの実施形態が以下で説明され、第2の実施形態は、認証プロセスを統合するために、OPカード機能とネットワークサイドのサーバ機能との間の共有鍵を含む暗号を前提とし、それを利用する。4.4.1.4.1プロトコルフロー説明以下のセクションでは、SCWSに関連付けられたOPを実施するためのプロトコルフローの例示的な実施形態について説明する。例示的な一実施形態では、上のR-1で述べたように、ステートレスとアソシエーションベースの両方のシナリオをカバーすることができる。プロトコルフロー図と、実施形態の呼フローの説明が、以下で提供される。一般的なOpenIDプロトコルが、図3に関連して説明される。複数のオプションが、図24~図27に示され、対応する記述において説明される。4.4.1.4.2ステートレスモードを使用するRPのためのプロトコルフロー図24は、RPがステートレスモードを使用して、OpenID認証を実行することを可能にするためのプロトコルフローの例示的な一実施形態を示している。例えば、RPは、ステートレスモードを使用して、OpenIDユーザ認証を実行することができる。図24に示されるように、530:ユーザは、RPウェブサイトを訪れ、自らのOpenID識別子を入力することができる。例えば、http://op.org/identity。535:ブラウザは、OpenID識別子を含むHTTPメッセージを、RPウェブサイトに送信することができる。540:RPは、HTTP/HTMLベースのOpenIDシンプル発見を使用することができ、公衆インターネットを介してOP-Aggとコンタクトを取り、OpenID識別子のためのアイデンティティページを取り出す。例えば、HTTPGEThttp://op.org/identity。545:OP-aggは、要求を受信し、例えば、<linkrel=openid.serverhref=http://op.org/server.cgi>を含めることによって、OPSFのインターネットアドレスを含むHTMLページによって応答することができる。OPSFは、RPに対して標準的なOpenIDアイデンティティプロバイダウェブサービスのように振る舞うことができ、すなわち、OPSFは、RPからの要求時に、アサーションメッセージ上のローカルOPによって発行されたシグネチャを検証することができる。OPSFは、公衆インターネットを介して到達可能とすることができ、http://op.orgによって到達可能な、op.orgなどの、DNS名を有すると仮定することができる。外部世界は、スマートカードのIPアドレスを知ることができないので、このインダイレクションOP-aggおよびOPSFが、通信のために使用される。OPSFのアドレスは、OP-aggのアドレスと異なることがある。a.オプション1:この項目は、必須ではなく、オプションを提示する。このオプションがここで使用されない場合、570におけるオプション2が、プロトコルの後のフェーズには存在することができる。i.OP-aggは、RP識別子とOpenIDユーザ識別子をOPSFに送信することによって、RPからの要求をOPSFに通知する。ii.OPSFは、ローカルデータベースにおいて、このRPおよびOpenIDアイデンティティのための秘密を検索しようと試みることができる。iii.秘密が見つからない場合、OPSFは、新しい秘密とアソシエーションハンドルを生成し、両方をSCWSに関連付けられたOPに送信し、次に、SCWSに関連付けられたOPが、それらを保存する。iv.秘密が見つかった場合、OPSFは、シグネチャ検証のために、それを後で使用する。秘密がOPSFによってローカルデータベース内で見つけられた場合、SCWSに関連付けられたOPは、このRPとの先のプロトコル実行において、この秘密とアソシエーションハンドルをすでに受信し、したがって、それを保存できており、それを再利用すると仮定される。シグネチャを検証するためにOPSFによって使用される秘密は、シグネチャを生成するためにSCWSに関連付けられたOPによって使用される秘密と同じとすることができる。シグネチャの新しさは、次のステップで挿入されるRPノンスによって保証することができ、RPノンスは、シグネチャの一部であることが要求される。OpenID仕様は、署名秘密自体の新しさについては何も言わないままである。秘密の暗号強度を保証すること、秘密の秘密性を維持すること、およびそれが必要な場合は、秘密の新しさを保証することは、OPの責任である。OPSFまたはSCWSに関連付けられたOPは、この目的のために、署名秘密に対して、限られた存続期間または使用カウントを実施することができる。秘密共有のためのさらなるオプションについては、セクション4.4.1.4.3.1において説明する。550:RPは、OPSFのアドレスを受信し、例えば、nonce=123123、session=Userなどと、ノンスおよびセッション識別子を生成することができる。RPは、ユーザ認証後にブラウザをどのURLにリダイレクトすべきかをOPに命じる、戻り先パラメータを編集することができる。RPは、以下のパラメータを含むことができる、ブラウザをOPサーバアドレスにリダイレクトする、HTTPリダイレクトを発行することができる。openid.mode=checked_setup、openid.identity=http://op.org/identity、openid.return_to=http://rp.org/return.cgisession=Usernonce=123123555:ブラウザは、リダイレクトを受信することができ、リダイレクトメッセージ内のRPによって指定されたURLへの接続をオープンする。560:例えば、エントリhttp://op.org==127.0.0.1を有するホストファイルを使用することによって、OPSFのURLをSCWSローカルIPアドレスにマッピングすることができる、変更されたローカルDNSルックアップテーブルを用いる場合、ブラウザは、SCWSに関連付けられたローカルOPにリダイレクトすることができ、550のパラメータを含むHTTP要求を発行する。変更されたローカルDNSルックアップテーブルは、デバイス上で使用することができ、URLhttp://op.orgがSCWSのローカルIPアドレスにあるとデバイスに思わせる。したがって、ブラウザは、公衆インターネットを介して到達可能な、URLhttp://op.orgにあるOPSFに接続する代わりに、SCWS/ローカルOPへの接続をオープンすることができる。565:以下は、認証トラフィックをローカルに保つことを保証するために実行することができるが、これらのステップは、必須ではなく、OpenIDプロトコル仕様によって規定されていない。a.SCWSに関連付けられたOPは、ローカル認証ページを表示することができる。b.ユーザは、例えば、ユーザ名およびパスワードなど、自らの認証用資格証明書を入力することができる。c.SCWSに関連付けられたOPは、資格証明書を検証することができる。570:545のオプション1が使用された場合、SCWSに関連付けられたOPは、OPSFから新たに取り出された、または秘密およびアソシエーションハンドルのローカル記憶から取り出された、SCWSに関連付けられたOPとOPSFとの間で共有される、秘密およびアソシエーションハンドルを有することができる。a.オプション2、545においてオプション1が使用されなかった場合、i.SCWSに関連付けられたOPは、新しい秘密およびアソシエーションハンドルを生成することができる。ii.SCWSに関連付けられたOPは、この秘密およびアソシエーションハンドルを、SCWSを介してOPSFに送信することができる。iii.OPSFは、この秘密を受信し、それを将来のアクセスのために安全に保存することができる。目標は、例えば、OPSFとローカルOPの間で秘密を共有することとすることができ、したがって、ローカルOPが秘密を生成した場合、生成後に秘密をOPSFに伝達することができる。ツールキット対応のローカルOPは、SCWSをバイパスして、ハンドセットとプロアクティブにproactively通信するために、CATを使用することができる。メッセージは、例えば、SMS-PPベアラを介してOPSFに送信するために標準的なOTA通りにフォーマットすることができる。しかし、これは、OPSFが、MNOのOTAシステムを介して、カードと通信することを必要とすることがある。あるいは、BIPゲートウェイが、ツールキットメッセージのペイロードを抽出することができ、ハンドセットが、TCP/IPを使用して、それをOPSFに送信することができる。しかし、これもやはり、メッセージがMNOのOTAサーバを通過することを必要とすることがある。カードがIPアドレスを有せず、TCP/IPをサポートしない場合、BIPを使用することができる。575:SCWSに関連付けられたOPは、戻り先、アイデンティティ、およびモードなどのパラメータに対するシグネチャを計算する。580:SCWSに関連付けられたOPは、ステップ550においてRPから受信したパラメータを含み、追加的に、以下のものも、すなわち、openid.signedパラメータ内の署名されたパラメータのリスト、openid.assoc_handleパラメータ内のアソシエーションハンドル、およびopenid.sigパラメータ内のシグネチャbase64符号化も含む、HTTPリダイレクトメッセージをブラウザに送信する。このメッセージは、ブラウザをRPの戻り先URLにリダイレクトするために使用される。585:ブラウザが、ユーザをRPの戻り先URLにリダイレクトする。590:RPは、署名されたアサーションメッセージを受信し、HTTPSベースの公衆インターネットを介する直接通信によって、OPSFとともに検証手順に携わる。595:RPは、580のSCWSに関連付けられたOPから受信したパラメータを含む、HTTPPOSTメッセージを発行する。600:OPSFは、共有鍵を使用して、受信したデータ上のシグネチャを検証する。605:OPSFは、シグネチャ検証が成功した場合、is_valid:trueを返す。610:RPからは、ユーザは、今ではhttp://op.org/identityとして識別されている。615:ブラウザは、RPのHTMLページを表示する。620:ユーザは、http://op.org/identityとして、RPにおいてログインする。4.4.1.4.3ステートレスモードについての追加の実施形態4.4.1.4.3.1秘密を共有するOpenIDのステートレスモードは、RPが署名されたステートメントをOPから受信するが、RPは署名のために使用された秘密を知らないので、自らこのシグネチャを検証することができないというプロセスによって特徴付けられる。ステートレスモードでは、RPは、このシグネチャを検証するために、再びOPとコンタクトを取る。SCWSに関連付けられたシグネチャ発行OPとシグネチャ検査OPOPSFは、RPの観点からは同じエンティティに見えるので、それらは、秘密を共有できなければならない。これには、いくつかのオプションが適用される。4.4.1.4.3.1.1オプション1:OPSFが秘密を管理する本セクションでは、図24の454に関して上で説明されたオプション1を利用する、実施形態のいくつかについて概説する。OP-aggは、発見実行が行われると直ちに、OPSFに通知することができる。その後、OPSFは、秘密およびアソシエーションハンドルを生成することができ、両方をSCWSに関連付けられたOPに送信する。OPSFがMNOの一部である場合、SCWSリモート管理プロセスを使用することができる。OPSFがMNOの一部でない場合、グローバルプラットフォーム方法は、ハンドセットがカード上のローカルOPをサポートすることを前提として、OPSFが、カード上のローカルOPに鍵を送信することを可能にする。オプション1では、OPSFにおいて中央秘密/アソシエーションハンドルデータベースを実施することを可能にすることができ、OPSFは、OpenID識別子、RPから、アソシエーションハンドルおよび秘密へのマッピングを、データベース内に保存する。OPSFは、通知されると直ちに、識別子およびRPについて検索を実行することができ、秘密が見つからない場合、OPSFは、新しい秘密およびアソシエーションハンドルを生成し、それをSCWS上のOPに送信することができる。この例示的な実施形態は、SCWS上のOPが、RPのための秘密およびアソシエーションハンドルを保存できること、ならびにSCWS上のOPが、OPSFがシグネチャ検証のために後で使用するのと同じ秘密を、署名のために使用することを仮定する。その場合、この手順は、RP毎に1回実行される。4.4.1.4.3.1.2オプション2:SCWS上のPOが新しい秘密を生成する本セクションでは、図24に関して上で説明されたオプション2を利用する、実施形態のいくつかについて概説する。SCWSに関連付けられたOPは、RPからパラメータを受信すると直ちに、新しいアソシエーションハンドルおよび秘密を生成することができる。SCWSに関連付けられたOPは、秘密を使用して、パラメータに署名することができ、その後、この秘密およびアソシエーションハンドルをOPSFに送信する。SCWS上のOPがこの秘密を保存できる場合も、OPSFは、将来使用するために、この秘密およびアソシエーションハンドルを保存すると決定することができる。その場合、この手順は、RP毎に1回だけ実行すればよい。これは、新しい秘密がOPSFによってのみ暗号解除できるように、ローカルOPが新しい秘密を暗号化することを可能にできる、永続的な秘密がすでに存在することを仮定している。この暗号化は、ローカルOPが、トランスポートレイヤセキュリティを必要とせずに、新しい秘密をOPSFに送信することを可能にする。4.4.1.4.3.1.3オプション3:共通のシードから導出される秘密例示的な一実施形態では、SCWSに関連付けられたOPとOPSFが、異なるRPとともに使用される秘密とは独立に前もって確立できる、共通のシードを共有する場合、別の変形を使用することができる。SCWS上のOPとOPSFが、共通のシード値Sを共有すると仮定する。Sと、SCWS上のOPとOPSFが通信中に受信する、現在のOpenID実行を一意的に識別する1つの情報Pとに、暗号関数を適用することによって、SCWS上のOPとOPSFは、同じ秘密を所有するようになることができる。共有秘密は、例えば、k=SHA1S|Pのように共有秘密を計算することなど、SとPの連結に対してハッシュ関数を適用することによって、計算することができる。SCWSに関連付けられたOPとOPSFの両方が受信する情報Pに注目すると、RPIPアドレスとOpenID識別子、RPから受信したパラメータセット全体、パラメータのサブセット、またはこれらの任意の組み合わせなど、異なる候補を考えることができる。そのような導出される秘密は、鍵導出関数におけるように、共通のパターンに従って事前生成することもでき、その場合、秘密およびアソシエーションハンドルは、事前生成されており、必要なときに使用することができる。4.4.1.4.3.1.4さらなるオプションさらなるオプションを適用することができ、例えば、OPとOPSFが同じ秘密を共有する場合、類似した状態をもたらすことができる。4.4.1.4.3.2認証オプション実際のユーザ認証は、OpenID仕様では規定されていないので、異なるオプションが適用される。4.4.1.4.3.2.1トラステッドOpenIDの概念の統合についての実施形態例示的な一実施形態では、デバイスは、例えば、TPMを使用することによって、ソフトウェアについての測定値を生成することができる。その後、これらの測定値は、認証セッション中に、SCWSに関連付けられたOPに伝送することができる。ローカルOPは、測定値と比較するために使用される基準値を有することができ、報告された測定値が、これらの知られた良好な基準値に一致する場合に限って、認証は成功することができる。4.4.1.4.3.2.2認証用資格証明書を使用してOpenID秘密をロック解除する例示的な一実施形態では、ユーザとOPSFは、PINコードなど、共通の秘密を共有することができる。4.4.1.4.3.1.3で説明された実施形態と同様に、ユーザが資格証明書を入力するたびに、PINコードを使用して、秘密を計算することができる。そのようなPINは、帯域外の登録プロセスによって共有することができる。4.4.1.4.3.2.3ユーザ認証をデバイスおよびネットワーク認証に結び付けるスマートカードおよびSCWSが、バイオメトリックユーザ認証をサポートする場合、OpenID認証を、ユーザによって提供されたバイオメトリック識別子に結び付けることができる。OPはローカルであるスマートカード上にあるので、OPは、バイオメトリック参照データに直接アクセスすることができ、バイオメトリックデータが、MNOまたは別のインターネットエンティティにさらされることはあり得ない。例示的な一実施形態では、通信デバイスをネットワークに接続することができる。デバイスは、資格証明書を保持することができ、資格証明書は、デバイス上またはUICCなどのスマートカード上に安全に保存することができ、ネットワークに対するデバイスの認証を可能にするために使用される。ユーザだけがアクセスできる、デバイスおよびネットワークサービスへの安全なアクセスを提供するため、デバイスにバイオメトリックスキャナを含ませて、完全な3因子認証メカニズムfullthree-factorauthenticationmechanismを提供することができ、完全な3因子認証メカニズムは、バイオメトリックを、pinまたはパスワードなどユーザが知っている何か、およびセキュリティトークンジェネレータフォブsecuritytokengeneratorfobなどユーザが有する何かと組み合わせる。デバイス認証のための先に説明された実施形態と組み合わせて、ユーザ認証も、認証手順に組み込むことができる。ユーザが、これらの認証メカニズムの組み合わせを使用して、デバイスに対して自らを認証した後、デバイスは、ユーザ認証が正しいかどうかをチェックすることができ、すなわち、最初にユーザを認証し、次に、結果がチェック合格の場合、チェックされたユーザ認証情報例えば、原形式、ハッシュ形式、または他の圧縮形式の、ユーザ認証で使用されたユーザの資格証明書を、デバイスがその内部に保持するデバイス資格証明書と組み合わせ、その後、組み合わされ、結び付けられた資格証明書情報をネットワークに送信する。ネットワークは、組み合わされた資格証明書を受信すると、その後、デバイスが合法ユーザによって使用されているかどうか、およびデバイス自体が合法的なものかどうかを評価することができる。デバイスがそれ自体で、ユーザの真正性をチェックすることが可能でない場合、デバイスは、何か他のことを行うことをユーザに許可せずに、組み合わされた資格証明書情報を最初にネットワークに送信することができ、ネットワークが組み合わされた資格証明書情報を評価し、ユーザが認証されたことを伝えてきた後になって初めて、デバイスの他の機能にアクセスすることをユーザに許可することができる。その後、デバイスは、デバイスの他の機能にアクセスすることをユーザに許可することができる。この手法は、最も厳格なセキュリティを提供することができるが、認証で使用される因子の数は、実施されるセキュリティ方針に基づいて、緩和することができる。認証メカニズム実施形態に組み込むことができる認証シナリオは、以下のことを含む。1.ユーザは、3つすべての形式の認証情報をデバイスに提供し、デバイスは、デバイスに対してユーザを認証し、認証が成功すると、デバイスの機能およびデバイス上に保持されたデータへのアクセスを提供する。その後、デバイスは、通常の方法でネットワークに対して認証を行い、デバイス上で利用可能なネットワークベースのサービスをユーザに提供する。2.ユーザは、3つすべての形式の認証情報をデバイスに提供し、その後、デバイスは、情報のいくつかまたはすべてを用いて、デバイスに対してユーザを認証し、認証が成功すると、認証情報のいくつかまたはすべてを、デバイス上に保持された資格証明書情報と一緒に、ネットワークによるさらなる認証のために、ネットワークに渡す。デバイスとネットワークの間で認証が成功すると、ユーザは、デバイスの機能およびデバイス上に保持されたデータ、ならびにネットワークベースのサービスへのアクセスを許可される。3.上記の2の変形では、デバイスに対するローカル認証のために、ユーザバイオメトリック情報を使用することを必要とせず、バイオメトリック情報、またはバイオメトリック情報のファジーハッシュなど、安全に導出された一意的な情報要素を、ユーザのネットワークレベルの認証のために、ネットワークに送信することができる。4.2または3の別の変形では、ネットワークがデバイスとともにユーザを認証し、デバイスがネットワークから返されたその評価の通知を取得するまで、ユーザは、デバイスの機能およびデータへの限定的なアクセスだけを許可される。このモードでは、ユーザおよびデバイスの資格証明書のネットワーク認証が完了し、適切な認可とともにデバイスに返信されるまで、ユーザは、いくつかの事前指定された安全に隔離された機能およびそれらの機能だけにアクセスすること、または使用することを許可される。デバイスとネットワークの間でユーザ認証機能を分散させた、または完全に1つのエンティティ上にある、上述のメカニズムの変形も可能である。また、ユーザ認証をデバイス認証に結び付けることも、ユーザおよび/またはデバイスの強力な認証を提供することができる。多くのタイプのバイオメトリックスを組み込むことができるが、例示的な一実施形態は、指紋スキャナまたは網膜スキャナなどの、バイオメトリックスキャンを利用することができる。ユーザインタフェースの自然な拡張としてバイオメトリックスキャンを組み込むことによって、ユーザがある機能を実行したこと、またはデバイスにとってローカルの、もしくは通信ネットワークを介する特定のサービスにアクセスしたことを契機とするトリガイベント時に、動的で透過的なユーザ認証を提供するような方法で、バイオメトリックスキャンをセキュリティ機能に組み込むことができる。例えば、ユーザを認証すると同時に発呼を行うために、指紋スキャナをソフトキーに組み込んで、指のストロークが、例えば送信などのソフトキーアクションをトリガするようにすることができる。あるいは、ディスプレイ画面、デバイス本体、またはタッチキーへの、ユーザのデバイスに対する物理的接触を、目立たない認証と組み合わせることによって、デバイスに対して継続的にユーザを認証し続けることができる。4.4.1.4.4アソシエーションベースモードを使用するRPのためのプロトコルフロー図25は、RPがアソシエーションベースモードを使用して、OpenIDユーザ認証を実行することを可能にするためのプロトコルフローの例示的な一実施形態を示している。アソシエーションは、ユーザが最初にRPとコンタクトを取り、RPとともに自らのOpenID識別子を使用した後に、行うことができる。アソシエーションが確立された場合、それを再利用することができ、そのことが通信労力をさらに低減させる。しかし、OPがRPの動作モードを命じることが可能でないことがあり、2つの通信モデルのうちの1つを決定することは、RPに任されていることがある。アソシエーションは、アサーションメッセージに署名するためにOPによって使用でき、OPシグネチャを検証するためにRPによって使用できる、RPとOPの間の永続的な秘密を確立する。OPは、共有秘密の有効期間を決定することができる。RPとOPは、アソシエーションハンドルを秘密のための識別子として使用する。RPは、OPへの第1の要求メッセージにアソシエーションハンドルを含め、その後、OPは、アソシエーションハンドルに応じて、対応する秘密を使用することができる。OPは、アソシエーションが失効していると決定した場合、応答メッセージでRPに通知する。原理的に、これは、OPが、いかなるアソシエーション要求も拒否することを可能にすることができる。RPが、ステートレスモードもサポートできるのであれば、これを使用して、RPを強制的にステートレス通信モードに依存させることができる。RPから要求されたシグネチャモードHMAC-SHA1またはHMAC-SHA256がOPによってサポートできない場合、OPは、例えば、アソシエーション要求を拒否することができる。ユーザがRPにログインするたびに、RPとOPの間で新しい秘密が確立される、ステートレス通信モードとは対照的に、アソシエーションは、アイデンティティとRP毎に1回確立される。OPとRPの間のアソシエーションがすでに確立されている場合、それをRPとOPによって再利用することができる。RPは、OPSFのアドレスが分かると直ちに、すなわち、発見フェーズの後に、アソシエーションを確立することができ、プロトコルを先に進める前に、すなわち、アソシエーションハンドルをリダイレクトメッセージに含める前に、アソシエーションを完了しなければならない。図25に示されるように、625:ユーザは、OpenIDを使用してログインするために、RPウェブサイトを訪れることができ、例えば、http://op.org/identityなど、自らのOpenID識別子を入力することができる。630:ブラウザは、OpenID識別子を含むHTTPメッセージを、RPウェブサイトに送信することができる。635:RPは、HTTP/HTMLベースのOpenIDシンプル発見を使用することができ、公衆インターネットを介してOP-Aggとコンタクトを取り、例えば、HTTPGEThttp://op.org/identityによって、OpenID識別子のためのアイデンティティページを取り出す。640:OP-aggは、要求を受信し、例えば、<linkrel=openid.serverhref=http://op.org/server.cgi>を含めることによって、OPSFのインターネットアドレスを含むHTMLページによって応答することができる。OPSFのアドレスは、OP-aggのアドレスと異なることがある。645:RPは、パラメータopenid.mode=associate、openid.assoc_type=HMAC-SHA1、openid.session_type=blank、openid.dh_=‘Diffie-HellmanParameters’を有する、OPSFに対するHTTPPOSTコールを使用することができる。650:OPSFは、RPのための共有秘密およびアソシエーションハンドルを生成することができる。655:OPSFは、キー=バリューフォーマット文書内にアソシエーションハンドルおよびディフィ-ヘルマンが使用される場合は暗号化された秘密を含む、HTTPPOSTによってRPに応答することができる。このアソシエーションは、RPとOpenIDアイデンティティ毎に1回確立することができる。ディフィ-ヘルマンは、MITM攻撃によって攻撃することができるので、OpenIDセキュリティのベストプラクティスは、HTTPS認証の使用を勧告している。660:RPは、例えば、nonce=123123、session=Userなど、セッションノンスおよびセッション識別子を生成することができる。665:RPは、OPSFから受信した秘密およびアソシエーションハンドルを保存することができる。670:RPは、アソシエーションハンドルをリダイレクトメッセージに含めることができる。675:RPは、パラメータopenid.mode=checked_setup、openid.identity=http://op.org/identity、openid.return_to=http://rp.org/return.cgisession=Usernonce=123123、openid.assoc_handle=‘associationhandle’を含む、HTTPREDIRECTメッセージを、ブラウザに送信することができる。680:ブラウザは、リダイレクトメッセージを受信することができ、リダイレクトメッセージ内のRPによって指定されたURLへの接続をオープンする。685:例えば、エントリhttp://op.org==127.0.0.1を有するホストファイルを使用することによって、OPSFのURLをSCWSローカルIPアドレスにマッピングする、変更されたローカルDNSルックアップテーブルを用いる場合、ブラウザは、SCWSに関連付けられたローカルOPにリダイレクトすることができ、675のパラメータを含むHTTP要求を発行する。変更されたローカルDNSルックアップテーブルは、デバイス上で使用することができ、URLhttp://op.orgがSCWSのローカルIPアドレスにあるとデバイスに思わせる。したがって、ブラウザは、公衆インターネットを介して到達可能な、URLhttp://op.orgにあるOPSFに接続する代わりに、SCWS/ローカルOPへの接続をオープンすることができる。690:以下は、OpenIDプロトコル仕様によって規定されていない。a.SCWSに関連付けられたOPは、ローカル認証ページを表示することができる。b.ユーザは、例えば、ユーザ名およびパスワードなど、自らの認証用資格証明書を入力することができる。c.SCWSに関連付けられたOPは、資格証明書を検証することができる。695:SCWSに関連付けられたOPは、リターンメッセージに署名するために、OPSFとRPの間ですでに共有されている秘密を使用することを必要とすることがあり、いくつかのオプションを適用することができる。a.オプション1:i.秘密は、例えば、事前に共有されていること、OPSFによって事前に用意されていることなど、すでに存在していることができる。b.オプション2:i.OPSFは、例えば、安全なSMSを介して、もしくはGBAによってブートストラップされて、および/またはSCWSHTTPSリモート管理インタフェースなどの安全な通信プロトコルを使用して、アソシエーションハンドルおよび秘密を、SCWSに関連付けられたOPに送信することができる。ii.SCWSに関連付けられたOPは、秘密およびアソシエーションハンドルを保存することができる。c.オプション3:i.SCWSに関連付けられたOPは、RPから受信したアソシエーションハンドルを使用することによって、OPSFに秘密を要求することができる。このメッセージのためのプロトコルは、SMSを介して動作することができ、実現可能性がさらなる研究課題ffsである、他のオプションも可能である。ii.OPSFは、アソシエーションハンドルに基づいて、秘密を求めて検索を実行することができる。iii.OPSFは、例えば、保護されたSMS-PPを介して、もしくは例えばGBAによってブートストラップされて、および/またはSCWSHTTPSリモート管理インタフェースなどの安全な通信プロトコルを使用して、秘密およびアソシエーションハンドルを、SCWSに関連付けられたOPに送信することができる。700:SCWSに関連付けられたOPは、秘密を使用して、戻り先URL、アイデンティティ、およびモードパラメータに対するシグネチャを計算することができる。705:SCWSに関連付けられたOPは、シグネチャを追加パラメータとしてHTTPリダイレクトに含めることができる。710:SCWSに関連付けられたOPは、以下のパラメータを含む、すなわち、openid.mode=id_res、openid.return_to=http://rp.org/return.cgisession=Usernonce=123123、openid.identity=http://op.org/identity、openid.signed=mode,identity,return_to、openid.assoc_handle=‘associationhandle’、openid.sig=‘base64encodedsignature’を含む、HTTPリダイレクトメッセージを、ブラウザに送信することができる。715:ユーザがさらにいかなる関与も行わなくても、ブラウザは、RPにおける戻り先URLにユーザをリダイレクトすることができる。720:RPは、署名されたアサーションメッセージを受信することができる。725:RPは、先に確立された共有秘密を使用して、シグネチャを検証することができる。730:RPからは、ユーザは、http://op.org/identityとして識別することができる。735:ブラウザは、RPのHTMLページを表示することができる。740:ユーザは、http://op.org/identityとして、RPにおいてログインすることができる。アソシエーションベースモードについての追加の実施形態追加の実施形態は、セクション4.4.1.4.3のステートレスプロトコルに対する追加の実施形態を使用する実施形態に基づくことができる。4.4.2SCWS上のOPの改良についての実施形態4.4.2.1改良の一般的な方法セクション4.4.1の例示的な実施形態では、SCWSに関連付けることができるローカルOPと、OPSFは、アサーションシグネチャとそれらの検証のために使用される共有秘密を、RP毎に少なくとも1回確立することを求められることがある。しかし、OPSFとローカルOPの間でただ1つの長期共有秘密を確立し、その後、シグネチャのために使用される秘密を、暗号関数を使用して導出することを可能にする、追加の暗号手法を使用することによって、プロトコルがさらに改良された、追加の方法を適用することができる。さらに、OPSFとローカルOPの間でのこの秘密の交換の統合は、プロトコルメッセージ内で実行することができる。4.4.2.2改良についての予備的な技術情報以下のセクションでは、可能な実施および実施形態についてのより技術的な予備知識を提供する。SCWSは、IPベースまたは従来のUICC方法を使用して、ハンドセットと、また間接的に外部世界の当事者と安全に通信することができ、UICCアプリケーションを所有する当事者は、それらをUICCにダウンロードし、リモートで管理することができる。UICC上でのリソース使用に関して、グローバルプラットフォーム、SCWS、および結果として生じるIPスタックをサポートすることが可能なUICCは、ほぼ確実に、大容量メモリおよびUSBもサポートすることに留意されたい。そのようなUICCは、十分に強力なプロセッサを有することができ、o/sが、リソース管理を引き受ける。図24ステートレスモードの575、および図25アソシエーションモードの695において、SCWSに関連付けられたOPは、秘密を保存し、使用することができる。これを行うことで、例えば、保護されたストレージ内に署名鍵を保持することができ、署名鍵は、そこから決して出ることがなく、署名鍵は、カード自体の中で暗号アルゴリズムによってのみ使用される。これは、MNOのような他のトラステッドパーティと安全に共有でき、スマートカードから決して出ないことを保証できる、何らかの鍵とすることができる。ダウンロードされたアプレットにおけるアプリケーション固有の署名鍵の場合、われわれは、1鍵をどのようにUICCに取り込み、アプレットに入れるか、2鍵のセキュリティをどのように維持するか、3誰が鍵を使用できるか、および4鍵はどのように更新できるかという、検討できる4つの課題を有する。例示的な一実施形態課題1に対する回答では、UICC上のOPに固有の鍵は、アプレットの実行可能ロードファイルの一部としてロードすることができ、そのアプレットの指定されたキーファイル内に存在することができる。アプリケーションダウンロードは、SCWS管理更新プロセスを使用しなくてもよい。しかし、SCWSは、単なるSCWSウェブページではない、任意のアプリケーションを意味するスマートカードアプリケーションを起動することができる。これは、ローカルOPを、グローバルプラットフォームフレームワークの下で動作するアプレットとすることができることを意味する。単なるSCWSHTMLページ以上のものであるそのような複雑なアプレットが、グローバルプラットフォームアプレットローディングプロセスを使用することが有利なことがある。別の例示的な実施形態課題2に対する回答では、いずれかのロードされたアプリケーションに属する秘密は、UICCのO/Sによって保護される。われわれは、O/Sに依存して、それを実施することができる。UICCのロードされたアプリケーションが動作するメモリは、O/Sによって保護される。別の例示的な実施形態課題3に対する回答では、例えば、何らかのデータに署名または暗号解除/暗号化するために、ローカルOPによってプライベート署名鍵を使用することができる。SCWSを介してUICC上のローカルOPと通信できる任意の外部エンティティは、署名または暗号解除するために、データをアプレットに提供することができるが、SCWSへのそのような通信は、リダイレクトとして端末のブラウザを通過しなければならないことがある。共有対称鍵の場合、そのような鍵をMNOなどのTTPに配布することは、TTPがUICCと対話して鍵を使用することができるように、例えばOPなどの鍵の所有者に任せることができる。SCWSに関連付けられたOPに鍵を保存するために、キーファイルが使用される場合、キーファイルを更新するために、標準化されたアプレット更新プロセスを使用することができる。SCWS管理更新プロセスが使用される場合、それは、MNOであると仮定されるSCWS更新プロセスの所有者によって行うことができる。オンカード鍵生成を代替として使用することも可能とすることができる。SCWSは、BIP/CAT通信を提供し、またUSBを介するTCP/IP/HTPPを提供する。後のケースでは、PSKまたはPKIベースのTLSを、デバイスとSCWSの間で使用することができる。別の例示的な実施形態では、OPサーバアプリケーションを、Java登録商標Cardアプレットとして、UICC上にロードすることができ、その後、文献において指定された方法で例えば、非特許文献13参照管理することができる。事実上、同じ当事者によって、すなわち、MNO/カード発行体CIによって、両方のドメインが所有されるとしても、アプレットは、CIのセキュリティドメインSDの下に、またはアプリケーションプロバイダAPのSDの下に配置することができる。あるいは、OPアプリケーションは、ファームウェアまたはネイティブアプリケーションとすることができる。OMAは、SCWSと相互認証を行うHTTPSを使用して、リモートサーバアプリケーションによって、SCWSのコンテンツおよび設定を更新するための安全なプロセスを提供することができる。これは、例えば、カード発行体としてのMNOによる使用のために行うことができ、トランスポートのための従来のOTAの周辺で、そのように考案されている。この機能は、SCWSに関連付けられたアプリケーションをダウンロードするために使用することは意図していないが、そのようなアプリケーションを更新するためにMNOによってのみ使用することができる。SCWSは、SMS-PPがそれのユビキタスデフォルトである従来のツールキットおよびOTA技術を使用することができる。したがって、UICCが自らのIPアドレスを有さない場合、SCWS上のウェブページをクライアントからブラウズするために、およびSCWS上のウェブページを移送し、管理エンティティから管理するために、SCWSは、UICC/ME接続のためにCAT/BIPを使用することを述べる。同様に、SCWSは、リモート管理者からのメッセージのために、連結されたSMS-PPをサポートすることもできる。しかし、UICCが自らのアドレスを有する場合、直接TCP/IP接続の上の直接TLS接続を介して、SCWS上のウェブページをクライアントからブラウズするために、およびSCWS上のウェブページを移送し、管理エンティティから管理するために、SCWSは、UICCの高速すなわちUSBインタフェースの上で、直接TCP/IP接続をサポートすることもできる。4.4.2.3SCWS上の改良OP序論以下の実施形態は、SCWS上のOPの改良された変形という概念について説明する。SCWS上のOPは、OpenID/GBAの改良とすることができる。例えば、実施形態は、以下の利点を提供することができる。●SCWS上のOPは、認証をデバイスにとってローカルなものにし、したがって、通信コストを著しく低下させることによって、OpenID/GBAを改良することができる。●SCWS上のOPのさらなる改良は、認証秘密を、標準的なOpenIDメッセージフィールドに収めて、OPとネットワーク側エンティティの間で伝達することによって、行うことができる。これによって、通信オーバヘッドをさらに低減することができ、またSCWS上のOPとネットワークエンティティOPSFの間の関係を緩和することができ、それによって、ネットワーク間でのOpenIDの移行を可能にすることができる。加えて、以下の実施形態は、SCWS上のOPが、ネットワーク通信事業者に、●認証トラフィックがモバイルネットワーク上で生じない●すべての認証トラフィックが公衆インターネット上で生じる●すべてのアプリケーションデータトラフィックがモバイルネットワーク上で生じるなどの主要な利点を提示することを可能にすることができる。4.4.2.4ローカルOPによって行われる改良例示的な実施形態では、トラフィックを大幅に低減させるために、SCWSに関連付けられたOPに対して、ローカル認証を実行することができる。これを行うことで、例えば、ネットワーク自体にかかる負担を低減するために、認証トラフィックをローカルなものにすることを可能にすることができる。例示的な一実施形態では、ユーザが訪れるRP毎に、ネットワークOPSFエンティティとSCWSに関連付けられたOPとの間で、共有秘密を確立することができる。そのような秘密の確立のためのいくつかの実施形態が、本明細書で説明される。例えば、例示的な一実施形態では、RPによってアソシエーションが使用される場合、RPは、シグネチャ検証のために使用される秘密を保存することができ、ユーザが次回RPを訪れたときに、その秘密を再利用することができる。別の例示的な実施形態では、RPがステートレスモードを使用する場合、RPは、秘密をセーブしないことがある。OPは、秘密を生成することができ、それをOPSFと安全に共有することができる。SCWSに関連付けられたOPは、この秘密を保存することができ、ユーザが次回同じRPを訪れたときに、その秘密を再利用することができ、OPSFは、ステートレスモードにおけるシグネチャ検証のためにその秘密を直接的に使用できるように、同じ秘密を保存することができる。別の例示的な実施形態では、OPSFとSCWSに関連付けられたOPとの間でひとたび共有された秘密は、ある程度までは再利用できると仮定することができる。例えば、OPのための秘密を全部で5つスマートカード上に保存できる場合、ユーザがRPを訪れるたびに、その秘密を再利用することができる。これを行うことで、例えば、文献において仕様が規定された例えば、非特許文献5参照OpenID/GBAと比較して、ネットワークトラフィックを大幅に減少させることができる。例えば、日々のトラフィックを半分に減少させることができ、複数の日を考えた場合、秘密を再利用することができるので、減少はより一層大きくなる。言及された秘密は、OpenID/GBAで使用される秘密とは異なることがあり、OPSFとSCWSに関連付けられたOPとの間で共有される秘密は、アサーションメッセージに署名するのに使用されるOpenID秘密である。標準的なOpenIDプロトコル手順におけるように、これらの秘密は、RPと共有することができ、例えば、単一のログインセッションよりも長く存続するなど、より長期にわたって存続する秘密として確立することができ、基本的にこの再利用を可能にする。4.4.2.5さらなる改良SCWS上のOPを実施するためのプロトコルフローの例示的な一実施形態では、MNO運用のOPSFネットワークエンティティは、デバイス上のSCWSに関連付けられたOPとの追加の通信に携わることができる。各RPがアサーションメッセージの署名または署名の検証をそれぞれ行うために、両方のエンティティが同じ対称鍵を備えていなければならないので、この通信が必要とされることがある。実施形態のさらなる改良は、デバイスとネットワークの間の付加的な通信を大幅に減少させることができ、秘密の確立のために必要な情報を、OpenIDメッセージのプロトコルフィールド内に直接的に収容することができる。これらのメッセージは、公衆インターネットを介してHTTPメッセージとして送信され、MNOのエアネットワークインフラストラクチャに追加的な負担をかけることがある。これを行うことで、例えば、ブラウザとデバイス内のUICC/SCWSの間の認証トラフィックがローカルであることを保証することができ、それによって、ネットワークを使用しないようにすることができる。これによって、通信はエアネットワークからデバイス内の内部通信にオフロードされるので、全般的なトラフィックの減少を可能にすることができる。実施形態の別の改良は、認証のためのMNOとUICC/デバイスの間の追加的なシグナリングトラフィックを実行する必要がないことを保証することによって、与えることができる。例えば、認証毎のGBA実行、または無線を介したネットワークとデバイスの間のSMS/MMSもしくは制御メッセージの送信は、存在しなくてもよい。すべての必要な情報は、HTTPメッセージに収めて直接的に搬送することができ、これは、一部デバイスからRPはエアネットワークを介するインターネット上で、一部RPからMNOは有線公衆インターネット上で行うことができる。しかし、このトラフィックは、1OpenIDを使用してログインすることを望むユーザによってトリガすること、2既存のデータプランによってユーザに請求すること、3ウェブベースのOpenIDよりも少なく、またOpenID/GBAよりも少なくすることができる。4.4.2.4プロトコル改良の技術的詳細4.4.2.4.1命名規約上で説明したのと同じ命名規約を、参考までにここでも繰り返す。●SCWSに関連付けられたOP:署名されたアサーションメッセージを発行し、それらをユーザのブラウザを介してRPに送信する、OpenIDアイデンティティプロバイダ。SCWSを、したがってOPをホストするスマートカードは、MNOと、したがって、すべてのMNO関連のエンティティと関係を有すると仮定される。●RP:ユーザにOpenIDを使用したログインを提供する任意のウェブサイトとすることができる依拠当事者。RPは、他のすべてのエンティティから完全に独立であり、したがって、RPに追加の要件を課すことはできず、RPについてのOpenIDプロトコルフローに対する変更は生じることができない。OPは、RPが使用することを選んだ通信モードはステートレスまたはアソシエーションベースのどちらであれサポートしなければならない。MNOが、ユーザはあるRPを使用すべきではないと決定した場合、ユーザは依然として別のアイデンティティを使用できるので、MNOは、これらのRPに対するOpenIDアクセスを拒否することによって、これらのサイトへのアクセスを拒否することはできない。MNOは、一般に帯域幅消費サイトへのアクセスをブロックする追加の手段を使用して、RPへのアクセスを制限できるにすぎない。●OP-Agg:OP-Aggは、OpenID標準に従って、RPに発見サービスを提供するネットワークエンティティを実施する。●OPSF:OPサーバ機能OPSFは、SCWSに関連付けられたOPおよび任意選択的にRPとともに、OpenIDプロトコルのための秘密を生成し、共有し、分配することができる、サポートOP機能を実施する。OPSFとSCWSに関連付けられたOPとは、RPの観点からは、それらが単一のエンティティであるかのように振る舞っている。OPSFは、SCWSに関連付けられたOPによって発行されたシグネチャを検証することができ、公衆インターネットを介してRPから直接的に到達可能である。デバイス上のブラウザは、OPSFのアドレスがSCWSに関連付けられたローカルOPにマッピングされるように、デバイス上のローカルDNS解決キャッシュを変更することによって、SCWSに関連付けられたOPにリダイレクトされる。このエンティティOPSFおよびその必要な機能についての要件は、上で詳細に示された先行文献において説明された例えば、非特許文献14参照。●ブラウザ:SCWSに関連付けられたOPへの、およびSCWSに関連付けられたOPからのルーティングおよびメッセージング機能を明示的にするために、プロトコルフロー図内に示される。それ以外では、ブラウザは、ユーザ認証を表示し、受信するためのフロントエンドにすぎない。4.4.2.4.2実施形態に対する可能な仮定SCWSに関連付けられたOPおよびOPSF機能は、スマートカードセキュリティ機能によって保護され、SCWSに関連付けられたOPにのみアクセス可能な、長期秘密Kを確立することができる。この秘密の確立は、例えば、単一のGBA実行によることができ、または例えばAKA鍵からこの鍵を導出することが可能な別の鍵導出関数、もしくはUICCセキュリティ機能によって保護できる、MNOとSCWSに関連付けられたOPとの間の共有秘密をもたらす他の任意の方法の使用によることができる。加えて、秘密の確立は、当技術分野で知られた任意の方法を使用して行うことができる。スマートカードは、Kから導出される新しい秘密を計算するための、暗号機能アルゴリズムおよび計算を提供することもできる。この機能の特定の特性を、説明およびセキュリティ要件から導出することができる。同一または同様の機能は、OPSFも知ることができ、それによって、OPSFがKから鍵を導出することを可能にすることができる。両方のエンティティは、暗号操作のために、十分な長さのランダム値を生成することができてよい。4.4.2.4.3プロトコルフロー説明以下のセクションでは、SCWSに関連付けられたOPを実施するためのプロトコルフローの例示的な実施形態について説明する。4.4.2.4.3.1ステートレスモードを使用するRPのためのプロトコルフローについての例示的な実施形態RPが、ステートレスモードを使用して、OpenIDユーザ認証を実行する場合、図26に示される実施形態を適用することができる。4.4.2.4.3.1.1ステートレスモードについての説明図26は、改良されたステートレスモードのためのプロトコルフローの例示的な一実施形態を示している。745:ユーザは、RPウェブサイトを訪れることができ、OpenIDを使用してログインするために、例えば、http://op.org/identityなどの、自らのOpenID識別子を入力する。750:ブラウザは、OpenID識別子を含むHTTPメッセージを、RPウェブサイトに送信することができる。755:RPは、HTTP/HTMLベースのOpenIDシンプル発見を使用することができ、公衆インターネットを介してOP-Aggとコンタクトを取り、例えば、HTTPGEThttp://op.org/identityによって、OpenID識別子のためのアイデンティティページを取り出す。760:OP-aggは、要求を受信することができ、OPSFのインターネットアドレスを含むHTMLページによって応答することができる。例えば、OP-aggは、<linkrel=openid.serverhref=http://op.org/server.cgi>を含めることによって応答することができる。OPSFは、RPに対して標準的なOpenIDアイデンティティプロバイダウェブサービスのように振る舞うことができる。例えば、OPSFは、RPからの要求時に、アサーションメッセージ上のローカルOPによって発行されたシグネチャを検証することができる。要件通りに、OPSFは、公衆インターネットを介して到達可能でなければならず、したがって、http://op.orgによって到達可能な、例えばop.orgなどの、DNS名を有すると仮定される。外部世界は、スマートカードのIPアドレスを知ることができないので、このインダイレクションOP-aggおよびOPSFを、通信のために使用することができる。OPSFのアドレスは、OP-aggのアドレスと異なることがある。765:RPは、OPSFのアドレスを受信することができ、例えば、nonce=123123、session=Userなどと、ノンスおよびセッション識別子を生成する。RPは、ユーザ認証後にブラウザをどのURLにリダイレクトすべきかをOPに命じる、戻り先パラメータを編集することができる。RPは、以下のパラメータを含む、ブラウザをOPサーバアドレスにリダイレクトする、HTTPリダイレクトを発行することができる。openid.mode=checkid_setup、openid.identity=http://op.org/identity、openid.return_to=http://rp.org/return.cgisession=Usernonce=123123770:ブラウザは、リダイレクトを受信することができ、リダイレクトメッセージ内のRPによって指定されたURLへの接続をオープンすることができる。775:例えば、エントリhttp://op.org==127.0.0.1を有するホストファイルを使用することによって、OPSFのURLをSCWSローカルIPアドレスにマッピングする、変更されたローカルDNSルックアップテーブルを用いる場合、ブラウザは、SCWSに関連付けられたローカルOPにリダイレクトすることができ、765のパラメータを含むHTTP要求を発行する。変更されたローカルDNSルックアップテーブルは、デバイス上に存在することができ、URLhttp://op.orgがSCWSのローカルIPアドレスにあるとデバイスに思わせる。ブラウザは、公衆インターネットを介して到達可能な、URLhttp://op.orgにあるOPSFに接続する代わりに、SCWS/ローカルOPへの接続をオープンすることができる。780:以下は、認証トラフィックをローカルに保つことを保証するために実行することができるが、これらのステップは、必須ではなく、OpenIDプロトコル仕様によって規定されていない。a.SCWSに関連付けられたOPは、ローカル認証ページを表示することができる。b.ユーザは、例えば、ユーザ名およびパスワードなど、自分の認証用資格証明書を入力することができる。c.SCWSに関連付けられたOPは、資格証明書を検証することができる。785:SCWSに関連付けられたOPは、一意的でランダムなアソシエーションハンドルAを生成することができる。関数fを使用すると、アサーションメッセージのための署名秘密を、S=fA,Kによって計算することができ、ここで、fは、Aの知識がKについてのいかなる知識も明かさないように、一方向とすべきである。例示的な一実施形態では、fは、SおよびAが明かされたとしても、Kについてのいかなる知識も明かすことはできず、すなわち、SおよびAが与えられた場合、ある関数gについて、K=gS,Kを計算することが、計算的に実行不可能であるべきである。Aは、リダイレクトメッセージ内のパラメータの一部として、RPに明かすことができるので、OpenIDプロトコル実行のステートレスモードでは、RPがSの知識を獲得しないと仮定することができる。アソシエーションハンドルAは、リダイレクトメッセージに含めることができる。加えて、Sを使用して署名された署名済メッセージmを与えても、シグネチャの検証者には、Kについてのいかなる情報も明かされ得ないと仮定することができる対称鍵シグネチャが使用されるので、シグネチャの検証者は、シグネチャを検証するために、常にSを所有していることが必要であり、したがって、シグネチャがSを明かさないことを必要としない。アソシエーションハンドルは、長さが255文字以下の文字列であると規定することができ、33と126を含む33~126の範囲のASCII文字印刷可能な非空白文字のみから成ることができる。シグネチャを検証するためにOPSFによって使用される秘密は、シグネチャを生成するためにSCWSに関連付けられたOPによって使用される秘密と同じとすることができる。シグネチャの新しさは、次のステップで挿入されるRPノンスによって保証することができ、RPノンスは、シグネチャの一部であることが要求される。OpenID仕様は、署名秘密自体の新しさについては何もいわないままである。秘密の暗号強度を保証すること、秘密の秘密性を維持すること、およびそれが必要な場合は、秘密の新しさを保証することは、OPの責任とすることができる。OPSF、またはSCWSに関連付けられたOPは、この目的のために、署名秘密に対して、限られた存続期間または使用カウントを実施することができる。ツールキット対応のローカルOPは、SCWSをバイパスして、ハンドセットとプロアクティブに通信するために、CATを使用することができる。メッセージは、例えば、SMS-PPベアラを介してOPSFに送信するために標準的なOTA通りにフォーマットすることができる。これは、OPSFが、MNOのOTAシステムを介して、カードと通信することを必要とすることがある。別の例示的な実施形態では、BIPゲートウェイが、ツールキットメッセージのペイロードを抽出することができ、ハンドセットが、TCP/IPを使用して、それをOPSFに送信することができる。これも、メッセージがMNOのOTAサーバを通過することを必要とすることがある。加えて、SCWSは、カードがIPアドレスを有せず、TCP/IPをサポートしない場合に限って、BIPを使用すべきであることを命じる。そのため、TCP/IPを使用したSCWSを介する送信が、期待されることであることがある。d.SCWSに関連付けられたOPとOPSFとの間の共有秘密をもたらさなければならないことがある、さらなるオプションも適用することができる。そのような方法の実現可能性は、さらなる研究課題である。790:SCWSに関連付けられたOPは、戻り先、アイデンティティ、およびモードなどのパラメータに対するシグネチャを計算することができる。795:SCWSに関連付けられたOPは、765においてRPから受信したパラメータを含む、HTTPリダイレクトメッセージをブラウザに送信することができる。追加的に、以下のものも、すなわち、●openid.signedパラメータ内の署名されたパラメータのリスト、●openid.assoc_handleパラメータ内のアソシエーションハンドルA、および●openid.sigパラメータ内のシグネチャbase64符号化も含むことができる。このメッセージは、ブラウザをRPの戻り先URLにリダイレクトするために使用することができる。800:ブラウザは、ユーザをRPの戻り先URLにリダイレクトすることができる。805:RPは、署名されたアサーションメッセージを受信することができ、HTTPSベースの公衆インターネットを介する直接通信によって、OPSFとともに検証手順に携わる。810:RPは、795のSCWSに関連付けられたOPから受信したパラメータを含む、HTTPPOSTメッセージを発行することができる。HTTPPostメッセージは、SCWSに関連付けられたOPによって生成された、アソシエーションハンドルAを含むことができる。815:OPSFは、パラメータリストからAを抽出することができ、同じ入力を有する、SCWSに関連付けられたOPと同じ関数を使用することができ、すなわち、OPSFは、fA,K=Sを計算し、Sを共有鍵として使用して、SCWSに関連付けられたOPから受信したデータ上のシグネチャを検証する。820:OPSFは、シグネチャ検証が成功した場合、is_valid:trueを返すことができる。825:RPからは、ユーザは、今ではhttp://op.org/identityとして識別することができる。830:ブラウザは、RPのHTMLページを表示することができる。835:ユーザは、http://op.org/identityとして、RPにおいてログインすることができる。4.4.2.4.3.2アソシエーションベースモードを使用するRPのためのプロトコルフロー図27は、改良されたアソシエーションベースモードのためのプロトコルフローの例示的な一実施形態を示している。これは、例えば、RPがアソシエーションベースモードを使用して、OpenIDユーザ認証を実行する場合に行うことができる。アソシエーションは、ユーザが最初にRPとコンタクトを取り、RPとともに自らのOpenID識別子を使用した後に、行うことができる。アソシエーションが確立された場合、それを再利用して、通信労力をさらに低減させることができる。しかし、OPがRPの動作モードを命じることが可能でないことがあり、2つの通信モデルのうちの1つを決定することは、RPに任されている。アソシエーションは、アサーションメッセージに署名するためにOPによって使用でき、OPシグネチャを検証するためにRPによって使用できる、RPとOPの間の永続的な秘密を確立することができる。OPは、共有秘密の有効期間を決定することができる。RPとOPは、アソシエーションハンドルを秘密のための識別子として使用することができる。RPは、OPへの第1の要求メッセージにアソシエーションハンドルを含めることができ、その後、OPは、アソシエーションハンドルに応じて、対応する秘密を使用することができる。OPは、アソシエーションが失効していると決定した場合、応答メッセージでRPに通知することができる。これは、OPが、いかなるアソシエーション要求も拒否することを可能にすることができる。RPが、ステートレスモードもサポートできるのであれば、これを使用して、RPを強制的にステートレス通信モードに依存させることができる。RPから要求されたシグネチャモードHMAC-SHA1またはHMAC-SHA256がOPによってサポートされない場合、OPは、例えば、アソシエーション要求を拒否することができる。ユーザがRPにログインするたびに、RPとOPの間で新しい秘密が確立される、ステートレス通信モードとは対照的に、アソシエーションは、アイデンティティとRP毎に1回確立することができる。例えば、ユーザがログインしたときに、図27に示される項目が、必ずしもすべて実行されなくてもよい。OPとRPの間のアソシエーションがすでに確立されている場合、それをRPとOPによって再利用することができる。RPは、OPSFのアドレスが分かると直ちに、すなわち、発見フェーズの後に、アソシエーションを確立することができ、プロトコルを先に進める前に、すなわち、アソシエーションハンドルをリダイレクトメッセージに含める前に、アソシエーションを完了することができる。図27に示されるように、840:ユーザは、RPウェブサイトを訪れることができ、OpenIDを使用してログインするために、例えば、http://op.org/identityなど、自らのOpenID識別子を入力することができる。845:ブラウザは、OpenID識別子を含むHTTPメッセージを、RPウェブサイトに送信することができる。850:RPは、HTTP/HTMLベースのOpenIDシンプル発見を使用することができ、公衆インターネットを介してOP-Aggとコンタクトを取り、例えば、HTTPGEThttp://op.org/identityによって、OpenID識別子のためのアイデンティティページを取り出す。855:OP-aggは、要求を受信することができ、例えば、<linkrel=openid.serverhref=http://op.org/server.cgi>を含めることによって、OPSFのインターネットアドレスを含むHTMLページによって応答することができる。OPSFのアドレスは、OP-aggのアドレスと異なることがある。860:RPは、パラメータopenid.mode=associate、openid.assoc_type=HMAC-SHA1、openid.session_type=blank、openid.dh_=‘Diffie-HellmanParameters’を有する、OPSFに対するHTTPPOSTコールを使用することができる。865:OPSFは、RPのためのランダムで一意的なアソシエーションハンドルAを生成することができる。加えて、OPSFは、関数fを使用することができ、S=fA,Kを計算する。その後、Sは、RPとOPSFの間のアソシエーション中期共有秘密として使用することができる。RPは後で、Sを使用して、SCWSに関連付けられたOPから来たアサーションメッセージ上のシグネチャを検証することができる。例示的な一実施形態では、AとSは両方とも、870においてRPと共有することができるので、SとAが与えられてもKを計算できないように、fは、AとSが分かったとしても一方向であり続ける関数であると仮定することができる。関数f自体は、秘密であることを要求されなくてもよい。870:OPSFは、キー=バリューフォーマット文書内にアソシエーションハンドルAおよびディフィ-ヘルマンが使用される場合は暗号化された秘密Sを含む、HTTPPOSTによってRPに応答することができる。このアソシエーションは、RPとOpenIDアイデンティティ毎に1回確立することができる。これは、HTTPS認証を使用することによって実行することができる。880:RPは、例えば、nonce=123123、session=Userなど、セッションノンスおよびセッション識別子を生成することができる。885:RPは、OPSFから受信した秘密SおよびアソシエーションハンドルAを保存することができる。890:RPは、アソシエーションハンドルAをリダイレクトメッセージに含めることができる。895:RPは、HTTPREDIRECTメッセージを、ブラウザに送信することができる。HTTPREDIRECTメッセージは、パラメータopenid.mode=checkid_setup、openid.identity=http://op.org/identity、openid.return_to=http://rp.org/return.cgisession=Usernonce=123123、openid.assoc_handle=Aを含むことができる。900:ブラウザは、リダイレクトメッセージを受信することができ、リダイレクトメッセージ内のRPによって指定されたURLへの接続をオープンすることができる。例えば、エントリhttp://op.org==127.0.0.1を有するホストファイルを使用することによって、OPSFのURLをSCWSローカルIPアドレスにマッピングする、変更されたローカルDNSルックアップテーブルを用いる場合、ブラウザは、SCWSに関連付けられたローカルOPにリダイレクトすることができ、885のパラメータを含むHTTP要求を発行する。変更されたローカルDNSルックアップテーブルは、デバイス上に存在することができ、URLhttp://op.orgがSCWSのローカルIPアドレスにあるとデバイスに思わせることができる。905:ブラウザは、公衆インターネットを介して到達可能な、URLhttp://op.orgにあるOPSFに接続する代わりに、SCWS/ローカルOPへの接続をオープンすることができる。910:以下は、認証トラフィックをローカルに保つことを保証するために実行することができるが、これらのステップは、必須ではなく、OpenIDプロトコル仕様によって規定されていない。a.SCWSに関連付けられたOPが、ローカル認証ページを表示する。b.ユーザが、例えば、ユーザ名およびパスワードなど、自分の認証用資格証明書を入力する。c.SCWSに関連付けられたOPが、資格証明書を検証する。915:SCWSに関連付けられたOPは、リターンメッセージに署名するために、OPSFとRPの間で共有できる秘密Sを使用することを必要とすることがある。パラメータAは、受信したHTTP要求から抽出することができ、関数fは、S=fA,Kのように適用される。920:SCWSに関連付けられたOPは、秘密を使用して、戻り先URL、アイデンティティ、およびモードパラメータに対するシグネチャを計算することができる。Sを使用して署名された署名済メッセージmを与えても、m上のシグネチャの検証者には、Kについてのいかなる情報も明かされ得ないような関数fが必要なことがある。925:SCWSに関連付けられたOPは、シグネチャを追加パラメータとしてHTTPリダイレクトに含めることができる。930:SCWSに関連付けられたOPは、以下のパラメータを含む、すなわち、openid.mode=idres、openid.return_to=http://rp.org/return.cgisession=Usernonce=123123、openid.identity=http://op.org/identity、openid.signed=mode,identity,return_to、openid.assoc_handle=A、openid.sig=‘base64encodedsignaturecalculatedusingS’を含む、HTTPリダイレクトメッセージを、ブラウザに送信することができる。935:ユーザがさらにいかなる関与も行わなくても、ブラウザは、RPにおける戻り先URLにユーザをリダイレクトすることができる。940:RPは、署名されたアサーションメッセージを受信することができる。945:RPは、確立された共有秘密Sを使用して、シグネチャを検証することができる。950:RPからは、ユーザは今では、http://op.org/identityとして識別することができる。955:ブラウザは、RPのHTMLページを表示することができる。960:ユーザは、http://op.org/identityとして、RPにおいてログインすることができる。アソシエーションベースモードについての追加の実施形態セクション4.4.1.4.3で説明されたステートレスプロトコル実施形態に関連する追加の実施形態が以下で開示される。4.4.2.5SCWS上の改良OPと既存のOpenID/GBAとの比較OpenID/GBAでは、ユーザは、GBAプロトコルを使用して認証を受け、すなわち、任意のRPにおいてOpenIDログインが試みられるたびに、エアインタフェースを介したOP/NAFを用いるGBA実行がトリガされ、増加するトラフィックによって、ネットワークエンティティOP/NAFとネットワーク自体の両方に対する負荷を生じさせる。1万人のユーザからなる顧客ベースが与えられ、毎日、すべてのユーザが10の異なるRPにログインすると仮定する。OpenID/GBAの下では、これは、1日当たり、合計で10万回のGBA認証実行をもたらし、各GBA実行誰何応答が1~5キロバイトしか消費しない場合でも、これは、1日当たり、合計で1~4.8GBの追加の認証トラフィックとなる。4.4.2.6セキュリティについての説明以下のセクションでは、ステートレスモードおよびアソシエーションベースモードのSCWS上のOPのプロトコルについての例示的な実施形態において使用できる、暗号ツールについての予備知識を提供する。使用できるハッシュアルゴリズムなどの態様が説明される。4.4.2.6.1全般関数fを使用して、ローカルOPとOPSFの間で共有秘密Sを確立することができる。OPSFとローカルOPは、fの1つの入力として使用できる、共通の共有長期秘密Kを有することができ、Kは、プロトコルにおける別の当事者に決して明かすことはできない。しかし、RPは、アサーションメッセージ上のシグネチャを検証できるので、アソシエーションベースモードでは、秘密SをRPに明かすことができる。秘密の共有は、セキュリティと密接に関係し得るので、Sの知識に関してRPが有する選択肢について説明する必要があるであろう。これは、標準的なOpenIDプロトコルにも適用することができる。RPに悪意があると仮定した場合、Sの知識は、RPが、ユーザを別のRPにおいてログインさせることを可能にすることはできず、それは、別のRPは、OPとともに別の共有秘密S’を確立しており、したがって、Sを使用して行われたシグネチャを無効と認識するからである。したがって、秘密SをRPに明かすことは、セキュリティ上の問題にはなり得ない。しかし、Sをブラウザまたはユーザに明かすことは、セキュリティ上の問題になり得る。この場合、攻撃者は、被害者のOpenID識別子を用いて、OpenIDプロトコルを開始することができる。攻撃者が、RPとOPの間で共有される共有秘密Sを取り出すことができたとすると、攻撃者は、実際の認証をOPに対して実行しなくても、Sを使用して、アサーションメッセージに署名することができる。したがって、攻撃者は、被害者のOPから認証を受けることなく、被害者の識別子を使用してログインすることができる。このシナリオから分かるように、RPとOPの間の共有秘密Sは、ブラウザに明かすことはできないが、SをRPに明かすことは、問題なしとすることができる。悪意あるユーザとRPが一緒に動作する場合、RPは、Sをブラウザに送信することができ、ユーザは、OPから認証を受けることなく、RPにログインすることができる。しかし、ユーザは、シナリオの仮定によれば、すでにユーザの制御下にあるまたは少なくともユーザと協力する、単一のRPにログインできるだけなので、これを攻撃と見なすことはできない。したがって、ユーザは、OpenID認証プロトコル実行をまったく実行しなくても、ログインすることができる。4.4.2.6.2例示的なプロトコルのセキュリティ特徴ある例示的な実施形態では、リダイレクトメッセージ内の、Sを使用して署名されたメッセージばかりでなく、Aも、ブラウザに明かすことができ、Aの知識と、Sを使用して署名されたメッセージとを与えても、Sを計算することは実現不可能とすることができる。さらに、同じ入力を与えても、Kを計算することは実現不可能とすることができる。AとSOPとOPSF以外の単一のサードパーティに明かすことができるほとんどの情報を与えても、Kを導出することが計算的に実現不可能であるすなわち、入力の長さのものを多項式時間で計算できる、f-1A,S=Kのような関数f-1が存在しないと仮定できることが要求される場合、RPは、OPSFとSCWSに関連付けられたOPとの間の長期共有秘密Kを導出することはできない。したがって、ランダムな入力Aと共有秘密Kを与えた場合に、fが、S=fA,Kのように、新しい秘密Sを生成することを必要とすることができる。AおよびSを使用して署名されたメッセージを与えた場合、Sを計算することは実現不可能とすることができる。それは、入力Kが正しく、現在のものである場合に、fが正しい結果を生成できることを必要とすることができる。fの計算は、多項式時間で可能とすることができ、好ましくは、スマートカードの保護された領域で行うことができる。Sは、OpenIDにおいて使用されるシグネチャ関数にとっての有効な入力とすることができる。OpenIDは、シグネチャアルゴリズムとしてHMAC-SHA1またはHMAC-SHA256の使用を見込んでいる。OPSFとSCWSに関連付けられたOPとは、あらかじめ特定のシグネチャアルゴリズムに合意できるので、鍵長を、したがって、関数fの出力長を固定することができる。例示的な一実施形態では、SHA1ベースのシグネチャの場合は、Kを使用して、Sを導出でき、SHA256シグネチャの場合は、K’を使用して、Sを導出できるように、OPSFとOPは、2つの共有秘密KおよびK’を使用することができる。4.4.2.6.3セキュリティ実施本セクションで説明される実施形態は、先のセクションで指摘された要件を満たすことができる暗号操作である。例示的な一実施形態では、秘密は、OpenIDメッセージ内に直接的に含めることができ、そうすることで、認証のために必要とされるトラフィックの減少をもたらすことができる。ユーザ認証は、ローカルにMNOネットワークが関与せずに実施することができ、OPSFMNOネットワークとデバイス内のSCWSに関連付けられたOPとの間の共有秘密は、MNOネットワークとデバイスの間のさらなる外部的な追加の通信を必要とせずに、OpenIDプロトコルメッセージ内に収めて安全に伝達することができる。4.4.2.6.3.1HMACHMACは、いかなる追加メカニズムも使用せずに、メッセージのソースとメッセージの完全性の両方を認証するための、鍵付きハッシュメッセージ認証コードMACである。HMACは、メッセージ入力と、メッセージの発信者および意図された受信者にのみ知られた秘密鍵という、2つの機能的に異なるパラメータを有する。HMAC関数は、秘密鍵とメッセージ入力とを要約することによって形成される値MACを生成するために、メッセージの送信者によって使用される。MACは、一般に、メッセージとともにメッセージ受信者に送信される。受信者は、送信者によって使用されたのと同じ鍵とHMAC関数を使用して、受信したメッセージに対してMACを計算し、計算された結果を受信したMACと比較する。2つの値が一致した場合、メッセージは、正しく受信されており、受信者は、送信者が鍵を共有するユーザからなるコミュニティのメンバであることを保証される。HMACの特性を考えると、関数fのためのHMACの使用は、上で説明されたすべての関連要件を満たすことができる。HMACのための関連パラメータのリストを以下に示す。●B-ハッシュ関数の入力のブロックサイズ、例えば、SHA1の場合は160ビット。●H-ハッシュ関数例えばSHA1。●ipad-内側パッド、x‘36’であるバイトがB回反復する。●K-OPとOPSFの間で共有される秘密鍵。●K0-Bバイトの鍵を取得するために前処理した後の鍵K●L-ハッシュ関数の出力のブロックサイズ、例えば、SHA1の場合は160ビット。●opad-外側パッド、x‘5c’であるバイトがB回反復する。●t-MACのバイト数。●text-長さがnビット0<=n<2^B-8Bの、HMACを計算するもととなる平文であり、われわれのケースでは、Aに相当する。●||-連結●XOR-排他的OR●Kは、L/2以上であるべきであり、すなわち、われわれのケースでは、Kは、SHA1が使用される場合、80ビットより大きく、SHA256の場合、128ビットより大きくすべきである。●MACtext=HMACK,text=HK0XORopad||HK0XORipad||textMACを計算するために2つのハッシュ関数の実行をネストさせることが、攻撃を防ぐために必要となることがある。ほとんどのハッシュ関数では、鍵Kを知ることなく、付加的なデータをメッセージに追加し、別の有効なMACを獲得することが可能である。他の代替を使用する場合、MAC=Hmessage||keyを使用して鍵を追加することは、鍵なしハッシュ関数において衝突を見つけることができる攻撃者が、MACにおいて衝突を取得することを可能にする。MAC=Hkey||message||keyを使用するほうがより好ましいが、様々なセキュリティ論文が、脆弱性を明らかにしており、2つの異なる鍵が使用される場合であっても脆弱である。図28は、文献から引用した例えば、非特許文献3参照鍵付きハッシュメッセージ認証コードHMACを示している。HMACの現在合意されているバージョンは、外側のハッシュ関数が、内側のハッシュ関数の中間結果をマスクするので、これらの脆弱性にさらされていない。パディングipadおよびopadの値は、アルゴリズムの安全性にとって重要ではないが、互いに大きなハミング距離を有するように定義され、そのため、内側の鍵と外側の鍵は、共通するビットを僅かしか有さず、すなわち、パディングは、ハッシュ関数において使用される2つの異なる鍵を、K0から導出するために使用される。例示的な一実施形態では、text=ランダムな入力としてのAは、OPまたはOPSFによってそれぞれ生成することができる。Aは、リダイレクトメッセージに含めることができ、Kを使用して、OPとOPSFは、上述のメカニズムを使用してHMACを再計算することができ、HMAC結果は、OpenIDアサーションメッセージのための共有署名秘密Sとして、使用することができる。4.4.2.6.3.2SCWS上の改良OPのプロトコルのセキュリティ証明示す必要があることは、1.プロトコルにおいて、攻撃者は、例えば、アソシエーションモードにおけるRPとしてAおよびSを取り出すことができ、したがって、攻撃者がKを取り出すことは不可能であることが示されなければならない。2.ブラウザ/ユーザは、RPよりもさらに僅かしか、すなわち、Aだけしか取り出さず、Aについての知識からSを計算できてはならない。3.ブラウザ/ユーザは、AからKも計算できてはならない。攻撃者がSについての与えられた情報を使用しない、SおよびAについての知識を有する攻撃者をモデル化した場合、3についての証明は、1から導出することができる。したがって、以下のことを示さなければならない。I.SおよびAが与えられた場合、S=fA,Kとして、K=fA,Sであるような関数fが存在してはならない。II.Aだけが与えられた場合、S=fA,Kとして、S=gAであるような関数gが存在してはならない。どちらの定理も、11においてBellare他によって提示された、HMACまたはNMACについての説明の中に、それらの証明が見出され、それらは、HMACが、基礎をなす圧縮ハッシュ関数が疑似ランダムであり、その関数は衝突困難性が弱いことを仮定した、疑似ランダム関数であることを本質的に示している。12では、これらの仮定は、圧縮関数がPRFであるというただ1つの仮定の下で、HMACがPRFであることを示すことによって緩和される。4.4.2.6.3.3RSA例示的な一実施形態では、OPSFとSCWSに関連付けられたOPとの間で共有しなければならない秘密鍵を用いて、ランダムに生成された一意的なアソシエーションハンドルを暗号化することによって、共有鍵KからOpenIDシグネチャ秘密Sを導出するために、RSA暗号化方式を使用することができる。N=pqが、RSA方式で使用される法を表すとし、p、qは、素数であるとする。さらに、鍵ペアは、e、d秘密、公開によって表され、長期秘密Kとして共有される。その後、秘密部分eを使用して、アソシエーションハンドルAに署名を行い、シグネチャ秘密Sを取得する、すなわち、S=AemodNとする。RSAについてのセキュリティ仮定を考えると、公開鍵dを知っている場合、SからAを計算することは可能になり得るが、AおよびSを与えても、eを計算することは可能になり得ない。Aだけを与えた場合、eについての知識なしに、Sを計算することは可能ではない。4.4.2.6.4セキュリティ実施の変形4.4.2.6.4.1長期秘密Kの変更セクション4.4.2で説明された、例示的な一実施形態では、長期秘密Kが使用されるが、この秘密は、例えば、一定の期間の後、OPSFとSCWSに関連付けられたOPとの間の鍵交換方法を使用して、変更することができる。知られた任意の鍵交換方法を使用することができる。Kの変更は、OPSFにおいて実行することができ、SCWSに関連付けられたOPは、成功したOpenIDプロトコル実行を阻むことはできない。例示的な一実施形態では、ステートレスモードにおいて、OPSFとOPが、新しい長期秘密K’に合意した場合、OPは、新しい鍵とともに関数fを使用して、署名鍵S’を計算することができ、すなわち、S’=fA,K’とすることができる。その後、S’は、アサーションメッセージに署名するために使用することができ、OPSFは、新しい長期共有秘密K’を使用して、S’を再計算することによって、アサーションメッセージ上のシグネチャを検証することができる。別の例示的な実施形態では、アソシエーションベースモードにおいて、新しい秘密の長期秘密K’が確立された場合、RPは、アソシエーションのために保存された旧い秘密Sを依然として有することがある。アソシエーションがまだ有効であり、RPがOPSFとのアソシエーションステップに係わらない場合、RPは、旧いアソシエーションハンドルAを直接的に使用することがあり、OPからのアサーションメッセージが、すでに保存された秘密Sを使用して署名されていることを期待することがある。しかし、OpenID仕様は、OPが、パラメータopenid.invalidate_handleをアサーションメッセージに含めることを可能にする。このパラメータが使用され、旧いアソシエーションハンドルAに設定された場合、ステートレスシナリオにおけるように、シグネチャ検証のために、RPを強制的にOPに戻らせることができる。これは、長期共有秘密が、新しいK’であり、シグネチャ秘密が、新たに生成されたアソシエーションハンドルA’を使用した、新しいS’=fA’,K’である場合にAに設定される、このパラメータを、SCWSに関連付けられたOPが含むことを可能にすることができる。これは、RPにおいてハンドルを無効化することができ、RPは、シグネチャ検証のために、OPSFとコンタクトを取ることができる。OPSFは、鍵交換のせいで、すでにK’を有していることができ、したがって、S’=fA’,K’を計算することができ、アサーションメッセージ上のシグネチャを検証することができる。しかし、RPが、OPSFとの新しいアソシエーションセッションに係わる場合、OPSFも、ハンドルAを無効化することができ、新しい鍵K’を使用して、RPとともに新しいペアA’,S’を確立することができる。4.4.2.6.4.2Kについてのハッシュチェインコミットメント例示的な一実施形態では、OPSFとSCWSに関連付けられたOPとは、長期秘密Kを定期的に変更することを望むことがある。秘密Kに基づいて、両方のエンティティは、チェインをもたらす以下の方法で、暗号的に安全なハッシュ関数hをKに適用することによって、すなわち、K0=hK、K1=hK0=hhK、...、Kn=hKn-1=hnKによって、ハッシュチェインコミットメントhash-chaincommitmentを実行することができる。初期秘密Kが安全に確立できる場合、OPとOPSFは、このチェインを独立に計算することができる。その場合、使用される最初の共有秘密は、Knとすることができる。ハッシュチェインを構築するのに使用されるハッシュ関数の一方向性を考えると、この値は、攻撃者が、以降の共有秘密Kn-1を直接的に計算することを可能にし得ない。攻撃者は、次の秘密を得るために、ハッシュ関数を逆転させなければならない。秘密は、OPSFとローカルOPによって、ハッシュチェインの逆順に使用される。セキュリティをさらに改善するために、OPSFとローカルOPによる現在の値の廃棄と次の値の計算である、ハッシュチェイン内の次の値への移行は、いくつかの方針に従うことができ、例えば、毎月、毎日、セッション毎などに実行することができる。4.4.2.6.5AKAAVおよび秘密の再利用、AKA資格証明書からのハッシュチェインの構築例示的な一実施形態では、OPSFは、MNOにおいてネットワーク機能と共存することができ、ネットワーク機能は、OPSFが、HLRホームロケーションレジスタ、およびMNOのAuC認証センタから、AKA認証ベクトルAV:AuthenticationVectorを取り出すことを可能にすることができる。OPSFは、AVを取り出すことができ、SCWSに関連付けられたOPを誰何するために、それらの1つを選択することができる。このAVを使用することによって、OPSFとSCWSに関連付けられたOPとは、共有秘密CKを確立することができ、その後、共有秘密CKは、OpenIDのための長期共有秘密Kとして使用することができる。別の例示的な実施形態では、長期秘密を確立する代わりに、OPとOPSFは、ハッシュチェインに対するコミットメントを確立することができ、その値は、OPSFとSCWSに関連付けられたOPとの間の共有秘密として使用される。これは、長期共有秘密を確立するための安全な方法とすることができる。4.4.2.7改良の利点の要点本セクションは、特にこの改良された変形において、SCWS上のOPによって提供され得る、利点を明瞭化することを意図している。4.4.2.7.1標準的なOpenID図29は、標準的なOpenIDプロトコルフローを示している。例えば、myopenid.comなどの既存のウェブベースのOpenIDOPサーバを使用して、モバイルデバイスからRPにアクセスするために、標準的なOpenIDプロトコル実行が使用される。図29に示されるように、ローカルトラフィックは存在せず、エアネットワークからオフロードされるトラフィックは、発見プロセスと、RPとOPの間のアソシエーション確立である。OPはウェブサービスであるので、ユーザ/ブラウザ/デバイスとOPの間のすべての通信は、エアインタフェースを介する。965および975において、無線通信が発生し、無線通信は、一般にはデータトラフィック例えば、HTTP、IPベースの通信として、MNO/エアネットワーク上で実施され、MNOネットワークにかかる負荷を表す。970において、トラフィックは、有線インターネット上で発生し、既存のインフラストラクチャを使用することができる。4.4.2.7.2OpenID/GBA図30は、OpenID/GBAのためのトラフィックフローを示している。この図は、文献の13ページにある図4-41.1から引用されている例えば、非特許文献2参照。図30に示されるように、RPとMNOの間のアソシエーションステップにも係わらず、すべての通信は、エアネットワークを介して行われる。例えば、980および985における信号は、MNO/エアネットワークを介してデータトラフィックとして実施される、無線通信を介し、MNOネットワークにかかる負荷を表す。ウェブベースのOPと比較して、OpenID/GBAでは、トラフィックがさらに増加するが、それは、認証のために追加のステップが必要とされるからであり、そのことが、エアデータネットワークばかりでなく、GBA認証のために必要とされるバックエンドサービス、すなわちBSFおよびNAFサブシステムにも負担をかける。したがって、エアネットワークトラフィックの増加と、ネットワークエンティティにおける負荷の増加が存在する。4.4.2.7.3簡略化されたアソシエーションベース通信図31は、アソシエーションベース通信モードのためのプロトコルフローの例示的な一実施形態を示している。図30に示されるように、無線トラフィックは、エアインタフェースネットワークトラフィックが減少するように、ローカルデバイスにオフロードすることができる。これを行うことで、例えば、認証トラフィックがローカルになることを可能にすることができ、その結果、認証トラフィックは、エアインタフェースネットワークまたはネットワークサービスにかかる負担を最小化する。加えて、発見および/またはアソシエーショントラフィックは、エアインタフェースネットワークを介して発生しなくてもよく、有線公衆インターネット上で行うことができる。990において、ユーザは、ブラウザなどのユーザインタフェースと対話することができ、RPを訪れることができ、OpenIDを使用してログインを要求することができる。995において、RPとOPMNOは、OpenIDアイデンティティに基づいて、OPサーバの発見を実行することができる。1000において、RPは、アソシエーション要求をOPに送信することができる。OPは、ランダムで一意的なアソシエーションハンドルAを生成することができ、鍵Sを計算することができる。OPは、アソシエーション応答をRPに送信することができる。アソシエーション応答は、アソシエーションハンドルAと、鍵Sとを含むことができる。RPは、鍵SとアソシエーションハンドルAを保存することができる。1005において、RPは、リダイレクトをブラウザに送信することができる。リダイレクトは、ブラウザをOPにリダイレクトすることができ、要求パラメータにアソシエーションハンドルAを含めることができる。OPは、SCWSに関連付けることができる。ブラウザは、リダイレクトを受信することができ、SCWSにマッピングするように変更されたローカルDNSルックアップを実行することができる。1010において、ブラウザは、認証のためのローカル要求をOPに送信することができる。1015において、認証をローカルに行うことができる。例えば、1020において、OPは、長期共有秘密鍵KとアソシエーションハンドルAに基づいて、資格証明書を検証することができる。加えて、OPは、鍵Sを計算することができ、鍵Sを使用して、シグネチャを計算することができる。シグネチャは、アサーションメッセージに署名するために、ならびに/または戻りURL、アイデンティティ、および/もしくはモードなどのパラメータに署名するために使用することができる。1025において、OPは、RPを訪れるようにブラウザに命令することができるリダイレクトを、ブラウザに送信することができる。リダイレクトは、アソシエーションハンドルAと、署名されたパラメータとを含むことができる。1030において、ブラウザは、OPからの署名されたアサーションメッセージを含むことができる要求を、RPに送信することができる。RPは、鍵Sを使用して、アサーションメッセージ上のシグネチャを検証することができる。その後、1035において、RPは、ブラウザが、ログインページを表示することを可能にすることができ、サービスへのアクセスをブラウザに提供することができる。例示的な一実施形態では、SCWSに関連付けられたOPとMNOとの間に長期共有鍵が存在すると仮定することができる。図31に示されるように、1010、1015、1020、および1025は、MNO/エアネットワークに負荷をかけ得ないローカル通信を表す。加えて、これらの通信は、デバイス内部で起こり得るので、他の有線または非MNOネットワーク上でのトラフィックを伴わずに、行うことができる。990、1005、1030、および1035は、無線通信を表し、無線通信は、データトラフィック例えば、HTTP、IPベースの通信として、MNO/エアネットワーク上で実施することができ、MNOネットワークにかかる負荷を表すことができる。995および1000は、有線インターネットなどの有線上で発生でき、既存のインフラストラクチャを使用できる、トラフィックを表す。この通信は、MNO/エアインタフェースネットワークにかかる負荷を増加させ得ない。図32は、アソシエーションベース通信モードのためのプロトコルフローの別の例示的な実施形態を示している。図32に示されるように、無線トラフィックは、エアインタフェースネットワークトラフィックが減少するように、ローカルデバイスにオフロードすることができる。これを行うことで、例えば、認証トラフィックがローカルになることを可能にすることができ、その結果、認証トラフィックは、エアインタフェースネットワークまたはネットワークサービスにかかる負担を最小化する。加えて、発見および/またはアソシエーショントラフィックは、エアインタフェースネットワークを介して発生しなくてもよく、有線公衆インターネット上で行うことができる。1040において、ユーザは、ブラウザなどのユーザインタフェースと対話することができ、RPを訪れることができ、OpenIDを使用してログインを要求することができる。1045において、ブラウザは、OpenIDアイデンティティURLを含むことができるHTTPメッセージを、RPに送信することができる。1050において、RPとOPMNOは、OpenIDアイデンティティに基づいて、OPサーバの発見を実行することができる。例えば、RPは、HTTPSGETアイデンティティページメッセージをOPに送信することができ、OPは、OpenIDIDPサーバアドレスによって応答することができる。1055において、RPは、アソシエーション要求をOPに送信することができる。例えば、RPは、HTTPSPOSTをOPに送信することができる。OPは、ランダムで一意的なアソシエーションハンドルAを生成することができ、秘密Sを計算することができる。OPは、アソシエーション応答をRPに送信することができる。例えば、OPは、HTTPSPOSTをRPに送信することができる。アソシエーション応答は、アソシエーションハンドルAと、秘密Sとを含むことができる。RPは、秘密SとアソシエーションハンドルAを保存することができる。RPは、ノンスおよびセッション識別子を生成することができる。1060において、RPは、リダイレクトをブラウザに送信することができる。例えば、RPは、HTTPREDIRECTをブラウザに送信することができる。リダイレクトは、ブラウザをOPにリダイレクトすることができ、要求パラメータにアソシエーションハンドルAを含むことができる。OPは、SCWSに関連付けることができる。ブラウザは、リダイレクトを受信することができ、SCWSにマッピングするように変更されたローカルDNSルックアップを実行することができる。1065において、ブラウザは、認証のためのローカル要求をOPに送信することができる。例えば、ブラウザは、リダイレクトに含まれるパラメータを含むことができる、HTTPGEThttp://op.org/server.cgiをOPに送信することができる。1070において、認証をローカルに行うことができる。ブラウザは、ユーザ認証用資格証明書を要求する認証ページを、ユーザに提示することができる。ユーザは、ユーザ名およびパスワードを含むことができる、認証用資格証明書を入力することができる。1075において、OPは、長期共有秘密鍵KとアソシエーションハンドルAに基づいて、資格証明書を検証することができる。加えて、OPは、秘密Sを計算することができ、Sを使用して、シグネチャを計算することができる。シグネチャは、アサーションメッセージに署名するために、ならびに/または戻りURL、アイデンティティ、および/もしくはモードなどのパラメータに署名するために使用することができる。1080において、OPは、RPを訪れるようにブラウザに命令することができるリダイレクトを、ブラウザに送信することができる。例えば、OPは、HTTPREDIRECTをRPに送信することができる。リダイレクトは、アソシエーションハンドルAと、署名されたパラメータとを含むことができる。1085において、ブラウザは、OPからの署名されたアサーションメッセージと、OPによって提供されたパラメータとを含むことができる要求を、RPに送信することができる。例えば、ブラウザは、HTTPGEThttp://rp.org/return.cgiを、RPに送信することができる。RPは、秘密Sを使用して、アサーションメッセージ上のシグネチャを検証することができる。その後、1090において、RPは、ブラウザがログインページを表示することを可能にすることができ、サービスへのアクセスをブラウザに提供することができる。例えば、RPは、HTMLページを表示するように、ブラウザに命令することができる。1095において、ブラウザは、ユーザがRPにおいてログインしたことを、ユーザに通知する。例示的な一実施形態では、SCWSに関連付けられたOPとMNOとの間に長期共有鍵が存在すると仮定することができる。図32に示されるように、1040、1065、1070、1080、および1095は、MNO/エアネットワークに負荷をかけ得ないローカル通信を表す。加えて、これらの通信は、デバイス内部で起こり得るので、他の有線または非MNOネットワーク上でのトラフィックを伴わずに、行うことができる。1045、1060、1085、および1090は、無線通信を表し、無線通信は、データトラフィック例えば、HTTP、IPベースの通信として、MNO/エアネットワーク上で実施することができ、MNOネットワークにかかる負荷を表すことができる。1050および1055は、有線インターネットなどの有線上で発生でき、既存のインフラストラクチャを使用できる、トラフィックを表す。この通信は、MNO/エアインタフェースネットワークにかかる負荷を増加させ得ない。図33は、アソシエーションベース通信モードのためのプロトコルフローの別の例示的な実施形態を示している。図33に示されるように、無線トラフィックは、エアインタフェースネットワークトラフィックが減少するように、ローカルデバイスにオフロードすることができる。これを行うことで、例えば、認証トラフィックがローカルになることを可能にすることができ、その結果、認証トラフィックは、エアインタフェースネットワークまたはネットワークサービスにかかる負担を最小化する。加えて、発見および/またはアソシエーショントラフィックは、エアインタフェースネットワークを介して発生しなくてもよく、有線公衆インターネット上で行うことができる。1100において、ユーザは、ブラウザなどのユーザインタフェースと対話することができ、RPを訪れることができ、OpenIDを使用してログインを要求することができる。1105において、ブラウザは、OpenIDアイデンティティURLを含むことができるHTTPメッセージを、RPに送信することができる。1110において、RPとOPMNOは、OpenIDアイデンティティに基づいて、OPサーバの発見を実行することができる。例えば、RPは、HTTPSGETアイデンティティページメッセージをOPに送信することができ、OPは、OpenIDIDPサーバアドレスによって応答することができる。1115において、RPは、アソシエーション要求をOPに送信することができる。例えば、RPは、HTTPSPOSTをOPに送信することができる。OPは、ランダムで一意的なアソシエーションハンドルAを生成することができ、秘密Sを計算することができる。OPは、アソシエーション応答をRPに送信することができる。例えば、OPは、HTTPSPOSTをRPに送信することができる。アソシエーション応答は、アソシエーションハンドルAと、秘密Sとを含むことができる。RPは、秘密SとアソシエーションハンドルAを保存することができる。RPは、ノンスおよびセッション識別子を生成することができる。1120において、RPは、リダイレクトをブラウザに送信することができる。例えば、RPは、HTTPREDIRECTをブラウザに送信することができる。リダイレクトは、ブラウザをOPにリダイレクトすることができ、要求パラメータにアソシエーションハンドルAを含むことができる。OPは、SCWSに関連付けることができる。ブラウザは、リダイレクトを受信することができ、SCWSにマッピングするように変更されたローカルDNSルックアップを実行することができる。1125において、ブラウザは、認証のためのローカル要求をOPに送信することができる。例えば、ブラウザは、リダイレクトに含まれるパラメータを含むことができる、HTTPGEThttp://op.org/server.cgiをOPに送信することができる。1130において、認証をローカルに行うことができる。ブラウザは、ユーザ認証用資格証明書を要求する認証ページを、ユーザに提示することができる。ユーザは、ユーザ名およびパスワードを含むことができる、認証用資格証明書を入力することができる。1135において、OPは、長期共有秘密鍵KとアソシエーションハンドルAに基づいて、資格証明書を検証することができる。加えて、OPは、秘密Sを計算することができ、Sを使用して、シグネチャを計算することができる。シグネチャは、アサーションメッセージに署名するために、ならびに/または戻りURL、アイデンティティ、および/もしくはモードなどのパラメータに署名するために使用することができる。1140において、OPは、RPを訪れるようにブラウザに命令することができるリダイレクトを、ブラウザに送信することができる。例えば、OPは、HTTPREDIRECTをRPに送信することができる。リダイレクトは、アソシエーションハンドルAと、署名されたパラメータとを含むことができる。1145において、ブラウザは、OPからの署名されたアサーションメッセージと、OPによって提供されたパラメータとを含むことができる要求を、RPに送信することができる。例えば、ブラウザは、HTTPGEThttp://rp.org/return.cgiを、RPに送信することができる。RPは、秘密Sを使用して、アサーションメッセージ上のシグネチャを検証することができる。その後、1150において、RPは、ブラウザがログインページを表示することを可能にすることができ、ブラウザにサービスへのアクセスを提供することができる。例えば、RPは、HTMLページを表示するように、ブラウザに命令することができる。1155において、ブラウザは、ユーザがRPにおいてログインしたことを、ユーザに通知する。例示的な一実施形態では、SCWSに関連付けられたOPとMNOとの間に長期共有鍵が存在すると仮定することができる。図33に示されるように、1100、1125、1130、1140、および1155は、MNO/エアネットワークに負荷をかけ得ないローカル通信を表す。加えて、これらの通信は、デバイス内部で起こり得るので、他の有線または非MNOネットワーク上でのトラフィックを伴わずに、行うことができる。1105、1120、1145、および1150は、無線通信を表し、無線通信は、データトラフィック例えば、HTTP、IPベースの通信として、MNO/エアネットワーク上で実施することができ、MNOネットワークにかかる負荷を表すことができる。1110および1115は、有線インターネットなどの有線上で発生でき、既存のインフラストラクチャを使用できる、トラフィックを表す。この通信は、MNO/エアインタフェースネットワークにかかる負荷を増加させ得ない。図34は、ステートレスモードのためのプロトコルフローの別の例示的な実施形態を示している。1160:ユーザは、RPウェブサイトを訪れ、OpenIDを使用してログインするために、例えば、http://op.org/identityなど、自らのOpenID識別子を入力する。1165:ブラウザは、OpenID識別子を含むHTTPメッセージを、RPウェブサイトに送信することができる。1170:RPは、HTTP/HTMLベースのOpenIDシンプル発見を使用することができ、公衆インターネットを介してOP-Aggとコンタクトを取り、例えば、HTTPGEThttp://op.org/identityによって、OpenID識別子のためのアイデンティティページを取り出す。1175:OP-aggは、要求を受信することができ、OPSFのインターネットアドレスを含むHTMLページによって応答することができる。例えば、OP-aggは、<linkrel=openid.serverhref=http://op.org/server.cgi>を含めることによって、応答することができる。OPSFは、RPに対して標準的なOpenIDアイデンティティプロバイダウェブサービスのように振る舞うことができる。例えば、OPSFは、RPからの要求時に、アサーションメッセージ上のローカルOPによって発行されたシグネチャを検証することができる。要件通りに、OPSFは、公衆インターネットを介して到達可能でなければならず、したがって、http://op.orgによって到達可能な、例えばop.orgなどの、DNS名を有すると仮定される。外部世界は、スマートカードのIPアドレスを知ることができないので、このインダイレクションOP-aggおよびOPSFを、通信のために使用することができる。OPSFのアドレスは、OP-aggのアドレスと異なることがある。1180:RPは、OPSFのアドレスを受信することができ、例えば、nonce=123123、session=Userなどと、ノンスおよびセッション識別子を生成する。RPは、ユーザ認証後にブラウザをどのURLにリダイレクトすべきかをOPに命じる、戻り先パラメータを編集することができる。RPは、以下のパラメータを含む、ブラウザをOPサーバアドレスにリダイレクトする、HTTPリダイレクトを発行することができる。openid.mode=checkid_setup、openid.identity=http://op.org/identity、openid.return_to=http://rp.org/return.cgisession=Usernonce=1231231185:ブラウザは、リダイレクトを受信することができ、リダイレクトメッセージ内のRPによって指定されたURLへの接続をオープンすることができる。1190:例えば、エントリhttp://op.org==127.0.0.1を有するホストファイルを使用することによって、OPSFのURLをSCWSローカルIPアドレスにマッピングする、変更されたローカルDNSルックアップテーブルを用いる場合、ブラウザは、SCWSに関連付けられたローカルOPにリダイレクトすることができ、765のパラメータを含むHTTP要求を発行する。変更されたローカルDNSルックアップテーブルは、デバイス上に存在することができ、URLhttp://op.orgがSCWSのローカルIPアドレスにあるとデバイスに思わせる。ブラウザは、公衆インターネットを介して到達可能な、URLhttp://op.orgにあるOPSFに接続する代わりに、SCWS/ローカルOPへの接続をオープンすることができる。1195:以下は、認証トラフィックをローカルに保つことを保証するために実行することができるが、これらのステップは、必須ではなく、OpenIDプロトコル仕様によって規定されていない。a.SCWSに関連付けられたOPは、ローカル認証ページを表示することができる。b.ユーザは、例えば、ユーザ名およびパスワードなど、自分の認証用資格証明書を入力することができる。c.SCWSに関連付けられたOPは、資格証明書を検証することができる。1200:SCWSに関連付けられたOPは、一意的でランダムなアソシエーションハンドルAを生成することができる。関数fを使用すると、アサーションメッセージのための署名秘密を、S=fA,Kによって計算することができ、ここで、fは、Aの知識がKについてのいかなる知識も明かさないように、一方向とすべきである。例示的な一実施形態では、fは、SおよびAが明かされたとしても、Kについてのいかなる知識も明かすことはできず、すなわち、SおよびAが与えられた場合、ある関数gについて、K=gS,Kを計算することが、計算的に実行不可能であるべきである。Aは、リダイレクトメッセージ内のパラメータの一部として、RPに明かすことができるので、OpenIDプロトコル実行のステートレスモードでは、RPがSの知識を獲得しないと仮定することができる。アソシエーションハンドルAは、リダイレクトメッセージに含めることができる。加えて、Sを使用して署名された署名済メッセージmを与えても、シグネチャの検証者には、Kについてのいかなる情報も明かされ得ないと仮定することができる対称鍵シグネチャが使用されるので、シグネチャの検証者は、シグネチャを検証するために、常にSを所有していることが必要であり、したがって、シグネチャがSを明かさないことを必要としない。例示的な一実施形態では、アソシエーションハンドルは、長さが255文字以下の文字列であると規定することができ、33と126を含む33~126の範囲のASCII文字印刷可能な非空白文字のみから成ることができる。シグネチャを検証するためにOPSFによって使用される秘密は、シグネチャを生成するためにSCWSに関連付けられたOPによって使用される秘密と同じとすることができる。シグネチャの新しさは、次のステップで挿入されるRPノンスによって保証することができ、RPノンスは、シグネチャの一部であることが要求される。OpenID仕様は、署名秘密自体の新しさについては何もいわないままである。秘密の暗号強度を保証すること、秘密の秘密性を維持すること、およびそれが必要な場合は、秘密の新しさを保証することは、OPの責任とすることができる。OPSF、またはSCWSに関連付けられたOPは、この目的のために、署名秘密に対して、限られた存続期間または使用カウントを実施することができる。ツールキット対応のローカルOPは、SCWSをバイパスして、ハンドセットとプロアクティブに通信するために、CATを使用することができる。メッセージは、例えば、SMS-PPベアラを介してOPSFに送信するために標準的なOTA通りにフォーマットすることができる。これは、OPSFが、MNOのOTAシステムを介して、カードと通信することを必要とすることがある。別の例示的な実施形態では、BIPゲートウェイが、ツールキットメッセージのペイロードを抽出することができ、ハンドセットが、TCP/IPを使用して、それをOPSFに送信することができる。これも、メッセージがMNOのOTAサーバを通過することを必要とすることがある。加えて、SCWSは、カードがIPアドレスを有せず、TCP/IPをサポートしない場合に限って、BIPを使用すべきであることを命じる。そのため、TCP/IPを使用したSCWSを介する送信が、期待されることであることがある。d.SCWSに関連付けられたOPとOPSFとの間の共有秘密をもたらさなければならないことがある、さらなるオプションも適用することができる。そのような方法の実現可能性は、さらなる研究課題である。1205:SCWSに関連付けられたOPは、戻り先、アイデンティティ、およびモードなどのパラメータに対するシグネチャを計算することができる。1210:SCWSに関連付けられたOPは、1180においてRPから受信したパラメータを含む、HTTPリダイレクトメッセージをブラウザに送信することができる。追加的に、以下のものも、すなわち、●openid.signedパラメータ内の署名されたパラメータのリスト、●openid.assoc_handleパラメータ内のアソシエーションハンドルA、および●openid.sigパラメータ内のシグネチャbase64符号化も含むことができる。1212において、このメッセージは、ブラウザをRPの戻り先URLにリダイレクトするために使用することができる。1215:ブラウザは、ユーザをRPの戻り先URLにリダイレクトすることができる。1220:RPは、署名されたアサーションメッセージを受信することができ、HTTPSベースの公衆インターネットを介する直接通信によって、OPSFとともに検証手順に携わる。1225:RPは、795のSCWSに関連付けられたOPから受信したパラメータを含む、HTTPPOSTメッセージを発行することができる。HTTPPostメッセージは、SCWSに関連付けられたOPによって生成された、アソシエーションハンドルAを含むことができる。1230:OPSFは、パラメータリストからAを抽出することができ、同じ入力を有する、SCWSに関連付けられたOPと同じ関数fを使用することができ、すなわち、OPSFは、fA,K=Sを計算し、Sを共有鍵として使用して、SCWSに関連付けられたOPから受信したデータ上のシグネチャを検証する。1235:OPSFは、シグネチャ検証が成功した場合、is_valid:trueを返すことができる。1240:RPからは、ユーザは、今ではhttp://op.org/identityとして識別することができる。1245:ブラウザは、RPのHTMLページを表示することができる。1250:ユーザは、http://op.org/identityとして、RPにおいてログインすることができる。図34に示されるように、1160、1190、1212、1215、および1250は、MNO/エアネットワークに負荷をかけ得ないローカル通信を表す。加えて、これらの通信は、デバイス内部で起こり得るので、他の有線または非MNOネットワーク上でのトラフィックを伴わずに、行うことができる。1165、1180、1220、および1245は、無線通信を表し、無線通信は、データトラフィック例えば、HTTP、IPベースの通信として、MNO/エアネットワーク上で実施することができ、MNOネットワークにかかる負荷を表すことができる。1170、1175、1225、および1235は、有線インターネットなどの有線上で発生でき、既存のインフラストラクチャを使用できる、トラフィックを表す。この通信は、MNO/エアインタフェースネットワークにかかる負荷を増加させ得ない。4.5シナリオおよび用途本セクションでは、これまでのセクションで説明された方法およびプロトコルの追加的な実施形態について説明する。例えば、本セクションでは、異なるシナリオのいくつかを明示的に列挙し、使用事例およびシナリオの範囲を広げることによって、一般化も拡張する。スマートカードSCという用語は、安全な動作機構を提供できる任意のタイプの集積回路カードICCを述べるために使用することができる。例えばGSM/UMTSなどネットワーク認証用資格証明書を保持するためにSCを使用できる、モバイルデバイスにおける特定の使用では、UICCと呼ばれることがある。オープンモバイルアライアンスOMA:OpenMobileAllianceによって定義された、スマートカードウェブサーバSCWSアプリケーションは、UICCにおける使用に限定されず、他の任意のスマートカードにおいて利用可能であると仮定することができる。したがって、安全な要素内に存在するOPエンティティを用いる、OpenIDを使用するローカルユーザ認証のための実施形態など、本明細書で説明される実施形態は、一般的なSCに容易に拡張することができる。加えて、類似のインタフェースおよび保護された実行をセキュリティ重視の方法に提供できる、他の任意の安全な環境も、上で説明された実施形態のための実施対象とすることができる。4.5.1利害関係者モデル4.5.1.1MNOモデル例示的な一実施形態では、MNOは、完全なアイデンティティプロバイダとしての役割を果たすことができる。MNOは、ウェブサービスとしてのOP-aggならびにOPSF発見およびアソシエーションポイントエンティティをホストすることができ、ユーザアイデンティティとともに、OPアプリケーションをUICCに提供することもできる。4.5.1.2サードパーティOPおよびMNO例示的な一実施形態では、ユーザは、myopenid.comなどのサードパーティOPに登録された、既存のOpenID識別子をすでに有すると仮定することができる。これは、サードパーティOP3OPと呼ばれることがある。MNOは、ユーザに対してもはやサービスプロバイダの役割を果たすことはできないが、データをトランスポートすることはでき、3OPが、UICC上にOPアプリケーションをインストールし、それをSCWSアプリケーションと関連付けることを可能にする。3OPは、MNOとビジネス関係を確立しなければならないことがある。MNOは、OPアプリケーションに対する3OPのリモート管理権を許諾することもできる。MNOは、そのサービスに対する対価を3OPに請求し、収入を得ることができる。以下では、グローバルプラットフォームGP準拠のカードの使用に関して、さらに詳細に説明する。4.5.1.3非MNO、非モバイル例示的な一実施形態を、非モバイルシナリオにおいて使用することができる。例えば、銀行によって発行されるSCなどの、汎用SCは、OPアプリケーションをインストールするために、OpenIDアイデンティティプロバイダによって使用することができる。これは、例えば、NFC発券アプリケーションおよびOpenID認証OPアプリケーションをホストできる、銀行カードを利用するために行うことができる。SCが通信するデバイスのタイプについて事前知識がないと仮定することができる。しかし、現在のSC仕様を考えると、例えば、ローカルリンク、SCリーダ、NFC通信インタフェースなどを介して、SCへのUSBを介するTCP/IP接続を確立することが可能なことがある。SCは、外部端末によって到達可能な、SCWSを備えることができる。4.5.2分割端末シナリオ本セクションでは、SCWSおよびOPアプリケーションをホストするSCを含むデバイスが、RPウェブサイトにアクセスすることを望むデバイスと同じでないことがある、実施形態について説明する。これらの実施形態では、SCは、外部認証トークンとして使用することができる。これらの分割端末実施形態は、本明細書で説明される異なる利害関係者モデルと組み合わせることができる。4.5.2.1モバイルデバイス内のUICCを用いる分割端末図34は、分割端末のためのプロトコルフローの例示的な一実施形態を示している。例示的な一実施形態では、ユーザは、SCWSおよびOPがインストールされたUICCを備える、モバイルデバイスを所有することができる。ユーザは、ブラウジングエージェントBAと呼ばれることがある、RPの所望のウェブページにアクセスするための、そのモバイルデバイスとは異なるデバイスを使用することができる。BAがRPを訪れ、ログインするためにOpenID識別子を提示した場合、RPは、BAをOPに、すなわち、OPのURLにリダイレクトすることができる。RPからBAへのHTTPリダイレクトメッセージは、必要な情報を含むことができ、必要な情報は、OPアプリケーションが、アサーションメッセージに対するシグネチャを計算するために必要とされることがある。このメッセージの内容は、モバイルと、SC上のOPに伝えることができる。OPは、モバイルデバイス上で認証ページをユーザに表示することができ、ユーザは、ログインの認可および認証を受ける。OPは、アサーションメッセージに署名することができる。その後、署名されたアサーションメッセージは、RPに返信することができ、それは、通常は、BAによって行うことができる。その後、RPは、シグネチャを検証することができ、ユーザ/BAは、RPにおいてログインする。BAとモバイルデバイスの間の通信を含む、別の例示的な実施形態では、2つのエンティティの間で、例えば、BluetoothまたはWLANを介するローカルリンクを確立し、OPをホストするデバイスとして、デバイスを登録することが可能なことがある。その後、ブラウザは、リダイレクトをOP/SCWSに転送できるローカルリンクを介して、リダイレクトをモバイルデバイスに送信することができる。その後、OPは、ユーザにユーザの資格証明書を求めることができる。ユーザは、例えば、パスワード、PIN、バイオメトリックスなどユーザ認証のために実施されるいずれかの方法を使用して、自らのモバイルデバイス上でOPから認証を受けることができる。OPは、アサーションメッセージに署名を行うことができ、そのアサーションメッセージを、ローカルリンクを介してBAに転送する。その後、BAは、このメッセージを使用して、RPから認証を受けることができる。このシナリオでは、BAは、RPとモバイルデバイスの間のMITMとしての役割を果たすことができる。ユーザは、自分がこのOpenIDセッションを開始したことを知ることができるので、自らのモバイルデバイス上で無認可の要求を検出できることがある。図35に示されるように、1255において、BAは、RPを訪れることができ、OpenIDを使用してログインを要求することができる。1260において、RPは、ログイン要求を受信することができ、OPMNOとともに、OpenIDアイデンティティに基づいて、OPサーバの発見を開始することができる。1265において、RPは、アソシエーション要求をOPMNOに送信することができ、OPMNOは、アソシエーション要求を送信することができる。アソシエーション応答は、アソシエーションハンドルAと、鍵Sとを含むことができる。1270において、RPは、ブラウザを、SCWSに関連付けられたOPにリダイレクトすることができる。RPリダイレクトは、要求パラメータにAを含めることができる。BAとユーザは、ローカルリンクを確立することができる。1275において、BAは、認証のためのローカル要求を、SCWSに関連付けられたOPに送信することができる。1280において、SCWSに関連付けられたOPとユーザ/モバイルデバイスとの間で、ローカル認証を確立することができる。1285において、SCWSに関連付けられたOPは、BAをRPにリダイレクトすることができる。ダイレクトは、アソシエーションハンドルを含むことができ、署名されたパラメータを含むことができる。1290において、BAは、要求をRPに送信することができる。要求は、SCWSに関連付けられたOPからの署名されたアサーションメッセージを含むことができる。1295において、RPは、BAが、ログインされたページを表示することを可能にすることができる。4.5.2.2外部カードリーダ/NFC内のスマートカードを用いる分割端末非モバイルSC配備の例示的な一実施形態では、SCは、ウェブベースのOPまたは別のサードパーティ例えば銀行によって、発行することができる。モバイル分割端末の場合に説明されたのと同様のステップを適用することができる。その場合、ローカルリンクの確立は、外部のスマートカードリーダを介すること、またはコンピュータに結合されたNFC近接場通信端末を介することができる。インタフェースは、SC上で実施されるOP/SCWSに送信できるHTTPメッセージをサポートすることができる。4.6OpenIDにおける信用関係4.6.1既存のOpenIDにおける信用関係図35は、OpenIDにおける信用関係を示している。4.6.1.1OpenIDプロトコルステップ1図36に示されるように、1300において、ユーザは、ログイン後にユーザがサービスにアクセスすることを可能にする、RPウェブサイトを訪れる。ユーザがOpenIDを使用してログインすることに決定した場合、ユーザは、自らのOPにリダイレクトされる。ユーザは、リダイレクトが適切に実行され、フィッシング攻撃を受けないことについて、RPを信用しなければならない。さらに、ユーザは、ログイン後にサービスを受けること、およびプライバシ上の理由でユーザとRPとの対話をRPが第三者に明かさないことについて、RPを信用する。ユーザが供給したOpenID\identifierは、RPのドメインに入り、RPのための正しいOPを発見する手段としてばかりでなく、RPとユーザの間の対話のための識別子としての役割を果たす。RPは、この識別子についての知識だけを獲得するが、それを解決することによって、RPは、OPのアドレスを知るようになる。OpenID仕様によれば、発見は、依拠当事者が、識別子を使用して、要求を開始するために必要な情報を検索発見するプロセスである。OpenID認証は、それを介して発見が行われる、3つのパスを有する。識別子がXRI、[XRI_Resolution_2.0]例えば、非特許文献15参照である場合、それは、必要な情報を含むXRDS文書を生成する。依拠当事者は、http://www.xri.netにおいてXDI.orgによって提供されるものなど、XRIプロキシリゾルバを利用できることにも留意されたい。これによって、RPがXRI解決をローカルで実行する必要がなくなる。それがURLである場合、ヤディスYadisプロトコル例えば、非特許文献16参照[Yadis]を最初に試みるべきである。それが成功した場合、結果は、やはりXRDS文書である。ヤディスプロトコルが失敗し、有効なXRDS文書が取り出せない場合、またはXRDS文書内にサービス要素OpenIDサービス要素が見つからない場合、URLを取り出し、HTMLベースの発見HTML-BasedDiscoveryを試みるべきである。発見ステップは、攻撃者にエントリポイントを提供することもできることに留意することが重要である。攻撃者は、RPを、本当のOPに代わりに、攻撃者の管理下にある偽のOPにリダイレクトする方法で、発見ステップを妨害するために、例えば、DNSスプーフィング攻撃を用いて、直接的にRPを攻撃しようと試みることができる。ホストは別のホストであるが、ドメイン名は同じであるので、RPは、それがユーザの本当のOPであるとまだ思っている。不備は、OpenIDプロトコルの設計内にあり、それに対する防御は、OpenID仕様の範囲外にあるように思える。この脅威も、トラステッドOpenID文書では、すでに捉えられており、いくつかの可能な緩和技法に対するヒントが説明されている。4.6.1.2OpenIDプロトコルステップ2図36に示されるように、1305において、RPは、ユーザのためのOPを発見すると、そのOPとアソシエーションを確立し、アソシエーションは、RPとOPが、共有鍵で保護されたチャネルを介して、安全に通信することを可能にする。ユーザ識別子は、RPドメインを出て、OPのドメインに入る。OPは、自分が、与えられた識別子を用いて、ユーザアイデンティティを実際にホストすることを認識するが、このユーザが今、どのサイトにアクセスしようと試みているかも知るようになる。共有秘密の確立が安全ではない場合標準は、MITM攻撃が可能な、ディフィ-ヘルマンを定めているだけである、OPは、ユーザがブラウザで見ているのと同じRPに自分が関連付けられていることを確信することができない。ユーザは、OPが、ユーザプロファイルを構築するために、収集した情報例えば、ユーザがどのサイトを、どれだけの頻度で訪れたかなどを使用しないことについて、OPを信用する。さらに、ユーザは、OPが、ユーザが訪れなかったサイトからのアソシエーション要求例えば、攻撃者による未知のサイトへの隠れたログインの試みを受け入れないことについて、OPを信用する。RPは、OPが、実際にユーザを認証し、ユーザのアイデンティティについての信頼できる情報をRPに提供することについて、OPを信用する。OPを介してRPサービスに対する対価の請求を実行できる、支払いシナリオでは、RPは、この請求を実行するのに必要な手段を提供することについても、OPを信用し、例えば、OpenID/GBAにおいてOPとしての役割を果たすMNOの場合、RPは、電話料金請求書によってユーザに請求を行うことを可能にする、MNOが実行しているOPとして、OPを認識する。その場合、RPは、請求が実行されることについて、MNO-OPを信用する。任意のOPを構築し、セットアップすることができるので例えば、ユーザを認証せず、したがって、スパム送信者によって悪用されて、スパムフォーラム、ブログなどに対するユニバーサルアカウントを生成するための容易なメカニズムをスパム送信者に与えることができるOPRPは、限られた1組のOPだけにアクセスを制限することを望むことがある。そのようなOPホワイトリスト/ブラックリスト手法は、OpenIDプロトコルに規定されていないが、悪徳OPから保護するために、RPにおいて実施することができる。4.6.1.3OpenIDプロトコルステップ3図36に示されるように、1310において、ユーザは、OPページにリダイレクトされ、認証を実行する。資格証明書は、ユーザドメインを出て、OPドメインに入る。したがって、ユーザとOPの間のインタフェースは、盗聴から保護されていなければならない。典型的なシナリオでは、HTTP上でのHTTPSの使用によって、小規模な保護が与えられる。しかし、ユーザが証明書チェイン全体をチェックしないことを考えると、これは、有効な証明書を用いる偽のOPに対する防御にはならない。ユーザは、OPが資格証明書を悪用しないことについて、OPを信用し、すなわち、ユーザは、OPが悪意を抱いているとは考えない。悪意あるOPは、そこに登録されたユーザに代わって、すべてのサービスに容易にアクセスすることができる。したがって、OPからの情報漏洩は、すべてのウェブサービスに対するユーザ資格証明書を直ちに暴露し、ユーザアイデンティティを危険にさらすことにつながるので、大規模なユーザベースを有する大規模なOPは、攻撃者の主要な目標になる。認証フェーズの結果として、ユーザのブラウザは、ユーザが自分の識別子の使用について認証した旨のOPからのアサーションとともに、RPにリダイレクトされる。OpenIDアイデンティティは、異なるウェブサイトへのアクセスを簡素化するための手段としてばかりでなく、複数のサイトにわたって評判を築くための手段としても、しばしば使用されるので、ユーザアイデンティティの漏洩は、特別な心配事とすることができる。したがって、識別子がひとたび悪用されると、評判の良いアイデンティティを回復することは困難かもしれない。4.6.1.4OpenIDプロトコルステップ4図36に示されるように、1315において、ユーザは、OPからのアサーションとともに、RPにリダイレクトされる。RPは、任意のタイプの認証が実行されたこと、およびユーザが識別子に関連付けられた秘密を知っていることについて、ユーザおよびOPを信用するための十分な情報を獲得する。RPは、ユーザとOPの間で使用された認証方法についてのいかなる情報および保証も獲得しない。4.6.2モバイルローカルOPにおける信用関係についての実施形態4.6.2.1全般図37は、ローカルOPとの信用関係についての例示的な一実施形態を示している。例示的な一実施形態ではOPがユーザにとってローカルエンティティになった場合、OPおよびユーザドメインは、点線1340によって識別される、単一のドメインと見なすことができる。1330において、ユーザは、認証を実行することができ、それによって、認証手順のためのネットワーク負荷を軽減することができる。ユーザは、ユーザにより多くの管理が委ねられたローカルエンティティと、プライベートデータを共有することができる。RPは、アソシエーションを構築すべき場合、ローカルOPと直接的にコンタクトを取る必要があることがある。この接続は、OpenIDプロトコルが機能するためには必要でないことがある。RPとOPの間の通信は、間接通信を介して、すなわち、ユーザのブラウザを使用したリダイレクトを介して、実行することもできる。しかし、ローカルOPに対してRPが有することのできる信用は、OPから来るアサーションから導出できる信頼できる情報の量に依存する。一般に、RPは、すべてのOPを受け入れるが、セキュリティ要件の厳しいアプリケーションでは、RPは、1組のOP、または与えられた特性を有するOPに、アクセスを制限することができる。その場合、OPは、これらの特性についての情報をRPに提供しなければならないことがある。そのような情報は、直接チャネル例えばアソシエーションチャネルを介して、または間接通信によるリダイレクトメッセージ内のアドオンを介して、ローカルOPから伝えることができる。別の例示的な実施形態では、例えば、信頼できるMNOによって発行されるOP特性についてのそのようなアサーションは、TTPから得ることができる。1325において、RPは、1305段落0572において説明されたように続行することができる。1335において、UEは、1315段落0580において説明されたように続行することができる。1320において、UEは、1300段落0565において説明されたように続行することができる。しかし、このシナリオでは、段落0582で言及されたように、ユーザは、インターネットを介した対話を行うことなく、様々な形でローカル認証を実行することができる。4.6.2.2MNOとの信用関係図38は、ローカルOPとの信用関係についての例示的な一実施形態を示している。図38に示されるように、OPはスマートカード上で動作するので、MNOは、OPと直接的な関係を有することができる。RPは、MNOと間接的な関係を有することができるが、標準に準拠したOpenIDプロトコルでは、RPとMNOは、そのような関係を確立する必要がないことがある。RPは、OPとの関係を確立する必要があることがある。例えば、MNOを介した請求、アイデンティティについての信用レベルの向上など、いくつかの理由で、RPは、ユーザのアイデンティティについての追加情報を獲得することを好むことがある。そのような信用は、RPがMNOに対して有する信用に基づくことができる。信用は、OPを介して、MNOからRPに伝えることができる。例示的な一実施形態では、RPが、例えば、MNOの評判、登録などの帯域外プロセス、サービスおよび契約上の合意によってMNOに対して一定のレベルの信用を有すると仮定することができる。加えて、必要な場合はいつでも、RPがMNOのエンティティと通信でき、この通信を適切な手段例えば、IPSEC、HTTPSによって保護できると仮定することができる。スマートカードおよびMNOのサーバが、必要に応じて異なる方法で通信するための手段を有することができると仮定することもできる。MNOは、発見プロセスに関与することができ、RPにOPの現在のアドレスを提供することによって、RPがOPとの直接通信チャネルアソシエーションを確立することを可能にする。これは、ユーザが訪れたサービスをMNOに明かすことができ、MNOがユーザの追跡プロファイルを生成することを可能にする。そのような発見は、ユーザのブラウザを介するインダイレクトが使用される場合、必要でないことがある。MNOは、OpenIDプロトコルに関与する場合、いくつかの役割を有することができる。4.6.2.2.1OPのための直接的な信用プロバイダとしてのMNO直接的な信用プロバイダとしての役割を果たすことは、MNOが、OPとRPの間における信用を構築するプロセスに直接的に関与することを意味することができる。そのような直接的な関与は、OPによってアサートされたアイデンティティがMNOに登録されていることを、RPに直ちに保証することができる。MNOが、OPのための直接的な信用プロバイダとしての役割を果たす場合、OP、RP、およびMNOの適切なサービス、または既存のサービスの組み合わせの間で、いくつかの方法を利用することができる。aRPとMNOの間の直接通信についての例示的な実施形態一例では、MNOは、RPによって到達できる、中央サービスを提供することができる。RPは、OPと直接的に関連することはできないが、MNOを介して関連することができる。ユーザのブラウザは、ローカルOPにリダイレクトすることができる。認証した後、OPは、認証が成功したことを述べるメッセージを、MNOに送信することができる。このメッセージは、MNOによってスマートカードに対して発行された鍵を用いて、署名することができる。MNOは、シグネチャを検証し、それ独自のシグネチャを追加することができ、その後、このメッセージをRPに転送する。RPは、ユーザが認証を受けたOPからのアサーションと、認証が有効なOPによって実行された旨のMNOからのメッセージの、2つのメッセージを受信することができる。これらのメッセージは、組み合わせて、認証が正常に行われた旨のアサーションをメッセージが含むような、MNOからの単一のメッセージにすることができる。bOPを介する間接通信についての例示的な実施形態例示的な一実施形態では、MNOは、そのような外部サービスをRPに提供することを望まないことがあり、通信は、OPを介して間接的に伝えることができる。信用は、依然として、MNOから来たステートメントから直接的に導出することができるが、RPとMNOの間の通信は、OPを介して行うことができる。RPは、ノンスを含む追加フィールドとともに、ブラウザをOPにリダイレクトすることができる。その後、OPは、このフィールドを要求から抽出することができ、それをMNOに転送することができる。MNOは、それに署名することができ、その後、署名された応答は、OPからRPへのアサーション回答に含めることができる。MNOは、知られたOPから受信したノンスに署名することができるので、これは、MNOからアクセスされているサービスを隠すという追加の利点を有することもできる。加入者の本当のアイデンティティをRPに明かさなければならない場合、ノンスをセッション識別子として使用することもでき、その場合、セッション識別子が、加入者を識別する。c組み合わされた方法についての例示的な実施形態例示的な一実施形態では、通信タイプを組み合わせることが可能なことがある。ユーザが、OpenIDを使用して、RPにログインすることを望む場合、RPは、MNOとコンタクトを取り、OpenIDプロトコルのアソシエーションフェーズにおいて、MNOとともに共有秘密を確立する。その場合、RPは、認証の完了時に、OPがこの秘密をアサーションメッセージに含めることを予期することができる。GBAプロトコルを使用して、MNOネットワークおよびスマートカードにおいて生成される、新たに生成された署名鍵を使用することによって署名されたステートメントを、MNOがRPに提供することは、オプションとすることができる。GBAプロトコルを用いる場合、MNOは、スマートカードとともに秘密を確立することができ、両方のエンティティは、同じステートメントに署名することができる。その後、OPは、この署名されたステートメントを、RPへのアサーションメッセージに含めることができる。RPは、MNOからの署名されたステートメントと、アサーションメッセージ内のステートメントとを比較することができる。MNOからの署名されたステートメントまたはチケットは、要求に応じて生成することができ、またはデバイスが最初にMNOから認証を受けたときに生成することができ、その後、デバイスは、これをローカルに保存する。その後、デバイスが、RPへの接続を試みる場合、先に保存された署名されたステートメントを、RPに送付することができる。OpenIDプロトコルは、OPとのアソシエーションしたがって共有秘密を確立するか、それともステートレスプロトコルフローを使用するかを、RPが決定することを可能にすることができる。OPによって、両方の動作モードをサポートすることができる。アソシエーションが使用される場合、RP毎およびOP毎に、共有秘密を確立することができる。これは、ユーザのデバイス上の、MNOとOPの間の事前共有ステートメントが、RPとMNOの間のこの新しい秘密を含まなければならないことがあることを意味する。デバイスOPとMNOの間で例えばGBAを介して事前共有できるものは、署名鍵であり、その後、署名鍵は、セッション毎に秘密/ノンスに署名するために、MNOとOPの両方によって使用され、ノンスは、RPとMNOの間で確立し、MNOによってOPに転送することができる。4.6.2.2.2OPのための間接的な信用プロバイダとしてのMNO例示的な一実施形態では、MNOは、OPのための間接的な信用プロバイダとしての役割を果たすこともできる。そのため、MNOは、OpenID認証中の通信プロセスに必ずしも関与しない。別の例示的な実施形態では、MNOは、証明書および鍵素材をスマートカードに発行することができ、その場合、OPからRPへのアサーションメッセージ内のフィールドに署名するために、それを使用することができる。その後、RPは、シグネチャおよび証明書を検証することができ、それが、OPが信頼できるMNOから得られることを、RPに保証する。証明書の検証は、MNOのさらなる関与なしに、例えば、TTPによって行うことができる。4.6.2.2.3OPのための信用およびソフトウェアプロバイダとしてのMNO例示的な一実施形態では、MNOは、OPソフトウェアパッケージをスマートカード上にリモートでダウンロードし、管理することができる。例えば、スマートカードウェブサーバSCWSなど、ソリューションによっては、この管理は、SCWSとMNOの間のHTTPS管理セッションを介して行うことができる。MNOは、信用を伝えるための秘密例えば、認定された鍵などの資格証明書を、OPによって発行されたステートメントに直接的に含めることができる。その後、RPは、認定された秘密から信用を導出することができる。MNOは、異なるユーザ識別子とともに使用するために、1組の秘密をOPソフトウェアに含めることさえできる。RPは、MNOによって発行されたOPソフトウェア証明書から信用を導出することができる。例示的な一実施形態では、GBAは、MNOが、デバイス上のOPとともに共有秘密を確立することを可能にすることができる。この秘密は、RPには知ることができないが、RPは、MNOとともに安全な通信チャネルを確立することができるので、MNOは、GBA導出の鍵を用いて署名されたOPアサーションステートメントをRPが自律的に検証できるように、このGBA導出の秘密をアソシエーションチャネルでRPに転送することができる。別の例示的な実施形態では、MNOとOPの間でGBA秘密が確立された後、MNOは、RPからのノンスおよびRPIDを尋ねることができ、その後、ノンスおよびRPIDを使用して、MNOとOPの間で、GBA秘密から、まさにこの特定のRPおよびこの特定のセッションのためのさらなる秘密を確立することができる。これは、例えば、RPとのアソシエーションのためのGBA導出の秘密を再利用すること、およびGBA導出の秘密をRPに明かすことを防止するために行うことができる。その後、MNOは、このRPとセッションに固有の秘密をRPに転送することができる。第1のオプションにおけるように、その後、RPは、このセッション固有の鍵に基づいて、アサーション上のOPシグネチャを検証することができる。4.7グローバルプラットフォームスマートカード上での実施GPSCは、複数のいわゆるセキュリティドメインSDをホストすることができ、各SDは、利害関係者を表すことができ、その利害関係者のために、鍵を保存し、アプリケーションをインストールし、カスタマイズすることができる。主なSDは、発行者SDとすることができ、発行者SDは、カード発行者に属する。SDは、階層に組織することができ、SDは、階層内のコンテンツを管理するために異なる特権を有することができる。発行者SDは、認定管理AM:AuthorizedManagement特権を有することができ、この特権は、発行者SDが、カードを自律的に管理し、その階層内においてSDをインストールでき、また削除できることを意味する。他のSDには、それらがカード上の別個の階層内に存在する場合に限って、AMを与えることができる。SDが同じ階層内に存在する場合、SDは、委任管理DM:DelegatedManagement特権を取得することができ、この特権は、SDが、そのサブ階層内においてカードコンテンツを管理することを可能にする。このSDによって実行されるすべてのアクションは、DMSDによって発行者SDに提示され、発行者SDによってチェックされるトークンによって、発行者によって認可することができる。異なるSD内に存在する、GPSC内のアプリケーションは、トラステッドパーティTPの概念を使用して、通信することができる。TPは、アプリケーションに割り当てなければならず、アプリケーションがGPオープンAPIを介してコマンドを交換することを可能にする、特権とすることができる。アプリケーションは、さもなければ、GPSC上で分離されたままである。図39は、発行者SDを有するSD階層の例示的な一実施形態を示している。図40は、DMを有するSD階層の例示的な一実施形態を示している。4.7.2実施形態についての実施オプションSC上にSCWSをどのように実施できるかに応じて、有効な異なる利害関係者モデルを利用することができる。4.7.2.1GPアプリケーションとしてのSCWSについての実施形態図41は、GPアプリケーションとしてのSCWSについての例示的な一実施形態を示している。例示的な一実施形態では、SCWSは、例えば、SC発行者によって所有されるGPアプリケーションとして、自分のSD内のアプリケーションとして実施することができ、MNOモデルおよびサードパーティOPモデル、ならびに非MNOモデルをサポートすることができる。OPのアプリケーションロジックは、異なるアプリケーションとして異なるSD内に存在でき、したがって、SCWSアプリケーションおよびドメインを所有するエンティティとは異なるエンティティによって所有および管理できると仮定する。両方のアプリケーションは、トラステッドパス機能を使用して通信することができる。サードパーティとカード発行者は、このシナリオを実施するために、例えば、正しい特権をSDおよびアプリケーションに与えるために、ビジネス関係に同意しなければならない。アプリケーションプロバイダサードパーティOPSDは、DM特権を備えることができ、OPアプリケーションを管理することができる。SCWS管理は、SCWS管理エージェントSDを介して、カード発行者によって実行することができ、SCWS管理エージェントSDは、例えば、HTTPを介するRAMなど、通常はOTA管理機能をサポートする。APSDが、SCP80プロトコルもサポートする場合、アプリケーションおよびコンテンツは、DMトークンを使用して、サードパーティによって、OTAで管理することができる。4.7.2.2ケース2:カードのランタイム環境RTEで実施されるSCWS図42は、カードのランタイム環境で実施されるSCWSについての例示的な一実施形態を示している。例示的な一実施形態では、SCWSは、SC製造業者によって、カードのRTEで実施することができるが、SCWSへのアクセスは、GPフレームワークを通して露わにされないので、サードパーティアプリケーションがSCWSと通信する方法が存在しないことがある。したがって、サードパーティOPの利害関係者モデルは、サポートされないことがある。しかし、MNOモデルおよび非モバイルモデルはサポートされる。4.8SCWS以外のプラットフォーム上でのOPの実施4.8.1プラットフォームとしてJava登録商標Cardの使用Java登録商標カード上では、異なるSIMカードおよびベンダ間でのSIMカードアプリケーションの相互運用を可能にする、Java登録商標ランタイム環境をインストールすることができる。例示的な一実施形態では、MNOがアプレットを生成し、Java登録商標カードにOTAで配備することを可能にするために、Java登録商標Cardプラットフォームを使用することができる。4.8.2組み込みセキュアエレメントを使用するための実施形態上で説明したように、ユーザに属する、または何らかのレベルのユーザ管理下にあるデバイス内に組み込まれたローカルOPアプリケーションは、スマートカード内で実施することができる。モバイルデバイス内に組み込まれるセキュリティソリューションがますます普及するのに伴い、異なるセキュリティ特性を提供する、複数の異なる実行環境が存在することがある。スマートカード上のOPの設計は、コードの安全な実行と、資格証明書の安全な保存を可能にすることができる、他の組み込みセキュリティエレメントに拡張することができる。さらに、実行環境は、特に、OP-ユーザの認証対話、HTTPSベースのOP-ブラウザ通信、ならびにやはりHTTPSベースのOP-RPアソシエーションおよびアサーションメッセージのために、外部環境への通信チャネルを提供しなければならないことがある。例示的な一実施形態では、トラステッド実行環境TEEをデバイス上のOPソフトウェアに提供するために、モバイルフォン内ですでに利用可能な既存のセキュリティ環境例えば、TrustZoneなどを利用することができる。スマートカードは、MNOの管理下にあると考えることができるので、MNOの主要な資産を表すことができる。組み込み実行環境上でのOPの実施では、特に、MNOがローカルOPとともに共有秘密を確立する実施形態では、MNOは、実行環境のセキュリティ特性を検証するための手段を必要とすることがある。そのような手段は、以下のものを含むことができるが、これらに限定されない。●実行環境の完全性測定を実行するための機能。●完全性測定を報告するための通信。●デバイスの実行環境をトラステッド実行環境TEEに変える、デバイスの実行環境の完全性検証の必要性。●MNOネットワークから組み込みTEEへの、OPのためのプロトコル/プロセスのダウンロード/プロビジョニング。●TEEの通信機能、OPは、RPおよびユーザならびにMNOと通信できなければならない。スマートカード上またはTEE内などいくつかの例示的な実施形態では、MNOは、ユーザ挙動例えば、ユーザが訪れたRP、ログイン頻度、ユーザ挙動などについての追加情報を獲得することができる。例えば、会社がユーザ挙動をMNOから隠すことを望む企業環境など、プライバシ要件の厳しいシナリオでは、MNOを深く関与させないほうが好都合なことがある。別の例示的な実施形態では、ローカルOP実施を実行するために、組み込みセキュリティ機能が使用される場合、MNOは、OpenIDプロセスに関与しないことがある。これは、ユーザが、自らのデバイスのTEE内で、OPインストールを自律的にセットアップし、管理し、維持することを可能にすることができる。そのようなシナリオでは、MNOはOP実施において信用を欠くことがあると仮定することができるので、OPがMNOと秘密を共有できる可能性が低いことがある。しかし、ユーザとユーザのデバイスの間のローカル信用関係は存在することができる。ユーザは、どのようなプライベートな個人データもサードパーティに漏れないことについて、OP実施を信用することができる。MNOはOP実施にいかなるアサーションも発行し得ないので、プライバシの向上は、OPに対するRPからの信用を低下させる代償を払ってもたらすことができる。4.8.3トラステッドOpenID革新の概念の統合例示的な一実施形態では、OPは、スマートカード上で実施することができる。デバイス完全性についての評価を含むことができ、この評価は、デバイスが完全性を測定および報告できるという要件を導入することができる。完全性検証/MNOに対する完全性報告をサポートできるデバイスの場合、MNOは、デバイスの完全性、およびOPのインストール/ランタイム環境の完全性を最初にチェックすることができる。その後、MNOは、OPソフトウェアのためのリモートソフトウェアインストール手順をトリガすることができる。さらに、MNOは、OPアプリケーションに、デバイスのための基準値を設定することができる。その後、OPは、OpenID認証中に報告された測定値を、これらの基準値と照合することができ、完全性チェックに合格した場合、認証を許可することができる。上では特徴および要素を特定の組み合わせで説明したが、各特徴または要素を単独で、または他の特徴および要素との任意の組み合わせで使用できることを当業者であれば理解されよう。加えて、本明細書で説明した方法は、コンピュータまたはプロセッサによって実行する、コンピュータ可読媒体内に包含された、コンピュータプログラム、ソフトウェア、またはファームウェアで実施することができる。コンピュータ可読媒体の例は、有線接続または無線接続を介して送信される電子信号と、コンピュータ可読記憶媒体とを含む。コンピュータ可読記憶媒体の例は、リードオンリメモリROM、ランダムアクセスメモリRAM、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、光磁気媒体、ならびにCD-ROMディスクおよびデジタル多用途ディスクDVDなどの光媒体を含むが、これらに限定されない。ソフトウェアと連携するプロセッサは、WTRU、UE、端末、基地局、RNC、または任意のホストコンピュータにおいて使用する無線周波数送受信機を実施するために使用することができる。"