"無線デバイスのユーザを認証する方法であって、ネットワークアプリケーション機能から認証要求を受信するステップと、信頼されるチケットサーバによって、プラットフォーム妥当性検査データを取り出すステップであって、前記プラットフォーム妥当性検査データは、前記無線デバイスの信頼性の尺度を含む、ステップと、前記ネットワークアプリケーション機能に前記プラットフォーム妥当性検査データを送信するステップと、前記ネットワークアプリケーション機能が前記プラットフォーム妥当性検査データおよび前記ユーザを検証したことを示すプラットフォーム検証を受信するステップとを含むことを特徴とする方法。前記プラットフォーム検証は、前記プラットフォーム妥当性検査データによって示されるシステム状態が以前に生成された基準値と一致することを示すことを特徴とする請求項1に記載の方法。前記プラットフォーム妥当性検査データは、署名されることを特徴とする請求項1に記載の方法。前記プラットフォーム妥当性検査データは、ユーザ識別パラメータを含むことを特徴とする請求項1に記載の方法。前記プラットフォーム妥当性検査データは、構成証明データを含むことを特徴とする請求項1に記載の方法。前記構成証明データは、AIKを用いて署名されたSMLおよびPCR引用を含むことを特徴とする請求項5に記載の方法。前記プラットフォーム検証を含むチケットを受信するステップをさらに含み、前記チケットは、前記無線デバイスの再妥当性検査なしで後続認可を実行するために再利用されることが可能であることを特徴とする請求項1に記載の方法。前記チケットは、タイムスタンプを含むことを特徴とする請求項7に記載の方法。前記チケットは、発信タイムスタンプoriginationtimestampを含むことを特徴とする請求項7に記載の方法。前記チケットは、寿命限度を含むことを特徴とする請求項7に記載の方法。前記チケットは、終了日付を含むことを特徴とする請求項7に記載の方法。前記チケットは、使用パラメータ限度を含むことを特徴とする請求項7に記載の方法。ネットワークエンティティからチケット参照を受信するステップをさらに含むことを特徴とする請求項7に記載の方法。前記チケット参照は、ネットワークアプリケーション機能から前記チケットを入手するのに使用されることが可能であり、前記プラットフォーム検証は、前記無線デバイスの再妥当性検査なしで後続認可を実行するために再利用されることが可能であることを特徴とする請求項13に記載の方法。依拠当事者への接続を確立するステップと、前記ネットワークアプリケーション機能へのブラウザリダイレクションを受信するステップと、前記ネットワークアプリケーション機能に認証要求を送信するステップとをさらに含むことを特徴とする請求項1に記載の方法。前記プラットフォーム検証は、依拠当事者への付与されたアクセスであることを含むことを特徴とする請求項1に記載の方法。より詳細な理解を、添付図面に関連して例として与えられる次の説明から得ることができる。図1~21は、開示されるシステム、方法、および手段を実施できる例示的実施形態に関連しうる。しかしながら、本発明を例示的実施形態に関連して説明する場合があるものの、本発明は、これに限定されず、本発明から逸脱せずに、他の実施形態を使用でき、または、本発明の同一の機能を実行するために、説明される実施形態に対して変更および追加が行われてもよいことを理解されたい。さらに、図面は、コールフローを示す場合があるが、これは、例示的であることが意図されている。他の実施形態を使用できることを理解されたい。さらに、フローの順序を、適当な場合に変更することができる。さらに、フローを、必要な場合に省略することができ、追加のフローを追加することができる。本明細書において後で言及される際、用語WTRU無線送受信ユニットは、UEユーザ機器、移動局、固定のもしくは可動の加入者ユニット、ポケットベル、セルラ電話機、携帯情報端末PDA、コンピュータ、または無線環境内で動作できる任意の他のタイプのデバイスを含むが、これに限定されない。本明細書で後で言及される際、用語基地局は、Node-B、サイトコントローラ、アクセスポイントAP、または無線環境内で動作できる任意の他のタイプのインターフェースするデバイスを含むことができるが、これに限定されない。本明細書の開示は、例の認証およびアクセスシステムとしてOpenIDプロトコルを使用することができ、他の認証およびアクセスシステムに適用可能である。説明において、さまざまな実施形態は、3GPPThirdGenerationPartnershipのコンテキストで説明されるが、さまざまな実施形態を、任意の無線通信技術で実施することができる。無線通信技術のいくつかの例のタイプは、WiMAXWorldwideInteroperabilityforMicrowaveAccess、802.xx、GSMGlobalSystemforMobilecommunications、符号分割多元接続CDMA2000、UMTSUniversalMobileTelecommunicationsSystem、LTELongTermEvolution、または任意の将来の技術を含むことができるが、これらに限定されない。図1に、クライアント/ユーザプラットフォーム110、アイデンティティプロバイダ120、プライバシ認証機関privacycertificationauthority:PCA130、およびサービスプロバイダ140を含むがこれらに限定されない例示的な認証およびアクセスシステム100を示す。クライアント/ユーザプラットフォーム110、アイデンティティプロバイダ120、およびサービスプロバイダ140は、無線通信システムおよび有線通信システムの任意の組合せを介してお互いと通信しているものとすることができる。クライアント/ユーザプラットフォーム110は、PCA130と通信しているものとすることができ、PCA130は、記憶媒体160との通信とすることができ、記憶媒体160は、たとえば証明書を格納することができる。クライアント/ユーザプラットフォーム110は、WTRU、基地局、コンピューティングプラットフォーム、または認証を必要とする可能性がある任意のデバイスとすることができる。クライアント/ユーザプラットフォーム110は、リモート構成証明attestationと、クライアント/ユーザプラットフォーム110のデータに関するスケーリング能力および束縛能力とを提供するtrustedplatformmoduleTPM115を含むことができるが、これに限定されない。TPM115は、鍵、パスワード、ディジタル証明書を格納し、暗号鍵を生成できる、マイクロコントローラとすることができる。TPM115を、マザーボードに固定するかシステムのチップセット内に統合することができ、TPM115を、これらの機能を必要とする可能性がある任意のコンピューティングデバイス内で使用することができる。TPM115は、たとえば外部ソフトウェア攻撃、物理的改竄、盗聴などからその情報を保護することができる。TPM115またはクライアント/ユーザプラットフォーム110内のデータおよび秘密へのアクセスは、ブートシーケンス中にコンポーネントについてとられた測定値が、セキュア電子メール、セキュアウェブアクセス、およびデータのローカル保護などのアプリケーションおよび能力をよりセキュアにすることができる基準測定に対して期待されるものではない場合に、拒否され得る。trustedplatformmoduleが本明細書において議論されるが、たとえばmobiletrustedmoduleなどの他の信頼センタtrustcenterを使用することができる。TPM115は、保証キーendorsementkey:EK、たとえば製造時にチップ上でランダムに作成され、変更できない2048ビットRSARivest-Shamir-Adelman公開鍵/秘密鍵対を使用することができる。秘密鍵をチップに制限することができ、公開鍵は、構成証明およびチップに送信される機密データの暗号化に使用される。EKの公開部分を、構成証明のためのEK証明書を介してPCA130によって一般に知られるものとすることができる。TPM115が、たとえばアイデンティティプロバイダなどのベリファイヤに対してそれ自体を認証することを必要とする時には、TPM115は、構成証明識別鍵attestationidentitykey:AIKと呼ばれる第2のRSA鍵対を生成し、AIK公開鍵をPCA130に送信し、対応するEKに対してこの公開鍵を認証することができる。PCA130が、そのリスト内でこのEKを見つける場合には、PCA130は、TPM115のAIKに対する証明書を発行することができる。その後、TPM115は、この証明書をアイデンティティプロバイダ120に供給し、それ自体を認証することができる。AIK少なくともAIK内で実施されるアイデンティティは、本明細書で説明されるチケットの少なくとも1つの部分を表すことができる。チケット内でのAIKの使用を、TPM115によって制限することができる。CertifyKey動作と称する間接的手法を使用することができ、ここでは、署名する鍵が、TPM115によって生成され、AIKを用いてこれに署名することによって証明される。この鍵を、証明された署名する鍵certifiedsigningkey:CSKと呼ぶことができる。CSKおよびAIKは、AIKの妥当性をアテストするPCAと一緒に、本明細書で説明されるチケットの一部を構成することができる。クライアント/ユーザプラットフォーム110は、サービスアクセス用の証明書すなわちチケットを生成する信頼されるチケットサーバ、TTS150を含むことができる。本明細書でtrustedOpenIDに関してチケットサーバに言及する際、そのような言及を、信頼されるチケットサーバへの言及とすることができる。TTS150は、ユーザを認証することができる。TTS150は、たとえばプラットフォーム構成証明のtrustedcomputing法を使用して、アイデンティティプロバイダ120に対してクライアント/ユーザプラットフォーム110およびそれ自体を妥当性検査することができる。セキュリティ情報およびセキュリティ動作をTTS150内に集中することができるので、TTS150は、AIK証明書およびCSKを正しく扱い、これらを他のプラットフォームに増殖させず、チケットおよび証明書を保護し、ユーザ認可によって証明書に対するセキュリティ動作を保護し、一般的なウェブブラウザに統合され、これによってアクセスされるセキュアオプションを提供し、プラットフォーム妥当性検査データを収集し、処理し、送信すると信頼される必要がある場合がある。ユーザは、TPM115内で作成されたAIKを証明するためにPCA130を選択する必要がある場合がある。PCA130は、アイデンティティ関連情報を保持することができ、契約措置が、このアイデンティティ関連情報の非開示を保証するためにとられる必要がある場合がある。PCA130でAIKを証明した後に、ユーザは、主張されたアイデンティティをホスティングするためにアイデンティティプロバイダ120を選択することができる。主張されたアイデンティティを、ユーザによって選択されたURIuniversalresourceidentifierによって表すことができる。そのような主張されたアイデンティティを登録するために、ユーザに、有効なAIK証明書をアイデンティティプロバイダ120に供給するように要求することができる。アイデンティティプロバイダ120に、最小限の量のアイデンティティ関連情報を提示することができる。ユーザは、PCA130でホスティングされるどの情報をアイデンティティプロバイダ120に明らかにすることができるのかを判断することができる。当事者の間での調整を保証するために契約措置をとる必要がある場合があり、そうでなければ、悪意者のPCAが、異なるユーザに属するアイデンティティを証明できる可能性がある。PCA130は、ユーザの実際のアイデンティティをアイデンティティプロバイダ120に明らかにすることができないので、アイデンティティプロバイダ120は、異なる要求を単一のアイデンティティにリンクすることができない可能性がある。主張されたアイデンティティを実際のアイデンティティに解決する能力を、PCA130に制限することができる。これは、一意のEK証明書をAIKにマッピングする保護されたデータベースを維持することによって行うことができる。AIK証明中に使用されるEK証明書は、TPM115の識別を、したがってクライアント/ユーザプラットフォーム110の識別を、可能にすることができるたとえば、1人のユーザがプラットフォーム110への物理アクセスを有すると仮定すると、これがそのユーザに解決される。サービスプロバイダ140は、サイトに関するアイデンティティプロバイダログインを可能にすることができる。たとえば、サービスプロバイダ140は、フロントページにOpenIDログインロゴを有することができる。ユーザ/クライアントによって使用されるアイデンティティプロバイダ120に、サービスプロバイダ140の既知の受け入れられるアイデンティティプロバイダのリストに含まれることを要求することができる。連合アイデンティティfederatedidentity方式またはシングルサインオンSSO方式は、ユーザが単一の証明書を使用して複数のセキュアサイトにログインすることを可能にする、ユーザフレンドリな方法を提供することができる。連合アイデンティティ方式の実施態様の複数の形が可能である可能性があるが、本明細書の開示は、例としてOpenIDを使用する信頼される概念trustedconceptsの概要を提供する。他の方法、たとえば、trustedcomputing技法を使用し、ユーザとデバイスとネットワークとの間で認証を束縛する、アプリケーションおよびインターネットベースのサービスへのシングルサインオンSSOアクセスを適用することができる。OpenIDは、ユーザを認証するための異なる認証方法を可能にすることができる。OpenIDプロバイダでアイデンティティを主張するために、複数の方法を使用することができる。ある方法は、ユーザがパスワードを提供するログオンフォームの使用であってもよい。このログオンを、TPMベースのログオンプロセスに置換することができる。ユーザは、かれらの特定のプラットフォーム、たとえばTPMに緊密に束縛されたアイデンティティを登録することができる。ユーザが、このアイデンティティを使用してログオンすると判断する場合には、OpenIDプロバイダは、正しい証明書を提供するために、そのユーザにチャレンジすることができる。この場合に、証明書は、TPMが生成したチケット、たとえば証明書チェーンcredentialchainを含むことができる。これは、ユーザが、OpenIDプロバイダでのパスワードの必要なしにログインすることを可能にすることができる。ユーザのコンピュータでのローカルパスワードを使用して、ローカル攻撃からアイデンティティを保護することができる。ログインを、特定のプラットフォームの完全性integrity検証と組み合わせることができる。システム構成値に対するTPM署名されたステートメントを使用して、OpenIDプロバイダは、報告されたシステム状態を以前に生成された基準値と比較することができる。この手順は、信頼できるクライアントがログインし、アイデンティティを主張することを可能にすることができる。この組み合わされた認証および構成証明は、認証データを特定のプラットフォームおよび信頼できると考えることのできる事前定義のシステム状態に束縛することによって、微細な粒度のアクセス制御を可能にすることができる。これは、システムの強化されたセキュリティおよび安全性を要求する可能性があるOpenIDの新しいユースケースの使用可能化を可能にすることができ、したがって、信頼できないシステムにつながる変更を可能にしないものとすることができる。議論される実施形態は、TPMに基づくが、たとえばモバイルツーモバイルMTM環境または信頼される環境など、他の信頼されるシステムの変形形態も可能である可能性がある。信頼されるケルベロスTKerberos:trustedKerberos概念は、たとえば認証サーバAS:AuthenticationServerおよび/またはチケット付与サーバTGS:TicketGrantingServerなど、2つのサーバに頼ることができる。これらのサーバのそれぞれが、チケットを発行することができる。各チケットは、2つの部分を含むことができる。たとえば、一方の部分は、次のターゲットサーバのために暗号化され得、したがって、クライアントによって暗号化解除decryptされ得ない。この部分は、次の通信ステップによって使用できるセッション鍵を含むことができる。セッション鍵を、チケットの第2部分内においてクライアントのために暗号化することができる。クライアントが第2部分を暗号化解除できる場合には、クライアントは、次のチケットを要求するためにセッション鍵を入手することができる。TKerberosを、たとえば次のように複数のステージで実行することができる。たとえば、TGTticketgrantingticketをASに要求し、かつ/またはASから受信し、将来の使用のために格納することができる。セッション鍵を暗号化解除して、STserviceticket用の認証データを暗号化することができる。TGTを、暗号化されたオーセンティケータ認証子と一緒にTGSに送信することができる。STを、TGSから受信することができる。セッション鍵を暗号化解除して、サービス要求用の認証データを暗号化することができる。STを、暗号化されたオーセンティケータと共にサービスプロバイダに送信することができる。TKerberosプロトコルは、TCを使用することができる。その設計は、たとえば、TPMを介してチケットをユーザのチケットサーバTSに密に束縛する手段を提供することによってセキュリティを高めるため、および/またはサービスにアクセスするユーザのプライバシを保護するため、などの目標を有しうる。ASが、PCAの役割を実行することができ、かつ/またはTGTが、AIK証明書として働くことができる。チケット獲得プロセスは、プラットフォームが前もってチケットをキャッシングし、サービスアクセスのためにそれらのチケットを個々に取り扱うことを可能にするために、TKerberosに2つの部分を含めることができる。サーバ側のセキュリティに含まれて、ユーザのシステムの構成証明が存在する場合がある。ユーザが、サービスにアクセスするためにSTを獲得することを望む時には、システム準拠をリモートにアテストするために、ユーザに、TGSによってチャレンジすることができる。その結果、証明されたシステム内のクライアントは、サービスにアクセスできるものとすることができる。図1Aに、信頼されるケルベロスに関連する例示的なコールフローを示す。TGTを、TCTicketによって増強することができ、このTCTicketは、TGTの主張されるアイデンティティおよびサービス要求を有し、TPMによって署名され得る。図1Aに示されているように、クライアント30、AS40、TGS50、およびサービスプロバイダ60が、お互いの間の通信のために構成される。10では、クライアント30が、TGTを取り出すことができる。たとえば、クライアント30は、ローカルキャッシュからロードし、かつ/またはAS40からTGTを得ることができる。クライアント30は、AS40へのTGT要求13を行うことができる。クライアントの実際のアイデンティティ情報は、AS40公開鍵を使用して暗号化され得るので、保護され得る。15では、AS40が、TGT応答をクライアント30に返すことができる。ASからのTGT応答を、TPMの公開EKを使用して暗号化することができる。17では、クライアント30が、STを取り出すことができる。17では、クライアント30が、ユーザからアイデンティティAIKパスワードを得、TPMを使用してTCTickitを作成し、かつ/またはシステム状態を引用することができる。18では、クライアント30が、STを取り出すためにST要求を使用することができる。クライアント30がTGS50にSTを要求するのにTGTを使用する時に、通信を、TGTからのセッション鍵によって暗号化することができる。TGS50は、19でTGTをチェックし、20でシステム状態完全性をチェックし、21でTCTをチェックし、かつ/または22でクライアントTPMのためにSTを暗号化することができる。セッション鍵を明らかにし、かつ/またはTGSがクライアントによって供給されるデータを暗号化解除することを可能にするために、TGTを、TGS50によって暗号化することができる。TCTicketからの証明された署名する鍵CSKに束縛され、TPMによって保護される使い捨て鍵を用いてセッション鍵を暗号化することによって、応答をTPMに暗号的に束縛することができる。TPMおよびTPMでのキー使用のための証明書を所有するユーザは、STを暗号化解除し、したがってサービスにアクセスするのにそのSTを使用することができる。たとえば、図1Aに示されているように、クライアント30は、25でサービスを要求することができる。クライアント30は、暗号化されている場合にSTを暗号化解除し、26でSTをサービスプロバイダ60に供給することができる。サービスプロバイダ60は、27でSTをチェックし、STが有効である場合には、28で要求されたサービスを提供することができる。信頼されるチケットの概念は、チケット獲得プロセスでのクライアントの構成証明を含むことができる。TGSに対する構成証明を、セキュリティの増大として説明することができる。これは、特定のアプリケーションの形態の変化を提供することができる。そのような変化は、TrustedOpenIdの概念にあてはまりうる。たとえば、あるそのような変化を、構成証明および/または潜在的に矯正を介して、TGSによって発行されたSTおよび/またはクライアントの状態を個々に取り扱うこととすることができる。すなわち、TGSは、特定の状態のクライアントが特定のサービスにアクセスすることを可能にすることができるポリシを実施することを可能にされ得る。もう1つのそのような例を、たとえばその状態の構成証明のためにサーバにチャレンジすることによるなど、クライアントがサービスにアクセスする前にTGSがそのサービス自体を妥当性検査することを可能にすることとすることができる。したがって、TGSまたはたとえばTrustedOpenIDの場合にOpenIDプロバイダは、相互に受け入れられかつ/または信頼できる状態にあるクライアントおよびサーバが通信関係に入ることを保証する調停物として働くことができる。多数のクライアントがある場合には、これが、サービスに対する高すぎる負荷に寄与する可能性があり、この寄与は、いくつかのケースにあてはまる可能性がある。負荷は、たとえば低い頻度でサービスを妥当性検査することなどによって軽減され得る。3GPPのM2Mmachine-to-machine通信に、並列問題がある場合がある。たとえば、既存のネットワークインフラストラクチャを変更せずに半自律的にM2MEを妥当性検査することが、問題を提示する場合がある。提示される信頼されるアイデンティティ管理IdM:identitymanagementの概念を、このためにオペレータの従来のAAAauthenticationauthorizationaccountingインフラストラクチャを使用可能にするための基本構成要素とすることができる。RADIUSremoteauthentificationdial-inuserserviceの信頼されるバージョンまたは類似物を適用することができる。trustedopenIDTOpenIdのシステムおよび方法を提供することができる。TrustedOpenIDエンティティは、1ユーザたとえばサービスにアクセスするユーザ、2OpenIDプロバイダ、3ユーザのTPMからのAIKを証明するPCA、および/または4OpenID認証を使用するサービスプロバイダを含むことができる。図2に、trustedOpenIDに関連する例示的なコールフロー200を示す。コールフロー200を、たとえばTrustedOpenIDを使用してサービスにアクセスする時に実行され得るプロトコルとすることができる。本明細書で議論されるように、クライアント/ユーザまたはユーザプラットフォーム210、サービスプロバイダ215、およびアイデンティティプロバイダ220例のOpenIDプロバイダとして図示は、お互いの間の通信のために構成される。TrustedOpenIDを使用する時に、クライアント/ユーザプラットフォーム210は、サービスプロバイダ215との初期接続を行うことができる。クライアント/ユーザプラットフォーム210は、そのウェブブラウザ225を使用して、ウェブページアクセスメッセージ227を介してサービスプロバイダウェブページindex.jsp235として識別されるにアクセスすることができる。クライアント/ユーザ210が、たとえばユーザのOpenIDURIを使用してログインすることを望む場合には、サービスプロバイダ215は、所与のURIに接続し、したがって、主張されるアイデンティティをホスティングするOpenIDプロバイダ220のアドレスを取り出すことができる。サービスプロバイダ215にあるindex.jspページ235は、OpenIDログオンフォームメッセージ229を介してURIを要求し、OpenIDアイデンティティメッセージ231を介して、主張されるアイデンティティをホスティングするOpenIDプロバイダ220のアドレスを取り出すことができる。次に、サービスプロバイダ215は、OpenIDプロバイダ220との関連付けを形成することを試みることができる。OpenIDプロトコルに従って、サービスプロバイダ215は、関連付けメッセージ241を介してOpenIDプロバイダ220に関連付けることができる。これは、関連付けメッセージ243を介する要求、主張されるアイデンティティ、および/またはリターンURLのセキュア交換を含むことができ、関連付けメッセージ243に対して、クライアント/ユーザプラットフォーム210は、認証が成功の場合にサービスプロバイダ215および/またはOpenIDプロバイダ220によってリダイレクトメッセージ247を送信され得る。これは、consumer_redirect.jsp240によるなど、サービスプロバイダ215で、および/またはprovider.jsp245によるなど、OpenIDプロバイダ220で実行される。関連付けの後に、クライアント/ユーザプラットフォーム210を、OpenIDプロバイダへのリダイレクトメッセージ249を介するなど、OpenIDプロバイダ220のprovider.jspウェブページ245にリダイレクトすることができる。リダイレクションアドレスを、ユーザが供給する識別子から取り出すことができ、このユーザが供給する識別子は、OPページにリダイレクトされるクライアント/ユーザプラットフォーム210が、その識別子を供給したものと同一のエンティティであることを保証することができる。リダイレクトを、ブラウザをOPログインページに直接にリダイレクトできるHTTPリダイレクトを介して実行することができる。次に、クライアント/ユーザプラットフォーム210を認証することができる。OpenIDプロバイダ220は、provider.jspウェブページ245からprovider_authorization.jspウェブページ255に切り替えて、クライアント/ユーザプラットフォーム210を認証することができる。クライアント/ユーザプラットフォーム210に、認証を要求するprovider_authorization.jspウェブページ255を与えることができる。ユーザは、provider_authorization.jspウェブページ255上のリンクをクリックすることによって、要求を開始することができる。これは、TTverifier258などの新しいバックグラウンドスレッドを開始し、このバックグラウンドスレッドは、チャレンジメッセージ252を介してチケットサーバ250にチャレンジする。provider_authorization.jspウェブページ255は、クライアント/ユーザプラットフォーム210をprovider.jspウェブページ245に戻ってリダイレクトする。provider.jspウェブページ245は、TTverifier258が終了し、チャレンジ回答メッセージ254で供給されたチャレンジの結果を評価するのを待つ。本明細書で説明されるように、チケットサーバ250などの信頼されるチケットサーバTTSは、チケットを含む適当な回答を生成するのにTPM機能性を使用することができ、かつ/またはTPM270、PCA275、および/もしくはたとえば証明書を保持できる記憶媒体280と相互作用することができる。プロトコルの他の部分は、OpenIDプロトコルを使用することができる。OpenIDプロバイダ220および/またはクライアント/ユーザプラットフォーム210は、認証トークンが変更され得るので、TPMの生成するTCTicketを使用することができる。認証が成功したとすると、クライアント/ユーザプラットフォーム210を、サービスプロバイダにリダイレクトすることができる。provider.jspウェブページ245は、リダイレクションメッセージ262をクライアント/ユーザプラットフォーム210に送信することができる。リダイレクションメッセージ262は、サービスへリダイレクトメッセージ264を介して、サービスプロバイダ215にあるconsumer_returnurl.jspページ265にクライアント/ユーザプラットフォーム210をリダイレクトすることができる。consumer_returnurl.jspページ265は、リダイレクトが関連付けられたOpenIDプロバイダ220に由来することをチェックし、サービスメッセージ267を介してクライアント/ユーザプラットフォーム210にアクセスを付与することができる。図3Aおよび図3Bに、チケットサーバ305とチケットチャレンジャ310との間の信頼されるチケットサーバチャレンジ-レスポンスに関連する例示的なコールフロー300を示す。記憶媒体320およびTPM325を使用することができる。チケットサーバ305は、クライアント上のサービスアプリケーションとして動作することができる。チケットサーバ305は、事前定義のポート上でリスンlistenし、チャレンジを待つことができる。チャレンジメッセージ327ユーザがたとえばOpenID内で使用することを望むアイデンティティと、サービスプロバイダで発行されたサービス要求とを含むの受信時に、ユーザに、肯定応答メッセージ329を使用してチャレンジを許容するように要求することができる。ユーザは、チャレンジを拒否するオプションを有することができる。拒否される場合には、OpenID認証が失敗しうる。チャレンジが受け入れられる場合には、ユーザに、所与のアイデンティティに対応するAIKのパスワードを入力するように、およびチケットサーバ305でストレージルートキーSRKパスワードを入力することによってTPM325使用を認証するように、促すことができる。次に、SRKを、TPM保護された鍵にアクセスできるTPMコマンドに含めることができる。次に、チケットサーバ305は、集合的に335として示されているように、このアイデンティティのAIK証明書などの以前に獲得された証明書を証明書記憶媒体320から取り出すことを試みることができ、この証明書は、本明細書で議論するように、システム状態情報取出345および/またはTCTicket生成350に使用され得る。証明書は、PCA315などのPCAとの以前のAIK証明に由来するものとすることができ、証明書記憶媒体320など、システム上のローカル証明書ストレージから取り出され得る。証明書が、ローカルストレージ内で使用可能ではないまたは、ローカルストレージ内のAIKに関する証明書が満了しているか、無効になる場合には、AIKによって表されるアイデンティティの別の証明書を、PCA315に要求することができる。証明書を証明書記憶媒体320内で見つけることができない場合には、ユーザは、AIK証明プロセスを受け、かつ/またはAIKの証明書を入手するために、接続すべきPCA315を選択することができる。ユーザは、TPM325の正しい所有者パスワードを供給することができる。これは、TPM325の所有者以外の人による悪意者のアイデンティティの作成を防ぐことができる。ユーザ入力を、チケットサーバ305によってTPM325に転送することができ、TPM325では、パスワードが評価される。チャレンジの受入に応答して、チケットチャレンジャ310は、ランダムナンスrandomnonce337を作成することができる。チケットサーバ305は、ナンスNONCEメッセージ339を介してチケットチャレンジャ310からランダムナンス337を受信することができる。集合的に345として示されているように、ナンスを含むシステム構成を記述するプラットフォーム構成レジスタPCR:platformconfigurationregisters値のAIK署名された引用QquoteQを、TPM325から取り出し、システムの状態に関するステートメントを作ることができる。次に、チケットサーバ305は、集合的に350として示されているように、TCTicketを作成することができる。TCTicket作成350は、要求および/またはアイデンティティに署名するのに使用できる鍵のTPMによる作成たとえば、RSA鍵対などを含むことができる。本明細書で説明されるように、この鍵を、CertifyKey動作を使用してAIKを用いて証明することができる。すなわち、TPMは、証明ステートメントおよび束縛を作成するのにこの作成された鍵対について関数CertifyKeyを使用することができ、ここで、束縛は、AIKおよび/またはPCAからのAIK証明書への信頼のチェーンchainoftrustを作成することを指す。作成された鍵が成功して証明される時には、その鍵を、証明された署名する鍵CSKと称することができる。1つのTPM内に複数のCSKおよび/または複数のAIKがあるまたは、TPMによって保護されるセキュアストレージ内でTPMによって保護される場合がある。TCTicket350を検証するのに必要な情報を、TCTicket350内に含めることができ、その結果、受信する当事者たとえば、図3Aおよび3Bのチケットチャレンジャ310などが、TCTicket350を簡単に検証できるようになる。平文測定ログMLおよび/または引用Qと一緒に、TCTicket350を含むレスポンスを、TCT、Q、MLメッセージ352を介するなど、チケットチャレンジャ310に送り返すことができる。CH-RESPONSEメッセージおよびACKメッセージ集合的に351を、次のメッセージがTCTicket350、引用、および/またはMLを含む可能性があることを受信する当事者たとえば、チケットチャレンジャ310などに知らせるためのプロトコルシグナリングメッセージとすることができる。図3Aおよび3Bは、図2のTTVerifierスレッド258の内側動作を表すことができる。OpenIDプロバイダは、同時に複数の要求を処理することができるので、各要求するクライアントが、反射攻撃replayattacksを防ぐために新しい、新鮮な、および/または一意のチャレンジを得る可能性がある。メッセージ355を介するTCTicket350の肯定応答時に、チケットチャレンジャ310は、抗反射保護antireplayprotectionとしてナンス337を含むTPM325からのAIK署名された引用と、平文測定ファイルと、署名されたアイデンティティストリング、署名された要求ストリング、CSKの公開鍵部分、CSKの公開鍵部分に対するAIK署名、および/またはPCA315によって発行されたAIK証明書を含むTCTicket350というデータを有することができる。クライアントを認証するために、チケットチャレンジャ310は、特定の順序に従わずに、集合的に360に示された、1AIK証明書を妥当性検査しタイムスタンプ妥当性情報を、たとえば使用カウンタの値として取り込むこともできる、2AIK証明書に対するPCA署名を検証し、3TCTicket350内のCSK公開鍵ハッシュに対するAIK署名を検証し、4TCTicket350内のサービス要求およびアイデンティティに対する署名を検証し、測定リスト内のエントリを妥当性検査し、かつ/または6実際の引用されたPCR値が測定リストMLに対応することを検証すること、を実行することができる。AIK証明書の妥当性検査では、検証できるものは、ローカルクライアント自体の保護されたカウンタ値が、AIK証明所内で示され得る最大数にまだ達していないかどうかである。ローカルクライアントの保護されたカウンタ値は、たとえばopenIDクライアントの証明書および/またはソフトウェアのインストールの回数を示すことができる。この検証プロセス内のあるアイテムが合格しない場合には、クライアントを認証することができない。たとえばAIK証明書-証明されたCSK-署名された要求など、特定の証明書チェーンを、チケットサーバ305およびPCA315によって作ることができる。検証状況メッセージ365を、ユーザに送信することができる。これは、たとえば、図2のリダイレクションメッセージ262によっても示される。この場合に、メッセージ262は、ユーザのブラウザをサービスプロバイダのリターンurlにリダイレクトするか、ユーザをサービスプロバイダで認証するかのいずれかを行うことができる。上記の検証が合格しない証明書不合格および/またはシステム完全性不合格場合には、リダイレクトは、ユーザを、OpenIDプロバイダの認証に不合格のページへ送ることができる。不合格の認証の場合には、カスタマイズされた結果ページをOpenIDプロバイダで作成することができる。カスタマイズされた結果ページは、不合格の原因を示すことができる。これは、どのモジュールまたはソフトウェアが完全性チェックに合格しなかったのかを示すことができ、かつ/またはこれを、ユーザに次のステップを提案するかユーザのシステムを信頼できる状態に戻すシステムにてこ入れすることができる。本明細書の開示を考慮すると、PCA275を、特定のサービスプロバイダ215と共に使用されるすべての部分的アイデンティティについて1回呼び出すことができる。初期登録では、クライアント/ユーザプラットフォーム210は、そのプラットフォームアイデンティティを偽名の部分的アイデンティティに関連付けることができる。PCA275は、この偽名アイデンティティの証明書を提供し、かつ/またはプラットフォームアイデンティティへの偽名の関連付けを格納することができる。このデータは、プライバシに敏感である可能性があり、したがって、保護されなければならない場合がある。PCA275の位置付けは、現在のチケットシステムと比較して、追加のオプションを可能にすることができる。本明細書で開示される信頼モデルおよび方法は、アイデンティティプロバイダ220以外のユーザの選択した場所でのPCA275の配置を可能にすることができる。これは、ユーザがアイデンティティプロバイダIdPによって選択されたPCAを信頼しなければならない可能性があるので、よりプライバシフレンドリではない可能性がある。平文測定ファイルを、ローカルクライアントデバイスによって実行される測定に関する情報、たとえば、機密性保護のために暗号化される測定値たとえばプラットフォームに束縛される鍵を使用するなどおよび/または個々の測定ファイルを要約する値を有することのできる他のタイプのファイルによって置換することができる。例としては、たとえば個々のコンポーネントではなくコンポーネントのグループの完全性を示す複数の個々の測定ファイルとすることができる。そのようなコンポーネントは、たとえば、ローカルクライアントプラットフォームの特定の機能性および/またはプロパティを集合的に実施できるグループに属することができる。チケットサーバ305とチケットチャレンジャ310との間の使用される認証プロトコルたとえば、OpenIDIdPプロトコルなどに応じて、プロトコルをチャレンジレスポンスプロトコルに縮小することが可能である場合がある。チャレンジレスポンスプロトコルは、1チケットチャレンジャ310が、challengeid,reqおよび/もしくはナンスをチケットサーバ305に送信でき、かつ/または、2チケットサーバ305が、TCT、引用Q、および/もしくは測定リストMLを応答できる、を含むことができる。そのようなプロトコルは、OPにあるものなどのチケットチャレンジャ310とクライアント/ユーザマシンにあるものなどのチケットサーバ305との他のプロトコルでの通信のより簡単な統合を可能にすることができる。たとえば、そのような統合を、たとえば単純なチャレンジ/レスポンス方式を使用できるHTTPプロトコルを使用して実行することができる。ユーザ認証を、図3Aおよび図3Bに示されたチャレンジレスポンスでOpenIDを使用して行うことができる。ユーザは、ユーザパスワードを入力することができる。ユーザパスワードは、OpenIDに以前に登録されている場合があり、その結果、チャレンジレスポンスに含まれる場合に、同一のパスワードは、ユーザが最初の事例でそのパスワードを登録したのと同一の個人であることを示すようになる。ユーザパスワードは、たとえば事前に共有される秘密から導出されるデータなど、ある種の他の証拠を示すことができる。TOpenIDでは、ユーザ認証とデバイス信頼構成証明devicetrustattestationとの両方を、本明細書で説明されるように達成することができる。ユーザ認証を達成できるのは、ユーザが既に、たとえばユーザデバイスおよび/またはユーザデバイスにハード束縛されるTPMのAIKおよび/またはCSKの証明書をOpenIDプロバイダに事前に登録している可能性があるからである。チャレンジレスポンスのステップでは、ユーザは、これらのAIKおよび/またはCSKの秘密鍵を用いて署名され得るデータを送信することができる。したがって、OpenIDプロバイダは、これらの鍵の公開部分の検証時に、および/またはユーザが事前に登録されたものと同一のAIKおよび/または同一のCSKを使用しつつあることの検証時に、チャレンジレスポンスを送信するのにそのデバイスを使用したユーザが、それに事前に登録したのと同一のユーザであることを知ることができる。たとえば、ユーザデバイスは、同一のハード束縛されるTPMをその上に有することができる。デバイス信頼構成証明を達成することができる。たとえば、デバイス信頼構成証明を達成できるのは、OpenIDプロバイダが、PCRのTPM_Quote、測定ログ、および/またはチケットの一部たとえばユーザIDまたは要求などが今や検証されたAIKCSKを使用して署名されているかどうかを検証できるからである。デバイス信頼構成証明を達成できるのは、OpenIDプロバイダが、PCRのTPM_Quote、測定ログ、および/またはチケットの一部が実際に期待される比較結果を生じるかどうかを検証できるからでもある。両方が一致する場合には、OpenIDプロバイダは、ユーザがOpenID要求を送信するのに使用したデバイスが実際に信頼できることを検証することができる。一例によれば、ユーザおよび要求の検証が達成されるが、PCR値と測定ログとの比較に合格しない場合には、OpenIDプロバイダは、デバイスが危険にさらされた可能性があり、期待されるものとは異なる構成状態にあることを示す前に、以前に登録された同一のデバイスから送信された信頼関連のデータを知ることができる。TOpenIDは、OpenID仕様に違反してはならず、かつ/またはTOpenIDは、OpenID仕様に対する変更なしでOpenIDに統合され得る。OpenIDアイデンティティに関する複数の認証オプションが、可能であり、実施される可能性がある。プロトコルフローを、標準化されたフローに分離することができる。プロトコルフローは、間接通信を介して行われ得る、依拠当事者RP:relyingpartiesおよびIdPの相互作用を記述することができる。たとえば、RPおよびIdPの相互作用を、ユーザのブラウザを異なるウェブページにリダイレクトすることおよび/またはメッセージのHTTPフィールド内で必要なデータをトランスポートすることによって、行うことができる。図4に、trustedOpenIDに関連する例示的な方法を示す。401、403、405、407、410、411、413、414、415、および416で、クライアントのブラウザ、OpenIDIdP、および/またはRPのインターワーキングを示すことができる。409では、ユーザ認証が行われるが、ユーザ認証を、意図的に未指定にすることができる。OpenIDは、ユーザが彼らのURLを所有することを検証するのにアイデンティティサーバが使用できる方法を指定しない場合がある。いくつかの場合に、この検証を、クッキーを介して実行することができる。サーバは、ユーザがコンシューマに対してユーザのアイデンティティを検証することを望むかどうかのプロンプトをユーザに出すことができる。図4に示されているように、プロトコルフローは、401で、ユーザが彼らのアイデンティティURLを入力することを含むことができる。コンシューマは、アイデンティティURLをフェッチすることができる。403では、コンシューマが、opened.serverリンク関係およびopened.delegateリンク関係の文書を処理することができる。委任する場合には、委任された文書をフェッチし、これをopenid.serverについて解析する。405では、コンシューマが、ユーザのアイデンティティサーバと共有される秘密を生成し、これをキャッシングすることができる。407では、コンシューマが、checkidのURLを構成し、ユーザのブラウザをこれにリダイレクトすることができる。409では、ユーザがURLを所有することをサーバがアサートできるかどうかを判定することができる。ユーザがURLを所有することをサーバがアサートできない場合には、410で、サーバは、コンシューマがcheckid_immediateを要求した場合に、checkid_setupモードのURLを返す。コンシューマがcheckid_setupを要求した場合には、サーバは、410でキャンセルを返すことができる。409で、ユーザがURLを所有することをサーバがアサートできる場合には、サーバは、411で、署名されたパラメータを有するコンシューマの要求で指定されたreturn_toURLへユーザのブラウザをリダイレクトすることができる。413では、コンシューマが共有される秘密をサーバのためにキャッシングさせるかどうかを判定することができる。コンシューマが共有される秘密をキャッシングさせる場合には、414で、署名されたパラメータを、その秘密を使用して検証することができる。413で、コンシューマが共有される秘密をキャッシングさせない場合には、415で、コンシューマが、association_handleおよびサーバによって返された署名を用いてcheck_authentication要求を生成することができる。416では、サーバは、署名が有効である場合にリターンすることができる。TOpenIDは、プラットフォーム妥当性検査データおよび/または認証ステップでのIdPによる完全性チェックを含むことができる。TOpenIDでの認証を、特定のTPMまたはたとえば単一のプラットフォームに束縛することができる。というのは、OpenID識別子を、TPM束縛されたAIKを使用して登録することができるからである。TPMおよび/またはAIK証明プロセスのセキュリティプロパティは、識別子を別のプラットフォーム上で使用できないことを保証することができる。IdPによる完全性妥当性検査は、正しいプラットフォームまたは、指定される場合に、信頼されるチケットサーバを含む信頼されるサブシステムが正しい構成で動作しつつあることを保証することができる。上の方法を、図2に示されたTOpenIDプロトコルフローに適用することができる。OpenIDアイデンティティプロバイダIdPおよび/またはユーザのシステムは、TPMおよびその完全性妥当性検査プロトコルを使用して認証ステップを実行する能力を含むことができる。これらの能力を、クライアントおよび/またはサーバ上のソフトウェアモジュールおよび/またはライブラリとして実施することができる。たとえば、これらの能力を、TTverifier258、チャレンジメッセージ252、チャレンジ回答メッセージ259、TPM270、PCA275、および/または記憶媒体280でなど、クライアント/ユーザプラットフォーム210および/またはOpenIDプロバイダ220で実施することができる。OpenIDのオープン概念は、非常にさまざまな異なるOpenIDIdP実施態様へとつながりうる。したがって、OpenIDIdPは、それら自体の中で区別するための概念を展開することができる。OpenIDIdPがそれら自体を区別するのに使用できる1つの機能を、たとえば、強化されたセキュリティ特徴のアサーションとすることができる。そのようなアサーションは、ユーザのOpenIDアイデンティティがたとえばHW束縛される場合など、そのアイデンティティが保護されることをユーザに保証することができる。ユーザに、そのようなIdPが、RPがそれらから受信される情報に頼ることを可能にすることができることを保証することができる。たとえば、銀行または他のセキュリティを要求するアプリケーションが、セキュリティを意識し証明されたOpenIDIdPのホワイトリストと共にOpenIDを使用することを可能にすることである。TOpenIDを実施する1つの方法は、プラットフォーム妥当性検査を実行するのに第2の非HTTPベースのプロトコルを使用することができる。たとえば、第2のプロトコルを使用して、チャレンジメッセージを、OpenIDプロバイダ220からクライアント/ユーザプラットフォーム210に送信することができ、レスポンスを、OpenIDプロバイダ220に送り返すことができる。これを、OpenIDプロバイダ220の主認証プロセスに制御を返すことができるバックグラウンドプロセスを介して実行することができる。主認証プロセスは、図2に示されているようにクライアント/ユーザプラットフォーム210からOpenIDプロバイダ220へのリダイレクトを用いて開始されている場合がある。その後、HTTPリダイレクトを、図2に示されているように、OpenIDプロバイダ220からクライアント/ユーザプラットフォーム210へ実行することができる。サーバおよび/またはユーザのデバイスの能力に応じて、異なるプロトコルを使用してデータを転送することができる。サービスアクセス用の証明書すなわちチケットを作るエンティティを、クライアント内に組み込むことができる。これを、たとえば図2に示されたチケットサーバ250などのクライアント内の信頼される機能エンティティによるTKerberosのセキュリティに関して妥協せずに、実行することができる。チケットサーバは、OpenIDプロバイダに対してクライアントおよびそれ自体を妥当性検査することができる。セキュリティ情報および動作を、チケットサーバコンポーネント内に集中することができるので、チケットサーバは、AIK証明書および/またはCSKを正しく処理すると信頼され得る。チケットサーバは、AIK証明書および/もしくはCSKを他のプラットフォームに増殖させず、チケットおよび証明書を保護し、ユーザ認可によってセキュリティ動作証明書を保護し、一般的なウェブブラウザに統合され、これによってアクセスされるセキュアオプションを提供し、プラットフォーム妥当性検査データを収集し、処理し、送信し、かつ/または反射攻撃を識別するためにナンスの妥当性に基づくアクセス制御を提供すると信頼されることができる。特定の証明書チェーンを、本明細書で説明されるように、チケットサーバおよびPCAによって作成することができる。TOpenIDでの証明書チェーンは、AIK証明書-証明されたCSK-署名された要求とすることができる。TKerberosシステム内にPCAを配置する実施態様は、次を含むことができる。OpenIDプロバイダ内にPCAを含めることは、複雑さを減らすことができる。それを、ウェブフォームを介するOpenIDプロバイダへの登録のシームレス置換とすることができる。TOpenIDでは、ユーザは、1そのAIK証明書をTOpenIDプロバイダによって受け入れることができる任意の外部PCAを選択し、かつ/または2TOpenIDプロバイダによって直接にまたは間接に提供されるPCA機能性を使用することができる。そのセキュリティアーキテクチャに起因して、TOpenIDは、OpenIDベースのシステムに関する特定の脅威を軽減することができる。TKerberosでは、AIK証明書が、クライアント上で可視であるのではなく、TGTで暗号化され、TGSによって暗号化解除可能である場合がある。AIK証明書は、クライアントに既知とすることができ、たとえばプライバシを脅かすことができる隠された情報を有しないものとすることができる。OpenID実施態様は、OpenIDプロバイダログインフォームをユーザに提示することができる。ユーザは、自身の証明書を入力することができ、OpenIDプロバイダは、クッキーをクライアントに発行することができる。次に、このクッキーを、各後続のOpenID対応サービスアクセスに使用することができる。これは、OpenIDプロトコルに対する複数の攻撃の可能性、たとえば、1OpenIDプロバイダへのログインに使用されるユーザ証明書に対する直接攻撃偽OpenIDプロバイダページを用いるフィッシングが、大量のユーザ証明書を露出させ、アイデンティティ窃盗を可能にする可能性がある、または2アイデンティティ窃盗につながる可能性がある、認証の後のクライアントのコンピュータからのクッキーの再利用、コピー、および/または窃盗を用いる攻撃につながる可能性がある。trustedOpenIDの使用によって、攻撃を軽減することができる。ユーザパスワードを、ローカルとし、かつ/またはローカルの信頼されるチケットサーバに供給することができるので、証明書フィッシングを阻止することができる。偽名アイデンティティを、プラットフォームに束縛することができる。すなわち、偽名アイデンティティは、別のデバイスにコピーすることができない。クライアントのプラットフォーム上に格納されるクッキーがないものとすることができる。これは、たとえばコンピュータが複数の人によって共有される時など、ローカル再利用の脅威を防ぐことができる。一例では、ユーザAが自身のOpenIDアカウントにログインし、サインアウトするのを忘れる場合に、ユーザBは、ユーザAに成りすますために格納されたクッキーを使用することを試みることができる。そのような再利用は、trustedOpenID認証をウェブブラウザにシームレスに統合することによって防ぐことができる。ユーザが、trustedOpenIDを使用してサービスにアクセスすることを望む時に必ず、OpenIDプロバイダは、チケットサーバに関する新しいチャレンジを作成することができる。ユーザは、たとえば、チャレンジに答えるために必要になる可能性があるローカルAIKパスワードをユーザに要求するプロンプトなど、自身の信頼されるチケットサーバアプリケーションからのプロンプトを見ることができる。チケットサーバは、このAIK認証秘密を格納してはならない。同一のプラットフォームにいる別のユーザBがそのサービスにアクセスすることを望む場合に、チケットサーバは、やはり、OpenIDプロバイダによってチャレンジされ得、かつ/またはユーザBは、ユーザAのローカルAIKパスワードユーザBには未知を提供しなければならないものとすることができる。これは、クライアントのプラットフォームに格納されないものとすることができる使い捨てクッキーの使用を必要とする可能性がある。発行されたクッキーを、ターゲットプラットフォームおよび/またはユーザがこれを暗号化解除し、認証トークンとして使用できる形で暗号化することができる。OpenIDプロバイダは、公開CSKを使用してクッキーを暗号化し、かつ/またはこれをクライアント側のチケットサーバに送信することができる。TPMを使用して、必要な時にクッキーを暗号化解除することができる。暗号化解除は、ユーザに、たとえばローカルCSK秘密を用いるなど、CSK使用のために認証することを要求することができる。チケットサーバは、クッキーが暗号化されて格納され、必要な場合に暗号化解除されることを保証することができる。暗号化されたクッキーの格納および/または使用のもう1つの実施態様を、シールする動作が行われる時にクッキーをプラットフォームの完全性に束縛する形でクッキーを格納するためのコマンドTPM-Sealの使用とすることができる。以前にシールされたクッキー値が次に取り出される時に、プラットフォームの完全性が、シールする動作が行われた時の値と同一であることを検証することができる。この例では、プラットフォームの完全性がその以前の値と一致する時に、シールされたクッキー値を取り出すことができる。TrustedOpenIDを、TrustedGoogleAPIに拡張することができる。OpenIDおよびOAuthを組み合わせることは、たとえばOpenIDプロバイダでの伝統的なログイン以外のさらなるユーザ対話が要求されないように、OpenID認証プロセスに頼ることができる。ユーザのTPMにOpenIDチャレンジに署名させる代わりに、TPMは、ウェブアプリケーションの要求を介してOpenIDプロバイダによって提示される組み合わされたOpenID/OAuthチャレンジに署名することができる。ユーザ識別および認可ならびにデーへのアクセスの受入に、TPMによってセキュアに署名することができる。TrustedOpenIDの文脈と同様に、ユーザに関するセキュリティを、1ログインおよび認可をハードウェアTPMにバインドすること、ならびに/または2クライアント上で動作する悪意のあるソフトウェアによる機密データの窃盗を防ぐためにOpenID/OAuthプロバイダによるオプションのプラットフォーム完全性検証を含めることによって改善することができる。完全性検証は、ウェブアプリケーションに関するセキュリティのレベルを高めることができる。サービスへのアクセスを、証明された完全性検証された状態のクライアントに制限することができる。これは、セキュリティおよびプライバシアプリケーションに関する新しいウェブサービスの確立を可能にすることができる。このプロセスは、否認防止を提供することができ、たとえば、OAuthアクセストークンに、TPMによって署名することができ、これは、一意に識別され得る。これは、ウェブアプリケーションのプロバイダによって実施され得る課金プロセスを容易にすることができる。署名は、ウェブアプリケーションプロバイダが、ユーザがサービスを要求し、サービスにアクセスしたことを証明することを可能にすることができる。TPMベースのユーザ認証は、プラットフォームアイデンティティがOpenIDアイデンティティにリンクすることを可能にすることができる。OpenIDプロバイダに、所与のプラットフォームの登録されたアイデンティティのデータベースを保持するように要求することができる。OpenIDプロバイダは、所与のプラットフォーム証明書によって、正当なユーザを攻撃者から区別することができる。別のプラットフォームからのログインの試みが検出される時に、OpenIDプロバイダは、1認証を拒否し、かつ/または2アイデンティティの正当な所有者が次にログインする時に、その所有者に通知することができる。OpenID/GBA認証方式とのTOpenIDの可能な統合を、NAF/IdPに、プラットフォーム完全性値を検証するためのTOpenIDIdPの能力を与えることとすることができる。NAF/IdPからのGBA認可ヘッダは、TOpenIDプロトコルからのチャレンジたとえば、id、req、ナンスを直列化された形で含むことができる。受信時に、ME/UEは、チャレンジを直列化解除し、これを、信頼されるチケットサーバおよび認可ダイジェストを計算するのに使用できるGBA鍵導出関数に多重化することができる。次に、両方の戻り値、たとえば、信頼されるチケットサーバからの署名された引用およびMLとGBAプロセスからのダイジェスト値を、HTTP応答ヘッダ内でNAF/IdPに返すことができる。認証および信頼評価を組み合わせることができる。そのような組合せは、特定のUICCたとえば、GBAクライアントの使用を単一のプラットフォームに束縛することができる。NAFは、プラットフォームがある完全性証明された状態であり、プラットフォームを認証できたとえば、AIKによって、ユーザを認証できるたとえば、UICC/GBAの所有によって場合に、OpenID識別子を認可することができる。そのようなプロトコルは、単一UICCを有する単一の構成の単一のプラットフォームと共に、ユーザのOpenID識別子を使用するために、ユーザをロックすることを可能にすることができる。図5および図6は、OpenID使用のためにUICCたとえば、ユーザに関連するおよびWTRUを束縛することに関連する例示的な図である。図5に、例示的なコールフロー図を示す。図6に、コンポーネントの間の例示的な関係を示す。実施態様は、信頼されないWTRU要素、たとえばブラウザとのセキュア通信を保証することができる。図5を参照すると、例示的なプロトコルステップは、次のうちの1つまたは複数を含むことができる1ユーザが、RPへの接続を確立することができ、2RPが、OP/NAFとの関連付けを開始することができ、3RPが、WTRUのブラウザをOP/NAFにリダイレクトすることができ、4WTRUとOP/NAFとの間の通信が、認証の責任を負うことができるTTSを介することができたとえば、TTSは、GBAチャレンジと一緒にTOpenIDチャレンジを受信することができる、5TTSが、UICCへのセキュアチャネルを確立することができ、6TTSが、GBAチャレンジをUICCに転送することができ、7UICCが、OpenID/GBAプロトコルと同様にダイジェストを計算することができ、7aUICCが、GBAレスポンスをTSSに送信することができたとえば、OpenID/GBAダイジェストを用いて、8TTSが、TOpenIDプロトコルのプラットフォーム妥当性検査データ/構成証明データを取り出すことができ、ここで、プラットフォーム妥当性検査データ/構成証明データは、WTRUの信頼性の尺度たとえば、AIKを用いて署名されたSMLおよびPCR引用を含むことができ、9TTSが、UICCGBAレスポンスおよびプラットフォーム妥当性検査データ/構成証明データを含む順序正しくまとめられたレスポンス内でOP/NAFに応答することができ、10OP/NAFが、GBAレスポンスを検証し、プラットフォーム妥当性検査データ/構成証明データを用いて完全性を検証することができたとえば、SMLPCR引用が、OP/NAFによって以前に受信された以前に生成された基準値と一致することを検証する。これは、WTRUの現在のシステム状態が以前の状態と一致することを示すことができる、11OP/NAFが、WTRUのブラウザを介してRPに肯定のアサーションを発行することができるたとえば、RPへのMEのブラウザのリダイレクト動作の一部として。すなわち、NAFは、それがプラットフォーム妥当性検査データおよび/またはユーザを検証したことを示すプラットフォーム検証を送信することができる。プラットフォーム検証を、直接にまたは間接に通信することができるたとえば、プラットフォーム検証は、依拠当事者RPへのアクセスを付与されるWTRU/ユーザを含むことができる。TTSは、必ずしもUICCとのセキュアチャネルを確立しなければならないのではない可能性がある。2つの独立のセッションすなわち、UICCとOP/NAFとの間の1つのGBAセッションならびにTTSとOP/NAFとの間の構成証明セッションを実行することが可能である場合がある。OP/NAFは、両方のプロトコルが成功する場合に肯定のアサーションを発行することができる。そのような並列セッションシナリオでは、構成証明結果をGBAプロトコルの認証結果に束縛するために、OPが少なくとも内部的に両方のセッションをリンクすることが必要である場合がある。妥当性タスクvalidationtasksは、実行にネットワークおよびデバイス上の大量のリソースを必要とする可能性がある。妥当性検査されるデバイスは、たとえば新しい妥当性検査手順を受ける必要なしに、後続の認証手順またはネットワークコンポーネントとの相互作用のために妥当性検査情報を再利用することができる。たとえば、ネットワークとの以前の妥当性検査セッションから生成されたものとすることができる妥当性検査情報を再利用することができる。信頼されるチケットサーバは、次のように妥当性検査チケットまたは証明書を提供することができる。ネットワークに対するデバイスの成功の妥当性検査に続いて、MNOのネットワークの内部のOP/NAFエンティティは、チケットを発行することができ、このチケットは、要求があり次第他のネットワークへの再配送のためにデバイスに通信され得、またはネットワークエンティティがOP/NAFエンティティからチケットを間接的に入手できるように参照され得る。OP/NAFエンティティは、チケットと共に情報を含めることができ、その結果、チケットは、チケット/デバイス信頼性の指示を含むようになる。たとえば、OP/NAFエンティティは、タイムスタンプ、発信タイムスタンプoriginationtimestamp、チケットの寿命限度、チケットの終了日付、使用パラメータ限度などを提供することができる。時間情報は、ネットワークコンポーネントが、デバイスの信頼できる状態および査定が実行された時を確かめることを可能にすることができる。チケットを受信するエンティティは、デバイスとのセキュアトランザクションを行うのに満足に情報を検討することができ、またはデバイスへの信頼に関する特定のアプリケーションの必要に応じて再妥当性検査を強制することができる。そのようなチケットを、プラットフォーム妥当性検査および管理に使用することができる。チケットを、完全性保護し、かつ/または機密性保護することができ、その結果、チケットは、OP/NAFエンティティおよびデバイスに束縛されるようになり、チケットは、データが束縛されるデバイスまたはOP/NAF以外のエンティティによって変更できなくなる。デバイス内の信頼される環境TrE:trustedenvironmentは、チケットをセキュアに格納し、再妥当性検査を実行する必要なしにネットワークとの後続相互作用にそのチケットを使用することができる。チケットを、デバイスによって分配して、他のネットワークコンポーネントに妥当性検査状況データを提供することができる。デバイスは、チケットへの参照を循環させることができ、この参照から、他のネットワークエンティティは、妥当性検査情報を入手するためにOP/NAFエンティティに相談することができる。組み合わされたTOpenID/GBAの場合について、信頼エバリュエータ信頼評価器:trustevaluator、たとえばTTSから測定を受信し、この査定に基づいて妥当性検査またはプラットフォームの信頼性に関するステートメントを導出するためにメトリックを参照するため、これらの測定を比較可能でありうるエンティティの位置は変化しうる。図7に、TOpenID/GBAの場合の信頼エバリュエータとしてのプラットフォーム妥当性検査エンティティPVE:platformvalidationentityの例を示す。図7は、プラットフォーム妥当性検査エンティティPVE705、BSF710、UE720、OP/NAF730、およびRP740を含む。妥当性検査プロセスをMNOのネットワークの内部のOP/NAFエンティティ内に統合するのではなく、信頼査定に関する基準完全性メトリックスを既に所有している可能性がある既存のネットワークエンティティを再利用することが可能である場合がある。そのような例を、PVE705など、プラットフォーム妥当性検査エンティティと称する場合がある。PVE705は、基準メトリックスを備えることができ、受信した妥当性検査データを基準メトリックスと比較し、デバイスの信頼性に関するステートメントを発行することができる可能性がある。そのようなシナリオでは、OP/NAF730は、内部ネットワーク内の妥当性検査データをPVE705に転送することができ、PVE705は、信頼妥当性検査を実行することができる。信頼評価を、信頼されるサードパーティTTP:trustedthirdpartyによって実施することができる。MNO内部エンティティが、受信された妥当性検査データの妥当性検査を実行するのに使用不能である場合には、NAF/OPは、セキュアチャネルを介して外部の信頼されるサードパーティに妥当性検査データを転送することができる。次に、TTPは、検証および妥当性検査を実行し、プラットフォームの信頼性に関するステートメントをNAF/OPに戻って発行することができる。ユーザのプラットフォームの成功の認証および検証の後に、サービスプロバイダSPは、署名されたjava登録商標アプレットをWTRUに送信することができ、このjavaアプレットは、WTRUの信頼される環境TrEにインストールされ得る。TrEは、javaアプレットを信頼される環境にインストールする前に、たとえばIdPまたは信頼されるサードパーティTTPによって供給されたSPまたはRIM証明書からの署名および/または証明書を介して、アプレット完全性を検証し、セキュアUIに関するSPチャレンジに回答することができる。TrEは、セキュアUIを使用してアプレットをロードし、現在のアプリケーションがセキュア環境内で動作できることをユーザに示すことができる。この方式を、偽SPから保護することができ、たとえば、SPに、認証し、IdPに完全性を供給するように要求することができる。この方式を、たとえばIdPがTrE完全性および機能性を検証することと、チェックが成功である場合にチケットを発行することとによって、偽TrEから保護することもできる。分離された/サンドボックス化されたウェブブラウザを実施することができる。通常のブラウザ解決策とは異なって、これは、たとえばオンラインバンキング、ウェブメール、ビデオストリーミング、その他などのウェブアプリケーションの発行者向けとすることができ、彼らのウェブアプリケーションの特定のマニフェストを定義することができる。このディジタル署名されたマニフェストは、ウェブアプリケーションが接続すべき許可されるウェブサイトのリストおよびウェブアプリケーションがその中で動作しなければならないブラウザを含むことができる。vmイメージへのURLなどのこのブラウザの仮想化されたエンティティを、マニフェスト内で定義することができ、ウェブアプリケーションを他のウェブアプリケーションおよび/またはホストオペレーティングシステム0sから分離するために実施することができる。各サンドボックス化されたウェブアプリケーションを、たとえば信頼状態を提示するためにグラフィカル境界を使用することによってレンダリングすることができる。この概念を、XEN仮想化を使用して実施することができる。WTRUは、TTSを使用するプラットフォーム構成証明と、その後のデバイス上のTrE小さい信頼されるサンドボックス化されたJavaアプレットを実行する環境を使用するアプリケーション構成証明との両方を実行することができる。TTSおよびTrEが、両方ともWTRUデバイス内のある共通の信頼されるハードウェアコンポーネントの上に構築され、その機能を使用することができることに留意されたい。セキュアユーザインターフェースセキュアUIは、セキュリティを高めるためにTOpenIDおよびOpenIDを要求され得る。基本的なTOpenIDプロトコルは、その高められたセキュリティを信頼されるチケットサーバから導出することができ、信頼されるチケットサーバは、デバイス完全性情報を収集することができる。デバイス完全性情報を、OpenIDIdPによって評価することができる。デバイス上で動作するソフトウェアが、周知の信頼される状態である場合には、認証は成功しうる。認証を、TPMに格納されPCA証明されるAIKに束縛することができる。AIKを使用して、構成証明に使用されるPCR引用に署名することができる。認証を、所与の状態の所与のプラットフォームたとえば、TPMを有するデバイスを用いる実施態様に制限することができる。構成証明および完全性チェックを、ある種のコンポーネント、たとえば、TOpenIDのセキュア動作に必要なコンポーネントに制限することができる。そのような手法では、デバイスを、信頼される/セキュア部分と信頼されない部分とに分離することができる。信頼されるチケットサーバは、信頼される世界の内部の、信頼され、完全性がチェックされたアプリケーションとして動作することができる。ドライバを含む、ハードウェアへのアクセスを、信頼される世界内のサービスインスタンスによって保護することができる。デバイスの能力へのアクセスを、必要なAPIを信頼されない世界に提供できるこのサービスインスタンスを介して制限することができる。これらのAPIは、デバイス能力へのアクセスを提供し、アクセス制限を実施することを可能にすることができるセキュリティポリシフレームワークを備えることができる。IdPによる完全性チェックおよび検証が、デバイスの一部に制限される場合には、ユーザは、信頼されるチケットサーバを用いるOpenIDIDの使用を確認し、この入力が中間者攻撃maninthemiddleattackまたはmaninthedevice/maninthebrowser攻撃の形でインターセプトされまたは再生され得ないことを確認する必要がある場合がある。信頼される部分は、入力を保護し、ユーザがセキュアモードのデバイスを使用しつつある可能性があることをユーザに示すことができる信頼されるユーザインターフェースUIを提供することができる。例のインジケータを、デバイスプロセッサが信頼されるモードで動作しつつある場合に光ることのできる発光ダイオードLEDとすることができる。LEDを、信頼される要素またはセキュア要素によって制御することができる。ユーザがOpenIDチケットの使用のために証明書を入力しなければならない時には必ず、セキュアUIは、デバイスがセキュアモードで動作しつつあることを示すことができる。LEDなどのデバイスは、セキュアハードウェアインターフェースを介して保護された外部プロセッサインターフェースに接続されたあるマッピング可能アドレス空間内にあるものとすることができ、ここで、アクセスを、セキュアな信頼される環境に制限することができる。グラフィックスデバイスの保護されたフレームバッファの諸部分を使用することができる。他のドライバは、デバイスメモリのこの部分に書き込みまたはこれから読み取ることを許可されないものとすることができる。次に、セキュア/信頼されるドライバは、悪意のあるソフトウェアによるセキュアアイコンの表示を防ぐためにディスプレイフレームバッファに直接に書き込むことによってデバイスのディスプレイ上にグラフィカル情報を表示することによって、セキュアUIの使用を示すためにこのフレームバッファメモリを使用することができる。OpenID認証用のUIとして働くことができるブラウザを、完全性チェック検査し、信頼される世界に統合することができる。ブラウザが、信頼される部分に含まれない場合には、ユーザに、ユーザOpenIDログインが使用されるたびに、セキュアUIを介して同意を提供するように要求することができる。ユーザが、OpenID識別子を使用してサイトにログインすることを望む場合には、ブラウザは、信頼されるチケットサーバにチャレンジを転送することができる。信頼されるチケットサーバは、UIをセキュアUIに切り替え、ユーザに同意インターフェースを提示することができ、同意インターフェースは、認証を終了するためにセキュアUIと対話するようにユーザに要求することができる。信頼されるチケットサーバは、レスポンスを生成し、これをOpenIDIdPに転送し、潜在的に危険にさらされるブラウザをバイパスすることができる。TrustedOpenIDプロセスでは、WTRUのブラウザおよびユーザインターフェースを保護することができる。信頼されるビジュアルトークンTVT:TrustedVisualTokenを使用することができる。信頼されるビジュアルトークンは、次の技術的特徴のうちの1つまたは複数の組合せを含むことができる。ビジュアル構成証明は、ユーザのプラットフォームユーザが対話するデバイスが信頼できる状態であることをアテストする、あるビジュアル情報のユーザへの表示を含むことができる。そのようなビジュアル情報は、暗号化された形でプラットフォーム上に存在する、たとえばユーザに既知であるが他者に既知ではない、秘密のイメージを含むことができ、ここで、暗号化解除は、プラットフォームが事前に定義された状態である場合に許可されるものとすることができる。これを、シーリングと称する場合がある。ビジュアル構成証明を、追加のビジュアライゼーション法によって増強することができる。たとえば、特定の取引が行われることのデータたとえば、ユーザ認証、支払データなどを、ビジュアライゼーションに含めることができる。これは、キャプチャアンドリプレイcapture-and-replay攻撃をよりむずかしくすることができる。特権インジケータPrivilegedIndicator:PIは、プラットフォームの内部のエンドポイントが信頼される環境またはセキュア要素、たとえば、所望の取引において信頼できる可能性がある、ある実行スペースである、プラットフォームのセキュア入力パスたとえば、鍵とすることができる。ユーザは、自身の支配下のチャレンジ-レスポンス機構によってプラットフォームのビジュアル構成証明を制御することができる。ユーザは、取引たとえば、認証、オンライン支払などプロセス中のある点で、自身のプラットフォームにチャレンジを提示することができ、このチャレンジに対して、プラットフォームは、ビジュアル構成証明を応答することができる。これを、特権インジケータを使用して実施することができる。特権インジケータチャレンジを、取引中に手続的に使用し、これを迂回できないように取引と組み合わせることができる。上の特徴を、信頼されるビジュアルトークンTVTとしてのオンライン取引での使用のためにプラットフォーム内で組み合わせることができる。TVTは、たとえばソフトウェア信頼される環境内またはハードウェアセキュア実行環境スマートカードなど内で実現される、PIを介して提示されるユーザチャレンジに対してビジュアル構成証明を用いて事前に定義された形で応答できる、ユーザのプラットフォーム上の信頼できるエンティティとすることができる。TVTは、次の特徴のうちの1つまたは複数を有することができる。TVTの信頼できる状態をユーザに提供するTVTビジュアル構成証明を、プラットフォームの主または別の、専用ディスプレイ上でユーザに表示することができる。TVTは、ビジュアル構成証明のためにハードウェア保護されたたとえば、スマートカード、TPMシールされたなど秘密を使用することができる。TVTは、バイオメトリック入力など、ユーザを認証する方法へのアクセスを有することができる。TVTの信頼できる状態を、リモート当事者によって、たとえばリモート構成証明を使用することによって、妥当性検査することができる。TVTは、プラットフォームの他のコンポーネント、たとえばブラウザまたはオンラインバンキングアプリケーションを妥当性検査し、これらのコンポーネントの信頼性に関する情報をビジュアル構成証明に組み込むことができる。TVTは、特定の取引に固有のデータへのアクセスを有することができ、意味のある一意の形でそのようなデータをビジュアル構成証明に組み込むことができるものとすることができる。ビジュアル構成証明にTVTによって表示されるものの基本的なモーダリティは、特定のユースケースで必要に応じて組み合わせることができる、次のうちの1つまたは複数を含むことができる。TVTは、ユーザに関連する情報、たとえば、ユーザが記録した秘密、個人情報などを表示することができる。TVTは、時間依存とすることができるTVT固有の秘密を表示することができる。TVTは、取引固有データ、たとえば取引番号、取引量、通貨タイプなどを表示することができる。TVTは、ユーザ通知を表示することができ、たとえば、ユーザに、たとえば特権インジケータを押したままにしながら指紋リーダーを使用することによって、取引を認可するように促すことができる。取引でのTVTの基本的な使用は、ローカルにまたはリモート当事者へのいずれかの、ユーザ認証の使用である。このプロセスは、ログオンと称する場合があるが、次の特徴のうちの1つまたは複数を含むことができる。ユーザが、プラットフォームまたはリモートサービスにログオンすることを望む時には、ユーザは、ウェブ上のサービスのログオンページへのログオンアプリケーションまたはブラウザを開くことができる。ユーザは、PIを押し、ログオンに関するビジュアル構成証明を入手することができる。図8に、一例を提供する。この形のビジュアライゼーションを、TVTの状態に対してアテストする秘密イメージを含めることによって増強することができる。図9に例を示す。TVTビジュアル構成証明のさらなるセキュリティ強化を、追加情報、たとえばランダムに現れる、削除がむずかしい、新鮮な、機械依存の、人間可読情報を含めることによって達成することができる。図10に例を示す。ユーザログオンに関するTVTのアクティビティを、リモート当事者、たとえばユーザ認証を要求するウェブサービスによってトリガすることができる。リモートサービスは、それがユーザ認証を必要とすることをプラットフォーム上のTVTにシグナリングすることができたとえば、相互に認証されたチャネルを介して、このシグナリングの際に、TVTは、包括的ログオン通知を表示する。たとえば、ユーザは、PIを押すことができ、TVTは、それ自体のビジュアル構成証明を実行する。ユーザは、本明細書で説明される直接ログオン変形形態と同様に、たとえばバイオメトリック入力を使用して、ローカルに認証することができる。図11に、例示的なビジュアル指示を提供する。図12ならびに以下の説明は、trustedcomputing概念に基づくプラットフォーム上のTVTの例示的実施態様を提供する。以下は、例としてMicrosoft登録商標Windows登録商標ネットワークドメインを含む場合があるが、そのような実施態様に限定されない。次の頭字語が、図12および以下の議論で使用される可能性がある。TCB信頼されるコンピューティングベースBIOバイオメトリック認証機能RoT信頼のルートMODLSASS変更されたLocalSecurityAuthoritySubsystemローカルユーザログオンおよびネットワークユーザログオンの責任を負うMicrosoftWindowsコンポーネントREQ要求DECENCの暗号化解除鍵ENCTVT秘密データを暗号化する鍵システムスタートアップ時のセキュアブートプロセスまたは認証されるブートプロセスでは、プラットフォームのRotは、TVTアプリケーションの状態を測定し、かつ/またはたとえばプラットフォームのPCRプラットフォーム構成レジスタ1b内に格納する1aことができる。TVTアプリケーションを、ランタイムのTVTの保護を含む信頼される環境に含めることができる。測定機能ならびにRoTは、プラットフォームのTCB内、たとえば、システム動作中に無条件で安全と考えられるコンポーネントのセット内に含まれる。ユーザが、このプラットフォームを使用してネットワークドメインにログオンすることを望む時に、ドメインコントローラは、プラットフォームにユーザ証明書を要求する2ことができる。TVTアクティブ化は、この時点で発生することができ、リモートに要求されたTVTユーザログオンが、本明細書で説明されるように開始され得る。ユーザに、PIを使用するように通知することができ、たとえば、3での使用を参照されたい。PI信号は、TCB内に含まれるあるPI機能性に送信される。PI機能性は、TVTマスタ暗号化解除鍵Decをシール解除し4、TVTの状態を引用して、プラットフォームRoTにDecのシール解除要求を発行することができる。RoTsは、状態をチェックし、たとえば状態が正しい場合に、Decを暗号化解除する5ことができるシール解除。Dec鍵は、鍵下位層のうちでTCBの内部での使用に制限された部分である鍵、たとえばTPM鍵階層の鍵を指すことができる。Decを使用して、対応する暗号化鍵Encを用いて暗号化されたTVTビジュアル構成証明シードを暗号化解除することができる。PI機能性は、ユーザに対してビジュアルにアテストするようにTVTアプリケーションに指令する6ことができる。TVTアプリケーションは、TVTシードの暗号化解除を要求する7ことができ、この暗号化解除は、Decを使用して実行され8得、TVTシードは、TVTアプリケーションに提供され9得る。これらを使用して、TVTアプリケーションは、たとえばバイオメトリック入力BIOを使用する、ローカルユーザ認証の要求を含む、ビジュアル構成証明を実行する10ことができる。ユーザは、BIOに認証する11ことができ、BIO機能性は、認証成功をTVTにシグナリングする12ことができる。TVTは、そのユーザアカウントデータストレージにユーザ証明書、たとえばネットワークログオンに使用されるユーザ名およびパスワードを要求する13ことができる。そのデータを、暗号化解除し、TVTに送信することができ、TVTは、これをログオンアプリケーションLSASSに提供する14ことができ、ログオンアプリケーションLSASSは、これをネットワークドメインコントローラに転送することができる。TVTによって使用される秘密は、2つのクラスを含むことができる。TVTシードは、ユーザにビジュアライズし、リモートエンティティとセキュアに通信するのにTVTが使用する秘密を含むことができ、この秘密は、ビジュアライゼーション用のシード、TVTの個々の秘密たとえば、プラットフォームに固有、他のエンティティとのセキュア通信用のTVT証明書、ユーザ定義のパラメータ、アプリケーションごとの秘密、ユーザが記録した秘密などのうちの1つまたは複数を含むことができる。ユーザアカウントデータは、パスワード金庫passwordvaultに似たものとすることができるTVTの機能を表すことができる。ユーザアカウントデータは、バイオメトリックユーザ基準データ、ドメイン、リモートサービス、およびユーザ名のリストおよび関連付け、ユーザ証明書、たとえばパスワードまたはパスワードのハッシュ値、リモートサービスまたはドメインコントローラの認証用の証明書などのうちの1つまたは複数を含むが、これらに限定されない。相互認証を、RPとTTSとの間で行うことができる。OpenIDプロトコルを、RP-ユーザインターフェースをどのようにして保護できるのかおよびユーザを悪意のあるRPからどのようにして保護できるのかを含むように定義することができる。悪意のあるRPは、ユーザがRPでログインフィールドに自身のアイデンティティたとえば、OpenID識別子を入力する時に、OpenIDプロトコルに対する脅威を押し付ける可能性がある。ユーザは、基礎になるプロセスが何を行いつつあるのかを理解しない場合があるが、ユーザを、ユーザが訪れるサイトについてユーザのアイデンティティをOpenIDを使用して管理できるIdPページにリダイレクトすることができる。IdPでは、ユーザは、自身の証明書たとえば、パスワードを入力することができ、リダイレクトされ得る。しかし、ユーザが、やはりOpenID対応である別のページを訪れる時に、IdPは、パスワードをもう一度要求しないものとすることができ、その代わりに格納されたクッキーを使用することができる。悪意のあるサイトのRPは、ユーザ証明書パスワードを盗むことを目指す偽サイトである可能性がある、説得力のある外見のIdPへユーザをリダイレクトできる可能性がある。次に、偽IdPは、実際のIdPを用いてユーザをOpenIDにログインさせることができ、ユーザは、異常を経験しない可能性がある。攻撃の影響は、IdPが、ユーザがOpenIDを使用してログインしたサイトのSSOポイントとして働くことができ、したがって、攻撃者がユーザから多数のアカウントを盗むことができるとい事実によって増やされる可能性がある。単一の悪意のあるRPウェブサイトを使用して、パスワードを収集する偽IdPページを訪問するようにユーザをだますことができる。RP認証を、TTSを使用して行うことができる。パスワードフィッシング攻撃を、次のうちの1つまたは複数を使用することによって軽減することができる。MicrosoftInformationCardsを、たとえば盗まれる可能性があるパスワードをユーザが入力しなくてもよくなるように、証明書として使用することができる。InformationCardsは、ユーザに、スクリーン上でそこから選択すべき複数のカードを示すことができるMicrosoft社の技術である。ユーザは、サービスに認証するためにカードを選択することができる。InformationCardsは、アイデンティティに関する所有の証明を提供するために、暗号証明を使用することができる。これらの証明を、再利用可能ではないものとすることができ、再生することができず、したがって、パスワードハーベスティングサイトpasswordharvestingsiteによる取込は、OpenIDアイデンティティへのアクセスをもたらすことができない。各RPを、ユーザの側で認証することができる。そのような認証を、ユーザがOpenIDに期待しているSSO経験に干渉しないセキュアな形で実行することができる。TOpenIDでは、TTSを、RPからの所与の証明書を検証するエンティティとすることができる。RPへのHTTPS接続を使用する時に、TTSは、ブラウザのプロキシとして働き、ブラウザからOpenID対応サイトへの呼出しをインターセプトすることができる。そのようなインターセプト機構は、HTTPGET要求の後にRPからブラウザに送信されるページ内のログインフォームを認識することができる。その後、TTSは、ドメイン証明書を要求し、その妥当性をチェックすることができる。証明書が有効である場合には、ユーザは、少なくとも、自身が訪れるサイトが暗号化された接続を使用することを保証され得る。assertedidentityなどのSSLセキュアソケットレイヤ証明書の追加の特徴を、確立し、TTSによってチェックすることができる。assertedidentityは、TTPが周知のページのデータベースまたは既知のフィッシングサイト、マルウェアサイトなどのブラックリストを維持することとすることができ、そのようなサイトによって使用されることが既知のすべての証明書の取消リストをTTSに提供する。TTSは、モジュラ手法で拡張できる能力を有することができる。たとえば、GooglePagerank登録商標、WebOfTrustスコアを評価するモジュール、評判システムを考慮に入れる別のモジュールなどがあるものとすることができる。これらのモジュールは、TTSにスコアを提供することができ、TTSは、たとえばユーザ定義の重み付けポリシの使用によって、モジュール入力の要約されたスコアを計算し、サイトの査定をユーザに提示することができるものとすることができる。そのような特徴は、たとえば、不一致または発行するCAへの信頼関係の欠如の場合にユーザが証明書をチェックするように求められるFirefox登録商標またはInternetExplorer登録商標での既存の質問を超える可能性がある。これらのモジュールを、SSL証明書が使用可能ではない可能性がある、RPへの非HTTPS接続に使用することもできる。一般に、モジュールは、セキュア環境内、たとえば、TTSによって使用されるものと同一のセキュア環境内で動作することができ、TTSとセキュアに通信できるものとすることができる。既存ページのハッシュ値の小さい基準データベースを維持することが可能である場合がある。記録プロセスは、新しいページについて定義されなければならない可能性があるが、基準メトリックのセットがウェブページ/サーバについて存在すると仮定して、TTSは、これらの基準メトリックを利用して、訪問されるRPの完全性および真正性を検証することができる。TTSプロトコルおよびOpenIDIdPプロトコルに似たリモート構成証明プロトコルに従って、RPは、TTSに対してその完全性をアテストすることができ、TTSは、その後、成功の構成証明の場合にさらに進行することを許可することができる。TTSとRPとの間の例示的な相互認証は、次のうちの1つまたは複数を含むことができる。相互認証は、RPウェブサイトおよびサーバのアイデンティティおよび信頼性のチェック以上のことをすることができる。このプロセスは、RPによる、デバイス上で動作するTTSの完全性および真正性のチェックを含むことができる。これは、TOpenIDの会社または政府の記録に有用である可能性があり、ここで、RPは、ユーザが実際に認証機構としてTOpenIDを使用していることを保証され得る。RPは、あるタイプの認証機構、たとえばTOpenIDが、IdPとユーザTTSとの間で使用されることを保証されることを望む可能性がある。しかし、RPは、それでも、IdPが実際にTTSを使用することを信頼しなければならない可能性がある。そうでない場合に、ユーザは、自身のOpenIDIdPに対して別の機構を使用して認証しながら、TOpenIDを使用すると主張することができる。そのような認証は、プロトコルに対する複数の変更を含むことができる。RPは、たとえば、ユーザのデバイス上のTTSの真正性およびおそらくは完全性を検証した後にTTSにある種のナンスを送信することができる。このナンスは、一意であり、この特定のクライアントTTSからのこの要求の識別子として働くことができる。TTSは、このナンスを、ログイン要求に関連付けられて、保護されたストレージにセキュアに格納することができる。RPがユーザをIdPにリダイレクトした後に、IdPは、TOpenIDと同様に認証プロトコルを実行することができる。TTSは、以前に認証されたOPにナンスを解放することができるたとえば、解放を、TOpenIDプロトコルでの使用に制限することができる。IdPからRPに来るアサーションは、ナンスを含む必要がある可能性があり、このナンスは、TOpenIDが実際に認証に使用されたことをRPに保証することができる。このシナリオで使用される用語ナンスは、TOpenID認証がIdPと共に使用され得ることを検証するためにRPによってTTSに渡されるトークンを記述するのに使用され得る。ナンスのセキュリティプロパティを定義するために、異なる攻撃タイプを検討することができる。ユーザは、非TOpenID認証を実行し終えた後に、通信にナンスを注入することを試みることができる。これは、ユーザが、不可能ではないとしても困難であると仮定され得る、IdPとRPとの間の通信にインターセプトすることを要求する可能性がある。ユーザは、TTSまたはRPとのTTSからの初期通信からナンスを抽出することもできる。これは、ナンスがセキュアストレージに格納され、TTSが危険にさらされていない場合には、困難である可能性がある。危険にさらされたTTSが、RPからそのようなナンスを受信しない可能性があると仮定することができる。というのは、RPが、まず、TTS完全性を検証し、その後にナンスを送信することができるからである。そのようなセキュリティを意識するRPは、ユーザのデバイス上で動作するTTSインスタンスの完全性メトリックを備えることができる。RPからナンスを受信しつつあるTTSインスタンスが保護される場合には、これらのTTSが悪意のあるユーザからナンスをセキュアに保護すると仮定することができる。もう1つの攻撃モデルは、悪意のあるIdPを含むことができ、この悪意のあるIdPは、認証機構をだますことを試みることができ、したがって、TTSからナンスを取り出すことができる。そのようなシナリオでは、TTSがナンスを効率的に保護すると仮定することができる。より複雑な攻撃モデルは、共謀するIdPおよびユーザを含むことができる。ユーザが、ナンスを獲得できる場合には、そのユーザは、TOpenID認証を実行せずにそのナンスをIdPに転送することができる。次に、IdPは、ユーザがTOpenIDを使用して認証したと主張しながら、RPヘのメッセージでそのナンスを使用することができる。検討される攻撃モデルでは、TTSがRPによって完全性チェックされる場合にTTSがナンスを受信でき、そのようなTTSがナンスを十分に保護でき、そのナンスをTOpenID認証プロトコルに公開することに制限され得るという事実に、セキュリティが頼ることができることがわかる。ナンスをサービスアクセスごとに一意とすることができるので、悪意のあるIdPは、これをRPに再生することができない。このプロトコルは、構成証明機構を含むことができる。OpenIDプロバイダは、システム状態に関する情報を提供するためにユーザにチャレンジすることができる。システムが信頼できる状態である場合には、アクセスを付与することができる。これは、サービスへのアクセスを信頼できるシステムに制限することができるので、ウェブアプリケーションに関するセキュリティを活用することができる。着信OpenID認証要求をリスンし、これらをTPMに転送するユーザ側のサービスアプリケーションを有するのではなく、シームレスブラウザ統合を提供することができる。これを、この機能性を引き受けるブラウザ拡張を使用することによって達成することができる。OpenIDプロバイダは、サインインページのHTMLコードの内部でチャレンジを発行することができる。ブラウザ拡張は、この情報を読み取り、必要なデータをTPMに転送することができる。TPMは、署名されたチケットを作成し、これをブラウザ拡張に返すことができる。次に、拡張は、署名されたチケットを含む正しいHTTPS応答をOpenIDプロバイダに発行することができる。デバイスがUICCを有する場合に、ブラウザを、デバイス内のUICC上で実施することができる。UICC上でのブラウザの実施は、デバイスに、ブラウザがそこから動作するための固有のセキュア環境を与えることができる。UICC内のブラウザとデバイスの残りTPMを含むとの間のインターフェースを、GBAベースのセキュアチャネルを使用して保護することもできる。OMTPBONDIフレームワークは、ウィジェットまたはウェブアプリケーションがHTMLページ内のjavascriptを介してデバイス能力にアクセスすることを可能にすることができるAPIのスイートである。BONDIを、さらなるデバイス能力へのアクセスを可能にするための追加APIよって拡張可能とすることができる。特定の基礎になるデバイス能力へのアクセスを試みるJavaScriptAPIと独立にこれらの能力へのアクセスを実施できるように、BONDIセキュリティフレームワークを、デバイス能力アクセス制御機構を提供するように制限することができる。BONDIは、デバイス能力をシールドすることができない。BONDIは、デバイスのリソースおよび能力への排他的なアクセスプロバイダになることができない。BONDIに加えて他のフレームワークまたは機能が存在する場合には、BONDIフレームワークの外部のこれらの非BONDI独自JavaScriptAPIまたはプラグインは、制御されまたは管理されることができず、これらは、BONDIセキュリティフレームワークをむしばむ可能性がある。図13は、TOpenIDと共のBONDIの例示的な使用の図である。1では、ユーザが、RPを訪問し、IDに関するXRIを送信することができる。2では、関連付けを、RPとOPとの間で作成することができる。3では、OPが、HTTPS認証ページを提示することができる。3bでは、信頼されるチケットサーバが、構成証明のために署名されたSMLPCRを提供することができる。4では、OPが、SMLPCRを妥当性検査することができる。5では、OPが、ユーザがログインした状態でRPのURLにリダイレクトすることができる。たとえばポリシの管理および実施をセキュアに格納でき、デバイス能力へのアクセスプロバイダがBONDIフレームワークに制限されるように、BONDIが、信頼される実行環境の上で実行される場合には、デバイス能力にセキュアにアクセスするウェブアプリケーションを作成することが可能である可能性がある。そのような機能は、ウェブページからデバイス内の保護された機能への間接アクセスを含むことができる。信頼されるBONDIの実行と、ウェブページがデバイス上で動作する信頼されるチケットサーバサービスにアクセスすることを可能にする特殊なAPIの追加とが、ブラウザへのTOpenIDのシームレスな統合の新しい形を開くことができる。図14に、TOpenIDと共のBONDIの使用の例示的なコールフロー図を示す。OpenIDOPは、TOpenID対応アカウント用の認証ページ内にBONDIjavascriptコマンドを含めることができる。ページの内部のこのjavascriptは、クライアントのブラウザによって実行され得、まず、BONDIのライブラリおよびAPIをロードすることができる。javascriptは、HTMLページから信頼されるチケットサーバを照会することができる。照会は、OpenIDOPからのID、REQ、およびナンスを含むことができる。BONDIAPIを介して、照会を、デバイス上のチケットサーバに転送することができる。BONDIセキュリティポリシを使用して、信頼されるチケットサーバへのアクセスを、たとえば単一のOpenIDOPに制限することができる。要求を、許可のためまたは信頼されるチケットサーバへのアクセスの試みのたびにユーザ同意を要求するために、ユーザに対して行うことができる。信頼されるチケットサーバは、署名されたPCR引用Qおよび測定ログMLを取り出し、HTTPPOSTメッセージを使用してこれらの値をOpenIDOPに転送することができる。次に、OPは、受信されたデータを評価し、基本的なTOpenIDの場合と同様にプロトコルに進むことができる。そのような統合の利益は、より少ないユーザ対話が要求される可能性があり、OPが、チケット、たとえば引用およびMLのトランスポートのために第2通信チャネルを開始する必要なしに、HTTPプロトコルを介して信頼されるチケットサーバと直接に通信できることとすることができる。図15は、例示的なOpenIDプロトコルの図である。図16は、例示的なOAuthプロトコルの図である。図17は、例示的な組み合わされたOpenID/OAuthプロトコルの図である。図18は、GoogleOpenIDと共の例示的なOpenIDプロトコルの図である。図19は、GoogleAPIを使用する例示的なOAuthプロトコルの図である。本明細書で開示されるように、ユーザクライアント/プラットフォームを、たとえば無線通信システム内で使用できるWTRUまたは基地局とすることができる。他の無線通信システムにも適用可能ではあるが、一例では、図20に、E-UTRANEvolved-UniversalTerrestrialRadioAccessNetwork405を含む例示的なLTELongTermEvolution無線通信システム/アクセスネットワーク400を示す。E-UTRAN405は、複数のeNBevolvedNode-B420を含む。WTRU410は、eNB420と通信している。eNB420は、X2インターフェースを使用してお互いとインターフェースする。eNB420のそれぞれは、S1インターフェースを介してMMEMobilityManagementEntity/S-GWServingGateway430とインターフェースする。単一のWTRU410および3つのeNB420が図20に図示されているが、無線デバイスおよび有線デバイスの任意の組合せを無線通信システムアクセスネットワーク400内に含めることができることは明白である。図21は、WTRU410、eNB420、およびMME/S-GW430を含むLTE無線通信システムを500の例示的なブロック図である。図21に示されているように、WTRU410、eNB420、およびMME/S-GW430は、リンケージを使用するブラインド復号BD複雑さ低減の方法を実行するように構成される。通常のWTRU内で見つけることのできるコンポーネントに加えて、WTRU410は、オプションのリンクされたメモリ522を有するプロセッサ516、少なくとも1つのトランシーバ514、オプションのバッテリ520、およびアンテナ518を含む。プロセッサ516を、本明細書で開示される方法を実行するように構成することができる。トランシーバ514は、無線通信の送信および受信を容易にするためにプロセッサ516およびアンテナ518と通信している。バッテリ520がWTRU410内で使用される場合には、バッテリ520は、トランシーバ514およびプロセッサ516に電力を供給する。通常のeNB内で見つけることのできるコンポーネントに加えて、eNB420は、オプションのリンクされたメモリ515を有するプロセッサ517、トランシーバ519、およびアンテナ521を含む。プロセッサ517を、本明細書で開示される方法を実行するように構成することができる。トランシーバ519は、無線通信の送信および受信を容易にするためにプロセッサ517およびアンテナ521と通信している。eNB420は、オプションのリンクされたメモリ534を有するプロセッサ533を含むMMEMobilityManagementEntity/S-GWServingGateway430に接続される。特徴および要素が、上で特定の組合せで説明されるが、各特徴または要素を、単独でまたは他の特徴および要素との任意の組合せで使用することができることを、当業者は了解するであろう。さらに、本明細書で説明される方法を、コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアで実施することができる。コンピュータ可読媒体の例は、電子信号有線または無線の接続を介して伝送されるおよびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、読取り専用メモリROM、ランダムアクセスメモリRAM、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびにCD-ROMディスクおよびディジタル多用途ディスクDVDなどの光学媒体を含むが、これらに限定されない。ソフトウェアに関連するプロセッサを使用して、WTRU、UE、端末、基地局、RNC、または任意のホストコンピュータ内で使用されるラジオ周波数トランシーバを実施することができる。適切なプロセッサは、たとえば、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、ディジタル信号プロセッサDSP、複数のマイクロプロセッサ、DSPコアに関連する1つもしくは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路ASIC、フィールドプログラマブルゲートアレイFPGA回路、任意の他のタイプの集積回路IC、および/または状態機械を含む。ソフトウェアに関連するプロセッサを使用して、WTRU無線送受信ユニット、UEユーザ機器、端末、基地局、無線ネットワーク制御装置RNC、または任意のホストコンピュータ内で使用されるラジオ周波数トランシーバを実施することができる。WTRUを、カメラ、ビデオカメラモジュール、ビデオ電話、スピーカホン、振動デバイス、スピーカ、マイクロホン、テレビジョントランシーバ、ハンズフリーヘッドセット、キーボード、Bluetooth登録商標モジュール、周波数変調FMラジオユニット、液晶ディスプレイLCD表示ユニット、有機発光ダイオードOLED表示ユニット、ディジタル音楽プレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、インターネットブラウザ、および/または任意の無線ローカルエリアネットワークWLANモジュールもしくはUWBウルトラワイドバンドモジュールなど、ハードウェアおよび/またはソフトウェアで実施されるモジュールに関連して使用することができる。"