JP6330916B2 - ｗｅｂＲＴＣのためのシステム及び方法 - Google Patents

Description

本発明は、ｗｅｂＲＴＣ（Ｗｅｂ Ｒｅａｌ Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）のための装置、システム、及び方法に関し、特に、ＩＭＳ（ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ） Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）へのｗｅｂＲＴＣクライアントのセキュア認証（ｓｅｃｕｒｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎ）技術に関する。

ｗｅｂＲＴＣと呼ばれる新たなサービス、すなわち、音声及びビデオ通話のようなリアルタイムコミュニケーションサービスは、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）に規定されており、盛んに取り組まれている。ｗｅｂＲＴＣは、スタンドアローン・サイロサービス（ｓｔａｎｄａｌｏｎｅ ｓｉｌｏ ｓｅｒｖｉｃｅ）として動作しないように、他のネットワークとインターワークする（ｉｎｔｅｒｗｏｒｋ）。これは、他のｗｅｂＲＴＣユーザとだけでなく、通常の電話とも通話したい最終顧客（ｅｎｄ ｃｕｓｔｏｍｅｒ）にとって重要である。

この機能を提供するために、非特許文献１に開示されているように、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）にて研究が行われている。

３ＧＰＰ ＴＲ２３．７０１，"Ｓｔｕｄｙ ｏｎ Ｗｅｂ Ｒｅａｌ Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ（ＷｅｂＲＴＣ）ａｃｃｅｓｓ ｔｏ ＩＭＳ（Ｓｔａｇｅ ２）（Ｒｅｌｅａｓｅ １２）"，Ｖ０．３．０， ２０１３年１１月 ３ＧＰＰ ＴＲ３３．ａｂｃ（Ｓ３−１３１１２５），"Ｓｔｕｄｙ ｏｎ Ｓｅｃｕｒｉｔｙ ｆｏｒ ＷｅｂＲＴＣ ＩＭＳ Ｃｌｉｅｎｔ ａｃｃｅｓｓ ｔｏ ＩＭＳ；（Ｒｅｌｅａｓｅ １２）"，Ｖ０．１．０， ２０１３年１１月

ＳＡ３（ｓｅｃｕｒｉｔｙ ｗｏｒｋｉｎｇ ｇｒｏｕｐ）においていくつかのセキュリティソリューションが開始されたが、ｗｅｂＲＴＣクライアントが、モバイルオペレータのＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ（ＩＭＳ）に登録及び接続したいときに、現在のソリューション及びその合意は、モバイルデバイスにおけるｗｅｂＲＴＣクライアントのセキュア認証（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）及び認可（Ａｕｔｈｏｒｉｚａｔｉｏｎ）メカニズムを欠いている。認証されておらず及び／又は認可されていない任意のｗｅｂＲＴＣクライアントを伴うインターネットからオペレータのＩＭＳシステムへの攻撃を防止するために、最終顧客及びモバイルオペレータの両方を保護するためのセキュアソリューションを提供することが重要である。

ＩＭＳへの認証及び認可を保証するアイデンティティの割り当てと正しいマッピング（またはバインディング）の問題は、図１２に示される。

Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ（ＵＥ）のブラウザは、ＷｅｂＲＴＣ Ｗｅｂ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ（ＷＷＳＦ）からｗｅｂＲＴＣ ＩＭＳ Ｃｌｉｅｎｔ（ＷＩＣ）をダウンロードする。ＷＷＳＦは、認証されたｗｅｂアイデンティティに関連したＷＩＣに対して、認可されたＩＭＳアイデンティティの正確で一貫した割り当てを管理することについて責任がある。３ＧＰＰにおいて、ＷＷＳＦが、オペレータ・ホームＩＭＳ、又はホームＩＭＳに認可されたサードパーティー・ネットワーク（ｔｈｉｒｄ ｐａｒｔｙ ｎｅｔｗｏｒｋ）に存在してもよいことが提案されている。

ＵＥがＩＭＳサービスにアクセスするときに、ネットワークは、ＵＥがそのようなサービスへのアクセスを許可されているかどうかを検証するために認可を実行すべきである。現在のシステムにおいて、ＷＷＳＦから割り当てられる２つの独立したアイデンティティ（ｗｅｂＲＴＣアイデンティティ及びＩＭＳアイデンティティ）がある。ネットワークがアイデンティティの検証に失敗した場合、認可されていないＷＩＣがＩＭＳサービスへアクセスすること、及びネットワークへのＤｏＳ（Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅ）攻撃を起こし得る。非特許文献１及び２にて提案された認証手順は、これらの脅威に対して十分ではない。

それらの脅威に対抗するために、ネットワークは、ＷＷＳＦによって行われる認証及び／又は認可を検証することが必要である。ｗｅｂＲＴＣアイデンティティとＩＭＳアイデンティティとの間のバインディングは、ネットワークが検証を実行するために必要である。

以下のセクションでは、どのようにＩＭＳアイデンティティとのバインディングが実行されるのか、どのようにＩＭＳネットワークはこのバインディングについて知らされるのか、及び追加の認証メカニズムが必要かどうかについて説明する。

本発明は、ｗｅｂＲＴＣ ＩＭＳクライアントの認証及び認可が、モバイルネットワークオペレータのＩＭＳにおいてどのように達成することができるかの様々な態様を提案する。ＷＩＣは、ＩＭＳに登録するためにＩＤを使用し、そのＩＤは、ＩＭＳ ｐｕｂｌｉｃ ｕｓｅｒ ｉｄｅｎｔｉｔｙ（ＩＭＰＵ）、ＩＭＳ ｐｒｉｖａｔｅ ｉｄｅｎｔｉｔｙ（ＩＭＰＩ）、ｇｌｏｂａｌｌｙ ｒｏｕｔａｂｌｅ ｕｓｅｒ ａｇｅｎｔ ＵＲＩ（ＧＲＵＵ）等であり得る。

ＷＩＣは、ＷＷＳＦによってｅＰ−ＣＳＣＦアドレス及び認証情報を用いて事前設定され得るが、そうでない場合、この情報は、直接ＩＭＳから又はＷＷＳＦを介して、又は例えばＯＭＡ ＤＭ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉｃａｎｃｅ Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ）である他のデバイス管理手順を介して、検索されるべきである。

加入者が、既に有効なｗｅｂＲＴＣアカウント又はメンバーシップを有すること、及びこれがＷＷＳＦによって、有効にされ、認証され、及び認可され得ることがさらに想定される。

本発明の第１の実施の態様にかかる方法は、通信システムにおける認証方法を提供する。この方法は、ＩＭＳ登録においてＷＷＳＦからＵＥへトークンを送信することと、前記トークンを伴うＲＥＧＩＳＴＥＲメッセージを前記ＵＥからｅＰ−ＣＳＣＦへ送信することと、前記ｅＰ−ＣＳＣＦによって前記トークンを検証することと、前記ＲＥＧＩＳＴＥＲメッセージを前記ｅＰ−ＣＳＣＦからＳ−ＣＳＣＦへ転送することと、加入者プロファイル（ｓｕｂｓｃｒｉｐｔｉｏｎ ｐｒｏｆｉｌｅ）をＨＳＳから前記Ｓ−ＣＳＣＦへ受信することと、２００ ＯＫメッセージを前記Ｓ−ＣＳＣＦから前記ｅＰ−ＣＳＣＦを介して前記ＵＥへ送信することと、を含む。

また、本発明の第２の実施の態様にかかるシステムは、ＵＥを認証する通信システムである。このシステムは、ＷＷＳＦと、ｅＰ−ＣＳＣＦと、Ｓ−ＣＳＣＦと、ＨＳＳと、を含む。前記ＷＷＳＦは、ＩＭＳ登録においてトークンを前記ＵＥへ送信する。前記ＵＥは、前記トークンを伴うＲＥＧＩＳＴＥＲメッセージを前記ｅＰ−ＣＳＣＦへ送信する。前記ｅＰ−ＣＳＣＦは、前記トークンを検証する。前記ｅＰ−ＣＳＣＦは、前記ＲＥＧＩＳＴＥＲメッセージを前記Ｓ−ＣＳＣＦへ転送する。前記Ｓ−ＣＳＣＦは、加入者プロファイルを前記ＨＳＳから受信する。前記Ｓ−ＣＳＣＦは、２００ ＯＫメッセージを前記ｅＰ−ＣＳＣＦを介して前記ＵＥへ送信する。

