5G（第5世代移動通信システム）/5G advanced/6G（第6世代移動通信システム）における新たなユースケースとして期待されるのが、3rd party事業者がユーザ同意に基づいて通信事業者のAPI（Application Programming Interface）を利用する例です。ここでは、その一例としてオンラインゲーム中のQoS（Quality of Service）設定の例を説明します（図1）。
この例では、通信事業者と契約を持つユーザが自身の保有する端末上のアプリを用いてタイムセンシティブなゲームをプレイする場面を想定しています。このような場面において、より良いサービス体験のためにより高品質で低遅延な通信をユーザが希望することもあるかもしれません。このようなユーザの要望に基づいて3rd party事業者であるゲームプロバイダのゲームサーバが通信事業者の提供するQoS設定APIを呼び出すためには、ゲームサーバが通信事業者からAPIの呼び出し認可を得る必要があります。さらにQoS変更のために追加料金が必要な場合は、追加料金に関するユーザの同意を得る必要があります。
このようなユースケースを実現するため、現在3GPP（3rd Generation Partnership Project）では、RNAA（Resource owner-aware Northbound API Access）の標準化を行っています。

RNAAではOAuth 2.0を利用してユーザの同意を取得する手順を規定しています。OAuth 2.0はAPI呼び出し等におけるリソースの保護を目的として多くのWebサイトで採用されているプロトコルであり、その仕様はIETF（Internet Engineering Task Force）のRFC 6749等で規定されています。このプロトコルではいくつかの付与方式（Grant Type）が規定されていますが、RNAAではClient Credentials Grant/Authorization Code Grant/PKCE（Proof Key for Code Exchange）を採用しています。ここでは、OAuth 2.0の標準的な付与方式であるAuthorization Code Grantを用いたOAuth 2.0フロー（図2）をRFC 6749の1.2節と4.1節の規定に基づいて説明します。
OAuth 2.0フローは、Resource Owner（エンドユーザなど）がアクセス権を持つリソース（APIなど）にアクセスしたいClientがResource OwnerのUser Agent（Webブラウザなど）をAuthorization Serverの認可エンドポイントに送信（リダイレクト）することで、リソースへのアクセスに必要な権限の委譲をAuthorization Serverにリクエストすることから開始します。リクエストを受けたAuthorization ServerはUser Agent経由でResource Ownerを認証し、その後Resource OwnerからAuthorization Server に対してClientへの権限移譲の許可を通知します。ここでのClientへの権限委譲が、RNAAにおけるユーザ同意取得手順に相当します。その後、Authorization ServerはUser AgentをClientにリダイレクトします。このときResource Ownerの権限委譲許可を示すものとして、ClientはUser Agentから一時的なクレデンシャルである認可コードを受け取ります。そしてClientはAuthorization Serverの認可エンドポイントにその認可コードを送信します。Authorization Serverは認可コードの検証やClientの認証等を行い、結果が正当である場合はアクセストークンを生成しClientに通知します。ClientはこのアクセストークンをResource Serverに提示し、リソースへのアクセスを要求します。Resource Serverはアクセストークンを検証し、その要求の正当性が認められた場合、ClientがResource Ownerの代わりにリソースへアクセスすることが可能となります。

