token refresh not possible on Event subscriptions

[Elisabeth-Mueller]

Problem description
The instance based (implicit subscription) only supports access token credential as sink credential.
Consequently, it is not possible to refresh the access token. Once expired, no further events can be communicated from resource server to API Invoker.

Possible solution: The sink credential type "plain credential" could be used instead of sink credential type "access token" . In addition the endpoint of the API Invokers authZ server must be made known to the resource server. then the resource server can get hold of an access token and a refresh token. Especially it is possible to acquire a new access token when the old one has expired.

Alternative solution: The sink credential type "refresh token" could be used instead of sink credential type "access token", but must be extended with client_id and client_secret. . In addition the endpoint of the API Invokers authZ server must be made known to the resource server. Then the resource server and use the access token provided in the refresh-token sink until it has expired and refresh it using the refresh token and the client credentials after expiry. this is the most convenient solution for the API resource server.

Additional context

CAMARA API QoD yaml file contains the current limitation about only supporting the sink of type "access token". Once the limitation has been removed from the Common documentation (https://github.com/camaraproject/Commonalities/blob/main/documentation/CAMARA-API-Event-Subscription-and-Notification-Guide.md) also the API implementations must be adjusted.

[FrimanJan]

Updated with a proposed solution!

Instance based subscription in commonalities defines 3 sink credentials types

• PLAIN, where identifier and secret are provided
  not a secure solution
• ACCESSTOKEN, where access token is provided in the subscription
  requires the resource server to act as an authorization server
• REFRESHTOKEN, where refresh token and access token are provided in the subscription
  requires the resource server to act as an authorization server
  Proposal is to replace these type with a standard OAuth2 authentication method private key JWT RFC7523 with OAuth2 client credentials flow.

Note that this is consistent with the L2 to L1 Camara recommended authentication method.

The following information are required for this

• L2 needs L1 JWKS URI
• L1 needs L2 client-id and L2 token endpoint

They could be shared:

• both at onboarding
• or JWK URI at on boarding and client-id/L2 token endpoint at subscription

Callback Authentication in CAMARA.pptx

[PedroDiez]

Hi @FrimanJan,

Just to have certainty about the Boxes. Is this understanding right?

L1 - Represents the Telco Operator
L2 - Represents the Aggregator
L3 - Represents the End App Developer

[FrimanJan]

Yes!

[bigludo7]

Hello, probably we need to have a discussion on this topic - @rartych what about having a discussion on this topic for a future commonalities meeting ? I think we need to set-up it to be sure to have the right attendees

I see the value of @FrimanJan / @Elisabeth-Mueller proposal but it has some impact on the subscription model that need to be identified (there as a side effect perhaps on the operate API)
cc: @Elisabeth-Mueller @FrimanJan @PedroDiez @patrice-conil

[rartych]

@bigludo7 thanks for bringing it up.
There is also #546 related to event type structure, that is important for CAMARA events.

[patrice-conil]

IMHO if the token is provided solely to authenticate the event sender, a two-party mTLS protocol will probably do the trick. Furthermore, mTLS is a very simple no-code (bug-free?) solution to deploy.

[patrice-conil]

Something else to consider, If we only want to perform callbacks via HTTPS, the requirement to use a non-self-signed certificate must also be met. In that case, nothing more needs to be deployed for mTLS.

[PedroDiez]

To compile comments on 26-NOV meeting from our side:

• We see this solution as an option.
• We see its applicability mainly to scenarios of long-life explicit subscriptions (not for implicit susbcriptions scenarios - QoD, Carrier Billing-, as events related to resource lifecycle usuarlly happens in few minutes so no need to add complexity for this kind of scenarios)
• This impose a requirement to API Consumer (Aggregator or App Developer) as it has to implement an Authorization Server

[bigludo7]

Hello @PedroDiez
When your wrote

We see this solution as an option.

you mean for the jwks uri proposal or for the mTLS one?

[PedroDiez]

Hello @PedroDiez When your wrote

We see this solution as an option.

you mean for the jwks uri proposal or for the mTLS one?

Hi Ludovic,
I mean the jwks uri proposal

[FrimanJan]

Updated sequence diagram

Aduna_Callback Authentication in CAMARA.pptx