また、本発明の第３の実施の態様にかかる方法は、ＵＥの認証方法を提供する。この方法は、ＩＭＳ登録においてトークンをＷＷＳＦから受信することと、前記トークンを検証してＲＥＧＩＳＴＥＲメッセージをＳ−ＣＳＣＦへ転送するｅＰ−ＣＳＣＦへ、前記トークンを伴う前記ＲＥＧＩＳＴＥＲメッセージを送信することと、ＨＳＳから加入者プロファイルを受信する前記Ｓ−ＣＳＣＦから、前記ｅＰ−ＣＳＣＦを介して２００ ＯＫメッセージを受信することと、を含む。

さらに、本発明の第４の実施の態様にかかる装置は、ＷＷＳＦと、ｅＰ−ＣＳＣＦと、Ｓ−ＣＳＣＦと、ＨＳＳと、を含む通信システムに接続可能なＵＥである。このＵＥは、ＩＭＳ登録においてトークンを前記ＷＷＳＦから受信し、前記ＨＳＳから加入者プロファイルを受信する前記Ｓ−ＣＳＣＦから、前記ｅＰ−ＣＳＣＦを介して２００ ＯＫメッセージを受信する受信部と、前記トークンを検証してＲＥＧＩＳＴＥＲメッセージを前記Ｓ−ＣＳＣＦへ転送する前記ｅＰ−ＣＳＣＦへ、前記トークンを伴う前記ＲＥＧＩＳＴＥＲメッセージを送信する送信部と、を含む。

本発明により、例えば、ＩＭＳへのｗｅｂＲＴＣクライアントのセキュア認証をすることができる。

本発明の第１の実施の形態にかかる静的なＩＭＳ ＩＤ割り当ての一例を示すブロック図である。 第１の実施の形態にかかる静的なＩＭＳ ＩＤ割り当てのためのコールフローの一例を示すシーケンス図である。 本発明の第２の実施の形態にかかる動的なＩＭＳ ＩＤ割り当ての一例を示すブロック図である。 第２の実施の形態にかかる動的なＩＭＳ ＩＤ割り当てのためのコールフローの一例を示すシーケンス図である。 第２の実施の形態にかかる動的なＩＭＳ ＩＤ割り当てのためのコールフローの他の例を示すシーケンス図である。 第２の実施の形態にかかるＷＷＳＦ及びｅＰ−ＣＳＣＦにおける同期されていない登録解除及びバインディング除去の一例を示すシーケンス図である。 第２の実施の形態にかかるＷＷＳＦ及びｅＰ−ＣＳＣＦにおける同期された登録解除及びバインディング除去の一例を示すシーケンス図である。 本発明の第３の実施の形態にかかる信頼されたサード・パーティーのＡＡＡにおけるｗｅｂＲＴＣ ＩＤ検証の一例を示すブロック図である。 第３の実施の形態にかかる信頼されたサード・パーティーのＡＡＡにおけるｗｅｂＲＴＣ ＩＤ検証のためのコールフローの一例を示すシーケンス図である。 第３の実施の形態にかかる信頼されたサード・パーティーのＡＡＡにおける同期されていない登録解除の一例を示すシーケンス図である。 第３の実施の形態にかかる信頼されたサード・パーティーのＡＡＡにおける同期された登録解除の一例を示すシーケンス図である。 典型的なアイデンティティマッピングを示すブロック図である。 ３ＧＰＰに提案されるＷＷＳＦトークンによるｗｅｂＲＴＣクライアント認証を示すシーケンス図である。 本発明にかかるＵＥの構成例を示すブロック図である。

以下、本発明の第１から第３の実施の形態を、図面を参照して説明する。

＜第１の実施の形態＞
本実施の形態は、ｗｅｂＲＴＣアイデンティティごとのＷＷＳＦへの静的なＩＭＳ ＩＤ割り当てを提案する。図１にアイデンティティバインディングの原理を示す。

ＷＷＳＦ ３０及びＨＳＳ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ） ６０は、ｗｈインタフェースを介してアイデンティティ情報を交換することができる。その情報は、ＩＭＳ ＩＤに対応する特定のｗｅｂＲＴＣアイデンティティと、必要であればＩＭＳ認証のためのパスワードを含むが、このパラメータセットに制限されない。

図２は、ステップＳ１１からＳ１５の事前準備段階によりＩＭＳ登録のためのコールフロー（ｃａｌｌ ｆｌｏｗ）を提供する。

ステップＳ１１：ＵＥ １０は、ＩＭＳ加入者（ＩＭＳ ｓｕｂｓｃｒｉｂｅｒ）及びｗｅｂＲＴＣ加入者（ｗｅｂＲＴＣ ｓｕｂｓｃｒｉｂｅｒ）であり、ＩＭＳオペレータに自身のｗｅｂＲＴＣ ＩＤを登録する。これは、そのＩＭＳ登録の間にＩＭＳクライアントに通常使用される通常のＩＭＳ登録メッセージにおいて行われ得る。

ステップＳ１２：ＨＳＳ ６０は、ｗｅｂＲＴＣ ＩＤとＩＭＳ ＩＤとの間でバインディングを生成する。それは、新たなＷＩＣ ＩＭＳ ＩＤと、必要であれば対応するパスワード又は他の認証に関連する情報を生成する。ＷＩＣのＩＭＳ ＩＤは、通常のＩＭＳクライアントのものとは異なる。

ステップＳ１３：ＨＳＳ ６０は、ｗｅｂＲＴＣ ＩＤからＷＷＳＦアドレスを導出する。ＨＳＳ ６０は、ＷＷＳＦ ３０を見つけるために、ｗｅｂＲＴＣプロバイダごとにルックアップテーブルを有することができ、又は固定されたフォーマット、例えば「wwsf@webrtcprovider.com」を有する。ＨＳＳ ６０は、ｗｈインタフェースを介してＷＷＳＦ ３０に、生成されたＷＩＣ ＩＭＳ ＩＤ、パスワード、及びｗｅｂＲＴＣ ＩＤを提供する。ＨＳＳ ６０は、他のｓｕｂｓｃｒｉｐｔｉｏｎ又は認証に関連する情報も提供し得る。ＷＩＣ ２０は、正しいｅＰ−ＣＳＣＦ（ｅｎｈａｎｃｅｄ Ｐｒｏｘｙ−Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）アドレスを検索することができないかもしれない。したがって、ＨＳＳ ６０は、ｅＰ−ＣＳＣＦをこのメッセージに含め得る。その情報はまた、ＷＩＣ ２０が例えばＷＷＳＦ ３０によって事前設定されるかどうかに依存している。

ステップＳ１４：ＷＷＳＦ ３０は、ｗｅｂＲＴＣ ＩＤとＷＩＣ ＩＭＳ ＩＤと、もし提供されるならばパスワード及び他の情報との間でバインディングを生成する。

ステップＳ１５：ｗｅｂＲＴＣを使用可能にされたブラウザ（ｗｅｂＲＴＣ−ｅｎａｂｌｅｄ ｂｒｏｗｓｅｒ）内から、ユーザーは、ＷＷＳＦ ３０とのＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ）接続を開始するために、ＷＷＳＦ ３０へのＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）にアクセスし得る。ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）接続は、サーバ証明書（ｓｅｒｖｅｒ ｃｅｒｔｉｆｉｃａｔｅ）に基づいてサーバの一方向の認証を提供し得る。ブラウザは、ＷＷＳＦ ３０からＷＩＣ ２０をダウンロードし、ＷＩＣ２０を初期設定して、準備段階は完了する。

