Handling Notifications for Expired Access Tokens in Sink Credentials

[dfischer-tech]

Problem description
...subscriptions.v0.subscription-ends notification should be sent, if

• the Access Token sinkCredential (optionally set by the requester) expiration time has been reached

If the requester optionally provides sinkCredentials (e.g., an access token), and the expiration time of the token is reached, it does not make sense to notify the secured client, as the token is already expired. How should we handle this scenario?

Alternative solution
A notification could be sent 30 seconds before the token expires. Would this approach work?

Additional context
This affects all new subscription APIs: like QoD, SimSwap, DeviceLocation and DeviceStatus

[rartych]

@bigludo7 It looks this should be clarified in API Design Guidelines section 12.2

[bigludo7]

We can add a note indicating that sending the notification once the token expired is useless but providing a hint/recommendation for the API provider to send this notification proactively before the expiration.
I can do it after #356 merge to not mix topic?

[jlurien]

In the case of explicit subscriptions, it makes sense to send such an event prior to the access token expiration, so it should be a clear guideline (implementation SHOULD send...). That would terminate the subscription.

More problematic is the situation with implicit subscriptions, as in QoD, where the events are used to notify changes during the life cycle of a session, which should not end due to the access token expiration. In such situations, the access token should be valid during the duration of the session in order to be useful or otherwise the client would stop receiving notifications.

[bigludo7]

For the second case (implicit subscription) as the developer will probably use the yaml we should probably document this in the yaml as a 'hint' and using specific vocabulary from the API (speaking session in Qod, Paymemt in Carrier billing), etc... WDYT?

[jlurien]

For the second case (implicit subscription) as the developer will probably use the yaml we should probably document this in the yaml as a 'hint' and using specific vocabulary from the API (speaking session in Qod, Paymemt in Carrier billing), etc... WDYT?

I agree, indeed, that is what I proposed in the issue opened in QoD: camaraproject/QualityOnDemand#385 (comment)