(57)【要約】  本明細書は、（ｉ）ＡＰＩインボーカーのオンボーディング、（ｉｉ）ＡＰＩインボーカーのオフボーディング、（ｉｉｉ）サービスＡＰＩの公開、（ｉｖ）サービスＡＰＩの非公開、（ｖ）サービスＡＰＩの更新、（ｖｉ）サービスＡＰＩのディスカバリ、（ｖｉｉ）サービスＡＰＩにアクセスする認可をＡＰＩインボーカーにおいてＣＣＦ（ＣＡＰＩＦ  Ｃｏｒｅ  Ｆｕｎｃｔｉｏｎ：ＣＡＰＩＦコア機能）から取得、（ｖｉｉｉ）サービス呼び出し時のＡＰＩインボーカーとＡＥＦ（ＡＰＩ  ｅｘｐｏｓｉｎｇ  ｆｕｎｃｔｉｏｎ：ＡＰＩエクスポーズ機能）との間の認証、（ｉｘ）サービスＡＰＩ取得、（ｘ）ＣＡＰＩＦイベントサブスクリプション、（ｘｉ）ＣＡＰＩＦイベントのサブスクリプション解除、（ｘｉｉ）サービスＡＰＩにアクセスするためのＡＰＩインボーカー認可などの、様々なフェーズで発生する様々なセキュリティ問題を解決するために、３ＧＰＰ  ＣＡＰＩＦ（Ｃｏｍｍｏｎ  ＡＰＩ  Ｆｒａｍｅｗｏｒｋ）のセキュリティ手順を提案する。【選択図】図２
2021516515.tif 000002
【特許請求の範囲】
【請求項１】
ＴＬＳを使用してアプリケーションサーバとの認証を行った後、オンボーディングＡＰＩインボーカー要求メッセージを前記アプリケーションサーバに送信する送信機と、
前記アプリケーションサーバから割り当てられるアプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオンボーディングＡＰＩインボーカー応答メッセージを前記アプリケーションサーバから受信する受信機と、を備える、
デバイス。
【請求項２】
前記デバイスは、前記アプリケーションサーバとＴＬＳセッションを確立する、
請求項１に記載のデバイス。
【請求項３】
前記オンボーディングＡＰＩインボーカー応答メッセージは、オンボーディングライフタイムの間同一であり続けるオンボードシークレット情報を含む、
請求項１または２に記載のデバイス。
【請求項４】
前記認証後、前記デバイスは、サービスＡＰＩへのアクセス許可を取得するために前記アプリケーションサーバに第２の要求メッセージを送信し、
前記デバイスは、前記デバイスに固有のアクセストークンを含む第２の応答メッセージを前記アプリケーションサーバから受信する、
請求項１から３のいずれか一項に記載のデバイス。
【請求項５】
前記第２の要求メッセージは、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤおよびオンボードシークレット情報を含む、
請求項４に記載のデバイス。
【請求項６】
前記ＴＬＳを使用した認証の後、前記デバイスは、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオフボードＡＰＩインボーカー要求メッセージを前記アプリケーションサーバに送信し、
前記デバイスは、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤの検証の成功に応じて、前記デバイスのオフボーディングが成功したことを示すオフボードＡＰＩインボーカー応答メッセージを前記アプリケーションサーバから受信する、
請求項１から５のいずれか一項に記載のデバイス。
【請求項７】
ＴＬＳを使用してデバイスとの認証を行った後、オンボーディングＡＰＩインボーカー要求メッセージを前記デバイスから受信する受信機と、
アプリケーションサーバから割り当てられるアプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオンボーディングＡＰＩインボーカー応答メッセージを、前記オンボーディングＡＰＩインボーカー要求メッセージに応じて前記デバイスに送信する送信機と、を備える、
アプリケーションサーバ。
【請求項８】
前記アプリケーションサーバは、前記デバイスとＴＬＳセッションを確立する、
請求項７に記載のアプリケーションサーバ。
【請求項９】
前記オンボーディングＡＰＩインボーカー応答メッセージは、オンボーディングライフタイムの間同一であり続けるオンボードシークレット情報を含む、
請求項７または８に記載のアプリケーションサーバ。
【請求項１０】
前記認証後、前記アプリケーションサーバは、サービスＡＰＩへのアクセス許可を取得するために前記デバイスから第２の要求メッセージを受信し、
前記アプリケーションサーバは、前記デバイスに固有のアクセストークンを生成し、
前記アプリケーションサーバは、前記アクセストークンを含む第２の応答メッセージを前記デバイスに送信する、
請求項７から９のいずれか一項に記載のアプリケーションサーバ。
【請求項１１】
前記第２の要求メッセージは、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤおよびオンボードシークレット情報を含む、
請求項１０に記載のアプリケーションサーバ。
【請求項１２】
前記ＴＬＳを使用した認証の後、前記アプリケーションサーバは、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオフボードＡＰＩインボーカー要求メッセージを前記デバイスから受信し、
前記アプリケーションサーバは、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤを検証し、
前記アプリケーションサーバは、前記デバイスの登録をキャンセルし、
前記アプリケーションサーバは、前記デバイスの認可情報を削除し、
前記アプリケーションサーバは、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤの検証の成功に応じて、オフボーディングの成功を示すオフボードＡＰＩインボーカー応答メッセージを前記デバイスに送信する、
請求項７から１１のいずれか一項に記載のアプリケーションサーバ。
【請求項１３】
前記アプリケーションサーバは、オペレータのポリシーに応じて前記デバイスの情報を保持する、
請求項１２に記載のアプリケーションサーバ。
【請求項１４】
デバイスにおける情報処理方法であって、
ＴＬＳを使用してアプリケーションサーバとの認証を行った後、オンボーディングＡＰＩインボーカー要求メッセージを前記アプリケーションサーバに送信することと、
前記アプリケーションサーバから割り当てられるアプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオンボーディングＡＰＩインボーカー応答メッセージを前記アプリケーションサーバから受信することと、を備える、
情報処理方法。
【請求項１５】
前記アプリケーションサーバとＴＬＳセッションを確立することを備える、
請求項１４に記載の情報処理方法。
【請求項１６】
前記オンボーディングＡＰＩインボーカー応答メッセージは、オンボーディングライフタイムの間同一であり続けるオンボードシークレット情報を含む、
請求項１４または１５に記載の情報処理方法。
【請求項１７】
前記認証後、サービスＡＰＩへのアクセス許可を取得するために前記アプリケーションサーバに第２の要求メッセージを送信することと、
前記デバイスに固有のアクセストークンを含む第２の応答メッセージを前記アプリケーションサーバから受信することと、を備える、
請求項１４から１６のいずれか一項に記載の情報処理方法。
【請求項１８】
前記第２の要求メッセージは、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤおよびオンボードシークレット情報を含む、
請求項１７に記載の情報処理方法。
【請求項１９】
前記ＴＬＳを使用した認証の後、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオフボードＡＰＩインボーカー要求メッセージを前記アプリケーションサーバに送信することと、
前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤの検証の成功に応じて、前記デバイスのオフボーディングが成功したことを示すオフボードＡＰＩインボーカー応答メッセージを前記アプリケーションサーバから受信することと、を備える、
請求項１４から１８のいずれか一項に記載の情報処理方法。
【請求項２０】
アプリケーションサーバにおける情報処理方法であって、
ＴＬＳを使用してデバイスとの認証を行った後、オンボーディングＡＰＩインボーカー要求メッセージを前記デバイスから受信することと、
アプリケーションサーバから割り当てられるアプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオンボーディングＡＰＩインボーカー応答メッセージを、前記オンボーディングＡＰＩインボーカー要求メッセージに応じて前記デバイスに送信することと、を備える、
情報処理方法。
【請求項２１】
前記デバイスとＴＬＳセッションを確立することを備える、
請求項２０に記載の情報処理方法。
【請求項２２】
前記オンボーディングＡＰＩインボーカー応答メッセージは、オンボーディングライフタイムの間同一であり続けるオンボードシークレット情報を含む、
請求項２０または２１に記載の情報処理方法。
【請求項２３】
前記認証後、サービスＡＰＩへのアクセス許可を取得するために前記デバイスから第２の要求メッセージを受信することと、
前記デバイスに固有のアクセストークンを生成することと、
前記アクセストークンを含む第２の応答メッセージを前記デバイスに送信することと、を備える、
請求項２０から２２のいずれか一項に記載の情報処理方法。
【請求項２４】
前記第２の要求メッセージは、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤおよびオンボードシークレット情報を含む、
請求項２３に記載の情報処理方法。
【請求項２５】
前記ＴＬＳを使用した認証の後、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオフボードＡＰＩインボーカー要求メッセージを前記デバイスから受信することと、
前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤを検証することと、
前記デバイスの登録をキャンセルすることと、
前記デバイスの認可情報を削除することと、
前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤの検証の成功に応じて、オフボーディングの成功を示すオフボードＡＰＩインボーカー応答メッセージを前記デバイスに送信することと、を備える、
請求項２０から２４のいずれか一項に記載の情報処理方法。
【請求項２６】
オペレータのポリシーに応じて前記デバイスの情報を保持することを備える、
請求項２５に記載の情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムに関する。特に、本発明は、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）規格、またはこれと同等もしくは派生の規格に従って動作する無線通信システムおよびそのデバイスに関するが、これに限定されない。特に、本発明は、いわゆる「５Ｇ」（または「次世代」）システムにおけるセキュリティ手順に関するが、これに限定されない。
【背景技術】
【０００２】
従来、３ＧＰＰにおける複数のＷＧ（Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ：ワーキンググループ）は、３ＧＰＰシステムの外部のノースバウンドＡＰＩインターフェースをサポートするさまざまなソリューションを規定してきた。これらの仕様は、相互の関連なく、個別のニーズによってトリガされた。これにより、個別のニーズに対応する、互換性のない複数のＡＰＩ定義が生じた。直近では、３ＧＰＰ  ＳＡ２がノースバウンドＡＰＩを規定して、外部エンティティが、３ＧＰＰシステムから提供されるサービスにＳＣＥＦ（Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｙ  Ｅｘｐｏｓｉｎｇ  Ｆｕｎｃｔｉｏｎ）を介してアクセスできるようにしている。３ＧＰＰは、ｏｎｅＭ２Ｍなどの外部ＳＤＯからの要求に応じて、ＳＣＥＦのＡＰＩを規定している。
【０００３】
これまでのところ、３ＧＰＰは、３ＧＰＰシステムから提供されるサービスへのＡＰＩを介したアクセスを外部エンティティに提供するための共通フレームワークを規定していない。ＬＴＥのＳＣＥＦおよび５ＧのＮＥＦは、このような共通フレームワークを利用可能な２つの例である。
【０００４】
この状況に対処するために、Ｒｅｌｅａｓｅ１５では、３ＧＰＰ  ＳＡ６  ＷＧがステージ２の仕様書（ＴＳ２３．２２２［２］）を規定し、３ＧＰＰの将来のいずれのＡＰＩ定義でも使用可能なＣＡＰＩＦ（Ｃｏｍｍｏｎ  ＡＰＩ  Ｆｒａｍｅｗｏｒｋ：共通ＡＰＩフレームワーク）のアーキテクチャを定義した。このステージ２のＴＳ（Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ：技術仕様書）は、サードパーティＡＰＩプロバイダがユーザにサービスを提供することのできるアーキテクチャを規定している。この規範的文書に先立って行われた調査は３ＧＰＰ  ＴＲ（Ｔｅｃｈｎｉｃａｌ  Ｒｅｐｏｒｔ：技術報告書）２３．７２２［１］にまとめられており、次の規範的仕様書ＴＳ２３．２２２［２］のベースとして使用された。このステージ２の仕様書は２０１７年１２月に完成した。
【０００５】
現在、３ＧＰＰ  ＳＡ３では、ＣＡＰＩＦのセキュリティの側面を規定するＷＩ（Ｗｏｒｋ  Ｉｔｅｍ：作業項目）が進められている。これに対応するＳＡ３  ＴＳは３３．１２２［３］である。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
［２］および［３］の仕様書は、セキュリティの観点からいくつかの問題がある。これらを以下に説明する。
【０００７】
（ｉ）ＡＰＩインボーカーのオンボーディング
ａ．ＡＰＩインボーカーのオンボーディングの手順では、当該手順におけるセキュリティ関連の側面が指定されていない。オンボーディング手順には、ＡＰＩインボーカーの位置／ゾーンに関する情報（信頼可／信頼不可／トラストレベル）がない。
ｂ．オンボーディング処理が成功した後、ＣＣＦ（ＣＡＰＩＦ  Ｃｏｒｅ  Ｆｕｎｃｔｉｏｎ：ＣＡＰＩＦコア機能）はＡＰＩインボーカーＩＤ（ｉｄｅｎｔｉｆｅｒ：識別子）をＡＰＩインボーカーに割り当てるが、この識別子はＣＣＦ固有ではない。このため、ＡＰＩインボーカーＩＤの割り当てと管理を制御できなくなるおそれがある。
ｃ．当該システムは、オンボーディング結果の、サービスＡＰＩのディスカバリ、認証、ＡＰＩインボーカーの認可などの後続の手順へのバインディングを行わない。
ｄ．オンボーディングは、ＡＰＩインボーカーをＣＡＰＩＦの認識されたユーザとして登録する１回限りのオンボーディング処理として記載されているが、当該システムにはオフボーディング処理もある。すなわち、ＣＡＰＩＦからオフボードされたＡＰＩインボーカーが、過去にオフボードされたのと同一のＣＡＰＩＦによって制御されるサービスＡＰＩにアクセスする必要がある場合、当該ＡＰＩインボーカーは、再度ＣＡＰＩＦにオンボードして対応のサービスＡＰＩにアクセスする必要がある。このため、ＡＰＩインボーカーはそのライフタイム中に複数回オンボーディングを行うことが予測される。さらに、ライフタイムの有効性を必要としないまたは信頼性のないＡＰＩインボーカーにライフタイムに亘って有効性を与えることは、リソースの不十分な活用、リソースの枯渇、およびセキュリティの問題につながるおそれがある。
【０００８】
（ｉｉ）ＡＰＩインボーカーのオフボーディング
ａ．当該システムでは、ＡＰＩインボーカー主導によるオフボーディングのみ行われる。悪意のあるＡＰＩインボーカーがサービスＡＰＩへのアクセスを悪用した場合、そのようなアクティビティを抑制する方法はない。
ｂ．ＣＡＰＩＦコア機能主導によるＡＰＩインボーカーのオフボーディングを行わないことで、悪意のあるＡＰＩインボーカーアクティビティからの保護を行う。
［６］および［７］の過去の文献では、ＣＡＰＩＦコア機能主導によるオフボーディング手順について説明しているが、セキュリティの側面については説明がない。
ｃ．さらに、ＡＰＩインボーカー主導によるオフボーディング処理では、ＡＰＩインボーカーによってトリガされたオフボーディング呼び出しの真正性を確認するメカニズムが定義されていない。
【０００９】
（ｉｉｉ）サービスＡＰＩの公開
ａ．ＣＡＰＩＦは、ＡＰＩプロバイダによるサービスＡＰＩの公開をサポートしている。真正のサービスＡＰＩプロバイダになりすましてサービスＡＰＩを公開するアタッカーは、悪意のあるサービスにつながるおそれがある。
ｂ．サービスＡＰＩの公開手順では、ＡＰＩプロバイダおよびサービスＡＰＩ連携の認可情報について明らかにしていない。セキュリティの向上のために他の側面とバインドする認可情報については説明がない。
ｃ．サービスＡＰＩの手順には、サービスＡＰＩの公開期間の割り当てが含まれないため、サービスＡＰＩの管理が無効になるおそれがある。
【００１０】
（ｉｖ）サービスＡＰＩの非公開
ａ．ＣＡＰＩＦは、ＡＰＩプロバイダによるサービスＡＰＩの非公開をサポートしている。サービスＡＰＩ情報を非公開にすると、ＡＰＩインボーカーはそれをディスカバーすることができなくなる。したがって、サービスＡＰＩを非公開にする何らかの不正行為によって、サービスＡＰＩが利用不可になるおそれがある。
ｂ．サービスＡＰＩを非公開にする手順で使用される認証および認可情報に厳密に何が含まれるかについては、明確な情報が存在しない。
【００１１】
（ｖ）サービスＡＰＩの更新
ａ．ＣＡＰＩＦは、対応のＡＰＩ公開機能によって公開されたサービスＡＰＩの更新をサポートする。しかしながら、過去に公開されたサービスＡＰＩの更新を行う場合、ＡＰＩ公開機能がＣＡＰＩＦコア機能によってどのように認証または認可されるかについては、明確な情報が存在しない。
ｂ．ＴＳ２３．２２２［２］の８．６節で説明されるサービスＡＰＩ手順の更新に使用される認証および認可情報に厳密に何が含まれるかについても、明確な情報が存在しない。
【００１２】
（ｖｉ）サービスＡＰＩのディスカバリ
ａ．ＣＡＰＩＦにおけるサービスＡＰＩディスカバリ手順では、セキュリティ要件が定義されていない。
ｂ．異なるトラストゾーンに位置する異なるＡＰＩインボーカーに対してまたはＡＰＩインボーカーのトラストレベルに基づいて定義または決定されたディスカバリレベル間には、明確な境界は存在しない。
ｃ．悪意のあるＡＰＩインボーカーはネットワークセキュリティの問題を引き起こす可能性があるため、サービストポロジを、トラストレベルに基づいて、サービスＡＰＩのトラストドメイン外のサービスＡＰＩをディスカバーしてアクセスするＡＰＩインボーカーから隠す必要がある。
ｄ．ＡＰＩインボーカーによるＡＰＩサービスのディスカバリと、ＡＥＦ（ＡＰＩ  Ｅｘｐｏｓｉｎｇ  Ｆｕｎｃｔｉｏｎ：ＡＰＩエクスポーズ機能）およびＣＣＦによるトポロジの隠蔽とはバインドされていない。サービスＡＰＩディスカバリの結果とトポロジ隠蔽の決定とをバインドしないことは、トポロジの隠蔽の非効率につながるおそれがある。
【００１３】
（ｖｉｉ）ＣＣＦから認可を取得してサービスＡＰＩにアクセスするＡＰＩインボーカー
ａ．ＡＰＩインボーカーとＣＣＦの間において、ＣＡＰＩＦ認証とサービスＡＰＩ認可要求とにバインディングがないことは、正当なＡＰＩインボーカーに宛てられた呼び出し／アクセストークンを取得したアタッカーによる中間者攻撃を許すおそれがある。
ｂ．呼び出し／アクセストークンを悪用してセッションを固定することが可能であるため、ハッカーは、実際のユーザの呼び出し／アクセストークンを使用して当該ユーザのアカウントにアクセスする。呼び出し／アクセストークンの生成に対してＡＥＦ  ＩＤ、ＣＡＰＩＦ  ＩＤおよびサービスＡＰＩ連携ＩＤがバインドされていないと、複数のＡＰＩインボーカーが同一の呼び出し／アクセストークンでサービスＡＰＩを要求した場合に、ＣＣＦまたはＡＥＦでのＡＰＩインボーカーの認可検証が問題になるおそれがある。
ｃ．ＣＡＰＩＦコア機能またはサービスＡＰＩは、ＤｏＳ攻撃に対する脆弱性がある。多数のアクセス試行があると、この状態のＣＡＰＩＦは、正常な動作のために、フラッディングしてシャットダウンする可能性がある。
ｄ．ＣＣＦまたはＡＥＦにおいて、すべてのＡＰＩインボーカーの認可要求またはサービスＡＰＩアクセス要求に対してＡＰＩインボーカー関連認証／認可カウンタの制御を維持および実施しなければ、ＣＣＦ、ＡＥＦ、およびサービスＡＰＩプロバイダへのＤｏＳ攻撃を許すおそれがある。
ｅ．ノンスまたはタイムスタンプベースのサービスＡＰＩ認可要求／応答手順の欠如は、リプレイ攻撃を許すおそれがある。
【００１４】
（ｖｉｉｉ）サービス呼び出し時のＡＰＩインボーカーとＡＥＦとの間の認証
ａ．すべてのサービスＡＰＩ呼び出しに対するＡＰＩインボーカーとＡＰＩエクスポーズ機能との間の認証には時間がかかり、サービス呼び出しプロセスを遅延させる可能性がある。
ｂ．サービス呼び出し時にＡＰＩインボーカーとＡＥＦとの間の認証にそのまま使用する場合、または繰り返し使用する場合、初期認証中にＣＣＦ／ＡＥＦからＡＰＩインボーカーによって受信された呼び出し／アクセストークンまたは認証／認可情報は、リプレイまたはマスカレード攻撃を許すおそれがある。
【００１５】
（ｉｘ）サービスＡＰＩの取得
ａ．ＣＡＰＩＦは、対応のＡＰＩ公開機能によって公開されたサービスＡＰＩの更新をサポートする。しかしながら、過去に公開されたサービスＡＰＩの更新を行う場合、ＡＰＩ公開機能がＣＡＰＩＦコア機能によってどのように認証または認可されるかについては、明確な情報が存在しない。
ｂ．ＴＳ２３．２２２［２］の８．５節で説明されるサービスＡＰＩ手順の更新に使用される認証および認可情報に厳密に何が含まれるかについても、明確な情報が存在しない。
【００１６】
（ｘ）ＣＡＰＩＦイベントサブスクリプション
ａ．ＣＡＰＩＦコア機能により、サブスクライブエンティティ（すなわち、ＡＰＩインボーカー、ＡＰＩエクスポーズ機能、ＡＰＩ公開機能、およびＡＰＩ管理機能）は、サービスＡＰＩの可用性イベント、サービスＡＰＩ情報の変更、サービスＡＰＩ呼び出しのモニタリング、ＡＰＩインボーカーオンボーディングイベントなどのＣＡＰＩＦイベントにサブスクライブすることができる。
ｂ．ＣＡＰＩＦイベントサブスクリプション手順では、悪意のあるＡＰＩインボーカーまたはサブスクライブエンティティがイベント通知にサブスクライブするのを防ぐために、ＡＰＩインボーカーまたはサブスクライブエンティティの認証または認可が具体的にどのように実行されるかについての説明がない。何らかの悪意のあるエンティティへのＣＡＰＩＦイベントのサブスクリプションおよび通知は、悪影響をもたらす。
【００１７】
（ｘｉ）ＣＡＰＩＦイベントのサブスクリプション解除
ａ．ＣＡＰＩＦコア機能は、基準に一致するイベントをサブスクライブしたすべてのサブスクライブエンティティにイベント通知を送信する。
ｂ．ＣＡＰＩＦイベントのサブスクリプション解除手順においては、正規のＡＰＩインボーカー／サブスクライブエンティティのイベント通知が悪意のあるＡＰＩインボーカーによってサブスクリプション解除されるのを防ぐために、ＡＰＩインボーカーの認証または認可が具体的にどのように実行されるかについての説明がない。
【００１８】
（ｘｉｉ）サービスＡＰＩへのＡＰＩインボーカーのアクセス認可
ａ．ＴＳ３３．１２２の５．２．２．２節と５．２．２．３節には、「ＣＡＰＩＦ−２ｅ参照ポイントでＴＬＳが正常に確立された後、ＡＰＩエクスポーズ機能は、ＴＳ２３．２２２［３］で規定されたＡＰＩインボーカーの認可権限をＣＡＰＩＦコア機能によって取得する。」と記載がある。ＴＳ２３．２２２の８．１５．２節「情報フロー」には、当該手順のセキュリティ関連情報フローを開発することがＳＡ３の範囲内であることを確認する注記がある。したがって、当該ＮＩＤは、ＡＥＦがＡＰＩインボーカーの認可権限を取得する場合のセキュリティ手順をＴＳ３３．１２２に組み込むことを提案している。
【００１９】
（ｘｉｉｉ）ＡＰＩインボーカーの認証
ａ．ＴＳ３３．１２２の５．２．２節は、アクセストークンを使用したＣＡＰＩＦ−２ｅインターフェースの認証と保護について説明している。当該説明の手順では、認証とアクセストークンの生成とが一切バインドされておらず、リプレイ攻撃などセキュリティ上の問題が生じるおそれがある。したがって、ＮＩＤは、ＣＡＰＩＦ−１ｅ認証中に導出したキーとアクセストークンの生成とをバインドすることを提案する。
【００２０】
本明細書では、１つ以上のセキュリティ問題を解決または少なくとも軽減するために、ＣＡＰＩＦのセキュリティ手順の複数の例を以下に説明する。当該手順には次の項目が含まれるが、限定的なものではない。（ｉ）ＡＰＩインボーカーのオンボーディング、（ｉｉ）ＡＰＩインボーカーのオフボーディング、（ｉｉｉ）サービスＡＰＩの公開、（ｉｖ）サービスＡＰＩの非公開、（ｖ）サービスＡＰＩの更新、（ｖｉ）サービスＡＰＩのディスカバリ、（ｖｉｉ）サービスＡＰＩにアクセスする認可をＡＰＩインボーカーにおいてＣＣＦ（ＣＡＰＩＦ  Ｃｏｒｅ  Ｆｕｎｃｔｉｏｎ：ＣＡＰＩＦコア機能）から取得、（ｖｉｉｉ）サービス呼び出し時のＡＰＩインボーカーとＡＥＦ（ＡＰＩ  ｅｘｐｏｓｉｎｇ  ｆｕｎｃｔｉｏｎ：ＡＰＩエクスポーズ機能）との間の認証、（ｉｘ）サービスＡＰＩ取得、（ｘ）ＣＡＰＩＦイベントサブスクリプション、（ｘｉ）ＣＡＰＩＦイベントのサブスクリプション解除、（ｘｉｉ）サービスＡＰＩにアクセスするためのＡＰＩインボーカー認可、（ｘｉｉｉ）ＡＰＩインボーカーの認証など。
【課題を解決するための手段】
【００２１】
本開示の一態様によれば、デバイスは、
ＴＬＳを使用してアプリケーションサーバとの認証を行った後、オンボーディングＡＰＩインボーカー要求メッセージを前記アプリケーションサーバに送信する送信機と、
前記アプリケーションサーバから割り当てられるアプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオンボーディングＡＰＩインボーカー応答メッセージを前記アプリケーションサーバから受信する受信機と、を備える。
【００２２】
本開示の別の一態様によれば、アプリケーションサーバは、
ＴＬＳを使用してデバイスとの認証を行った後、オンボーディングＡＰＩインボーカー要求メッセージを前記デバイスから受信する受信機と、
アプリケーションサーバから割り当てられるアプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオンボーディングＡＰＩインボーカー応答メッセージを、前記オンボーディングＡＰＩインボーカー要求メッセージに応じて前記デバイスに送信する送信機と、を備える。
【００２３】
本開示の別の一態様によれば、デバイスにおける情報処理方法は、
ＴＬＳを使用してアプリケーションサーバとの認証を行った後、オンボーディングＡＰＩインボーカー要求メッセージを前記アプリケーションサーバに送信することと、
前記アプリケーションサーバから割り当てられるアプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオンボーディングＡＰＩインボーカー応答メッセージを前記アプリケーションサーバから受信することと、を備える。
【００２４】
本開示の別の一態様によれば、アプリケーションサーバにおける情報処理方法は、
ＴＬＳを使用してデバイスとの認証を行った後、オンボーディングＡＰＩインボーカー要求メッセージを前記デバイスから受信することと、
アプリケーションサーバから割り当てられるアプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオンボーディングＡＰＩインボーカー応答メッセージを、前記オンボーディングＡＰＩインボーカー要求メッセージに応じて前記デバイスに送信することと、を備える。
【図面の簡単な説明】
【００２５】
【図１】図１は、本発明の実施形態を適用可能なシステムの例を概略的に示す。
【図２】図２は、ＣＡＰＩＦにＡＰＩインボーカーをオンボードする場合のセキュリティ手順の例を概略的に示す。
【図３】図３は、ＡＰＩインボーカー主導によるＣＡＰＩＦからのオフボーディングの手順の例を概略的に示す。
【図４】図４は、ＣＡＰＩＦ主導によるＣＡＰＩＦからのオフボーディングの手順の例を概略的に示す。
【図５】図５は、サービスＡＰＩを公開する場合のセキュリティ手順の例を概略的に示す。
【図６】図６は、サービスＡＰＩを非公開にする場合のセキュリティ手順の例を概略的に示す。
【図７】図７は、サービスＡＰＩを更新する場合のセキュリティ手順の例を概略的に示す。
【図８】図８は、サービスＡＰＩをディスカバーする場合のセキュリティ手順の例を概略的に示す。
【図９】図９は、ＡＰＩインボーカーがサービスＡＰＩアクセスの認可を取得する場合のセキュリティ手順の例を概略的に示す。
【図１０】図１０は、サービスＡＰＩ呼び出し時にＡＰＩインボーカーとＡＥＦとの間で認証を行う場合のセキュリティ手順の例を概略的に示す。
【図１１】図１１は、呼び出しトークン＊を導出する場合の手順の例を概略的に示す。
【図１２】図１２は、サービスＡＰＩを取得する場合のセキュリティ手順の例を概略的に示す。
【図１３】図１３は、ＣＡＰＩＦイベントサブスクリプションのセキュリティ手順の例を概略的に示す。
【図１４】図１４は、ＣＡＰＩＦイベントのサブスクリプション解除を行う場合のセキュリティ手順の例を概略的に示す。
【図１５】図１５は、サービスＡＰＩへのＡＰＩインボーカーのアクセス認可の手順の例を概略的に示す。
【図１６】図１６は、上記の実施形態を適用可能なモバイル（セルラまたは無線）通信システム１を概略的に示す。
【図１７】図１７は、図１６に示すＵＥ（モバイルデバイス３）の主な構成要素を示すブロック図である。
【図１８】図１８は、図１６に示す（Ｒ）ＡＮノード５（基地局）の主な構成要素の例を示すブロック図である。
【図１９】図１９は、例えば図１６に示すＣＰＦ８またはＵＰＦ９（またはＡＰＩインボーカー２０）などの一般的なコアネットワークノード（または機能）の主な構成要素を示すブロック図である。
【発明を実施するための形態】
【００２６】
図１は、本発明の実施形態を適用可能なシステムの例を概略的に示す。図１に示すアーキテクチャは、ＴＳ２３．２２２［２］の６．２項で説明されているＣＡＰＩＦアーキテクチャの全体に対応する。
【００２７】
図１では、ＣＡＰＩＦ−１からＣＡＰＩＦ−５は、論理エンティティ間の参照ポイントを指す。
【００２８】
−ＣＡＰＩＦ−１：ＡＰＩインボーカー２０とＣＣＦ２１との間の参照ポイントであり、ＡＰＩインボーカー２０がＰＬＭＮのトラストドメイン内にある。
−ＣＡＰＩＦ−１ｅ：ＡＰＩインボーカー２０とＣＣＦ２１との間の参照ポイントであり、ＡＰＩインボーカー２０がＰＬＭＮのトラストドメイン内にある。
−ＣＡＰＩＦ−２：ＡＰＩインボーカー２０とＡＥＦ２２との間の参照ポイントであり、ＡＰＩインボーカー２０がＰＬＭＮのトラストドメイン内にある。
−ＣＡＰＩＦ−２ｅ：ＡＰＩインボーカー２０とＡＥＦ２２との間の参照ポイントであり、ＡＰＩインボーカー２０がＰＬＭＮのトラストドメイン内にある。
−ＣＡＰＩＦ−３：ＣＣＦ２１とＡＥＦ２２との間の参照ポイント。
−ＣＡＰＩＦ−４：ＣＣＦ２１とＡＰＦ（ＡＰＩ  Ｐｕｂｌｉｓｈｉｎｇ  Ｆｕｎｃｔｉｏｎ：ＡＰＩ公開機能）２３との間の参照ポイント。
−ＣＡＰＩＦ−５：ＣＣＦ２１とＡＭＦ（ＡＰＩ  Ｍａｎａｇｅｍｅｎｔ  Ｆｕｎｃｔｉｏｎ：ＡＰＩ管理機能）２４との間の参照ポイント。
【００２９】
２．詳細な説明
【００３０】
上述の問題に対応するセキュリティ手順を、それぞれサブセクション２．１からサブセクション２．１３として以下に詳細に説明する。
【００３１】
以下の説明を明確にするために、このセクションで提案されるパラメータ（図を含む）は、以下のＣＡＰＩＦセキュリティ手順において太字または下線を付して示される。しかしながら、本発明は、図で強調した点に限定されない。セクション２．１からセクション２．１３に記載のすべてのＣＡＰＩＦセキュリティ手順（当該手順に用いる全パラメータ）は、ＣＡＰＩＦの通信エンティティ間における過去の認証または認可手順のいずれかから導出したセキュリティコンテキストによってその機密性および／または完全性が保護される。
【００３２】
２．１  ＡＰＩインボーカーのオンボーディングのセキュリティ手順
【００３３】
このセクションにおける説明は、ＴＳ２３．２２２［２］の８．１項で説明されている手順に対応する。
【００３４】
図２は、ＣＡＰＩＦにＡＰＩインボーカー２０をオンボードする場合のセキュリティ手順の例を概略的に示す。
【００３５】
認可およびオンボードトークンは、１つ以上の情報を使用して生成することができる。以下に、当該トークンを生成する方法の一実施例を示す。ただし、他の種類の情報を使用する他の生成方法も除外されない。
【表１】
2021516515.tif 000003
【００３６】
オンボードトークン生成の変形例：オンボードトークンの生成は、以下の任意の組み合わせにバインドされるものとする。ＡＰＩプロバイダＩＤ／ＣＡＰＩＦコア機能固有のＡＰＩインボーカーＩＤ｜｜ＣＡＰＩＦ  ＩＤ｜｜オンボーディングサブスクリプションタイプ｜｜ディスカバリレベル｜｜ライフタイム｜｜シークレット。
【００３７】
シークレットまたはシークレット乱数の変形例として、ＣＣＦ２１によって生成された任意の乱数を事前に設定することができる。
【００３８】
ＡＰＩインボーカー２０（デバイスまたはサブスクライバまたはサブスクリプション）とＣＡＰＩＦコア機能２１／ネットワークとの間で、ＴＬＳ、またはＥＡＰ−ＡＫＡ’や５Ｇ  ＡＫＡなど関連の認証メカニズム、または任意のセキュリティ方法を使用したＡＰＩインボーカーオンボーディング処理の前に、認証／認可手順が行われる。例えば、ＮＡＳシグナリングの一部として確立されたセキュリティコンテキスト（例えば、ＵＥアタッチ手順）は、ＵＥとネットワークとの間で相互認証が確立された後、アプリケーションレイヤと（すなわち、ＡＰＩインボーカー２０とＣＡＰＩＦコア機能２１との間で）共有可能である。オンボーディング手順を保証するのに必要なセキュリティコンテキストは、ＮＡＳシグナリングの保護のために導出されたセキュリティコンテキストから明示的に導出される。当該セキュリティコンテキストを使用してＣＡＰＩＦオンボーディング保護キーを導出することで、ＡＰＩインボーカー２０とＣＣＦ２１との間におけるオンボーディングメッセージ（オンボーディング処理に用いるパラメータまたは情報要素）のやり取りの機密性および／または完全性を保護することができる。
【００３９】
変形例：ＡＰＩインボーカー２０とＣＡＰＩＦコア機能２１との間におけるオンボーディングメッセージのやり取りの機密性または整合性の保護のために必要なセキュリティコンテキスト、あるいはセクション２．１「ＡＰＩインボーカーのオンボーディングのセキュリティ手順」または図２を参照して説明したパラメータが、ネットワークによってＡＰＩインボーカー２０に事前に設定される。
【００４０】
１．ＡＰＩインボーカー２０は、サブスクリプション識別情報、サブスクリプション識別子、サブスクライバ識別子またはデバイス識別子、ユーザまたはデバイス固有のアプリケーション識別子、要求されたサブスクリプションタイプ、その位置におけるトラストゾーンレベル指標またはゾーンＩＤ（Ｚｏｎｅ  Ｉｄｅｎｔｉｆｉｅｒ：ゾーン識別子）、および最大または最小のオンボーディングライフタイム（オプションのパラメータ）を含むＡＰＩインボーカー情報と併せて、オンボーディングＡＰＩインボーカー要求をＣＡＰＩＦコア機能２１に送信する。
ａ．変形例：ゾーンＩＤは、ＡＰＩインボーカー２０がネットワークに接続する際に経由するアクセスポイント名またはアクセスネットワーク関連情報であってもよい。
ｂ．変形例：ＴＳ３３．５０１の５．７．１節の「トラストバウンダリ」には、「この項における一連の要件は、モバイルネットワークオペレータがネットワークをトラストゾーンに分割することを想定している。事業者が異なるサブネットワークは、異なるトラストゾーンに位置すると想定される」とある。ここでの提案は、すべてのデバイスにＡＰＮ（Ａｃｃｅｓｓ  Ｐｏｉｎｔ  Ｎａｍｅ：アクセスポイント名）またはアクセスネットワーク情報を持たせることである。これにより、デバイスが共有のＡＰＮを介してネットワークに接続する場合、ＣＣＦ２１は、受信したＡＰＮ情報と自身が記憶するトラスト値とを利用して、特定のＡＰＩインボーカーのサービスＡＰＩ要求に対するトラストを分析する。これをサポートするために、ＣＣＦ２１は、各ゾーンに関する情報、ゾーン内のＡＰＮに関する情報、および各ゾーンに対応するトラスト値、またはＣＣＦ２１／ネットワークおよび各トラストゾーンに対応するトラスト値を記憶する必要がある。
ｃ．変形例：ＡＰＩインボーカー情報には、ユーザ固有のアプリケーションＩＤ、サブスクリプション／サブスクライバＩＤ、またはサードパーティのアプリケーションＩＤと併せて、当該ＩＤのクレデンシャル（例えば、パスワード）が含まれる。ＡＰＩインボーカー情報にユーザのプライバシーに影響を与えるユーザ固有ＩＤが含まれる場合、識別子を隠した状態で送信する必要がある。
【００４１】
２．ＣＣＦ２１は、ＡＰＩインボーカー情報を受信すると、この特定のＡＰＩインボーカー２０が過去にオンボードされたか否かを検証する。当該ＡＰＩインボーカー２０が既にＣＣＦ２１にオンボードされている場合、オンボーディングＡＰＩインボーカー要求メッセージを無視する。当該ＡＰＩインボーカー２０が過去にオンボードされていない場合、ＣＣＦ２１は、オンボーディングＡＰＩインボーカー要求メッセージ中で受信したＡＰＩインボーカーのサブスクリプション関連情報、受信したゾーンＩＤ関連トラスト情報、ＡＰＩインボーカー２０および／またはその位置／ネットワーク情報の両方のトラストレベル、またはＡＰＩインボーカーがネットワークに接続するアクセスポイントのトラスト値／ＡＰＩインボーカーがネットワークに接続するゾーンのトラスト値を、自身が記憶する情報に基づいて検証する。検証が成功してＡＰＩインボーカーがオンボーディングライフタイムを要求した場合、ＣＣＦ２１は、当該検証結果に基づいて、ＡＰＩインボーカー２０のオンボーディングライフタイムを割り当て、ＡＰＩ提供の情報とオンボーディング結果とを後の使用のために（ＡＰＩインボーカーサービスのディスカバリの可能性を設定するために）記憶する。トラストレベルとオンボーディング結果に基づいて、オンボーディング／登録へのサブスクリプション、およびサービスＡＰＩディスカバリのトポロジ隠蔽のレベルが決定され、関連のデータがＣＣＦ２１に記憶される。ＡＰＩインボーカー２０によって要求されたオンボーディングライフタイムパラメータはオプションであってもよく、ＣＣＦ２１は、ＡＰＩインボーカー情報、ＡＰＩインボーカーの在圏ゾーンのトラストレベル、サブスクリプションの検証とそのポリシーに基づいて、オンボーディングライフタイムを決定する。ＣＣＦ２１は、ＡＰＩインボーカー２０から要求があった場合、オンボーディングライフタイム値を決定する。
ａ．変形例：すべてのデバイスがＡＰＮ情報を有する。これにより、デバイスが共有のＡＰＮを介してネットワークに接続する場合、ＣＣＦ２１は、自身が記憶するＡＰＮ情報（トラスト値）を利用して、特定のＡＰＩインボーカーに関する側面についてトラストを分析する。
【００４２】
３．ＡＰＩインボーカー２０のオンボーディングの許可の取得が成功した場合、ＣＣＦ２１は、オンボーディングＡＰＩインボーカー応答メッセージを、成功通知、ＣＡＰＩＦ  ＩＤ（ＡＰＩインボーカー２０がどのＣＡＰＩＦまたはＣＣＦ２１にオンボードしたかを一意に識別できるＣＡＰＩＦ／ＣＣＦ関連の識別子）、ＣＡＰＩＦ固有のＡＰＩインボーカーＩＤ（ＣＡＰＩＦコア機能またはＣＡＰＩＦホストオペレータ固有のＡＰＩインボーカーＩＤ）、オンボーディングライフタイム、認可トークン／オンボードトークン（これは、ＡＰＩインボーカー２０とＣＣＦ２１／ＡＥＦ２２との間のさらなる認証／認可をサポートする）およびサービスＡＰＩ可用性通知とともに送信する。ＣＡＰＩＦ固有のＡＰＩインボーカーＩＤは、オンボーディング処理が成功した後にＣＣＦ２１によって割り当てられるＣＣＦ関連ＡＰＩインボーカー識別子である。当該ＣＡＰＩＦコア機能固有のＡＰＩインボーカーＩＤは、オンボーディングライフタイムを通じて変わることはない。オンボードトークンは、認証要求を送信する際に、オンボードしたＡＰＩインボーカー２０からオンボーディング成功のトークンとして送信する必要のあるシークレットトークンである。オンボードトークンは、オンボーディングライフタイムの間変化しない。ＡＰＩインボーカー２０に与えられる認可トークンは動的シークレットであり、オンボーディングライフタイムの間、ＣＣＦ２１で認証が行われるたびに更新される。オンボーディングが成功すると、該当のまたはサービスＡＰＩ可用性通知パラメータには、ＡＰＩインボーカー２０でディスカバー可能な／呼び出される全サービスＡＰＩ（名称および／または識別子および／またはタイプ）のリストが含まれる。
ａ．変形例：オンボードしたＡＰＩインボーカー２０の認可の証明またはトークンとして、ＡＰＩインボーカー２０とＣＣＦ２１／ＡＥＦ２２の間でオンボードトークンをそのまま使用する、または当該オンボードトークンから導出したものを使用する。
ｂ．変形例：認可トークンとオンボードトークンの両方を、オンボーディングＡＰＩインボーカー要求メッセージ中で、成功通知とともに、ＣＣＦ２１からＡＰＩインボーカー２０に送信する。
【００４３】
４．オンボーディングが成功すると、ＡＰＩインボーカー２０は、呼び出しの可能性のある／ＣＡＰＩＦによって管理されるＣＣＦ提供サービスＡＰＩリストを、オンボードサービスＡＰＩリストとして記憶する。
ａ．変形例：オンボーディングの結果は、サービスＡＰＩのディスカバリ、認証、ＡＰＩインボーカーの認可など、後続のＣＡＰＩＦ手順にバインドする必要がある。
【００４４】
２．１．１  オンボーディング結果の認証および認可手順へのバインディング
【００４５】
ＴＳ３３．１２２では、５．２．２．１節「方法１−ＴＬＳ−ＰＳＫの使用」に、ＡＰＩインボーカー２０とＡＥＦ２２との間の認証および認可手順が説明されている。ＡＰＩインボーカー２０とＡＰＩエクスポーズ機能２２が、事前共有キーに基づくＴＬＳ接続を使用して個別のセキュアセッションを確立する。ＣＡＰＩＦ−１ｅでのＴＬＳの確立に成功した後、ＡＰＩインボーカー２０とＣＡＰＩＦコア機能２１はキーＡＥＦＰＳＫを導出する。
【００４６】
提案：ＡＥＦＰＳＫは、ＣＡＰＩＦコア機能固有のＡＰＩインボーカー識別子、オンボードトークン、ＣＡＰＩＦ識別子、認可トークン、およびＡＥＦ識別子にバインドすることができる。
【００４７】
２．２  ＡＰＩインボーカーオフボーディングのセキュリティ手順
【００４８】
ａ．ＡＰＩインボーカー２０主導のオフボーディング
【００４９】
このセクションにおける説明は、ＴＳ２３．２２２［２］の８．２項で説明されている手順に対応する。
【００５０】
図３は、ＡＰＩインボーカー２０主導によるＣＡＰＩＦからのオフボーディングの手順の例を概略的に示す。
【００５１】
１．ＡＰＩインボーカー２０は、ＣＡＰＩＦコア機能２１へのオフボードＡＰＩインボーカー要求をトリガし、ＡＰＩ管理用にＣＣＦ２１で必要となるＣＡＰＩＦ  ＩＤ、ＣＡＰＩＦ固有のＡＰＩインボーカーＩＤ、認可トークン／オンボードトークンを提供する。
ａ．変形例：オフボーディングを認可する認可トークンはオンボードトークンから導出され、当該導出は、ＣＡＰＩＦ  ＩＤおよび／またはＣＡＰＩＦ  ＡＰＩインボーカーＩＤおよび／またはオフボードコード（静的または動的）にバインドされる。
ｂ．変形例：認可トークンまたはオンボードトークンのいずれか、あるいはその両方が、オフボードＡＰＩインボーカー要求メッセージで送信される。
【００５２】
２．ＣＣＦ２１は、要求元のＡＰＩインボーカー２０が、要求対象のＡＰＩインボーカー２０を本当にオフボードしようとしているか否かを、ＣＡＰＩＦ  ＡＰＩインボーカーＩＤに基づいて検証する。検証が成功した場合、ＣＡＰＩＦコア機能２１は、ＡＰＩインボーカー２０の登録をＣＡＰＩＦから抹消する。これにより、ＡＰＩインボーカー２０はＣＡＰＩＦの被識別ユーザではなくなる。ＡＰＩインボーカー２０に対応するすべての認可と関連情報とがＣＡＰＩＦから削除される。必要に応じて、ＡＰＩインボーカー２０の情報は、オペレータポリシーに従ってＣＡＰＩＦコア機能２１に維持される。
【００５３】
３．ＣＡＰＩＦコア機能２１は、オフボードＡＰＩインボーカー応答メッセージを返し、オフボーディングの成功をＡＰＩインボーカー２０に通知する。
【００５４】
ｂ．ＣＡＰＩＦ主導によるＡＰＩオフボーディング
【００５５】
図４は、ＣＡＰＩＦ主導によるＣＡＰＩＦからのオフボーディングの手順の例を概略的に示す。
【００５６】
１．ＣＣＦ２１はＡＰＩインボーカーオフボード通知メッセージをＡＰＩインボーカー２０に送信する。この動作の理由には、ＡＰＩインボーカー２０による、サービスＡＰＩアクセスに対する想定外、許容不可、あるいは不正な行為をＡＰＩインボーカー管理機能またはＣＡＰＩＦがディスカバーした場合などが含まれる。ＡＰＩインボーカーオフボード通知メッセージには、ＣＡＰＩＦ  ＩＤ、ＣＡＰＩＦ固有のＡＰＩインボーカーＩＤ／情報、およびオフボーディングの理由が含まれる。
ａ．変形例：ＣＣＦ２１は、ＡＰＩインボーカーのオフボード通知メッセージで認可トークン／オンボードトークンそのものをＡＰＩインボーカー２０に送信し、これにより、ＣＣＦ２１認証／認可がオフボーディング処理をトリガする。認可トークンの導出は、過去に正常なオンボーディング中にＡＰＩインボーカー２０と共有されたＣＡＰＩＦ  ＩＤまたはオンボードトークンにバインドされる。
ｂ．変形例：ＡＰＩインボーカーオフボード通知メッセージをＡＰＩインボーカー２０に送信した後、ＣＣＦ２１はサービスを取り消し、当該ＡＰＩインボーカーの要求を処理しない。
ｃ．変形例：オフボーディングの理由がＡＰＩインボーカー２０による想定外、許容不可または不正な行為である場合、ＣＣＦ２１は、認可トークン／オンボードトークンなしでＡＰＩインボーカーオフボード通知メッセージをＡＰＩインボーカー２０に送信する。ＣＣＦ２１はサービスを取り消し、当該ＡＰＩインボーカーの要求を処理しない。
【００５７】
２．ＡＰＩインボーカー２０は、ＡＰＩインボーカーオフボード通知メッセージを受信した後、ＣＡＰＩＦ  ＩＤ、ＣＡＰＩＦ固有のＡＰＩインボーカーＩＤ、および受信した認可トークン／オンボードトークンを、記憶している情報に基づいて検証し、なりすまし攻撃を防ぐ。
【００５８】
３．検証が成功した場合、ＡＰＩインボーカー２０は、ＡＰＩインボーカーオフボード確認応答メッセージを送信して、ＣＣＦ２１へオフボード通知に対する肯定応答を行う。
【００５９】
４．ＣＡＰＩＦは、ＡＰＩインボーカー２０からＡＰＩインボーカーオフボード確認応答メッセージを受信した後、ＡＰＩインボーカー登録をキャンセルする。
【００６０】
２．３サービスＡＰＩ公開のセキュリティ手順
【００６１】
このセクションにおける説明は、ＴＳ２３．２２２［２］の８．３項で説明されている手順に対応する。
【００６２】
図５は、サービスＡＰＩを公開する場合のセキュリティ手順の例を概略的に示す。
【００６３】
パブリッシャＩＤとＳＬＡの検証が成功すると、ＣＣＦは、要求されたサービスＡＰＩの公開に対応する一意のＣＡＰＩＦ固有のサービスＡＰＩ  ＩＤ（Ｓｅｒｖｉｃｅ  ＡＰＩ  Ｉｄｅｎｔｉｆｉｅｒ：サービスＡＰＩ識別子）を割り当てる。さらに、公開トークンは、後述するように、１つ以上の情報を使用して、ＣＣＦ２１によって生成することができる。以下に、当該トークンを生成する方法の一実施例を示す。ただし、他の種類の情報を使用する他の生成方法も除外されない。
【表２】
2021516515.tif 000004
【００６４】
１．ＡＰＦ２３は、公開期間を含むサービスＡＰＩ公開要求を、ＡＰＩパブリッシャＩＤ／ＡＰＦ  ＩＤ、サービスＡＰＩタイプ固有の認証および認可情報（存在する場合）、サービスＡＰＩ情報、ＡＰＩインボーカーへの公開中にＣＣＦ２１がサービスＡＰＩを維持するために必要なセキュリティのレベルを示すインジケータなどの他のパラメータとともに送信する。
ａ．変形例：ＡＰＦ２３によって通知されるセキュリティレベルインジケータには、サービスＡＰＩのセキュリティに関する任意の情報（機能／暗号アルゴリズム／アクセスレベルと動作権限／必要最低限のセキュリティ／インボーカーのタイプ／ＡＰＩインボーカー２０のトラストレベル／ＡＰＩ在圏ゾーンのトラストレベル）と、サービスＡＰＩへのアクセスの要件に関する情報とが含まれている。
【００６５】
２．ＣＣＦ２１は、サービスＡＰＩ公開要求メッセージを受信すると、ＳＬＡに基づいて、認可情報（（１）認証または認可中に事前に共有される、または（２）事前に設定されるセキュリティコンテキストに関する情報）およびＡＰＩパブリッシャＩＤ／ＡＰＦ  ＩＤを検証し、ＡＰＩプロバイダの検証を行う。また、ＣＣＦ２１は、トラスト、ＳＬＡ、および要求のあった公開期間に基づいて、通知されたサービスＡＰＩ  ＩＤの公開期間を設定する。検証が成功した場合、ＣＣＦ２１は、要求元のＡＰＩ公開機能２３のための公開トークンを生成し、公開されたサービスＡＰＩに対し一意のＣＡＰＩＦ固有サービスＡＰＩ  ＩＤを生成する／割り当てる。次に、ＣＣＦ２１は、ＡＰＩ情報を、公開トークン、ＡＰＦ  ＩＤ、サービスＡＰＩ  ＩＤ、およびＡＰＦ２３から提供されるサービスＡＰＩに対応するセキュリティ要件インジケータとともに記憶する。
ａ．変形例：上記の公開トークンの生成には、ＡＰＩプロバイダＩＤ、ＡＰＦ  ＩＤ、公開関連キーワード、公開コード（静的または動的）、サービスＡＰＩタイプ／名称／関連情報、シークレット、およびＣＣＦ  ＩＤなどの１つ以上のパラメータの任意の組み合わせが用いられる。
【００６６】
３．検証が成功した場合、ＣＣＦ２１は、成功通知、公開トークン、サービスＡＰＩ  ＩＤ、および認可された公開期間とともに、サービスＡＰＩ公開応答メッセージをＡＰＦ２３に送信する。
【００６７】
４．ＡＰＦ２３は、非公開、サービスＡＰＩの取得および更新などのさらなる処理のために、受信したサービスＡＰＩ  ＩＤ、公開期間、および対応する公開トークンを記憶する。
ａ．変形例：ＣＣＦ２１から受信した公開トークンは、ＡＰＦ２３によって、サービスＡＰＩの非公開、取得、および更新動作を行う場合の認可情報として使用される。すなわち、ＡＰＦによって提供される有効な公開トークンは、当該ＡＰＦ２３が過去に認可されていたことを示す。
【００６８】
２．４  サービスＡＰＩ非公開のセキュリティ手順
【００６９】
このセクションにおける説明は、ＴＳ２３．２２２［２］の８．４項で説明されている手順に対応する。
【００７０】
図６は、サービスＡＰＩを非公開にする場合のセキュリティ手順の例を概略的に示す。
【００７１】
公開トークンの生成については、セクション２．３で説明した。公開トークンは、ＡＰＦ２３がＣＣＦ２１からのサービスＡＰＩを非公開にするのに使用される。
【００７２】
１．ＡＰＦ２３は、公開トークン（セクション２．３で導出したもの）および過去に公開されたＣＡＰＩＦ固有のサービスＡＰＩ  ＩＤ／サービスＡＰＩ連携情報を含むサービスＡＰＩ非公開要求メッセージを、ＡＰＩパブリッシャＩＤ／ＡＰＦ  ＩＤ、認証および認可情報などの他のパラメータとともに送信する。
【００７３】
２．ＣＣＦ２１は、サービスＡＰＩ非公開要求メッセージを受信すると、サービスＡＰＩ  ＩＤを使用して、サービスＡＰＩに関連する記憶情報を識別し、次に、ＳＬＡに基づいてＡＰＩパブリッシャＩＤを検証するとともに、サービスＡＰＩの非公開要求の認可の証明として公開トークンを検証する。検証が成功した場合、ＣＣＦ２１は、使用可能なＡＰＩのリストから上記のサービスＡＰＩを削除する。
【００７４】
３．公開トークンの検証が成功した場合、ＣＣＦ２１は、成功通知、ＣＡＰＩＦ  ＩＤ、非公開サービスＡＰＩ  ＩＤおよび関連情報とともに、サービスＡＰＩ非公開応答メッセージを、ＡＰＦ２３に対する確認応答としてＡＰＦ２３に送信する。
変形例：この手順に関わらず、サービスＡＰＩの公開期間が終了すると、ＣＣＦ２１は当該公開されたサービスＡＰＩを非公開にする。
【００７５】
２．５  サービスＡＰＩ更新のセキュリティ手順
【００７６】
図７は、サービスＡＰＩを更新する場合のセキュリティ手順の例を概略的に示す。
【００７７】
ＣＣＦ２１でＡＰＦ２３によるサービスＡＰＩ更新を実行するための公開トークンの使用：
【００７８】
公開トークンの生成については、セクション２．３で説明した。公開トークンは、ＡＰＦ２３がＣＣＦ２１からのサービスＡＰＩを更新するのに使用される。
【００７９】
変形例１：公開トークンは、ＣＡＰＩＦコア機能２１とＡＰＩプロバイダ／パブリッシャとの間の認証／認可中に事前に共有される。
【００８０】
変形例２：公開トークンは、ＣＣＦ２１とＡＰＩパブリッシャとの間における認証が成功した後に導出されたキー／シークレットを使用して導出され、ＣＣＦ２１で公開されたサービスＡＰＩを更新する場合の認証または認可情報としてＡＰＦ２３によって使用される。
【００８１】
このセクションにおける説明は、ＴＳ２３．２２２［２］の項８．６で説明されている手順に対応する。
【００８２】
１．ＡＰＩ公開機能２３は、サービスＡＰＩ更新要求をＣＡＰＩＦコア機能２１に送信する。当該サービスＡＰＩ更新要求は、サービスＡＰＩの公開成功後にＣＣＦ２１によって提供されるＡＰＩパブリッシャＩＤ、公開トークン、およびサービスＡＰＩ  ＩＤ（タイプ／名称／ＩＤ）を含む。
【００８３】
２．サービスＡＰＩ更新要求を受信すると、ＣＡＰＩＦコア機能２１は、公開トークンおよび／またはサービスＡＰＩ  ＩＤ（タイプ／名称／ＩＤ）およびＡＰＩパブリッシャＩＤをチェックして、公開されたサービスＡＰＩ情報の更新を行う認可をＡＰＩ公開機能２３が得ているか否かを検証する。チェックが成功した場合、ＡＰＩ公開機能２３から提供されるサービスＡＰＩ情報は、ＣＡＰＩＦコア機能２１（ＡＰＩレジストリ）で更新される。
【００８４】
３．ＣＡＰＩＦコア機能２１は、ＣＡＰＩＦ  ＩＤおよび更新後のサービスＡＰＩ  ＩＤ（タイプ／名称／ＩＤ）とともに、サービスＡＰＩ更新応答メッセージをＡＰＩ公開機能２３に提供し、サブスクライブされたＡＰＩインボーカーへの通知をトリガする。
【００８５】
２．６  サービスＡＰＩディスカバリのセキュリティ手順
【００８６】
このセクションにおける説明は、ＴＳ２３．２２２［２］の８．７項で説明されている手順に対応する。
【００８７】
図８は、サービスＡＰＩをディスカバーする場合のセキュリティ手順の例を概略的に示す。
【００８８】
１．ＡＰＩインボーカー２０は、ＡＰＩインボーカーＩＤ情報（ＣＡＰＩＦ  ＡＰＩインボーカーＩＤおよび／またはその関連のクレデンシャル）、認可トークン（オンボードトークンそのものまたはオンボードトークンから導出したトークン）、ゾーンＩＤ（ＡＰＩインボーカーの現在のネットワークまたは位置）、およびその他のクエリ情報（例えば、ＡＰＩタイプ、インターフェース、プロトコルなど、マッチするサービスＡＰＩをディスカバーするための基準）とともに、サービスＡＰＩディスカバリ要求メッセージをＣＣＦ２１に送信する。
ａ．変形例：発行する認可トークンは、ディスカバリレベルに固有である、またはオンボードトークンから導出される。
【００８９】
２．ＣＣＦ２１は、サービスＡＰＩディスカバリ要求メッセージを受信すると、ＣＡＰＩＦ固有のＡＰＩインボーカーＩＤ、記憶されているオンボーディング結果、ＡＰＩインボーカーのトラストレベル、およびＡＰＩインボーカーが在圏するゾーンＩＤに対応するゾーン／ネットワーク／位置、および認可トークン（オンボードトークンおよび／またはＣＡＰＩＦ  ＡＰＩ  ＩＤおよび／またはＣＡＰＩＦ  ＩＤにバインドされている）を検証する。検証が成功した場合、ＣＣＦ２１は、当該検証結果に基づいてサービスＡＰＩ情報を取得する。
【００９０】
３．検証が成功した場合、ＣＣＦ２１は、サービスＡＰＩディスカバリ応答メッセージを、検証結果およびサービスＡＰＩ情報とともにＡＰＩインボーカー２０に送信する。ＡＰＩインボーカー２０および／またはそのＡＰＩインボーカーゾーンのトラストレベルの検証に基づいて、またはＣＣＦ２１に記憶されているユーザ／ＡＰＩインボーカー／アプリケーション固有のサブスクリプション情報に基づいてＡＰＩインボーカー２０のサービスＡＰＩレベルのディスカバリが決定され、これによりトポロジが隠蔽される。
ｂ．変形例：これにより、ＡＰＩインボーカー２０またはデバイスが共有のＡＰＮを介してネットワークに接続する場合、ＣＣＦ２１は、受信したＡＰＮ情報と自身が記憶するトラスト値とを利用して、特定のＡＰＩインボーカーのサービスＡＰＩ要求に対するトラストを分析する。これをサポートするために、ＣＣＦ２１は、各ゾーンにする情報、ゾーン内のＡＰＮに関する情報、および各ゾーンに対応するトラスト値、またはＣＣＦ２１／ネットワークおよび各トラストゾーンに対応するトラスト値を記憶する必要がある。
【００９１】
２．７  ＡＰＩインボーカーがサービスＡＰＩにアクセスする認可をＣＣＦから取得する場合のセキュリティ手順
【００９２】
このセクションにおける説明は、ＴＳ２３．２２２［２］の８．１１項で説明されている手順に対応する。
【００９３】
図９は、ＡＰＩインボーカーがサービスＡＰＩアクセスの認可を取得する場合のセキュリティ手順の例を概略的に示す。
【００９４】
呼び出しトークンの生成：
【表３】
2021516515.tif 000005
【００９５】
変形例：呼び出しトークンは、サービスＡＰＩ呼び出しトークン、サービスＡＰＩアクセストークン、ＡＰＩインボーカー認可トークン、またはサービスＡＰＩ認可トークンとも呼ばれる。いずれの場合も、このトークンがＡＰＩインボーカーに割り当てられているということは、当該ＡＰＩインボーカー２０が認可され、サービスＡＰＩにアクセスする許可が与えられていることを示す。
【００９６】
１．ＡＰＩインボーカー２０は、サービスＡＰＩへのアクセス許可を取得するために、サービスＡＰＩ認可要求メッセージをＣＡＰＩＦコア機能２１に送信する。当該サービスＡＰＩ認可要求メッセージには、ＣＡＰＩＦ固有のＡＰＩインボーカーＩＤ、初期／ＣＡＰＩＦ  １ｅ／ＣＡＰＩＦ  ２ｅ認可（例えば、ＴＬＳ）から導出した認可トークン、認証／認可カウンタ、タイムスタンプ（またはノンス）、要求されたサービスタイプ／名称／ＡＰＩ  ＩＤ、ＡＰＩインボーカー２０の認証／認可に必要な任意の関連情報などのＡＰＩインボーカー情報が含まれる。
ａ．変形例：また、ＡＰＩインボーカー２０は、ユーザ、ユーザアプリケーションまたはＡＰＩインボーカー固有のサブスクリプション情報もサービスＡＰＩ認可リクエストメッセージに含ませる。
【００９７】
２．ＣＡＰＩＦコア機能２１は、受信したＣＡＰＩＦ  ＡＰＩインボーカーＩＤ、認可トークン、および認証／認可カウンタを、ＣＣＦ２１で管理するものに基づいて検証することで、ＡＰＩインボーカー２０の認可を（認証情報を使用して）有効化する。また、これにより、リソースの枯渇を防ぐこともできる。ＣＣＦ２１は、当該検証結果と、ＡＰＩインボーカー２０から受信したユーザ、ユーザアプリケーションまたはＡＰＩインボーカー固有のサブスクリプション情報とに基づいて、ローカルに記憶されたサブスクリプション情報をチェックし、要求されたサービスタイプ／名称／ＡＰＩへのアクセスをＡＰＩインボーカー２０に認可可能か否かを決定する。
ａ．変形例：ＣＣＦ２１は、認可に必要な場合、ＡＰＩインボーカー２０と追加のメッセージをやり取りしてもよい。
【００９８】
３．サービスＡＰＩにアクセスする認可情報は、ＣＣＦ２１によってＡＰＩインボーカー２０に送信される。当該認可情報は、サービスＡＰＩ認可応答メッセージ内で、後続のＡＰＩインボーカーのＡＥＦ２２との認証／認可のためのサービスＡＰＩ呼び出しトークン、ライフタイムまたは有効期間後に新しい呼び出し／アクセストークンを取得するためのリフレッシュトークン、認可済／適用可能なサービスＡＰＩインジケータおよび関連情報（サービスＡＰＩタイプおよび／またはＩＤ／名称）、およびＡＰＩインボーカー２０とＡＥＦ２２との間におけるさらなる相互認証をサポートするＡＥＦ認可トークンとともに送信される。
ａ．変形例：ＡＥＦ２２認可トークンは、シークレット（例えば、ランダム値）、ＡＥＦ  ＩＤ、ＣＡＰＩＦ  ＡＰＩインボーカーＩＤ、および任意のサービスＡＰＩ連携情報を使用して、ＣＣＦ２１によって導出される。
ｂ．変形例：取得サービスＡＰＩ認可応答メッセージには、呼び出しトークン／アクセストークンの有効期間も含まれる。
ｃ．変形例：有効期間が経過した後、ＡＰＩインボーカー２０は、インクリメントされた認証／認可カウンタを使用して、呼び出しトークン／アクセストークンを自身でリフレッシュする。認証または認可後のサービスＡＰＩ呼び出しが成功するたびに、ＡＰＩインボーカー２０側とＣＣＦ２１側の両方で対応するカウンタをインクリメントする。
ｄ．変形例：ＡＰＩインボーカー２０は、サービスＡＰＩにアクセスする認可をＣＣＦ２１から取得する。ＡＰＩインボーカー２０は、（１）ユーザＩＤ、サブスクリプションＩＤ、またはユーザ固有のアプリケーションＩＤを送信することにより、ユーザごとに上記認可を取得する；（２）デバイスＩＤ、デバイスサブスクリプションＩＤ、またはデバイス固有のアプリケーションＩＤを送信することにより、ＡＰＩインボーカー２０ごとに上記認可を取得する；および／または（３）要求されたサービスタイプ／名称／ＩＤを送信することにより、サービスＡＰＩレベルごとに上記認可を取得する。
【００９９】
２．７．１  ＡＰＩインボーカーがサービスＡＰＩにアクセスする認可をユーザ／ＡＰＩ／サービスＡＰＩレベルごとにＣＣＦから取得する場合のセキュリティ手順
【０１００】
変形例１：ユーザごとの認可
【０１０１】
ＡＰＩインボーカー２０は、ＣＣＦ２１からユーザ（アプリケーション固有）／サブスクライバ／ヒューマンユーザのサブスクリプションごとに認可を取得して、関連のＡＥＦ２２からサービスＡＰＩにアクセスを要求する。
【０１０２】
セキュリティ手順は、セクション２．７で説明したものと同様である。
【０１０３】
さらに、ＡＰＩインボーカー２０によって送信されるサービスＡＰＩ認可要求メッセージには、ユーザ固有の識別子／サブスクライバ識別情報／サブスクリプション識別情報も含まれる。セクション２．７で説明した他の検証とともに、ＣＣＦ２１は、受信したユーザ固有の識別子／サブスクライバ識別情報／サブスクリプション識別情報も併せて検証を行い、呼び出しトークンやリフレッシュトークンなどの認可情報を提供する。検証が成功すると、ＣＣＦ２１は、呼び出しトークンやリフレッシュトークンなどの認可情報をＡＰＩインボーカー２０に送信する。
【０１０４】
当該認可情報は、その有効期間の終了まで、サービス呼び出し時に、ＡＰＩインボーカー２０によってＡＥＦ２２との認証に１回または任意の回数使用される。
【０１０５】
変形例２：ＡＰＩインボーカー２０ごとの認可
【０１０６】
ＡＰＩインボーカー２０は、特定のユーザではなく、複数のユーザが共有するＵＥまたはデバイスに対応してもよい。セキュリティ手順は、セクション２．６で説明したものと同様である。これに加えて、ＡＰＩインボーカー２０は、関連のＡＥＦ２２からサービスＡＰＩへのアクセスを要求する認可を、ＣＣＦ２１から取得する。当該認可の取得は、ＣＡＰＩＦ固有のＡＰＩインボーカーＩＤ、および／または特定のＣＡＰＩＦまたはＣＣＦでのオンボーディングが成功した後に受信したオンボードトークンを、サービスＡＰＩ認可要求メッセージ内で提供することで、取得される。
【０１０７】
ＣＣＦ２１は、ＡＰＩインボーカー２０から受信したＣＡＰＩＦ固有のＡＰＩインボーカーＩＤおよび／またはオンボードトークンを、自身に記憶された情報に基づいて検証して、呼び出しトークンやリフレッシュトークンなどの認可情報を提供する。検証が成功すると、ＣＣＦ２１は、呼び出しトークンやリフレッシュトークンなどの認可情報をＡＰＩインボーカー２０に送信する。
【０１０８】
当該認可情報は、その有効期間の終了まで、同一または異なるサービス（ＡＰＩ）呼び出し時に、認可済ＡＰＩインボーカーによって、ＡＥＦ２２との認証に１回または任意の回数使用される。
【０１０９】
ＡＰＩインボーカー２０がＣＣＦ２１から認可を取得すると、当該特定のＡＰＩインボーカー２０は、同一のＣＣＦ２１で認可を行って当該ＡＥＦ２２でさらにサービスを呼び出す必要はない。
【０１１０】
変形例３：サービスＡＰＩレベルごとの認可
【０１１１】
セキュリティ手順は、セクション２．６で説明したものと同様である。これに加えて、ＡＰＩインボーカー２０は、関連のＡＥＦ２２からサービスＡＰＩへのアクセスを要求する認可を、ＣＣＦ２１から取得する。当該認可の取得は、ＣＡＰＩＦ固有のＡＰＩインボーカーＩＤ、サービスＡＰＩ  ＩＤ（タイプ／名称／ＩＤ）および／または特定のＣＡＰＩＦまたはＣＣＦでのオンボーディングが成功した後に受信したオンボードトークンを、取得サービスＡＰＩ認可要求メッセージ内で提供することで、取得される。
【０１１２】
ＣＣＦ２１は、ＡＰＩインボーカー２０から受信したＣＡＰＩＦ固有のＡＰＩインボーカーＩＤ、サービスＡＰＩ  ＩＤ（タイプ／名称／ＩＤ）および／またはオンボードトークンを、自身に記憶された情報に基づいて検証して、呼び出しトークンやリフレッシュトークンなどの認可情報を提供する。ＣＣＦ２１は、ＡＰＩインボーカー２０が要求されたサービスＡＰＩ  ＩＤ（タイプ／名称／ＩＤ）の認可を受けるのに適しているか否かについても検証を行う。検証が成功すると、ＣＣＦ２１は、呼び出しトークンやリフレッシュトークンなどの認可情報をＡＰＩインボーカー２０に送信する。
【０１１３】
当該認可情報は、その有効期間の終了まで、同一または類似の（サービスＡＰＩ  ＩＤ）（タイプ／名称／ＩＤ）サービス呼び出し時に、認可済ＡＰＩインボーカー２０によって、ＡＥＦ２２との認証に１回または任意の回数使用される。
【０１１４】
すべての異なるサービス（タイプ／名称／ＩＤ）について、ＡＰＩインボーカー２０は、セクション２．６のセキュリティ手順で説明したように、ＣＣＦ２１から認可を取得する。
【０１１５】
２．８  サービス呼び出し時のＡＰＩインボーカーとＡＥＦとの間の認証を行う場合のセキュリティ手順
【０１１６】
このセクションにおける説明は、ＴＳ２３．２２２［２］の８．１５項で説明されている手順に対応する。
【０１１７】
図１０は、サービスＡＰＩ呼び出し時にＡＰＩインボーカー２０とＡＥＦ２２との間で認証を行う場合のセキュリティ手順の例を概略的に示す。
【０１１８】
１．ＡＰＩインボーカー２０は、サービスＡＰＩ呼び出し要求メッセージをＡＥＦ２２に送信する。当該サービスＡＰＩ呼び出し要求メッセージには、ＣＡＰＩＦ  ＡＰＩインボーカーＩＤ、呼び出しトークン＊（図１１に示すように導出）、必要または要求されたサービスＡＰＩ  ＩＤ（サービスタイプ／名称／ＩＤ）、関連情報などの認証情報が含まれる。新しい呼び出しごとに、トークンの再利用によるセキュリティ違反を回避するために、新しい呼び出しトークン＊が計算される。
ａ．変形例：呼び出しトークン＊は、呼び出し／アクセス／認可トークンおよび／またはキーを使用して導出され、ＡＰＩインボーカー２０とＣＣＦ２１／ＡＥＦ２２との間の認証／認可、および呼び出しカウンタ値が得られる。呼び出しトークン＊は、サービスＡＰＩ呼び出しトークン＊と呼ばれてもよい。
ｂ．変形例：ＡＰＩインボーカー２０は、サブスクリプション関連情報も、サービスＡＰＩ呼び出し要求メッセージ内でＡＥＦ２２に送信する。
【０１１９】
２．ＡＥＦ２２は、サービスＡＰＩ呼び出し要求メッセージを受信すると、さらに、ＣＡＰＩＦ  ＡＰＩインボーカーＩＤなどのＡＰＩインボーカー関連情報、呼び出し／認可トークンまたは呼び出しトークン＊などの認可情報、要求された／必要な／適用可能なサービスＡＰＩに関連する識別（名称／タイプ／ＩＤ）情報、ＡＰＩインボーカー／ＡＰＩインボーカーの在圏ゾーンのトラストレベル、およびＣＣＦ２１からのＡＥＦ認可トークンを取得して、ＡＰＩインボーカー２０とＡＥＦ２２との間で相互認証を行う。
ａ．変形例：ＡＥＦ２２は、ＣＣＦ２１から呼び出しトークンまたは呼び出しトークン＊をステップ２で挙げた他のパラメータと共に取得して、認証を行う。
ｂ．変形例：呼び出しトークン＊は、ＡＰＩインボーカー２０側とＣＣＦ２１またはＡＥＦ２２側のいずれかで導出される。
【０１２０】
３．ＡＥＦ２２は、ＣＣＦ２１から取得した情報に基づいて、ＡＰＩインボーカー２０の本人確認および認証を行う。また、ＡＥＦ２２は、ＣＡＰＩＦ  ＡＰＩインボーカーＩＤ、呼び出しトークン／呼び出しトークン＊、および要求されたサービスＡＰＩインジケータを検証して、ＡＰＩインボーカー２０とそのサブスクリプションとが、要求されたサービスＡＰＩ（タイプ／名称／ＩＤ）にアクセスする可能性があるか否かをチェックする。
【０１２１】
４．検証が成功した場合、ＡＥＦ２２は、ＣＣＦ２１から受信したＡＥＦ認可トークン、認可済サービスＡＰＩのＩＤおよび関連情報、および割り当てられたサービスＡＰＩ呼び出し回数（サブスクリプション、ＡＰＩインボーカー／そのゾーンのトラストレベル、関連するＣＡＰＩＦ、システム負荷、アクティブユーザ数、期間などに基づく）とともにサービスＡＰＩ呼び出し応答メッセージを送信する。
【０１２２】
５．ＡＰＩインボーカー２０は、受信したＡＥＦ認可トークンを検証して、ＡＥＦ２２の認証／認可を行う。検証が成功した場合、ＡＰＩインボーカー２０は認可済サービスＡＰＩを呼び出す。これにより、サービス呼び出し時に、ＡＰＩインボーカー２０とＡＥＦ２２との間の相互認証が保証される。
【０１２３】
図１１は、呼び出しトークン＊を導出する場合の手順の例を概略的に示す。
【０１２４】
変形例：呼び出しトークン＊をＡＰＩインボーカー２０からの認可証明として使用する代わりに、呼び出しキー＊、呼び出しシークレット＊などの任意のシークレットを認可証明に用いることができる。ＡＰＩインボーカー２０、ＣＣＦ２１、またはＡＥＦ２２は、呼び出しトークン＊生成用のＴＤＳ（Ｔｏｋｅｎ  Ｄｅｒｉｖａｔｉｏｎ  Ｆｕｎｃｔｉｏｎ：トークン導出関数）、呼び出しキー＊生成用のキー導出関数、または呼び出しシークレット＊生成用の任意の関数をそれぞれ使用する。
【０１２５】
変形例：呼び出しトークン＊または呼び出しキー＊または呼び出しシークレット＊は、任意のサービスＡＰＩ連携情報、ＣＣＦ２１から受信した呼び出しトークン／アクセストークン、ＣＡＰＩＦ  ＡＰＩ  ＩＤ、ＣＡＰＩＦ  ＩＤ、およびサービスタイプ／ＩＤ／名称に固有の呼び出し回数を使用して導出することができる。上に挙げたパラメータの任意の１つ以上の組み合わせが、呼び出しトークン＊、呼び出しキー＊、または呼び出しシークレット＊の導出に使用される。
【０１２６】
２．９  サービスＡＰＩを取得する場合のセキュリティ手順
【０１２７】
このセクションにおける説明は、ＴＳ２３．２２２［２］の８．５項で説明されている手順に対応する。
【０１２８】
図１２は、サービスＡＰＩを取得する場合のセキュリティ手順の例を概略的に示す。
【０１２９】
公開トークンの生成については、セクション２．３で説明した。本明細書のセクション２．３で説明されているサービスＡＰＩ公開手順においてＣＣＦ２１から提供される公開トークンは、ＣＣＦ２１からサービスＡＰＩを取得するための認可情報としてＡＰＦ２３によって使用される。ＴＳ２３．２２２の８．５節に対応するセキュリティ手順を以下に説明する。
【０１３０】
１．ＡＰＩ公開機能２３は、サービスＡＰＩの公開時にＣＡＰＩＦコア機能２１から提供されるサービスＡＰＩ公開情報リファレンスに対応する、ＡＰＩパブリッシャ情報、公開トークン、およびサービスＡＰＩ  ＩＤとともに、サービスＡＰＩ取得要求をＣＡＰＩＦコア機能２１に送信する。
【０１３１】
２．サービスＡＰＩ取得リクエストを受信すると、ＣＣＦは、サービスＡＰＩ  ＩＤに基づいてＡＰＩ情報を取得する。ＣＡＰＩＦコア機能２１は、ＡＰＩ公開機能２３が公開されたサービスＡＰＩ情報を検索することを許可されているか否かをチェックする。チェックが成功した場合、対応するサービスＡＰＩ情報は、ＡＰＩ公開機能２３によってＣＡＰＩＦコア機能２１（ＡＰＩレジストリ）から取得される。
【０１３２】
３．ＣＡＰＩＦコア機能２１は、サービスＡＰＩ情報およびＣＡＰＩＦ  ＩＤを含むサービスＡＰＩ取得応答をＡＰＩ公開機能２３に提供する。
【０１３３】
２．１０  ＣＡＰＩＦイベントサブスクリプションのセキュリティ手順
【０１３４】
このセクションにおける説明は、ＴＳ２３．２２２［２］の８．８．３項で説明されている手順に対応する。
【０１３５】
以下の図における「サブスクライバエンティティ」は、ＣＡＰＩＦコア機能２１のサービスを使用するエンティティを指す。これらの「サブスクライバエンティティ」には、（１）ＡＰＩインボーカー２０、（２）ＡＰＩエクスポーズ機能２２、（３）ＡＰＩ公開機能２３、（４）ＡＰＩ管理機能２４などのエンティティが含まれる。
【０１３６】
図１３は、ＣＡＰＩＦイベントサブスクリプションのセキュリティ手順の例を概略的に示す。
【０１３７】
サブスクリプショントークン／キーの生成：
【０１３８】
サブスクリプションのトークン／キーは、以下の１つ以上のパラメータの任意の組み合わせを使用して導出される。
【０１３９】
オンボーディングの成功後にＣＣＦ２１から提供されるオンボードトークン（ＡＰＩインボーカー２０がサブスクライバエンティティの場合）、サブスクライバＩＤ（他のサブスクライバエンティティの場合）、サブスクリプションＩＤ、サブスクライバエンティティＩＤ、ＣＡＰＩＦイベントＩＤ、ＣＡＰＩＦ  ＩＤ、サブスクリプションコード／キーワード、サービスＡＰＩのタイプ／名称／ＩＤ、任意の事前共有シークレット、およびＡＰＩインボーカー２０／サブスクライバエンティティとＣＣＦ２１との間の初期認証／認可から導出した任意のキー／トークン。
【０１４０】
認可トークンの生成
【０１４１】
サブスクライバエンティティがＡＰＩインボーカー２０である場合、認可トークンが導出され、ＡＰＩインボーカー２０のオンボーディング処理中、ＣＣＦ２１によって共有される。ＡＰＩインボーカー２０の認可トークンを導出する方法については、セクション２．１で説明される。サブスクライバエンティティが、当該セクションで説明した別のタイプのいずれかである場合、認可トークンは、登録手順が成功した場合に導出される。
【０１４２】
認可トークンは、以下の１つ以上のパラメータの任意の組み合わせを使用して導出される。オンボーディングが成功したＩＤ（ＡＰＩインボーカー）の後にＣＣＦ２１から提供されるオンボードトークン、ＣＡＰＩＦ固有のＡＰＩ  ＩＤ（ＡＰＩインボーカー）、サブスクライバＩＤ（他のサブスクライバエンティティの場合）、ＣＡＰＩＦイベントＩＤ、ＣＡＰＩＦ  ＩＤ、サブスクリプションコード／キーワード、サービスＡＰＩのタイプ／名称／ＩＤ、任意の事前共有シークレット、およびＡＰＩインボーカー２０／サブスクライバエンティティとＣＣＦ２１との間の初期認証／認可から導出した任意のキー／トークン。
【０１４３】
このセクションにおける説明は、ＴＳ２３．２２２［２］の８．８．３項で説明されている手順に対応する。
【０１４４】
１．サブスクライブエンティティは、イベントの通知を受信するために、イベントサブスクリプション要求を、サブスクライブエンティティ識別子、認可トークン、イベントタイプ、サービスＡＰＩ  ＩＤ、およびサービスＡＰＩ名とともにＣＡＰＩＦコア機能２１に送信する。
ａ．変形例：サブスクライブエンティティは、ＡＰＩインボーカー２０、ＡＰＩエクスポーズ機能２２、ＡＰＩ公開機能２３、またはＡＰＩ管理機能２４であってもよい。
ｂ．変形例：サブスクライブエンティティがＡＰＩインボーカー２０である場合、サブスクライブエンティティＩＤはＣＡＰＩＦ固有のＡＰＩインボーカーＩＤである。
【０１４５】
２．ＣＡＰＩＦコア機能２１は、サブスクライブエンティティからイベントサブスクリプション要求を受信すると、イベントサブスクリプションに関連する認可をチェックする。ＣＣＦ２１は認可トークンを検証し、有効化／検証が成功した場合、ＣＣはサブスクリプションＩＤを割り当て、サブスクリプショントークンを生成する。
【０１４６】
３．認可が成功した場合、ＣＡＰＩＦコア機能２１は、サブスクリプションＩＤおよびサブスクリプショントークンなどのサブスクリプション情報を記憶する。
【０１４７】
４．ＣＡＰＩＦコア機能２１は、動作の成功を示すイベントサブスクリプション応答を、サブスクリプションＩＤおよびサブスクリプショントークンとともに送信する。
【０１４８】
２．１１  ＣＡＰＩＦイベントのサブスクリプション解除を行う場合のセキュリティ手順
【０１４９】
このセクションにおける説明は、ＴＳ２３．２２２［２］の８．８．５項で説明されている手順に対応する。
【０１５０】
図１４は、ＣＡＰＩＦイベントのサブスクリプション解除を行う場合のセキュリティ手順の例を概略的に示す。
【０１５１】
セキュリティ手順：
【０１５２】
１．サブスクライブエンティティは、イベントサブスクリプション解除要求を、セクション２．１０で説明したようにサブスクリプション手順が正常に行われている間に受信したサブスクライバＩＤ／サブスクライバエンティティＩＤ、サブスクリプションＩＤ、サブスクライバＣＡＰＩＦイベントＩＤ、およびサブスクリプショントークン／キーなどのサブスクリプション情報とともに、ＣＡＰＩＦコア機能２１に送信する。
【０１５３】
２．サブスクライブエンティティからイベントのサブスクリプション解除要求を受信すると、ＣＡＰＩＦコア機能２１は、サブスクライバＩＤおよびサブスクリプション情報を検証することで、サブスクライブエンティティに対応するイベントサブスクリプションをチェックする。さらに、サブスクリプショントークン／キーおよびＣＡＰＩＦイベントＩＤを検証することで、サブスクライブエンティティがＣＡＰＩＦイベントからサブスクリプション解除を認可されているか否かをチェックする。
【０１５４】
３．すべての検証が正常に終了して、サブスクライブエンティティに対応するイベントサブスクリプション情報が利用可能であり、かつサブスクライブエンティティがＣＡＰＩＦイベントのサブスクリプション解除の認可を得ている場合、ＣＡＰＩＦコア機能２１はサブスクリプション情報を削除する。
【０１５５】
４．ＣＡＰＩＦコア機能２１は、動作の成功または失敗を示すイベントサブスクリプション解除応答を、適宜送信する。
【０１５６】
２．１２  サービスＡＰＩへのＡＰＩインボーカーのアクセス認可のセキュリティ手順
【０１５７】
このセクションにおける説明は、ＴＳ２３．２２２［２］の８．１６項で説明されている手順に対応する。
【０１５８】
図１５は、サービスＡＰＩへのＡＰＩインボーカーのアクセス認可の手順の例を概略的に示す。
【０１５９】
１．ＡＰＩインボーカー２０は、ＡＥＦ２２に対してサービスＡＰＩ呼び出し要求をトリガする。当該サービスＡＰＩ呼び出し要求には、ＣＡＰＩＦコア機能固有のＡＰＩインボーカーＩＤ、ＣＡＰＩＦ  ＩＤ、呼び出しトークン／呼び出しトークン＊、および呼び出し対象として要求されたサービスＡＰＩ（タイプ／名称／ＩＤ）が含まれる。呼び出しトークン＊は、セクション２．８で説明されるように導出される。ＡＰＩインボーカー２０は、複数のサービスＡＰＩ呼び出しを非同期でトリガすることができる。サービスＡＰＩ呼び出し要求には、応答およびフラッディング攻撃を防ぐためのノンスまたはタイムスタンプのパラメータも含まれる。
【０１６０】
２．ＡＥＦ２２は、サービスＡＰＩ呼び出し要求を受信すると、ＣＣＦ２１からＡＰＩインボーカーサービスＡＰＩ認可情報を取得する。ＣＣＦ２１は、ＡＰＩインボーカーがそのサービスＡＰＩを呼び出す認可を得ているか否かについての確認など、ＡＰＩインボーカーの認可情報を、ＣＡＰＩＦコア機能固有のＡＰＩインボーカーＩＤ、ＣＡＰＩＦ  ＩＤ、呼び出しトークン／呼び出しトークン＊、および呼び出し可能なサービスＡＰＩ（タイプ／名称／ＩＤ）などの情報に基づいて、ＡＥＦ２２に提供する。認可トークンは認可情報として機能する。新しいサービスＡＰＩ呼び出し要求ごとに、呼び出しトークン＊は、過去に使用された呼び出しトークン／呼び出しトークン＊、サービスＡＰＩ  ＩＤ、および対応する呼び出しカウントから導出される。
ＣＣＦ２１での呼び出しトークンの生成：呼び出しトークンは、ＡＰＩインボーカーがサービスＡＰＩにアクセスする認可情報として使用される。当該呼び出しトークンは、ＡＰＩインボーカー２０とＣＣＦ２１との間、またはＡＰインボーカーとＡＥＦ２２（例えば、ＡＥＦＰＳＫを使って）との間における認証成功後に導出されるキー、ＣＡＰＩＦ  ＩＤ、ＡＥＦ  ＩＤ、ＣＣＦ固有のＡＰＩインボーカーＩＤ、オンボードトークン、および呼び出し回数に基づいて生成される。
【０１６１】
２ａ．ＡＥＦ２２にサービスＡＰＩ呼び出しを認可するのに必要な情報がない場合、ＡＥＦ２２は、呼び出しトークン／呼び出しトークン＊、ＣＡＰＩＦ  ＩＤ、ＡＥＦ  ＩＤ、ＣＣＦ固有のＡＰＩインボーカーＩＤ、オンボードトークン、呼び出し回数などの認可情報を取得する。
【０１６２】
３．ＡＥＦ２２は認可情報を検証し、検証が成功した場合には、呼び出したサービスＡＰＩのサービスロジックを実行する。
【０１６３】
４．ＡＰＩインボーカーは、サービスＡＰＩ呼び出しの結果としてサービスＡＰＩ呼び出し応答を受信する。
【０１６４】
２．１３  ＡＰＩインボーカーの認証
【０１６５】
ＴＳ３３．１２２の５．２．２．３節に記載の方法３を参照すると、トークンベースの認可において、ＣＡＰＩＦコア機能２１が正常アクセストークン付与要求の検証を行う場合、オンボードトークンと、過去に成功したＣＡＰＩＦ−１ｅ認証で共有した任意のキーとを使用して、ＡＰＩインボーカー２０のアクセストークンを生成する。
【０１６６】
概要
【０１６７】
有利には、上記の例示的な実施形態には、現行の３ＧＰＰの仕様書［２］および［３］が対応しない、以下に詳細を示す機能の１つまたは複数が含まれるが、これは限定的ではない。
【０１６８】
１）オンボーディングが成功した後、ＡＰＩインボーカー２０に対応する任意のＣＡＰＩＦまたはＣＣＦ２１によって提供されるＣＡＰＩＦ固有のＡＰＩインボーカーＩＤは、ＡＰＩインボーカー２０とＣＡＰＩＦ  ＡＰＩインボーカーＩＤを発行する固有のＣＡＰＩＦ／ＣＣＦとにバインドされる。これにより、ＡＰＩインボーカー２０がオンボードされていない他のＣＡＰＩＦ／ＣＣＦでのＣＡＰＩＦ  ＡＰＩインボーカーＩＤの再利用が防止される。このＩＤは、ＣＣＦ固有のＡＰＩインボーカーＩＤとも呼ばれる。
【０１６９】
２）ＣＡＰＩＦ  ＩＤは、ＣＡＰＩＦフレームワーク内のＣＡＰＩＦコア機能２１を一意に識別するのに使用される。ＣＡＰＩＦ  ＩＤは、集中型、分散型、カスケード型などの配置シナリオにバインドされるもしくは固有である、またはバインドされないもしくは固有ではない。ただし、ＣＡＰＩＦ  ＩＤは論理エンティティとしてＣＡＰＩＦコア機能２１に固有である。
【０１７０】
３）トラストゾーンレベルの表示／インジケータは、ＡＰＩインボーカー２０の在圏ゾーン、またはＡＰＩインボーカーのアクセスポイント、無線、またはネットワークへの接続に使用するアクセスネットワーク要素を示す。ＣＣＦ２１は、ＡＰＩインボーカー２０から受信したゾーンＩＤ／ＡＰＮ／アクセスネットワーク情報、または当該ＣＣＦ２１が通信およびサービスをサポート可能なさまざまなネットワークゾーンで維持するトラストレベル情報に基づいて、ＡＰＩインボーカーの在圏ゾーンのトラストレベルを決定する。すべてのＣＣＦ２１は、当該ＣＣＦ２１がサービス／通信をサポート可能なすべてのネットワーク／位置／ゾーンに固有のトラストレベルを維持する。
【０１７１】
４）ＡＰＩインボーカーのトラストレベル関連インジケータは、ポイント３において指定されたパラメータとは異なる。このトラストレベルインジケータパラメータは、ＣＣＦ２１／ＣＡＰＩＦネットワーク／ＡＥＦ２２とそのサービスＡＰＩを含む任意のＡＰＩインボーカー２０の動作に固有である。当該パラメータは、ＡＰＩインボーカー２０の過去の動作に基づいて、ＣＣＦ２１／ＡＥＦ２２によって割り当てられる。
【０１７２】
５）ゾーンＩＤおよびそのトラストレベルに関連するインジケータ：モバイルネットワークオペレータは、ネットワークをトラストゾーンに分割する。各トラストゾーンは、一意のゾーンＩＤを有する。特定のゾーンに存在する別のエンティティと通信する任意のネットワークエンティティには、ポリシーまたはサービスレベルの履歴に基づいて、当該ゾーンＩＤにトラストレベルが割り当てられている。固有のゾーンのゾーンＩＤとそのトラストレベルは、他の異なるネットワークとの関係性が全体で異なるまたは異ならない。
【０１７３】
６）オンボーディングライフタイムは、ＡＰＩインボーカー２０がそのライフタイムを通して真正な動作をすることが確かな期間に制限される。さらに、現行のシステムはオフボーディングについて検討を進めており、オンボーディングをＡＰＩインボーカー２０の全ライフタイムに対する１回限りの登録プロセスとしないオプションも考えられる。オンボーディングライフタイムはサブスクリプションにバインドされており、ＡＰＩインボーカー２０のＡＰＩインボーカータイプとトラストレベルもネットワークのＣＡＰＩＦポリシーに基づく。
【０１７４】
７）オンボードトークン：ＣＣＦ２１でオンボーディングが成功した後にＣＣＦ２１によって割り当てられまたは生成され、ＡＰＩインボーカー２０によって送受信されたシークレット認可値またはシークレットトークンは、オンボーディングを、ＡＰＦインボーカー、ＣＣＦ２１、およびＡＥＦ２２の間で発生する後続の手順のすべてにバインドする。これは、オンボーディングライフタイムを通して有効である。
【０１７５】
８）認可トークン：ＣＣＦ２１でオンボーディングが成功した後にＡＰＩインボーカー２０が受信した、１回限りまたは長期使用のシークレット認可値。これは、ＡＰＩインボーカー２０、ＣＣＦ２１、およびＡＥＦ２２の間における認可に使用される。
ａ．変形例：イベントへのサブスクリプション、サービスＡＰＩのディスカバリなどの動作を行うための登録が成功した後にＣＣＦ２１から任意のサブスクライブエンティティにおいて受信する１回限り／長期使用のシークレット認可値。サブスクライブエンティティは、ＡＰＩインボーカー２０、ＡＰＩエクスポーズ機能２２、ＡＰＩ公開機能２３、またはＡＰＩ管理機能２４であってもよい。認可トークンは、オンボードトークンおよび本明細書のセクション２．１で説明した他のパラメータから導出することができる。
【０１７６】
９）ＣＡＰＩＦ主導によるＡＰＩオフボーディングは、ＡＰＩインボーカー２０について予期せぬ何らかの悪意のアクティビティがディスカバーまたはモニタされるのを防止するための提案である。［２］の仕様には、悪意のあるＡＰＩインボーカーを制御するメカニズムのないＡＰＩインボーカー２０主導のオフボーディング処理のみが含まれる。
【０１７７】
１０）公開トークンは、シークレット、ＡＰＩプロバイダ、ＡＰＦ２３、ＣＣＦ２１、サービスＡＰＩ連携情報、およびＣＡＰＩＦで認証済のＡＰＦ２３とＣＣＦ２１との間で使用された公開コードにバインドされており、悪意のあるＡＰＩパブリッシャが悪意のあるサービスを公開するのを防止する。
ａ．公開トークンは、非公開サービスＡＰＩ要求をトリガする認可情報としてＡＰＦ２３によって使用される。
ｂ．公開トークンは、更新サービスＡＰＩ要求をトリガする認可情報としてＡＰＦ２３によって使用される。
ｃ．公開トークンは、取得サービスＡＰＩ要求をトリガする認可情報としてＡＰＦ２３によって使用される。
【０１７８】
１１）公開期間は、要求のあったサービスＡＰＩを公開するために割り当てられた期間である。これにより、ＣＣＦ２１での効率的なリソース利用と、ＣＡＰＩＦでのより良いサービスＡＰＩ管理とがサポートされる。公開期間の終了後、ＣＣＦ２１は、過去にＣＣＦ２１のＡＰＦ２３によって公開されたサービスＡＰＩを非公開にする。
【０１７９】
１２）サービスＡＰＩのディスカバリレベルとトポロジの隠蔽は、ＡＰＩインボーカー２０のトラストレベルおよび／または、現在の在圏ネットワークゾーン、あるいはＡＰＩインボーカー２０がネットワークに接続するのに経由するＡＰＮのトラストレベルに基づく。
【０１８０】
１３）ＡＥＦ認可トークンは、シークレット（乱数）、ＡＥＦ  ＩＤ、ＣＡＰＩＦ  ＡＰＩインボーカーＩＤおよびサービスＡＰＩ連携情報を使用してＣＣＦ２１によって導出される。認証／認可が成功すると、ＣＣＦはＡＥＦ認可トークンをＡＰＩインボーカー２０およびＡＥＦ２２と共有し、後にＡＥＦ２２がＡＰＩインボーカー２０と共有し、サービス呼び出し中に自身の認可／相互認証を行う。ＡＥＦ認可トークンは、静的または動的である。
【０１８１】
呼び出しトークン／アクセストークン：ＡＰＩインボーカー２０がＡＥＦ２２へのサービス呼び出しを要求しようとするたびに、ＣＣＦ２１から受信した呼び出しトークンを、上記認証に続いて送信する、または、ＡＰＩインボーカー２０とＣＣＦ２１／ＡＥＦ２２との間の認証／認可に使用したキー、呼び出しカウンタ値、サービスＡＰＩ連携情報などの他のパラメータと共に、呼び出しトークン＊を導出するのに使用する。
ａ．呼び出しトークン＊／アクセストークン＊は、ＡＰＩインボーカー２０がサービスＡＰＩの呼び出し時にＡＰＩインボーカー２０とＡＥＦ２２の間で認証を行うための認可証明として使用する。また、リプレイ攻撃を防ぎ、トークンの鮮度を確保するためにも使用する。呼び出しトークン／アクセストークンを１回使用してサービスＡＰＩ呼び出しを要求した場合、セキュリティレベルが向上する。これによれば、リフレッシュトークンベースのアクセストークン要求／応答手順ではメッセージのラウンドトリップが追加で必要となる現行の技術とは異なり、追加のメッセージ交換を行う必要がない。
ｂ．変形例：リフレッシュトークンがＡＰＩインボーカー２０によって使用され、ＣＣＦ２１またはＡＥＦ２２から新しい認可証明を取得して、呼び出しトークン＊の生成に使用する。
ｃ．変形例：ＣＣＦ２１またはＡＥＦ２２提供のリフレッシュトークンは、認可リフレッシュ通知トークンとして使用され、ＡＰＩインボーカー２０によって、呼び出しトークン＊と共にＣＣＦ２１またはＡＥＦ２２に提供される。
ｄ．変形例：認可証明として呼び出しトークン＊を使用する代わりに、ＡＰＩインボーカー２０は、サービスＡＰＩの呼び出し時に、呼び出しキー＊または呼び出しシークレット＊を使用してＡＰＩインボーカー２０とＡＥＦ２２の間で認証を行う。
【０１８２】
１５）セキュリティレベルインジケータ：ＡＰＦ２３によってＣＣＦ２１へ通知されるセキュリティレベルインジケータには、公開されたサービスＡＰＩのセキュリティに関する任意の情報（機能／暗号アルゴリズム／アクセスレベルと動作権限／必要最低限のセキュリティ／インボーカーのタイプ／ＡＰＩインボーカー２０のトラストレベル／ＡＰＩ在圏ゾーンのトラストレベル）と、サービスＡＰＩにアクセスする要件に関する情報とが含まれている。
【０１８３】
１６）ＣＡＰＩＦイベントＩＤ：ＣＣＦ２１によるＣＡＰＩＦイベント管理には、サービスＡＰＩの可用性、サービスＡＰＩの更新、サービスＡＰＩ呼び出しのモニタリング、ＡＰＩインボーカーのオンボーディング、システム関連のイベント、パフォーマンス関連のイベントなどの管理が含まれ、これらは一意のＣＡＰＩＦイベントＩＤ（ＣＡＰＩＦ  Ｅｖｅｎｔ  Ｉｄｅｎｔｉｆｉｅｒ：ＣＡＰＩＦイベント識別子）を有する。ＣＡＰＩＦイベントＩＤは、ＣＡＰＩＦイベントを一意に識別するために、サブスクライバエンティティ、ＡＰＩインボーカー２０またはＣＣＦ２１によって使用される。
【０１８４】
１７）サブスクリプショントークン／キー：サブスクリプショントークン／キーは、ＣＣＦ２１でイベントのサブスクリプションおよびサブスクリプション解除を要求するために、サブスクライバエンティティによって認証または認可情報として生成および使用される。イベントのサブスクリプションを要求するサブスクライバエンティティの認可を検証するために、イベントのサブスクリプションを要求するサブスクライバエンティティに対応するサブスクリプショントークン／キーがＣＣＦ２１によって生成される。サブスクリプショントークン／キーは、以下の１つ以上のパラメータの任意の組み合わせを使用して導出される。オンボーディングの成功後にＣＣＦ２１から提供されるオンボードトークン、サブスクライバＩＤ、ＣＡＰＩＦイベントＩＤ、ＣＡＰＩＦ  ＩＤ、サブスクリプションコード／キーワード、サービスＡＰＩのタイプ／名称／ＩＤ、任意の事前共有シークレット、およびＡＰＩインボーカー２０／サブスクライバエンティティとＣＣＦ２１との間の初期認証／認可から導出した任意のキー／トークン。
ａ．サブスクリプショントークン／キーは、ＣＡＰＩＦイベントに関するサブスクリプション解除要求をＣＣＦ２１に対してトリガするために、サブスクライブされたエンティティによって認可情報として使用される。
【０１８５】
上記の実施形態では、以下のことが分かる。
【０１８６】
１）ＡＰＩインボーカー２０のオンボーディングが成功した後、ＣＣＦ２１はＡＰＩインボーカー２０にオンボードトークンを提供する。当該オンボードトークンは、ＣＡＰＩＦセキュリティ手順に使用するいずれかの認証または認可情報を導出するのに使用される。
２）ＣＡＰＩＦ手順で使用する認可トークンは、いずれも認証結果、通信相手の識別子、シークレット値、カウンタおよびサービスＡＰＩ連携情報にバインドされている。
３）オンボーディング結果は、オンボードトークンまたはこれから導出した認可トークンを介して、ＡＰＩインボーカー２０とＣＣＦ２１（および他のエンティティ）との間において行われるすべてのＣＡＰＩＦセキュリティ手順にバインドされる。
４）トポロジの隠蔽とサービスＡＰＩのディスカバリレベルでは、要求元のＡＰＩインボーカー２０のトラストレベル、または在圏ゾーンとそのネットワークとの一方または両方を考慮する。
５）サービスＡＰＩ呼び出しトークンは、追加のメッセージ交換を行うことなくリフレッシュされる。
６）ＣＣＦ２１へのＡＰＩインボーカー２０のオンボーディングにはライフタイムがある。
７）ＡＰＩ公開機能２３／ＡＰＩプロバイダによるサービスＡＰＩの公開、非公開、更新、および取得は、ＣＣＦ／ＣＡＰＩＦからＡＰＦ２３に提供される公開トークンを使用して、ＣＣＦ／ＣＡＰＩＦによって認可される。
８）ＣＡＰＩＦイベントのサブスクリプションの要求は、サブスクライバエンティティから提供される認可トークン／キーなどの認証または認可情報を検証することにより、ＣＣＦ２１によってチェックされる。認可トークンは、ＣＣＦ２１への登録時にサブスクライバエンティティに提供される。
９）サブスクリプショントークンは、サブスクリプション手順が正常に行われた後、ＣＣＦ２１によってサブスクライブエンティティに発行される。このサブスクリプショントークンは、ＣＣＦ２１またはＣＡＰＩＦからサブスクリプションを解除するために、サブスクライブエンティティによって使用される。
【０１８７】
利点
【０１８８】
提案した例示的な実施形態は、以下を含む多くの利点を有する。
現行のシステムには、ＣＡＰＩＦのセキュリティ問題に対処するための十分なセキュリティ手順がない。
現在の最新技術でのアクセストークンをリフレッシュするには、追加のメッセージ交換を行う必要がある。
【０１８９】
システム概要
【０１９０】
図１６は、上記の実施形態を適用可能なモバイル（セルラまたは無線）通信システム１を概略的に示す。
【０１９１】
このネットワークにおいて、各モバイルデバイス３（ＵＥ）のユーザは、例えばＥ−ＵＴＲＡ、５Ｇ  ＲＡＴなどの適切な３ＧＰＰ  ＲＡＴ（Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｔｅｃｈｎｏｌｏｇｙ：無線アクセス技術）を使用して、それぞれの基地局５および／またはコアネットワーク７を介して相互におよび他のユーザと通信を行うことができる。複数の基地局５で（無線）アクセスネットワークまたは（Ｒ）ＡＮを形成してもよい。図１６には１つのモバイルデバイス３および１つの基地局５が例示目的で示されているが、通常のシステム実装時には、他の基地局およびモバイルデバイス（ＵＥ）も含まれることは当業者には明らかである。
【０１９２】
各基地局５は、（直接、またはホーム基地局、リレー、リモートラジオヘッドなどの他のノードを介して）１つ以上の関連セルを制御する。Ｅ−ＵＴＲＡ／４Ｇプロトコルをサポートする基地局５は「ｅＮＢ」と呼ばれてもよく、次世代／５Ｇプロトコルをサポートする基地局５は「ｇＮＢ」と呼ばれてもよい。いくつかの基地局５は、４Ｇおよび５Ｇの両方、および／または任意の他の３ＧＰＰまたは非３ＧＰＰ通信プロトコルをサポートするように構成してもよい。
【０１９３】
モバイルデバイス３およびそのサービング基地局５は、適切なエアインターフェース（例えば、いわゆる「Ｕｕ」インターフェースなど）を介して接続される。隣接する基地局５は、適切な基地局を介して基地局インターフェース（いわゆる「Ｘ２」インターフェース、「Ｘｎ」インターフェースなど）に相互に接続されている。基地局５は、適切なインターフェース（いわゆる「Ｓ１」、「Ｎ１」、「Ｎ２」、「Ｎ３」インターフェースなど）を介してコアネットワークノードに接続されている。
【０１９４】
通常、コアネットワーク７は、通信システム１における通信をサポートするための論理ノード（または「機能」）を含む。通常、例えば、「次世代」／５Ｇシステムのコアネットワーク７には、各種機能の中でも特にＣＰＦ（Ｃｏｎｔｒｏｌ  Ｐｌａｎｅ  Ｆｕｎｃｔｉｏｎｓ：制御プレーン機能）８と、ＵＰＦ（Ｕｓｅｒ  Ｐｌａｎｅ  Ｆｕｎｃｔｉｏｎｓ：ユーザプレーン機能）９とを含む。コアネットワーク７からは、（例えば、１つ以上のゲートウェイを介して）外部ＩＰネットワーク１０（インターネットなど）への接続も提供される。
【０１９５】
ＣＡＰＩＦは、オペレーターネットワーク内でホストされる。したがって、システム１のノードは、適宜ＣＡＰＩＦ機能を提供するように構成される。例えば、１つ以上のノード（例えば、１つ以上のＣＰＦ８）は、ＣＡＰＩＦコア機能２１、ＡＰＩエクスポーズ機能２２、ＡＰＩ管理機能２４、ＡＰＩ公開機能２３、ＴＤＦ（Ｔｏｋｅｎ  Ｄｅｒｉｖａｔｉｏｎ  Ｆｕｎｃｔｉｏｎ：トークン導出機能）、サブスクライバエンティティなどとして動作するように構成してもよい。
【０１９６】
ＡＰＩインボーカー２０は、通常、オペレータとサービス契約を結んでいる第三者アプリケーションプロバイダから提供される。ＡＰＩインボーカー２０は、事業者ネットワークと同一のトラストドメイン内または事業者ネットワークのトラストドメイン外に在圏してもよい。
【０１９７】
ＵＥ（Ｕｓｅｒ  ｅｑｕｉｐｍｅｎｔ：ユーザ機器）
【０１９８】
図１７は、図１６に示すＵＥ（モバイルデバイス３）の主要構成要素を示すブロック図である。図示のように、ＵＥは、１つ以上のアンテナ３３を介して接続ノードと信号の送受信を行うように動作可能なトランシーバ回路３１を含む。図１７には示されていないが、ＵＥが従来のモバイルデバイスの通常の機能（ユーザインタフェース３５など）をすべて備えることは明らかである。これは、ハードウェア、ソフトウェアおよびファームウェアのいずれか１つまたはこれらの任意の組み合わせによって適宜実現してもよい。コントローラ３７は、メモリ３９に記憶されたソフトウェアに従ってＵＥの動作を制御する。ソフトウェアは、メモリ３９に事前にインストールしてもよいし、例えば、通信ネットワーク１を介して、またはＲＭＤ（Ｒｅｍｏｖａｂｌｅ  Ｄａｔａ  Ｓｔｏｒａｇｅ  Ｄｅｖｉｃｅ：リムーバブルデータ格納デバイス）からダウンロードしてもよい。ソフトウェアは、特にオペレーティングシステム４１および通信制御モジュール４３を含む。通信制御モジュール４３は、ＵＥ３と、（Ｒ）ＡＮノード５、コアネットワークノードなどの他のノードとの間におけるシグナリングメッセージおよびアップリンク／ダウンリンクデータパケットの処理（生成／送信／受信）を担う。
【０１９９】
（Ｒ）ＡＮノード
【０２００】
図１８は、図１６に示す（Ｒ）ＡＮノード５（基地局）の主な構成要素の例を示すブロック図である。図示のように、（Ｒ）ＡＮノード５は、１つ以上のアンテナ５３を介して接続ＵＥ３と信号の送受信を行い、ネットワークインターフェース５５を介して他のネットワークノードと（直接的または間接的に）信号の送受信を行うように動作可能なトランシーバ回路５１を含む。ネットワークインターフェース５５は、通常、適切な基地局−基地局インターフェース（Ｘ２／Ｘｎなど）および適切な基地局−コアネットワークインターフェース（Ｓ１／Ｎ１／Ｎ２／Ｎ３など）を含む。コントローラ５７は、メモリ５９に記憶されたソフトウェアに従って（Ｒ）ＡＮノード５の動作を制御する。ソフトウェアは、メモリ５９に事前にインストールしてもよいし、例えば、通信ネットワーク１を介して、またはＲＭＤから、ダウンロードしてもよい。ソフトウェアは、特にオペレーティングシステム６１および通信制御モジュール６３を含む。通信制御モジュール６３は、（Ｒ）ＡＮノード５と、ＵＥ３、コアネットワークノードなどの他のノードとの間におけるシグナリングの処理（生成／送信／受信）を担う。通信制御モジュール６３はまた、ＡＰＩ連携のセキュリティ手順の実行を担う。
【０２０１】
コアネットワークノード
【０２０２】
図１９は、例えば図１６に示すＣＰＦ８またはＵＰＦ９（またはＡＰＩインボーカー２０）などの一般的なコアネットワークノード（または機能）の主な構成要素を示すブロック図である。図示のように、コアネットワークノードは、他のノード（ＵＥ３および（Ｒ）ＡＮノード５を含む）とネットワークインターフェース７５を介して信号の送受信を行うように動作可能なトランシーバ回路７１を含む。コントローラ７７は、メモリ７９に記憶されたソフトウェアに従ってコアネットワークノードの動作を制御する。ソフトウェアは、メモリ７９に事前にインストールしてもよいし、例えば、通信ネットワーク１を介して、またはＲＭＤから、ダウンロードしてもよい。ソフトウェアは、特にオペレーティングシステム８１および通信制御モジュール８３を含む。通信制御モジュール８３は、コアネットワークノードと、ＵＥ３、（Ｒ）ＡＮノード５、他のコアネットワークなどの他のノードとの間におけるシグナリングの処理（生成／送信／受信）を担う。このシグナリングには、ＡＰＩ連携のセキュリティ手順に関する、適切にフォーマットされた要求と応答とが含まれる。
【０２０３】
（変形例および代替案）
【０２０４】
以上、実施形態を詳細に説明した。上記実施形態については複数の変形例および代替案が可能であり、そのようにして具現化された発明であっても同様の利を得ることができることは当業者には明らかである。説明のため、これらの変形例および代替案の例を一部のみ説明する。
【０２０５】
上記の説明では、ＵＥ、（Ｒ）ＡＮノード、およびコアネットワークノード（ＡＰＩインボーカーを含む）は、理解を容易にするために、複数の個別モジュール（通信制御モジュールなど）を有するものとして説明された。これらのモジュールは、例えば、本発明を実施するために既存のシステムに変更を加えた特定のアプリケーションについては、上述のような方法で提供することができるが、例えば、最初から本発明の特徴を念頭に置いて設計されたシステムなどの他のアプリケーションについては、これらのモジュールをオペレーティングシステムまたはコード全体に組み込んでもよく、この場合、これらのモジュールを個別のエンティティとして認識する必要はない。これらのモジュールは、ソフトウェア、ハードウェア、ファームウェア、またはこれらの組み合わせで実現してもよい。
【０２０６】
各コントローラは任意の形態の処理回路を適宜含んでもよく、例えば、以下が含まれる（限定的ではない）。ハードウェアに実装された１つ以上のコンピュータプロセッサ；マイクロプロセッサ；ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔｓ：中央処理装置）；ＡＬＵ（Ａｒｉｔｈｍｅｔｉｃ  Ｌｏｇｉｃ  Ｕｎｉｔｓ：算術論理ユニット）；ＩＯ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ：入出力）回路；内部メモリ／キャッシュ（プログラムおよび／またはデータ）；処理レジスタ；通信バス（例えば、制御、データおよび／またはアドレスバス）；ＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ：ダイレクトメモリアクセス）機能；およびハードウェアまたはソフトウェア実装されたカウンタ、ポインタ、タイマなど。
【０２０７】
上述の実施形態では、複数のソフトウェアモジュールを説明した。当業者が理解するように、ソフトウェアモジュールは、コンパイルされた形式またはコンパイルされていない形式で提供してもよいし、コンピュータネットワークを介した信号として、または記録媒体上で、ＵＥ、（Ｒ）ＡＮノード、およびコアネットワークノードに供給してもよい。さらに、このソフトウェアの一部またはすべてによって実行される機能は、１つ以上の専用ハードウェア回路を使用して実行してもよい。ただし、ソフトウェアモジュールは、ＵＥ、（Ｒ）ＡＮノード、およびコアネットワークノードの機能性向上のための更新をファシリテートするため、使用することが望ましい。
【０２０８】
上記の実施形態は、「非モバイル」または一般に固定のユーザ機器にも適用可能である。
【０２０９】
種々の他の変更は、当業者にとって明らかであるため、ここでは更に詳細な説明は省略する。
【０２１０】
上記の例示的な態様で説明したプログラムは、記憶デバイスに格納されるか、コンピュータで読み取り可能な記録媒体に記録される。例えば、記録媒体は、フレキシブルディスク、光ディスク、光磁気ディスク、半導体メモリ等の可搬媒体である。
【０２１１】
以上、例示的な態様を参照して本開示を説明したが、本開示は、上記の例示的な態様に限定されるものではない。本開示の構成および詳細は、本開示の範囲内で当業者が理解し得る様々な形で変更が可能である。
【０２１２】
本出願は、２０１８年４月６日出願のインド特許出願第２０１８１１０１３２１２号に基づく優先権の利益を主張する。この開示の内容は、全てここに含めておく。
【０２１３】
参考文献一覧
【０２１４】
［１］３ＧＰＰ  ＴＲ  ２３．７２２  Ｖ１．０．０  （２０１７−０９），  “Ｓｔｕｄｙ  ｏｎ  Ｃｏｍｍｏｎ  ＡＰＩ  Ｆｒａｍｅｗｏｒｋ  ｆｏｒ  ３ＧＰＰ  Ｎｏｒｔｈｂｏｕｎｄ  ＡＰＩｓ”  （Ｒｅｌｅａｓｅ  １５）．
［２］３ＧＰＰ  ＴＳ  ２３．２２２  Ｖ１５．０．０  （２０１８−０１），  “Ｃｏｍｍｏｎ  ＡＰＩ  Ｆｒａｍｅｗｏｒｋ  ｆｏｒ  ３ＧＰＰ  Ｎｏｒｔｈｂｏｕｎｄ  ＡＰＩｓ；  Ｓｔａｇｅ  ２”  （Ｒｅｌｅａｓｅ  １５）．
［３］３ＧＰＰ  ＴＳ  ３３．１２２  Ｖ０．１．０  （２０１８−０１），  “Ｓｅｃｕｒｉｔｙ  Ａｓｐｅｃｔｓ  ｏｆ  Ｃｏｍｍｏｎ  ＡＰＩ  Ｆｒａｍｅｗｏｒｋ  ｆｏｒ  ３ＧＰＰ  Ｎｏｒｔｈｂｏｕｎｄ  ＡＰＩｓ”．（Ｓ３−１８０４０１として入手可能）
［４］ＲＦＣ  ６７４９：  “ＯＡｕｔｈ  ２．０  Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ｆｒａｍｅｗｏｒｋ”．
［５］ＲＦＣ  ６７５０：  “ＯＡｕｔｈ  ２．０  Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ｆｒａｍｅｗｏｒｋ  Ｂｅａｒｅｒ  Ｔｏｋｅｎ  Ｕｓａｇｅ”．
［６］３ＧＰＰ  Ｓ６−１７１５３４，  “Ｉｓｓｕｅｓ  ｏｆ  ｆｕｎｃｔｉｏｎａｌｉｔｉｅｓ  ｉｎ  ｔｈｅ  ＣＡＰＩＦ  ＴＳ  ２３．２２２”，  Ｎｏｖ  ２０１７，  ＮＥＣ
［７］３ＧＰＰ  Ｓ６−１７１５３８，  “Ｐｓｅｕｄｏ−ＣＲ  ｏｎ  ｍｉｓｓｉｎｇ  ｆｕｎｃｔｉｏｎａｌｉｔｉｅｓ  ｉｎ  ＣＡＰＩＦ−ｏｆｆｂｏａｒｄｉｎｇ”，  Ｎｏｖ  ２０１７，  ＮＥＣ
【０２１５】
略語と用語
【０２１６】
３ＧＰＰ    ３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ（第３世代パートナーシッププロジェクト）
５Ｇ    ５ｔｈ  Ｇｅｎｅｒａｔｉｏｎ（第５世代）
ＡＥＦ    ＡＰＩ  Ｅｘｐｏｓｉｎｇ  Ｆｕｎｃｔｉｏｎ（ＡＰＩエクスポーズ機能）
ＡＭＦ    ＡＰＩ  Ｍａｎａｇｅｍｅｎｔ  Ｆｕｎｃｔｉｏｎ（ＡＰＩ管理機能）
ＡＰＦ    ＡＰＩ  Ｐｕｂｌｉｓｈｉｎｇ  Ｆｕｎｃｔｉｏｎ（ＡＰＩ公開機能）
ＡＰＩ    Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ（アプリケーションプログラミングインターフェース）
ＣＡＰＩＦ      Ｃｏｍｍｏｎ  ＡＰＩ  Ｆｒａｍｅｗｏｒｋ（共通ＡＰＩフレームワーク）
ＣＣＦ    ＣＡＰＩＦ  Ｃｏｒｅ  Ｆｕｎｃｔｉｏｎ（ＣＡＰＩＦコア機能）
ＤｏＳ    Ｄｅｎｉａｌ  ｏｆ  Ｓｅｒｖｉｃｅ（サービス拒否）
ＬＴＥ    Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ（ロングタームエボリューション）
ＮＥＦ    Ｎｅｔｗｏｒｋ  Ｅｘｐｏｓｕｒｅ  Ｆｕｎｃｔｉｏｎ（ネットワークエクスポーズ機能）
ＰＬＭＮ    Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ（公衆陸上モバイルネットワーク）
ＴＤＦ    Ｔｏｋｅｎ  Ｄｅｒｉｖａｔｉｏｎ  Ｆｕｎｃｔｉｏｎ（トークン導出機能）
ＳＡ２    ３ＧＰＰ  ＳＡ  ＷＧ  ２（３ＧＰＰ  ＳＡワーキンググループ２）
ＳＡ３    ３ＧＰＰ  ＳＡ  ＷＧ  ３（３ＧＰＰ  ＳＡワーキンググループ３）
ＳＡ６    ３ＧＰＰ  ＳＡ  ＷＧ  ６（３ＧＰＰ  ＳＡワーキンググループ６）
ＳＣＥＦ    Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｙ  Ｅｘｐｏｓｉｎｇ  Ｆｕｎｃｔｉｏｎ（サービスケーパビリティエクスポーズ機能）
ＳＤＯ    Ｓｔａｎｄａｒｄ  Ｄｅｖｅｌｏｐｉｎｇ  Ｏｒｇａｎｉｚａｔｉｏｎ（標準化団体）
ＳＬＡ    Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ａｇｒｅｅｍｅｎｔ（サービスレベルアグリーメント）
ＴＲ    Ｔｅｃｈｎｉｃａｌ  Ｒｅｐｏｒｔ（技術報告書）
ＴＳ    Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（技術仕様書）
ＷＩ    Ｗｏｒｋ  Ｉｔｅｍ（作業項目）
【図１】
2021516515.tif 000006
【図２】
2021516515.tif 000007
【図３】
2021516515.tif 000008
【図４】
2021516515.tif 000009
【図５】
2021516515.tif 000010
【図６】
2021516515.tif 000011
【図７】
2021516515.tif 000012
【図８】
2021516515.tif 000013
【図９】
2021516515.tif 000014
【図１０】
2021516515.tif 000015
【図１１】
2021516515.tif 000016
【図１２】
2021516515.tif 000017
【図１３】
2021516515.tif 000018
【図１４】
2021516515.tif 000019
【図１５】
2021516515.tif 000020
【図１６】
2021516515.tif 000021
【図１７】
2021516515.tif 000022
【図１８】
2021516515.tif 000023
【図１９】
2021516515.tif 000024
【手続補正書】
【提出日】令和2年9月23日(2020.9.23)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ＴＬＳを使用してアプリケーションサーバとの認証を行った後、オンボーディングＡＰＩインボーカー要求メッセージを前記アプリケーションサーバに送信する送信手段と、
前記アプリケーションサーバから割り当てられるアプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオンボーディングＡＰＩインボーカー応答メッセージを前記アプリケーションサーバから受信する受信手段と、を備える、
デバイス。
【請求項２】
前記アプリケーションサーバとＴＬＳセッションを確立する確立手段を更に備える、
請求項１に記載のデバイス。
【請求項３】
前記オンボーディングＡＰＩインボーカー応答メッセージは、オンボーディングライフタイムの間同一であり続けるオンボードシークレット情報を含む、
請求項１または２に記載のデバイス。
【請求項４】
前記認証後、前記送信手段は、サービスＡＰＩへのアクセス許可を取得するために前記アプリケーションサーバに第２の要求メッセージを送信し、
前記受信手段は、前記デバイスに固有のアクセストークンを含む第２の応答メッセージを前記アプリケーションサーバから受信する、
請求項１から３のいずれか一項に記載のデバイス。
【請求項５】
前記第２の要求メッセージは、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤおよびオンボードシークレット情報を含む、
請求項４に記載のデバイス。
【請求項６】
前記ＴＬＳを使用した認証の後、前記送信手段は、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオフボードＡＰＩインボーカー要求メッセージを前記アプリケーションサーバに送信し、
前記受信手段は、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤの検証の成功に応じて、前記デバイスのオフボーディングが成功したことを示すオフボードＡＰＩインボーカー応答メッセージを前記アプリケーションサーバから受信する、
請求項１から５のいずれか一項に記載のデバイス。
【請求項７】
ＴＬＳを使用してデバイスとの認証を行った後、オンボーディングＡＰＩインボーカー要求メッセージを前記デバイスから受信する受信手段と、
アプリケーションサーバから割り当てられるアプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオンボーディングＡＰＩインボーカー応答メッセージを、前記オンボーディングＡＰＩインボーカー要求メッセージに応じて前記デバイスに送信する送信手段と、を備える、
アプリケーションサーバ。
【請求項８】
前記デバイスとＴＬＳセッションを確立する確立手段を更に備える、
請求項７に記載のアプリケーションサーバ。
【請求項９】
前記オンボーディングＡＰＩインボーカー応答メッセージは、オンボーディングライフタイムの間同一であり続けるオンボードシークレット情報を含む、
請求項７または８に記載のアプリケーションサーバ。
【請求項１０】
前記認証後、前記受信手段は、サービスＡＰＩへのアクセス許可を取得するために前記デバイスから第２の要求メッセージを受信し、
更に、前記デバイスに固有のアクセストークンを生成する生成手段を備え、
前記送信手段は、前記アクセストークンを含む第２の応答メッセージを前記デバイスに送信する、
請求項７から９のいずれか一項に記載のアプリケーションサーバ。
【請求項１１】
前記第２の要求メッセージは、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤおよびオンボードシークレット情報を含む、
請求項１０に記載のアプリケーションサーバ。
【請求項１２】
前記ＴＬＳを使用した認証の後、前記受信手段は、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオフボードＡＰＩインボーカー要求メッセージを前記デバイスから受信し、
更に、
前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤを検証する検証手段と、
前記デバイスの登録をキャンセルするキャンセル手段と、
前記デバイスの認可情報を削除する削除手段と、を備え、
前記送信手段は、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤの検証の成功に応じて、オフボーディングの成功を示すオフボードＡＰＩインボーカー応答メッセージを前記デバイスに送信する、
請求項７から１１のいずれか一項に記載のアプリケーションサーバ。
【請求項１３】
オペレータのポリシーに応じて前記デバイスの情報を保持する保持手段を更に備える、
請求項１２に記載のアプリケーションサーバ。
【請求項１４】
デバイスにおける情報処理方法であって、
ＴＬＳを使用してアプリケーションサーバとの認証を行った後、オンボーディングＡＰＩインボーカー要求メッセージを前記アプリケーションサーバに送信することと、
前記アプリケーションサーバから割り当てられるアプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオンボーディングＡＰＩインボーカー応答メッセージを前記アプリケーションサーバから受信することと、を備える、
情報処理方法。
【請求項１５】
前記アプリケーションサーバとＴＬＳセッションを確立することを備える、
請求項１４に記載の情報処理方法。
【請求項１６】
前記オンボーディングＡＰＩインボーカー応答メッセージは、オンボーディングライフタイムの間同一であり続けるオンボードシークレット情報を含む、
請求項１４または１５に記載の情報処理方法。
【請求項１７】
前記認証後、サービスＡＰＩへのアクセス許可を取得するために前記アプリケーションサーバに第２の要求メッセージを送信することと、
前記デバイスに固有のアクセストークンを含む第２の応答メッセージを前記アプリケーションサーバから受信することと、を備える、
請求項１４から１６のいずれか一項に記載の情報処理方法。
【請求項１８】
前記第２の要求メッセージは、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤおよびオンボードシークレット情報を含む、
請求項１７に記載の情報処理方法。
【請求項１９】
前記ＴＬＳを使用した認証の後、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオフボードＡＰＩインボーカー要求メッセージを前記アプリケーションサーバに送信することと、
前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤの検証の成功に応じて、前記デバイスのオフボーディングが成功したことを示すオフボードＡＰＩインボーカー応答メッセージを前記アプリケーションサーバから受信することと、を備える、
請求項１４から１８のいずれか一項に記載の情報処理方法。
【請求項２０】
アプリケーションサーバにおける情報処理方法であって、
ＴＬＳを使用してデバイスとの認証を行った後、オンボーディングＡＰＩインボーカー要求メッセージを前記デバイスから受信することと、
アプリケーションサーバから割り当てられるアプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオンボーディングＡＰＩインボーカー応答メッセージを、前記オンボーディングＡＰＩインボーカー要求メッセージに応じて前記デバイスに送信することと、を備える、
情報処理方法。
【請求項２１】
前記デバイスとＴＬＳセッションを確立することを備える、
請求項２０に記載の情報処理方法。
【請求項２２】
前記オンボーディングＡＰＩインボーカー応答メッセージは、オンボーディングライフタイムの間同一であり続けるオンボードシークレット情報を含む、
請求項２０または２１に記載の情報処理方法。
【請求項２３】
前記認証後、サービスＡＰＩへのアクセス許可を取得するために前記デバイスから第２の要求メッセージを受信することと、
前記デバイスに固有のアクセストークンを生成することと、
前記アクセストークンを含む第２の応答メッセージを前記デバイスに送信することと、を備える、
請求項２０から２２のいずれか一項に記載の情報処理方法。
【請求項２４】
前記第２の要求メッセージは、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤおよびオンボードシークレット情報を含む、
請求項２３に記載の情報処理方法。
【請求項２５】
前記ＴＬＳを使用した認証の後、前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤを含むオフボードＡＰＩインボーカー要求メッセージを前記デバイスから受信することと、
前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤを検証することと、
前記デバイスの登録をキャンセルすることと、
前記デバイスの認可情報を削除することと、
前記アプリケーションサーバ関連ＡＰＩインボーカーＩＤの検証の成功に応じて、オフボーディングの成功を示すオフボードＡＰＩインボーカー応答メッセージを前記デバイスに送信することと、を備える、
請求項２０から２４のいずれか一項に記載の情報処理方法。
【請求項２６】
オペレータのポリシーに応じて前記デバイスの情報を保持することを備える、
請求項２５に記載の情報処理方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０１８１
【補正方法】変更
【補正の内容】
【０１８１】
１４）呼び出しトークン／アクセストークン：ＡＰＩインボーカー２０がＡＥＦ２２へのサービス呼び出しを要求しようとするたびに、ＣＣＦ２１から受信した呼び出しトークンを、上記認証に続いて送信する、または、ＡＰＩインボーカー２０とＣＣＦ２１／ＡＥＦ２２との間の認証／認可に使用したキー、呼び出しカウンタ値、サービスＡＰＩ連携情報などの他のパラメータと共に、呼び出しトークン＊を導出するのに使用する。
ａ．呼び出しトークン＊／アクセストークン＊は、ＡＰＩインボーカー２０がサービスＡＰＩの呼び出し時にＡＰＩインボーカー２０とＡＥＦ２２の間で認証を行うための認可証明として使用する。また、リプレイ攻撃を防ぎ、トークンの鮮度を確保するためにも使用する。呼び出しトークン／アクセストークンを１回使用してサービスＡＰＩ呼び出しを要求した場合、セキュリティレベルが向上する。これによれば、リフレッシュトークンベースのアクセストークン要求／応答手順ではメッセージのラウンドトリップが追加で必要となる現行の技術とは異なり、追加のメッセージ交換を行う必要がない。
ｂ．変形例：リフレッシュトークンがＡＰＩインボーカー２０によって使用され、ＣＣＦ２１またはＡＥＦ２２から新しい認可証明を取得して、呼び出しトークン＊の生成に使用する。
ｃ．変形例：ＣＣＦ２１またはＡＥＦ２２提供のリフレッシュトークンは、認可リフレッシュ通知トークンとして使用され、ＡＰＩインボーカー２０によって、呼び出しトークン＊と共にＣＣＦ２１またはＡＥＦ２２に提供される。
ｄ．変形例：認可証明として呼び出しトークン＊を使用する代わりに、ＡＰＩインボーカー２０は、サービスＡＰＩの呼び出し時に、呼び出しキー＊または呼び出しシークレット＊を使用してＡＰＩインボーカー２０とＡＥＦ２２の間で認証を行う。
【国際調査報告】
2021516515.tif 000025
2021516515.tif 000026
2021516515.tif 000027
2021516515.tif 000028