ステップＳ１６：ＷＩＣ ２０は、自身のｗｅｂＲＴＣ ＩＤを用いてＷＷＳＦ ３０に登録する。ＷＷＳＦ ３０は、共通のウェブ認証手順（ｃｏｍｍｏｎ ｗｅｂ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｐｒｏｃｅｄｕｒｅ）を用いてユーザを認証し得る。

ステップＳ１７：ＷＷＳＦ ３０は、対応するＩＭＳ ＩＤ、及び可能な場合、パスワード、ｅＰ−ＣＳＣＦアドレス、認証情報等を、ＷＩＣ ２０へ提供する。その情報はまた、ＷＩＣ ２０が事前設定されるかどうかに依存している。

ステップＳ１８：ＷＩＣ ２０は、受信した情報を格納し、ＷＩＣ ＩＭＳ ＩＤを用いて、ＲＥＧＩＳＴＥＲメッセージをｅＰ−ＣＳＣＦ ４０に送信する。このメッセージは、望ましくは、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）メッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）等のような他のプロトコルに基づくことができる。

ステップＳ１９：Ｓ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ−ＣＳＣＦ） ５０は、ＨＳＳ ６０から認証データを検索し、４０１ ｕｎａｕｔｈｏｒｉｚｅｄ ｒｅｓｐｏｎｓｅを用いてＵＥ １０にチャレンジする。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ２０：ＷＩＣ ２０は、ＷＷＳＦ ３０から受信した情報（パスワード、情報に関する他の認証）を用いてチャレンジを解決し、別のＲＥＧＩＳＴＥＲメッセージをｅＰ−ＣＳＣＦ ４０に送信する。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ２１：Ｓ−ＣＳＣＦ ５０は、２００ ＯＫ又は他の適切なメッセージを用いてＷＩＣ ２０に対して登録に確認応答し（ａｃｋｎｏｗｌｅｄｇｅ）、ＨＳＳ ６０から加入者プロファイルを検索する。 このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

本実施の形態は、ｗｅｂＲＴＣユーザが同時にＩＭＳ加入者でもあることを必要とする。ＷＩＣ ２０が、ＵＩＣＣ（Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）にアクセスできず、Ｐ−ＣＳＣＦ割り当てを有さないので、ＨＳＳ ６０は、ｗｅｂＲＴＣサービスプロバイダとのインタフェースを必要とし、ＩＭＳ ＩＤ＋パスワード及びｅＰ−ＣＳＣＦアドレスを交換する。

＜第２の実施の形態＞
本実施の形態において、ＷＷＳＦは、ＩＭＳオペレータのＨＳＳから受信したＩＭＳ ＩＤのプールを使用している。その背景にあるアイデアは、ｗｅｂＲＴＣサービスプロバイダが、自身のＩＭＳ ｓｕｂｓｃｒｉｐｔｉｏｎをｗｅｂＲＴＣユーザが有すると仮定せず、したがって、ｗｅｂＲＴＣサービスプロバイダが、オンデマンド（ｏｎ ｄｅｍａｎｄ）でｗｅｂＲＴＣ ＩＭＳクライアントに割り当てられ得るＩＭＳ ｓｕｂｓｃｒｉｐｔｉｏｎのプールを保持する。アーキテクチャを図３に示す。

ＩＭＳ ＩＤのプールは、ｗｉｌｄｃａｒｄｅｄ ＩＭＰＵのフォーム（ｆｏｒｍ）でＷＷＳＦ ３０に提供され得るが、それはＩＭＰＵのリストにすることもでき、これに制限されない。

図４にその手順のコールフローを示す。

ステップＳ３１：ＷＷＳＦ ３０は、オンデマンドでｗｅｂＲＴＣユーザにより共有される例えば、ｗｉｌｄｃａｒｄｅｄ ＩＭＰＵ、又はＩＭＰＵのリストであるＩＭＳ ＩＤのプールを用いて事前設定される。ＨＳＳ ６０は、ＷＷＳＦ ３０にコンフィギュレーションを提供し、また、例えばｅＰ−ＣＳＣＦアドレス、認証情報、パスワード等の追加の情報も提供し得る。

ステップＳ３２：ｗｅｂＲＴＣを使用可能にされたブラウザ内から、ユーザは、ＷＷＳＦ ３０とのＨＴＴＰＳ接続を開始するために、ＷＷＳＦ ３０のＵＲＩにアクセスし得る。ＴＬＳ接続は、サーバ証明書に基づいてサーバの一方向の認証を提供し得る。ブラウザは、ＷＷＳＦ ３０からＷＩＣ ２０をダウンロードし、ＷＩＣ２０を初期設定して、準備段階は完了する。

ステップＳ３３：ＷＩＣ ２０は、自身のｗｅｂＲＴＣ ＩＤを用いてＷＷＳＦ ３０に登録する。ＷＷＳＦ ３０は、必要であれば、認証手続を開始し得る。

ステップＳ３４：ＷＷＳＦ ３０は、現在使用されていないＩＭＳ ＩＤを選択する、又はｗｉｌｄｃａｒｄｅｄ ＩＭＰＵの場合に、例えばｗｅｂＲＴＣ ＩＤに基づきＩＭＰＵを生成する。ＷＷＳＦ ３０は、このＩＭＳ ＩＤをｗｅｂＲＴＣ ＩＤにバインドし、且つ入手可能な場合、ＩＭＳ ＩＤを、パスワード、ｅＰ−ＣＳＣＦアドレス、認証情報等にバインドする。その情報はまた、ＷＩＣ ２０が、ＷＷＳＦ ３０によってｅＰ−ＣＳＣＦアドレス及び認証情報を用いて事前設定されるか否かに依存している。

ステップＳ３５：ＷＷＳＦ ３０は、ｗｅｂＲＴＣ ＩＤ及びＩＭＳ ＩＤのバインディングをｅＰ−ＣＳＣＦ ４０に登録する。

ステップＳ３６：ｅＰ−ＣＳＣＦ ４０及びＷＷＳＦ ３０は信頼関係（ｔｒａｓｔ ｒｅｌａｔｉｏｎｓｈｉｐ）を有し、お互いに認証し得る。ｅＰ−ＣＳＣＦ ４０は、バインディングを格納し、バインディングに確認応答する。それはバインディングのためのｖａｌｉｄｉｔｙ ｔｉｍｅｒを開始することができ、ＷＷＳＦ ３０にそのｔｉｍｅｒを提供する。

ステップＳ３７：ＷＷＳＦ ３０は、ｗｅｂＲＴＣ ＩＤにバインドしているＩＭＳ ＩＤをＷＩＣ ２０に提供する。

ステップＳ３８：ＷＩＣ ２０は、受信した情報を格納し、ＩＭＳ ＩＤを伴うＲＥＧＩＳＴＥＲメッセージをｅＰ−ＣＳＣＦ ４０に送信する。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ３９：ｅＰ−ＣＳＣＦ ４０は、ｗｅｂＲＴＣ ＩＤ及びＩＭＳ ＩＤのバインディングを検証し、ＲＥＧＩＳＴＥＲを認可する。ｅＰ−ＣＳＣＦ ４０は、Ｓ−ＣＳＣＦ ５０によるチャレンジの必要をなくすために、そのバインディングが検証された及び／又は登録が認可されたことを示すインジケータ（ｉｎｄｉｃａｔｏｒ）、フラグ、又は他のパラメータをＲＥＧＩＳＴＥＲ内に含めることができる。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ４０：ｅＰ−ＣＳＣＦ ４０は、ＩＭＳ ＩＤを伴うＲＥＧＩＳＴＥＲを（潜在的にＩＢＣＦ（Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ Ｂｏｒｄｅｒ Ｃｏｎｔｒｏｌ）又はＩ−ＣＳＣＦ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ−ＣＳＣＦ）のような他のＩＭＳノードを介して）Ｓ−ＣＳＣＦ ５０に転送し、前のステップにおいて説明されるようにそれにマークを付け得る。Ｓ−ＣＳＣＦ ５０は、加入者プロファイルをＨＳＳ ６０に要求する。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ４１：Ｓ−ＣＳＣＦ ５０は、登録に確認応答し、このｗｅｂＲＴＣサービスプロバイダのための一般加入者プロファイルをＨＳＳ ６０から検索する。２００ ＯＫ又は他の適切なメッセージがＷＩＣ ２０へ転送される。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

