search

camaraproject / IdentityAndConsentManagement

Repository to describe, develop, document and test the Identity And Consent Management for CAMARA APIs
Apache License 2.0
18 stars 30 forks source link

Application identification for usage tracking and monetization #126

Open SyeddR opened 3 months ago

SyeddR commented 3 months ago

Problem description There is a need to transmit the application identifier to downstream systems, enabling the generation of usage records for each application. This process is crucial for monitoring performance and facilitating monetization strategies.

Use Case: When the QoD Service processes a request, it captures the application identifier and forwards this identifier (as either a sponsor ID and/or application ID) to downstream network elements, such as SCEF/NEF within the 4G/5G networks. These systems, in turn, produce usage records or CDRs that include the application identifier, thereby enabling detailed monitoring and monetization based on session usage.

One question arises: Can the client ID serve as an effective application identifier for tracking purposes? Several concerns need to be addressed:

  1. An application provider may offer multiple applications. Is it feasible to generate a unique client ID for each application?
  2. In an aggregator model, if a client ID represents an aggregator, how does the Camara API service layer distinguish between individual applications for usage tracking?
  3. Conversely, if a client ID denotes an individual application, how do we authenticate an aggregator acting on behalf of the application?
  4. Regarding consent flow, is it possible for consent to be granted to both an application and an aggregator? How would this flow work?

Possible evolution Introducing a more granular level ID, distinct from the client ID, within the authorization flow could potentially resolve these issues. Please discuss.

Additional context This issue has been documented and is being tracked under QoD workstream , link -https://github.com/camaraproject/QualityOnDemand/issues/194

garciasolero commented 3 months ago
  1. & 2. In the aggregation solution, each application has its own client_id in the aggregator and the operators. That is, the aggregator never uses a single client_id to route requests from all applications to the operators.
  2. Due to each application having its own client_id, in the requests routed by the aggregator (which will rebuild the requests and JWTs), operators authenticate the application with the information provided by the aggregator. If an application has been registered through an aggregator, the TMForum Operate API (TMF931 Open Gateway Onboarding and Ordering Component Suite v5.0.0) defines the concept of Channel Partner to link that application with the aggregator during application provisioning.
  3. Since applications are authenticated, consent is granted to the application, not the aggregator .
SyeddR commented 2 months ago

For point 2 How does a client id get generated in TMF 931 flow? Is it generated at application owner registration or individual application registration? Note that application owner can register multiple applications. If client id is generated at application owner level then the issue still holds.

For point 3 If aggregator is in the loop for resource api calls, i think consent flow should take into account aggregator as well.

garciasolero commented 2 months ago
  1. In TMF931 flow, the client_id is provided by the Application Owner on Application registration.
  2. I think this is not the appropriate project to address the question of whether the aggregator should be considered in the consent capture flow. Perhaps it should be discussed in the GSMA Open Gateway forums.