無線OTAリンクに結合されるインターフェースと、ユーザの第1のIDに対応するデータを記憶する記憶エリアと、前記第1のIDに対応する前記記憶エリア内に記憶される前記データに基づいて、前記ユーザの第2のIDを確立するプロセッサとを備え、前記第1のIDに対応する前記データは、セキュアプロトコルセッション中に前記インターフェースを通して受信され、前記第1のIDは第1のサービスのために確立され、前記第2のIDは第2のサービスのために確立され、前記第1のサービス及び前記第2のサービスは前記ユーザの電子デバイスによって受信される、装置。前記装置は前記デバイス内に含まれている、請求項1に記載の装置。前記装置及び前記デバイスはワイヤレスリンクを介して通信する、請求項1に記載の装置。前記デバイスはモバイル通信デバイスである、請求項1に記載の装置。前記ユーザの前記第1のIDに対応する前記データは暗号化された信号において受信される、請求項1に記載の装置。前記暗号化された信号は、エンハンストプライバシーIDEPID鍵を用いて暗号化される、請求項5に記載の装置。前記第1のIDに対応する前記データは前記ユーザの複数の認証情報を含む、請求項1に記載の装置。前記プロセッサは、1つ又は複数の要求された認証情報の要求を受信し、前記記憶エリア内に記憶される前記複数の認証情報を前記1つ又は複数の要求された認証情報と比較し、前記1つ又は複数の要求された認証情報が前記記憶エリア内に記憶される前記複数の認証情報に含まれる場合には、前記ユーザの前記第2のIDを確立する、請求項7に記載の装置。前記プロセッサは、前記1つ又は複数の要求された認証情報の全ては前記記憶エリア内に記憶される前記複数の認証情報に含まれていない場合には、別のソースから前記ユーザのIDに対応するデータを得る、請求項8に記載の装置。前記ユーザの前記第1のIDに対応する前記データは、公開鍵暗号化標準PKCS信号に基づいて受信される、請求項1に記載の装置。無線OTAリンクに結合されるインターフェースと、ユーザのIDに対応するデータを記憶する記憶エリアと、前記OTAリンクから要求信号を受信し、IDデータに関する前記要求信号内の情報を前記記憶エリア内の前記IDに対応する前記データと比較し、前記比較に基づいて、前記ユーザの前記IDに対応する前記データを前記記憶エリアから前記OTAリンクに送信するコントローラとを備え、前記ユーザの前記IDに対応する前記データは前記装置のために実行されるセキュアプロトコルセッション中に前記OTAリンクを介して送信される、装置。前記比較が、前記要求信号内のIDデータに関する前記情報の全ては前記記憶エリア内の前記データに含まれていないことを示すとき、前記コントローラは前記記憶エリア内の前記データを送信するのを阻止する、請求項11に記載の装置。前記比較が、前記要求信号内のIDデータに関する前記情報の全てが前記記憶エリア内の前記データに含まれることを示すとき、前記コントローラは前記記憶エリア内の前記データを送信する、請求項11に記載の装置。前記記憶エリア内に記憶される前記データは、第1の優先順位の1つ又は複数のID認証情報と、前記第1の優先順位とは異なる第2の優先順位の1つ又は複数のID認証情報とを含む、請求項11に記載の装置。前記第1の優先順位は公開で入手可能な認証情報に対応し、前記第2の優先順位は前記ユーザの秘密認証情報に対応する、請求項14に記載の装置。前記要求信号内のIDデータに関する前記情報は、前記ユーザの1つ又は複数のID認証情報を含み、前記コントローラは、前記要求信号内の前記1つ又は複数のID認証情報をメモリ内に記憶される認証データと比較し、前記認証データは、前記ユーザが前記第1の優先順位の認証情報を開示する許可を与えており、前記第2の優先順位の認証情報を開示する許可を与えていないことを示し、前記比較が、前記要求信号内の前記ID認証情報の少なくとも1つが前記第2の優先順位を有することを示すとき、前記記憶エリア内に記憶される前記ユーザの前記IDに対応する前記データを送信するのを防ぐ、請求項14に記載の装置。前記コントローラは、前記ユーザの前記IDに対応する前記データを、エンハンストプライバシーIDEPID鍵に基づいて暗号化された形で前記記憶エリアから前記OTAリンクに送信する、請求項11に記載の装置。情報へのアクセスを制御するための方法であって、無線OTAリンクを通してIDプロバイダに要求を送信するステップと、前記要求が送信された後に、前記IDプロバイダからデータを受信するステップであって、前記IDプロバイダからの前記データはユーザの第1のIDに対応する、受信するステップと、前記IDプロバイダから受信された前記データに基づいて前記ユーザの第2のIDを確立するステップとを含み、前記第1のIDに対応する前記データはセキュアプロトコルセッション中に受信され、前記第1のIDは第1のサービスのために前記IDプロバイダによって確立され、前記第2のIDは第2のサービスを受信するために確立され、前記第1のサービス及び前記第2のサービスは前記ユーザの電子デバイスによって受信される、情報へのアクセスを制御するための方法。少なくとも前記受信するステップ及び前記確立するステップはIDリクエスタによって実行され、前記IDリクエスタは前記第2のサービスを提供する、請求項18に記載の方法。少なくとも前記受信するステップ及び前記確立するステップはIDリクエスタによって実行され、前記IDリクエスタは前記電子デバイス内に含まれている、請求項18に記載の方法。前記デバイスはモバイル通信デバイスである、請求項20に記載の方法。前記IDプロバイダからの前記データは暗号化された信号において受信される、請求項18に記載の方法。前記暗号化された信号は、エンハンストプライバシーIDEPID鍵を用いて暗号化される、請求項22に記載の方法。前記要求は、前記第1のIDに基づいて前記第2のIDを確立するために前記IDプロバイダから受信される、1つ又は複数のID認証情報を特定する情報を含む、請求項18に記載の方法。前記第1のサービス又は前記第2のサービスのうちの少なくとも1つは加入に基づく、請求項18に記載の方法。情報へのアクセスを制御するための方法であって、ユーザに対応するIDデータを記憶するステップと、前記ユーザのIDデータの要求を受信するステップと、前記要求内のIDデータを前記記憶されるIDデータと比較するステップと、前記比較に基づいて、前記記憶されたIDデータをIDリクエスタに送信するステップとを含み、前記要求は前記IDリクエスタから受信され、前記記憶されたデータは無線OTAリンクを介して前記IDリクエスタに送信され、前記記憶されたデータはセキュアプロトコルセッション中に前記OTAリンクを通して送信される、情報へのアクセスを制御するための方法。前記要求内の全ての前記IDデータが前記記憶されたIDデータに含まれるとき、前記記憶されたIDデータは前記IDリクエスタに送信される、請求項26に記載の方法。前記要求内の全ての前記IDデータが前記記憶されたIDデータに含まれるわけでないとき、前記記憶されたIDデータは前記IDリクエスタに送信されない、請求項26に記載の方法。前記記憶されたデータは第1の優先順位の第1のID認証情報と、第2の優先順位の第2のID認証情報とを含み、前記記憶されたデータは、第2の優先順位の認証情報を開示するための承認が前記ユーザによって与えられないときに、前記IDリクエスタに送信されない、請求項26に記載の方法。前記記憶されたIDデータはエンハンストプライバシーIDEPID鍵を用いて暗号化された信号において送信される、請求項26に記載の方法。図1は、一実施形態に従ってOTAIDプロビジョニングが実行されるシステムの一例を示す。この実施形態では、ワイヤレスデバイス10のユーザは、プロバイダから1つ又は複数のサービス、商品又は情報を入手しようとする。ワイヤレスデバイスは、モバイル若しくはスマートフォン、ノートブック若しくはデスクトップコンピュータ、携帯情報端末、ポッド若しくはパッドタイプデバイス、タブレット、又はワイヤレス能力を備えている幾つかの他の電子デバイスのうちのいずれか1つとすることができる。本明細書において説明される実施形態は、モバイルデバイスにも関連することができる。しかしながら、他の実施形態では、固定式又は可搬式であると見なされるデバイスも、本明細書において説明される方法及びシステムの対象とすることができる。IDプロバイダは、金融サービス、メディア若しくはエンターテインメントサービス、通信サービス、インターネット関連サービス、及び/又は個人若しくは企業/ビジネスソースからの他のサービスを提供することができる。一例によれば、電子デバイスのユーザは、そのソース又はサービスに対して、加入している場合があるか、又は他の約束された形の支払いをしている、若しくは会員である場合がある。プロバイダがサービスを提供できる前に、そのプロバイダはユーザの信頼できるIDを確立しなければならない。このために、そのプロバイダは図1においてIDリクエスタ20として説明される。本実施形態によれば、IDリクエスタは、別のプロバイダによって既に確立されているIDに基づいて電子デバイスのユーザに対するIDを確立する。したがって、他のプロバイダが、既に確立されているIDを示す情報をIDリクエスタ20によって使用するために提供する。それゆえ、リクエスタ20及びプロバイダ30がいずれも実際にはプロバイダであるという了解のもとで、他方のプロバイダは図1との関連においてIDプロバイダ30として説明される。IDプロバイダ30は、金融サービス、メディア若しくはエンターテインメントサービス、通信サービス、インターネット関連サービス、及び/又は種々の他のサービスをユーザに提供することができる。一例によれば、IDプロバイダは、小売業者、公共施設、政府機関、又はユーザによって求められる商品及び/若しくはサービス及び/若しくは情報を提供し、かつIDの確立及び認証が要求される他のタイプの個人、企業又はビジネスソースとすることができる。ワイヤレスデバイス10は、ワイヤレスリンク40を介してIDリクエスタ20と通信することができ、例えば、ワイヤレスリンクは、1つ又は複数のモバイルネットワークを通して確立することができるか、又は限定はしないが、インターネットのような有線若しくはワイヤレスネットワークに接続される短距離リンクを通して確立することができる。そのデバイスは、同じタイプのリンクを介してIDプロバイダ30と通信することもできる。代替的には、IDプロバイダはデバイス10と直接通信するのではなく、むしろ、デバイスの使用とは関係のない方法で、このデバイスのユーザのIDを単に保持する場合がある。例えば、IDプロバイダはクレジットカード会社、銀行、投資顧問、株式仲買人、保険会社又は他の金融機関とすることができる。この場合、IDプロバイダ30は、以下に更に詳細に説明されるように、IDリクエスタ20によってアクセスできるようになるデータベースにアクセスすることができる。IDリクエスタ20及びIDプロバイダ30は、無線リンク60を通して互いに通信する。一実施形態によれば、IDリクエスタとIDプロバイダとの間で交換される情報は、格納された制御ソフトウェアに基づいて、ユーザに対してトランスペアレントに発生することができる。交換された情報を用いて、IDリクエスタは自らのドメインにおいてユーザに対するIDを認証及び確立し、それにより、手作業、又は他のコストがかかり、非効率的なデータ入力の必要性を緩和する。リンク60はユーザに対してトランスペアレントに確立されるので、幾つかのアプリケーションにおいてバックチャネルbackchannelと呼ばれる場合がある。図2は、モバイルデバイスユーザに対して確立された既存のIDに基づいてOTAIDを確立するための方法の一実施形態を示す。この方法は、図1に示されるようなシステム又は異なるシステムにおいて実施することができる。IDプロバイダ及びIDリクエスタ内に少なくとも部分的に位置する制御ソフトウェアを用いて、その方法を実施することができる。第1のIDの確立初期動作は、モバイルデバイスのユーザから、IDプロバイダからのサービスを受信する要求210を受信することを含む。例示のために、本実施形態では、サービスは加入に基づくものと仮定される。しかしながら、他の実施形態では、他の商品及び/又はサービスが取り扱われる場合がある。その要求は、例えば、電話を介して、本人が直に、インターネットを介して行われる要求を通して、又はデバイスからワイヤレスで行われる要求を含む、店舗及び他の方法で受信することができる。要求が行われると、IDプロバイダは、加入を確立するためにユーザに対するID220第1のIDと呼ばれるを確立する。そのIDは、従来の技法を用いて確立される場合がある。例えば、示されるように、ユーザのIDは、手作業で、又は別の方法で入力されたユーザ情報に基づくことができ、生年月日、住所、社会保障番号、クレジットカード又は口座番号、及びユーザのIDを確認することができる信頼性のある基礎を構成する他の情報を含むことができる。これらの技法は、アウトオブバンド加入又はID決定技法と呼ばれる場合がある。ユーザが認証され、そのIDが確立されると、第1のID認証情報230が電子的にアクセス可能なデータベース又は他の記憶デバイスに記憶される。これらの認証情報は、上記のユーザ情報に基づいており、ユーザに対する第2のIDを確立するための基礎として信頼される。第2のIDの確立第1のID認証情報が記憶された後に、ユーザは、IDリクエスタからサービス250を受信するために、加入を要求する。その要求は、例えば、ワイヤレスネットワークを介して、モバイルデバイス10から直接行うことができる。代替的には、その要求は、ユーザのモバイルデバイス上でアクセスされるインターネットウェブサイトを通して行うことができる。一例によれば、その要求は、サービスへの加入要求、ウェブサイトへの入会要求、オンライン購入要求、又は別の状況に応じて行われる。1つの具体例によれば、要求をするとき、ユーザは、ユーザアカウントを作成するための選択可能なオプションを含む、IDプロバイダのウェブページにアクセスすることができる。そのアカウントは、ユーザ名、パスワード、セキュリティに関する質問への回答、及び他の情報に基づいて作成することができる。別の例では、ユーザは、例えば、公開鍵インフラストラクチャPKI鍵に基づいて暗号化された情報の初期転送を与えることができる。その情報は、例えば、証明書要求メッセージの送信に基づいて転送される場合があり、そのメッセージは、ユーザ及び/又はユーザのデバイスに対するデジタル証明書を構成するために証明機関によって用いられる場合がある。要求されると、IDリクエスタは、ユーザの第1のID認証情報を含む、記憶デバイスからの情報を受信するためのリンク例えば、OTAバックチャネル接続を自動的に確立することを含む手順を実行する。第1のID認証情報はIDプロバイダのデータベース又は記憶デバイス内に記憶されるので、上記の手順は、IDプロバイダとのリンクが確立されることが必要とされる場合がある。リンクを確立するために、IDリクエスタは、例えば、ユーティリティツールに基づいて、IDプロバイダ30の存在及び連絡先情報を特定する。より具体的には、ユーザはパスワードマネージャのようなユーティリティツールを用いて自分のIDを管理することができ、パスワードマネージャはウェブ統合機能を有し、その機能によれば、ユーザ名/パスワードの入力を指示するユニバーサルリソースロケータURLが、オートコンプリーション/フォーム記入のためにパスワードマネージャにリダイレクトされる。一実施形態によれば、マネージャツールは、新たなユーザIDが作成されることを検出することができる。ユーザに新たなユーザ名及びパスワードを作成するように指示するのではなく、ユーザは、第1のユーザIDに対応する情報に基づいて新たなID例えば、ユーザ名及びパスワードを構成する代替の選択肢を与えられる場合があり、その情報は、例えば、ユーザ名、デジタル証明書、及び/又はユーザを識別するための他の情報を含むことができる。ユーザ名及びパスワードの場合、パスワードマネージャは、ウェブサイトURLを呼び戻す情報を記憶することができる例えば、オートフィルインのため。その後、このURLを用いて、ID再利用要求を構成することができる。そのIDが証明書であるか、又は証明書を含む場合には、その証明書は、発行者RDN及び発行者URLのような発行者連絡先情報を含むことができ、その発行者はIDプロバイダ30に対応している。この情報に基づいて、IDリクエスタは、第1のID認証情報を受信するためのリンクを確立することができる。リンクが確立されると、IDリクエスタによって提示された加入をユーザが受信できるようにするために、そのユーザのための第2のID260を確立する際に用いるための第1のID認証情報がIDリクエスタに送信される。IDリクエスタは、第1のID認証情報を受信するために、上記のバックチャネルを介して、IDプロバイダと連絡を取ることができる。示されるように、これは、自動的に例えば、ユーザの加入要求に応答して、かつユーザに対してトランスペアレントに行うことができる。受信されると、IDプロバイダは、第1のID認証情報に基づいて、ユーザを認証し、その後、この情報に基づいて第2のIDを確立する。一例によれば、第1のIDは、ユーザ名、パスワード及び/又はデジタル証明書を含むことができる。また、第1のID及び第2のIDは同じにすることができるか、又は互いに異なることができ、例えば、異なるユーザ名及びパスワードを有することができる。第1のIDがデジタル証明書であり、第2のIDが確立されることになる場合、例えば、異なる証明機関でのエンロールメントプロセスの実行に基づいて、異なる証明書が作成される場合がある。IDリクエスタからの加入要求又は他のサービス要求はワイヤレスで行われ、及び/又はIDプロバイダから得られる情報は、モバイルネットワークを含むリンクを介してワイヤレスで得られるので、第2のIDを確立するための手順は、無線OTAIDプロビジョニングと呼ばれる場合があるしたがって、IDリクエスタとIDプロバイダとの間のバックチャネルは、OTA接続と呼ばれる場合がある。第2のIDが確立されると、その第2のIDに基づいて、ユーザのモバイルデバイス上でユーザに対してサービス270を提供することができる。図3は、第1のID認証情報をいかに分類することができ、それらの認証情報がIDリクエスタにいかに転送されるかの一例を示す。これらの認証情報を転送するために、IDリクエスタ20は、IDプロバイダ30へのOTAバックチャネル240を確立する。そのリンクは、例えば、IDリクエスタからIDプロバイダに送信される情報要求requestforinformationRFI信号に基づいて自動的に確立することができる。RFI信号を送信するために、IDリクエスタは最初にIDプロバイダ及び対応するアドレス情報を識別しなければならない。これは、例えば、モバイルデバイスにおいて実行されることになるダウンロードされたアプリケーションに基づいて、又は例えば、コンパクトディスクCD又はデジタル多用途ディスクDVDから読み出されるときに、モバイルデバイス上に記憶される実行可能ファイルによって成し遂げられる場合がある。実行されるときに、そのアプリケーション又はファイルは、第2のユーザIDを確立するために必要とされる認証情報を得るためにIDプロバイダへの接続を自動的に確立することができる。インターフェース330を通してRFI信号が受信されると、IDプロバイダ30内の制御ソフトウェア340によって管理されるプロセッサが、記憶デバイス310からの1つ又は複数の第1のID認証情報の出力を制御し、そのデバイスは例えば、加入者データベース、メモリ、又は他の記憶エリアとすることができる。一実施形態によれば、1つ又は複数の選択された認証情報のみがIDリクエスタに与えられる場合がある。例えば、第1のID認証情報が、公開認証情報320及び秘密認証情報330を含むように分類される場合について考える。公開認証情報は、例えば、住所、電話番号、電子メールアドレス及び/又はユーザに関連する他の公知の情報に対応することができる。秘密認証情報は、クレジットカード情報、社会保障番号、パスワード及び/若しくはユーザ名、並びに/又は他の秘密情報を含むことができる。ユーザを認証し、それゆえ、第2のIDを確立するために、秘密認証情報は不要である場合がある。更に、ユーザは、特別な許可を得ることなく、この情報に他のエンティティがアクセスするのを個別に阻止したい場合がある。これらの状況下で、公開認証情報320はバックチャネルを介してIDリクエスタに送信することができ、秘密認証情報は、秘密認証情報の転送を管理するIDプロバイダの制御ソフトウェアに基づいて、送信されないように阻止することができる。その代わりに、又はそれに加えて、秘密認証情報の転送を阻止する判断は、IDプロバイダ内に記憶される1つ又は複数のユーザ設定に基づいて、及び/又はRFI信号内の情報に基づいて行うことができる。秘密認証情報の転送を阻止することは2つの目的を果たすことができる。第一に、秘密認証情報の転送を阻止することは、ユーザのIDを不正利用から保護し、それはネットワークを介して行われる通信にとって益々重要になっている。第二に、秘密認証情報を阻止することによって、ユーザIDがIDプロバイダによってあらかじめ確認されているという事実に基づいて、第2のIDの信憑性を確認できるようになる。IDプロバイダが信頼できる場合には、ユーザのIDを別にもう一度確認する必要はない場合がある。これにより、更に、第2のIDの確立プロセスが、処理速度及びユーザ利便性に関して、より効率的になる。代替の実施形態では、秘密認証情報は、暗号化された形で、及び/又は情報保護の他の安全な方法を用いてIDリクエスタに送信することができる。公開認証情報が秘密認証情報よりも機密性が低いと見なされる場合であっても、同じことを公開認証情報に対して実行することもできる。図4は、IDリクエスタの一実施形態を示しており、IDリクエスタは、IDプロバイダとの安全なOTA接続を確立するために、信頼できるクライアントアプレットを実施する能力を備えている。図示されるように、IDリクエスタは、OTAプロキシインターフェース410と、OTA接続及び第2のユーザIDを確立するための動作を実行し、かつ他の処理機能及び管理機能を実行するための管理エンジン420を含むプロセッサ415と、第2のユーザIDを確立するための認証情報を記憶する記憶デバイス430とを含む。OTAプロキシ410は、ネットワーク接続性を提供するように動作することができ、管理エンジンが直接ネットワークにアクセスしない場合に用いられる場合がある。一実施形態によれば、OTAプロキシは、所定の標準規格又はプロトコルに基づいて、モバイル通信システムにおいて信号を中継するためのインターフェースとして動作する。この実施形態では、プロキシはOTAバックチャネル接続を通して、IDリクエスタとIDプロバイダとの間の通信を制御することができる。プロキシは、管理エンジン/コントローラによって実行されるチップセットファームウェアとして実現することができ、エンジンの信頼境界外に、又は信頼境界内に存在することができる。他の実施形態では、管理エンジンは、通信ネットワーク及び/又は通信ハブに直接アクセスする場合がある。このシナリオでは、管理エンジンがプロキシとは別にOTAバックチャネル接続を確立することができるので、プロキシはオプションの機構と見なすことができる。管理エンジン420はOTAアプレット又は他のタイプのアプリケーションを実行し、OTAアプレットは、IDプロバイダへのOTAバックチャネル接続を確立する。この接続はIDプロバイダ及びIDリクエスタにおけるシグマセッション中に確立される場合がある。より具体的には、OTA接続は、認証を伴うシグマプロトコルを用いて確立される場合がある。IDプロバイダからIDリクエスタへの認証情報の転送を管理する所定のID属性開示ポリシーがIDプロバイダによって実施される場合がある。そのようなポリシーソフトウェアにおいて実施されるによって、公開認証情報を転送できるようになり、かつ秘密又は機密性が高い階層の認証情報をIDリクエスタに転送できるようになる場合がある。管理エンジンは、先に説明されたように、OTAバックチャネル接続を介して、IDプロバイダの記憶デバイスから認証情報暗号化されている場合も、されてない場合もあるを受信し、その後、これらの認証情報を記憶デバイス430に記憶する。その後、管理エンジンは、記憶された認証情報に基づいて、第2のユーザIDを確立し、確立された第2のIDに基づいて、ユーザデバイスに加入及び/又はサービスを提供する450。このようにして、管理エンジンは、保護された環境内で信頼できるサービスマネージャとして動作すると考えることができる。一実施形態によれば、OTAプロキシ、管理エンジン及び/又は記憶デバイスはIDリクエスタのサーバ内に位置することができる。一例によれば、管理エンジンは、IDリクエスタ内に含まれるチップセット内のコントローラによって実現することができる。このエンジンはセキュアエレメントとして動作することができ、信頼できるコードを実行する強化された安全境界を有する。このコードを実行する際に、IDプロバイダ及びIDリクエスタはいずれも、例えば、先に論じられたRFI信号の送信に応じて、IDプロバイダからIDリクエスタに第1のIDを転送するための機能に頼ることができる。IDリクエスタからのRFI信号は管理エンジンアプレットによって生成することができ、管理エンジンアプレットは、それに関するIDが既に確立されており、記憶された情報がIDリクエスタをこのIDプロバイダにリンクするための情報を提供するプロバイダを識別するように動作する。この機能を実行する際に、アプレットは、コントローラに、可能なら、IDリクエスタのための第2のIDを確立するために必要とされるID認証情報に近い既存のIDを確立しているプロバイダを選択するように指示することができる。また、IDリクエスタは、本明細書において説明されたようにして、IDプロバイダが第1のIDに対応する認証情報の開示を許可したことを検証することもできる。例えば、IDプロバイダがAmazon.com第1のユーザID認証情報のデータベースを保守管理するであり、IDリクエスタがビデオオンデマンドVODウェブサイトである場合について考える。このシナリオでは、管理エンジンは信頼できるサードパーティの役割を果たし、そのサードパーティによって、Amazon.com及びVODエンティティは、ユーティリティツールを用いて互いに接続できるようになる。そのツールは、Amazon.comのための接続情報例えば、URL例えば、管理エンジンに結合されるメモリ内に記憶されるにアクセスすることができ、その接続情報によって、OTAバックチャネルリンクを確立できるようになる。その後、管理エンジンによって実行される動作に基づいて、VODエンティティのための第2のIDを確立するために、第1のID認証情報をAmazon.comからVODエンティティに送信することができる。図5~図8は、OTAIDプロビジョニングを実行するための方法の更に詳細な実施形態に含まれる動作を示す。この方法は、IDリクエスタとIDプロバイダとの間にOTA接続を確立することを含むブロック510。IDリクエスタ及びIDプロバイダは先に論じられたものにすることができ、OTA接続は、限定はしないが、バックチャネル接続を含む、先に論じられた任意のタイプの接続であると考えることができる。OTA接続は、例えば、図1に示される電子デバイス10から受信された信号に応答して、又は別の方法で通知されるときに、IDリクエスタによって開始することができる。その信号又は他の通知は、電子デバイス上で実行されるアプリケーションの制御に基づいて受信される場合があるか、又は有線リンク若しくはワイヤレスリンクを介してユーザから受信された情報に基づいて後の時点で開始される場合がある。接続が確立された後に、IDプロバイダはIDリクエスタから1つ又は複数の特定の認証情報の要求を受信するブロック520。認証情報は、先に確認された認証情報のいずれかとすることができる。その要求に応じて、IDプロバイダは、そのユーザに対応する記憶エリアから認証情報を検索する。認証情報は、その要求において特定される特定の認証情報の全て又は一部とすることができる。記憶エリアは、IDプロバイダのサーバ内に位置する場合があるか、又は遠隔して位置し、そのサーバに結合される場合があるブロック530。検索されると、その要求において特定された全ての認証情報が、検索された認証情報において見つけられるか否かに関する判断が行われるブロック540。見つけられると判断された場合には、各認証情報がチェックされることになるブロック550。この動作は、IDリクエスタに認証情報を与える際に順守されることになる許可又は開示ポリシーを重視する。例えば、各認証情報例えば、名前、電話番号、口座番号、IDプロバイダの1つ又は複数の鍵によって署名されたシグネチャビットなどは、異なる一意性及び機密性を有する場合がある。したがって、幾つかの認証情報は開示を許容できる場合があるが、他の認証情報は、IDプロバイダに対するユーザの信頼を仮定して、許容されない。望ましくない情報の開示を防ぐために、IDプロバイダは、開示されることになる認証情報のネゴシエーションを制御する際に、ユーザの許可例えば、記憶された情報に基づくを順守することができる。開示されることを許容された認証情報の転送はシグマセッション中に送信され、シグマセッションは、望ましくない、又は意図しない開示に対する更なる安全措置を提供する。その要求において特定された全ての認証情報は検索された認証情報において見つけられないと判断された場合には、そのIDプロバイダはIDリクエスタのための第2のユーザIDを確立するために使用できないと結論付けられる。この場合、第2のユーザIDを確立するために別のIDプロバイダを使用できるか、又は利用可能であるかに関する判断がIDリクエスタによって行われる。他のプロバイダによって確立されたIDは、あらかじめ確立されたIDとすることができるブロック570。別のIDプロバイダが存在すると判断された場合には、そのIDプロバイダに対して、ブロック530及び後続のブロックが繰り返される。そうでない場合には、その方法は終了する場合があり、例えば、従来の方法に従って、ユーザのIDが確立されなければならない。ブロック550における動作が実行された後に、要求において特定された全ての認証情報がユーザによって開示を許可されたか否かに関する判断が行われるブロック560。この判断は、例えば、ユーザによってあらかじめ提供され、現時点でIDプロバイダにおいて記憶される設定又は許可情報に基づいて、IDプロバイダによって行われる。ユーザによって、全ての要求された認証情報は、IDリクエスタへの開示を許可されない場合には例えば、そのうちの幾つかが、先に論じられたように、別のエンティティへの転送が許可されない秘密認証情報であるため、プロセスフローはブロック570に続き、可能なら、別のIDプロバイダを特定する。ユーザによって、全ての要求された認証情報が開示を許可される例えば、全て公開認証情報であるか、又はユーザがあらかじめ開示するのを許可した秘密認証情報を含む場合には、認証情報の利用可能性を確認するために、OTA接続を介して、IDプロバイダからIDリクエスタに確認応答信号が送信されるブロック610。この信号は、OTA接続に沿って送信するために、管理エンジンによって生成することができる。確認応答信号が受信された後に、IDリクエスタ内の管理エンジンは第2のユーザIDを作成するためのシグマセッションを開始するブロック620。1つの例示的な実施形態によれば、シグマセッションは、シグマ鍵交換プロトコルに基づいて実行される場合がある。このプロトコルを実施する際に、2つのセッション鍵MK及びSKが用いられる場合がある。これらの鍵のうちの一方MKは秘密性を保護するために用いられ、他方の鍵SKは、IDプロバイダとIDリクエスタとの間で交換されることになるメッセージの完全性を保護するために用いられる。セッション中に、IDリクエスタは、IDプロバイダに対して、IDリクエスタが信頼できるセキュアエレメントであることを証明することができる。これは、例えば、セキュアエレメントのファームウェア構成を厳密に記述するTASKINFO信号に基づいて成し遂げることができ、一方、EPIDは、そのリンクのクライアント側が特定の例えば、インテル社のハードウェアであることを定めている。図10は、シグマセッションを実施する際に交換される場合があるメッセージの一例を示す。シグマセッションが開始された後に、IDリクエスタ内の管理エンジンは、ユーザを認証する手順を実行するブロック630。この手順を実行する際に、認証情報がユーザを記述することができ、認証情報はIDプロバイダにおいて、又はIDプロバイダによって保守管理されているとして、ユーザのセキュアエレメントに由来していると信用されることは理解されたい。このようにして、認証は、IDプロバイダによるユーザのためのIDの確立に基づくことができ、また、先に説明されたように、シグマセッション中に交換されるメッセージに従うこともできる。ユーザが認証された後に、認証情報がIDプロバイダによって開示するのを許可されるか否かに関する判断が行われるブロック640。これは、IDプロバイダ内のコントローラ例えば、管理エンジン420に類似している場合があるか、又は類似していない場合があるによって実施されるポリシーに基づいて実行することができる。このポリシーは、コントローラに、どの認証情報が、機密性があるか例えば、優先順位が高いか、及び/又は開示するのを許可されないかをタグ付けするように指示することができる。それに加えて、又はその代わりに、シグマセッション及びOTAバックチャネル接続を用いて、属性ごとに問合せを実行することができる。認証を実施する擬似コードのサンプルを以下のように与えることができ、ドメインBがIDリクエスタに対応する。与えられたユーザ1、アサート:属性AをドメインBに開示するのを許可するイエス/ノー属性BをドメインBに開示するのを許可するイエス/ノー認証情報が、IDプロバイダによって開示するのを許可されない場合には、ブロック570の動作を実行して、第2のIDを確立するために、別のIDプロバイダが利用可能であるか否かを判断する。一方、認証情報が、IDプロバイダによって開示するのを許可される場合には、IDプロバイダがシグマエンロールメントをサポートするか否かの判断が行われるブロック710。これは、例えば、図10におけるS1メッセージを送信することに基づいて成し遂げることができる。IDプロバイダがシグマエンロールメントをサポートしない場合には、制御はブロック570に移る。一方、IDプロバイダがシグマエンロールメントをサポートすると判断される場合には、IDプロバイダにおいてシグマセッションが開始されるブロック720。シグマセッションの開始は、図10におけるS1メッセージを送信することを伴う場合がある。一実施形態によれば、第1のメッセージは、シグマとも呼ばれる、署名付きディフィ-ヘルマン鍵交換プロトコルに基づいて送信される。また、図10において、検証機構、証明機構及びオンライン証明書状態プロトコルOSCP応答機構は、IDプロバイダ、IDリクエスタ及び電子デバイスの任意の組み合わせに対応することができる。また、一例によれば、証明機構は、シグマプロトコルのクライアント側に対応すると見なすことができ、検証機構は、シグマプロトコルのサーバ側に対応すると見なすことができる。シグマプロトコルを用いることによって、証明機構は、検証機構IDを検証できるようになるしたがって、例えば、クライアントは、自らがやりとりしているドメインがわかる。サーバは、クライアント例えば、証明機構が信頼できる環境例えば、セキュアエレメントであることを検証することができる。また、一実施形態では、OSCP応答機構は、取消リスト情報を供給する第3のエンティティとして動作することができる。第3のエンティティは、例えば、証明機関とすることができ、証明機関は、証明機構ハードウェア内に埋め込まれた公開鍵を有し、その公開鍵によって、検証機構の証明書及び証明機関の1つ又は複数の取消リストを検証できるようになる。S2メッセージ及びS3メッセージは証明機構と検証機構との間で交換され、OCSP応答機構からの応答メッセージの受信後にIDを検証できるようにする。シグマセッションが開始された後に、IDプロバイダのサーバ又は他の場所に記憶される要求された認証情報が所定の鍵を用いて暗号化されるブロック730。暗号化は、例えば、高度暗号化標準AdvancedEncryptionStandard:AES及びトリプルデータ暗号化標準TripleDataEncryptionStandard:3DESのような対称鍵暗号を用いてシグマセッション鍵SKに基づいて実行することができる。シグマ鍵は、ユーザに対応する秘密鍵とすることができるか、又は別のタイプの鍵とすることができる。暗号化されると、認証情報は、OTA接続に沿ってIDプロバイダからIDリクエスタに転送されるブロック740。この動作は、開始されたシグマセッションに対応する1つ又は複数の所定のエンロールメントプロトコルに基づいて実行することができる。認証情報をIDリクエスタに開示するプロセスは、エンロールメントプロトコルを構成すると考えることができる。この関連で、IDプロバイダ内の管理エンジン又は他のセキュアエレメント又は代替的には、IDリクエスタ内の管理エンジンが、認証情報の信憑性を保証する信頼できる機関の役割を果たすことができる。PKI用語において、管理エンジンは、この場合、登録認定機関であると見なすことができる。暗号化された認証情報は、管理エンジンによって暗号解読され、その後、このエンジンは認証情報に基づいて第2のユーザIDを確立するブロック750。暗号解読は、暗号化のために用いられた所定の鍵及び技法に基づいて実行され、その情報は、シグマセッション中にIDリクエスタに通知することができ、例えば、図10に示される交換されるメッセージのうちの1つ又は複数において、MK鍵マスター鍵及びSK鍵が送信される。第2のユーザIDは、ユーザを一意的に識別する高い確率を有する1つ又は複数の認証情報先に言及された認証情報のいずれか、例えば、名前、口座番号などを含むによって確立することができる。第2のユーザIDを確立するために実行される動作の一例は、以下のことを含む場合がある。1.ユーザの認証情報を得る。2.ユーザに対する正当性及び/又は妥当性を吟味する。例えば、それは登録認定機関のような信頼できる機関によって実行される。その際、IDリクエスタの管理エンジンは、別のサービスプロバイダからあらかじめ発行されたIDを利用して、正当性及び妥当性を得る。3.ドメイン命名機関によって制御されるドメイン特有の認証情報又は他の属性例えば、名前、番号、役割、特権を関連付けるドメイン機関に認証情報を提示する。例えば、.comドメインは、インターネット属性及び命名機関InternetAttributeandNamingAuthority:IANAによって制御される。ドメイン機関は、例えば、証明書に署名することによって、又は関連するドメイン、例えば、IDリクエスタのドメインによって制御されるデータベース内のエントリを作成することによって、第2のユーザIDに対応する1つ又は複数の認証情報を発行することができる。この例では、IDプロバイダの管理エンジンがユーザに対するドメインの役割を果たすことができる。管理エンジンは、属性を適切にネゴシエートするために、他のドメイン例えば、IDリクエスタによって信頼されるので、人手が介入することなく、認証情報を無線で自動的に構成できるようになる。基本的に、このIDは、ユーザによって求められた加入又はサービスが、そのユーザに対して許可された、例えば、ユーザのモバイルデバイス又は他のデバイス上で受信されることを許可されたという指示をIDプロバイダに与える。図1に示されるように、モバイルデバイスは無線リンク又は他のタイプのリンクを通してIDプロバイダに結合される場合がある。別のエンティティ/IDプロバイダによってユーザに対して既に確立されているIDに基づいて、ユーザに対してトランスペアレントに第2のユーザIDを確立することによって、他の人手に基づく方法と比べて、加入/サービスの受信を認証し、許可するプロセスが効率的にされる。図7のブロック720、730及び740の動作に対する代替形態として、図8の動作を実行することができる。これらの動作は、所定の鍵によって署名された公開鍵暗号化標準PKCS要求を構成することブロック820を含む。PKCS要求は、証明要求を構成するPCKS10標準に対応する。より具体的には、PCKS10は、鍵の証明を要求するために証明機関に送信されるメッセージのフォーマットに対応する。その鍵は公開鍵又は秘密鍵とすることができ、後者の場合、モバイルデバイス10のユーザの秘密鍵に対応することができる。PCKS要求が構成されると、その要求は、エンハンストプライバシーIDEnhancedPrivacyIdentity:EPID鍵を用いて暗号化又は署名することができるブロック830。EPIDは、匿名でIDの証明又はグループ内のメンバーシップを与える暗号化プロトコルである。このプロトコルによれば、EPIDを発行するエンティティは、データベース内にユーザの秘密鍵を記憶せず、ユーザの秘密鍵が漏れた場合には、EPID鍵は取消可能である。より具体的には、EPIDは高度な取消能力を有する直接匿名認証方式を利用し、その能力はユーザに対して高度な保護手段を提供する。他の方法とは異なり、EPIDでは、署名者を特定するグループ署名を誰も公開することができない。更に、EPIDは、ユーザのプライバシーを保護しながら、同時に、認証及び証明のために用いることができる。PCKS要求がEPID鍵を用いて暗号化されると、IDリクエスタに送信されるブロック840。その要求は、OTA接続又は異なる接続に沿って送信される場合がある。EPIDによって提供される高度な保護のため、その要求の安全性は無傷のままである。その後、IDリクエスタは、ブロック750と同様に、第2のユーザIDを確立することができる。図9は、OTAIDプロビジョニングを実行するために、IDリクエスタが電子デバイス内に位置するシステムの別の実施形態を示す。この実施形態では、IDリクエスタ915は、ユーザの電子デバイス910内に位置し、例えば、電子デバイスはモバイルデバイス、又は上記の他のデバイスのいずれかとすることができる。IDリクエスタは、ID認証情報を得るために、更には、IDプロバイダ920とともにインタラクティブに実行される他の動作のために、上記のIDリクエスタと同じように動作することができる。IDプロバイダ及びIDリクエスタ/デバイスは、OTA接続930を介して互いに通信することができる。別の実施形態によれば、電子デバイスは含まれず、IDリクエスタは、IDプロバイダによってあらかじめ確立されたIDに基づいてユーザのためのIDを確立する。そのような実施形態は、例えば、IDリクエスタが店頭POS端末、チケット端末又は現金自動預払機、給油所ポンプの制御システム、事務所、建物又は家庭用のセキュリティシステム、駐車場検証又は支払機、又はユーザ認証及びID確認を必要とする他のタイプのシステム又はデバイスである場合を含むことができる。別の実施形態は、上記の方法の動作を実行するためのコード部分を含むプログラムを記憶するコンピュータ可読媒体に対応する。第1のコンピュータ可読媒体はIDリクエスタ内に位置し、管理エンジン及びその関連する機構の動作を実行するためのコードを記憶することができる。第2のコンピュータ可読媒体は、先に説明されたようにIDプロバイダの動作を実行するコードを記憶するためにIDプロバイダ内に位置することができる。第3のコンピュータ可読媒体は、本明細書において説明されたように、サービスを要求し、及び/又は受信するための動作を実行するためにデバイス内に位置することができる。本明細書において実施形態を参照することは、その実施形態に関連して記述される特定の特徴、構造又は特性が本発明の少なくとも1つの実施形態に含まれることを意味する。本明細書内の種々の場所において、そのような語句が現れても、全てが同じ実施形態を指しているとは限らない。更に、任意の実施形態に関連して特定の特徴、構造又は特性が記述されるとき、他の実施形態に関連してそのような特徴、構造又は特性を達成することも当業者の理解の範囲内にあると考えられる。また、本明細書において説明されるいずれか1つの実施形態の特徴を1つ又は複数の他の実施形態の特徴と組み合わせて、更なる実施形態を形成することができる。更に、理解するのを容易にするために、特定の機能ブロックが別々のブロックとして示されている場合がある。しかしながら、これらの別々に図示されるブロックは、それらのブロックが本明細書において論じられるか、又は別の方法で提示される順序をなすものと必ずしも解釈されるべきではない。例えば、幾つかのブロックは別の順序で、同時に、などで実行できる場合がある。本発明は本明細書において幾つかの例示的な実施形態を参照しながら説明されてきたが、当業者は、本発明の原理の精神及び範囲内に入る数多くの他の変更形態及び実施形態を考案できることは理解されたい。より詳細には、本発明の精神から逸脱することなく、これまでの開示、図面及び添付の特許請求の範囲の中で、対象となる組み合わせの構成の構成部品及び/又は構成に関して合理的な変形及び変更が可能である。構成部品及び/又は構成に関する変形及び変更に加えて、代替の使用も当業者には明らかであろう。