本実施の形態の他のバリエーションにおいて、図５に示す以下のコールフローを適用する。

前の図４と同じ原則が適用され、すなわちステップはほぼ同じであり、ステップＳ５１ｂ及び検証ステップＳ５６により２つだけ追加のステップが含められている。

ステップＳ５１ａ：ＷＷＳＦ ３０は、オンデマンドでｗｅｂＲＴＣユーザにより共有される例えば、ｗｉｌｄｃａｒｄｅｄ ＩＭＰＵ、又はＩＭＰＵのリストであるＩＭＳ ＩＤのプールを用いて事前設定される。ＨＳＳ ６０は、ＷＷＳＦ ３０にコンフィギュレーションを提供し、また、例えばｅＰ−ＣＳＣＦアドレス、認証情報、パスワード等の追加の情報も提供し得る。

ステップＳ５１ｂ：ＨＳＳ ６０は、ＷＷＳＦ ＩＤ及びそれの許可されたＩＭＳ ＩＤをｅＰ−ＣＳＣＦ ４０に提供する。それはＰＳＩ（Ｐｒｏｊｅｃｔ Ｓｅｒｖｅｒ Ｉｎｔｅｒｆａｃｅ）ルーティングを使用することができ、適切なＳＩＰメッセージ、例えばＯＰＴＩＯＮＳ、ＵＰＤＡＴＥ、ＩＮＶＩＴＥ、ＲＥＧＩＳＴＥＲ、２００ ＯＫ、ＭＥＳＳＡＧＥ等を使用することができる。

ステップＳ５２：ｗｅｂＲＴＣを使用可能にされたブラウザ内から、ユーザは、ＷＷＳＦ ３０とのＨＴＴＰＳ接続を開始するために、ＷＷＳＦ ３０のＵＲＩにアクセスし得る。ＴＬＳ接続は、サーバ証明書に基づいてサーバの一方向の認証を提供し得る。ブラウザは、ＷＷＳＦ ３０からＷＩＣ ２０をダウンロードし、ＷＩＣ２０を初期設定して、準備段階は完了する。

ステップＳ５３：ＷＩＣ ２０は、自身のｗｅｂＲＴＣ ＩＤを用いてＷＷＳＦ ３０に登録する。ＷＷＳＦ ３０は、必要であれば、認証手続を開始し得る。

ステップＳ５４：ＷＷＳＦ ３０は、現在使用されていないＩＭＳ ＩＤを選択する、又はｗｉｌｄｃａｒｄｅｄ ＩＭＰＵの場合に、例えばｗｅｂＲＴＣ ＩＤに基づきＩＭＰＵを生成する。ＷＷＳＦ ３０は、このＩＭＳ ＩＤをｗｅｂＲＴＣ ＩＤにバインドし、且つ入手可能な場合、ＩＭＳ ＩＤを、パスワード、ｅＰ−ＣＳＣＦアドレス、認証情報等にバインドする。その情報はまた、ＷＩＣ ２０が、ＷＷＳＦ ３０によってｅＰ−ＣＳＣＦアドレス及び認証情報を用いて事前設定されるか否かに依存している。

ステップＳ５５：ＷＷＳＦ ３０は、ｗｅｂＲＴＣ ＩＤ及びＩＭＳ ＩＤのバインディングをｅＰ−ＣＳＣＦ ４０に登録する。

ステップＳ５６：ｅＰ−ＣＳＣＦ ４０及びＷＷＳＦ ３０は信頼関係を有し、お互いに認証し得る。ｅＰ−ＣＳＣＦ ４０は、ステップＳ５１ｂにおけるＨＳＳ ｐｒｏｖｉｓｉｏｎｉｎｇに基づいて、ＷＷＳＦ ３０がそのＩＭＳ ＩＤの使用を認可されているかどうかを検証する。ｅＰ−ＣＳＣＦ ４０は、ｗｅｂＲＴＣ ＩＤ及びＩＭＳ ＩＤのバインディングのためのｖａｌｉｄｉｔｙ ｔｉｍｅｒを開始することができる。

ステップＳ５７：ｅＰ−ＣＳＣＦ ４０は、ＷＷＳＦ ３０に対してｗｅｂＲＴＣ ＩＤ及びＩＭＳ ＩＤのバインディングに確認応答し、バインディングが有効な期間のためのｖａｌｉｄｉｔｙ ｔｉｍｅｒを提供し得る。

ステップＳ５８：ＷＷＳＦ ３０は、ｗｅｂＲＴＣ ＩＤにバインドしているＩＭＳ ＩＤをＷＩＣ ２０に提供する。

ステップＳ５９：ＷＩＣ ２０は、受信した情報を格納し、ＩＭＳ ＩＤを伴うＲＥＧＩＳＴＥＲメッセージをｅＰ−ＣＳＣＦ ４０に送信する。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ６０：ｅＰ−ＣＳＣＦ ４０は、ｗｅｂＲＴＣ ＩＤ及びＩＭＳ ＩＤのバインディングを検証し、ＲＥＧＩＳＴＥＲを認可する。ｅＰ−ＣＳＣＦ ４０は、Ｓ−ＣＳＣＦ ５０によるチャレンジの必要をなくすために、そのバインディングが検証された及び／又は登録が認可されたことを示すインジケータ、フラグ、又は他のパラメータをＲＥＧＩＳＴＥＲ内に含めることができる。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ６１：ｅＰ−ＣＳＣＦ ４０は、ＩＭＳ ＩＤを伴うＲＥＧＩＳＴＥＲを（潜在的にＩＢＣＦ又はＩ−ＣＳＣＦのような他のＩＭＳノードを介して）Ｓ−ＣＳＣＦ ５０に転送し、前のステップにおいて説明されるようにそれにマークを付け得る。Ｓ−ＣＳＣＦ ５０は、加入者プロファイルをＨＳＳ ６０に要求する。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ６２：Ｓ−ＣＳＣＦ ５０は、登録に確認応答し、このｗｅｂＲＴＣサービスプロバイダのための一般加入者プロファイルをＨＳＳ ６０から検索する。２００ ＯＫ又は他の適切なメッセージがＷＩＣ ２０へ転送される。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

（登録解除及びバインディング除去）
ある時点では、ＵＥ １０、すなわちＷＩＣ ２０は、これ以上ＩＭＳ登録されていたくないかもしれず、そのとき、ＷＩＣ ２０は、Ｓ−ＣＳＣＦ ５０が登録を除去するように、期限切れのｔｉｍｅｒに基づきタイムアウトし得るＩＭＳ登録をリフレッシュ（ｒｅｆｒｅｓｈ）しないことができる。

ＷＩＣ ２０は、積極的に登録解除を望むことができ、これは終端コールが直接失敗する利点を有し、ｃａｌｌｉｎｇ ｐａｒｔｙが直接知らされ得るように、配信されないタイムアウト（ｕｎｄｅｌｉｖｅｒｅｄ ｔｉｍｅｏｕｔ）に起因しない。また、フリーＩＭＳ ＩＤは、他のｗｅｂＲＴＣ ＩＤに割り当てるために再利用可能である。

図６に、同期されていない登録解除をどのように行うことができるかを示す。

ステップＳ７１：ＷＩＣ ２０は、自身のｗｅｂＲＴＣ ＩＤを伴う登録解除メッセージをＷＷＳＦ ３０に送信する。

ステップＳ７２：ＷＷＳＦ ３０は、ＷＩＣ ｓｔａｔｅを未登録に設定し、ＩＭＳ ＩＤとｗｅｂＲＴＣ ＩＤとのバインディングを除去する。ＷＷＳＦ ３０は、図７に示すようにバインディングの除去についてｅＰ−ＣＳＣＦ ４０に知らせ得る。

