JP6307593B2 - 必要とされる認証保証レベルを達成するための多要素認証 - Google Patents

必要とされる認証保証レベルを達成するための多要素認証 Download PDF

Info

Publication number
JP6307593B2
JP6307593B2 JP2016510810A JP2016510810A JP6307593B2 JP 6307593 B2 JP6307593 B2 JP 6307593B2 JP 2016510810 A JP2016510810 A JP 2016510810A JP 2016510810 A JP2016510810 A JP 2016510810A JP 6307593 B2 JP6307593 B2 JP 6307593B2
Authority
JP
Japan
Prior art keywords
authentication
user
factor
mfas
assurance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2016510810A
Other languages
English (en)
Other versions
JP2016525807A (ja
Inventor
シー．シャー ヨゲンドラ
シー．シャー ヨゲンドラ
アンドレアス　シュミット
シュミット アンドレアス
クマール チョイ ビノッド
クマール チョイ ビノッド
スブラマニアン ラクシュミ
スブラマニアン ラクシュミ
レシェル アンドレアス
レシェル アンドレアス
Original Assignee
インターデイジタル パテント ホールディングス インコーポレイテッド
インターデイジタル パテント ホールディングス インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by インターデイジタル パテント ホールディングス インコーポレイテッド, インターデイジタル パテント ホールディングス インコーポレイテッド filed Critical インターデイジタル パテント ホールディングス インコーポレイテッド
Publication of JP2016525807A publication Critical patent/JP2016525807A/ja
Application granted granted Critical
Publication of JP6307593B2 publication Critical patent/JP6307593B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/121—Timestamp
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/67—Risk-dependent, e.g. selecting a security level depending on risk profiles

Description

関連出願の相互参照
本出願は、その両方の開示が全体として本明細書に記載されているかのように、参照により本明細書に組み込まれている、２０１３年４月２６日に出願された米国特許仮出願第６１／８１６，４４６号明細書、および、２０１３年６月７日に出願された米国特許仮出願第６１／８３２，５０９号明細書の利益を主張する。
クラウドにおけるサービスおよびコンテンツにアクセスするためのモバイルデバイスの消費者使用は、近年増加している。加えて、法人による「個人所有デバイス持ち込み（bring your own device）」（ＢＹＯＤ）への増加傾向があり、そこでは、従業員が自分の個人のモバイルデバイスを使用して、企業サービス／データにアクセスし、企業データを自分のデバイス上でローカルに記憶することができる。モバイル支払いサービスのためのモバイルデバイスの使用もまた増加しつつある。モバイルデバイスの増加された使用の上記の例は、他の使用とともに、セキュリティのための新しい要件につながっている。例えば、単なるパスワードよりも強力である認証の形式が、サービスにアクセスするために、およびセキュアな動作を処理するために、しばしば必要とされる。
２要素認証は、ユーザの認証を強化するために使用され得る。例示的な２要素認証は、第１の認証要素としてユーザのアイデンティティ（ＩＤ）およびパスワード、ならびに、第２の認証要素としてハードウェア／ソフトウェアベースのトークンに基づいている。ユーザＩＤおよびパスワードは、ユーザのプレゼンスを認証し、トークンは、その上にトークン機能性が存在するデバイスのユーザの所有を確認する。多要素認証は、２以上の要素を使用する任意の認証を指す。例示的な認証要素は、ユーザの対応するパスワード、トークン、およびバイオメトリクス／行動態様とともに、ユーザアイデンティティを含む。
多要素認証への既存の手法は、柔軟ではなく、ユーザフレンドリーではない。本明細書で説明される様々な実施形態は、認証の様々な要素を組み込むための汎用アーキテクチャを含む。様々な要素は、ユーザが何を知っているかに対応する要素（例えば、パスワード）、ユーザが何であるかに対応する要素（例えば、バイオメトリクス）、または、ユーザが何を有するかに対応する要素（デバイス認証）を含み得る。例えば、バイオメトリック認証は、パスワードベースの認証と組み合わされ得る。認証は、ネットワーク上またはユーザ機器（ＵＥ）上で実施され得る。いくつかの場合には、本明細書で説明される多要素認証は、例えばＯｐｅｎＩＤ（登録商標）プロトコルなど、様々なプロトコルを活用する。
例示的な実施形態では、ワイヤレス送信／受信ユニット（ＷＴＲＵ）またはＷＴＲＵを操作するユーザのうちの少なくとも一方、例えば両方が認証される。例えばサービスプロバイダ（ＳＰ）またはアイデンティティプロバイダ（ＩｄＰ）など、ネットワークエンティティは、ＳＰによって提供される第１のサービスにアクセスするために、ＳＰによって必要とされる第１の認証要件を判断する。認証要件は、必要とされる第１の保証レベルを示し得る。例示的な実施形態によれば、ネットワークエンティティは、認証のために利用可能である１または複数の能力を発見する。１または複数の能力は、ＷＴＲＵまたはユーザのうちの少なくとも１つに関連付けられ得る。ネットワークエンティティは、発見された１または複数の能力のうちの少なくとも１つが、第１の認証要件、例えばＳＰによって必要とされる認証保証レベルを達成するために十分であるか否かを判断し得る。発見された能力のうちの少なくとも１つが十分であると判断される場合、１または複数の認証要素が選択される。１または複数の認証要素は、ＳＰによって必要とされる第１の認証保証レベルを達成し得る。その後、選択された１または複数の認証要素のうちの少なくとも１つの実施がトリガされる。１または複数の認証要素の成功した実施において、ＷＴＲＵおよびユーザは、第１のサービスにアクセスすることができる。
一実施形態による多要素認証のための例示的なアーキテクチャのブロック図である。 例示的な実施形態による、図１に示されたアーキテクチャによって実施され得る多要素認証のためのフロー図である。 例示的な実施形態による、図１に示されたアーキテクチャによって実施され得る多要素認証のためのフロー図である。 別の例示的な実施形態による多要素認証のための別のフロー図である。 別の例示的な実施形態による多要素認証のための別のフロー図である。 別の例示的な実施形態による多要素認証のための別のフロー図である。 例示的な実施形態による、例示的なＯｐｅｎＩＤアサーションを示すコールフローである。 例示的な実施形態による、どのように保証レベルが通信されるかを示すブロック図である。 例示的な実施形態による、ＯｐｅｎＩＤアイデンティティプロバイダ（ＯＰ）への例示的なインターフェースを示すブロック図である。 例示的な実施形態による、ネットワークベースの多要素認証を示すフロー図である。 例示的な実施形態による、ネットワークベースの多要素認証を示すフロー図である。 例示的な実施形態による、ネットワークベースの多要素認証を示すフロー図である。 別の例示的な実施形態による、オンデバイス認証とローカルで生成されたアサーションとを示すフロー図である。 別の例示的な実施形態による、オンデバイス認証とローカルで生成されたアサーションとを示すフロー図である。 別の例示的な実施形態による、オンデバイス認証とローカルで生成されたアサーションとを示すフロー図である。 さらに別の実施形態による、ネットワーク上で生成されるアサーションと組み合わされるローカル認証を示すフロー図である。 さらに別の実施形態による、ネットワーク上で生成されるアサーションと組み合わされるローカル認証を示すフロー図である。 さらに別の実施形態による、ネットワーク上で生成されるアサーションと組み合わされるローカル認証を示すフロー図である。 例示的な実施形態による、サービスプロバイダがリライングパーティ（ＲＰ）とアイデンティティプロバイダ（ＩｄＰ）とを含む、例示的なシステムを示すブロック図である。 サービスへの疑似アイデンティティ（ＰＩＤ）ベースのシームレスアクセスを示すフロー図である。 サービスへの疑似アイデンティティ（ＰＩＤ）ベースのシームレスアクセスを示すフロー図である。 サービスへのＰＩＤベースのシームレスアクセスの別の例を示すフロー図である。 サービスへのＰＩＤベースのシームレスアクセスの別の例を示すフロー図である。 サービスへのＰＩＤベースのシームレスアクセスの別の例を示すフロー図である。 サービスへのＰＩＤベースのシームレスアクセスの別の例を示すフロー図である。 サービスへのＰＩＤベースのシームレスアクセスの別の例を示すフロー図である。 ＵＥと通信し得る２つのトラストサークルを示すブロック図である。 例示的な実施形態による、別のトラストサークル（ＣｏＴ）を示すブロック図である。 様々な実施形態によって実装され得る多要素認証のための例示的なアーキテクチャを示すブロック図である。 例示的な実施形態による、図１５に図示された例示的なアーキテクチャの変形形態を示すブロック図である。 追加の例示的な機能性が図示された、図１５のアーキテクチャを示すブロック図である。 一例による例示的なデバイスアーキテクチャの図である。 例示的な実施形態による、多要素認証のための例示的なデバイスアーキテクチャを示すブロック図である。 例示的な実施形態による、多要素認証のための例示的なサーブレットアーキテクチャを示すブロック図である。 例示的な多要素認証サーバ（ＭＦＡＳ）と通信することができる様々なデータベースの一例を示すシステム図である。 上記で参照されたアーキテクチャを使用して実施され得る多要素認証のためのコールフローである。 追加のポリシーエンティティが図示された、図２０に示された例示的なアーキテクチャを示す図である。 Ｓｍａｒｔ ＯｐｅｎＩＤに基づく多要素認証アーキテクチャの一例を示す図である。 始動され得る異なる例示的な認証アクティビティを示すアプリケーションのブロック図である。 例示的な実施形態による、一体化されたパスワードおよびバイオメトリック認証を示すコールフローである。 例示的な実施形態による、一体化されたパスワードおよびバイオメトリック認証を示すコールフローである。 例示的な実施形態による、一体化されたパスワードおよびバイオメトリック認証を示すコールフローである。 図１に示された例示的なアーキテクチャの変形形態を示すブロック図である。 図２７に示されたアーキテクチャによって実装され得るローカルバイオメトリック認証のためのコールフローである。 図２７に示されたアーキテクチャによって実装され得るローカルバイオメトリック認証のためのコールフローである。 ２つのリライングパーティを使用する例示的な多要素認証のためのコールを示す図である。 ２つのリライングパーティを使用する例示的な多要素認証のためのコールを示す図である。 ２つのリライングパーティを使用する例示的な多要素認証のためのコールを示す図である。 ２つのリライングパーティを使用する例示的な多要素認証のためのコールを示す図である。 １つのＲＰが実装される、図２９Ａ〜図２９Ｄに図示されたコールフローの変形形態を示す図である。 １つのＲＰが実装される、図２９Ａ〜図２９Ｄに図示されたコールフローの変形形態を示す図である。 １つのＲＰが実装される、図２９Ａ〜図２９Ｄに図示されたコールフローの変形形態を示す図である。 １つのＲＰが実装される、図２９Ａ〜図２９Ｄに図示されたコールフローの変形形態を示す図である。 例示的なＦＩＤＯ−ＭＦＡＳアーキテクチャを示すブロック図である。 １または複数の開示された実施形態が実装され得る、例示的な通信システムのシステム図である。 図３２Ａに図示された通信システム内で使用され得る、例示的なワイヤレス送信／受信ユニット（ＷＴＲＵ）のシステム図である。 図３２Ａに図示された通信システム内で使用され得る、例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。
次の詳細な説明は、例示的な実施形態を例示するために提供され、本発明の範囲、適用可能性、または構成を限定するように意図されない。様々な変更が、本発明の趣旨および範囲から逸脱することなく、エレメントおよびステップの機能および配置において行われ得る。例えば、実施形態は、ユーザフレンドリーな多要素認証を提供するために、例えば最適化されたＯｐｅｎＩＤプロトコルなど、連携された管理技術を使用して本明細書で説明されることがあるが、同様の実施形態は、他の認証エンティティおよび機能を使用して実装され得る。
多要素認証は、２以上の要素を使用する任意の認証を指す。例示的な要素は、ユーザのユーザ識別子（ＩＤ）、パスワード、トークン、およびバイオメトリクスを含む。本明細書で説明される様々な実施形態によれば、セキュアおよびユーザフレンドリーな多要素認証の実装および展開は、例えば、ユーザが何を知っているか、ユーザが何であるか、および、ユーザが何を有するかを含む、ユーザ認証の様々な態様を査定する複数の認証要素に基づく、ユーザまたはユーザのモバイルデバイスの認証を含み得る。
図１を参照すると、例示的なシステム１００は、ネットワークを介して互いと通信し得る、ユーザ機器（ＵＥ）１０２と、リライングパーティ（ＲＰ）１０４と、ＯｐｅｎＩＤサーバ１０６とを含む。ユーザ１０７は、ＵＥ１０２を操作し得る。ユーザ機器（ＵＥ）という用語は、以下でさらに説明されるような、任意の適切なワイヤレス送信／受信ユニット（ＷＴＲＵ）を含むデバイスを指すことがあることは理解されよう。例えば、ＷＴＲＵは、固定またはモバイル加入者ユニット、ページャ、携帯電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、タブレットコンピュータ、パーソナルコンピュータ、ワイヤレスセンサ、家庭用電化製品などを指すことがある。ＯｐｅｎＩＤ（ＯＩＤ）サーバ１０６は、任意の適切なアイデンティティプロバイダによって実装されることがあり、したがって、ＯＩＤサーバ１０６は、アイデンティティプロバイダ１０６と呼ばれることがあることは理解されよう。さらに、ＲＰ１０４は、例えばウェブサービスなど、任意のサービスプロバイダ（ＳＰ）によって実装されることがあり、したがって、ＲＰ１０４はまた、ＳＰ１０４と呼ばれることもある。例示的なシステム１００は、開示される主題の説明を容易にするために簡略化され、本開示の範囲を限定するように意図されないことは諒解されよう。他のデバイス、システム、および構成が、システム１００などのシステムに加えて、またはその代わりに、本明細書で開示された実施形態を実装するために使用されてよく、すべてのそのような実施形態が、本開示の範囲内として企図される。
図示された実施形態によれば、ＯＩＤサーバ１０６は、認証の複数の要素を協調させるか、または容易にすることができ、したがって、ＯＩＤサーバ１０６はまた、多要素認証レイヤ（ＭＦＡＬ）１０６またはマスタＩｄＰ１０６と呼ばれることもあるが、簡単のために、ＭＦＡＬ１０６およびマスタＩｄＰ１０６は、本明細書で多要素認証サーバ（ＭＦＡＳ）１０６と呼ばれる。例えば、ＭＦＡＳ１０６は、ネットワーク側と総称されることがある、１または複数の他のアイデンティティプロバイダからの複数の認証要素を使用し得る。ＭＦＡＳ１０６はまた、クライアント側と呼ばれることがある、ＵＥ１０２からの認証要素をも使用し得る。したがって、ＭＦＡＬは、ネットワーク側またはクライアント側からの多要素認証を可能にし得る。図示されるように、ＵＥ１０２は、任意の適切なブラウザであり得る、ＯｐｅｎＩＤクライアント１０８を含み、したがって、ＯｐｅｎＩＤクライアント１０８はまた、ブラウザ１０８と呼ばれることもある。図示されるように、ＵＥ１０２は、バイオメトリッククライアント１１２を含み、それは、例えば指紋または目スキャンなど、バイオメトリック認証要素を受信および処理するように構成され得る。図示されたＵＥ１０２は、加入者アイデンティティモジュール（ＳＩＭ）１１４またはユニバーサル集積回路カード（ＵＩＣＣ）１１４をさらに含み、それは、ＳＩＭ／ＵＩＣＣ１１４と呼ばれることがある。ＵＥ１０２は、多要素認証プロキシ（ＭＦＡＰ）１１０をさらに含んでよく、それは、認証の複数の要素を協調させる論理エンティティであり得る。例えば、ＭＦＡＰ１１０は、アプリケーションプログラミングインターフェース（ＡＰＩ）を使用してアクセスされてよく、または、ＭＦＡＰ１１０は、ブラウザ１０８へのプラグインとして実装されてよい。ＭＦＡＰ１１０は、拡張された機能性を有してよく、マスタＩｄＰ１０６のプロキシとして働き得る。
ＭＦＡＰ１１０は、様々な機能を実施し得る。例えば、ＭＦＡＰ１１０は、ユーザ１０７およびＵＥ１０２のプロファイルを維持し得る。プロファイルは、ユーザ１０７またはＵＥ１０２の、例えば認証能力などの能力を含み得る。ＭＦＡＰ１１０は、ＲＰ１０４と認証要件をネゴシエートし得る。例として、認証要件は、必要とされる認証の特定の強度を表し得る、保証レベルを指すことがある。ＭＦＡＰ１１０は、ユーザ１０７および／またはＵＥ１０２と、認証要件をさらにネゴシエートし得る。以下でさらに説明されるように、ＭＦＡＰ１１０は、保証レベルを認証の要素に変換し得る。詳細には、ＭＦＡＰ１１０は、保証レベルを、適切な認証方法またはプロトコルの粒度の細かいレベルに変換し得る。ＭＦＡＰ１１０は、ＵＥ１０２またはユーザ１０７のアイデンティティに基づいて、適切なアイデンティティプロバイダ（ＩｄＰ）を識別し得る。さらに、ＭＦＡＰ１１０は、対応するＩｄＰまたは対応するクライアント認証エージェント（ＡＡ）を呼び出すことによって、認証の要素をトリガし得る。例示的な実施形態では、ＭＦＡＰ１１０は、認証のためのポリシー決定ポイントである。ＭＦＡＰ１１０は、各認証要素のためのフレッシュネスレベルを維持し得る。本明細書で使用されるとき、認証要素に関連付けられるフレッシュネスレベルは、その認証要素を使用する認証が実施された時間を示す。例として、ＳＰ１０４は、認証要素のための一定のフレッシュネスレベルを必要とし得る。さらに例として、ＳＰ１０４は、認証が３０分前未満に行われた場合、その認証が許容できるが、それが３０分よりも前に行われた場合、その認証が許容できないと判断し得る。３０分という時間は、例示的なものにすぎず、フレッシュネスレベル要件は、望まれるような任意の適切な時間を規定し得る。さらに図１を参照すると、ＭＦＡＰ１１０は、複数の認証要素の結果を統合して、アサーションを作成し得る。アサーションは、それぞれ、必要とされる保証レベルおよび必要とされるフレッシュネスレベルを満たすかまたは超える、保証レベルおよびフレッシュネスレベルを含み得る。フレッシュネスレベルは、複数の認証要素のアグリゲートフレッシュネスを表す、統合されたフレッシュネスレベルであり得る。様々な認証要素の結果は、認証サーバ（ＡＳ）によってＭＦＡＳ１０６へ通信され得る。あるいは、結果は、ローカル認証エージェントによってＭＦＡＰ１１０へ通信されてよく、ＭＦＡＰ１１０は、次いで、結果／アサーションをＭＦＡＳ１０６へ通信し得る。統合されたフレッシュネスレベルの代わりに、またはそれに加えて、アサーションは、複数の認証要素の各々のためのフレッシュネスレベルを含み得る。ＭＦＡＰ１１０は、複数のデバイスを使用して、認証デバイスを実施し得る。例えば、ユーザ１０７は、多要素認証において使用される複数のデバイスの各々を所有または操作し得る。そのようなシナリオは、分離端末シナリオ（split-terminal scenario）と呼ばれることがある。ＭＦＡＰ１１０は、ポリシーレイヤと呼ばれることもある、ポリシーエンジンとともに働き、ポリシーがＵＥ１０２上でローカルに記憶され得るように、または、ポリシーが、例えばＭＦＡＳ１０６および／もしくはＲＰ１０４など、ネットワークエンティティと同期され得るようにすることができる。
引き続き図１を参照すると、クライアント側のＭＦＡＰ１１０は、マスタＩｄＰ１０６が実施する機能と比較して、同様および補完的な機能を実施し得る。例えば、オンデバイスベースの認証と呼ばれることがある、ユーザ１０７がＵＥ１０２上で認証されるシナリオでは、ＭＦＡＰ１０６は、マスタＩｄＰ１０６がユーザ１０７を認証するとき、マスタＩｄＰ１０６が実施する機能のうちの少なくともいくつか、例えば機能のすべてを模倣し得る。ＭＦＡＰ１１０は、ＵＥ１０２またはブラウザ１０８のユーザインターフェースを介して、ユーザ１０７がパスワードベースの認証を開始することを要求し得る。同様に、ＵＥ１０２、および詳細にはＳＩＭ／ＵＩＣＣ１１４が、例えば汎用ブートストラッピングアーキテクチャ（generic bootstrapping architecture）（ＧＢＡ）認証など、デバイス認証を実施するためにトリガされ得る。バイオメトリッククライアント１１２は、バイオメトリック認証を実施するために呼び出され得る。デバイス側の認証クライアントの各々について、関連付けられた認証サービスがネットワーク側にあり得る。例えば、図示された実施形態によれば、バイオメトリッククライアント１１２は、マスタＩｄＰ１０６の一部であり得る、バイオメトリック認証サーバ１１６と通信し得る。あるいは、バイオメトリック認証サーバ１１６は、マスタＩｄＰ１０６とは別個であり得るが、マスタＩｄＰ１０６のバイオメトリックプロキシ機能１１８を介して、マスタＩｄＰ１０６と通信可能に結合され得る。パスワードサーバ１２０は、ＵＥ１０７と通信して、パスワードを使用して、ユーザ１０７を認証し得る。パスワードサーバ１２０は、マスタＩｄＰ１０６の一部であり得るか、または、あるいはマスタＩｄＰ１０６と通信可能に結合され得る。マスタＩｄＰ１０６は、ブートストラッピングサーバ機能（ＢＳＦ）１２４と対話するネットワークアプリケーション機能（ＮＡＦ）１２２を含み、または、あるいはそれと通信可能に結合され得る。マスタＩｄＰ１０６は、ホーム加入者サーバ（ＨＳＳ）１２８と対話するＡＡＡサーバ１２６をさらに含み、または、あるいはそれと通信可能に結合され得る。マスタＩｄＰ１０６は、例えば認証要件に基づいて、デバイス側で認証クライアントに関連付けられ得る様々な認証サービスを呼び出し得る。
例示的な実施形態によれば、１または複数の認証要素が認証された後、マスタＩｄＰ１０６は、アサーションを作成する。アサーションは、１または複数の認証要素によって達成される保証レベルを含み得る。アサーションは、１または複数の認証要素に関連付けられるフレッシュネス情報をさらに含み得る。アサーションは、ユーザ１０７およびＵＥ１０２が、ＲＰ１０４によって提供されるサービスへのアクセスを受信し得るように、ＲＰ１０４に提示され得る。
さらに図１を全体的に参照すると、多要素認証は、ＳＰ１０４によって提供されるサービスに関連付けられるポリシーなど、ポリシーによって駆動され得る。本明細書で説明されるものは、連携されたアイデンティティ管理シナリオにおける、ポリシー駆動された多要素認証をサポートする方法である。例えば、ＳＰ１０４は、フェデレーションサービスを使用して、多要素認証を要求し、ＳＰがエンドユーザ１０７との直接的なトラスト関係を確立する必要がないようにすることができる。さらに、例えばシステム１００を使用して、ＳＰ１０４は、ＳＰ１０４が複数の認証要素のためのインフラストラクチャを有することなしに、多要素認証を要求することができる。
サービスにアクセスするために、ユーザ１０７は、そのサービスを提供するＳＰ１０４の認証要件を満たさなければならないことがある。認証要件は、様々なサービスの認証ポリシーに基づき得る。例えば、ＳＰ１０４のポリシーは、ＳＰ１０４によって提供されるサービスがアクセスされる前に、認証が、認証強度と呼ばれることもある、予め判断された保証レベルを満たすことを必要とし得る。したがって、ポリシーは、保証レベルとして表現され得る。保証レベルは、認証の強度を示すことができ、高い保証レベルは、認証の複数の要素を必要とし得る。例示的な実施形態では、保証レベルは、それにおいてユーザが認証される保証のレベルを指す。保証レベルは、どの認証プロトコルが使用されるか、認証のための要素の数、認証要素のタイプ（例えば、バイオメトリック、デバイス、ユーザ）、認証のフレッシュネス、補足条件、またはそれらの任意の適切な組合せに基づき得る。保証レベルは、外部機関によって定義され得る。例示的な実施形態では、望まれる保証レベルは、例えば、米国標準技術局（ＮＩＳＴ）、第３世代パートナーシッププロジェクト（３ＧＰＰ）、ワールドワイドウェブコンソーシアム（Ｗ３Ｃ）などを含む標準団体など、様々な外部機関によって規定される。例えば、外部機関は、例えば、アプリケーション自体のセキュリティ要件、要求されたサービスをホストする会社のセキュリティポリシーなど、様々な基準に基づいて、保証レベルを規定し得る。さらに例として、ＳＰ１０４は、ＳＰ１０４が要求されたサービスをユーザ１０７に提供するために必要とする保証レベルを規定し得る。
いくつかの場合には、必要とされる保証のレベルは、要求されるサービスに関連付けられたリスクに基づく。例えば、要求されたサービスが、例えば銀行口座情報を送信および受信するバンキングサービスなど、機密性の高い情報の送信および受信を含む場合、必要とされる保証レベルは高くなり得る。高い保証レベルは、多要素認証を実施することによって満足され得る。さらに例として、要求されたサービスが小さいリスクに関連付けられる、例えば、個人情報へのアクセスを有していないサービスである場合、必要とされる保証レベルは低くなり得る。例えば、低い保証レベルは、パスワード認証によって満たされ得る。したがって、例えばＳＰ１０４などのサービスプロバイダは、粒度の細かいサービスを提供して、認証の強度が、サービスに関連付けられたリスクにマッチされるようにし、それによって、ユーザにとっての過度の不都合を回避することができる。
例示的な実施形態では、ＳＰ１０４は、ＵＥ１０２およびユーザ１０７の認証能力を発見する。発見された認証能力に基づいて、ＳＰ１０４は、必要とされる保証のレベルを達成するために遂行されるべきである、１または複数の認証要素を選択および規定し得る。あるいは、マスタＩｄＰ１０６は、ＵＥ１０２および１０７の認証能力を発見し得る。例えば、ＳＰ１０４は、認証能力の発見をＩｄＰ１０６にデリゲートし得る。したがって、発見された認証能力に基づいて、ＩｄＰ１０６は、必要とされる保証のレベルを達成するために遂行されるべきである、１または複数の認証要素を選択および規定し得る。ＳＰ１０４は、ＳＰ１０４が提供する、要求されたサービスにアクセスするユーザ１０７に関連付けられたリスクを示すことによって、能力の発見をＩｄＰ１０６にデリゲートし得る。ＳＰ１０４はまた、ユーザ１０７がＳＰ１０４によって提供されるサービスにアクセスするために必要とされる保証のレベルを示し得る。例えば、保証レベル要件は、様々な手段を使用して、ＭＦＡＳ１０６と呼ばれることがある、マスタＩｄＰ１０６に通信され得る。例として、単にＰＡＰＥ拡張と呼ばれることがある、ＯｐｅｎＩＤプロバイダ認証ポリシー（Provider Authentication Policy）（ＰＡＰＥ）拡張が実装され、ＲＰ１０４がＰＡＰＥ拡張を使用して、保証レベル要件に関する任意の必要な詳細をＭＦＡＳ１０６に提供するようにすることができる。一般にポリシーサーバと呼ばれることがある、ＭＦＡＳ１０６の例示的な実装では、ＭＦＡＳ１０６上のインテリジェントポリシーエンジンが実装され、情報を受信すると、ＭＦＡＳ１０６が、任意の所与の保証レベルに基づいて、必要とされるポリシーを動的に生成し、生成されたポリシーを実行することができるようになる。ＭＦＡＳ１０６によってポリシーを生成するために受信され得る例示的な情報は、例として、限定としてではなく提示される、ユーザ１０７のポリシー、ＳＰ１０４のポリシー、ＳＰ１０４によって提供される特定のサービスにアクセスするための要件などを含む。
さらに図１を参照すると、ＳＰ１０４などのサービスプロバイダは、様々なサービスにアクセスするための認証強度要件を有し得る。例えば、ＳＰ１０４によって提供されたサービスにアクセスするために、ユーザは、認証がＳＰ１０４の認証要件を満足するように、認証される必要があり得る。いくつかの場合には、認証要件は、例えばＯｐｅｎＩＤ ２．０またはＯｐｅｎＩＤ Ｃｏｎｎｅｃｔなどの連携されたアイデンティティ管理プロトコルを使用するシナリオなど、デリゲートされた認証シナリオを含み得る。本明細書で説明される様々な例示的な実施形態は、様々な連携されたアイデンティティプロトコル（例えば、ＳＡＭＬ、ＯｐｅｎＩＤ ２．０、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ）を使用して実装され得るので、特定のプロトコルのコンテキストにおいて説明される実施形態は、そのように限定されないことは理解されよう。例えば、多要素認証は、認証が連携されないように、および、サービスプロバイダ１０４が、連携されたアイデンティティプロバイダ１０４によって実施されるとして本明細書で説明されることがある機能を実施するように、様々な実施形態において実装され得る。以下で説明されるポリシー管理機能は、アイデンティティ管理システムに追加されて、ユーザフレンドリーで柔軟な多要素認証が可能にされ得る、プラグ可能なモジュールであり得る。
上述されたように、例えばＲＰ１０４などのサービスプロバイダは、ユーザの認証が認証のために複数の要素を使用することを要求し得る。ＲＰ１０４は、ユーザ１０７またはユーザのデバイス（ＵＥ１０２）との直接的なトラスト関係を有する必要がなく、その理由は、ＲＰ１０４が、他のエンティティがユーザ１０７またはＵＥ１０２を認証することを要求することができるからである。例えば、サービスプロバイダは、サービスがそれらのアプリケーション、サービス、またはサーバにおいて認証機能を実装する必要なしに、利用可能な認証要素の任意の組合せを使用する認証を要求することができる。したがって、認証要素を実装、維持、および管理すること、ならびに、ユーザおよび認証要素のエンロールメントの負担は、システム１００によってハンドリングされてよく、ＲＰ１０４が、それ自体の多要素認証インフラストラクチャにおける投資なしに、多要素認証を使用することができるようになる。システム１００などの例示的な認証システムは、異なる要件、異なるユーザ、および異なるデバイスタイプに応じる、柔軟な多要素認証解決策を提供することができる。さらに、本明細書で説明される例示的なシステムは、多要素認証をサービス（ＭＦＡａａＳ）として提供し得る。
いくつかの場合には、ＳＰ１０４は、ユーザ１０７によって、および／またはユーザの現在のデバイス（ＵＥ１０２）によって供給され得ない認証を要求することがある。例えば、要求された認証は、特定のデバイスによって実施され得ない、例えば指紋認証などの認証要素を必要とすることがある。そのような場合、ＳＰ１０４は、ユーザ／デバイスの能力に基づいて、サービスアクセスをネゴシエートし得る。例えば、ＳＰ１０４は、ＵＥ１０２および／またはアイデンティティプロバイダ１０６によって提供され得る認証強度に従って、ＩｄＰ１０６およびＵＥ１０２とネゴシエートして、アクセスされ得るサービスを調節し得る。
例として、ユーザ１０７が、例えばタブレットコンピュータであり得るＵＥ１０７上で、バンキングアプリケーションを使用中であり、ユーザ１０７が取引を行うことを望む場合を考えられたい。この例ではＲＰ１０４である銀行は、バイオメトリクスを使用してユーザ１０７を認証する必要があり得るが、ユーザのタブレットは、バイオメトリック認証をオファーしない。その場合、バンキングアプリケーションは、ユーザが自分の残高をチェックすることを可能にし得るが、別の口座に対するいかなる取引をも可能にしないようになる。したがって、ＳＰ１０４は、デバイスの認証能力に基づいて、限定されたアクセスを提供し得る。限定されたアクセスは、要求されたフルアクセス未満であり得るが、それは、アクセスなしよりも大きくなり得る。
本明細書で説明されるように、サービスは、複数のタイプ、例えば２つのタイプに分類され得る。例えば、特定の要素から認証を得る必要があるサービスなど、厳密および明瞭な要件を有するサービスは、本明細書でタイプ１サービスと呼ばれることがある。必要とされる認証強度のインディケーションと呼ばれることがある、保証のレベルを含む要件を有する例示的なサービスは、タイプ２サービスと呼ばれることがある。必要とされる認証強度は、様々な認証要素、または異なる認証要素の組合せに変換され得る。タイプ１サービスを提供するサービスプロバイダは、ユーザおよびデバイス能力を要求することがあり、特定の要素を使用する認証を要求することがある。タイプ１サービスを提供するサービスプロバイダは、それら自体で異なる要素からの認証結果を評価し得る。タイプ２サービスは、満たされる必要がある特定の保証のレベルを要求することができる。必要とされる保証のレベルは、ユーザおよびデバイスの認証能力に基づいて選択され得る、１または複数の認証要素を実施することによって満たされ得る。認証要素が実施された後、認証要素の各々からの結果を組み合わせる結果が、サービスプロバイダに返され得る。
図２Ａ〜図２Ｂを参照すると、タイプ２サービスのための例示的な多要素認証２００が示される。例示的な実施形態では、多要素認証２００は、例えばＩｄＰ１０６など、システム１００によって実施され得る。図１および図２Ａ〜図２Ｂを参照すると、図示された実施形態によれば、ＲＰ１０４は、必要とされる認証保証レベル２０２を含む。認証保証レベル２０２は、ユーザ１０７およびＵＥがＲＰ１０４によって提供される特定のサービスにアクセスできる前に、満たされなければならない認証のレベルを表し得る。２０４で、ＩｄＰ１０６が、認証保証レベル２０２をＲＰ１０４から取得する。ＵＥ１０２は、その認証能力２０６のインディケーションを含み得る。２０８で、ＩｄＰ１０６が、ＵＥ１０２の認証能力２０６を取得または発見する。２１０で、図示された実施形態によれば、ＩｄＰ１０６が、発見されたＵＥの認証能力２０６が認証保証レベル２０２を満たすことができるか否かを判断する。ＵＥの認証能力２０６が必要とされる認証保証レベル２０２を満たすことができる場合、ＩｄＰ１０６は、ＲＰ１０４のポリシー要件に基づいて、必要とされる認証保証レベル２０２を達成する１または複数の認証要素を選択し得る。必要とされる認証保証レベル２０２はまた、第１の認証保証レベル２０２と呼ばれることもある。例えば、２１２で、ＩｄＰ１０６が、必要とされる認証要素のリストを抽出し得る。ＵＥの認証能力２０６が必要とされる認証保証レベル２０２を満たすことができない場合、２１４で、ＩｄＰ１０６が、ＲＰ１０４とネゴシエートして、第２の認証保証レベルを判断し得る。第２の認証保証レベルは、第２の認証保証レベルがＵＥ１０２の能力に等しくなるように、ＵＥ１０２の認証能力に基づき得る。例として、第２の認証保証レベルは、第１の認証保証レベル未満であり得る。認証保証レベルがネゴシエートされた後、ＩｄＰ１０６が、２１２で、ＲＰ１０４のポリシー要件に基づいて、必要とされる認証保証レベルを達成する１または複数の認証要素を選択し得る。
図２Ｂを参照すると、図示された実施形態によれば、２１４で、ＩｄＰ１０６が、選択された認証要素のうちの１つが実施される必要があるか否かを判断する。認証要素のうちの１つが実施される必要がある場合、２１６で、認証要素がリストから選択される。認証要素がリストから選択された後、２１８で、ＲＰ１０４のポリシー要件に基づいて、認証要素に関連付けられたフレッシュネスレベルが十分であるか否かが判断される。認証要素が十分なフレッシュネスに関連付けられている場合、認証要素のための認証が実施される必要がなく、２２０で、以前の認証情報がアサーションに追加され得る。認証要素が十分なフレッシュネスに関連付けられておらず、認証要素の認証が満了しているかまたは古いことを意味する場合、２２２で、認証要素のための認証が実施され、情報がアサーションに追加され得る。２２４で、ロギング情報（例えば、認証の時間、再試行の回数など）などの関連付けられた情報を含む認証結果が、ＩｄＰ１０６に記憶され得る。認証結果は、例えば様々な認証が実施された時間を示すタイムスタンプなど、関連付けられたフレッシュネス情報を含み得る。所与の認証結果が記憶された後、プロセスがステップ２１４へ戻ってよく、そこで、別の認証要素が実施される必要があるか否かが判断される。実施するべき他の認証要素がない場合、プロセスが２２６へ進んでよく、そこで、統合されたアサーションが作成される。統合されたアサーションは、１または複数の認証要素の各々の実施に関連付けられる１または複数の認証結果に基づき得る。統合されたアサーションは、統合された結果と呼ばれることがあり、ＲＰ１０４によって必要とされる認証保証レベル、例えば第１の認証保証レベルまたは第２の認証保証レベルを達成する。２２８で、統合されたアサーションがＲＰ１０４へ送られ、それによって、ＵＥ１０２および／またはユーザ１０７がＲＰ１０４によって提供されたサービスにアクセスすることが可能にされる。
図示されるように、図２Ａ〜図２Ｂは、ＩｄＰにおける認証の実行のためのフローを図示する。他の代替形態は本開示の範囲内である。例えば、以下で説明されるように、認証要素はローカルで実施され得るか、または、それらは、いくつかの要素がＵＥ１０２上でローカルに実施され、他のものがＩｄＰ１０６上で実施されるように、分離され得る。追加として、アサーションはまた、例示的な実施形態によれば、ＩｄＰ１０６の関与なしに、ローカルで生成され、ＲＰ１０４に直接供給され得る。これは、例えば、すべての認証がＵＥ１０２上でローカルに協調される場合、実装され得る。
図２Ａ〜図２Ｂを全体的に参照すると、多要素認証２００は、個々の認証要素の順次処理を図示するが、認証要素は、望まれるように、代替的に処理され、例えば同時に処理され得る。認証の順序は、例えば、各認証要素に関連付けられた強度によって判断され得る。例えば、最も強力な認証要素は、最も弱い認証要素の前に処理され得る。別の例として、ユーザ入力を必要としない認証要素は、ユーザ入力（例えば、指紋）を必要とする認証要素の前に処理され得る。各認証要素について、認証の結果およびフレッシュネス情報が記憶され得る。示されるように、必要とされる認証要素がＩｄＰ１０６によって処理された後、ＩｄＰ１０６は、要素の各々の結果を表す、組み合わされたアサーションを作成することができる。
アサーションは、タイプ１サービスおよびタイプ２サービスをカバーし得る、柔軟なデータ構造であり得る。アサーションは、多要素認証中に生成され得る。アサーションは、デバイスに基づいてテンプレートを使用し得る。以下は、例として、および限定としてではなく提示される、アサーションタイプのいくつかの例であり、汎用認証保証レベルアサーション、アカウンタビリティ／否認防止のために使用されるいくつかの識別子（例えば、ＩＭＳＩ）のためのアサーション、すべての要素における完全なアサーション（例えば、チャレンジ−レスポンスペア、要素バインディングの暗号アサーションを含む）、または、連鎖したアサーション、もしくは一緒にバインドされる個々のアサーションの収集物である。一緒にバインドされるアサーションは、どのように個々のアサーションが互いとともにバインドされるかのインディケーションを含み得る。アサーションは、ユーザデバイス上でローカルに生成され得る。そのようなアサーションは、ネットワーク中で生成されたアサーションと組み合わされ得る。アサーションは、汎用保証レベル（サービスプロバイダにとって軽量）を示すか、または上記で説明されたようにより詳細であり得る。
図３Ａ〜図３Ｃを参照すると、例示的な多要素認証３００が図示される。図示された多要素認証３００の処理は、２つの部分に分割される。図示された実施形態によれば、１つの部分は、デバイス上で実行され、したがって「ＵＥ中心処理」と呼ばれることがあり、１つの部分は、ネットワークを介してデバイスと通信し得る様々なネットワークエンティティによって実行され得る。この部分は、「ネットワーク中心処理」と呼ばれることがある。図示された認証３００は、本明細書で説明される多要素アーキテクチャが使用されて、デバイス上のローカル機能へのアクセス、ならびにネットワークサービスへのアクセスが認証され、可能にされ得ることを示す。３０２で、ユーザまたはＵＥ上のアプリケーションが、認証要求を発行し、それが、例えばリライングパーティなどのネットワークエンティティに向けてユーザおよび／またはＵＥを最終的に認証し得る。３０４で、ＵＥが、ネットワーク接続が利用可能であるか否かを判断する。ネットワーク接続が利用可能ではない場合、図示されたプロセスが３１４へ進み、そこで、ＵＥ認証プロキシ、例えばＭＦＡＰ１１０が、ローカル認証ポリシーが要求された認証のために構成されており、認証がローカルで遂行され得るようになるか否かを判断する。３０４で、ネットワーク接続があると判断される場合、プロセスがステップ３０６へ進み、そこで、ＵＥ、および詳細にはＭＦＡＰ１１０が、ローカル認証を実施するように構成される。３１４で、特定のローカル認証ポリシーが利用可能である場合、ＵＥ（ＭＦＡＰ）が、３１８で、ポリシーをフェッチし得る。特定の認証ポリシーが利用可能ではない場合、デフォルトポリシーが、３１６でフェッチされ得る。
引き続き図３Ａ〜図３Ｃを参照すると、３３６で、図示された実施形態によれば、認証ポリシーが、ローカルで利用可能な認証要素を使用して実行される。３３８で判断される、ネットワーク接続が存在する場合、ＵＥ、および詳細にはＭＦＡＰ１１０が、３４０で署名付きトークンを生成し、それを、ＳＰからのサービスにアクセスするためにＳＰへ送る。署名付きトークンは、ローカル認証が成功であるか不成功であるかを示す。３３８で、ネットワーク接続が利用不可能である場合、ＵＥ／ＭＦＡＰが、３４２で、成功したローカル認証についてチェックする。例えば、（例えば、３３６で）成功したローカル認証があった場合、３４４で、アクセスがデバイスリソースに対して許可され得る。ローカルデバイスリソースは、ＵＥ上で実行するアプリケーションを含み得る。例示的な実施形態によれば、ローカル認証が成功しなかった場合、３４６で、ＵＥまたはＵＥ上でホストされたリソースへのアクセスが不可能にされ得る。３０６で、ネットワーク側認証が可能であると判断される場合、３０８で、特定の認証ポリシーがルックアップされる。３０８で、特定の認証ポリシーがＵＥ上で利用可能であるか否かが判断される。それが利用可能である場合、プロセスがステップ３１２へ進み、そこで、特定のＳＰに関連付けられ得る、特定のポリシーがフェッチされる。３０８で、ポリシーが利用不可能であると判断される場合、３１０で、ポリシープロビジョニングプロトコルランが、ＵＥ／ＭＦＡＰとネットワーク側ＩｄＰ（例えば、ＭＦＡＳ１０６）との間で試みられる。３０８および３１０のステップは、１または複数回、繰り返され得る。ＳＰに関連付けられ得る認証ポリシーを受信またはフェッチした後、３２０で、様々なネットワーク側およびローカル認証要件が区切られる。３２２で、ローカル認証要素のみがＳＰによって必要とされるか否かが判断される。ローカル認証要素のみが必要とされる場合、図示された実施形態によれば、プロセスが３２４へ進み、そこで、ローカル要素が、３３６で使用された機能と実質的に同一であり得る機能によって実行される。３２６で、トークンチェーンが準備され得る。トークンチェーンは、ローカルで実行された要素にわたるアサーションを含有し得る。
さらに図３Ａ〜図３Ｃを参照すると、図示された実施形態によれば、３５０で、ネットワーク支援認証が、ＳＰによって提供される、要求されたサービスにアクセスするために必要とされるか否かが判断される。ネットワーク支援認証が必要である場合、プロセスがステップ３５２へ進んでよく、そこで、ローカル要素にわたるアサーションを含有する署名付きトークンが、必要とされるネットワーク支援要素の実行のために、ネットワークＩｄＰ／ＭＦＡＳへ送られる。ネットワーク支援要素が必要とされない場合、３５４で、署名付きトークンがＳＰへ送られ、３５６で、認証が成功裏に終了する。３２２で、ＳＰの特定のポリシー要件により、ローカル認証が適用可能ではないと判断された場合、または、３５０で、ローカル認証要素（複数可）に加えて、ネットワーク支援認証が必要とされると判断された場合、３２８で、ネットワーク認証要素が、３２８／３３０で判断される。３３２で、ネットワーク認証要素がイニシエートおよび実行される。ステップ３３２などのステップは、例えばＭＦＡＳ１０６およびＭＦＡＰ１１０など、１もしくは複数のネットワークエンティティ、ならびに／または、本明細書で説明される１もしくは複数のサードパーティ認証サーバ（例えば、ＭＮＯ、ＵＩＣＣなど）の間の対話を伴い得ることに留意されたい。３３４で、図示された実施形態によれば、ローカル認証アサーションを既に含有し得る、アサーショントークンチェーンが、実行された１または複数のネットワーク認証要素に対応するアサーションを追加することによって、補正される。したがって、一般に組み合わされたまたは統合されたアサーションと呼ばれることがある、完全なトークンチェーンが、３４８および３５４で、ＵＥを介してＳＰ／ＲＰへ送られ、それが３５６で認証プロセスを終了する。
本明細書で説明されるように、ＵＥ１０２などのデバイスの認証容量が発見され得る。発見され得る認証能力の例は、以下を実施するための能力を含み、すなわち、（例えば、ＡＫＡ、ＧＢＡ、もしくはＥＡＰ−ＳＩＭを使用して）モバイルネットワークによってサポートされる認証などのＵｌＣＣベースの認証、例えばＳＭＳを介して送られるＯＴＰなど、２次チャネルを使用する認証、バイオメトリックリーダおよび関連付けられたバックエンドサービスを使用するバイオメトリック認証、インターネットＩｄＰ（例えば、電子メールアドレス／パスワード）とともに使用されるユーザ名／パスワードを使用する認証、暗号トークン（例えば、政府によって発行された電子アイデンティティカードのＮＦＣチップ）を使用する認証、ユーザ行動解析学を使用する認証、または、ユーザ／ＵＥと、例えばＩｄＰなどの認証エンドポイントとの間で動作するチャレンジ／レスポンス機構を使用する認証である。
認証機能と呼ばれることもある、認証能力は、ＳＰまたはＩｄＰによって検出され得る。認証能力は、特定の認証要素を使用する認証を実施できることを指すことがある。したがって、ユーザまたはデバイスの認証要素がＳＰまたはＩｄＰによって検出され得るとも言われ得る。一実施形態では、認証能力が検出されるとき、各能力と単一のユーザとの間のセキュアな関連付けが、ＳＰまたはＩｄＰにおいて維持される。このセキュアな関連付けは、例えば後で、特定のＳＰによって必要とされ得る、ユーザおよび特定の認証プロトコルに対応する保証レベルの確立を可能にし得る。さらに、認証要素が検出されるとき、各認証要素に対応する識別子は、ユーザアイデンティティまたはＵＥの識別子に関連付けられてよく、認証要素とユーザまたはＵＥとの関連付けは、ユーザ認証データベースに記憶され得る。関連付けを記憶することは、ＩｄＰとは無関係の異なるパーティによる様々な認証要素の実施を協調させることを助け得る。例えば、指紋が、あるパーティによって認証されてよく、パスワードが、別のパーティによって認証されてよい。ユーザ認証データベース（ＤＢ）は、ＭＦＡＳ１０６において存在し得る。
いくつかの場合には、１または複数の認証要素は、デバイスの製造時にデバイスアーキテクチャに組み込まれる。他の場合には、認証要素は、ソフトウェア機能である。そのような機能は、デバイスが購入されるときにプリロードされ得るか、またはデバイスの購入後にユーザによってロードされ得る。本明細書で使用される他の認証要素は、上記の組合せであり得る。したがって、認証の要素が、プラットフォーム上で実装および実行されるときに機能のセキュリティを考慮に入れて、外部オーセンティケータが認証要素の実施における保証または信頼の全体的なレベルを査定することを可能にするようにすることが、重要であることが、本明細書で認識される。例えば、デバイスは、指紋認証能力をオファーし得るが、指紋ベースの認証の実施の周囲のセキュリティが、デバイスセキュリティアーキテクチャ観点から弱い（強力ではない）場合、保証または信頼のレベルが変調され得る。例示のための例として、Ａｐｐｌｅ（登録商標） ｉＰｈｏｎｅ（登録商標） ５Ｓは、指紋の取り込みから認証までのすべての機能がセキュアな方法で遂行され、メインプロセッサにとって可視ではない、指紋認証能力を有する。例示のためのさらなる例として、異なるタイプの電話デバイス（例えば、Ｓａｍｓｕｎｇ（登録商標） Ｓ５）もまた、指紋認証能力を所有し得るが、異なるものの指紋認証能力は、認証を実施するためにソフトウェアおよびハードウェアを用いて実装され得る。ソフトウェアが十分に保護されない場合、例えば、後者のプロセッサにおける保証または信頼のレベルは、Ａｐｐｌｅ ｉＰｈｏｎｅ ５Ｓ未満であると見なされ得る。上記の例は、すべての認証能力が、それらが同じ要素（例えば、指紋）に依拠する場合でも、セキュリティ観点から同じであると見なされるべきであるとは限らないことを示す。上記の例は、両方のデバイス上で実施される特定の要素が同じタイプである場合でも、保証のレベルは、特定の認証要素についてデバイスごとに変動し得ることをさらに示す。
したがって、デバイスによってサポートされる認証要素のタイプのみでなく、認証の実施の周囲のセキュリティをもセキュアに確かめることが、重要であり得る。様々な例示的な実施形態によれば、これは、デバイスの固有の不変の識別子から始める発見プロトコルによって査定され得る。追加の情報は、トラステッドサードパーティを通して、識別子から、寄せ集められ得る。例えば、あるパーティは、独立した、トラストできる認定会社（certification house）からデバイスのための認定を取得した、デバイスのメーカーであり得る。同様に、デバイスのソフトウェア態様もまた、プラットフォーム上のソフトウェア構成要素のセキュリティと、それらの認定のレベルとを査定することを通して、査定され得る。この情報（例えば、ハードウェアおよびソフトウェア認定）は、デバイスの証明とともに含まれ得る。したがって、デバイスのプラットフォームの全体のセキュリティ状態が確かめられ得る。詳細には、例えば、デバイスの認証能力の査定が、トラストできる方法で集められて、デバイスがデバイス上で利用可能である認証の様々な要素を使用することによって達成することができる、認証保証レベルの査定が可能にされ得る。
再び図１を参照すると、デバイスまたはユーザ、例えばＵＥ１０２またはユーザ１０７の１または複数の認証能力を発見することは、様々な例示的な実施形態によれば、セキュアに行われる。例えば、ユーザ１０７は、ＵＥ１０２を使用して、ＩｄＰ１０６のウェブサイトを閲覧し得る。ＩｄＰ１０６は、ユーザおよびデバイスをエンロールする、ＭＦＡＳ１０６を含み得る。セキュアチャネルが、成功裏に遂行された認証に基づいて、ユーザ１０７とＭＦＡＳ１０６との間で確立される。例として、電子メールが、自分のＩｄＰ１０６識別子である、ユーザの電子メールアドレスへ送られ得る。電子メールは、ソフトウェアをＭＦＡＳ１０６からＵＥ１０２へ、または複数のデバイスへダウンロードするためのリンクを含有し得る。ユーザによってダウンロードされたこのソフトウェアは、ＭＦＡＰ１１０と呼ばれる、ＭＦＡＳ１０６のローカルプロキシとして作用し得る。したがって、ＭＦＡＰ１１０には、ユーザのＩｄＰアイデンティティが備えられる。
ＭＦＡＰ１１０は、様々なローカルインターフェースとＡＰＩとを使用して、ＵＥ１０２上で利用可能である認証能力、例えば認証プロトコルを判断し得る。ＭＦＡＰ１１０は、トラストできる方法で、認証能力（機能性）をさらに判断し得る。認証能力はまた、トラストできるサードパーティにとって情報が追跡可能であるように、ＭＦＡＳ１０６によって発見可能でもあり得る。例えば、ＵＥ１０２の認証能力は、ＵＥ１０２の製造中に認定され、永続的な不変のデバイスアイデンティティにバインドされ、したがって、認定された認証能力に対応する特定の認証を実施することにおいて、外部からアクセス可能な保証のレベルを提供し得る。認証の要素の少なくともいくつか、例えばすべてが確かめられるかまたは発見されると、ＭＦＡＳ１０６は、認証能力およびポリシーをＭＦＡＰ１１０へプッシュし得る。
例示的な実施形態によれば、いくつかの場合には、ＭＦＡＳ１０６は、認証容量に関連付けられた特定の識別子を自律的に判断し得る。例えば、ＭＦＡＳ１０６は、ＵＥ１０２のアイデンティティ（ＩＤ）のためのＩＭＳＩを判断し得る。いくつかの場合には、ＭＦＡＳ１０６は、いくつかの識別子を判断することができないことがある。そのような場合、ＭＦＡＳ１０６は、ユーザ１０７に識別子（複数可）を促し得る。識別子は、サポートされた認証能力に対応する、例えばバックエンドサーバのアドレス情報など、任意の他の必要とされる特性とともに収集され得る。ユーザレコードは、例えば、ＭＦＡＳ１０６によって記憶され得る。ユーザレコードは、ユーザ１０７および／またはＵＥ１０２に対応する様々な認証能力のための収集された識別子からなり得る。ユーザレコードは、ＭＦＡＳ１０６によって収集された補足データをさらに含み得る。
さらに図１を全体的に参照すると、ＵＥ１０２（またはユーザ１０７）と、ローカルであるかまたはネットワーク中にある、認証エンドポイントと総称されることがある、認証を実施する様々なエンティティとの間で、多要素認証の実行を可能にするために、トリガメッセージが認証エンドポイントへ送られる。各認証要素のためのトリガメッセージは、多要素認証における様々な段階で送られ得る。
いくつかの場合には、トリガメッセージのターゲットは、ＵＥ１０２などのモバイルデバイスである。多要素認証がＯｐｅｎＩＤに基づく例示的なシナリオでは、ＵＥ１０２の方へ向けられる、ＯｐｅｎＩＤサーバ１０６と呼ばれることがある、ＩｄＰ１０６から来るＨＴＴＰ ＲＥＤＩＲＥＣＴメッセージがあり得る。リダイレクトメッセージは、典型的には、ブラウザ１０８を認証ウェブページへリダイレクトすることは認識されよう。例示的な実施形態では、ブラウザ１０８を「ＨＴＴＰ ＲＥＤＩＲＥＣＴ ｈｔｔｐ：／／．．．」という形式のウェブアドレスへリダイレクトするリダイレクトメッセージの代わりに、異なるＵＲＩ方式が使用されて、ＵＥ１０２による送信されたＵＲＩの異なるハンドリングが求められ得る。
別の実施形態では、様々なプロトコルが、連携されないかまたは連携され得る、多要素認証を遂行するために使用され得る。例えば、ＯｐｅｎＩＤは、１つのそのようなプロトコルである。ＳＡＭＬもまた、多要素認証のあるサブセットを実施するために使用され得る。組み合わされた認証の結果およびアサーションが、例えばＯｐｅｎＩＤ／ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔに基づいて、またはＳＡＭＬを介して、単一のアサーションを使用してトランスポートされ得る。あるいは、プロトコルの組合せが、認証およびアサーションをトランスポートするために使用され得る。
例示的な実施形態によれば、ＭＦＡＰ１１０の機能のうちの１つは、ユーザ１０７の認証（ユーザ認証）をサポートするＵＥ１０２の調整されたフロントエンドをサポートすることである。ＵＥ１０２の調整されたフロントエンドは、認証の保証を達成するために使用される必要がある認証要素の様々な組合せをサポートし得る。そのようなフロントエンドは、認証フロントエンド（ＡＦＥ）によって生成され得る。
ＡＦＥは、ＵＥ１０２上で認証フローを導くために使用されるユーザフロントエンドを、動的に生成し得る。ユーザフロントエンドは、例えばＨＴＭＬ５またはＪａｖａｓｃｒｉｐｔ（登録商標）など、様々なプロトコルを使用して生成され得る。フロントエンドは、自律的にＡＦＥによって、またはＵＥ１０２とのユーザ対話によって生成され得る。例えば、バイオメトリクス、パスワードなどの認証要素は、ユーザ対話を必要とし、組み込まれた確認を有し得る。あるいは、例えばＧＢＡおよびＥＡＰ−ＳＩＭなど、デバイス認証のためのモバイルネットワークベースの要素は、ユーザ１０７がＵＥ１０２と対話することなしに遂行され得る。アサーションおよび認証の、悪意のある、および隠された作成から保護するために、認証要素は、ユーザによって少なくとも確認され得る。ユーザ対話は、認証のためのユーザに関係付けられた様々なクレデンシャルの使用を可能にするための、ユーザ１０７からのパーミッションを受信することを含み得る。クレデンシャルは、デバイス情報、または他の記憶された情報を含み得る。例えば、ユーザパーミッションは、認証要素がトリガされる前にユーザ１０７が押す必要がある１または複数のボタンを介して、ＵＥ１０２によって受信され得る。ディスプレイなど、ＵＥ１０２のユーザインターフェースは、各認証が完了した後、カラー（例えば、緑色）インディケーションなど、インディケーションをレンダリングすることができる。
様々な例示的な実施形態では、ユーザ１０７は、使用されている要素についての情報を示す確認画面を提示される。確認画面は、そのために認証要素が使用されているウェブページまたはサービスをさらに表示し得る。ユーザ１０７は、自分の認証情報が使用され得ることを検証するための機会を有し得る。ユーザインターフェースは、ユーザ、デバイス、サービス、または認証に基づいて、それらが調整されるように、動的に生成され得る。この動的なユーザインターフェース生成がサービスに負担をかけないために、それは、以下で説明されるように、ＡＦＥにオフロードされ得る。
ＡＦＥによって生成され得るフロントエンドは、ＡＰＩを介してＭＦＡＰ１１０にインターフェースしてよく、ＭＦＡＰ１１０は、それらの特定のＡＰＩを介して、様々な認証要素とインターフェースする。ＡＦＥはまた、デバイスコネクタを介してＭＦＡＰ１１０と通信して、ＭＦＡＰ１１０がフロントエンドを生成すること、および多要素認証をローカルで実行することを可能にし得る。同様の機構もまた、ＭＦＡＳ１０６との認証の協調を容易にし得る。
以下でさらに説明されるように、認証要素は、ネットワークポリシーエンティティとともにロギングおよび同期され得る。ローカルログと呼ばれることがある、ＵＥ１０２上で記憶されたログは、例えば、ＭＦＡＳ１０６への接続性のとき、使用され得る。ローカルログは、接続性が利用可能になるとき、ＭＦＡＳ１０６との同期を可能にし得る。ログは、セッションハンドル、遂行された特定の認証のインディケーション、認証に関連付けられた時間、再試行の数、認証の成果などを含み得る。
いくつかの場合には、各個々の認証要素のフレッシュネスがチェックされて、認証プロセスを繰り返すことによってユーザ１０７に負担をかけることなしに、以前の認証結果が再使用され得るか否かが判断される。さらに、認証要求は、認証要素がフレッシュであるときに低減されてよく、それが、ネットワーク認証サーバへの負担を減少させ得る。一実施形態では、ＭＦＡＳ１０６は、フレッシュである認証要素に基づいて、望まれる保証レベルのためのアサーションを生成することになる。例示的なシナリオでは、多要素認証の個々の要素がフレッシュである場合、複数の認証された結果のうちの少なくとも１つ、例えばすべてが再使用され得る。例えば、ＭＦＡＳ１０６は、要素のうちのいくつかが古くなった後、より低い保証レベルにアサートすることができる。そのようなより低いレベルは、サービスにアクセスするために十分であり得、したがって、ＭＦＡＳ１０６は、新しい認証が実施されることをトリガする必要がないように、より低い保証レベルにアサートし得る。代替的実施形態では、ＭＦＡＰ１１０は、フレッシュネスを制御する。例えば、ユーザ１０７が、サービスアクセスとは無関係に（例えば、バイオメトリクスを使用して）ＵＥ１０２に対してローカルで認証するとき、ＵＥ１０２を用いたユーザ認証のフレッシュネスは、ユーザ１０７がＵＥ１０２を用いて認証するたびに更新されてよく、更新がＭＦＡＳ１０６にシグナリングされ得る。各アサーションは、アサーションとのフレッシュネス情報関連付けを含有し得る。
再び図１を参照すると、上記で説明されたように、ＳＰ１０４は、ＵＥ１０２およびユーザ１０７がＳＰ１０４によって提供されるサービスにアクセスすることが可能にされる前に、認証を必要とし得る。ＳＰ１０４は、例えば会社ポリシーまたは法的要件に従って、ユーザ認証のための要件を設定し得る。必要とされるものはまた、アクセスされているデータまたはサービスのタイプにも基づき得る。例示的な実施形態では、サービスポリシーに従って多要素認証を可能にするために、多要素認証を遂行することにおける保証レベルおよびポリシーが、例えばＲＰ１０４、ＵＥ１０２、およびＩｄＰ１０６などのエンティティ間でトランスポートされる。例えば、ＲＰ１０４は、ＲＰ１０４と、ＯｐｅｎＩＤアイデンティティプロバイダ（ＯＰ）であり得る、ＩｄＰ１０６との間の関連付け中に、認証要件を通信してよく、したがって、ＩｄＰ１０６はまた、ＯＰ１０６と呼ばれることもある。ＯＰ１０６は、例えば、Ｙａｄｉｓに基づく発見プロトコルにおいて、サポートされた認証保証レベルを広告し得る。
ＯｐｅｎＩＤプロトコルランにおいてポリシー要件を出すための例示的な方法は、ＲＰ１０４がＰＡＰＥを使用することである。ＰＡＰＥは、多要素認証および要素フレッシュネスを要求するために使用され得る総称語を含有する。ＰＡＰＥは、カスタム保証レベル指定をトランスポートするために、拡張を定義するための機構をさらに含む。
ＭＦＡＳ１０６は、サービスプロバイダが、認証が実施される前に認証要素を通信するか、または認証要素をネゴシエートするための、インターフェースを含み得る。例えば、既存のＯｐｅｎＩＤ ２．０またはＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ発見プロトコルに一体化され得る、例示的な発見プロトコルを使用して、ＳＰ１０４は、ユーザ１０７など、特定のユーザにとって利用可能である認証要素のリストを判断し得る。例示的な実施形態では、ＭＦＡＳ１０６の一部であり得る、保証レベルデータベースおよび論理機能は、サービスのリスク要件を、対応するフレッシュネス要件をもつ認証の要素に変換する。あるいは、サービスは、供給されたＵＥ１０２の認証能力に基づいて、認証要素のセットを直接規定し得る。例えば、ユーザ１０７のための構成およびアイデンティティマッピングに応じて、ＭＦＡＳ１０６は、ユーザ１０７に関連付けられたすべてのデバイスと、ユーザ１０７に関連付けられたすべての要素とのリストを返すことができる。あるいは、ＭＦＡＳ１０６は、ユーザ１０７が使用中である現在のデバイス１０２のみに関連付けられる認証要素のリストを返すことができる。認証能力のリストに基づいて、ＳＰ１０４は、好適な認証要素、または複数の要素の組合せを選択し、選択された１または複数の要素に従って、認証を要求し得る。
さらに図１を全体的に参照すると、別の例示的なシナリオでは、ＳＰ１０４は、例えば、異なるユーザ／ＵＥによってサポートされる認証の要素を確かめる負担を回避するために、必要とされるリスクプロファイルにマッチする保証レベルに、ＵＥ／ユーザが認証されることを要求し得る。例えば、ＳＰ１０４は、ＵＥ１０２がサービスにアクセスするためにそれが必要とする保証の最小（および、また、望まれる場合は最大）レベルを要求することができる。ＭＦＡＳ１０６は、次いで、認証のために使用するために、認証要素のリストをコンパイルし得る。リストは、ユーザ１０７がこの保証レベルを達成するための最良適合または使用しやすさに基づいて、コンパイルされ得る。
ＭＦＡＳ１０６は、異なる特性を考慮に入れて、認証要素のリストを判断することができる。例示的なパラメータは、認証のコスト、ユーザ選好、ユーザに対する最小の摩擦、プライバシー要件、認証プロセスのセキュリティ、デバイス上のエネルギー消費、ネットワークおよびバックエンド上の帯域幅負荷、法的条件、既存の認証のフレッシュネスおよび再使用可能性などを含む。これらの例示的な特性の査定に基づいて、ＭＦＡＳ１０６は、望まれる保証のレベルを達成するために使用され得る要素のリストを導出することができる。
上述されたように、特定の認証要素がＳＰ１０４によって必要とされ得る。異なるサービスまたはＵＲＬドメインでは、サービスは、異なる保証レベルに関連付けられ得る。ＭＦＡＳ１０６において、例えば、静的なＵＲＬポリシーが、異なる認証要素に対してマッチされてよく、それらの認証要素が、異なるＵＲＬドメインのために呼び出され得る。
一実施形態では、ＭＦＡＳ１０６において、認証要素に対するＵＲＬサブストリングのマッピングが、静的なサービスプロバイダＵＲＬのための対応する認証要素を実行するために使用される。追加として、特定のサービスプロバイダのサブドメインもまた、異なる認証要件を要求し得る。例として、Ａｍａｚｏｎ（登録商標）チェックアウトシナリオでは、ＵＲＬサブストリングＡｍａｚｏｎ／ｃａｒｔが、必要とされる保証レベルであり得る認証要件に対してマッピングされる。「ｏｐｅｎｉｄ．ｒｅｔｕｒｎ＿ｔｏ」がこのサブストリングを含有する場合、規定された認証要素が呼び出される。言い換えれば、ＲＰは、ＲＰから要求されているサービスに基づいて、対応する（例えば、より粒度の細かい）保証レベル要件を有し得る。高リスク取引は、より低いリスク取引と比較して、より高い保証レベルを必要とし得る。したがって、保証レベル要件は、ＲＰに直接結び付かないことがあるが、代わりに、ＲＰによってオファーされているサービスに結び付くことがある。再び図１を参照すると、望まれる認証要件は、ＲＰ１０４によってＯＰ１０６へ動的に中継され得る。選択された認証要素に基づく認証は、ＭＦＡＳ１０６によって実施されてよく、選択された認証要素を含む認証の結果は、ＭＦＡＳ１０６からＲＰ１０４へ通信され得る。
認証要素をトリガするための例示的なメッセージは、ｓｏｉｄ．ｓｃｈｅｍｅ：／／＜ｍｅｔｈｏｄ＞．＜ｆａｃｔｏｒ＞／＜ｆａｃｔｏｒ−ｄａｔａ＞であり、ただし、「ｓｏｉｄ．ｓｃｈｅｍｅ」は、認証要素をハンドリングするＵＥ１０２における汎用機能を求めるためのＵＲＩスキーマである。この内部エンティティのメインタスクは、ＵＥ１０２内で要素認証プロセスをディスパッチすることである。例えば、ディスパッチは、認証を実施するための、ＵＥ１０２内の適切な機能へのコールを含み得る。異なるＵＲＩスキーマをハンドリングするための機能性は、ＵＥ１０２のプラットフォームオペレーティングシステム中に含有され得ることは諒解されよう。ディスパッチするために、ＵＲＩのＵＲＬ部分中のロケーション情報が使用され得る。例えば、これは、上記で示されたように階層的に行われてよく、ただし、＜ｍｅｔｈｏｄ＞は、バイオメトリック要素、または、ＳＩＭカード１１４などのセキュアエレメント上に存在する要素など、共通の特質をもつ認証要素のサブセットを制御する、ハンドラ機能を示す。＜ｆａｃｔｏｒ＞キーは、次に、認証されるべき実際の要素を示し得る。＜ｆａｃｔｏｒ−ｄａｔａ＞は、ＵＥ１０２上の認証機能がそのタスクを実施するために必要な任意のデータをトランスポートするために使用され得る。例えば、それは、要素がチャレンジレスポンス認証であるとき、チャレンジ値を保持し得る。＜ｆａｃｔｏｒ−ｄａｔａ＞の例は、例として、限定なしに提示される、以下を含む。
上記の「ｓｏｉｄ．ｓｃｈｅｍｅ：／／ｓｏｉｄ．ｌｏｃａｌ／？＜ＯｐｅｎＩＤ−ｐａｒａｍｅｔｅｒ−ｓｅｔ＞」は、要素が、ローカルＯＰと呼ばれることがある、ＵＥ１０２上にロケートされたＯｐｅｎＩＤプロバイダエンティティであることを示すことは諒解されよう。上記でリストされた最後の例は、パスワードがユーザ１０７からローカルで要求される、異なる方式である。ローカル認証エージェントは、例えば、ユーザ１０７によって提供されたパスワードをハッシングし、それを、ｓａｌｔパラメータとともに標準の暗号方法（例えば、ＨＭＡＣを使用する）と組み合わせ、それを、ｓｌａｔｅｄ−ｄｉｇｅｓｔパラメータと比較することによって、この場合はユーザ１０７を認証し得る。この方法は、ＨＴＴＰ−ＤＩＧＥＳＴ認証に少なくとも部分的に類似し得る。
上記で説明されたトリガメッセージの例示的な拡張は、以下の例、すなわち、ｓｏｉｄ．ｓｃｈｅｍｅ：／／ｓｏｉｄ．ｍｕｌｔｉ／？＜ｍｕｌｔｉ−ｆａｃｔｏｒ−ｐｏｌｉｃｙ＞によって与えられる。ＵＥ１０２上のローカルエンティティは、（「ｓｏｉｄ」キーによってコールされた）そのような認証要素要求をハンドリングすることができ、ローカルエンティティは、複数の認証要素をハンドリングすることができる下位構成要素を含み得る。その下位構成要素は、この例によれば、キー「ｍｕｌｔｉ」によってコールされる。単一認証要素のための任意の必要なデータと、追加として、単一要素のために必要とされるフレッシュネスなど、それらのジョイント実行におけるポリシーとが、付加されたパラメータセット中に含まれ得る。
あるいは、サーバからコールされるＵＥローカル要素認証は、ローカル認証クライアントをイニシエートするために、ウェブページ中に挿入されたカスタムＪａｖａＳｃｒｉｐｔコード、およびその中のカスタムＡＰＩコールからコールされ得る。そのようなコールの例は、３ＧＰＰ ＴＲ３３．８２３に記載されている。
さらに図１を全体的に参照すると、システム１００の分散された、および連携された性質のために、サービスプロバイダ、詳細にはＳＰ１０４は、ユーザ１０７によって供給され得るよりも多くの要素、またはそれよりも強力な認証を要求し得る。達成可能な、または達成された認証強度が、サービス要件にマッチしない場合、ＳＰ１０４は、提示された認証アサーションが要求に従っていないので、アクセスを拒否することができ、または、ＳＰ１０４は、受信された認証アサーションに基づいて、サービス機能性を格下げすることができる。
一実施形態では、望まれる保証のレベルが、任意の組合せの認証要素によって到達され得ない場合、ＩｄＰ１０６は、ネットワーク／ＵＥ／ユーザ支援機構が認証強度または保証レベルを向上させることを引き起こし得る。例えば、ＩｄＰ１０６は、ＳＰ１０４との入札プロセスにおける対話型プロトコルを開始してよく、そこで、ＭＦＡＳは、所与のユーザ１０７およびデバイス１０２にとって合理的に到達可能である最高保証レベルで応答することができる。ＳＰ１０４は、次いで、新しい保証レベルでの認証を要求することができ、または、ＳＰ１０４は、サービスがより小さい保証とともにアクセスされ得るように、サービスオファーを格下げまたは変更する。あるいは、例えばチャレンジ−レスポンスプロトコルを実施することによって、より強力な形式の認証要素が生じて、最初に要求されたサービスがアクセスされることが可能にされ得る。
ＵＥ１０７またはユーザ１０２によって達成可能である認証保証レベルを発見することの一部として、ＭＦＡＳ１０６はまた、過去の認証要素のフレッシュネスを考慮に入れて、場合によっては以前の認証を再使用することもできる。フレッシュネス要件は、認証要素ごとに、およびサービスごとに異なり得る。ネゴシエーションの一部として、サービスプロバイダは、いくつかの認証要素が、少なくとも緩和されたフレッシュネス要件とともに必要とされる、「緩和された」ポリシーモードを示し得る。認証要素に応じてフレッシュネス要件を変動させることは、異なるレートで経時的に低下し得る、測定された認証要素に配慮する。
例えば行動またはバイオメトリック解析学を使用する、連続的な認証を実施するための能力が存在する、いくつかの場合には、ＭＦＡＳ１０６は、その能力をうまく利用し、その認証要素の測定された保証レベルを適切に利用し得る。連続的な認証は、侵入なしに、または最小の対話ありで、ユーザを認証することができるという利点を有する。
異なるサービスまたはＵＲＬドメインは、異なる保証レベルに関連付けられ得る。ＭＦＡＳにおいて、静的なＵＲＬポリシーが、異なる認証要素に対してマッチされてよく、それらの認証要素が、異なるＵＲＬドメインのために呼び出される。一実施形態では、ＭＦＡＳ１０６において、認証要素に対するＵＲＬサブストリングの保証レベルマッピングが、静的なサービスプロバイダＵＲＬのための対応する認証要素を実行するために使用される。追加として、特定のサービスプロバイダのサブドメインもまた、異なる認証要件を要求し得る。一例として、Ａｍａｚｏｎチェックアウトシナリオでは、ＵＲＬサブストリングＡｍａｚｏｎ／ｃａｒｔが、必要とされる認証要件に対してマッピングされ得る。「ｏｐｅｎｉｄ．ｒｅｔｕｒｎ＿ｔｏ」がこのサブストリングを含有する場合、規定された認証保証レベルに対応する認証要素が呼び出される。
望まれる保証レベルは、ＲＰ１０４によってＯＰ１０６へ動的に中継され得る。通信された保証レベルに基づいて、要求するユーザ１０７のための必要とされる認証要素が、ＭＦＡＳ１０６によって実施され、様々な例示的な実施形態によれば、達成された保証レベル、および、実施された認証のさらなる情報が、ＲＰ１０４へ通信される。ＰＡＰＥ拡張は、様々な情報を通信するために使用され得る。ＰＡＰＥ拡張は、ＵＲＬベースであり、ＯＰ１０６に、必要とされる保証レベルに関係付けられた情報を提供し得る。ＰＡＰＥメッセージングは、適切な要求およびレスポンスメッセージングスキーマが一貫して使用されることを必要とし得る。
例示的な実施形態では、以下のパラメータが、ＲＰ１０４によるＯｐｅｎＩＤ認証要求中に含まれる。
・ｏｐｅｎｉｄ．ｎｓ．ｐａｐｅ
値：ｈｔｔｐ：／／ｓｐｅｃｓ．ｏｐｅｎｉｄ．ｎｅｔ／ｅｘｔｅｎｓｉｏｎｓ／ｐａｐｅ／１．０
ｏｐｅｎｉｄ．ｐａｐｅ．ｐｒｅｆｅｒｒｅｄ＿ａｕｔｈ＿ｐｏｌｉｃｉｅｓ：ユーザ１０７を認証するときにＯＰ１０６が満足するべきである認証ポリシーを表す、０またはそれ以上の認証ポリシーＵＲＩ。複数のポリシーが要求される場合、ＯＰ１０６は、それらのうちのできる限り多くを満足するべきである。ポリシーが要求されない場合、ＲＰ１０４は、例えば認証年数など、他の情報に関心があり得る。このパラメータは、認証ポリシーＵＲＩの区切られたリストを提供する。例は以下を含む。
・ｏｐｅｎｉｄ．ｐａｐｅ．ａｕｔｈ＿ｌｅｖｅｌ．ｎｓ．＜ｃｕｓｔ＞：（オプション）これは、カスタム保証レベルのための名前空間を表す。保証レベルおよびそれらの名前空間は、国もしくは業界固有の標準団体、または他のグループもしくは個人など、様々なパーティによって定義される。このパラメータは、この保証レベルを表すＵＲＬを含む。例は以下を含む。
例示的な実施形態では、上記のフィールドは、ＭＦＡＳ１０６によって定義されるカスタム保証レベル標準を定義するために使用され得る。異なる認証要素へのマッピングを規定する、保証レベルのための、ＭＦＡＳにおいて定義された全体的なポリシーが、基準として使用され得る。
・ｏｐｅｎｉｄ．ｐａｐｅ．ｐｒｅｆｅｒｒｅｄ＿ａｕｔｈ＿ｌｅｖｅｌ＿ｔｙｐｅｓ：（オプション）ＲＰが、その選好の順序で、レスポンスにおいて存在することを要求する、カスタム保証レベル名前空間のための名前空間エイリアスのリスト。このパラメータは、ＲＰの選好の順序で、名前空間エイリアスのペースで区切られたリストを含む。一例は以下の通りである。
このカスタムフィールドは、ＭＦＡＳにおいて解釈され得る、このユーザのための必要とされる認証レベルを送るために使用されてよく、対応する認証要素が呼び出され得る。
リライングパーティの要求に対するレスポンスにおいて、以下のパラメータが、例示的な実施形態によれば、ＯｐｅｎＩＤ認証レスポンス中に含まれる。レスポンスパラメータは、認証レスポンスの署名中に含まれる。この拡張をサポートするＯＰは、リライングパーティによって要求されない場合でも、以下のパラメータを含み得る。レスポンスパラメータは、例示的な実施形態によれば、ＯｐｅｎＩＤプロバイダとのエンドユーザの現在のセッションを記述する。例示的なレスポンスパラメータは、例として、限定なしに提示される、以下を含む。
・ｏｐｅｎｉｄ．ｎｓ．ｐａｐｅ
値：ｈｔｔｐ：／／ｓｐｅｃｓ．ｏｐｅｎｉｄ．ｎｅｔ／ｅｘｔｅｎｓｉｏｎｓ／ｐａｐｅ／１．０
・ｏｐｅｎｉｄ．ｐａｐｅ．ａｕｔｈ＿ｐｏｌｉｃｉｅｓ：エンドユーザを認証するときにＯＰが満足したポリシーを表す、１または複数の認証ポリシーＵＲＩ。ＯＰがレスポンスにおいて他の情報を伝達することを希望するにもかかわらず、ポリシーが満たされなかった場合、例示的な実施形態によれば、このパラメータが、ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ｏｐｅｎｉｄ．ｎｅｔ／ｐａｐｅ／ｐｏｌｉｃｉｅｓ／２００７／０６／ｎｏｎｅの値とともに含まれる。このパラメータは、例えば以下のように、認証ポリシーＵＲＩのスペースで区切られたリストを提供し得る。
・ｏｐｅｎｉｄ．ｐａｐｅ．ａｕｔｈ＿ｔｉｍｅ：（オプション）エンドユーザが、アサートされたポリシーに適合する方法でＯＰに対してアクティブに認証したときの、直近のタイムスタンプ。例示的な実施形態によれば、時間は、「Ｚ」で示されるＵＴＣ時間帯でフォーマットされる。一例によれば、秒の小数部は含まれない。このパラメータの一例は、２００５−０５−１５Ｔ１７：１１：５１Ｚである。ＲＰの要求が「ｏｐｅｎｉｄ．ｐａｐｅ．ｍａｘ＿ａｕｔｈ＿ａｇｅ」パラメータを含んでいた場合、例示的な実施形態によれば、ＯＰは、「ｏｐｅｎｉｄ．ｐａｐｅ．ａｕｔｈ＿ｔｉｍｅ」をそのレスポンス中に含める。「ｏｐｅｎｉｄ．ｐａｐｅ．ｍａｘ＿ａｕｔｈ＿ａｇｅ」が要求されなかった場合、ＯＰは、「ｏｐｅｎｉｄ．ｐａｐｅ．ａｕｔｈ＿ｔｉｍｅ」をそのレスポンス中に含めることを選定し得る。
・ｏｐｅｎｉｄ．ｐａｐｅ．ａｕｔｈ＿ｌｅｖｅｌ．ｎｓ．＜ｃｕｓｔ＞：（オプション）国もしくは業界固有の標準団体、または他のグループもしくは個人など、様々なパーティによって定義されたカスタム保証レベルのための名前空間。このパラメータは、この保証レベルを表すＵＲＬを提供し得る。例えば、以下の通りである。
・ｏｐｅｎｉｄ．ｐａｐｅ．ａｕｔｈ＿ｌｅｖｅｌ．＜ｃｕｓｔ＞：（オプション）エンドユーザを認証するときにＯＰによって採用された認証方法およびポリシーに対応する、上記の標準団体、グループ、または個人によって定義されるような保証レベル。カスタム保証レベル定義は、その名前空間内で表現される追加のサブパラメータ値を定義し得るが、簡単の理由のために、これは、可能な場合は回避され得る。このパラメータは、この保証レベルに従って定義されたストリングを提供し得る。例は以下を含む。
上記で説明されたＰＡＰＥ拡張は、リライングパーティ１０４とＭＦＡＳ１０６との間の通信を可能にし得る。ｏｐｅｎｉｄ４ｊａｖａライブラリは、ＰＡＰＥ通信のために使用されるべきいくつかのクラスを提供する。それらのクラスは、必要とされた、および満足された保証レベルなどに関して、必要とされた情報を、ＯＰ１０６とリライングパーティ１０４との間で通信するために操作され得る。
上記で説明された動的な保証レベル機能性のために、ＭＦＡＳ１０６は、少なくともいくつか、例えばすべての、保証レベルのための可能なポリシーのマッピングを記憶し得る。例えば、保証レベルは、必要とされる数のネットワーク認証要素およびローカル認証要素に対してマッピングされ得る。ＭＦＡＳ１０６はまた、ユーザがそれらのデバイス能力に応じてそこから選定し得る、可能なネットワーク認証要素およびローカル認証要素のリストを維持し得る。ユーザ１０７は、登録プロセス中にポリシーまたは選好を規定することが可能にされ得る。ＭＦＡＳ１０６におけるポリシーの全体的なセット、ならびに、ユーザ１０７およびＵＥ１０２の能力から、ＭＦＡＳ１０６は、それが認証するためにそこから選定することができるポリシーサブセットを作成し得る。
様々な例示的な実施形態によれば、保証レベルは、あるトラストできる機関によって定義されたユーザ真正性の保証のレベルの列挙を、認証プロトコルと、認証のフレッシュネスなどの補足条件とにマッピングする。望まれる保証レベルは、異なる外部機関によって決定され得る。いくつかの場合には、リライングパーティまたはサービスプロバイダは、要求されたサービスをユーザに提供するために必要とした保証レベルを判断する外部機関であり得る。外部機関は、異なるセットの基準に基づいて、これらの保証レベルを固定し得る。例示的な基準は、アプリケーションもしくはサービス自体のためのセキュリティ要件、または、要求されたサービスをホストする会社のセキュリティポリシーを含む。
望まれる保証レベルが、担う機関によって規定されると、例示的な実施形態によれば、望まれる認証を実施する必要がある、ユーザエージェントと総称されるユーザまたはＵＥが、そうするための能力を有するか否かが判断される。これを評価した後、「デバイスごとの認証マッピングポリシー」が、必要とされる保証レベルと問題のユーザ機器の能力とに基づいて生成され得る。マッピングポリシーは、様々な形式の認証要素のユーザ選好に基づいて、さらに生成され得る。例えば、所与のユーザは、チャレンジ−レスポンスベースの認証を許容しないことがある。さらに例として、所与のユーザは、パスワードベースの認証と比較して、バイオメトリック認証を選好することがある。
例えば、バンキングアプリケーションは、ベーキングアプリケーションによって提供された銀行口座へのフルアクセスのための、高い保証レベルおよび／またはバイオメトリック認証を要求し得る。所与のＵＥがバイオメトリックセキュリティ能力を提供しない場合、ＩｄＰは、ＲＰとネゴシエートすることができる。例えば、ＩｄＰは、所与のＵＥの認証能力のうちの１つである、ＥＡＰ−ＳＩＭデバイス認証をオファーすることができる。オファーに対するレスポンスにおいて、ＲＰは、次いで、それが提供するサービスを格下げすることができる。例えば、銀行口座へのフルアクセスを提供する代わりに、ＲＰは、取引額を限定するか、または、いくつかの取引タイプを制限し得る。あるいは、ＩｄＰは、チャレンジ−レスポンスプロトコルを実施して、ユーザにとっての不都合という犠牲を払って、保証レベルを望まれるレベルまで増大させ得る。それはユーザにとって不都合であり、その理由は、ユーザは、ユーザがさらに検証されるようにセキュリティ質問に答えなければならないことがあるからである（例えば、あなたの母の旧姓は何か？ あなたの最初のペットの名前は何か？ あなたはどこで生まれたか？など）。
保証レベルマッピングは、例示的な実施形態によれば、経時的に変化し得る。例えば、デバイスの認証能力は、機能が可能にされ、または不可能にされることに基づいて、ユーザ選好が変化することに基づいてなど、変化し得る。デバイスは、容量が変化するとき、以下で説明されるように、再エンロールされる必要があり得る。
多要素認証が終了すると、ＳＰは、単一要素を使用する成功した認証（複数可）における単一のアサーション、または、保証レベルに従って組み合わされたアサーションを取得し得る。様々な実施形態によれば、そのようなアサーションを組み立て、トランスポートするための異なる方法がある。
署名付きアサーションを作成するための標準的な方法は、ＯｐｅｎＩＤ標準仕様によって規定される。それは、ＯｐｅｎＩＤプロバイダ（ＯＰ）エンティティと、ユーザの認証を要求する、リライングパーティ（ＲＰ）との間で、最初に共有キーを確立することからなる。このプロセスは、コールされた関連付けである。この場合、ＯＰエンティティは、ＯＰサービス機能（ＯＰＳＦ）とも呼ばれる、ＭＦＡＳシステムの一部であり、それは、認証要求がＲＰから受信されるとき、および、多要素認証を実行する前、共有キーを確立する。多要素認証ポリシーの成功した実行の後、ＭＦＡＳは、制御をＯＰＳＦエンティティに渡してよく、ＯＰＳＦエンティティは、次いで、前述の共有キーを使用してＯｐｅｎＩＤアサーションに署名する。アサーションは、標準仕様によれば、例えば文字のストリングまたはＪＳＯＮウェブトークンなど、異なるフォーマットを有し得る。１つの例示的な実施形態では、アサーションはまた、例えば、実行された多要素認証の具体的な詳細、認証されたユーザアイデンティティ、または他のコンテキスト情報を表し得る、情報エレメントを表す様々なデータを含有する。有意味なアサーションをどのように組み立てるかのいくつかの例示的なオプションが、以下で詳述される。
ＰＡＰＥが、保証レベルおよび／または必要とされる要素をシグナリングするために使用された、一実施形態では、次いで、ちょうどその情報が、ＯｐｅｎＩＤプロトコルランにおいて自動的に繰り越される。認証が実施された後、ＯｐｅｎＩＤプロバイダは、アサーションに署名し、そこで、署名は、任意のＰＡＰＥパラメータを含む、ＯｐｅｎＩＤアサーション要求中に含まれたパラメータを介して遂行される。すなわち、署名付きＯｐｅｎＩＤアサーションは、認証要素に関する情報への暗黙的アサーションを含有し得る。この場合、保証レベルと含有された要素認証とを立証することは、ＯｐｅｎＩＤプロバイダの義務であり得る。
別の実施形態では、識別されたユーザについての情報が、ＯｐｅｎＩＤ属性交換（ＡＸ）機構を使用して交換される。ＯｐｅｎＩＤ ＡＸは、ＯｐｅｎＩＤプロバイダが対象（例えば、識別されたユーザ）についての情報を記憶し、それを、要求するリライングパーティに提供するための、拡張可能な機構である。例えば、特定のＳＰが、ＭＦＡＳによって発行された汎用認証アサーションの検証を完了しており、それが、多要素認証がユーザおよびＵＥとともに成功裏に完了されたことを意味すると仮定され得る。例えば、ＯｐｅｎＩＤアサーションは、上記で説明されたように、ＰＡＰＥフィールドを含有し得る。ＲＰ／ＳＰは、単一要素認証についての詳細に関心があり得る。例えば、ＲＰ／ＳＰは、法科学使用のために、単一要素認証の各々のための署名付きアサーションを望むことがある。そのような情報を取得するために、ＲＰは、ＯｐｅｎＩＤ ＡＸフェッチ要求をＯＰへ送り、利用可能な情報のリストを要求し得る。要求の例は以下の通りである。
上記の要求は、実際の認証のリストについての要求と、また、利用可能な情報のリストがアイデンティティプロバイダによって署名されることの要求とを含む。一例として、ユーザの本名もまた要求され得る。元のＯｐｅｎＩＤアサーションが作成された時間を搬送するものとして定義され得る、タイムスタンプを含有することは、認証アサーションのフルネスのためにも重要であり得る。例示的なレスポンスは、以下を含む。
フェッチ要求に対する上記の例示的なレスポンスは、遂行された２つの認証のリストを含有する。この例では、署名属性行を除く、完全レスポンスが、ＯＰによって署名される。署名は、同じ署名キーを使用してそれに署名することによって、元のＯｐｅｎＩＤアサーションにバインドされ得る。これはまた、レスポンスを即時に検証するためのＲＰであり得る。
ＲＰは、個々の認証要素の識別子を知っているので、ＲＰは、例えば法科学または一般的なコンプライアンスの目的のために必要とされ得る、個々の要素についてのより多くの情報を要求するように続行し得る。例えば、サービスプロバイダ（ＲＰ）は、以下の情報など、ＥＡＰ ＳＩＭ認証の情報を要求し得る。
ＯＰは、ＳＰからの情報についての要求に応答し得る。例示的なレスポンスは、以下を含み得る。
上記の例示的なレスポンスを参照すると、署名は、元のアサーションのためのものと同じ署名秘密を使用して取得され得る。このレスポンスにおいて、ＯＰは、例えばユーザプライバシーを保護するために、事業者ポリシーによりＩＭＳＩを省略し得る。受信されたＳＩＭトリプレットは、認証のため、または認証を法科学的に再追跡するために無用であり得るが、ＥＡＰ ＳＩＭ認証を遂行した事業者には、レスポンス中に含有されている事業者レルムの情報によって、後に到達され得る。例えば、事業者は、トリプレットをＩＭＳＩに関連付けて、その正しさを妥当性検査し得る。
様々な例示的な実施形態では、他の属性交換が、他の認証要素のために使用される。指紋が認証のために使用される例として、属性交換は以下を含み得る。
上記で指紋例において示されたように、「機関」と呼ばれるサードパーティは、指紋を使用する認証を提供する。例えば、サードパーティは、バイオメトリック入力を処理し、それをテンプレートデータベースに対してマッチさせて、バイオメトリック認証を実施し得る。そのような場合、ＯＰは、例示的な実施形態によれば、認証についてのデータを生じないことになる。代わりに、ＯＰは、ＲＰを、認証データを提供することができる機関にダイレクトし得る。したがって、そのような属性要求のためのタイプは、汎用であり、認証要素の実際の種類に依存しなくてよいが、対応する属性の名称は、上記で示されたように、指紋認証要素に固有である。したがって、上記の例を参照すると、ｆｐ＿ａｕｔｈｏｒｉｔｙは、そこからＳＰが、任意の後の時間に、識別子「ｔｒａｎｓａｃｔｉｏｎ＿ｉｄ」を使用して認証についての詳細情報を要求することができる、適格なＵＲＬであり得る。さらに、ＳＰは、「ｆｐ＿ｒｅｑｕｅｓｔ＿ｐｒｏｔｏｃｏｌ」などのプロトコルを要求することができる。レスポンスは、例示的な要求に従って構築され得る。上記の例は、例示的な指紋認証を例示するが、例えばパスワード認証など、他の認証要素が、望まれるように実装され得ることは理解されよう。指紋またはパスワードが認証されるいくつかの場合には、実際のクレデンシャルデータと呼ばれることがある、指紋テンプレートデータまたはパスワードは、ＯＰまたは要素認証機関との属性交換中に含まれない。例えば、実際のクレデンシャルデータを含めることは、認証のセキュリティを低下させ得る。
次に図４を参照すると、例示的な認証システム４００は、１または複数の認証エンドポイント４０６、例えば、第１の認証エンドポイント４０６ａと、第２の認証エンドポイント４０６ｂと、第３の認証エンドポイント４０６ｃとを含む。システム４００は、クライアント４０２と呼ばれることもある、ＲＰ４０２と、ＯｐｅｎＩＤサーバ機能（ＯＰＳＦ）４０４とをさらに含む。ＯＰＳＦ４０４、ＲＰ４０２、および認証エンドポイント４０６は、ネットワークを介して互いと通信し得る。
いくつかの場合には、ＯｐｅｎＩＤアサーションは、ＯＰＳＦ４０４によって、成功した認証後に作成され、ユーザを通して適切なリライングパーティに持ち込まれる。アサーションは、認証タイプ、認証強度などの情報を、リライングパーティ４０２に提供し得る。ＯｐｅｎＩＤ ２．０は、多数の詳細が追加されるとき、長い署名付きアサーションを使用する。ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔは、トークンを使用するその動作を通して、このプロセスを大いに簡略化する。
多要素認証では、関与する認証の各々の性質についてのより多くの情報を理解する必要があり得る。ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔは、トークンを介して、必要とされた情報を指定されたエンドポイントからフェッチするために使用され得る。例えば、法科学では、各認証要素のための個々のアサーションの情報を取得することが有益であり得る。したがって、エンドポイント４０６の各々は、それぞれの認証要素に対応し得る。したがって、エンドポイント４０６の各々は、認証プロセスにおいてその要素のために作成されたアサーションの詳細を提供し得る。例えば、図示された実施形態によれば、４０２で、ＯＰＳＦ４０４が、認証アサーションを取り出すための１または複数のアクセストークンをプロビジョンする。４１０で、ＲＰ４０２が、１または複数のトークンのうちの第１のアクセストークンを、第１の認証エンドポイント４０６ａに提供する。レスポンスにおいて、４１２で、ＲＰ４０２が、第１の認証要素に関係付けられた、アサーションおよび他の情報を受信する。４１４で、ＲＰ４０２が、１または複数のトークンのうちの第２のアクセストークンを、第２の認証エンドポイント４０６ｂに提供する。レスポンスにおいて、４１６で、ＲＰ４０２が、第２の認証要素に関係付けられた、アサーションおよび他の情報を受信する。４１８で、ＲＰ４０２が、１または複数のトークンのうちの第３のアクセストークンを、第３の認証エンドポイント４０６ｃに提供する。レスポンスにおいて、４２０で、ＲＰ４０２が、第３の認証要素に関係付けられた、アサーションおよび他の情報を受信する。
図１を全体的に参照すると、認証は、シングルサインオン（ＳＳＯ）サブシステム、または、ローカルＯｐｅｎＩＤアイデンティティプロバイダ（ＯＰ）と呼ばれることもある、ＭＦＡＰ１１０を介して、ＵＥ１０２上でローカルに実施され得る。認証がローカルに実施され得る、いくつかの場合には、ＵＥ１０２の認証能力が識別子にマッピングしており、マッピングが、例えばセキュア環境において、ＵＥ上でローカルに記憶される。発見またはエンロールメントプロセス中に、ネットワークにおいて集められ、維持されるポリシー情報は、ＵＥ１０２、および詳細にはＭＦＡＰ１１０上でも利用可能であり得る。例えば、ネットワークＭＦＡＳ１０６は、ＭＦＡＰ１１０においてマッピング情報を構成し得る。責務の明瞭な区切りを維持するために、例えば、ＭＦＡＰ１１０は、利用可能な認証要素を使用して、ネットワーク側ＭＦＡＳ１０６ポリシーマッピング機能性を模倣し得る。ＭＦＡＰ１１０は、次いで、ユーザ１０７などの特定のユーザと、関連付けられたユーザ識別子とを、望まれるポリシー、およびしたがって認証要素とともにマッピングし得る。したがって、デバイスおよびユーザ認証能力がサードパーティに対してエクスポーズされる必要がないとき、ユーザのプライバシーは保護され得る。
また図５を参照すると、ＭＦＡＳ１０６およびＭＦＡＰ１１０は、ネットワークおよびデバイス側の異なる認証方法が実行され得るように、様々なポリシーに従って異なる方法で機能することができる。ＭＦＡＳ１０６において、ポリシーエンジン５０３など、極めて機能豊富なポリシーエンジンは、異なるセキュリティ要件、ユーザ要件、およびサービスプロバイダ要件に応じ得る。例えば、あらゆるユーザおよびユーザが使用するデバイス（複数可）についての可能な認証能力のリストがあり得、ポリシーエンジン５０３は、ユーザがＲＰ１０４からの保証レベル要件を満足するために実施することが可能である、ネットワーク認証要素およびローカル認証要素の組合せから、動的に選定し得る。簡略化された例示的なシナリオでは、ＭＦＡＳ１０６においてエンロールされるユーザの異なるデバイスのためにユーザが実施することができる、ネットワーク認証要素およびローカル認証要素の静的なリストがあり得、ポリシーエンジン５０３は、このネットワーク認証要素およびローカル認証要素組合せの静的なリストから選定し得る。
ＭＦＡＳ１０６およびＭＦＡＰ１１０の責務は、様々な実施形態によれば、変動する。一実施形態では、マスタ−スレーブ関係が、ＭＦＡＳ１０６と１１０ＭＦＡＰとの間に存在する。例えば、ユーザ１０７およびサービスプロバイダに関係するポリシーが、ＭＦＡＳ１０６において利用可能であり、ＭＦＡＳ１０６は、ネットワーク側とデバイス側の両方において、関連ポリシーの実行をイニシエートする。例示的な実施形態によれば、ＭＦＡＰ１１０は、ローカル認証要素を所与のシーケンスにおいて実行することによって、それがＭＦＡＳ１０６から受信する順序に従う。したがって、一実施形態では、ＭＦＡＰ１１０にはポリシーエンジンがない。
別の実施形態では、ユーザ１０７がＲＰ１０４からＭＦＡＳ１０６と通信すると、ＭＦＡＳ１０６におけるポリシーエンジン５０３は、ＭＦＡＳ１０６によってハンドリングされることになるネットワーク側ポリシーと、それがプロキシポリシーエンジンを使用してハンドリングすることができる、デバイス１０２上でＭＦＡＰ１１０においてハンドリングされるローカルポリシーとの明瞭な区切りを、動的に返す。この実施形態では、ＭＦＡＰ１１０は、ポリシープッシュ中を除いて、ＭＦＡＳ１０６によって直接制御されなくてよい。ポリシープッシュは、認証ごとに発生することがあり、または、ポリシーへの更新がある場合、後続のプッシュを含む初期ポリシープッシュとして発生することがある。
上記で説明された、例示的な実施形態では、ＭＦＡＳ１０６は、ＵＥ１０２の具象的なローカル認証能力を含有する情報と、構成されたポリシーおよびマッピング情報とを維持し得る。加えて、ポリシーは、認証要素への望まれる認証保証または保証レベルマッピングを達成するために使用されるべき認証要素に基づき得る。
図５を参照すると、さらに別の例示的な実施形態によれば、認証ポリシーへの保証レベルのマッピングは、ＭＦＡＳ１０６とＭＦＡＰ１１０との間で区切られ得る。すなわち、（ＲＰ１０３によって）要求された保証レベル（ＡＬ）は、ローカル保証レベル（ＡＬ＿ｌｏｃ）と、ポリシー、予め定義されたルール、およびマッピングテーブルに従って、様々なエンティティによって満たされる、ネットワーク保証レベル（ＡＬ＿ｎｅｔ）とに分離され得る。例えば、ＭＦＡＳ１０６は、分離を実行し、ＡＬ＿ｌｏｃを認証要求においてＭＦＡＰ１１０へ送ることができる。別の例では、ＭＦＡＰ１１０は、ＭＦＡＳ１０６と要件をネゴシエートし得る。ＭＦＡＰ１１０は、より低いＡＬ＿ｌｏｃ能力を示すメッセージで、ネゴシエーションに応答してよく、それにおいて、ＭＦＡＳは、ＡＬ＿ｎｅｔを、それに応じて、依然として全体的なＡＬを達成するように適合させる（例えば、それを高める）か、または、要件を満たすようにＭＦＡＰポリシーを適合させ得る。ＭＦＡＰ１１０のレスポンスは、ローカル条件、および／または、ローカルで維持されたデバイス能力情報（例えば、光条件が、現在、顔認識バイオメトリのために不十分である）に基づき得る。
さらに図５を参照すると、図示された実施形態によれば、５０４で、全体的なＡＬがＭＦＡＳ１０６に通信される。ＡＬマッピングエンジンは、例えば、計算エンジン、データベース、または、ＡＬマッピングエンジンおよびルックアップテーブル５０２と呼ばれることがあるルックアップテーブルを使用して、ＡＬ＿ｌｏｃおよびＡＬ＿ｎｅｔの仮の値を導出し得る。５０６で、ＡＬ＿ｌｏｃが、ＵＥ１０２およびＭＦＡＰ１１０に通信される。５０８で、ＭＦＡＰ１１０が、次いで、ＵＥ１０２上のローカル条件を評価し、その現在の能力を表すＡＬ＿ｌｏｃ＊で、ＭＦＡＳ１０６に応答し得る。ローカル保証レベルは、ＵＥ１０２の現在の条件に基づいており、したがって、図５では、同じものを示すためにアスタリスクとともに参照される。ローカル認証は、既に遂行されていることがあり、ＡＬ＿ｌｏｃ＊は、したがって、ローカルで達成された保証レベルを示す署名付きアサーションメッセージの一部であり得る。この場合、５０６におけるメッセージはまた、最小の必要とされるローカル保証レベル（ＡＬ＿ｌｏｃ＿ｍｉｎ）を表す、下限しきい値保証レベルを含有しており、下限しきい値さえもが達成可能ではない場合、ローカル認証を遂行するか、動作を中断するかを、ＭＦＡＰ１１０に決定させるようにすることがある。５０８で送られる保証レベルに基づいて、ＭＦＡＳ１０６は、５１０で、ＡＬ＿ｎｅｔをポリシー実行エンジン５０３にサブミットすることによって、ネットワークベースの認証を開始し得る。
ＭＦＡＰ１１０を使用することから導出される例示的な利益は、例えば、デバイス１０２がＭＦＡＳ１０６に接続されていないときでも、ローカルＭＦＡＰによってプロビジョンされたポリシーが認証を実行し得ることである。例えば、いくつかの場合には、デバイス１０２がネットワークに接続されていないので、ＭＦＡＳ１０６と通信することが可能ではない。他の場合には、ＭＦＡＳ１０６への通信は、例えば、ネットワークトラフィックを低減するため、または、ＭＦＡＳ１０６上の処理負担を低減するために限定される。ローカルで施行される認証ポリシーは、ネットワークポリシー機能と同期され、経時的に更新または再同期されてよく、その理由は、例えば、能力が変化することがあり、または、保証レベルから認証の要素へのマッピングが変化し得るからである。
例示的な実施形態によれば、ＯＰサーバは、本明細書で説明される多要素認証実施形態を実装するように拡張され得る。例えば、図６に図示された例示的なシステム６００を参照すると、ＯＰサーバ６０２は、ＯｐｅｎＩＤ仕様と競合することなしに、追加のインターフェースを含むように拡張され得る。ＯＰサーバ６０２は、例示的な実施形態によれば、アサーションに署名するか否かの最終決定を有し得る。例えば、アサーションがユーザ／ＵＥ６０６へ送り出された後、ＲＰ６０４は、それが有効である場合、アサーションを受け入れ得る。ＯＰサーバ６０２は、ＲＰ６０４およびユーザ６０６のためのＨＴＴＰＳベースのエンドポイントを実装し得る。バイオメトリック認証は、ユーザエージェント６０６がそれらのプロトコルを実行することができる限り、プロプライエタリプロトコルを介することができることは理解されよう。ＯＰ６０２が実際の認証を実施することは必要とされないことは、さらに理解されよう。したがって、認証は、他の認証サービスによって実施され得る。他の認証サービスは、認証の結果をＯＰ６０２にセキュアに返し得る。ＯＰ６０２および／または他の認証サービスは、例えば、様々な認証を一緒にバインドするために、認証プロセス中に含めるためのランダムナンスを生成し得る。さらに、結果を含有するメッセージは、認証のフレッシュネスのインディケーションと、ＯＰ６−２が成功／失敗メッセージを進行中のユーザログインセッションにマッピングすることができるように、セッション識別子とを含み得る。
図６を参照すると、図示された実施形態によれば、ＯＰ６０２は、例えばＯｐｅｎＩＤ ２．０エンティティなど、任意のＯｐｅｎＩＤアイデンティティプロバイダを指す。ＲＰ６０４は、例えばＯｐｅｎＩＤ ２．０ ＲＰなど、ＯｐｅｎＩＤリライングパーティを指す。ＵＥ６０６は、ユーザを有するモバイルデバイスなど、任意のユーザエージェントを表し得る。ＯＰ６０２における認証拡張インターフェース（認証ＸＩＦ）６０８は、ＯＰ６０２を認証サーバ６１０に接続する。認証サーバ６１０の各々は、実際のユーザ／ＵＥ認証方法をランし得る。例えば、認証サーバ６１０は、ユーザ認証を実施するために必要な情報（例えば、ＧＢＡの場合、ＳＬＦ）である、認証データを記憶し得る。多要素認証レイヤ６１１は、ＯＰ６０２に一体化される構成要素であってよく、それが、多要素認証が行われることを可能にする。多要素認証レイヤ６１１は、ＯＰ６０２およびポリシーレイヤ６１２が複数の認証要素をトリガし、異なる認証からの結果を収集／バインドするための、インターフェースをさらに提供し得る。ＩｄＰポリシーレイヤ６１２は、必要とされるポリシーに基づいて、どの認証方法をトリガするかを判断する、クロスレイヤ機能として働き得る。ポリシーレイヤ６１２はまた、複数の認証の成果を評価し、（例えば、必要とされるポリシーとのマッチングに基づいて）組み合わされた認証の結果をＯＰ６０２へ戻すように伝達してよく、ＯＰ６０２は、次いで（組み合わされた）アサーションを作成し得る。
さらに図６を参照すると、ユーザ認証拡張インターフェース６１４は、ＯＰ６０２によって、ユーザ／ＵＥ６０６のための認証プロセスをイニシエートするために必要とされ得る。このインターフェースは、ＨＴＴＰ（Ｓ）ベースであり得るが、このインターフェースは、例えばプロプライエタリプロトコルに基づくなど、代替的なベースであり得ることは理解されよう。ユーザ認証インターフェース６１６は、図示された実施形態によれば、認証サーバ６１０によって、ユーザ認証機構をランするために使用される。例えば、インターフェース６１６は、ＧＢＡキーを要求する、指紋を要求する、ＥＡＰ−ＳＩＭを要求するなどのために使用され得る。インターフェース６１６は、ＨＴＴＰ（Ｓ）ベースであるとして図示されるが、任意の適切なトランスポートプロトコルが、ＵＥ６０６と認証サーバ６１０との間でデータを渡すために使用され得ることは理解されよう。インターフェース６１８は、認証サーバ６１２０がそれぞれのクレデンシャルデータベース６２０を接続するための、内部インターフェースを表し得る。インターフェース６１８は、ＯＰ６０２、ＲＰ６０４、およびＵＥ６０６の観点から不可視であり得る。
複数の認証要素が使用されることになる場合、追加のインターフェース６０８がＯＰ６０２に追加され得る。例えば、図示されたシステム６００は、ＯＰ６０２を第１の認証サーバ６１０ａに結合する、第１のインターフェース６０８ａを示す。システムは、ＯＰ６０２を第２の認証サーバ６１０ｂに結合する、第２のインターフェース６０８ｂをさらに含む。認証拡張インターフェース６０８は、それぞれの認証サーバ６１０によって提供されるライブラリ／モジュールであり得る。例えば、インターフェース６０８は、Ｗｅｂキーのためのウェブキーアプリケーションコード、ＧＢＡのためのＮＡＦライブラリなどであり得る。例示的なシステム６００は、ＯＰ６０２が異なる認証方法を含むための、統一されたインターフェースを提供する。ＯＰ６０２は、異なる認証をトリガして、それらの結果を得て、適切なアサーションメッセージを構築し、認証方法に関する様々な情報を含み得る署名付きアサーションを（例えば、ＰＡＰＥを使用して）ＲＰ６０４へ送ることができる。ＲＰ６４０は、次いで、認証方法が認証強度の要求および必要とされるレベルを少なくとも満たすために十分であるか否かを、チェックすることができる。様々なライブラリがＯＰ６０２と一体化され得ることは理解されよう。さらに、認証要素は、順次または互いに並列にトリガされ得る。認証ＸＩＦ構成要素は、内部インターフェースを介して、例えばサーバ実装／コードへのライブラリまたはモジュールとして、ＯＰ６０２に一体化され得る。
上記で説明されたように、認証およびアサーションは、様々な実施形態によれば、様々な方法で遂行され得る。例えば、認証は、サーバ（ネットワーク）上で実施され、ネットワーク生成アサーションと組み合わされ得る。認証は、ＵＥ上（オンデバイスまたはローカル）で実施され、オンデバイス（ローカル）生成アサーションと組み合わされ得る。認証は、オンデバイス（ローカル）であり、ネットワーク生成アサーションと組み合わされ得る。認証は、オンデバイス（ローカル）であり、オンサーバ（ネットワーク）認証と組み合わされ得る。
次に図７Ａ〜図７Ｃを参照すると、例示的な認証システム７００は、１または複数の認証エージェント（ＡＡ）７１０、例えば、第１の認証エージェント（ＡＡ）７１０ａと、第２のＡＡ７１０ｂと、第３のＡＡ７１０ｃとを含む。図７Ａ〜図７Ｃは、ネットワークベースの多要素認証の一例を例示する。認証エージェントは、ＵＥ１０２の一部であってよく、ＵＥ１０２は、ユーザ１０７によって操作され得る。ＵＥ１０２、およびしたがってシステム７００は、限定はしないが、ブラウザ７０４と呼ばれることもある、クライアントアプリケーション７０４を含む。クライアントアプリケーション７０４はまた、例えばＡｎｄｒｉｏｄまたはｉＯＳ（登録商標）アプリケーションなど、モバイルアプリケーションであってもよく、したがって、モバイルアプリケーションと呼ばれることもある。システム７００は、マスタＩｄＰ／ＭＦＡＳ１０６と、ＲＰ／ＳＰ１０４と、１または複数の認証サーバ７０６とをさらに含む。参照番号は、便宜上、図の全体を通して繰り返され、２以上の図に現れる参照番号は、それらが現れる各図において同じまたは同様の特徴を指すことは理解されよう。３つの認証エージェントが認証システム７００において図示されているが、認証システム７００における認証エージェントの数が望まれるように変動し得ることは理解されよう。図示された実施形態によれば、第１の認証エージェント７１０ａは第１の認証サーバ７０６ａに関連付けられ、第２の認証エージェント７１０ｂは第２の認証サーバ７０６ｂに関連付けられ、第３の認証エージェント７１０ｃは第３の認証エージェント７０６ｃに関連付けられる。さらに、認証エージェント７１０および認証サーバは、３要素認証を可能にし、ブラウザ７０４が、ＳＰ１０４によってオファーされたサービスへのアクセスを提供され得るようにする。マスタＩｄＰ１０６、および認証サーバ７０６は、認証システム７００のネットワーク側と総称されることがある。例示的な３要素認証が図７Ａ〜図７Ｃに図示されているが、図７Ａ〜図７Ｃに示されたコールフローは、３要素より多いまたはより少ないものを使用する認証のために拡張され得ることは理解されよう。図示された実施形態によれば、ＭＦＡＰ１１０は、ＳＰ１０４のポリシー要件を査定し、マスタＩｄＰ１０６は、ポリシーを変換して、ポリシー要件を満たすことになる認証プロトコルのパラメータを判断する。
さらに図７Ａ〜図７Ｃを参照すると、図示された実施形態によれば、７１２で、ユーザ１０７が、ブラウザ７０４を介して（ＳＰ１０４によって提供された）サービスへのアクセスを要求する。ブラウザは、ＳＰ１０４と通信してよく、通信は、ユーザ１０７に関連付けられるユーザＩＤを含み得る。ユーザＩＤに基づいて、７１６で、ＳＰ１０４が発見を実施し、ユーザＩＤに関連付けられるマスタＩｄＰ１０６と関連付ける。マスタＩｄＰ１０６は、ＯｐｅｎＩＤアイデンティティプロバイダ（ＯＰ）またはネットワークアクセス機能（ＮＡＦ）に関連付けられる機能性を実施してよく、したがって、マスタＩｄＰ１０６はまた、ＯＰ１０６またはＮＡＦ１０６と呼ばれることもある。７１４で、図示された実施形態によれば、ＳＰ１０４が、例えばＳＰ１０４のポリシーに基づいて、ユーザ１０７がＳＰ１０４によって提供される、要求されたサービスにアクセスするために、多要素認証が必要とされると判断する。図示された実施形態によれば、ＳＰ１０４は、パスワード認証およびバイオメトリック認証が、サービスにアクセスするために必要とされると判断する。ＳＰ１０４はまた、ユーザがＳＰ１０４によって提供される、要求されたサービスにアクセスするために必要とされる、認証の保証のレベルを判断し得る。７１８および７２０で、図示された実施形態によれば、ＳＰ１０４が、ブラウザ７０４を介して、７２０でＨＴＴＰリダイレクト機構を使用して、その保証レベル要件をＭＦＡＳ／マスタＩｄＰ１０６へ通信する。
図示された実施形態によれば、ブラウザ７０４はまた、ＳＰ１０４によって必要とされる保証情報をトランスポートする。７２２で、サービスにアクセスするために必要とされる保証のレベルに基づいて、例えば、ＭＦＡＳ１０６が、必要とされる保証レベルを達成するために実施され得る認証要素のタイプおよび強度を判断する。ＭＦＡＳ１０６は、必要とされる認証を実施することができる認証エージェントをさらに識別し得る。例えば、図示された実施形態によれば、ＭＦＡＳ１０６は、第１のＡＡ７１０ａ、第２のＡＡ７１０ｂ、および第３のＡＡ７１０ｃが、判断された認証要素のタイプおよび強度に関連付けられると判断する。第１の認証エージェント７１０ａが識別された後、７２５で、ＭＦＡＳ１０６が、第１の認証要素の認証を実施するように、第１のＡＡ認証エージェント７１０をトリガし得る。７２６で、ＭＦＡＳ１０６がまた、第１の認証要素の認証を実施するように、第１の認証サーバ７０６ａをトリガし得る。例えば、ＭＦＡＳ１０６は、第１のＡＡ７１０ａに関連付けられる第１の認証サーバ７０６ａと通信して、第１の認証サーバ７０６ａが第１のＡＡによりイニシエートされた認証のためのコンテキストを作成することを要求し得る。７２４で、ＭＦＡＳ１０６が、場合によっては、第１の認証要素、または、少なくとも、第１の認証要素を準備するための機構を含む、メッセージをＭＦＡＰ１１０へ送ることによって、第１の認証要素をイニシエートし得る。７２５および７２６で実施されるステップは、互いに並列に実施され得る。代替的実施形態では、７２５および７２６を互いに並列に実施するのではなく、７２６におけるメッセージのみが送られ、７２５における認証を実施するためのトリガが、以下で説明される７２８で遂行される。
引き続き図７Ｂを参照すると、図示された実施形態によれば、７２８で、第１のＡＡ７１０ａおよび第１の認証サーバ７０６ａが、認証を遂行し得る。認証はまた、ユーザ１０７からの入力を必要とし得る。例えば、認証は、ブラウザ７０４のユーザ（例えば、ユーザのバイオメトリック）の、ブラウザ７０４の、ＵＥ１０２などの認証を備え得る。７２８で遂行された認証の成功または失敗は、７２８で、認証サーバ７０６ａによってＡＡ７１０ａへ通信され得る。７２８で遂行された認証は、例えば、チャレンジ−レスポンスメッセージをも含み得る、いくつかの往復メッセージングを伴い得る。例えば第１のアサーションなどのアサーションが、成功した認証において、第１の認証サーバ７０６ａによって生成され得る。第１のアサーションは、７３２で、第１の認証サーバ７０６ａによってＭＦＡＳ１０６へ送られ得る。第１のアサーションは、認証結果のフレッシュネスを含む認証結果を表し得る。あるいは、図示された実施形態によれば、第１のアサーションは、７３０で、第１のＡＡ７１０ａによって生成され、ＭＦＡＰ１１０へ送られ得る。それにかかわらず、認証が終了すると、第１のＡＡ７１０ａと第１の認証サーバ７０６ａの両方が、認証のプルーフを有してよく、プルーフは、図７によれば、第１のアサーションと呼ばれる。加えて、ＭＦＡＳ１０６およびＭＦＡＰ１１０は、７２８で遂行された第１の認証の知識およびプルーフを有し得る。
７３０で、７２５で受信されたトリガに対するレスポンスにおいて、第１のＡＡ７１０ａが、第１のアサーションを備えるトリガレスポンスを送り得る。トリガレスポンスは、ＭＦＡＰ１１０へ送られてよく、トリガレスポンスは、成功した認証が実施されたことを実証し得る。７３２で、ネットワーク側において、第１の認証サーバ７０６ａが、第１のアサーションおよびその関連付けられたフレッシュネス（例えば、認証が遂行されたときの日付／時間）をＭＦＡＳ１０６へ送り得る。
７３６で、図示された実施形態によれば、ＭＦＡＳ１０６が、第２の認証コンテキストを作成するように、第２の認証サーバ７０６ｂへトリガを送る。トリガされる第２の認証コンテキストは、第２の認証サーバ７０６ｂおよび第２のＡＡ７１０ｂによって実施される、第２の認証要素を使用する、第２の認証に関連付けられる。７３４で、例えばポリシーに基づいて、ＭＦＡＳ１０６が、ＭＦＡＰ１１０を介して第２のＡＡ７１０ｂへトリガを送ることによって、あるいはＭＦＡＰ１１０によってトリガされた、第２の認証要素を使用する第２の認証の開始をイニシエートし得る。７３４および７３６のステップは、互いに並列に実施されてよく、または、代替的実施形態では、７３６で、ＭＦＡＳ１０６から第２の認証サーバ７０６へのトリガのみが遂行される。７３８で、図示された実施形態によれば、第２の要素認証が、第２のＡＡ７１０ｂと第２の認証サーバ７０６ｂとの間で遂行される。第２の要素認証を実施するために使用される第２の要素は、ユーザのバイオメトリック、ユーザ１０７に関連付けられた別の要素、デバイス１０２に関連付けられた要素、ユーザ１０７の行動解析に関連付けられた要素などであり得る。あるいは、例えば、第２の要素認証は、第２のＡＡ７１０ｂとユーザ１０７との間で搬送され得る。そのような認証は、例えば、バイオメトリック認証、ユーザデバイスに関連付けられた要素の認証、またはユーザの行動解析に関連付けられた要素を含み得る。第２の要素認証が終了すると、第２の認証サーバ７０６ｂは、例えば第２のアサーションなど、アサーションを生成し得る。第２のアサーションは、ランダムナンスを備えてよく、および／または、チケットが暗号的に生成され得る。第２のアサーションは、第２のＡＡ７１０ｂへ送られ得る。あるいは、例示的な実施形態では、第２のＡＡ７１０ｂは、第２の認証サーバ７０６ｂによって第２のチケットを生成するために使用された同様の機構を使用して第２のチケットを生成し、したがって、第２のチケットは、第２の認証サーバ７０６ｂから第２のＡＡ７１０ｂへ送られない。７４０で、７３４で送られたトリガに対するレスポンスにおいて、第２のＡＡ７１０ｂが、第２のアサーションと、その関連付けられたフレッシュネスとをＭＦＡＰ１１０へ送る。同様に、７４２で、第２の認証サーバ７０６ｂが、第２のアサーションと、そのアサーションに関連付けられた認証のフレッシュネスとを、ＭＦＡＳ１０６へ送り得る。あるいは、例えば、ローカル認証が第２のＡＡ７１０ｂによって遂行される場合、第２のＡＡ７１０ｂは、第２のアサーションを生成し、第２のアサーションをＭＦＡＰ１１０へフォワードし得る。望まれるような任意の数の認証要素は理解されよう。したがって、ステップ７４３および７４５は、第３のＡＡ７１０ｃおよび第３の認証サーバ７０６ｃがそれぞれ第２のＡＡ７１０ｂおよび第２の認証サーバ７０６ｂの代わりに使用されることを除いて、それぞれ、ステップ７３４および７３６のように実施され得る。さらに、ステップ７４７、７４９、および７５１は、それぞれ、ステップ７３８、７４０、および７４２を参照しながら上記で説明されたように実施され得る。
引き続き図７Ａ〜図７Ｃを参照すると、図示された実施形態によれば、７４４で、ＭＦＡＳ１０６が、第１のアサーションと、第２のアサーションと、第３のアサーションとを統合して、複数の認証要素のための統合されたアサーションを作成する。一例では、アグリゲート保証レベルは、各認証要素に関連付けられた保証レベルを一緒に合計することによって計算される。別の例として、両方の認証要素に対応するアグリゲート保証レベルにおいて、一方の認証要素が別の認証要素と比較してより重く重み付けされるように、保証レベルが重み付けされ得る。各認証要素の年数を考慮に入れる、フレッシュネス低下関数（freshness decay function）など、追加のパラメータが、アグリゲート保証レベルを計算することにおいて考慮され得る。別の実施形態では、ＭＦＡＳ１０６は、計算されたアグリゲート保証レベルを送らない。例えば、ＭＦＡＳ１０６は、各認証の結果を送り得る。７４６で、ブラウザ７０４が、統合されたアサーションをＭＦＡＳ１０６から受信する。７４８で、ブラウザ７０４が、アサーションをＳＰ１０４へリダイレクトして送る。アグリゲート保証レベルを含有し得る、署名付きアサーションが、ＭＦＡＳ１０６によって、７４６でＵＥブラウザを介して、例えばＨＴＴＰリダイレクトメッセージを使用することによってＳＰ１０４へ通信される。あるいは、アグリゲート保証レベルを含有する署名付きアサーションは、他のチャネルを使用して、ＭＦＡＳ１０６によってＳＰ１０４へ直接通信され得る。送られる署名付きアサーションは、各認証要素のためのフレッシュネスレベルと、実施された多要素認証によって達成された保証レベルとを含み得る。７５０で、図示された実施形態によれば、ＳＰ１０４が、アサーション、および詳細にはアサーション署名を検証し、７５２で、ＳＰ１０４によって提供された、要求されたサービスへのアクセスを、ブラウザ７０４のユーザ１０７に提供する。
図８Ａ〜図８Ｃは、認証がＵＥ１０２上で実施される、図７Ａ〜図７Ｃの変形形態を図示する。図８Ａ〜図８Ｃに図示されているステップの大部分は、図７Ａ〜図７Ｃに関して説明される。特に図８Ａを参照すると、７１８ａで、図示された実施形態によれば、ＳＰ１０４が、ブラウザ７０４を介して、その保証レベル要件をＭＦＡＳ１０６へ通信する。あるいは、ＳＰ１０４は、ＳＰ１０４とＭＦＡＳ１０６との間で直接確立されるチャネルを通して、その保証レベル要件を通信し得る。そのようなチャネルは、７１６で発生する発見および関連付けの一部として確立され得る。７２０ａで、ブラウザ７０４がＭＦＡＳ１０６へリダイレクトされ、ＳＰ１０４がブラウザ７０４を介してＭＦＡＳ１０６のサービスを呼び出すようにされる。７２２で、ＭＦＡＳ１０６が、ＳＰ１０４によって要求された保証レベルを達成するために呼び出されなければならないことがある、認証要素のタイプおよび数を判断する。７２４ａで、ＭＦＡＳ１０６が、ブラウザ７０４を介して、ＭＦＡＰ１１０へメッセージまたはトリガを送ることによって、多要素認証要素をイニシエートする。メッセージまたはトリガは、認証要素を含み得る。メッセージまたはトリガはまた、認証要素の代わりに、または認証要素に加えて送られる、必要とされる保証レベルを含み得る。ＭＦＡＰ１１０は、保証レベルを使用して、認証要素を判断し得る。８０２で、ブラウザ７０４がＭＦＡＰ１１０へリダイレクトされるか、または、ＭＦＡＰ１１０がトリガされる。第１の認証エージェント７１０ａが識別された後、７２５で、ＭＦＡＳ１０６が、第１の認証要素の認証を実施するように、第１のＡＡ認証エージェント７１０ａをトリガし得る。７２８ａで、特に図８Ｂを参照すると、第１のＡＡ７１０ａおよびユーザ１０７が、認証を遂行し得る。ユーザ１０７はまた、例えばバイオメトリックリーダなど、リーダを指すこともある。７２８ａにおける認証は、ユーザ１０７からの入力を必要とし得る。図示された実施形態によれば、第１のアサーションが、７３０で、第１のＡＡ７１０ａによって生成され、ＭＦＡＰ１１０へ送られ得る。同様に、７３８ａで、第２のＡＡ７１０ｂおよびユーザ１０７が、ＭＦＡＰ１１０によって第２のＡＡ７１０ｂへ送られたトリガに対するレスポンスにおいて、認証を遂行して、第２の認証結果を作成し得る。７４０で、第２のＡＡ７１０ｂが、第２の認証結果をＭＦＡＰ１１０へ送る。さらに、７４７ａで、第３のＡＡ７１０ｃおよびユーザ１０７、および詳細にはリーダが、ＭＦＡＰ１１０によって第３のＡＡ７１０ｃに対してイニシエートされたトリガに基づいて、認証を遂行して、第３の認証結果を作成し得る。７４９で、引き続き図７Ａ〜図７Ｃを参照すると、図示された実施形態によれば、第３の認証の結果が、第３のＡＡ７１０ｃによってＭＦＡＰ１１０へ送られる。７４４ａで、ＭＦＡＰ１１０が、第１の認証アサーションと、第２の認証アサーションと、第３の認証アサーションとを統合して、複数の認証要素のための統合されたアサーションを作成する。ＭＦＡＰ１１０は、統合されたアサーションに署名する。ＭＦＡＰ１１０は、アグリゲート達成された保証レベルおよびフレッシュネスレベルをさらに計算し得る。一例では、アグリゲート保証レベルは、各認証要素に関連付けられた保証レベルを一緒に合計することによって計算される。別の例として、両方の認証要素に対応するアグリゲート保証レベルにおいて、一方の認証要素が別の認証要素と比較してより重く重み付けされるように、保証レベルが重み付けされ得る。各認証要素の年数を考慮に入れる、フレッシュネス低下関数など、追加のパラメータが、アグリゲート保証レベルを計算することにおいて考慮され得る。別の実施形態では、ＭＦＡＳ１０６は、計算されたアグリゲート保証レベルを送らない。７４６ａで、ブラウザ７０４が、統合アサーションをＭＦＡＰ１１０から受信する。７４８で、ブラウザ７０４が、アサーションをＳＰ１０４へ送る。送られるアサーションは、保証レベルと、実施された多要素認証によって達成されたフレッシュネスレベルとを含み得る。７５０で、図示された実施形態によれば、ＳＰ１０４が、アサーション、および詳細にはアサーション署名を検証し、７５２で、ＳＰ１０４によって提供された、要求されたサービスへのアクセスを、ブラウザ７０４のユーザ１０７に提供する。
図９Ａ〜図９Ｃは、アサーションがネットワークによって遂行され得るが、認証がＭＦＡＰ１１０を用いてＵＥ１０２上で遂行され得る、図７Ａ〜図７Ｃおよび図８Ａ〜図８Ｃの変形形態を図示する。図９Ａ〜図９Ｃに図示されているステップの大部分は、図７Ａ〜図７Ｃおよび図８Ａ〜図８Ｃに関して説明される。図９Ａ〜図９Ｃを参照すると、図示された実施形態によれば、９０１で、ＭＦＡＰ１１０が、第１の認証結果と、第２の認証結果と、第３の認証結果とを組み合わせる。ＭＦＡＰ１１０は、ブラウザ７０４のために、アグリゲート達成された保証レベルおよびフレッシュネスレベルをさらに計算し得る。一例では、アグリゲート保証レベルは、各認証要素に関連付けられた保証レベルを一緒に合計することによって計算される。別の例として、両方の認証要素に対応するアグリゲート保証レベルにおいて、一方の認証要素が別の認証要素と比較してより重く重み付けされるように、保証レベルが重み付けされ得る。各認証要素の年数を考慮に入れる、フレッシュネス低下関数など、追加のパラメータが、アグリゲート保証要素を計算することにおいて考慮され得る。９０２および９０４で、ＭＦＡＰ１１０が、組み合わされた結果を関連付けられた情報とともに、ブラウザ７０４を介してＭＦＡＳ１０６へ送る。７４４ｂで、ＭＦＡＳ１０６が、受信された認証結果に基づいて、署名付きアサーションを作成する。ＭＦＡＳ１０６は、図９Ａ〜図９Ｃに図示された実施形態によれば、統合されたアサーションに署名する。９０６で、ＭＦＡＳ１０６が、ブラウザ７０４を使用して、署名付きアサーションを送る。ブラウザ７０４は、統合アサーションをＭＦＡＳ１０６から受信する。７４８で、ブラウザ７０４が、アサーションをＳＰ１０４へリダイレクトする。送られるアサーションは、保証レベルと、実施された多要素認証によって達成されたフレッシュネスレベルとを含み得る。７５０で、図示された実施形態によれば、ＳＰ１０４が、アサーション、および詳細にはアサーション署名を検証し、７５２で、ＳＰ１０４によって提供された、要求されたサービスへのアクセスを、ブラウザ７０４のユーザ１０７に提供する。上記で説明されたオンデバイス認証またはオンネットワーク認証のうちの少なくとも１つは、１または複数のポリシーに従って遂行され得ることは理解されよう。さらに、署名付きアサーションは、ＵＥ１０２上でＭＦＡＰ１１０を用いて生成されてよく、または、署名付きアサーションは、ＩｄＰ／ＭＦＡＳ１０６上で生成されてよい。
次に図１０を参照すると、例示的なシステム１０００は、第１のネットワークエンティティ１００２ａに折りたたまれた第１のＲＰ１０４ａと第１のＩｄＰ１０６ａとを含む、サービスプロバイダ機能を含む。同様に、第２のネットワークエンティティ１００２ａは、第２のＲＰ１０４ｂと第２のＩｄＰ１０６ｂとを含み、第３のネットワークエンティティ１００２ｃは、第３のＲＰ１０４ｃと第３のＩｄＰ１０６ｃとを含む。したがって、ネットワークエンティティ１０００２は、より強力な認証サービスを提供するために、それらのそれぞれのＲＰにおいてＭＦＡＳ機能をそれぞれホストすることができる。図示された実施形態によれば、図示されたリライングパーティはまた、複数の認証要素を実施することができるＩｄＰの役割を実施し得る。したがって、パスワードなど、認証のための１つの要素を現在使用している、例えば銀行などの所与のＲＰは、折りたたまれたＲＰ／ＩｄＰ内で制御されるＭＦＡＳ機能をホストすることによって、多要素認証の方へ進化し得る。ネットワークエンティティ１００２の構成はまた、ＲＰが、例えばモバイルネットワーク事業者などのサードパーティによって提供される他の認証要素に接続することも可能にし得る。
さらに図１０を全体的に参照すると、図示されたＲＰ／ＩｄＰ折りたたみ機能は、以下で説明されるように、プライバシーを保護し得る。例えば、ＯｐｅｎＩＤは、識別子選択動作モードとして知られるアイデンティティプライバシーのための機構を提供する。疑似アイデンティティ（ＰＩＤ）は、例示的な実施形態によれば、代替的な方法で達成され得る。例として、ユーザがＩｄＰによって、ＭＦＡＳのサービスを使用して認証される場合、（ＰＩＤ）と呼ばれることがある、一時的アイデンティティが作成され得る。ＲＰのサービスを取得することを望むユーザは、次いで、認証保証およびフレッシュネスが、アクセスされている特定のサービスのために十分であると仮定して、ＰＩＤを使用するＩｄＰとの既存の認証を活用することによって、ＲＰへのシームレスなアクセスを得ることができる。例示的な実施形態では、ＰＩＤは、ユーザのアイデンティティとして、サービスプロバイダ発行アイデンティティと一緒に提示され、事前認証情報が、発見を通して回復される。例えば、事前認証情報がアクセスのために十分である場合、シームレスおよび透過的なアクセスが、別の認証を実施することなしに提供される。これは、例えば、ユーザが一旦認証され、次いで、ＰＩＤが時間期間（例えば、１時間）にわたって有効であるとき、有用であり得、したがって、他のＲＰにアクセスするためのいかなる後続の試みも、認証がリフレッシュを必要とするように時間期間（例えば、その時間）が満了するまで、ユーザ介入なしにシームレスに提供される。
どのようにＰＩＤが導出され得るかの一例が以下のように示され、それは、例として提示され、限定として提示されない。
ｓｅｓｓｉｏｎＩＤは、ＨＴＴＰセッションまたはＴＬＳ−マスタ秘密に関連付けられ得る。ナンスは、ＭＦＡＳによって、ＰＩＤの新しい生成ごとに生成され得る。ＲＰ−ＩＤは、ＲＰのドメインＩＤ（例えば、ｗｗｗ．ｂａｎｋｏｆａｍｅｒｉｃａ．ｃｏｍなど、サーバ認定書内のドメイン情報）であり得る。「ストリング」は、オプションである何かであってよく、例えばＰＩＤ生成など、動作のタイプを識別する。「ＳｅｓｓｉｏｎＳｔｒｉｎｇ」は、この例によれば、上記で示された様々なパラメータの連結である。
図１１を参照すると、ユーザ１１０２と、組み合わされた機能性を有する第１のＲＰおよびＩｄＰを含むネットワークエンティティ１１０４と、第２のＲＰ１１０６とを含む例示的なシステム１１００である。ネットワークエンティティ１１０４はまた、上記で説明されたような、ＭＦＡＳを含み得る。ユーザ１１０２は、図１１において「Ｊａｎｅ」と呼ばれる。例示的なシステム１１００は、開示される主題の説明を容易にするために簡略化され、本開示の範囲を限定することは意図されないことは諒解されよう。他のデバイス、システム、および構成が、システム１１００などのシステムに加えて、またはその代わりに、本明細書で開示された実施形態を実装するために使用されてよく、すべてのそのような実施形態が、本開示の範囲内として企図される。
図示された実施形態によれば、１１０８で、ユーザ１１０２が、自分のＵＥにおいてローカルで認証される。例えば、ユーザ１１０２は、バイオメトリック認証が発生するように、ＵＥの指紋センサをスワイプし得る。バイオメトリック認証が完了すると、それは、次いで、ネットワークエンティティ１１０４上でＭＦＡＳへのローカル認証の登録をトリガし得る。追加の認証要素は、ローカルで実施されてよく、それらは、ＵＥ１１０２上にロケートされるＭＦＡＰ１１０によって容易にされてよく、または、追加の認証が、ＩｄＰ１１０４のサービスを使用してネットワーク上で実施され得る。例えば、１１１０で、ネットワーク認証が、ネットワークエンティティ１１０４、および詳細にはＭＦＡＳによって実施され得る。１１１０における認証に基づいて、１１１２で、疑似アイデンティティ（ＩＤ）（ＰＩＤ）であり得る一時的アイデンティティが作成される。ＰＩＤは、以前に遂行された認証に対応する、関連付けられた存続期間と保証レベルとを有し得る。１１１４で、ＰＩＤがユーザ１１０２へ送られる。１１１６で、ＰＩＤが、例えばトラステッドプラットフォームモジュール（ＴＰＭ）またはトラステッド実行環境（ＴＥＥ）など、セキュアエレメント内に記憶され、ＰＩＤがＭＦＡＰ１１０にとってのみアクセス可能であるようになる。１１１８で、ユーザが、例えばユーザの銀行であり得る、第２のＲＰ１１０６によって提供されたサービスにアクセスすることを望む。１１２０で、ユーザのＵＥ上のＭＦＡＰが、有効な存続期間（満了していない）をもつ有効な認証があると認識する。有効な認証は、以前に遂行された認証を表す。ユーザのＵＥ上のＭＦＡＰは、ＰＩＤを取得し、ＰＩＤを、第２のＲＰ１１０６に関連付けられるユーザアイデンティティ（ＵＩＤ）とともに組み込む。１１２２で、ＵＥが、ＰＩＤと、第２のＲＰ１１０６に関連付けられたＵＩＤとを、第２のＲＰ１１０６へ送る。１１２４で、第２のＲＰ１１０６が、場合によっては、例えばＰＩＤとともに提供されたドメイン情報に基づいて、ＵＩＤに関連付けられるＰＩＤを検証し得る。１１２６で、ＲＰ１１０６が、ＲＰ１／ＩｄＰ１１０４と呼ばれることもある、ネットワークエンティティ１１０４を発見するために、ＰＩＤに基づいて発見プロセスを実施する。ＲＰ１１０６は、ユーザ（Ｊａｎｅ）が、そのユーザが要求したサービスにアクセスするために必要とされる、保証レベル（ＡＬ）要件を判断する。１１２８および１１３０で、ユーザ１１０２が、ＲＰ１１０６によって、ネットワークエンティティ１１０４、および詳細にはＩｄＰ１１０４へリダイレクトされる。リダイレクションは、保証レベル要件を示す情報を含み得る。１１３２で、ＭＦＡＳが、そのＰＩＤのための有効な認証があると認識した。ＭＦＡＳは、ＰＩＤを組み込み、場合によっては、ユーザのプロファイル情報に関連付けられるパラメータを含み得る。ＭＦＡＳは、ＩｄＰ１１０４によって第２のＲＰ１１０６へ送られる署名付きアサーションを作成する。１１３４で、ネットワークエンティティ、および詳細にはＭＦＡＳが、ユーザ１１０２を介して（例えば、Ｊａｎｅのウェブブラウザを介して）、署名付きアサーションを第２のＲＰ１１０６へ送る。ユーザ１１０２は、ＵＥを介して、署名付きアサーションをＲＰ１１０６へフォワードする。１１３８で、第２のＲＰ１１０６が、それがＵＥから受信する署名付きアサーションを検証する。署名付きアサーションが有効である場合、ＲＰ１１０６が、成功メッセージをユーザ１１０２へ送り、１１４２で、ユーザ／ＵＥが、ＲＰ１１０６によって提供されるサービスへのアクセスを受信することができる。したがって、ユーザ１１０２は、ＲＰ１１０６によって、ネットワークエンティティ１１０２の一部であるＲＰとの既存の認証を活用することによって、シームレスに認証される。
次に図１２Ａ〜図１２Ｅ、およびまた図１を全体的に参照すると、例示的なシステム１２００は、図１２Ａ〜図１２Ｅにおいて「Ｊａｎｅ」と呼ばれるユーザ１０７を有するＵＥ１０２を含む。ＵＥ１０２は、ローカルバイオメトリック認証機能１１２と呼ばれることもある、バイオメトリッククライアント１１２を含む。ＵＥ１０２は、ＭＦＡＰ１１０とブラウザ７０４とをさらに含む。システム１２００は、第１のＲＰ１２０２と、第２のＲＰ１２０４と、マスタＩｄＰ１０６と呼ばれることもある、ＭＦＡＳ１０６とをさらに含む。
特に図１２Ａを参照すると、図示された実施形態によれば、１２０６で、１回目に、ユーザ１０７が、第１のＲＰ１２０２である、自分の銀行（ｗｗｗ．ｂａｃ．ｃｏｍ）と少なくとも１つの取引を実施することを望む。１２０８で、ユーザ１０７が、自分のユーザアイデンティティ（例えば、ｊａｎｅ＠ｂａｃ．ｃｏｍ）を、第１のＲＰ１２０２によって提供されたポータルの「ユーザｉｄ」フィールド内に入力する。ブラウザ７０４またはブラウザプラグインは、使用され得るＰＩＤがあるか否かを判断し得る。１２１０で、第１のＲＰ１２０２が、例えばユーザアイデンティティに基づいて、ＭＦＡＳに関連付ける。１２１２で、図示された実施形態によれば、ＲＰ１２０２（ｗｗｗ．ｂａｃ．ｃｏｍ）におけるポリシーが、要求されているサービスにユーザ１０７がアクセスするために必要とされる保証レベルを判断する。必要とされる保証レベルは、ユーザ１０７に関係付けられたユーザプロファイル情報に基づいて判断され得る。例えば、ＭＦＡＳ１０６は、ユーザプロファイル情報をユーザプロファイルデータベース（ＤＢ）１２０３から取り出し得る。必要とされる保証レベル（ＡＬ）はまた、ポリシーＤＢ内に記憶されたポリシーに基づいて判断され得る。ポリシーエンジンおよびＤＢは、マスタＩｄＰ／ＭＦＡＳ／ＯＰ１０６にロケートされ得る。１２１４で、ＲＰ１２０２が、ブラウザ７０４を介して、一般に認証要件と呼ばれることがある、必要とされる保証レベルと、セッションハンドルまたはチャレンジとで応答する。１６で、インテントがＭＦＡＰ１１０をコールする。
特に図１２を参照すると、図示された実施形態によれば、１２１８で、ＲＰ１２０２によって必要とされたポリシーおよびＡＬと、遂行されたフレッシュな認証とに基づいて、ＭＦＡＰ１１０が、遂行されなければならないことになる残りの認証要素を判断する。１２２０で、ＭＦＡＰ１１０が、パスワード（ＰＷＤ）認証が遂行されなければならないと判断してよく、したがって、ユーザ１０７に、自分のＰＷＤを入力するように要求する。１２２２で、ユーザ１０７が自分のＰＷＤを入力し、ＰＷＤがＭＦＡＰ１１０において受信される。１２２４で、ＭＦＡＰ１１０がパスワードをチェックし、ポリシーに基づいて、それが、ローカルバイオメトリック認証が発生するべきであると判断する。１２２６で、ＭＦＡＰ１１０が、バイオメトリックアプリケーション１１２と呼ばれることもある、ローカルバイオメトリック認証機能１１２を呼び出す。１２２８で、バイオメトリックアプリケーション１１２が、ユーザ１０７に、自分の指を指紋リーダ上にスワイプさせるように要求し得る。１２３０で、ユーザ１０７が、自分の指を指紋リーダに結合されたセンサ上に走らせ、指紋（複数可）がバイオメトリックアプリケーション１１２へ送られる。
特に図１２Ｃを参照すると、図示された実施形態によれば、１２３２で、バイオメトリックアプリケーション１１２が、受信された指紋から指紋モデルを生成し、そのモデルを、指紋エンロールメントプロセス中に作成された、ローカルに記憶され、セキュアにされた指紋モデルと比較する。１２３４で、バイオメトリック認証の結果が、バイオメトリックアプリケーション１１２によってＭＦＡＰ１１０へ送られる。１２３６で、上記で説明された認証要素の両方が成功裏に遂行される場合、署名付きアサーションが、ＲＰ１２０２によって提供されたハンドル／チャレンジを使用して作成される。署名キーは、マスタＩｄＰ／ＭＦＡＳ１０６と、ＲＰ１２０２と、ＭＦＡＰ１１０との間の共有秘密であり得る。あるいは、ＭＦＡＰ１１０のプライベートキーが、アサーションに署名するために使用されてよく、ＭＦＡＰ１１０の対応する公開キーが、登録プロセス中にＭＦＡＳ１０６に登録されていてよい。署名付きアサーションは、ブラウザ７０４を介してＲＰ１２０２へ送られ得る。加えて、例示的な実施形態によれば、１２４２で、ＰＩＤが生成される。例えば、ＰＩＤは、例えばＨＭＡＣ−ＳＨＡ−２５６（ＰＩＤＫｅｙ，ＳｅｓｓｉｏｎＳｔｒｉｎｇ）＠ｂａｃ．ｃｏｍなどの関数に等しくなり得る。１２３８で、ＭＦＡＰ１１０が、署名付きアサーションをＰＩＤとともにＭＦＡＳ／マスタＩｄＰ１０６へ送る。１２４０で、ＭＦＡＳ１０６が、署名付きアサーションと、取得された保証レベルとを検証する。さらに、ＭＦＡＳ１０６が、１２４４で、ＰＩＤをユーザプロファイルＤＢ１２０３内に登録し得る。１２４６で、図示された実施形態によれば、ＭＦＡＳ１０６が、ＰＩＤの登録を確認し、ＨＴＴＰ ２００ ＯＫメッセージをＭＦＡＰ１１０へ送る。１２４８で、ブラウザ７０４が、ＵＥ１０２上のユーザＤＢを、以下でさらに説明される、その特定のトラストサークル（ＣｏＴ）についてのＰＩＤ情報で更新する。したがって、ＰＩＤは、ＭＦＡＰ１１０内に登録され、ユーザ１０８は、第１のＲＰ１２０４（例えば、ｗｗｗ．ｂａｃ．ｃｏｍ）によって提供されたサービスへのアクセスを有する。
特に図１２Ｄを参照すると、１回目よりも後である２回目に、ユーザは、例えばブローカー（例えば、Ｍｅｒｒｉｌｌ Ｌｙｎｃｈ（登録商標））であり得る、第２のＲＰ１２０４といくつかの取引を実施することを望む。第１のＲＰおよび第２のＲＰは、望まれるような任意のサービスプロバイダであり得ることは理解されよう。１２４２で、ユーザ１０７が、第２のＲＰ１２０４に関連付けられる自分のｉｄ（ｊａｎｅ＠ｍｅｒｒｉｌｌｙｎｃｈ．ｃｏｍ）を使用して、自分のサービス要求を第２のＲＰ１２０４へ送ることを試みる。１２５４で、ブラウザプラグイン７０４が、その要求が、第１のＲＰ１２０２と同じＣｏＴ内に属するＲＰ１２０４に対して行われると判断する。さらに、ブラウザ７０４は、ＰＩＤがそのユーザ１０７のために既に存在すると判断する。したがって、ユーザアイデンティティがＰＩＤで置き換えられる。１２５６で、ＰＩＤ（例えば、ａｂｃｌ２ｄｅ８２．．．＠ｂａｃ．ｃｏｍ）が、「ユーザｉｄ」としてＲＰ１２０４（ｗｗｗ．ｍｅｒｒｉｌｌｙｎｃｈ．ｃｏｍ）へ送られる。１２５８で、ＰＩＤに関連付けられたドメイン名（例えば、ｂａｃ．ｃｏｍ）に基づいて、ＯｐｅｎＩＤを使用する発見および関連付けが、ＭＦＡＳ１０６と第２のＲＰ１２０４との間で遂行される。１２６０および１２６２で、ＨＴＴＰメッセージがマスタＩｄＰ１０６（ｗｗｗ．ｂａｃ．ｃｏｍ）へリダイレクトされ、それはまた、この例示的なシナリオではＲＰ１２０４でもあり得る。１２６４で、図示された例によれば、ＩｄＰ１０６が、ＡＬ要件をチェックし、ネットワークベースの認証が許容できるものであり、フレッシュなローカル認証が必要とされると判断する。
特に図１２Ｅを参照すると、図示された実施形態によれば、ＭＦＡＳ１０６が、ハンドル／チャレンジとＡＬ要件とを、ブラウザ７０４を介してＭＦＡＰ１１０へ送る。１２６８で、ハンドル／チャレンジおよびＡＬ要件が、ＭＦＡＰ１１０へ送られる。１２７０で、ＭＦＡＰ１１０が、要求された認証のポリシーおよびフレッシュネスに基づいて、任意のローカル認証／要素が遂行されなければならないか否かを判断する。図示された例によれば、ＭＦＡＰ１１０が、１２７０で署名付きアサーションを作成する。１２７２で、署名付きアサーションが、ブラウザ７０４を介してＭＦＡＳ１０６へフォワードされる。１２７４で、ＭＦＡＳ１０６が、署名付きアサーションを検証し、必要とされるＡＬが達成されたか否かを検証する。１２７６で、ＯＩＤプロトコルの後に続いて、例えば、署名付きアサーションを含有するリダイレクトメッセージが、第２のＲＰ１２０４（ｗｗｗ．ｍｅｒｒｉｌｌｙｎｃｈ．ｃｏｍ）へ送られる。１２８０で、アサーションがＲＰ１２０４によって検証される。１２８２で、ＲＰがＨＴＴＰ ２００ Ｏｋメッセージをユーザへ送り、ユーザ１０７が、第２のＲＰ１２０４によって提供される、要求されたサービスにアクセスすることができる。したがって、第１の認証中に生成されるＰＩＤは、ユーザ介入なしに、他のサービスプロバイダによって提供されたサービスへのシームレスで自動化されたアクセスを得るために、後で使用され得る。
図１３および図１４を参照すると、第１のトラストサークル（ＣｏＴ）１３０２および第２のＣｏＴ１３０４が、ＵＥ１０２に関連付けられ得る。各ＣｏＴは、もう１つのリライングパーティ１３０６を含み得る。例示的な実施形態では、ＲＰは、同じＣｏＴ中にあるパートナーを通して、様々なサービスを提供し得る。例えば、ＲＰは、ＩｄＰサービスをＣｏＴ内の他のＲＰ（パートナー）へ提供し得る。いくつかの場合には、ユーザがそれと対話する第１のＲＰは、ＣｏＴ内のメンバーにとってＩｄＰとして作用することができる。ＣｏＴ内のユーザのためのＩｄＰとして働き得る、単一または少数のＲＰのみがある可能性がある。示されているＵＥ１０２は、２つのＣｏＴ、詳細には第１のＣｏＴ１３０２および第２のＣｏＴ１３０４に接続されるが、ＵＥ１０２が望まれるような任意の数のＣｏＴと接続され得ることは諒解されよう。いくつかの場合には、ＲＰは、ＵＥ／ユーザ１０２が関連付けられる複数のＣｏＴに属し得る。ＵＥ１０２は、各ＣｏＴに関連付けられるアイデンティティを有してよく、各アイデンティティは、互いに対して一意であり得る。ユーザまたはＵＥが、ＣｏＴ内のＲＰのサービスを取得することを望むとき、そのＣｏＴに関連付けられた、関連付けられたアイデンティティが使用され得る。アイデンティティとＣｏＴとの間の関係は、デバイス内で予め構成され得る。図１４を参照すると、多要素認証であり得る認証が、ＵＥ／ユーザ１０２（ＵＥ＠ＩｄＰ１アイデンティティを使用する）と、ＲＰ１３０４およびＩｄＰ１／ＭＦＡＳ１０６の組み合わされたエンティティとの間で遂行された場合、その認証プロセスの一部として生成されるＰＩＤが、ＣｏＴ１３０２内の他のＲＰ１３０６とのＵＥ／ユーザ１０２による将来の認証のために使用される。例えば、ＰＩＤに関連付けられた有効性またはタイムスタンプが満了した場合、ＩｄＰ１／ＭＦＡＳ１０６との再認証が遂行され得る。別の例として、有効な認証が常に利用可能であることを確実にするために、再認証が連続的に遂行され得る。
例示的な実施形態では、ＰＩＤのプライバシーは、同じＣｏＴ内のＲＰが、ＣｏＴ内の他のＲＰの各々に関連付けられたユーザの永続的なアイデンティティに内々関知していないことを、確実にする。いくつかの場合には、ＰＩＤのみが、ＩｄＰ（ＭＦＡＳ１０６）とともに遂行された認証を識別するために使用される。ＰＩＤと、関連付けられたＣｏＴおよびＲＰ情報とをセキュアに記憶するブラウザプラグインまたはアプリケーションは、以下のように提示され、例として提示されてよく、限定として提示されなくてよい。
いくつかの場合には、特定のユーザは、ＲＰ／ＩｄＰの各々に関連付けられた、対応する認証クレデンシャル（例えば、ＵＩＤ／ＰＷＤ、トークン、公開／プライベートキーなど）をもつユーザプロファイルを有する。したがって、認証クレデンシャルは、ＣｏＴ内のメンバー間で変動し得る。したがって、第１のＲＰ／ＩｄＰとともに遂行された認証のＡＬは、各ＲＰ／ＩｄＰが同じＣｏＴ中にあり得るとしても、第２のＲＰ／ＩｄＰとともに遂行された認証のＡＬとは異なり得る。さらに、メッセージおよびチャレンジ／ハンドルは、固有の署名キー（ＲＰ＜−＞ユーザ）を用いて署名され得るが、同時に、（ユーザ＜−＞ＩｄＰ／ＲＰ）キーによって署名されたアサーションを有する。これは、追加のレベルのセキュリティを提供し得る。例示的なキーが表２に提示される。
上記で説明されたように構築および使用された疑似ＩＤは、サービスへの変名のアクセスを可能にし得る。一実施形態では、ＰＩＤは、１回限りの識別子であり、したがって、それらは、ユーザが、ＰＩＤを受信するＲＰから個別化されたサービスを取得することを防止する。例えば、ＰＩＤは、例えば、ＰＩＤの一部である名前または他の個人識別可能な情報を有することなしに、ユーザが特定のＩｄＰのＣｏＴの「メンバー」であることを示す「メンバーシップカード」のようであり得る。
例示的な実施形態によれば、ＰＩＤが互いとリンク可能であり得るので、ユーザは、一貫したサービスを受信し得る。例えば、特定のシーケンスにおいて使用されるＰＩＤは、リンク可能であり得る。例として、ＭＦＡＰ１１０は、アクセスされたＲＰごとの最後の使用されたＰＩＤを記憶し、それを現在のＰＩＤと一緒に特定のＲＰへ送り得る。リプレイアタックの確認および防止のために、新しいＰＩＤが、次いで、例えば、以下のように構築され得る。
ＰＩＤ＿ｎｅｗ＝ＨＭＡＣ−ＳＨＡ−２５６（ＰＩＤＫｅｙ，ＳｅｓｓｉｏｎＳｔｒｉｎｇ）
リンク可能性は、例示的な実施形態によれば、任意の時間に中断され得る。例えば、リンク可能性は、ユーザの要求によって、または、例えば、以前に使用されたＰＩＤにリンクされないフレッシュなＰＩＤを作成することによって中断され得る。
以下で使用されるように、「フェデレーションターゲット」という用語は、ネットワーク認証プロバイダ機能（例えば、ＯＰ／ＮＡＦ、ＢＳＦなど）、ＩｄＰ技術（ＯｐｅｎＩＤ、Ｌｉｂｅｒｔｙ、ＲＡＤＩＵＳ、ＬＤＡＰなど）、ネットワーク認証セキュリティアンカー（ＵＩＣＣ、スマートカード、ＮＦＣセキュアエレメント、トークンなど）、ユーザ認証方法（ＰＩＮ、バイオメトリ、ＯＴＰ、トークン、多要素など）、オンデバイスアプリケーション（ブラウザ、アプリ）などを指すことがある。様々な例示的な実施形態では、ユーザのクライアントデバイスは、典型的であるものよりも微細な、粒度の細かい構造を有し、したがって、デバイスは、それら自体がフェデレーションターゲットである、例えばセキュアエレメントおよびアプリケーションなど、別個のエンティティを含み得る。
便宜上、フェデレーションターゲットの例示的なリストが、例として、限定なしに、表３において提示される。
表３を参照すると、デバイス界およびネットワーク界は、部分的な「鏡像」対称を示し得る。いくつかの場合には、この対称は、例えばユーザと、それにユーザが登録されるアイデンティティプロバイダとの間、または、ネットワーク認証に関連付けられた物理的セキュリティアンカー間などの、トラスト関係を示し得る。他の場合には、デバイス界とネットワーク界との間の接続は、例えば多数のＷｉＦｉネットワークへのアクセスを容易にする汎用ＷｉＦｉクライアントアプリケーションなど、機能的なものであってよく、その場合、このアプリケーション自体が、サービスのタイプにわたって連携するための手段の一部になり得る。
フェデレーションターゲットは、エンティティクラスとして、またはその具象インスタンス化として、以下で説明される例示的なＳＳＯアーキテクチャにおいて現れる。それらは別として、１または複数のターゲットエンティティクラスのためのフェデレーションを達成することにおいて助けになり得る、機能的ビルディングブロックもあり得る。例えば、「ＳＳＯフレームワーク」という用語は、ユーザ認証方法、アプリケーション、およびセキュリティアンカーを連携することにおいて中心的役割を果たし得る、デバイス上の機能的ネクサスを指す。
以下の略語が、上記で導入されたエンティティクラスのために使用され得る。以下の表は、いくつかの頭字語をリストしている。本明細書で使用される他の頭字語は、よく知られていることがある。表４を参照すると、ＵおよびＵＩＤは、ユーザと、識別子として実施されるそれらのアイデンティティとの間の区別を表し得る。例えば、１人のユーザは、２以上のアイデンティティを有し得る。
本明細書で使用されるとき、リライングパーティ（ＲＰ）という用語は、ユーザのためのアイデンティティアサーションを受け入れる、および／または評価する、エンティティを指すことがある。サービス（ＳＲＶ）は、限定はしないが、サービスプロバイダを指すことがある。さらに、サービスはＲＰであり得るが、そうである必要はない。
背景として、連携されたアイデンティティ管理システムを介して、サービスプロバイダは、認証アサーションのためにサードパーティにアクセスする手段を有する。これは、彼らが複数のサービスプロバイダ（ＳＲＶ）にアクセスするために思い出す必要があるクレデンシャルの数を限定することによって、認証をユーザにとってよりユーザフレンドリーにする。しかしながら、ユーザが、低価値サービスから高価値サービスまでの可変グレードサービスにアクセスするとき、認証の強度もまた、粒度の細かい形で変動し得る。ユーザに最高のグレードの認証を負わせるのではなく、本明細書では、必要なときのみ、ユーザに負担をかけることが有益であり得ることが認識される。したがって、可変グレード認証を連携されたシステムに提供することは、必要とされるとき、依然として高強度認証を提供しながら、ユーザにとっての認証経験を簡略化し得る。
さらなる背景として、ＩｄＰは、しばしば、ユーザアイデンティティ（例えば、電子メールアドレスなどの名前付きＩＤ）と、ユーザ固有のデータ（ビリングおよび出荷情報、または消費者選好など）とを一般的に提供する。しかし、ＩｄＰ自体は、ユーザ名／パスワードよりも強力なユーザ認証方法を通常は提供しない。より強力な認証方法を採用するためのＩｄＰによる様々な試みは、これまでは散在しており、プロプライエタリであり、断片化されており（２次チャネルを使用する要素としてＳＭＳ ＯＴＰ、もしくは特殊な暗号トークンを採用することなど）、または、釣り合いが取れるように実装するためにコストがかかる（キーフォブなど）ままである。したがって、現在の技術は、ユーザのための認証方法を選定することが可能にされないサービスプロバイダにとって、柔軟性がない。また、認証方法技術の断片化は、スケーラビリティおよび展開コストに悪影響を及ぼす。
現在の技術は、サービスプロバイダがポリシーを記述および施行して、異なる状況におけるユーザの多要素認証を柔軟に統制すること、例えば、チェックアウトおよび支払いとは対照的にウェブショップに最初にログオンすることを可能にしない。また、サービスプロバイダは、例えば、ＧＢＡを使用する３ＧＰＰネットワーク認証など、ネットワークベースの認証方法に容易に接続して、複数の追加の認証要素にアクセスすることができない。
図１５を参照すると、図示された実施形態によれば、例示的なアーキテクチャ１５００は、サービス１５０２とＩｄＰ（ＩＤＰ）１５０４との間、および、サービス１５０２とネットワーク認証エンティティ（ＮＡＥ）１５０６との間に中間レイヤを提供する。この中間物は、フェデレーションネクサス（Federation Nexus）（ＦＮＸ）１５０８と呼ばれることがある。ＦＮＸ１５０８は、古典的なアイデンティティプロバイダ役割を実施することに加えて、コネクタ１５１０と、下位機能のクラスと見なされ得る、ブローカーとを制御する、汎用マスタＩｄＰ役割を実施し得る。ＦＮＸ１５０８は、ＭＦＡＰ１１０またはＭＦＡＳ１０６（図１参照）上に存在する、論理エンティティであり得る。
さらに図１５を参照すると、図示された実施形態によれば、コネクタ１５１０は、様々な標準化された、またはプロプライエタリなネットワークベースの認証方法へのインターフェースを提供する、ＮＡＥコネクタ１５１０ａであり得る。コネクタ１５１０は、ＩＤＰ１５０６へのインターフェースを提供するＩＤＰコネクタ１５１０ｂであってよく、ＩＤＰ１５０６は、次にユーザ識別子およびユーザ情報をリリースし得る。コネクタ１５１０は、例えばＡＡＡなど、ユーザ認証および管理のための様々なサービスへのインターフェースを提供する、サービスコネクタ１５１０ｃであり得る。
さらに図１５を参照すると、例示的な実施形態によれば、保証レベルブローカー（ＡＬＢ）１５１２は、ＦＮＸ１５０８の必須の機能を可能にし得る、データベースおよび論理機能である。ＡＬＢ１５１２は、上記で説明されたように、保証レベルをマッピングし得る。保証レベルは、例えば保証機関１５１６として、ある機関によって定義されたユーザ真正性の保証のレベルの列挙を指すことがある。したがって、ＡＬＢ１５１２は、保証レベルを、認証方法、および、例えば認証のフレッシュネスなどの補足条件にマッピングし得る。例示的な実施形態によれば、認証フロントエンド（ＡＦＥ）ブローカー（ＡＦＢ）１５１４は、調整されたフロントエンド（例えば、ｊａｖａｓｃｒｉｐｔまたはＡｃｔｉｖｅＸ（登録商標）エレメントなど、ウェブページまたはアクティブウェブエレメント）を提供して、ユーザ認証をサポートする、ブローカーであり得る。ＡＦＥ１５１４は、組み合わされた認証を表す、調整されたフロントエンドを提供し得る（例えば、ＥＡＰ−ＳＩＭなどのＮＡＥ認証が、電子メールアドレスなどのＩＤＰアイデンティティに対して認証するために使用されることをユーザに反映すること、およびユーザからの受入れを要求すること）。
次に図１６を参照すると、例示的なアーキテクチャ１６００は、サービス１５０２と「バックエンド」ＩｄＰ１５０４との間で介在およびインターフェースする、プロキシＩｄＰ１６０２を含む。図示された実施形態によれば、プロキシＩＤＰ１６０２は、サービス１５０２と、一般にＩＤＰ１５０４およびＮＡＥ１５０６エンティティと呼ばれることがある、バックエンド認証およびアイデンティティサービスとの間で、中間アグリゲーションレイヤを確立し得る。プロキシＩＤＰ１６０２は、他のＩｄＰへの接続を含み得る。プロキシＩｄＰ１５０６はまた、ＩｄＰ／ＮＡＥへのカスタム接続を有し得る。
例示的なアーキテクチャ１６００は、ＳＲＶ１５０２を、例えばｇｏｏｇｌｅ（登録商標）ツールキット１６０６またはプラグイン１６０８などの認証フロントエンドに接続する、認証フロントエンド（ＡＦＲＯ）アグリゲータ１６０４をさらに含む。ＡＦＲＯアグリゲータ１６０４は、ＡＦＲＯからプロキシＩＤＰ１６０２へ情報交換を提供し得る。したがって、異なるＡＦＲＯが、様々なＩＤＰおよびＮＡＥ方法をトリガするために使用され得る。また、ＡＦＲＯアグリゲータ１６０４は、例えばトリガを介して相互通信を提供することによって、複数のＳＲＶ１５０２を伴う使用事例を容易にし得る。
プロキシＩＤＰ１６０２は、例えば、ＥＡＰ−ＳＩＭ、ＧＢＡ、ＡＫＡ、ＡＫＡ’など、複数の異なるＮＡＥプロトコルへの接続を提供し得る。プロキシＩＤＰ１６０２は、例えば、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔプロバイダ、ＳＡＭＬ Ａｕｔｈｏｒｉｔｙ、Ｘ．５０９ ＣＡ、ＲＡＤＩＵＳおよびＬＤＡＰサーバなど、異なるインターフェースを介して、ＩＤＰへの接続を提供し得る。プロキシＩｄＰ１６０２は、ＮＡＥ認証をトリガし得る。プロキシＩｄＰは、それ自体のマッピングデータベースを使用することによって、または、ＵＥ上に存在し得る別のエンティティによるマッピングをトリガすることによってのいずれかで、異なるアイデンティティドメイン間でＵＩＤをマッピングすることができる。プロキシＩＤＰ１６０２は、例えばプロセス同期のために、ＡＦＲＯアグリゲータ１６０４と通信することができる。プロキシＩＤＰ１６０２は、ユーザ認証に関するポリシーを維持および施行し得る。
ＡＦＲＯアグリゲータ１６０４は、様々な機能を実施し得る。例として、ＡＦＲＯアグリゲータ１６０４は、ＪａｖａＳｃｒｉｐｔコードが添付されるボタンなど、認証トリガエレメントを動的に作成し得る。アグリゲータ１６０４は、トリガエレメントを、サービスおよび／またはユーザデバイスへ送り得る。アグリゲータ１６０４は、ユーザデバイスへ送られ得るコードエレメントを動的に作成することができる。コードエレメントは、デバイスによって、例えばＮＡＥまたはユーザ認証方法などの認証方法と対話する、例えばそれをトリガするために使用され得る。図１６に図示された、いくつかのエンティティは、他のエンティティの役割とともに折りたたまれ、および／または一体化され得ることは理解されよう。例えば、ＮＡＥはＩｄＰでもあり得る。さらに、プロキシＩＤＰおよびＡＦＲＯアグリゲータは、例示的な実施形態によれば、互いと一体化され得る。ＳＲＶ１５０２とプロキシＩＤＰ１６０２との間のインターフェースは、例えばＯｐｅｎＩＤなど、予め定義されたインターフェースであり得る。したがって、ＳＲＶ１５０２は、プロキシＩＤＰ１６０２におけるＯＰ機能に直接接続し得る。あるいは、プロキシＩＤＰ１６０２は、ＳＲＶ選好により、多数のインターフェースを一体化し得る。
プロキシＩＤＰ１６０２によって可能にされる例示的な有利な機能をさらに説明するために、例示的なシナリオが以下で説明される。例として、ユーザは、大規模なインターネットＩＤＰ（例えば、ｇｏｏｇｌｅ）によって提供されたアイデンティティを使用して、自分のラップトップコンピュータ上でオンラインショップにログインする。自分のバスケットが満たされると、ユーザは、チェックアウトへ進む。ショップのチェックアウト機能は、より強力な要素、この例示的な場合では、ＮＡＥ（例えば、ＯｐｅｎＩＤ／ＧＢＡを使用する）による認証を必要とする。これを実施するために、プロキシＩＤＰ１６０２は、ユーザのスマートフォン上でＯｐｅｎＩＤ／ＧＢＡ認証をトリガする。前提条件として、プロキシＩＤＰ１６０２は、インターネットＩＤＰからのユーザアイデンティティを、ＮＡＥ第２の要素認証（例えば、ＩＭＳＩ）のために使用される識別子にマッピングする。上記で説明された例では、プライバシーが保護され得る。例えば、オンラインＩＤＰがユーザのＮＡＥ識別子を知ることは、必要ではない。同様に、ＮＡＥは、ショップのために使用されるオンラインＵＩＤを知る必要がない。上記で説明されたオンラインＩＤＰおよび／またはＮＡＥは、例えばビリングなど、追加のバックエンド機能をチェックアウトに提供し得るが、それらの間の相互接続を必要とすることはない。さらに、認証要素は、随意に、例えば要件に従って、オーケストレートおよび組み合わされ得る。
以下で説明される別の例示的なシナリオは、判断されたＮＡＥおよび／またはユーザ認証方法を使用する、あるＩＤＰから別のものへの、ユーザの例示的なエンロールメントを示す。例として、ユーザのデバイスは、ユーザが接続することを望む、近傍にある、以前に知られていないＷｉＦｉホットスポットネットワークを発見し得る。ホットスポットネットワークは、ユーザがビリングのためのＭＮＯ加入を示すこともできる場合に、それがユーザのＧｏｏｇｌｅ Ｍａｉｌアイデンティティを受け入れることを告知する。プロキシＩＤＰ１６０２は、Ｇｏｏｇｌｅ ＭａｉｌアイデンティティをＭＮＯアイデンティティ（例えば、ＩＭＳＩ）にマッピングすること、または、そのマッピングをトリガすることによって、この例示的な使用事例を可能にし得る。プロキシＩＤＰ１６０２は、ユーザ選好およびホットスポットネットワーク使用ポリシーが互いに従うものであるか否かをチェックし得る。プロキシＩＤＰ１６０２は、ＡＦＲＯアグリゲータ１６０４を介して好適なフロントエンドに接続して、ホットスポットネットワーク契約条件をユーザに表示し、ユーザによるその受入れを取得し得る。さらに、プロキシＩｄＰは、ホットスポットネットワークによって必要とされ得るあるユーザ情報を転送（または、その転送をトリガ）し得る。
次に図１７を参照すると、ＦＮＸ１５０８は、例えば、認証保証レベルのためのそれらのそれぞれのポリシーに基づいて、ＳＲＶ１５０２によって要求されるような、複数の認証要素を使用する認証を可能にし得る。図示された実施形態によれば、プロキシＩｄＰ１６０２、例えばＯｐｅｎＩＤプロバイダインスタンスは、技術的エンドポイントである。したがって、ポリシーネゴシエーション機能１７０２および多要素アサーション機能１７０４など、多要素認証のための追加の論理が、ＳＲＶ１５０２とは別個であり、それから隠され得る。図示されるように、追加の論理は、多要素オーケストレータ（ＭＦＯ）１７０６と呼ばれる、ステアリングエンティティにおいて集中される。ＭＦＯ１７０６は、ＯＰがフロントエンドとしてＦＮＸ１５０８と一体化されるときの場合に、ＯＰを制御し得る。
多要素認証を遂行するために、ＯＰは、全体的な認証手順をイニシエートするため、および完了するために、追加の機能を必要とし得る。例えば、ＯＰは、ポリシーＤＢ１７０８に記憶され得る、ＳＲＶ１５０２によって出された認証の要件と、ユーザ／ＵＥデータベース１７１０中に記憶され得る、各ユーザおよびＵＥの能力／選好との間のマッチを見つける、特定のポリシーネゴシエーション機能、この例では、ポリシーネゴシエーション機能１７０２を必要とし得る。
さらに図１７を参照すると、多要素アサーション機能１７０４は、行われた多要素認証の細目を準備およびアサートし得る。示されたように、ＭＦＯ、ポリシーネゴシエーション、アサーション生成、およびＯＰエンドポイントは、密に一体化され得るが、それらはまた、アプリケーションレイヤインターフェースによって、疎に結合および接続され得る。実際の、単一認証は、それらが多要素プロセス全体に対してそれぞれアグノスティックであるように、透過的な方法で遂行され得る。
図１８を全体的に参照すると、デバイス界フェデレーションアーキテクチャは、ネットワーク界アーキテクチャと対称的に構築される。例示的な場合では、デバイスは、フェデレーションの目的で、バックエンドエンティティ、詳細には例えばＭＦＡＳ１０６によって遠隔で制御される、パッシブエンティティと見なされ得る。このタイプのシナリオは、デバイス上へのフェデレーション技術の展開に関して、最小要件を出す。結果として、レベル１デバイス側アーキテクチャを使用する現在のフェデレーション手順は、「クラウドにおけるフェデレーション」に集中する。したがって、認証要素の組合せなど、フェデレーションのメインタスクは、ネットワーク界エンティティＭＦＡＳおよびＮＡＥによって負担され得る。
図１８を参照すると、ＵＩＣＣにおけるＥＡＰ−ＳＩＭ認証など、デバイス１０２上で事前に既存であり得るローカル認証機能が、ブラウザおよび他のアプリケーションによってエクスポーズされ得る。これらのプラグインエレメントは、ＭＦＡＳ１０６を通して、認証ＮＡＤとネットワークバックエンドとの間でインターフェースする、簡略化された通信を実施し得る。この通信は、ＮＡＤ認証をトリガする。
プラグイン１８０２など、様々な認証プラグインは、いくつかの認証エンドポイント１８０４を通して、それらのそれぞれのＮＡＤを操作し得る。例えば、認証エンドポイントは、ＥＡＰ−ＳＩＭまたはＡＫＡプロトコルスタックからなり得る。次に、認証エンドポイント１８０４は、予め定義されたインターフェースを介して、実際のＮＡＤ認証にアクセスし得る。いくつかの場合には、複数の認証エンドポイントおよびＮＡＤは、Ａｎｄｒｏｉｄ（登録商標）オペレーティングシステムからの様々なセキュアエレメントへのアクセスを可能にする、例えばＯｐｅｎＭｏｂｉｌｅ ＡＰＩなどの共通ＡＰＩを通して、アクセスされ得る。
特定の認証要素は、例えばバイオメトリック要素など、ローカルユーザ認証要素を含み得る。それらの認証エンドポイントおよびＮＡＤ（バイオメトリックリーダ）は、ＢｉｏＫｅｙのＷｅｂＫｅｙによって提供されるなど、プロプライエタリ技術からなり得る。いくつかの他の認証要素はまた、ユーザ対話および／またはローカルユーザ認証を伴い得る。いくつかの場合には、そのような対話は、ボタンを押すか、またはＰＩＮを入力することによって、認証アクションを受け入れることにまで低減される。
また図１９を参照すると、例示的なアーキテクチャ１９００は、サーバ側ＭＦＡＳ１０６と相互動作中であり得る、デバイス１０２上で、多要素認証のために使用され得る。アーキテクチャ１９００は、様々な形で、上記で説明されたパッシブデバイスアーキテクチャとは異なる。例えば、アーキテクチャ１９００は、デバイス１０２上でＭＦＡＰ１１０を含む。
図１９を参照すると、例示的な実施形態によれば、デバイス１０２のトラステッド実行環境（ＴＥＥ）は、極めて重要なデータを改ざんすることが可能ではないように、アーキテクチャ１９００における様々な機能を保護し得る。例示的なセキュリティ要件のさらなる詳細が、以下で詳述される。
例のために、多要素アーキテクチャ１９００の例示的な機能が、Ａｎｄｒｏｉｄプラットフォームに基づいて説明されるが、このアーキテクチャが、望まれるように他のプラットフォームにも適用され得ることは諒解されよう。ポリシー動作は、Ａｎｄｒｏｉｄ ＯＳスキーマ「ｓｏｉｄ．ｓｃｈｅｍｅ：／／＜ｍｅｔｈｏｄ＞．＜ｆａｃｔｏｒ＞／＜ｆａｃｔｏｒ−ｄａｔａ＞」に登録されたＡｎｄｒｏｉｄアプリケーションが、ブラウザエージェント（ＢＡ）１９０２を使用してトリガされるとき、ＭＦＡＬ１１０と呼ばれることもある、多要素認証プロキシ１１０においてコールされるべき第１のアクティビティであり得る。Ａｎｄｒｏｉｄアプリケーションのこのレイヤは、多要素認証のために決定を行い、ポリシーをフィルタ除去し得る。例えば、アクセス権ポリシーに基づいて、様々な認証要素が必要とされると判断され得る。デバイス−ローカル認証のために定義されたポリシーに基づいて、異なるローカル認証要素（ＬＡＦ）１９０４およびネットワーク認証デリゲート（ＮＡＤ）１９０６が、認証要求を処理するためにコールされる。異なる認証要素は、Ａｎｄｒｏｉｄアプリケーションにおける異なるアクティビティの一部であり得る。
ＭＦＡＬ１１０およびローカル認証要素１９０４ＬＡＦの状態は、Ａｎｄｒｏｉｄ ＯＳのアプリケーションシステム状態アプリケーションに更新され得る。このシステム状態アプリケーションは、可能な場合、ＴＥＥにおいてランするべきであり、その理由は、それが、認証要素の数、認証要素の状態（例えば、成功、失敗）、再試行の数、セッション情報など、認証依存情報を含有し得るからである。
いくつかの場合には、ＬＡＦ１９００４は、認証のためにＵＥ１０２のローカルエンティティのみを必要とする要素であり得る。例えば、そのような要素は、ローカルデータベースに対するローカルパスワード認証、ローカル指紋認証、ローカル虹彩スキャン、行動パターン認証などを含み得る。
ネットワーク認証デリゲート（ＮＡＤ）１９０６は、内部／外部ネットワークのサーバと通信することを必要とし得る。例示的な認証は、ＭＮＯ認証、ＳＩＭベースのデバイス認証、指紋認証などを含む。
図示されたＭＦＡＬ１１０中に含まれるローカルアサーションエンティティ（ＬＡＥ）１９０８は、ローカルで実行された認証に関するアサーションを発行するためのあるポイントであり得る。ローカル認証シナリオにおいても、ネットワーク上にＬＡＥがあり得る（例えば、上記で説明された、ローカル認証＋ネットワークアサートシナリオ）。ＬＡＥ１９０８は、ＭＦＡＬポリシープロセッサ１９１２が、ＭＦＡＳ１０６から受信されるような、ローカル認証のための認証ポリシーを成功裏に実行した後、アサーションをピアＭＦＡＳ１９０６に発行し得る。
機能、論理、およびデータを、ユーザ認証などのトラステッド機能が与えられているユーザデバイス１０２上に置くとき、本明細書では、セキュリティが最も重要であることが認識される。以下で説明されるものは、例示的なアーキテクチャ１９００上でセキュリティを実装するいくつかの実施形態である。
一実施形態では、単一認証要素の機能が必ずしもＴＥＥ中に含まれるとは限らず、その理由は、各要素のセキュリティが別個で査定され得るからである。したがって、デバイス上でローカルに実施された認証要素は、ソフトクレデンシャルストアを使用するソフトウェアセキュリティレベルを有し得る。さらに、認証要素は、スマートカードによって提供されたハードウェアセキュリティを有し得る。別の例として、ローカル認証要素は、中間レベルを有してよく、例えば、セキュア指紋リーダは、ユーザ空間においてランしているアルゴリズムにマッチするソフトウェアと組み合わされ得る。さらに、様々な実施形態によれば、特定の認証要素は、ＴＥＥリソースを使用し得る。
認証要素ＮＡＤ１９０６およびＬＡＦ１９０４からのデータパスは、ＴＥＥリソースによってセキュアにされ、例えば暗号化された／完全性保護されたメッセージングであり得る。また、ユーザへ／から、ＬＡＦ／ＮＡＤへのデータパスは、ＴＥＥリソースによってセキュアにされ得る。加えて、例示的な実施形態では、認証結果がＭＦＡＬ１１０とＭＦＡＳ１０６との間で送られるデータパスが保護される。
データベースは、必ずしもＴＥＥ保護されたストレージ中に含まれるとは限らないが、ＴＥＥリソースによって、例えば少なくとも完全性のために保護され得る。いくつかの場合には、ユーザ／ＵＥデータを含有するＤＢは、プライバシーのために暗号化される。
ＭＦＡＬ１１０がローカルアサーション製作エンティティを含有する場合、例えば、その論理は、ＴＥＥの内部で保護され得る。さらに、ルートクレデンシャル、およびローカルで生成されたアサーションの実際の署名プロセスは、ＴＥＥによって、または、ＬＡのためのＳＥとして図示され得る別個のセキュアエレメントによって保護され得る。ＳＥは、長期秘密（Long Term Secret）（ＬＴＳ）を有し得る。
図２０を参照すると、例示的な実施形態による、例示的なサーブレットアーキテクチャ２０００が示される。例示的なアーキテクチャ２０００は、ＯｐｅｎＩＤサーブレット２００２と、多要素オーケストレータ（ＭＦＯ）１７０６と、個々の認証モジュール２００４とからなる。構成要素はモジュラリティを維持するので、既存のベースシステムへのさらなる拡張が実装され得るようになる。実装されたモジュラーおよび疎結合された設計は、本明細書で説明されるポリシーシステムなど、追加の機能性、または追加の認証要素を、新しい認証モジュール２００４として追加する可能性を提供する。開発および展開観点から、アーキテクチャ２０００は、比較的最小の作業で他のシステムが既存のシステムと一体化し得るので、利益を提供する。
図示された実施形態によれば、ＯｐｅｎＩＤサーブレット２００２は、ＯｐｅｎＩＤプロトコル機能性を含有する。ＯｐｅｎＩＤサーブレット２００２は、ＲＰ１０４とのＯｐｅｎＩＤ関連付けを作成すること、および、ＯｐｅｎＩＤ署名付きアサーションを作成することを担い得る。ＭＦＯオーケストレータ１７０６は、ＯｐｅｎＩＤサーブレット２００２にインターフェースし、多要素認証機能性を提供する。例えば、ＯｐｅｎＩＤサーブレット２００２は、ＭＦＯ１７０６をトリガすることによって、多要素認証を呼び出し得る。これらの独立したサーブレットを有することによって、例えば、ＯｐｅｎＩＤプロトコルの機能性および多要素認証の機能性は、コード依存性を低減するために互いから隔離されたままであり得る。
ＭＦＯ１７０６は、多要素認証のためのコア機能的構成要素であり得る。例示的な実施形態では、ＭＦＯ１７０６は、認証要素をフェッチすること、個々の要素の処理を順序付けすること、認証モジュールのための終了条件を判断すること、および、基礎をなすポリシーに基づいて個々の認証結果を統合することを含む、様々な機能性を実施することができる。より高いレベルで、ＭＦＯ１７０６は、ＯｐｅｎＩＤサーブレット２００２と認証モジュール２００４との間のゲートウェイと見なされ得る。ＭＦＯ１７０６は、認証の主要な機能性の大部分がこのモジュールにおいて実装され得るので、既存のシステムのさらなる拡張の可能性を提供する。
図示された実施形態によれば、認証モジュール２００４は、認証要素のタイプに基づいて、様々な認証構成要素を含有する（例えば、パスワード認証モジュール、Ｂｉｏｋｅｙ認証モジュール、スマートＯｐｅｎＩＤ認証モジュール）。例示的な実施形態によれば、ＭＦＯ１７０６は、ＪＳＯＮオブジェクトとして記憶され得る、各ユーザのプロファイルをフェッチし、ユーザが実施することができる認証要素のタイプを判断する。さらに、ＭＦＯ１７０６は、認証要素が遂行されるべき順序を判断し得る。対応する認証要素（例えば、Ｂｉｏｋｅｙ、Ｓｍａｒｔ ＯｐｅｎＩＤ、ＥＡＰ ＳＩＭ）を実装する認証モジュール２００４は、ＭＦＯ１７０６によってトリガされる。１つの例示的な実施形態では、１つの認証要素に固有のコードの実行が完了すると、制御がＭＦＯ１７０６へ戻され、ＭＦＯ１７０６は、そのユーザのために必要とされた認証要素のすべてにわたって反復してしまうまで、同じ手順を繰り返す。したがって、多要素認証プロセスは、認証要素のうちの少なくとも１つ、例えばすべてが、ユーザによって成功裏に完了されたとき、終了し得る。
ＪＳＯＮ ｔｘｔファイル２００６は、ユーザ名識別子をオブジェクトとして、および、対応するユーザデータを、ＪＳＯＮスニペットにおいて見られ得るキー／値としてもつ、対応するキー／値ペアをもつオブジェクトを含有し得る。一実施形態では、それは、例えば以下などの様々な情報を記憶する、ユーザデータベースであり得る。
上記の例示的なＪＳＯＮスニペットを参照すると、ＪＳＯＮスニペットは、ＯｐｅｎＩＤ識別子を含むＯｐｅｎＩＤプロトコル情報と、この特定のユーザのための認証のために使用される認証要素のタイプと、各ユーザのための認証要素の実行の順序（認証要素がＪＳＯＮファイルにおいて規定される順序であり得る）と、Ｂｉｏｋｅｙ人物ＩＤとを含み得る。ＪＳＯＮスニペットはまた、例えば、フルネーム、電子メール、市など、ユーザに関連付けられた様々な情報を含有し得る。
さらに図２０を参照すると、図示された認証モジュール２００４は、外部モジュールではなく、ＭＦＡＳ１１０の一体部分である。いくつかの場合には、モジュール２００４は、ＪＳＯＮユーザＤＢ２００６からの情報を使用して、それらのジョブを完了し得る。例えば、ＢｉｏＫｅｙを用いたバイオメトリック認証の場合、認証モジュール２００４は、ＤＢを使用して、返されたＢｉｏＫｅｙ ＩＤをユーザのＢｉｏｋｅｙ ＩＤにマッチさせ得る。
特定の認証要素のための再試行およびフレッシュネス情報もまた、認証結果オブジェクト内に記憶され得る。ユーザのための認証要素への保証レベルマッピングもまた、ユーザプロファイルにバインドされたままにされ得る。
図２１を参照すると、一実施形態によれば、ＭＦＡＳ１０６を使用する各ユーザは、サーバ１０６内の内部での動作のために使用される内部ＤＢ４Ｏユーザレコードを有し得る。例示的な実施形態では、図２１を参照すると、ＭＦＡＳ１０６は、オープンソースライブラリを利用する動作モジュールを介して、ＬＤＡＰ２１０２と対話する。したがって、ＭＦＡＳ１０６は、ＬＤＡＰ２１０２に接続し、ＬＤＡＰ２１０２からのユーザＩＤに基づいて、ユーザ情報をフェッチするための動作を含有し得る。例えば、通常のブラウザを使用中であるＵＥ１０２は、リライングパーティのＵＲＬにヒットし、自分のＯｐｅｎＩＤ識別子を入力することがある。リライングパーティは、ＯｐｅｎＩＤ識別子に基づいてＯｐｅｎＩＤプロトコルを実行するように、ＭＦＡＳ１０６をトリガする。ＭＦＡＳ１０６上のＤＢ４Ｏ動作モジュールは、ＬＤＡＰ２１０２からフェッチされるユーザプロファイル情報をポピュレートし得る。ＤＢ４Ｏ動作は、ユーザプロファイル情報を記憶し、読み出し、更新するための機能性を含有し得る。図示されるように、ＬＤＡＰサーバ２１０２は、ＬＤＡＰ接続を確立することによって、ＭＦＡＳサーバ１０６によって到達可能である外部エンティティであり得る。Ｏｒａｃｌｅ（登録商標） Ｄａｔａｂａｓｅ ２１０４は、Ｂｉｏｋｅｙセットアップの一部であり得る、外部エンティティである。Ｏｒａｃｌｅデータベース２１０４は、Ｏｒａｃｌｅデータベース接続を確立することによって、ウェブキーサーバ２１０６によって到達可能であり得る。
さらに図２１を参照すると、図示された実施形態によれば、クライアントマシン１０２に、指紋エンロールメントおよび識別目的のためのドライバがインストールされる。クライアントマシン１０２は、ＨＴＴＰを介して、ＲＰ１０２、ＭＦＡＳ１０６、ウェブキーサーバ２１０６、およびウェブキーアプリケーションサーバに到達することができる。ＭＦＡＳサーバ１０６とＷｅｂＫｅｙサーバ２１０６との間の通信は、ＨＴＴＰを介したものであり得る。
図２２および図２０を参照すると、図示された実施形態によれば、２２０２で、ユーザ１０７ユーザが、ＯｐｅｎＩＤ ＵＲＬ／ユーザ名を入力する。２２０４で、リライングパーティ１０４が、ＯｐｅｎＩＤプロバイダ１０６を発見し、関連付けを確立する。２２０６で、ＲＰ１０４が、ユーザ機器１０２をＯＰ１０６へリダイレクトする。２２０８で、ユーザ１０２／１０７が、ＯｐｅｎＩＤプロバイダ１０６へのリダイレクトに従う。ＯｐｅｎＩＤプロバイダ１０６は、ＵＥ１０２の認証のために、制御をＭＦＯ１７０６に渡す。ＯｐｅｎＩＤサーブレット２００２は、ユーザＤＢ ＪＳＯＮファイル２００６にアクセスして、ユーザ識別子の存在についてチェックする。多要素オーケストレーション（ＭＦＯ）１７０６は、ユーザのための認証要素を含む、必要とされるユーザ情報をＪＳＯＮファイル２００６からフェッチし、個々の認証要素を処理する。ＭＦＯ１７０６は、認証要素と実行の順序とを、ユーザのためのＪＳＯＮファイルから読み出す。２２０９で、ＭＦＯ１７０６が、パスワードモジュール、バイオキーモジュールＥＡＰ−ＳＩＭモジュールなど、個々の認証モジュール２００４に制御を渡す。２２１１で、各個々の認証要素が実行された後、それが制御をＭＦＯ１７０６へ戻し、ＭＦＯ１７０６が、次の認証要素をトリガする。したがって、ステップ２２０９および２２１１は、特定のユーザのためのすべての要素が完了されるまで、各認証要素について繰り返され得る。２２１３で、例えばすべての認証要素が処理されると、多要素オーケストレータ（ＭＦＯ）１７０６が、個々の認証要素結果を使用して、統合された多要素ユーザ認証結果を処理する。２２１０で、ユーザのための多要素認証結果が成功すると、例えば、ＯｐｅｎＩＤサーブレット２００２が、ＯｐｅｎＩＤ署名付きアサーションを作成する。２２１２で、ＨＴＴＰリダイレクトに従うことによって、ユーザ１０７が、この署名付きアサーションをＲＰ１０４に持ち込む。したがって、２２１４で、ユーザ１０７およびＵＥ１０２が、ＲＰ１０４によって提供されたサービスにアクセスすることができる。
図２０を参照すると、ＯｐｅｎＩＤサーブレット２００２およびＭＦＯ１７０６は、例示的な実施形態で実装される追加の特徴のための一体化ポイントを含む。例えば、ＯｐｅｎＩＤサーブレット２００２は、ＲＰとのネゴシエーションを可能にすることができる、ポリシーネゴシエーション機能をさらに含み得る。ＯｐｅｎＩＤサーブレットはまた、それが個々の認証要素のための多要素認証アサーションを作成し、署名することができるように、アサーション作成機能を含み得る。ＭＦＯ１７０６は、それがフレッシュネスをチェックすること、認証再試行を追跡すること、ポリシーを施行すること、および、例えばＢｉｏｋｅｙ識別子など、要素から返される属性を評価することを可能にする、機能性をさらに含み得る。
次に図２３を参照すると、例示的なポリシーベースの認証アーキテクチャ２３００が示される。アーキテクチャ２３００は、例えば、ＯｐｅｎＩＤ識別子、および、多要素認証において使用され得る、上記で説明された他のユーザ属性など、様々なユーザ情報を含有し得る、ユーザＤＢ２３０２を含む。アーキテクチャ２３００は、ポリシー情報ポイント（ＰＩＰ）２３０６と呼ばれることもある、ポリシーストア２３０６と、ポリシー決定ポイント２３０４と呼ばれることもある、ポリシーエンジン２３０４とをさらに含み得る。
一実施形態では、ＰＩＰ２３０６は、様々な内部または外部エンティティから情報を収集する情報源ポイントとして作用する。ＯｐｅｎＩＤサーブレット２００２は、ＰＩＰ２３０６に、ＲＰとのポリシーネゴシエーションのための情報をフィードする、エンティティとして作用し得る。したがって、ＲＰは、必要とされる認証のためのユーザデバイス能力を識別することができる。決定を行うために、ポリシーエンジン２３０４に影響を及ぼす、追加のエンティティがあり得る。ポリシーエンジン２３０４は、特定のユーザについて、またはポリシーについて、ＰＩＰ２３０６から関連情報を収集する意志決定ポイントである。一実施形態では、ポリシーエンジン２３０４は、ポリシー決定を１または複数のポリシー施行ポイント（ＰＥＰ）にパブリッシュし、ポリシー施行ポイント（ＰＥＰ）は、ポリシーを施行するタスクを課せられる。例えば、ＭＦＯ１７０６は、再試行の数、フレッシュネスチェックなどに基づいて、ポリシーを施行することができるＰＥＰであり得る。
次に図２４を参照すると、例示的なシステム２４００は、Ｓｍａｒｔ ＯｐｅｎＩＤに基づく多要素認証を実装する。図２４は、ＵＥ１０２の例示的なアーキテクチャを示す。２４０２で、図示された実施形態によれば、ＵＥ１０２が、ＲＰ１０４からのサービスを要求する。２４０４で、ＲＰ１０４が、ＯＰＳＦ１０６との発見および関連付けを実施する。ＵＥ１０２が、２４０６および２４０８で、ＯＰＳＦ１０６へリダイレクトされる。２４１００で、ＯＰＳＦがローカルユーザ認証をイニシエートする。認証が、ＵＥ１０２上で、ローカル認証エージェントのうちの１つを使用して実施され、２４１２で、認証結果がブラウザ７０４へ送られる。ブラウザ７０４が、２４１４で、認証結果を２４１４へ、ＯＰＳＦ１０６へフォワードする。ＯＰＳＦ１０６が、２４１６で、認証保証をブラウザ７０４に提供する。２４１８で、ＵＥ１０２が、アサーションに基づいて、ＲＰ１０４によって提供されたサービスへのアクセスを受信することができる。
次に図２５を参照すると、例示的な多要素アプリケーション２５００が示される。アプリケーションがＡｎｄｒｏｉｄアプリケーションとして図示されるが、多要素アプリケーションが、望まれるような代替的なプラットフォーム上で実装され得ることは諒解されよう。アプリケーション２５００は、メインアクティビティ２５０２によって認証要素として始動され得る、１または複数のアクティビティを含む。１または複数のアクティビティは、Ｓｉｍ認証アクティビティ２５０４と、Ｓｍａｒｔ ＯｐｅｎＩＤアクティビティ２５０６と、Ｂｉｏｋｅｙアクティビティ２５０８とを含む。アクティビティ２５０４、２５０６、および２５０８の各々はまた、認証要素アクティビティと呼ばれることもある。認証要素アクティビティは、それぞれ、そのステータスを状態アプリケーション２５１０に対して更新することができる。ステータスの例は、認証、および非認証を含む。図示された実施形態によれば、要素の各々がデバイスの認証のために実施された後、図２５に示されるように、制御に完了アクティビティが与えられる。この完了アクティビティは、図２４に示されるように、認証結果をＯＰＳＦ１０６へ送り得る。認証／完了サーブレットは、認証結果を受信し、次いでデバイスを認証し得る。
次に図２６Ａ〜図２６Ｃを参照すると、例示的な認証システム２６００は、ユーザ２６０２と、ウェブキークライアント２６０４と、ブラウザエージェント２６０６と、ＲＰ２６１０と、ＯＰ２６１２と、パスワードサーバ（ＰＷＤ）２６１４と、アプリケーションサーバ２６１６と、ウェブキーサーバ２６１８とを含む。ウェブキークライアント２６０４およびブラウザエージェント２６０６は、ユーザ２６０２の一部であり得る。ユーザ２６０２、ＲＰ２６１０、ＯＰ２６１２、ＰＷＤ２６１４、アプリサーバ２６１６、およびウェブキーサーバ２６１８は、ネットワークを介して互いと通信し得る。
また図１５および図１７を全体的に参照すると、パスワードベースのユーザ認証は、ＦＮＸ１５０８を介して、指紋ベースの識別および認証と一体化され得る。例えば、バイオメトリックＮＡＥコネクタ（例えば、ウェブキー２６０４）は、ＦＮＸ１５０８とコロケートされ得る。ＦＮＸ１５０８は、特定のユーザがサポートする認証方法を記憶するデータベースへのアクセスを有し得る。いくつかの場合には、サービスプロバイダ（ＲＰ）は、ＯｐｅｎＩＤ ＰＡＰＥ拡張を使用して、その望まれる／必要とされる認証方法をＦＮＸ１５０８に通信することができる。
例示的な実施形態では、ＲＰ２６１０が、必要とされる認証ポリシーに関する決定を行い、その理由は、例えば、ＲＰ２６１０は、どのような認証の強度が、それが提供するサービスのために必要とされるべきであるかを、最も良く知り得るからである。ＲＰ２６１０は、例えば、ＰＡＰＥを使用して、この必要とされるポリシーをＦＮＸ１５０８に通信することができる。ＦＮＸ１５０８は、そのポリシーに基づいて、および、ユーザ／ＵＥ２６０２の能力に基づいて、認証を実行し得る。例として、表５は、能力およびポリシーの例示的なマッピングを示す。表５を参照すると、４つの異なる認証画面が、４つの異なる成果をレンダリングするが、望まれるような任意の数の成果がレンダリングされ得ることは理解されよう。図示された例によれば、ＦＮＸ１５０８は、ポリシーおよび能力に基づいて、パスワード認証が必要とされること、バイオメトリック認証が必要とされること、パスワードとバイオメトリックの両方の認証が必要とされること、または、ユーザ１０２がサービスにアクセスすることができないことを判断し得る。したがって、パスワードを要求する、指紋を要求する、パスワードおよび指紋を要求する、または、彼らがサービスにアクセスすることができないことをユーザに知らせる、ＵＥ１０２上の画面が表示され得る（表５参照）。
特に図２６Ａを参照すると、２６２０で、図示された実施形態によれば、ユーザ２６０２がブラウザ２６０８を開き、ＲＰウェブページ２６１０を訪れ、自分のＯｐｅｎＩＤ識別子（ＵＲＬ）をＯｐｅｎＩＤログインフィールドに入力する。２６２２で、ＲＰ２６１０が、ローカルポリシーデータベースを用いてチェックし、バイオメトリック認証がこの特定のユーザのために必要とされると判断する。２６２４で、ＲＰ２６１０が、ＯｐｅｎＩＤ発見および関連付けステップをランし、関連付けの結果として、ＯＰ２６１２から共有キーを取り出す。例示的な実施形態では、ＯＰ２６１２は、サポートされた認証ポリシーを、Ｙａｄｉｓ発見のためのユーザのＸＲＤＳドキュメントに追加することによって、発見段階で特定の認証ポリシーのためのサポートを広告することができる。２６２６で、ＲＰ２６１０が、ＵＥ２６０２をＯＰ２６１２へダイレクトすることによって、ＯｐｅｎＩＤ認証要求を開始する（間接要求）。ＲＰ２６１０は、例えば、ＰＡＰＥ拡張を使用して、現在のアサーションのための認証ポリシーのためのその選好を記述する、任意の必要なパラメータを含み得る。例えば、ＲＰ２６１０は、それがパスワードおよびバイオキー認証を必要とすることを示し得る。２６２８で、ＵＥブラウザ２６０８が、ＲＰ２６１０から受信されたリダイレクトに従い、要求をＯＰ２６１２に発行する。例示的な実施形態では、ステップ２６２８の後、およびステップ２６３０の前に、ポリシーレイヤおよび多要素認証レイヤが、上記で説明されたように、それを用いて認証をトリガするための任意の必要な認証インターフェースを判断し得る。この例では、ポリシーレイヤは、ＢＩＯｋｅｙとパスワードの両方の認証が遂行されるべきであると判断し、ポリシーレイヤは、次いで、両方の認証方法をランするように、多要素認証レイヤをトリガする。２６３０で、ＯＰ２６１２が、ユーザデータベースと呼ばれることもある、ＰＷＤ２６１４を用いてチェックして、ユーザがＤＢ中に存在することを検証する。ユーザがデータベース中に存在する場合、ＯＰ２６１２が進み得る。そうでない場合、ＯＰは、ユーザ（実装についてはＯＯＳ）がＰＷＤ２６１４に登録するための、登録／サインアップページを提示し得る。２６３２で、ＯＰ２６１２が、ユーザにパスワードのためのタスクを課す。２６３４で、ユーザがパスワードを入力し、パスワードのダイジェストがＯＰ２６１２へ送り返される。２６３６で、ＯＰ２６１２が、パスワードデータベース２６１４を用いて、受信されたパスワードダイジェストをチェックして、受信されたパスワードを妥当性検査する。パスワードが正しい場合、ＯＰ２６１２が進み得る。ＯＰ２６１２は、セッション識別子を使用して、内部で現在のセッションを追跡し得る。
特に図２６Ｂを参照すると、図示された実施形態によれば、２６３８で、ＯＰ２６１２が、例えば認証要求（ステップ２６２６参照）からのユーザ名に基づいて、一般にアプリサーバ２６１６と呼ばれる、ＢＩＯｋｅｙバイオメトリック認証サブシステムをトリガするために、必要なキーおよび識別子を取り出すことができる。Ｂｉｏｋｅｙ技術は、異なる識別子を内部で使用することがあり、このステップはまた、ＯＰ２６１２が入力されたＯｐｅｎＩＤユーザ名をＢＩＯｋｅｙサブシステムユーザ名にマッピングすることを含み得るようになる。往復通信が、例えば、実装されるＢＩＯｋｅｙ技術に基づいて、２６４０および２６４２で発生し得る。したがって、ＵＥ２６０２上のＢＩＯｋｅｙクライアントは、ＯＰ２６１２においてアプリケーションサーバ２６１６からの認証を要求し得る。２６４３で、上記で説明されたようにＯＰ２６１２の構成要素であり得る、ＢＩＯｋｅｙアプリケーションサーバが、ＢＩＯｋｅｙ認証要求をＢＩＯｋｅｙ Ｗｅｂｋｅｙサーバ２６１８に発行する。そのような要求は、アプリケーションキー（Ｋａ）を使用して暗号化され得る。２６３５で、ＢＩＯｋｅｙウェブキーサーバが、クライアント固有のキー（Ｋｃ）を用いて構成データを暗号化してよく、アプリケーションキーＫａを使用して、メッセージを暗号化してよい。図示された実施形態によれば、暗号化されたメッセージは、アプリケーションサーバ２６１６に返される。２６４４で、アプリケーションサーバ２６１６が、ユーザデバイス２６０２上でＢＩＯｋｅｙクライアントをトリガし、クライアントキーＫｃを使用して暗号化された構成データを送る。２６４６で、ＵＥ１０２上のウェブキークライアント２６０４が、指紋リーダデバイスと対話して、指紋画像をスキャンし得る。２６４８で、Ｗｅｂｋｅｙクライアント２６０４が、指紋データをアプリケーションサーバ２６１８へ送り返す。２６５０で、アプリケーションサーバ２６１６が，受信された指紋データをウェブキーサーバ２６１８へフォワードする。
特に図２６Ｃを参照すると、図示された実施形態によれば、２６５２で、ウェブキーサーバ２６１８が指紋をチェックし、次いで、成功したマッチがあるとき、アプリケーションサーバ２６１６に成功メッセージで応答する。２６５４で、アプリケーションサーバ２６１６が、成功メッセージをＯＰ２６１２へフォワードする。いくつかの場合には、アサーションを作成する前、上記で説明されたポリシーレイヤおよび多要素認証レイヤは、認証が成功したと判断してよく、認証結果が必要とされるポリシーを履行するので、ＯＰ２６１２は、署名付きアサーションメッセージを作成するように進むことができる。２６５６で、ＯＰ２６１２が、署名付きアサーションメッセージを作成する。２６５８で、ＯＰ２６１２が、ＵＥ２６０２をＲＰ２６１０に戻すようにリダイレクトする。２要素認証が行われたことをアサートする署名付きアサーションが、このリダイレクトメッセージ中に含まれ得る。２６６０で、ＵＥ２６０２が、ＲＰ２６１０へのリダイレクトに従う。２６６２で、ＲＰ２６１０が、アサーションメッセージを受信し、ステップ２６２４で確立された共有キーを使用して、アサーション署名を妥当性検査する。２６６４で、アサーションが有効である場合、ユーザ２６０２がＲＰ２６１０において認証され、ＲＰサービスがユーザ２６０２に提供され得る。一実施形態では、ステップ２６２６の後、ＯＰ２６１６は、ユーザがパスワードデータベース２６１４中に存在するか否かをチェックする。そうである場合、ＯＰ２６１２は、パスワードベースの認証を実施する。ＯＰ２６１２は、パスワードデータベースと通信（対話）して、パスワードダイジェストを検証してよく、パスワードが正しい場合、ＯＰ２６１２が、２６３２で、ＢＩＯｋｅｙウェブクライアントをトリガし得る。
次に図２７を参照すると、システム１００ａは、図１に図示されたシステム１００と同様であるが、システム１００ａは、ＵＥ１０２の一部である、バイオメトリック認証モジュール２７０４と、記憶されたテンプレート２７０６とをさらに図示する。システム１００ａにおけるＵＥ１０２は、ローカルＯＰ２７０２をさらに含み、それは、ＵＥ１０２上でＯｐｅｎＩＤベースの認証をローカルで実施するように構成されるモジュールである。
図２８Ａ〜図２８Ｂを参照すると、例示的な認証システム２８００は、ユーザ２８０２と、ＶＳＴのような機能およびキャッシュとして構成され得る、ウェブキー認証クライアント２８０４と、スマートＯｐｅｎＩＤ（ＳＯＩＤ）クライアント２８０８と、ＲＰ２８１０と、ＩｄＰ／ＯＰＳＦ２８１２とを含む。例示的な実施形態では、ＳＯＩＤクライアント２８０８およびウェブキークライアント２８０８、ならびにウェブキー認証機能は、ＵＥ２８０８上に存在する。したがって、ＳＯＩＤクライアント２８０８は、図２７において参照されるローカルＯＰ２７０２に類似し得る。２８１４で、図示された実施形態によれば、ユーザ２８０２が、ＯｐｅｎＩＤアウェアなクライアントまたはブラウザを介して、ユーザの登録されたアイデンティティを使用して、ＳＰ２８１０と呼ばれることがあるＲＰ２８１０に対してサービスを要求する。２８１６で、ＲＰ２８１０が、ＯＩＤ／ＯＩＤＣプロトコルに従ってユーザのアイデンティティに関連付けられるＩｄＰ２８１２とともに、発見および関連付けを実施する。２８１８で、図示された実施形態によれば、ユーザのアイデンティティ、および／またはユーザ１０２によって要求されたタイプサービスに基づいて、ＲＰ２８１０が、多要素認証が必要とされるか否かを判断する。ＲＰ２８１０は、認証要件を満足する認証要素をさらに判断または選択し得る。２８１８で、ＲＰ２８１０におけるポリシーに基づいて、ＲＰ２８１０が、認証のために必要とされる要素のタイプを判断し、必要とされる要素をユーザ／ＳＯＩＤクライアント２８０２に通信する。２８２０で、ユーザ認証およびバイオメトリック認証が必要とされる場合、ＳＯＩＤ２８０８が、ローカルユーザ認証をイニシエートし、次いで、バイオメトリック認証をトリガする。２８２２で、成功したローカルユーザ認証において、ＳＯＩＤ２８０８が、Ｗｅｂ−キークライアント２８０６へのトリガ（例えば、ＡＰＩコール）を使用して、バイオメトリック認証要求をイニシエートする。
特に図２８Ｂを参照すると、図示された実施形態によれば、２８２４で、Ｗｅｂ−キークライアント２８０６が、スマートカード内で保護され得る、ローカルで記憶されたキャッシュから、コマンドデータを取得するように要求する。２８２６で、コマンドデータが、キャッシュからＷｅｂ−キークライアント２８０６へ送られる。データは、ＯｐｅｎＭｏｂｉｌｅ ＡＰＩなどの機構を使用して取得され得る。２８２８で、コマンドデータを使用して、ウェブ−キークライアント２８０６が、ユーザの指紋をスキャンするためのプロセスをイニシエートするように、リーダ／ユーザ２８０２に命令する。様々な例示的な要件は、必要とされる品質および番号指を含む。スキャニングのために使用されるそのような要件は、コマンドデータの一部であってよく、または、それらは、ＲＰ２８１０からの命令に基づいて調整され得る。２８３０で、スキャンされた画像がリーダ、および、したがってＵＥ２８０２から読み出され、ウェブ−キークライアント２８０６へ送られる。２８３２で、ウェブ−キークライアント２８０６が、指紋モデルをＷｅｂ−キーサーバ２８０４へ送り、ユーザの指紋を認証（検証）するように、それに要求する。２８３４で、ローカルバイオメトリック認証が成功する場合、Ｗｅｂ−キー２８０４は、関連付けられた保証情報（例えば、画像の品質、使用される指の数など）と、関連付けられたフレッシュネス情報とをもつアサーションを、Ｓｍａｒｔ ＯＩＤクライアント２８０８へ送る。２８３６で、Ｓｍａｒｔ ＯＩＤクライアント２８０８が、Ｗｅｂ−キークライアント２８０６によって提供された情報と、より早く遂行されたローカルユーザ認証情報とを使用して、単一のアサーションを作成する。２８３８で、Ｓｍａｒｔ ＯＩＤクライアント２８０８が、組み合わされたアサーションをＲＰ２８１０へ送り、ユーザ２８０２が、アサーションの結果に基づいて、サービスへのアクセスを取得することができるようにする。
次に図２９Ａ〜図２９Ｄを参照すると、例示的なシステム２９００は、ネットワークを介して互いと通信する、ユーザ２９０２およびＵＥ２９０１と、第１のＲＰ２９１２と、マスタＩｄＰ／ＭＦＡＳ２９１６と、第２のＲＰ１１０６とを含む。ネットワークは、ＰＷＤサーバ２９１８とウェブ−キーサーバ２９２０とをさらに含み得る。ユーザ２９０２は、図２９Ａ〜図２９Ｄにおいて「Ｊａｎｅ」と呼ばれる。ＵＥ２９０１は、ローカルバイオ−キークライアント２９０５とブラウザ２９１０とを含み得る。例示的なシステム２９００は、開示される主題の説明を容易にするために簡略化され、本開示の範囲を限定するように意図されないことは諒解されよう。他のデバイス、システム、および構成が、システム２９００などのシステムに加えて、またはその代わりに、本明細書で開示された実施形態を実装するために使用されてよく、すべてのそのような実施形態が、本開示の範囲内として企図される。さらに、第１のＲＰ２９１２および第２のＲＰ２９１４は、それぞれ、Ｆａｃｅｂｏｏｋ（登録商標）およびＢａｎｋ ｏｆ Ａｍｅｒｉｃａ（登録商標）として図示されるが、この図示は例のためであり、第１のＲＰおよび第２のＲＰは、望まれるような任意の好適なサービスプロバイダであり得ることは理解されよう。
図示された実施形態によれば、２９２２で、ユーザ２９０２が、第１のＲＰ２９１２に関連付けられたユーザ識別子を入力する。２９２４で、図示された実施形態によれば、第１のＲＰ２９１２が、例えばＲＰ２９１２のポリシーに基づいて、ユーザ／ＵＥがＲＰ２９１２によって提供される、要求されたサービスにアクセスするために必要とされる保証レベル（ＡＬ）を判断する。２９２９で、ＲＰ２９１２が、ＭＦＡＳ２９１６を発見し、ＭＦＡＳ２９１６と関連付ける。２９２８で、図示された実施形態によれば、ＲＰ２９１２が、その保証レベル要件をブラウザ２９１０に通信する。２９３０で、ブラウザ２９１０が、ＭＦＡＳ２９１６のサービスを呼び出す。２９３０におけるメッセージは、必要とされる保証レベルを含み得る。
２９３２で、サービスにアクセスするために必要とされる保証のレベルに基づいて、例えば、ＭＦＡＳ２９１６が、必要とされる保証レベルを達成するために実施され得る認証要素のタイプおよび強度を判断する。ＭＦＡＳは、ユーザ２９０２およびＵＥ２９０１に関連付けられた情報（例えば、認証能力）を、ユーザプロファイルＤＢ２９２９から取り出し得る。この例によれば、２９３２で、ＭＦＡＳが、パスワード認証のみが、ＲＰ２０１２からのサービスにアクセスするために必要とされると判断し得る。２９３４で、ＭＦＡＳ２９１６が、パスワードを入力するようにユーザに促すＨＴＴＰメッセージを、ユーザ２９０２へ送ることによって、パスワード認証をトリガし得る。２９３６で、ユーザがパスワードを入力する。２９３８で、ＭＦＡＳ２９１６が、パスワードおよびＵＩＤをＰＷＤサーバ２９１８へ、パスワード認証のために送る。ＰＷＤサーバ２９１８は、ユーザのための入力されたパスワードがユーザのための記憶されたパスワードにマッチすると確認することによって、パスワード認証を実施する。２９４０で、ＰＷＤサーバ２９１８が、ＭＦＡＳ２９１６に、パスワードがマッチすることを知らせる。そのようなメッセージは、認証結果と呼ばれることがある。
特に図２９Ｂを参照すると、例えば第１のアサーションなどのアサーションが、ＭＦＡＳ２９１６によって生成され、ブラウザ２９１０へ送られ得る。ブラウザ２９１０が、アサーションをＲＰ２９１２へ送ってよく、ＲＰ２９１２が、２９４６で、成功メッセージを返し得る。したがって、２９４８で、ユーザが、ＲＰ２９１２によって提供されたサービスへのアクセスを有し得る。
特に図２９Ｃを参照すると、図示された実施形態によれば、２９５０で、ユーザ２９０２が、ユーザが第２のＲＰ２９１２によって提供されたサービスにアクセスすることができるように、第２のＲＰ２９１２に関連付けられたユーザ識別子を入力する。２９５２で、図示された実施形態によれば、第２のＲＰ２９１４が、例えばＲＰ２９１４のポリシーに基づいて、ユーザ／ＵＥがＲＰ２９１４によって提供される、要求されたサービスにアクセスするために、保証レベル（ＡＬ）が必要とされると判断する。２９５４で、図示された実施形態によれば、第２のＲＰ２９１４が、その保証レベル要件をブラウザ２９１０に通信する。２９５６で、ブラウザ２９１０が、ＭＦＡＳ２９１６のサービスを呼び出す。２９５６におけるメッセージは、必要とされる保証レベルを含み得る。２９５８で、サービスにアクセスするために必要とされる保証のレベルに基づいて、例えば、ＭＦＡＳ２９１６が、必要とされる保証レベルを達成するために実施され得る認証要素のタイプおよび強度を判断する。この判断は、第２のＲＰ２９１４のポリシーに従ってフレッシュであり得る、上記で説明された過去のパスワード認証に基づき得る。ＭＦＡＳ２９１６は、ユーザ２９０２およびＵＥ２９０１に関連付けられた情報（例えば、認証能力）を、ユーザプロファイルＤＢ２９２９から取り出し得る。この例によれば、２９３２で、ＭＦＡＳが、バイオメトリック認証が、第２のＲＰ２０１４からのサービスにアクセスするために必要とされると判断し得る。２９６９で、ＭＦＡＳ２９１６が、メッセージをウェブ−キーサーバ２９２０へ送ることによって、バイオメトリック認証をイニシエートし得る。レスポンスにおいて、２９６２において、ウェブキーサーバ２９２０が、構成データをＭＦＡＳ２９１６へ送る。２９６４で、ＭＦＡＳ２９１６が、ＨＴＴＰＳメッセージをブラウザ２９１０へ送ることによって、バイオメトリック認証をトリガする。２９６６で、ブラウザ２９１０が、ローカルバイオ−キークライアント２９０４を呼び出し、クライアント２９０４が、ユーザ２９０２に自分の指紋をスキャンさせるように促すようにする。したがって、２９６８で、指紋モデルがクライアント２９０４によって取得される。２９７０で、指紋モードがブラウザ２９１０へ送られる。２９７２で、指紋モデルがＭＦＡＳ２９１６へ送られる。２９７４で、ＭＦＡＳ２９１６が、指紋モデルをウェブ−キーサーバ２９２０へ、バイオメトリック認証のために送る。サーバ２９２０は、ユーザからの受信された指紋モデルがユーザの記憶された指紋にマッチすることを確認することによって、バイオメトリック認証を実施する。２９７６で、サーバ２９２０が、ＭＦＡＳ２９１６に、指紋がマッチすることを知らせる。そのようなメッセージは、認証結果と呼ばれることがある。２９７８で、ＭＦＡＳ２９１６が、パスワード認証およびバイオメトリック認証からの認証結果に基づいて、アサーションを作成する。アサーションは、以前の（フレッシュな）パスワード認証およびバイオメトリック認証の保証レベルを含む、関連付けられた保証レベルを有し得る。２９８０で、関連付けられた保証レベルを含み得るアサーションが、ブラウザ２９１０へ送られる。２９８２および２９８４で、アサーションが、第２のＲＰ２９１４にアサートされ、成功メッセージが、第２のＲＰ２９１４からブラウザ２９１０へ送られる。したがって、２９８６で、ユーザ／ＵＥが、第２のＲＰ２９１４によって提供される、要求されたサービスにアクセスすることができる。さらに、フレッシュな認証要素が、第２のＲＰによって提供されるサービスにアクセスするために活用され、それによって、効率的な認証が容易にされる。
次に図３０Ａ〜図３０Ｄを参照すると、例示的なシステム３０００は、システム２９００によって実施される多要素認証のような多要素認証を実施する。図３０Ａ〜図３０Ｅは、同じＲＰが異なるサービスをオファーし、したがって、異なる保証レベルが、ＲＰによってオファーされた異なるサービスを査定するために必要とされ得る、実施形態を示す。例えば、図３０Ｃを参照すると、２９５０で、ユーザ２９０２が、ＲＰ２９１２によって提供された第１のサービスへのアクセスを受信した後（２９４８参照）、ＲＰ２９１２によって提供された第２のサービスへのアクセスを要求する。２９５２ａで、ＲＰ２９１２が、例えばポリシーに基づいて、以前に取得されたよりも高い保証のレベルが、第２のサービスにアクセスするために必要とされると判断する。例えば、第２のサービスは、金銭取引を含み得るのに対して、第１のサービスは、ウェブページへのアクセスのみを含み得る。第２のサービスは、第１のサービスよりもセキュリティ観点から機密性の高いものであり得るので、より高い保証のレベルが、第２のサービスのために必要とされ得る。したがって、図３０Ｃ〜図３０Ｅを参照すると、ユーザ１０２は、ユーザがＲＰ２９１２の第１のサービスに既にアクセスしたにもかかわらず、ＲＰ２９１２の第２のサービスを査定するためにバイオメトリック認証を受ける。図３０Ａ〜図３０Ｄに図示された例示的な実施形態が、望まれるような任意の数のリライングパーティを使用して実装され得ることは理解されよう。
例示的な実施形態では、ＵＲＩのＵＲＬ部分におけるロケーション情報が、特定の認証要素をトリガするために使用される。例示的なＵＲＬは、以下を含む。
上記の例では、パスワードベースの認証がトリガされ、バイオメトリック認証によって後続される。
タイムスタンプを含有する認証アサーションを用いる、２要素（パスワードおよびバイオメトリック）認証のためのＯｐｅｎＩＤ ＡＸクエリレスポンスの一例は、以下を含み得る。
上記で示されたように、フェッチ要求に対するレスポンスは、遂行された２つの認証のリストを含有し得る。例えば署名属性行を除く、完全レスポンスが、ＯＰによって署名される。署名は、同じ署名キーを使用してそれに署名することによって、元のＯｐｅｎＩＤアサーションにバインドされ得る。これはまた、ＲＰがレスポンスを即時に検証することを可能にし得る。
例示的な実施形態では、認証要素が、最も弱い認証要素から開始して、順次の順序でループされる。
上記で説明されたようなＭＦＡＳは、認証保証のための複数の異なる要件を有するサービスプロバイダのための認証ポリシーのシームレスな実装を可能にし得る。例えば、サービスプロバイダは、それらが提供する異なるサービスに基づいて、異なる認証要件を有する。例として、電子商取引サイト（例えば、Ａｍａｚｏｎ）は、ウェブサイトにログインするための第１の認証要件（ユーザ名／パスワード）と、商品を購入するための第２の認証要件（バイオメトリック）とを有し得る。現在、チェックアウトするための手法は粗雑である。例えば、しばしば、ユーザ名およびパスワードがチェックアウトにおいて単に再入力され、それが、クレデンシャルがブラウザに記憶されるなどの様々な理由のために、セキュリティ弱点を引き起こし得る。上記で説明されたＭＦＡＳの例示的な実施形態によれば、ユーザは、ショッピングサイトを訪れ、カタログを閲覧し、品目をショッピングカートに追加し得る。それがチェックアウトに来るとき、ショッピングサイトページは、チェックアウトのための特定の認証ポリシーを使用するＭＦＡＳを使用して、ログインをトリガし得る。
この例示的なシナリオはまた、サービスプロバイダ一体化を疎結合されたままにしながら、支払い情報を管理し、支払いを認可するためのＭＦＡＳの柔軟性をデモンストレーションし得る。同じトラステッド／知られているインターフェースをユーザに提示することによって、彼は、自分の支払いがセキュアに処理されるようになることを保証され得、ストアから商品を購入する可能性がより高い。ストアは、支払いプロセスにおいて、ＭＦＡＳを操作し得るモバイルネットワーク事業者（ＭＮＯ）と、ユーザとの間の既存のビリング関係を活用することができる。モバイルネットワーク事業者は、ストアが加入者ベースにアクセスし、合理化された支払い方法およびプロセスをオファーして、ユーザに容易に関与するための方法を提供することができる。ＭＮＯとその加入者との既存のビリング関係が活用されてよく、電子商取引プラットフォームのような、ＭＮＯにより操作されないサービスに拡張され得る。以下の表は、上記で説明された例示的なシナリオから生じ得る、いくつかの例示的な利点を示す。
別の例として、ユーザは、例えばソーシャルネットワーキングサイトなどの第１のサイトを閲覧してよく、そこで、彼は、自分のＭＮＯによって提供されたＭＦＡＳログインを使用して、例えば自分のパスワードなど、自分の通常のクレデンシャルを用いてログインする。そのサイト上のあるアクティビティの後、ユーザは、例えばＡｍａｚｏｎなどの電子商取引サイトを用いてあるショッピングを行うように進むように決定する。そこで、彼は、自分のＭＮＯによって提供されたＭＦＡＳサービスを使用してログインするための（以前に訪問されたソーシャルネットワーキングサイト上のような）オプションを提示される。電子商取引サイトとＭＦＡＳとの間で合意された認証ポリシーは、それが十分にフレッシュであるとすれば、ソーシャルネットワーキングサイトとの以前の認証をクレデンシャルとして使用することを可能にし得る。したがって、ユーザが、電子商取引サイトに関連付けられる自分のＩＤを入力した（ブラウザ機能またはプラグインによってしばしば自動化されるステップ）後、ＭＮＯのＭＦＡＳシステムは、対応するポリシーをルックアップし、ソーシャルネットワークサイトとの以前の認証要素のフレッシュネスをチェックし、成功の場合、成功した認証を電子商取引サイトにアサートし得る。ユーザは、次いで、自分のためのいくつかのショッピング推奨を示す自分の個人ログインページにシームレスに連れて行かれる。
この例を続けると、ユーザは、自分のショッピングバスケットを満たすことができ、ある時点で、その中の商品を購入することを決定する。彼は、「チェックアウトに進む」ボタンを押す。チェックアウトのための電子商取引サイトのポリシーは、電子商取引サイトにログインするために使用されたものよりも強力な要素を使用する、別個の認証を必要とし得る。例えば、チェックアウトは、真の２要素認証として、電話ＳＩＭカード、プラス、ユーザによるバイオメトリック認証を使用する、事業者ベースの認証を必要とし得る。それはまた、少なくともバイオメトリック認証がフレッシュであるものとすることを、必要とし得る（すなわち、バイオメトリック要素を使用した以前のユーザ認証は、有効であると見なされない）。ＳＩＭカードを使用する第１の要素認証は、ユーザデバイスと事業者ＭＦＡＳシステムとの間で、バックグラウンドで進むが、バイオメトリック要素は、明示的なユーザ対話を必要とし、例えば、ユーザは、自分の指を電話の指紋センサ上でスワイプさせなければならない。
事業者ＭＦＡＳが、電子商取引サイトのチェックアウトのためのポリシーに従って、成功した組み合わされた認証をアサートした後、ユーザは、通常のチェックアウトページに連れて行かれ、そこで、彼は、自分の出荷および／または支払い詳細を確認／選択／編集することができる。上記で説明されたＭＦＡＳ実施形態を使用して、そのようなユーザ詳細は、ＭＦＡＳまたはクライアントデバイスからショッピングサイトへアドホックに転送され得る。
電子商取引ログインサイトと電子商取引チェックアウトサイトとの間の認証ポリシーの区別は、それぞれａｍａｚｏｎ．ｃｏｍ／ｌｏｇｉｎまたはｃｈｅｃｋｏｕｔ．ａｍａｚｏｎ．ｃｏｍなど、サブドメイン名またはサイトＵＲＬを使用することによってもたらされ得る。これらのＵＲＬの各々に対して、単一のユーザが、複数のデバイスを所有および使用して、同じまたは異なるサービスにアクセスする可能性が極めて高い。すべてのデバイスが同じ認証能力を示すとは限らないことがある。しかしながら、同じユーザおよび同じユーザ識別子が、サービスに代わってＦＮＸによって認証され得る。したがって、ＦＮＸは、上記で説明された機構をサポートして、複数のデバイスを単一のユーザにエンロールおよびマッピングし、ＦＮＸは、異なるデバイスから組み合わされるべき認証をサポートすることができる。例示のために提示された例示的なシナリオでは、ユーザは、自分のラップトップ上で自分の電子バンキングウェブサイトを閲覧し得る。ウェブサイトにログインするために、ウェブサイトは、ＦＮＸからのバイオメトリック認証を要求する。ＦＮＸは、次いで、ユーザのラップトップとのバイオメトリック認証をトリガする。ユーザが自分の指紋をスキャンした後、ＦＮＸは、バンキングウェブサイトに向けて必要なアサーションを作成し、アクセスが付与される。ユーザが次に取引を行うことを望むとき、バンキングウェブサイトは、ＦＮＸからのバイオメトリックプラスＳＭＳ認証を要求し得る。ＦＮＸは、要求を評価することができ、ＳＭＳがユーザの登録されたスマートフォンから可能であると検出する。ＦＮＸは、必要なＮＡＥコネクタをトリガして、ＳＭＳをユーザの電話に送り得る。ユーザは、そのＳＭＳをＦＮＸへ送り返して、ＳＭＳ認証を完了する。ポリシーによれば、最後のバイオメトリック認証は、ユーザがログインしたときにちょうど起こったので、ＦＮＸは、バイオメトリック要素を再認証する必要がなくてよい。例えば、ＦＮＸは、代わりに、フレッシュネスステートメントを、２つの認証のための組み合わされたアサーションに追加し得る。バンキング取引が、続いて遂行され得る。上記の例示的なシナリオでは、サービスが、それ自体のバイオメトリックおよびＳＭＳ認証インフラストラクチャを実装することなしに、シームレスおよび一体化された方法で認証をランすることができるのは、ＦＮＸによる両方の認証要素の知識を通してである。
上記の例示的なシナリオを可能にするために、ＦＮＸは、デバイスエンロールメント中にユーザが所有する各デバイスを構成するために使用され得る、追加のデバイスコネクタを有し得る。エンロールメントプロトコルの一部として、一実施形態によれば、ユーザは、このデバイスをＦＮＸに登録し、デバイス固有の能力をＦＮＸマッピングに追加する。ローカルＦＮＸの場合、ローカルＦＮＸは、ローカルデバイスのデバイス能力についてのみ知ることがある。しかしながら、ネットワークＦＮＸは、デバイス情報をユーザのすべてのローカルＦＮＸインスタンスに配信し得るので、例えば、モバイルフォンローカルＦＮＸは、それがユーザのラップトップ上でバイオメトリック認証をトリガすることができることを知るようになる。例えば、デバイス能力を含むポリシーは、ＭＦＡＳにおいて対応するユーザプロファイル中に記憶され得る。
次に図３１を参照すると、例示的なアーキテクチャ３２００は、ＦＩＤＯおよび上記で説明されたＭＦＡＳ機能性を見せるアーキテクチャがどのように互いとともに働き得るかの一例を示す。
図３１に示されたＦＩＤＯユーザデバイスは、ＦＩＤＯ可能なユーザデバイスを指し、それは、ＦＩＤＯ認証を行うために必要な構成要素を有するデバイスを指す。例示的な実施形態では、ＦＩＤＯ可能なユーザデバイスはまた、追加の多要素認証レイヤを有して、多要素認証における認証要素のうちの１つとしての、ＦＩＤＯオーセンティケータの使用を可能にする。ＦＩＤＯアーキテクチャの一部として、例示的なＦＩＤＯユーザデバイスは、ＦＩＤＯクライアントと、認証抽象化レイヤと、ＦＩＤＯオーセンティケータとからなる。
ＦＩＤＯクライアントは、ＦＩＤＯプロトコルのクライアント側を実装し、ＦＩＤＯオーセンティケータＡＰＩを介して、ＦＩＤＯオーセンティケータ抽象化レイヤとインターフェースする。ＦＩＤＯオーセンティケータ抽象化レイヤは、均一なＡＰＩを上位レイヤに提供し、オーセンティケータベースの暗号サービスの利用を可能にする。それは、均一な下位レイヤ「オーセンティケータプラグイン」ＡＰＩを提供し、マルチベンダオーセンティケータとそれらの必須のドライバとの採用を容易にする。
ＦＩＤＯオーセンティケータは、ＦＩＤＯユーザデバイスに付加されるか、またはＦＩＤＯユーザデバイス内に収容される、セキュアエンティティであり得る。それは、リライングパーティによってキー材料を遠隔でプロビジョンされ得ることがあり、それは次いで、暗号強力認証プロトコルに参加することが可能である。例えば、ＦＩＤＯオーセンティケータは、キー材料に基づいて暗号チャレンジレスポンスを提供し、したがってそれ自体を認証することが可能であり得る。
デバイス側で、例えば、ＦＩＤＯユーザデバイスは、上記で説明されたＭＦＡＰを収容してよく、それは、上記で説明されたＭＦＡＳと対話し、したがって、多要素認証における認証要素のうちの１つとしての、ＦＩＤＯの使用を可能にする。ＭＦＡＰは、典型的にはＦＩＤＯオーセンティケータ（複数可）によって遂行される、２ステップローカル認証（複数可）の、ネットワークの認証プロトコルとのバインディング（暗号または他の手段）を容易にし得る。ＭＦＡＰは、認証要素のフレッシュネス態様と、全体的な多要素認証および可変グレード認証保証を駆動するポリシーとを含む、ＭＦＡａａＳサービスのフルネスを考慮に入れ得る。
例示的な実施形態では、ＭＦＡａａＳサービスは、ＭＦＡＳの制御を有してよく、またＦＩＤＯサーバおよびＦＩＤＯ証明サービスを有してもよく、または、これらのＦＩＤＯ構成要素への外部接続がプロビジョンされ得る。ＦＩＤＯサーバは、様々な機能性を有し得る。例えば、ＦＩＤＯサーバは、ＦＩＤＯプロトコルのサーバ部分を実装し、ＦＩＤＯ証明サービスと通信して、ＦＩＤＯオーセンティケータ証明を妥当性検査し、ＦＩＤＯ証明サービスと通信して、ＦＩＤＯオーセンティケータデータを更新し得る。ＦＩＤＯ証明サービスは、ＦＩＤＯオーセンティケータとＦＩＤＯサーバとの間のループを閉じるために使用され得る。ＦＩＤＯ証明サービスの責任は、例えば、ＦＩＤＯオーセンティケータを支持すること、ＦＩＤＯオーセンティケータ証明を妥当性検査すること、およびＦＩＤＯオーセンティケータの取り消しデータをＦＩＤＯサーバに提供することを含み得る。
例示的な実施形態によれば、上記で説明されるＭＦＡＳにおいて、ＦＩＤＯ要素のための認証モジュールが追加される。このモジュールが呼び出されるとき、それは、ＦＩＤＯオーセンティケータに基づいて、ローカル認証を行うように、ＭＦＡＰに命じてよい。この認証は、ＦＩＤＯサーバによって証明サービスを使用して妥当性検査され得る。したがって、ＦＩＤＯ認証アーキテクチャは、例示的な実施形態によれば、ＭＦＡａａＳと連動して働くように修正されてよく、ここにおいて、異なるタイプのネットワーク認証ベクトルおよびローカル認証ベクトルが、様々なリライングパーティに認証するための異なる望まれる方法で組み合わされ得る。
図３２Ａは、１または複数の開示された実施形態が実装され得る、例示的な通信システム５０の図である。通信システム５０は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数のワイヤレスユーザに提供する、多重アクセスシステムであり得る。通信システム５０は、ワイヤレス帯域幅を含むシステムリソースの共有を通して、複数のワイヤレスユーザがそのようなコンテンツにアクセスすることを可能にし得る。例えば、通信システム５０は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）など、１または複数のチャネルアクセス方法を採用し得る。
図３２Ａに示されるように、通信システム５０は、ワイヤレス送信／受信ユニット（ＷＴＲＵ）５２ａ、５２ｂ、５２ｃ、５２ｄと、無線アクセスネットワーク（ＲＡＮ）５４と、コアネットワーク５６と、公衆交換電話ネットワーク（ＰＳＴＮ）５８と、インターネット６０と、他のネットワーク６２とを含み得るが、開示された実施形態が任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワークエレメントを企図することは諒解されよう。ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄの各々は、ワイヤレス環境内で動作および／または通信するように構成された任意のタイプのデバイスであり得る。例として、ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄは、ワイヤレス信号を送信および／または受信するように構成されてよく、ユーザ機器（ＵＥ）、移動局、固定またはモバイル加入者ユニット、ページャ、携帯電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、家庭用電化製品などを含み得る。
通信システム５０はまた、基地局６４ａと基地局６４ｂとを含み得る。基地局６４ａ、６４ｂの各々は、ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄのうちの少なくとも１つとワイヤレスにインターフェースして、コアネットワーク５６、インターネット６０、および／またはネットワーク６２など、１または複数の通信ネットワークへのアクセスを容易にするように構成された、任意のタイプのデバイスであり得る。例として、基地局６４ａ、６４ｂは、トランシーバ基地局（ＢＴＳ）、ノードＢ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ワイヤレスルータなどであり得る。基地局６４ａ、６４ｂは、それぞれ単一のエレメントとして示されるが、基地局６４ａ、６４ｂが任意の数の相互接続された基地局および／またはネットワークエレメントを含み得ることは諒解されよう。
基地局６４ａは、ＲＡＮ５４の一部であってよく、それはまた、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、リレーノードなど、他の基地局および／またはネットワークエレメント（図示せず）を含んでもよい。基地局６４ａおよび／または基地局６４ｂは、セル（図示せず）と呼ばれることがある特定の地理的領域内で、ワイヤレス信号を送信および／または受信するように構成され得る。セルは、セルセクタにさらに分割され得る。例えば、基地局６４ａに関連付けられたセルは、３つのセクタに分割され得る。したがって、一実施形態では、基地局６４ａは３つのトランシーバを、すなわち、セルのセクタごとに１つずつ含み得る。別の実施形態では、基地局６４ａは、多入力多出力（ＭＩＭＯ）技術を採用してよく、したがって、セルのセクタごとに複数のトランシーバを利用してよい。
基地局６４ａ、６４ｂは、エアインターフェース６６を介して、ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄのうちの１または複数と通信してよく、エアインターフェース６６は、任意の好適なワイヤレス通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光線など）であり得る。エアインターフェース６６は、任意の好適な無線アクセス技術（ＲＡＴ）を使用して確立され得る。
より詳細には、上述されたように、通信システム５０は、多重アクセスシステムであってよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなど、１または複数のチャネルアクセス方式を採用し得る。例えば、ＲＡＮ５４における基地局６４ａ、および、ＷＴＲＵ５２ａ、５２ｂ、５２ｃは、ユニバーサルモバイル電気通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実装してよく、それは、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用して、エアインターフェース６６を確立し得る。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または発展型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含み得る。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含み得る。
一実施形態では、基地局６４ａおよびＷＴＲＵ５２ａ、５２ｂ、５２ｃは、発展型ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実装してよく、それは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用して、エアインターフェース６６を確立し得る。
他の実施形態では、基地局６４ａおよびＷＴＲＵ５２ａ、５２ｂ、５２ｃは、ＩＥＥＥ８０２．１６（すなわち、ワールドワイドインターオペラビリティフォーマイクロウェーブアクセス（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、モバイル通信用グローバルシステム（ＧＳＭ（登録商標））、ＧＳＭ進化型高速データレート（ＥＤＧＥ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装し得る。
図３２Ａにおける基地局６４ｂは、例えば、ワイヤレスルータ、ホームノードＢ、ホームｅノードＢ、フェムトセル基地局、またはアクセスポイントであってよく、職場、自宅、車両、キャンパスなど、局在化されたエリア内のワイヤレス接続性を容易にするための任意の好適なＲＡＴを利用し得る。一実施形態では、基地局６４ｂおよびＷＴＲＵ５２ｃ、５２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実装して、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）を確立し得る。一実施形態では、基地局６４ｂおよびＷＴＲＵ５２ｃ、５２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）を確立し得る。さらに別の実施形態では、基地局６４ｂおよびＷＴＲＵ５２ｃ、５２ｄは、セルラーベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立し得る。図３２Ａに示されるように、基地局６４ｂは、インターネット６０への直接接続を有し得る。したがって、基地局６４ｂは、コアネットワーク５６を介してインターネット６０にアクセスすることが必要とされなくてよい。
ＲＡＮ５４は、コアネットワーク５６と通信していてよく、それは、音声、データ、アプリケーション、および／またはボイスオーバーインターネットプロトコル（ＶｏＩＰ）サービスを、ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄのうちの１または複数に提供するように構成された、任意のタイプのネットワークであり得る。例えば、コアネットワーク５６は、呼制御、ビリングサービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続性、ビデオ配信などを提供し、および／または、ユーザ認証などの高レベルセキュリティ機能を実施し得る。図３２Ａに示されていないが、ＲＡＮ５４および／またはコアネットワーク５６は、ＲＡＮ５４と同じＲＡＴまたは異なるＲＡＴを採用する他のＲＡＮと、直接的または間接的に通信中であり得ることは諒解されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用中であり得るＲＡＮ５４に接続されることに加えて、コアネットワーク５６はまた、ＧＳＭ無線技術を採用する別のＲＡＮ（図示せず）と通信中であり得る。
コアネットワーク５６はまた、ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄがＰＳＴＮ５８、インターネット６０、および／または他のネットワーク６２にアクセスするための、ゲートウェイとしても働き得る。ＰＳＴＮ５８は、基本電話サービス（ＰＯＴＳ）を提供する回線交換電話ネットワークを含み得る。インターネット６０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおける、送信制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）など、共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスのグローバルなシステムを含み得る。ネットワーク６２は、他のサービスプロバイダによって所有され、および／または動作させられる、ワイヤードまたはワイヤレス通信ネットワークを含み得る。例えば、ネットワーク６２は、ＲＡＮ５４と同じＲＡＴまたは異なるＲＡＴを採用し得る１または複数のＲＡＮに接続された、別のコアネットワークを含み得る。
通信システム８００におけるＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄの一部または全部は、マルチモード能力を含んでよく、すなわち、ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄは、異なるワイヤレスリンクを介して異なるワイヤレスネットワークと通信するための複数のトランシーバを含み得る。例えば、図３２Ａに示されたＷＴＲＵ５２ｃは、セルラーベースの無線技術を採用し得る基地局６４ａと、および、ＩＥＥＥ８０２無線技術を採用し得る基地局６４ｂと、通信するように構成され得る。
図３２Ｂは、例示的なＷＴＲＵ５２のシステム図である。図３２Ｂに示されるように、ＷＴＲＵ５２は、プロセッサ６８と、トランシーバ７０と、送信／受信エレメント７２と、スピーカー／マイクロフォン７４と、キーパッド７６と、ディスプレイ／タッチパッド７８と、非リムーバブルメモリ８０と、リムーバブルメモリ８２と、電源８４と、全地球測位システム（ＧＰＳ）チップセット８６と、他の周辺機器８８とを含み得る。ＷＴＲＵ５２は、一実施形態と矛盾しないままで、前述のエレメントの任意の部分組合せを含み得ることは諒解されよう。
プロセッサ６８は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、また、ＤＳＰコア、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態機械などに関連する、１または複数のマイクロプロセッサであり得る。プロセッサ６８は、信号コーディング、データ処理、電力制御、入力／出力処理、および／または、ＷＴＲＵ５２がワイヤレス環境において動作することを可能にする任意の他の機能性を実施し得る。プロセッサ６８は、送信／受信エレメント７２に結合され得るトランシーバ７０に結合され得る。図３２Ｂは、プロセッサ６８およびトランシーバ７０を別個の構成要素として図示するが、プロセッサ６８およびトランシーバ７０は、電子パッケージまたはチップにおいて一緒に統合され得ることは諒解されよう。プロセッサ６８は、アプリケーションレイヤプログラム（例えば、ブラウザ）、ならびに／または無線アクセスレイヤ（ＲＡＮ）プログラムおよび／もしくは通信を実施し得る。プロセッサ６８は、例えば、アクセスレイヤおよび／またはアプリケーションレイヤにおいてなど、認証、セキュリティキー合意、および／または暗号動作など、セキュリティ動作を実施し得る。
送信／受信エレメント７２は、エアインターフェース６６を介して、基地局（例えば、基地局６４ａ）へ信号を送信し、または、基地局から信号を受信するように構成され得る。例えば、一実施形態では、送信／受信エレメント７２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであり得る。一実施形態では、送信／受信エレメント７２は、例えば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成されたエミッタ／検出器であり得る。さらに別の実施形態では、送信／受信エレメント７２は、ＲＦ信号と光信号の両方を送信および受信するように構成され得る。送信／受信エレメント７２は、任意の組合せのワイヤレス信号を送信および／または受信するように構成され得ることは諒解されよう。
加えて、送信／受信エレメント７２は、図３２Ｂにおいて単一のエレメントとして図示されるが、ＷＴＲＵ５２は、任意の数の送信／受信エレメント７２を含み得る。より詳細には、ＷＴＲＵ５２は、ＭＩＭＯ技術を採用し得る。したがって、一実施形態では、ＷＴＲＵ５２は、エアインターフェース６６を介してワイヤレス信号を送信および受信するための、２またはそれ以上の送信／受信エレメント７２（例えば、複数のアンテナ）を含み得る。
トランシーバ７０は、送信／受信エレメント７２によって送信されることになる信号を変調するように、および、送信／受信エレメント７２によって受信される信号を復調するように構成され得る。上述されたように、ＷＴＲＵ５２は、マルチモード能力を有し得る。したがって、トランシーバ７０は、ＷＴＲＵ５２が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にするための、複数のトランシーバを含み得る。
ＷＴＲＵ５２のプロセッサ６８は、スピーカー／マイクロフォン７４、キーパッド７６、および／または、ディスプレイ／タッチパッド７８（例えば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニット、もしくは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合されてよく、それらからユーザ入力データを受信し得る。プロセッサ６８はまた、ユーザデータを、スピーカー／マイクロフォン７４、キーパッド７６、および／または、ディスプレイ／タッチパッド７８に出力し得る。加えて、プロセッサ８１８は、非リムーバブルメモリ８０および／またはリムーバブルメモリ８２など、任意のタイプの好適なメモリからの情報にアクセスし、それにデータを記憶し得る。非リムーバブルメモリ８０は、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。リムーバブルメモリ８２は、加入者アイデンティティモジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含み得る。他の実施形態では、プロセッサ８１８は、サーバまたはホームコンピュータ（図示せず）上など、ＷＴＲＵ５２上に物理的にロケートされないメモリからの情報にアクセスし、それにデータを記憶し得る。
プロセッサ６８は、電源８４から電力を受信してよく、ＷＴＲＵ５２における他の構成要素への電力を分配および／または制御するように構成され得る。電源８４は、ＷＴＲＵ５２に電力供給するための任意の好適なデバイスであり得る。例えば、電源８４は、１または複数の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、燃料電池などを含み得る。
プロセッサ６８はまた、ＧＰＳチップセット８６に結合されてもよく、それは、ＷＴＲＵ５２の現在のロケーションに関するロケーション情報（例えば、経度および緯度）を提供するように構成され得る。ＧＰＳチップセット８６からの情報に加えて、またはその代わりに、ＷＴＲＵ５２は、エアインターフェース８１６を介して、基地局（例えば、基地局６４ａ、６４ｂ）からロケーション情報を受信し、および／または、信号が２またはそれ以上の近くの基地局から受信されるタイミングに基づいて、そのロケーションを判断し得る。ＷＴＲＵ５２は、一実施形態と矛盾しないままで、任意の好適なロケーション判断方法によってロケーション情報を獲得し得ることは諒解されよう。
プロセッサ６８は、他の周辺機器８８にさらに結合されてよく、それらは、追加の特徴、機能性、および／またはワイヤードもしくはワイヤレス接続性を提供する、１または複数のソフトウェアおよび／またはハードウェアモジュールを含み得る。例えば、周辺機器８８は、加速度計、ｅコンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含み得る。
図３２Ｃは、一実施形態によるＲＡＮ５４およびコアネットワーク８０６のシステム図である。上述されたように、ＲＡＮ５４は、ＵＴＲＡ無線技術を採用して、エアインターフェース６６を介してＷＴＲＵ５２ａ、５２ｂ、５２ｃと通信し得る。ＲＡＮ５４はまた、コアネットワーク８０６と通信中であり得る。図３２Ｃに示されるように、ＲＡＮ５４は、ノードＢ９０ａ、９０ｂ、９０ｃを含み得るが、それらは、エアインターフェース６６を介してＷＴＲＵ５２ａ、５２ｂ、５２ｃと通信するための、１または複数のトランシーバをそれぞれ含み得る。ノードＢ９０ａ、９０ｂ、９０ｃは、それぞれ、ＲＡＮ５４内の特定のセル（図示せず）に関連付けられ得る。ＲＡＮ５４はまた、ＲＮＣ９２ａ、９２ｂを含み得る。ＲＡＮ５４は、一実施形態と矛盾しないままで、任意の数のノードＢおよびＲＮＣを含み得ることは諒解されよう。
図３２Ｃに示されるように、ノードＢ９０ａ、９０ｂは、ＲＮＣ９２ａと通信中であり得る。追加として、ノードＢ９０ｃは、ＲＮＣ９２ｂと通信中であり得る。ノードＢ９０ａ、９０ｂ、９０ｃは、Ｉｕｂインターフェースを介してそれぞれのＲＮＣ９２ａ、９２ｂと通信し得る。ＲＮＣ９２ａ、９２ｂは、Ｉｕｒインターフェースを介して互いと通信中であり得る。ＲＮＣ９２ａ、９２ｂの各々は、それが接続される先のそれぞれのノードＢ９０ａ、９０ｂ、９０ｃを制御するように構成され得る。加えて、ＲＮＣ９２ａ、９２ｂの各々は、アウターループ電力制御、負荷制御、承認制御、パケットスケジューリング、ハンドオーバー制御、マクロダイバーシティ、セキュリティ機能、データ暗号化など、他の機能性を遂行および／またはサポートするように構成され得る。
図３２Ｃに示されるコアネットワーク５６は、メディアゲートウェイ（ＭＧＷ）８４４、モバイル交換センター（ＭＳＣ）９６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）９８、および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）９９を含み得る。前述のエレメントの各々は、コアネットワーク５６の一部として図示されるが、これらのエレメントのいずれか１つは、コアネットワーク事業者以外のエンティティによって所有され、および／または動作させられ得ることは諒解されよう。
ＲＡＮ５４中のＲＮＣ９２ａは、ＩｕＣＳインターフェースを介してコアネットワーク５６中のＭＳＣ９６に接続され得る。ＭＳＣ９６は、ＭＳＷ９４に接続され得る。ＭＳＣ９６およびＭＧＷ９４は、ＷＴＲＵ５２ａ、５２ｂ、５２ｃに、ＰＳＴＮ５８などの回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ５２ａ、５２ｂ、５２ｃと従来の陸線通信デバイスとの間の通信を容易にし得る。
ＲＡＮ５４中のＲＮＣ９２ａはまた、ＩｕＰＳインターフェースを介してコアネットワーク８０６中のＳＧＳＮ９８にも接続され得る。ＳＧＳＮ９８は、ＧＧＳＮ９９に接続され得る。ＳＧＳＮ９８およびＧＧＳＮ９９は、ＷＴＲＵ５２ａ、５２ｂ、５２ｃに、インターネット６０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ５２ａ、５２ｂ、５２ｃとＩＰ可能デバイスとの間の通信を容易にし得る。
上述されたように、コアネットワーク５６はまた、ネットワーク６２に接続されてもよく、ネットワーク６２は、他のサービスプロバイダによって所有され、および／または動作させられる他のワイヤードまたはワイヤレスネットワークを含み得る。
特徴およびエレメントが、上記で特定の組合せにおいて説明されるが、各特徴またはエレメントは、単独で、または、他の特徴およびエレメントとの任意の組合せにおいて使用され得る。追加として、本明細書で説明される実施形態は、例示のためにのみ提供される。さらに、本明細書で説明される実施形態は、コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体に組み込まれた、コンピュータプログラム、ソフトウェア、またはファームウェアにおいて実装され得る。コンピュータ可読媒体の例は、（ワイヤードまたはワイヤレス接続を介して送信される）電子信号、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、それに限定されないが、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびに、ＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光媒体を含む。ソフトウェアに関連するプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおいて使用するための、無線周波数トランシーバを実装するために使用され得る。

Claims (19)

  1. ワイヤレス送信／受信ユニット（ＷＴＲＵ）または前記ＷＴＲＵを操作するユーザのうちの少なくとも１つの認証を容易にする方法であって、前記ＷＴＲＵは、サービスプロバイダ（ＳＰ）をさらに含む通信ネットワーク中にあり、
    前記ＳＰによって提供される第１のサービスにアクセスするために前記ＳＰによって必要とされる第１の認証保証レベルを判断するステップと、
    前記ＷＴＲＵの１または複数の認証能力を発見するステップと、
    前記発見された１または複数の認証能力が、前記ＳＰによって必要とされる前記第１の認証保証レベルを満たすことができるか否かを判断するステップと、
    前記発見された１または複数の認証能力が、前記ＳＰによって必要とされる前記第１の認証保証レベルを満たすことができる場合、前記発見された１または複数の認証能力に関連付けられた１または複数の認証要素のうちの少なくとも１つを使用する実施をトリガするステップと
    を備える、方法。
  2. 前記１または複数の認証要素の各々の前記実施に関連付けられた１または複数の認証結果に基づいて、前記ＳＰによって必要とされる前記第１の認証保証レベルを達成する、統合された結果を作成するステップと、
    前記統合された結果を前記ＳＰへ送り、それによって、前記ＷＴＲＵが前記第１のサービスにアクセスすることを可能にするステップと
    をさらに備える、請求項１に記載の方法。
  3. 前記統合された結果は、暗号方法で一緒にバインドされた前記１または複数の認証結果を備え、前記統合された結果は、一緒にバインドされた前記１または複数の認証結果を識別する、請求項２に記載の方法。
  4. 前記統合された結果は、アグリゲート認証保証レベルとアグリゲート認証フレッシュネスレベルとをさらに備え、前記アグリゲート認証保証レベルおよび前記アグリゲート認証フレッシュネスレベルは、前記１または複数の認証結果に関連付けられる、請求項３に記載の方法。
  5. 前記統合された結果は、前記１または複数の認証要素の各々の前記実施の間に共有されるナンスによってバインドされた前記１または複数の認証結果を備える、請求項２に記載の方法。
  6. 前記１または複数の認証要素のうちの選択された１つに関連付けられたフレッシュネスレベルを判断するステップと、
    前記ＳＰのポリシーに基づいて、前記選択された１つの認証要素に関連付けられた前記フレッシュネスレベルがしきい値レベルを満足するか否かを判断するステップと、
    前記フレッシュネスレベルが前記しきい値レベルを満足する場合、前記１つの認証要素の以前の認証結果をアサートし、それによって、前記１つの認証要素を使用する新しい認証を実施することを控えるステップと
    をさらに備える、請求項１に記載の方法。
  7. 前記１または複数の認証要素のうちの少なくとも１つの前記実施をトリガするステップは、
    チャレンジをネットワーク認証エンティティへ送るステップと、
    前記チャレンジに応答して、レスポンスを前記ネットワーク認証エンティティから受信するステップと
    を備える、請求項１に記載の方法。
  8. 前記ＷＴＲＵ上で動作する論理エンティティによって実施される、請求項１に記載の方法。
  9. 前記ＷＴＲＵおよび前記ＳＰと通信している前記通信ネットワーク中で動作する論理エンティティによって実施される、請求項１に記載の方法。
  10. 前記発見された１または複数の認証能力が、前記第１の認証保証レベルを満たすことができない場合、第２の認証保証レベルを達成することができる１または複数の認証要素を選択するステップと、
    前記第２の認証保証レベルを達成することができる前記１または複数の認証要素の実施をトリガするステップと
    をさらに備える、請求項１に記載の方法。
  11. 前記第２の認証保証レベルを達成することができる前記１または複数の認証要素の前記実施に関連付けられた１または複数の認証結果に基づいて、前記方法は、
    前記第２の認証保証レベルを達成する、第２の統合された結果を作成するステップと、
    前記第２の統合された結果を前記ＳＰへ送り、それによって、前記ＷＴＲＵが、前記ＳＰによって提供された第２のサービスにアクセスすることを可能にするステップであって、前記第２のサービスへのアクセスは、前記第１のサービスにアクセスするために必要とされる前記第１の認証保証レベルよりも低い保証レベルを必要とする、ステップと、
    をさらに備える、請求項１０に記載の方法。
  12. 前記発見された１または複数の認証能力のいずれもが前記第１の認証保証レベルを満たすことができない場合、または、前記１または複数の認証要素を使用する前記実施が失敗する場合、通知を前記ＳＰへ送り、少なくとも前記ＷＴＲＵまたはユーザが、前記ＳＰによって提供されたサービスへのアクセスを受信しないようにするステップ
    をさらに備える、請求項１に記載の方法。
  13. 前記発見された１または複数の認証能力は、バイオメトリック能力を備え、前記方法は、
    前記バイオメトリック能力を使用する認証が、前記第１の認証保証レベルを満たすことができると判断するステップ
    をさらに備える、請求項１に記載の方法。
  14. 前記１または複数の認証要素のうちの１つは、バイオメトリック要素であり、前記バイオメトリック要素は、唯一の認証要素である、請求項１３に記載の方法。
  15. 前記１または複数の認証要素のうちの第１の認証要素は、バイオメトリック要素であり、前記１または複数の認証要素のうちの第２の認証要素は、パスワード要素である、請求項１に記載の方法。
  16. 前記１または複数の認証能力を発見するステップは、
    前記ＷＴＲＵの登録中に、前記ＷＴＲＵの少なくとも１つの能力を受信するステップと、
    前記ＷＴＲＵの前記少なくとも１つの能力を、前記ＷＴＲＵの識別子とともに記憶するステップと、
    前記識別子に基づいて、前記ＷＴＲＵが前記第１のサービスにアクセスしようと試みるとき前記少なくとも１つの能力を取り出すステップと
    を備える、請求項１に記載の方法。
  17. ワイヤレス送信／受信ユニット（ＷＴＲＵ）とサービスプロバイダ（ＳＰ）とをさらに含む通信ネットワーク中のネットワークサーバであって、
    実行可能命令を備えるメモリと、
    プロセッサであって、前記実行可能命令を実行するとき、
    前記ＳＰによって提供される第１のサービスにアクセスするための認証要件を判断するステップと、
    前記ＷＴＲＵの１または複数の認証能力を発見するステップと、
    前記発見された１または複数の認証能力のうちの少なくとも１つが、前記認証要件を達成することができるか否かを判断するステップと、
    前記発見された１または複数の認証能力が前記認証要件を達成することができる場合、前記認証能力に関連付けられた１または複数の認証要素のうちの少なくとも１つを使用する実施をトリガするステップと
    を含む動作を実現するプロセッサと
    を備える、ネットワークサーバ。
  18. 前記ネットワークサーバは、アイデンティティプロバイダ（ＩｄＰ）であり、前記１または複数の認証要素のうちの前記少なくとも１つを使用する前記実施は、前記ＩｄＰにおいて発生する、請求項１７に記載のネットワークサーバ。
  19. 前記ＳＰによって提供される第１のサービスにアクセスするための認証要件を判断するステップは、
    前記認証要件を前記ＳＰから受信するステップであって、前記認証要件は、認証保証レベルを示す、ステップと、
    を含む、請求項１７に記載のネットワークサーバ。
JP2016510810A 2013-04-26 2014-04-25 必要とされる認証保証レベルを達成するための多要素認証 Expired - Fee Related JP6307593B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201361816446P 2013-04-26 2013-04-26
US61/816,446 2013-04-26
US201361832509P 2013-06-07 2013-06-07
US61/832,509 2013-06-07
PCT/US2014/035517 WO2014176539A1 (en) 2013-04-26 2014-04-25 Multi-factor authentication to achieve required authentication assurance level

Publications (2)

Publication Number Publication Date
JP2016525807A JP2016525807A (ja) 2016-08-25
JP6307593B2 true JP6307593B2 (ja) 2018-04-04

Family

ID=50942315

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016510810A Expired - Fee Related JP6307593B2 (ja) 2013-04-26 2014-04-25 必要とされる認証保証レベルを達成するための多要素認証

Country Status (7)

Country Link
US (1) US20160087957A1 (ja)
EP (1) EP2989770A1 (ja)
JP (1) JP6307593B2 (ja)
KR (1) KR101924683B1 (ja)
CN (1) CN105144656A (ja)
TW (1) TW201541977A (ja)
WO (1) WO2014176539A1 (ja)

Families Citing this family (293)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11204729B2 (en) 2000-11-01 2021-12-21 Flexiworld Technologies, Inc. Internet based digital content services for pervasively providing protected digital content to smart devices based on having subscribed to the digital content service
US20020051200A1 (en) 2000-11-01 2002-05-02 Chang William Ho Controller for device-to-device pervasive digital output
US10915296B2 (en) 2000-11-01 2021-02-09 Flexiworld Technologies, Inc. Information apparatus that includes a touch sensitive screen interface for managing or replying to e-mails
US10860290B2 (en) 2000-11-01 2020-12-08 Flexiworld Technologies, Inc. Mobile information apparatuses that include a digital camera, a touch sensitive screen interface, support for voice activated commands, and a wireless communication chip or chipset supporting IEEE 802.11
US7318086B2 (en) 2000-11-20 2008-01-08 Flexiworld Technologies, Inc. System for mobile and pervasive output
US20020097408A1 (en) 2001-01-19 2002-07-25 Chang William Ho Output device for universal data output
US9203835B2 (en) 2013-03-01 2015-12-01 Paypal, Inc. Systems and methods for authenticating a user based on a biometric model associated with the user
US20160048846A1 (en) * 2013-03-15 2016-02-18 Capital One Financial Corporation System and method for digital authentication
US9887983B2 (en) 2013-10-29 2018-02-06 Nok Nok Labs, Inc. Apparatus and method for implementing composite authenticators
US10270748B2 (en) 2013-03-22 2019-04-23 Nok Nok Labs, Inc. Advanced authentication techniques and applications
US9396320B2 (en) 2013-03-22 2016-07-19 Nok Nok Labs, Inc. System and method for non-intrusive, privacy-preserving authentication
US9961077B2 (en) 2013-05-30 2018-05-01 Nok Nok Labs, Inc. System and method for biometric authentication with device attestation
US10069811B2 (en) * 2013-10-17 2018-09-04 Arm Ip Limited Registry apparatus, agent device, application providing apparatus and corresponding methods
US20150242605A1 (en) * 2014-02-23 2015-08-27 Qualcomm Incorporated Continuous authentication with a mobile device
US10032008B2 (en) 2014-02-23 2018-07-24 Qualcomm Incorporated Trust broker authentication method for mobile devices
US10049202B1 (en) 2014-03-25 2018-08-14 Amazon Technologies, Inc. Strong authentication using authentication objects
US10050787B1 (en) * 2014-03-25 2018-08-14 Amazon Technologies, Inc. Authentication objects with attestation
US9680812B1 (en) * 2014-03-27 2017-06-13 EMC IP Holding Company LLC Enrolling a user in a new authentication procdure only if trusted
US10069868B2 (en) * 2014-03-28 2018-09-04 Intel Corporation Systems and methods to facilitate multi-factor authentication policy enforcement using one or more policy handlers
US9654469B1 (en) 2014-05-02 2017-05-16 Nok Nok Labs, Inc. Web-based user authentication techniques and applications
GB201408539D0 (en) * 2014-05-14 2014-06-25 Mastercard International Inc Improvements in mobile payment systems
US9264419B1 (en) * 2014-06-26 2016-02-16 Amazon Technologies, Inc. Two factor authentication with authentication objects
KR102191017B1 (ko) * 2014-07-19 2020-12-15 삼성전자주식회사 eSIM 프로비저닝 방법과 이를 지원하는 서버 장치
US9875347B2 (en) 2014-07-31 2018-01-23 Nok Nok Labs, Inc. System and method for performing authentication using data analytics
US9749131B2 (en) 2014-07-31 2017-08-29 Nok Nok Labs, Inc. System and method for implementing a one-time-password using asymmetric cryptography
US10148630B2 (en) 2014-07-31 2018-12-04 Nok Nok Labs, Inc. System and method for implementing a hosted authentication service
US10740447B2 (en) 2014-09-08 2020-08-11 Tessera Advanced Technologies, Inc. Using biometric user-specific attributes
US9740841B2 (en) * 2014-09-08 2017-08-22 Tessera Advanced Technologies, Inc. Using biometric user-specific attributes
US10142338B2 (en) * 2014-09-12 2018-11-27 Id.Me, Inc. Systems and methods for online third-party authentication of credentials
US9736154B2 (en) 2014-09-16 2017-08-15 Nok Nok Labs, Inc. System and method for integrating an authentication service within a network architecture
US10560418B2 (en) * 2014-10-02 2020-02-11 Facebook, Inc. Techniques for managing discussion sharing on a mobile platform
US10225245B2 (en) * 2014-11-18 2019-03-05 Auth0, Inc. Identity infrastructure as a service
AU2015378512B2 (en) * 2014-12-31 2020-07-02 Tech5 Usa, Inc. Cloud-based biometric enrollment, identification and verification through identity providers
WO2016112290A1 (en) * 2015-01-09 2016-07-14 Interdigital Technology Corporation Scalable policy based execution of multi-factor authentication
CN104660416B (zh) * 2015-02-13 2018-08-28 飞天诚信科技股份有限公司 一种语音认证系统和设备的工作方法
US11171941B2 (en) 2015-02-24 2021-11-09 Nelson A. Cicchitto Mobile device enabled desktop tethered and tetherless authentication
US11122034B2 (en) 2015-02-24 2021-09-14 Nelson A. Cicchitto Method and apparatus for an identity assurance score with ties to an ID-less and password-less authentication system
US9565183B2 (en) * 2015-03-13 2017-02-07 Apollo Education Group, Inc. Location and device based student access control
CN106161365B (zh) * 2015-04-03 2020-02-18 腾讯科技（深圳）有限公司 一种数据处理方法、装置及终端
US10298563B2 (en) 2015-04-29 2019-05-21 Hewlett Packard Enterprise Development Lp Multi-factor authorization for IEEE 802.1x-enabled networks
CN106211152B (zh) * 2015-04-30 2019-09-06 新华三技术有限公司 一种无线接入认证方法及装置
US9866543B2 (en) * 2015-06-03 2018-01-09 Paypal, Inc. Authentication through multiple pathways based on device capabilities and user requests
US10009329B2 (en) 2015-06-23 2018-06-26 Microsoft Technology Licensing, Llc Learned roving authentication profiles
US10757104B1 (en) 2015-06-29 2020-08-25 Veritas Technologies Llc System and method for authentication in a computing system
US9736169B2 (en) * 2015-07-02 2017-08-15 International Business Machines Corporation Managing user authentication in association with application access
CN106487511B (zh) * 2015-08-27 2020-02-04 阿里巴巴集团控股有限公司 身份认证方法及装置
JP5951094B1 (ja) * 2015-09-07 2016-07-13 ヤフー株式会社 生成装置、端末装置、生成方法、生成プログラム及び認証処理システム
US10135801B2 (en) * 2015-09-09 2018-11-20 Oath Inc. On-line account recovery
US9779230B2 (en) * 2015-09-11 2017-10-03 Dell Products, Lp System and method for off-host abstraction of multifactor authentication
JP6122924B2 (ja) 2015-09-11 2017-04-26 ヤフー株式会社 提供装置、端末装置、提供方法、提供プログラム及び認証処理システム
US10616196B1 (en) * 2015-09-24 2020-04-07 EMC IP Holding Company LLC User authentication with multiple authentication sources and non-binary authentication decisions
US10348709B2 (en) * 2015-09-25 2019-07-09 Mcafee, Llc Cumulative authentication for step-up increased authentication factors
JP6505573B2 (ja) * 2015-10-07 2019-04-24 Kddi株式会社 認証システム、認証サーバ、事業者サーバ及び利用者端末
CN105187450B (zh) * 2015-10-08 2019-05-10 飞天诚信科技股份有限公司 一种基于认证设备进行认证的方法和设备
ES2609836B2 (es) * 2015-10-15 2018-08-16 Universidad Rey Juan Carlos Procedimiento y sistema para la validación de una petición de autenticación/autorización de un usuario
CN105472125B (zh) * 2015-11-16 2019-11-26 联想(北京)有限公司 一种信息处理方法及电子设备
US9819684B2 (en) * 2015-12-04 2017-11-14 Live Nation Entertainment, Inc. Systems and methods for scalable-factor authentication
US11232187B2 (en) * 2016-01-13 2022-01-25 American Express Travel Related Services Company, Inc. Contextual identification and information security
WO2017128756A1 (en) * 2016-01-25 2017-08-03 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for network access
WO2017134632A1 (en) * 2016-02-03 2017-08-10 Averon Us, Inc. Method and apparatus for facilitating frictionless two-factor authentication
JP2017152947A (ja) * 2016-02-25 2017-08-31 京セラ株式会社 携帯端末
CN105721480A (zh) * 2016-03-02 2016-06-29 北京九州云腾科技有限公司 基于fido硬件的用户操作方法及系统
US10693855B1 (en) * 2016-03-31 2020-06-23 EMC IP Holding Company LLC Fraud detection
US10305901B2 (en) * 2016-05-06 2019-05-28 Blackberry Limited System and method for multi-factor authentication
US10523660B1 (en) 2016-05-13 2019-12-31 MobileIron, Inc. Asserting a mobile identity to users and devices in an enterprise authentication system
WO2017197400A1 (en) * 2016-05-13 2017-11-16 Mobile Iron, Inc. Unified vpn and identity based authentication to cloud-based services
JP6570480B2 (ja) * 2016-06-07 2019-09-04 ヤフー株式会社 生成装置、端末装置、生成方法、生成プログラム及び認証処理システム
US10447736B1 (en) * 2016-06-09 2019-10-15 Symantec Corporation Systems and methods for providing security in smart buildings
US10997318B2 (en) 2016-06-10 2021-05-04 OneTrust, LLC Data processing systems for generating and populating a data inventory for processing data access requests
US11625502B2 (en) 2016-06-10 2023-04-11 OneTrust, LLC Data processing systems for identifying and modifying processes that are subject to data subject access requests
US11354435B2 (en) 2016-06-10 2022-06-07 OneTrust, LLC Data processing systems for data testing to confirm data deletion and related methods
US20220035945A1 (en) * 2016-06-10 2022-02-03 OneTrust, LLC Data processing systems for fulfilling data subject access requests and related methods
US11651106B2 (en) 2016-06-10 2023-05-16 OneTrust, LLC Data processing systems for fulfilling data subject access requests and related methods
US11392720B2 (en) 2016-06-10 2022-07-19 OneTrust, LLC Data processing systems for verification of consent and notice processing and related methods
US11586700B2 (en) 2016-06-10 2023-02-21 OneTrust, LLC Data processing systems and methods for automatically blocking the use of tracking tools
US11188615B2 (en) 2016-06-10 2021-11-30 OneTrust, LLC Data processing consent capture systems and related methods
AU2017292796B2 (en) * 2016-07-05 2022-05-12 Idemia Identity & Security USA LLC Communication flow for verification and identification check
US10769635B2 (en) 2016-08-05 2020-09-08 Nok Nok Labs, Inc. Authentication techniques including speech and/or lip movement analysis
US10637853B2 (en) 2016-08-05 2020-04-28 Nok Nok Labs, Inc. Authentication techniques including speech and/or lip movement analysis
US10291609B2 (en) * 2016-08-23 2019-05-14 Reavire, Inc. Vault appliance for identity verification and secure dispatch of rights
US11050758B2 (en) 2016-08-23 2021-06-29 Reavire, Inc. Controlling access to a computer network using measured device location
WO2018051236A1 (en) 2016-09-13 2018-03-22 Silverfort Ltd. Protection of authentication tokens
US10282537B2 (en) * 2016-09-20 2019-05-07 International Business Machines Corporation Single prompt multiple-response user authentication method
US10122706B2 (en) * 2016-10-27 2018-11-06 Ca, Inc. Authenticating identity for password changes
US10789386B2 (en) 2016-11-09 2020-09-29 Reavire, Inc. Dispatching identity information from secure hardware appliance
US11017404B1 (en) * 2016-11-15 2021-05-25 Wells Fargo Bank, N.A. Event based authentication
US20180145984A1 (en) * 2016-11-24 2018-05-24 Rajender Duggal System and method for providing security solutions to protect enterprise critical assets
US10027662B1 (en) * 2016-12-06 2018-07-17 Amazon Technologies, Inc. Dynamic user authentication
US20180167383A1 (en) * 2016-12-12 2018-06-14 Qualcomm Incorporated Integration of password-less authentication systems with legacy identity federation
US10446157B2 (en) 2016-12-19 2019-10-15 Bank Of America Corporation Synthesized voice authentication engine
US10049673B2 (en) * 2016-12-19 2018-08-14 Bank Of America Corporation Synthesized voice authentication engine
CN108243115B (zh) * 2016-12-26 2021-06-29 新华三技术有限公司 报文处理方法及装置
US10091195B2 (en) 2016-12-31 2018-10-02 Nok Nok Labs, Inc. System and method for bootstrapping a user binding
US10237070B2 (en) 2016-12-31 2019-03-19 Nok Nok Labs, Inc. System and method for sharing keys across authenticators
DE102017000768A1 (de) * 2017-01-27 2018-08-02 Giesecke+Devrient Mobile Security Gmbh Verfahren zum Durchführen einer Zweifaktorauthentifizierung
US10977345B2 (en) 2017-02-17 2021-04-13 TwoSesnse, Inc. Authentication session extension using ephemeral behavior detection
JP6581611B2 (ja) * 2017-02-21 2019-09-25 日本電信電話株式会社 認証鍵共有システムおよび認証鍵共有方法
US10565591B2 (en) * 2017-02-23 2020-02-18 Paypal, Inc. Bridge for communicating data outside of a mobile application
CN107172008B (zh) * 2017-04-01 2019-10-18 北京芯盾时代科技有限公司 一种在移动设备中进行多系统认证及同步的系统和方法
US10630668B2 (en) * 2017-04-28 2020-04-21 Amazon Technologies, Inc. Single sign-on registration
US9882918B1 (en) * 2017-05-15 2018-01-30 Forcepoint, LLC User behavior profile in a blockchain
JP6759152B2 (ja) * 2017-05-24 2020-09-23 キヤノン株式会社 画像処理装置、方法、プログラム及びシステム
CN110869928A (zh) * 2017-05-25 2020-03-06 巴克莱服务公司 认证系统和方法
US10462120B2 (en) 2017-05-25 2019-10-29 Barclays Services Corporation Authentication system and method
KR102413638B1 (ko) * 2017-05-30 2022-06-27 삼성에스디에스 주식회사 인증 서비스 시스템 및 방법
ES2862180T3 (es) * 2017-06-01 2021-10-07 Nokia Solutions & Networks Oy Autenticación de usuarios en la red de acceso inalámbrico
EP3643001B1 (en) 2017-06-19 2023-08-02 Silverfort Ltd. Actively monitoring encrypted traffic by inspecting logs
US11544356B2 (en) 2017-06-19 2023-01-03 Citrix Systems, Inc. Systems and methods for dynamic flexible authentication in a cloud service
WO2019014928A1 (zh) * 2017-07-21 2019-01-24 北京小米移动软件有限公司 一种控制可操控设备接入网络的方法及装置
CN107483419B (zh) * 2017-07-28 2020-06-09 深圳市优克联新技术有限公司 服务器认证接入终端的方法、装置、系统、服务器及计算机可读存储介质
EP3665860B1 (en) 2017-08-11 2021-07-21 KOBIL GmbH Multi-factor authentication
US10097538B1 (en) * 2017-08-12 2018-10-09 Growpath, Inc. User authentication systems and methods
US10476870B2 (en) * 2017-08-25 2019-11-12 Microsoft Technology Licensing, Llc Local claim-based security service with cross-browser compatibility
KR102382470B1 (ko) * 2017-08-29 2022-04-04 홈 컨트롤 싱가포르 피티이. 엘티디. 정교한 사용자 인식
CN107395644B (zh) * 2017-09-01 2020-05-12 北京知道创宇信息技术股份有限公司 一种多协议认证系统及方法
WO2019061514A1 (zh) * 2017-09-30 2019-04-04 深圳大学 安全的无线通信物理层斜率认证方法和装置
US11429745B2 (en) * 2017-10-30 2022-08-30 Visa International Service Association Data security hub
US10764270B2 (en) * 2017-11-20 2020-09-01 Allstate Insurance Company Cryptographically transmitting and storing identity tokens and/or activity data among spatially distributed computing devices
US10972468B2 (en) 2017-11-21 2021-04-06 Vmware, Inc. Adaptive device enrollment
US10749870B2 (en) * 2017-11-21 2020-08-18 Vmware, Inc. Adaptive device enrollment
US10986078B2 (en) * 2017-11-21 2021-04-20 Vmware, Inc. Adaptive device enrollment
US10798103B2 (en) 2017-11-21 2020-10-06 VWware, Inc. Adaptive device enrollment
JP7091057B2 (ja) * 2017-11-22 2022-06-27 キヤノン株式会社 情報処理装置、情報処理装置における方法、およびプログラム
US11868995B2 (en) 2017-11-27 2024-01-09 Nok Nok Labs, Inc. Extending a secure key storage for transaction confirmation and cryptocurrency
US11349665B2 (en) * 2017-12-22 2022-05-31 Motorola Solutions, Inc. Device attestation server and method for attesting to the integrity of a mobile device
EP3503492A1 (en) * 2017-12-22 2019-06-26 Deutsche Telekom AG Techniques for establishing data communication based on user identification
US11831409B2 (en) 2018-01-12 2023-11-28 Nok Nok Labs, Inc. System and method for binding verifiable claims
SG10201800338TA (en) * 2018-01-15 2019-08-27 Mastercard International Inc User authentication systems and methods
US11367323B1 (en) 2018-01-16 2022-06-21 Secureauth Corporation System and method for secure pair and unpair processing using a dynamic level of assurance (LOA) score
EP3746928A4 (en) * 2018-02-01 2021-10-13 Equifax, Inc. VERIFICATION OF ACCESS TO SECURE ELECTRONIC EQUIPMENT
US11625473B2 (en) * 2018-02-14 2023-04-11 Samsung Electronics Co., Ltd. Method and apparatus with selective combined authentication
GB2573262B (en) * 2018-03-08 2022-04-13 Benefit Vantage Ltd Mobile identification method based on SIM card and device-related parameters
US10911464B2 (en) * 2018-04-27 2021-02-02 Oracle International Corporation Framework for multi-level and multi-factor inline enrollment
US11328115B2 (en) * 2018-05-10 2022-05-10 Microsoft Technology Licensing, Llc. Self-asserted claims provider
US11240220B2 (en) * 2018-06-13 2022-02-01 Paypal, Inc. Systems and methods for user authentication based on multiple devices
US10546444B2 (en) 2018-06-21 2020-01-28 Capital One Services, Llc Systems and methods for secure read-only authentication
US10911234B2 (en) * 2018-06-22 2021-02-02 Experian Information Solutions, Inc. System and method for a token gateway environment
US11271930B2 (en) 2018-07-02 2022-03-08 Mastercard International Incorporated System architecture and database for context-based authentication
TWI772657B (zh) * 2018-07-05 2022-08-01 聯發科技股份有限公司 用於通用積體電路卡操作的方法及使用者設備
US10993110B2 (en) * 2018-07-13 2021-04-27 Nvidia Corp. Connectionless fast method for configuring Wi-Fi on displayless Wi-Fi IoT device
CN112425132B (zh) * 2018-07-17 2024-02-20 瑞典爱立信有限公司 用于促进订户与服务提供商之间的安全通信的方法和设备
US11100204B2 (en) * 2018-07-19 2021-08-24 Motorola Mobility Llc Methods and devices for granting increasing operational access with increasing authentication factors
WO2020038590A1 (en) 2018-08-20 2020-02-27 Telefonaktiebolaget Lm Ericsson (Publ) First node, second node, third node, and methods performed thereby for managing data in a database in a communications network
US11544409B2 (en) 2018-09-07 2023-01-03 OneTrust, LLC Data processing systems and methods for automatically protecting sensitive data within privacy management systems
KR20210069643A (ko) 2018-10-02 2021-06-11 캐피탈 원 서비시즈, 엘엘씨 비접촉식 카드의 암호화 인증을 위한 시스템 및 방법
US10581611B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072694A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
CA3113101A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072537A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US11210664B2 (en) 2018-10-02 2021-12-28 Capital One Services, Llc Systems and methods for amplifying the strength of cryptographic algorithms
US10489781B1 (en) 2018-10-02 2019-11-26 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10771253B2 (en) 2018-10-02 2020-09-08 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10579998B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10511443B1 (en) 2018-10-02 2019-12-17 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10909527B2 (en) 2018-10-02 2021-02-02 Capital One Services, Llc Systems and methods for performing a reissue of a contactless card
WO2020072583A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for establishing identity for order pick up
US10771254B2 (en) 2018-10-02 2020-09-08 Capital One Services, Llc Systems and methods for email-based card activation
CA3115107A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10565587B1 (en) 2018-10-02 2020-02-18 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10949520B2 (en) 2018-10-02 2021-03-16 Capital One Services, Llc Systems and methods for cross coupling risk analytics and one-time-passcodes
US10607214B1 (en) 2018-10-02 2020-03-31 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
KR20210065961A (ko) 2018-10-02 2021-06-04 캐피탈 원 서비시즈, 엘엘씨 비접촉식 카드의 암호화 인증을 위한 시스템 및 방법
US10592710B1 (en) 2018-10-02 2020-03-17 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072552A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
CA3108917A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10783519B2 (en) 2018-10-02 2020-09-22 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10554411B1 (en) 2018-10-02 2020-02-04 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10542036B1 (en) 2018-10-02 2020-01-21 Capital One Services, Llc Systems and methods for signaling an attack on contactless cards
AU2019355110A1 (en) 2018-10-02 2021-04-08 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10582386B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
AU2019351906A1 (en) 2018-10-02 2021-03-18 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10505738B1 (en) 2018-10-02 2019-12-10 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072529A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072440A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US11822637B2 (en) * 2018-10-18 2023-11-21 Oracle International Corporation Adaptive authentication in spreadsheet interface integrated with web service
WO2020092131A1 (en) * 2018-10-30 2020-05-07 Valimail Inc. Signed message header storing sender account authentication method
US11159517B2 (en) * 2018-11-21 2021-10-26 Citrix Systems, Inc. Self-federation in authentication systems
US11227036B1 (en) * 2018-11-27 2022-01-18 Amazon Technologies, Inc. Determination of authentication assurance via algorithmic decay
US11233788B1 (en) * 2018-11-27 2022-01-25 Amazon Technologies, Inc. Determining authentication assurance from historical and runtime-provided inputs
US10958661B2 (en) * 2018-11-28 2021-03-23 Bank Of America Corporation Multi-layer authentication system with selective level access control
US20200220948A1 (en) * 2019-01-04 2020-07-09 Byton North America Corporation Unique id for correlating services across regions
WO2020144518A1 (en) * 2019-01-10 2020-07-16 Silverfort Ltd. Using virtual tokens to extend authentication protocols
US11361302B2 (en) 2019-01-11 2022-06-14 Capital One Services, Llc Systems and methods for touch screen interface interaction using a card overlay
US11037136B2 (en) 2019-01-24 2021-06-15 Capital One Services, Llc Tap to autofill card data
US11451532B2 (en) * 2019-01-25 2022-09-20 Dell Products L.P. Behavioral biometrics and machine learning to secure website logins
US10467622B1 (en) 2019-02-01 2019-11-05 Capital One Services, Llc Using on-demand applications to generate virtual numbers for a contactless card to securely autofill forms
US10510074B1 (en) 2019-02-01 2019-12-17 Capital One Services, Llc One-tap payment using a contactless card
US11120453B2 (en) 2019-02-01 2021-09-14 Capital One Services, Llc Tap card to securely generate card data to copy to clipboard
KR20200100481A (ko) * 2019-02-18 2020-08-26 삼성전자주식회사 생체 정보를 인증하기 위한 전자 장치 및 그의 동작 방법
US10425129B1 (en) 2019-02-27 2019-09-24 Capital One Services, Llc Techniques to reduce power consumption in near field communication systems
US10523708B1 (en) 2019-03-18 2019-12-31 Capital One Services, Llc System and method for second factor authentication of customer support calls
US11531736B1 (en) 2019-03-18 2022-12-20 Amazon Technologies, Inc. User authentication as a service
US10535062B1 (en) 2019-03-20 2020-01-14 Capital One Services, Llc Using a contactless card to securely share personal data stored in a blockchain
US10984416B2 (en) 2019-03-20 2021-04-20 Capital One Services, Llc NFC mobile currency transfer
US10438437B1 (en) 2019-03-20 2019-10-08 Capital One Services, Llc Tap to copy data to clipboard via NFC
US10643420B1 (en) 2019-03-20 2020-05-05 Capital One Services, Llc Contextual tapping engine
US10970712B2 (en) 2019-03-21 2021-04-06 Capital One Services, Llc Delegated administration of permissions using a contactless card
US10467445B1 (en) 2019-03-28 2019-11-05 Capital One Services, Llc Devices and methods for contactless card alignment with a foldable mobile device
US11792024B2 (en) 2019-03-29 2023-10-17 Nok Nok Labs, Inc. System and method for efficient challenge-response authentication
CN110138736B (zh) * 2019-04-11 2022-05-13 泉州信息工程学院 物联网多重动态随机加密的身份认证方法和装置及设备
US20200344599A1 (en) * 2019-04-29 2020-10-29 Sonicwall Inc. Streamlined creation and expansion of a wireless mesh network
US11521262B2 (en) 2019-05-28 2022-12-06 Capital One Services, Llc NFC enhanced augmented reality information overlays
US10516447B1 (en) 2019-06-17 2019-12-24 Capital One Services, Llc Dynamic power levels in NFC card communications
US11392933B2 (en) 2019-07-03 2022-07-19 Capital One Services, Llc Systems and methods for providing online and hybridcard interactions
US11694187B2 (en) 2019-07-03 2023-07-04 Capital One Services, Llc Constraining transactional capabilities for contactless cards
US10871958B1 (en) 2019-07-03 2020-12-22 Capital One Services, Llc Techniques to perform applet programming
US11336682B2 (en) * 2019-07-09 2022-05-17 Nice Ltd. System and method for generating and implementing a real-time multi-factor authentication policy across multiple channels
US10713649B1 (en) 2019-07-09 2020-07-14 Capital One Services, Llc System and method enabling mobile near-field communication to update display on a payment card
US11265305B2 (en) * 2019-07-12 2022-03-01 International Business Machines Corporation Managing anonymous network connections
US10498401B1 (en) 2019-07-15 2019-12-03 Capital One Services, Llc System and method for guiding card positioning using phone sensors
US10885514B1 (en) 2019-07-15 2021-01-05 Capital One Services, Llc System and method for using image data to trigger contactless card transactions
US11182771B2 (en) 2019-07-17 2021-11-23 Capital One Services, Llc System for value loading onto in-vehicle device
US10832271B1 (en) 2019-07-17 2020-11-10 Capital One Services, Llc Verified reviews using a contactless card
US10733601B1 (en) 2019-07-17 2020-08-04 Capital One Services, Llc Body area network facilitated authentication or payment authorization
US11521213B2 (en) 2019-07-18 2022-12-06 Capital One Services, Llc Continuous authentication for digital services based on contactless card positioning
US10506426B1 (en) 2019-07-19 2019-12-10 Capital One Services, Llc Techniques for call authentication
US10862689B1 (en) * 2019-07-23 2020-12-08 Cyberark Software Ltd. Verification of client identities based on non-distributed data
US10541995B1 (en) 2019-07-23 2020-01-21 Capital One Services, Llc First factor contactless card authentication system and method
US20220224692A1 (en) * 2019-07-31 2022-07-14 Coronet Cyber Security Ltd. Multi factor authentication
US11096059B1 (en) 2019-08-04 2021-08-17 Acceptto Corporation System and method for secure touchless authentication of user paired device, behavior and identity
US20210056193A1 (en) * 2019-08-20 2021-02-25 Microsoft Technology Licensing, Llc Permitted authentication types for account access
CA3153291A1 (en) 2019-10-02 2021-04-08 Evan Lerner Client device authentication using contactless legacy magnetic stripe data
JP7367443B2 (ja) * 2019-10-09 2023-10-24 富士通株式会社 本人確認プログラム、管理装置及び本人確認方法
US11171945B2 (en) 2019-10-16 2021-11-09 Capital One Services, Llc Time-based token trust depreciation
US10685137B1 (en) * 2019-10-16 2020-06-16 Capital One Services, Llc Methods and systems for leveraging existing user data to verify user credentials
US11722481B2 (en) * 2019-10-31 2023-08-08 Citrix Systems, Inc. Multiple identity provider authentication system
US10951606B1 (en) * 2019-12-04 2021-03-16 Acceptto Corporation Continuous authentication through orchestration and risk calculation post-authorization system and method
EP3840322A1 (en) * 2019-12-20 2021-06-23 Thales Dis France Sa Method to facilitate user authenticating in a wireless network
US10885410B1 (en) 2019-12-23 2021-01-05 Capital One Services, Llc Generating barcodes utilizing cryptographic techniques
US10862540B1 (en) 2019-12-23 2020-12-08 Capital One Services, Llc Method for mapping NFC field strength and location on mobile devices
US10657754B1 (en) 2019-12-23 2020-05-19 Capital One Services, Llc Contactless card and personal identification system
US11651361B2 (en) 2019-12-23 2023-05-16 Capital One Services, Llc Secure authentication based on passport data stored in a contactless card
US11615395B2 (en) 2019-12-23 2023-03-28 Capital One Services, Llc Authentication for third party digital wallet provisioning
US10733283B1 (en) 2019-12-23 2020-08-04 Capital One Services, Llc Secure password generation and management using NFC and contactless smart cards
US11113685B2 (en) 2019-12-23 2021-09-07 Capital One Services, Llc Card issuing with restricted virtual numbers
US10664941B1 (en) 2019-12-24 2020-05-26 Capital One Services, Llc Steganographic image encoding of biometric template information on a card
US10853795B1 (en) 2019-12-24 2020-12-01 Capital One Services, Llc Secure authentication based on identity data stored in a contactless card
US11200563B2 (en) 2019-12-24 2021-12-14 Capital One Services, Llc Account registration using a contactless card
US10909544B1 (en) 2019-12-26 2021-02-02 Capital One Services, Llc Accessing and utilizing multiple loyalty point accounts
US10757574B1 (en) 2019-12-26 2020-08-25 Capital One Services, Llc Multi-factor authentication providing a credential via a contactless card for secure messaging
US11038688B1 (en) 2019-12-30 2021-06-15 Capital One Services, Llc Techniques to control applets for contactless cards
US11455620B2 (en) 2019-12-31 2022-09-27 Capital One Services, Llc Tapping a contactless card to a computing device to provision a virtual number
US10860914B1 (en) 2019-12-31 2020-12-08 Capital One Services, Llc Contactless card and method of assembly
CN111091387A (zh) * 2019-12-31 2020-05-01 中国银行股份有限公司 一种认证方法、装置及系统
US11258779B2 (en) 2020-01-14 2022-02-22 Cisco Technology, Inc. Wireless LAN (WLAN) public identity federation trust architecture
CN111404933B (zh) * 2020-03-16 2022-04-15 维沃移动通信有限公司 鉴权方法、电子设备及鉴权服务器
TWI768307B (zh) * 2020-03-18 2022-06-21 傑睿資訊服務股份有限公司 開源軟體整合方法
US11210656B2 (en) 2020-04-13 2021-12-28 Capital One Services, Llc Determining specific terms for contactless card activation
US10861006B1 (en) 2020-04-30 2020-12-08 Capital One Services, Llc Systems and methods for data access control using a short-range transceiver
US11030339B1 (en) 2020-04-30 2021-06-08 Capital One Services, Llc Systems and methods for data access control of personal user data using a short-range transceiver
US11222342B2 (en) 2020-04-30 2022-01-11 Capital One Services, Llc Accurate images in graphical user interfaces to enable data transfer
US11823175B2 (en) 2020-04-30 2023-11-21 Capital One Services, Llc Intelligent card unlock
US10915888B1 (en) 2020-04-30 2021-02-09 Capital One Services, Llc Contactless card with multiple rotating security keys
US10963865B1 (en) 2020-05-12 2021-03-30 Capital One Services, Llc Augmented reality card activation experience
US11100511B1 (en) 2020-05-18 2021-08-24 Capital One Services, Llc Application-based point of sale system in mobile operating systems
US11063979B1 (en) 2020-05-18 2021-07-13 Capital One Services, Llc Enabling communications between applications in a mobile operating system
US20210377051A1 (en) * 2020-05-26 2021-12-02 Motorola Solutions, Inc. Method of establishing a future 2-way authentication between a client application and an application server
US20210385183A1 (en) * 2020-06-06 2021-12-09 Fortinet, Inc. Multi-factor authentication for accessing an electronic mail
CA3185242A1 (en) * 2020-07-08 2022-01-13 James A. Austin Peer-to-peer secure communication system, apparatus, and method
US11797528B2 (en) 2020-07-08 2023-10-24 OneTrust, LLC Systems and methods for targeted data discovery
TWI759968B (zh) * 2020-08-06 2022-04-01 美商動信安全股份有限公司 安全金鑰裝置、安全認證系統以及安全認證方法
US11062098B1 (en) 2020-08-11 2021-07-13 Capital One Services, Llc Augmented reality information display and interaction via NFC based authentication
FR3113753B1 (fr) * 2020-08-25 2023-05-12 Idemia France Procédé de vérification d’une carte à microcircuit, procédé de personnalisation d’une carte à microcircuit, carte à microcircuit et dispositif électronique associé
US11329998B1 (en) 2020-08-31 2022-05-10 Secureauth Corporation Identification (ID) proofing and risk engine integration system and method
US20220109671A1 (en) * 2020-10-07 2022-04-07 Arris Enterprises Llc Biometrics based access controls for network features
US11165586B1 (en) 2020-10-30 2021-11-02 Capital One Services, Llc Call center web-based authentication using a contactless card
US11482312B2 (en) 2020-10-30 2022-10-25 Capital One Services, Llc Secure verification of medical status using a contactless card
US11373169B2 (en) 2020-11-03 2022-06-28 Capital One Services, Llc Web-based activation of contactless cards
US11216799B1 (en) 2021-01-04 2022-01-04 Capital One Services, Llc Secure generation of one-time passcodes using a contactless card
WO2022159901A1 (en) 2021-01-25 2022-07-28 OneTrust, LLC Systems and methods for discovery, classification, and indexing of data in a native computing system
US11682012B2 (en) 2021-01-27 2023-06-20 Capital One Services, Llc Contactless delivery systems and methods
US11562358B2 (en) 2021-01-28 2023-01-24 Capital One Services, Llc Systems and methods for near field contactless card communication and cryptographic authentication
US11792001B2 (en) 2021-01-28 2023-10-17 Capital One Services, Llc Systems and methods for secure reprovisioning
US11687930B2 (en) 2021-01-28 2023-06-27 Capital One Services, Llc Systems and methods for authentication of access tokens
US11438329B2 (en) 2021-01-29 2022-09-06 Capital One Services, Llc Systems and methods for authenticated peer-to-peer data transfer using resource locators
US11777933B2 (en) 2021-02-03 2023-10-03 Capital One Services, Llc URL-based authentication for payment cards
WO2022178089A1 (en) 2021-02-17 2022-08-25 OneTrust, LLC Managing custom workflows for domain objects defined within microservices
US11637826B2 (en) 2021-02-24 2023-04-25 Capital One Services, Llc Establishing authentication persistence
US11245438B1 (en) 2021-03-26 2022-02-08 Capital One Services, Llc Network-enabled smart apparatus and systems and methods for activating and provisioning same
US11621957B2 (en) 2021-03-31 2023-04-04 Cisco Technology, Inc. Identity verification for network access
US11961089B2 (en) 2021-04-20 2024-04-16 Capital One Services, Llc On-demand applications to extend web services
US11935035B2 (en) 2021-04-20 2024-03-19 Capital One Services, Llc Techniques to utilize resource locators by a contactless card to perform a sequence of operations
US11902442B2 (en) 2021-04-22 2024-02-13 Capital One Services, Llc Secure management of accounts on display devices using a contactless card
US11354555B1 (en) 2021-05-04 2022-06-07 Capital One Services, Llc Methods, mediums, and systems for applying a display to a transaction card
US11855979B2 (en) 2021-05-28 2023-12-26 Microsoft Technology Licensing, Llc Proxy configured to dynamically failover authentication traffic to a backup authentication system
US20220385660A1 (en) * 2021-05-28 2022-12-01 Microsoft Technology Licensing, Llc Client device capable of dynamically routing authentication requests to a backup authentication system
KR102577882B1 (ko) * 2021-06-03 2023-09-12 중부대학교 산학협력단 쌍토큰을 이용한 tls 세션 복구 방법
US11968242B2 (en) 2021-07-01 2024-04-23 Cisco Technology, Inc. Differentiated service in a federation-based access network
JPWO2023062809A1 (ja) * 2021-10-15 2023-04-20
US20230198973A1 (en) * 2021-12-16 2023-06-22 Microsoft Technology Licensing, Llc Service to service authentication in computing systems
JP7466807B2 (ja) 2022-02-10 2024-04-12 三菱電機株式会社 負荷特定装置、負荷特定方法及び負荷特定プログラム
TWI824517B (zh) * 2022-05-12 2023-12-01 技嘉科技股份有限公司 身分驗證方法及身分驗證系統
KR102654983B1 (ko) * 2023-12-29 2024-04-05 한국과학기술정보연구원 다요소 인증 방법 및 시스템

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6321339B1 (en) * 1998-05-21 2001-11-20 Equifax Inc. System and method for authentication of network users and issuing a digital certificate
JP2003091509A (ja) * 2001-09-17 2003-03-28 Nec Corp 携帯通信機器の個人認証方法およびそれを記述したプログラム
US20030115142A1 (en) * 2001-12-12 2003-06-19 Intel Corporation Identity authentication portfolio system
JP2003248661A (ja) * 2002-02-25 2003-09-05 Sony Corp 認証処理装置および認証処理方法、情報処理装置および情報処理方法、認証処理システム、記録媒体、並びにプログラム
US20040039909A1 (en) * 2002-08-22 2004-02-26 David Cheng Flexible authentication with multiple levels and factors
US7207058B2 (en) * 2002-12-31 2007-04-17 American Express Travel Related Services Company, Inc. Method and system for transmitting authentication context information
US20050177724A1 (en) * 2004-01-16 2005-08-11 Valiuddin Ali Authentication system and method
KR20060131169A (ko) * 2005-06-15 2006-12-20 삼성전자주식회사 통신 시스템에서 인증 수행 시스템 및 방법
JP4684100B2 (ja) * 2005-12-26 2011-05-18 株式会社日立製作所 認証システムおよび認証方法
US7966489B2 (en) * 2006-08-01 2011-06-21 Cisco Technology, Inc. Method and apparatus for selecting an appropriate authentication method on a client
JP2008117326A (ja) * 2006-11-08 2008-05-22 Fuji Xerox Co Ltd サービス利用認可システム、コンテンツ利用認可システム、サービス利用認可プログラム、コンテンツ利用認可プログラムおよびサービス利用認可方法
CN100530213C (zh) * 2006-11-08 2009-08-19 华为技术有限公司 一种确定生物认证系统的安全级别的方法和设备
US8978117B2 (en) * 2007-11-19 2015-03-10 Avaya Inc. Authentication frequency and challenge type based on environmental and physiological properties
US9122895B2 (en) * 2008-06-25 2015-09-01 Microsoft Technology Licensing, Llc Authorization for transient storage devices with multiple authentication silos
JP2010067124A (ja) * 2008-09-12 2010-03-25 Nec Corp 認証管理装置および認証管理方法ならびにそのプログラム
JP5459583B2 (ja) * 2009-03-25 2014-04-02 日本電気株式会社 認証方法及びその認証システム並びにその認証処理プログラム
CN101853360A (zh) * 2009-04-02 2010-10-06 同方股份有限公司 一种用于移动存储设备的认证系统
JP2011145906A (ja) * 2010-01-15 2011-07-28 Hitachi Omron Terminal Solutions Corp 取引処理装置および取引処理方法
US8756650B2 (en) * 2010-03-15 2014-06-17 Broadcom Corporation Dynamic authentication of a user
US8839346B2 (en) * 2010-07-21 2014-09-16 Citrix Systems, Inc. Systems and methods for providing a smart group
WO2012149384A1 (en) * 2011-04-28 2012-11-01 Interdigital Patent Holdings, Inc. Sso framework for multiple sso technologies
CN102780674A (zh) * 2011-05-09 2012-11-14 同方股份有限公司 一种具有多因素认证方法的网络业务处理方法及系统
US8914636B2 (en) * 2011-06-28 2014-12-16 Interdigital Patent Holdings, Inc. Automated negotiation and selection of authentication protocols
EP2725835A1 (en) * 2012-10-24 2014-04-30 Gemalto SA Method for authenticating a user
US20140157401A1 (en) * 2012-11-30 2014-06-05 Motorola Mobility Llc Method of Dynamically Adjusting an Authentication Sensor
WO2014093613A1 (en) * 2012-12-12 2014-06-19 Interdigital Patent Holdings, Inc. Independent identity management systems
US9172687B2 (en) * 2012-12-28 2015-10-27 Nok Nok Labs, Inc. Query system and method to determine authentication capabilities
US9219732B2 (en) * 2012-12-28 2015-12-22 Nok Nok Labs, Inc. System and method for processing random challenges within an authentication framework
GB2510120A (en) * 2013-01-24 2014-07-30 Ibm User authentication based on dynamically selected service authentication levels
US10270748B2 (en) * 2013-03-22 2019-04-23 Nok Nok Labs, Inc. Advanced authentication techniques and applications
US9426183B2 (en) * 2013-07-28 2016-08-23 Acceptto Corporation Authentication policy orchestration for a user device
US9444824B1 (en) * 2014-02-28 2016-09-13 Intuit Inc. Methods, systems, and articles of manufacture for implementing adaptive levels of assurance in a financial management system

Also Published As

Publication number Publication date
EP2989770A1 (en) 2016-03-02
JP2016525807A (ja) 2016-08-25
WO2014176539A1 (en) 2014-10-30
TW201541977A (zh) 2015-11-01
KR101924683B1 (ko) 2018-12-03
CN105144656A (zh) 2015-12-09
US20160087957A1 (en) 2016-03-24
KR20160004363A (ko) 2016-01-12

Similar Documents

Publication Publication Date Title
JP6307593B2 (ja) 必要とされる認証保証レベルを達成するための多要素認証
US20170374070A1 (en) Scalable policy based execution of multi-factor authentication
US9237142B2 (en) Client and server group SSO with local openID
JP5540119B2 (ja) トラステッド連合アイデンティティのための方法および装置
EP2702745B1 (en) Sso framework for multiple sso technologies
KR101670973B1 (ko) 무선 유닛의 사용자를 인증하는 방법들 및 시스템들
US20150319156A1 (en) Independent identity management systems
US10044713B2 (en) OpenID/local openID security
US9467429B2 (en) Identity management with generic bootstrapping architecture
US20160050234A1 (en) Seamless authentication across multiple entities
JP2018525722A (ja) リソース駆動動的承認フレームワーク
US20180013782A1 (en) Continuous device/uicc based authentication for lte systems
TW201225697A (en) Identity management on a wireless device

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170220

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170228

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20170531

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170831

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180109

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20180208

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180312

R150 Certificate of patent or registration of utility model

Ref document number: 6307593

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees