(57)【特許請求の範囲】
【請求項１】
サードパーティからサービスにアクセスしようと試みるユーザの認証を可能にするユーザ機器であって、
前記サードパーティによって提供された前記サービスへのアクセスを要求するために、
プロトコルを使用して前記サードパーティと通信をし、および
アソシエーションハンドルを受信する
ように構成されたユーザインタフェースと、
プロセッサであって、
アイデンティティプロバイダとともに秘密を確立し、
前記ユーザ機器内で前記ユーザのローカル認証を実行し、
前記ユーザ認証の結果を前記サードパーティに知らせる署名されたアサーションを生成するために、前記秘密を使用するように構成されており、前記秘密は、前記サードパーティが、前記アイデンティティプロバイダから受信された鍵に基づいて、前記署名されたアサーションの真正性を検証することを可能とし、および、前記サードパーティによって提供された前記サービスにアクセスすることを前記ユーザに可能にするように構成されている、プロセッサと
を備え、
前記ユーザインタフェースは、前記署名されたアサーションおよび前記アソシエーションハンドルを前記サードパーティへ送信するようさらに構成されたことを特徴とするユーザ機器。
【請求項２】
前記ユーザインタフェースは、前記サードパーティが前記ユーザを認証することを望んでいる旨の表示を前記サードパーティから受信するようさらに構成されたことを特徴とする請求項１に記載のユーザ機器。
【請求項３】
前記ユーザインタフェースは、リダイレクションメッセージを前記サードパーティから受信するようにさらに構成され、前記リダイレクションメッセージは、前記ユーザを認証するように前記ユーザインタフェースに命令するように構成されたことを特徴とする請求項１に記載のユーザ機器。
【請求項４】
前記ユーザインタフェースは、ユーザ資格証明書を前記ユーザから受け取るようさらに構成されたことを特徴とする請求項１に記載のユーザ機器。
【請求項５】
前記プロセッサは、トラステッドコンピューティング環境であることを特徴とする請求項１に記載のユーザ機器。
【請求項６】
前記トラステッドコンピューティング環境は、前記ユーザが認証されたときに、認証応答を前記サードパーティに送信するようさらに構成されたことを特徴とする請求項５に記載のユーザ機器。
【請求項７】
前記トラステッドコンピューティング環境は、ユニバーサル集積回路カード（ＵＩＣＣ）、加入者識別モジュール（ＳＩＭ）、機器対機器（Ｍ２Ｍ）デバイス、スマートカード、ｊａｖａ（登録商標）カード、グローバルプラットフォームスマートカード、または安全な統合チップカード（ＩＣＣ）のうちの１つであることを特徴とする請求項５に記載のユーザ機器。
【請求項８】
前記トラステッドコンピューティング環境は、スマートカードウェブサーバ（ＳＣＷＳ）を使用して実施されることを特徴とする請求項５に記載のユーザ機器。
【請求項９】
前記トラステッドコンピューティング環境は、ＯｐｅｎＩＤプロバイダ（ＯＰ）と秘密を共有することを特徴とする請求項５に記載のユーザ機器。
【請求項１０】
前記トラステッドコンピューティング環境は、シグネチャを計算し、前記サードパーティが前記トラステッドコンピューティング環境の資格証明書を検証することが可能なように、前記シグネチャを、前記ユーザインタフェースを介して、前記サードパーティに提供するようさらに構成されたことを特徴とする請求項５に記載のユーザ機器。
【請求項１１】
前記トラステッドコンピューティング環境は、シグネチャを計算し、ＯｐｅｎＩＤプロバイダ（ＯＰ）が前記トラステッドコンピューティング環境の資格証明書を検証することが可能なように、前記シグネチャを、前記ユーザインタフェースを介して、前記ＯＰに提供するようさらに構成されたことを特徴とする請求項５に記載のユーザ機器。
【請求項１２】
前記トラステッドコンピューティング環境は、前記ＯＰとの前記共有秘密に基づいてシグネチャを計算し、前記サードパーティが前記トラステッドコンピューティング環境の資格証明書を検証することが可能なように、前記シグネチャを、前記ユーザインタフェースを介して、前記サードパーティに提供するようさらに構成されたことを特徴とする請求項９に記載のユーザ機器。
【請求項１３】
前記トラステッドコンピューティング環境は、前記ＯＰとの前記共有秘密に基づいてシグネチャを計算し、前記ＯＰが前記トラステッドコンピューティング環境の資格証明書を検証することが可能なように、前記シグネチャを、前記ユーザインタフェースを介して、前記ＯＰに提供するようさらに構成されたことを特徴とする請求項９に記載のユーザ機器。
【請求項１４】
前記トラステッドコンピューティング環境は、前記ユーザインタフェースを介して、ＯｐｅｎＩＤプロバイダ（ＯＰ）とともに共有秘密を確立するようさらに構成されたことを特徴とする請求項５に記載のユーザ機器。
【請求項１５】
前記ユーザインタフェースは、前記アソシエーションハンドルを含む認証要求を前記サードパーティから受信し、前記アソシエーションハンドルを前記トラステッドコンピューティング環境に提供するようさらに構成されたことを特徴とする請求項１４に記載のユーザ機器。
【請求項１６】
前記ユーザインタフェースは、前記アソシエーションハンドルを含むリダイレクトメッセージを前記トラステッドコンピューティング環境から受信し、前記アソシエーションハンドルを前記サードパーティに提供するようさらに構成されたことを特徴とする請求項１４に記載のユーザ機器。
【請求項１７】
前記トラステッドコンピューティング環境は、前記ＯＰとの前記共有秘密に基づいてシグネチャを生成し、前記シグネチャと前記アソシエーションハンドルとを含む認証応答を生成するようさらに構成されたことを特徴とする請求項１５に記載のユーザ機器。
【請求項１８】
前記ユーザインタフェースは、前記トラステッドコンピューティング環境によって生成された前記認証応答を前記サードパーティに提供するようさらに構成されたことを特徴とする請求項１７に記載のユーザ機器。
【請求項１９】
前記プロセッサは、シグネチャを生成し、シグネチャアサーションメッセージをＯｐｅｎＩＤプロバイダ（ＯＰ）から受信するようさらに構成されたことを特徴とする請求項１に記載のユーザ機器。
【請求項２０】
前記プロセッサは、シグネチャ応答メッセージを前記サードパーティに送信するようさらに構成されたことを特徴とする請求項１９に記載のユーザ機器。
【請求項２１】
前記ユーザインタフェースと前記プロセッサは、同じデバイス上に存在することを特徴とする請求項１に記載のユーザ機器。
【請求項２２】
前記ユーザインタフェースと前記プロセッサは、別々のデバイス上に存在することを特徴とする請求項１に記載のユーザ機器。
【請求項２３】
前記ユーザは、パスワード、ＰＩＮコード、バイオメトリックアイデンティティ、トークン、またはそれらの組み合わせを用いて、前記ユーザを検証することによって認証されることを特徴とする請求項１に記載のユーザ機器。
【請求項２４】
サードパーティからサービスにアクセスしようと試みるユーザを認証する方法であって、
アソシエーションハンドルを含み、前記サードパーティが前記ユーザを認証することを望んでいる旨の表示を、ユーザインタフェースを介して、前記サードパーティから受信するステップと、
アイデンティティプロバイダとともに秘密を確立するステップと、
ユーザ資格証明書を、前記ユーザインタフェースを介して、前記ユーザから受け取るステップと、
前記受信したユーザ資格証明書を用いて、前記ユーザをユーザデバイスにおいてローカルに認証するステップと、
署名されたアサーションを、前記秘密を使用して生成するステップであって、前記署名されたアサーションは、前記ユーザ認証の結果を前記サードパーティに示し、前記秘密は、前記サードパーティが、前記アイデンティティプロバイダから受信された鍵に基づいて、前記署名されたアサーションの真正性を検証することを可能にするように構成されている、生成するステップと、
前記サードパーティによって提供された前記サービスにアクセスすることを前記ユーザに許可するために、前記署名されたアサーションおよび前記アソシエーションハンドルを前記サードパーティに送信するステップと
を備えることを特徴とする方法。
【請求項２５】
前記表示は、リダイレクションメッセージであることを特徴とする請求項２４に記載の方法。
【請求項２６】
前記リダイレクションメッセージは、トラステッドコンピューティング環境を使用して前記ユーザを認証するように前記ユーザインタフェースに命令することを特徴とする請求項２５に記載の方法。
【請求項２７】
前記ユーザを認証するステップは、トラステッドコンピューティング環境を介して実行されることを特徴とする請求項２４に記載の方法。
【請求項２８】
前記トラステッドコンピューティング環境は、ユニバーサル集積回路カード（ＵＩＣＣ）、加入者識別モジュール（ＳＩＭ）、機器対機器（Ｍ２Ｍ）デバイス、スマートカードもしくはｊａｖａ（登録商標）カード、グローバルプラットフォームスマートカード、または安全な統合チップカード（ＩＣＣ）のうちの１つであることを特徴とする請求項２７に記載の方法。
【請求項２９】
前記署名されたアサーションは、前記ユーザが認証されたときに、送信されることを特徴とする請求項２４に記載の方法。
【請求項３０】
前記トラステッドコンピューティング環境を用いて前記ユーザを認証するステップは、安全なウェブサーバを使用して行われることを特徴とする請求項２７に記載の方法。
【請求項３１】
モバイルネットワーク通信事業者（ＭＮＯ）に関連付けられたオープン管理セキュリティプロバイダと共有秘密を共有するステップをさらに備えることを特徴とする請求項２４に記載の方法。
【請求項３２】
モバイルネットワーク通信事業者（ＭＮＯ）に関連付けられたＯｐｅｎＩＤプロバイダ（ＯＰ）と共有秘密を共有するステップをさらに備えることを特徴とする請求項２４に記載の方法。
【請求項３３】
シグネチャを計算するステップと、前記サードパーティが前記トラステッドコンピューティング環境の資格証明書を検証することが可能なように、前記シグネチャを、前記ユーザインタフェースを介して、前記サードパーティに提供するステップとをさらに備えることを特徴とする請求項２７に記載の方法。
【請求項３４】
前記ユーザインタフェースを介して、前記サードパーティとともに共有秘密を確立するステップをさらに備えることを特徴とする請求項３３に記載の方法。
【請求項３５】
前記共有秘密に基づいてシグネチャを生成するステップと、前記シグネチャと前記アソシエーションハンドルとを含む認証応答を生成するステップとをさらに備えることを特徴とする請求項２４に記載の方法。
【請求項３６】
シグネチャを計算するステップと、ＯｐｅｎＩＤプロバイダ（ＯＰ）が前記トラステッドコンピューティング環境の資格証明書を検証することが可能なように、前記ユーザインタフェースを介して、前記シグネチャを前記ＯＰに提供するステップとをさらに備えることを特徴とする請求項２７に記載の方法。
【請求項３７】
前記ユーザインタフェースを介して、前記ＯＰとともに共有秘密を確立するステップをさらに備えることを特徴とする請求項３６に記載の方法。
【請求項３８】
前記共有秘密に基づいてシグネチャを生成するステップと、前記シグネチャと前記アソシエーションハンドルとを含む認証応答を生成するステップとをさらに備えることを特徴とする請求項３７に記載の方法。
【請求項３９】
前記ユーザを認証するステップは、パスワード、ＰＩＮコード、バイオメトリックアイデンティティ、トークン、またはそれらの組み合わせを用いて、前記ユーザを検証することによって実行されることを特徴とする請求項２４に記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
本発明は、インターネットのユーザに対するセキュリティに関する。
【０００２】
インターネットユーザは、複数のウェブサイトにアクセスするために、ユーザ認証用に使用できる複数のユーザ名およびパスワードをしばしば有する。例えば、インターネットユーザは、Ｆａｃｅｂｏｏｋなどのソーシャルネットワーキングサイトにアクセスするために使用される１つのユーザ名／パスワードの組み合わせと、Ｇｍａｉｌなどの電子メールサイトにアクセスするために使用される別のユーザ名／パスワードの組み合わせを有することができる。複数のユーザ名／パスワードの組み合わせを有することが、ユーザ認証のために必要となり得る一方で、インターネットユーザは、ユーザ名／パスワードの各組み合わせを覚えていることを面倒だと感じることがある。例えば、インターネットユーザは、あるウェブサイト用の自分のユーザ名／パスワードの組み合わせを忘れてしまうことがあり、そのウェブサイトにアクセスすることができない。
【０００３】
ユーザ認証をインターネットユーザにとってあまり面倒なものにしないようにするために、ＯｐｅｎＩＤなどのシングルサインオン（ＳＳＯ：ｓｉｎｇｌｅ  ｓｉｇｎ−ｏｎ）ソリューションが提案された。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】３ＧＰＰ  ＴＳ  ３３．２２０
【非特許文献２】３ＧＰＰ  ＴＲ  ３３．９２４  ｖ９．１．０
【非特許文献３】ＮＩＳＴ−ＦＩＰＳ  ＰＵＢ  １９８−１
【非特許文献４】ＮＩＳＴ  Special  Publication  ８００−６３  version  1.0.1
【非特許文献５】３ＧＰＰ  ＴＲ  ３３．９２４
【非特許文献６】３ＧＰＰ  ＴＲ  ３３．９８０
【非特許文献７】３ＧＰＰ  ＴＳ１１．１１
【非特許文献８】３ＧＰＰ  ＴＳ  ３１．１１１
【非特許文献９】ＥＴＳＩ  ＴＳ  １０２  １２４
【非特許文献１０】ＭａｃＤｏｎａｌｄ他、「Ａ  Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｓｈｏｐｐｉｎｇ  Ｍａｌｌ  ｆｏｒ  Ｍｏｂｉｌｅ  Ｕｓｅｒｓ」
【非特許文献１１】ＴＳ  ３３．２５９
【非特許文献１２】３ＧＰＰ  ＴＳ  １１．１４
【非特許文献１３】Global Platform Card Specification、Version2.2、2006年3月
【非特許文献１４】ＯＰ  ｏｎ  ＳＣＷＳ  specification  draft
【非特許文献１５】Wachob，Ｇ．、Reed，Ｄ．、Chasen，Ｌ．、Ｔａｎ，Ｗ．、Ｓ．Churchill、「Extensible  Resource  Identifier（XRI）Resolution V2.0−Committee  Draft02」
【非特許文献１６】Ｍｉｌｌｅｒ，Ｊ．、「Ｙａｄｉｓ  Specification１．０」
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、ＳＳＯをウェブサービスとして実施する場合、いくつかの不都合が生じる。例えば、ユーザは、ウェブベースのＳＳＯプロバイダへの安全なチャネルを有さないことがある。加えて、ユーザは、ＳＳＯプロバイダを限定的にしか制御することができない。
【０００６】
さらに、ＳＳＯにおける認証は、無線インタフェース通信を生じさせることがあり、無線インタフェース通信では、増加したトラフィックが、ネットワークエンティティ（すなわち、ＯｐｅｎＩＤプロバイダ（ＯＰまたはＮＡＦ）とネットワーク自体の両方において、負荷を生じさせることがある。加えて、モバイルネットワーク通信事業者（ＭＮＯ：ｍｏｂｉｌｅ  ｎｅｔｗｏｒｋ  ｏｐｅｒａｔｏｒ）が、この追加のトラフィックおよび処理のコストを負担しなければならないことがある。
【課題を解決するための手段】
【０００７】
本出願では、発明者らは、スマートカード、無線スマートフォン、Ｈ（ｅ）ＮＢ、または他のタイプのデバイスなどの、トラステッド環境において、ローカルおよび分散シングルサインオン（ＳＳＯ）プロバイダを実施することを可能にするための実施形態について説明する。シングルサインオンプロバイダは、ＯｐｅｎＩＤプロバイダ、リバティアライアンス（Ｌｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅ）もしくはカンターライニシアティブ（Ｋａｎｔａｒａ  Ｉｎｉｔｉａｔｉｖｅ）に基づいたアイデンティティのプロバイダ、セキュリティアサーションマークアップ言語（ＳＡＭＬ：Ｓｅｃｕｒｉｔｙ  Ａｓｓｅｒｔｉｏｎ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）を使用するアイデンティティプロバイダ、またはオープン認証（ＯＡＵＴＨ：Ｏｐｅｎ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）プロバイダなどとすることができる。本出願は、異なるシナリオの集まりと、それらの実施オプションを提供する。説明される概念は、ＯｐｅｎＩＤプロトコルに関連したものとすることができるが、そのアイデアは、他のシングルサインオン（ＳＳＯ）プロトコルおよび／または連合アイデンティティプロトコルに拡張可能である。
【０００８】
例示的な一実施形態では、依拠当事者（ＲＰ：ｒｅｌｙｉｎｇ  ｐａｒｔｙ）がユーザを認証することを可能にするオープン管理セキュリティプロトコルを可能にするためのユーザ環境を使用することができる。ユーザ環境は、以下のものを備えることができる。
【０００９】
ＲＰによって提供されるサービスへのアクセスをユーザに代わって要求するために、シングルサインオンセキュリティプロトコルを使用して、ＲＰと通信するユーザインタフェースであって、ＲＰは、ユーザ環境の外部に存在することができ、ユーザの認証を開始するために、シングルサインオン資格証明書（ｓｉｎｇｌｅ  ｓｉｇｎ−ｏｎ  ｃｒｅｄｅｎｔｉａｌ）のトラステッドプロバイダ（ｔｒｕｓｔｅｄ  ｐｒｏｖｉｄｅｒ）と通信する、ユーザインタフェース；および
トラステッドプロバイダのために、ユーザ環境内においてユーザを認証する、トラステッドコンピューティング環境などの、プロセッサであって、認証プロセス中にユーザ環境の外部との通信を制限するために、シングルサインオン資格証明書のトラステッドプロバイダの少なくともいくつかの機能をローカルで実行するように構成されるプロセッサ。
【００１０】
別の例示的な実施形態では、ＯｐｅｎＩＤなどのオープン管理セキュリティプロトコルにおいて依拠当事者（ＲＰ）のためにユーザを認証するユーザ環境および／またはローカルアサーションエンティティ（ＬＡＥ：ｌｏｃａｌ  ａｓｓｅｒｔｉｏｎ  ｅｎｔｉｔｙ）を保護するための方法を使用することができる。方法は、以下のステップを含むことができる。
【００１１】
ＲＰがユーザを認証することを望んでいる旨のリダイレクション（ｒｅｄｉｒｅｃｔｉｏｎ）を、ユーザインタフェースを介して、ＲＰから受信するステップであって、ＲＰは、ＯｐｅｎＩＤプロバイダ（ＯＰ）などの、シングルサインオン（ＳＳＯ）資格証明書のトラステッドプロバイダと通信することが可能である、ステップ；
ユーザ資格証明書（ｕｓｅｒ  ｃｒｅｄｅｎｔｉａｌ）を、ユーザインタフェースを介して、ユーザから受け取るステップ；
受け取ったユーザ資格証明書を用いてＲＰのためにユーザを認証するステップであって、認証プロセス中にユーザ環境の外部との通信を制限するために、ＯＰなどの、ＳＳＯ資格証明書のトラステッドプロバイダの少なくともいくつかの機能をローカルで実行する、ステップ；および
認証応答を、ユーザインタフェースを介して、ＲＰに送信するステップ。
【００１２】
この「課題を解決するための手段」は、以下の「発明を実施するための形態」においてさらに説明される概念の抜粋を簡略化された形式で紹介するために提供された。この「課題を解決するための手段」は、特許請求される発明の主要な特徴または必須の特徴を識別することを意図しておらず、特許請求される発明の範囲を限定するために使用されることも意図していない。さらに、特許請求される発明は、本開示のいずれかの部分で言及されるいずれかまたはすべての不都合を解決する実施形態に限定されない。
【図面の簡単な説明】
【００１３】
【図１Ａ】図１Ａは、１つまたは複数の開示される実施形態を実施できる例示的な通信システムの図である。
【図１Ｂ】図１Ｂは、１つまたは複数の開示される実施形態を実施できる例示的な無線送受信ユニットの図である。
【図１Ｃ】図１Ｃは、１つまたは複数の開示される実施形態を実施できる例示的なシステム無線アクセスネットワークの図である。
【図２】図２は、アイデンティティプロバイダとサービスプロバイダの間で認証およびデータを交換するためのＳＡＭＬプロトコルフローを示す図である。
【図３】図３は、ユーザが単一のＯＰを使用して、異なる依拠当事者サイトにログインすることを可能にするためのＯｐｅｎＩＤプロトコルフローを示す図である。
【図４】図４は、トラステッドコンピューティング環境上の統合ＯＰを用いるＳＳＯプロトコルを提供するためのプロトコルフローの例示的な一実施形態を示す図である。
【図５】図５は、トラステッドコンピューティング環境上の統合ＯＰを用いるＳＳＯプロトコルを提供するためのプロトコルフローの例示的な一実施形態を示す図である。
【図６】図６は、アソシエーションベース通信のためのＯｐｅｎＩＤプロトコルフローを示す図である。
【図７】図７は、ステートレス（ｓｔａｔｅｌｅｓｓ）なシグネチャ検証のためのＯｐｅｎＩＤプロトコルフローを示す図である。
【図８】図８は、ＢＯＮＤＩとアソシエーションベースのＯｐｅｎＩＤとの統合についての例示的な一実施形態を示す図である。
【図９】図９は、ＢＯＮＤＩとステートレスなシグネチャ検証との統合についての例示的な一実施形態を示す図である。
【図１０】図１０は、分割ＯＰを可能にする例示的一実施形態を示す図である。
【図１１】図１１は、分割ＯＰを可能にする別の例示的実施形態を示す図である。
【図１２】図１２は、ＧＢＡアーキテクチャにおいて使用するＢＳＦ機能を示す図である。
【図１３】図１３は、ＧＢＡアーキテクチャ概要を示す図である。
【図１４】図１４は、文献から引用した（例えば、非特許文献１参照）ＧＢＡ参照モジュールを示す図である。
【図１５】図１５は、文献から引用した（例えば、非特許文献１参照）訪問先ネットワークＮＡＦのためのＧＢＡ参照モジュールを示す図である。
【図１６】図１６は、リバティ／ＧＢＡのためのアーキテクチャを示す図である。
【図１７】図１７は、ＭＮＯ支援のアイデンティティアサーションのためのＧＢＡの使用についての例示的な一実施形態を示す図である。
【図１８】図１８は、分割ＯＰを可能にする別の例示的な実施形態を示す図である。
【図１９】図１９は、分割端末／ローカルＯｐｅｎＩｄを可能にするための例示的な実施形態を示す図である。
【図２０】図２０は、標準的なＯｐｅｎＩＤプロトコルを示す図である。
【図２１】図２１は、文献から引用した（例えば、非特許文献２参照）ＯｐｅｎＩＤ／ＧＢＡのためのトラフィックフローを示す図である。
【図２２】図２２は、無線トラフィックを減少させるためのプロトコルフローの例示的な一実施形態を示す図である。
【図２３】図２３は、ＳＣＷＳ上のＯＰのための内部ルーティングについての例示的な一実施形態を示す図である。
【図２４Ａ】図２４Ａは、ＲＰがステートレスモードを使用して、ＯｐｅｎＩＤ認証を実行することを可能にするためのプロトコルフローの例示的な一実施形態を示す図である。
【図２４Ｂ】図２４Ｂは、ＲＰがステートレスモードを使用して、ＯｐｅｎＩＤ認証を実行することを可能にするためのプロトコルフローの例示的な一実施形態を示す図である。
【図２５Ａ】図２５Ａは、ＲＰがアソシエーションベースモードを使用して、ＯｐｅｎＩＤ認証を実行するのを可能にするプロトコルフローの例示的一実施形態を示す図である。
【図２５Ｂ】図２５Ｂは、ＲＰがアソシエーションベースモードを使用して、ＯｐｅｎＩＤ認証を実行するのを可能にするプロトコルフローの例示的一実施形態を示す図である。
【図２６Ａ】図２６Ａは、改良されたステートレスモードのためのプロトコルフローの例示的な一実施形態を示す図である。
【図２６Ｂ】図２６Ｂは、改良されたステートレスモードのためのプロトコルフローの例示的な一実施形態を示す図である。
【図２７Ａ】図２７Ａは、改良されたアソシエーションベースモードのためのプロトコルフローの例示的な一実施形態を示す図である。
【図２７Ｂ】図２７Ｂは、改良されたアソシエーションベースモードのためのプロトコルフローの例示的な一実施形態を示す図である。
【図２８】図２８は、文献から引用した（例えば、非特許文献３参照）鍵付きハッシュメッセージ認証コード（ＨＭＡＣ：Ｈａｓｈ  Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ）を示す図である。
【図２９】図２９は、ＯｐｅｎＩＤ／ＧＢＡのためのトラフィックフローを示す図である。
【図３０】図３０は、アソシエーションベース通信モードのためのプロトコルフローの別の例示的な実施形態を示す図である。
【図３１】図３１は、アソシエーションベース通信モードのためのプロトコルフローの別の例示的な実施形態を示す図である。
【図３２Ａ】図３２Ａは、アソシエーションベース通信モードのためのプロトコルフローの別の例示的な実施形態を示す図である。
【図３２Ｂ】図３２Ｂは、アソシエーションベース通信モードのためのプロトコルフローの別の例示的な実施形態を示す図である。
【図３３Ａ】図３３Ａは、ステートレスモードのためのプロトコルフローの別の例示的な実施形態を示す図である。
【図３３Ｂ】図３３Ｂは、ステートレスモードのためのプロトコルフローの別の例示的な実施形態を示す図である。
【図３４Ａ】図３４Ａは、分割端末のためのプロトコルフローの例示的な一実施形態を示す図である。
【図３４Ｂ】図３４Ｂは、分割端末のためのプロトコルフローの例示的な一実施形態を示す図である。
【図３５】図３５は、ＯｐｅｎＩＤにおける信用関係を示す図である。
【図３６】図３６は、ローカルＯＰとの信用関係についての例示的な一実施形態を示す図である。
【図３７】図３７は、ＭＮＯとの信用関係についての例示的な一実施形態を示す図である。
【図３８】図３８は、発行者ＳＤを有するＳＤ階層の例示的な一実施形態を示す図である。
【図３９】図３９は、ＤＭを有するＳＤ階層の例示的な一実施形態を示す図である。
【図４０】図４０は、ＤＭを有するＳＤ階層の例示的な一実施形態を示す図である。
【図４１】図４１は、ＧＰアプリケーションとしてのＳＣＷＳについての例示的な一実施形態を示す図である。
【図４２】図４２は、カードのランタイム環境で実施されるＳＣＷＳについての例示的な一実施形態を示す図である。
【発明を実施するための形態】
【００１４】
本出願では、発明者らは、ユーザ機器（ＵＥ）、スマートカード、スマートフォン、Ｈ（ｅ）ＮＢ、または他のタイプのデバイスなどの、トラステッド環境において実施される、ローカルおよび分散シングルサインオン（ＳＳＯ）プロバイダのアイデアおよび概念について説明する。シングルサインオンプロバイダは、ＯｐｅｎＩＤプロバイダ、リバティアライアンスプロバイダ、またはオープン認証（ＯＡＵＴＨ）プロバイダなどとすることができる。本出願は、異なるシナリオの集まりと、それらの実施オプションを提供する。説明される概念はＯｐｅｎＩＤプロトコルに関連したものとすることができるが、そのアイデアは、他のシングルサインオン（ＳＳＯ）プロトコルおよび／または連合アイデンティティプロトコルに拡張可能である。
【００１５】
ローカルモバイルＯｐｅｎＩＤなどの、ローカルモバイルＳＳＯプロトコルは、ローカルに配置されたモジュールまたはエンティティが、ＯｐｅｎＩＤプロトコルなどの、ＳＳＯまたはアイデンティティ管理プロトコルの一部として、アイデンティティ認証／アサーション（ａｓｓｅｒｔｉｏｎ）機能を実行することを可能にする概念である。ローカルに配置されたモジュールは、スマートカード、ＳＩＭ、ユニバーサル集積回路カード（ＵＩＣＣ）、Ｊａｖａ（登録商標）カード、スマートカードウェブサーバ（ＳＣＷＳ：ｓｍａｒｔ  ｃａｒｄ  ｗｅｂ  ｓｅｒｖｅｒ）対応のスマートカード、またはスマートフォンなどの無線デバイスとすることができる。
【００１６】
ローカルモバイルＳＳＯは、従来はウェブベースのＳＳＯサーバによって実行されたシングルサインオン（ＳＳＯ）および関連するアイデンティティ管理機能の一部もしくは全部が、通信デバイス自体の一部もしくは全部であるローカルベースのエンティティおよび／もしくはモジュールによって代わりに実行される方法、またはそのようなエンティティ／モジュールが、通信デバイスおよび／もしくはそのユーザの近傍に物理的および／もしくは論理的に配置される（すなわちローカルに配置される）方法を一括して指すために使用される用語である。例えば、エンティティ／モジュールは、デバイス内に組み込むこと、デバイスに取り付けること、またはローカルインタフェース、配線、もしくは短距離無線手段によってデバイスに接続することができる。
【００１７】
ローカルＯｐｅｎＩＤも、ＳＳＯまたはアイデンティティ管理の方法がＯｐｅｎＩＤプロトコルに基づく、ローカルモバイルＳＳＯ方法のサブセットを指す用語として使用することができる。例えば、ローカルＯｐｅｎＩＤは、ローカルに配置されたエンティティ／モジュールによって実行できる、ＯｐｅｎＩＤアイデンティティプロバイダ（省略表記ではＯＰまたはＯｐｅｎＩＤ  ＩｄＰ）の機能を指すために使用することができる。
【００１８】
ローカルＩｄＰは、ＯｐｅｎＩＤサーバの機能を実行するエンティティまたはモジュールを指すために使用される用語である。ローカルＩｄＰを表すのに、頭字語ＯＰｌｏｃを使用することができる。ローカルＩｄＰの主要な機能の１つは、ユーザおよび／またはデバイスのアイデンティティについてのアサーションを通して、ユーザおよび／またはデバイスの認証を円滑化することとすることができる。そのようなアサーションは、ローカルＩｄＰからデバイス上で動作するブラウザエージェント（ＢＡ）に送信することができ、その後、ＢＡは、アサーションを外部の依拠当事者（ＲＰ）に転送することができる。ローカルＩｄＰによって提供される機能が、主としてそのようなアイデンティティアサーションを提供することに限定される場合、ローカルＩｄＰは、ローカルアサーションエンティティ（ＬＡＥ）と呼ばれることもある。
【００１９】
ローカルＩｄＰは、アサーションメッセージを処理し、生成し、管理し、または１つもしくは複数の外部の受信先に送信することができる。アサーションメッセージは、ユーザおよび／またはデバイスに関連する１つまたは複数のアイデンティティの検証の状態をアサートすることができる。例えば、ＯｐｅｎＩＤプロトコルでは、依拠当事者（ＲＰ）と呼ばれるサードパーティエンティティを、アサーションメッセージの受信先の１つとすることができる。ローカルＩｄＰは、シグネチャ、暗号鍵、または暗号などを使用して、アサーションメッセージに署名することもできる。
【００２０】
ローカルＯｐｅｎＩＤ方法は、ルートセッション鍵など、１つまたは複数の暗号鍵を使用することができる。ルートセッション鍵は、Ｋｒｐによって表すことができ、ＲＰとＯＰの間で使用することを意図したセッション鍵とすることができる。Ｋｒｐは、他の鍵を導出できる、ＲＰとＯＰの間のルートセッション鍵としての役割を果たすこともできる。ローカルＯｐｅｎＩＤ方法は、Ｋａｓｃによって表すことができる、アサーション鍵を使用することもできる。Ｋａｓｃは、ユーザの認証のためのアサーションメッセージの１つまたは複数に署名するために使用される署名鍵とすることができる。Ｋａｓｃは、Ｋｒｐから導出することができる。
【００２１】
ローカルＯｐｅｎＩＤ方法は、ＯｐｅｎＩＤサーバ機能（ＯＰＳＦ：ＯｐｅｎＩＤ  Ｓｅｒｖｅｒ  Ｆｕｎｃｔｉｏｎ）と呼ばれるサービスを使用することもでき、ＯＰＳＦの役割は、ローカルＩｄＰおよび／または依拠当事者（ＲＰ）によって使用できる秘密を生成し、共有し、分配することとすることができる。ＯＰＳＦとローカルＩｄＰは、外部のＲＰには単一のエンティティとして見えることがある。ＯＰＳＦは、ローカルＯｐｅｎＩＤによって発行されたシグネチャを検証することもできてよく、例えば、公衆インターネットを介して、ＲＰから直接的に到達可能とすることができる。デバイス上のブラウザは、ＯＰＳＦのアドレスがローカルＩｄＰにマッピングされるように、デバイス上のローカルＤＮＳ解決キャッシュを変更することによって、ローカルＩｄＰにリダイレクトすることができる。
【００２２】
ローカルＯｐｅｎＩＤ方法は、ＯＰ−ａｇｇによって表されるサービスを使用することもでき、ＯＰ−ａｇｇの役割は、ＲＰに代わって、ローカルＩｄＰの発見を円滑化することとすることができる。
【００２３】
１  通信システム
図１Ａは、１つまたは複数の開示される実施形態を実施できる例示的な通信システム１００の図である。通信システム１００は、音声、データ、ビデオ、メッセージング、放送などのコンテンツを複数の無線ユーザに提供する、多元接続システムとすることができる。通信システム１００は、複数のユーザが、固定有線または無線通信帯域幅を含むシステムリソースの共用を通して、そのようなコンテンツにアクセスできるようにすることができる。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、およびシングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）など、１つまたは複数の固定有線または無線チャネルアクセス方法を利用することができる。
【００２４】
図１Ａに示されるように、通信システム１００は、無線送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、および他のネットワーク１１２を含むことができるが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図していることが理解されよう。ＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線または固定有線環境において動作および／または通信するように構成された任意のタイプのデバイスとすることができる。例を挙げると、ＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成することができ、ユーザ機器（ＵＥ）、移動局、固定もしくは移動加入者ユニット、ページャ、セルラ電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、および家電製品などを含むことができる。
【００２５】
通信システム１００は、基地局１１４ａおよび基地局１１４ｂも含むことができる。基地局１１４ａ、１１４ｂの各々は、ＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃ、１０２ｄの少なくとも１つと無線でインタフェースを取って、コアネットワーク１０６、インターネット１１０、および／またはネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを円滑化するように構成された、任意のタイプのデバイスとすることができる。例を挙げると、基地局１１４ａ、１１４ｂは、送受信機基地局（ＢＴＳ）、ノードＢ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、および無線ルータなどとすることができる。基地局１１４ａ、１１４ｂは各々、単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含むことができることが理解されよう。
【００２６】
基地局１１４ａは、ＲＡＮ  １０４の部分とすることができ、ＲＡＮ  １０４は、他の基地局、および／または基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどのネットワーク要素（図示されず）も含むことができる。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示されず）と呼ばれることがある特定の地理的領域内で、無線信号を送信および／または受信するように構成することができる。セルは、さらにセルセクタに分割することができる。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割することができる。したがって、一実施形態では、基地局１１４ａは、送受信機を３つ、すなわち、セルのセクタ毎に１つずつ含むことができる。別の実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を利用することができ、したがって、セルのセクタ毎に複数の送受信機を利用することができる。
【００２７】
基地局１１４ａ、１１４ｂは、エアインタフェース１１６を介して、ＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つまたは複数と通信することができ、エアインタフェース１１６は、任意の適切な無線通信リンク（例えば、無線周波（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）とすることができる。エアインタフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立することができる。
【００２８】
より具体的には、上で言及したように、通信システム１００は、多元接続システムとすることができ、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、およびＳＣ−ＦＤＭＡなどの１つまたは複数の固定有線または無線チャネルアクセス方式を利用することができる。例えば、ＲＡＮ  １０４内の基地局１１４ａ、およびＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ）を使用してエアインタフェース１１６を確立できる、ユニバーサル移動体通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実施することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含むことができる。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含むことができる。
【００２９】
別の実施形態では、基地局１１４ａ、およびＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用してエアインタフェース１１６を確立できる、進化型ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実施することができる。
【００３０】
他の実施形態では、基地局１１４ａ、およびＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ  ８０２．１６（すなわちマイクロ波アクセス用の世界的相互運用性（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００  １Ｘ、ＣＤＭＡ２０００  ＥＶ−ＤＯ、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、移動体通信用グローバルシステム（ＧＳＭ）、ＧＳＭ進化型高速データレート（ＥＤＧＥ）、およびＧＳＭ  ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実施することができる。
【００３１】
図１Ａの基地局１１４ｂは、例えば、無線ルータ、ホームノードＢ、ホームｅノードＢ、またはアクセスポイントとすることができ、職場、家庭、乗物、およびキャンパスなどの局所的エリアにおける無線接続性を円滑化するための任意の適切なＲＡＴを利用することができる。一実施形態では、基地局１１４ｂ、およびＷＴＲＵ  １０２ｃ、１０２ｄは、ＩＥＥＥ  ８０２．１１などの無線技術を実施して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立することができる。別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ  １０２ｃ、１０２ｄは、ＩＥＥＥ  ８０２．１５などの無線技術を実施して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立することができる。また別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ  １０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立することができる。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接的な接続を有することがある。したがって、基地局１１４ｂは、コアネットワーク１０６を介して、インターネット１１０にアクセスする必要がないことがある。
【００３２】
ＲＡＮ  １０４は、コアネットワーク１０６と通信することができ、コアネットワーク１０６は、音声、データ、アプリケーション、および／またはボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つまたは複数に提供するように構成された、任意のタイプのネットワークとすることができる。例えば、コアネットワーク１０６は、呼制御、請求サービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続性、ビデオ配信などを提供することができ、および／またはユーザ認証など、高レベルのセキュリティ機能を実行することができる。図１Ａには示されていないが、ＲＡＮ  １０４および／またはコアネットワーク１０６は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを利用する他のＲＡＮと直接的または間接的に通信できることが理解されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用できるＲＡＮ  １０４に接続するのに加えて、コアネットワーク１０６は、ＧＳＭ無線技術を利用する別のＲＡＮ（図示されず）と通信することもできる。
【００３３】
コアネットワーク１０６は、ＰＳＴＮ  １０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするための、ＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃ、１０２ｄのためのゲートウェイとしての役割を果たすこともできる。ＰＳＴＮ  １０８は、基本電話サービス（ＰＯＴＳ）を提供する回路交換電話網を含むことができる。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイート内の伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）など、共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークとデバイスとからなるグローバルシステムを含むことができる。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される有線または無線通信ネットワークを含むことができる。例えば、ネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを利用できる１つまたは複数のＲＡＮに接続された、別のコアネットワークを含むことができる。
【００３４】
通信システム１００内のＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃ、１０２ｄのいくつかまたはすべては、マルチモード機能を含むことができ、すなわち、ＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンクを介して異なる無線ネットワークと通信するための複数の送受信機を含むことができる。例えば、図１Ａに示されたＷＴＲＵ  １０２ｃは、セルラベースの無線技術を利用できる基地局１１４ａと通信するように、またＩＥＥＥ  ８０２無線技術を利用できる基地局１１４ｂと通信するように構成することができる。
【００３５】
図１Ｂは、例示的なＷＴＲＵ  １０２のシステム図である。図１Ｂに示されるように、ＷＴＲＵ  １０２は、プロセッサ１１８と、送受信機１２０と、送信／受信要素１２２と、スピーカ／マイクロフォン１２４と、キーパッド１２６と、ディスプレイ／タッチパッド１２８と、着脱不能メモリ１０６と、着脱可能メモリ１３２と、電源１３４と、全地球測位システム（ＧＰＳ）チップセット１３６と、他の周辺機器１３８とを含むことができる。ＷＴＲＵ  １０２は、一実施形態との整合性を保ちながら、上記の要素の任意のサブコンビネーションを含むことができる。
【００３６】
プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他の任意のタイプの集積回路（ＩＣ）、および状態機械などとすることができる。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出力処理、および／またはＷＴＲＵ  １０２が無線環境で動作できるようにする他の任意の機能を実行することができる。プロセッサ１１８は、送受信機１２０に結合することができ、送受信機１２０は、送信／受信要素１２２に結合することができる。図１Ｂは、プロセッサ１１８と送受信機１２０を別々のコンポーネントとして示しているが、プロセッサ１１８と送受信機１２０は、電子パッケージまたはチップ内に一緒に統合できることが理解されよう。
【００３７】
送信／受信要素１２２は、エアインタフェース１１６を介して、基地局（例えば基地局１１４ａ）に信号を送信し、または基地局から信号を受信するように構成することができる。例えば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナとすることができる。別の実施形態では、送信／受信要素１２２は、例えば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成された放射器／検出器とすることができる。また別の実施形態では、送信／受信要素１２２は、ＲＦ信号と光信号の両方を送信および受信するように構成することができる。送信／受信要素１２２は、無線信号の任意の組み合わせを送信および／または受信するように構成できることが理解されよう。
【００３８】
加えて、図１Ｂでは、送信／受信要素１２２は単一の要素として示されているが、ＷＴＲＵ  １０２は、任意の数の送信／受信要素１２２を含むことができる。より具体的には、ＷＴＲＵ  １０２は、ＭＩＭＯ技術を利用することができる。したがって、一実施形態では、ＷＴＲＵ  １０２は、エアインタフェース１１６を介して無線信号を送信および受信するための２つ以上の送信／受信要素１２２（例えば複数のアンテナ）を含むことができる。
【００３９】
送受信機１２０は、送信／受信要素１２２によって送信される信号を変調し、送信／受信要素１２２によって受信された信号を復調するように構成することができる。上で言及したように、ＷＴＲＵ  １０２は、マルチモード機能を有することができる。したがって、送受信機１２０は、ＷＴＲＵ  １０２が、例えばＵＴＲＡおよびＩＥＥＥ  ８０２．１１などの複数のＲＡＴを介して通信できるようにするための、複数の送受信機を含むことができる。
【００４０】
ＷＴＲＵ  １０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶表示（ＬＣＤ）ディスプレイユニットもしくは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合することができ、それらからユーザ入力データを受け取ることができる。プロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力することもできる。加えて、プロセッサ１１８は、着脱不能メモリ１０６および／または着脱可能メモリ１３２など、任意のタイプの適切なメモリから情報を入手することができ、それらにデータを記憶することができる。着脱不能メモリ１０６は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、ハードディスク、または他の任意のタイプのメモリ記憶デバイスを含むことができる。着脱可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、およびセキュアデジタル（ＳＤ）メモリカードなどを含むことができる。他の実施形態では、プロセッサ１１８は、ＷＴＲＵ  １０２上に物理的に配置されたメモリではなく、サーバまたはホームコンピュータ（図示されず）などの上に配置されたメモリから情報を入手することができ、それにデータを記憶することができる。
【００４１】
プロセッサ１１８は、アプリケーションレイヤプログラム（例えばブラウザ）、無線アクセスレイヤ（ＲＡＮ）プログラム、および／または通信プログラムを実行することができる。プロセッサ１１８は、認証などのセキュリティ動作、セキュリティ鍵合意動作、および／または暗号化動作などを実行することができる。これらの動作は、アクセスレイヤまたはアプリケーションレイヤなどにおいて実行することができる。
【００４２】
プロセッサ１１８は、電源１３４から電力を受け取ることができ、ＷＴＲＵ  １０２内の他のコンポーネントへの電力の分配および／または制御を行うように構成することができる。電源１３４は、ＷＴＲＵ  １０２に給電するための任意の適切なデバイスとすることができる。例えば、電源１３４は、１つまたは複数の乾電池（例えば、ニッケル−カドミウム（ＮｉＣｄ）、ニッケル−亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、および燃料電池などを含むことができる。
【００４３】
プロセッサ１１８は、ＧＰＳチップセット１３６に結合することもでき、ＧＰＳチップセット１３６は、ＷＴＲＵ  １０２の現在位置に関する位置情報（例えば経度および緯度）を提供するように構成することができる。ＧＰＳチップセット１３６からの情報に加えて、またはその代わりに、ＷＴＲＵ  １０２は、基地局（例えば基地局１１４ａ、１１４ｂ）からエアインタフェース１１６を介して位置情報を受け取ることができ、および／または２つ以上の近くの基地局から受信した信号のタイミングに基づいて、自らの位置を決定することができる。ＷＴＲＵ  １０２は、一実施形態との整合性を保ちながら、任意の適切な位置決定方法を用いて、位置情報を獲得できることが理解されよう。
【００４４】
プロセッサ１１８は、他の周辺機器１３８にさらに結合することができ、他の周辺機器１３８は、追加的な特徴、機能、および／または有線もしくは無線接続性を提供する、１つまたは複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含むことができる。例えば、周辺機器１３８は、加速度計、ｅコンパス、衛星送受信機、（写真またはビデオ用の）デジタルカメラ、ユニバーサルシリアルバス（ＵＳＢ）ポート、バイブレーションデバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、およびインターネットブラウザなどを含むことができる。
【００４５】
図１Ｃは、一実施形態による、ＲＡＮ  １０４およびコアネットワーク１０６のシステム図である。上で言及したように、ＲＡＮ  １０４は、Ｅ−ＵＴＲＡ無線技術を利用して、エアインタフェース１１６を介してＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃと通信することができる。ＲＡＮ  １０４は、コアネットワーク１０６と通信することもできる。
【００４６】
ＲＡＮ  １０４は、ｅノードＢ  １４０ａ、１４０ｂ、１４０ｃを含むことができるが、ＲＡＮ  １０４は、一実施形態との整合性を保ちながら、任意の数のｅノードＢを含むことができることが理解されよう。ｅノードＢ  １４０ａ、１４０ｂ、１４０ｃは、各々が、エアインタフェース１１６を介してＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数の送受信機を含むことができる。一実施形態では、ｅノードＢ  １４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯ技術を実施することができる。したがって、ｅノードＢ  １４０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ  １０２ａに無線信号を送信し、ＷＴＲＵ  １０２ａから無線信号を受信することができる。
【００４７】
ｅノードＢ  １４０ａ、１４０ｂ、１４０ｃの各々は、特定のセル（図示されず）に関連付けることができ、無線リソース管理決定、ハンドオーバ決定、ならびにアップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成することができる。図１Ｃに示されるように、ｅノードＢ  １４０ａ、１４０ｂ、１４０ｃは、Ｘ２インタフェースを介して互いに通信することができる。
【００４８】
図１Ｃに示されるコアネットワーク１０６は、モビリティ管理ゲートウェイ（ＭＭＥ）１４２、サービングゲートウェイ１４４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１４６を含むことができる。上記の要素の各々は、コアネットワーク１０６の部分として示されているが、これらの要素は、どの１つをとっても、コアネットワーク運営体とは異なる主体によって所有および／または運営できることが理解されよう。
【００４９】
ＭＭＥ  １４２は、Ｓ１インタフェースを介して、ＲＡＮ  １０４内のｅノードＢ  １４０ａ、１４０ｂ、１４０ｃの各々に接続することができ、制御ノードとしての役割を果たすことができる。例えば、ＭＭＥ  １４２は、ＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃのユーザの認証、ベアラ活動化／非活動化、ＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃの初期接続中における特定のサービングゲートウェイの選択などを担うことができる。ＭＭＥ  １４２は、ＲＡＮ  １０４とＧＳＭまたはＷＣＤＭＡなどの他の無線技術を利用する他のＲＡＮ（図示されず）との間の交換のための制御プレーン機能を提供することもできる。
【００５０】
サービングゲートウェイ１４４は、Ｓ１インタフェースを介して、ＲＡＮ  １０４内のｅノードＢ  １４０ａ、１４０ｂ、１４０ｃの各々に接続することができる。サービングゲートウェイ１４４は、一般に、ユーザデータパケットをＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃに／からルーティングおよび転送することができる。サービングゲートウェイ１４４は、ｅノードＢ間ハンドオーバ中におけるユーザプレーンのアンカリング（ａｎｃｈｏｒｉｎｇ）、ダウンリンクデータがＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃに利用可能な場合に行う一斉呼出のトリガ、ならびにＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃのコンテキストの管理および記憶など、他の機能を実行することもできる。
【００５１】
サービングゲートウェイ１４４は、ＰＤＮゲートウェイ１４６に接続することもでき、ＰＤＮゲートウェイ１４６は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスの間の通信を円滑化することができる。
【００５２】
コアネットワーク１０６は、他のネットワークとの通信を円滑化することができる。例えば、コアネットワーク１０６は、ＰＳＴＮ  １０８などの回路交換ネットワークへのアクセスをＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスの間の通信を円滑化することができる。例えば、コアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ  １０８の間のインタフェースとしての役割を果たすＩＰゲートウェイ（例えばＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むことができ、またはＩＰゲートウェイと通信することができる。加えて、コアネットワーク１０６は、ネットワーク１１２へのアクセスをＷＴＲＵ  １０２ａ、１０２ｂ、１０２ｃに提供することができ、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される他の有線または無線ネットワークを含むことができる。
【００５３】
２．３  アイデンティティ管理および使用可能なセキュリティ
ユーザがモバイルデバイスにおいて情報へのアクセスに携わるようになるとユーザは、ウェブサービス別の多数のユーザ資格証明書を扱うというジレンマに直面する。ユーザは、これらの資格証明書を覚えておき、ウェブサービスにアクセスするたびに、ログイン情報およびパスワード情報を入力するという面倒な作業に直面する。デバイスがこれらの資格証明書を覚えておくこともできるが、デバイスは、紛失すること、または盗難にあうことがあり、悪者の手に渡ることもある。
【００５４】
ローカルユーザ認証を透過的なネットワーク認証と組み合わせて、ユーザ資格証明書、およびウェブサービスへのアクセスを安全に管理する、堅牢な認証ソリューションを提供することができる。例えば、様々なパスワードもしくはトークンの入力、および／またはバイオメトリック認証技術を、ウェブサービスポータルとともに機能する無料のシームレスなネットワーク認証方式とともに使用することができる。これらの方式は、シングルサインオン（ＳＳＯ）または連合アイデンティティと呼ばれることがある。
【００５５】
ＵＥを含むことができるモバイルプラットフォームは、様々な独自仕様のプロセッサアーキテクチャおよびオペレーティングシステムをサポートすることができる。これにより、ソフトウェア／ファームウェア開発業者について、断片化された市場が形成され、通信事業者は、アクセス制御および認証などの一般的な技術を組み込み、サポートするために、ＯＥＭと交渉することを強いられる。以下のセクションでは、モバイルプラットフォームにおいてＳＳＯプロトコルを提供する実施形態について説明する。
【００５６】
例示的な一実施形態では、依拠当事者（ＲＰ）がユーザを認証することを可能にするオープン管理セキュリティプロトコルを可能にするために、ユーザ環境を使用することができる。オープン管理セキュリティプロトコルは、ＯｐｅｎＩＤプロトコル、リバティアライアンスプロトコル、オープン認証（ＯＡＵＴＨ）プロトコル、セキュリティアサーションマークアップ言語、またはアイデンティティ保証フレームワークなどの、シングルサインオンプロトコル（ＳＳＯ）とすることができる。依拠当事者は、ユーザの資格証明書を認証または検証することを望んでいる当事者とすることができる。
【００５７】
ユーザ環境は、ユーザインタフェース、および／またはトラステッドコンピューティング環境などのプロセッサから成ることができる。
【００５８】
ユーザインタフェースは、ＵＥとユーザの間のインタフェースを提供することができる。例えば、ユーザインタフェースは、ウェブブラウザ、ウェブページ、またはアプリケーションなどとすることができる。ユーザインタフェースは、ユーザ資格証明書を受け取ることもできる。ユーザ資格証明書は、ユーザ名、パスワード、ＰＩＮコード、秘密鍵、トークン、またはバイオメトリックアイデンティティの組み合わせとすることができる。
【００５９】
ユーザインタフェースは、インタフェースを提供することができ、および／またはＲＰによって提供されるサービスへのアクセスをユーザに代わって要求するために、ＯｐｅｎＩＤなどのＳＳＯプロトコルを使用して、ＲＰと通信することができる。例えば、ユーザは、ウェブブラウザなどのユーザインタフェースエージェントを使用して、ＲＰを訪れることができ、ＯｐｅｎＩＤを使用してログインすることを選択することができる。ユーザインタフェースは、ＲＰがユーザを認証することを望んでいる旨の通知をＲＰから受信することもできる。例えば、ユーザインタフェースは、トラステッドコンピューティング環境を使用してユーザを認証するようにユーザインタフェースに命令する、リダイレクションメッセージをＲＰから受信することができる。
【００６０】
ユーザインタフェースは、ユーザの認証を開始するために、ＳＳＯ資格証明書のトラステッドプロバイダと通信することもできる。例えば、ＲＰは、ユーザインタフェースをトラステッドコンピューティング環境にリダイレクトすることができ、トラステッドコンピューティング環境は、トラステッドプロバイダに関連付けることができる。トラステッドプロバイダは、ユーザ資格証明書のプロバイダとすることができる。例えば、トラステッドプロバイダは、ユーザを知っていることができ、供給されたユーザ資格証明書を用いてユーザを認証することが可能である。
【００６１】
プロセッサは、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他の任意のタイプの集積回路（ＩＣ）、および状態機械などとすることができる。加えて、プロセッサは。
【００６２】
例示的な一実施形態では、プロセッサは、ＵＭＴＳ集積回路カード（ＵＩＣＣ）、加入者識別モジュール（ＳＩＭ）、機器対機器（Ｍ２Ｍ：ｍａｃｈｉｎｅ  ｔｏ  ｍａｃｈｉｎｅ）デバイス、スマートカード、Ｊａｖａ（登録商標）カード、グローバルプラットフォーム（ｇｌｏｂａｌ  ｐｌａｔｆｏｒｍ）スマートカード、または安全な統合チップカード（ＩＣＣ）などの、トラステッドコンピューティング環境とすることができる。トラステッドコンピューティング環境は、スマートカードウェブサーバ（ＳＣＷＳ）を使用して実施することができる。
【００６３】
トラステッドコンピューティング環境は、トラステッドプロバイダのために、ユーザ環境内においてユーザを認証することができる。ユーザを認証するため、トラステッドコンピューティング環境は、認証プロセス中にユーザ環境の外部との通信を制限するために、シングルサインオン資格証明書のトラステッドプロバイダの少なくともいくつかの機能をローカルで実行することができる。例えば、ユーザは、ＰＩＮコード、バイオメトリックアイデンティティ、もしくはトークンなど、またはそれらの組み合わせ（すなわち、ＰＩＮコードとバイオメトリックアイデンティティ）を用いて、トラステッドコンピューティング環境からローカルで認証を受けることができる。トラステッドコンピューティング環境は、認証応答を生成することができる。トラステッドコンピューティング環境は、ユーザが認証された旨のアサーションを含むことができるリダイレクトメッセージを用いて、ユーザインタフェースエージェントをＲＰにリダイレクトすることができる。その後、ユーザインタフェースは、ＲＰにリダイレクトすることができ、ユーザは、ＲＰがトラステッドコンピューティング環境からのアサーションを検証した後、ログインすることができる。
【００６４】
例示的な一実施形態では、トラステッドコンピューティング環境は、ｂａｓｅ６４符号化ＨＭＡＣシグネチャなどの、シグネチャを計算することができ、シグネチャを、ユーザインタフェースを介して、ＲＰに提供することができる。これを行うことで、例えば、ＲＰがトラステッドコンピューティング環境の資格証明書を検証することを可能にすることができる。トラステッド環境は、トラステッドコンピューティング環境と、ＭＮＯまたはＯＰに関連付けることができるトラステッドプロバイダとの間の共有秘密に基づいて、シグネチャを計算することができる。共有秘密は、ユーザインタフェースを介して、トラステッドコンピューティング環境とトラステッドプロバイダの間で確立することができる。シグネチャは、ＲＰから受信したパラメータのリストに署名するために使用することができる。
【００６５】
依拠当事者（ＲＰ）は、サービス、ウェブサイト、データベース、またはアプリケーションなどとすることができる。例示的な一実施形態では、ＲＰは、ユーザ環境の外部に存在することができる。例えば、ＲＰは、ウェブサイトにアクセスするためにユーザによって使用されているセルフォンまたは他のＵＥなどのユーザ環境の外部に存在する、サーバ上でホストされるウェブサイトとすることができる。ＲＰは、例えば、モバイルネットワーク通信事業者（ＭＮＯ）によって提供される、ウェブサービスエンティティへの公衆インターネット通信を使用して、接続を確立しなければならないことがある。これは、例えば、依拠当事者（ＲＰ）がトラステッドコンピューティング環境と直接的に通信できない場合に行うことができる。ＭＮＯは、トラステッドコンピューティング環境とのリモート管理インタフェースと、例えばＳＭＳとしての、追加の通信チャネルとを有することができ、それらは、ＭＮＯが、ＵＥおよび／またはトラステッドコンピューティング環境と通信することを可能にすることができる。ＭＮＯは、ＲＰとトラステッドコンピューティング環境上のＯＰの間の交渉の橋渡し（ｎｅｇｏｔｉａｔｉｎｇ  ｂｒｉｄｇｅ）としての役割を果たすことができる。
【００６６】
別の例示的な実施形態では、ＲＰは、ユーザ環境内に存在することができる。例えば、ユーザインタフェースおよびトラステッドコンピューティング環境を含むことができるＵＥ内において、ＲＰをホストすることができる。
【００６７】
例示的な一実施形態では、ＲＰは、ＲＰがトラステッドコンピューティング環境の資格証明書を検証することが可能なように、認証要求を送信するように構成することができる。ユーザインタフェースは、ＲＰから認証要求を受信することができる。認証要求は、アソシエーションハンドル（ａｓｓｏｃｉａｔｉｏｎ  ｈａｎｄｌｅ）を含むことができる。ユーザインタフェースは、トラステッドコンピューティング環境にアソシエーションハンドルを提供することができる。トラステッドコンピューティング環境は、共有秘密に基づいて、シグネチャを生成することができ、シグネチャおよびアソシエーションハンドルを含む認証応答を生成することができる。ユーザインタフェースまたはトラステッドコンピューティング環境は、トラステッド環境によって生成された認証応答をＲＰに提供することができる。
【００６８】
例示的な一実施形態では、ユーザ環境は、ユーザ機器（ＵＥ）内に存在することができる。例えば、ユーザインタフェースおよびトラステッドコンピューティング環境を、単一のＵＥ内に含むことができる。別の例示的な実施形態では、ユーザ環境は、ユーザインタフェースとトラステッドコンピューティング環境が別々のＵＥ内に存在できる、分割端末構成で配備することができる。例えば、ユーザインタフェースは、ユーザに属するセルフォン上に存在することができ、一方、トラステッドコンピューティング環境は、ユーザに属する銀行カードまたはＵＩＣＣ上に存在することができる。別の例として、ユーザインタフェースは、ユーザに属するパーソナルコンピュータ上に存在することができ、一方、トラステッドコンピューティング環境は、ユーザに属するセルフォン上に存在することができる。
【００６９】
例示的な一実施形態では、オープン管理セキュリティプロトコルにおいて依拠当事者（ＲＰ）のためにユーザを認証するユーザ環境および／またはローカルアサーションエンティティ（ＬＡＥ）を保護するための方法を提供することができる。例示的な一実施形態では、ＬＡＥは、トラステッドコンピューティング環境などのプロセッサ内に存在することができる。ＲＰがユーザを認証することを望んでいる旨のＲＰからの通知を、ユーザインタフェースを介して受信することができる。ＲＰは、ユーザ環境の外部に存在することができ、シングルサインオン（ＳＳＯ）資格証明書のトラステッドプロバイダと通信可能とすることができる。ユーザ資格証明書を、ユーザインタフェースを介して、ユーザから受け取ることができる。受け取ったユーザ資格証明書を用いて、ユーザを認証することができる。例えば、トラステッドコンピューティング環境などのプロセッサは、受け取ったユーザ資格証明書を用いてＲＰのためにユーザを認証することができ、認証プロセス中にユーザ環境の外部との通信を制限するために、ＳＳＯ資格証明書のトラステッドプロバイダの少なくともいくつかの機能をローカルで実行する。認証は、スマートカードウェブサーバ（ＳＣＷＳ）を使用したものとすることができる。
【００７０】
認証応答を、ユーザインタフェースを介して、ＲＰに送信することができる。例えば、ユーザが認証されたときに、認証応答を送信することができる。
【００７１】
ＲＰから受信する通知は、リダイレクションメッセージとすることができる。リダイレクションメッセージは、トラステッドコンピューティング環境を使用してユーザを認証するようにユーザインタフェースに命令することができる。例えば、リダイレクションメッセージは、トラステッドプロバイダを用いて認証する代わりに、ユーザをローカルで認証するように、ブラウザに指示することができる。
【００７２】
ｂａｓｅ６４符号化ＨＭＡＣシグネチャなどの、シグネチャを計算することができ、シグネチャを、ユーザインタフェースを介して、ＲＰに提供することができる。これを行うことで、例えば、ＲＰがトラステッドコンピューティング環境の資格証明書を検証することを可能にすることができる。トラステッドコンピューティング環境は、トラステッドコンピューティング環境と、ＭＮＯに関連付けることができる、ＯｐｅｎＩＤプロバイダなどの、トラステッドプロバイダとの間の共有秘密に基づいて、シグネチャを計算することができる。共有秘密は、ユーザインタフェースを介して、トラステッドコンピューティング環境とトラステッドプロバイダの間で確立することができる。
【００７３】
例示的な一実施形態では、ＲＰがトラステッドコンピューティング環境の資格証明書を検証することを可能にすることができる認証要求をＲＰから受信することができる。例えば、ユーザインタフェースは、ＲＰから認証要求を受信することができる。認証要求は、アソシエーションハンドルを含むことができる。ユーザインタフェースは、トラステッドコンピューティング環境にアソシエーションハンドルを提供することができる。共有秘密に基づいたシグネチャを生成することができる。シグネチャとアソシエーションハンドルとを含む認証応答を生成することもできる。その後、認証応答をＲＰに提供することができる。
【００７４】
２．３．２  ＯｐｅｎＩＤおよびＳＣＷＳを使用するシングルサインオンについての実施形態
ＯｐｅｎＩＤは、通信事業者に軽減された役割を提供することができ、ＯｐｅｎＩＤプロバイダ（ＯＰ）に対する信用を、最小の労力およびリスクで、依拠当事者（ＲＰ）に提供することができる。ＯｐｅｎＩＤは、既存の認証方法とともに機能することができ、したがって、通信事業者は、ＯＰ自身のＡＡＡ資格証明書およびＵＩＣＣ内の事前提供されたＡＫＡ資格証明書を使用して、またはＰＫＩ、事前共有鍵、ＳＩＰダイジェスト資格証明書、ＴＬＳなどを含むが、これらに限定されない、他の認証方法を使用して、ＯＰに対して認証手順をサポートすることができる。
【００７５】
ＯｐｅｎＩＤとスマートカードの組み合わせは、興味深い価値提案（ｖａｌｕｅ  ｐｒｏｐｏｓｉｔｉｏｎ）に至る道を提供する。スマートカードウェブサーバ（ＳＣＷＳ）は、新しいＩＰベースのサービスを提供し、このサービスは、はるかに豊かで安全なウェブエクスペリエンスをユーザに提供することができる。ウェブサーバの基本機能は、ＨＴＴＰプロトコルを使用した、ウェブページの配信である。これは、スマートカードまたはＵＩＣＣ上に存在するＳＣＷＳについても同じである。ＳＣＷＳは、モバイルフォンプロバイダのＩＰネットワーク内のネットワークノードとしてＵＩＣＣを統合する際の、最初のステップとすることができる。
【００７６】
例示的な一実施形態では、ＵＩＣＣは、通信事業者のためのローカル信用センタおよびプロキシとして使用することができる。これを行うことで、例えば、認証トラフィックをローカルに保ち、通信事業者ネットワークに負担がかかるのを防止することができる。ＯＰは、認証強度を増減させて、ＯｐｅｎＩＤ資格証明書を、ＵＩＣＣおよび／またはデバイスおよび／または加入者識別情報および／または加入者に結び付ける、多くの方法を可能にする。ＯｐｅｎＩＤは、例えば、ＵＩＣＣベースのＵＥ認証ＡＫＡ資格証明書もしくはＧＢＡとともに、または証明書ベースの認証メカニズムなど、他の形態の認証メカニズムとともに相互動作することができる。本明細書で開示される実施形態では、ＵＥは、デバイス上のＯＰプロキシに対する通信事業者の信用および評判を利用することができ、標準的なＯｐｅｎＩＤプロトコルよりも高いセキュリティを提供する。
【００７７】
２．３．３  スマートカード上のＯＰ
以下のセクション４において説明されるいくつかの実施形態は、スマートカード上にＯＰを組み込むことについて説明する。例えば、一実施形態は、スマートカードウェブサーバ（ＳＣＷＳ）が存在する、スマートカード上のＯｐｅｎＩＤについて説明する。別の例示的な実施形態は、ＳＣＷＳ上のＯｐｅｎＩＤに対する改良について説明する。
【００７８】
本明細書で説明される実施形態から得られる利点は、以下のものを含むことができる。
●ＯｐｅｎＩＤの使用におけるユーザ移動性。
●必須情報が今ではクラウド内ではなくカード上に存在するので、この資格証明書に対するユーザ制御が改善される（セキュリティ保護が強化される）。
●ＧＢＡを使用する必要性が減少したことで、ネットワークリソースにかかる負荷の大幅な削減がもたらされる。
●認証トラフィックは、いずれも無線を必要としないネットワークエンティティ間の公衆インターネット内に限定される。このことは、ＳＣＷＳ上のＯｐｅｎＩＤのために改良されたプロトコルの場合は明らかである。
【００７９】
３  標準化の展望
多くの正式標準およびデファクトスタンダード（業界標準）の標準化団体が、アイデンティティ管理（ＩｄＭ）に取り組んでいるが、これらの団体のほとんどは、デスクトップ環境におけるＩｄＭの使用に重点を置いている。本明細書で開示される実施形態は、スマートカードなどのトラステッド環境内で実施できる、またはトラステッドコンピューティング環境を含むことができる、スマートフォン、Ｈ（ｅ）ＮＢ、もしくは他のタイプのデバイスなどのプラットフォーム上で実施できる、ローカルおよび／または分散ＳＳＯプロバイダを通してＩｄＭを提供する。シングルサインオンプロバイダは、リバティアライアンスプロバイダ、ＳＡＭＬプロバイダ、カンターライニシアティブプロバイダ、またはＯｐｅｎＩＤプロバイダなど、標準化団体によって提供されるシングルサインオンプロバイダとすることができる。
【００８０】
３．２  リバティアライアンス
リバティアライアンスは、ＢＴ、ＡＯＬ、オラクル、インテル、ＮＴＴ、ＣＡ、フィデリティインベストメンツ、ＮＴＴ、およびサンマイクロシステムズなどの企業によって主導される業界フォーラムとして発足した。アライアンスは、ＩＤフェデレーション（ＩＤ−ＦＦ）およびアイデンティティウェブサービス（ＩＤ−ＷＳＦ）を扱う仕様からなる、リバティアライアンスフレームワークシリーズをリリースしている。
【００８１】
リバティアイデンティティフェデレーション（ＩＤ−ＦＦ）仕様１．０は、インターネットベースのサービスおよびｅコマースアプリケーションの消費者およびユーザが、一度いずれかのデバイスにおいて認証を受け、ネットワークまたはドメインにサインオンすれば、その後は複数のウェブサイトのサービスを訪れることを可能にし、それによって、ユーザが再度認証を受け、プライバシ問題を制御する必要性をバイパスする仕様である。リバティアライアンスは、さらに２つのバージョンのアイデンティティフェデレーション仕様をリリースしており、そのフェデレーション仕様を、セキュリティアサーションマークアップ言語（ＳＡＭＬ）２．０の基礎を形成する、ＯＡＳＩＳ（ｈｔｔｐ：／／ｗｗｗ．ｏａｓｉｓ．ｏｒｇ）に提供した。リバティアライアンスは、アイデンティティベースのウェブサービスを扱う、リバティアイデンティティウェブサービスフレームワーク（ＩＤ−ＷＳＦ）も発表した。この仕様は、安全でプライバシに配慮した連合ソーシャルネットワークにおいて、ジオロケーション、連絡帳、カレンダ、モバイルメッセージングなど、様々なアイデンティティベースのウェブサービスを配備し、管理するためのオープンフレームワークである。
【００８２】
本明細書で開示される実施形態は、セキュリティを強化するために使用できる新機軸、およびリバティアライアンス標準の他の態様を、ＵＥとの関連において開示する。例えば、一実施形態は、トラステッドチケットサーバまたはＴＴｖｅｒｉｆｉｅｒの機能など、開示される機能のいくつかを単独または集団でＵＥ上においてホストできる、ＵＩＣＣ、スマートカード、または統合トラステッド環境（ＴｒＥ）などの安全な環境を、着脱可能モジュールまたは統合モジュールとして有する、モバイルデバイスを開示する。これらの開示される機能は、単独または集団で、既存のリバティアライアンスクライアントプロトコルだけをサポートできる通常のＵＥにおいて現在利用可能なセキュリティおよび信用証明をさらに強化することができる。
【００８３】
３．３  ＯＡＳＩＳおよびＳＡＭＬ
構造化情報標準促進協会（ＯＡＳＩＳ：Ｏｒｇａｎｉｚａｔｉｏｎ  ｆｏｒ  ｔｈｅ  Ａｄｖａｎｃｅｍｅｎｔ  ｏｆ  Ｓｔｒｕｃｔｕｒｅｄ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｔａｎｄａｒｄｓ）は、ｅビジネスおよびウェブサービス標準の開発、収束、および採用のためのグローバルオープンコンソーシアムである。ＩｄＭとの関連では、ＯＡＳＩＳは、現在のバージョンが２．０の、セキュリティアサーションマークアップ言語（ＳＡＭＬ）を開発した。
【００８４】
ＳＡＭＬは、セキュリティドメイン間で、すなわち、アイデンティティプロバイダ（アイデンティティについてのアサーションの生成者）とサービスプロバイダ（前記アサーションの消費者）の間で、認証および認可データを交換するための、ＸＭＬベースの標準である。ＳＡＭＬは、従来のイントラネットベースのＳＳＯソリューションをウェブのオープン環境に拡張して、ウェブブラウザシングルサインオン（ウェブＳＳＯ）の問題を解決しようと試みる。ＳＡＭＬは、ＸＭＬ（およびＸＨＴＭＬ）ベースのオープン標準化プロトコルを使用して、相互運用不能な独自仕様の技術の急増がもたらした結果を克服しようと試みる。ＳＡＭＬは、リクエストおよびアサーションを提供するために、ユーザエージェントに依存する点で、ＯｐｅｎＩＤなどの他のＩｄＭ技術とは異なる。
【００８５】
図２は、アイデンティティプロバイダとサービスプロバイダの間で認証およびデータを交換するためのＳＡＭＬプロトコルを示している。
【００８６】
本明細書で開示される実施形態は、セキュリティを強化するために使用できる新機軸、およびＳＡＭＬの他の態様を、ＵＥとの関連において開示する。例えば、一実施形態は、トラステッドチケットサーバまたはＴＴｖｅｒｉｆｉｅｒの機能など、開示される機能のいくつかを単独または集団でＵＥ上においてホストできる、ＵＩＣＣ、スマートカード、または統合トラステッド環境（ＴｒＥ）などの安全な環境を、着脱可能モジュールまたは統合モジュールとして有する、モバイルデバイスを開示する。これらの開示される機能は、単独または集団で、既存のＳＡＭＬクライアントプロトコルだけをサポートできる通常のＵＥにおいて現在利用可能なセキュリティおよび信用証明をさらに強化することができる。
【００８７】
３．４  カンターライニシアティブ
カンターライニシアティブは、ＢＴ、ＮＴＴ、Ｔ−Ｍｏｂｉｌｅ、ＡＯＬ、およびフィデリティインベストメンツなど、リバティアライアンスの当初の後援企業のいくつかによって主導される、リバティアライアンスの後継組織である。カンターラの公告は勧告であり、アイデンティティ保証と相互運用性という２つの主要な技術的トピックに重点を置いているので、カンターラは、標準定義組織（ＳＤＯ：ｓｔａｎｄａｒｄ  ｄｅｆｉｎｉｎｇ  ｏｒｇａｎｉｚａｔｉｏｎ）ではない。
【００８８】
カンターラは、最初に、アイデンティティ保証フレームワーク（ＩＡＰ）ｖ２．０の仕様を規定したが、ＩＡＰ  ｖ２．０は、リバティアライアンスによって行われたＩＡＰ  ｖ１．０仕様策定作業を拡張したものである。当初のＩＡＰ仕様は、共通の標準化されたルール、およびアイデンティティ保証の各レベルに関連付けられたセキュリティリスク評価に基づいて、トラステッドアイデンティティ対応の企業、ソーシャルネットワーキング、およびウェブ２．０アプリケーションを互いに結び付ける助けとなる、多くのアイデンティティ保証レベルを詳細に規定する。そのため、フレームワークは、アイデンティティ主張および評価に対する柔軟で粒度の細かい信用保証を可能にした。規定された保証レベルは、文献によって概説された（例えば、非特許文献４参照）、低いから非常に高いまでの信頼水準にわたる４つのレベルの保証に基づいている。
【００８９】
本明細書で開示される実施形態は、セキュリティを強化するための新機軸、およびＩＡＰの他の態様を、ＵＥとの関連において開示する。例えば、一実施形態は、トラステッドチケットサーバまたはＴＴｖｅｒｉｆｉｅｒの機能など、開示される機能のいくつかを単独または集団でＵＥ上においてホストできる、ＵＩＣＣ、スマートカード、または統合トラステッド環境（ＴｒＥ）などの安全な環境を、着脱可能モジュールまたは統合モジュールとして有する、モバイルデバイスを開示する。これらの開示される機能は、単独または集団で、既存のカンターライＩＡＰクライアントプロトコルだけをサポートできる通常のＵＥにおいて現在利用可能なセキュリティおよび信用証明をさらに強化することができる。
【００９０】
３．５  ＯｐｅｎＩＤ
ＯｐｅｎＩＤは、アクセス制御のために使用できる、ユーザを認証するためのオープン標準であり、ユーザが、異なるサービスに同じデジタルアイデンティティを用いてログオンすることを可能にし、その際、これらのサービスは、認証機関を信用する。ＯｐｅｎＩＤは、従来のユーザログオンプロセスに取って代わり、それによって、ユーザが、ログインを一度行えば、複数のソフトウェアシステムのリソースにアクセスできるようにする。ＯｐｅｎＩＤという用語は、この標準において使用されるＩＤを指すこともある。
【００９１】
ＯｐｅｎＩＤは、米国に本拠を置く非営利団体であるＯｐｅｎＩＤ財団によって開発、維持されている。ＯｐｅｎＩＤ財団（ＯＩＤＦ）は、ＯｐｅｎＩＤ技術の実現、普及、および保護に携わる個人および企業から成る。
【００９２】
ＯｐｅｎＩＤプロトコルによって使用されるＩＤを指す用語としては、ＯｐｅｎＩＤは、一意的なＵＲＬの形式を取り、ユーザの「ＯｐｅｎＩＤプロバイダ」（すなわち、ＯｐｅｎＩＤ  ＵＲＬをホストするエンティティ）によって認証される。ＯｐｅｎＩＤプロトコルは、ユーザのアイデンティティを認証するために中央当局に依存することはなく、認証自体については特定の方法にも依存しない。ＯｐｅｎＩＤプロトコルも、本人確認を必要とするウェブサイトも、特定のタイプの認証を命じないので、スマートカード、バイオメトリックス、または通常のパスワードなど、多様な認証を使用することができる。
【００９３】
本明細書で開示される実施形態は、セキュリティを強化するための新機軸、およびＯｐｅｎＩＤの他の態様を、ＵＥとの関連において開示する。例えば、一実施形態は、ＵＩＣＣ、スマートカード、または統合トラステッド環境（ＴｒＥ）などの安全な環境を、着脱可能モジュールまたは統合モジュールとして有する、モバイルデバイスを開示する。本明細書で使用される場合、ＯｐｅｎＩＤは、例示的なプロトコルであり、そのプロトコルにおいて、トラステッドチケットサーバ（ＴＴＳ）、ＴＴｖｅｒｉｆｉｅｒ、およびＴＣＴｉｃｋｅｔなどの新たに開示される機能は、ＵＥ内の前記安全な環境によってホストすることができ、単独または集団で、ＵＥをより安全で信頼できるものにすることができ、ＵＥがＯｐｅｎＩＤプロトコルに従ってユーザ本人確認クライアント機能を実行しているときに、これらの開示される方法を使用することによって、そのような強化されたセキュリティおよび信頼性を外部的に検証可能にすることもできる。
【００９４】
３．６  ３ＧＰＰ  ＳＡ３およびＯｐｅｎＩＤにおけるその働き
３ＧＰＰのセキュリティ標準化作業部会である３ＧＰＰ  ＳＡ３では、２Ｇ、３Ｇ、およびより上の世代のモバイルフォン、端末、およびシステムについてのセキュリティの広範な局面において、総合的なアプローチが取られている。ＩｄＭの分野では、現在、ＯｐｅｎＩＤと汎用ブートストラッピングアーキテクチャ（ＧＢＡ：Ｇｅｎｅｒｉｃ  Ｂｏｏｔｓｔｒａｐｐｉｎｇ  Ａｒｃｈｉｔｅｃｔｕｒｅ）との統合に関する１つの技術報告書（例えば、非特許文献５参照）が存在する。リバティアライアンスとＧＢＡのインタワーキングに関する別の技術報告書（例えば、非特許文献６参照）も存在する。
【００９５】
本明細書では、実施形態は、セキュリティを強化するための新機軸、ならびにＯｐｅｎＩＤおよび／またはＯｐｅｎＩＤとＧＢＡもしくは他の認証メカニズムとの統合の他の態様を、ＵＥとの関連において開示する。例えば、一実施形態は、トラステッドチケットサーバまたはＴＴｖｅｒｉｆｉｅｒの機能など、開示される機能のいくつかを単独または集団でＵＥ上においてホストできる、ＵＩＣＣ、スマートカード、または統合トラステッド環境（ＴｒＥ）などの安全な環境を、着脱可能モジュールまたは統合モジュールとして有する、モバイルデバイスを開示する。これらの開示される機能は、単独または集団で、３Ｇネットワーク上でのＯｐｅｎＩＤまたはリバティアライアンスのインタワーキングのための、既存の３ＧＰＰが仕様を規定したプロトコルだけをサポートできる通常のＵＥにおいて現在利用可能なセキュリティおよび信用証明をさらに強化することができる。
【００９６】
４  技術的概要
このセクションは、アイデンティティ管理（ＩｄＭ）ソリューションを提供できる実施形態の技術的概要を提供する。例えば、実施形態は、モバイルローカルプラットフォーム内に、特にスマートカード内に、ＯｐｅｎＩＤプロバイダ（ＯＰ）サーバ機能を配置するために使用することができる。
【００９７】
セクション４．１では、ＯｐｅｎＩＤ序論を提供する。
【００９８】
セクション４．２では、スマートカード上のＯｐｅｎＩＤ、ならびにアーキテクチャ、実施オプション、変形、および３ＧＰＰ  ＧＢＡ（汎用ブートストラッピングアーキテクチャ）の統合を提供する実施形態について説明する。
【００９９】
セクション４．３では、ＯｐｅｎＩＤプロバイダ（ＯＰ）実施プラットフォームオプションについて考察する実施形態について説明する。加えて、セクション４．３では、Ｊａｖａ（登録商標）Ｃａｒｄ（商標）準拠のスマートカードを実施する実施形態、およびスマートカードウェブサーバ（ＳＣＷＳ）上でＯＰを実施する実施形態について説明する。
【０１００】
セクション４．４では、ローカルユーザ認証を扱う実施形態について説明する。ローカルユーザ認証は、ＯｐｅｎＩＤおよび他のＳＳＯ技術に関連するトピックである。加えて、セクション４．４では、バイオメトリックスを使用する実施形態について説明する。
【０１０１】
セクション４．５では、ＯｐｅｎＩＤとの関連で開発できる、「信用（Ｔｒｕｓｔ）」および「信用関係（Ｔｒｕｓｔ  ｒｅｌａｔｉｏｎｓｈｉｐ）」の方法を提供する実施形態について説明する。例えば、ＭＮＯの役割を開示するいくつかの実施形態が説明され、ＭＮＯがＯｐｅｎＩＤプロトコルにおいて他のエンティティ／アクタと有することができる信用関係が詳細に扱われる。例示的な一実施形態では、ＭＮＯは、メインのアイデンティティプロバイダ（ＩｄＰ）と全く同一であり、スマートカード上のＯＰは、（ＩＤＰの役割を果たす）ＭＮＯのプロキシである。第２の例示的な実施形態では、スマートカード上のＯＰは、ＭＮＯによって所有または管理されず、ＭＮＯは、ＩｄＰではなく、サードパーティＩｄＰが、スマートカード上のＯＰを所有および管理する。
【０１０２】
セクション４．６では、スマートカード以外のプラットフォーム上でＯＰを実施することを可能にできる実施形態について説明する。例えば、実施形態は、Ｊａｖａ（登録商標）Ｃａｒｄ（商標）および組み込みセキュアエレメント上での実施の実現可能性について開示する。加えて、実施形態は、モバイルＯＰに非常に高いレベルの信用およびセキュリティを与えるために、（トラステッドコンピューティングにおけるような）プラットフォーム信用の考えを、モバイルＯＰの概念とどのように統合できるかについて説明する。
【０１０３】
４．１  ＯｐｅｎＩＤ序論
ＯｐｅｎＩＤは、ユーザが、単一のＯＰを使用して、異なる依拠当事者サイトにログインすることを可能にする。ＯＰは、ユーザのアイデンティティの中心的な記憶場所であり、ユーザのための単一の認証ポイントとしての役割を果たす。ユーザが自らのＯＰに認証されると、このＯＰは、依拠当事者（ＲＰ）にアサーションを発行することができ、その結果として、ＲＰは、サービスへのアクセスをユーザに許可する。便利なように、ＯＰは、ユーザプロファイルと同等の個人情報を記憶することも許可される。その後、この情報は、ログインプロセスの後、ユーザについてのより詳細な情報をＲＰに提供するために、ＯＰとＲＰの間で交換することができる。
【０１０４】
図３は、ユーザが単一のＯＰを使用して、異なる依拠当事者サイトにログインすることを可能にするためのＯｐｅｎＩＤプロトコルフローを示している。図３に示されるように、ユーザが、ＯｐｅｎＩＤログインを試みると、その後、ＯｐｅｎＩＤログインが、ＲＰによるＯｐｅｎＩＤ  ＵＲＩの発見を起動する。共有秘密が確立されるオプションのセキュリティアソシエーションを、ＲＰとＯＰの間で生成することができる。発見プロセスが完了すると、ユーザは、ＲＰによって、ユーザ認証が試みられるＯＰにリダイレクトされる。ＯＰは、ユーザにログインウェブページを提供し、ログインウェブページにおいて、適切な資格証明書を入力すると、ユーザは認証される。認証が成功すると、その後、ユーザは、ＲＰにリダイレクトされ戻し、ウェブのサービスへのログインが、ユーザに示される。
【０１０５】
４．２  スマートカード上のＯｐｅｎＩＤ
ＯｐｅｎＩＤプロトコルでは、ＯＰは、ユーザ資格証明書および他のユーザ個人情報のためのリポジトリとすることができる。そのため、ＯＰは、ＯｐｅｎＩＤプロトコルにおいて、ほとんどの攻撃の標的となるが、それは、ＯＰから認証を受けるためのユーザ資格証明書を盗むことで、攻撃者は、ユーザの名前で、すべてのＯｐｅｎＩＤ対応サイトにアクセスすることが可能になるからである。攻撃者が、ログインユーザのブラウザセッションを利用する、例えば、ユーザが自らのＯＰから認証を受けた後で、ユーザに代わって隠れたアクションを実行する、より穏当な攻撃シナリオでは、攻撃者は、ユーザ資格証明書を獲得せず、したがって、ユーザ資格証明書を使用して、任意のサイトにログインすることはできない。しかし、ＯｐｅｎＩＤプロトコルの設計は、以前のブラウザセッションにおいてユーザがログインしたすべてのＲＰサイトに、攻撃者がログインすることを可能にする。攻撃者は、必ずしも、例えばマルウェアまたはＭＩＴＭによって、ユーザのマシンにアクセスする必要はなく、そのような攻撃は、ウェブサイト内の隠されたフレームを用いるＸＳＲＦ攻撃を使用することによって、任意のサイト（サイトはＲＰサイトである必要はない）によって実行することができる。攻撃者がマルウェアを注入すること、またはＭＩＴＭとして振る舞うことができる場合、ログインプロセス全体をキャプチャすることができ、その後、別のブラウザセッションにおいて必要な場合はいつでも、それを再現することができる。加えて、ユーザが、ＯＰに資格証明書を再び提供することを必要とせずに、以後のログインを可能にすることを（ＯＰにおいて）決定し（例えば、ＯＰがユーザのブラウザ内に永続的なクッキを記憶し）、サイトが、ＯｐｅｎＩＤプロトコルの「要求即時認証（ｒｅｑｕｅｓｔ  ｉｍｍｅｄｉａｔｅ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ）」オプションを使用する場合、攻撃者は、ユーザを無断でログインさせることができる。したがって、ＯＰセキュリティは、ＯｐｅｎＩＤ実施に関する主要な懸案事項である。
【０１０６】
ＯｐｅｎＩＤ自体は、ユーザが、自ら所有するウェブサイト、例えばブログ上に、自らのＯＰをインストールすることを可能にする。しかし、ユーザがホストを所有することは非常にまれである。したがって、ユーザは、自分のホストのプロバイダが健全に振る舞い、自分のプライベートデータを適切な方法で保護するものと信用する。ユーザ固有の設計を用いてカスタマイズされたＯＰは、容易な自動化された方法ではもはや攻撃を実行できないので、フィッシング攻撃を阻止することができるが、ＯＰ実施の脆弱性、およびユーザのブラウザとＯＰのインタフェースの脆弱性を利用するすべての攻撃（ＭＩＴＭ、マルウェアなど）が、依然として可能である。
【０１０７】
例示的な一実施形態では、ＯＰなどのＳＳＯプロバイダの機能を、ユーザが制御および／または所有できるＵＥに与えることができる。これを行うことで、例えば、ユーザのアイデンティティを管理すると同時に、ＯｐｅｎＩＤプロトコルによって提供される認証の利点であるシームレス性と容易性を提供する、集中環境を提供することができる。ユーザが、自分で管理する安全なデバイス上に自らのＯＰを有することができる場合、攻撃のいくつかは、一般的な方法で実行することがより困難になる。ユーザのためにＯＰを保存および実行するそのようなデバイスは、ユーザが自分のモバイルデバイス内に収めて持ち運ぶ、スマートカードなどのトラステッドコンピューティング環境とすることができる。ＵＩＣＣまたはＪａｖａ（登録商標）カードなどのほとんどのスマートカードは、強化された機能を実行することができ、ユーザと対話することができる。
【０１０８】
ユーザに属するスマートカード上でＯＰを実行することで、ユーザが、自分のプライベートデータに対するより多くの管理を維持することを可能にすることができる。ＲＰがそのサービスに対して料金を請求する場合など、いくつかのシナリオについては、スマートカードベースのＯＰの信頼性についての情報を、ＭＮＯからＲＰに伝えると有益なことがある。これは、ＲＰがＭＮＯを介してユーザに請求することを可能にする、バックチャネルを含むことができる。ユーザは、例えばＰＩＮコードによって、ＯＰから認証を受けるために、ローカルチャネルを使用することができる。ＯＰは、ＭＮＯによってリモートからインストールすることができ、ＯＰのための必要な資格証明書は、ＧＢＡプロトコルを介して、スマートカードにもたらすことができる。
【０１０９】
図４は、トラステッドコンピューティング環境上の統合ＯＰを用いるＳＳＯプロトコルを提供するためのプロトコルフローの例示的な一実施形態を示している。プロトコルフローは、例えば、スマートカード上の統合ＯＰを用いるＯｐｅｎＩＤを提供するために使用することができる。
【０１１０】
図４に示されるように、２０１において、ユーザは、ウェブブラウザなどのユーザインタフェースエージェントを使用して、ＲＰを訪れることができ、ＯｐｅｎＩＤを使用してログインすることを選択することができる。２０２において、ＲＰは、スマートカード、ＵＩＣＣ、またはＪａｖａ（登録商標）カードなどの、トラステッドコンピューティング環境内に含むことができるローカルＯＰに、ユーザインタフェースエージェントをリダイレクトすることができる。２０３において、ユーザは、ＰＩＮコードまたはバイオメトリックアイデンティティなどを用いて、トラステッドコンピューティング環境上のＯＰからローカルで認証を受けることができる。２０４において、トラステッドコンピューティング環境内のＯＰは、認証応答を生成することができる。２０５において、ＯＰは、ユーザインタフェースエージェントをＲＰにリダイレクトすることができ、ユーザが認証された旨のアサーションを含めることができる。２０６において、ユーザインタフェースエージェントをＲＰにリダイレクトすることができ、ユーザは、ＲＰがＯＰからのアサーションを検証した後、ログインすることができる。
【０１１１】
ＲＰは、（ＯＰがＭＮＯによって提供される場合には）例えば、ＭＮＯによって提供されるウェブサービスエンティティへの公衆インターネット通信を使用して、接続を確立しなければならないことがある。これは、例えば、ＲＰがトラステッドコンピューティング環境上のＯＰと直接的に通信できない場合に行うことができる。ＭＮＯは、トラステッドコンピューティング環境とのリモート管理インタフェースと、例えばＳＭＳとしての、追加の通信チャネルとを有することができ、それらは、ＭＮＯが、デバイスおよび／またはトラステッドコンピューティング環境と通信することを可能にする。ＭＮＯは、ＲＰとトラステッドコンピューティング環境上のＯＰの間の交渉の橋渡しとしての役割を果たすことができる。
【０１１２】
図５は、スマートカード上の統合ＯＰを用いるＯｐｅｎＩＤを提供するためのプロトコルフローの例示的な一実施形態を示している。
【０１１３】
図５に示されるように、２０７において、ユーザは、ＲＰを訪れ、ＯｐｅｎＩＤを使用してログインすることを選択することができる。２０８において、サービスは、ユーザ（ユーザのブラウザ）をユーザのローカルＯＰにリダイレクトすることができる。２０９において、ユーザは、例えば、スマートカードインタフェースを介するＰＩＮコードおよび／またはバイオメトリックアイデンティティを使用することによって、ＯＰからローカルで認証を受けることができる。２１０において、ＯＰは、認証応答を生成することができる。２１１において、ＯＰは、ブラウザをＲＰにリダイレクトすることができ、ユーザが認証された旨のアサーションを含めることができる。２１２において、ブラウザをＲＰにリダイレクトすることができ、ユーザは、ＲＰがＯＰからのアサーションを検証した後、ログインすることができる。
【０１１４】
ＲＰは、（ＯＰがＭＮＯによって提供される場合には）例えば、ＭＮＯによって提供されるウェブサービスエンティティへの公衆インターネット通信を使用して、接続を確立しなければならないことがある。これは、例えば、ＲＰがスマートカード上のＯＰと直接的に通信できない場合に行うことができる。ＭＮＯは、スマートカードとのリモート管理インタフェースと、例えばＳＭＳとしての、追加の通信チャネルとを有することができ、それらは、ＭＮＯが、デバイスおよび／またはスマートカードと通信することを可能にする。ＭＮＯは、ＲＰとスマートカード上のＯＰの間の交渉の橋渡しとしての役割を果たすことができる。
【０１１５】
４．２．１  アーキテクチャおよびプリファレンス
４．２．１．１  ＲＰ  ＯＰ通信要件
例示的な一実施形態では、スマートカードなどのトラステッドコンピューティング環境上で動作するＯＰからＲＰがアサーションを取得するために、ＲＰは、ＯＰと通信しなければならない。ＲＰは、ユーザ識別子をＯＰにトランスポートすることができ、その後、認証の後で、ＯＰは、認証の結果をＲＰに通知することができる。
【０１１６】
ＯｐｅｎＩＤプロトコルは、プロトコル中に２つの異なるタイプの通信を使用する。間接通信は、ＨＴＴＰリダイレクトまたはＨＴＭＬ形式のサブミッションを介して実行される。通信がユーザのブラウザを通過するという意味で、通信は間接的である。間接通信は、（ＲＰからブラウザを介してＯＰに至る）認証要求および（ＯＰからブラウザを介してＲＰに至る）認証応答のために使用される。直接通信は、ＲＰとＯＰの間で直接的に実行され、アソシエーションを確立するため、およびＯＰを用いて直接的にアサーションを検証するために使用される。
【０１１７】
ＲＰとＯＰの間でのアソシエーションの（したがって共有秘密の）確立は、命令されてはいないので、ＯｐｅｎＩＤ認証について、２つのプロトコルフローが存在する。
【０１１８】
本明細書で説明される実施形態は、ＯｐｅｎＩＤ認証のためのどちらかのプロトコルフローを使用して実施することができる。
【０１１９】
４．２．１．１．１  アソシエーションベース通信についての予備知識
図６は、アソシエーションベース通信のためのＯｐｅｎＩＤプロトコルフローを示している。
【０１２０】
図６に示されるように、ＯｐｅｎＩＤプロトコルにおけるＯＰとＲＰの間のアソシエーションは、ＯＰとＲＰの間の事前共有秘密に依存しない。アソシエーションは、ユーザが自らのＯｐｅｎＩＤ識別子をＲＰに提供し、ＯｐｅｎＩＤを使用してＲＰにログインすることを望んだ後に、ＲＰによって実行される最初のステップである。２１５において、ＲＰは、（ＨＴＴＰＳを介して）ＯＰに接続し、ＯＰとの（短期の認証毎セッションの）共有秘密ｋを確立するために、ディフィ−ヘルマン鍵交換を実行する。この共有秘密は、後で２３０において、元々はＯＰから来たものであるが、ＲＰは間接通信を介してユーザのブラウザから受信する（ブラウザリダイレクト）、アサーションメッセージ上のシグネチャを検証するために、ＲＰによって使用される。
【０１２１】
アソシエーションが（したがって共有秘密ｋが）、ＲＰとＯＰの間で確立された場合、２２０において、アソシエーションハンドルが、（間接通信を介する）認証要求および認証応答に収めて渡される。２２５において、ＯＰからの認証応答は、アソシエーションハンドルと、共有秘密ｋを使用したアサーション上のシグネチャとを含む。その後、ＲＰは、ｋを使用して、シグネチャを自律的に検証することができる。アソシエーションハンドルの使用は、ＯＰとＲＰの両方が、複数の同時セッションを追跡することを可能にする。
【０１２２】
４．２．１．１．２  ステートレスなシグネチャ検証についての予備知識
図７は、ステートレスなシグネチャ検証のためのＯｐｅｎＩＤプロトコルフローを示している。
【０１２３】
図７に示されるように、ＲＰとＯＰの間でアソシエーションが確立されない場合、２４０において、ＯＰへのダイレクトメッセージとして、ＲＰは、２３５に対する応答である受信した認証応答内のシグネチャを検証しなければならない。その後、２４５において、ＯＰは、ＲＰへのステートメントを発行しなければならず、ステートメントは、アサーションが有効なアサーションであり、実際にＯＰによって発行された場合に「ｙｅｓ」に設定される、「ｉｓ＿ｖａｌｉｄ」フィールドを含む。
【０１２４】
認証要求および認証応答は、ＨＴＴＰリダイレクトによってユーザのブラウザを通過し、したがって、どのシナリオにおいても、ＲＰとＯＰの間のいかなる直接通信チャネルも必要としないが、受信したアサーション上のシグネチャをＲＰが検証する方法が存在しなければならない。オリジナルのプロトコルが標準準拠であり続けなければならない場合、ＲＰは、シグネチャ検証のために、アサーションを受信した後、少なくとも一度はＯＰとコンタクトを取ることができなければならない。その場合、アソシエーションの確立は必要ではない。
【０１２５】
４．２．１．２  認証のためのローカルデバイス上のＯＰの発見についての実施形態
ＯｐｅｎＩＤプロトコルを使用する場合、ＲＰは、間接通信を実行するとき、必ずしもＯＰを発見する必要はない。
【０１２６】
例示的な一実施形態では、ＲＰにアクセスするために使用されるブラウザは、スマートカード上のローカルＯＰを指し示すリダイレクトを取得する。ブラウザとＲＰの間のチャネルが使用されるので、ＲＰは、ＯＰのアドレスを知る必要すらないことがある。しかし、リダイレクトは、ブラウザをあるアドレスに向ける必要があることがある。このアドレスは、後でローカル認証に係わるブラウザによって認識される、（ローカルホストを参照する、１２７．０．０．１に類似した）デバイスローカルＩＰアドレスとして与えることができる。
【０１２７】
別の実施形態では、ローカルＯＰにリダイレクトして、ユーザ認証を続行する目的で、ブラウザによって変換される、特別な識別子を使用することができる。そのような識別子は、例えば、ｓｃ：／／ｏｐｅｎｉｄ／ｉｄｅｎｔｉｆｉｅｒという形式を取ることができ、これは、その識別子に対するスマートカード上のＯＰを用いる認証セッションに係わるようにブラウザに命じる。認証要求は、スマートカードなどのトラステッドコンピューティング環境にとって正しい通信フォーマットに変換することができる。その後、認証は、ＵＩＣＣ機能に応じた適切なインタフェースを介して、ユーザとＵＩＣＣの間で行うことができる。例えば、認証は、ＰＩＮコードまたはバイオメトリック照合などを使用して行うことができる。この認証は、ユーザが認証に同意を与えたことを別途示すことができる。これを行うことで、例えば、スマートカードが攻撃者または無権限ユーザによって使用された場合に、ユーザが知らないうちに認証を受けることを可能にし得る攻撃を防ぐことができる。
【０１２８】
認証をユーザ対話と結合することで、ユーザは、起きているトランザクションを知ることができる。スマートカード機能に応じて、実際のトランザクション詳細を、すなわち、どのサイトがＲＰとしての役割を果たしているか、ＲＰにおける戻り先ＵＲＬ、およびどのアイデンティティを使用すべきかを示すことが望ましいことがある。スマートカード上のＯＰが、複数のＯｐｅｎＩＤアイデンティティをサポートする場合、ＯＰは、このＲＰとともに使用するアイデンティティを選択してユーザに提示することさえできる。（例えばＰＩＮコードを使用して）ＯＰからローカル認証を受けた後、ＯＰからの肯定的アサーションを含めて、ブラウザは、ＲＰにリダイレクトされる。
【０１２９】
例示的な一実施形態では、アサーションは、ＲＰによって検証することができ、したがって、アソシエーションまたは先のセクションで説明されたような直接シグネチャ検証を介する、ＲＰとＯＰの間の直接通信が必要とされる。アサーション検証のための方法は、実施に固有であり、以下のセクション４．２．２．１においてさらに説明される。
【０１３０】
４．２．１．３  ＭＮＯアサートアイデンティティについての実施形態
例示的な一実施形態では、スマートカードなどのトラステッドコンピューティング環境上のローカルＯＰが、ローカルユーザ認証のために使用される。ＭＮＯは、ユーザが正常に認証されたことを述べるトリガリングメッセージをスマートカード上のローカルＯＰから受信した後、必要なアサーションをＲＰに提供するエンティティとすることができる。この実施形態は、セクション４．２．２．１．２において分割ＯＰシナリオとしてさらに説明される。
【０１３１】
４．２．２  実施形態の実施オプションおよび変形
本セクションは、本明細書で開示されるより一般的な概念と組み合わせることができる、実施形態の実施オプションおよび変形について説明することを意図している。
【０１３２】
４．２．２．１  アサーション検証のためのＲＰ−ＯＰ通信についての実施形態
４．２．２．１．１  ＢＯＮＤＩの統合についての実施形態
例示的な一実施形態では、ＲＰとＯＰの間の直接通信チャネルを、少なくともアサーションシグネチャの検証のために使用することができる。そのような直接チャネルは、例えば、ＯＰとＲＰの間のユーザのブラウザを介してトラフィックをトンネルさせることによって提供することができる。この概念は、ブラウザが、現在のセッション内で追加のリダイレクトを実行することを必要とすることがある。
【０１３３】
別の実施形態では、ブラウザは、ＲＰとＯＰの間の通信チャネルを確立するために使用できる第２のプロセスについての、ＲＰのための単一のコンタクトポイントとしての役割を果たすことができる。ＲＰとＯＰの間の指定された通信プロトコルは、ＨＴＴＰまたはＨＴＴＰＳであるので、ブラウザは、すべてのトラフィックをトランスポートすることが可能とすることができる。
【０１３４】
スマートカードなどのトラステッドコンピューティング環境とのブラウザ通信を円滑化するため、ＯＭＴＰ  ＢＯＮＤＩ  ＡＰＩを使用することができる。ＢＯＮＤＩ  ＡＰＩは、ブラウザが、スマートカードと、したがってＯＰと通信するために、ＪａｖａＳｃｒｉｐｔ（登録商標）を使用することを可能にすることができる。ＢＯＮＤＩを使用することによって、リダイレクトを減らすことさえできる。ＲＰは、ＲＰがブラウザに送信するウェブページ内に、適切なＪａｖａＳｃｒｉｐｔ（登録商標）コールを含める。このＪａｖａＳｃｒｉｐｔ（登録商標）コールは、ＢＯＮＤＩ  ＡＰＩを起動し、スマートカードへのアクセスを可能にすることができる。その後、コールの結果は、ＲＰへの応答メッセージ内に（例えばＨＴＴＰ  ＰＯＳＴメッセージ内に）、同じＪａｖａＳｃｒｉｐｔ（登録商標）によってラップすることができる。ＲＰがＢＯＮＤＩコールをいつ使用するかに応じて、ＲＰは、ＲＰが認証要求リダイレクトページ内のスマートカードコールを使用するときに、アソシエーションを確立することができ、またはＲＰは、ＲＰがＯＰアサーションを受信した後で示されるページを使用することができ、これは、ＲＰが、アソシエーションなしに直接検証を実行することを可能にする。
【０１３５】
図８は、ＢＯＮＤＩとアソシエーションベースのＯｐｅｎＩＤとの統合についての例示的な一実施形態を示している。図８に示されるように、２４５において、ＢＯＮＤＩを使用して、ＯＰとＲＰの間で、アソシエーションが確立される。ＢＯＮＤＩは、ブラウザが、スマートカードなどのトラステッドコンピューティング環境、および／またはトラステッドコンピューティング環境内に存在できるＯＰと通信することを可能にすることができる。２５０において、認証要求が、ＯＰにおいてＲＰから受信される。２５５において、認証応答が、ＲＰに伝達され戻す。
【０１３６】
図９は、ＢＯＮＤＩとステートレスな（アソシエーションなしの）シグネチャ検証との統合についての例示的な一実施形態を示している。図９に示されるように、２６０において、ＯＰとＲＰは、ＢＯＮＤＩおよびブラウザを介して通信する。２６５において、ＲＰが、認証要求をＯＰに送信する。２７０において、ＯＰが、認証応答をＲＰに送信する。
【０１３７】
４．２．２．１．２  分割ＯＰについての実施形態
例示的な一実施形態では、ＲＰは、分割ＯＰを使用して、受信したアサーションを検証することができる。分割ＯＰでは、ＯＰ機能をＭＮＯとローカルＯＰの間で分割することができる。ローカルＯＰは、ユーザ認証を担うことができ、一方、ＭＮＯは、ＲＰと通信して、スマートカードＯＰからのシグネチャを検証することができる。これは、ＲＰとＭＮＯの間でセットアップされるアソシエーションを用いて、またはステートレスなシグネチャ検証を介して行うことができる。
【０１３８】
図１０は、分割ＯＰを可能にするための例示的な一実施形態を示している。図１０に示されるように、２７５において、ＲＰとＭＮＯの間でアソシエーションをセットアップすることができる。ＲＰは、ＭＮＯとともに共有秘密を確立することができ、その後、共有秘密は、アサーションメッセージの署名プロセスにおいて、ＯＰによって使用することができる。アサーションメッセージは、ＲＰが異なるユーザと複数の同時接続を有する場合に、ＲＰが正しい共有秘密を識別するための、アソシエーションハンドルを含まなければならないこともある。共有秘密は、ＲＰが、ＯＰと通信することを必要とせずに、アサーションシグネチャを検証することを可能にすることができる。このアソシエーションは、ＵＥのブラウザのＲＰからの最初のリダイレクトが実行される前に、実行することができる。
【０１３９】
２８０において、ＯＰは、認証要求をＲＰに送信することができる。２８５において、ＲＰは、認証応答をＯＰに送信することができる。２９０において、ＯＰは、ＭＮＯとともにアソシエーションハンドルおよび署名鍵を確立することができる。アソシエーションハンドルおよび署名鍵は、ＧＢＡを使用して確立することができる。
【０１４０】
ＲＰとＭＮＯの間でアソシエーションが確立されない場合、ＲＰは、ＭＮＯにおけるエンティティとコンタクトを取ることによって、受信したシグネチャを検証できる必要が依然としてあることがある。このエンティティは、シグネチャの有効性についてのステートメントを発行するように求められることがある。例示的な一実施形態では、ＯＰが、ＭＮＯによって発行されたＯＰに本当に属するかどうかをチェックすることはオプションである。そのようなチェックは、後でＭＮＯに転送される、ＲＰへの認証アサーションメッセージ内に、一意的な識別子を含めるようにＯＰに要求することがある。そのような識別子としてＯＰアドレス（ＩＭＥＩ／ＩＭＳＩ）を使用することが可能なことさえある。ＯＰが、有効なＯＰとしてＭＮＯに登録されている場合、ＭＮＯは、「ｉｓ＿ｖａｌｉｄ」フィールドがｙｅｓに設定されたメッセージをＲＰに返送し、その結果、ＲＰは、アサーションメッセージ（アサーション検証）を承認する。分割ＯＰシナリオは、ＭＮＯが、すべての認証に要する負担をスマートカード上のローカルＯＰにオフロードする方法で、ＯｐｅｎＩＤプロセスに対する制御を保持することを可能にすることができる一方で、ＭＮＯは、ｎｏに設定された「ｉｓ＿ｖａｌｉｄ」を用いて応答することによって、アイデンティティを無効にするためオプションを依然として有する。シグネチャ検証は、ユーザがＲＰにログインする前に、プロトコルの最後のステップとして実行するができる。
【０１４１】
図１１は、分割ＯＰを可能にするためのステートレスな（アソシエーションなしの）実施形態の一例を示している。２９５において、ＭＮＯとＲＰの間で、アサーション検証を行うことができる。３００において、ＲＰは、認証要求をＯＰに送信することができる。３０５において、ＯＰは、認証応答をＲＰに送信することができる。３１０において、ＯＰとＭＮＯの間で、アソシエーションハンドルおよび署名鍵を確立することができる。アソシエーションハンドルおよび署名鍵は、ＧＢＡを使用して確立することができる。
【０１４２】
別の例示的な実施形態では、ＭＮＯがスマートカード上のＯＰと通信するため、ＭＮＯは、ベアラとして暗号化ＳＭＳを使用する、標準ＯＴＡ管理手順が使用できるかどうかを探ることもできる。ＳＭＳ内に含まれるコマンドは、ＳＩＭカードによって暗号解除し、文献において定義されているように（例えば、非特許文献７参照）実行することができる。
【０１４３】
別の例示的な実施形態では、ベアラ独立プロトコル（ＢＩＰ：Ｂｅａｒｅｒ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｐｒｏｔｏｃｏｌ）を、カードアプリケーションツールキットトランスポートプロトコル（ＣＡＴ＿ＴＰ：Ｃａｒｄ  Ａｐｐｌｉｃａｔｉｏｎ  Ｔｏｏｌｋｉｔ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）とともに使用することができる。ＢＩＰは、エンドツーエンドのデータチャネルをもたらす、ハンドセットからＯＴＡサーバおよび（Ｕ）ＳＩＭカードへのデータチャネルを開くことを可能にする。１つのＳＭＳが１４０バイトのサイズを有するＳＭＳと比較して、ＢＩＰのためのデータパッケージは、１４７２バイトを含む。ＢＩＰは、より高速の接続のために、ＵＥ  ＧＰＲＳ接続を使用することができる。ＢＩＰは、文献において標準化されており（例えば、非特許文献８参照）、ＣＡＴ  ＴＰは、文献において標準化されている（例えば、非特許文献９参照）。
【０１４４】
４．２．２．２  スマートカード上のＯＰのための３ＧＰＰ  ＧＢＡの使用についての実施形態
例示的な一実施形態では、本出願全体で説明されるＵＩＣＣ／Ｈ（ｅ）ＮＢベースのＯＰを組み込むために、ＧＢＡを使用することができる。例えば、ＧＢＡプロトコルは、多くのＭＮＯによって使用および確立することができる。
【０１４５】
４．２．２．２．１  ＧＢＡ序論
３ＧＰＰ  ＧＢＡプロトコル仕様（例えば、非特許文献１参照）は、ホームロケーションレジスタ（ＨＬＲ）またはホーム加入者サーバ（ＨＳＳ）上のユーザの有効なアイデンティティを使用して、ユーザ認証を可能にするための技術である。ＧＢＡ認証は、ネットワークコンポーネントに、ＵＥ内のＳＩＭカードを誰何させ、返答がＨＬＲ／ＨＳＳによって予測される返答と同様であることを検証させることによって行われる。ＧＢＡは、共有鍵認証方法の代表である。
【０１４６】
ブートストラッピングサーバ機能（ＢＳＦ：Ｂｏｏｔｓｔｒａｐｐｉｎｇ  Ｓｅｒｖｅｒ  Ｆｕｎｃｔｉｏｎ）では、ＭＮＯネットワークエンティティは、２つのエンドポイントの間の仲介者としての役割を果たし、それらが（存続期間中だけに限定できる）共有秘密を確立することを可能にする。
【０１４７】
以下の図は、参考として含まれ、ＧＢＡアーキテクチャおよびその要素の概要を与える。
【０１４８】
図１２は、ＧＢＡアーキテクチャにおいて使用するＢＳＦ機能を示している。
【０１４９】
図１３は、ＧＢＡアーキテクチャ概要を示している。
【０１５０】
図１４は、文献から引用した（例えば、非特許文献１参照）ＧＢＡ参照モジュールを示している。
【０１５１】
図１５は、文献から引用した（例えば、非特許文献１参照）訪問先ネットワークＮＡＦのためのＧＢＡ参照モジュールを示している。
【０１５２】
４．２．２．２．２  ＧＢＡとＳＳＯの統合における従来技術
ＧＢＡは、３ＧＰＰ認証および鍵合意プロセスを利用して、アプリケーション固有の資格証明書を生成するために、ＳＳＯとの関連において使用することができる。そのような使用の一例が、文献において与えられており（例えば、非特許文献６参照）、その文献は、ＧＢＡとリバティアライアンスＳＳＯプロトコルの間のインタワーキングシナリオについて説明している。別の例も、文献にあり（例えば、非特許文献５参照）、その文献は、ＧＢＡとＯｐｅｎＩＤプロトコルの間のインタワーキングシナリオについて説明している。３ＧＰＰ  ＴＲは、ＧＢＡ鍵を使用して、アイデンティティプロバイダとしての共存ＮＡＦ／ＯＰとＵＥ／ユーザのＵＩＣＣとの間でユーザ認証を実行する。本セクションの残りでは、例を挙げて、ＧＢＡとＯｐｅｎＩＤの間のインタワーキングについて重点的に説明する。
【０１５３】
ＵＥは、Ｕｂインタフェースを介して、これらのアプリケーションレイヤ資格証明書を生成するために、ＭＮＯ  ＨＳＳのＢＳＦを使用する。その後、これらは、Ｚｎインタフェースを介して、ＯＰ／ＮＡＦと共有される。その後、ＵＥクライアントは、これらの資格証明書を使用して、サービスプロバイダと直接的に通信することができる。
【０１５４】
図１６は、ＭａｃＤｏｎａｌｄ他によって書かれた文献に示されるような（例えば、非特許文献１０参照）、リバティ／ＧＢＡのためのアーキテクチャ図式を示している。図１６に示されるように、ＧＢＡは、リバティＩｄＰを実施するショッピングモールを提供するために、リバティアライアンスプロトコルと統合することができる。リバティＩｄＰを通して、ショッピングモールは、ユーザがショッピングサービスにおいて使用できるアイデンティティをユーザに提供する。ＩｄＰは、認証メカニズムとしてＧＢＡプロトコルを使用する。
【０１５５】
図１６は、以下のステップを示している。
３１５。ひとたび登録されると、（ＵＥ）のユーザエージェントは、Ｕｂを介して、（ＢＳＦ）とともにＧＢＡ  Ｕを実行する。
３２０。ＵＩＣＣ内のユーザエージェントアプレットにＵｂパラメータが提供される。
３２５。ユーザエージェントのＵＩＣＣコンポーネントが、Ｋｓを計算し、ＵＥにサービスレイヤ資格証明書（Ｋｓ（ｉｎｔ／ｅｘｔ）ＮＡＦ）を提供する。Ｋｓは、常にＵＩＣＣ内に残っている。
３３０。ユーザエージェントが、「ショッピングモール」アイデンティティを獲得するために、（ＮＡＦ／ＩｄＰ）とコンタクトを取る。
３３５。ユーザエージェントに適したサービス資格証明書が、Ｚｎを介して（ＮＡＦ／ＩｄＰ）に伝達される。
３４０。「ショッピングモール」のための認証トークンが、（ＮＡＦ／ＩｄＰ）からユーザエージェントに提供される。
３４５。（ＵＥ）が、サービス資格証明書を使用して（ＳＰ）と通信し、サービスを要求する。
３５０。（ＳＰ）が、（ＵＥ）のサービス資格証明書の有効性を確認する。
【０１５６】
４．２．２．２．３  ＧＢＡおよびＯｐｅｎＩＤの使用についての実施形態
例示的な一実施形態では、ＵＩＣＣとＮＡＦの間で共有秘密を確立するために、ＧＢＡを使用することができる。ＮＡＦは、他のサービス（例えばＩｄＰ）と共存することができ、ＭＮＯネットワーク内に存在する必要がないことがある。ＮＡＦは、（ＭＮＯのネットワーク内の）ＢＳＦへの接続を必要とすることがある。ＵＥ内のＵＩＣＣとＮＡＦの間の接続は、例えば、ＨＴＴＰまたはＨＴＴＰＳ上のＳＯＡＰを介することができる。以下でさらに説明される他の実施形態では、ＯＰとＭＮＯの間の通信のために使用できるＵＩＣＣベースのＯＰは、ＧＢＡプロトコルを使用することができる。
【０１５７】
４．２．２．２．３．１  ＯＰのための（直接）信用プロバイダとしてのＭＮＯ
例示的な一実施形態では、ＭＮＯを使用して、ＲＰとＯＰの間で信用を確立できるという意味で、ＭＮＯは、ＲＰ−ＯＰ通信に直接的に関与することができる。
【０１５８】
以下の実施形態は、セクション４．５．２．２．１において先に説明された実施形態と統合することができる。
【０１５９】
ＲＰとＭＮＯの間の直接接続についての実施形態
図１７は、ＭＮＯ支援のアイデンティティアサーションのためのＧＢＡの使用についての例示的な一実施形態を示している。
【０１６０】
図１７に示されるように、３７０において、ＲＰは、アソシエーションを確立するために、ＭＮＯのネットワークエンティティに接続することができる。このＭＮＯエンティティは、ＵＩＣＣベースのＯＰのためのアサーションサポートとしての役割を果たすことができ、このエンティティは、ＯＰｓｕｐと呼ばれることがある。ＯＰｓｕｐは、統合ＮＡＦ機能を有することができ、ＭＮＯネットワークの内部の（しかし到達可能な）エンティティ、または外部の（しかしＭＮＯによって操作もしくは保証される）エンティティとして実現することができる。３６５において、ＯＰｓｕｐとＵＩＣＣ上のＯＰは、ＧＡＡ／ＧＢＡを使用して共有秘密を確立するために、必要なブートストラッピングプロセスを実行することができる。３５５において、ユーザのブラウザは、ＲＰからローカルＯＰにリダイレクトすることができる。３６０において、ブラウザとＯＰの間で通信を行うことができる。
【０１６１】
ユーザは、ローカル（ＵＩＣＣ）ＯＰから認証を受けることができる。（例えばＰＩＮコードを使用する）３６０におけるローカル認証の後、３６５において、ＯＰは、Ｋｓ＿ＮＡＦから導出される、ＲＰ固有の、また任意選択的にセッション固有の鍵Ｋｓ＿ＮＡＦ＿ＲＰを用いて署名された、セッション識別子（または初期リダイレクトにおいてＲＰによって渡された追加のノンス）を含むメッセージを、ＯＰｓｕｐに送信することができる。３７０において、ＯＰｓｕｐとＲＰの間の安全な接続がすでに確立されている場合、確立されたチャネルは、ソースの真正性とメッセージに対する完全性保護をすでに提供しているので、ＯＰｓｕｐは、このメッセージをＲＰに転送することができる。しかし、ＯＰｓｕｐは、公開鍵を用いてメッセージに署名することができ、したがって、通信チャネルから独立して、完全性保護および真正性を提供することができる。ＲＰは、ＯＰシグネチャを検証するために、Ｋｓ＿ＮＡＦから導出される、ＲＰ固有の、また任意選択的にセッション固有の鍵Ｋｓ＿ＮＡＦ＿ＲＰを備えることができる。その場合、Ｋｓ＿ＮＡＦ＿ＲＰは、ＯＰｓｕｐを介してＲＰに渡すことができる。別の実施形態では、シグネチャ生成および検証のために、ＫＳ＿ＮＡＦを直接的に使用することができる。
【０１６２】
ＯＰを介する間接通信についての実施形態
例示的な一実施形態では、ノンスをＲＰからＯＰに伝達するために、間接通信を使用することができ、その後、ＯＰは、ノンスをＭＮＯに転送する。ＭＮＯは、アサーション内に含めることができるノンスに署名し、アサーションは、ローカル認証が成功した後、ＯＰからＲＰに渡される。ＭＮＯがノンスに署名するので、ＯＰがＭＮＯ発行のＵＩＣＣ上で動作していることについての保証が、ＲＰに提供される。
【０１６３】
組み合わされた方法についての実施形態
例示的な一実施形態では、直接通信（例えばＨＴＴＰＳ接続）を介してＲＰとＭＮＯの間で確立される共有秘密を使用することができる。その場合、ＲＰは、ＯＰが、認証の完了時に、この秘密をアサーションメッセージに含めることを予期することができる。
【０１６４】
別の例示的な実施形態では、ＧＢＡを使用することができる。ＧＢＡプロトコルは、ＮＡＦとＵＩＣＣの間で恣意的な共有秘密（例えばＲＰの秘密）を確立することを許容しないので、ここ（例えば共存ＯＰｓｕｐエンティティ）では、インダイレクション（ｉｎｄｉｒｅｃｔｉｏｎ）を使用することができる。ＲＰは、セッション識別子をＯＰｓｕｐに送信し、ＯＰｓｕｐは、ＧＢＡを使用して、ＵＩＣＣとともに共有秘密を確立することができる。その後、ＯＰｓｕｐは、ＵＩＣＣ（したがってＵＩＣＣ上のＯＰ）とともに確立したのと同じ秘密を使用して、セッション識別子に署名し、署名されたセッション識別子をＲＰに返送することができる。ＲＰは、この署名されたセッション識別子を参照として保持することができる。ＲＰは、セッション識別子をリダイレクトメッセージに含め、それによって、ＯＰが、ＧＢＡ秘密を使用して、セッション識別子に署名することを可能にすることができる。その後、ＯＰは、署名されたセッション識別子をＲＰへのアサーションメッセージに含めることができる。その後、ＲＰは、ＯＰからの署名されたメッセージとＯＰｓｕｐからの署名されたメッセージを比較することができる。それらがマッチした場合、ＲＰは、ＯＰがＯＰｓｕｐのＭＮＯの加入者に属することの証拠を得る。この実施形態は、メッセージ保護を強化し、ＯｐｅｎＩＤ認証を確立する、シグネチャマッチングを用いるクローズドループプロセスを表すことができる。
【０１６５】
４．２．２．２．３．２  ＯＰ機能がＭＮＯとスマートカード上のＯＰの間で分割された場合（分割ＯＰ）のＧＢＡの使用についての実施形態
図１８は、分割ＯＰを可能にするための例示的な一実施形態を示している。図１８に示されるように、３７５において、ＲＰとＭＮＯの間でアソシエーションをセットアップすることができる。ＲＰは、ＭＮＯとともに共有秘密を確立することができ、その後、共有秘密は、アサーションメッセージの署名プロセスにおいて、ＯＰによって使用することができる。アサーションメッセージは、ＲＰが異なるユーザと複数の同時接続を有する場合に、ＲＰが正しい共有秘密を識別するための、アソシエーションハンドルを含まなければならないこともある。共有秘密は、ＲＰが、ＯＰと通信することを必要とせずに、アサーションシグネチャを検証することを可能にすることができる。このアソシエーションは、ＵＥのブラウザのＲＰからの最初のリダイレクトが実行される前に、実行することができる。
【０１６６】
３８０において、ＯＰは、認証要求をＲＰに送信することができる。３８５において、ＲＰは、認証応答をＯＰに送信することができる。３９０において、ＯＰは、ＭＮＯとともにアソシエーションハンドルおよび署名鍵を確立することができる。アソシエーションハンドルおよび署名鍵は、ＧＢＡを使用して確立することができる。
【０１６７】
例示的な実施形態では、ＯＰ機能は、ＭＮＯとローカルＯＰの間で分割することができる。ＲＰとＭＮＯの間のアソシエーションが使用される場合、ＲＰは、ＭＮＯとともに共有秘密を確立することができ、その後、共有秘密は、アサーションメッセージの署名プロセスにおいて、ＯＰによって使用することができる。アサーションメッセージは、ＲＰが異なるユーザと複数の同時接続を有する場合に、ＲＰが正しい共有秘密を識別するための、アソシエーションハンドルを含むこともある。共有秘密は、ＲＰが、ＯＰと通信することを必要とせずに、アサーションシグネチャを検証することを可能にすることができる。ＧＢＡが行われると仮定すると、ＭＮＯとＲＰの間の共有鍵は、Ｋｓ＿ＮＡＦによって保護して、ＯＰに渡すことができる。したがって、ＯＰは、アソシエーションを介して確立された共有鍵を使用して、アサーションメッセージに署名することができる。
【０１６８】
ＲＰは、ＭＮＯとともにアソシエーションを確立することができ、その後、ＭＮＯは、ＭＮＯとＯＰの間の共有秘密を生成するＧＢＡ手順を実行する。ＭＮＯは、ＲＰから到達可能なサーバにおいて、ＮＡＦ機能を実施することができる。ＮＡＦは、ＵＩＣＣ上のＯＰとともに共有秘密を確立することができ、ＲＰは、共有秘密をＮＡＦから受信する。（ＮＡＦとＲＰに知られている）アソシエーションハンドルも、ＭＮＯコンタクトポイント（ＮＡＦ）からＯＰに送信することができる。その後、ＯＰは、ＧＢＡ共有秘密を使用して、アソシエーションハンドルを含む、ＲＰに送信されるアサーションに署名することができる。ＲＰは、ＮＡＦからアソシエーションリンクを介して同じ共有秘密を受信することができるので、ＯＰシグネチャを検証することができる。アソシエーションハンドルの使用は、ＯＰおよびＲＰが、複数の（同時）セッションを扱うことを可能にする。
【０１６９】
４．２．２．２．３．３  分割端末の場合のモバイルＯｐｅｎＩＤにおけるＧＢＡの使用
例示的な一実施形態では、ＧＢＡは、ブラウザとＯＰ／ＵＩＣＣの組み合わせとが別個のデバイス内に存在する、分割端末構成において使用することができる。分割端末タイプ構成は、ＯＰがユーザにとってローカルエンティティであり、先に説明したように、ユーザがＯＰを用いてローカルに認証を実行する場合に、まさに利用されると仮定することができる。
【０１７０】
図１９は、分割端末／ローカルＯｐｅｎＩｄを可能にするための例示的な実施形態を示している。図１９に示されるように、２つのデバイス間のチャネルの保護は、例えばｂｌｕｅｔｏｏｔｈセキュアリンクを使用して、または場合によっては、共有秘密鍵Ｋｓ＿ｌｏｃａｌ＿ｄｅｖｉｃｅが確立される、文献で説明されている手順（例えば、非特許文献１１参照）を介するなどして、達成することができる。鍵は、ＵＩＣＣにおいて内部的に計算することができ、セキュアトンネルを介してブラウザに渡すことができる。共有秘密の確立は、ＧＢＡによってサポートすることができる。共有秘密鍵は、ＧＢＡ生成鍵Ｋｓ＿（ｅｘｔ／ｉｎｔ）＿ＮＡＦから導出することができる。
【０１７１】
例示的な一実施形態では、３３．２５９を利用する場合、証明書ベースの相互認証を用い、ＨＴＴＰＳを使用して、ＮＡＦとリモートデバイスを接続するセキュアトンネルを確立することができる。例えば、ブラウザは、ＰＣベースであり、インターネット／ＴＣＰ接続の環境において動作するトンネルを用いることができる。トンネルのセキュリティは、信用メカニズムによって強化することができる。モバイルフォン仕様（ＭＰＷＧ）の要件の通り、ブラウザを含むリモートデバイスは、ＴＣＧ準拠であると仮定することができる。ＨＴＴＰＳトンネル確立は、デバイスにおけるＴＰＭの証明を通して、ブラウザデバイスの信用ステータスに結び付けることができる。したがって、このプロトコルに組み込まれた完全性チェックは、Ｋｓ＿ｌｏｃａｌ＿ｄｅｖｉｃｅをプラットフォームに結び付ける。
【０１７２】
別の例示的な実施形態では、手順の一環として、ＵＩＣＣホスティングデバイスは、ユーザのブラウザをホストするリモートデバイスによって、それにＮＡＦ＿ＩＤのリストを送信するように要求されることがある。ＭｉＴＭは、そのような要求を容易に行い、要求されたＩＤを受信することができる。トンネルを保護する証明書および相互認証の態様は、適所において仮定される信用機能と一緒になって、分割端末構成内ではＭｉＴＭ攻撃は行われていないこと、またはそのような攻撃が行われていても、それは検出されることを保証する。ひとたびこのセットアップが完了すると、トンネルを介して、Ｋｓ＿ｌｏｃａｌ＿ｄｅｖｉｃｅ鍵をリモートデバイスに安全に送信することができ、その後、リモートデバイス（ブラウザ）は、デバイスをホストするＵＩＣＣ上でＫｓ＿ｌｏｃａｌ＿ｄｅｖｉｃｅの計算を開始するために、（完全性保護された）鍵生成要求メッセージを送信することができる。
【０１７３】
分割端末タイプ構成のためのアイデンティティアサーションプロトコルが、本明細書で説明される。リモートプラットフォーム（ブラウザ−ＰＣ）とＵＩＣＣ／ＯＰを含むデバイス（ＵＥ）との間の共有秘密鍵Ｋｓ＿ｌｏｃａｌ＿ｄｅｖｉｃｅを確立する手順とともに、ＧＢＡがすでに行われていると仮定することができる。図１９に示されるように、（ＵＥとＮＡＦ／ＯＰｓｕｐを接続する）４０５によって識別されるチャネルと、（ＵＥとＰＣを接続する）４００によって識別されるチャネルは、安全とすることができる。別の例示的な実施形態では、ＭＮＯは、ＵＩＣＣベースのＯＰのアイデンティティアサーションがここで適用されるのをサポートするのに役立つことがある。
【０１７４】
別の例示的な実施形態では、
●ユーザは、ＯｐｅｎＩＤログインフォームを使用して、自分のＯＰ識別子（ＵＲＬ）をＲＰに提供する（３９５）。
●ユーザは、ＲＰによって自分のＯＰにリダイレクトされ、リダイレクトメッセージは、ノンスまたはセッション識別子を含む。
●ＲＰとＭＮＯは、セキュリティアソシエーション（例えばＨＴＴＰＳ接続）を確立する（４１０）。
●ＲＰも、セッション識別子をＯＰｓｕｐに送信し、このメッセージは、上述のセキュリティアソシエーションによって保護される（４１０）。
●ユーザは、ブラウザを介して入力されるＰＩＮ（またはパスワード）を使用して認証を受ける。
●この情報は、ＲＰから獲得したセッション識別子も含むメッセージに収めて、４００を介してＰＣからＵＩＣＣ／ＯＰに伝達され、上で説明したように、このメッセージは、Ｋｓ＿ｌｏｃａｌ＿ｄｅｖｉｃｅを用いて保護される。
●ＯＰｓｕｐは、ＧＢＡ鍵Ｋｓ＿（ｅｘｔ／ｉｎｔ）＿ＮＡＦを使用して、セッション識別子に署名し、それをＲＰに返信し、ＲＰは、このシグネチャを参照として保持する（４１０）。
●ＯＰは、やはりＧＢＡ鍵Ｋｓ＿（ｅｘｔ／ｉｎｔ）＿ＮＡＦを使用して、今度はブラウザからＯＰに送信されたセッション識別子に署名し、このシグネチャをアサーションメッセージに含め、その後、アサーションメッセージは、ＲＰに送信される（３９５）。
●ＲＰは、ＯＰｓｕｐからの１つ（４１０）と、ＯＰからのもう１つ（３９５）の、２つのシグネチャを比較し、それらがマッチした場合、ＲＰは、ＯＰがＯＰｓｕｐのＭＮＯの加入者に属すると結論づける。
【０１７５】
４．３  スマートカードウェブサーバ上のＯＰのための効率的なプロトコルについての実施形態
本セクションは、本出願においてさらに説明される、効率的な改良を提供する実施形態に特に関して、ＳＣＷＳ上のＯＰによって提供される利益を明瞭化することを意図している。ＯｐｅｎＩＤプロトコルを実施する実施形態など、提案される実施形態の利益の１つは、認証トラフィックがローカルであり、エアインタフェースネットワークまたはネットワークサービスに、既存のＨＴＴＰメッセージフローのために必要とされるもの以外の負担をかけないことである。発見およびアソシエーショントラフィックは、エアインタフェースネットワークを介することはなく、通信事業者ＯＰとＲＰの間の有線公衆インターネットを介して行われる。
【０１７６】
４．３．１  標準的なＯｐｅｎＩＤ
図２０は、標準的なＯｐｅｎＩＤプロトコルを示している。このプロトコルの場合、ローカルトラフィックは存在せず、エアネットワークからオフロードされるトラフィックは、発見プロセスと、ＲＰとＯＰの間のアソシエーション確立だけである。ＯＰはウェブサービスであるので、ユーザ／ブラウザ／デバイスとＯＰの間のすべての通信は、エアインタフェースを介する。例えば、信号４２０、４３５、４４０、４４５、４５０、４５５、４６０、４６５は、無線通信上に発生し、無線通信は、一般にはデータトラフィック（例えば、ＨＴＴＰ、ＩＰベースの通信）として、ＭＮＯ／エアネットワーク上で実施される。これは、ＭＮＯネットワーク上に負荷をかけることを表す。加えて、信号４２５、４３０は、有線インターネット上で発生するトラフィックであり、既存のインフラストラクチャを使用することができる。
【０１７７】
４．３．２  ＯｐｅｎＩＤ／ＧＢＡ
図２１は、文献から引用した（例えば、非特許文献２参照）ＯｐｅｎＩＤ／ＧＢＡのためのトラフィックフローを示している。このプロトコル定義の場合、ＲＰとＭＮＯの間のアソシエーションステップにも係わらず、すべての通信は、エアネットワーク上で行われる。しかし、ウェブベースのＯＰと比較して、ＯｐｅｎＩＤ／ＧＢＡでは、認証のために４７２および４７４が必要とされ、それらは、エアデータネットワークばかりでなく、ＧＢＡ認証のために必要とされるバックエンドサービス、すなわちＢＳＦおよびＮＡＦサブシステムにも負担をかけるので、トラフィックはさらに増加する。そのため、ここでは、エアネットワークトラフィックの増加と、ネットワークエンティティにおける負荷の増加を見る。
【０１７８】
４．３．３  プロトコル改良についての実施形態
図２２は、無線トラフィックを減少させるためのプロトコルフローの例示的な一実施形態を示している。例えば、ＳＣＷＳ上のＯｐｅｎＩＤのための効率的なプロトコルを使用することができる。この実施形態では、ＳＣＷＳに関連付けられたＯＰとＭＮＯの間に長期共有鍵が存在すると仮定することができる。
【０１７９】
図２２に示されるように、無線トラフィックは、エアインタフェースネットワークトラフィックに減少するように、ローカルデバイスにオフロードすることができる。これを行うことで、例えば、認証トラフィックがローカルになることを可能にすることができ、その結果、認証トラフィックは、エアインタフェースネットワークまたはネットワークサービスにかかる負担を最小化する。加えて、発見および／またはアソシエーショントラフィックは、エアインタフェースネットワークを介して発生しなくてもよく、有線公衆インターネット上で行うことができる。
【０１８０】
４８０において、ユーザは、ブラウザなどのユーザインタフェースと対話することができ、ＲＰを訪れることができ、ＯｐｅｎＩＤを使用してログインを要求することができる。４８５において、ＲＰとＯＰ（ＭＮＯ）は、ＯｐｅｎＩＤアイデンティティに基づいて、ＯＰサーバの発見を実行することができる。４９０において、ＲＰは、アソシエーション要求をＯＰに送信することができる。ＯＰは、ランダムで一意的なアソシエーションハンドルＡを生成することができ、鍵Ｓを計算することができる。ＯＰは、アソシエーション応答をＲＰに送信することができる。アソシエーション応答は、アソシエーションハンドルＡと、鍵Ｓとを含むことができる。ＲＰは、鍵ＳとアソシエーションハンドルＡを保存することができる。
【０１８１】
４９５において、ＲＰは、リダイレクトをブラウザに送信することができる。リダイレクトは、ブラウザをＯＰにリダイレクトすることができ、要求パラメータにアソシエーションハンドルＡを含めることができる。ＯＰは、ＳＣＷＳに関連付けることができる。ブラウザは、リダイレクトを受信することができ、ＳＣＷＳにマッピングするように変更されたローカルＤＮＳルックアップを実行することができる。５００において、ブラウザは、認証のためのローカル要求をＯＰに送信することができる。５０５において、認証をローカルに行うことができる。例えば、５１０において、ＯＰは、長期共有秘密鍵ＫとアソシエーションハンドルＡに基づいて、資格証明書を検証することができる。加えて、ＯＰは、鍵Ｓを計算することができ、鍵Ｓを使用して、シグネチャを計算することができる。シグネチャは、アサーションメッセージに署名するために、ならびに／または戻り先ＵＲＬ、アイデンティティ、および／もしくはモードなどのパラメータに署名するために使用することができる。
【０１８２】
５１５において、ＯＰは、ブラウザをＲＰにリダイレクトできるリダイレクトを、ブラウザに送信することができる。リダイレクトは、アソシエーションハンドルＡと、署名されたパラメータとを含むことができる。５２０において、ブラウザは、ＯＰからの署名されたアサーションメッセージを含むことができる要求を、ＲＰに送信することができる。ＲＰは、鍵Ｓを使用して、アサーションメッセージ上のシグネチャを検証することができる。その後、５２５において、ＲＰは、ブラウザが、ログインページを表示することを可能にすることができ、サービスへのアクセスをブラウザに提供することができる。
【０１８３】
４．４  スマートカードウェブサーバ上でのＯＰ実施についての実施形態
ユーザ機器（ＵＥ）がＳＩＭカードと通信するために利用可能な標準化された方法が存在し、例えば、文献は、ＳＩＭアプリケーションによって使用できる、ＳＩＭアプリケーションツールキット（ＳＡＴ）インタフェースを定義しているが（例えば、非特許文献１２参照）、どのようにすれば、異なるＳＩＭベンダからの様々なＳＩＭカードタイプにわたって統一された方法で、コマンドを利用できるかは定義していない。例示的な一実施形態では、ＳＩＭアプリケーションツールキットを使用して、ＳＩＭカードは、ＵＥに対する一時的な制御（プロアクティブ（ｐｒｏａｃｔｉｖｅ））を取得することができる。ＵＥがＳＩＭカードに要求を送信し、ＳＩＭが応答する場合と比較して、ＵＥは、ＳＩＭからＳＡＴコマンドをフェッチすることができる。ＳＩＭカードは、ＵＥに向けてＳＡＴコマンドを発行し、ＵＥはしかるべく反応して、コマンドが正常に実行されてもされなくても、ＳＩＭに応答を返信する。
【０１８４】
４．４．１  スマートカードウェブサーバ上のＯＰ
スマートカードウェブサーバ（ＳＣＷＳ）は、ＵＳＩＭカード上で動作し、従来のウェブサーバのように振る舞う、ウェブサーバである。ＳＣＷＳは、ＳＩＭツールキットの進歩と見なされ、現在のアプリケーションシナリオでは、ローカルＵＥブラウザを使用するＨＴＭＬインタフェースを介して、電話帳、追加のＭＮＯサービスなどを表示するために使用される。ＳＣＷＳは、標準的なＨＴＴＰプロトコルを使用して、そのコンテンツをブラウザに配信するが、従来のウェブサーバとは異なり、ＳＣＷＳは、２つの異なるベアラを、すなわち、（Ｔ＝０のスマートカードプロトコルの上の）ＢＩＰ、またはＵＳＢインタフェースの上の（カード上で実施される）完全なＴＣＰ／ＩＰスタックを使用することができる。
【０１８５】
ＵＥは、ＳＣＷＳ  ＵＳＩＭへのトラフィックおよびＳＣＷＳ  ＵＳＩＭからのトラフィックのルーティングを担い、（Ｕ）ＳＩＭをＭＮＯおよびインターネットに接続するゲートウェイとしての役割を果たす。ＢＩＰインタフェースが使用される場合、ＭＥ内のルータが、ある種のＨＴＴＰ要求をＵＥブラウザからローカルＳＣＷＳにリダイレクトする。決められたＴＣＰポート上のＨＴＴＰ要求は、（Ｕ）ＳＩＭ上のＳＣＷＳに送信され、応答内のＨＴＭＬページは、ＳＣＷＳによって生成される。ＢＩＰ専用のＴＣＰポートを使用しないＨＴＴＰ要求は、インターネット上のサーバに送られる。ＵＳＢプロトコルが、（Ｕ）ＳＩＭ上の完全なＴＣＰ／ＩＰスタックと組み合わせて使用される場合、ＵＥは、イントラネットをインターネットに接続する他のコンピュータと同じＩＰゲートウェイ機能を有する。ＭＥゲートウェイは、使用されるＩＰプロトコルバージョンにも、すなわち、ＩＰｖ４か、それともＩＰｖ６かにも依存する。ＢＩＰと比較して、完全なＴＣＰ／ＩＰスタックは、要求を（Ｕ）ＳＩＭからインターネットに回送する可能性も提供する。
【０１８６】
図２３は、ＳＣＷＳ上のＯＰのための内部ルーティングについての例示的な一実施形態を示している。図２３に示されるように、ＳＣＷＳは、ＯＰのための基盤として使用することができ、ＵＥルーティング機能は、与えられた外部ポートに反応し、通信をＳＣＷＳ上のＯＰに転送するように、変更することができる。これは、例えば、ブラウザを通るトンネルを用いずに、直接通信を生成するために行うことができる。トラフィックは、依然として同じデバイスを通過するが、異なる方法でリダイレクトすることができる。
【０１８７】
ＵＥにおけるルーティング機能（ＲＦ）は、複数の通信経路を可能にすることができる。ユーザがブラウザを使用して最初にＲＰサイトを訪れたとき、ＲＦは、利用可能なアウトバウンドＴＣＰ／ＩＰインタフェース（例えば３Ｇネットワーク接続）を介して、要求をＲＰにリダイレクトすることができる。ＲＰとブラウザは、この接続を介して共通のセッションを確立したので、今では、ＲＰは、ブラウザのＩＰアドレスを知っている。ＲＰは、ユーザ／ブラウザセッションにおけるのと同じアドレスを使用して、ＯＰとコンタクトを取ることができる。ＲＰは、ブラウザとのＨＴＴＰセッションにおけるものとは異なる、デバイス上の別の（事前定義された）ポートを使用することができる。ＲＦは、このポートを、ＳＣＷＳ上のＯＰに回送すべきポートとして認識する。ＲＦは、メッセージを直接的にＯＰにリダイレクトすることができ、それによって、ＲＰが、ＯＰとのアソシエーションを確立することを可能にすることができる。ＲＰは、ＯｐｅｎＩＤ認証を実行するために、ブラウザにリダイレクトを発行することもできる。ブラウザは、ＳＣＷＳ上のＯＰにリダイレクトすることができる。ＲＦは、ブラウザからのコールを、ローカルＳＣＷＳに回送できるコールとして認識することができる。ＯＰは、ローカルユーザ認証を実行することができる（ローカルユーザ認証は、安全なＵＩを介することができ、一般にはＰＩＮコードを提供するようにユーザに要求することによって、デバイスを制御するＵＩＣＣ機能の一部として、ＳＣＷＳによって提供することができる）。
【０１８８】
認証の後、ＯＰは、肯定的なアサーションとともに、ブラウザをＲＰにリダイレクトすることができる。ＲＰとＯＰはアソシエーションを確立していることがあるので、ＲＰは、アサーションを自律的に検証することができる。アソシエーションを生成することができない場合は、ＯｐｅｎＩＤの直接検証シナリオを実施することが可能なこともある。この場合、ＲＰは、肯定的なアサーションを受信した後、事前定義されたポート上でＵＥとコンタクトを取ることができ、ＲＦは、要求をＯＰに回送し、ＯＰは、検証要求に回答することができる。
【０１８９】
例示的な一実施形態では、ローカルデバイスにおいて、ＯＰへのアクセスを制限することができる。例えば、ローカルブラウザだけに、アイデンティティについてのアサーションを獲得することを許可することができる。こうすることで、攻撃者が、他のデバイス（ｆｏｒｅｉｇｎ  ｄｅｖｉｃｅ）からアイデンティティアサーションを取り出すことを防ぐことができる。ＲＦは、ＯＰへのインバウンドトラフィックのルーティングを、先行するブラウザ要求に結合することもできる。例えば、ルーティングは、ブラウザが通信する単一のＲＰに対して、限られた期間だけ、アクティブになることができる。
【０１９０】
ＲＦは、それぞれＳＣＷＳおよびＯＰに対する管理タスクを実行するために、ＭＮＯによって使用することもできる。
【０１９１】
４．４．１．１．１  一般的な要件
以下は、ＯｐｅｎＩＤ仕様によって説明されている一般的な要件である。
【０１９２】
（Ｒ−１）ＯｐｅｎＩＤでは、ＲＰは、ステートレス通信モードで動作するか、それともアソシエーションベース通信モードで動作するかを決定することができる。ＲＰについてどんな仮定も行うことはできないので、両方のオプションがＯＰ実施によってサポートされなければならない。
【０１９３】
（Ｒ−２）ステートレスモードでは、ＯＰとＲＰの間で共有秘密は確立されず、ＯＰは、ＲＰがブラウザを介してＯＰからアサーションメッセージを受信した後、ＲＰによって直接的にコンタクトされる。その後、ＲＰは、ＯＰへの直接ＨＴＴＰ（Ｓ）接続を確立し、アサーションメッセージ上のシグネチャを検証するようにＯＰに要求する。
【０１９４】
ＯｐｅｎＩＤ仕様は、１６０ビット鍵長のＨＭＡＣ−ＳＨＡ１と、２５６ビット鍵長のＨＭＡＣ−ＳＨＡ２５６の、２つの異なるタイプの（対称）シグネチャ方式を許容している。対称鍵は、アソシエーションがＲＰによって使用される場合、アソシエーション確立の際に、ＯＰとＲＰの間で交換することができる。秘密の交換は、ディフィ−ヘルマン鍵交換を使用し、その後、ＤＨ−ｋｅｙ−ｖａｌｕｅを用いて共有秘密を暗号化して保護され、またはディフィ−ヘルマンが使用されない場合、接続は、トランスポートレイヤセキュリティによって盗聴者から保護されなければならない。アサーションメッセージ上のＯＰによって発行されたすべてのシグネチャは、言及されたアルゴリズムの１つを使用する対称シグネチャである。例えばグローバルプラットフォームなどの、スマートカードの用語では、この暗号シグネチャ方式を言い表すのに、クリプトグラム（ｃｒｙｐｔｏｇｒａｍ）またはより一般に「データ認証パターン（ＤＡＰ：Ｄａｔａ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｐａｔｔｅｒｎ）」という用語を使用する。
【０１９５】
（Ｒ−３）アソシエーションベースのＯｐｅｎＩＤでは、ＲＰとＯＰは、アソシエーションハンドルによって識別される、共有秘密を確立する。ＲＰは、ブラウザをＯＰにリダイレクトする最初のリダイレクトメッセージに、このアソシエーションハンドルを含める。その後、ＯＰは、アソシエーションハンドルを使用して、このＲＰのための共有秘密を見つけることができ、その後、この秘密を使用して、アサーションメッセージに署名することができる。このメッセージを受信すると、ＲＰは、受信したシグネチャを自律的に検証することができる。
【０１９６】
（Ｒ−４）（Ｒ−１）、（Ｒ−２）、（Ｒ−３）で説明された通信オプションはどちらも、ＲＰから、公衆インターネットを介して到達できるエンティティＥ１への少なくとも１つの直接通信を必要とし、エンティティＥ１は、通常のＯｐｅｎＩＤの場合は、ＯＰサーバである。
【０１９７】
（Ｒ−５）（Ｒ−４）のエンティティＥ１は、アソシエーションベースモードでは、ＯＰサーバとＲＰの間で共有秘密を確立できなければならない。ステートレスモードでは、この秘密は、メッセージに署名をするために、ＯＰが知っていなければならず、またＯＰシグネチャを検証するために、ＲＰによって後でコンタクトされる、この到達可能なエンティティＥ１が知っていなければならない。
【０１９８】
（Ｒ−６）ＯｐｅｎＩＤにおけるシグネチャは、通常はＨＭＡＣ−ＳＨＡ１ベースであり、ＯＰおよび検証当事者は、データに署名し、適切なアルゴリズムを使用してシグネチャを検証できなければならない。
【０１９９】
（Ｒ−７）ＭＮＯは、ＯＰ発見を提供する、ネットワークエンティティＥ２を提供しなければならず、ＯＰ発見は、ＯｐｅｎＩＤ標準によれば、ＨＴＭＬまたはＸＲＤＳ発見によることができる。エンティティＥ２は、ＯｐｅｎＩＤ識別子の一部である、ＤＮＳアドレスにおいて動作しなければならず、例えば、識別子がｈｔｔｐ：／／ｏｐｅｎｉｄ．ｍｎｏ．ｃｏｍ／ｉｄである場合、ＭＮＯは、ｈｔｔｐ：／／ｏｐｅｎｉｄ．ｍｎｏ．ｃｏｍにおいてウェブサービスＥ２を実行しなければならず、すなわち、ＭＮＯは、発見サービスとして動作するために、ドメインおよびサーバを所有しなければならない。発見サービスは、公衆インターネットを介し、軽量とすることができる。エンティティＥ２は、（Ｒ−４）のエンティティＥ１と、両方の機能を提供する共通の物理エンティティ内に共存することができる。Ｅ２は、Ｅ１から分離することができ、その場合、発見プロセスは、ＯｐｅｎＩＤを使用してデバイスを渡り歩くためのオプションのためのエントリポイントを提供する。
【０２００】
（Ｒ−８）（Ｒ−７）のＥ２の（ＤＮＳ）アドレスは、ユーザに一貫した識別子を提供するために、変更すべきではない。
【０２０１】
（Ｒ−９）ＯＰは、少なくともＨＴＴＰを介して、ユーザのブラウザによって到達可能でなければならない。
【０２０２】
（Ｒ−１０）（Ｒ−９）におけるのと同じ接続は、ＨＴＴＰの代わりに、ＨＴＴＰＳを使用することができる。
【０２０３】
（Ｒ−１１）任意選択：ＯＰは、認証ページとして使用されるＨＴＭＬページを作成し、表示できなければならない。実際の認証は規定されていないので、これは任意選択である。認証ページが使用されない場合、アイデンティティの隠れた使用を防ぐために、ＯＰは、ユーザに、ユーザのＯｐｅｎＩＤ識別子が使用されることを少なくとも通知すべきである。しかし、認証ページを表示しないことで、ユーザにより一貫性のあるＳＳＯ感を提供するのに役立つことがあり、例えば、ユーザは、１日につき１回だけ、ＳＣＷＳ上のＯＰから認証を受け、その後、すべての後続の認証は自律的に行われる。
【０２０４】
（Ｒ−１２）任意選択：認証ページが使用され、認証ページが、例えば、ユーザ名およびパスワードなどのデータをユーザから受け取った場合、ＯＰは、このデータを受け入れ、それを処理および検証し、しかるべく振る舞うことができなければならない。
【０２０５】
（Ｒ−１３）任意選択：認証ページが使用される場合、認証ページは、ＲＰによって受信された情報を使用して、例えば、ＲＰの名前および使用される識別子を、テキストもしくはグラフィックアイコンまたは両方の組み合わせで表示するなど、理解しやすい方法で、ユーザに追加情報を表示することができる。
【０２０６】
（Ｒ−１４）任意選択：認証ページが使用される場合、認証ページは、ユーザが合法的ＯＰと通信していることを示す、ユーザ向けのインジケータとして使用される、（視覚的）秘密を含むことができる。
【０２０７】
４．４．１．１．２  ＯｐｅｎＩＤにおいてＳＣＷＳを使用する実施についての実施形態
先のセクションでは、ＯｐｅｎＩＤ標準によって定められた一般的な要件について説明した。本セクションでは、上で説明されたＯｐｅｎＩＤ要件内で、ＳＣＷＳを使用してローカルＯＰを実施するための実施形態について説明する。
【０２０８】
例示的な一実施形態では、ＳＣＷＳは、公衆インターネットから直接的に到達可能でないことがあり、すなわち、ＲＰは、ＳＣＷＳ上のＯＰと直接的にコンタクトを取ることができない。要件（Ｒ−１）、（Ｒ−２）、（Ｒ−３）を考えると、インダイレクションを使用することができる。例えば、ＭＮＯは、公衆インターネットを介して到達可能であり、ＳＣＷＳに関連付けられたＯＰと秘密を共有することができる、ウェブサービスを提供することができる（本文書の分割ＯＰについてのセクションを参照）。このウェブサービスは、この秘密をＲＰとも共有することができ、したがって、ＲＰとＳＣＷＳに関連付けられたＯＰとの間の共有秘密を確立することができる。別の実施形態では、ＲＦは、ＳＣＷＳ上のＯＰに要求を回送することができる。
【０２０９】
ＳＣＷＳへの通信は、ＳＣＷＳおよび関連アプレットのリモート更新など、リモート管理インタフェースを経由した、ＨＴＴＰ（Ｓ）を介する、ＭＮＯからのものと、ローカルＨＴＴＰ（Ｓ）を介する、ハンドセットのブラウザからのものとすることができる。ＯｐｅｎＩＤ通信のために、ローカル接続インタフェースを使用することができる。加えて、ローカル接続は、ＳＣＷＳおよびＯＰと通信するために使用できる、一般的なＨＴＴＰ（Ｓ）インタフェースとしての機能を果たすこともできる。
【０２１０】
ＥＴＳＩ  ＳＣＰは、ローカルアクセスだけに制限しなくてよい、ＴＣＰ／ＩＰ（９）を介するスマートカードへのアクセスを定義した。例えば、外部エンティティからＳＣＷＳへの制限されたアクセスは、技術的問題とはなり得ないが、代わりに、ＳＣＷＳの現在の標準的な仕様によれば、デバイス内部のルーティング機能における制限となり得る。ＳＣＷＳへの直接ＨＴＴＰアクセスは、ＳＣＷＳの将来のリリースにおいて実施されるであろう。そのようなアクセスは、管理アクセスとして意図されなくてよい。例えば、ＯｐｅｎＩＤ動作の場合、ＲＰは、ＳＣＷＳによってサービスされるウェブページ（ＯＰサーバロジックを実施する動的アプレット）にアクセスしなければならないことがある。
【０２１１】
４．４．１．２  ＳＣＷＳに関連付けられたＯＰを実施するための追加要件および導出要件を扱うための実施形態
以下の実施形態は、ＯＰがＵＩＣＣ上で実施され、ＳＣＷＳに関連付けられる場合に、追加要件を生じさせることがある。
【０２１２】
（ＲＳＣＷＳ−１）例示的な一実施形態では、ＭＮＯは、ＳＣＷＳに関連付けられたローカルＯＰおよび任意選択的にＲＰとともに、ＯｐｅｎＩＤプロトコルのための秘密を生成し、共有し、分配することができる、サポートＯＰサーバ機能（ＯＰＳＦ）を実施しなければならない。
【０２１３】
サポートＯＰ機能は、ＯｐｅｎＩＤアサーション上のシグネチャにおいて使用される共有秘密のための、ＲＰとＵＥ上のローカルＯＰエンティティとの間のネゴシエーショントラステッドパーティ（ｎｅｇｏｔｉａｔｉｎｇ  ｔｒｕｓｔｅｄ  ｐａｒｔｙ）としての役割を果たさなければならないことがある。このサポート機能は、（アソシエーションが使用される場合は）アソシエーションプロセスを開始するために、またはＲＰから要求があったときはローカルＯＰからのシグネチャを確認するために、ＲＰにＨＴＴＰ（Ｓ）インタフェースを提供することができる。したがって、サポート機能は、公衆インターネットを介して到達可能とすることができ、加えて、この機能は、秘密を交換するために、ローカルＯＰと通信できなければならない。ローカルＯＰとのこの通信は、少なくとも、ユーザが訪れることを望むＲＰ毎に１回、発生しなければならないことがある。例示的な一実施形態では、ローカルＯＰは、ＭＮＯによって管理および維持される。ＭＮＯは、共有秘密を更新するために、ローカルＯＰ／ＳＣＷＳと通信することができ、ＯＭＡ  ＳＣＷＳ標準で十分とすることができる。非ＭＮＯのリモートＯｐｅｎＩＤアイデンティティプロバイダサービスが、スマートカード上のローカルＯＰを管理し、それと通信する、別の例示的な実施形態では、グローバルプラットフォーム標準を使用することができる。
【０２１４】
通常、ＯＰとＲＰの間で、ＲＰ毎に新しい（対称）秘密を確立することができる。ユーザがＯｐｅｎＩＤログインを使用して訪れるＲＰを制限することは困難であるので、ユーザが将来訪れることを望むすべてのＲＰに、これらの共有秘密を事前提供することは非常に困難である。ＵＩＣＣにおいて、各ＲＰのために（例えば、シード値から秘密を導出することによって）秘密が都度生成される場合、この秘密は、ＲＰと共有することができるが、それについては、このオプションについて説明する、後のセクションにおけるプロトコルフローを参照されたい。
【０２１５】
（ＲＳＣＷＳ−２）別の例示的な実施形態では、（ＲＳＣＷＳ−１）のＭＮＯ運用のネットワークエンティティは、異なるチャネルおよび通信方法を使用して、ＳＣＷＳに関連付けられたＯＰにおいて秘密を確立し、それらをＲＰに分配することができる。ＭＮＯからＲＰへの通信は、ＯｐｅｎＩＤプロトコルによって、ＨＴＴＰベースの通信に限定される。ＭＮＯからＳＣＷＳに関連付けられたＯＰへの通信は、保護されたＳＭＳ−ＰＰを使用することができ、または例えばＧＢＡによってブートストラップすること、および／もしくはＨＴＴＰ（Ｓ）ＳＣＷＳリモート管理インタフェースなど、安全な通信プロトコルを使用することができる。
【０２１６】
（ＲＳＣＷＳ−３）別の例示的な実施形態では、ＳＣＷＳに関連付けられたローカルＯＰは、（ＲＳＣＷＳ−１）のＭＮＯエンティティとスマートカードの間で共有される秘密にアクセスしなければならない。これらの秘密は、ネットワーク固有の鍵ではないが、ＯｐｅｎＩＤプロトコルのためにだけ使用され、必要な場合には取り消して、ＯＴＡ手法を介して再確立することができる。秘密は、対称鍵であり、ＲＰから送信されたＨＴＴＰパラメータに署名するために、ＯＰによって使用される。
【０２１７】
ＯＰがローカルＯＰを所有する場合、ＯＰは、（ＧＰおよび／またはＯＭＡによる確認に従って）ローカルＯＰに対する鍵を確立できるので、ＭＮＯがこれらの秘密を分配する必要がないことがある。しかし、ＭＮＯは、ＳＣＷＳのリモート管理のために秘密を必要とすることがあり、そのため、ＭＮＯが、そのルートを介して、ローカルＯＰのための鍵を確立することも可能である。
【０２１８】
（ＲＳＣＷＳ−４）別の例示的な実施形態では、（ＲＳＣＷＳ−３）の秘密の保護は、ハンドセット上の他のアプリケーションから秘密を読み取ることができないような、また秘密がスマートカード環境内のそのアプリケーション空間の外部にさらされないように、秘密に基づいて動作するすべてのアルゴリズムが、スマートカードによって提供される安全な環境内で動作するようなものであるべきである。
【０２１９】
ローカルＯＰがグローバルプラットフォームアプリケーションである場合、鍵は、ローカルＯＰのセキュリティドメインによって保存することができ、ローカルＯＰのセキュリティドメインは、ローカルＯＰのための暗号操作を実行する。
【０２２０】
（ＲＳＣＷＳ−５）別の例示的な実施形態では、ＳＣＷＳに関連付けられたローカルＯＰは、ＯＰによる将来の使用のために、秘密とアソシエーションハンドルを保存することができ、その結果、ＲＰを再び訪れる場合、ＭＮＯからＯＰへの追加のＯＴＡトラフィックを削減することができる。
【０２２１】
（ＲＳＣＷＳ−６）別の例示的な実施形態では、ＳＣＷＳに関連付けられたローカルＯＰは、合法的なローカルＯＰだけによって示すことができる、スマートカード内に安全に保存された秘密イメージなどの、追加のセキュリティ特徴を、ユーザに示される認証ページにおいて使用することができる。
【０２２２】
（ＲＳＣＷＳ−７）別の例示的な実施形態では、ＳＣＷＳに関連付けられたＯＰは、特にＲＰから来たパラメータに署名するために、ＨＴＴＰ要求の処理およびＨＴＭＬページの表示にとどまらない、いくつかのアプリケーションロジックを実施しなければならない。
【０２２３】
（ＲＳＣＷＳ−８）別の例示的な実施形態では、ＳＣＷＳに関連付けられたＯＰによって秘密が生成される、実施オプションが使用される場合、（ＲＳＣＷＳ−７）のアプリケーションロジックは、対称秘密を生成でき、それらを安全にＭＮＯネットワーク内のエンティティに伝達できなければならない。
【０２２４】
（ＲＳＣＷＳ−９）別の例示的な実施形態では、（ＲＳＣＷＳ−７）および（ＲＳＣＷＳ−８）のアプリケーションロジックは、ｊａｖａ（登録商標）アプレットまたはサーブレットで実施することができ、ｊａｖａ（登録商標）アプレットまたはサーブレットは、ＳＣＷＳによって動的にコールされて、必要な動作を実行し、その後、制御をＳＣＷＳに戻す。アプレット／サーブレットは、ＵＩＣＣ内の安全な環境において動作すべきである。
【０２２５】
（ＲＳＣＷＳ−１０）別の例示的な実施形態では、ＳＣＷＳは、ＲＰにわたってユーザのＯｐｅｎＩＤアイデンティティ使用を追跡することによって生成できるユーザプロファイルに基づいて、例えば広告バナーなどの、ＭＮＯから取り出された情報を表示した、認証のための動的なウェブページを提供することができる。ＭＮＯは、ＳＣＷＳ上で、マーケティング／広告目的の「ウェブスペース」をＲＰに提供することができる。これは、ＳＣＷＳ上のＯＰに別の価値をもたらす。
【０２２６】
（ＲＳＣＷＳ−１１）別の例示的な実施形態では、具体的なシナリオにおいて、ＳＣＷＳでは制限が強すぎることが分かった場合、別のオプションは、ＳＣＷＳの機能を模倣するＪａｖａ（登録商標）Ｃａｒｄアプリケーションに基づいて、アプリケーションロジックを実施することである。アプリケーションは、着信ＨＴＴＰ要求を受け入れ、ユーザに認証インタフェースを提供し（例えばＰＩＮ入力）、シグネチャを計算し、ＨＴＴＰ応答を生成し、ブラウザに応答を返す。このシナリオにおいて、ＢＯＮＤＩフレームワークが、ブラウザとＳＣＷＳに取って代わったスマートカードアプリケーションとの間の間接通信部分で役立ち得るかどうかを探ることができる。
【０２２７】
４．４．１．３  命名規約
エンティティに対して、以下の命名規約が適用される。
【０２２８】
●ＳＣＷＳに関連付けられたＯＰ：署名されたアサーションメッセージを発行し、それらをユーザのブラウザを介してＲＰに送信する、ローカルＯｐｅｎＩＤアイデンティティプロバイダ。ＳＣＷＳを、したがってＯＰをホストするスマートカードは、ＭＮＯと、したがってすべてのＭＮＯ関連のエンティティと関係を有すると仮定される。
【０２２９】
●ＲＰ：ユーザにＯｐｅｎＩＤを使用したログインを提供する任意のウェブサイトとすることができる依拠当事者。ＲＰは、他のすべてのエンティティから完全に独立であり、したがって、ＲＰに追加の要件を課すことはできず、ＲＰについてのＯｐｅｎＩＤプロトコルフローに対する変更は生じることができない。ＯＰは、ＲＰが使用することを選んだ通信モードは（ステートレスまたはアソシエーションベースの）どちらであれサポートしなければならない。ＭＮＯが、ユーザはあるＲＰを使用すべきではないと決定した場合、ユーザは依然として別のアイデンティティを使用できるので、ＭＮＯは、これらのＲＰに対するＯｐｅｎＩＤアクセスを拒否することによって、これらのサイトへのアクセスを拒否することはできない。ＭＮＯは、一般に帯域幅消費サイトへのアクセスをブロックする追加の手段を使用して、ＲＰへのアクセスを制限できるにすぎない。
【０２３０】
●ＯＰ−Ａｇｇ：ＯＰ−Ａｇｇは、（Ｒ−７）のエンティティＥ２を実施し、ＲＰに発見サービスを提供する。
【０２３１】
●ＯＰＳＦ：ＯＰサーバ機能（ＯＰＳＦ）は、（ＲＳＣＷＳ−１）のＳＣＷＳに関連付けられたＯＰおよび任意選択的にＲＰとともに、ＯｐｅｎＩＤプロトコルのための秘密を生成し、共有し、分配することができる、サポートＯＰ機能を実施する。ＯＰＳＦとＳＣＷＳに関連付けられたＯＰとは、ＲＰの観点からは、それらが単一のエンティティであるかのように振る舞っている。ＯＰＳＦは、ＳＣＷＳに関連付けられたＯＰによって発行されたシグネチャを検証することができ、公衆インターネットを介してＲＰから直接的に到達可能である。デバイス上のブラウザは、ＯＰＳＦのアドレスがＳＣＷＳに関連付けられたローカルＯＰにマッピングされるように、デバイス上のローカルＤＮＳ解決キャッシュを変更することによって、ＳＣＷＳに関連付けられたＯＰにリダイレクトされる。
【０２３２】
●ブラウザ：ＳＣＷＳに関連付けられたＯＰへの、およびＳＣＷＳに関連付けられたＯＰからのルーティングおよびメッセージング機能を明示的にするために、プロトコルフロー図内に示される。それ以外では、ブラウザは、ユーザ認証を表示し、受信するためのフロントエンドにすぎない。
【０２３３】
４．４．１．４  ＳＣＷＳ／ＵＩＣＣ上のＯＰを実施するための実施形態
本セクションは、標準的なＯｐｅｎＩＤ認証プロトコルに準拠したままであることを試みながら、上で説明した一般的な概念から導かれる実施形態を探求する。ステートレスモードのプロトコルとアソシエーションベースモードのプロトコルの２つの実施形態が以下で説明され、第２の実施形態は、認証プロセスを統合するために、ＯＰカード機能とネットワークサイドのサーバ機能との間の共有鍵を含む暗号を前提とし、それを利用する。
【０２３４】
４．４．１．４．１  プロトコルフロー説明
以下のセクションでは、ＳＣＷＳに関連付けられたＯＰを実施するためのプロトコルフローの例示的な実施形態について説明する。例示的な一実施形態では、上の（Ｒ−１）で述べたように、（ステートレスとアソシエーションベースの）両方のシナリオをカバーすることができる。プロトコルフロー図と、実施形態の呼フローの説明が、以下で提供される。一般的なＯｐｅｎＩＤプロトコルが、図３に関連して説明される。
【０２３５】
複数のオプションが、図２４〜図２７に示され、対応する記述において説明される。
【０２３６】
４．４．１．４．２  ステートレスモードを使用するＲＰのためのプロトコルフロー
図２４は、ＲＰがステートレスモードを使用して、ＯｐｅｎＩＤ認証を実行することを可能にするためのプロトコルフローの例示的な一実施形態を示している。例えば、ＲＰは、ステートレスモードを使用して、ＯｐｅｎＩＤユーザ認証を実行することができる。図２４に示されるように、
５３０：ユーザは、ＲＰウェブサイトを訪れ、自らのＯｐｅｎＩＤ識別子を入力することができる。例えば、ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙ。
【０２３７】
５３５：ブラウザは、ＯｐｅｎＩＤ識別子を含むＨＴＴＰメッセージを、ＲＰウェブサイトに送信することができる。
【０２３８】
５４０：ＲＰは、ＨＴＴＰ／ＨＴＭＬベースのＯｐｅｎＩＤ「シンプル」発見を使用することができ、公衆インターネットを介してＯＰ−Ａｇｇとコンタクトを取り、ＯｐｅｎＩＤ識別子のためのアイデンティティページを取り出す。例えば、ＨＴＴＰ  ＧＥＴ  ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙ。
【０２３９】
５４５：ＯＰ−ａｇｇは、要求を受信し、例えば、
＜ｌｉｎｋ  ｒｅｌ＝“ｏｐｅｎｉｄ．ｓｅｒｖｅｒ”ｈｒｅｆ＝ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｓｅｒｖｅｒ．ｃｇｉ＞
を含めることによって、ＯＰＳＦのインターネットアドレスを含むＨＴＭＬページによって応答することができる。
【０２４０】
ＯＰＳＦは、ＲＰに対して標準的なＯｐｅｎＩＤアイデンティティプロバイダウェブサービスのように振る舞うことができ、すなわち、ＯＰＳＦは、ＲＰからの要求時に、アサーションメッセージ上の（ローカルＯＰによって発行された）シグネチャを検証することができる。ＯＰＳＦは、公衆インターネットを介して到達可能とすることができ、ｈｔｔｐ：／／ｏｐ．ｏｒｇによって到達可能な、ｏｐ．ｏｒｇなどの、ＤＮＳ名を有すると仮定することができる。外部世界は、スマートカードのＩＰアドレスを知ることができないので、このインダイレクションＯＰ−ａｇｇおよびＯＰＳＦが、通信のために使用される。
【０２４１】
ＯＰＳＦのアドレスは、ＯＰ−ａｇｇのアドレスと異なることがある。
ａ．オプション１：この項目は、必須ではなく、オプションを提示する。このオプションがここで使用されない場合、５７０におけるオプション２が、プロトコルの後のフェーズには存在することができる。
ｉ．ＯＰ−ａｇｇは、ＲＰ識別子とＯｐｅｎＩＤユーザ識別子をＯＰＳＦに送信することによって、ＲＰからの要求をＯＰＳＦに通知する。
ｉｉ．ＯＰＳＦは、ローカルデータベースにおいて、このＲＰおよびＯｐｅｎＩＤアイデンティティのための秘密を検索しようと試みることができる。
ｉｉｉ．秘密が見つからない場合、ＯＰＳＦは、新しい秘密とアソシエーションハンドルを生成し、両方をＳＣＷＳに関連付けられたＯＰに送信し、次に、ＳＣＷＳに関連付けられたＯＰが、それらを保存する。
ｉｖ．秘密が見つかった場合、ＯＰＳＦは、シグネチャ検証のために、それを後で使用する。秘密がＯＰＳＦによってローカルデータベース内で見つけられた場合、ＳＣＷＳに関連付けられたＯＰは、このＲＰとの先のプロトコル実行において、この秘密とアソシエーションハンドルをすでに受信し、したがって、それを保存できており、それを再利用すると仮定される。
【０２４２】
シグネチャを検証するためにＯＰＳＦによって使用される秘密は、シグネチャを生成するためにＳＣＷＳに関連付けられたＯＰによって使用される秘密と同じとすることができる。シグネチャの新しさは、次のステップで挿入されるＲＰノンスによって保証することができ、ＲＰノンスは、シグネチャの一部であることが要求される。ＯｐｅｎＩＤ仕様は、署名秘密自体の新しさについては何も言わないままである。秘密の暗号強度を保証すること、秘密の秘密性を維持すること、およびそれが必要な場合は、秘密の新しさを保証することは、ＯＰの責任である。ＯＰＳＦまたはＳＣＷＳに関連付けられたＯＰは、この目的のために、署名秘密に対して、限られた存続期間または使用カウントを実施することができる。秘密共有のためのさらなるオプションについては、セクション４．４．１．４．３．１において説明する。
【０２４３】
５５０：ＲＰは、ＯＰＳＦのアドレスを受信し、例えば、ｎｏｎｃｅ＝１２３１２３、ｓｅｓｓｉｏｎ＝Ｕｓｅｒなどと、ノンスおよびセッション識別子を生成することができる。ＲＰは、ユーザ認証後にブラウザをどのＵＲＬにリダイレクトすべきかをＯＰに命じる、戻り先パラメータを編集することができる。ＲＰは、以下のパラメータを含むことができる、ブラウザをＯＰサーバアドレスにリダイレクトする、ＨＴＴＰリダイレクトを発行することができる。
ｏｐｅｎｉｄ．ｍｏｄｅ＝ｃｈｅｃｋｅｄ＿ｓｅｔｕｐ、
ｏｐｅｎｉｄ．ｉｄｅｎｔｉｔｙ＝ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙ、
ｏｐｅｎｉｄ．ｒｅｔｕｒｎ＿ｔｏ＝ｈｔｔｐ：／／ｒｐ．ｏｒｇ／ｒｅｔｕｒｎ．ｃｇｉ？ｓｅｓｓｉｏｎ＝Ｕｓｅｒ＆ｎｏｎｃｅ＝１２３１２３
【０２４４】
５５５：ブラウザは、リダイレクトを受信することができ、リダイレクトメッセージ内のＲＰによって指定されたＵＲＬへの接続をオープンする。
【０２４５】
５６０：例えば、エントリｈｔｔｐ：／／ｏｐ．ｏｒｇ＝＝１２７．０．０．１を有するホストファイルを使用することによって、ＯＰＳＦのＵＲＬをＳＣＷＳローカルＩＰアドレスにマッピングすることができる、変更されたローカルＤＮＳルックアップテーブルを用いる場合、ブラウザは、ＳＣＷＳに関連付けられたローカルＯＰにリダイレクトすることができ、５５０のパラメータを含むＨＴＴＰ要求を発行する。
【０２４６】
変更されたローカルＤＮＳルックアップテーブルは、デバイス上で使用することができ、ＵＲＬ  ｈｔｔｐ：／／ｏｐ．ｏｒｇがＳＣＷＳのローカルＩＰアドレスにあるとデバイスに思わせる。したがって、ブラウザは、（公衆インターネットを介して到達可能な、ＵＲＬ  ｈｔｔｐ：／／ｏｐ．ｏｒｇにある）ＯＰＳＦに接続する代わりに、ＳＣＷＳ／ローカルＯＰへの接続をオープンすることができる。
【０２４７】
５６５：以下は、認証トラフィックをローカルに保つことを保証するために実行することができるが、これらのステップは、必須ではなく、ＯｐｅｎＩＤプロトコル仕様によって規定されていない。
ａ．ＳＣＷＳに関連付けられたＯＰは、ローカル認証ページを表示することができる。
ｂ．ユーザは、例えば、ユーザ名およびパスワードなど、自らの認証用資格証明書を入力することができる。
ｃ．ＳＣＷＳに関連付けられたＯＰは、資格証明書を検証することができる。
【０２４８】
５７０：５４５のオプション１が使用された場合、ＳＣＷＳに関連付けられたＯＰは、ＯＰＳＦから新たに取り出された、または秘密およびアソシエーションハンドルのローカル記憶から取り出された、ＳＣＷＳに関連付けられたＯＰとＯＰＳＦとの間で共有される、秘密およびアソシエーションハンドルを有することができる。
ａ．オプション２、５４５においてオプション１が使用されなかった場合、
ｉ．ＳＣＷＳに関連付けられたＯＰは、新しい秘密およびアソシエーションハンドルを生成することができる。
ｉｉ．ＳＣＷＳに関連付けられたＯＰは、この秘密およびアソシエーションハンドルを、ＳＣＷＳを介してＯＰＳＦに送信することができる。
ｉｉｉ．ＯＰＳＦは、この秘密を受信し、それを将来のアクセスのために安全に保存することができる。
【０２４９】
目標は、例えば、ＯＰＳＦとローカルＯＰの間で秘密を共有することとすることができ、したがって、ローカルＯＰが秘密を生成した場合、生成後に秘密をＯＰＳＦに伝達することができる。
【０２５０】
ツールキット対応のローカルＯＰは、ＳＣＷＳをバイパスして、ハンドセットとプロアクティブに（ｐｒｏａｃｔｉｖｅｌｙ）通信するために、ＣＡＴを使用することができる。メッセージは、（例えば、ＳＭＳ−ＰＰベアラを介してＯＰＳＦに送信するために）標準的なＯＴＡ通りにフォーマットすることができる。しかし、これは、ＯＰＳＦが、ＭＮＯのＯＴＡシステムを介して、カードと通信することを必要とすることがある。あるいは、ＢＩＰゲートウェイが、ツールキットメッセージのペイロードを抽出することができ、ハンドセットが、ＴＣＰ／ＩＰを使用して、それをＯＰＳＦに送信することができる。しかし、これもやはり、メッセージがＭＮＯのＯＴＡサーバを通過することを必要とすることがある。カードがＩＰアドレスを有せず、ＴＣＰ／ＩＰをサポートしない場合、ＢＩＰを使用することができる。
【０２５１】
５７５：ＳＣＷＳに関連付けられたＯＰは、戻り先、アイデンティティ、およびモードなどのパラメータに対するシグネチャを計算する。
【０２５２】
５８０：ＳＣＷＳに関連付けられたＯＰは、ステップ５５０においてＲＰから受信したパラメータを含み、追加的に、以下のものも、すなわち、
ｏｐｅｎｉｄ．ｓｉｇｎｅｄパラメータ内の署名されたパラメータのリスト、
ｏｐｅｎｉｄ．ａｓｓｏｃ＿ｈａｎｄｌｅパラメータ内のアソシエーションハンドル、および
ｏｐｅｎｉｄ．ｓｉｇパラメータ内のシグネチャ（ｂａｓｅ６４符号化）
も含む、ＨＴＴＰリダイレクトメッセージをブラウザに送信する。
【０２５３】
このメッセージは、ブラウザをＲＰの戻り先ＵＲＬにリダイレクトするために使用される。
【０２５４】
５８５：ブラウザが、ユーザをＲＰの戻り先ＵＲＬにリダイレクトする。
【０２５５】
５９０：ＲＰは、署名されたアサーションメッセージを受信し、ＨＴＴＰ（Ｓ）ベースの公衆インターネットを介する直接通信によって、ＯＰＳＦとともに検証手順に携わる。
【０２５６】
５９５：ＲＰは、５８０のＳＣＷＳに関連付けられたＯＰから受信したパラメータを含む、ＨＴＴＰ  ＰＯＳＴメッセージを発行する。
【０２５７】
６００：ＯＰＳＦは、共有鍵を使用して、受信したデータ上のシグネチャを検証する。
【０２５８】
６０５：ＯＰＳＦは、シグネチャ検証が成功した場合、ｉｓ＿ｖａｌｉｄ：ｔｒｕｅを返す。
【０２５９】
６１０：ＲＰからは、ユーザは、今ではｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙとして識別されている。
【０２６０】
６１５：ブラウザは、ＲＰのＨＴＭＬページを表示する。
【０２６１】
６２０：ユーザは、ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙとして、ＲＰにおいてログインする。
【０２６２】
４．４．１．４．３  ステートレスモードについての追加の実施形態
４．４．１．４．３．１  秘密を共有する
ＯｐｅｎＩＤのステートレスモードは、ＲＰが署名されたステートメントをＯＰから受信するが、ＲＰは署名のために使用された秘密を知らないので、自らこのシグネチャを検証することができないというプロセスによって特徴付けられる。ステートレスモードでは、ＲＰは、このシグネチャを検証するために、再びＯＰとコンタクトを取る。（ＳＣＷＳに関連付けられた）シグネチャ発行ＯＰとシグネチャ検査ＯＰ（ＯＰＳＦ）は、ＲＰの観点からは同じエンティティに見えるので、それらは、秘密を共有できなければならない。これには、いくつかのオプションが適用される。
【０２６３】
４．４．１．４．３．１．１  オプション１：ＯＰＳＦが秘密を管理する
本セクションでは、図２４の４５４に関して上で説明されたオプション１を利用する、実施形態のいくつかについて概説する。ＯＰ−ａｇｇは、発見実行が行われると直ちに、ＯＰＳＦに通知することができる。その後、ＯＰＳＦは、秘密およびアソシエーションハンドルを生成することができ、両方をＳＣＷＳに関連付けられたＯＰに送信する。ＯＰＳＦがＭＮＯの一部である場合、ＳＣＷＳリモート管理プロセスを使用することができる。ＯＰＳＦがＭＮＯの一部でない場合、グローバルプラットフォーム方法は、ハンドセットがカード上のローカルＯＰをサポートすることを前提として、ＯＰＳＦが、カード上のローカルＯＰに鍵を送信することを可能にする。オプション１では、ＯＰＳＦにおいて中央秘密／アソシエーションハンドルデータベースを実施することを可能にすることができ、ＯＰＳＦは、ＯｐｅｎＩＤ識別子、ＲＰから、アソシエーションハンドルおよび秘密へのマッピングを、データベース内に保存する。ＯＰＳＦは、通知されると直ちに、識別子およびＲＰについて検索を実行することができ、秘密が見つからない場合、ＯＰＳＦは、新しい秘密およびアソシエーションハンドルを生成し、それをＳＣＷＳ上のＯＰに送信することができる。この例示的な実施形態は、ＳＣＷＳ上のＯＰが、ＲＰのための秘密およびアソシエーションハンドルを保存できること、ならびにＳＣＷＳ上のＯＰが、ＯＰＳＦがシグネチャ検証のために後で使用するのと同じ秘密を、署名のために使用することを仮定する。その場合、この手順は、ＲＰ毎に１回実行される。
【０２６４】
４．４．１．４．３．１．２  オプション２：ＳＣＷＳ上のＰＯが新しい秘密を生成する
本セクションでは、図２４に関して上で説明されたオプション２を利用する、実施形態のいくつかについて概説する。ＳＣＷＳに関連付けられたＯＰは、ＲＰからパラメータを受信すると直ちに、新しいアソシエーションハンドルおよび秘密を生成することができる。ＳＣＷＳに関連付けられたＯＰは、秘密を使用して、パラメータに署名することができ、その後、この秘密およびアソシエーションハンドルをＯＰＳＦに送信する。ＳＣＷＳ上のＯＰがこの秘密を保存できる場合も、ＯＰＳＦは、将来使用するために、この秘密およびアソシエーションハンドルを保存すると決定することができる。その場合、この手順は、ＲＰ毎に１回だけ実行すればよい。これは、新しい秘密がＯＰＳＦによってのみ暗号解除できるように、ローカルＯＰが新しい秘密を暗号化することを可能にできる、永続的な秘密がすでに存在することを仮定している。この暗号化は、ローカルＯＰが、トランスポートレイヤセキュリティを必要とせずに、新しい秘密をＯＰＳＦに送信することを可能にする。
【０２６５】
４．４．１．４．３．１．３  オプション３：共通のシードから導出される秘密
例示的な一実施形態では、ＳＣＷＳに関連付けられたＯＰとＯＰＳＦが、異なるＲＰとともに使用される秘密とは独立に前もって確立できる、共通のシードを共有する場合、別の変形を使用することができる。ＳＣＷＳ上のＯＰとＯＰＳＦが、共通のシード値Ｓを共有すると仮定する。Ｓと、ＳＣＷＳ上のＯＰとＯＰＳＦが通信中に受信する、現在のＯｐｅｎＩＤ実行を一意的に識別する１つの情報Ｐとに、暗号関数を適用することによって、ＳＣＷＳ上のＯＰとＯＰＳＦは、同じ秘密を所有するようになることができる。共有秘密は、例えば、ｋ＝ＳＨＡ１（Ｓ｜Ｐ）のように共有秘密を計算することなど、ＳとＰの連結に対してハッシュ関数を適用することによって、計算することができる。ＳＣＷＳに関連付けられたＯＰとＯＰＳＦの両方が受信する情報Ｐに注目すると、ＲＰ  ＩＰアドレスとＯｐｅｎＩＤ識別子、ＲＰから受信したパラメータセット全体、パラメータのサブセット、またはこれらの任意の組み合わせなど、異なる候補を考えることができる。
【０２６６】
そのような導出される秘密は、鍵導出関数におけるように、共通のパターンに従って事前生成することもでき、その場合、秘密およびアソシエーションハンドルは、事前生成されており、必要なときに使用することができる。
【０２６７】
４．４．１．４．３．１．４  さらなるオプション
さらなるオプションを適用することができ、例えば、ＯＰとＯＰＳＦが同じ秘密を共有する場合、類似した状態をもたらすことができる。
【０２６８】
４．４．１．４．３．２  認証オプション
実際のユーザ認証は、ＯｐｅｎＩＤ仕様では規定されていないので、異なるオプションが適用される。
【０２６９】
４．４．１．４．３．２．１  トラステッドＯｐｅｎＩＤの概念の統合についての実施形態
例示的な一実施形態では、デバイスは、例えば、ＴＰＭを使用することによって、ソフトウェアについての測定値を生成することができる。その後、これらの測定値は、認証セッション中に、ＳＣＷＳに関連付けられたＯＰに伝送することができる。ローカルＯＰは、測定値と比較するために使用される基準値を有することができ、報告された測定値が、これらの知られた良好な基準値に一致する場合に限って、認証は成功することができる。
【０２７０】
４．４．１．４．３．２．２  認証用資格証明書を使用してＯｐｅｎＩＤ秘密をロック解除する
例示的な一実施形態では、ユーザとＯＰＳＦは、ＰＩＮコードなど、共通の秘密を共有することができる。４．４．１．４．３．１．３で説明された実施形態と同様に、ユーザが資格証明書を入力するたびに、ＰＩＮコードを使用して、秘密を計算することができる。そのようなＰＩＮは、帯域外の登録プロセスによって共有することができる。
【０２７１】
４．４．１．４．３．２．３  ユーザ認証をデバイスおよびネットワーク認証に結び付ける
スマートカード（およびＳＣＷＳ）が、バイオメトリックユーザ認証をサポートする場合、ＯｐｅｎＩＤ認証を、ユーザによって提供されたバイオメトリック識別子に結び付けることができる。ＯＰはローカルである（スマートカード上にある）ので、ＯＰは、バイオメトリック参照データに直接アクセスすることができ、バイオメトリックデータが、ＭＮＯまたは別のインターネットエンティティにさらされることはあり得ない。
【０２７２】
例示的な一実施形態では、通信デバイスをネットワークに接続することができる。デバイスは、資格証明書を保持することができ、資格証明書は、デバイス上またはＵＩＣＣなどのスマートカード上に安全に保存することができ、ネットワークに対するデバイスの認証を可能にするために使用される。ユーザだけがアクセスできる、デバイスおよびネットワークサービスへの安全なアクセスを提供するため、デバイスにバイオメトリックスキャナを含ませて、完全な３因子認証メカニズム（ｆｕｌｌ  ｔｈｒｅｅ−ｆａｃｔｏｒ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｍｅｃｈａｎｉｓｍ）を提供することができ、完全な３因子認証メカニズムは、バイオメトリックを、ｐｉｎまたはパスワードなどユーザが知っている何か、およびセキュリティトークンジェネレータフォブ（ｓｅｃｕｒｉｔｙ  ｔｏｋｅｎ  ｇｅｎｅｒａｔｏｒ  ｆｏｂ）などユーザが有する何かと組み合わせる。
【０２７３】
デバイス認証のための先に説明された実施形態と組み合わせて、ユーザ認証も、認証手順に組み込むことができる。ユーザが、これらの認証メカニズムの組み合わせを使用して、デバイスに対して自らを認証した後、デバイスは、ユーザ認証が正しいかどうかをチェックすることができ、すなわち、最初にユーザを認証し、次に、結果がチェック合格の場合、チェックされたユーザ認証情報（例えば、原形式、ハッシュ形式、または他の圧縮形式の、ユーザ認証で使用されたユーザの資格証明書）を、デバイスがその内部に保持するデバイス資格証明書と組み合わせ、その後、組み合わされ、結び付けられた資格証明書情報をネットワークに送信する。
【０２７４】
ネットワークは、組み合わされた資格証明書を受信すると、その後、デバイスが合法ユーザによって使用されているかどうか、およびデバイス自体が合法的なものかどうかを評価することができる。
【０２７５】
デバイスがそれ自体で、ユーザの真正性をチェックすることが可能でない場合、デバイスは、何か他のことを行うことをユーザに許可せずに、組み合わされた資格証明書情報を最初にネットワークに送信することができ、ネットワークが組み合わされた資格証明書情報を評価し、ユーザが認証されたことを伝えてきた後になって初めて、デバイスの他の機能にアクセスすることをユーザに許可することができる。その後、デバイスは、デバイスの他の機能にアクセスすることをユーザに許可することができる。
【０２７６】
この手法は、最も厳格なセキュリティを提供することができるが、認証で使用される因子の数は、実施されるセキュリティ方針に基づいて、緩和することができる。
認証メカニズム
実施形態に組み込むことができる認証シナリオは、以下のことを含む。
【０２７７】
１．ユーザは、３つすべての形式の認証情報をデバイスに提供し、デバイスは、デバイスに対してユーザを認証し、認証が成功すると、デバイスの機能およびデバイス上に保持されたデータへのアクセスを提供する。その後、デバイスは、通常の方法でネットワークに対して認証を行い、デバイス上で利用可能なネットワークベースのサービスをユーザに提供する。
【０２７８】
２．ユーザは、３つすべての形式の認証情報をデバイスに提供し、その後、デバイスは、情報のいくつかまたはすべてを用いて、デバイスに対してユーザを認証し、認証が成功すると、認証情報のいくつかまたはすべてを、デバイス上に保持された資格証明書情報と一緒に、ネットワークによるさらなる認証のために、ネットワークに渡す。デバイスとネットワークの間で認証が成功すると、ユーザは、デバイスの機能およびデバイス上に保持されたデータ、ならびにネットワークベースのサービスへのアクセスを許可される。
【０２７９】
３．上記の（２）の変形では、デバイスに対するローカル認証のために、ユーザバイオメトリック情報を使用することを必要とせず、バイオメトリック情報、またはバイオメトリック情報のファジーハッシュなど、安全に導出された一意的な情報要素を、ユーザのネットワークレベルの認証のために、ネットワークに送信することができる。
【０２８０】
４．（２）または（３）の別の変形では、ネットワークが（デバイスとともに）ユーザを認証し、デバイスがネットワークから返されたその評価の通知を取得するまで、ユーザは、デバイスの機能およびデータへの限定的なアクセスだけを許可される。このモードでは、ユーザおよびデバイスの資格証明書のネットワーク認証が完了し、適切な認可とともにデバイスに返信されるまで、ユーザは、いくつかの事前指定された「安全に隔離された」機能およびそれらの機能だけにアクセスすること、または使用することを許可される。
【０２８１】
デバイスとネットワークの間でユーザ認証機能を分散させた、または完全に１つのエンティティ上にある、上述のメカニズムの変形も可能である。また、ユーザ認証をデバイス認証に結び付けることも、ユーザおよび／またはデバイスの強力な認証を提供することができる。
【０２８２】
多くのタイプのバイオメトリックスを組み込むことができるが、例示的な一実施形態は、指紋スキャナまたは網膜スキャナなどの、バイオメトリックスキャンを利用することができる。ユーザインタフェースの自然な拡張としてバイオメトリックスキャンを組み込むことによって、ユーザがある機能を実行したこと、またはデバイスにとってローカルの、もしくは通信ネットワークを介する特定のサービスにアクセスしたことを契機とするトリガイベント時に、動的で透過的なユーザ認証を提供するような方法で、バイオメトリックスキャンをセキュリティ機能に組み込むことができる。例えば、ユーザを認証すると同時に発呼を行うために、指紋スキャナをソフトキーに組み込んで、指のストロークが、例えば「送信」などのソフトキーアクションをトリガするようにすることができる。あるいは、ディスプレイ画面、デバイス本体、またはタッチキーへの、ユーザのデバイスに対する物理的接触を、目立たない認証と組み合わせることによって、デバイスに対して継続的にユーザを認証し続けることができる。
【０２８３】
４．４．１．４．４  アソシエーションベースモードを使用するＲＰのためのプロトコルフロー
図２５は、ＲＰがアソシエーションベースモードを使用して、ＯｐｅｎＩＤユーザ認証を実行することを可能にするためのプロトコルフローの例示的な一実施形態を示している。アソシエーションは、ユーザが最初にＲＰとコンタクトを取り、ＲＰとともに自らのＯｐｅｎＩＤ識別子を使用した後に、行うことができる。アソシエーションが確立された場合、それを再利用することができ、そのことが通信労力をさらに低減させる。しかし、ＯＰがＲＰの動作モードを命じることが可能でないことがあり、２つの通信モデルのうちの１つを決定することは、ＲＰに任されていることがある。
【０２８４】
アソシエーションは、アサーションメッセージに署名するためにＯＰによって使用でき、ＯＰシグネチャを検証するためにＲＰによって使用できる、ＲＰとＯＰの間の永続的な秘密を確立する。ＯＰは、共有秘密の有効期間を決定することができる。ＲＰとＯＰは、アソシエーションハンドルを秘密のための識別子として使用する。ＲＰは、ＯＰへの第１の要求メッセージにアソシエーションハンドルを含め、その後、ＯＰは、アソシエーションハンドルに応じて、対応する秘密を使用することができる。ＯＰは、アソシエーションが失効していると決定した場合、応答メッセージでＲＰに通知する。原理的に、これは、ＯＰが、いかなるアソシエーション要求も拒否することを可能にすることができる。ＲＰが、ステートレスモードもサポートできるのであれば、これを使用して、ＲＰを強制的にステートレス通信モードに依存させることができる。ＲＰから要求されたシグネチャモード（ＨＭＡＣ−ＳＨＡ１またはＨＭＡＣ−ＳＨＡ２５６）がＯＰによってサポートできない場合、ＯＰは、例えば、アソシエーション要求を拒否することができる。
【０２８５】
ユーザがＲＰにログインするたびに、ＲＰとＯＰの間で新しい秘密が確立される、ステートレス通信モードとは対照的に、アソシエーションは、アイデンティティとＲＰ毎に１回確立される。ＯＰとＲＰの間のアソシエーションがすでに確立されている場合、それをＲＰとＯＰによって再利用することができる。
【０２８６】
ＲＰは、ＯＰＳＦのアドレスが分かると直ちに、すなわち、発見フェーズの後に、アソシエーションを確立することができ、プロトコルを先に進める前に、すなわち、アソシエーションハンドルをリダイレクトメッセージに含める前に、アソシエーションを完了しなければならない。
【０２８７】
図２５に示されるように、
６２５：ユーザは、ＯｐｅｎＩＤを使用してログインするために、ＲＰウェブサイトを訪れることができ、例えば、ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙなど、自らのＯｐｅｎＩＤ識別子を入力することができる。
【０２８８】
６３０：ブラウザは、ＯｐｅｎＩＤ識別子を含むＨＴＴＰメッセージを、ＲＰウェブサイトに送信することができる。
【０２８９】
６３５：ＲＰは、ＨＴＴＰ／ＨＴＭＬベースのＯｐｅｎＩＤ「シンプル」発見を使用することができ、公衆インターネットを介してＯＰ−Ａｇｇとコンタクトを取り、例えば、ＨＴＴＰ  ＧＥＴ  ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙによって、ＯｐｅｎＩＤ識別子のためのアイデンティティページを取り出す。
【０２９０】
６４０：ＯＰ−ａｇｇは、要求を受信し、例えば、
＜ｌｉｎｋ  ｒｅｌ＝“ｏｐｅｎｉｄ．ｓｅｒｖｅｒ”ｈｒｅｆ＝ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｓｅｒｖｅｒ．ｃｇｉ＞
を含めることによって、ＯＰＳＦのインターネットアドレスを含むＨＴＭＬページによって応答することができる。
【０２９１】
ＯＰＳＦのアドレスは、ＯＰ−ａｇｇのアドレスと異なることがある。
【０２９２】
６４５：ＲＰは、パラメータ
ｏｐｅｎｉｄ．ｍｏｄｅ＝ａｓｓｏｃｉａｔｅ、
ｏｐｅｎｉｄ．ａｓｓｏｃ＿ｔｙｐｅ＝ＨＭＡＣ−ＳＨＡ１、
ｏｐｅｎｉｄ．ｓｅｓｓｉｏｎ＿ｔｙｐｅ＝ｂｌａｎｋ、
ｏｐｅｎｉｄ．ｄｈ＿＊＝‘Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ  Ｐａｒａｍｅｔｅｒｓ’
を有する、ＯＰＳＦに対するＨＴＴＰ  ＰＯＳＴコールを使用することができる。
【０２９３】
６５０：ＯＰＳＦは、ＲＰのための共有秘密およびアソシエーションハンドルを生成することができる。
【０２９４】
６５５：ＯＰＳＦは、キー＝バリューフォーマット文書内にアソシエーションハンドルおよび（ディフィ−ヘルマンが使用される場合は暗号化された）秘密を含む、ＨＴＴＰ  ＰＯＳＴによってＲＰに応答することができる。このアソシエーションは、ＲＰとＯｐｅｎＩＤアイデンティティ毎に１回確立することができる。ディフィ−ヘルマンは、ＭＩＴＭ攻撃によって攻撃することができるので、ＯｐｅｎＩＤセキュリティのベストプラクティスは、ＨＴＴＰＳ認証の使用を勧告している。
【０２９５】
６６０：ＲＰは、例えば、
ｎｏｎｃｅ＝１２３１２３、
ｓｅｓｓｉｏｎ＝Ｕｓｅｒ
など、セッションノンスおよびセッション識別子を生成することができる。
【０２９６】
６６５：ＲＰは、ＯＰＳＦから受信した秘密およびアソシエーションハンドルを保存することができる。
【０２９７】
６７０：ＲＰは、アソシエーションハンドルをリダイレクトメッセージに含めることができる。
【０２９８】
６７５：ＲＰは、パラメータ
ｏｐｅｎｉｄ．ｍｏｄｅ＝ｃｈｅｃｋｅｄ＿ｓｅｔｕｐ、
ｏｐｅｎｉｄ．ｉｄｅｎｔｉｔｙ＝ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙ、
ｏｐｅｎｉｄ．ｒｅｔｕｒｎ＿ｔｏ＝ｈｔｔｐ：／／ｒｐ．ｏｒｇ／ｒｅｔｕｒｎ．ｃｇｉ？ｓｅｓｓｉｏｎ＝Ｕｓｅｒ＆ｎｏｎｃｅ＝１２３１２３、
ｏｐｅｎｉｄ．ａｓｓｏｃ＿ｈａｎｄｌｅ＝‘ａｓｓｏｃｉａｔｉｏｎ  ｈａｎｄｌｅ’
を含む、ＨＴＴＰ  ＲＥＤＩＲＥＣＴメッセージを、ブラウザに送信することができる。
【０２９９】
６８０：ブラウザは、リダイレクトメッセージを受信することができ、リダイレクトメッセージ内のＲＰによって指定されたＵＲＬへの接続をオープンする。
【０３００】
６８５：例えば、エントリｈｔｔｐ：／／ｏｐ．ｏｒｇ＝＝１２７．０．０．１を有するホストファイルを使用することによって、ＯＰＳＦのＵＲＬをＳＣＷＳローカルＩＰアドレスにマッピングする、変更されたローカルＤＮＳルックアップテーブルを用いる場合、ブラウザは、ＳＣＷＳに関連付けられたローカルＯＰにリダイレクトすることができ、６７５のパラメータを含むＨＴＴＰ要求を発行する。
【０３０１】
変更されたローカルＤＮＳルックアップテーブルは、デバイス上で使用することができ、ＵＲＬ  ｈｔｔｐ：／／ｏｐ．ｏｒｇがＳＣＷＳのローカルＩＰアドレスにあるとデバイスに思わせる。したがって、ブラウザは、（公衆インターネットを介して到達可能な、ＵＲＬ  ｈｔｔｐ：／／ｏｐ．ｏｒｇにある）ＯＰＳＦに接続する代わりに、ＳＣＷＳ／ローカルＯＰへの接続をオープンすることができる。
【０３０２】
６９０：以下は、ＯｐｅｎＩＤプロトコル仕様によって規定されていない。
ａ．ＳＣＷＳに関連付けられたＯＰは、ローカル認証ページを表示することができる。
ｂ．ユーザは、例えば、ユーザ名およびパスワードなど、自らの認証用資格証明書を入力することができる。
ｃ．ＳＣＷＳに関連付けられたＯＰは、資格証明書を検証することができる。
【０３０３】
６９５：ＳＣＷＳに関連付けられたＯＰは、リターンメッセージに署名するために、ＯＰＳＦとＲＰの間ですでに共有されている秘密を使用することを必要とすることがあり、いくつかのオプションを適用することができる。
ａ．オプション１：
ｉ．秘密は、例えば、事前に共有されていること、ＯＰＳＦによって事前に用意されていることなど、すでに存在していることができる。
ｂ．オプション２：
ｉ．ＯＰＳＦは、例えば、安全なＳＭＳを介して、もしくはＧＢＡによってブートストラップされて、および／またはＳＣＷＳ  ＨＴＴＰＳリモート管理インタフェースなどの安全な通信プロトコルを使用して、アソシエーションハンドルおよび秘密を、ＳＣＷＳに関連付けられたＯＰに送信することができる。
ｉｉ．ＳＣＷＳに関連付けられたＯＰは、秘密およびアソシエーションハンドルを保存することができる。
ｃ．オプション３：
ｉ．ＳＣＷＳに関連付けられたＯＰは、ＲＰから受信したアソシエーションハンドルを使用することによって、ＯＰＳＦに秘密を要求することができる。このメッセージのためのプロトコルは、ＳＭＳを介して動作することができ、実現可能性がさらなる研究課題（ｆｆｓ）である、他のオプションも可能である。
ｉｉ．ＯＰＳＦは、アソシエーションハンドルに基づいて、秘密を求めて検索を実行することができる。
ｉｉｉ．ＯＰＳＦは、例えば、保護されたＳＭＳ−ＰＰを介して、もしくは例えばＧＢＡによってブートストラップされて、および／またはＳＣＷＳ  ＨＴＴＰＳリモート管理インタフェースなどの安全な通信プロトコルを使用して、秘密およびアソシエーションハンドルを、ＳＣＷＳに関連付けられたＯＰに送信することができる。
【０３０４】
７００：ＳＣＷＳに関連付けられたＯＰは、秘密を使用して、戻り先ＵＲＬ、アイデンティティ、およびモードパラメータに対するシグネチャを計算することができる。
【０３０５】
７０５：ＳＣＷＳに関連付けられたＯＰは、シグネチャを追加パラメータとしてＨＴＴＰリダイレクトに含めることができる。
【０３０６】
７１０：ＳＣＷＳに関連付けられたＯＰは、以下のパラメータを含む、すなわち、
ｏｐｅｎｉｄ．ｍｏｄｅ＝ｉｄ＿ｒｅｓ、
ｏｐｅｎｉｄ．ｒｅｔｕｒｎ＿ｔｏ＝ｈｔｔｐ：／／ｒｐ．ｏｒｇ／ｒｅｔｕｒｎ．ｃｇｉ？ｓｅｓｓｉｏｎ＝Ｕｓｅｒ＆ｎｏｎｃｅ＝１２３１２３、
ｏｐｅｎｉｄ．ｉｄｅｎｔｉｔｙ＝ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙ、
ｏｐｅｎｉｄ．ｓｉｇｎｅｄ＝ｍｏｄｅ，ｉｄｅｎｔｉｔｙ，ｒｅｔｕｒｎ＿ｔｏ、
ｏｐｅｎｉｄ．ａｓｓｏｃ＿ｈａｎｄｌｅ＝‘ａｓｓｏｃｉａｔｉｏｎ  ｈａｎｄｌｅ’、
ｏｐｅｎｉｄ．ｓｉｇ＝‘ｂａｓｅ６４  ｅｎｃｏｄｅｄ  ｓｉｇｎａｔｕｒｅ’
を含む、ＨＴＴＰリダイレクトメッセージを、ブラウザに送信することができる。
【０３０７】
７１５：ユーザがさらにいかなる関与も行わなくても、ブラウザは、ＲＰにおける戻り先ＵＲＬにユーザをリダイレクトすることができる。
【０３０８】
７２０：ＲＰは、署名されたアサーションメッセージを受信することができる。
【０３０９】
７２５：ＲＰは、先に確立された共有秘密を使用して、シグネチャを検証することができる。
【０３１０】
７３０：ＲＰからは、ユーザは、ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙとして識別することができる。
【０３１１】
７３５：ブラウザは、ＲＰのＨＴＭＬページを表示することができる。
【０３１２】
７４０：ユーザは、ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙとして、ＲＰにおいてログインすることができる。
【０３１３】
アソシエーションベースモードについての追加の実施形態
追加の実施形態は、セクション４．４．１．４．３のステートレスプロトコルに対する追加の実施形態を使用する実施形態に基づくことができる。
【０３１４】
４．４．２  ＳＣＷＳ上のＯＰの改良についての実施形態
４．４．２．１  改良の一般的な方法
セクション４．４．１の例示的な実施形態では、ＳＣＷＳに関連付けることができるローカルＯＰと、ＯＰＳＦは、アサーションシグネチャとそれらの検証のために使用される共有秘密を、ＲＰ毎に少なくとも１回確立することを求められることがある。しかし、ＯＰＳＦとローカルＯＰの間でただ１つの（長期）共有秘密を確立し、その後、シグネチャのために使用される秘密を、暗号関数を使用して導出することを可能にする、追加の暗号手法を使用することによって、プロトコルがさらに改良された、追加の方法を適用することができる。さらに、ＯＰＳＦとローカルＯＰの間でのこの秘密の交換の統合は、プロトコルメッセージ内で実行することができる。
【０３１５】
４．４．２．２  改良についての予備的な技術情報
以下のセクションでは、可能な実施および実施形態についてのより技術的な予備知識を提供する。
【０３１６】
ＳＣＷＳは、ＩＰベースまたは従来のＵＩＣＣ方法を使用して、ハンドセットと、また間接的に外部世界の当事者と安全に通信することができ、ＵＩＣＣアプリケーションを所有する当事者は、それらをＵＩＣＣにダウンロードし、リモートで管理することができる。
【０３１７】
ＵＩＣＣ上でのリソース使用に関して、グローバルプラットフォーム、ＳＣＷＳ、および結果として生じるＩＰスタックをサポートすることが可能なＵＩＣＣは、ほぼ確実に、大容量メモリおよびＵＳＢもサポートすることに留意されたい。そのようなＵＩＣＣは、十分に強力なプロセッサを有することができ、ｏ／ｓが、リソース管理を引き受ける。
【０３１８】
図２４（ステートレスモード）の５７５、および図２５（アソシエーションモード）の６９５において、ＳＣＷＳに関連付けられたＯＰは、秘密を保存し、使用することができる。これを行うことで、例えば、保護されたストレージ内に署名鍵を保持することができ、署名鍵は、そこから決して出ることがなく、署名鍵は、カード自体の中で暗号アルゴリズムによってのみ使用される。これは、（ＭＮＯのような）他の（トラステッド）パーティと安全に共有でき、スマートカードから決して出ないことを保証できる、何らかの鍵とすることができる。ダウンロードされたアプレットにおけるアプリケーション固有の署名鍵の場合、われわれは、（１）鍵をどのようにＵＩＣＣに取り込み、アプレットに入れるか、（２）鍵のセキュリティをどのように維持するか、（３）誰が鍵を使用できるか、および（４）鍵はどのように更新できるかという、検討できる４つの課題を有する。
【０３１９】
例示的な一実施形態（課題（１）に対する回答）では、ＵＩＣＣ上のＯＰに固有の鍵は、アプレットの実行可能ロードファイルの一部としてロードすることができ、そのアプレットの指定されたキーファイル内に存在することができる。アプリケーションダウンロードは、ＳＣＷＳ管理更新プロセスを使用しなくてもよい。しかし、ＳＣＷＳは、（単なるＳＣＷＳウェブページではない、任意のアプリケーションを意味する）スマートカードアプリケーションを起動することができる。これは、ローカルＯＰを、グローバルプラットフォームフレームワークの下で動作するアプレットとすることができることを意味する。（単なるＳＣＷＳ  ＨＴＭＬページ以上のものである）そのような複雑なアプレットが、グローバルプラットフォームアプレットローディングプロセスを使用することが有利なことがある。
【０３２０】
別の例示的な実施形態（課題（２）に対する回答）では、いずれかのロードされたアプリケーションに属する秘密は、ＵＩＣＣのＯ／Ｓによって保護される。われわれは、Ｏ／Ｓに依存して、それを実施することができる。ＵＩＣＣのロードされたアプリケーションが動作するメモリは、Ｏ／Ｓによって保護される。
【０３２１】
別の例示的な実施形態（課題（３）に対する回答）では、例えば、何らかのデータに署名（または暗号解除／暗号化）するために、ローカルＯＰによって（プライベート）署名鍵を使用することができる。ＳＣＷＳを介してＵＩＣＣ上のローカルＯＰと通信できる任意の外部エンティティは、署名または暗号解除するために、データをアプレットに提供することができるが、ＳＣＷＳへのそのような通信は、リダイレクトとして端末のブラウザを通過しなければならないことがある。共有対称鍵の場合、そのような鍵をＭＮＯなどのＴＴＰに配布することは、ＴＴＰがＵＩＣＣと対話して鍵を使用することができるように、例えばＯＰなどの鍵の所有者に任せることができる。
【０３２２】
ＳＣＷＳに関連付けられたＯＰに鍵を保存するために、キーファイルが使用される場合、キーファイルを更新するために、標準化されたアプレット更新プロセスを使用することができる。ＳＣＷＳ管理更新プロセスが使用される場合、それは、（ＭＮＯであると仮定される）ＳＣＷＳ更新プロセスの所有者によって行うことができる。オンカード鍵生成を代替として使用することも可能とすることができる。
【０３２３】
ＳＣＷＳは、ＢＩＰ／ＣＡＴ通信を提供し、またＵＳＢを介するＴＣＰ／ＩＰ／ＨＴＰＰを提供する。後のケースでは、（ＰＳＫまたはＰＫＩベースの）ＴＬＳを、デバイスとＳＣＷＳの間で使用することができる。
【０３２４】
別の例示的な実施形態では、ＯＰサーバアプリケーションを、Ｊａｖａ（登録商標）Ｃａｒｄアプレットとして、ＵＩＣＣ上にロードすることができ、その後、文献において指定された方法で（例えば、非特許文献１３参照）管理することができる。事実上、同じ当事者によって、すなわち、ＭＮＯ／カード発行体（ＣＩ）によって、両方のドメインが所有されるとしても、アプレットは、ＣＩのセキュリティドメイン（ＳＤ）の下に、またはアプリケーションプロバイダ（ＡＰ）のＳＤの下に配置することができる。あるいは、ＯＰアプリケーションは、ファームウェアまたはネイティブアプリケーションとすることができる。
【０３２５】
ＯＭＡは、ＳＣＷＳと相互認証を行うＨＴＴＰＳを使用して、リモートサーバアプリケーションによって、ＳＣＷＳのコンテンツおよび設定を更新するための安全なプロセスを提供することができる。これは、例えば、カード発行体としてのＭＮＯによる使用のために行うことができ、トランスポートのための従来のＯＴＡの周辺で、そのように考案されている。この機能は、ＳＣＷＳに関連付けられたアプリケーションをダウンロードするために使用することは意図していないが、そのようなアプリケーションを更新するために（ＭＮＯによってのみ）使用することができる。
【０３２６】
ＳＣＷＳは、（ＳＭＳ−ＰＰがそれのユビキタスデフォルトである）従来のツールキットおよびＯＴＡ技術を使用することができる。したがって、ＵＩＣＣが自らのＩＰアドレスを有さない場合、ＳＣＷＳ上のウェブページをクライアントからブラウズするために、およびＳＣＷＳ上のウェブページを移送し、管理エンティティから管理するために、ＳＣＷＳは、ＵＩＣＣ／ＭＥ接続のためにＣＡＴ／ＢＩＰを使用することを述べる。同様に、ＳＣＷＳは、リモート管理者からのメッセージのために、連結されたＳＭＳ−ＰＰをサポートすることもできる。しかし、ＵＩＣＣが自らのアドレスを有する場合、直接ＴＣＰ／ＩＰ接続の上の直接ＴＬＳ接続を介して、ＳＣＷＳ上のウェブページをクライアントからブラウズするために、およびＳＣＷＳ上のウェブページを移送し、管理エンティティから管理するために、ＳＣＷＳは、ＵＩＣＣの高速（すなわちＵＳＢ）インタフェースの上で、直接ＴＣＰ／ＩＰ接続をサポートすることもできる。
【０３２７】
４．４．２．３  ＳＣＷＳ上の改良ＯＰ序論
以下の実施形態は、ＳＣＷＳ上のＯＰの改良された変形という概念について説明する。ＳＣＷＳ上のＯＰは、ＯｐｅｎＩＤ／ＧＢＡの改良とすることができる。例えば、実施形態は、以下の利点を提供することができる。
【０３２８】
●ＳＣＷＳ上のＯＰは、認証をデバイスにとってローカルなものにし、したがって、通信コストを著しく低下させることによって、ＯｐｅｎＩＤ／ＧＢＡを改良することができる。
【０３２９】
●ＳＣＷＳ上のＯＰのさらなる改良は、認証秘密を、標準的なＯｐｅｎＩＤメッセージフィールドに収めて、ＯＰとネットワーク側エンティティの間で伝達することによって、行うことができる。これによって、通信オーバヘッドをさらに低減することができ、またＳＣＷＳ上のＯＰとネットワークエンティティ（ＯＰＳＦ）の間の関係を緩和することができ、それによって、ネットワーク間でのＯｐｅｎＩＤの移行を可能にすることができる。
【０３３０】
加えて、以下の実施形態は、ＳＣＷＳ上のＯＰが、ネットワーク通信事業者に、
●認証トラフィックがモバイルネットワーク上で生じない
●すべての認証トラフィックが公衆インターネット上で生じる
●すべてのアプリケーションデータトラフィックがモバイルネットワーク上で生じる
などの主要な利点を提示することを可能にすることができる。
【０３３１】
４．４．２．４  ローカルＯＰによって行われる改良
例示的な実施形態では、トラフィックを大幅に低減させるために、ＳＣＷＳに関連付けられたＯＰに対して、ローカル認証を実行することができる。これを行うことで、例えば、ネットワーク自体にかかる負担を低減するために、認証トラフィックをローカルなものにすることを可能にすることができる。例示的な一実施形態では、ユーザが訪れるＲＰ毎に、ネットワークＯＰＳＦエンティティとＳＣＷＳに関連付けられたＯＰとの間で、共有秘密を確立することができる。そのような秘密の確立のためのいくつかの実施形態が、本明細書で説明される。例えば、例示的な一実施形態では、ＲＰによってアソシエーションが使用される場合、ＲＰは、シグネチャ検証のために使用される秘密を保存することができ、ユーザが次回ＲＰを訪れたときに、その秘密を再利用することができる。別の例示的な実施形態では、ＲＰがステートレスモードを使用する場合、ＲＰは、秘密をセーブしないことがある。ＯＰは、秘密を生成することができ、それをＯＰＳＦと安全に共有することができる。ＳＣＷＳに関連付けられたＯＰは、この秘密を保存することができ、ユーザが次回同じＲＰを訪れたときに、その秘密を再利用することができ、ＯＰＳＦは、ステートレスモードにおけるシグネチャ検証のためにその秘密を直接的に使用できるように、同じ秘密を保存することができる。
【０３３２】
別の例示的な実施形態では、ＯＰＳＦとＳＣＷＳに関連付けられたＯＰとの間でひとたび共有された秘密は、ある程度までは再利用できると仮定することができる。例えば、ＯＰのための秘密を全部で５つスマートカード上に保存できる場合、ユーザがＲＰを訪れるたびに、その秘密を再利用することができる。これを行うことで、例えば、文献において仕様が規定された（例えば、非特許文献５参照）ＯｐｅｎＩＤ／ＧＢＡと比較して、ネットワークトラフィックを大幅に減少させることができる。例えば、日々のトラフィックを半分に減少させることができ、複数の日を考えた場合、秘密を再利用することができるので、減少はより一層大きくなる。
【０３３３】
言及された秘密は、ＯｐｅｎＩＤ／ＧＢＡで使用される秘密とは異なることがあり、ＯＰＳＦとＳＣＷＳに関連付けられたＯＰとの間で共有される秘密は、アサーションメッセージに署名するのに使用されるＯｐｅｎＩＤ秘密である。標準的なＯｐｅｎＩＤプロトコル手順におけるように、これらの秘密は、ＲＰと共有することができ、例えば、単一のログインセッションよりも長く存続するなど、より長期にわたって存続する秘密として確立することができ、基本的にこの再利用を可能にする。
【０３３４】
４．４．２．５  さらなる改良
ＳＣＷＳ上のＯＰを実施するためのプロトコルフローの例示的な一実施形態では、ＭＮＯ運用のＯＰＳＦネットワークエンティティは、デバイス上のＳＣＷＳに関連付けられたＯＰとの追加の通信に携わることができる。各ＲＰがアサーションメッセージの署名または署名の検証をそれぞれ行うために、両方のエンティティが同じ対称鍵を備えていなければならないので、この通信が必要とされることがある。
【０３３５】
実施形態のさらなる改良は、デバイスとネットワークの間の付加的な通信を大幅に減少させることができ、秘密の確立のために必要な情報を、ＯｐｅｎＩＤメッセージのプロトコルフィールド内に直接的に収容することができる。これらのメッセージは、公衆インターネットを介してＨＴＴＰメッセージとして送信され、ＭＮＯのエアネットワークインフラストラクチャに追加的な負担をかけることがある。これを行うことで、例えば、ブラウザとデバイス内のＵＩＣＣ／ＳＣＷＳの間の認証トラフィックがローカルであることを保証することができ、それによって、ネットワークを使用しないようにすることができる。これによって、通信は（エア）ネットワークからデバイス内の内部通信にオフロードされるので、全般的なトラフィックの減少を可能にすることができる。
【０３３６】
実施形態の別の改良は、認証のためのＭＮＯとＵＩＣＣ／デバイスの間の追加的なシグナリングトラフィックを実行する必要がないことを保証することによって、与えることができる。例えば、認証毎のＧＢＡ実行、または無線を介したネットワークとデバイスの間のＳＭＳ／ＭＭＳもしくは制御メッセージの送信は、存在しなくてもよい。すべての必要な情報は、ＨＴＴＰメッセージに収めて直接的に搬送することができ、これは、一部（デバイスからＲＰ）はエアネットワークを介するインターネット上で、一部（ＲＰからＭＮＯ）は有線公衆インターネット上で行うことができる。しかし、このトラフィックは、１）ＯｐｅｎＩＤを使用してログインすることを望むユーザによってトリガすること、２）既存のデータプランによってユーザに請求すること、３）ウェブベースのＯｐｅｎＩＤよりも少なく、またＯｐｅｎＩＤ／ＧＢＡよりも少なくすることができる。
【０３３７】
４．４．２．４  プロトコル改良の技術的詳細
４．４．２．４．１  命名規約
上で説明したのと同じ命名規約を、参考までにここでも繰り返す。
【０３３８】
●ＳＣＷＳに関連付けられたＯＰ：署名されたアサーションメッセージを発行し、それらをユーザのブラウザを介してＲＰに送信する、ＯｐｅｎＩＤアイデンティティプロバイダ。ＳＣＷＳを、したがってＯＰをホストするスマートカードは、ＭＮＯと、したがって、すべてのＭＮＯ関連のエンティティと関係を有すると仮定される。
【０３３９】
●ＲＰ：ユーザにＯｐｅｎＩＤを使用したログインを提供する任意のウェブサイトとすることができる依拠当事者。ＲＰは、他のすべてのエンティティから完全に独立であり、したがって、ＲＰに追加の要件を課すことはできず、ＲＰについてのＯｐｅｎＩＤプロトコルフローに対する変更は生じることができない。ＯＰは、ＲＰが使用することを選んだ通信モードは（ステートレスまたはアソシエーションベースの）どちらであれサポートしなければならない。ＭＮＯが、ユーザはあるＲＰを使用すべきではないと決定した場合、ユーザは依然として別のアイデンティティを使用できるので、ＭＮＯは、これらのＲＰに対するＯｐｅｎＩＤアクセスを拒否することによって、これらのサイトへのアクセスを拒否することはできない。ＭＮＯは、一般に帯域幅消費サイトへのアクセスをブロックする追加の手段を使用して、ＲＰへのアクセスを制限できるにすぎない。
【０３４０】
●ＯＰ−Ａｇｇ：ＯＰ−Ａｇｇは、ＯｐｅｎＩＤ標準に従って、ＲＰに発見サービスを提供するネットワークエンティティを実施する。
【０３４１】
●ＯＰＳＦ：ＯＰサーバ機能（ＯＰＳＦ）は、ＳＣＷＳに関連付けられたＯＰおよび任意選択的にＲＰとともに、ＯｐｅｎＩＤプロトコルのための秘密を生成し、共有し、分配することができる、サポートＯＰ機能を実施する。ＯＰＳＦとＳＣＷＳに関連付けられたＯＰとは、ＲＰの観点からは、それらが単一のエンティティであるかのように振る舞っている。ＯＰＳＦは、ＳＣＷＳに関連付けられたＯＰによって発行されたシグネチャを検証することができ、公衆インターネットを介してＲＰから直接的に到達可能である。デバイス上のブラウザは、ＯＰＳＦのアドレスがＳＣＷＳに関連付けられたローカルＯＰにマッピングされるように、デバイス上のローカルＤＮＳ解決キャッシュを変更することによって、ＳＣＷＳに関連付けられたＯＰにリダイレクトされる。
【０３４２】
このエンティティＯＰＳＦおよびその必要な機能についての要件は、上で詳細に示された先行文献において説明された（例えば、非特許文献１４参照）。
【０３４３】
●ブラウザ：ＳＣＷＳに関連付けられたＯＰへの、およびＳＣＷＳに関連付けられたＯＰからのルーティングおよびメッセージング機能を明示的にするために、プロトコルフロー図内に示される。それ以外では、ブラウザは、ユーザ認証を表示し、受信するためのフロントエンドにすぎない。
【０３４４】
４．４．２．４．２  実施形態に対する可能な仮定
ＳＣＷＳに関連付けられたＯＰおよびＯＰＳＦ機能は、スマートカードセキュリティ機能によって保護され、ＳＣＷＳに関連付けられたＯＰにのみアクセス可能な、長期秘密Ｋを確立することができる。この秘密の確立は、例えば、単一のＧＢＡ実行によることができ、または例えばＡＫＡ鍵からこの鍵を導出することが可能な別の鍵導出関数、もしくはＵＩＣＣセキュリティ機能によって保護できる、ＭＮＯとＳＣＷＳに関連付けられたＯＰとの間の共有秘密をもたらす他の任意の方法の使用によることができる。加えて、秘密の確立は、当技術分野で知られた任意の方法を使用して行うことができる。
【０３４５】
スマートカードは、Ｋから導出される新しい秘密を計算するための、暗号機能（アルゴリズムおよび計算）を提供することもできる。この機能の特定の特性を、説明およびセキュリティ要件から導出することができる。同一または同様の機能は、ＯＰＳＦも知ることができ、それによって、ＯＰＳＦがＫから鍵を導出することを可能にすることができる。
【０３４６】
両方のエンティティは、暗号操作のために、十分な長さのランダム値を生成することができてよい。
【０３４７】
４．４．２．４．３  プロトコルフロー説明
以下のセクションでは、ＳＣＷＳに関連付けられたＯＰを実施するためのプロトコルフローの例示的な実施形態について説明する。
【０３４８】
４．４．２．４．３．１  ステートレスモードを使用するＲＰのためのプロトコルフローについての例示的な実施形態
ＲＰが、ステートレスモードを使用して、ＯｐｅｎＩＤユーザ認証を実行する場合、図２６に示される実施形態を適用することができる。
【０３４９】
４．４．２．４．３．１．１  ステートレスモードについての説明
図２６は、改良されたステートレスモードのためのプロトコルフローの例示的な一実施形態を示している。
【０３５０】
７４５：ユーザは、ＲＰウェブサイトを訪れることができ、ＯｐｅｎＩＤを使用してログインするために、例えば、ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙなどの、自らのＯｐｅｎＩＤ識別子を入力する。
【０３５１】
７５０：ブラウザは、ＯｐｅｎＩＤ識別子を含むＨＴＴＰメッセージを、ＲＰウェブサイトに送信することができる。
【０３５２】
７５５：ＲＰは、ＨＴＴＰ／ＨＴＭＬベースのＯｐｅｎＩＤ「シンプル」発見を使用することができ、公衆インターネットを介してＯＰ−Ａｇｇとコンタクトを取り、例えば、ＨＴＴＰ  ＧＥＴ  ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙによって、ＯｐｅｎＩＤ識別子のためのアイデンティティページを取り出す。
【０３５３】
７６０：ＯＰ−ａｇｇは、要求を受信することができ、ＯＰＳＦのインターネットアドレスを含むＨＴＭＬページによって応答することができる。例えば、ＯＰ−ａｇｇは、
＜ｌｉｎｋ  ｒｅｌ＝“ｏｐｅｎｉｄ．ｓｅｒｖｅｒ”ｈｒｅｆ＝ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｓｅｒｖｅｒ．ｃｇｉ＞
を含めることによって応答することができる。
【０３５４】
ＯＰＳＦは、ＲＰに対して標準的なＯｐｅｎＩＤアイデンティティプロバイダウェブサービスのように振る舞うことができる。例えば、ＯＰＳＦは、ＲＰからの要求時に、アサーションメッセージ上の（ローカルＯＰによって発行された）シグネチャを検証することができる。要件通りに、ＯＰＳＦは、公衆インターネットを介して到達可能でなければならず、したがって、ｈｔｔｐ：／／ｏｐ．ｏｒｇによって到達可能な、例えばｏｐ．ｏｒｇなどの、ＤＮＳ名を有すると仮定される。外部世界は、スマートカードのＩＰアドレスを知ることができないので、このインダイレクションＯＰ−ａｇｇおよびＯＰＳＦを、通信のために使用することができる。
【０３５５】
ＯＰＳＦのアドレスは、ＯＰ−ａｇｇのアドレスと異なることがある。
【０３５６】
７６５：ＲＰは、ＯＰＳＦのアドレスを受信することができ、例えば、ｎｏｎｃｅ＝１２３１２３、ｓｅｓｓｉｏｎ＝Ｕｓｅｒなどと、ノンスおよびセッション識別子を生成する。ＲＰは、ユーザ認証後にブラウザをどのＵＲＬにリダイレクトすべきかをＯＰに命じる、戻り先パラメータを編集することができる。ＲＰは、以下のパラメータを含む、ブラウザをＯＰサーバアドレスにリダイレクトする、ＨＴＴＰリダイレクトを発行することができる。
ｏｐｅｎｉｄ．ｍｏｄｅ＝ｃｈｅｃｋｉｄ＿ｓｅｔｕｐ、
ｏｐｅｎｉｄ．ｉｄｅｎｔｉｔｙ＝ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙ、
ｏｐｅｎｉｄ．ｒｅｔｕｒｎ＿ｔｏ＝ｈｔｔｐ：／／ｒｐ．ｏｒｇ／ｒｅｔｕｒｎ．ｃｇｉ？ｓｅｓｓｉｏｎ＝Ｕｓｅｒ＆ｎｏｎｃｅ＝１２３１２３
【０３５７】
７７０：ブラウザは、リダイレクトを受信することができ、リダイレクトメッセージ内のＲＰによって指定されたＵＲＬへの接続をオープンすることができる。
【０３５８】
７７５：例えば、エントリｈｔｔｐ：／／ｏｐ．ｏｒｇ＝＝１２７．０．０．１を有するホストファイルを使用することによって、ＯＰＳＦのＵＲＬをＳＣＷＳローカルＩＰアドレスにマッピングする、変更されたローカルＤＮＳルックアップテーブルを用いる場合、ブラウザは、ＳＣＷＳに関連付けられたローカルＯＰにリダイレクトすることができ、７６５のパラメータを含むＨＴＴＰ要求を発行する。
【０３５９】
変更されたローカルＤＮＳルックアップテーブルは、デバイス上に存在することができ、ＵＲＬ  ｈｔｔｐ：／／ｏｐ．ｏｒｇがＳＣＷＳのローカルＩＰアドレスにあるとデバイスに思わせる。ブラウザは、（公衆インターネットを介して到達可能な、ＵＲＬ  ｈｔｔｐ：／／ｏｐ．ｏｒｇにある）ＯＰＳＦに接続する代わりに、ＳＣＷＳ／ローカルＯＰへの接続をオープンすることができる。
【０３６０】
７８０：以下は、認証トラフィックをローカルに保つことを保証するために実行することができるが、これらのステップは、必須ではなく、ＯｐｅｎＩＤプロトコル仕様によって規定されていない。
ａ．ＳＣＷＳに関連付けられたＯＰは、ローカル認証ページを表示することができる。
ｂ．ユーザは、例えば、ユーザ名およびパスワードなど、自分の認証用資格証明書を入力することができる。
ｃ．ＳＣＷＳに関連付けられたＯＰは、資格証明書を検証することができる。
【０３６１】
７８５：ＳＣＷＳに関連付けられたＯＰは、一意的でランダムなアソシエーションハンドルＡを生成することができる。関数ｆを使用すると、アサーションメッセージのための署名秘密を、Ｓ＝ｆ（Ａ，Ｋ）によって計算することができ、ここで、ｆは、Ａの知識がＫについてのいかなる知識も明かさないように、一方向とすべきである。例示的な一実施形態では、ｆは、ＳおよびＡが明かされたとしても、Ｋについてのいかなる知識も明かすことはできず、すなわち、ＳおよびＡが与えられた場合、ある関数ｇについて、Ｋ＝ｇ（Ｓ，Ｋ）を計算することが、計算的に実行不可能であるべきである。
【０３６２】
Ａは、リダイレクトメッセージ内のパラメータの一部として、ＲＰに明かすことができるので、ＯｐｅｎＩＤプロトコル実行のステートレスモードでは、ＲＰがＳの知識を獲得しないと仮定することができる。アソシエーションハンドルＡは、リダイレクトメッセージに含めることができる。加えて、Ｓを使用して署名された署名済メッセージｍを与えても、シグネチャの検証者には、Ｋについてのいかなる情報も明かされ得ないと仮定することができる（対称鍵シグネチャが使用されるので、シグネチャの検証者は、シグネチャを検証するために、常にＳを所有していることが必要であり、したがって、シグネチャがＳを明かさないことを必要としない）。
【０３６３】
アソシエーションハンドルは、長さが２５５文字以下の文字列であると規定することができ、３３と１２６を含む３３〜１２６の範囲のＡＳＣＩＩ文字（印刷可能な非空白文字）のみから成ることができる。
【０３６４】
シグネチャを検証するためにＯＰＳＦによって使用される秘密は、シグネチャを生成するためにＳＣＷＳに関連付けられたＯＰによって使用される秘密と同じとすることができる。シグネチャの新しさは、次のステップで挿入されるＲＰノンスによって保証することができ、ＲＰノンスは、シグネチャの一部であることが要求される。ＯｐｅｎＩＤ仕様は、署名秘密自体の新しさについては何もいわないままである。秘密の暗号強度を保証すること、秘密の秘密性を維持すること、およびそれが必要な場合は、秘密の新しさを保証することは、ＯＰの責任とすることができる。ＯＰＳＦ、またはＳＣＷＳに関連付けられたＯＰは、この目的のために、署名秘密に対して、限られた存続期間または使用カウントを実施することができる。
【０３６５】
ツールキット対応のローカルＯＰは、ＳＣＷＳをバイパスして、ハンドセットとプロアクティブに通信するために、ＣＡＴを使用することができる。メッセージは、（例えば、ＳＭＳ−ＰＰベアラを介してＯＰＳＦに送信するために）標準的なＯＴＡ通りにフォーマットすることができる。これは、ＯＰＳＦが、ＭＮＯのＯＴＡシステムを介して、カードと通信することを必要とすることがある。別の例示的な実施形態では、ＢＩＰゲートウェイが、ツールキットメッセージのペイロードを抽出することができ、ハンドセットが、ＴＣＰ／ＩＰを使用して、それをＯＰＳＦに送信することができる。これも、メッセージがＭＮＯのＯＴＡサーバを通過することを必要とすることがある。加えて、ＳＣＷＳは、カードがＩＰアドレスを有せず、ＴＣＰ／ＩＰをサポートしない場合に限って、ＢＩＰを使用すべきであることを命じる。そのため、ＴＣＰ／ＩＰを使用したＳＣＷＳを介する送信が、期待されることであることがある。
ｄ．ＳＣＷＳに関連付けられたＯＰとＯＰＳＦとの間の共有秘密をもたらさなければならないことがある、さらなるオプションも適用することができる。そのような方法の実現可能性は、さらなる研究課題である。
【０３６６】
７９０：ＳＣＷＳに関連付けられたＯＰは、戻り先、アイデンティティ、およびモードなどのパラメータに対するシグネチャを計算することができる。
【０３６７】
７９５：ＳＣＷＳに関連付けられたＯＰは、７６５においてＲＰから受信したパラメータを含む、ＨＴＴＰリダイレクトメッセージをブラウザに送信することができる。追加的に、以下のものも、すなわち、
●ｏｐｅｎｉｄ．ｓｉｇｎｅｄパラメータ内の署名されたパラメータのリスト、
●ｏｐｅｎｉｄ．ａｓｓｏｃ＿ｈａｎｄｌｅパラメータ内のアソシエーションハンドルＡ、および
●ｏｐｅｎｉｄ．ｓｉｇパラメータ内のシグネチャ（ｂａｓｅ６４符号化）
も含むことができる。
【０３６８】
このメッセージは、ブラウザをＲＰの戻り先ＵＲＬにリダイレクトするために使用することができる。
【０３６９】
８００：ブラウザは、ユーザをＲＰの戻り先ＵＲＬにリダイレクトすることができる。
【０３７０】
８０５：ＲＰは、署名されたアサーションメッセージを受信することができ、ＨＴＴＰ（Ｓ）ベースの公衆インターネットを介する直接通信によって、ＯＰＳＦとともに検証手順に携わる。
【０３７１】
８１０：ＲＰは、７９５のＳＣＷＳに関連付けられたＯＰから受信したパラメータを含む、ＨＴＴＰ  ＰＯＳＴメッセージを発行することができる。ＨＴＴＰ  Ｐｏｓｔメッセージは、ＳＣＷＳに関連付けられたＯＰによって生成された、アソシエーションハンドルＡを含むことができる。
【０３７２】
８１５：ＯＰＳＦは、パラメータリストからＡを抽出することができ、同じ入力を有する、ＳＣＷＳに関連付けられたＯＰと同じ関数を使用することができ、すなわち、ＯＰＳＦは、ｆ（Ａ，Ｋ）＝Ｓを計算し、Ｓを共有鍵として使用して、ＳＣＷＳに関連付けられたＯＰから受信したデータ上のシグネチャを検証する。
【０３７３】
８２０：ＯＰＳＦは、シグネチャ検証が成功した場合、ｉｓ＿ｖａｌｉｄ：ｔｒｕｅを返すことができる。
【０３７４】
８２５：ＲＰからは、ユーザは、今ではｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙとして識別することができる。
【０３７５】
８３０：ブラウザは、ＲＰのＨＴＭＬページを表示することができる。
【０３７６】
８３５：ユーザは、ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙとして、ＲＰにおいてログインすることができる。
【０３７７】
４．４．２．４．３．２  アソシエーションベースモードを使用するＲＰのためのプロトコルフロー
図２７は、改良されたアソシエーションベースモードのためのプロトコルフローの例示的な一実施形態を示している。これは、例えば、ＲＰがアソシエーションベースモードを使用して、ＯｐｅｎＩＤユーザ認証を実行する場合に行うことができる。アソシエーションは、ユーザが最初にＲＰとコンタクトを取り、ＲＰとともに自らのＯｐｅｎＩＤ識別子を使用した後に、行うことができる。アソシエーションが確立された場合、それを再利用して、通信労力をさらに低減させることができる。しかし、ＯＰがＲＰの動作モードを命じることが可能でないことがあり、２つの通信モデルのうちの１つを決定することは、ＲＰに任されている。
【０３７８】
アソシエーションは、アサーションメッセージに署名するためにＯＰによって使用でき、ＯＰシグネチャを検証するためにＲＰによって使用できる、ＲＰとＯＰの間の永続的な秘密を確立することができる。ＯＰは、共有秘密の有効期間を決定することができる。ＲＰとＯＰは、アソシエーションハンドルを秘密のための識別子として使用することができる。ＲＰは、ＯＰへの第１の要求メッセージにアソシエーションハンドルを含めることができ、その後、ＯＰは、アソシエーションハンドルに応じて、対応する秘密を使用することができる。ＯＰは、アソシエーションが失効していると決定した場合、応答メッセージでＲＰに通知することができる。これは、ＯＰが、いかなるアソシエーション要求も拒否することを可能にすることができる。ＲＰが、ステートレスモードもサポートできるのであれば、これを使用して、ＲＰを強制的にステートレス通信モードに依存させることができる。ＲＰから要求されたシグネチャモード（ＨＭＡＣ−ＳＨＡ１またはＨＭＡＣ−ＳＨＡ２５６）がＯＰによってサポートされない場合、ＯＰは、例えば、アソシエーション要求を拒否することができる。
【０３７９】
ユーザがＲＰにログインするたびに、ＲＰとＯＰの間で新しい秘密が確立される、ステートレス通信モードとは対照的に、アソシエーションは、アイデンティティとＲＰ毎に１回確立することができる。例えば、ユーザがログインしたときに、図２７に示される項目が、必ずしもすべて実行されなくてもよい。ＯＰとＲＰの間のアソシエーションがすでに確立されている場合、それをＲＰとＯＰによって再利用することができる。
【０３８０】
ＲＰは、ＯＰＳＦのアドレスが分かると直ちに、すなわち、発見フェーズの後に、アソシエーションを確立することができ、プロトコルを先に進める前に、すなわち、アソシエーションハンドルをリダイレクトメッセージに含める前に、アソシエーションを完了することができる。
【０３８１】
図２７に示されるように、
８４０：ユーザは、ＲＰウェブサイトを訪れることができ、ＯｐｅｎＩＤを使用してログインするために、例えば、ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙなど、自らのＯｐｅｎＩＤ識別子を入力することができる。
【０３８２】
８４５：ブラウザは、ＯｐｅｎＩＤ識別子を含むＨＴＴＰメッセージを、ＲＰウェブサイトに送信することができる。
【０３８３】
８５０：ＲＰは、ＨＴＴＰ／ＨＴＭＬベースのＯｐｅｎＩＤ「シンプル」発見を使用することができ、公衆インターネットを介してＯＰ−Ａｇｇとコンタクトを取り、例えば、ＨＴＴＰ  ＧＥＴ  ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙによって、ＯｐｅｎＩＤ識別子のためのアイデンティティページを取り出す。
【０３８４】
８５５：ＯＰ−ａｇｇは、要求を受信することができ、例えば、
＜ｌｉｎｋ  ｒｅｌ＝“ｏｐｅｎｉｄ．ｓｅｒｖｅｒ”ｈｒｅｆ＝ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｓｅｒｖｅｒ．ｃｇｉ＞
を含めることによって、ＯＰＳＦのインターネットアドレスを含むＨＴＭＬページによって応答することができる。
【０３８５】
ＯＰＳＦのアドレスは、ＯＰ−ａｇｇのアドレスと異なることがある。
【０３８６】
８６０：ＲＰは、パラメータ
ｏｐｅｎｉｄ．ｍｏｄｅ＝ａｓｓｏｃｉａｔｅ、
ｏｐｅｎｉｄ．ａｓｓｏｃ＿ｔｙｐｅ＝ＨＭＡＣ−ＳＨＡ１、
ｏｐｅｎｉｄ．ｓｅｓｓｉｏｎ＿ｔｙｐｅ＝ｂｌａｎｋ、
ｏｐｅｎｉｄ．ｄｈ＿＊＝‘Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ  Ｐａｒａｍｅｔｅｒｓ’
を有する、ＯＰＳＦに対するＨＴＴＰ  ＰＯＳＴコールを使用することができる。
【０３８７】
８６５：ＯＰＳＦは、ＲＰのためのランダムで一意的なアソシエーションハンドルＡを生成することができる。加えて、ＯＰＳＦは、関数ｆを使用することができ、Ｓ＝ｆ（Ａ，Ｋ）を計算する。その後、Ｓは、ＲＰとＯＰＳＦの間のアソシエーション（中期）共有秘密として使用することができる。ＲＰは後で、Ｓを使用して、ＳＣＷＳに関連付けられたＯＰから来たアサーションメッセージ上のシグネチャを検証することができる。例示的な一実施形態では、ＡとＳは両方とも、８７０においてＲＰと共有することができるので、ＳとＡが与えられてもＫを計算できないように、ｆは、ＡとＳが分かったとしても一方向であり続ける関数であると仮定することができる。関数ｆ自体は、秘密であることを要求されなくてもよい。
【０３８８】
８７０：ＯＰＳＦは、キー＝バリューフォーマット文書内にアソシエーションハンドルＡおよび（ディフィ−ヘルマンが使用される場合は暗号化された）秘密Ｓを含む、ＨＴＴＰ  ＰＯＳＴによってＲＰに応答することができる。このアソシエーションは、ＲＰとＯｐｅｎＩＤアイデンティティ毎に１回確立することができる。これは、ＨＴＴＰＳ認証を使用することによって実行することができる。
【０３８９】
８８０：ＲＰは、例えば、
ｎｏｎｃｅ＝１２３１２３、
ｓｅｓｓｉｏｎ＝Ｕｓｅｒ
など、セッションノンスおよびセッション識別子を生成することができる。
【０３９０】
８８５：ＲＰは、ＯＰＳＦから受信した秘密ＳおよびアソシエーションハンドルＡを保存することができる。
【０３９１】
８９０：ＲＰは、アソシエーションハンドルＡをリダイレクトメッセージに含めることができる。
【０３９２】
８９５：ＲＰは、ＨＴＴＰ  ＲＥＤＩＲＥＣＴメッセージを、ブラウザに送信することができる。ＨＴＴＰ  ＲＥＤＩＲＥＣＴメッセージは、パラメータ
ｏｐｅｎｉｄ．ｍｏｄｅ＝ｃｈｅｃｋｉｄ＿ｓｅｔｕｐ、
ｏｐｅｎｉｄ．ｉｄｅｎｔｉｔｙ＝ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙ、
ｏｐｅｎｉｄ．ｒｅｔｕｒｎ＿ｔｏ＝ｈｔｔｐ：／／ｒｐ．ｏｒｇ／ｒｅｔｕｒｎ．ｃｇｉ？ｓｅｓｓｉｏｎ＝Ｕｓｅｒ＆ｎｏｎｃｅ＝１２３１２３、
ｏｐｅｎｉｄ．ａｓｓｏｃ＿ｈａｎｄｌｅ＝Ａ
を含むことができる。
【０３９３】
９００：ブラウザは、リダイレクトメッセージを受信することができ、リダイレクトメッセージ内のＲＰによって指定されたＵＲＬへの接続をオープンすることができる。
【０３９４】
例えば、エントリｈｔｔｐ：／／ｏｐ．ｏｒｇ＝＝１２７．０．０．１を有するホストファイルを使用することによって、ＯＰＳＦのＵＲＬをＳＣＷＳローカルＩＰアドレスにマッピングする、変更されたローカルＤＮＳルックアップテーブルを用いる場合、ブラウザは、ＳＣＷＳに関連付けられたローカルＯＰにリダイレクトすることができ、８８５のパラメータを含むＨＴＴＰ要求を発行する。
【０３９５】
変更されたローカルＤＮＳルックアップテーブルは、デバイス上に存在することができ、ＵＲＬ  ｈｔｔｐ：／／ｏｐ．ｏｒｇがＳＣＷＳのローカルＩＰアドレスにあるとデバイスに思わせることができる。
【０３９６】
９０５：ブラウザは、（公衆インターネットを介して到達可能な、ＵＲＬ  ｈｔｔｐ：／／ｏｐ．ｏｒｇにある）ＯＰＳＦに接続する代わりに、ＳＣＷＳ／ローカルＯＰへの接続をオープンすることができる。
【０３９７】
９１０：以下は、認証トラフィックをローカルに保つことを保証するために実行することができるが、これらのステップは、必須ではなく、ＯｐｅｎＩＤプロトコル仕様によって規定されていない。
ａ．ＳＣＷＳに関連付けられたＯＰが、ローカル認証ページを表示する。
ｂ．ユーザが、例えば、ユーザ名およびパスワードなど、自分の認証用資格証明書を入力する。
ｃ．ＳＣＷＳに関連付けられたＯＰが、資格証明書を検証する。
【０３９８】
９１５：ＳＣＷＳに関連付けられたＯＰは、リターンメッセージに署名するために、ＯＰＳＦとＲＰの間で共有できる秘密Ｓを使用することを必要とすることがある。パラメータＡは、受信したＨＴＴＰ要求から抽出することができ、関数ｆは、Ｓ＝ｆ（Ａ，Ｋ）のように適用される。
【０３９９】
９２０：ＳＣＷＳに関連付けられたＯＰは、秘密を使用して、戻り先ＵＲＬ、アイデンティティ、およびモードパラメータに対するシグネチャを計算することができる。Ｓを使用して署名された署名済メッセージｍを与えても、ｍ上のシグネチャの検証者には、Ｋについてのいかなる情報も明かされ得ないような関数ｆが必要なことがある。
【０４００】
９２５：ＳＣＷＳに関連付けられたＯＰは、シグネチャを追加パラメータとしてＨＴＴＰリダイレクトに含めることができる。
【０４０１】
９３０：ＳＣＷＳに関連付けられたＯＰは、以下のパラメータを含む、すなわち、
ｏｐｅｎｉｄ．ｍｏｄｅ＝ｉｄ  ｒｅｓ、
ｏｐｅｎｉｄ．ｒｅｔｕｒｎ＿ｔｏ＝ｈｔｔｐ：／／ｒｐ．ｏｒｇ／ｒｅｔｕｒｎ．ｃｇｉ？ｓｅｓｓｉｏｎ＝Ｕｓｅｒ＆ｎｏｎｃｅ＝１２３１２３、
ｏｐｅｎｉｄ．ｉｄｅｎｔｉｔｙ＝ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙ、
ｏｐｅｎｉｄ．ｓｉｇｎｅｄ＝ｍｏｄｅ，ｉｄｅｎｔｉｔｙ，ｒｅｔｕｒｎ＿ｔｏ、
ｏｐｅｎｉｄ．ａｓｓｏｃ＿ｈａｎｄｌｅ＝Ａ、
ｏｐｅｎｉｄ．ｓｉｇ＝‘ｂａｓｅ６４  ｅｎｃｏｄｅｄ  ｓｉｇｎａｔｕｒｅ  ｃａｌｃｕｌａｔｅｄ  ｕｓｉｎｇ  Ｓ’
を含む、ＨＴＴＰリダイレクトメッセージを、ブラウザに送信することができる。
【０４０２】
９３５：ユーザがさらにいかなる関与も行わなくても、ブラウザは、ＲＰにおける戻り先ＵＲＬにユーザをリダイレクトすることができる。
【０４０３】
９４０：ＲＰは、署名されたアサーションメッセージを受信することができる。
【０４０４】
９４５：ＲＰは、確立された共有秘密Ｓを使用して、シグネチャを検証することができる。
【０４０５】
９５０：ＲＰからは、ユーザは今では、ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙとして識別することができる。
【０４０６】
９５５：ブラウザは、ＲＰのＨＴＭＬページを表示することができる。
【０４０７】
９６０：ユーザは、ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙとして、ＲＰにおいてログインすることができる。
【０４０８】
アソシエーションベースモードについての追加の実施形態
セクション４．４．１．４．３で説明されたステートレスプロトコル実施形態に関連する追加の実施形態が以下で開示される。
【０４０９】
４．４．２．５  ＳＣＷＳ上の改良ＯＰと既存のＯｐｅｎＩＤ／ＧＢＡとの比較
ＯｐｅｎＩＤ／ＧＢＡでは、ユーザは、ＧＢＡプロトコルを使用して認証を受け、すなわち、任意のＲＰにおいてＯｐｅｎＩＤログインが試みられるたびに、エアインタフェースを介したＯＰ／ＮＡＦを用いるＧＢＡ実行がトリガされ、増加するトラフィックによって、ネットワークエンティティ（ＯＰ／ＮＡＦ）とネットワーク自体の両方に対する負荷を生じさせる。１万人のユーザからなる顧客ベースが与えられ、毎日、すべてのユーザが１０の異なるＲＰにログインすると仮定する。ＯｐｅｎＩＤ／ＧＢＡの下では、これは、１日当たり、合計で１０万回のＧＢＡ認証実行をもたらし、各ＧＢＡ実行（誰何＋応答）が１〜５キロバイトしか消費しない場合でも、これは、１日当たり、合計で１〜４．８ＧＢの追加の認証トラフィックとなる。
【０４１０】
４．４．２．６  セキュリティについての説明
以下のセクションでは、ステートレスモードおよびアソシエーションベースモードのＳＣＷＳ上のＯＰのプロトコルについての例示的な実施形態において使用できる、暗号ツールについての予備知識を提供する。使用できるハッシュアルゴリズムなどの態様が説明される。
【０４１１】
４．４．２．６．１  全般
関数ｆを使用して、ローカルＯＰとＯＰＳＦの間で共有秘密Ｓを確立することができる。ＯＰＳＦとローカルＯＰは、ｆの１つの入力として使用できる、共通の共有長期秘密Ｋを有することができ、Ｋは、プロトコルにおける別の当事者に決して明かすことはできない。しかし、ＲＰは、アサーションメッセージ上のシグネチャを検証できるので、アソシエーションベースモードでは、秘密ＳをＲＰに明かすことができる。秘密の共有は、セキュリティと密接に関係し得るので、Ｓの知識に関してＲＰが有する選択肢について説明する必要があるであろう。
【０４１２】
これは、標準的なＯｐｅｎＩＤプロトコルにも適用することができる。ＲＰに悪意があると仮定した場合、Ｓの知識は、ＲＰが、ユーザを別のＲＰにおいてログインさせることを可能にすることはできず、それは、別のＲＰは、ＯＰとともに別の共有秘密Ｓ’を確立しており、したがって、Ｓを使用して行われたシグネチャを無効と認識するからである。したがって、秘密ＳをＲＰに明かすことは、セキュリティ上の問題にはなり得ない。しかし、Ｓをブラウザ（またはユーザ）に明かすことは、セキュリティ上の問題になり得る。この場合、攻撃者は、被害者のＯｐｅｎＩＤ識別子を用いて、ＯｐｅｎＩＤプロトコルを開始することができる。攻撃者が、ＲＰとＯＰの間で共有される共有秘密Ｓを取り出すことができたとすると、攻撃者は、実際の認証をＯＰに対して実行しなくても、Ｓを使用して、アサーションメッセージに署名することができる。したがって、攻撃者は、被害者のＯＰから認証を受けることなく、被害者の識別子を使用してログインすることができる。このシナリオから分かるように、ＲＰとＯＰの間の共有秘密Ｓは、ブラウザに明かすことはできないが、ＳをＲＰに明かすことは、問題なしとすることができる。
【０４１３】
悪意あるユーザとＲＰが一緒に動作する場合、ＲＰは、Ｓをブラウザに送信することができ、ユーザは、ＯＰから認証を受けることなく、ＲＰにログインすることができる。しかし、ユーザは、シナリオの仮定によれば、すでにユーザの制御下にある（または少なくともユーザと協力する）、単一のＲＰにログインできるだけなので、これを攻撃と見なすことはできない。したがって、ユーザは、ＯｐｅｎＩＤ認証プロトコル実行をまったく実行しなくても、ログインすることができる。
【０４１４】
４．４．２．６．２  例示的なプロトコルのセキュリティ特徴
ある例示的な実施形態では、リダイレクトメッセージ内の、Ｓを使用して署名されたメッセージばかりでなく、Ａも、ブラウザに明かすことができ、Ａの知識と、Ｓを使用して署名されたメッセージとを与えても、Ｓを計算することは実現不可能とすることができる。さらに、同じ入力を与えても、Ｋを計算することは実現不可能とすることができる。
【０４１５】
ＡとＳ（ＯＰとＯＰＳＦ以外の単一のサードパーティに明かすことができるほとんどの情報）を与えても、Ｋを導出することが計算的に実現不可能である（すなわち、入力の長さのものを多項式時間で計算できる、ｆ−１（Ａ，Ｓ）＝Ｋのような関数ｆ−１が存在しないと仮定できる）ことが要求される場合、ＲＰは、ＯＰＳＦとＳＣＷＳに関連付けられたＯＰとの間の長期共有秘密Ｋを導出することはできない。
【０４１６】
したがって、ランダムな入力Ａと共有秘密Ｋを与えた場合に、ｆが、Ｓ＝ｆ（Ａ，Ｋ）のように、新しい秘密Ｓを生成することを必要とすることができる。Ａ（およびＳを使用して署名されたメッセージ）を与えた場合、Ｓを計算することは実現不可能とすることができる。それは、入力Ｋが正しく、現在のものである場合に、ｆが正しい結果を生成できることを必要とすることができる。
【０４１７】
ｆの計算は、多項式時間で可能とすることができ、好ましくは、スマートカードの保護された領域で行うことができる。
【０４１８】
Ｓは、ＯｐｅｎＩＤにおいて使用されるシグネチャ関数にとっての有効な入力とすることができる。ＯｐｅｎＩＤは、シグネチャアルゴリズムとしてＨＭＡＣ−ＳＨＡ１またはＨＭＡＣ−ＳＨＡ２５６の使用を見込んでいる。ＯＰＳＦとＳＣＷＳに関連付けられたＯＰとは、あらかじめ特定のシグネチャアルゴリズムに合意できるので、鍵長を、したがって、関数ｆの出力長を固定することができる。例示的な一実施形態では、ＳＨＡ１ベースのシグネチャの場合は、Ｋを使用して、Ｓを導出でき、ＳＨＡ２５６シグネチャの場合は、Ｋ’を使用して、Ｓを導出できるように、ＯＰＳＦとＯＰは、２つの共有秘密ＫおよびＫ’を使用することができる。
【０４１９】
４．４．２．６．３  セキュリティ実施
本セクションで説明される実施形態は、先のセクションで指摘された要件を満たすことができる暗号操作である。例示的な一実施形態では、秘密は、ＯｐｅｎＩＤメッセージ内に直接的に含めることができ、そうすることで、認証のために必要とされるトラフィックの減少をもたらすことができる。ユーザ認証は、ローカルに（ＭＮＯネットワークが関与せずに）実施することができ、ＯＰＳＦ（ＭＮＯネットワーク）と（デバイス内の）ＳＣＷＳに関連付けられたＯＰとの間の共有秘密は、ＭＮＯネットワークとデバイスの間のさらなる外部的な追加の通信を必要とせずに、ＯｐｅｎＩＤプロトコルメッセージ内に収めて安全に伝達することができる。
【０４２０】
４．４．２．６．３．１  ＨＭＡＣ
ＨＭＡＣは、いかなる追加メカニズムも使用せずに、メッセージのソースとメッセージの完全性の両方を認証するための、鍵付きハッシュメッセージ認証コード（ＭＡＣ）である。ＨＭＡＣは、メッセージ入力と、メッセージの発信者および意図された受信者にのみ知られた秘密鍵という、２つの機能的に異なるパラメータを有する。
【０４２１】
ＨＭＡＣ関数は、秘密鍵とメッセージ入力とを要約することによって形成される値（ＭＡＣ）を生成するために、メッセージの送信者によって使用される。ＭＡＣは、一般に、メッセージとともにメッセージ受信者に送信される。受信者は、送信者によって使用されたのと同じ鍵とＨＭＡＣ関数を使用して、受信したメッセージに対してＭＡＣを計算し、計算された結果を受信したＭＡＣと比較する。２つの値が一致した場合、メッセージは、正しく受信されており、受信者は、送信者が鍵を共有するユーザからなるコミュニティのメンバであることを保証される。
【０４２２】
ＨＭＡＣの特性を考えると、関数ｆのためのＨＭＡＣの使用は、上で説明されたすべての関連要件を満たすことができる。
【０４２３】
ＨＭＡＣのための関連パラメータのリストを以下に示す。
●Ｂ−ハッシュ関数の入力のブロックサイズ、例えば、ＳＨＡ１の場合は１６０ビット。
●Ｈ−ハッシュ関数（例えばＳＨＡ１）。
●ｉｐａｄ−内側パッド、ｘ‘３６’であるバイトがＢ回反復する。
●Ｋ−ＯＰとＯＰＳＦの間で共有される秘密鍵。
●Ｋ０−Ｂバイトの鍵を取得するために前処理した後の鍵Ｋ
●Ｌ−ハッシュ関数の出力のブロックサイズ、例えば、ＳＨＡ１の場合は１６０ビット。
●ｏｐａｄ−外側パッド、ｘ‘５ｃ’であるバイトがＢ回反復する。
●ｔ−ＭＡＣのバイト数。
●ｔｅｘｔ−長さがｎビット（０＜＝ｎ＜２＾Ｂ−８Ｂ）の、ＨＭＡＣを計算するもととなる平文であり、われわれのケースでは、Ａに相当する。
●｜｜−連結
●ＸＯＲ−排他的ＯＲ
●Ｋは、Ｌ／２以上であるべきであり、すなわち、われわれのケースでは、Ｋは、ＳＨＡ１が使用される場合、８０ビットより大きく、ＳＨＡ２５６の場合、１２８ビットより大きくすべきである。
●ＭＡＣ（ｔｅｘｔ）＝ＨＭＡＣ（Ｋ，ｔｅｘｔ）＝Ｈ（（Ｋ０  ＸＯＲ  ｏｐａｄ）｜｜Ｈ（（Ｋ０  ＸＯＲ  ｉｐａｄ）｜｜ｔｅｘｔ））
【０４２４】
ＭＡＣを計算するために２つのハッシュ関数の実行をネストさせることが、攻撃を防ぐために必要となることがある。ほとんどのハッシュ関数では、鍵Ｋを知ることなく、付加的なデータをメッセージに追加し、別の有効なＭＡＣを獲得することが可能である。他の代替を使用する場合、ＭＡＣ＝Ｈ（ｍｅｓｓａｇｅ｜｜ｋｅｙ）を使用して鍵を追加することは、（鍵なし）ハッシュ関数において衝突を見つけることができる攻撃者が、ＭＡＣにおいて衝突を取得することを可能にする。ＭＡＣ＝Ｈ（ｋｅｙ｜｜ｍｅｓｓａｇｅ｜｜ｋｅｙ）を使用するほうがより好ましいが、様々なセキュリティ論文が、脆弱性を明らかにしており、２つの異なる鍵が使用される場合であっても脆弱である。
【０４２５】
図２８は、文献から引用した（例えば、非特許文献３参照）鍵付きハッシュメッセージ認証コード（ＨＭＡＣ）を示している。
【０４２６】
ＨＭＡＣの現在合意されているバージョンは、外側のハッシュ関数が、内側のハッシュ関数の中間結果をマスクするので、これらの脆弱性にさらされていない。パディング（ｉｐａｄおよびｏｐａｄ）の値は、アルゴリズムの安全性にとって重要ではないが、互いに大きなハミング距離を有するように定義され、そのため、内側の鍵と外側の鍵は、共通するビットを僅かしか有さず、すなわち、パディングは、ハッシュ関数において使用される２つの異なる鍵を、Ｋ０から「導出」するために使用される。
【０４２７】
例示的な一実施形態では、ｔｅｘｔ＝ランダムな入力としてのＡは、ＯＰまたはＯＰＳＦによってそれぞれ生成することができる。Ａは、リダイレクトメッセージに含めることができ、Ｋを使用して、ＯＰとＯＰＳＦは、上述のメカニズムを使用してＨＭＡＣを再計算することができ、ＨＭＡＣ結果は、ＯｐｅｎＩＤアサーションメッセージのための共有署名秘密Ｓとして、使用することができる。
【０４２８】
４．４．２．６．３．２  ＳＣＷＳ上の改良ＯＰのプロトコルのセキュリティ証明
示す必要があることは、
１．プロトコルにおいて、攻撃者は、（例えば、アソシエーションモードにおけるＲＰとして）ＡおよびＳを取り出すことができ、したがって、攻撃者がＫを取り出すことは不可能であることが示されなければならない。
【０４２９】
２．ブラウザ／ユーザは、ＲＰよりもさらに僅かしか、すなわち、Ａだけしか取り出さず、Ａについての知識からＳを計算できてはならない。
【０４３０】
３．ブラウザ／ユーザは、ＡからＫも計算できてはならない。攻撃者がＳについての与えられた情報を使用しない、ＳおよびＡについての知識を有する攻撃者をモデル化した場合、３についての証明は、１から導出することができる。
【０４３１】
したがって、以下のことを示さなければならない。
Ｉ．ＳおよびＡが与えられた場合、Ｓ＝ｆ（Ａ，Ｋ）として、Ｋ＝ｆ＊（Ａ，Ｓ）であるような関数ｆ＊が存在してはならない。
ＩＩ．Ａだけが与えられた場合、Ｓ＝ｆ（Ａ，Ｋ）として、Ｓ＝ｇ（Ａ）であるような関数ｇが存在してはならない。
【０４３２】
どちらの定理も、（１１）においてＢｅｌｌａｒｅ他によって提示された、ＨＭＡＣ（またはＮＭＡＣ）についての説明の中に、それらの証明が見出され、それらは、ＨＭＡＣが、基礎をなす圧縮ハッシュ関数が疑似ランダムであり、その関数は衝突困難性が弱いことを仮定した、疑似ランダム関数であることを本質的に示している。（１２）では、これらの仮定は、圧縮関数がＰＲＦであるというただ１つの仮定の下で、ＨＭＡＣがＰＲＦであることを示すことによって緩和される。
【０４３３】
４．４．２．６．３．３  ＲＳＡ
例示的な一実施形態では、ＯＰＳＦとＳＣＷＳに関連付けられたＯＰとの間で共有しなければならない秘密鍵を用いて、ランダムに生成された一意的なアソシエーションハンドルを暗号化することによって、共有鍵ＫからＯｐｅｎＩＤシグネチャ秘密Ｓを導出するために、ＲＳＡ暗号化方式を使用することができる。Ｎ＝ｐｑが、ＲＳＡ方式で使用される法を表すとし、ｐ、ｑは、素数であるとする。さらに、鍵ペアは、ｅ、ｄ（秘密、公開）によって表され、長期秘密Ｋとして共有される。その後、秘密部分ｅを使用して、アソシエーションハンドルＡに署名を行い、シグネチャ秘密Ｓを取得する、すなわち、Ｓ＝Ａｅ  ｍｏｄ  Ｎとする。ＲＳＡについてのセキュリティ仮定を考えると、公開鍵ｄを知っている場合、ＳからＡを計算することは可能になり得るが、ＡおよびＳを与えても、ｅを計算することは可能になり得ない。Ａだけを与えた場合、ｅについての知識なしに、Ｓを計算することは可能ではない。
【０４３４】
４．４．２．６．４  セキュリティ実施の変形
４．４．２．６．４．１  長期秘密Ｋの変更
セクション４．４．２で説明された、例示的な一実施形態では、長期秘密Ｋが使用されるが、この秘密は、例えば、一定の期間の後、ＯＰＳＦとＳＣＷＳに関連付けられたＯＰとの間の鍵交換方法を使用して、変更することができる。知られた任意の鍵交換方法を使用することができる。
【０４３５】
Ｋの変更は、ＯＰＳＦにおいて実行することができ、ＳＣＷＳに関連付けられたＯＰは、成功したＯｐｅｎＩＤプロトコル実行を阻むことはできない。
【０４３６】
例示的な一実施形態では、ステートレスモードにおいて、ＯＰＳＦとＯＰが、新しい長期秘密Ｋ’に合意した場合、ＯＰは、新しい鍵とともに関数ｆを使用して、署名鍵Ｓ’を計算することができ、すなわち、Ｓ’＝ｆ（Ａ，Ｋ’）とすることができる。その後、Ｓ’は、アサーションメッセージに署名するために使用することができ、ＯＰＳＦは、新しい長期共有秘密Ｋ’を使用して、Ｓ’を再計算することによって、アサーションメッセージ上のシグネチャを検証することができる。
【０４３７】
別の例示的な実施形態では、アソシエーションベースモードにおいて、新しい秘密の長期秘密Ｋ’が確立された場合、ＲＰは、アソシエーションのために保存された旧い秘密Ｓを依然として有することがある。アソシエーションがまだ有効であり、ＲＰがＯＰＳＦとのアソシエーションステップに係わらない場合、ＲＰは、旧いアソシエーションハンドルＡを直接的に使用することがあり、ＯＰからのアサーションメッセージが、すでに保存された秘密Ｓを使用して署名されていることを期待することがある。しかし、ＯｐｅｎＩＤ仕様は、ＯＰが、パラメータｏｐｅｎｉｄ．ｉｎｖａｌｉｄａｔｅ＿ｈａｎｄｌｅをアサーションメッセージに含めることを可能にする。このパラメータが使用され、旧いアソシエーションハンドルＡに設定された場合、ステートレスシナリオにおけるように、シグネチャ検証のために、ＲＰを強制的にＯＰに戻らせることができる。これは、長期共有秘密が、新しいＫ’であり、シグネチャ秘密が、新たに生成されたアソシエーションハンドルＡ’を使用した、新しいＳ’＝ｆ（Ａ’，Ｋ’）である場合にＡに設定される、このパラメータを、ＳＣＷＳに関連付けられたＯＰが含むことを可能にすることができる。これは、ＲＰにおいてハンドルを無効化することができ、ＲＰは、シグネチャ検証のために、ＯＰＳＦとコンタクトを取ることができる。ＯＰＳＦは、鍵交換のせいで、すでにＫ’を有していることができ、したがって、Ｓ’＝ｆ（Ａ’，Ｋ’）を計算することができ、アサーションメッセージ上のシグネチャを検証することができる。しかし、ＲＰが、ＯＰＳＦとの新しいアソシエーションセッションに係わる場合、ＯＰＳＦも、ハンドルＡを無効化することができ、新しい鍵Ｋ’を使用して、ＲＰとともに新しいペアＡ’，Ｓ’を確立することができる。
【０４３８】
４．４．２．６．４．２  Ｋについてのハッシュチェインコミットメント
例示的な一実施形態では、ＯＰＳＦとＳＣＷＳに関連付けられたＯＰとは、長期秘密Ｋを定期的に変更することを望むことがある。秘密Ｋに基づいて、両方のエンティティは、チェインをもたらす以下の方法で、（暗号的に安全な）ハッシュ関数ｈをＫに適用することによって、すなわち、Ｋ０＝ｈ（Ｋ）、Ｋ１＝ｈ（Ｋ０）＝ｈ（ｈ（Ｋ））、．．．、Ｋｎ＝ｈ（Ｋｎ−１）＝ｈｎ（Ｋ）によって、ハッシュチェインコミットメント（ｈａｓｈ−ｃｈａｉｎ  ｃｏｍｍｉｔｍｅｎｔ）を実行することができる。初期秘密Ｋが安全に確立できる場合、ＯＰとＯＰＳＦは、このチェインを独立に計算することができる。その場合、使用される最初の共有秘密は、Ｋｎとすることができる。ハッシュチェインを構築するのに使用されるハッシュ関数の一方向性を考えると、この値は、攻撃者が、以降の共有秘密Ｋｎ−１を直接的に計算することを可能にし得ない。攻撃者は、次の秘密を得るために、ハッシュ関数を逆転させなければならない。秘密は、ＯＰＳＦとローカルＯＰによって、ハッシュチェインの逆順に使用される。セキュリティをさらに改善するために、ＯＰＳＦとローカルＯＰによる現在の値の廃棄と次の値の計算である、ハッシュチェイン内の次の値への移行は、いくつかの方針に従うことができ、例えば、毎月、毎日、セッション毎などに実行することができる。
【０４３９】
４．４．２．６．５  ＡＫＡ  ＡＶおよび秘密の再利用、ＡＫＡ資格証明書からのハッシュチェインの構築
例示的な一実施形態では、ＯＰＳＦは、ＭＮＯにおいてネットワーク機能と共存することができ、ネットワーク機能は、ＯＰＳＦが、ＨＬＲ（ホームロケーションレジスタ）、およびＭＮＯのＡｕＣ（認証センタ）から、ＡＫＡ認証ベクトル（ＡＶ：Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｖｅｃｔｏｒ）を取り出すことを可能にすることができる。ＯＰＳＦは、ＡＶを取り出すことができ、ＳＣＷＳに関連付けられたＯＰを誰何するために、それらの１つを選択することができる。このＡＶを使用することによって、ＯＰＳＦとＳＣＷＳに関連付けられたＯＰとは、共有秘密ＣＫを確立することができ、その後、共有秘密ＣＫは、ＯｐｅｎＩＤのための長期共有秘密Ｋとして使用することができる。別の例示的な実施形態では、長期秘密を確立する代わりに、ＯＰとＯＰＳＦは、ハッシュチェインに対するコミットメントを確立することができ、その値は、ＯＰＳＦとＳＣＷＳに関連付けられたＯＰとの間の共有秘密として使用される。これは、長期共有秘密を確立するための安全な方法とすることができる。
【０４４０】
４．４．２．７  改良の利点の要点
本セクションは、特にこの改良された変形において、ＳＣＷＳ上のＯＰによって提供され得る、利点を明瞭化することを意図している。
【０４４１】
４．４．２．７．１  標準的なＯｐｅｎＩＤ
図２９は、標準的なＯｐｅｎＩＤプロトコルフローを示している。（例えば、ｍｙｏｐｅｎｉｄ．ｃｏｍなどの）既存のウェブベースのＯｐｅｎＩＤ  ＯＰサーバを使用して、モバイルデバイスからＲＰにアクセスするために、標準的なＯｐｅｎＩＤプロトコル実行が使用される。
【０４４２】
図２９に示されるように、ローカルトラフィックは存在せず、エアネットワークからオフロードされるトラフィックは、発見プロセスと、ＲＰとＯＰの間のアソシエーション確立である。ＯＰはウェブサービスであるので、ユーザ／ブラウザ／デバイスとＯＰの間のすべての通信は、エアインタフェースを介する。
【０４４３】
９６５および９７５において、無線通信が発生し、無線通信は、一般にはデータトラフィック（例えば、ＨＴＴＰ、ＩＰベースの通信）として、ＭＮＯ／エアネットワーク上で実施され、ＭＮＯネットワークにかかる負荷を表す。
【０４４４】
９７０において、トラフィックは、有線インターネット上で発生し、既存のインフラストラクチャを使用することができる。
【０４４５】
４．４．２．７．２  ＯｐｅｎＩＤ／ＧＢＡ
図３０は、ＯｐｅｎＩＤ／ＧＢＡのためのトラフィックフローを示している。この図は、文献の１３ページにある図４−４  １．１から引用されている（例えば、非特許文献２参照）。
【０４４６】
図３０に示されるように、ＲＰとＭＮＯの間のアソシエーションステップにも係わらず、すべての通信は、エアネットワークを介して行われる。例えば、９８０および９８５における信号は、ＭＮＯ／エアネットワークを介してデータトラフィックとして実施される、無線通信を介し、ＭＮＯネットワークにかかる負荷を表す。ウェブベースのＯＰと比較して、ＯｐｅｎＩＤ／ＧＢＡでは、トラフィックがさらに増加するが、それは、認証のために追加のステップが必要とされるからであり、そのことが、エアデータネットワークばかりでなく、ＧＢＡ認証のために必要とされるバックエンドサービス、すなわちＢＳＦおよびＮＡＦサブシステムにも負担をかける。したがって、エアネットワークトラフィックの増加と、ネットワークエンティティにおける負荷の増加が存在する。
【０４４７】
４．４．２．７．３  簡略化されたアソシエーションベース通信
図３１は、アソシエーションベース通信モードのためのプロトコルフローの例示的な一実施形態を示している。図３０に示されるように、無線トラフィックは、エアインタフェースネットワークトラフィックが減少するように、ローカルデバイスにオフロードすることができる。これを行うことで、例えば、認証トラフィックがローカルになることを可能にすることができ、その結果、認証トラフィックは、エアインタフェースネットワークまたはネットワークサービスにかかる負担を最小化する。加えて、発見および／またはアソシエーショントラフィックは、エアインタフェースネットワークを介して発生しなくてもよく、有線公衆インターネット上で行うことができる。
【０４４８】
９９０において、ユーザは、ブラウザなどのユーザインタフェースと対話することができ、ＲＰを訪れることができ、ＯｐｅｎＩＤを使用してログインを要求することができる。９９５において、ＲＰとＯＰ（ＭＮＯ）は、ＯｐｅｎＩＤアイデンティティに基づいて、ＯＰサーバの発見を実行することができる。１０００において、ＲＰは、アソシエーション要求をＯＰに送信することができる。ＯＰは、ランダムで一意的なアソシエーションハンドルＡを生成することができ、鍵Ｓを計算することができる。ＯＰは、アソシエーション応答をＲＰに送信することができる。アソシエーション応答は、アソシエーションハンドルＡと、鍵Ｓとを含むことができる。ＲＰは、鍵ＳとアソシエーションハンドルＡを保存することができる。
【０４４９】
１００５において、ＲＰは、リダイレクトをブラウザに送信することができる。リダイレクトは、ブラウザをＯＰにリダイレクトすることができ、要求パラメータにアソシエーションハンドルＡを含めることができる。ＯＰは、ＳＣＷＳに関連付けることができる。ブラウザは、リダイレクトを受信することができ、ＳＣＷＳにマッピングするように変更されたローカルＤＮＳルックアップを実行することができる。１０１０において、ブラウザは、認証のためのローカル要求をＯＰに送信することができる。１０１５において、認証をローカルに行うことができる。例えば、１０２０において、ＯＰは、長期共有秘密鍵ＫとアソシエーションハンドルＡに基づいて、資格証明書を検証することができる。加えて、ＯＰは、鍵Ｓを計算することができ、鍵Ｓを使用して、シグネチャを計算することができる。シグネチャは、アサーションメッセージに署名するために、ならびに／または戻りＵＲＬ、アイデンティティ、および／もしくはモードなどのパラメータに署名するために使用することができる。
【０４５０】
１０２５において、ＯＰは、ＲＰを訪れるようにブラウザに命令することができるリダイレクトを、ブラウザに送信することができる。リダイレクトは、アソシエーションハンドルＡと、署名されたパラメータとを含むことができる。１０３０において、ブラウザは、ＯＰからの署名されたアサーションメッセージを含むことができる要求を、ＲＰに送信することができる。ＲＰは、鍵Ｓを使用して、アサーションメッセージ上のシグネチャを検証することができる。その後、１０３５において、ＲＰは、ブラウザが、ログインページを表示することを可能にすることができ、サービスへのアクセスをブラウザに提供することができる。
【０４５１】
例示的な一実施形態では、ＳＣＷＳに関連付けられたＯＰとＭＮＯとの間に長期共有鍵が存在すると仮定することができる。
【０４５２】
図３１に示されるように、１０１０、１０１５、１０２０、および１０２５は、ＭＮＯ／エアネットワークに負荷をかけ得ないローカル通信を表す。加えて、これらの通信は、デバイス内部で起こり得るので、他の（有線または非ＭＮＯ）ネットワーク上でのトラフィックを伴わずに、行うことができる。
【０４５３】
９９０、１００５、１０３０、および１０３５は、無線通信を表し、無線通信は、データトラフィック（例えば、ＨＴＴＰ、ＩＰベースの通信）として、ＭＮＯ／エアネットワーク上で実施することができ、ＭＮＯネットワークにかかる負荷を表すことができる。
【０４５４】
９９５および１０００は、有線インターネットなどの有線上で発生でき、既存のインフラストラクチャを使用できる、トラフィックを表す。この通信は、ＭＮＯ／エアインタフェースネットワークにかかる負荷を増加させ得ない。
【０４５５】
図３２は、アソシエーションベース通信モードのためのプロトコルフローの別の例示的な実施形態を示している。図３２に示されるように、無線トラフィックは、エアインタフェースネットワークトラフィックが減少するように、ローカルデバイスにオフロードすることができる。これを行うことで、例えば、認証トラフィックがローカルになることを可能にすることができ、その結果、認証トラフィックは、エアインタフェースネットワークまたはネットワークサービスにかかる負担を最小化する。加えて、発見および／またはアソシエーショントラフィックは、エアインタフェースネットワークを介して発生しなくてもよく、有線公衆インターネット上で行うことができる。
【０４５６】
１０４０において、ユーザは、ブラウザなどのユーザインタフェースと対話することができ、ＲＰを訪れることができ、ＯｐｅｎＩＤを使用してログインを要求することができる。１０４５において、ブラウザは、ＯｐｅｎＩＤアイデンティティＵＲＬを含むことができるＨＴＴＰメッセージを、ＲＰに送信することができる。１０５０において、ＲＰとＯＰ（ＭＮＯ）は、ＯｐｅｎＩＤアイデンティティに基づいて、ＯＰサーバの発見を実行することができる。例えば、ＲＰは、ＨＴＴＰ（Ｓ）ＧＥＴアイデンティティページメッセージをＯＰに送信することができ、ＯＰは、ＯｐｅｎＩＤ  ＩＤＰサーバアドレスによって応答することができる。
【０４５７】
１０５５において、ＲＰは、アソシエーション要求をＯＰに送信することができる。例えば、ＲＰは、ＨＴＴＰ（Ｓ）ＰＯＳＴをＯＰに送信することができる。ＯＰは、ランダムで一意的なアソシエーションハンドルＡを生成することができ、秘密Ｓを計算することができる。ＯＰは、アソシエーション応答をＲＰに送信することができる。例えば、ＯＰは、ＨＴＴＰ（Ｓ）ＰＯＳＴをＲＰに送信することができる。アソシエーション応答は、アソシエーションハンドルＡと、秘密Ｓとを含むことができる。ＲＰは、秘密ＳとアソシエーションハンドルＡを保存することができる。ＲＰは、ノンスおよびセッション識別子を生成することができる。
【０４５８】
１０６０において、ＲＰは、リダイレクトをブラウザに送信することができる。例えば、ＲＰは、ＨＴＴＰ  ＲＥＤＩＲＥＣＴをブラウザに送信することができる。リダイレクトは、ブラウザをＯＰにリダイレクトすることができ、要求パラメータにアソシエーションハンドルＡを含むことができる。ＯＰは、ＳＣＷＳに関連付けることができる。ブラウザは、リダイレクトを受信することができ、ＳＣＷＳにマッピングするように変更されたローカルＤＮＳルックアップを実行することができる。１０６５において、ブラウザは、認証のためのローカル要求をＯＰに送信することができる。例えば、ブラウザは、リダイレクトに含まれるパラメータを含むことができる、ＨＴＴＰ  ＧＥＴ  ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｓｅｒｖｅｒ．ｃｇｉをＯＰに送信することができる。
【０４５９】
１０７０において、認証をローカルに行うことができる。ブラウザは、ユーザ認証用資格証明書を要求する認証ページを、ユーザに提示することができる。ユーザは、ユーザ名およびパスワードを含むことができる、認証用資格証明書を入力することができる。１０７５において、ＯＰは、長期共有秘密鍵ＫとアソシエーションハンドルＡに基づいて、資格証明書を検証することができる。加えて、ＯＰは、秘密Ｓを計算することができ、Ｓを使用して、シグネチャを計算することができる。シグネチャは、アサーションメッセージに署名するために、ならびに／または戻りＵＲＬ、アイデンティティ、および／もしくはモードなどのパラメータに署名するために使用することができる。
【０４６０】
１０８０において、ＯＰは、ＲＰを訪れるようにブラウザに命令することができるリダイレクトを、ブラウザに送信することができる。例えば、ＯＰは、ＨＴＴＰ  ＲＥＤＩＲＥＣＴをＲＰに送信することができる。リダイレクトは、アソシエーションハンドルＡと、署名されたパラメータとを含むことができる。１０８５において、ブラウザは、ＯＰからの署名されたアサーションメッセージと、ＯＰによって提供されたパラメータとを含むことができる要求を、ＲＰに送信することができる。例えば、ブラウザは、ＨＴＴＰ  ＧＥＴ  ｈｔｔｐ：／／ｒｐ．ｏｒｇ／ｒｅｔｕｒｎ．ｃｇｉを、ＲＰに送信することができる。ＲＰは、秘密Ｓを使用して、アサーションメッセージ上のシグネチャを検証することができる。その後、１０９０において、ＲＰは、ブラウザがログインページを表示することを可能にすることができ、サービスへのアクセスをブラウザに提供することができる。例えば、ＲＰは、ＨＴＭＬページを表示するように、ブラウザに命令することができる。１０９５において、ブラウザは、ユーザがＲＰにおいてログインしたことを、ユーザに通知する。
【０４６１】
例示的な一実施形態では、ＳＣＷＳに関連付けられたＯＰとＭＮＯとの間に長期共有鍵が存在すると仮定することができる。
【０４６２】
図３２に示されるように、１０４０、１０６５、１０７０、１０８０、および１０９５は、ＭＮＯ／エアネットワークに負荷をかけ得ないローカル通信を表す。加えて、これらの通信は、デバイス内部で起こり得るので、他の（有線または非ＭＮＯ）ネットワーク上でのトラフィックを伴わずに、行うことができる。
【０４６３】
１０４５、１０６０、１０８５、および１０９０は、無線通信を表し、無線通信は、データトラフィック（例えば、ＨＴＴＰ、ＩＰベースの通信）として、ＭＮＯ／エアネットワーク上で実施することができ、ＭＮＯネットワークにかかる負荷を表すことができる。
【０４６４】
１０５０および１０５５は、有線インターネットなどの有線上で発生でき、既存のインフラストラクチャを使用できる、トラフィックを表す。この通信は、ＭＮＯ／エアインタフェースネットワークにかかる負荷を増加させ得ない。
【０４６５】
図３３は、アソシエーションベース通信モードのためのプロトコルフローの別の例示的な実施形態を示している。図３３に示されるように、無線トラフィックは、エアインタフェースネットワークトラフィックが減少するように、ローカルデバイスにオフロードすることができる。これを行うことで、例えば、認証トラフィックがローカルになることを可能にすることができ、その結果、認証トラフィックは、エアインタフェースネットワークまたはネットワークサービスにかかる負担を最小化する。加えて、発見および／またはアソシエーショントラフィックは、エアインタフェースネットワークを介して発生しなくてもよく、有線公衆インターネット上で行うことができる。
【０４６６】
１１００において、ユーザは、ブラウザなどのユーザインタフェースと対話することができ、ＲＰを訪れることができ、ＯｐｅｎＩＤを使用してログインを要求することができる。１１０５において、ブラウザは、ＯｐｅｎＩＤアイデンティティＵＲＬを含むことができるＨＴＴＰメッセージを、ＲＰに送信することができる。１１１０において、ＲＰとＯＰ（ＭＮＯ）は、ＯｐｅｎＩＤアイデンティティに基づいて、ＯＰサーバの発見を実行することができる。例えば、ＲＰは、ＨＴＴＰ（Ｓ）ＧＥＴアイデンティティページメッセージをＯＰに送信することができ、ＯＰは、ＯｐｅｎＩＤ  ＩＤＰサーバアドレスによって応答することができる。
【０４６７】
１１１５において、ＲＰは、アソシエーション要求をＯＰに送信することができる。例えば、ＲＰは、ＨＴＴＰ（Ｓ）ＰＯＳＴをＯＰに送信することができる。ＯＰは、ランダムで一意的なアソシエーションハンドルＡを生成することができ、秘密Ｓを計算することができる。ＯＰは、アソシエーション応答をＲＰに送信することができる。例えば、ＯＰは、ＨＴＴＰ（Ｓ）ＰＯＳＴをＲＰに送信することができる。アソシエーション応答は、アソシエーションハンドルＡと、秘密Ｓとを含むことができる。ＲＰは、秘密ＳとアソシエーションハンドルＡを保存することができる。ＲＰは、ノンスおよびセッション識別子を生成することができる。
【０４６８】
１１２０において、ＲＰは、リダイレクトをブラウザに送信することができる。例えば、ＲＰは、ＨＴＴＰ  ＲＥＤＩＲＥＣＴをブラウザに送信することができる。リダイレクトは、ブラウザをＯＰにリダイレクトすることができ、要求パラメータにアソシエーションハンドルＡを含むことができる。ＯＰは、ＳＣＷＳに関連付けることができる。ブラウザは、リダイレクトを受信することができ、ＳＣＷＳにマッピングするように変更されたローカルＤＮＳルックアップを実行することができる。１１２５において、ブラウザは、認証のためのローカル要求をＯＰに送信することができる。例えば、ブラウザは、リダイレクトに含まれるパラメータを含むことができる、ＨＴＴＰ  ＧＥＴ  ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｓｅｒｖｅｒ．ｃｇｉをＯＰに送信することができる。
【０４６９】
１１３０において、認証をローカルに行うことができる。ブラウザは、ユーザ認証用資格証明書を要求する認証ページを、ユーザに提示することができる。ユーザは、ユーザ名およびパスワードを含むことができる、認証用資格証明書を入力することができる。１１３５において、ＯＰは、長期共有秘密鍵ＫとアソシエーションハンドルＡに基づいて、資格証明書を検証することができる。加えて、ＯＰは、秘密Ｓを計算することができ、Ｓを使用して、シグネチャを計算することができる。シグネチャは、アサーションメッセージに署名するために、ならびに／または戻りＵＲＬ、アイデンティティ、および／もしくはモードなどのパラメータに署名するために使用することができる。
【０４７０】
１１４０において、ＯＰは、ＲＰを訪れるようにブラウザに命令することができるリダイレクトを、ブラウザに送信することができる。例えば、ＯＰは、ＨＴＴＰ  ＲＥＤＩＲＥＣＴをＲＰに送信することができる。リダイレクトは、アソシエーションハンドルＡと、署名されたパラメータとを含むことができる。１１４５において、ブラウザは、ＯＰからの署名されたアサーションメッセージと、ＯＰによって提供されたパラメータとを含むことができる要求を、ＲＰに送信することができる。例えば、ブラウザは、ＨＴＴＰ  ＧＥＴ  ｈｔｔｐ：／／ｒｐ．ｏｒｇ／ｒｅｔｕｒｎ．ｃｇｉを、ＲＰに送信することができる。ＲＰは、秘密Ｓを使用して、アサーションメッセージ上のシグネチャを検証することができる。その後、１１５０において、ＲＰは、ブラウザがログインページを表示することを可能にすることができ、ブラウザにサービスへのアクセスを提供することができる。例えば、ＲＰは、ＨＴＭＬページを表示するように、ブラウザに命令することができる。１１５５において、ブラウザは、ユーザがＲＰにおいてログインしたことを、ユーザに通知する。
【０４７１】
例示的な一実施形態では、ＳＣＷＳに関連付けられたＯＰとＭＮＯとの間に長期共有鍵が存在すると仮定することができる。
【０４７２】
図３３に示されるように、１１００、１１２５、１１３０、１１４０、および１１５５は、ＭＮＯ／エアネットワークに負荷をかけ得ないローカル通信を表す。加えて、これらの通信は、デバイス内部で起こり得るので、他の（有線または非ＭＮＯ）ネットワーク上でのトラフィックを伴わずに、行うことができる。
【０４７３】
１１０５、１１２０、１１４５、および１１５０は、無線通信を表し、無線通信は、データトラフィック（例えば、ＨＴＴＰ、ＩＰベースの通信）として、ＭＮＯ／エアネットワーク上で実施することができ、ＭＮＯネットワークにかかる負荷を表すことができる。
【０４７４】
１１１０および１１１５は、有線インターネットなどの有線上で発生でき、既存のインフラストラクチャを使用できる、トラフィックを表す。この通信は、ＭＮＯ／エアインタフェースネットワークにかかる負荷を増加させ得ない。
【０４７５】
図３４は、ステートレスモードのためのプロトコルフローの別の例示的な実施形態を示している。
【０４７６】
１１６０：ユーザは、ＲＰウェブサイトを訪れ、ＯｐｅｎＩＤを使用してログインするために、例えば、ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙなど、自らのＯｐｅｎＩＤ識別子を入力する。
【０４７７】
１１６５：ブラウザは、ＯｐｅｎＩＤ識別子を含むＨＴＴＰメッセージを、ＲＰウェブサイトに送信することができる。
【０４７８】
１１７０：ＲＰは、ＨＴＴＰ／ＨＴＭＬベースのＯｐｅｎＩＤ「シンプル」発見を使用することができ、公衆インターネットを介してＯＰ−Ａｇｇとコンタクトを取り、例えば、ＨＴＴＰ  ＧＥＴ  ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙによって、ＯｐｅｎＩＤ識別子のためのアイデンティティページを取り出す。
【０４７９】
１１７５：ＯＰ−ａｇｇは、要求を受信することができ、ＯＰＳＦのインターネットアドレスを含むＨＴＭＬページによって応答することができる。例えば、ＯＰ−ａｇｇは、
＜ｌｉｎｋ  ｒｅｌ＝“ｏｐｅｎｉｄ．ｓｅｒｖｅｒ”ｈｒｅｆ＝ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｓｅｒｖｅｒ．ｃｇｉ＞
を含めることによって、応答することができる。
【０４８０】
ＯＰＳＦは、ＲＰに対して標準的なＯｐｅｎＩＤアイデンティティプロバイダウェブサービスのように振る舞うことができる。例えば、ＯＰＳＦは、ＲＰからの要求時に、アサーションメッセージ上の（ローカルＯＰによって発行された）シグネチャを検証することができる。要件通りに、ＯＰＳＦは、公衆インターネットを介して到達可能でなければならず、したがって、ｈｔｔｐ：／／ｏｐ．ｏｒｇによって到達可能な、例えばｏｐ．ｏｒｇなどの、ＤＮＳ名を有すると仮定される。外部世界は、スマートカードのＩＰアドレスを知ることができないので、このインダイレクションＯＰ−ａｇｇおよびＯＰＳＦを、通信のために使用することができる。
【０４８１】
ＯＰＳＦのアドレスは、ＯＰ−ａｇｇのアドレスと異なることがある。
【０４８２】
１１８０：ＲＰは、ＯＰＳＦのアドレスを受信することができ、例えば、ｎｏｎｃｅ＝１２３１２３、ｓｅｓｓｉｏｎ＝Ｕｓｅｒなどと、ノンスおよびセッション識別子を生成する。ＲＰは、ユーザ認証後にブラウザをどのＵＲＬにリダイレクトすべきかをＯＰに命じる、戻り先パラメータを編集することができる。ＲＰは、以下のパラメータを含む、ブラウザをＯＰサーバアドレスにリダイレクトする、ＨＴＴＰリダイレクトを発行することができる。
ｏｐｅｎｉｄ．ｍｏｄｅ＝ｃｈｅｃｋｉｄ＿ｓｅｔｕｐ、
ｏｐｅｎｉｄ．ｉｄｅｎｔｉｔｙ＝ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙ、
ｏｐｅｎｉｄ．ｒｅｔｕｒｎ＿ｔｏ＝ｈｔｔｐ：／／ｒｐ．ｏｒｇ／ｒｅｔｕｒｎ．ｃｇｉ？ｓｅｓｓｉｏｎ＝Ｕｓｅｒ＆ｎｏｎｃｅ＝１２３１２３
【０４８３】
１１８５：ブラウザは、リダイレクトを受信することができ、リダイレクトメッセージ内のＲＰによって指定されたＵＲＬへの接続をオープンすることができる。
【０４８４】
１１９０：例えば、エントリｈｔｔｐ：／／ｏｐ．ｏｒｇ＝＝１２７．０．０．１を有するホストファイルを使用することによって、ＯＰＳＦのＵＲＬをＳＣＷＳローカルＩＰアドレスにマッピングする、変更されたローカルＤＮＳルックアップテーブルを用いる場合、ブラウザは、ＳＣＷＳに関連付けられたローカルＯＰにリダイレクトすることができ、７６５のパラメータを含むＨＴＴＰ要求を発行する。
【０４８５】
変更されたローカルＤＮＳルックアップテーブルは、デバイス上に存在することができ、ＵＲＬ  ｈｔｔｐ：／／ｏｐ．ｏｒｇがＳＣＷＳのローカルＩＰアドレスにあるとデバイスに思わせる。ブラウザは、（公衆インターネットを介して到達可能な、ＵＲＬ  ｈｔｔｐ：／／ｏｐ．ｏｒｇにある）ＯＰＳＦに接続する代わりに、ＳＣＷＳ／ローカルＯＰへの接続をオープンすることができる。
【０４８６】
１１９５：以下は、認証トラフィックをローカルに保つことを保証するために実行することができるが、これらのステップは、必須ではなく、ＯｐｅｎＩＤプロトコル仕様によって規定されていない。
ａ．ＳＣＷＳに関連付けられたＯＰは、ローカル認証ページを表示することができる。
ｂ．ユーザは、例えば、ユーザ名およびパスワードなど、自分の認証用資格証明書を入力することができる。
ｃ．ＳＣＷＳに関連付けられたＯＰは、資格証明書を検証することができる。
【０４８７】
１２００：ＳＣＷＳに関連付けられたＯＰは、一意的でランダムなアソシエーションハンドルＡを生成することができる。関数ｆを使用すると、アサーションメッセージのための署名秘密を、Ｓ＝ｆ（Ａ，Ｋ）によって計算することができ、ここで、ｆは、Ａの知識がＫについてのいかなる知識も明かさないように、一方向とすべきである。例示的な一実施形態では、ｆは、ＳおよびＡが明かされたとしても、Ｋについてのいかなる知識も明かすことはできず、すなわち、ＳおよびＡが与えられた場合、ある関数ｇについて、Ｋ＝ｇ（Ｓ，Ｋ）を計算することが、計算的に実行不可能であるべきである。
【０４８８】
Ａは、リダイレクトメッセージ内のパラメータの一部として、ＲＰに明かすことができるので、ＯｐｅｎＩＤプロトコル実行のステートレスモードでは、ＲＰがＳの知識を獲得しないと仮定することができる。アソシエーションハンドルＡは、リダイレクトメッセージに含めることができる。加えて、Ｓを使用して署名された署名済メッセージｍを与えても、シグネチャの検証者には、Ｋについてのいかなる情報も明かされ得ないと仮定することができる（対称鍵シグネチャが使用されるので、シグネチャの検証者は、シグネチャを検証するために、常にＳを所有していることが必要であり、したがって、シグネチャがＳを明かさないことを必要としない）。
【０４８９】
例示的な一実施形態では、アソシエーションハンドルは、長さが２５５文字以下の文字列であると規定することができ、３３と１２６を含む３３〜１２６の範囲のＡＳＣＩＩ文字（印刷可能な非空白文字）のみから成ることができる。
【０４９０】
シグネチャを検証するためにＯＰＳＦによって使用される秘密は、シグネチャを生成するためにＳＣＷＳに関連付けられたＯＰによって使用される秘密と同じとすることができる。シグネチャの新しさは、次のステップで挿入されるＲＰノンスによって保証することができ、ＲＰノンスは、シグネチャの一部であることが要求される。ＯｐｅｎＩＤ仕様は、署名秘密自体の新しさについては何もいわないままである。秘密の暗号強度を保証すること、秘密の秘密性を維持すること、およびそれが必要な場合は、秘密の新しさを保証することは、ＯＰの責任とすることができる。ＯＰＳＦ、またはＳＣＷＳに関連付けられたＯＰは、この目的のために、署名秘密に対して、限られた存続期間または使用カウントを実施することができる。
【０４９１】
ツールキット対応のローカルＯＰは、ＳＣＷＳをバイパスして、ハンドセットとプロアクティブに通信するために、ＣＡＴを使用することができる。メッセージは、（例えば、ＳＭＳ−ＰＰベアラを介してＯＰＳＦに送信するために）標準的なＯＴＡ通りにフォーマットすることができる。これは、ＯＰＳＦが、ＭＮＯのＯＴＡシステムを介して、カードと通信することを必要とすることがある。別の例示的な実施形態では、ＢＩＰゲートウェイが、ツールキットメッセージのペイロードを抽出することができ、ハンドセットが、ＴＣＰ／ＩＰを使用して、それをＯＰＳＦに送信することができる。これも、メッセージがＭＮＯのＯＴＡサーバを通過することを必要とすることがある。加えて、ＳＣＷＳは、カードがＩＰアドレスを有せず、ＴＣＰ／ＩＰをサポートしない場合に限って、ＢＩＰを使用すべきであることを命じる。そのため、ＴＣＰ／ＩＰを使用したＳＣＷＳを介する送信が、期待されることであることがある。
ｄ．ＳＣＷＳに関連付けられたＯＰとＯＰＳＦとの間の共有秘密をもたらさなければならないことがある、さらなるオプションも適用することができる。そのような方法の実現可能性は、さらなる研究課題である。
【０４９２】
１２０５：ＳＣＷＳに関連付けられたＯＰは、戻り先、アイデンティティ、およびモードなどのパラメータに対するシグネチャを計算することができる。
【０４９３】
１２１０：ＳＣＷＳに関連付けられたＯＰは、１１８０においてＲＰから受信したパラメータを含む、ＨＴＴＰリダイレクトメッセージをブラウザに送信することができる。追加的に、以下のものも、すなわち、
●ｏｐｅｎｉｄ．ｓｉｇｎｅｄパラメータ内の署名されたパラメータのリスト、
●ｏｐｅｎｉｄ．ａｓｓｏｃ＿ｈａｎｄｌｅパラメータ内のアソシエーションハンドルＡ、および
●ｏｐｅｎｉｄ．ｓｉｇパラメータ内のシグネチャ（ｂａｓｅ６４符号化）
も含むことができる。
【０４９４】
１２１２において、このメッセージは、ブラウザをＲＰの戻り先ＵＲＬにリダイレクトするために使用することができる。
【０４９５】
１２１５：ブラウザは、ユーザをＲＰの戻り先ＵＲＬにリダイレクトすることができる。
【０４９６】
１２２０：ＲＰは、署名されたアサーションメッセージを受信することができ、ＨＴＴＰ（Ｓ）ベースの公衆インターネットを介する直接通信によって、ＯＰＳＦとともに検証手順に携わる。
【０４９７】
１２２５：ＲＰは、７９５のＳＣＷＳに関連付けられたＯＰから受信したパラメータを含む、ＨＴＴＰ  ＰＯＳＴメッセージを発行することができる。ＨＴＴＰ  Ｐｏｓｔメッセージは、ＳＣＷＳに関連付けられたＯＰによって生成された、アソシエーションハンドルＡを含むことができる。
【０４９８】
１２３０：ＯＰＳＦは、パラメータリストからＡを抽出することができ、同じ入力を有する、ＳＣＷＳに関連付けられたＯＰと同じ関数ｆを使用することができ、すなわち、ＯＰＳＦは、ｆ（Ａ，Ｋ）＝Ｓを計算し、Ｓを共有鍵として使用して、ＳＣＷＳに関連付けられたＯＰから受信したデータ上のシグネチャを検証する。
【０４９９】
１２３５：ＯＰＳＦは、シグネチャ検証が成功した場合、ｉｓ＿ｖａｌｉｄ：ｔｒｕｅを返すことができる。
【０５００】
１２４０：ＲＰからは、ユーザは、今ではｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙとして識別することができる。
【０５０１】
１２４５：ブラウザは、ＲＰのＨＴＭＬページを表示することができる。
【０５０２】
１２５０：ユーザは、ｈｔｔｐ：／／ｏｐ．ｏｒｇ／ｉｄｅｎｔｉｔｙとして、ＲＰにおいてログインすることができる。
【０５０３】
図３４に示されるように、１１６０、１１９０、１２１２、１２１５、および１２５０は、ＭＮＯ／エアネットワークに負荷をかけ得ないローカル通信を表す。加えて、これらの通信は、デバイス内部で起こり得るので、他の（有線または非ＭＮＯ）ネットワーク上でのトラフィックを伴わずに、行うことができる。
【０５０４】
１１６５、１１８０、１２２０、および１２４５は、無線通信を表し、無線通信は、データトラフィック（例えば、ＨＴＴＰ、ＩＰベースの通信）として、ＭＮＯ／エアネットワーク上で実施することができ、ＭＮＯネットワークにかかる負荷を表すことができる。
【０５０５】
１１７０、１１７５、１２２５、および１２３５は、有線インターネットなどの有線上で発生でき、既存のインフラストラクチャを使用できる、トラフィックを表す。この通信は、ＭＮＯ／エアインタフェースネットワークにかかる負荷を増加させ得ない。
【０５０６】
４．５  シナリオおよび用途
本セクションでは、これまでのセクションで説明された方法およびプロトコルの追加的な実施形態について説明する。例えば、本セクションでは、異なるシナリオのいくつかを明示的に列挙し、使用事例およびシナリオの範囲を広げることによって、一般化も拡張する。
【０５０７】
スマートカード（ＳＣ）という用語は、安全な動作機構を提供できる任意のタイプの集積回路カード（ＩＣＣ）を述べるために使用することができる。（例えばＧＳＭ／ＵＭＴＳなど）ネットワーク認証用資格証明書を保持するためにＳＣを使用できる、モバイルデバイスにおける特定の使用では、ＵＩＣＣと呼ばれることがある。オープンモバイルアライアンス（ＯＭＡ：Ｏｐｅｎ  Ｍｏｂｉｌｅ  Ａｌｌｉａｎｃｅ）によって定義された、スマートカードウェブサーバ（ＳＣＷＳ）アプリケーションは、ＵＩＣＣにおける使用に限定されず、他の任意のスマートカードにおいて利用可能であると仮定することができる。したがって、安全な要素内に存在するＯＰエンティティを用いる、ＯｐｅｎＩＤを使用するローカルユーザ認証のための実施形態など、本明細書で説明される実施形態は、一般的なＳＣに容易に拡張することができる。
【０５０８】
加えて、類似のインタフェースおよび保護された実行をセキュリティ重視の方法に提供できる、他の任意の安全な環境も、上で説明された実施形態のための実施対象とすることができる。
【０５０９】
４．５．１  利害関係者モデル
４．５．１．１  ＭＮＯモデル
例示的な一実施形態では、ＭＮＯは、完全なアイデンティティプロバイダとしての役割を果たすことができる。ＭＮＯは、ウェブサービスとしてのＯＰ−ａｇｇならびにＯＰＳＦ発見およびアソシエーションポイントエンティティをホストすることができ、ユーザアイデンティティとともに、ＯＰアプリケーションをＵＩＣＣに提供することもできる。
【０５１０】
４．５．１．２  サードパーティＯＰおよびＭＮＯ
例示的な一実施形態では、ユーザは、ｍｙｏｐｅｎｉｄ．ｃｏｍなどのサードパーティＯＰに登録された、既存のＯｐｅｎＩＤ識別子をすでに有すると仮定することができる。これは、サードパーティＯＰ（３ＯＰ）と呼ばれることがある。
【０５１１】
ＭＮＯは、ユーザに対してもはやサービスプロバイダの役割を果たすことはできないが、データをトランスポートすることはでき、３ＯＰが、ＵＩＣＣ上にＯＰアプリケーションをインストールし、それをＳＣＷＳアプリケーションと関連付けることを可能にする。３ＯＰは、ＭＮＯとビジネス関係を確立しなければならないことがある。ＭＮＯは、ＯＰアプリケーションに対する３ＯＰのリモート管理権を許諾することもできる。ＭＮＯは、そのサービスに対する対価を３ＯＰに請求し、収入を得ることができる。以下では、グローバルプラットフォーム（ＧＰ）準拠のカードの使用に関して、さらに詳細に説明する。
【０５１２】
４．５．１．３  非ＭＮＯ、非モバイル
例示的な一実施形態を、非モバイルシナリオにおいて使用することができる。例えば、銀行によって発行されるＳＣなどの、汎用ＳＣは、ＯＰアプリケーションをインストールするために、ＯｐｅｎＩＤアイデンティティプロバイダによって使用することができる。これは、例えば、ＮＦＣ発券アプリケーションおよびＯｐｅｎＩＤ認証ＯＰアプリケーションをホストできる、銀行カードを利用するために行うことができる。ＳＣが通信するデバイスのタイプについて事前知識がないと仮定することができる。しかし、現在のＳＣ仕様を考えると、例えば、ローカルリンク、ＳＣリーダ、ＮＦＣ通信インタフェースなどを介して、ＳＣへのＵＳＢを介するＴＣＰ／ＩＰ接続を確立することが可能なことがある。ＳＣは、外部端末によって到達可能な、ＳＣＷＳを備えることができる。
【０５１３】
４．５．２  分割端末シナリオ
本セクションでは、ＳＣＷＳおよびＯＰアプリケーションをホストするＳＣを含むデバイスが、ＲＰウェブサイトにアクセスすることを望むデバイスと同じでないことがある、実施形態について説明する。これらの実施形態では、ＳＣは、外部認証トークンとして使用することができる。これらの分割端末実施形態は、本明細書で説明される異なる利害関係者モデルと組み合わせることができる。
【０５１４】
４．５．２．１  モバイルデバイス内のＵＩＣＣを用いる分割端末
図３４は、分割端末のためのプロトコルフローの例示的な一実施形態を示している。例示的な一実施形態では、ユーザは、ＳＣＷＳおよびＯＰがインストールされたＵＩＣＣを備える、モバイルデバイスを所有することができる。ユーザは、ブラウジングエージェント（ＢＡ）と呼ばれることがある、ＲＰの所望のウェブページにアクセスするための、そのモバイルデバイスとは異なるデバイスを使用することができる。ＢＡがＲＰを訪れ、ログインするためにＯｐｅｎＩＤ識別子を提示した場合、ＲＰは、ＢＡをＯＰに、すなわち、ＯＰのＵＲＬにリダイレクトすることができる。ＲＰからＢＡへのＨＴＴＰリダイレクトメッセージは、必要な情報を含むことができ、必要な情報は、ＯＰアプリケーションが、アサーションメッセージに対するシグネチャを計算するために必要とされることがある。このメッセージの内容は、モバイルと、ＳＣ上のＯＰに伝えることができる。ＯＰは、モバイルデバイス上で認証ページをユーザに表示することができ、ユーザは、ログインの認可および認証を受ける。ＯＰは、アサーションメッセージに署名することができる。その後、署名されたアサーションメッセージは、ＲＰに返信することができ、それは、通常は、ＢＡによって行うことができる。その後、ＲＰは、シグネチャを検証することができ、ユーザ／ＢＡは、ＲＰにおいてログインする。
【０５１５】
ＢＡとモバイルデバイスの間の通信を含む、別の例示的な実施形態では、２つのエンティティの間で、例えば、ＢｌｕｅｔｏｏｔｈまたはＷＬＡＮを介するローカルリンクを確立し、ＯＰをホストするデバイスとして、デバイスを登録することが可能なことがある。その後、ブラウザは、リダイレクトをＯＰ／ＳＣＷＳに転送できるローカルリンクを介して、リダイレクトをモバイルデバイスに送信することができる。その後、ＯＰは、ユーザにユーザの資格証明書を求めることができる。ユーザは、（例えば、パスワード、ＰＩＮ、バイオメトリックスなど）ユーザ認証のために実施されるいずれかの方法を使用して、自らのモバイルデバイス上でＯＰから認証を受けることができる。ＯＰは、アサーションメッセージに署名を行うことができ、そのアサーションメッセージを、ローカルリンクを介してＢＡに転送する。その後、ＢＡは、このメッセージを使用して、ＲＰから認証を受けることができる。このシナリオでは、ＢＡは、ＲＰとモバイルデバイスの間のＭＩＴＭとしての役割を果たすことができる。ユーザは、自分がこのＯｐｅｎＩＤセッションを開始したことを知ることができるので、自らのモバイルデバイス上で無認可の要求を検出できることがある。
【０５１６】
図３５に示されるように、１２５５において、ＢＡは、ＲＰを訪れることができ、ＯｐｅｎＩＤを使用してログインを要求することができる。１２６０において、ＲＰは、ログイン要求を受信することができ、ＯＰ（ＭＮＯ）とともに、ＯｐｅｎＩＤアイデンティティに基づいて、ＯＰサーバの発見を開始することができる。１２６５において、ＲＰは、アソシエーション要求をＯＰ（ＭＮＯ）に送信することができ、ＯＰ（ＭＮＯ）は、アソシエーション要求を送信することができる。アソシエーション応答は、アソシエーションハンドルＡと、鍵Ｓとを含むことができる。１２７０において、ＲＰは、ブラウザを、ＳＣＷＳに関連付けられたＯＰにリダイレクトすることができる。ＲＰリダイレクトは、要求パラメータにＡを含めることができる。ＢＡとユーザは、ローカルリンクを確立することができる。
【０５１７】
１２７５において、ＢＡは、認証のためのローカル要求を、ＳＣＷＳに関連付けられたＯＰに送信することができる。１２８０において、ＳＣＷＳに関連付けられたＯＰとユーザ／モバイルデバイスとの間で、ローカル認証を確立することができる。
【０５１８】
１２８５において、ＳＣＷＳに関連付けられたＯＰは、ＢＡをＲＰにリダイレクトすることができる。ダイレクトは、アソシエーションハンドルを含むことができ、署名されたパラメータを含むことができる。１２９０において、ＢＡは、要求をＲＰに送信することができる。要求は、ＳＣＷＳに関連付けられたＯＰからの署名されたアサーションメッセージを含むことができる。１２９５において、ＲＰは、ＢＡが、ログインされたページを表示することを可能にすることができる。
【０５１９】
４．５．２．２  外部カードリーダ／ＮＦＣ内のスマートカードを用いる分割端末
非モバイルＳＣ配備の例示的な一実施形態では、ＳＣは、ウェブベースのＯＰまたは別のサードパーティ（例えば銀行）によって、発行することができる。モバイル分割端末の場合に説明されたのと同様のステップを適用することができる。その場合、ローカルリンクの確立は、外部のスマートカードリーダを介すること、またはコンピュータに結合されたＮＦＣ（近接場通信）端末を介することができる。インタフェースは、ＳＣ上で実施されるＯＰ／ＳＣＷＳに送信できるＨＴＴＰメッセージをサポートすることができる。
【０５２０】
４．６  ＯｐｅｎＩＤにおける信用関係
４．６．１  既存のＯｐｅｎＩＤにおける信用関係
図３５は、ＯｐｅｎＩＤにおける信用関係を示している。
【０５２１】
４．６．１．１  ＯｐｅｎＩＤプロトコルステップ１
図３６に示されるように、１３００において、ユーザは、ログイン後にユーザがサービスにアクセスすることを可能にする、ＲＰウェブサイトを訪れる。ユーザがＯｐｅｎＩＤを使用してログインすることに決定した場合、ユーザは、自らのＯＰにリダイレクトされる。ユーザは、リダイレクトが適切に実行され、フィッシング攻撃を受けないことについて、ＲＰを信用しなければならない。さらに、ユーザは、ログイン後にサービスを受けること、および（プライバシ上の理由で）ユーザとＲＰとの対話をＲＰが第三者に明かさないことについて、ＲＰを信用する。
【０５２２】
ユーザが供給したＯｐｅｎＩＤ＼ｉｄｅｎｔｉｆｉｅｒは、ＲＰのドメインに入り、ＲＰのための正しいＯＰを発見する手段としてばかりでなく、ＲＰとユーザの間の対話のための識別子としての役割を果たす。ＲＰは、この識別子についての知識だけを獲得するが、それを解決することによって、ＲＰは、ＯＰのアドレスを知るようになる。
【０５２３】
ＯｐｅｎＩＤ仕様によれば、発見は、依拠当事者が、識別子を使用して、要求を開始するために必要な情報を検索（「発見」）するプロセスである。ＯｐｅｎＩＤ認証は、それを介して発見が行われる、３つのパスを有する。
【０５２４】
識別子がＸＲＩ、［ＸＲＩ＿Ｒｅｓｏｌｕｔｉｏｎ＿２．０］（例えば、非特許文献１５参照）である場合、それは、必要な情報を含むＸＲＤＳ文書を生成する。
【０５２５】
依拠当事者は、ｈｔｔｐ：／／ｗｗｗ．ｘｒｉ．ｎｅｔにおいてＸＤＩ．ｏｒｇによって提供されるものなど、ＸＲＩプロキシリゾルバを利用できることにも留意されたい。これによって、ＲＰがＸＲＩ解決をローカルで実行する必要がなくなる。
【０５２６】
それがＵＲＬである場合、ヤディス（Ｙａｄｉｓ）プロトコル（例えば、非特許文献１６参照）［Ｙａｄｉｓ］を最初に試みるべきである。それが成功した場合、結果は、やはりＸＲＤＳ文書である。ヤディスプロトコルが失敗し、有効なＸＲＤＳ文書が取り出せない場合、またはＸＲＤＳ文書内にサービス要素（ＯｐｅｎＩＤサービス要素）が見つからない場合、ＵＲＬを取り出し、ＨＴＭＬベースの発見（ＨＴＭＬ−Ｂａｓｅｄ  Ｄｉｓｃｏｖｅｒｙ）を試みるべきである。
【０５２７】
発見ステップは、攻撃者にエントリポイントを提供することもできることに留意することが重要である。攻撃者は、ＲＰを、本当のＯＰに代わりに、攻撃者の管理下にある偽のＯＰにリダイレクトする方法で、発見ステップを妨害するために、例えば、ＤＮＳスプーフィング攻撃を用いて、直接的にＲＰを攻撃しようと試みることができる。ホストは別のホストであるが、ドメイン名は同じであるので、ＲＰは、それがユーザの本当のＯＰであるとまだ思っている。不備は、ＯｐｅｎＩＤプロトコルの設計内にあり、それに対する防御は、ＯｐｅｎＩＤ仕様の範囲外にあるように思える。この脅威も、トラステッドＯｐｅｎＩＤ文書では、すでに捉えられており、いくつかの可能な緩和技法に対するヒントが説明されている。
【０５２８】
４．６．１．２  ＯｐｅｎＩＤプロトコルステップ２
図３６に示されるように、１３０５において、ＲＰは、ユーザのためのＯＰを発見すると、そのＯＰとアソシエーションを確立し、アソシエーションは、ＲＰとＯＰが、共有鍵で保護されたチャネルを介して、安全に通信することを可能にする。ユーザ識別子は、ＲＰドメインを出て、ＯＰのドメインに入る。ＯＰは、自分が、与えられた識別子を用いて、ユーザアイデンティティを実際にホストすることを認識するが、このユーザが今、どのサイトにアクセスしようと試みているかも知るようになる。共有秘密の確立が安全ではない場合（標準は、ＭＩＴＭ攻撃が可能な、ディフィ−ヘルマンを定めているだけである）、ＯＰは、ユーザがブラウザで見ているのと同じＲＰに自分が関連付けられていることを確信することができない。
【０５２９】
ユーザは、ＯＰが、ユーザプロファイルを構築するために、収集した情報（例えば、ユーザがどのサイトを、どれだけの頻度で訪れたかなど）を使用しないことについて、ＯＰを信用する。さらに、ユーザは、ＯＰが、ユーザが訪れなかったサイトからのアソシエーション要求（例えば、攻撃者による未知のサイトへの隠れたログインの試み）を受け入れないことについて、ＯＰを信用する。
【０５３０】
ＲＰは、ＯＰが、実際にユーザを認証し、ユーザのアイデンティティについての信頼できる情報をＲＰに提供することについて、ＯＰを信用する。ＯＰを介してＲＰサービスに対する対価の請求を実行できる、支払いシナリオでは、ＲＰは、この請求を実行するのに必要な手段を提供することについても、ＯＰを信用し、例えば、ＯｐｅｎＩＤ／ＧＢＡにおいてＯＰとしての役割を果たすＭＮＯの場合、ＲＰは、電話料金請求書によってユーザに請求を行うことを可能にする、ＭＮＯが実行しているＯＰとして、ＯＰを認識する。その場合、ＲＰは、請求が実行されることについて、ＭＮＯ−ＯＰを信用する。
【０５３１】
任意のＯＰを構築し、セットアップすることができるので（例えば、ユーザを認証せず、したがって、スパム送信者によって悪用されて、スパムフォーラム、ブログなどに対するユニバーサルアカウントを生成するための容易なメカニズムをスパム送信者に与えることができるＯＰ）ＲＰは、限られた１組のＯＰだけにアクセスを制限することを望むことがある。そのようなＯＰホワイトリスト／ブラックリスト手法は、ＯｐｅｎＩＤプロトコルに規定されていないが、悪徳ＯＰから保護するために、ＲＰにおいて実施することができる。
【０５３２】
４．６．１．３  ＯｐｅｎＩＤプロトコルステップ３
図３６に示されるように、１３１０において、ユーザは、ＯＰページにリダイレクトされ、認証を実行する。資格証明書は、ユーザドメインを出て、ＯＰドメインに入る。したがって、ユーザとＯＰの間のインタフェースは、盗聴から保護されていなければならない。典型的なシナリオでは、ＨＴＴＰ上でのＨＴＴＰＳの使用によって、小規模な保護が与えられる。しかし、ユーザが証明書チェイン全体をチェックしないことを考えると、これは、有効な証明書を用いる偽のＯＰに対する防御にはならない。
【０５３３】
ユーザは、ＯＰが資格証明書を悪用しないことについて、ＯＰを信用し、すなわち、ユーザは、ＯＰが悪意を抱いているとは考えない。悪意あるＯＰは、そこに登録されたユーザに代わって、すべてのサービスに容易にアクセスすることができる。したがって、ＯＰからの情報漏洩は、すべてのウェブサービスに対するユーザ資格証明書を直ちに暴露し、ユーザアイデンティティを危険にさらすことにつながるので、大規模なユーザベースを有する大規模なＯＰは、攻撃者の主要な目標になる。
【０５３４】
認証フェーズの結果として、ユーザのブラウザは、ユーザが自分の識別子の使用について認証した旨のＯＰからのアサーションとともに、ＲＰにリダイレクトされる。
【０５３５】
ＯｐｅｎＩＤアイデンティティは、異なるウェブサイトへのアクセスを簡素化するための手段としてばかりでなく、複数のサイトにわたって評判を築くための手段としても、しばしば使用されるので、ユーザアイデンティティの漏洩は、特別な心配事とすることができる。したがって、識別子がひとたび悪用されると、評判の良いアイデンティティを回復することは困難かもしれない。
【０５３６】
４．６．１．４  ＯｐｅｎＩＤプロトコルステップ４
図３６に示されるように、１３１５において、ユーザは、ＯＰからのアサーションとともに、ＲＰにリダイレクトされる。ＲＰは、（任意のタイプの）認証が実行されたこと、およびユーザが識別子に関連付けられた秘密を知っていることについて、ユーザ（およびＯＰ）を信用するための十分な情報を獲得する。ＲＰは、ユーザとＯＰの間で使用された認証方法についてのいかなる情報および保証も獲得しない。
【０５３７】
４．６．２  モバイルローカルＯＰにおける信用関係についての実施形態
４．６．２．１  全般
図３７は、ローカルＯＰとの信用関係についての例示的な一実施形態を示している。例示的な一実施形態ではＯＰがユーザにとってローカルエンティティになった場合、ＯＰおよびユーザドメインは、点線１３４０によって識別される、単一のドメインと見なすことができる。
【０５３８】
１３３０において、ユーザは、認証を実行することができ、それによって、認証手順のためのネットワーク負荷を軽減することができる。ユーザは、ユーザにより多くの管理が委ねられたローカルエンティティと、プライベートデータを共有することができる。ＲＰは、アソシエーションを構築すべき場合、ローカルＯＰと直接的にコンタクトを取る必要があることがある。この接続は、ＯｐｅｎＩＤプロトコルが機能するためには必要でないことがある。ＲＰとＯＰの間の通信は、間接通信を介して、すなわち、ユーザのブラウザを使用したリダイレクトを介して、実行することもできる。
【０５３９】
しかし、ローカルＯＰに対してＲＰが有することのできる信用は、ＯＰから来るアサーションから導出できる信頼できる情報の量に依存する。一般に、ＲＰは、すべてのＯＰを受け入れるが、セキュリティ要件の厳しいアプリケーションでは、ＲＰは、１組のＯＰ、または与えられた特性を有するＯＰに、アクセスを制限することができる。その場合、ＯＰは、これらの特性についての情報をＲＰに提供しなければならないことがある。そのような情報は、直接チャネル（例えばアソシエーションチャネル）を介して、または間接通信によるリダイレクトメッセージ内のアドオンを介して、ローカルＯＰから伝えることができる。別の例示的な実施形態では、（例えば、信頼できるＭＮＯによって発行される）ＯＰ特性についてのそのようなアサーションは、ＴＴＰから得ることができる。
【０５４０】
１３２５において、ＲＰは、１３０５（段落０５７２）において説明されたように続行することができる。１３３５において、ＵＥは、１３１５（段落０５８０）において説明されたように続行することができる。１３２０において、ＵＥは、１３００（段落０５６５）において説明されたように続行することができる。しかし、このシナリオでは、段落０５８２で言及されたように、ユーザは、インターネットを介した対話を行うことなく、様々な形でローカル認証を実行することができる。
【０５４１】
４．６．２．２  ＭＮＯとの信用関係
図３８は、ローカルＯＰとの信用関係についての例示的な一実施形態を示している。図３８に示されるように、ＯＰはスマートカード上で動作するので、ＭＮＯは、ＯＰと直接的な関係を有することができる。ＲＰは、ＭＮＯと間接的な関係を有することができるが、標準に準拠したＯｐｅｎＩＤプロトコルでは、ＲＰとＭＮＯは、そのような関係を確立する必要がないことがある。ＲＰは、ＯＰとの関係を確立する必要があることがある。例えば、ＭＮＯを介した請求、アイデンティティについての信用レベルの向上など、いくつかの理由で、ＲＰは、ユーザのアイデンティティについての追加情報を獲得することを好むことがある。そのような信用は、ＲＰがＭＮＯに対して有する信用に基づくことができる。
【０５４２】
信用は、ＯＰを介して、ＭＮＯからＲＰに伝えることができる。例示的な一実施形態では、ＲＰが、（例えば、ＭＮＯの評判、登録などの帯域外プロセス、サービスおよび契約上の合意によって）ＭＮＯに対して一定のレベルの信用を有すると仮定することができる。加えて、必要な場合はいつでも、ＲＰがＭＮＯのエンティティと通信でき、この通信を適切な手段（例えば、ＩＰＳＥＣ、ＨＴＴＰＳ）によって保護できると仮定することができる。スマートカードおよびＭＮＯ（のサーバ）が、必要に応じて異なる方法で通信するための手段を有することができると仮定することもできる。
【０５４３】
ＭＮＯは、発見プロセスに関与することができ、ＲＰにＯＰの現在のアドレスを提供することによって、ＲＰがＯＰとの直接通信チャネル（アソシエーション）を確立することを可能にする。これは、ユーザが訪れたサービスをＭＮＯに明かすことができ、ＭＮＯがユーザの追跡プロファイルを生成することを可能にする。そのような発見は、ユーザのブラウザを介するインダイレクトが使用される場合、必要でないことがある。
【０５４４】
ＭＮＯは、ＯｐｅｎＩＤプロトコルに関与する場合、いくつかの役割を有することができる。
【０５４５】
４．６．２．２．１  ＯＰのための（直接的な）信用プロバイダとしてのＭＮＯ
直接的な信用プロバイダとしての役割を果たすことは、ＭＮＯが、ＯＰとＲＰの間における信用を構築するプロセスに直接的に関与することを意味することができる。そのような直接的な関与は、ＯＰによってアサートされたアイデンティティがＭＮＯに登録されていることを、ＲＰに直ちに保証することができる。ＭＮＯが、ＯＰのための直接的な信用プロバイダとしての役割を果たす場合、ＯＰ、ＲＰ、およびＭＮＯの適切なサービス、または既存のサービスの組み合わせの間で、いくつかの方法を利用することができる。
【０５４６】
ａ）ＲＰとＭＮＯの間の直接通信についての例示的な実施形態
一例では、ＭＮＯは、ＲＰによって到達できる、中央サービスを提供することができる。ＲＰは、ＯＰと直接的に関連することはできないが、ＭＮＯを介して関連することができる。ユーザのブラウザは、ローカルＯＰにリダイレクトすることができる。認証した後、ＯＰは、認証が成功したことを述べるメッセージを、ＭＮＯに送信することができる。このメッセージは、ＭＮＯによってスマートカードに対して発行された鍵を用いて、署名することができる。ＭＮＯは、シグネチャを検証し、それ独自のシグネチャを追加することができ、その後、このメッセージをＲＰに転送する。ＲＰは、ユーザが認証を受けたＯＰからのアサーションと、認証が有効なＯＰによって実行された旨のＭＮＯからのメッセージの、２つのメッセージを受信することができる。これらのメッセージは、組み合わせて、認証が正常に行われた旨のアサーションをメッセージが含むような、ＭＮＯからの単一のメッセージにすることができる。
【０５４７】
ｂ）ＯＰを介する間接通信についての例示的な実施形態
例示的な一実施形態では、ＭＮＯは、そのような外部サービスをＲＰに提供することを望まないことがあり、通信は、ＯＰを介して間接的に伝えることができる。信用は、依然として、ＭＮＯから来たステートメントから直接的に導出することができるが、ＲＰとＭＮＯの間の通信は、ＯＰを介して行うことができる。ＲＰは、ノンスを含む追加フィールドとともに、ブラウザをＯＰにリダイレクトすることができる。その後、ＯＰは、このフィールドを要求から抽出することができ、それをＭＮＯに転送することができる。ＭＮＯは、それに署名することができ、その後、署名された応答は、ＯＰからＲＰへのアサーション回答に含めることができる。ＭＮＯは、知られたＯＰから受信したノンスに署名することができるので、これは、ＭＮＯからアクセスされているサービスを隠すという追加の利点を有することもできる。加入者の本当のアイデンティティをＲＰに明かさなければならない場合、ノンスをセッション識別子として使用することもでき、その場合、セッション識別子が、加入者を識別する。
【０５４８】
ｃ）組み合わされた方法についての例示的な実施形態
例示的な一実施形態では、通信タイプを組み合わせることが可能なことがある。ユーザが、ＯｐｅｎＩＤを使用して、ＲＰにログインすることを望む場合、ＲＰは、ＭＮＯとコンタクトを取り、ＯｐｅｎＩＤプロトコルのアソシエーションフェーズにおいて、ＭＮＯとともに共有秘密を確立する。その場合、ＲＰは、認証の完了時に、ＯＰがこの秘密をアサーションメッセージに含めることを予期することができる。ＧＢＡプロトコルを使用して、ＭＮＯネットワークおよびスマートカードにおいて生成される、新たに生成された署名鍵を使用することによって署名されたステートメントを、ＭＮＯがＲＰに提供することは、オプションとすることができる。ＧＢＡプロトコルを用いる場合、ＭＮＯは、スマートカードとともに秘密を確立することができ、両方のエンティティは、同じステートメントに署名することができる。その後、ＯＰは、この署名されたステートメントを、ＲＰへのアサーションメッセージに含めることができる。ＲＰは、ＭＮＯからの署名されたステートメントと、アサーションメッセージ内のステートメントとを比較することができる。ＭＮＯからの署名されたステートメント（またはチケット）は、要求に応じて生成することができ、またはデバイスが最初にＭＮＯから認証を受けたときに生成することができ、その後、デバイスは、これをローカルに保存する。その後、デバイスが、ＲＰへの接続を試みる場合、先に保存された署名されたステートメントを、ＲＰに送付することができる。
【０５４９】
ＯｐｅｎＩＤプロトコルは、ＯＰとのアソシエーション（したがって共有秘密）を確立するか、それともステートレスプロトコルフローを使用するかを、ＲＰが決定することを可能にすることができる。ＯＰによって、両方の動作モードをサポートすることができる。アソシエーションが使用される場合、ＲＰ毎およびＯＰ毎に、共有秘密を確立することができる。これは、ユーザのデバイス上の、ＭＮＯとＯＰの間の事前共有ステートメントが、ＲＰとＭＮＯの間のこの新しい秘密を含まなければならないことがあることを意味する。デバイスＯＰとＭＮＯの間で（例えばＧＢＡを介して）事前共有できるものは、署名鍵であり、その後、署名鍵は、セッション毎に秘密／ノンスに署名するために、ＭＮＯとＯＰの両方によって使用され、ノンスは、ＲＰとＭＮＯの間で確立し、ＭＮＯによってＯＰに転送することができる。
【０５５０】
４．６．２．２．２  ＯＰのための（間接的な）信用プロバイダとしてのＭＮＯ
例示的な一実施形態では、ＭＮＯは、ＯＰのための間接的な信用プロバイダとしての役割を果たすこともできる。そのため、ＭＮＯは、ＯｐｅｎＩＤ認証中の通信プロセスに必ずしも関与しない。別の例示的な実施形態では、ＭＮＯは、証明書および鍵素材をスマートカードに発行することができ、その場合、ＯＰからＲＰへのアサーションメッセージ内のフィールドに署名するために、それを使用することができる。その後、ＲＰは、シグネチャおよび証明書を検証することができ、それが、ＯＰが信頼できるＭＮＯから得られることを、ＲＰに保証する。証明書の検証は、ＭＮＯのさらなる関与なしに、例えば、ＴＴＰによって行うことができる。
【０５５１】
４．６．２．２．３  ＯＰのための信用およびソフトウェアプロバイダとしてのＭＮＯ
例示的な一実施形態では、ＭＮＯは、ＯＰソフトウェアパッケージをスマートカード上にリモートでダウンロードし、管理することができる。例えば、スマートカードウェブサーバ（ＳＣＷＳ）など、ソリューションによっては、この管理は、ＳＣＷＳとＭＮＯの間のＨＴＴＰＳ管理セッションを介して行うことができる。ＭＮＯは、信用を伝えるための秘密（例えば、認定された鍵などの資格証明書）を、ＯＰによって発行されたステートメントに直接的に含めることができる。その後、ＲＰは、認定された秘密から信用を導出することができる。ＭＮＯは、異なるユーザ識別子とともに使用するために、１組の秘密をＯＰソフトウェアに含めることさえできる。ＲＰは、ＭＮＯによって発行されたＯＰソフトウェア証明書から信用を導出することができる。
【０５５２】
例示的な一実施形態では、ＧＢＡは、ＭＮＯが、デバイス上のＯＰとともに共有秘密を確立することを可能にすることができる。この秘密は、ＲＰには知ることができないが、ＲＰは、ＭＮＯとともに安全な通信チャネルを確立することができるので、ＭＮＯは、ＧＢＡ導出の鍵を用いて署名されたＯＰアサーションステートメントをＲＰが自律的に検証できるように、この（ＧＢＡ導出の）秘密をアソシエーションチャネルでＲＰに転送することができる。
【０５５３】
別の例示的な実施形態では、ＭＮＯとＯＰの間でＧＢＡ秘密が確立された後、ＭＮＯは、ＲＰからのノンスおよびＲＰ  ＩＤを尋ねることができ、その後、ノンスおよびＲＰ  ＩＤを使用して、ＭＮＯとＯＰの間で、ＧＢＡ秘密から、まさにこの特定のＲＰおよびこの特定のセッションのためのさらなる秘密を確立することができる。これは、例えば、ＲＰとのアソシエーションのためのＧＢＡ導出の秘密を再利用すること、およびＧＢＡ導出の秘密をＲＰに明かすことを防止するために行うことができる。その後、ＭＮＯは、このＲＰとセッションに固有の秘密をＲＰに転送することができる。第１のオプションにおけるように、その後、ＲＰは、このセッション固有の鍵に基づいて、アサーション上のＯＰシグネチャを検証することができる。
【０５５４】
４．７  グローバルプラットフォームスマートカード上での実施
ＧＰ  ＳＣは、複数のいわゆるセキュリティドメイン（ＳＤ）をホストすることができ、各ＳＤは、利害関係者を表すことができ、その利害関係者のために、鍵を保存し、アプリケーションをインストールし、カスタマイズすることができる。主なＳＤは、発行者ＳＤとすることができ、発行者ＳＤは、カード発行者に属する。ＳＤは、階層に組織することができ、ＳＤは、階層内のコンテンツを管理するために異なる特権を有することができる。発行者ＳＤは、認定管理（ＡＭ：Ａｕｔｈｏｒｉｚｅｄ  Ｍａｎａｇｅｍｅｎｔ）特権を有することができ、この特権は、発行者ＳＤが、カードを自律的に管理し、その階層内においてＳＤをインストールでき、また削除できることを意味する。他のＳＤには、それらがカード上の別個の階層内に存在する場合に限って、ＡＭを与えることができる。ＳＤが同じ階層内に存在する場合、ＳＤは、委任管理（ＤＭ：Ｄｅｌｅｇａｔｅｄ  Ｍａｎａｇｅｍｅｎｔ）特権を取得することができ、この特権は、ＳＤが、そのサブ階層内においてカードコンテンツを管理することを可能にする。このＳＤによって実行されるすべてのアクションは、ＤＭ  ＳＤによって発行者ＳＤに提示され、発行者ＳＤによってチェックされるトークンによって、発行者によって認可することができる。
【０５５５】
異なるＳＤ内に存在する、ＧＰ  ＳＣ内のアプリケーションは、トラステッドパーティ（ＴＰ）の概念を使用して、通信することができる。ＴＰは、アプリケーションに割り当てなければならず、アプリケーションがＧＰオープンＡＰＩを介してコマンドを交換することを可能にする、特権とすることができる。アプリケーションは、さもなければ、ＧＰ  ＳＣ上で分離されたままである。
【０５５６】
図３９は、発行者ＳＤを有するＳＤ階層の例示的な一実施形態を示している。
【０５５７】
図４０は、ＤＭを有するＳＤ階層の例示的な一実施形態を示している。
【０５５８】
４．７．２  実施形態についての実施オプション
ＳＣ上にＳＣＷＳをどのように実施できるかに応じて、有効な異なる利害関係者モデルを利用することができる。
【０５５９】
４．７．２．１  ＧＰアプリケーションとしてのＳＣＷＳについての実施形態
図４１は、ＧＰアプリケーションとしてのＳＣＷＳについての例示的な一実施形態を示している。例示的な一実施形態では、ＳＣＷＳは、例えば、ＳＣ発行者によって所有されるＧＰアプリケーションとして、自分のＳＤ内のアプリケーションとして実施することができ、ＭＮＯモデルおよびサードパーティＯＰモデル、ならびに非ＭＮＯモデルをサポートすることができる。ＯＰのアプリケーションロジックは、異なるアプリケーションとして異なるＳＤ内に存在でき、したがって、ＳＣＷＳアプリケーションおよびドメインを所有するエンティティとは異なるエンティティによって所有および管理できると仮定する。両方のアプリケーションは、トラステッドパス機能を使用して通信することができる。サードパーティとカード発行者は、このシナリオを実施するために、例えば、正しい特権をＳＤおよびアプリケーションに与えるために、ビジネス関係に同意しなければならない。
【０５６０】
アプリケーションプロバイダ（サードパーティＯＰ）ＳＤは、ＤＭ特権を備えることができ、ＯＰアプリケーションを管理することができる。ＳＣＷＳ管理は、ＳＣＷＳ管理エージェントＳＤを介して、カード発行者によって実行することができ、ＳＣＷＳ管理エージェントＳＤは、例えば、ＨＴＴＰを介するＲＡＭなど、通常はＯＴＡ管理機能をサポートする。ＡＰＳＤが、ＳＣＰ８０プロトコルもサポートする場合、アプリケーションおよびコンテンツは、ＤＭトークンを使用して、サードパーティによって、ＯＴＡで管理することができる。
【０５６１】
４．７．２．２  ケース２：カードのランタイム環境（ＲＴＥ）で実施されるＳＣＷＳ
図４２は、カードのランタイム環境で実施されるＳＣＷＳについての例示的な一実施形態を示している。例示的な一実施形態では、ＳＣＷＳは、ＳＣ製造業者によって、カードのＲＴＥで実施することができるが、ＳＣＷＳへのアクセスは、ＧＰフレームワークを通して露わにされないので、サードパーティアプリケーションがＳＣＷＳと通信する方法が存在しないことがある。したがって、サードパーティＯＰの利害関係者モデルは、サポートされないことがある。しかし、ＭＮＯモデルおよび非モバイルモデルはサポートされる。
【０５６２】
４．８  ＳＣＷＳ以外のプラットフォーム上でのＯＰの実施
４．８．１  プラットフォームとしてＪａｖａ（登録商標）Ｃａｒｄの使用
Ｊａｖａ（登録商標）カード上では、異なるＳＩＭカード（およびベンダ）間でのＳＩＭカードアプリケーションの相互運用を可能にする、Ｊａｖａ（登録商標）ランタイム環境をインストールすることができる。
【０５６３】
例示的な一実施形態では、ＭＮＯがアプレットを生成し、Ｊａｖａ（登録商標）カードにＯＴＡで配備することを可能にするために、Ｊａｖａ（登録商標）Ｃａｒｄプラットフォームを使用することができる。
【０５６４】
４．８．２  組み込みセキュアエレメントを使用するための実施形態
上で説明したように、ユーザに属する、または何らかのレベルのユーザ管理下にあるデバイス内に組み込まれたローカルＯＰアプリケーションは、スマートカード内で実施することができる。モバイルデバイス内に組み込まれるセキュリティソリューションがますます普及するのに伴い、異なるセキュリティ特性を提供する、複数の異なる実行環境が存在することがある。スマートカード上のＯＰの設計は、コードの安全な実行と、資格証明書の安全な保存を可能にすることができる、他の（組み込み）セキュリティエレメントに拡張することができる。さらに、実行環境は、特に、ＯＰ−ユーザの認証対話、（ＨＴＴＰ（Ｓ）ベースの）ＯＰ−ブラウザ通信、ならびに（やはりＨＴＴＰ（Ｓ）ベースの）ＯＰ−ＲＰアソシエーションおよびアサーションメッセージのために、外部環境への通信チャネルを提供しなければならないことがある。
【０５６５】
例示的な一実施形態では、トラステッド実行環境（ＴＥＥ）をデバイス上のＯＰソフトウェアに提供するために、モバイルフォン内ですでに利用可能な既存のセキュリティ環境（例えば、Ｔｒｕｓｔ  Ｚｏｎｅなど）を利用することができる。
【０５６６】
スマートカードは、ＭＮＯの管理下にあると考えることができるので、ＭＮＯの主要な資産を表すことができる。組み込み実行環境上でのＯＰの実施では、特に、ＭＮＯがローカルＯＰとともに共有秘密を確立する実施形態では、ＭＮＯは、実行環境のセキュリティ特性を検証するための手段を必要とすることがある。そのような手段は、以下のものを含むことができるが、これらに限定されない。
●実行環境の完全性測定を実行するための機能。
●完全性測定を報告するための通信。
●デバイスの実行環境をトラステッド実行環境（ＴＥＥ）に変える、デバイスの実行環境の（完全性）検証の必要性。
●ＭＮＯネットワークから組み込みＴＥＥへの、ＯＰのためのプロトコル／プロセスのダウンロード／プロビジョニング。
●ＴＥＥの通信機能、ＯＰは、ＲＰおよびユーザ（ならびにＭＮＯ）と通信できなければならない。
【０５６７】
（スマートカード上またはＴＥＥ内など）いくつかの例示的な実施形態では、ＭＮＯは、ユーザ挙動（例えば、ユーザが訪れたＲＰ、ログイン頻度、ユーザ挙動など）についての追加情報を獲得することができる。例えば、会社がユーザ挙動をＭＮＯから隠すことを望む企業環境など、プライバシ要件の厳しいシナリオでは、ＭＮＯを深く関与させないほうが好都合なことがある。
【０５６８】
別の例示的な実施形態では、ローカルＯＰ実施を実行するために、組み込みセキュリティ機能が使用される場合、ＭＮＯは、ＯｐｅｎＩＤプロセスに関与しないことがある。これは、ユーザが、自らのデバイスのＴＥＥ内で、ＯＰインストールを自律的にセットアップし、管理し、維持することを可能にすることができる。そのようなシナリオでは、ＭＮＯはＯＰ実施において信用を欠くことがあると仮定することができるので、ＯＰがＭＮＯと秘密を共有できる可能性が低いことがある。しかし、ユーザとユーザのデバイスの間のローカル信用関係は存在することができる。ユーザは、どのようなプライベートな個人データもサードパーティに漏れないことについて、ＯＰ実施を信用することができる。ＭＮＯはＯＰ実施にいかなるアサーションも発行し得ないので、プライバシの向上は、ＯＰに対するＲＰからの信用を低下させる代償を払ってもたらすことができる。
【０５６９】
４．８．３  トラステッドＯｐｅｎＩＤ革新の概念の統合
例示的な一実施形態では、ＯＰは、スマートカード上で実施することができる。デバイス完全性についての評価を含むことができ、この評価は、デバイスが完全性を測定および報告できるという要件を導入することができる。完全性検証／ＭＮＯに対する完全性報告をサポートできるデバイスの場合、ＭＮＯは、デバイスの完全性、およびＯＰのインストール／ランタイム環境の完全性を最初にチェックすることができる。その後、ＭＮＯは、ＯＰソフトウェアのための（リモート）ソフトウェアインストール手順をトリガすることができる。さらに、ＭＮＯは、ＯＰアプリケーションに、デバイスのための基準値を設定することができる。その後、ＯＰは、ＯｐｅｎＩＤ認証中に報告された測定値を、これらの基準値と照合することができ、完全性チェックに合格した場合、認証を許可することができる。
【０５７０】
上では特徴および要素を特定の組み合わせで説明したが、各特徴または要素を単独で、または他の特徴および要素との任意の組み合わせで使用できることを当業者であれば理解されよう。加えて、本明細書で説明した方法は、コンピュータまたはプロセッサによって実行する、コンピュータ可読媒体内に包含された、コンピュータプログラム、ソフトウェア、またはファームウェアで実施することができる。コンピュータ可読媒体の例は、（有線接続または無線接続を介して送信される）電子信号と、コンピュータ可読記憶媒体とを含む。コンピュータ可読記憶媒体の例は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光媒体を含むが、これらに限定されない。ソフトウェアと連携するプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおいて使用する無線周波数送受信機を実施するために使用することができる。  
【図１Ａ】
0005540119.tif 000002
【図１Ｂ】
0005540119.tif 000003
【図１Ｃ】
0005540119.tif 000004
【図２】
0005540119.tif 000005
【図３】
0005540119.tif 000006
【図４】
0005540119.tif 000007
【図５】
0005540119.tif 000008
【図６】
0005540119.tif 000009
【図７】
0005540119.tif 000010
【図８】
0005540119.tif 000011
【図９】
0005540119.tif 000012
【図１０】
0005540119.tif 000013
【図１１】
0005540119.tif 000014
【図１２】
0005540119.tif 000015
【図１３】
0005540119.tif 000016
【図１４】
0005540119.tif 000017
【図１５】
0005540119.tif 000018
【図１６】
0005540119.tif 000019
【図１７】
0005540119.tif 000020
【図１８】
0005540119.tif 000021
【図１９】
0005540119.tif 000022
【図２０】
0005540119.tif 000023
【図２１】
0005540119.tif 000024
【図２２】
0005540119.tif 000025
【図２３】
0005540119.tif 000026
【図２４Ａ】
0005540119.tif 000027
【図２４Ｂ】
0005540119.tif 000028
【図２５Ａ】
0005540119.tif 000029
【図２５Ｂ】
0005540119.tif 000030
【図２６Ａ】
0005540119.tif 000031
【図２６Ｂ】
0005540119.tif 000032
【図２７Ａ】
0005540119.tif 000033
【図２７Ｂ】
0005540119.tif 000034
【図２８】
0005540119.tif 000035
【図２９】
0005540119.tif 000036
【図３０】
0005540119.tif 000037
【図３１】
0005540119.tif 000038
【図３２Ａ】
0005540119.tif 000039
【図３２Ｂ】
0005540119.tif 000040
【図３３Ａ】
0005540119.tif 000041
【図３３Ｂ】
0005540119.tif 000042
【図３４Ａ】
0005540119.tif 000043
【図３４Ｂ】
0005540119.tif 000044
【図３５】
0005540119.tif 000045
【図３６】
0005540119.tif 000046
【図３７】
0005540119.tif 000047
【図３８】
0005540119.tif 000048
【図３９】
0005540119.tif 000049
【図４０】
0005540119.tif 000050
【図４１】
0005540119.tif 000051
【図４２】
0005540119.tif 000052