ステップＳ７３：ＷＷＳＦ ３０は、登録解除に確認応答する。

ステップＳ７４：ＷＩＣ ２０は、０に等しい期間満了ｔｉｍｅｒと共にＩＭＳ ＩＤ及びｗｅｂＲＴＣ ＩＤを伴うＲＥＧＩＳＴＥＲメッセージをｅＰ−ＣＳＣＦ ４０に送信する。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ７５：ｅＰ−ＣＳＣＦ ４０は、ｗｅｂＲＴＣ ＩＤ及びＩＭＳ ＩＤのバインディングを検証し、ＲＥＧＩＳＴＥＲを認可する。ｅＰ−ＣＳＣＦ ４０は、Ｓ−ＣＳＣＦ ５０によるチャレンジの必要をなくすために、そのバインディングが検証された及び／又は登録が認可されたことを示すインジケータ、フラグ、又は他のパラメータをＲＥＧＩＳＴＥＲ内に含めることができる。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ７６：ｅＰ−ＣＳＣＦ ４０は、ＩＭＳ ＩＤを伴うＲＥＧＩＳＴＥＲを（潜在的にＩＢＣＦ又はＩ−ＣＳＣＦのような他のＩＭＳノードを介して）Ｓ−ＣＳＣＦ ５０に転送し、前のステップにおいて説明されるようにそれをマークし得る。Ｓ−ＣＳＣＦ ５０は、登録解除についてＨＳＳ ６０に知らせる。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ７７：Ｓ−ＣＳＣＦ ５０は、登録解除に確認応答する。２００ ＯＫ又は他の適切なメッセージがＷＩＣ ２０へ転送される。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ７８：ｅＰ−ＣＳＣＦ ４０は、ＩＭＳ登録解除が成功したという確認応答（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を受信した時点で、ｗｅｂＲＴＣ ＩＤとＩＭＳ ＩＤとの間のバインディングを除去する。

登録解除のバリエーションにおいて、ＷＩＣ ２０は、ステップＳ７４にて登録解除メッセージをＩＭＳに直接送信することができ、ｅＰ−ＣＳＣＦ ４０は、登録解除及び／又はバインディングの除去についてＷＷＳＦ ３０に知らせるよう気を付ける。

図７に、ｗｅｂＲＴＣプロバイダとＩＭＳプロバイダとの間で同期された登録解除をどのように行うことができるかの他のバリエーションを示す。

ステップＳ８１：ＷＩＣ ２０は、自身のｗｅｂＲＴＣ ＩＤを伴う登録解除メッセージをＷＷＳＦ ３０に送信する。

ステップＳ８２：ＷＷＳＦ ３０は、ＩＭＳ ＩＤ及びｗｅｂＲＴＣ ＩＤのタプル（ｔｕｐｌｅ）を伴う登録解除メッセージをｅＰ−ＣＳＣＦ ４０に送信する。ＷＷＳＦ ３０は、既にバインディングを除去し得るが、後の段階、例えばステップＳ８８にてそれを行うこともできる。

ステップＳ８３：ｅＰ−ＣＳＣＦ ４０は、ｗｅｂＲＴＣ ＩＤとＩＭＳ ＩＤとの間のバインディングを検証し、０に等しい期間満了ｔｉｍｅｒと共にＩＭＳ ＩＤ及びｗｅｂＲＴＣ ＩＤを伴うＳ−ＣＳＣＦ ５０へのＲＥＧＩＳＴＥＲメッセージを生成する。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ８４：ｅＰ−ＣＳＣＦ ４０は、０に等しい期間満了ｔｉｍｅｒと共にＩＭＳ ＩＤ及びｗｅｂＲＴＣ ＩＤを伴うＲＥＧＩＳＴＥＲメッセージを（潜在的にＩＢＣＦ又はＩ−ＣＳＣＦのような他のＩＭＳノードを介して）Ｓ−ＣＳＣＦ ５０に送信する。ｅＰ−ＣＳＣＦ ４０は、そのバインディングが検証された及び／又は登録が認可されたことを示すインジケータ、フラグ、又は他のパラメータを含めることができる。Ｓ−ＣＳＣＦ ５０は、登録解除についてＨＳＳ ６０に知らせる。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ８５：Ｓ−ＣＳＣＦ ５０は、登録解除に確認応答する。２００ ＯＫ又は他の適切なメッセージがｅＰ−ＣＳＣＦ ４０へ転送される。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ８６：ｅＰ−ＣＳＣＦ ４０は、ｗｅｂＲＴＣ ＩＤ及びＩＭＳ ＩＤのバインディングを除去する。

ステップＳ８７：ｅＰ−ＣＳＣＦ ４０は、成功した登録解除に確認応答する。

ステップＳ８８：ＷＷＳＦ ３０は、ＷＩＣ ｓｔａｔｅを未登録に設定し、ＩＭＳ ＩＤとｗｅｂＲＴＣ ＩＤとのバインディングを除去する。

ステップＳ８９：ＷＷＳＦ ３０は、登録解除に成功したことをＷＩＣ ２０に確認応答する。

＜第３の実施の形態＞
本実施の形態において、サード・パーティー認証（ｔｈｉｒｄ ｐａｒｔｙ ａｕｔｈｅｎｔｉｃａｔｉｏｎ）と、ＩＭＳオペレータだけでなくｗｅｂＲＴＣサービスプロバイダにより信頼された認可サーバとが使用される。アーキテクチャを図８に示す。

ＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ ａｎｄ Ａｃｃｏｕｎｔｉｎｇ）７０は、特定のｗｅｂＲＴＣ ＩＤのために、ＷＷＳＦ ３０にトークン又は他のメカニズムを提供する。ＡＡＡ ７０は、信頼されたサード・パーティーによりホストされたモバイルオペレータ又はインターネット内に配置され得る。ＷＩＣ ２０が、特定の時間間隔内で、正しいｗｅｂＲＴＣ ＩＤと共にトークンを使用する場合、ＨＳＳ ６０は、ＷＩＣ ２０が登録することを許可されるかどうかをＡＡＡ ７０でチェックする。このために、ｗｅｂＲＴＣユーザは、ＩＭＳ登録を有する必要はなく、ＩＭＳネットワーク又はモバイルネットワークの加入者になるユーザを有していない。

図９にその手順のコールフローを示す。

ステップＳ９１：ｗｅｂＲＴＣを使用可能にされたブラウザ内から、ユーザは、ＷＷＳＦ ３０とのＨＴＴＰＳ接続を開始するために、ＷＷＳＦ ３０のＵＲＩにアクセスし得る。ＴＬＳ接続は、サーバ証明書に基づいてサーバの一方向の認証を提供し得る。ブラウザは、ＷＷＳＦ ３０からＷＩＣ ２０をダウンロードし、ＷＩＣ２０を初期設定して、準備段階は完了する。

ステップＳ９２：ＷＩＣ ２０は、自身のｗｅｂＲＴＣ ＩＤを用いてＷＷＳＦ ３０に登録する。ＷＷＳＦ ３０は、必要であれば、認証手続を開始し得る。

ステップＳ９３：ＷＩＣ ２０が事前設定されていない場合、ＷＷＳＦ ３０はｅＰ−ＣＳＣＦ ４０を選択する。ｗｅｂＲＴＣが少なくとも１つのＩＭＳオペレータとＳｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔを有していると仮定される。したがって、ＷＷＳＦ ３０は、ｅＰ−ＣＳＣＦアドレスを知り、特定のｗｅｂＲＴＣ ＩＤごとに１つ選択することができる。

ステップＳ９４：ＷＷＳＦ ３０は、ｗｅｂＲＴＣ ＩＤのためのトークンをＡＡＡ ７０に要求する。

ステップＳ９５：ＡＡＡ ７０は、ｗｅｂＲＴＣ ＩＤのためのトークンを生成し、バインディングを格納する。トークンは、制限された有効時間（ｌｉｍｉｔｅｄ ｖａｌｉｄｉｔｙ ｔｉｍｅ）を有し得る。