RNAAでは、CAPIF（Common API Framework）仕様^{（1）～（3）}の拡張によってユーザの同意に基づくAPI利用のユースケースを実現することを検討しています。
CAPIFは通信事業者のモバイル網機能を3rd party事業者が利用できるようにするためのフレームワークであり、3GPPではリリース15から標準化を行ってきました。CAPIFの主な機能としては、複数の通信事業者がAPIを提供する際における3rd party事業者による適切なAPIの発見が挙げられます。なお、モバイル網機能を3rd party事業者が利用する際に用いられるNorthbound APIは、EPC（Evolved Packet Core）や5GC（5G Core network）内のSCEF（Service Capability Exposure Function）やNEF（Network Exposure Function）と呼ばれる機能部が提供しています。SCEF/NEFは通信事業者のEPC/5GCの他の機能部とSouthboundインタフェースを介して接続しており、3rd party事業者からAPIの呼出しリクエストを受けたSCEF/NEFはこのインタフェースを介してEPC/5GCの機能（QoS設定など）にアクセスすることができます。
RNAAではCAPIFの拡張として、Resource Owner Client、Authorization Functionと呼ばれる機能部と、これらに関係するリファレンスポイントを新たに規定しました（図3）。Authorization Function、API Invoker、AEF（API Exposing Function）はそれぞれOAuth 2.0におけるAuthorization Server、Client、Resource Serverに相当します。Authorization Serverはリリース18時点ではCCF（CAPIF Core Function）内部に存在し、Resource Owner Clientは端末上に存在します。
API InvokerはAPIの呼び出し元を指します。通信事業者と3rd party事業者のどちらかがこの役割を果たします。AEFはサービスAPIと呼ばれるNorthbound APIを公開する機能を持ち、SCEFやNEFなどがこの機能部に相当します。AEFはAPI Invokerの認証認可も行います。APF（API Publishing Function）はCCFに対してサービスAPI関連情報を発行します。このとき発行された情報等により、CCFは適切な接続先サービスAPIを発見できるようになります。AMF（API Management Function）は発行されたサービスAPIの管理（サービスAPIの呼び出しログやサービスAPIの状態監視など）を行います。最後に紹介するCCF（CAPIF Core Function）はCAPIF仕様の要となる機能部です。CCFはAPI Invokerの認証や、サービスAPI情報の保持とそれに基づくサービスAPI発見等の能力を持っています。API InvokerはCCFが公開するCAPIF APIを呼び出すことで、サービスAPI呼び出しを行うためのAPI Invokerの認証認可や接続先APIの発見などの共通手順を実行することができます。
CAPIFではCCFとAEF/APF/AMFを異なる事業者が提供するケースも想定されていますが、現時点のRNAA仕様ではCCFとAEF/APF/AMFをすべて同一の通信事業者が提供するケースを前提としています。

API InvokerがCAPIFでサービスAPIを呼び出す際にユーザの同意を取得する手順^（3）は、API Invoker～AEF間の認証認可手順において発生します。この手順では、API InvokerがCCFのCAPIF APIを呼び出して、CCFに対して自身の認証を行います。CCFはAPI Invokerの認証実行後に適切なAPIを発見します。その後、API Invokerが再度CCFのCAPIF APIを呼び出して、API Invoker～AEF間の認証認可を行う方法（セキュリティメソッド）を決定します。ユーザの同意取得が必要な場合は、どの付与方式を用いてユーザの同意を取得するかをこのとき併せてネゴシエートします。その後、API Invokerは決定したセキュリティメソッドを用いてAEFに対して自身の認証を行い、Client Credentials Grant/Authorization Code Grant/PKCEのいずれかの付与方式を用いて自身の認可（サービスAPI呼び出しに関するユーザ同意の取得）を行います。

NTTでは2023年からRNAAの詳細手順の仕様化をCT3＊1とSA3＊2で進めています。これらの仕様はSA1＊3、SA6＊4で規定したサービス要求条件とアーキテクチャに従っています。CT3ではNTTがラポータを担当し、SA3ではNTTドコモがラポータを担当しています。これらのRNAA仕様^{（2）（3）}は2023年度末に完成予定です。NTTでは、今後も3GPPにおける標準化活動を通してさまざまな産業界とのコラボレーションや新規サービスの創出に寄与していきます。

＊1　CT3：異なるネットワーク間のプロトコルなどを検討する3GPPワーキンググループ。
＊2　SA3：セキュリティ関連仕様を検討する3GPPワーキンググループ。
＊3　SA1：サービス要求条件を検討する3GPPワーキンググループ。
＊4　SA6：アプリケーションイネーブラなどを検討する3GPPワーキンググループ。

■参考文献
（1）　https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3337
（2）　https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3450
（3）　https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3420