(57)【要約】  ユーザ機器（Ｕ）は、Ｕ内に存在する信頼されたモジュール上などでローカルに実行することができる。例えばＵは、ローカルＩＤプロバイダ機能を通じて、例えばオープンされたＣｏｎｎｅｃｔなどの、シングルサインオンプロトコルに関連する機能を実行することができる。例えばＵは、識別情報および／またはユーザ属性などのユーザ情報を取り出すためにサービスプロバイダによって使用することができる識別トークンおよびアクセストークンを生成することができる。ユーザ属性は、Ｕ上にローカルにまたはネットワークエンティティ上に存在することができるユーザ情報エンドポイントを介して取り出されてもよい。サービスプロバイダは、それがトークンを使用して取り出す情報に基づいて、サービスへのユーザアクセスを許可することができる。
2015511348.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを通じて通信するユーザ機器（ＵＥ）とＩＤプロバイダ（ＩｄＰ）とサービスプロバイダ（ＳＰ）とを備えるシステムにおいて、
トークンを求める要求を受け取るステップであって、前記トークンを求める前記要求は、前記サービスプロバイダによって提供されるサービスへのアクセスを求める要求に応答する、ステップと、
前記トークンを求める前記要求に応答して、前記ＵＥにおいて、前記トークンを求める前記要求に従ってＩＤトークンを生成するステップと、
前記ＵＥを通じて前記ＩＤトークンを発行するステップであって、前記ＩＤトークンは前記サービスへのアクセスを前記ＵＥにもたらすために検証される、ステップと
含むことを特徴とする方法。
【請求項２】
前記ＩＤトークンは、前記ＵＥ内に存在する信頼された環境において安全に生成されることを特徴とする請求項１に記載の方法。
【請求項３】
前記ＳＰのためのアクセストークンを生成するために承認要求を受け取るステップであって、前記承認要求は前記ＵＥのユーザによって認可される、ステップと、
前記承認要求に応答して、前記ＵＥにおいて、前記承認要求の前記ユーザ認可に関連する前記アクセストークンを生成するステップと
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記承認要求の前記ユーザ認可は、前記ＵＥのポリシーを通じて自動的に受け取られることを特徴とする請求項３に記載の方法。
【請求項５】
前記アクセストークンは、ユーザ情報エンドポイントの場所を示す情報を備え、前記ユーザ情報エンドポイントは、前記アクセストークンの検証後すぐに、要求されたユーザ属性を前記ＳＰに供給することを特徴とする請求項３に記載の方法。
【請求項６】
前記アクセストークンの前記検証は、前記要求されたユーザ属性を前記ＳＰにリリースすることを前記ユーザが同意したことの検証を含むことを特徴とする請求項５に記載の方法。
【請求項７】
前記アクセストークンは、前記ＵＥ内に存在する信頼された環境において安全に生成され、前記アクセストークンの前記検証は、前記信頼された環境が有効であることの検証を含むことを特徴とする請求項５に記載の方法。
【請求項８】
前記ユーザ情報エンドポイントは、前記ＵＥまたは、前記ネットワークを通じて前記ＳＰと通信するネットワークエンティティの少なくとも１つに位置することを特徴とする請求項５に記載の方法。
【請求項９】
前記ＩＤトークンおよび前記アクセストークンは、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルに従って生成されることを特徴とする請求項３に記載の方法。
【請求項１０】
前記ＩＤトークンおよび前記アクセストークンは前記ＵＥ内に存在する信頼された環境において安全に生成され、前記方法は、
前記信頼されたモジュールによって前記ユーザの認証状態を判断するステップと、
前記ユーザは認証されていないことを前記認証状態が示す場合は、前記信頼された環境において前記ユーザを認証するステップと
をさらに含むことを特徴とする請求項３に記載の方法。
【請求項１１】
前記ＳＰのためにアクセストークンを生成するための承認要求を受け取るステップと、
前記承認要求に基づいて、前記ＵＥにおいて、第１のアクセストークンおよび第２のアクセストークンを生成するステップであって、前記アクセストークンは前記サービスおよび前記ユーザに関連する、ステップと
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項１２】
前記第１のアクセストークンは、前記第１のアクセストークンの検証後すぐに、第１の要求されたユーザ属性を前記ＳＰに供給する第１のユーザ情報エンドポイントの場所を示す情報を含み、前記第２のアクセストークンは、前記第２のアクセストークンの検証後すぐに、第２の要求されたユーザ属性を前記ＳＰに供給する第２のユーザ情報エンドポイントの場所を示す情報を含み、前記第１のユーザ情報エンドポイントは前記ＵＥ上に位置し、前記第２のユーザ情報エンドポイントは前記ネットワークを通じて前記ＳＰと通信するネットワークエンティティ上に位置することを特徴とする請求項１１に記載の方法。
【請求項１３】
前記第１のユーザ情報エンドポイントによって供給される前記第１の要求されたユーザ属性は、前記ユーザによって機密データとして分類され、前記第２のユーザ情報エンドポイントによって供給される前記第２の要求されたユーザ属性は、前記ユーザによって非機密データとして分類されることを特徴とする請求項１２に記載の方法。
【請求項１４】
前記ＳＰはＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔクライアントであり、前記信頼された環境はローカルＯｐｅｎＩＤ  ＩＤプロバイダ（ＯＰ）であることを特徴とする請求項２に記載の方法。
【請求項１５】
ネットワークを通じて通信するユーザ機器（ＵＥ）とＩＤプロバイダ（ＩｄＰ）とサービスプロバイダ（ＳＰ）とを備えるシステムにおいて、前記ＵＥにおいて
ユーザデータを求める要求を受け取るステップと、
前記ユーザデータの同意された部分をリリースすることへのユーザ同意を受け取るステップと、
前記ユーザ同意に応答して、前記ＳＰに関連するアクセストークンを発生するステップと、
前記ＳＰに前記アクセストークンを発行するステップであって、前記ユーザデータの前記同意された部分は、前記アクセストークンの検証後すぐに前記ＳＰにリリースされる、ステップと
を含むことを特徴とする方法。
【請求項１６】
前記要求されたユーザデータは複数のユーザ属性を備え、前記複数のユーザ属性の少なくとも１つは、リリースされた前記ユーザデータの前記同意された部分の一部ではないことを特徴とする請求項１５に記載の方法。
【請求項１７】
署名を用いて前記アクセストークンに署名するステップであって、前記署名は、前記ＵＥの識別子、または前記ＵＥ内に存在する信頼された環境の識別子の少なくとも１つを含む、ステップ
をさらに含むことを特徴とする請求項１５に記載の方法。
【請求項１８】
前記ＵＥと、前記ネットワークを通じて前記ＳＰと通信する前記ＩｄＰとによって共有されるシークレットを用いて、前記アクセストークンに署名するステップ
をさらに含むことを特徴とする請求項１５に記載の方法。
【請求項１９】
ユーザ情報エンドポイントは前記ＵＥ内に存在し、前記方法は、
前記ユーザ情報エンドポイントにおいて前記アクセストークンを受け取るステップと、
前記アクセストークンの受け取りに応答して、前記ユーザデータの前記同意された部分を前記ＳＰに供給するステップと
をさらに含むことを特徴とする請求項１５に記載の方法。
【請求項２０】
ネットワークを通じて通信するユーザ機器（ＵＥ）とサービスプロバイダ（ＳＰ）とを備えるシステムにおいて、
前記ＳＰにおいて、前記ＳＰによって提供されるサービスへのアクセスを求める要求を受け取るステップであって、前記要求は、前記ＵＥのユーザの識別子、または前記ＵＥの識別子の少なくとも１つを含む、ステップと、
アクセスを求める前記要求に応答して、前記ＳＰにおいてＩＤトークンおよび第１のアクセストークンを受け取るステップと、
前記アクセストークンの検証に応答して、前記ＳＰにおいて、第１のユーザ情報エンドポイントから第１のユーザ属性を取り出すステップであって、前記第１のユーザ情報エンドポイントは前記ＵＥ上に存在する、ステップと
を含むことを特徴とする方法。
【請求項２１】
前記ＳＰにおいて、前記ＳＰ上に記憶されたシークレットを用いて前記ＩＤトークンの署名を検証するステップと、
前記検証に応答して、前記サービスへのアクセスを前記ＵＥに許諾するステップと
をさらに含むことを特徴とする請求項２０に記載の方法。
【請求項２２】
検証のために、前記受け取られたＩＤトークンをチェックＩＤエンドポイントに送るステップと、
検証のために、前記受け取られた第１のアクセストークンを前記第１のユーザ情報エンドポイントに送るステップであって、それによって前記ＩＤトークンおよびアクセストークンを曖昧な値として取り扱う、ステップと
をさらに含むことを特徴とする請求項２０に記載の方法。
【請求項２３】
アクセスを求める前記要求に応答して、第２のアクセストークンを受け取るステップと、
前記第２のアクセストークンの検証に応答して、前記ＳＰにおいて、第２のユーザ情報エンドポイントから第２のユーザ属性を取り出すステップであって、前記第２のユーザ情報エンドポイントは、前記ネットワークを通じて前記ＳＰと通信するネットワークエンティティ上に存在する、ステップと、
前記ＳＰにおいて、前記第１のユーザ属性と前記第２のユーザ属性を組み合わせるステップと
をさらに含むことを特徴とする請求項２０に記載の方法。
【請求項２４】
実行可能命令を備えるメモリと、
前記メモリと通信するプロセッサと
を備える無線送信／受信ユニット（ＷＴＲＵ）であって、
前記命令は、前記プロセッサによって実行されるときに前記プロセッサに、
トークンを求める要求を受け取るステップであって、前記トークンを求める前記要求は、サービスプロバイダ（ＳＰ）によって提供されるサービスへのアクセスを求める要求に応答する、ステップと、
前記トークンを求める前記要求に応答して、前記トークンを求める前記要求に従ってＩＤトークンを生成するステップと、
前記ＩＤトークンを発行するステップであって、前記ＩＤトークンは前記サービスへのアクセスを前記ＷＴＲＵにもたらすために検証される、ステップと
を含む動作を遂行させることを特徴とする無線送信／受信ユニット（ＷＴＲＵ）。
【請求項２５】
前記ＳＰのためのアクセストークンを生成するために承認要求を受け取るステップであって、前記承認要求は前記ＷＴＲＵのユーザによって認可される、ステップと、
前記承認要求に応答して、前記承認要求の前記ユーザ認可に関連する前記アクセストークンを生成するステップと
を含む動作を行うための命令を実行するように、前記プロセッサがさらに構成されることを特徴とする請求項２４に記載のＷＴＲＵ。
【請求項２６】
前記アクセストークンは、ユーザ情報エンドポイントの場所を示す情報を備え、前記ユーザ情報エンドポイントは、前記アクセストークンの検証後すぐに、要求されたユーザ属性を前記ＳＰに供給することを特徴とする請求項２５に記載のＷＴＲＵ。
【請求項２７】
前記アクセストークンの前記検証は、前記要求されたユーザ属性を前記ＳＰにリリースすることを前記ユーザが同意したことの検証を含むことを特徴とする請求項２６に記載のＷＴＲＵ。
【請求項２８】
前記ユーザ情報エンドポイントは、前記ＷＴＲＵまたは、前記ネットワークを通じて前記ＳＰと通信するネットワークエンティティの少なくとも１つに位置することを特徴とする請求項２５に記載のＷＴＲＵ。
【請求項２９】
前記ＳＰのためにアクセストークンを生成するための承認要求を受け取るステップと、
前記承認要求に基づいて、前記ＷＴＲＵにおいて、第１のアクセストークンおよび第２のアクセストークンを生成するステップであって、前記アクセストークンは前記サービスおよび前記ユーザに関連する、ステップと
を含む動作を行うための命令を実行するように、前記プロセッサがさらに構成されることを特徴とする請求項２４に記載のＷＴＲＵ。
【請求項３０】
前記第１のアクセストークンは、前記第１のアクセストークンの検証後すぐに、第１の要求されたユーザ属性を前記ＳＰに供給する第１のユーザ情報エンドポイントの場所を示す情報を含み、前記第２のアクセストークンは、前記第２のアクセストークンの検証後すぐに、第２の要求されたユーザ属性を前記ＳＰに供給する第２のユーザ情報エンドポイントの場所を示す情報を含み、前記第１のユーザ情報エンドポイントは前記ＷＴＲＵ上に位置し、前記第２のユーザ情報エンドポイントはネットワークを通じて前記ＳＰと通信するネットワークエンティティ上に位置することを特徴とする請求項２９に記載のＷＴＲＵ。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２０１２年１月２０日に出願された米国仮特許出願第６１／５８９，１２５号の利益を主張するものであり、その内容の全体が参照により本明細書に組み込まれている。
【背景技術】
【０００２】
インターネットサービスにアクセスするために、モバイルデバイスがますます使用されるようになっている。インターネットサービスは、センシティブなデータを保護するために安全な取引を必要とすることが多い。このようなセキュリティ対策はしばしば、ユーザ名、個人識別番号（pin）、および／またはパスワードなどのデータ要件の形式で、識別および認証の負担をユーザに課す。無線通信ネットワークは、様々な形式の認証を実施することがある。サービスプロバイダはまた、様々なユーザ属性を探索して、ユーザを認証し、ユーザを識別し、および／または、ウェブサービスへのアクセスのユーザのレベルを判定することがある。
【０００３】
ユーザに対してユーザ認証の煩わしさを軽減することを目指して、シングルサインオン（ＳＳＯ）ソリューションが提案されている。ＯｐｅｎＩＤプロトコルは、シングルサインオンを可能にするプロトコルの一例である。ＯｐｅｎＩＤ２．０プロトコル、およびより最近のＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルは、ＯｐｅｎＩＤプロトコルの最も普及しているものである。本明細書において以下では、用語「ＯｐｅｎＩＤプロトコル」は単に、ＯｐｅｎＩＤ２．０およびＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔを含む、様々な形式のＯｐｅｎＩＤプロトコルのいずれかを包含することを意味される。特定のプロトコルが考察される場合は、それが具体的に識別される。
【０００４】
ＯｐｅｎＩＤプロトコルなどの、ＳＳＯに対する現在のアプローチは、ネットワーク識別プロバイダが様々なＳＳＯ機構を実装することを必要とする。これらのアプローチは、ユーザ識別情報に対して、それがＳＳＯ識別プロバイダによって扱われるので、ユーザには限られた制御を付与し、結果として、ユーザデータおよび通信がセキュリティ攻撃を受けやすくなることがある。
【発明の概要】
【０００５】
本明細書では、ユーザ機器（ＵＥ）上に、例えばＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルに関連付けられた機構などの、識別管理機構を実装するためのシステム、方法、および装置の実施形態について述べられる。例示的な実施形態では、ユーザ機器（ＵＥ）およびサービスプロバイダ（ＳＰ）は、ネットワークを介して通信することができる。ＵＥのユーザは、ＳＰによって提供されるサービスへのアクセスを要求することができる。ＳＰは、ユーザおよび／またはＵＥの識別を認証するために識別（ＩＤ）トークンを要求することができる。ＵＥは、要求に従ってＩＤトークンを生成することができる。例えば、ＩＤトークンは、ＵＥ内に存在する信頼された環境において安全に生成されてもよい。このような信頼された環境は、ユニバーサル集積回路カード（ＵＩＣＣ：Universal Integrated Circuit Card）、信頼されたモジュール、安全な環境など、またはそれらの任意の適当な組み合わせによって実装されてもよい。ＵＥは、例えば、信頼された環境を解して、ＳＰにＩＤトークンを発行することができる。ＩＤトークンは、ＳＰによって提供されるサービスへのアクセスをＵＥに提供するために検証されてもよい。ＵＥはまた、ユーザによって認可された承認要求（authorization request）の受信に応答して、アクセストークンを生成することができる。アクセストークンは、ＵＥによって要求されたＳＰからのサービスに関連してもよい。したがってアクセストークンは、承認要求のユーザ認可に関連付けられてもよい。例えばＳＰは、例えばユーザ属性などのユーザについての追加の情報を受信するために、承認要求を発行することができる。ＵＥはＳＰに前記アクセストークンを発行することができ、および、ＳＰは、アクセストークンを検証すると、それが要求したユーザ属性を受信することができる。ＩＤトークンおよびアクセストークンは、ＵＥにおいて、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルに従って、生成されてもよい。例えばトークンは、ＵＥ内に存在する信頼されたモジュールにおいて安全に生成されてもよい。
【０００６】
別の例示的な実施形態では、ＵＥは、ＳＰによって要求されるサービスに関連するアクセストークンをプロビジョニング（provision）することができる。このようなアクセストークンは、要求されたサービスを提供するＳＰによって回収（redeem）されてもよい。ＵＥは、ユーザデータに対する要求受信したことに応答して、アクセストークンを生成することができる。アクセストークンは、ユーザ情報エンドポイントの位置を示す情報を備えることができる。例えばＳＰは、位置を使用して、ユーザ情報エンドポイントからユーザデータを取り出す（retrieve）ことができる。ユーザ情報エンドポイントは、アクセストークンの検証をすると、要求されたユーザ属性をＳＰに提供することができる。ユーザ情報エンドポイントは、ＵＥ内の信頼されたモジュール、ネットワークを介してＳＰと通信するネットワークエンティティ、またはそれらの組み合わせ上に位置することができる。例えばＵＥは、サービスおよびＵＥのユーザに関連付けられた、第１のアクセストークンおよび第２のアクセストークンを生成することができる。第１のアクセストークンは、第１のアクセストークンの検証をすると、ＳＰに第１の要求されたユーザ属性を提供する、第１のユーザ情報エンドポイントの位置を示す情報を備えることができる。第２のアクセストークンは、第２のアクセストークンの検証をすると、ＳＰに第２の要求されたユーザ属性を提供する、第２のユーザ情報エンドポイントの位置を示す情報を備えることができる。第１のユーザ情報エンドポイントは、例えば信頼されたモジュール上など、ＵＥ上に位置することができ、および、第２のユーザ情報エンドポイントは、ネットワークを介してＳＰと通信するネットワークエンティティ上に位置することができる。例えば、第１のユーザ情報エンドポイントによって提供される第１の要求されたユーザ属性は、ユーザによって機密データとして分類されてもよく、および、第２のユーザ情報エンドポイントによって提供される第２の要求されたユーザ属性は、ユーザによって非機密データとして分類されてもよい。ＳＰは、ＵＥ／ユーザにサービスするために、異なるセキュリティ分類を有し、および、それらのそれぞれのユーザ情報エンドポイントから取得される、第１のユーザ属性と第２のユーザ属性とを組み合わせることができる。
【０００７】
代替的実施形態では、アクセストークンを、ＳＰに代えて、または、それに加えて、トークンを受信する他の当事者によって回収することができる。
【図面の簡単な説明】
【０００８】
添付の図面と併せて例として示される以下の説明から、より詳細な理解を得ることができる。
【図１】ネットワークにおける例示的なインターフェースを示すブロック図である。
【図２】例示的な実施形態に従って、ＨＴＴＰリダイレクトメッセージでのＯｐｅｎＩＤプロトコルのフローチャートである。
【図３】ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルの例示的な実装形態に従って、例示的な検出（discovery）プロセスを示すフロー図である。
【図４】構成情報を取り出すための例示的なプロトコルフローを示すフローチャートである。
【図５】例示的な登録プロトコルフローを示すフローチャートである。
【図６】ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルの例示的な実装形態のフローチャートである。
【図７】承認要求を使用した例示的なＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔコールフローのフローチャートである。
【図８】例示的な実施形態に従って、ローカルトークン生成での例示的なコールフローの図である。
【図９】例示的な実施形態に従って、事前に確立された共有シークレットＳを共有するローカルＯＰでの例示的なプロトコルフローのフローチャートである。
【図１０】例示的な実施形態に従って、ユーザ情報エンドポイントがＵＥ上にローカルに存在する、ＯｐｅｎＩＤプロトコルのコールフローを示す図である。
【図１１】例示的な実施形態に従って、ユーザデータがローカルに記憶され、および、ユーザデータがネットワークエンティティ上に記憶される、ＯｐｅｎＩＤプロトコルのコールフローを示す図である。
【図１２Ａ】１つまたは複数の開示された実施形態を実装することができる、例示的な通信システムのシステム図である。
【図１２Ｂ】図１２Ａに示される通信システム内で使用することができる、例示的な無線送信／受信ユニット（ＷＴＲＵ）のシステム図である。
【図１２Ｃ】図１２Ａに示される通信システム内で使用することができる、例示的な無線アクセスネットワーク、および例示的なコアネットワークのシステム図である。
【発明を実施するための形態】
【０００９】
以下の詳細な説明は、例示的な実施形態を示すために提供され、および、本発明の範囲、適用可能性、または構成を限定するものではない。本発明の趣旨および範囲から逸脱せずに、要素およびステップの機能および構成において様々な変更が行われてもよい。
【００１０】
本明細書では、ユーザおよび／またはユーザ機器（ＵＥ）の識別を管理するための様々な方法およびシステムが述べられる。本明細書では、実施形態はＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルとのコンテキストにおいて説明されてもよいが、実施形態はＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルを実装することに限定されず、例えば他のシングルサインオン（ＳＳＯ）プロトコルおよび／またはフェデレーテッド（federated）識別プロトコルを実装することができる。同様に本明細書ではＯｐｅｎＩＤエンティティが参照として使用されてもよいが、実施形態はＯｐｅｎＩＤエンティティに限定されず、ＯｐｅｎＩＤエンティティは、ＯｐｅｎＩＤエンティティと同一または同様な機能を実行する他のエンティティに拡張可能であってもよい。例えば本明細書で使用される用語、リライングパーティ（ＲＰ：relying party）およびクライアントは、サービスウェブサイトなどのサービスプロバイダ（ＳＰ）を称してもよい。用語、ＯｐｅｎＩＤ識別プロバイダ（ＯＰ）、および承認サーバ（authorization server）は、ネットワークＩＤプロバイダ（ＩｄＰ）または認証エンドポイント（ＡＥＰ）を称してもよい。用語、ユーザ機器（ＵＥ）は、本明細書でさらに述べられるように任意の適切な無線送信／受信ユニット（ＷＴＲＵ）を称してもよい。
【００１１】
１つの例示的な実施形態では、認証エンドポイント（例えばＯＰサーバ）の認証機能は、ＵＥ内に存在するローカルセキュリティモジュールによって実装されてもよい。例えば、モバイルデバイスのローカルエージェント（例えばセキュリティモジュール、信頼されたモジュールなどの信頼された環境）は、ネットワークサイド識別プロバイダに対するプロキシとして動作してもよい。ローカルセキュリティモジュールは、ＵＥのエンドユーザを認証および／または承認することができる機能を実行するために使用されてもよい。ローカルセキュリティモジュールは、ローカル識別プロバイダと称されてもよく、および、例えばＯｐｅｎＩＤ  ＣｏｎｎｅｃｔなどのＯｐｅｎＩＤプロトコルに基づいてエンドユーザを認証するために使用されてもよい。用語、ローカルＯｐｅｎＩＤは、ＳＳＯおよび／または識別管理の実装形態が、例えばＯｐｅｎＩＤ  ＣｏｎｎｅｃｔなどのＯｐｅｎＩＤプロトコルに準拠している、ローカルＳＳＯ実装形態のサブセットを示すために使用されてもよい。例えば、ローカルＯｐｅｎＩＤは、ローカルに位置するエンティティまたは信頼された環境によって実行することができる、ＯＰの機能を示すために使用されてもよい。ローカルＯＰは、装置上でローカルに、ＯｐｅｎＩＤサーバ（例えば、承認サーバ）の機能または機能のサブセットを実行するエンティティまたはモジュールを示すために使用されてもよい用語である。
【００１２】
例示的な実施形態に従って、ローカルＯＰは、トークンに基づいているプロトコルフローを利用してもよい。このようなトークンはＳＰ（例えばＲＰ）に発行されてもよい。トークンは、識別プロバイダから、および／または、ユーザ情報エンドポイントから、ユーザについての情報（例えば属性）を取り出すために使用されてもよい。本明細書で使用されるように、ユーザ属性は、ユーザに関連付けられた任意の情報要素を称してもよい。例示的なユーザ情報（例えば属性）は、非限定的にユーザの年齢および住所を含み、このような属性は、トークンを使用してＳＰによって取り出されてもよい。例えばＳＰは、トークンを使用して、トークンが情報を搬送することなく情報を取り出してもよい。
【００１３】
本明細書で述べられる実施形態は、認証のためにトークンを使用してもよい。例えばＵＲＬおよび／または電子メールアドレスなどの、様々な識別子が使用されてもよい。例えばＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔなどの認証プロトコルは、ユーザ属性および／または識別情報の安全な交換を容易にすることができる。
【００１４】
図１は例示的な実施形態に従って、例示的な通信インターフェースを示すブロック図である。ＵＥ１００などのモバイルデバイスは、公衆インターネット上で直接にアドレス可能となることなくインターネットに接続されてもよい。例示的なシナリオでは、ＵＥ１００、ならびにＵＥ１００上で稼働しているサービスおよび／またはアプリケーションは、例えばウェブサービスプロバイダ１０２などの外部エンティティから到達されなくてもよい。例えばローカルＯＰ１０４などのＵＥ１００上のローカルサービスは、ＵＥ１００上のブラウザ１０６を介して、および／またはモバイルネットワークオペレータ（ＭＮＯ）１０８の管理バックエンドシステムによって到達されてもよい。ローカルサービスは、ローカルＯＰ１０４がＭＮＯ１０８によって発行され、および、ＳＩＭカード上にインストールされる場合は、例えばオーバージエア（ＯＴＡ：over the air）管理を介してアクセスされてもよい。例えばサービスプロバイダ１０２などの一部のウェブサービスは、ＵＥ１００上で稼働するサービスと直接通信してもよい。
【００１５】
ＵＥ１００がＭＮＯネットワーク１０８を介してインターネットに接続される例示的な構成では、例示的な通信パス／インターフェースは、図１に示される実施形態に従って識別されてもよい。インターフェース（ＩＦ）１１２において、ＵＥ１００におけるブラウザ１０６は、例えばＨＴＴＰ要求を使用することによって、ウェブベースのサービス（例えばＳＰ１０２）をコンタクトしてもよい。ＳＰ１０２は、ＨＴＴＰ要求に回答し、および／または、ブラウザ１０６に応答を送信してもよい。例示的なシナリオでは、ＳＰ１０２は、要求を受信する前に、ブラウザ１０６との通信を開始することができなくてもよい。ＩＦ１１４は、ブラウザ１０６および内部ローカルＯＰ１０４に利用可能であってもよい。ブラウザ１０６は、例えばＨＴＴＰを介して、および／または、Ｊａｖａアプレット、Ｊａｖａスクリプトウィジェット、もしくはＯＳ  ＡＰＩなどのミドルウェアソフトウェアエンティティを介して、ＵＥ１００内に存在するローカルＯＰ１０４と通信してもよい。ローカルＯＰ１０４は、例えばＨＴＴＰ応答で、ブラウザ、アプリケーション、および／またはＡＰＩからの要求に応答してもよい。例示的な構成では、ローカルＯＰ１０４は、要求を受信する前に、ブラウザ１０６との通信を開始することができなくてもよい。
【００１６】
ＩＦ１１６は、バックチャネルと称されてもよい。バックチャネル１１６を使用して、ＳＰ１０２はＩｄＰサーバ１１０と（例えばＨＴＴＰを使用して）コンタクトしてもよく、および／または、ＩｄＰサーバ１１０はサービスプロバイダ１０２と（例えばＨＴＴＰを使用して）コンタクトしてもよい。ＩＦ１１６を介した通信は、ブラウザ１０６またはユーザのデバイス１００を含むことなく発生してもよい。ＩＦ１１８は、ＩｄＰ１１０およびＭＮＯネットワーク１０８に利用可能であってもよい。図１の破線の楕円で示されるように、ＩｄＰ１１０はスタンドアロンであってもよく、または、ＭＮＯネットワーク１０８の一部であってもよい。ＩｄＰサーバ１１０は、ＭＮＯネットワーク１０８の内部エンティティによって（例えば、ＨＴＴＰおよび／またはプロプライエタリ（proprietary）インターフェースを使用して）到達されてもよい。ＩｄＰサーバ１１０は、ＭＮＯネットワーク１０８の内部エンティティと通信することが可能であってもよい。例示的な構成では、ＩｄＰサーバ１１０がＭＮＯネットワーク１０８の内部エンティティと通信できるかは、ＭＮＯファイアウォールルールおよび／またはポリシーに依存してもよい。ＩＦ１２０は、オーバージエア（ＯＴＡ）管理インターフェース１２０と称されてもよい。ＯＴＡインターフェース１２０は、ＭＮＯネットワーク１０８およびローカルＯＰ１０４に対して利用可能であってもよい。例えば、ＭＮＯネットワーク１０８におけるエンティティは、ＯＴＡ管理インターフェース１２０を使用して、ＵＩＣＣ／ＳＩＭカード上のアプリケーションと通信してもよい。ローカルＯＰ１０４のアプリケーションからＭＮＯネットワーク１０８上のエンティティへの接続は、ＭＮＯファイアウォールルールに依存してもよい。ＩＦ１２２は、例えばローカルＯＰ１０４および／またはＩｄＰ１１０のアプリケーションの所有権に応じて、ローカルＯＰ１０４および／またはＩｄＰサーバ１１０に利用可能であってもよく、または、利用不能であってもよい。例えば、ＩＦ１２２の両方のエンティティ（例えばローカルＯＰ１０４およびＩｄＰ１１０）の間の直接通信チャネル（例えばＳＭＳ、ＯＴＡなどを使用して）は、両方のエンティティがＭＮＯによって動作され、および／もしくは、所有され、ならびに／またはＭＮＯからの同意を有するときに確立されてもよい。例示的な構成では、ＭＮＯは、ＩＦ１２２において通信チャネルを有効にしてもよい。通信ＩＦ１２４は、ＳＰ１０２とローカルＯＰ１０４の間では利用不能であってもよい。サービスプロバイダ１０２からＵＥ１００、またはＵＥ１００上で稼働しているローカルＯＰサービスへの直接通信は、例えばＵＥ１００がパブリックに（publicly）アドレス可能でないときは、利用可能でなくてもよい。ＩＦ１２６は、ブラウザ１０６およびＩｄＰ１１０に対して利用可能であってもよい。例えば、ブラウザ１０６は、ＨＴＴＰ要求を介してＩｄＰ１１０に到達してもよい。ＩｄＰサーバ１１０は、ブラウザ１０６のＨＴＴＰ要求に応答してもよい。
【００１７】
例えばＩＦ１２２を介して通信する能力などのインターフェース利用可能性は、通信エンドポイントの制御、および／または、エンドポイントの間の通信パスに依存してもよい。例示的な構成では、ＩＦ１２２は、ＯＰ１１０およびローカルＯＰ１０４がＭＮＯの制御下にあり、ならびに、ＯＰ１１０とローカルＯＰ１０４との間の通信が、ＳＰ１０２とローカルＯＰ１０４との間の物理通信パス上で実現されるときに利用可能であってもよい。
【００１８】
例示的な実施形態では、ローカルＯＰ１０４は、ＳＰ１０２にトークンを発行してもよい。トークンは、ＳＰ１０２によってネットワークＩｄＰ／ＯＰ１１０に提示されてもよい。このようなトークンは、データを取り出すために使用されてもよい。ローカルＯＰ１０４にトークンを提示するために通信インターフェースがＳＰ１０２に利用可能でない例示的な構成では、ネットワークＩｄＰ／ＯＰ１１０は、トークンが正当なローカルＯＰ１０４によって発行されたことを検証してもよい。ＩｄＰ／ＯＰ１１０はまた、トークンが有効であるかを判定してもよい。例えばトークンが有効であるかを判定することは、トークンが失効していないことを検証することを備えてもよい。
【００１９】
さらに図１を参照すると、ＳＰ１０２からローカルＯＰ１０４への間接通信が、例えばリダイレクトメッセージの手段によって、ＵＥ１００のブラウザ１０６を介して発生してもよい。ＳＰ１０２は、ＵＲＬを備えるＨＴＴＰ３ｘｘメッセージを送信して、ブラウザ１０６をリダイレクトしてもよい。例えば、ＯｐｅｎＩＤプロトコルに従って、ＵＲＬはＩｄＰ認証エンドポイント（ＡＥＰ）に対応するＵＲＬであってもよい。ＩｄＰ認証エンドポイントは、例えば検出（discovery）機構を通じてＳＰ１０２に通知されてもよい。ＵＥ１００は、ＵＲＬをＡＥＰのサーバのインターネットプロトコル（ＩＰ）アドレスに解決してもよい。例えばＵＥ１００上にインストールされたローカルＯＰ１０４を有するＵＥ１００は、ＵＲＬをローカルＯＰサーバ１０４のローカルＩＰアドレスに解決してもよい。
【００２０】
図２は、例示的なＨＴＴＰリダイレクトメッセージを示すフローチャートである。図２における情報フローは、ＯｐｅｎＩＤプロトコルを実装するときに使用することができる、間接通信で実装されてもよい。ＵＥのブラウザ２０２は、ＳＰ２０４によって提供されるサービスへのアクセスを要求することによって、ＳＰ２０４との通信を開始してもよい。要求は、サービスにアクセスするためのＨＴＴＰ要求を備えてもよい。２０６において、ＳＰ２０４は要求に応答してもよく、および、２０６において、リダイレクトメッセージの一部としてローカルＯＰ２００にデータを送信してもよい（例えば、データはＨＴＴＰメッセージのパラメータにおいて渡されてもよい）。２０８において、ブラウザ２０２は、ローカルＯＰ２００のローカルアドレスに解決してもよい。ブラウザ２０２は、例えば２１０においてメッセージを送信することによって、それが２０６において受信したリダイレクトメッセージをローカルＯＰ２００まで追跡（follow）してもよい。例えば、ブラウザ２０２は、ＤＮＳルックアップへの変更および／またはヘルパソフトウェア（例えばＪａｖａアプレット）を介して、リダイレクトを追跡してもよい。例えば、ＵＲＬ／アドレスのＤＮＳ解決はホストファイルを介して発生してもよく、および／または、Ｊａｖａアプレットサプリカントによって容易にされてもよい。２１２において、ローカルＯＰ動作が発声してもよい。例えば、２１２において、ＵＥのユーザはＵＥで認証されてもよい。２１４および２１６において、ローカルＯＰ２００は、例えばブラウザ２０２をＳＰ２０４に送信することができる別のリダイレクト（２１４で）を介して、ＳＰ２０４に情報を渡してもよい（２１６において）。情報および／またはデータは、ＨＴＴＰメッセージのパラメータにおいて渡されてもよい。例示的な構成では、ＳＰ２０４からローカルＯＰ２００への直接通信は利用可能でなくてもよい。
【００２１】
ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルは、例えばブラウザベース、モバイル、および／またはＪａｖａスクリプトクライアントなどの様々なタイプのクライアントが、識別および認証セッションについての情報を要求および受信することを可能にする。ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔの様々な例示的な実装では、識別データは暗号化されてもよく、ＯＰは検出されてもよく、および、進化したセッション管理（例えばログアウト）が有効とされてもよい。ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔの例示的な実装では、ユーザ識別子は電子メールアドレスおよび／またはＵＲＬに基づいてもよい。例えばユーザから承認が取得されるときに（例えばＯＡｕｔｈベースのコールフローを介して）、サービスプロバイダはユーザ所有のコンテンツおよび／またはプロファイルデータにアクセスすることを許可されてもよい。
【００２２】
ＯｐｅｎＩＤ２．０プロトコルの例示的な実装に従って、クライアントシークレット（例えば、識別プロバイダ（ＩｄＰ／ＯＰ）とＳＰ／クライアントとの間の共有シークレット（shared secret））が各ユーザに対して（例えば、認証プロトコル実行ごとに）確立されてもよい。共有シークレットは、検出プロセスの間に、ＯＰとサービスとの間で確立されてもよい。例えば、共有シークレットは、ロングタームシークレット（long term secret）から派生してもよく、および／または、それはローカルＯＰインスタンスによって計算されてもよい。ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルの例示的な実装に従って、クライアントシークレットはトークンを備えてもよい。例えば、識別（ＩＤ）トークンは、ＯＰによって署名されてもよく、クライアントはトークンを検証してもよく（例えばＯＰ提供のトークンエンドポイントの支援で）、および／または、クライアントはそれ自体でトークン署名を検証してもよい。例示的な実施形態では、ＯＰは、検出および／または登録プロセスの間に、鍵を提供してもよい。登録は、例えば、検出の後で、クライアントとＯＰとの間で実行されてもよい。例示的な構成では、登録プロトコルステップはユーザに特有でなくてもよい。例えば、鍵はトークンを署名するために使用されてもよく、および、鍵は複数のユーザに対する汎用鍵であってもよい。例示的な実施形態では、トークンおよびそれらの署名は、ローカルＯＰによって生成されてもよい。例えば、鍵は、ローカルＯＰに利用可能であってもよく、および、ＯＰは鍵を使用して、署名を生成してもよい。
【００２３】
図３は、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔの例示的な実装に従った例示的な検出プロセスを示す。ＳＰと称されてもよいクライアント３００は、例えばＯｐｅｎＩＤ  ＩＤプロバイダ３０２のエンドポイントＵＲＬなどの情報を探索してもよい。探索後の情報（sought-after information）を取得するプロセスは、検出と称されてもよい。ＯｐｅｎＩＤプロトコルの例示的な実装に従って、ＳＰはプロバイダ情報（例えば帯域外機構を介して）を知ってもよく、したがって検出をスキップしてもよい。別の例示的な実装形態では、クライアント３００は、Ｓｉｍｐｌｅ  Ｗｅｂ  Ｄｉｓｃｏｖｅｒｙ（ＳＷＤ）を使用して、情報を検出してもよい。ＳＷＤにおいては、例えば３０６において、ＵＥのユーザはクライアント３００にユーザの識別子を供給してもよい。ユーザはプリンシパル（principal）と称されてもよい。３０６において、クライアント３００は、識別子のホストを識別してもよい。ホストは、ＳＷＤサービスをホスティングするサーバを参照してもよい。プリンシパルおよび／またはホスト情報は、例えば識別子においてエンドユーザによって供給されてもよい。識別子は、例えばＸＲＩ、電子メール、またはＵＲＬなどであってもよい。３０６において、クライアント３００は、ユーザ供給の識別子に対して、正規化および／または抽出ルールを適用して、プリンシパルおよび／またはホストを判定してもよい。図３を参照すると、例えば、プリンシパルは電子メールを参照してもよく、および、ホストは提供されたメールアドレスにおける「＠」の右側のすべてを参照してもよい。３０８において、クライアント３００は、ＨＴＴＰ  ＧＥＴ要求を使用して、プロバイダ３０２から位置（例えばＵＲＬ）を要求してもよい。３１０において、ＯＰ３０２は、例えば認証エンドポイントおよび／または承認エンドポイントのアドレスなどの位置情報を備える情報を返してもよい。
【００２４】
検出の一部として、クライアント３００は、構成情報を取り出してもよい（例えば図４を参照）。４００において、クライアント３００は、構成情報を要求してもよい。このような構成情報は、ＯｐｅｎＩＤプロバイダ３０２において（例えばＪＳＯＮドキュメントを示すことができるＵＲＬ  ｗｅｌｌ−ｋｎｏｗｎ／ｏｐｅｎｉｄ−ｃｏｎｆｉｇｕｒａｔｉｏｎにおいて）利用可能であってもよい。通信は、ＴＬＳを使用してセキュアとされてもよい。要求に対する応答として、４０２において、ＯｐｅｎＩＤプロバイダ３０２は、ＯｐｅｎＩＤプロバイダ３０２の構成についての属性（例えば情報）を備えることができるＪＳＯＮドキュメントを返してもよい。情報は、例えばエンドポイントについての情報、および／または公開鍵ロケーション情報を備えてもよい。例えば、エンドポイント情報は、認証および／もしくは承認エンドポイントの、トークンエンドポイントの、ユーザ情報（Ｕｓｅｒ  Ｉｎｆｏ）エンドポイントの、ならびに／または、チェックＩＤエンドポイントのＵＲＬを備えてもよい。ＪＳＯＮ  Ｗｅｂ  Ｋｅｙドキュメントは、プロバイダのＪＳＯＮ  Ｗｅｂ  Ｋｅｙ（ＪＷＫ）ドキュメントのＵＲＬを備えてもよい。ＪＷＫドキュメントは、公開鍵のセットを提供することができるＪＳＯＮ構造にあってもよい。このような鍵は、ＪＳＯＮ  Ｗｅｂ  Ｔｏｋｅｎ（例えばＩＤトークン）に署名するように使用されてもよい。
【００２５】
図５は、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルの例示的な実装に従った、例示的な登録プロセスを示す。クライアント３００は、ＯｐｅｎＩＤプロバイダ３０２に登録して、例えば、クライアントＩＤおよび／またはクライアントシークレットを取得してもよい。５００において、クライアント３００は、プロバイダ３０２の検出された登録エンドポイントに要求を発行してもよい。５０２において、応答がクライアント３００に発行されてもよい。応答はＪＳＯＮドキュメントを備えてもよい。ＪＳＯＮドキュメントは、クライアントＩＤおよび／またはクライアントシークレットを備えてもよい。ＴＬＳが通信をセキュアにするために使用されてもよい。
【００２６】
図５を続けて参照すると、クライアントシークレットは、クライアント／ＳＰ３００とＩｄＰ３０２との間の登録の間に確立されてもよい。クライアントシークレットは、承認コードフローを実行することを希望するクライアントに対する認証証明情報（authentication credential）として使用されてもよい。承認コードフローでは、クライアントは、例えばクライアントがアクセストークンを要求するとき、または、クライアントがアクセストークンをリフレッシュすることを希望するときは、プロバイダのトークンエンドポイントに向かって認証するためにクライアントシークレットを使用してもよい。例示的な実装に従って、ＨＭＡＣ署名がＩＤトークンに署名するために使用されてもよい。このような実装では、クライアントシークレットは、署名鍵として使用されてもよい。ＲＰは、例えばＨＭＡＣが署名機構として用いられる場合に、トークン署名を検証するために、その記憶されたクライアントシークレットを使用することを試行してもよい。例えば、ＨＭＡＣ対称署名がローカルＯＰで使用されてもよい。ローカルＯＰは、例えば、ＨＭＡＣ署名を生成するために、ＳＰに対するクライアントシークレットを認識してもよい。
【００２７】
登録は、ユーザがクライアントにログインしたときに、実行され、または、実行されなくてもよい。ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルの例示的な実装では、クライアントシークレットはサービスおよびＩｄＰごとに確立されてもよく、それによりサービスは、ＩｄＰとともにそれ自体のクライアントシークレットを有することができる。ＯｐｅｎＩＤ２．０プロトコルの例示的な実装では、関連シークレット（association secret）が、サービスとＩｄＰとの間の各ユーザ認証プロセスに対して生成されてもよい。関連シークレットは、識別アサーションメッセージ（identity assertion message）に署名するために使用されてもよく、例えば、クライアントは署名を検証してもよい。例示的なＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔ実装では、クライアントシークレットは、クライアント認証証明情報であってもよい。したがって、関連シークレットの役割は、ＩＤトークン上の署名によって実装されてもよい。ＩＤトークン上の署名は、例えばプロバイダＪＷＫ鍵を使用して生成されてもよい。
【００２８】
ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルの例示的な実装に従って、検出および登録プロセスは、ＳＰとネットワーク上のＩｄＰとの間で行われてもよく、それにより２つのエンティティの間で交換されるクライアントシークレットおよび／または他の情報の利用可能性は、ＳＰおよびネットワークＩｄＰに制限されてもよい。
【００２９】
ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルの様々な例示的な実装では、ＩＤトークンは、ＯＡｕｔｈアクセストークンとして作動してもよい。例えばＩＤトークンは、例えばユーザ識別子などの認証データに対して、ＯＰにおいて交換されてもよい。ＩＤトークンは、エンコードされたデータを搬送してもよい。アクセストークンに対する要求は、サービスプロバイダが、ユーザ識別子および／または追加のプロファイルデータ（例えば住所、年齢などのユーザ属性）にアクセスすることを可能にしてもよい。ＩＤトークンのデータフォーマットは、例えばＪＳＯＮデータを備えることができるＪＷＴであってもよい。
【００３０】
本明細書で述べられる実施形態は、例えばＩＤトークンおよび／またはアクセストークンなどの様々なトークンタイプを使用してもよい。このようなトークンは、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルに従って実装されてもよい。例えばＩＤトークンは、認証イベントについての情報を備えてもよく、および、ユーザがＩｄＰにおいて認証されたことをサービスプロバイダが検証することを可能にしてもよい。検証を有効にするために、例えば、ＩＤトークンは、エンコードされたデータを備えてもよい。アクセストークンは、例えばＯＡｕｔｈ  Ｂｅａｒｅｒトークンであってもよい。アクセストークンは、受信するサービスがトークンを回収する（例えばユーザ情報エンドポイントにおいて）ことを可能にする。サービスプロバイダは、アクセストークンを回収して、例えばユーザ情報（例えばユーザ属性／クレーム（claims））を受信してもよい。サービスプロバイダは、ＩＤトークンを使用して、ユーザを認証してもよい。例示的な実施では、サービスは、ＩＤトークンに含まれない追加のデータを取り出すように、アクセストークンを要求してもよい。例えば、サービスプロバイダは、エンドポイントからデータを取得するように、アクセストークンを要求してもよい。
【００３１】
ＩＤトークンは、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルの例示的な実装形態に従って、ＪＷＴフォーマットにあってもよい。ＪＷＴは、例えばユーザの実際の認証のＪＳＯＮ属性を備えてもよい。例えばＩＤトークンは、ＪＷＴとしてエンコードすることができる以下のデータを備えてもよい。
【００３２】
ｉｓｓ−これは応答の発行者の一意な識別子を称してもよい。
【００３３】
ｕｓｅｒ＿ｉ−これはローカルに一意な、および／または、再割り当てされることのないユーザに対する識別子を称してもよく、クライアント（例えば２４４００３２０、またはＡＩｔＯａｗｍｗｔＷｗｃＴ０ｋ５１ＢａｙｅｗＮｖｕｔｒＪＵｑｓｖｌ６ｑｓ７Ａ４）によって消費（consume）されることが意図されてもよい。これは例示的な実装形態に従って、２５５のＡＳＣＩＩ文字を超えなくてもよい。
【００３４】
ａｕｄ−これはＩＤトークンの意図されたオーディエンス（audience）を称してもよい。例えば「ａｕｄ」は、ＲＰのＯＡｕｔｈ  ｃｌｉｅｎｔ＿ｉｄであってもよい。
【００３５】
ｅｘｐ−これは整数を備えてもよく、および／または、ＩＤトークンを処理に対して受け入れることができる満了時間を識別してもよい。このパラメータの処理は、現在の日付／時間が、値にリストされた満了日付／時間の前であるかに依存してもよい。例えば実装者は、例えばクロックスキュー（clock skew）を考慮するために許容量（leeway）を提供してもよい。値は、ＵＴＣにて測定される１９７０−０１−０１Ｔ０：０：０Ｚから所望の日時までの秒数であってもよい。
【００３６】
ｉｓｏ２９１１５−これはエンティティ認証保証（entity authentication assurance）を提供してもよい。例えばこのデータパラメータは、実行さる認証のエンティティ認証保証レベルを特定してもよい。
【００３７】
ｎｏｎｃｅ−承認要求がノンス要求値を含む場合は、この値は要求値と同一の値に設定されてもよい。
【００３８】
以下はＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルの例示的な実装に従って、ＩＤトークンの例示的なコンテンツを示す。例示的なＩＤトークンは、クライアントからチェックＩＤエンドポイントに送信されてもよい。以下のセクションは、例示的なトークンを含む、サービスからエンドポイントへの例示的な要求を示す。
【００３９】
【数１】
2015511348.tif 000003
【００４０】
次のセクションは、エンドポイントによってサービスプロバイダに返すことができる例示的なトークンの（ＪＳＯＮ）コンテンツの例を示す。
【００４１】
【数２】
2015511348.tif 000004
【００４２】
例示的なトークンは、ＪＳＯＮ  Ｗｅｂ  Ｓｉｇｎａｔｕｒｅ（ＪＷＳ）および／またはＪＳＯＮ  Ｗｅｂ  Ｅｎｃｒｙｐｔｉｏｎ（ＪＷＥ）を使用して、署名されてもよく、および／または暗号化されてもよい。署名および／または暗号化に使用される鍵は、例えばＪＳＯＮ  Ｗｅｂ  Ｋｅｙであってもよい。
【００４３】
ＪＷＴにおける属性は、ＪＳＯＮオブジェクトとしてエンコードされてもよい。ＪＷＴは、コンポーネントの組み合わせでの文字列であってもよい。例示的なコンポーネントは、ＪＷＴヘッダセグメント、ＪＷＴ属性セグメント、およびＪＷＴ暗号セグメントを含む。ＪＷＴヘッダセグメントは、ヘッダおよび属性セグメントに適用された暗号動作を記述することができる、ｂａｓｅ６４ｕｒｌ＊エンコードＪＳＯＮを備えてもよい。ＪＷＴ属性セグメントは、属性をエンコードするｂａｓｅ６４ｕｒｌ＊エンコードＪＳＯＮオブジェクトを備えてもよい。ＪＷＴ暗号セグメントは、ＪＷＴヘッダおよび属性セグメントのコンテンツをセキュアにする、ｂａｓｅ６４ｕｒｌ＊エンコード暗号マテリアルを備えてもよい。例示的なｂａｓｅ６４エンコーディングは、後端の「＝」の文字を除去してもよい。
【００４４】
ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルの例示的な実装では、トークン上の署名は、有効なＪＳＯＮ  Ｗｅｂ  Ｔｏｋｅｎ  Ｓｉｇｎａｔｕｒｅｓ（ＪＷＳ）であってもよい。ＪＷＳを使用して署名されたトークンは、署名アルゴリズムについての情報を備えるヘッダを有してもよく、および／または、署名に使用される鍵へのポインタを備えてもよい。ＪＷＳに対する署名アルゴリズムは、以下のアルゴリズムを含むことができるが、実施形態は以下の署名アルゴリズムに限定されない。
【００４５】
ＨＳ２５６  ＳＨＡ−２５６ハッシュアルゴリズムを使用したＨＭＡＣ
ＨＳ３８４  ＳＨＡ−３８４ハッシュアルゴリズムを使用したＨＭＡＣ
ＨＳ５１２  ＳＨＡ−５１２ハッシュアルゴリズムを使用したＨＭＡＣ
ＲＳ２５６  ＳＨＡ−２５６ハッシュアルゴリズムを使用したＲＳＡ
ＲＳ３８４  ＳＨＡ−３８４ハッシュアルゴリズムを使用したＲＳＡ
ＲＳ５１２  ＳＨＡ−５１２ハッシュアルゴリズムを使用したＲＳＡ
ＥＳ２５６  Ｐ２５６曲線およびＳＨＡ−２５６ハッシュアルゴリズムを使用したＥＣＤＳＡ
ＥＳ３８４  Ｐ３８４曲線およびＳＨＡ−３８４ハッシュアルゴリズムを使用したＥＣＤＳＡ、および／または、
ＥＳ５１２  Ｐ５２１曲線およびＳＨＡ−５１２ハッシュアルゴリズムを使用したＥＣＤＳＡ
【００４６】
上記のように、例えば選択された署名アルゴリズムに基づいて、異なる鍵タイプがサポートされてもよい。例示的な実装では、ＲＰはＩＤトークン自体の署名を検証することを選択してもよく、それによりＲＰは検証鍵を知ることが必要になる。鍵へのポインタは、ヘッダの一部であってもよい。例えばポインタは、ＪＳＯＮエンコード公開鍵のセットを示すＵＲＬを備えることができるｊｋｕ（例えばＪＳＯＮ  Ｗｅｂ  Ｋｅｙ  ＵＲＬ）パラメータであってもよい。例示的な実装では、ｘ５ｕパラメータは、Ｘ．５０９公開鍵証明書または証明書チェーン（certificate chain）（例えば鍵に対応する）を示すＵＲＬを備えてもよい。ヘッダパラメータは、トークンおよびトークン署名を生成するエンティティによって設定されてもよい。ＩＤトークンを署名するためにＨＭＡＣ署名が使用される場合は、署名鍵としてクライアントシークレットが使用されてもよい。例示的なアクセストークンは、例えばＯＡｕｔｈ  Ｂｅａｒｅｒトークンであってもよい。例示的なアクセストークンは、例えば、ユーザ情報（例えばＩＤ属性および／またはユーザ情報）を取得するために、ユーザ情報エンドポイントにおいて使用されてもよい。
【００４７】
サービスプロバイダ（クライアント）は、独立してＩＤトークンの検証を実行してもよい。例えば、クライアントは、ＩｄＰ発行サーバとコンタクトせずにトークンを検証してもよい。検証に対する鍵マテリアル（key material）は、検出プロセスにおいて（例えばＪＳＯＮ  Ｗｅｂ  Ｋｅｙ  ＵＲＬパラメータにおいて）、クライアントによって受信されてもよい。
【００４８】
例示的な実施形態に従って、サービスプロバイダは、ＩＤトークンを曖昧な値（（opaque value）として扱ってもよく、および、それらを検証のためにチェックＩＤエンドポイントに提出してもよい。このような実施形態では、サービスプロバイダは、ユーザ認証についての情報をチェックＩＤエンドポイントから受信してもよい。ＩＤトークン上の署名および／または暗号化は、例えばＪＳＯＮ  Ｗｅｂ  Ｋｅｙを使用してもよい。鍵は、登録におけるＪＳＯＮ  Ｗｅｂ  Ｋｅｙパラメータ、および／または公開鍵（例えば、ｘ５ｕヘッダパラメータにおいて参照される）を介してクライアントに利用可能であってもよい。
【００４９】
図６は、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルの例示的な実装形態に従った、例示的なコールフローを示す。図６における例示的なコールフローは、例えばＯＰ（例えば承認サーバ６０４）に共有シークレットを登録していないサービスプロバイダ（例えばクライアント６０２）によって使用されてもよい。サービスプロバイダが識別プロバイダに共有シークレットを登録していない例示的なＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔ実装形態では、サービスプロバイダは、図６の６１０に示されるようにＩＤプロバイダからのＩＤトークンを直接要求してもよい。
【００５０】
サービスプロバイダが識別プロバイダに共有シークレットを登録している、別のＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔ実装形態では、サービスプロバイダがトークンの代わりにセキュアな承認コード（authorization code）を受信することができる、サービスプロバイダは承認コードフロー（図７を参照）に従ってもよい。承認コードは、例えば識別プロバイダにおいてＩＤトークンに対して交換されてもよい。サービスプロバイダは、ＩＤトークンに対する承認コードを回収するときは、事前に確立された共有シークレット（例えば識別プロバイダで）を使用して、サービスプロバイダを認証してもよい。
【００５１】
図６を再び参照すると、ユーザ／ＵＥ６００がクライアント６０２によって提供されるサービスへのアクセスを要求するときに、クライアント６０２は、承認サーバ６０４にシークレットを登録していないことがある。６０６において、ユーザ６００は、例えば電子メールアドレスなどのＯｐｅｎＩＤ識別子を使用することによって、サービスへのアクセスを要求してもよい。識別子は、ユーザ名およびＯｐｅｎＩＤ  ＩｄＰ（ＯＰ）のドメインを備えてもよい。ＯＰは、検出および認証に対するエンドポイントを提供してもよい。６０８において、クライアント６０２（サービスプロバイダ）は、承認要求を準備してもよく、および、要求をユーザ６００に送信してもよい。要求は所望の要求パラメータを備えてもよい。６１０において、承認要求は、例えばＨＴＴＰリダイレクトを使用して、承認サーバ６０４に（例えばユーザを介して）送信されてもよい。６１２において、承認サーバ６０４はユーザ６００を認証してもよく、したがって、承認サーバ６０４は認証エンドポイント（ＡＥＰ）と称されてもよい。例示的な構成では、承認サーバ６０４は、ユーザ６００がすでに認証されており、および、認証が失効していない限り、ユーザ４００を認証してもよい。例えば、ユーザ６００の現在の認証状態は「真」であってもよく、それにより６１２において、ユーザ６００は再認証をする必要がない。６１４において、承認サーバ６０４は、例えばトークンの発行を許可するために、ユーザ６００から同意または承認を取得してもよい。例示的な構成では、ユーザ６００は、ユーザ同意／承認を回避することができるポリシーを確立してもよい。例えば、ユーザ６００は、先のプロトコル実行において「ｒｅｍｅｍｂｅｒ  ｔｈｉｓ  ｄｅｃｉｓｉｏｎ」チェックボックスをクリックしておいてもよい。６１６において、トークンが生成されてもよく、および、承認サーバ６０４はアクセストークンおよび／またはＩＤトークンで、ユーザ６００をクライアント６０２に（６１８において）返信してもよい。例示的な実装形態では、６２０において、クライアント６０２は、チェックＩＤエンドポイント６２８においてＩＤトークンを有効（validate）にしてもよい。６２２において、クライアント６０２は、例えばユーザの識別で、ＩＤトークン応答を受信してもよい。６２４において、クライアント６０２は、例えばアクセストークンを使用して、ユーザ情報エンドポイント６３０にアクセスしてもよい。クライアント６０２は、ユーザ情報エンドポイント６３０にアクセスした後に、例えば要求されたユーザ属性などのユーザ情報応答を受信してもよい。
【００５２】
図７を参照すると、サービスプロバイダ（例えばクライアント７０２）は、ＩＤプロバイダ（例えば承認サーバ７０４）に共有シークレットを登録していてもよい。７０６において、ユーザ／ＵＥ７００は、クライアント７０２によって提供されるサービスへのアクセスを要求してもよい。７０６において、ユーザ７００の識別子をクライアント７０２に供給することによって、アクセスが要求されてもよい。このような識別子は、例えばＯｐｅｎＩＤ識別子を備えてもよい。クライアント７０２は、所望の要求パラメータを備えることができる承認要求を準備してもよく、および、クライアント７０２は、７０８において、ユーザ７００に要求を送信してもよい。クライアント７０２は、７１０において、ＨＴＴＰリダイレクトを使用して承認サーバ７０４などの（例えばユーザ７００を介して）認証エンドポイント（ＡＥＰ）７１３に要求を送信してもよい。７０４において、ＡＥＰ７１３（例えば承認サーバ７０４）は、例えばユーザ７００が現在認証されていない場合は、ユーザ７００を認証してもよい。７１４において、承認サーバ７０４は、例えばユーザ同意／承認をすでに取得していることがあるポリシーが整って（in place）いない場合は、ユーザ７００の同意／承認を取得してもよい。７１６において、承認サーバは承認コードを生成してもよく、および、例えば７１８において承認コードでユーザ７００をクライアント７０２にリダイレクトしてもよい。７２０において、クライアント７０２は、例えばトークンエンドポイント７３４において承認コードを使用して、アサーションを要求してもよい。７２４において、クライアント７０２は、トークンエンドポイント７３４からアサーションを受信してもよい。アサーションは、応答本体（response body）にアクセストークンおよび／またはＩＤトークンを備えてもよい。７２５において、クライアント７０２は、例えばチェックＩＤエンドポイント７３６においてＩＤトークンを有効にしてもよい。７２８において、クライアント７０２は、チェックＩＤエンドポイント７３６からＩＤトークン応答を受信してもよい。このようなＩＤトークン応答は、エンドユーザ７００の識別を備えてもよい。７３０において、クライアント７０２は、例えばアクセストークンを使用してユーザ情報エンドポイント７３８にアクセスしてもよい。７３２において、クライアント７０２は、ユーザ情報エンドポイント７３８からユーザ情報応答を受信してもよい。例示的な実装形態では、サービスプロバイダ（例えばクライアント７０２）は、ステップ７１８で受信されたＩＤトークンを検証してもよく、および、ＩＤトークンから取得された識別情報に基づいてアクセスを許可してもよい。ユーザ情報エンドポイント７３８におけるアクセストークンを使用したＩＤ属性の取り出しは、クライアント７０２に対するオプションであってもよい。
【００５３】
例示的な実施形態では、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルが実装されることを可能にする機構は、ＵＥにおいてローカルに実行されてもよい。例えば、ユーザは、ローカルに認証されてもよく、ユーザに対応する識別属性はローカルに管理されてもよく、ユーザによる識別属性のリリースはローカルに承認されてもよく、および、ユーザ情報エンドポイントはＵＥ上にローカルに位置してもよい。例示的な実施形態では、例えばローカルＯＰなどのローカルな信頼された環境は、セキュアにユーザを認証し、ユーザから承認を取得し、および／または、トークンを生成してもよい。ローカルに生成されたトークンは、例えばそれぞれのエンドポイントからユーザ認証データおよび／またはユーザ識別情報（例えば属性）を取り出すために、サービスプロバイダ（ＳＰ）によって使用されてもよい。本明細書で述べられるように、トークンは、ネットワーク識別プロバイダ（ＩｄＰ）が、承認されたＵＥおよび／または承認されたローカルＯＰによってトークンが発行されたこと、ならびに、トークンが失効していないことを検証するための情報を備えてもよい。トークンが失効したかを判定するために、例えばトークンはユーザ認証に時点でタイムスタンプが付加されてもよい。
【００５４】
図８は、例示的な実施形態に従って、トークンがローカルに生成されてもよい、例示的なプロトコルフローのフローチャートを示す。８０６において、例えばデバイス８００などのＵＥは、サービスプロバイダ８０２によって提供されるサービスへのアクセスを要求してもよい。要求は、デバイス８００のユーザの識別子を含んでもよい。８０８において、サービスプロバイダ８０２（クライアント）は、リダイレクトメッセージを介してデバイス８００からトークンを要求してもよい。したがってＵＥは、トークンに対する要求を受信してもよく、トークンに対する要求は、サービスプロバイダによって提供されるサービスへのアクセスに対する要求に対応する。８０８における要求は、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルに従って、ＩＤトークンに対する要求を含んでもよい。８０８における要求は、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルに従って、アクセストークンに対する要求を含んでもよい。例えば、アクセストークンは、サービスプロバイダ８０２によって要求されてもよく、それによりサービスプロバイダはデバイス８００のユーザの属性を取り出すことができる。属性は、ユーザの識別に関連してもよい。サービスプロバイダ８０２は、例えば、サービスプロバイダ８０２が、追加の属性またはユーザ情報は必要ないと判定した場合に、アクセストークンを要求しないことを決定してもよい。
【００５５】
さらに図８を参照すると、８１０において、ユーザは、デバイス８００がサービスプロバイダ８０２にトークンを発行することに同意（認可）を与えてもよい。例えば、アクセストークンは、サービスプロバイダ８０２が、ユーザ情報エンドポイントから、指定された属性にアクセスすることを可能にする同意（例えばユーザによって与えられる）を表してもよい。例えば、ローカルに生成されたアクセストークンは、ユーザ情報エンドポイントが、アクセスが許可された特定の属性を識別することを可能にするデータを備えてもよい。例示的な実施形態に従って、例えばサービスプロバイダ８０２が複数の属性へのアクセスを要求し、および、要求された属性の一部へのアクセスの承認することにユーザが同意した（８１０において）場合は、ユーザ情報エンドポイントは、承認された情報をリリースしてもよく、および、ユーザによって承認されていない属性はリリースしなくてもよい。
【００５６】
例えばデバイス８００などのＵＥは、ユーザデータに対する要求を受信してもよく、および、ユーザデータの同意された部分をリリースすることのユーザ同意を受信してもよい。ユーザ同意に応答して、デバイス８００は、サービスプロバイダ８０２に関連付けられてもよいアクセストークンを生成してもよい。デバイス８００は、サービスプロバイダ８０２にアクセストークンを発行してもよく、アクセストークンを検証すると、ユーザデータの同意された部分は、サービスプロバイダ８０２にリリースされる。要求されたユーザデータは、複数のユーザ属性を備えてもよく、複数のユーザ属性の少なくとも１つは、リリースされたユーザデータの同意された部分の一部ではない。本明細書においてさらに述べられるように、例示的な実施形態に従って、ユーザ情報エンドポイントは、デバイス８００内に存在してもよく、および、アクセストークンはこのようなユーザ情報エンドポイントにおいて受信されてもよい。アクセストークンを受信したことに応答して、デバイス８００は、ユーザデータの同意された部分をサービスプロバイダ８０２に提供してもよい。
【００５７】
８１２において、トークンは、デバイス８００上に生成されてもよい。例えば、トークンに対する要求に応答して、デバイス８００は、トークンに対する要求に従って識別トークンを生成してもよい。例示的な実施形態では、トークンは、デバイス８００内に存在する、ローカルＯＰなどの信頼された環境上にセキュアに生成されてもよい。８１２において、アクセストークンは、デバイス８００上に生成されてもよい。このようなアクセストークンは、例えばサービスプロバイダ８０２によってどの属性を取り出すことができるかを、ネットワークエンティティが判定することを可能にする情報を備えてもよい。８１４において、トークンは、サービスプロバイダ８０２に発行されてもよい。例えば、識別（ＩＤ）トークンは、例えばデバイス８００などのＵＥを介して発行されてもよく、ＩＤトークンは、サービスへのアクセスをＵＥに提供するために検証される。サービスプロバイダ８０２は、８２０において、例えばＩＤトークンなどのトークンを検証してもよい。例示的な実施形態では、サービスプロバイダ８０２は、ＩＤトークン上の署名をチェックして、トークンが有効であることを検証してもよい。検証に対する鍵マテリアルは、例えばＪＳＯＮ  Ｗｅｂ  Ｋｅｙ  ＵＲＬパラメータなどの、検出プロセスにおいてサービスプロバイダ８０２によって受信されてもよい。サービスプロバイダ８０２がＩＤトークン署名を確証した後に、サービスプロバイダ８０２は、ＩＤトークンにおいてエンコードされたフィールドをチェックして、ＩＤトークンをさらに確証してもよい。例えば「ｉｓｓ」（発行者（issuer））フィールドは、ユーザ提供識別子からＳＰが検出したＩｄＰの一意な識別子などの、トークン発行者の一意の識別子を含んでもよい。「ａｕｄ」（オーディエンス（audience））フィールドは、トークンが意図されたオーディエンスを識別してもよい。したがってオーディエンスフィールドは、サービスプロバイダ８０２のｃｌｉｅｎｔ＿ｉｄを含んでもよい。「ｅｘｐ」（失効（expires））フィールドは、それ以後にはトークンが受け入れられない満了時間を識別してもよい。満了時間での例示的な構成では、現在の時間が「ｅｘｐ」日時より後である場合は、対応するＩＤトークンは失効している。サービスプロバイダは、ＩＤトークンが失効していない場合に、それを検証および確証してもよい。
【００５８】
８１６において、例えばネットワークＩｄＰなどのユーザ情報エンドポイントは、アクセストークンが提示されてもよい。アクセストークンは、ステップ８１０からの同意情報を備えてもよい。例示的な実施形態では、サービスプロバイダ（ＳＰ）８０２は、アクセストークンを曖昧な値として扱ってもよい。このようなアクセストークンは、署名を搬送しない、曖昧ベアラトークンと称されてもよい。８１６において、アクセストークンは、ユーザ属性および／または他の情報を取り出すために、それぞれのトークンエンドポイントに向かって使用されてもよい。トークンは、例えばデバイス８００のローカルＯＰの識別子などの、デバイス８００の識別子を備えてもよい。このような識別子は、発行デバイス８００または発行ローカルＯＰの一意の識別を、ネットワークＩｄＰ８０４に通知してもよい。このようなデバイス８００の識別子、および／または、デバイス８００のローカルＯＰは、トークンの署名に含まれてもよい。識別子は、例えば８２２において、ネットワークＩｄＰ８０４が、ローカルＯＰによって発行されたトークンを認識および確証することを可能にしてもよい。識別子は、図８に示されるように少なくとも２つの異なるエンティティにおいて、トークン生成およびトークン検証が生じることを可能にしてもよい。例えば、ネットワークＩｄＰ８０４などのネットワークエンティティは、トークン検証エンドポイント８２２を介して、トークンを検証することを求められてもよい。エンドポイント８２２は、ＩＤトークンを検証するために、上述の例示的なステップに従って、アクセストークンを検証してもよい。ネットワークＩｄＰ８０４は、検証の結果をサービスプロバイダ８０２に返してもよい。サービスプロバイダ８０２がＩＤトークンを受け入れ、および、そのコンテンツを信頼する前に、成功した検証が要求されてもよい。例えば、サービスプロバイダは、トークンが検証されるまで、電子メールアドレスが現在のセッションのユーザに属することを信頼しなくてもよい。検証が成功すると、サービスプロバイダ８０２は、検証されたユーザをそのユーザデータベースに追加すること、または、それが提供するサービスへのアクセスを許可することなどを行ってもよい。
【００５９】
ローカルＯＰがトークンを発行する例示的な実施形態では、ローカルＯＰは、トークンに署名するためにシークレットを認識してもよい。例えば、ローカルＯＰは、検出プロセスにおいてＩｄＰに登録したサービスプロバイダに提供されているシークレットを認識してもよい。本明細書で述べられるように、サービスプロバイダは、チェックＩＤエンドポイントにトークン（例えばＩＤトークン）を送信してもよい。エンドポイントは、ＪＷＴエンコーディングをデコードし、および／または、署名を検証してもよい。例示的な構成では、サービスプロバイダは、チェックＩＤエンドポイント（例えば図８の８２０を参照）なしにＩＤトークンを検証してもよい。例えば、ＩＤトークンＪＷＴは、ＪＷＫ鍵で署名されてもよい。鍵は、例えば識別プロバイダでの検出プロセスの結果として、サービスプロバイダに通知されてもよい。
【００６０】
本明細書で述べられる装置の様々な実施形態は、トークンをローカルに（例えばローカルＯＰによって）生成してもよい。例えば、ローカルＯＰは、トークン署名を生成するためのシークレットを認識してもよい。例示的な実施形態では、ＨＭＡＣ署名が使用されてもよい。例えば、ローカルＯＰは、サービスに対するクライアントシークレットを備えるリストへのアクセスを有してもよい。例えばリストは、ＭＮＯによって（例えばＯＴＡチャネルを使用して）、維持、更新、および／または管理されてもよい。
【００６１】
ＨＭＡＣ署名を使用した別の実装形態に従って、ローカルＯＰは、オーディエンスフィールドを使用してもよく、および／または、ＭＮＯサービスエンドポイントに問い合わせて（例えばセキュアな通信チャネル上で）、例えばネットワークＩｄＰから対応するシークレットを取得してもよい。例えばプロバイダのＪＳＯＮ  Ｗｅｂ  ＫｅｙドキュメントのＵＲＬを問い合わせることによって、鍵の識別子を取得することができる。ローカルＯＰは、セキュアな、および／または、認証された要求を行って、鍵マテリアルを取得してもよい。要求は、例えば、通信ステップを導入することにより、および／または、ユーザ認証とは独立とすることができるプロトコル実行（例えば低使用の時点での鍵マテリアルのロード）などにより、認証の時点で発生してもよい。
【００６２】
別の例示的な実施形態では、シークレットは、共有シークレットＳおよび／またはオーディエンスフィールドコンテンツから導出されてもよい。例えば、ローカルＯＰは、クライアント鍵を計算してもよい。鍵導出関数は、ネットワークＩｄＰによって使用されて、例えばクライアントシークレットを（例えばロングタームシークレットＳに基づいて）計算してもよい。クライアントシークレットは、ローカルＯＰインスタンスと共有されてもよい。検出プロセスでは、例えばネットワークＩｄＰは、ＫＥＦを使用して、クライアントシークレットを計算してもよい。ローカルＯＰは、同一のクライアントシークレットを計算してもよい。
【００６３】
ＪＳＯＮ  Ｗｅｂ  Ｓｉｇｎａｔｕｒｅ（ＪＷＳ）は、署名されたＪＷＴに対するヘッダフィールドの使用を可能にする。例えばヘッダフィールドは、署名に対して使用されていてもよい情報などの、鍵についての情報を搬送するために使用されてもよい。「ｊｋｕ」パラメータは、公開鍵をホスティングすることができるＪＳＯＮ  Ｗｅｂ  Ｋｅｙ（ＪＷＫ）ＵＲＬを示してもよい。「ｋｉｄ」鍵ＩＤパラメータは、どの鍵が使用されていたかを示してもよい。代替的実施形態では、ヘッダは、ＵＲＬ（例えばＸ．５０９公開鍵証明書に対する）を示すことができるフィールド「ｘ５ｕ」を備えてもよい。ネットワークにおけるＯＰは、例えば、ローカルＯＰインスタンスに対する鍵および／もしくは証明書を生成してもよく、ならびに／または、ＵＲＬを提供して、例えばサービス／クライアントが公開鍵証明書を取ってもよい（fetch）。ローカルＯＰは、秘密鍵を備えてもよく、および／または、例えばＪＷＳのヘッダにおける対応する公開鍵証明書に対するＵＲＬへのポイントなどの、ＵＲＬへのポインタを備えてもよい。例示的な実施形態では、ローカルＯＰは、ＪＷＴに従ってＩＤトークンをエンコードしてもよく、署名を適用してもよく、および、ＩＤトークンをサービスプロバイダに送信してもよい。
【００６４】
ローカルＯＰは、鍵ペアを備えてもよい。例えば、秘密鍵は、セキュアに記憶されてもよい（例えばローカルＯＰに）。ネットワークＯＰは公開鍵、および、オプションとして公開鍵に対する対応する証明書を認識してもよい。ネットワークＯＰは、証明機関（ＣＡ：Certificate Authority）として動作してもよく、および、それ自体で証明書を生成してもよく、または、ネットワークＯＰは公開鍵を証明させてもよい（例えばサードパーティＣＡから）。ローカルＯＰが鍵ペアを備える例示的な実施形態では、ユーザはサービスプロバイダを訪問することを望んでもよく（例えば初めて）、および、電子メールアドレスを入力してもよい。サービスプロバイダは、ユーザ名および／もしくはＯＰホストを抽出してもよく、ならびに／または、検出および／または登録ステップを実行してもよい。例えば、サービスプロバイダ（例えばウェブサイト）は、以前にユーザおよび／またはＯＰによって参照されていなくてもよい。サービスプロバイダ（クライアント）は、ネットワークＯＰに登録してもよく、および、ネットワークＯＰは証明された公開鍵のリストを備えるＪＷＫ  ＵＲＬを提供してもよい。サービスプロバイダは、例えばＩＤトークン、および／または属性に対するアクセストークンを求める要求で、ユーザエージェント（例えばブラウザ）を承認サーバにリダイレクトしてもよい。
【００６５】
装置の内部ルーティング（internal routing）は、ユーザエージェントがローカルＯＰインスタンスに向けられる（direct）ようにしてもよい。ローカルＯＰは、ユーザをローカルに認証してもよい。例示的な実施形態では、ローカルＯＰは、要求された属性（例えばクレーム）を抽出してもよく、および／または、ユーザ属性の利用可能性をチェックしてもよい。要求された属性は、ネットワークにおいて利用可能であってもよく、または、利用可能でなくてもよい。例えば、ローカルＯＰは、ユーザ同意（承認）を取得して、アクセストークンを生成してもよい。承認は、要求された属性の少なくとも一部分へのアクセスをサービスプロバイダに与えてもよい。ユーザは、データをリリースする同意を事前に与えてもよい（例えば「ａｌｗａｙｓ  ｏｋ  ｔｏ  ｒｅｌｅａｓｅ」チェックボックスをクリックすることにより）。このような同意は、例えば今後の決定のために記憶されてもよい。ローカルＯＰは、ＩＤトークンを生成してもよく、および、例えば秘密鍵を使用することなどによって、トークンに署名してもよい。証明書のＵＲＬは、トークンのＪＷＳヘッダのｘ５ｕフィールドに置かれてもよい。ローカルＯＰは、アクセストークンを生成してもよく、および、それに署名を適用してもよい。アクセストークンは、サービスプロバイダによって曖昧な値として扱われてもよく、および、データを備えなくてもよい。アクセストークンは、回収されてもよい（例えばネットワークまたはデバイスにおけるユーザ情報エンドポイントにおいて）。同意は、トークンにおいてエンコードされてもよい。アクセストークンにおける同意決定のエンコーディングのタイプは、実装依存であってもよい。ローカルＯＰは、例えばＩＤトークンおよびアクセストークンで、ユーザエージェントをクライアントエンドポイントにリダイレクトしてもよい。ユーザエージェントをリダイレクトするＵＲＬは、初期の要求において（例えばパラメータｒｅｄｉｒｅｃｔ＿ｕｒｉ）サービスプロバイダによって提供されてもよい。サービスプロバイダは、ＩＤトークン署名自体を検証することを望んでもよい。例えば、サービスプロバイダは、例えばトークンのヘッダにおけるｘ５ｕパラメータにおいて提供されたＵＲＬなどの、ＵＲＬから公開鍵および／または証明書を要求してもよい。例示的な実施形態では、サービスプロバイダは、ＩＤトークンでＯＰのチェックＩＤエンドポイントとコンタクトしてもよい（例えばトークン検証要求に対して）。この通信は、例えば、サービスプロバイダとＯＰとの間で共有されてもよい、クライアントシークレットの使用によって保護されてもよい。チェックＩＤエンドポイントは、例えばヘッダのｘ５ｕパラメータにおいて提供されるような公開鍵を使用することなどにより、トークンヘッダから署名をチェックすることによって、トークンが、承認されたローカルＯＰインスタンスによって発行されたことを検証してもよい。チェックＩＤエンドポイントは、トークン検証の結果をサービスプロバイダに返してもよい。
【００６６】
ＩＤトークン検証の結果として、サービスプロバイダは、ユーザ識別子および／または識別子の発行者を認識してもよい。例えば、サービスプロバイダがアクセストークンを要求しない場合（例えばサービスプロバイダが、要求されたサービスへのアクセスを提供するための追加のデータを必要としない）、認証プロトコルは終了してもよく、および、サービスプロバイダは要求されたデータ／サービスをユーザに提供してもよい。アクセストークンがサービスプロバイダによって要求されており、および、アクセストークンがサービスプロバイダに発行された場合は、サービスプロバイダは、ユーザ情報エンドポイントへの要求においてアクセストークンを使用して、例えばユーザ情報（例えば属性）を取り出してもよい。例示的な実施形態に従って、アクセストークンはユーザ属性を備えてもよい。ローカルＯＰは、属性を取り出してもよく、トークンを生成してもよく、および／または、トークンを署名してもよい。例示的な実施形態に従って、サービスプロバイダは、トークン有効性を自律的に検証してもよく、および、所望の情報（例えばユーザ属性またはクレーム）を取り出してもよい。
【００６７】
ユーザ情報エンドポイントは、有効および承認されたローカルＯＰによってトークンが発行されたことを検証してもよい。エンドポイントは、要求されたデータのリリースにユーザが同意したことを検証してもよい。ローカルＯＰの有効性の検証は、アクセストークン上のＪＷＳ署名を検証することによって完了されてもよい。ユーザ同意の検証は、例えばユーザ同意に関連付けられた情報を搬送するようにアクセストークンの内部構造を変更してもよい。検証すると、ユーザ情報エンドポイントは、要求された属性をサービスプロバイダに返してもよい（例えばＪＳＯＮフォーマットにおいて）。サービスプロバイダは、ユーザのユーザプロファイルのローカルコピーを生成してもよく（例えば受信された属性を使用して）、および／または、サービスへのアクセスを提供してもよい。例示的な実施形態に従って、ユーザが再びサービスプロバイダを訪問する場合は、登録および／または検出ステップがサービスプロバイダによって実行されなくてもよい。ユーザは認証および承認を実行するように指示されてもよく、ならびに、ユーザはトークン検証の後にサービスプロバイダに直接ログインしてもよい。
【００６８】
例示的な実施形態では、秘密鍵は、セキュアな環境に存在してもよい。ローカルＯＰは、鍵ペアをセキュアな信頼された環境（例えばセキュリティモジュール、または信頼されたモジュールなど）においてローカルに生成してもよく、および、セキュアな要素において秘密鍵を記憶してもよい。ネットワークＯＰは、対応する公開鍵に対する証明書を生成してもよく、および／または、証明書（例えば要求に応じて）をサービスプロバイダに提供してもよい。本明細書で述べられるように、表記Ｋは鍵ペアを表してもよく、ｐｕ（Ｋ）は公開鍵を表してもよく、ｐｒ（Ｋ）は秘密鍵を表してもよく、および、ｃｅｒｔ（Ｋ，Ｃ）はｐｕ（Ｋ）に対する証明書を表してもよい。例えば、ｃｅｒｔ（Ｋ，Ｃ）は鍵Ｃの保有者によって発行されてもよく、および／または、鍵ｐｒ（Ｃ）を使用して生成されてもよく、および／または、ｐｕ（Ｃ）を使用して検証されてもよい。
【００６９】
セキュアな要素上へのローカルＯＰアプレットをインストールすると、例えば、アプレットはルート鍵ペアＲを生成してもよく、ｐｒ（Ｒ）をセキュアな要素に記憶してもよく、および、セキュアな要素発行者または製造業者（例えばスマートカード製造業者から）証明書ｃｅｒｔ（Ｒ，Ｉ）を取得してもよい。証明書は、発行者によって記憶されてもよく、および、セキュアな要素に記憶されてもよい。
【００７０】
例示的な実施形態に従って、ローカルＯＰは、ＯＰサーバ機能（ＯＰＳＦ：OP Server Function）のドメインに登録（enroll）されてもよい。この登録は、例えばモバイルデバイス上のローカルＯＰアプリケーションがインストールされたとき、または最初に開始したときにトリガされてもよい。ＯＰＳＦは、ローカルＯＰによって使用されてもよい登録エンドポイントを提供して、例えば新しい鍵ペアをＯＰＳＦに登録してもよい。
【００７１】
ローカルＯＰは、ＯｐｅｎＩＤアプリケーション固有の鍵ペアＯ１を生成してもよく、ｃｅｒｔ（Ｏ１，Ｒ）を生成することができ（例えばｐｒ（Ｒ）を使用してｐｕ（Ｏ１）を署名してもよい）、ｃｅｒｔ（Ｏ１，Ｒ）およびｃｅｒｔ（Ｒ，Ｉ）をＯＰＳＦの登録エンドポイントに提出してもよい。登録エンドポイントは、ｃｅｒｔ（Ｒ，Ｉ）をチェックして、例えば、ローカルＯＰが信頼できる発行者によって生成および発行されたことを検証してもよい。例えば、検証は、発行者鍵Ｉに対する証明書をチェックすることを備えてもよく、および、ＯＣＳＰチェックを備えてもよい（例えば、証明書が有効かを判定してもよい）。ＯＰＳＦ登録エンドポイントは、ｃｅｒｔ（Ｏ１，Ｒ）をチェックして、鍵ｐｕ（Ｏ１）がローカルＯＰインスタンスによって生成されたことを検証してもよい。
【００７２】
ローカルＯＰは、鍵を使用して、トークン署名を生成してもよい。例えばＯＰＳＦは、証明書（例えばチェーン）を、ＲＰに（例えば証明書エンドポイントにおいて）利用可能にしてもよい。ＯＰＳＦは、証明書およびその証明書チェーンを記憶してもよい。例示的な実施形態に従って、証明書エンドポイントにおいて、証明書が利用可能であってもよい。代わりに、ＯＰＳＦは、ｃｅｒｔ（Ｏ１，Ｐ）とすることができるＯ１に対する証明書を生成してもよい。ＯＰＳＦは、証明書エンドポイントにおいて証明書ｃｅｒｔ（Ｏ１，Ｐ）を利用可能にしてもよい。様々な実施形態では、ＯＰＳＦは、証明書エンドポイントにおける証明書のＵＲＬをローカルＯＰに返してもよい（例えば暗号化および／または署名されてもよい）。ＯＰＳＦは証明書にわたって適用（apply across certification）してもよく、したがってＯＰＳＦドメインＰＫＩをセキュアな要素発行者ドメインと統合してもよい。
【００７３】
ローカルＯＰは、本明細書で述べられるようにトークンヘッダに、証明書（例えば、使用される方法に依存してもよいｃｅｒｔ（Ｏ１，Ｒ）および／またはｃｅｒｔ（Ｏ１，Ｐ））に対するＵＲＬ（例えば受信された）を含めてもよい。例えばローカルＯＰは、ｐｒ（Ｏ１）鍵を使用して、トークン署名を生成してもよい。
【００７４】
ローカルＯＰは、署名鍵Ｏ１および／または証明書を更新することが必要になることがある。例えば、証明書の有効性は、鍵を使用することができるときにチェックされてもよい。更新プロセス（renewal process） は、満了日が近付いたときにトリガされてもよい。
【００７５】
署名鍵Ｏ１は、新たに生成された鍵ペアＯ２と置き換えられてもよい。例えば新たな公開検証鍵は、ＯＰＳＦドメインに登録されてもよい。古い検証鍵は利用可能のままであってもよい（例えば移行期間の間、その古いＵＲＬにおいて）。例示的な実施形態では、クライアントは、トークン署名検証に対して鍵を使用してもよい。ＯＰＳＦは、最後に発行されたＩＤトークンの有効期間を認識してもよく、および、古い証明書（例えばｃｅｒｔ（Ｏ１，Ｒ）またはｃｅｒｔ（Ｏ１，Ｐ））は、有効期間の間に利用可能であってもよい。有効期間が認識されない場合は、例えばエンティティは、古い証明書が利用可能のままである移行期間に対する最小継続時間について合意してもよい。ＯＰＳＦは、証明書を生成してもよく、以前のｃｅｒｔ（Ｏ１，Ｐ）を生成してもよく、および、ｃｅｒｔ（Ｏ２，Ｐ）を生成してもよい。新たな鍵ペアＯ２は、古い鍵ペアＯ１を使用して登録されてもよく（例えば登録においてｃｅｒｔ（Ｏ２，Ｏ１）が使用されてもよい）、および、鍵のチェーン（例えば鍵履歴）が構築されてもよい。古い／以前の／失効した署名鍵は削除されてもよい。
【００７６】
登録の別の例示的な実施形態では、ローカルＯＰは、例えばプロトコルフローにおいて動的に鍵ペアを生成してもよい。例えば、ローカルＯＰおよびＯＰＳＦは、ロングタームシークレット（ＫＬ）を共有してもよい。鍵ペアは、生成されてもよく、ならびに／または、ＯＰＳＦに通知されてもよいランダムシード値（random seed value）および／もしくはロングターム共有シークレットに基づいてもよい。ランダムシードはＯＰＳＦに渡されてもよく、および、ＯＰＳＦは鍵を再計算してもよい。秘密鍵は、ローカルＯＰおよびネットワークで利用可能であってもよい。
【００７７】
本明細書で述べられるように、ローカルＯＰは、トークン要求メッセージを受信してもよく、および、トークン署名を生成してもよい。ローカルＯＰは、例えばトークン署名が生成されるときに、ランダムシード値Ｓを生成してもよい。ローカルＯＰは、例えばＳおよびロングタームシークレットＫＬに基づいて、新たな鍵ペアを計算してもよい。トークンを署名するために使用することができる公開鍵、および、トークンヘッダのｘ５ｔＵＲＬパラメータは、動的ＵＲＬに（例えばＯＰＳＦの証明書エンドポイントにおいて）設定されてもよい。動的ＵＲＬは、シードＳをパラメータ（例えばｈｔｔｐ：／／ｏｐｓｆ．ｏｒｇ／ｃｅｒｔ．ｐｈｐ？ｓｅｅｄ＝１２３４）として備えてもよい。証明書エンドポイントは、例えば受信されたパラメータＳおよび／またはロングタームシークレットＫＬに基づいて、ローカルＯＰが計算した鍵ペアを計算してもよい。証明書エンドポイントは、公開鍵に対する証明書を生成してもよい。ＯＰＳＦは、秘密鍵を削除してもよく、および／または、動的ＵＲＬ（例えばｈｔｔｐ：／／ｏｐｓｆ．ｏｒｇ／ｃｅｒｔ．ｐｈｐ？ｓｅｅｄ＝１２３４）において公開鍵証明書を提供してもよい。クライアントがトークンを受信し、および、ＵＲＬ（例えばｈｔｔｐ：／／ｏｐｓｆ．ｏｒｇ／ｃｅｒｔ．ｐｈｐ？ｓｅｅｄ＝１２３４）を問い合わせる場合は、ＯＰＳＦは正確な鍵ペアを生成してもよく、および、証明書をクライアントに提供してもよい。例えば鍵および／または証明書がすでに生成されている場合は、ＯＰＳＦは証明書をクライアントに直接提供してもよい。
【００７８】
図９は、事前に確立された共有シークレットＳを認証サーバ９０６と共有する、ローカルＯＰ９００での例示的なプロトコルフローのフローチャートを示す。例示的なシナリオでは、ローカルＯＰは、ＩＤトークン上に非対称署名を生成するために使用されてもよい秘密鍵を備えなくてもよい。例えばＨＭＡＣ署名が、トークン署名に対して使用されてもよい。代替の例示的なシナリオでは、認証サーバ９０６などのネットワークＯＰとクライアント（例えばサービスプロバイダ９０４）との間で確立された鍵は、例えばトークン署名の生成に使用されてもよく、それによりクライアントは署名を自律的に確証することができる。
【００７９】
図９を参照すると、９０８において、ユーザは、ＵＥのブラウザ９０２を介して、サービスプロバイダ９０４によって提供されるサービスへのアクセスを要求してもよい。９０８において、ブラウザ９０２は、例えばＯｐｅｎＩＤ識別子などの識別子をサービスプロバイダ９０４に提供してもよい。サービスプロバイダ９０４は、ＩＤトークンおよびアクセストークンに対する要求を備えることができる承認要求を準備してもよく、ならびに、サービスプロバイダ９０４は、９１０において、リダイレクトメッセージ９１０を介して要求をブラウザ９０２に送信してもよい。９１０における要求は、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルに従って、ＩＤトークンに対する要求を含んでもよい。９１０における要求は、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルに従って、アクセストークンに対する要求を含んでもよい。例えば、アクセストークンは、サービスプロバイダ９０４がＵＥのユーザの属性を取り出すことができるように、サービスプロバイダ９０４によって要求されてもよい。９１２において、要求は、例えばリダイレクトメッセージを介してＵＥ上のブラウザ９０２から、ローカルＯＰ９００などのＵＥ上の信頼されたモジュールに転送されてもよい。９１４において、ＵＥのユーザは、ローカルＯＰ９００によって認証されてもよい。９１６において、ユーザは、ＵＥに対して、サービスプロバイダ９０４にトークンを発行することの同意（認可）を与えてもよい。例えば、承認要求は、ＵＥのユーザによって認可されてもよい。さらにＵＥにおいて承認要求に応答して、承認要求のユーザ認可に関連付けられたアクセストークンが生成されてもよい。例示的な実施形態では、承認要求のユーザ認可は、ＵＥ上に記憶されたポリシーを介して自動的に受信されてもよい。
【００８０】
図９をさらに参照すると、９１８において、トークンがローカルＯＰ９００において生成されてもよい。情報がトークンに追加されてもよい。例えばトークンへの拡張は、トークンのＪＳＯＮデータ構造に情報を追加してもよい。例示的な実施形態では、トークンは、
{
"iss": (例えば、http://server.example.com)
"user_id": (例えば、248289761001)
"aud": (例えば、http://client.example.com")
"exp": (例えば、1311281970)
"lop_id": (例えば、11223344556677などのローカルＯＰに対する識別子を表してもよい)
"timestamp" : (例えば、20111012143815ZなどのYYYYMMDDhhmmss[.s...]Zのフォーマットで時間タイムスタンプを表してもよい)、 および／または、
"lop_sig": (例えば、572400e4ec56fdce9549777bf67d70041f53a6aaなどのHMACSHA1({lop_id|timestamp})を使用した署名を表してもよい)
}
を備えてもよい。
【００８１】
例えば、９１８において、共有シークレットＳを鍵として使用して、ＨＭＡＣ＿ＳＨＡ１署名が計算されてもよい。署名はローカルＯＰ  ＩＤ、および／またはユーザ認証のタイムスタンプの連結上で（on the concatenation）計算されてもよい。別の例示的なトークンでは、データは、以下に示されるように、例えば、ローカルＯＰフィールドのグループを生成することによって、ＪＳＯＮに従って構成されてもよい。
{
"iss": (例えば、http://server.example.com)
"user_id": (例えば、248289761001)
"aud": (例えば、http://client.example.com)
"exp": (例えば、1311281970)
"local_openid": {
"lop_id": "(例えば、11223344556677などのローカルＯＰに対する識別子であってもよい)
"timestamp": "(例えば、20111012143815Z)、 および／または、
"lop_sig": (例えば、572400e4ec56fdce9549777bf67d70041f53a6aaなどのHMAC SHA1({lop_id|timestamp})を使用した署名であってもよい)
}
}
【００８２】
示されたように、コンテンツがＩＤトークンに追加されてもよく、および、有効なＨＭＡＣ  ＳＨＡ１署名が生成されてもよい。例えば署名に使用することができる鍵は、クライアントシークレットであってもよい。情報がＪＳＯＮトークンに追加されてもよく、および／または、その内部構造が変更されてもよい。例示的な実施形態に従って、サービスプロバイダは、トークンにおける追加のフィールドを無視してもよく、および／または、サービスプロバイダはトークンを曖昧な値として扱ってもよい。
【００８３】
本明細書で述べられるように、トークン署名を生成することができる鍵は、クライアントシークレットであってもよい。例えば、クライアントシークレットは、例えば登録プロセスにおいて、クライアント（サービスプロバイダ）と、認証サーバ（ＯＰＳＦ）との間で確立されてもよい。認証サーバは、ローカルＯＰにクライアントシークレットのリストを提供して、ローカルＯＰが正確なトークン署名を生成することを可能にしてもよい。例えば、認証サーバは、オーバージエア管理方法（over the air management method）を使用して、ローカルＯＰインスタンスにクライアントシークレットのリストをインストールしてもよい。新たなクライアントシークレット（例えば新たなクライアントおよび／または既存のクライアントに対する）が登録されるときは、ローカルＯＰにおけるリストが更新されてもよい。例えば、クライアントのＵＲＬとすることができる、トークン要求におけるオーディエンスパラメータは、トークンを要求しているクライアントを識別してもよい。オーディエンスパラメータは、例えばローカルＯＰ記憶装置において対応するクライアントシークレットをファインドする（find）ために、ローカルＯＰによって使用されてもよい。
【００８４】
別の例示的な実施形態では、クライアントシークレットは、認証サーバから問い合わされてもよい。例えば、ローカルＯＰは、トークンに対する有効なＨＭＡＣ署名を生成するために、クライアントシークレットを知るようになってもよい。ローカルＯＰがクライアントシークレットを認識するために、認証サーバは、要求をすると、ローカルＯＰにクライアントシークレットを提供してもよい。このような提供において、ローカルＯＰは、トークン要求において受信されてもよいオーディエンスパラメータからクライアント名を抽出してもよい。ローカルＯＰは、例えば特定のエンドポイントにおいて、認証サーバへの、認証および／またはセキュアな接続を確立してもよい。ローカルＯＰは、クライアントに対してクライアントシークレットを要求してもよい。クライアントシークレットは、署名を生成するために使用されてもよい。例えば、認証サーバは、クライアントシークレットエンドポイントｈｔｔｐｓ：／／ｏｐ．ｏｒｇ／ｃｌｉｅｎｔｓ．ｐｈｐを提供してもよい。このようなクライアントシークレットエンドポイントは、ＴＬＳ暗号化を使用してもよく、および／または、認証されてもよい。実施形態に従った例示的プロトコル実行では、トークン署名を生成する前に、ローカルＯＰは、例えばクライアントシークレットエンドポイントに接続してもよく、クライアントシークレットエンドポイントに認証してもよく、および、ｈｔｔｐｓ：／／ｏｐ．ｏｒｇ／ｃｌｉｅｎｔｓ．ｐｈｐ？ｃｌｉｅｎｔ＿ａｕｄｉｅｎｃｅ＝ａｕｄｉｅｎｃｅなどのリソースを要求してもよい。例示的なリソースでは、オーディエンスは、受信されたオーディエンスフィールドからのコンテンツに等しくてもよい。クライアントシークレットエンドポイントは、ローカルＯＰにクライアントシークレットを返してもよい。次いでローカルＯＰは、シークレットを使用して、有効な署名を生成してもよい。
【００８５】
さらなる別の例示的な実施形態では、クライアントシークレットは、認証サーバおよびローカルＯＰにおいてロングタームシークレットから導出されてもよい。例えば、クライアントシークレットは、例えばクライアントとネットワークＯＰとの間の登録プロセスにおいて確立されてもよい。本明細書で述べられる実施形態に従って、ローカルＯＰおよびネットワークＩｄＰ／ＯＰ（認証サーバ）は、ロングタームシークレットを共有してもよい。本明細書では、ロングターム共有シークレットを生成するための様々な方法が示される。例えばロングターム共有シークレットは、ローカルＯＰアプリケーションに埋め込まれてもよい（例えばインストールにおいて）。ロングターム共有シークレットは、ＭＮＯのＯＴＡ管理動作を介して生成されてもよい。ロングターム共有シークレットは、例えばネットワーク認証プロトコル実行からの鍵導出によって生成されてもよい。共有シークレットは、ネットワークＩｄＰ／ＯＰ（認証サーバ）と、デバイス／ローカルＯＰとの間のトラストアンカ（trust anchor）として動作してもよい。シークレットは、例えばＳＩＭカードおよび／または埋め込み型セキュリティ要素などの、セキュアな要素のセキュリティ機能によってローカルＯＰ内で保護されてもよい。
【００８６】
クライアントの例示的な登録プロセスでは、認証サーバは鍵導出関数（ＫＤＦ：key derivation function）において、クライアントからオーディエンスパラメータとともに、ロングタームシークレットを使用してもよい。例えば、ネットワークＯＰは、クライアントシークレット＝ＫＤＦ（オーディエンス、ロングタームシークレット）となるように、クライアントシークレットを導出してもよい。例示的な認証プロトコル実行では、ローカルＯＰは、トークン要求ヘッダからオーディエンスフィールドを読み出してもよく、および、同一のＫＤＦをオーディエンスフィールドおよびロングタームシークレットに適用して、クライアントシークレットを計算してもよい。次いでクライアントシークレットは、トークン署名を生成するために使用され得る。
【００８７】
図９を再び参照すると、９１０において、承認要求は、例えばアクセストークンなどのトークンに組み込まれてもよい。クライアント（例えばサービスプロバイダ９０４）からの元の承認要求は、トークンに組み込まれて、例えば発行されたアクセストークンが、要求されたリソースに対して回収されることを確実にしてもよい。例示的なシナリオでは、ローカルＯＰ９００は、ローカルトークン生成プロセスにおいて、データへのアクセスを承認してもよく、および、データはネットワークによって、または、ローカルＯＰ９００によってローカルに提供されてもよい。例示的なシナリオでは、要求は、例えばネットワークに向かってトークンを使用しているときに、変更されてもよい。トークンは、ネットワークへの承認要求についての情報を備えてもよい。例えば、承認要求は、リダイレクトメッセージを介して、サービスプロバイダから承認サーバ／ＯＰ９０６に送信されてもよい。ローカルＯＰ９００が本明細書で述べられるように使用されるときは、９１０および９１２において、承認要求は、リダイレクトを介して、ローカルＯＰ９００に送信されてもよい。サービスプロバイダ９０４は、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔスコープ（OpenID Connect scopes）を使用して、アクセス特権がアクセストークンに対する承認要求において要求されたことを特定してもよい。例えば、アクセストークンに関連付けられたスコープは、例えば利用可能となってもよいリソースを、それらがＯＡｕｔｈ２保護エンドポイント（OAuth 2 protected endpoints）にアクセスするのに使用されるときに、判定してもよい。
【００８８】
例示的なスコープは、クライアントがＯｐｅｎＩＤ要求を作成していることがあることを承認サーバに通知することができる、ＯｐｅｎＩＤスコープを含む。例示的な構成では、ＯｐｅｎＩＤスコープが指定されない場合は、承認サーバは、要求を一般的なＯＡｕｔｈ２．０要求として扱ってもよく、および、ＯｐｅｎＩＤ処理を実行しなくてもよい。プロファイルスコープは、例えば、デフォルトのプロファイル情報を要求してもよい。電子メールスコープは電子メールアドレスを要求してもよい。アドレススコープはアドレスを要求してもよい。
【００８９】
スコープパラメータに加えて、承認要求は、クライアント（例えばサービスプロバイダ９０４）が要求構造を構築することを可能にすることができる、ＯｐｅｎＩＤ要求オブジェクトを備えてもよい。例えば、ＯｐｅｎＩＤ要求オブジェクトは、エンコードされたＪＷＴとして、および／またはＯｐｅｎＩＤ要求オブジェクトを示すことができるＵＲＬとして渡されてもよい。
【００９０】
以下は、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルにおいて実施されてもよい、ＪＷＴエンコーディングの前のＯｐｅｎＩＤ要求オブジェクトの例である。
【００９１】
【数３】
2015511348.tif 000005
【００９２】
以下は、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルにおいて実装されてもよい、エンコードされたＪＷＴの例である。
JWT algorithm = HS256
HMAC HASH Key = 'aaa' (例えば、これはＪＷＴを署名する鍵のｉｄであってもよい)
JSON Encoded Header = "{"alg":"HS256","typ":"JWT"}"
JSON Encoded Payload = "{"response_type":"code id_token",
"client_id":"s6BhdRkqt3",
"redirect_uri":"https://client.example.com/cb",
"scope":"openid profile",
"state":"af0ifjsldkj",
"userinfo":{"claims":{"name":null,"nickname":{"optional":true},
"email":null,"verified":null,
"picture":{"optional":true}},"format":"signed"},
"id_token":{"max_age":86400,"iso29115":"2"}}"
【００９３】
【数４】
2015511348.tif 000006
【００９４】
以下は、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルに従って実装されてもよい、承認要求の例である。
【００９５】
【数５】
2015511348.tif 000007
【００９６】
図９を再び参照すると、例えば本明細書に示される承認要求などの承認要求は、ＨＴＴＰリダイレクトを介して、ローカルＯＰに送信されてもよい（例えば図９における９１０および９１２を参照）。ローカルＯＰ９００は、要求が有効であることをチェックしてもよく、および／またはユーザを認証してもよい。ローカルＯＰ９００は、９２０および９２２においてリダイレクトメッセージを介してサービスプロバイダ９０４に発行することができるトークンを生成してもよい。サービスプロバイダ９０４は、トークンを使用して、例えばＩＤトークンエンドポイント９２６および／またはユーザ情報エンドポイント９２８からデータを取得してもよい。
【００９７】
例示的な実施形態では、それぞれトークンエンドポイント９２６および９２８への要求９２４および９３０は、元の要求オブジェクトを備えなくてもよい。このような要求（例えば要求９２４および９３０）では、トークンは、例えばトークンエンドポイント９２６および９２８によって受信されてもよく、ならびに、情報がサービスプロバイダ９０４によって要求されたこと、および、情報がサービスプロバイダ９０４によってアクセスされるように承認されることのインジケーションは存在しなくてもよい。このような要求では、ローカルＯＰ９００は、ＪＷＴエンコード要求をトークンに、それがサービスプロバイダ９０４に発行する前に追加することによって、要求された情報をトークンエンドポイントに搬送してもよい。例えば、トークンは、要求情報を搬送してもよく、および、要求情報はトークンエンドポイントによって評価されてもよい。要求ＪＷＴは、例えば、ローカルＯＰ９００によって署名されて、例えばユーザの承認の後に、サービスが要求を変更することができる攻撃（attack）などの、攻撃を防止してもよい。トークン署名は、９３２および９３４において、共有シークレットＳを使用して、それぞれのエンドポイントにおいて検証されてもよい。ＩＤトークン署名が検証された後に、９３６において、ユーザの認証情報（例えばユーザ識別子）は、サービスプロバイダ９０４に提供されてもよい。アクセストークン署名が検証された後に、サービスプロバイダ９０４によって要求されたユーザ属性またはユーザクレームなどの、ユーザのプロファイル情報は、９３８において、サービスプロバイダ９０４に提供されてもよい。要求情報を備えるトークンの例は、以下に提供される。
{
"iss": "http://server.example.com",     //ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔにおいて実装されてもよい
"user_id": "248289761001",             //ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔにおいて実装されてもよい
"aud": "http://client.example.com",    //ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔにおいて実装されてもよい
"exp": 1311281970,                    //ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔにおいて実装されてもよい
"local_openid": {
"lop_id": "11223344556677",         //ローカルＯＰに使用される識別子であってもよい
"timestamp": "20111012143815Z",                   //'YYYYMMDDhhmmss[.s...]Z'
"request":
"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF90b2tlbiIsImNsa
WVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOiJodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29t
XC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwidXNlcmluZm8iOns
iY2xhaW1zIjp7Im5hbWUiOm51bGwsIm5pY2tuYW1lIjp7Im9wdGlvbmFsIjp0cnVlfSwiZW1haWwiOm51bGwsIn
ZlcmlmaWVkIjpudWxsLCJwaWN0dXJlIjp7Im9wdGlvbmFsIjp0cnVlfX0sImZvcm1hdCI6InNpZ25lZCJ9LCJpZ
F90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiaXNvMjkxMTUiOiIyIn19.2OiqRgrbrHkA1FZ5p_7bc_RSdTbH-woAgk-ZRpD3wY",
"lop_sig": "a0a52ecf404981d579dab41439b10e0cdfb48f91"
// HMAC SHA1({lop_id|timestamp|request})を使用した署名であってもよい
}
}
【００９８】
上記の例示的なトークンを参照すると、署名ｌｏｐ＿ｓｉｇは、連結されたｌｏｐ＿ｉｄ、タイムスタンプ、および要求を通して計算されてもよい。トークンは、ローカルＯＰによって署名されて、例えば、それにより署名は、サービスプロバイダおよび／または識別プロバイダのトークンエンドポイントによって検証されるようになってもよい。例示的な実施形態に従って、承認コードは要求情報を備えてもよい。
【００９９】
本明細書で述べられるように、ユーザデータ（例えば、属性）は、ユーザ情報エンドポイントにおいて記憶されてもよい。このようなユーザ情報エンドポイントは、ネットワークエンティティ、またはクラウド上などに存在してもよく、および、ユーザデータはネットワークまたはクラウドからアクセスされてもよい。図１０は、ユーザ情報エンドポイントがＵＥ上にローカルに存在する、別の例示的な実施形態に従ったコールフローを示す。機密情報などのユーザデータは、ＵＥ１０００、ＵＥ１０００内のＵＩＣＣ、またはＵＥ１０００内に存在する信頼されたモジュール１００２などにローカルに記憶されてもよい。ローカルに記憶されたユーザデータの承認および転送を可能にする機構が提供される。図示の実施形態に従って、ユーザ情報エンドポイントは、信頼されたモジュール１００２上に位置してもよい。
【０１００】
例示的なシナリオでは、例えばユーザは、ユーザのソーシャルセキュリティ番号（ＳＳＮ：social security number）などの特定の機密情報が、ＵＥ１０００上にローカルに記憶されることを望んでもよい。このようなローカルに記憶された情報は、ネットワーク／クラウドにおいてではなく、セキュアな／信頼されたハードウェアモジュール１００２またはＵＩＣＣ上に記憶されてもよい。例えばＯＰ／ＯＰＳＦ、およびＵＥ内のユーザなどの複数の関係者（stakeholders）によって管理および構成されてもよいローカルポリシーは、ＵＥ１０００に記憶された機密情報の、サービスプロバイダＲＰ／クライアント１００６へのリリースを承認してもよい。
【０１０１】
例えば、ユーザは、ネットワークまたはクラウド上に記憶された機密情報のセキュリティおよび／またはプライバシについて確信（confident）していないことがある。このような情報は、例えばユーザのソーシャルセキュリティ番号を含んでもよい。ユーザは、この情報をＵＥ上に記憶することによって、プライベートに保つことを選択してもよい。例示的な構成では、ユーザは、いくつかのユーザ属性（例えば名前、または住所など）をネットワーク上に記憶してもよく、一方、他のユーザ属性（例えばＳＳＮ、または生年月日など）はＵＥのセキュアな環境にローカルに記憶される。ユーザが金融機関のサービスを得ることを望む例示的なシナリオでは、機関は、金融機関によって提供されるサービスにユーザがアクセスするために、ユーザのＳＳＮを要求することがある。ネットワークベースおよび／またはローカルとすることができる認証が成功した後に、例えば、ＵＥ上のポリシーは、ローカルに記憶されたＳＳＮをその金融機関にリリースすることを承認してもよい。ＳＳＮがローカルに記憶されるこのような例示的なシナリオでは、他のユーザ情報、例えば非機密ユーザ属性は、機関によってネットワーク／クラウドから取得されてもよい。
【０１０２】
図１０を参照すると、１０１０において、ブラウザエージェント（ＢＡ）１００４は、ユーザ識別子を、ＳＰ／クライアント／ＲＰ１００６に送信してもよく、および、ＲＰ１００６によって提供されるサービスへのアクセスを要求してもよい。１０１２において、ＲＰ１００６は、承認要求を構築してもよく、および、承認要求でＢＡ１００４を、信頼されたモジュール１００２にリダイレクトしてもよい（１０１４において）。１０１６において、ＵＥ１０００のユーザは、ＵＥ１０００において認証されてもよい。１０１８において、ＵＥは、少なくとも１つのトークンをＲＰ１００６に発行することの、ユーザ同意／承認を有していると判定してもよい。１０２０において、信頼されたモジュール１００２（例えばローカルＯＰ）は、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルに従って、トークンを生成してもよい。信頼されたモジュール１００２は、１０２０において、トークンを署名してもよい。トークンヘッダは、ヘッダを備えるトークンがローカルに生成されたことを判定するためのＯＰ１００８に対するインジケータを備えてもよい。１０２２において、信頼されたモジュール１００２は、署名されたトークンを備えるリダイレクトメッセージをＢＡ１００４に渡してもよく、これは１０２４において、ＢＡ１００４をＲＰ１００６にリダイレクトすることができる。署名されたトークンの１つまたは複数は、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルに従って、フォーマットされてもよいアクセストークンを備えてもよい。例えば、１０２０において、アクセストークンは、信頼されたモジュール１００２を介して、ＯＰ１００８などのネットワークエンティティの知識を有して、または、有さずに、ＵＥ１０００上にローカルに生成されてもよく、ならびに、ステップ１０２２および１０２４において、ＳＰ／クライアント／ＲＰ１００６に送信されてもよい。特定のユーザデータまたはユーザデータのクラスに関連付けられたアクセストークンは、アクセストークンに関連付けられたユーザ情報エンドポイントの位置に対応する位置（例えばＵＲＬ）に固定（be bound）されてもよい。例示的な構成では、ユーザデータ（例えば属性）は、機密または非機密として分類されてもよく、ならびに、機密データは、ＵＥ１０００上にローカルに存在するユーザ情報エンドポイントからアクセスされてもよく、および、非機密データは、ネットワーク上に存在するユーザ情報エンドポイントにおいてアクセスされてもよい。
【０１０３】
図１０を続けて参照すると、１０２６において、ＲＰ１００６は、ＩＤトークンを備えることができる有効とされた（validate）トークン要求メッセージで、ＯＰ１００８におけるチェックＩＤエンドポイント１０２８とコンタクトしてもよい。１０３０において、チェックＩＤエンドポイント１０３０は、本明細書で述べられるようにトークン署名Ｓを検証してもよい。１０３２において、チェックＩＤエンドポイント１０２８は、ユーザの認証情報をＲＰ１００６に返してもよい。アクセストークンが要求および発行された場合は、例えば、１０３４において、クライアント１００６は、要求されたアクセストークンを使用してユーザデータを要求してもよい。例えば、アクセストークンは、ユーザ情報エンドポイント１０３６をホスティングする信頼されたモジュール１００２の位置などの、ユーザ情報エンドポイント１０３６の位置についての情報を搬送してもよい。代わりに、ユーザ情報エンドポイントの位置情報は、例えばアクセストークンの一部となる代わりに、１０２４において、リダイレクトメッセージの一部として搬送されてもよい。１０３４において、ＲＰ１００６は、例えば、本明細書で述べられるようにアクセストークンを使用することによって、ＵＥ１０００上にローカルに存在することができるユーザ情報エンドポイント１０３６からユーザデータを要求してもよい。１０３８において、信頼されたモジュール１００２上に存在することができるユーザ情報エンドポイント１０３６は、要求されたユーザデータ（例えば、ソーシャルセキュリティ番号、住所など）を返してもよい。例示的な実施形態では、ＵＥ１０００は、ユーザデータがＲＰ１００６によって受信された後に、クライアント１００６によって提供されるサービスへの完全なアクセスを受信してもよい。
【０１０４】
本明細書で述べられる別の例示的な実施形態では、アクセストークンは、ネットワーク／クラウドにおいて生成されてもよい。例えば、ネットワークエンティティは、ＵＥの代わりにアクセストークンを生成してもよく、および、トークンは、ＳＰ／クライアント／ＲＰに送信されてもよい。アクセストークンは、ユーザ情報エンドポイントの位置（例えば、ＵＲＬ）についての情報を搬送してもよく、および、位置はネットワーク／クラウドにおけるエンティティ、または、ＵＥ上もしくはＵＥ内の信頼されたモジュール内のユーザ情報エンドポイントに対応してもよい。ユーザ情報エンドポイント位置情報は、アクセストークンのメッセージ本体内で搬送されてもよい。
【０１０５】
例示的な実施形態に従って、トークンでアクセス可能な情報は、場合によってはＩＤプロバイダまたはネットワーク／クラウドエンティティの知識なしに、ＵＥ上に存在してもよい。代わりに、それぞれのトークンでアクセス可能な情報は、ネットワーク／クラウド上に存在してもよい。トークンにおける情報は、盗聴（eavesdropping）からトークンデータを保護するために署名および／または暗号化されてもよい。このような情報は、トークン情報を取得するために復号されてもよい。このような対策は、正確な鍵を有する正当なＳＰ／クライアント／ＲＰのみがトークンを取得できることを確実にすることができる。トークンがＳＰ／クライアント／ＲＰによって復号されると、ＳＰ／クライアント／ＲＰは、トークンをユーザ情報エンドポイントに提示してもよい。ＵＥもしくはＵＥ上の信頼されたモジュール、および／またはネットワーク／クラウドエンティティは、トークンを生成および／または検証し、ならびに、要求されたデータをＳＰ／クライアント／ＲＰに提供してもよい。情報要素はネットワークとＵＥとの間で配布されてもよく、または、ネットワークとＵＥとの間で共通もしくは同期されてもよい。
【０１０６】
例えば、ユーザデータは、ＵＥ上（例えばＵＩＣＣ上、または信頼されたモジュール上など）にローカルに記憶されてもよく、ユーザデータは、ネットワークエンティティ上（例えばＯＰ上など）に記憶されてもよく、および、ユーザデータは、それらの任意の適当な組み合わせに記憶されてもよい。図１１は、例示的な実施形態に従った、一部のユーザデータがローカルに記憶され、および、一部のユーザデータがネットワークエンティティ上に記憶されるコールフローを示す。図１１を参照すると、図１０にもあるステップ番号は、図１０に関連して上記で述べられている。例示的な構成では、機密データとして適格な（be qualified）ユーザデータは、ローカルに記憶されてもよく、および、非機密データとして適格なユーザデータは、ネットワーク／クラウドエンティティ上に記憶されてもよい。代替の構成では、データは分類されないが、ローカルに記憶されてもよく、データは、ネットワークエンティティ上に記憶されてもよく、または、データはそれらの組み合わせ上に記憶されてもよい。
【０１０７】
ＩＤトークンのユーザ認証および検証に成功すると、ＲＰ１００６は、１１００および１１０６において、ユーザデータ（例えばユーザ属性）を要求してもよい。例えば、１１００において、ＲＰ１００６は、第１のアクセストークンを使用して、信頼されたモジュール１００２においてＵＥ１０００内に存在するユーザ情報エンドポイント１１０２から、ユーザデータを取り出してもよい。このようなユーザデータは、機密データとして分類されていてもよい。第１のアクセストークンは、ユーザ情報エンドポイント１１０２の位置情報を備えてもよい。１１０４において、例えば機密ユーザデータは、ＲＰ１００６に提供されてもよい。１１０６において、ＲＰ１００６は、第２のアクセストークンを使用して、例えばＯＰ１００８などのネットワークエンティティ上のユーザ情報エンドポイント１１０８から、ユーザデータを取り出してもよい。このようなユーザデータは、非機密データとして分類されていてもよい。第２のアクセストークンは、ＲＰ１００６がユーザ情報エンドポイント１１０８からユーザデータを回収するために、ユーザ情報エンドポイント１１０８の位置情報（例えばＵＲＬ）を備えてもよい。機密データに関連付けられ、および、ＵＥ１０００内の記憶装置からデータを取得するために使用される第１のアクセストークンは、ローカルＯＰ（例えば、ＵＥ１０００の信頼されたモジュール１００２）によって提供されてもよい。ユーザ情報エンドポイント１１０２の位置（例えば、ＵＲＬ）はまた、ＵＥ１０００のローカルＯＰによって提供されてもよい。例示的な実施形態では、例えば機密および非機密データなどのデータがＲＰ１００６によって取得された後に、それがＲＰ１００６において組み合わされ、および、ＲＰ１００６によって提供されるサービスへのアクセスをＵＥ１０００に提供するために使用されてもよい。データはＲＰ１００６において組み合わされ、および、消費されてもよい。
【０１０８】
したがって本明細書で述べられるように、各アクセストークン、またはユーザデータの各クラス（例えば機密、非機密、センシティブ、または一般など）は、ユーザデータの位置に関連付けられてもよい。ユーザデータの位置は、ＵＥ、もしくはＵＩＣＣなどの信頼されたモジュールの位置（例えば、ＵＥ／ＵＩＣＣへのＵＲＬ）、ネットワーク／クラウドにおける位置（例えば、ネットワーク／クラウド内のエンティティへのＵＲＬ）、またはそれらの組み合わせに対応してもよい。したがって様々な位置に記憶されたユーザ属性は、ＳＰ／クライアント／ＲＰによって要求され、処理され、組み合わされ、および消費されてもよい。
【０１０９】
例として、ＵＥ１０００は、承認要求を受信して、ＲＰ１００６などのサービスプロバイダに対するアクセストークンを生成してもよい。ＵＥでは承認要求に基づいて、第１のアクセストークンが生成されてもよく、および、第２のアクセストークンが生成されてもよい。アクセストークンは、ＲＰ１００６によって提供されるサービス、および、ＵＥ１０００のユーザに関連付けられてもよい。第１のアクセストークンは、第１のアクセストークンが検証されると、ＲＰ１００６に第１の要求されたユーザ属性を提供する、第１のユーザ情報エンドポイントの位置を示す情報を備えてもよい。第２のアクセストークンは、第２のアクセストークンが検証されると、ＲＰ１００６に第２の要求されたユーザ属性を提供する、第２のユーザ情報エンドポイントの位置を示す情報を備えてもよい。第１のユーザ情報エンドポイントは、ＵＥ１００上に位置してもよく、および、第２のユーザ情報エンドポイントは、例えばネットワークを介してＲＰ１００６と通信するＯＰ１００８などのネットワークエンティティ上に位置してもよい。
【０１１０】
図１２Ａは、１つまたは複数の開示された実施形態が実施されてもよい、例示的な通信システム１４００の図である。通信システム１４００は、複数の無線ユーザに音声、データ、ビデオ、メッセージ、放送などのコンテンツを提供する多元接続システムであってもよい。通信システム１４００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有を通じて、このようなコンテンツにアクセスすることを可能にすることができる。例えば、通信システム１４００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、および単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などの１つまたは複数のチャネルアクセス方法を採用してもよい。
【０１１１】
図１２Ａに示されるように通信システム１４００は、無線送信／受信ユニット（ＷＴＲＵ）１４０２ａ、１４０２ｂ、１４０２ｃ、１４０２ｄ、無線アクセスネットワーク（ＲＡＮ）１４０４、コアネットワーク１４０６、公衆交換電話網（ＰＳＴＮ）１４０８、インターネット１４１０、および他のネットワーク１４１２を含んでもよいが、開示された実施形態は任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を意図していることが理解されよう。ＷＴＲＵ１４０２ａ、１４０２ｂ、１４０２ｃ、１４０２ｄのそれぞれは、無線環境において動作および／または通信するように構成された任意のタイプのデバイスであってもよい。例として、ＷＴＲＵ１４０２ａ、１４０２ｂ、１４０２ｃ、１４０２ｄは、無線信号を送信および／または受信するように構成されてもよく、ならびに、ユーザ機器（ＵＥ）、移動局、固定または移動加入者ユニット、ページャ、セルラ電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ノートブック、パーソナルコンピュータ、無線センサ、および家庭用電化製品などを含んでもよい。
【０１１２】
通信システム１４００はまた、基地局１４１４ａおよび基地局１４１４ｂを含んでもよい。基地局１４１４ａ、１４１４ｂのそれぞれは、コアネットワーク１４０６、インターネット１４１０、および／またはネットワーク１４１２などの１または複数の通信ネットワークへのアクセスを容易にするように、ＷＴＲＵ１４０２ａ、１４０２ｂ、１４０２ｃ、１４０２ｄの少なくとも１つと無線でインターフェースするように構成された任意のタイプのデバイスであってもよい。例として、基地局１４１４ａ、１４１４ｂは、基地局トランシーバ局（ＢＴＳ）、ＮｏｄｅＢ、ｅＮｏｄｅＢ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、サイトコントローラ、アクセスポイント（ＡＰ）、および無線ルータなどであってもよい。基地局１４１４ａ、１４１４ｂは、それぞれ単一の要素として示されているが、基地局１４１４ａ、１４１４ｂは任意の数の相互接続された基地局および／またはネットワーク要素を含んでもよいことが理解されよう。
【０１１３】
基地局１４１４ａは、他の基地局、および／または、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどのネットワーク要素（図示せず）を含むことができる、ＲＡＮ１４０４の一部であってもよい。基地局１４１４ａおよび／または基地局１４１４ｂは、セル（図示せず）と称されてもよい特定の地理的領域内で無線信号を送信および／または受信するように構成されてもよい。セルはさらに、セルセクタに分割されてもよい。例えば、基地局１４１４ａに関連付けられたセルは、３つのセクタに分割されてもよい。したがって実施形態では、基地局１４１４ａは、３つの送受信機、すなわちセルの各セクタに対して１つを含んでもよい。実施形態では、基地局１４１４ａは、多入力多出力（ＭＩＭＯ）技術を採用してもよく、したがってセルの各セクタに対して複数の送受信機を利用してもよい。
【０１１４】
基地局１４１４ａ、１４１４ｂは、任意の適切な無線通信リンク（例えば無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）とすることができる、エアインターフェース１４１６上でＷＴＲＵ１４０２ａ、１４０２ｂ、１４０２ｃ、１４０２ｄの１つまたは複数と通信してもよい。エアインターフェース１４１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されてもよい。
【０１１５】
特に、上述したように、通信システム１００は多元接続システムであってもよく、ならびに、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、およびＳＣ−ＦＤＭＡなどの１つまたは複数のチャネルアクセス方式を採用してもよい。例えば、ＲＡＮ１４０４における基地局１４１４ａ、およびＷＴＲＵ１４０２ａ、１４０２ｂ、１４０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ：登録商標）を使用してエアインターフェース１４１６を確立することができる、ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）地上波無線アクセス（ＵＴＲＡ）などの無線技術を実装してもよい。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）、および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含んでもよい。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含んでもよい。
【０１１６】
実施形態では、基地局１４１４ａおよびＷＴＲＵ１４０２ａ、１４０２ｂ、１４０２ｃは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用してエアインターフェース１４１６を確立することができる、進化型ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実装してもよい。
【０１１７】
他の実施形態では、基地局１４１４ａおよびＷＴＲＵ１４０２ａ、１４０２ｂ、１４０２ｃは、ＩＥＥＥ８０２．１６（Ｗｏｒｌｄｗｉｄｅ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  ｆｏｒ  Ｍｉｃｒｏｗａｖｅ  Ａｃｃｅｓｓ（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００  １Ｘ、ＣＤＭＡ２０００ＥＶ−ＤＯ、Ｉｎｔｅｒｉｍ  Ｓｔａｎｄａｒｄ  ２０００（ＩＳ−２０００）、Ｉｎｔｅｒｉｍ  Ｓｔａｎｄａｒｄ  ９５（ＩＳ−９５）、Ｉｎｔｅｒｉｍ  Ｓｔａｎｄａｒｄ  ８５６（ＩＳ−８５６）、Ｇｌｏｂａｌ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｍｏｂｉｌｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ：登録商標）、Ｅｎｈａｎｃｅｄ  Ｄａｔａ  ｒａｔｅ  ｆｏｒ  ＧＳＭ  Ｅｖｏｌｕｔｉｏｎ（ＥＤＧＥ）、およびＧＳＭ  ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装してもよい。
【０１１８】
図１２Ａにおける基地局１４１４ｂは、例えば無線ルータ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、フェムトセル基地局、またはアクセスポイントであってもよく、ならびに、事業所、家庭、自動車、およびキャンパスの場所などの局所的領域において、無線接続性を容易にするための任意の適切なＲＡＴを利用してもよい。実施形態では、基地局１４１４ｂおよびＷＴＲＵ１４０２ｃ、１４０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実装して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立してもよい。実施形態では、基地局１４１４ｂおよびＷＴＲＵ１４０２ｃ、１４０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立してもよい。さらなる実施形態では、基地局１４１４ｂおよびＷＴＲＵ１４０２ｃ、１４０２ｄは、セルラベースのＲＡＴ（例えばＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立してもよい。図１２Ａに示されるように、基地局１４１４ｂは、インターネット１４１０への直接接続を有してもよい。したがって、基地局１４１４ｂは、コアネットワーク１４０６を介してインターネット１４１０にアクセスすることを要求されない。
【０１１９】
ＲＡＮ１４０４は、音声、データ、アプリケーション、および／またはボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスを、ＷＴＲＵ１４０２ａ、１４０２ｂ、１４０２ｃ、１４０２ｄの１つまたは複数に提供するように構成された任意のタイプのネットワークとすることができる、コアネットワーク１４０６と通信してもよい。例えば、コアネットワーク１４０６は、呼制御、課金サービス、モバイルロケーションベースのサービス、プリペイドコール、インターネット接続性、ビデオ配信などを提供してもよく、ならびに／またはユーザ認証などの高レベルセキュリティ機能を実行してもよい。図１２Ａに示されないが、ＲＡＮ１４０４および／またはコアネットワーク１４０６は、ＲＡＮ１４０４と同一のＲＡＴ、または異なるＲＡＴを採用する他のＲＡＮと、直接または間接に通信してもよいことが理解されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用することができるＲＡＮ１４０４に接続されることに加えて、コアネットワーク１４０６はまた、ＧＳＭ無線技術を採用する他のＲＡＮ（図示せず）と通信してもよい。
【０１２０】
コアネットワーク１４０６はまた、ＰＳＴＮ１４０８、ＷＴＲＵ１４０２ａ、１４０２ｂ、１４０２ｃ、１４０２ｄに対するゲートウェイとしてサービスして、インターネット１４１０、および／または他のネットワーク１４１２にアクセスしてもよい。ＰＳＴＮ１４０８は、従来型電話サービス（ＰＯＴＳ：plain old telephone service）を提供する回線交換電話網を含んでもよい。インターネット１４１０は、ＴＣＰ／ＩＰインターネットプロトコル群における、伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）などの共通通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含んでもよい。ネットワーク１４１２は、他のサービスプロバイダによって所有および／または運用される有線または無線通信ネットワークを含んでもよい。例えばネットワーク１４１２は、ＲＡＮ１４０４と同一のＲＡＴまたは異なるＲＡＴを採用することができる、１つまたは複数のＲＡＮに接続された別のコアネットワークを含んでもよい。
【０１２１】
通信システム１００におけるＷＴＲＵ１４０２ａ、１４０２ｂ、１４０２ｃ、１４０２ｄの一部またはすべては、マルチモード能力を含んでもよく、すなわちＷＴＲＵ１４０２ａ、１４０２ｂ、１４０２ｃ、１４０２ｄは、異なる無線リンク上で異なる無線ネットワークと通信するための複数の送受信機を含んでもよい。例えば、図１２Ａに示されるＷＴＲＵ１４０２ｃは、セルラベースの無線技術を採用することができる基地局１４１４ａ、および、ＩＥＥＥ８０２無線技術を採用することができる基地局１４１４ｂと通信するように構成されてもよい。
【０１２２】
図１２Ｂは、例示的なＷＴＲＵ１４０２のシステム図である。図１２Ｂに示されるようにＷＴＲＵ１４０２は、プロセッサ１４１８、送受信機１４２０、送信／受信素子１４２２、スピーカ／マイク１４２４、キーパッド１４２６、ディスプレイ／タッチパッド１４２８、着脱不能メモリ１４３０、着脱可能メモリ１４３２、電源１４３４、全地球測位システム（ＧＰＳ）チップセット１４３６、および他の周辺機器１４３８を含んでもよい。ＷＴＲＵ１４０２は、実施形態と一貫性を維持しながら、上記の要素の任意のサブコンビネーションを含んでもよいことが理解されよう。
【０１２３】
プロセッサ１４１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連する１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、および状態機械などであってもよい。プロセッサ１４１８は、信号符号化、データ処理、電源制御、入力／出力処理、および／またはＷＴＲＵ１４０２が無線環境において動作することを可能にする任意の他の機能を実行してもよい。プロセッサ１４１８は、送信／受信素子１４２２に結合することができる送受信機１４２０に結合されてもよい。図１２Ｂは、プロセッサ１４１８と送受信機１４２０とを別々の構成要素として示すが、プロセッサ１４１８と送受信機１４２０は、電子回路パッケージまたはチップ内に一緒に統合されてもよいことが理解されよう。プロセッサ１４１８は、アプリケーションレイヤプログラム（例えばブラウザ）、および／または無線アクセスレイヤ（ＲＡＮ）プログラム、および／または通信を実行してもよい。プロセッサ１４１８は、例えばアクセスレイヤおよび／またはアプリケーションレイヤなどにおいて、認証、セキュリティ鍵照合などのセキュリティ動作、および／または、暗号化動作を実行してもよい。
【０１２４】
例示的な実施形態では、ＷＴＲＵ１４０２は、プロセッサ１４１８と、プロセッサに結合されたメモリとを備える。メモリは、プロセッサによって実行されたときに、プロセッサに、ＯｐｅｎＩＤプロトコルの機能をローカルに実行することに関連付けられた動作を遂行させる、実行可能命令を備えてもよい。
【０１２５】
送信／受信素子１４２２は、エアインターフェース１４１６上で、基地局（例えば基地局１４１４ａ）に信号を送信し、またはそれから信号を受信するように構成されてもよい。例えば実施形態では、送信／受信素子１４２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってもよい。実施形態では、送信／受信素子１４２２は、例えばＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成されたエミッタ／ディテクタであってもよい。他の実施形態では、送信／受信素子１４２２は、ＲＦ信号および光信号の両方を送信および受信するように構成されてもよい。送信／受信素子１４２２は、無線信号の任意の組み合わせを送信および／または受信するように構成されてもよいことが理解されよう。
【０１２６】
加えて、図１２Ｂでは、送信／受信素子１４２２は単一の要素として示されるが、ＷＴＲＵ１４０２は任意の数の送信／受信素子１４２２を含んでもよい。特に、ＷＴＲＵ１４０２は、ＭＩＭＯ技術を採用してもよい。したがって実施形態では、ＷＴＲＵ１４０２は、エアインターフェース１４１６上で無線信号を送信および受信するために、２つ以上の送信／受信素子１４２２（例えば、複数のアンテナ）を含んでもよい。
【０１２７】
送受信機１４２０は、送信／受信素子１４２２によって送信されることになる信号を変調し、および、送信／受信素子１４２２によって受信された信号を復調するように構成されてもよい。上述したように、ＷＴＲＵ１４０２は、マルチモード能力を有してもよい。したがって、送受信機１４２０は、例えばＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して、ＷＴＲＵ１４０２が通信することを可能にする、複数の送受信機を含んでもよい。
【０１２８】
ＷＴＲＵ１４０２のプロセッサ１４１８は、スピーカ／マイク１４２４、キーパッド１４２６、および／またはディスプレイ／タッチパッド１４２８（例えば液晶ディスプレイ（ＬＣＤ）ディスプレイユニット、または有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合されてもよく、ならびに、それらからユーザ入力データを受信してもよい。プロセッサ１４１８はまた、スピーカ／マイク１４２４、キーパッド１４２６、および／またはディスプレイ／タッチパッド１４２８にユーザデータを出力してもよい。さらにプロセッサ１４１８は、着脱不能メモリ１４３０および／または着脱可能メモリ１４３２などの任意のタイプの適切なメモリからの情報にアクセスし、ならびに、それらにデータを記憶してもよい。着脱不能メモリ１４３０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶装置を含んでもよい。着脱可能メモリ１４３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含んでもよい。他の実施形態では、プロセッサ１４１８は、サーバまたはホームコンピュータ（図示せず）などの、物理的にＷＴＲＵ１４０２上に位置しないメモリからの情報にアクセスし、および、それにデータを記憶してもよい。
【０１２９】
プロセッサ１４１８は、電源１４３４から電力を受信してもよく、および、ＷＴＲＵ１４０２における他のコンポーネントに電力を分配および／または制御するように構成されてもよい。電源１４３４は、ＷＴＲＵ１４０２に電力供給するための任意の適切なデバイスであってもよい。例えば電源１４３４は、１つまたは複数の乾電池（例えばニッケル−カドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉイオン）など）、太陽電池、および燃料電池などを含んでもよい。
【０１３０】
プロセッサ１４１８はまた、ＷＴＲＵ１４０２の現在位置に関する位置情報（例えば経度および緯度）を提供するように構成することができる、ＧＰＳチップセット１４３６に結合されてもよい。ＧＰＳチップセット１４３６からの情報に加えて、またはその代わりに、ＷＴＲＵ１４０２は、エアインターフェース１４１６上で基地局（例えば基地局１４１４ａ、１４１４ｂ）から位置情報を受信してもよく、ならびに／または、２つ以上の近隣の基地局から受信される信号のタイミングに基づいて、その位置を判定してもよい。ＷＴＲＵ１４０２は、実施形態と一貫性を維持しながら、任意の適切な位置判定方法によって、位置情報を取得してもよいことが理解されよう。
【０１３１】
プロセッサ１４１８はさらに、追加の特徴、機能、および／または有線または無線接続性を提供する１つまたは複数のソフトウェアおよび／またはハードウェアモジュールを含むことができる、他の周辺機器１４３８に結合されてもよい。例えば周辺機器１４３８は、加速度計、電子コンパス、衛星送受信機、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、ブルートゥース（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、およびインターネットブラウザなどを含んでもよい。
【０１３２】
図１２Ｃは、実施形態に従った、ＲＡＮ１４０４およびコアネットワーク１４０６のシステム図である。上述したように、ＲＡＮ１４０４は、ＵＴＲＡ無線技術を使用して、エアインターフェース１４１６上でＷＴＲＵ１４０２ａ、１４０２ｂ、１４０２ｃと通信してもよい。ＲＡＮ１４０４はまた、コアネットワーク１４０６と通信してもよい。図１２Ｃに示されるように、ＲＡＮ１４０４は、それぞれ、エアインターフェース１４１６を上でＷＴＲＵ１４０２ａ、１４０２ｂ、１４０２ｃと通信するための１つまたは複数のト送受信機を含むことができる、ＮｏｄｅＢ１４４０ａ、１４４０ｂ、１４４０ｃを含んでもよい。ＮｏｄｅＢ１４４０ａ、１４４０ｂ、１４４０ｃはそれぞれ、ＲＡＮ１４０４における特定のセル（図示せず）に関連付けられてもよい。ＲＡＮ１４０４はまた、ＲＮＣ１４４２ａ、１４４２ｂを含んでもよい。ＲＡＮ１４０４は、実施形態と一貫性を維持しながら、任意の数のＮｏｄｅＢおよびＲＮＣを含んでもよいことが理解されよう。
【０１３３】
図１２Ｃに示されるように、ＮｏｄｅＢ１４４０ａ、１４４０ｂは、ＲＮＣ１４４２ａと通信してもよい。さらにＮｏｄｅＢ１４４０ｃは、ＲＮＣ１４４２ｂと通信してもよい。ＮｏｄｅＢ１４４０ａ、１４４０ｂ、１４４０ｃは、Ｉｕｂインターフェースを介して、それぞれＲＮＣ１４４２ａ、１４４２ｂと通信してもよい。ＲＮＣ１４４２ａ、１４４２ｂは、Ｉｕｒインターフェースと介して、互いに通信してもよい。ＲＮＣ１４４２ａ、１４４２ｂのそれぞれは、それが接続されるそれぞれのＮｏｄｅＢ１４４０ａ、１４４０ｂ、１４４０ｃを制御するように構成されてもよい。さらにＲＮＣ１４４２ａ、１４４２ｂのそれぞれは、アウターループ電力制御、負荷制御、アドミッション制御、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、およびデータ暗号化などを実行および／またはサポートするように構成されてもよい。
【０１３４】
図１２Ｃに示されるコアネットワーク１４０６は、メディアゲートウェイ（ＭＧＷ）１４４４、モバイルスイッチングセンタ（ＭＳＣ）１４４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４４８、および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１４５０を含んでもよい。上記の要素のそれぞれは、コアネットワーク１４０６の一部として示されるが、これらの要素のいずれか１つは、コアネットワークオペレータ以外のエンティティによって所有および／または運用されてもよいことが理解されよう。
【０１３５】
ＲＡＮ１４０４におけるＲＮＣ１４４２ａは、ＩｕＣＳインターフェースを介して、コアネットワーク１４０６におけるＭＳＣ１４４６に接続されてもよい。ＭＳＣ１４４６は、ＭＧＷ１４４４に接続されてもよい。ＭＳＣ１４４６およびＭＧＷ１４４４は、ＰＳＴＮ１４０８などの回線交換ネットワークへのアクセスを、ＷＴＲＵ１４０２ａ、１４０２ｂ、１４０２ｃに提供して、ＷＴＲＵ１４０２ａ、１４０２ｂ、１４０２ｃと従来型の陸線通信デバイスとの間の通信を容易にしてもよい。
【０１３６】
ＲＡＮ１４０４におけるＲＮＣ１４４２ａはまた、ＩｕＰＳインターフェースを介して、コアネットワーク１４０６におけるＳＧＳＮ１４４８に接続されてもよい。ＳＧＳＮ１４４８は、ＧＧＳＮ１４５０に接続されてもよい。ＳＧＳＮ１４４８およびＧＧＳＮ１４５０は、インターネット１４１０などのパケット交換ネットワークへのアクセスを、ＷＴＲＵ１４０２ａ、１４０２ｂ、１４０２ｃに提供して、ＷＴＲＵ１４０２ａ、１４０２ｂ、１４０２ｃとＩＰ対応デバイスとの間の通信を容易にしてもよい。
【０１３７】
上述したように、コアネットワーク１４０６はまた、他のサービスプロバイダによって所有および／または運用される他の有線または無線ネットワークを含むことができる、ネットワーク１４１２に接続されてもよい。
【０１３８】
特徴および要素が特定の組み合わせにおいて述べられたが、当業者は、各特徴または要素を、単独で、または他の特徴および要素との任意の組み合わせで使用することができることを理解されよう。さらに当業者は、本明細書で述べられる実施形態が例示的な目的のみのために示されることが理解されよう。例えば本明細書では、実施形態はローカルＯｐｅｎＩＤ  ＩＤプロバイダ（ＯＰ）を使用して説明されてもよいが、同様な機能を実行するために非ローカルＯＰまたは外部ＯＰが使用されてもよく、逆も同様である。さらに本明細書で述べられる実施形態は、コンピュータまたはプロセッサによる実行に対するコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実装されてもよい。コンピュータ可読媒体の例は、電子信号（有線または無線接続を上で送信される）、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリ装置、内蔵ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光学媒体を含む。ソフトウェアに関連したプロセッサが、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおける使用のために、無線周波数送受信機を実装するように使用されてもよい。
【図１】
2015511348.tif 000008
【図２】
2015511348.tif 000009
【図３】
2015511348.tif 000010
【図４】
2015511348.tif 000011
【図５】
2015511348.tif 000012
【図６】
2015511348.tif 000013
【図７】
2015511348.tif 000014
【図８】
2015511348.tif 000015
【図９】
2015511348.tif 000016
【図１０】
2015511348.tif 000017
【図１１】
2015511348.tif 000018
【図１２Ａ】
2015511348.tif 000019
【図１２Ｂ】
2015511348.tif 000020
【図１２Ｃ】
2015511348.tif 000021
【手続補正書】
【提出日】平成25年11月20日(2013.11.20)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークを介して通信するユーザ機器（ＵＥ）、識別プロバイダ（ＩｄＰ）、およびサービスプロバイダ（ＳＰ）を備えるシステムにおいて、
少なくとも１つのトークンに対する要求を受信するステップであって、前記トークンに対する前記要求は、前記サービスプロバイダによって提供されるサービスへのアクセスに対する要求に対応する、ステップと、
前記少なくとも１つのトークンに対する前記要求に応答して、前記ＵＥにおいて、前記少なくとも１つのトークンに対する前記要求に従って、識別（ＩＤ）トークンおよびアクセストークンを生成するステップと、
前記ＵＥを介して、前記アクセストークンを発行するステップであって、前記ＵＥ上に存在するユーザ情報エンドポイントからユーザ属性を取り出すことができるように、前記アクセストークンが検証される、ステップと、
前記ＵＥを介して、前記ＩＤトークンを発行するステップであって、前記ＩＤトークンが検証されて、前記ＵＥに前記サービスへのアクセスを提供する、ステップと
を備えたことを特徴とする方法。
【請求項２】
前記ＩＤトークンは、前記ＵＥ内に存在する信頼された環境においてセキュアに生成されることを特徴とする請求項１に記載の方法。
【請求項３】
前記ＳＰに対する前記アクセストークンを生成する承認要求を受信するステップであって、前記承認要求は、前記ＵＥのユーザによって認可される、ステップと、
前記承認要求に応答して、前記ＵＥにおいて、前記承認要求の前記ユーザ認可に関連付けられた前記アクセストークンを生成するステップと
をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項４】
前記承認要求の前記ユーザ認可は、前記ＵＥのポリシーを介して自動的に受信されることを特徴とする請求項３に記載の方法。
【請求項５】
前記アクセストークンは、前記ユーザ情報エンドポイントの位置を示す情報を備え、前記ユーザ情報エンドポイントは、前記アクセストークンが検証されると、前記ＳＰへの要求されたユーザ属性を提供することを特徴とする請求項３に記載の方法。
【請求項６】
前記アクセストークンの前記検証は、前記ユーザが、前記ＳＰへの前記要求されたユーザ属性のリリースに同意したことの検証を備えていることを特徴とする請求項５に記載の方法。
【請求項７】
前記アクセストークンは、前記ＵＥ内に存在する信頼された環境においてセキュアに生成され、および、前記アクセストークンの前記検証は、前記信頼された環境が有効であることの検証を備えていることを特徴とする請求項５に記載の方法。
【請求項８】
前記ＩＤトークンおよび前記アクセストークンは、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔプロトコルに従って生成されることを特徴とする請求項３に記載の方法。
【請求項９】
前記ＩＤトークンおよび前記アクセストークンは、前記ＵＥ内に存在する信頼された環境においてセキュアに生成され、
前記方法は、
信頼されたモジュールで、前記ユーザの認証ステータスを判定するステップと、
前記認証ステータスが、前記ユーザが認証されないことを示している場合に、前記信頼された環境において前記ユーザを認証するステップと
をさらに備えたことを特徴とする請求項３に記載の方法。
【請求項１０】
前記アクセストークンは、第１のアクセストークンであり、
前記方法は、
前記ＳＰに対する少なくとも１つのアクセストークンを生成する承認要求を受信するステップと、
前記承認要求に基づいて、前記ＵＥにおいて、前記第１のアクセストークンおよび第２のアクセストークンを生成するステップであって、前記アクセストークンは、前記サービスおよび前記ユーザに関連付けられる、ステップと
をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項１１】
前記ユーザ情報エンドポイントは、第１のユーザ情報エンドポイントであり、前記第１のアクセストークンは、前記第１のアクセストークンが検証されると、前記ＳＰに第１の要求されたユーザ属性を提供する、前記第１のユーザ情報エンドポイントの位置を示す情報を備え、前記第２のアクセストークンは、前記第２のアクセストークンが検証されると、前記ＳＰに第２の要求されたユーザ属性を提供する、第２のユーザ情報エンドポイントの位置を示す情報を備え、前記第１のユーザ情報エンドポイントは、前記ＵＥ上に位置し、ならびに、前記第２のユーザ情報エンドポイントは、前記ネットワークを介して前記ＳＰと通信するネットワークエンティティ上に位置することを特徴とする請求項１０に記載の方法。
【請求項１２】
前記第１のユーザ情報エンドポイントによって提供される前記第１の要求されたユーザ属性は、前記ユーザによって機密データとして分類され、および、前記第２のユーザ情報エンドポイントによって提供される前記第２の要求されたユーザ属性は、前記ユーザによって非機密データとして分類されることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記ＳＰは、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔクライアントであり、および、前記信頼された環境は、ローカルＯｐｅｎＩＤ識別プロバイダ（ＯＰ）であることを特徴とする請求項２に記載の方法。
【請求項１４】
ネットワークを介して通信するユーザ機器（ＵＥ）、識別プロバイダ（ＩｄＰ）、およびサービスプロバイダ（ＳＰ）を備えるシステムにおいて、前記ＵＥにおいて、
ユーザデータに対する要求を受信するステップと、
前記ユーザデータの同意された部分をリリースすることのユーザ同意を受信するステップと、
前記ユーザ同意に応答して、前記ＳＰに関連付けられたアクセストークンを生成するステップと、
前記アクセストークンを前記ＳＰに発行するステップと
を備え、
前記ユーザデータの前記同意された部分は、前記アクセストークンが検証されると、前記ＳＰにリリースされる
ことを特徴とする方法。
【請求項１５】
前記要求されたユーザデータは、複数のユーザ属性を備え、前記複数のユーザ属性の少なくとも１つは、リリースされる前記ユーザデータの前記同意された部分の一部ではないことを特徴とする請求項１４に記載の方法。
【請求項１６】
署名で前記アクセストークンを署名するステップであって、前記署名は、前記ＵＥの識別子、または、前記ＵＥ内に存在する信頼された環境の識別子の少なくとも１つを備えていることを特徴とする請求項１４に記載の方法。
【請求項１７】
前記ＵＥと、前記ネットワークを介して前記ＳＰと通信する前記ＩｄＰとによって共有されるシークレットで前記アクセストークンを署名するステップをさらに備えたことを特徴とする請求項１４に記載の方法。
【請求項１８】
ユーザ情報エンドポイントは、前記ＵＥ内に存在し、
前記方法は、
前記ユーザ情報エンドポイントにおいて、前記アクセストークンを受信するステップと、
前記アクセストークンを受信したことに応答して、前記ユーザデータの前記同意された部分を前記ＳＰに提供するステップと
をさらに備えたことを特徴とする請求項１４に記載の方法。
【請求項１９】
ネットワークを介して通信するユーザ機器（ＵＥ）およびサービスプロバイダ（ＳＰ）を備えるシステムにおいて、
前記ＳＰにおいて、前記ＳＰによって提供されるサービスへのアクセスに対する要求を受信するステップであって、前記要求は、前記ＵＥのユーザの識別子、または、前記ＵＥの識別子の少なくとも１つを備えている、ステップと、
前記アクセスに対する要求に応答して、前記ＳＰにおいて、識別（ＩＤ）トークンおよび第１のアクセストークンを受信するステップと、
前記アクセストークンの検証に応答して、前記ＳＰにおいて、第１のユーザ情報エンドポイントから第１のユーザ属性を取り出すステップであって、前記第１のユーザ情報エンドポイントは、前記ＵＥ上に存在する、ステップと
を備えたことを特徴とする方法。
【請求項２０】
前記ＳＰにおいて、前記ＳＰ上に記憶されたシークレットを使用して、前記ＩＤトークンの署名を検証するステップと、
前記検証に応答して、前記サービスへの前記ＵＥのアクセスを許可するステップと
をさらに備えたことを特徴とする請求項１９に記載の方法。
【請求項２１】
検証に対して、前記受信されたＩＤトークンをチェックＩＤエンドポイントに送信するステップと、
検証に対して、前記受信された第１のアクセストークンを前記第１のユーザ情報エンドポイントに送信し、それによって、前記ＩＤトークンおよびアクセストークンを曖昧な値として扱うステップと
をさらに備えたことを特徴とする請求項１９に記載の方法。
【請求項２２】
前記アクセスに対する要求に応答して、第２のアクセストークンを受信するステップと、
前記第２のアクセストークンの検証に応答して、前記ＳＰにおいて、第２のユーザ情報エンドポイントから第２のユーザ属性を取り出すステップであって、前記第２のユーザ情報エンドポイントは、前記ネットワークを介して前記ＳＰと通信するネットワークエンティティ上に存在する、ステップと、
前記ＳＰにおいて、前記第１のユーザ属性および前記第２のユーザ属性を結合するステップと
をさらに備えたことを特徴とする請求項１９に記載の方法。
【請求項２３】
無線送信／受信ユニット（ＷＴＲＵ）であって、
実行可能命令を備えるメモリと、
前記メモリと通信するプロセッサであって、前記命令は、前記プロセッサにより実行されると、前記プロセッサに、
少なくとも１つのトークンに対する要求を受信するステップであって、前記トークンに対する前記要求は、サービスプロバイダ（ＳＰ）によって提供されるサービスへのアクセスに対する要求に対応する、ステップと、
前記少なくとも１つのトークンに対する前記要求に応答して、前記少なくとも１つのトークンに対する前記要求に従って、識別（ＩＤ）トークンおよびアクセストークンを生成するステップと、
前記アクセストークンを発行するステップであって、前記ＷＴＲＵ上に存在するユーザ情報エンドポイントからユーザ属性を取り出すことができるように、前記アクセストークンが検証される、ステップと、
前記ＩＤトークンを発行するステップであって、前記ＩＤトークンが検証されて、前記サービスへの前記ＷＴＲＵのアクセスを提供する、ステップと
を備えている動作を実行させることを特徴とするＷＴＲＵ。
【請求項２４】
前記プロセッサは、
前記ＳＰに対する前記アクセストークンを生成することの承認要求を受信するステップであって、前記承認要求は、前記ＷＴＲＵのユーザによって認可される、ステップと、
前記承認要求に応答して、前記承認要求の前記ユーザの認可に関連付けられた前記アクセストークンを生成するステップと
をさらに備えている動作を実行する前記命令を実行するようにさらに構成されていることを特徴とする請求項２３に記載のＷＴＲＵ。
【請求項２５】
前記アクセストークンは、前記ユーザ情報エンドポイントの位置を示す情報を備え、前記ユーザ情報エンドポイントは、前記アクセストークンが検証されると、要求されたユーザ属性を前記ＳＰに提供することを特徴とする請求項２４に記載のＷＴＲＵ。
【請求項２６】
前記アクセストークンの前記検証は、前記ユーザが、前記ＳＰへの前記要求されたユーザ属性のリリースに同意したことの検証を備えていることを特徴とする請求項２５に記載のＷＴＲＵ。
【請求項２７】
前記アクセストークンは、第１のアクセストークンであり、
前記プロセッサは、
前記ＳＰに対する前記少なくとも１つのアクセストークンを生成することの承認要求を受信するステップと、
前記承認要求に基づいて、前記ＷＴＲＵにおいて、前記第１のアクセストークンおよび第２のアクセストークンを生成するステップであって、前記アクセストークンは、前記サービスおよび前記ユーザに関連付けられている、ステップと
をさらに備えている動作を実行する前記命令を実行するようにさらに構成されていることを特徴とする請求項２３に記載のＷＴＲＵ。
【請求項２８】
前記ユーザ情報エンドポイントは、第１のユーザ情報エンドポイントであり、前記第１のアクセストークンは、前記第１のアクセストークンが検証されると、前記ＳＰに第１の要求されたユーザ属性を提供する前記第１のユーザ情報エンドポイントの位置を示す情報を備え、前記第２のアクセストークンは、前記第２のアクセストークンが検証されると、前記ＳＰに第２の要求されたユーザ属性を提供する第２のユーザ情報エンドポイントの位置を示す情報を備え、前記第１のユーザ情報エンドポイントは、前記ＷＴＲＵ上に位置し、ならびに、前記第２のユーザ情報エンドポイントは、ネットワークを介して前記ＳＰと通信するネットワークエンティティ上に位置することを特徴とする請求項２７に記載のＷＴＲＵ。
【国際調査報告】
2015511348.tif 000022
2015511348.tif 000023
2015511348.tif 000024