ステップＳ９６：ＡＡＡ ７０は、ｗｅｂＲＴＣ ＩＤのためのトークンを許可（ｇｒａｎｔ）し、それとオプションで関連情報（例えば、ｖａｌｉｄｉｔｙ ｔｉｍｅｒ）とをＷＷＳＦ ３０に送信する。

ステップＳ９７：ＷＷＳＦ ３０は、トークン及びオプションでｅＰ−ＣＳＣＦアドレスをＷＩＣ ２０に提供する。

ステップＳ９８：ＷＩＣ ２０は、自身のｗｅｂＲＴＣ ＩＤ及びトークンを伴うＲＥＧＩＳＴＥＲを、ｅＰ−ＣＳＣＦ ４０及びＳ−ＣＳＣＦ ５０に送信する。

ステップＳ９９：Ｓ−ＣＳＣＦ ５０は、このｗｅｂＲＴＣ ＩＤ及びトークンのために認証要求（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｒｅｑｕｅｓｔ）を実行する。

ステップＳ１００：ＨＳＳ ６０は、ｗｅｂＲＴＣ ＩＤ及びトークンを検証することをＡＡＡ ７０に要求する。

ステップＳ１０１：ＨＳＳ ６０は、認証に確認応答し、このｗｅｂＲＴＣサービスプロバイダのために一般加入者プロファイルをＳ−ＣＳＣＦ ５０に提供する。

ステップＳ１０２：Ｓ−ＣＳＣＦ ５０は、２００ ＯＫ又は他の適切なメッセージを用いてＲＥＧＩＳＴＥＲに確認応答する。

（登録解除及びバインディング除去）
ある時点では、ＵＥ １０、すなわちＷＩＣ ２０は、これ以上ＩＭＳ登録されていたくないかもしれず、そのとき、ＷＩＣ ２０は、Ｓ−ＣＳＣＦ ５０が登録を除去するように、期限切れのｔｉｍｅｒに基づきタイムアウトし得るＩＭＳ登録をリフレッシュしないことができる。

ＷＩＣ ２０は、積極的に登録解除を望むことができ、これは終端コールが直接失敗する利点を有し、ｃａｌｌｉｎｇ ｐａｒｔｙが直接知らされ得るように、配信されないタイムアウトに起因しない。また、フリーＩＭＳ ＩＤは、他のｗｅｂＲＴＣ ＩＤに割り当てるために再利用可能である。

図１０に、同期されていない登録解除をどのように行うことができるかを示す。

ステップＳ１１１：ＷＩＣ ２０は、自身のｗｅｂＲＴＣ ＩＤを伴う登録解除メッセージをＷＷＳＦ ３０に送信する。

ステップＳ１１２：ＷＷＳＦ ３０は、トークン及び／又はバインディングを除去するために、ｗｅｂＲＴＣ ＩＤを伴う要求メッセージをＡＡＡ ７０に送信する。

ステップＳ１１３：ＡＡＡ ７０は、ＩＭＳ登録解除が起こった時点で、そのバインディングにマークを付け、それはすぐに除去される。

ステップＳ１１４：ＡＡＡ ７０は、トークン及び／又はバインディングの除去の情報が準備されたこと、及び今やＷＩＣ ２０がＩＭＳ登録解除を実行できることを確認応答する。

ステップＳ１１５：ＷＷＳＦ ３０は、ＷＩＣ ｓｔａｔｅを未登録に設定し、ｗｅｂＲＴＣ ＩＤと他の情報とのバインディングを除去し、登録解除に成功したことをＷＩＣ ２０に確認応答する。

ステップＳ１１６：ＷＩＣ ２０は、０に等しい期間満了ｔｉｍｅｒと共にｗｅｂＲＴＣ ＩＤを伴うＲＥＧＩＳＴＥＲメッセージを（潜在的にＩＢＣＦ又はＩ−ＣＳＣＦのような他のＩＭＳノードを介して）Ｓ−ＣＳＣＦ ５０に送信する。ｅＰ−ＣＳＣＦ ４０は、そのバインディングが検証された及び／又は登録が認可されたことを示すインジケータ、フラグ、又は他のパラメータを含めることができる。

ステップＳ１１７：Ｓ−ＣＳＣＦ ５０は、ｗｅｂＲＴＣ ＩＤのための登録解除についてＨＳＳ ６０に知らせる。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ１１８：ＨＳＳ ６０は、ｗｅｂＲＴＣ ＩＤを認証すること、及びバインディングを除去することをＡＡＡ ７０に要求する。ＡＡＡ ７０は、ｗｅｂＲＴＣ ＩＤを認証し、バインディングを除去したことをＨＳＳ ６０に示す。

ステップＳ１１９：ＨＳＳ ６０は、登録解除に確認応答する。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ１２０：Ｓ−ＣＳＣＦ ５０は、２００ ＯＫ又は他の適切なメッセージをＷＩＣ ２０に送信する。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

登録解除のバリエーションにおいて、ＷＩＣ ２０は、ステップＳ１１６にて登録解除メッセージをＩＭＳに直接送信することができ、ＡＡＡ ７０は、登録解除、及び／又はバインディング及び／又はトークンの除去についてＷＷＳＦ ３０に知らせるよう気を付ける。

図１１に、同期されたマナーにおいて登録解除をどのように行うことができるかの他のバリエーションを示す。

ステップＳ１３１：ＷＩＣ ２０は、自身のｗｅｂＲＴＣ ＩＤを伴う登録解除メッセージをＷＷＳＦ ３０に送信する。

ステップＳ１３２：ＷＷＳＦ ３０は、トークン及び／又はバインディングを除去するために、ｗｅｂＲＴＣ ＩＤを伴う要求メッセージをＡＡＡ ７０に送信する。

ステップＳ１３３：ＡＡＡ ７０は、バインディングを除去し、ＩＭＳ登録解除をＨＳＳ ６０に要求する。また、ＡＡＡ ７０は、成功した登録解除についての確認応答をＨＳＳ ６０から得た時点で、バインディングを除去することもできる。

ステップＳ１３４：ＨＳＳ ６０は、０に等しい期間満了ｔｉｍｅｒと共にｗｅｂＲＴＣ ＩＤを伴うＲＥＧＩＳＴＥＲメッセージをｅＰ−ＣＳＣＦ ４０に送信する。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

ステップＳ１３５：ｅＰ−ＣＳＣＦ ４０は、登録解除に確認応答し、間にあるすべてのノード、例えばＳ−ＣＳＣＦ ５０は、加入者プロファイルを除去する。このメッセージは、望ましくは、ＳＩＰメッセージであり得るが、ＷｅｂＳｏｃｋｅｔ、ＪＳＯＮ等のような他のプロトコルに基づくことができる。

上述した説明に基づいて、下記文書を３ＧＰＰに提案する。

議論：
現在のｗｅｂＲＴＣ ＴＲ ３３．ａｂｃは、ユーザが個人のＩＭＰＵと共にｓｕｂｓｃｒｉｐｔｉｏｎを有し、ＩＭＳとの認証を行うＩＭＳ認証メカニズム（例えば、ＩＭＳ ｄｉｇｅｓｔ）を使用するという仮定に基づいて、ＩＭＳにおけるｗｅｂＲＴＣ ＩＭＳクライアントの認証のための２つの異なるソリューションを説明している。この仮定は、ｗｅｂＲＴＣインターワーキング機能（ｗｅｂＲＴＣ ｉｎｔｅｒｗｏｒｋｉｎｇ ｆｅａｔｕｒｅ）の有用性を極めて制限する。なぜなら、もしユーザがＩＭＳクライアントを有し、ｗｅｂＲＴＣなしでＩＭＳセッションをセットアップできるならば、ｗｅｂＲＴＣ通信を使用する意味がないからである。

