(57)【要約】【課題】ＩＤプロバイダ（４０）を利用して要求側エンティティ（５０）にＩＤ関連情報（ＩＲＩ）を提供する方法を提供すること。【解決手段】本発明は、ＩＤプロバイダ（４０）による第１の真正性リファレンス部（ａｒｔ１）の生成を備える、第１の真正性リファレンス部生成ステップ（ＩＶａ）と、真正性リファレンス部（ａｒｔ１）の通信を備える、クライアント・アプリケーション（３０）とＩＤプロバイダ（４０）との間の第１の真正性リファレンス通信ステップ（ＩＶｂ、ＩＶｄ）と、ＩＤプロバイダ（４０）による第２の真正性リファレンス部（ａｒｔ２）の生成を備える、第２の真正性リファレンス部生成ステップ（ＶＩ）と、第２の真正性リファレンス部（ａｒｔ２）の通信と、リファラ要素での第１の真正性リファレンス部（ａｒｔ１）の通信とを備える、第１の通信プロトコルを用いたＩＤプロバイダ（４０）と要求側エンティティ（５０）との間の第２の真正性リファレンス通信ステップ（ＶＩＩＩ、ＩＸ）と、を備える。【選択図】図１
2009521046.tif 000002
【特許請求の範囲】
【請求項１】
ＩＤプロバイダ（４０）を利用してＩＤ関連情報（ＩＲＩ）を要求側エンティティ（５０）に提供する方法であって、ユーザと前記要求側エンティティ（５０）および前記ＩＤプロバイダ（４０）との通信のためにクライアント・アプリケーション（３０）が提供され、前記クライアント・アプリケーション（３０）は、第１の通信プロトコルを使用し、前記第１の通信プロトコルは、リファラ機能を備え、当該リファラ機能により、通信メッセージは、少なくとも１回の以前の通信ステップについての情報を有するリファラ要素を備えることができ、前記方法は、
前記ユーザを前記ＩＤプロバイダ（４０）に対して認証することと、
前記ＩＤプロバイダ（４０）による第１の真正性リファレンス部（ａｒｔ１）の生成を備える、第１の真正性リファレンス部生成ステップ（ＩＶａ）と、
前記真正性リファレンス部（ａｒｔ１）の通信を備える、前記クライアント・アプリケーション（３０）と前記ＩＤプロバイダ（４０）との間の第１の真正性リファレンス通信ステップ（ＩＶｂ、ＩＶｄ）と、
前記ＩＤプロバイダ（４０）による第２の真正性リファレンス部（ａｒｔ２）の生成を備える、第２の真正性リファレンス部生成ステップ（ＶＩ）と、
前記第２の真正性リファレンス部（ａｒｔ２）の通信と、前記リファラ要素での前記第１の真正性リファレンス部（ａｒｔ１）の通信とを備える、前記第１の通信プロトコルを用いた前記ＩＤプロバイダ（４０）と前記要求側エンティティ（５０）との間の第２の真正性リファレンス通信ステップ（ＶＩＩＩ、ＩＸ）と、
前記要求側エンティティ（５０）が前記第１（ａｒｔ１）および前記第２（ａｒｔ２）の真正性リファレンス部、または前記第１（ａｒｔ１）および前記第２（ａｒｔ２）の真正性リファレンス部のセキュアな関数（ａｒｔ）を前記ＩＤプロバイダ（４０）に送信する要求ステップ（Ｘ）と、
前記ＩＤプロバイダが前記ＩＤ関連情報（ＩＲＩ）を前記要求側エンティティ（５０）に送信する応答ステップ（ＸＩＩＩ）と
を備える方法。
【請求項２】
前記方法は、前記第１の通信プロトコルを用いて前記要求側エンティティ（５０）から前記クライアント・アプリケーション（３０）に結果を通信する結果ステップ（ＸＩＶ）を備える請求項１に記載の方法。
【請求項３】
前記第１の通信プロトコルは、ブラウザ・プロトコル、詳細にはＨＴＴＰ（ハイパー・テキスト転送プロトコル）である請求項１または２に記載の方法。
【請求項４】
前記第１の真正性リファレンス通信ステップ（ＩＶｂ、ＩＶｄ）、第２の真正性リファレンス通信ステップ（ＶＩＩＩ、ＩＸ）、または結果ステップ（ＸＩＶ）、あるいはそのすべては、セキュアな通信路、詳細にはサーバ認証を伴うセキュアな通信路を介して行われる請求項１ないし３のいずれか一項に記載の方法。
【請求項５】
前記第２の真正性リファレンス通信ステップ（ＶＩＩＩ、ＩＸ）は、前記クライアント・アプリケーション（３０）を介して前記ＩＤプロバイダ（４０）を前記要求側エンティティ（５０）にリダイレクトするリダイレクト・ステップである請求項１ないし４のいずれか一項に記載の方法。
【請求項６】
前記リダイレクト・ステップ（ＶＩＩＩ、ＩＸ）は、第１（ＶＩＩＩ）および第２（ＩＸ）のリダイレクト下位ステップを備え、前記ＩＤプロバイダ（４０）は、前記第１のリダイレクト下位ステップ（ＶＩＩＩ）で、リダイレクト・アドレスを伴うリダイレクト・コマンドを前記クライアント・アプリケーション（３０）に送信し、前記リダイレクト・アドレスは、前記第２の真正性リファレンス部（ａｒｔ２）を備え、前記クライアント・アプリケーション（３０）は、前記第２のリダイレクト下位ステップ（ＩＸ）で、前記第２の真正性リファレンス部（ａｒｔ２）と、前記リファラ要素中に前記第１の真正性リファレンス部（ａｒｔ１）とを伴うリダイレクト・アドレスを備えるＧＥＴ要求を前記要求側エンティティ（５０）に送信する請求項５に記載の方法。
【請求項７】
前記要求ステップ（Ｘ）および前記応答ステップ（ＸＩＶ）は、第２の通信プロトコル、詳細にはＳＡＭＬ（セキュリティ・アサーション・マークアップ言語）を使用する請求項１ないし６のいずれか一項に記載の方法。
【請求項８】
前記要求ステップ（Ｘ）および前記応答ステップ（ＸＩＶ）は、相互認証を伴うセキュアな通信路を介して行われる請求項１ないし７のいずれか一項に記載の方法。
【請求項９】
前記セキュアな関数は、ＸＯＲ関数、擬似ランダム関数、ハッシュ関数、暗号化関数、または秘密共有関数である請求項１ないし８のいずれか一項に記載の方法。
【請求項１０】
前記第１の真正性リファレンス通信ステップ（ＩＶｂ、ＩＶｄ）は、前記ＩＤプロバイダ（４０）が前記第１の真正性リファレンス部（ａｒｔ１）を前記クライアント・アプリケーション（３０）に送信する下位ステップ（ＩＶｂ）と、前記クライアント・アプリケーション（３０）が認証および前記第１の真正性リファレンス部（ａｒｔ１）を前記ＩＤプロバイダ（４０）に送信する、それに続く下位ステップ（ＩＶｄ）とを備える請求項１ないし９のいずれか一項に記載の方法。
【請求項１１】
ＩＤ関連情報（ＩＲＩ）を所有するＩＤプロバイダ（４０）から前記ＩＤ関連情報（ＩＲＩ）を受信する方法であって、クライアント・アプリケーション（３０）のユーザおよび前記ＩＤプロバイダ（４０）との通信のために第１の通信プロトコルが提供され、前記第１の通信プロトコルは、リファラ機能を備え、当該リファラ機能により、通信メッセージは、少なくとも１回の以前の通信ステップについての情報を有するリファラ要素を備えることができ、前記方法は、
前記第１の通信プロトコルを使用して、第２の真正性リファレンス部（ａｒｔ２）と、前記リファラ要素で第１の真正性リファレンス部（ａｒｔ１）とを前記ＩＤプロバイダ（４０）から受信することと、
前記第１（ａｒｔ１）および前記第２（ａｒｔ２）の真正性リファレンス部、または前記第１（ａｒｔ１）および前記第２（ａｒｔ２）の真正性リファレンス部のセキュアな関数（ａｒｔ）を前記ＩＤプロバイダ（４０）に送信することと、
前記ＩＤプロバイダ（４０）から前記ＩＤ関連情報（ＩＲＩ）を受信することと
を備える方法。
【請求項１２】
要求側エンティティ（５０）にＩＤ関連情報（ＩＲＩ）を提供する方法であって、クライアント・アプリケーション（３０）のユーザおよび前記ＩＤ関連情報（ＩＲＩ）を要求する前記要求側エンティティ（５０）との通信のために第１の通信プロトコルが提供され、前記第１の通信プロトコルは、リファラ機能を備え、当該リファラ機能により、通信メッセージは、少なくとも１回の以前の通信ステップについての情報を有するリファラ要素を備えることができ、前記方法は、
第１の真正性リファレンス部（ａｒｔ１）を生成することと、
前記第１の真正性リファレンス部（ａｒｔ１）を前記クライアント・アプリケーション（３０）に通信することと、
第２の真正性リファレンス部（ａｒｔ２）を生成することと、
前記第１の通信プロトコルを使用して、前記第２の真正性リファレンス部（ａｒｔ２）と、前記リファラ要素で前記第１の真正性リファレンス部（ａｒｔ１）とを前記要求側エンティティ（５０）に通信することと、
前記要求側エンティティ（５０）から、前記第１（ａｒｔ１）および前記第２（ａｒｔ２）の真正性リファレンス部、または前記第１（ａｒｔ１）および前記第２（ａｒｔ２）の真正性リファレンス部のセキュアな関数（ａｒｔ）を受信することと、
前記ＩＤ関連情報（ＩＲＩ）を伴う応答を前記要求側エンティティ（５０）に送信することと
を備える方法。
【請求項１３】
コンピュータ・システムで実行されると、請求項１ないし１２のいずれか一項に記載の方法のステップを実施する命令を備えたコンピュータ・プログラム。
【請求項１４】
ＩＤ関連情報（ＩＲＩ）を所有するＩＤプロバイダ（４０）から前記ＩＤ関連情報（ＩＲＩ）を受信する要求側エンティティ（５０）であって、前記要求側エンティティ（５０）は、クライアント・アプリケーション（３０）のユーザと、第１の通信プロトコルを使用して通信するように適合され、前記第１の通信プロトコルは、リファラ機能を備え、当該リファラ機能により、通信メッセージは、少なくとも１回の以前の通信ステップについての情報を有するリファラ要素を備えることができ、前記要求側エンティティ（５０）は、
前記第１の通信プロトコルを使用して、第２の真正性リファレンス部（ａｒｔ２）と、前記リファラ要素で第１の真正性リファレンス部（ａｒｔ１）とを前記ＩＤプロバイダ（４０）から受信するステップと、
前記第１（ａｒｔ１）および前記第２（ａｒｔ２）の真正性リファレンス部、または前記第１（ａｒｔ１）および前記第２（ａｒｔ２）の真正性リファレンス部のセキュアな関数（ａｒｔ）を前記ＩＤプロバイダ（４０）に送信するステップと、
前記ＩＤプロバイダ（４０）から前記ＩＤ関連情報（ＩＲＩ）を受信するステップと
を行うように適合される要求側エンティティ（５０）。
【請求項１５】
要求側エンティティ（５０）にＩＤ関連情報（ＩＲＩ）を提供するＩＤプロバイダ（４０）であって、前記ＩＤプロバイダ（４０）は、クライアント・アプリケーション（３０）のユーザと、第１の通信プロトコルを使用して通信するように適合され、前記第１の通信プロトコルは、リファラ機能を備え、当該リファラ機能により、通信メッセージは、少なくとも１回の以前の通信ステップについての情報を有するリファラ要素を備えることができ、
前記ＩＤプロバイダ（４０）は、
第１の真正性リファレンス部（ａｒｔ１）を生成するステップと、
前記第１の真正性リファレンス部（ａｒｔ１）を前記クライアント・アプリケーション（３０）に通信するステップと、
第２の真正性リファレンス部（ａｒｔ２）を生成するステップと、
前記第１の通信プロトコルを使用して、前記第２の真正性リファレンス部（ａｒｔ２）と、前記リファラ要素で前記第１の真正性リファレンス部（ａｒｔ１）とを前記要求側エンティティ（５０）に通信するステップと、
前記要求側エンティティ（５０）から、前記第１（ａｒｔ１）および前記第２（ａｒｔ２）の真正性リファレンス部、または前記第１（ａｒｔ１）および前記第２（ａｒｔ２）の真正性リファレンス部のセキュアな関数（ａｒｔ）を受信するステップと、
前記ＩＤ関連情報（ＩＲＩ）を伴う応答を前記要求側エンティティ（５０）に送信するステップと
を行うように適合されるＩＤプロバイダ（４０）。
【請求項１６】
ＩＤプロバイダ（４０）を利用してＩＤ関連情報（ＩＲＩ）を要求側エンティティ（５０）に提供するシステムであって、ユーザと前記要求側エンティティ（５０）および前記ＩＤプロバイダ（４０）との通信のためにクライアント・アプリケーション（３０）が提供され、前記クライアント・アプリケーション（３０）は、第１の通信プロトコルを使用し、前記第１の通信プロトコルは、リファラ機能を備え、当該リファラ機能により、通信メッセージは、少なくとも１回の以前の通信ステップについての情報を有するリファラ要素を備えることができ、前記システムは、
前記ユーザを前記ＩＤプロバイダ（４０）に対して認証するステップと、
前記ＩＤプロバイダ（４０）による第１の真正性リファレンス部（ａｒｔ１）の生成を備える、第１の真正性リファレンス部生成ステップ（ＩＶａ）と、
前記第１の真正性リファレンス部（ａｒｔ１）の通信を備える、前記クライアント・アプリケーション（３０）と前記ＩＤプロバイダ（４０）との間の第１の真正性リファレンス通信ステップ（ＩＶｂ、ＩＶｄ）と、
前記ＩＤプロバイダ（４０）による第２の真正性リファレンス部（ａｒｔ２）の生成を備える、第２の真正性リファレンス部生成ステップ（ＶＩ）と、
前記第２の真正性リファレンス部（ａｒｔ２）の通信と前記リファラ要素での前記第１の真正性リファレンス部（ａｒｔ１）の通信とを備える、前記第１の通信プロトコルを用いた前記ＩＤプロバイダ（４０）と前記要求側エンティティ（５０）との間の第２の真正性リファレンス通信ステップ（ＶＩＩＩ、ＩＸ）と、
前記要求側エンティティ（５０）が前記第１（ａｒｔ１）および前記第２（ａｒｔ２）の真正性リファレンス部、または前記第１（ａｒｔ１）および前記第２（ａｒｔ２）の真正性リファレンス部のセキュアな関数（ａｒｔ）を前記ＩＤプロバイダ（４０）に送信する要求ステップ（Ｘ）と、
前記ＩＤプロバイダが前記ＩＤ関連情報（ＩＲＩ）を前記要求側エンティティ（５０）に送信する応答ステップ（ＸＩＩＩ）と
を行うように適合されるシステム。
【請求項１７】
ＩＤプロバイダ（４０）を利用してＩＤ関連情報（ＩＲＩ）を要求側エンティティ（５０）に提供する方法であって、ユーザと前記要求側エンティティ（５０）および前記ＩＤプロバイダ（４０）との通信のためにクライアント・アプリケーション（３０）が提供され、前記クライアント・アプリケーション（３０）は、第１の通信プロトコルを使用し、前記方法は、
前記第１の通信プロトコルが、少なくとも１回の以前の通信ステップについての情報を伴うリファラ要素を備えるかどうかを調べることと、
前記第１の通信プロトコルがリファラ要素を備える場合、
前記ユーザを前記ＩＤプロバイダ（４０）に対して認証するステップと、
前記ＩＤプロバイダ（４０）による第１の真正性リファレンス部（ａｒｔ１）の生成を備える、第１の真正性リファレンス部生成ステップ（ＩＶａ）と、
前記第１の真正性リファレンス部（ａｒｔ１）の通信を備える、前記クライアント・アプリケーション（３０）と前記ＩＤプロバイダ（４０）との間の第１の真正性リファレンス通信ステップ（ＩＶｂ、ＩＶｄ）と、
前記ＩＤプロバイダ（４０）による第２の真正性リファレンス部（ａｒｔ２）の生成を備える、第２の真正性リファレンス部生成ステップ（ＶＩ）と、
前記第２の真正性リファレンス部（ａｒｔ２）の通信と前記リファラ要素での前記第１の真正性リファレンス部（ａｒｔ１）の通信とを備える、前記第１の通信プロトコルを用いた前記ＩＤプロバイダ（４０）と前記要求側エンティティ（５０）との間の第２の真正性リファレンス通信ステップ（ＶＩＩＩ、ＩＸ）と、
前記要求側エンティティ（５０）が前記第１（ａｒｔ１）および前記第２（ａｒｔ２）の真正性リファレンス部、または前記第１（ａｒｔ１）および前記第２（ａｒｔ２）の真正性リファレンス部のセキュアな関数（ａｒｔ）を前記ＩＤプロバイダ（４０）に送信する要求ステップ（Ｘ）と、
前記ＩＤプロバイダが前記ＩＤ関連情報（ＩＲＩ）を前記要求側エンティティ（５０）に送信する応答ステップ（ＸＩＩＩ）と
を行うことと
を備える方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＤプロバイダを利用して、要求側エンティティに、ユーザに関するＩＤ関連情報を提供する方法およびシステムに関する。
【背景技術】
【０００２】
最も広い意味におけるＩＤ管理とは、少なくとも当該人物のすべてのデジタル関係を含む、ある人物についての全個人情報の管理を意味する。今後十年のうちに、この広い意味におけるＩＤ管理システムは発展していくものと思われる。短期のＩＤ管理は、通例、人物についての少量のデータの転送を伴うウェブ上のシングル・サインオンについて言われる。
【０００３】
主要な実務の事例は、電子商取引の一般的な支援である。すなわち、ＩＤ管理はインフラの問題であり、ここでは、インターネットやウェブの標準のような標準がほぼすべての関係者にとって利益となる可能性がある。
【非特許文献１】http://www.passport.com
【非特許文献２】http://www.oasisopen.org/committees/security/docs
【非特許文献３】http://www.projectliberty.org
【非特許文献４】http://www.ietf.org/rfc/rfc2068.txt
【発明の開示】
【発明が解決しようとする課題】
【０００４】
シングル・サインオンは、人物またはユーザが、１つのみのパスワードを覚えて種々の組織やサービスにログインすることを可能にする。さらに、シングル・サインオンのプロトコルは、クライアント・アプリケーションが、事前に鍵などの共通のデータを交換していない他のアプリケーションに対して自身を識別することを可能にする。通常、多くのユーザは、すべての組織やサービスに同じユーザ名とパスワードを選択する。このことには２つの問題がある。各サービスが、他のサービスに向けてユーザになりすますことができる。これは、１つの企業の複数のサービスには容認できるかもしれないが、その場合もユーザはよりよいモジュール化を好むものと思われる。そして、明らかなように、ユーザのウェブ体験全体にとって、これは許容できることではない。
【０００５】
シングル・サインオンは、インターネット上の電子ビジネスをより容易にし、新たに出現するウェブ・サービスの広範な使用を可能にするために必要なインフラと一般にみなされている。シングル・サインオンは、例えば、ＩＤが一旦確立されると人物についての追加的な情報を交換するような、より一般的なＩＤ管理へと発展する可能性もある。
【０００６】
近年、シングル・サインオンの種々のソリューションが知られており、例えば、マイクロソフト社のＰａｓｓｐｏｒｔシステム（ＵＲＬ：http://www.passport.com）、ＯＡＳＩＳ（Organization for the Advancement ofStructured Information Standards）のＳＡＭＬ（セキュリティ・アサーション・マークアップ言語）の標準化（ＵＲＬ：http://www.oasisopen.org/committees/security/docs）、および、Ｌｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅ  Ｐｒｏｊｅｃｔの最近の仕様（ＵＲＬ:http://www.projectliberty.org）がある。Ｌｉｂｅｒｔｙ仕様の態様の１つは、クライアント・アプリケーションとしてのブラウザだけに詳細なプロトコルが提供されるのではなく、他のより強力なクライアント・アプリケーション用のより効率的なプロトコルが提供されることである。この状況における関連するより古い方式は、従来の３者間認証プロトコルである。
【０００７】
ＫｅｒｂｅｒｏｓやＮｅｅｄｈａｍ−Ｓｃｈｒｏｅｄｅｒのような従来の３者間クライアント認証プロトコルは、いずれも、鍵交換または鍵確立プロトコルから開始し、次いでクライアント・アプリケーションがその鍵を暗号化および認証に使用することを要求する。すなわち、パスワード、秘密鍵、確立された公開鍵等の事前に交換された何らかの情報でクライアント・アプリケーションを識別することができる第３者が、通例は、クライアント・アプリケーションと、本明細書では「要求側エンティティ」と呼ぶその相手エンティティとの間の通信のための新しい秘密鍵を生成し、その秘密鍵をそれら両エンティティに対してセキュアに設定する。この秘密鍵のセキュアな転送を実施するために各種のプロトコルがある。
【０００８】
ＳＡＭＬ（セキュリティ・アサーション・マークアップ言語）等の連携型（federated）ＩＤ管理の提案は、パスワードのヘルプデスクの節減、ユーザ管理、およびユーザの削除により、ユーザ管理コストの削減を可能にする。ＳＡＭＬの特徴は、標準的なウェブ・ブラウザのみに依拠して例えばシングル・サインオンによりＩＤの連携を実施するブラウザに基づくプロファイルである。これらのプロトコルは、連携型ＩＤ管理のソリューションの一般的な利点を、ゼロ・フットプリントであるという特性、すなわち追加的なクライアント・ソフトウェアのインストールを必要としないことで補う。したがって、ブラウザに基づくプロファイルは、コスト効率的に展開することができる。しかし、標準的なウェブ・ブラウザをクライアントとするセキュアなプロトコルを設計することは、些細なことではない。関与しているプロトコルを認識しないブラウザは、あらかじめ定義されたふるまいを有し、あらかじめ定義されたメッセージに応答し、基礎となるオペレーティング・システムと通信相手両者への情報フローを生成する。特に、ブラウザのＵＲＬ（UniformResource Location）を通じて機密情報を転送するプロトコルのセキュリティは、この標準的なウェブ・ブラウザのプロトコルを認識しないふるまいによって危険にさらされる。ＳＡＭＬのブラウザ／アーティファクトのプロファイルは、セキュリティ・トークンへのリファレンスとして無作為のアーティファクトを発行し、そのアーティファクトをブラウザのリダイレクトＵＲＬを介して移送するので、この類のプロトコルに属する。
【０００９】
その一方で、ＳＡＭＬは、Ｖｅｒｓｉｏｎ２．０に進化している。ＳＡＭＬ標準の構造と命名もわずかに変わっており、そのため、現在、（セキュリティ・プロトコル・リサーチの専門用語における）相当プロトコルは、SAML V2.0 Web Browser SSO/Response/Artifact Featureとなっている。
【００１０】
本発明は、改良されたＩＤ管理のソリューションを提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明は、独立請求項に定義される方法、システム、要求側エンティティ、ＩＤプロバイダ、およびコンピュータ・プログラムを対象とする。本発明のさらなる実施形態は、その後に記載される従属請求項に提供される。
【００１２】
本発明の一態様によれば、ＩＤプロバイダを利用してＩＤ関連情報を要求側エンティティに提供する方法が提示され、ユーザと要求側エンティティおよびＩＤプロバイダとの通信のためにクライアント・アプリケーションが提供され、クライアント・アプリケーションは、第１の通信プロトコルを使用し、第１の通信プロトコルは、リファラ機能を備え、当該リファラ機能により、通信メッセージは、少なくとも１回の以前の通信ステップについての情報を有するリファラ要素を備えることができ、この方法は、
ユーザをＩＤプロバイダに対して認証することと、
ＩＤプロバイダによる第１の真正性リファレンス部（authenticityreference part）の生成を備える、第１の真正性リファレンス部生成ステップと、
真正性リファレンス部の通信を備える、クライアント・アプリケーションとＩＤプロバイダとの間の第１の真正性リファレンス通信ステップと、
ＩＤプロバイダによる第２の真正性リファレンス部の生成を備える、第２の真正性リファレンス部生成ステップと、
第２の真正性リファレンス部の通信と、リファラ要素での第１の真正性リファレンス部の通信とを備える、第１の通信プロトコルを用いたＩＤプロバイダと要求側エンティティとの間の第２の真正性リファレンス通信ステップと、
要求側エンティティが第１および第２の真正性リファレンス部、または第１および第２の真正性リファレンス部のセキュアな関数をＩＤプロバイダに送信する要求ステップと、
ＩＤプロバイダがＩＤ関連情報を要求側エンティティに送信する応答ステップと
を備える。
【００１３】
この方法には、セキュリティが著しく強化されるという利点がある。加えて、実装が容易で効率的である。少なくとも２つの真正性リファレンス部、すなわち第１の真正性リファレンス部および第２の真正性リファレンス部を発行することにより、敵対者が、２つの真正性リファレンス部の１つを入手しても、要求側エンティティに対してユーザに代わって行動できないことが保証される。
【００１４】
用語「ユーザ」は、広い意味で解釈すべきである。ユーザは、ＩＤが管理される任意のエンティティまたは人物である。用語「ユーザ」は、ユーザのクライアント、例えば特定のソフトウェア・アプリケーションも含むものとする。
【００１５】
本発明の各種実施形態によると、要求ステップを行うには種々の可能性がある。
【００１６】
１つの可能性は、要求ステップで第１および第２の真正性リファレンス部をＩＤプロバイダに送信することである。この場合は、第１および第２の真正性リファレンス部を生成した後、ＩＤプロバイダはそれらを対としてデータベースに記憶し、ＩＤプロバイダが要求ステップで真正性リファレンス部の対を受信した場合に、対応する対が記憶されているかどうかデータベースを調べる。対応する対が記憶されている場合、ＩＤプロバイダは、対応するＩＤ関連情報を要求側エンティティに送信する。そうでない場合は、エラー・メッセージが送信されることができる。
【００１７】
別の可能性は、第１および第２の真正性リファレンス部のセキュアな関数を使用するものである。セキュアな関数とは、敵対者が、第１および第２の真正性リファレンス部から計算されたその関数の結果を、それら真正性リファレンス部の１つのみから復元することが不可能であるか、少なくともほぼ不可能であることを保証する関数と理解すべきである。その場合は、第１および第２の真正性リファレンス部を生成した後、ＩＤプロバイダがそれぞれ主要真正性リファレンスを計算し、決定する。この主要真正性リファレンスは、第１および第２の真正性リファレンス部からセキュアな関数を使用して計算される。そして、ＩＤプロバイダは、主要真正性リファレンスを記憶する。要求側エンティティが第２の真正性リファレンス通信ステップで第１および第２の真正性リファレンス部を受信した場合、要求側エンティティは、全く同じセキュア関数または対応するセキュア関数を用いて、それぞれ主要真正性リファレンスを計算し、決定する。これは、その場合は、ＩＤプロバイダと要求側エンティティの両方が同じセキュア関数を知っているか、ＩＤプロバイダがセキュア関数を知っており、要求側エンティティがそれに対応するセキュア関数を知っていることを意味する。要求側エンティティ側で対応するセキュア関数を使用することにより、公開鍵暗号法が可能になる。要求ステップで、要求側エンティティは、主要真正性リファレンスをＩＤプロバイダに送信する。ＩＤプロバイダは自身のデータベースで、対応する主要真正性リファレンスが記憶されているかどうかを調べる。記憶されている場合、ＩＤプロバイダは、対応するＩＤ関連情報を要求側エンティティに送信する。
【００１８】
本発明は、各種形態の通信プロトコルに適用することができる。特に、本発明は、リファラ機能を備える通信プロトコルに適用することができ、リファラ機能により、通信メッセージは、２回以上の以前の通信ステップについての情報を含む複数のリファラ要素を備える。リファラ要素が２回の以前の通信ステップについての情報を備える場合は、３つの真正性リファレンス部を生成することにより、セキュアな認証を保証することができる。一般に、リファラ要素がｎ回（ｎは自然数）の以前の通信ステップについての情報を備える場合は、ｎ＋１個の真正性リファレンス部を生成することでセキュアな認証を保証することができる。
【００１９】
用語「ＩＤ関連情報（ＩＲＩ）」は、人物またはユーザに関連する任意の情報と理解される。ＩＤ関連情報ＩＲＩは、名前、住所、グループの所属、権限付与の資格証明、人口統計データ、個人の嗜好、予定表の項目、医療および金融情報、および、ある人物について、またはユーザ名の下にデジタルで記憶されることが可能な他の事柄すべてを備える。要求側エンティティは、アクセス制御、権限付与、個人別設定、認証、ログイン、商業、医療または行政に関する発行、またはＩＤ関連情報ＩＲＩに基づいて機能する他の用途のためにＩＤに関連する情報を要求する可能性がある。この用語の別の表現は、「資格証明」、すなわちユーザまたは人物についての任意の証明済みの情報である。
【００２０】
真正性リファレンス部は、一律に選択される、ランダムな要素、擬似ランダムな要素、またはその他の形で推測が困難な要素である。「認証リファレンス」と「認証リファレンス部」はそれぞれ、しばしば「アーティファクト」と呼ばれる。
【００２１】
ＩＤプロバイダに対するユーザの認証には、例えば、パスワードを伴うユーザ名、暗証番号または取引番号（ＴＡＮ）、またはスマートカード、ハードウェア・トークン、電子メール・メッセージ等の２ファクタ認証方法などの各種の方法が使用されることができる。
【００２２】
クライアント・アプリケーションは、要求側エンティティおよびＩＤプロバイダと通信するために提供される任意のソフトウェア・ツールまたはハードウェア・ツールまたはデバイスとすることができる。
【００２３】
本方法はさらに、第１の通信プロトコルを用いて要求側エンティティからクライアント・アプリケーションに結果を通信する結果ステップを備えることができる。
【００２４】
結果ページは、ユーザが要求側エンティティに要求した情報をユーザに提示する。結果ページは、ユーザの機密情報または個人情報を備える場合があるため、結果ページの通信は、しばしばセキュアな通信路を介して行われる。
【００２５】
結果ページを受信した後、ユーザはしばしば、セキュアでない通信路を介して、例えばＨＴＴＰ（ハイパー・テキスト転送プロトコル）などの非セキュアなブラウザ・プロトコルを使用することにより、クライアント・アプリケーションを引き続き使用する場合がある。そのため、敵対者が、このユーザのその後の活動をかなり容易に観察できる可能性がある。第１の通信プロトコルのリファラ機能のために、クライアント・アプリケーションが要求側エンティティまたは別のエンティティに送信する次の通信メッセージは、リファラ要素になお第２の真正性リファレンス部を備える可能性がある。したがって、敵対者がこの第２の真正性リファレンス部を入手する可能性があるが、この通信メッセージからはもはや入手することができない第１の真正性リファレンス部は入手できない（リファラ機能が１回の以前の通信ステップについての情報のみを記憶するものとする）。そのため、敵対者がこの第２の真正性リファレンス部を入手したとしても、第１の真正性リファレンス部がなくては役に立たないため、悪用することができない。
【００２６】
第１の通信プロトコルは、本発明の一実施形態によると、ブラウザ・プロトコル、詳細にはＨＴＴＰ（ハイパー・テキスト転送プロトコル）である。これは、本発明の実施形態の平易で広範な適用を可能にする。ユーザは、本発明の実施形態を実施するための追加的なソフトウェアを必要としない。それでもなお本方法のセキュリティは保証される。
【００２７】
ブラウザ・プロトコルは、しばしばリファラ機能を備える。ＨＴＴＰプロトコルによるメッセージは、第１の部分にＵＲＬ（Uniform Resource Location）を備える。ＵＲＬは、あるステップでは第１の真正性リファレンス部の通信に使用されることができ、別のステップでは、第２の真正性リファレンス部の通信に使用されることができるクエリ・フィールドを備える。また、ＨＴＴＰプロトコルのメッセージは、１つまたは複数のヘッダを有する第２の層を備える。このヘッダは、リファラ要素、すなわち前回の通信ステップのＵＲＬを備え、したがって、前回のＵＲＬのクエリ・フィールドに前回の真正性リファレンス部の前回のＵＲＬを備える。
【００２８】
本発明のさらなる実施形態によると、第１の真正性リファレンス通信ステップまたは第２の真正性リファレンス通信ステップ、または結果ステップあるいはそのすべては、セキュアな通信路、詳細にはサーバ認証を伴うセキュアな通信路を介して行われる。セキュアな通信路は、好ましくは、ＳＳＬ（セキュア・ソケット・レイヤ）、ＴＬＳ（トランスポート・レイヤ・セキュリティ）、またはＷＳ（ウェブ・サービス）セキュリティ等のＳＯＡＰ（シンプル・オブジェクト・アクセス・プロトコル）の拡張などのプロトコルを用いて実装されることができる。
【００２９】
これにより、第１または第２の真正性リファレンス通信ステップあるいはその両方の際に、敵対者が第１および第２の真正性リファレンス部または結果ページの情報あるいはその両方を入手できないことが保証される。
【００３０】
本発明のさらなる実施形態によると、第２の真正性リファレンス通信ステップは、クライアント・アプリケーションを介してＩＤプロバイダを要求側エンティティにリダイレクトするリダイレクト・ステップである。リダイレクト・コマンドで開始されるこのようなリダイレクト・ステップは、ブラウザ・プロトコルの共通要素である。これにより、本発明が、各種の通信システムで容易に実施できることが保証される。
【００３１】
好ましくは、リダイレクト・ステップは、第１および第２のリダイレクト下位ステップを備え、ＩＤプロバイダは、第１のリダイレクト下位ステップで、リダイレクト・アドレスを伴うリダイレクト・コマンドをクライアント・アプリケーションに送信し、リダイレクト・アドレスは、第２の真正性リファレンス部を備え、クライアント・アプリケーションは、第２のリダイレクト下位ステップで、第２の真正性リファレンス部と、リファラ要素中に第１の真正性リファレンス部とを伴うリダイレクト・アドレスを備えるＧＥＴ要求を要求側エンティティに送信する。
【００３２】
このことは、第１の真正性リファレンス部は、第２のリダイレクト下位ステップのみでクライアント・アプリケーションと要求側エンティティ間を送信され、第１のリダイレクト下位ステップでは送信されないことを意味する。これにより、両方の真正性リファレンス部が、両方の下位ステップではなく１つのみの下位ステップで送信され、したがって、敵対者が両方の真正性リファレンス部を入手する可能性があるのが第２の下位ステップのみになるため、セキュリティが強化される。
【００３３】
本発明のさらなる実施形態によると、要求ステップおよび応答ステップは、第２の通信プロトコル、詳細にはＳＡＭＬ（セキュリティ・アサーション・マークアップ言語）を使用する。しかし、連携型ＩＤ管理に真正性リファレンス（「アーティファクト」とも称される）を使用する他の標準も第２の通信プロトコルとして有利に使用されることができる。Ｌｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅ  ＰｒｏｊｅｃｔあるいはＷｅｂ  Ｓｅｒｖｉｃｅ  Ｆｅｄｅｒａｔｉｏｎの関連標準は、さらなる好ましい例である。
【００３４】
本発明のさらなる実施形態によると、要求ステップおよび応答ステップは、相互認証を伴うセキュアな通信路を介して行われる。セキュアな通信路は、好ましくは、クライアントおよびサーバの証明書を伴うＳＳＬ（セキュア・ソケット・レイヤ）またはＴＳＬ（トランスポート・レイヤ・セキュリティ）、またはＷＳセキュリティ等のＳＯＡＰ（シンプル・オブジェクト・アクセス・プロトコル）の拡張を用いて実装されることができる。
【００３５】
これによりセキュリティがさらに向上し、第１および第２の真正性リファレンス部または第１および第２の真正性リファレンス部のセキュアな関数が敵対者に渡らないことが保証される。
【００３６】
本発明のさらなる実施形態によると、セキュアな関数は、ＸＯＲ関数、擬似ランダム関数、ハッシュ関数、暗号化関数、または秘密共有関数である。
【００３７】
これらの関数はすべて、敵対者が、第１および第２の真正性リファレンス部から計算されるその関数の結果を、それら真正性リファレンス部の１つだけから復元することが不可能であるか、少なくともほぼ不可能であることを保証しなければならない。
【００３８】
本発明のさらなる実施形態によると、第１の真正性リファレンス通信ステップは、ＩＤプロバイダが第１の真正性リファレンス部をクライアント・アプリケーションに送信する下位ステップと、クライアント・アプリケーションが認証および第１の真正性リファレンス部をＩＤプロバイダに送信する、それに続く下位ステップとを備える。
【００３９】
この実施形態では、第１の真正性リファレンス部は、ユーザがＩＤプロバイダに対して自身を認証する前に生成される。ＩＤプロバイダは、第１の下位ステップで、第１の真正性リファレンス部をクライアント・アプリケーションに送信する。この第１の真正性リファレンス通信ステップで送信されるメッセージは、ユーザにパスワードまたは別の権限付与手段を入力するように要求する認証フォームまたは認証コマンドをさらに備えてよい。そして、さらなる下位ステップで、クライアント・アプリケーションは、パスワードまたは別の権限付与手段を、例えばＳＵＢＭＩＴ要求またはＧＥＴ要求を用いて送り返す。ＳＵＢＭＩＴ要求またはＧＥＴ要求は、アドレスとしてＩＤプロバイダのＵＲＬを備える。加えて、このさらなる下位ステップの通信メッセージは、例えばＧＥＴ要求またはＳＵＢＭＩＴ要求のＵＲＬのクエリ・フィールドに第１の真正性リファレンス部を備える。その結果、第１の通信プロトコルの現在のＵＲＬは、第１の真正性リファレンス部を備える。これは、第２の真正性リファレンス通信ステップで第１の真正性リファレンス部がリファラ要素で送信され、一方、第１の層でＵＲＬのクエリ・フィールドで第２の真正性リファレンス部が送信されることができることを意味する。
【００４０】
本発明の異なる態様のステップは、異なる順序で行われてよいことに留意されたい。さらに、それらのステップは組み合わせてもよい。すなわち、例えば２つのステップが例えば１つの通信メッセージ内で共に行われてよい。一例として、ＩＤプロバイダに対するユーザの認証は、第１の真正性リファレンス部生成ステップまたは第１の真正性リファレンス通信ステップあるいはその両方と組み合わせて行われることができる。別の例として、第１および第２の真正性リファレンス部生成ステップは、１つのステップで同時に共に行われてよい。
【００４１】
本発明の別の態様は、ＩＤ関連情報（ＩＲＩ）を所有するＩＤプロバイダからＩＤ関連情報を受信する方法に関し、クライアント・アプリケーションのユーザおよびＩＤプロバイダとの通信のために第１の通信プロトコルが提供され、第１の通信プロトコルは、リファラ機能を備え、当該リファラ機能により、通信メッセージは、少なくとも１回の以前の通信ステップについての情報を有するリファラ要素を備えることができ、この方法は、
第１の通信プロトコルを使用して、第２の真正性リファレンス部と、リファラ要素で第１の真正性リファレンス部とをＩＤプロバイダから受信することと、
第１および第２の真正性リファレンス部、または第１および第２の真正性リファレンス部のセキュアな関数をＩＤプロバイダに送信することと、
ＩＤプロバイダからＩＤ関連情報（ＩＲＩ）を受信することと
を備える。
【００４２】
本発明の別の態様によると、要求側エンティティにＩＤ関連情報を提供する方法が提示され、クライアント・アプリケーションのユーザおよびＩＤ関連情報を要求する要求側エンティティとの通信のために第１の通信プロトコルが提供され、第１の通信プロトコルは、リファラ機能を備え、当該リファラ機能により、通信メッセージは、少なくとも１回の以前の通信ステップについての情報を有するリファラ要素を備えることができ、この方法は、
第１の真正性リファレンス部を生成することと、
第１の真正性リファレンス部をクライアント・アプリケーションに通信することと、
第２の真正性リファレンス部を生成することと、
第１の通信プロトコルを使用して、第２の真正性リファレンス部と、リファラ要素で第１の真正性リファレンス部とを要求側エンティティに通信することと、
要求側エンティティから、第１および第２の真正性リファレンス部、または第１および第２の真正性リファレンス部のセキュアな関数を受信することと、
ＩＤ関連情報を伴う応答を要求側エンティティに送信することと
を備える。
【００４３】
本発明の別の態様は、コンピュータ・システムで実行されると、請求項１ないし１２のいずれか一項に記載の方法のステップを実施する命令を備えたコンピュータ・プログラムに関する。
【００４４】
本発明の別の態様は、ＩＤ関連情報（ＩＲＩ）を所有するＩＤプロバイダからＩＤ関連情報を受信する要求側エンティティに関し、要求側エンティティは、クライアント・アプリケーションのユーザと、第１の通信プロトコルを使用して通信するように適合され、第１の通信プロトコルは、リファラ機能を備え、当該リファラ機能により、通信メッセージは、少なくとも１回の以前の通信ステップについての情報を有するリファラ要素を備えることができ、要求側エンティティは、
第１の通信プロトコルを使用して、第２の真正性リファレンス部と、リファラ要素で第１の真正性リファレンス部とをＩＤプロバイダから受信するステップと、
第１および第２の真正性リファレンス部、または第１および第２の真正性リファレンス部のセキュアな関数をＩＤプロバイダに送信するステップと、
ＩＤプロバイダからＩＤ関連情報を受信するステップと
を行うように適合される。
【００４５】
本発明の別の態様は、要求側エンティティにＩＤ関連情報（ＩＲＩ）を提供するＩＤプロバイダに関し、ＩＤプロバイダは、クライアント・アプリケーションのユーザと、第１の通信プロトコルを使用して通信するように適合され、第１の通信プロトコルは、リファラ機能を備え、当該リファラ機能により、通信メッセージは、少なくとも１回の以前の通信ステップについての情報を有するリファラ要素を備えることができ、ＩＤプロバイダは、
第１の真正性リファレンス部を生成するステップと、
第１の真正性リファレンス部をクライアント・アプリケーションに通信するステップと、
第２の真正性リファレンス部を生成するステップと、
第１の通信プロトコルを使用して、第２の真正性リファレンス部と、リファラ要素で第１の真正性リファレンス部とを要求側エンティティに通信するステップと、
要求側エンティティから、第１および第２の真正性リファレンス部、または第１および第２の真正性リファレンス部のセキュアな関数を受信するステップと、
ＩＤ関連情報を伴う応答を要求側エンティティに送信するステップと
を行うように適合される。
【００４６】
本発明の別の態様は、ＩＤプロバイダを利用してＩＤ関連情報を要求側エンティティに提供するシステムに関し、ユーザと要求側エンティティおよびＩＤプロバイダとの通信のためにクライアント・アプリケーションが提供され、クライアント・アプリケーションは、第１の通信プロトコルを使用し、第１の通信プロトコルは、リファラ機能を備え、当該リファラ機能により、通信メッセージは、少なくとも１回の以前の通信ステップについての情報を有するリファラ要素を備えることができ、このシステムは、
ユーザをＩＤプロバイダに対して認証するステップと、
ＩＤプロバイダによる第１の真正性リファレンス部の生成を備える、第１の真正性リファレンス部生成ステップと、
第１の真正性リファレンス部の通信を備える、クライアント・アプリケーションとＩＤプロバイダとの間の第１の真正性リファレンス通信ステップと、
ＩＤプロバイダによる第２の真正性リファレンス部の生成を備える、第２の真正性リファレンス部生成ステップと、
第２の真正性リファレンス部の通信とリファラ要素での第１の真正性リファレンス部の通信とを備える、第１の通信プロトコルを用いたＩＤプロバイダと要求側エンティティとの間の第２の真正性リファレンス通信ステップと、
要求側エンティティが第１および第２の真正性リファレンス部、または第１および第２の真正性リファレンス部のセキュアな関数をＩＤプロバイダに送信する要求ステップと、
ＩＤプロバイダがＩＤ関連情報（ＩＲＩ）を要求側エンティティに送信する応答ステップと
を行うように適合される。
【００４７】
本発明の別の態様は、ＩＤプロバイダを利用してＩＤ関連情報を要求側エンティティに提供する方法に関し、ユーザと要求側エンティティおよびＩＤプロバイダとの通信のためにクライアント・アプリケーションが提供され、クライアント・アプリケーションは、第１の通信プロトコルを使用し、この方法は、
第１の通信プロトコルが、少なくとも１回の以前の通信ステップについての情報を伴うリファラ要素を備えるかどうかを調べることと、
第１の通信プロトコルがリファラ要素を備える場合、
ユーザをＩＤプロバイダに対して認証するステップと、
ＩＤプロバイダによる第１の真正性リファレンス部の生成を備える、第１の真正性リファレンス部生成ステップと、
第１の真正性リファレンス部の通信を備える、クライアント・アプリケーションとＩＤプロバイダとの間の第１の真正性リファレンス通信ステップと、
ＩＤプロバイダによる第２の真正性リファレンス部の生成を備える、第２の真正性リファレンス部生成ステップと、
第２の真正性リファレンス部の通信とリファラ要素での第１の真正性リファレンス部の通信とを備える、第１の通信プロトコルを用いたＩＤプロバイダと要求側エンティティとの間の第２の真正性リファレンス通信ステップと、
要求側エンティティが第１および第２の真正性リファレンス部、または第１および第２の真正性リファレンス部のセキュアな関数をＩＤプロバイダに送信する要求ステップと、
ＩＤプロバイダがＩＤ関連情報（ＩＲＩ）を要求側エンティティに送信する応答ステップと
を行うことと
を備える。
【００４８】
本発明のこの態様によると、好ましくはＩＤプロバイダによって行われる追加的な確認ステップが提供される。この確認ステップでは、クライアント・アプリケーションからＩＤプロバイダまたは要求側エンティティあるいはその両方に送信される通信メッセージがリファラ要素を備えるかどうかが調べられる。通信メッセージがリファラ要素を備えない場合は、ＩＤプロバイダから要求側エンティティに１つの真正性リファレンス部のみを通信すれば十分である。この確認ステップは、ＩＤプロバイダに対するユーザの認証の前に行われる場合も後に行われる場合もある。通信メッセージがリファラ要素を備えない理由は、第１の通信プロトコルがリファラ機能を全く備えないためか、または、リファラ機能が個々にオフにされ、非作動状態になっているかのいずれかである。
【００４９】
本発明のこの態様は、リファラ機能を持つ通信プロトコルとリファラ機能を持たない通信プロトコルの両方が使用される用途、またはクライアントがリファラを設定するか否かを選択できる用途に特に有用である。
【００５０】
本発明の各種実施形態は、完全な相互動作性を得た場合には関係者の各種の要件、特に認証情報および他のＩＤ関連情報の転送に対応することが可能な、信頼性が高く、セキュアで効率的なＩＤ管理を可能にする。本発明は、ユーザがブラウザ・ソフトウェアのみを有するシステム、ならびにユーザがより強力なソフトウェアを有するシステムに適用可能である。特に、本発明は、単純なブラウザ・プロトコル（例えばＨＴＴＰ）とより精緻な連携型ＩＤ管理用のプロトコル（例えばＳＡＭＬ）を組み合わせることを可能にする。単純なブラウザ・プロトコルは、クライアント・アプリケーションとＩＤプロバイダおよび要求側エンティティとの通信に使用し、一方、連携型ＩＤ管理用のプロトコルは、ＩＤプロバイダと要求側エンティティとの間の通信に使用されることができる。
【００５１】
すなわち、本発明は、ウェブベースのサービスのエンド・ユーザ、例えば電子商取引のエンド・ユーザが、シングル・サインオン（ＳＳＯ）の動作、分散型のトランザクション、または他の権限付与サービスを行うことを可能にする。ここに提示される本発明の実施形態および態様は、ゼロ・フットプリントのバージョンに対応することができ、すなわち、ＪａｖａｓｃｒｉｐｔやＡｃｔｉｖｅＸ（「Ｊａｖａｓｃｒｉｐｔ」および「Ｊａｖａ」は、サン・マイクロシステムズ社の商標。「ＡｃｔｉｖｅＸ」は、マイクロソフト社の商標）のようなアクティブ・コンテンツにさえ他のソフトウェアが必要とされない。
【００５２】
下記に以下の概略図面をリファレンスして単なる例として本発明の好ましい実施形態を説明する。
【００５３】
図面は、例示の目的のみで提供され、必ずしも本発明の実際的な例を一定の縮尺で表すものではない。
【発明を実施するための最良の形態】
【００５４】
（用語解説）
以下に示すのは、詳細な説明の理解を助ける非公式の定義である。
【００５５】
「ユーザ」または「人物」：ＩＤが管理されるエンティティ。人物が行動するとユーザになる。通例、人物またはユーザは個人であるが、少なくとも小規模の企業は、例えば旅行の予約や情報収集の際に他の企業と個人と同じように対話することがしばしばある。
【００５６】
「要求側エンティティ」：人物の名前あるいは属性を知ることを望むエンティティ、例えばサーバによって表される組織。容易に展開可能な登録システムの保証性が低いために、当初の組織は、主としてインターネット上の店舗である。長期的には、組織には、銀行、医師、同僚、家族等、一人の人物の通信相手すべてが含まれる。「組織」としての同僚と家族は、例えばインスタント・メッセージングや予定表管理の際にＩＤ管理に連絡先情報あるいは位置情報を含めたい場合に特に関連する。
【００５７】
「ＩＤプロバイダ」：ある人物についてのＩＤ関連情報を記憶するエンティティ。銀行、認証機関（ＣＡ）、インターネット・サービス・プロバイダ等である。
【００５８】
用語「コンピュータ」には、ＰＣのような機器が含まれるが、ブラウズ機能を備える携帯情報端末や携帯電話も含まれる。
【００５９】
（詳細な説明）
図１を参照して、本発明が使用されることができる通信環境の全体的な構成を説明する。図では、同一または同様の部分は同じ参照符号を使用して表す。図１は、ユーザ２０として行動する人物Ｐを示す。ユーザ２０は、例えばウェブ・ブラウザなどのクライアント・アプリケーション３０を自身のコンピュータで実行する。クライアント・アプリケーション３０は、アプリケーションに依存する対話のために、例えばサービスを提供する企業や銀行のサーバである要求側エンティティ５０に接続される。クライアント・アプリケーション３０と要求側エンティティ５０は、当技術分野で知られるように通信回線５を介して接続される。通信回線５は、通常、例えばインターネットなどのネットワークを通じて提供される。クライアント・アプリケーション３０はさらにＩＤプロバイダ４０に接続され、ここで、ＩＤプロバイダ４０は、ローカル、すなわちユーザ２０のコンピュータにあっても、またはリモート、すなわち外部サーバ等にあってもよい。ＩＤプロバイダ４０は、例えば、銀行や、ＩＤ管理サービスを提供する他の専門組織である。ＩＤプロバイダ４０は、ＩＤ関連情報ＩＲＩの送信のために、要求側エンティティ５０にも接続することができる。用語「ＩＤ関連情報ＩＲＩ」は、人物またはユーザに関連する任意の情報と解釈される。ＩＤ関連情報ＩＲＩは、名前、住所、グループの所属、権限付与の資格証明、人口統計データ、個人の嗜好、予定表の項目、医療および金融情報、および、ある人物について、またはユーザ名の下にデジタルで記憶されることが可能な他の事柄すべてを備える。要求側エンティティは、アクセス制御、権限付与、個人別設定、認証、ログイン、商業、医療または行政に関する発行、またはＩＤ関連情報ＩＲＩに基づいて機能する他の用途のためにＩＤに関連する情報を要求する可能性がある。図１のシナリオは、要求側エンティティ５０にＩＤ関連情報ＩＲＩを提供する下記の流れの説明を助けるために示している。
【００６０】
クライアント・アプリケーション３０は、好ましくは第１の通信プロトコルを用いてＩＤプロバイダ４０および要求側エンティティ５０と通信する。この第１の通信プロトコルは、ブラウザ・ベースのプロトコル、例えばＨＴＴＰ（ハイパー・テキスト転送プロトコル）であることが好ましい。第１の通信プロトコルは、リファラ機能を備え、この機能により、通信ステップは、少なくとも１回の以前の通信ステップについての情報を有するリファラ要素を備える。第１の通信プロトコルが、例えばＨＴＴＰのようなブラウザ・ベースのプロトコルである場合、クライアント・アプリケーション３０が通信相手に送信する通信メッセージは、リファラ要素の中に、クライアント・アプリケーションが前回訪問したＵＲＬ（Uniform Resource Location）を備える。ＨＴＴＰでは、リファラ要素は、通信メッセージのヘッダ内に割り当てられる。
【００６１】
当初のＲＦＣ２０６８プロトコル（http://www.ietf.org/rfc/rfc2068.txt）とＨＴＴＰ１．１  ＲＦＣ２６１６は、誤って、間違った綴り「ｒｅｆｅｒｅｒ」を含んでおり、その綴りがＨＴＴＰ標準の綴りとなっていることに留意されたい。それでも、本願では、ＨＴＴＰコマンド言語の直接の引用を除いては正しい英語の綴りである「ｒｅｆｅｒｒｅｒ」を使用する。
【００６２】
ＩＤプロバイダ４０と要求側エンティティ５０は、第２の通信プロトコルを用いて、例えばＳＡＭＬ（セキュリティ・アサーション・マークアップ言語）やＬｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅ  ＰｒｏｊｅｃｔやＷＳ−Ｆｅｄｅｒａｔｉｏｎ等の他の連携型ＩＤ管理プロトコルを用いて、ＩＲＩを交換するために直接通信することができる。
【００６３】
図２に、第１の実施形態のメッセージ・フローの模式図を示す。同図では、クライアント・アプリケーション３０、ＩＤプロバイダ４０、および要求側エンティティ５０間のメッセージ・フローは、個々のローマ数字が割り当てられた符号付き矢印で示している。さらなるステップすなわち下位ステップは、丸で囲んだローマ数字で示す。この流れは、次第に大きくなるローマ数字で表されるように、上から下へ順次行われるものと理解される。ただし、指定された順序なしに並行して実行される、このプロトコルの複数のインスタンスがあってよいことに留意されたい。
【００６４】
ステップＩで、クライアント・アプリケーション３０と要求側エンティティ５０の間でアプリケーションに依存する対話が行われる。このステップＩで、ユーザは、アクセスの制約を受けずに、要求側エンティティの一般に公開されたウェブサイトを訪問する可能性もある。ユーザが、アクセスが制限されたウェブサイトへのアクセスを望む、または認証を必要とする動作を行うことを望む場合（例えば購入取引や送金を行う）、要求側エンティティ５０は、ＩＤプロバイダ要求ステップＩＩを開始する。下位ステップＩＩａで、要求側エンティティ５０は、クライアント・アプリケーション３０に、ＩＤ関連情報ＩＲＩを所有するＩＤプロバイダ４０に対応したＩＤプロバイダ情報（ＩＰＩ）を要求する。ＩＤプロバイダ情報（ＩＰＩ）は、下位ステップＩＩｃで要求側エンティティ５０に送信される。任意で、下位ステップＩＩｂで、クライアント・アプリケーション３０が例えばユーザ２０に要求する等の異なる方式でＩＤプロバイダ情報ＩＰＩを得られるようにする。任意で、要求側エンティティ５０がデフォルトで特定のＩＤプロバイダ４０を使用する。その場合は、ＩＤプロバイダ要求ステップＩＩを省略することができる。その後にリダイレクト命令（下位ステップＩＩＩａ）を伴うリダイレクト・ステップＩＩＩが行われ、このステップでは、最終的にクライアント・アプリケーション３０がＩＤプロバイダ４０のＩＳＴ（サイト内転送）−ＵＲＬに接続される（下位ステップＩＩＩｂ）。
【００６５】
第１の真正性リファレンス部生成ステップＩＶａで、ＩＤプロバイダ４０は、ユーザの第１の真正性リファレンス部ａｒｔ１を生成する。真正性リファレンスは、しばしば「アーティファクト(artifact)」と呼ばれる。この第１の真正性リファレンス部ａｒｔ１は、一律に選択される、ランダムな要素、擬似ランダムな要素、またはその他の形で推測が困難な要素である。ステップＩＶｂで、ＩＤプロバイダ４０は、例えばユーザ名とパスワードまたは暗証番号（ＰＩＮ）で自身を認証するようにユーザに要求する認証フォームを備えたメッセージをクライアント・アプリケーション３０に送信する。また、このメッセージは、クライアント・アプリケーション３０が記入した権限付与フォームを提出すべきＩＤプロバイダ４０のＳＳＯ（シングル・サインオン）−ＵＲＬアドレスも備える。このＳＳＯ−ＵＲＬアドレスは、クエリ・フィールドに第１の真正性リファレンス部ａｒｔ１を備える。ステップＩＶｃで、ユーザは、例えばキーボード入力により、自分のユーザ名とパスワードをクライアント・アプリケーション３０に提出する。ステップＩＶｄで、クライアント・アプリケーション３０は、ＩＤプロバイダ４０の指定されたＳＳＯ−ＵＲＬアドレスに、記入された権限付与フォームを送り返し、このアドレスは、クエリ・フィールドに第１の真正性リファレンス部ａｒｔ１を備える。ステップＩＶｂとステップＩＶｄは、第１の真正性リファレンス通信ステップを確立する。この第１の真正性リファレンス通信ステップは、第１の真正性リファレンス部ａｒｔ１を、第１の通信プロトコルの現在のＵＲＬに配信する。すなわち、第１の真正性リファレンス通信ステップでは、クライアント・アプリケーション３０（ブラウザ）がＩＤプロバイダ４０に接触し、ＩＤプロバイダ４０は、第１の真正性リファレンス部ａｒｔ１をクライアント・アプリケーション３０に通信する。本発明のこの例示的実施形態では、第１の真正性リファレンス通信ステップは、ユーザの認証と組み合わせられる。これにより、この方法の効率が高まり、追加的なステップが不要になる。ただし、認証と第１の真正性リファレンス通信ステップは、別個に行われてもよい。
【００６６】
ステップＶで、ＩＤプロバイダ４０は、配信された認証情報、例えばパスワードやＰＩＮが正しいかどうかを確認する。正しい場合、ユーザは、ＩＤプロバイダ４０に対する自身の認証に成功している。第２の真正性リファレンス生成ステップＶＩで、ＩＤプロバイダ４０は、権限付与に成功したユーザに第２の真正性リファレンス部ａｒｔ２を生成し、これをアーティファクト２とも呼ぶ。第２の真正性リファレンス部ａｒｔ２は、一律に選択される、ランダム、擬似ランダム、またはその他の形で推測が困難な要素であり、また、第１の真正性リファレンス部ａｒｔ１からは独立している。
【００６７】
ステップＶＩＩで、ＩＤプロバイダ４０は、第１および第２の真正性リファレンス部ａｒｔ１およびａｒｔ２と、第１の真正性リファレンス部ａｒｔ１と第２の真正性リファレンス部ａｒｔ２との間の関係、すなわち、それらが対で共に属するという関係を記憶する。
【００６８】
第１のリダイレクト下位ステップＶＩＩＩで、ＩＤプロバイダ４０は、クライアント・アプリケーション３０にリダイレクト・コマンドを送信する。このリダイレクト・コマンドは、リダイレクト・アドレスとして、要求側エンティティ５０のＡＣＳ（アサーション・コンシューマ・サービス）−ＵＲＬを備え、このＡＣＳ−ＵＲＬは、クエリ・フィールドに、第２の真正性リファレンス部ａｒｔ２を備える。ＡＳＣ−ＵＲＬは、例えばＳＡＭＬ標準に従って連携型ＩＤ管理のために提供される要求側エンティティ５０のアドレスである。第２のリダイレクト下位ステップＩＸで、クライアント・アプリケーション３０は、要求されている要求側エンティティのＡＳＣ−ＵＲＬを備えるＧＥＴ要求を要求側エンティティ５０に送信し、この要求されるＡＣＳ−ＵＲＬは、第２の真正性リファレンス部ａｒｔ２を備える。ステップＩＸで送信される通信メッセージは、加えて、リファラ要素中にブラウザの前回のＵＲＬ（ＳＳＯ）を備える。したがって、前回のＵＲＬとして、クエリ・フィールドで、第１の真正性リファレンス部ａｒｔ１と、第１および第２の真正性リファレンス部ａｒｔ１およびａｒｔ２がステップＩＸで送信される。第１のリダイレクト下位ステップＶＩＩＩと第２のリダイレクト下位ステップＩＸは、一般に、第２の真正性リファレンス通信ステップを確立し、この特定の例ではリダイレクト・ステップを確立する。
【００６９】
要求ステップＸで、要求側エンティティは、第１および第２の真正性リファレンス部ａｒｔ１およびａｒｔ２を、ＩＤプロバイダ４０のアサーション・レスポンス・サービス・アドレスＡＲＳに送信する。このアサーション・レスポンス・サービスは、例えば、ＳＡＭＬ標準によるアサーション応答サービスである。
【００７０】
ステップＸＩで、ＩＤプロバイダ４０は、第１および第２の真正性リファレンス部ａｒｔ１およびａｒｔ２が有効であるかどうか、すなわち、それらが、ＩＤプロバイダ４０が以前に発行し、無効化あるいは失効していない真正性リファレンス部の対と対応するかどうかを調べる。
【００７１】
ステップＸＩＩで、ＩＤプロバイダ４０は、以前に要求側エンティティから送信された第１および第２の真正性リファレンス部ａｒｔ１およびａｒｔ２をデータベースから除去あるいは削除する。これにより、それらの真正性リファレンス部がそれ以上どのような認証目的にも使用できなくなることが保証される。
【００７２】
ステップＸで送信された第１および第２の真正性リファレンス部ａｒｔ１およびａｒｔ２が有効である場合、ＩＤプロバイダ４０は、応答ステップＸＩＩＩで、ＩＤ関連情報ＩＲＩを含む応答を要求側エンティティ５０に送信する。そうでない場合、ＩＤプロバイダ４０は、応答ステップＸＩＩＩで、受信された第１および第２の真正性リファレンス部ａｒｔ１およびａｒｔ２が無効であったことを知らせるエラー・メッセージを要求側エンティティ５０に送信する。
【００７３】
ステップＸＩＶで、要求側エンティティ５０は、ステップＩで発行されたユーザ２０の要求に対する結果を備えた結果ページを伴う結果をクライアント・アプリケーション３０に送信する。これは、要求された結果ページである場合も、エラー・ページである場合もある。結果ページはしばしば機密情報を備えるので、ステップＸＩＶは、セキュアな通信路を介して行われることが好ましい。
【００７４】
結果ページを受信した後、ユーザはしばしばさらなるステップＸＶに進む場合がある。このさらなるステップＸＶで、ユーザは、要求側エンティティ５０または別のサーバにさらなる要求を送信する。このさらなる要求について、ユーザは、しばしば、セキュアでないブラウザ・プロトコル、すなわちセキュアな通信路を介して行われないブラウザ・プロトコルを使用する場合がある。一例として、このさらなる要求は、ＨＴＴＰ（ハイパー・テキスト転送プロトコル）を用いて要求側エンティティ５０に送信される可能性がある。したがって、敵対者がこのさらなる要求をかなり容易に観察し、この要求の情報を入手する恐れがある。このさらなる要求で送信される情報は、ユーザが入手したい新しいＵＲＬのアドレスを備えるが、リファラ要素に前回のＵＲＬの情報も備える。前回のＵＲＬ（この場合はＡＳＣ−ＵＲＬ）は、第２の真正性リファレンス部ａｒｔ２を備えており、したがって、敵対者がこの第２の真正性リファレンス部ａｒｔ２を容易に入手する可能性がある。しかし、第１の真正性リファレンス部ａｒｔ１についての情報はリファラ要素から削除されているので、このさらなる要求は、ａｒｔ１についての情報はもはや備えていない。したがって、敵対者がこの第２の真正性リファレンス部ａｒｔ２を入手したとしても、第１の真正性リファレンス部ａｒｔ１がなくては役に立たないため、悪用することはできない。
【００７５】
セキュリティをさらに強化するために、第１の真正性リファレンス通信ステップＩＶｂ、ＩＶｄ、第２の真正性リファレンス通信ステップＶＩＩＩ、ＩＶ、ならびに要求ステップＸと応答ステップＸＩＩＩは、セキュアな通信路を介して行われるべきである。セキュアな通信路は、好ましくは、ＳＳＬ（セキュア・ソケット・レイヤ）、ＴＬＳ（トランスポート・レイヤ・セキュリティ）、またはＷＳ（ウェブ・サービス）セキュリティ等のＳＯＡＰ（シンプル・オブジェクト・アクセス・プロトコル）の拡張などのプロトコルを用いて実装されることができる。要求ステップＸと応答ステップＸＩＩＩは、好ましくは相互認証と共に行われることができ、一方、第１の真正性リファレンス通信ステップＩＶｂ、ＩＶｄ、および第２の真正性リファレンス通信ステップＶＩＩＩ、ＩＸは、好ましくはサーバ認証と共に行われることができる。
【００７６】
図３に、本発明の第２の実施形態のメッセージ・フローの模式図を示す。ステップＩ〜Ｖは、図２に関して説明したステップと同じであり、したがって再度の説明はしない。第２の真正性リファレンス生成ステップＶＩは、この実施形態では２つの下位ステップに分割される。第１の下位ステップＶ１ａでは、第２の真正性リファレンス部ａｒｔ２が生成される。第２の真正性リファレンス部ａｒｔ２は、ランダムな要素、擬似ランダムな要素、またはその他の形で類推するのが困難な要素である。第２の下位ステップＶ１ｂでは、主要真正性リファレンス部ａｒｔがそれぞれ計算され、決定される。主要真正性リファレンス部ａｒｔは、第１の真正性リファレンス部ａｒｔ１および第２の真正性リファレンス部ａｒｔ２からセキュアな関数によって個々に計算され、決定されるアーティファクトである。
【００７７】
セキュアな関数は、排他的論理和関数（ＸＯＲ）であることが好ましい。次いで、主要真正性リファレンス部ａｒｔが下記のように決定される。
主要アーティファクトａｒｔ＝ａｒｔ１  ＸＯＲ  ａｒｔ２
【００７８】
ステップＶＩＩで、ＩＤプロバイダ４０は、主要真正性リファレンス部ａｒｔを自身のデータベースに記憶する。第１の真正性リファレンス部ａｒｔ１と第２の真正性リファレンス部ａｒｔ２が真にランダムに選択される場合、第１の真正性リファレンス部ａｒｔ１と第２の真正性リファレンス部ａｒｔ２は、主要真正性リファレンス部ａｒｔから理論的に独立した情報となる。
【００７９】
ステップＶＩＩＩおよびＩＸは、図２に関して上記で説明したステップと同じであり、そのため再び説明しない。
【００８０】
この実施形態では、要求ステップＸは、２つの下位ステップＸａおよびＸｂを備える。要求側エンティティ５０は、下位ステップＸａで、例えばＸＯＲ関数などのセキュアな関数を用いて、受信した第１および第２の真正性リファレンス部ａｒｔ１およびａｒｔ２から主要真正性リファレンスａｒｔを計算する。これは、この実施形態によると、要求側エンティティ５０がこのセキュアな関数を知っていなければならないことを意味する。
【００８１】
下位ステップＸｂで、要求側エンティティ５０は、主要真正性リファレンスａｒｔをＩＤプロバイダ４０に送信する。
【００８２】
ステップＸＩで、ＩＤプロバイダ４０は、受信した主要真正性リファレンスａｒｔが有効であるかどうか、すなわちそれが、ＩＤプロバイダが以前に発行し、削除あるいは失効していない、あるいはその他の理由で無効となっていない、記憶された主要真正性リファレンスと対応するかどうかを確認する。
【００８３】
ステップＸＩＩで、ＩＤプロバイダ４０は、要求側エンティティ５０から以前に送信された、記憶された主要真正性リファレンスａｒｔを除去あるいは削除する。これにより、その主要真正性リファレンスがそれ以上どのような認証目的にも使用できなくなることが保証される。
【００８４】
ステップＸＩで送信された主要真正性リファレンスが有効であった場合、ＩＤプロバイダ４０は、応答ステップＸＩＩＩで、ＩＤ関連情報ＩＲＩを伴う応答を要求側エンティティ５０に送信する。そうでない場合、ＩＤプロバイダ４０は、応答ステップＸＩＩＩで、送信された主要真正性リファレンスが無効であったことを知らせるエラー・メッセージを要求側エンティティに送信する。
【００８５】
ステップＸＩＶおよびＸＶは、図２に関して上記で説明したステップと同じであり、そのため再び説明しない。
【００８６】
図３による実施形態では、ＩＤプロバイダ４０と要求側エンティティ５０は、セキュアな関数を知っていなければならない。それに対し、ＩＤプロバイダ４０のデータベースは、主要真正性リファレンスａｒｔだけを記憶すればよく、真正性リファレンス部ａｒｔ１およびａｒｔ２はどちらも記憶しなくてよい。また、要求ステップでは、主要真正性リファレンスａｒｔのみが送信されればよい。
【００８７】
他のソリューションも可能であることに留意されたい。例えば、ＩＤプロバイダ４０は主要アーティファクトａｒｔのみを記憶し、要求側エンティティ４０はセキュアな関数を知らず、要求ステップで第１および第２の真正性リファレンス部ａｒｔ１およびａｒｔ２を送信し、ＩＤプロバイダ４０は、受信した第１および第２の真正性リファレンス部ａｒｔ１およびａｒｔ２から主要真正性リファレンスａｒｔを計算し、それに一致する有効な主要真正性リファレンスａｒｔを自身が記憶しているかどうかを確認する。
【００８８】
図４〜図９は、図２または図３あるいはその両方に示す方法のステップの一部で送信されることが可能な通信メッセージの例示的実施形態を示す。図４〜図９に示す例示メッセージは、ハイパー・テキスト転送プロトコル、バージョン１．１（ＨＴＴＰ１．１）に基づく。
【００８９】
図４は、ステップＩＶｄでクライアント・アプリケーション３０からＩＤプロバイダ４０に送信されることが可能な通信メッセージの例示的実施形態を示す。この実施形態では、ＨＴＴＰ認証が使用される。クライアント・アプリケーション３０は、アドレスとしてシングル・サインオン・ページＳＳＯｐａｇｅを備え、クエリ・フィールドに第１の真正性リファレンス部ａｒｔ１を備えるＧＥＴ要求をＩＤプロバイダ４０に送信する。（ホストの）ＩＤプロバイダのサーバの名前は、ＩＤプロバイダ．ｏｒｇであり、クライアント・アプリケーション３０のブラウザの名前はＸＹＺ．１．０．８である。この通信メッセージのリファラ要素は、クライアント・アプリケーション３０の前回の宛先ＵＲＬ、この例ではサイト間転送ＩＳＴページを備える。このリファラ要素は、一般に、通信メッセージのヘッダ内に割り当てられる。このヘッダのさらなるフィールドで、クライアント・アプリケーションは、ユーザの資格証明、例えばユーザ名およびパスワードを、ＩＤプロバイダ４０に送信する。
【００９０】
図５は、ステップＩＶｄでクライアント・アプリケーション３０からＩＤプロバイダ４０に送信されることが可能な通信メッセージの別の例示的実施形態を示す。この実施形態では、ＨＴＭＬフォームに基づく認証が使用される。したがって、ＧＥＴコマンドの代わりにＰＯＳＴコマンドが送信され、ＨＴＭＬフォームは、ユーザの資格証明を備える。
【００９１】
図６は、ステップＶＩＩＩでＩＤプロバイダ４０からクライアント・アプリケーション３０に送信されることが可能な通信メッセージの例示的実施形態を示す。これは、要求側エンティティ５０にあるサーバのアサーション・コンシューマ・サービスページＡＣＳｐａｇｅ、ｄｅ．ｒｅｑｕｅｓｔｉｎｇｅｎｔｉｔｙ．ｏｒｇに行くようにクライアント・アプリケーション３０に要求する、ＩＤプロバイダ４０のリダイレクト・コマンドである。このメッセージのクエリ・フィールドは、第２の真正性リファレンス部ａｒｔ２を備える。
【００９２】
図７は、ステップＩＸでクライアント・アプリケーション３０から要求側エンティティ５０に送信されることが可能な通信メッセージの例示的実施形態を示す。クライアント・アプリケーション３０は、要求側エンティティ５０にＧＥＴ要求を送信して、ＡＣＳｐａｇｅを入手するように要求する。このメッセージは、クエリ・フィールドに第２の真正性リファレンス部ａｒｔ２を備える。（ホストの）要求側エンティティ５０のサーバの名前は、ｄｅ．ｒｅｑｕｅｓｔｉｎｇｅｎｔｉｔｙ．ｏｒｇである。この通信メッセージのリファラ要素は、クライアント・アプリケーション３０の前回の宛先ＵＲＬ、https://idprovider.org/SSOpage?...art1を備える。したがって、リファラ要素のクエリ・フィールドは、第１の真正性リファレンス部ａｒｔ１を備える。したがって、この通信メッセージは、第１の真正性リファレンス部ａｒｔ１ならびに第２の真正性リファレンス部ａｒｔ２を備える。
【００９３】
図８は、ステップＸＩＶで要求側エンティティ５０からクライアント・アプリケーション３０に送信される通信メッセージの例示的実施形態を示す。このメッセージは、結果としてのＨＴＭＬページを備える。
【００９４】
図９は、ステップＸＶでクライアント・アプリケーション３０から要求側エンティティ５０に送信されることが可能な通信メッセージの例示的実施形態を示す。クライアント・アプリケーション３０は、ｏｔｈｅｒｐａｇｅという名前の宛先ページを備えているｏｔｈｅｒｈｏｓｔ．ｏｒｇという名前の別のサーバにＧＥＴ要求を送信する。この通信メッセージのリファラ要素は、クライアント・アプリケーション３０の前回の宛先ＵＲＬを備える。この例では、前回の宛先ＵＲＬは、ＵＲＬ、https:// de.requestingentity.org/ACSpage?...art2である。このＵＲＬのクエリ・フィールドは、なお第２の真正性リファレンス部ａｒｔ２を備えるが、この通信メッセージは、第１の真正性リファレンス部ａｒｔ１はもはや備えていない。したがって、敵対者が図９に示すこの通信メッセージへのアクセス権を得ても、役に立たない。
【００９５】
図１０は、本発明の第３の実施形態のメッセージ・フローの概略図である。ステップＩ〜ＩＶは、図２に関して上記で説明したステップと同じであり、そのため再び説明しない。ステップＶａで、ＩＤプロバイダ４０は、配信された認証情報、例えばパスワードあるいはＰＩＮが正しいかどうかを調べる。正しい場合、ユーザは、ＩＤプロバイダ４０に対する自身の認証に成功している。さらなるステップＶｂで、ＩＤプロバイダ４０は、クライアント・アプリケーションがそれぞれリファラ機能を備え、使用するかどうかを調べる。リファラ機能を備え、使用する場合、この方法は、図２または図３に記載されるステップに続くことができる。ＩＤプロバイダ４０が、クライアント・アプリケーション３０がリファラ機能を使用していないと認識した場合は、以下のステップが行われる。第２の真正性リファレンス生成ステップＶＩで、ＩＤプロバイダ４０は、権限付与が成功したユーザに第２の真正性リファレンス部ａｒｔ２を生成する。その代法として、第２の真正性リファレンス部ａｒｔ１が再度使用されてもよい。第２の真正性リファレンス部ａｒｔ２は、ランダムな要素、擬似ランダムな要素、またはその他の形で推測が困難な要素である。
【００９６】
ステップＶＩＩで、ＩＤプロバイダ４０は、第２の真正性リファレンス部ａｒｔ２を記憶する。
【００９７】
第１のリダイレクト下位ステップＶＩＩＩで、ＩＤプロバイダ４０は、クライアント・アプリケーション３０にリダイレクト・コマンドを送信する。このリダイレクト・コマンドは、要求側エンティティ５０のＡＣＳ（アサーション・コンシューマ・サービス）−ＵＲＬを備え、このＡＣＳ−ＵＲＬは、クエリ・フィールドに第２の真正性リファレンス部ａｒｔ２を備える。第２のリダイレクト下位ステップＩＸで、クライアント・アプリケーション３０は、要求されている要求側エンティティのＡＣＳ−ＵＲＬを備えるＧＥＴ要求を、要求側エンティティ５０に送信し、この要求されるＡＣＳ−ＵＲＬは、第２の真正性リファレンス部を備える。要求ステップＸで、要求側エンティティ５０は、第２の真正性リファレンス部ａｒｔ２を、ＩＤプロバイダ４０のアサーション・レスポンス・サービスアドレスＡＲＳに送信する。ステップＸＩで、ＩＤプロバイダ４０は、第２の真正性リファレンス部ａｒｔ２が有効であるかどうかを確認する。ステップＸＩＩで、ＩＤプロバイダ４０は、第２の真正性リファレンス部ａｒｔ２を除去あるいは削除する。
【００９８】
ステップＸで送信された第２の真正性リファレンス部ａｒｔ２が有効であった場合、ＩＤプロバイダ４０は、応答ステップＸＩＩＩで、ＩＤ関連情報ＩＲＩを伴う応答を要求側エンティティ５０に送信する。そうでない場合、ＩＤプロバイダ４０は、応答ステップＸＩＩＩで、受信された真正性リファレンス部ａｒｔ２が無効であったことを知らせるエラー・メッセージを要求側エンティティ５０に送信する。
【００９９】
ステップＸＩＶおよびＸＶは、この場合も図２および図３に関して説明した通りである。
【０１００】
この実施形態は、クライアント・アプリケーション３０が時にリファラ機能のある通信プロトコルを用い、時にリファラ機能のない通信プロトコルを用いる用途、あるいはクライアント・アプリケーションのリファラ機能がユーザによってオフにされる可能性のある用途に特に適する。
【０１０１】
図１１は、本発明の第４の実施形態のメッセージ・フローの模式図を示す。ステップＩ〜ＸＶは、図３に関して上記で説明したステップと概ね同様であり、したがってその全体は再度説明しない。この実施形態によると、クライアント・アプリケーション３０は、例えば携帯電話などのモバイル機器のＷＡＰ（ワイヤレス・アプリケーション・プロトコル）ブラウザである。ＷＡＰは、いくつかのモバイル固有の追加事項を追加してウェブ・ブラウザと同等のサービスを提供するように設計され、非常に小型の携帯型機器の制約に対応するように特に設計されている。この実施形態によると、ＷＡＰゲートウェイ・サーバ６０が、ＷＡＰフォーマットとＨＴＴＰフォーマット間のインタフェースとして提供される。ＷＡＰゲートウェイ・サーバ６０は、それぞれ、ＩＤプロバイダ４０または要求側エンティティ５０から到着するＨＴＴＰフォーマットのメッセージをＷＡＰフォーマットのメッセージに翻訳あるいは変換する。一方、ＷＡＰゲートウェイ・サーバ６０は、クライアント・アプリケーション３０からのＷＡＰフォーマットのメッセージを、ＩＤプロバイダ４０または要求側エンティティ５０に転送されることが可能なＨＴＴＰフォーマットのメッセージに変換する。
【０１０２】
この変換は下記のステップで行われる。下位ステップＩＩａで、要求側エンティティ５０は、クライアント・アプリケーション３０にＩＤプロバイダ情報（ＩＰＩ）を要求する。ＷＡＰゲートウェイ・サーバ６０は、そのＨＴＴＰ要求をＷＡＰ要求に変換する。クライアント・アプリケーション３０すなわちＷＡＰブラウザは、次いで下位ステップＩＩｃで、ＷＡＰゲートウェイ６０にＩＤプロバイダ情報ＩＰＩを送信し、ＷＡＰゲートウェイ６０は、そのＷＡＰメッセージをＨＴＴＰフォーマットに変換し、要求側エンティティ５０に転送する。それに対応する形で、ＨＴＴＰフォーマットからＷＡＰフォーマットへのそのような変換とその逆の変換が、リダイレクト・ステップＩＩＩ、第１の真正性リファレンス通信ステップＩＶｂ、ＩＶｄ、および、第２の真正性リファレンス通信ステップＶＩＩＩ、ＩＸで行われる。
【０１０３】
本発明は、上記の実施形態以外に、各種の他の分野への適用が可能である。さらなる例として、本発明は、インターネットを介した音声または映像あるいはその両方の送信の認証に使用することができる。その例では、要求側エンティティ５０は、音声データまたは映像データあるいはその両方のコンテンツ・プロバイダであり、クライアント・アプリケーション３０はコンテンツ・プレーヤであることが考えられる。コンテンツ・プレーヤは、コンテンツ・ストリームを入手する要求をコンテンツ・プロバイダに送信し、認証は上記の方法の１つに従って行われ、コンテンツ・プロバイダは、応答としてコンテンツ・ストリームをコンテンツ・プレーヤに送信する。
【０１０４】
本発明は、各種の標準、特にＯＡＳＩＳセキュリティ・アサーション・マークアップ言語、Ｌｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅ  Ｐｒｏｊｅｃｔ、およびＷＳ-Ｆｅｄｅｒａｔｉｏｎに適用することができる。
【０１０５】
ここに開示される実施形態はいずれも、本明細書に図示または記載される、あるいは図示および記載される他の実施形態の１つまたはいくつかと組み合わせてよい。そのことは、それら実施形態の１つまたは複数の特徴についても可能である。
【０１０６】
本発明は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアとの組合せとして実現することができる。任意種のコンピュータ・システムまたは本明細書に記載される方法を実施するように適合された他の装置が適する。ハードウェアとソフトウェアの典型的な組合せは、ロードされ、実行されると本明細書に記載される方法を実施するようにコンピュータ・システムを制御するコンピュータ・プログラムを有する汎用コンピュータ・システムである。本発明は、コンピュータ・プログラム製品に埋め込まれることもでき、コンピュータ・プログラム製品は、本明細書に記載される方法の実装を可能にするすべての機能を備え、コンピュータ・システムにロードされるとそれらの方法を実施することができる。
【０１０７】
本発明の文脈におけるコンピュータ・プログラム手段またはコンピュータ・プログラムとは、情報処理機能を有するシステムに、直接、またはａ）別の言語、コード、または表記法への変換、ｂ）異なる材料形態での再現のどちらかまたは両方の後に、特定の機能を行わせる命令セットの、任意の言語、コード、または表記法での表現を意味する。
【図面の簡単な説明】
【０１０８】
【図１】本発明によるシステムの模式図である。
【図２】本発明による第１の実施形態のメッセージ・フローの模式図である。
【図３】本発明による第２の実施形態のメッセージ・フローの模式図である。
【図４】通信メッセージの例示的実施形態の模式図である。
【図５】通信メッセージの例示的実施形態の模式図である。
【図６】通信メッセージの例示的実施形態の模式図である。
【図７】通信メッセージの例示的実施形態の模式図である。
【図８】通信メッセージの例示的実施形態の模式図である。
【図９】通信メッセージの例示的実施形態の模式図である。
【図１０】本発明の第３の実施形態のメッセージ・フローの模式図である。
【図１１】本発明の第４の実施形態のメッセージ・フローの模式図である。
【図１】
2009521046.tif 000003
【図２】
2009521046.tif 000004
【図３】
2009521046.tif 000005
【図４】
2009521046.tif 000006
【図５】
2009521046.tif 000007
【図６】
2009521046.tif 000008
【図７】
2009521046.tif 000009
【図８】
2009521046.tif 000010
【図９】
2009521046.tif 000011
【図１０】
2009521046.tif 000012
【図１１】
2009521046.tif 000013
2009521046.tif 000014
【国際調査報告】
2009521046.tif 000015
2009521046.tif 000016