(57)【要約】【課題】  マークアップ言語で使用されるメッセージに対する構造体の規約が、多様な認証方法の種類を有して実現されることで、クライアントとサーバ間の認証方法の種類を多様に選択し得るマークアップ言語を使用する有無線通信システムにおける認証方法を提供する。また、クライアントとサーバ間の認証方法の種類を動的に選択することで、強力な双方向の認証を可能にするマークアップ言語を使用する有無線通信システムにおける認証方法を提供する。【解決手段】  マークアップ言語の構造体を宣言するＤＴＤに多様な認証方法の種類を宣言し、該宣言された多様な認証方法の種類中、クライアントとサーバ間で行われる認証方法の種類を動的に選択することで、マークアップ言語を使用する有無線通信システムにおける認証を行う。【選択図】図１
2005004769.tif 000002
【特許請求の範囲】
【請求項１】
マークアップ言語（ｍａｒｋｕｐ  ｌａｎｇｕａｇｅ）の構造体を宣言するＤＴＤに多様な認証方法の種類を宣言し、
該宣言された多様な認証方法の種類中、クライアントとサーバ間で行われる認証方法の種類を動的に選択することを特徴とするマークアップ言語を使用する有無線通信システムにおける認証方法。
【請求項２】
前記多様な認証方法の種類は、
アイデンティティ／パスワードに基づく認証方法、ＭＤ５に基づく認証方法、ＯＴＰ（ｏｎｅ  ｔｉｍｅ  ｐａｓｓｗｏｒｄ）に基づく認証方法、ＴｏｋｅｎＣａｒｄに基づく認証方法及びＴＬＳ（ｔｒａｎｓｐｏｒｔ  ｌａｙｅｒ  ｓｅｃｕｒｉｔｙ）を利用した認証書に基づく認証方法を含むことを特徴とする請求項１記載のマークアップ言語を使用する有無線通信システムにおける認証方法。
【請求項３】
前記多様な認証方法の種類の宣言は、ＥＡＰ（ｅｘｔｅｎｓｉｂｌｅ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｐｒｏｔｏｃｏｌ）を利用することを特徴とする請求項１記載のマークアップ言語を使用する有無線通信システムにおける認証方法。
【請求項４】
前記クライアント及び前記サーバは、認証手順を行う前に、互いに使用し得る認証方法の種類を一致させることを特徴とする請求項１記載のマークアップ言語を使用する有無線通信システムにおける認証方法。
【請求項５】
前記クライアントにより接続要求が伝送されると、前記サーバは、認証方法の種類中いずれか一つを任意に選択し、該任意に選択された認証方法の種類による保安情報を前記クライアントに要求することを特徴とする請求項１記載のマークアップ言語を使用する有無線通信システムにおける認証方法。
【請求項６】
前記任意に選択された認証方法の種類及び該認証方法の種類による保安情報の要求を含む要求メッセージは、前記サーバから前記クライアントに伝送されることを特徴とする請求項５記載のマークアップ言語を使用する有無線通信システムにおける認証方法。
【請求項７】
前記要求メッセージを受信した前記クライアントは、
前記要求メッセージから認証方法の種類及び保安情報の要求を検出し、
前記認証方法の種類による保安情報を応答として前記サーバに伝送することを特徴とする請求項６記載のマークアップ言語を使用する有無線通信システムにおける認証方法。
【請求項８】
前記認証方法の種類の検出は、
前記要求メッセージから＜ＥＡＰ＞要素を検出し、
該＜ＥＡＰ＞要素に含まれた＜ＥＡＰＤａｔａ＞要素の＜ＤａｔａＫｉｎｄ＞要素が有する情報を検出することで行われることを特徴とする請求項７記載のマークアップ言語を使用する有無線通信システムにおける認証方法。
【請求項９】
前記要求メッセージは、ランダム値を更に含むことを特徴とする請求項７記載のマークアップ言語を使用する有無線通信システムにおける認証方法。
【請求項１０】
前記認証方法の種類による応答は、
前記要求メッセージからランダム値を検出し、
該検出されたランダム値、保安情報及び設定された値を、前記検出された認証方法の種類によって処理した結果値を含むことを特徴とする請求項９記載のマークアップ言語を使用する有無線通信システムにおける認証方法。
【請求項１１】
前記設定された値は、前記クライアントを確認し得る他の値を含むことを特徴とする請求項１０記載のマークアップ言語を使用する有無線通信システムにおける認証方法。
【請求項１２】
前記サーバは、
前記クライアントに要求した保安情報をデータベースからフェッチし、
該フェッチされた保安情報を前記任意に選択された認証方法の種類によって処理し、
該処理された値と前記クライアントから伝送された応答とを比較して認証の成功可否を決定することを特徴とする請求項７記載のマークアップ言語を使用する有無線通信システムにおける認証方法。
【請求項１３】
クライアントとサーバ間の互いに一致する認証方法の種類を認知する過程と、
前記一致する認証方法の種類中、任意の認証方法の種類を利用して前記サーバが前記クライアントを認証する過程と、
前記一致する認証方法の種類中、他の任意の認証方法の種類を利用して前記クライアントが前記サーバを認証する過程と、を行うことを特徴とするマークアップ言語を使用する有無線通信システムにおけるクライアントとサーバ間の認証方法。
【請求項１４】
前記認証方法の種類は、マークアップ言語の構造体を宣言するＤＴＤ（ｄｏｃｕｍｅｎｔ  ｔｙｐｅ  ｄｅｆｉｎｉｔｉｏｎ）にＥＡＰ（ｅｘｔｅｎｓｉｂｌｅ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｐｒｏｔｏｃｏｌ）を利用して定義されることを特徴とする請求項１３記載のマークアップ言語を使用する有無線通信システムにおけるクライアントとサーバ間の認証方法。
【請求項１５】
前記認証方法の種類は、
アイデンティティ／パスワードに基づく認証方法、ＭＤ５に基づく認証方法、ＯＴＰ（ｏｎｅ  ｔｉｍｅ  ｐａｓｓｗｏｒｄ）に基づく認証方法、ＴｏｋｅｎＣａｒｄに基づく認証方法及びＴＬＳ（ｔｒａｎｓｐｏｒｔ  ｌａｙｅｒ  ｓｅｃｕｒｉｔｙ）を利用した認証書に基づく認証方法を含むことを特徴とする請求項１３記載のマークアップ言語を使用する有無線通信システムにおけるクライアントとサーバ間の認証方法。
【請求項１６】
前記任意の認証方法の種類及び前記他の任意の認証方法の種類は、互いに異なることを特徴とする請求項１３記載のマークアップ言語を使用する有無線通信システムにおけるクライアントとサーバ間の認証方法。
【請求項１７】
前記任意の認証方法の種類及び前記他の任意の認証方法の種類は、互いに同様であることを特徴とする請求項１３記載のマークアップ言語を使用する有無線通信システムにおけるクライアントとサーバ間の認証方法。
【請求項１８】
多様な認証方法の種類をＥＡＰ要素を利用して宣言したＸＭＬ  ＤＴＤと、
前記宣言された多様な認証方法の種類中、任意の認証方法の種類情報を有するＥＡＰ要素を含む認証メッセージと、を含むことを特徴とするマークアップ言語を使用する有無線通信システムの認証プロトコル。
【請求項１９】
前記ＥＡＰ要素は、
認証メッセージの種類を示す＜Ｃｏｄｅ＞要素と、前記認証メッセージを識別するための＜Ｉｄｅｎｔｉｆｉｅｒ＞要素とを必ず含み、前記認証メッセージの実際的なデータを取り込むための＜ＥＡＰＤａｔａ＞を選択的に含むことを特徴とする請求項１８記載のマークアップ言語を使用する有無線通信システムの認証プロトコル。
【請求項２０】
前記＜ＥＡＰＤａｔａ＞要素は、
前記データの種類を示す＜ＤａｔａＫｉｎｄ＞要素と、
前記任意の認証方法の種類情報を有する情報要素と、を含むことを特徴とする請求項１９記載のマークアップ言語を使用する有無線通信システムの認証プロトコル。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マークアップ言語（ｍａｒｋｕｐ  ｌａｎｇｕａｇｅ）を使用する有無線通信システムにおける認証に係るもので、詳しくは、ｓｙｎｃＭＬを使用する有無線通信システムにおけるクライアントとサーバ間の認証方法に関するものである。
【背景技術】
【０００２】
一般に、マークアップ言語を使用する有無線通信システムにおいては、クライアントとサーバ間の認証が要求される接続である場合、認証が成功すると、前記接続が維持されて次の手順へと進行される。
【０００３】
例えば、同一データが有無線網及び端末機に分散されて存在することで、データ同期化が必要である場合、互いにデータ同期化を維持すべきであるクライアントとサーバとの間に認証過程が要求される。
【０００４】
ＳｙｎｃＭＬ（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  Ｍａｋｒｕｐ  Ｌａｎｇｕａｇｅ）は、データ同期化のための標準プロトコルであって、ウエブポータル（ｐｏｒｔａｌ）の個人情報、携帯電話の個人情報及びＰＣの個人情報などの同期化に利用される。また、ＳｙｎｃＭＬは、個人情報管理だけでなく、電子メール及びテキストメモ帳などの多様な応用サービスタイプに対するデータ同期化機能を支援することができる。
【０００５】
図９はｓｙｎｃＭＬを使用する通信システムにおけるデータ同期化時、一般のクライアントとサーバ間の認証方法を示した図である。
【０００６】
図示したように、ｓｙｎｃＭＬを利用してクライアントとサーバ間のデータ同期化を行う場合、クライアントは、サーバにデータ同期化を要求する（Ｓ１０）。次いで、サーバは、前記クライアントにアイデンティティ及びパスワードを要求し（Ｓ１２）、前記クライアントは、自身のアイデンティティ及びパスワードをエンコーディングするか、又はＭＤ５のようなアルゴリズムにより圧縮した後にエンコーディングし、該エンコーディングされたアイデンティティ及びパスワードを前記サーバに伝送する（Ｓ１４）。次いで、前記サーバは、前記伝送されたアイデンティティ及びパスワードを確認し、認証成功可否を前記クライアントに知らせる（Ｓ１６）。
このとき、前記クライアントの認証が成功された場合、前記サーバは、前記クライアントに認証を受けるために、自身のアイデンティティ及びパスワードを前記クライアントに伝送する。次いで、前記クライアントは、前記伝送されたアイデンティティ及びパスワードを確認し、前記サーバの認証成功可否を前記サーバに知らせる。
【０００７】
このような方法により双方向の認証が成功的に終了すると、前記クライアントと前記サーバ間では、変更されたデータに対する双方向又は単方向のデータ同期化手順が行われる。
【特許文献１】韓国特許出願公開第２００２−００９３２６３号明細書
【特許文献２】韓国特許出願公開第２００３−０００８１８０号明細書
【特許文献３】特開２００２−２９７５４７号公報
【特許文献４】米国特許出願公開第２００２／０１４７９２６号明細書
【特許文献５】欧州特許第０９０６６８２号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００８】
然るに、このような一般のマークアップ言語を使用する通信システムにおける一般の認証方法は、認証方法の種類がアイデンティティに対するパスワード等により固定されているため、該固定された認証方法のみで認証過程を行うべきであり、且つ、固定された認証方法による保安情報が漏出される危険が大きいため、保安上に脆弱点があるという不都合な点があった。
【０００９】
また、このような一般の認証プロトコルにおける保安上の脆弱点を補完するために、別途の認証サーバが利用されるが、この場合、認証サーバを別途に設置すべきであるため、煩雑であるという不都合な点があった。
【００１０】
本発明は、このような従来の課題に鑑みてなされたもので、マークアップ言語で使用されるメッセージに対する構造体の規約が、多様な認証方法の種類を有して実現されることで、クライアントとサーバ間の認証方法の種類を多様に選択し得るマークアップ言語を使用する有無線通信システムにおける認証方法を提供することを目的とする。
【００１１】
また、クライアントとサーバ間の認証方法の種類を動的に（ｄｙｎａｍｉｃ）選択することで、強力な双方向の認証を可能にするマークアップ言語を使用する有無線通信システムにおける認証方法を提供することを目的とする。
【課題を解決するための手段】
【００１２】
このような目的を達成するため、本発明に係るマークアップ言語を使用する有無線通信システムにおける認証方法は、マークアップ言語の構造体を宣言するＤＴＤに多様な認証方法の種類を宣言し、該宣言された多様な認証方法の種類中、クライアントとサーバ間で行われる認証方法の種類を動的に選択することを特徴とする。
【００１３】
また、前記クライアントにより接続要求が伝送されると、前記サーバは、認証方法の種類中いずれか一つを任意に選択し、該任意に選択された認証方法の種類による保安情報を前記クライアントに要求することを特徴とする。
【００１４】
且つ、本発明に係るマークアップ言語を使用する有無線通信システムにおけるクライアントとサーバ間の認証方法は、クライアントとサーバ間の互いに一致する認証方法の種類を認知する過程と、前記一致する認証方法の種類中、任意の認証方法の種類を利用して前記サーバが前記クライアントを認証する過程と、前記一致する認証方法種類中、他の任意の認証方法の種類を利用して前記クライアントが前記サーバを認証する過程と、を行うことを特徴とする。
【００１５】
また、前記任意の認証方法の種類及び前記他の任意の認証方法の種類は、互いに異なるか、又は同様であることを特徴とする。
【００１６】
且つ、本発明に係るマークアップ言語を使用する有無線通信システムの認証プロトコルは、多様な認証方法の種類をＥＡＰ要素を利用して宣言したＸＭＬ  ＤＴＤと、該宣言された多様な認証方法の種類中、任意の認証方法の種類情報を有するＥＡＰ要素を含む認証メッセージと、を含むことを特徴とする。
【００１７】
また、前記ＥＡＰ要素は、認証メッセージの種類を示す＜Ｃｏｄｅ＞要素と、前記認証メッセージを識別するための＜Ｉｄｅｎｔｉｆｉｅｒ＞要素とを必ず含み、前記認証メッセージの実際的なデータを取り込むための＜ＥＡＰＤａｔａ＞を選択的に含むことを特徴とする。
【００１８】
また、前記＜ＥＡＰＤａｔａ＞要素は、前記データの種類を示す＜ＤａｔａＫｉｎｄ＞要素と、前記任意の認証方法の種類情報を有する情報要素と、を含むことを特徴とする。
【００１９】
本発明のマークアップ言語を使用する有無線通信システムにおける認証方法は、マークアップ言語（ｍａｒｋｕｐ  ｌａｎｇｕａｇｅ）の構造体を宣言するＤＴＤに多様な認証方法の種類を宣言し、該宣言された多様な認証方法の種類中、クライアントとサーバ間で行われる認証方法の種類を動的に選択することを特徴とし、それにより上記目的が達成される
前記多様な認証方法の種類は、アイデンティティ／パスワードに基づく認証方法、ＭＤ５に基づく認証方法、ＯＴＰ（ｏｎｅ  ｔｉｍｅ  ｐａｓｓｗｏｒｄ）に基づく認証方法、ＴｏｋｅｎＣａｒｄに基づく認証方法及びＴＬＳ（ｔｒａｎｓｐｏｒｔ  ｌａｙｅｒ  ｓｅｃｕｒｉｔｙ）を利用した認証書に基づく認証方法を含むことを特徴とし、それにより上記目的が達成される。
【００２０】
前記多様な認証方法の種類の宣言は、ＥＡＰ（ｅｘｔｅｎｓｉｂｌｅ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｐｒｏｔｏｃｏｌ）を利用することを特徴としてもよい。
【００２１】
前記クライアント及び前記サーバは、認証手順を行う前に、互いに使用し得る認証方法の種類を一致させることを特徴としてもよい。
【００２２】
前記クライアントにより接続要求が伝送されると、前記サーバは、認証方法の種類中いずれか一つを任意に選択し、該任意に選択された認証方法の種類による保安情報を前記クライアントに要求することを特徴としてもよい。
【００２３】
前記任意に選択された認証方法の種類及び該認証方法の種類による保安情報の要求を含む要求メッセージは、前記サーバから前記クライアントに伝送されることを特徴としてもよい。
【００２４】
前記要求メッセージを受信した前記クライアントは、前記要求メッセージから認証方法の種類及び保安情報の要求を検出し、前記認証方法の種類による保安情報を応答として前記サーバに伝送することを特徴としてもよい。
【００２５】
前記認証方法の種類の検出は、前記要求メッセージから＜ＥＡＰ＞要素を検出し、該＜ＥＡＰ＞要素に含まれた＜ＥＡＰＤａｔａ＞要素の＜ＤａｔａＫｉｎｄ＞要素が有する情報を検出することで行われることを特徴としてもよい。
【００２６】
前記要求メッセージは、ランダム値を更に含むことを特徴としてもよい。
【００２７】
前記認証方法の種類による応答は、前記要求メッセージからランダム値を検出し、該検出されたランダム値、保安情報及び設定された値を、前記検出された認証方法の種類によって処理した結果値を含むことを特徴としてもよい。
【００２８】
前記設定された値は、前記クライアントを確認し得る他の値を含むことを特徴としてもよい。
【００２９】
前記サーバは、前記クライアントに要求した保安情報をデータベースからフェッチし、該フェッチされた保安情報を前記任意に選択された認証方法の種類によって処理し、該処理された値と前記クライアントから伝送された応答とを比較して認証の成功可否を決定することを特徴としてもよい。
【００３０】
本発明のマークアップ言語を使用する有無線通信システムにおけるクライアントとサーバ間の認証方法は、クライアントとサーバ間の互いに一致する認証方法の種類を認知する過程と、前記一致する認証方法の種類中、任意の認証方法の種類を利用して前記サーバが前記クライアントを認証する過程と、前記一致する認証方法の種類中、他の任意の認証方法の種類を利用して前記クライアントが前記サーバを認証する過程と、を行うことを特徴とし、それにより上記目的が達成される。
【００３１】
前記認証方法の種類は、マークアップ言語の構造体を宣言するＤＴＤ（ｄｏｃｕｍｅｎｔ  ｔｙｐｅ  ｄｅｆｉｎｉｔｉｏｎ）にＥＡＰ（ｅｘｔｅｎｓｉｂｌｅ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｐｒｏｔｏｃｏｌ）を利用して定義されることを特徴としてもよい。
【００３２】
前記認証方法の種類は、アイデンティティ／パスワードに基づく認証方法、ＭＤ５に基づく認証方法、ＯＴＰ（ｏｎｅ  ｔｉｍｅ  ｐａｓｓｗｏｒｄ）に基づく認証方法、ＴｏｋｅｎＣａｒｄに基づく認証方法及びＴＬＳ（ｔｒａｎｓｐｏｒｔ  ｌａｙｅｒ  ｓｅｃｕｒｉｔｙ）を利用した認証書に基づく認証方法を含むことを特徴としてもよい。
【００３３】
前記任意の認証方法の種類及び前記他の任意の認証方法の種類は、互いに異なることを特徴としてもよい。
【００３４】
前記任意の認証方法の種類及び前記他の任意の認証方法の種類は、互いに同様であることを特徴としてもよい。
【００３５】
本発明のマークアップ言語を使用する有無線通信システムの認証プロトコルは、多様な認証方法の種類をＥＡＰ要素を利用して宣言したＸＭＬ  ＤＴＤと、前記宣言された多様な認証方法の種類中、任意の認証方法の種類情報を有するＥＡＰ要素を含む認証メッセージと、を含むことを特徴とし、それにより上記目的が達成される。
【００３６】
前記ＥＡＰ要素は、認証メッセージの種類を示す＜Ｃｏｄｅ＞要素と、前記認証メッセージを識別するための＜Ｉｄｅｎｔｉｆｉｅｒ＞要素とを必ず含み、前記認証メッセージの実際的なデータを取り込むための＜ＥＡＰＤａｔａ＞を選択的に含むことを特徴としてもよい。
【００３７】
前記＜ＥＡＰＤａｔａ＞要素は、前記データの種類を示す＜ＤａｔａＫｉｎｄ＞要素と、前記任意の認証方法の種類情報を有する情報要素と、を含むことを特徴としてもよい。
【発明の効果】
【００３８】
本発明に係るマークアップ言語を使用する有無線通信システムにおける認証方法は、ＸＭＬ  ＤＴＤに多様な認証方法の種類を宣言して、マークアップ言語を使用するクライアントとサーバ間の認証方法の種類を多様に選択し得るという効果がある。
【００３９】
また、クライアントとサーバ間の認証方法の種類を動的に選択し得るため、強力な双方向の認証が可能であるという効果がある。
【発明を実施するための最良の形態】
【００４０】
以下、本発明の実施の形態に対し、図面に基づいて説明する。
【００４１】
一般に、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ  ｍａｒｋｕｐ  ｌａｎｇｕａｇｅ）に基づいて表現されたメッセージをクライアントとサーバ間で取り交わすことでデータ同期化が行われるが、このようなデータ同期化を行うためのプロトコルは、表現プロトコル（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ  ｐｒｏｔｏｃｏｌ）、同期化プロトコル（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  ｐｒｏｔｏｃｏｌ）及び伝送プロトコル（ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ）により構成される。このとき、前記同期化プロトコルは、クライアントとサーバ間のｓｙｎｃＭＬメッセージの交換方法及び手順、同期化遂行方法並びに同期化タイプを定義する。また、前記伝送プロトコルは、メッセージ伝送のためにＨＴＴＰ（ｈｙｐｅｒ  ｔｅｘｔ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ）及びＷＳＰ（ｗｉｒｅｌｅｓｓ  ｓｅｓｓｉｏｎ  ｐｒｏｔｏｃｏｌ）などの既存の伝送プロトコルを利用し得るようにバインディング規則を定義する。
【００４２】
また、前記表現プロトコルは、同期化のためのＸＭＬ  ＤＴＤ（ｄｏｃｕｍｅｎｔ  ｔｙｐｅ  ｄｅｆｉｎｉｔｉｏｎ）を定義し、ｓｙｎｃＭＬメッセージに対する構造体の規約である。このとき、ＸＭＬ  ＤＴＤは、ＸＭＬ文書で使用されるマークアップを宣言したもので、文書に対する論理構造及び物理構造を定義する。
【００４３】
一般に、作成された文書の内容を全ての使用者が認識するためには、文書を作成するときに使用した言語規則を全ての使用者に性格に伝達すべきであって、ＸＭＬは、ＤＴＤを使用して言語規則を明示している。即ち、ＤＴＤは、ＸＭＬ文書で使用される要素（ｅｌｅｍｅｎｔ）、要素の属性（ａｔｔｒｉｂｕｔｅ）、各要素間の関係及び個体（ｅｎｔｉｔｙ）などを記述する部分である。
【００４４】
本発明は、多様な認証方法の種類をＸＭＬ  ＤＴＤに予め定義し、クライアント及びサーバは、前記定義された多様な認証方法中、任意のいくつかの認証方法を選択する。次いで、接続を設定すべきクライアント及びサーバは、互いに各自が有する認証方法の種類を比較し、互いに一致する認証方法の種類を認知する。その後、データ同期化のための双方向の認証時、クライアント及びサーバは、互いに一致する認証方法の種類を相手側に動的に提示することで、一層多様で且つ安全な認証手順を行うことができる。
【００４５】
本発明は、クライアントとサーバ間において、任意に認証方法を選択して決定し得る拡張認証方法のための新しいｓｙｎｃＭＬスキーマ（ｓｃｈｅｍａ）を更に定義し、図１に示したＸＭＬ  ＤＴＤを設計する。
【００４６】
図１は本発明に係るＸＭＬ  ＤＴＤを示した図である。本発明に係るＸＭＬ  ＤＴＤは、多様な認証方法の種類を備えるように、ＩＥＴＦ  ＲＦＣ２２８４で定義しているＥＡＰ（ｅｘｔｅｎｓｉｂｌｅ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｐｒｏｔｏｃｏｌ）によるスキーマを含んでいる。
【００４７】
本発明に係るＸＭＬ  ＤＴＤは、本発明で使用されるＳｙｎｃＭＬメッセージの構造を説明するが、前記ＸＭＬ  ＤＴＤによると、ＳｙｎｃＭＬのメッセージは、ヘッダー要素（＜ＳｙｎｃＨｄｒ＞）及びボディー要素（＜ＳｙｎｃＢｏｄｙ＞）により構成され、前記ヘッダー要素（＜ＳｙｎｃＨｄｒ＞）は、ＤＴＤバージョン（＜ＶｅｒＤＴＤ＞）、プロトコルバージョン（＜ＶｅｒＰｒｏｔｏ＞）、メッセージＩＤ（＜ＭｓｇＩＤ＞）、＜Ｔａｒｇｅｔ＞、＜Ｓｏｕｒｃｅ＞、＜ＲｅｓｐＵＲＩ＞、＜ＮｏＲｅｓｐ＞、＜Ｃｒｅｄ＞、＜Ｍｅｔａ＞及び＜ＥＡＰ＞の要素を含んでいる。これら中、前記＜Ｔａｒｇｅｔ＞、＜Ｓｏｕｒｃｅ＞、＜ＲｅｓｐＵＲＩ＞、＜ＮｏＲｅｓｐ＞、＜Ｃｒｅｄ＞及び＜Ｍｅｔａ＞の各要素は、本発明に係る拡張認証プロトコルと関連性が少ないので、その説明を省略する。また、前記ボディー要素は、データ同期化手順を行うための複数のコマンド（ｃｏｍｍａｎｄ）を含むが、ここでは説明を省略する。
【００４８】
前記＜ＥＡＰ＞要素は、＜Ｃｏｄｅ＞要素及び＜Ｉｄｅｎｔｉｆｉｅｒ＞要素を必ず含み、＜ＥＡＰｄａｔａ＞要素は選択的に含んでいる。また、前記＜Ｃｏｄｅ＞要素は、ＥＡＰメッセージの種類を示すもので、Ｒｅｑｕｅｓｔ、Ｒｅｓｐｏｎｓｅ、Ｓｕｃｃｅｓｓ及びＦａｉｌなどの情報を有する。また、前記＜Ｉｄｅｎｔｉｆｉｅｒ＞要素は、ＥＡＰメッセージを識別するための識別子である。また、前記＜ＥＡＰｄａｔａ＞要素は、ＥＡＰメッセージの実際的なデータが載せられる要素であって、主に認証に関する情報を含む要素である。また、前記＜ＥＡＰＤａｔａ＞要素は、＜ＤａｔａＫｉｎｄ＞要素だけでなく、＜Ｉｄｅｎｔｉｔｙ＞、＜Ｎｏｔｉｆｉｃａｔｉｏｎ＞、＜Ｎａｋ＞、＜ＭＤ５Ｃｈａｌ＞、＜ＯＴＰ＞、＜ＴｏｋｅｎＣａｒｄ＞及び＜ＴＬＳ（ｔｒａｎｓｐｏｒｔ  ｌａｙｅｒ  ｓｅｃｕｒｉｔｙ）＞中いずれか一つを含んでいる。
【００４９】
また、前記＜Ｉｄｅｎｔｉｔｙ＞要素は、クライアントやサーバのアイデンティティを利用した認証方法を示し、前記＜Ｎｏｔｉｆｉｃａｔｉｏｎ＞要素は、相手方に知らすべき注意事項などを示し、前記＜Ｎａｋ＞要素は、認証が必要でないので応答しないことを示し、前記＜ＭＤ５Ｃｈａｌ＞要素は、ＭＤ５圧縮アルゴリズムを利用してチャレンジ（ｃｈａｌｌｅｎｇｅ）を要求又は応答する時に使用される。また、前記＜ＯＴＰ＞要素は、ワンタイムパスワードアルゴリズムを利用した認証方法を示し、前記＜ＴｏｋｅｎＣａｒｄ＞要素は、スマートカードの入力、瞳の入力及び指紋の入力などの物理的入力による情報（トークン）を利用した認証方法を示し、前記ＴＬＳ（ｔｒａｎｓｐｏｒｔ  ｌａｙｅｒ  ｓｅｃｕｒｉｔｙ）は、ＩＥＴＦにより提案された標準であって、クライアント及びサーバの応用プログラムの変更なしに、保安チャンネル（ｓｅｃｕｒｅ  ｃｈａｎｎｅｌ）を通してデータが伝送されるように、トランスポート層（ｔｒａｎｓｐｏｒｔ  ｌａｙｅｒ）（例えば、ＴＣＰ（ｔｒａｎｓｍｉｓｓｉｏｎ  ｃｏｎｔｒｏｌ  ｐｒｏｔｏｃｏｌ））により暗号化及び認証を提供する認証方法である。例えば、前記＜ＴＬＳ＞要素による認証方法は、認証書を利用した認証方法を示している。
【００５０】
従って、本発明は、アイデンティティ／パスワードに基づく認証方法、ＭＤ５に基づく認証方法、ＯＴＰに基づく認証方法、ＴｏｋｅｎＣａｒｄに基づく認証方法及びＴＬＳを利用した認証書に基づく認証方法などの複数の認証方法の種類を宣言している。
【００５１】
このように、本発明に係るＸＭＬ  ＤＴＤは、複数の認証方法の種類を宣言しているので、ＳｙｎｃＭＬを使用するクライアント及びサーバは、宣言された複数の認証方法の種類中、任意の個数の認証方法の種類を選択的に備えることができる。
【００５２】
また、前記クライアント及びサーバは、認証エージェントをそれぞれ備えていて、該認証エージェントは、複数の認証方法の種類を宣言するために提示されたスキーマにより行われる、ｓｙｎｃＭＬに基づく拡張認証プロトコル手順を行う。
【００５３】
このとき、クライアント及びサーバがそれぞれ備えている認証方法の種類は、異なることもあるため、データ同期化のための認証手順を行う前に、該当のクライアント及びサーバは、各自の認証方法の種類を公開して互いに一致する可用認証方法の種類を認知する。
【００５４】
図２はクライアントとサーバ間の可用認証方法の確認方法を示した図である。
【００５５】
図２に示したように、データ同期化が要求されるクライアント及びサーバである場合、クライアントは、自身が備えている認証方法の種類をサーバに伝送する（Ｓ２０）。次いで、前記クライアントは、前記サーバから該サーバが備えている認証方法の種類を受信する（Ｓ２２）。
【００５６】
次いで、前記クライアントは、該クライアントの認証方法の種類と前記サーバの認証方法の種類とを比較し、互いに一致する可用認証方法の種類を認知する（Ｓ２４）。また、サーバも、前記クライアントの認証方法の種類及びサーバの認証方法の種類中、互いに一致する可用認証方法の種類を認知する。
【００５７】
例えば、前記クライアントが備えている認証方法の種類がＩｄｅｎｔｉｔｙ、ＭＤ５Ｃｈａｌ、ＯＴＰ及びＴＬＳで、前記サーバが備えている認証方法の種類がＩｄｅｎｔｉｔｙ、ＭＤ５Ｃｈａｌ、ＯＴＰ、ＴｏｋｅｎＣａｒｄ及びＴＬＳである場合、前記クライアント及び前記サーバは、互いに一致するＩｄｅｎｔｉｔｙ、ＭＤ５Ｃｈａｌ、ＯＴＰ及びＴＬＳの認証方法の種類を確認する。
【００５８】
次いで、互いに一致する可用認証方法の種類を確認した後、クライアント及びサーバは、データ同期化のための認証手順を行う。
【００５９】
図３はｓｙｎｃＭＬを使用する通信システムにおいて、本発明に係るクライアントとサーバ間のデータ同期化のための認証方法を示した図である。
【００６０】
図３に示したように、クライアントは、サーバにデータ同期化を要求し（Ｓ３０）、前記サーバは、アイデンティティを前記クライアントに要求する（Ｓ３２）。次いで、前記クライアントは、前記要求に従って自身のアイデンティティを前記サーバに伝送する（Ｓ３４）。次いで、前記サーバは、前記クライアントが実際的な前記アイデンティティのクライアントであるかを確認するために、前記クライアントと一致する可用認証方法の種類中、いずれか一つを任意に選択し、該選択された認証方法の種類による前記アイデンティティの保安情報を前記クライアントに要求する（Ｓ３６）。次いで、前記クライアントは、前記選択された認証方法の種類によって前記アイデンティティの保安情報を前記サーバに伝送する（Ｓ３８）。次いで、前記サーバは、前記クライアントから伝送された保安情報が正常な保安情報であると、前記任意に選択された認証方法の種類による認証が成功的に行われたと判断し、成功情報を前記クライアントに伝送する（Ｓ４０）。
【００６１】
その後、前記サーバも前記クライアントに認証を要求し得るが、これに対する動作は前記の場合と同様に行われるので、その説明を省略する。
【００６２】
以下、サーバによるクライアントの認証方法を詳しく説明する。
【００６３】
まず、クライアントは、データ同期化を要求するためにサーバとの接続を試みる。即ち、前記クライアントは、データ同期化要求メッセージ（Ｒｅｑｕｅｓｔ  Ｓｙｎｃ）を生成し、該生成されたメッセージをＴＣＰ／ＩＰ（ｉｎｔｅｒｎｅｔ  ｐｒｏｔｏｃｏｌ）を通してサーバに伝送する（Ｓ３０）。
【００６４】
次いで、前記サーバは、本発明に係る拡張認証プロトコルを使用するために、＜ＥＡＰ＞要素及びその下位要素を利用して、アイデンティティを要求するための第１ＥＡＰ要求メッセージ（ＥＡＰ−Ｒｅｑｕｅｓｔ／Ｉｄｅｎｔｉｔｙ）を、図４のように生成する。次いで、前記第１ＥＡＰ要求メッセージ（ＥＡＰ−Ｒｅｑｕｅｓｔ／Ｉｄｅｎｔｉｔｙ）は、＜ＥＡＰ＞要素の下位要素であって、Ｒｅｑｕｅｓｔを示す＜Ｃｏｄｅ＞要素と、１を示す＜Ｉｄｅｎｔｉｆｉｅｒ＞要素と、＜ＥＡＰＤａｔａ＞要素と、を含む。また、前記＜ＥＡＰＤａｔａ＞要素は、前記選択された認証方法によるアイデンティティを示す＜ＤａｔａＫｉｎｄ＞要素と、前記クライアントが使用者にディスプレイするデータを示す＜Ｄａｔａ＞要素と、を含む。次いで、前記サーバは、生成された前記第１ＥＡＰ要求メッセージ（ＥＡＰ−Ｒｅｑｕｅｓｔ／Ｉｄｅｎｔｉｔｙ）を前記クライアントに伝送する（Ｓ３２）。
【００６５】
次いで、前記クライアントは、受信された第１ＥＡＰ要求メッセージを分析して＜ＥＡＰ＞要素が検出されると、拡張認証プロトコルを使用して認証過程を行うことを認識し、前記＜ＥＡＰ＞要素の＜Ｃｏｄｅ＞要素及び＜ＤａｔａＫｉｎｄ＞要素に基づいて、前記第１ＥＡＰ要求メッセージがアイデンティティを要求する認証メッセージであることを認識した後、それに該当する第１ＥＡＰ応答メッセージ（ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙ）を、図５のように生成する。即ち、前記クライアントは、前記第１ＥＡＰ応答メッセージ（ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙ）に含まれた＜ＥＡＰ＞要素の＜Ｃｏｄｅ＞要素に、応答であることを示すための“Ｒｅｓｐｏｎｓｅ”を記録し、＜ＥＡＰＤａｔａ＞要素の＜ＤａｔａＫｉｎｄ＞要素に“Ｉｄｅｎｔｉｔｙ”を記録し、クライアント自身のアイデンティティが“Ｈｏｎｇ”である場合、＜Ｉｄｅｎｔｉｔｙ＞要素に“Ｈｏｎｇ”を記録する。このようにして、前記クライアントは、生成された前記第１ＥＡＰ応答メッセージ（ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙ）を前記サーバに伝送する（Ｓ３４）。
【００６６】
次いで、前記サーバは、受信された前記第１ＥＡＰ応答メッセージ（ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙ）を分析して、前記第１ＥＡＰ応答メッセージ（ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙ）に含まれた＜ＥＡＰ＞要素の＜Ｃｏｄｅ＞Ｒｅｓｐｏｎｓｅ＜／Ｃｏｄｅ＞、＜ＤａｔａＫｉｎｄ＞Ｉｄｅｎｔｉｔｙ＜／ＤａｔａＫｉｎｄ＞及び＜Ｉｄｅｎｔｉｔｙ＞Ｈｏｎｇ＜／  Ｉｄｅｎｔｉｔｙ  ＞に基づいて、アイデンティティが“Ｈｏｎｇ”であるクライアントが認証を受けることを待っていると認知する。従って、前記サーバは、前記可用認証方法の種類中、いずれか一つを任意に選択し、該選択された認証方法の種類による前記アイデンティティの保安情報を、前記クライアントが真のＨｏｎｇであるかを確認するために、前記クライアントに要求し、実際的な認証過程を行う。
【００６７】
即ち、前記サーバが前記可用認証方法の種類中、任意に選択した認証方法の種類が“ＭＤ５Ｃｈａｌ”である場合、前記サーバは、図６に示したように、＜ＥＡＰ＞要素の＜Ｃｏｄｅ＞に“Ｒｅｑｕｅｓｔ”を記録し、＜ＥＡＰＤａｔａ＞要素の＜ＤａｔａＫｉｎｄ＞要素に“ＭＤ５Ｃｈａｌ”を記録し、＜ＭＤ５Ｃｈａｌ＞要素に任意のランダム値である“９０３８４０２９３０４８０２０３９４８０２３０”を記録し、＜Ｄａｔａ＞要素に“Ｗｈａｔ’ｓ  ｙｏｕｒ  ｐａｓｓｗｏｒｄ？”を記録することで、第２ＥＡＰ要求メッセージ（ＥＡＰ−Ｒｅｑｕｅｓｔ／ｃｈａｌｌｅｎｇｅ）を生成する。また、前記可用認証方法の種類中、任意に選択された認証方法の種類が“ＯＴＰ”である場合、前記サーバは、＜ＤａｔａＫｉｎｄ＞ＯＴＰ＜ＤａｔａＫｉｎｄ＞及び＜ＯＴＰ＞ｘ＜ＯＴＰ＞を含んで、前記第２ＥＡＰ要求メッセージ（ＥＡＰ−Ｒｅｑｕｅｓｔ／ｃｈａｌｌｅｎｇｅ）を生成することができる。前記サーバは、このように生成された前記第２ＥＡＰ要求メッセージ（ＥＡＰ−Ｒｅｑｕｅｓｔ／ｃｈａｌｌｅｎｇｅ）を前記クライアントに伝送する（Ｓ３６）。
【００６８】
次いで、前記第２ＥＡＰ要求メッセージ（ＥＡＰ−Ｒｅｑｕｅｓｔ／ｃｈａｌｌｅｎｇｅ）を受信した前記クライアントは、＜ＥＡＰ＞要素の＜ＤａｔａＫｉｎｄ＞ＭＤ５Ｃｈａｌ＜ＤａｔａＫｉｎｄ＞及び＜ＭＤ５Ｃｈａｌ＞９０３８４０２９３０４８０２０３９４８０２３０＜／ＭＤ５Ｃｈａｌ＞に基づいて、＜ＭＤ５Ｃｈａｌ＞要素に記録されたランダム値と共に前記アイデンティティのパスワード（保安情報）を、ＭＤ５圧縮アルゴリズムを使用して前記サーバに応答すべきであると認知する。
【００６９】
このとき、前記クライアントは、自身のアイデンティティのパスワード（保安情報）を、前記＜ＭＤ５Ｃｈａｌ＞要素に記録されたランダム値と共に、ＭＤ５圧縮アルゴリズムを使用して（数式１）のように応答値を計算する。
【００７０】
ＭＤ５（ランダム値＋パスワード＋α）−−−−−−−−−−−（数式１）
上式中、前記αは、身元を確認し得る予め設定された値を示すもので、例えば、“身分登録番号”を挙げることができる。
【００７１】
即ち、前記クライアントは、受信されたランダム値、自身のパスワード及びαをＭＤ５圧縮アルゴリズムを使用して圧縮するが、圧縮の結果値（応答値）は、常に所定のビット（例えば、１２８ｂｉｔ）を有するため、前記結果値により入力値を知ることはできない。即ち、前記ＭＤ５は非可逆関数であるため、前記圧縮結果値（応答値）が他人に知られるとしても、パスワードを類推することはできない。
【００７２】
前記第２ＥＡＰ要求メッセージ（ＥＡＰ−Ｒｅｑｕｅｓｔ／ｃｈａｌｌｅｎｇｅ）に含まれた＜ＥＡＰ＞要素に＜ＤａｔａＫｉｎｄ＞ＯＴＰ＜ＤａｔａＫｉｎｄ＞及び＜ＯＴＰ＞ｘ＜ＯＴＰ＞が記録された場合、前記クライアントは、受信された前記ｘ及び自身のパスワードを利用して応答値を用意する。
【００７３】
次いで、前記クライアントは、前記応答値を含むように、図７のように第２ＥＡＰ応答メッセージ（ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｃｒｅｄｅｎｔｉａｌｓ）を生成し、該生成された第２ＥＡＰ応答メッセージ（ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｃｒｅｄｅｎｔｉａｌｓ）を前記サーバに伝送する（Ｓ３８）。図７の第２ＥＡＰ応答メッセージ（ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｃｒｅｄｅｎｔｉａｌｓ）において、＜ＭＤ５Ｃｈａｌ＞要素の値として記録された“ｓｌｋｄｊｆｌｓｌｄｊｆｌｊｓｌｄｊｋｆｌｊｌｓｄｊｋｆｔｕｉｒ”が前記応答値を示すものである。
【００７４】
次いで、前記第２ＥＡＰ応答メッセージ（ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｃｒｅｄｅｎｔｉａｌｓ）を受信した前記サーバは、使用者登録データベースから該当のアイデンティティのパスワードをフェッチする。次いで、前記サーバは、前記フェッチされたパスワードと、前記サーバが前記クライアントにチャレンジとして伝送したランダム値を前記（数式１）と同様な方法により圧縮する。次いで、前記サーバは、圧縮により計算された値と前記クライアントから受信された応答値とを比較し、前記計算された値と前記受信された応答値とが同様であると、前記任意に選択された認証方法の種類による認証が成功的に行われたと判断し、同様でないと、認証が失敗したと判断する。前記サーバは、図８に示したように、認証の結果を＜ＥＡＰ＞要素の＜Ｃｏｄｅ＞要素に記録することで認証結果メッセージを生成し、該生成された認証結果メッセージを前記クライアントに伝送する（Ｓ４０）。
【００７５】
次いで、図８に示した認証結果メッセージを受信した前記クライアントは、＜Ｃｏｄｅ＞Ｓｕｃｃｅｓｓ＜／Ｃｏｄｅ＞に基づいて認証が成功したと認知する。このとき、前記認証結果メッセージには、＜ＥＡＰＤａｔａ＞要素が不要である。
【００７６】
以上のように、本発明の好ましい実施形態を用いて本発明を例示してきたが、本発明は、この実施形態に限定して解釈されるべきものではない。本発明は、特許請求の範囲によってのみその範囲が解釈されるべきであることが理解される。当業者は、本発明の具体的な好ましい実施形態の記載から、本発明の記載および技術常識に基づいて等価な範囲を実施することができることが理解される。本明細書において引用した特許、特許出願および文献は、その内容自体が具体的に本明細書に記載されているのと同様にその内容が本明細書に対する参考として援用されるべきであることが理解される。
【図面の簡単な説明】
【００７７】
【図１】本発明に係るＸＭＬ  ＤＴＤを示した図である。
【図２】本発明に係るクライアントとサーバ間の可用認証方法の確認方法を示したフローチャートである。
【図３】本発明に係るクライアントとサーバ間のデータ同期化のための認証方法を示した図である。
【図４】本発明に係るＥＡＰを使用してアイデンティティを要求するための認証メッセージ（例えば、ＥＡＰ−Ｒｅｑｕｅｓｔ／Ｉｄｅｎｔｉｔｙメッセージ）を示した図である。
【図５】本発明に係るＥＡＰを使用してアイデンティティの実際の値を応答するための認証メッセージ（例えば、ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙティメッセージ）を示した図である。
【図６】本発明に係るＥＡＰを使用して任意の認証方法の種類による保安情報を要求するための認証メッセージ（例えば、ＥＡＰ−Ｒｅｑｕｅｓｔ／Ｃｈａｌｌｅｎｇｅメッセージ）を示した図である。
【図７】本発明に係るＥＡＰを使用して任意の認証方法の種類による保安情報を応答するための認証メッセージ（例えば、ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｃｒｅｄｅｎｔｉａｌｓメッセージ）を示した図である。
【図８】本発明に係るＥＡＰを使用して認証の結果を伝送するための認証メッセージを示した図である。
【図９】マークアップ言語を使用する通信システムにおけるデータ同期化時、一般のクライアントとサーバ間の認証方法を示した図である。
【図１】
2005004769.tif 000003
【図２】
2005004769.tif 000004
【図３】
2005004769.tif 000005
【図４】
2005004769.tif 000006
【図５】
2005004769.tif 000007
【図６】
2005004769.tif 000008
【図７】
2005004769.tif 000009
【図８】
2005004769.tif 000010
【図９】
2005004769.tif 000011