ＴＲ ２３．７０１における現在の研究の結論では、ｅＰ−ＣＳＣＦのための以下の機能を載せている。
−ｅＰ−ＣＳＣＦは、ＷＷＳＦにより実行されるあらゆるＵＥ認証を検証し、ＷＷＳＦにより既に認証されたＵＥのために、ＩＭＳにおいて、ＴＳ ３３．２０３に定義されているようにＴｒｕｓｔｅｄ Ｎｏｄｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ（ＴＮＡ）を実行する。
−Ｗｅｂ認証シナリオ（Ｗｅｂ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｓｃｅｎａｒｉｏｓ）のために、ｅＰ−ＣＳＣＦは、ＷＩＣに付すＩＭＳアイデンティティを割り当てることをＷＷＳＦが認可されていることを検証する。
−ｅＰ−ＣＳＣＦは、ＩＭＳ又はＷｅｂ認証シナリオを使用して、ＷＩＣのためのＩＭＳ登録を実行する。

これらの必須の機能を達成可能とするために、ｅＰ−ＣＳＣＦは、 ＷＷＳＦの使用されたアイデンティティについての知識を有する必要がある。

ＴＲ ２３．７０１のオリジナルのソリューション３においてＷ２リファレンスポイントで示されるように、ＷＷＳＦが関連情報をｅＰ−ＣＳＣＦに提供することが、ここで提案される。また、ＩＭＳ登録のプールから、ＩＭＳに対する登録を望むＷＩＣに、有効なＩＭＰＵを割り当てることをＷＷＳＦに許可することによって、ＩＭＳ登録に必須の制限を克服することが提案される。ＩＭＳ登録のプールは、ｗｉｌｄｃａｒｄｅｄ ＩＭＰＵを用いて簡単に実現できる。

ＷＩＣの要求に際して、ＷＷＳＦは、ＩＭＰＵをＷＩＣに提供し、このＩＭＰＵのためのトークンをｅＰ−ＣＳＣＦに提供する。ｅＰ−ＣＳＣＦは、この情報に基づいて、ＷＩＣからの登録要求を認証することができる。

提案：
ｗｅｂＲＴＣ ＴＲ ３３．ａｂｃに以下の文章を追加することを提案する。

６．１．ｘ ｅＰ−ＣＳＣＦでのＷＷＳＦトークンを用いてのｗｅｂＲＴＣ ＩＭＳクライアントの認証
ＷＷＳＦは、ＩＭＳオペレータのＨＳＳから受信したＩＭＳ ＩＤのプールを使用している。その背景にあるアイデアは、ｗｅｂＲＴＣサービスプロバイダが、自身のＩＭＳ ｓｕｂｓｃｒｉｐｔｉｏｎをｗｅｂＲＴＣユーザが有すると仮定せず、したがって、ｗｅｂＲＴＣサービスプロバイダが、オンデマンドでｗｅｂＲＴＣ ＩＭＳクライアントに割り当てられ得るＩＭＳ ｓｕｂｓｃｒｉｐｔｉｏｎのプールを保持する。ＩＭＳ ＩＤのプールは、ｗｉｌｄｃａｒｄｅｄ ＩＭＰＵのフォームでＷＷＳＦに提供され得る。

図１３に認証手順のコールフローを示す。

１：ＷＷＳＦは、オンデマンドでｗｅｂＲＴＣユーザにより共有されるｗｉｌｄｃａｒｄｅｄ ＩＭＰＵを用いて事前設定される。

２：ｗｅｂＲＴＣを使用可能にされたブラウザ内から、ユーザは、ＷＷＳＦとのＨＴＴＰＳ接続を開始するために、ＷＷＳＦのＵＲＩにアクセスする。ＴＬＳ接続は、サーバ証明書に基づいてサーバの一方向の認証を提供する。ブラウザは、ＷＷＳＦからＷＩＣをダウンロードし、ＷＩＣを初期設定する。

３：ＷＩＣは、自身のｗｅｂＲＴＣ ＩＤを用いて、ＩＭＳ登録情報（ＩＭＳ ｒｅｇｉｓｔｒａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）をＷＷＳＦに要求する。ＷＷＳＦは、必要であれば、認証手続を開始し得る。

４：ＷＷＳＦは、例えば、そのｗｅｂＲＴＣ ＩＤに基づいて、ｗｉｌｄｃａｒｄｅｄ ＩＭＰＵからＩＭＰＵを生成する。ＷＷＳＦは、このＩＭＰＵをｗｅｂＲＴＣ ＩＤにバインドし、トークンを生成する。

５：ＷＷＳＦは、ＩＭＰＵ及びトークンをｅＰ−ＣＳＣＦに登録する。

６：Ｐ−ＣＳＣＦ及びＷＷＳＦは、信頼関係を有し、お互いに認証し得る。ｅＰ−ＣＳＣＦは、バインディングを格納し、バインディングに確認応答する。それはバインディングのためのｖａｌｉｄｉｔｙ ｔｉｍｅｒを開始することができ、ＷＷＳＦにそのｔｉｍｅｒを提供する。

７：ＷＷＳＦは、ｗｅｂＲＴＣ ＩＤにバインドしているＩＭＰＵ及びトークンをＷＩＣに提供する。

８：ＷＩＣは、受信した情報を格納し、ＩＭＰＵ及びトークンを用いてＲＥＧＩＳＴＥＲメッセージをｅＰ−ＣＳＣＦに送信する。

９：ｅＰ−ＣＳＣＦは、ＩＭＰＵ及びトークンのバインディングを検証し、ＲＥＧＩＳＴＥＲを認可する。ｅＰ−ＣＳＣＦは、Ｓ−ＣＳＣＦによるチャレンジの必要をなくすために、そのバインディングが検証された及び／又は登録が認可されたことを示すインジケータ、フラグ、又は他のパラメータをＲＥＧＩＳＴＥＲ内に含めることができる。

１０：ｅＰ−ＣＳＣＦは、ＲＥＧＩＳＴＥＲをＳ−ＣＳＣＦに転送する。Ｓ−ＣＳＣＦは、加入者プロファイルをＨＳＳに要求する。

１１：Ｓ−ＣＳＣＦは、登録に確認応答し、このｗｅｂＲＴＣサービスプロバイダのための一般加入者プロファイルをＨＳＳから検索する。２００ ＯＫメッセージがＷＩＣへ転送される。

図１４に、この認証手順におけるＵＥ １０の構成例を示す。図１４に示すように、ＵＥ １０は、少なくとも受信部１１と、送信部１２と、を備える。受信部１１は、ＩＭＳ登録において、トークンをＷＷＳＦ ３０から受信し、２００ ＯＫメッセージをＳ−ＣＳＣＦ ５０から受信する。上述したように、Ｓ−ＣＳＣＦ ５０は、ＨＳＳ ６０からｅＰ−ＣＳＣＦ ４０を介して加入者プロファイルを受信する。送信部１２は、トークンを伴うＲＥＧＩＳＴＥＲメッセージをｅＰ−ＣＳＣＦ ４０に送信する。上述したように、ｅＰ−ＣＳＣＦ ４０は、トークンを検証し、ＲＥＧＩＳＴＥＲメッセージをＳ−ＣＳＣＦ ５０へ転送する。ＵＥ １０は、そこから認証の開始に際して、ＩＭＳ登録のための情報をＷＷＳＦ ３０に要求し得る。受信部１１は、トークンと共にＩＭＰＵをＷＷＳＦ ３０から受信し得る。送信部１２は、ＩＭＰＵ及びトークンを伴うＲＥＧＩＳＴＥＲメッセージをｅＰ−ＣＳＣＦ ４０に送信し得る。上述したように、ｅＰ−ＣＳＣＦ ４０は、トークンと共にＩＭＰＵを検証する。さらに、上述したように、ＵＥ １０は、ＷＩＣ ２０をＷＷＳＦ ３０からダウンロードすることができ、したがって、ＷＩＣ ２０として機能／動作する。なお、これらのユニット１１及び１２は、バス等を介して相互接続される。これらのユニット１１及び１２は、例えば、図１、３及び８のそれぞれに示されたＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）を介してＷＷＳＦ ３０及びｅＰ−ＣＳＣＦ ４０との通信を実行するトランシーバと、図２、４〜７、９〜１１及び１３のそれぞれに示されたプロセス又はそれに同等な（ｅｑｕｉｖａｌｅｎｔ）プロセスを実行するために、このトランシーバを制御するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等のコントローラと、で構成できる。

なお、本発明は、上記の実施の形態によって限定されるものではなく、特許請求の範囲の記載に基づき、当業者によって種々の変更が可能なことは明らかである。

上記の実施の形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。

（付記１）
ｗｅｂＲＴＣ ＩＤ及びＩＭＳ ＩＤのバインディング
ａ．バインディングは、ＨＳＳ、ＷＷＳＦ、又はＡＡＡで生成できる。
ｂ．バインディングは、（ネットワーク）エンティティ、例えばＨＳＳからＷＷＳＦ、ＷＷＳＦからｅＰ−ＣＳＣＦ、に提供することができる。
ｃ．バインディングの検証は、バインディングを生成したエンティティ、又はバインディングを提供されたエンティティで行うことができる。
ｄ．これ以上必要でなくなった時点でＩＭＳ登録解除を含めたバインディングの除去

（付記２）
ＵＥ ＷＩＣがｗｅｂアイデンティティ（ｗｅｂＲＴＣ ＩＤ）を用いてＩＭＳサービスにアクセスするときに、上述したバインディングの検証によって、オペレータは、認証及び認可を実行することができる。

（付記３）
ＷＩＣから登録メッセージを送信するための認証及び認可を制限する有効時間

（付記４）
ＷＷＳＦによるＵＥ ＷＩＣへのｅＰ−ＣＳＣＦ割り当て

（付記５）
ＩＭＳ ＩＤの代わりにｗｅｂＲＴＣ ＩＤを用いるだけでなく、静的なｗｅｂＲＴＣ ＩＤをＩＭＳバインディングに用いる、又は動的なバインディングをＩＭＳ ＩＤのプールに用いる。

この出願は、２０１３年１２月１９日に出願された日本出願特願２０１３−２６２１７０、及び２０１４年１月９日に出願された日本出願特願２０１４−００２６３３を基礎とする優先権を主張し、それらの開示の全てをここに取り込む。

１０ ＵＥ
１１ 受信部
１２ 送信部
２０ ＷＩＣ
３０ ＷＷＳＦ
４０ ｅＰ−ＣＳＣＦ
５０ Ｉ／Ｓ−ＣＳＣＦ
６０ ＨＳＳ
７０ ＡＡＡ

Claims (8)

1. 通信システムにおける認証方法であって、
   ＷＷＳＦ（ＷｅｂＲＴＣ（Ｗｅｂ Ｒｅａｌ Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ） Ｗｅｂ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ）によってトークンを認可ノードに要求することと、
   ＩＭＳ（ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ） Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）登録においてＷＷＳＦからＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）へ前記トークンを送信することと、
   前記トークンを伴うＲＥＧＩＳＴＥＲメッセージを前記ＵＥからｅＰ−ＣＳＣＦ（ｅｎｈａｎｃｅｄ Ｐｒｏｘｙ−ＣＳＣＦ（Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ））へ送信することと、
   前記ｅＰ−ＣＳＣＦによって、有効時間を有する前記トークンを検証することと、
   前記ＲＥＧＩＳＴＥＲメッセージを前記ｅＰ−ＣＳＣＦからＳ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ−ＣＳＣＦ）へ転送することと、
   加入者プロファイルをＨＳＳ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ）から前記Ｓ−ＣＳＣＦへ受信することと、
   ２００ ＯＫメッセージを前記Ｓ−ＣＳＣＦから前記ｅＰ−ＣＳＣＦを介して前記ＵＥへ送信することと、を含み、
   前記トークンは、前記ＵＥから前記ＷＷＳＦが受信したｗｅｂＲＴＣ ＩＤ（Ｉｄｅｎｔｉｔｙ）にＩＭＰＵ（ＩＭＳ ｐｕｂｌｉｃ ｕｓｅｒ ｉｄｅｎｔｉｔｙ）をバインドすることにより生成されたものであり、前記ＷＷＳＦから前記ＵＥへ送信される
   認証方法。
2. 前記認証方法の開始にあたって、前記ＵＥによって前記ＩＭＳ登録のための情報を前記ＷＷＳＦに要求することをさらに含む、請求項１に記載の認証方法。
3. 前記ＷＷＳＦは、前記トークンと共にＩＭＰＵ（ＩＭＳ ｐｕｂｌｉｃ ｕｓｅｒ ｉｄｅｎｔｉｔｙ）を前記ＵＥへ送信し、
   前記ＵＥは、前記トークンと共に前記ＩＭＰＵを伴う前記ＲＥＧＩＳＴＥＲメッセージを前記ｅＰ−ＣＳＣＦへ送信し、
   前記ｅＰ−ＣＳＣＦは、前記トークンと共に前記ＩＭＰＵを検証する、
   請求項１又は２に記載の認証方法。
4. 前記ＵＥは、ＷＩＣ（ＷｅｂＲＴＣ ＩＭＳ Ｃｌｉｅｎｔ）である、請求項１〜３のいずれか１項に記載の認証方法。
5. ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）を認証する通信システムであって、
   ＷＷＳＦ（ＷｅｂＲＴＣ（Ｗｅｂ Ｒｅａｌ Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ） Ｗｅｂ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ）と、ｅＰ−ＣＳＣＦ（ｅｎｈａｎｃｅｄ Ｐｒｏｘｙ−ＣＳＣＦ（Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ））と、Ｓ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ−ＣＳＣＦ）と、ＨＳＳ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ）と、認可ノードと、を備え、
   前記ＷＷＳＦは、トークンを前記認可ノードに要求し、
   前記ＷＷＳＦは、ＩＭＳ（ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ） Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）登録において前記トークンを前記ＵＥへ送信し、
   前記ＵＥは、前記トークンを伴うＲＥＧＩＳＴＥＲメッセージを前記ｅＰ−ＣＳＣＦへ送信し、
   前記ｅＰ−ＣＳＣＦは、有効時間を有する前記トークンを検証し、
   前記ｅＰ−ＣＳＣＦは、前記ＲＥＧＩＳＴＥＲメッセージを前記Ｓ−ＣＳＣＦへ転送し、
   前記Ｓ−ＣＳＣＦは、加入者プロファイルを前記ＨＳＳから受信し、
   前記Ｓ−ＣＳＣＦは、２００ ＯＫメッセージを前記ｅＰ−ＣＳＣＦを介して前記ＵＥへ送信し、
   前記トークンは、前記ＵＥから前記ＷＷＳＦが受信したｗｅｂＲＴＣ ＩＤ（Ｉｄｅｎｔｉｔｙ）にＩＭＰＵ（ＩＭＳ ｐｕｂｌｉｃ ｕｓｅｒ ｉｄｅｎｔｉｔｙ）をバインドすることにより生成されたものであり、前記ＷＷＳＦから前記ＵＥへ送信される
   通信システム。
6. 前記ＵＥは、前記ＩＭＳ登録のための情報を前記ＷＷＳＦに要求する、請求項５に記載の通信システム。
7. 前記ＷＷＳＦは、前記トークンと共にＩＭＰＵ（ＩＭＳ ｐｕｂｌｉｃ ｕｓｅｒ ｉｄｅｎｔｉｔｙ）を前記ＵＥへ送信し、
   前記ＵＥは、前記トークンと共に前記ＩＭＰＵを伴う前記ＲＥＧＩＳＴＥＲメッセージを前記ｅＰ−ＣＳＣＦへ送信し、
   前記ｅＰ−ＣＳＣＦは、前記トークンと共に前記ＩＭＰＵを検証する、
   請求項５又は６に記載の通信システム。
8. 前記ＵＥは、ＷＩＣ（ＷｅｂＲＴＣ ＩＭＳ Ｃｌｉｅｎｔ）である、請求項５〜７のいずれか１項に記載の通信システム。

Images