INACTIVE Subscription State - What is the Rational

[sachinvodafone]

While reviewing the CAMARA API design guidelines (https://github.com/camaraproject/Commonalities/blob/main/documentation/API-design-guidelines.md#subscription-status-value-table), I noticed we’ve defined an INACTIVE status for subscriptions. Initially, it seemed like a logical pause point—e.g., when a user revokes consent—but after deeper analysis, I couldn’t find a solid rationale to justify keeping it. Here’s why I propose we remove the INACTIVE state from our model or someone please share more thought/rational to keep it .

The INACTIVE state, meant as a temporary hold when consent is withdrawn, looks reasonable at first glance but doesn’t hold up under scrutiny, especially within the CAMARA context. Below are the key reasons to eliminate it:

1. GDPR Compliance Risks

Consent Withdrawal (Article 7(3)): GDPR mandates that data processing stop immediately when a user revokes consent. An INACTIVE subscription, retaining its workflow (e.g., device/subscription ID, webhook), keeps personal data linked to a rejected purpose. This conflicts with the requirement to cease processing—not just pause it.

Data Minimization (Article 5(1)(c)): Data must be “limited to what is necessary.” INACTIVE holds onto event filters, sink credentials, and more, despite the user’s “No” signaling no data should flow. Termination (e.g., DELETED) clears this out; INACTIVE retains it without a clear basis.

Right to Erasure (Article 17): If a user requests consent revooked (linking it with deletion process), an INACTIVE state complicates compliance. Why maintain a dormant resource when the user wants it erased/"consent revoked" means he/she doesn't want to follow by anyone ?

2. Operational Inefficiency

Backend Overhead: Managing INACTIVE subscriptions requires tracking timers (e.g., until EXPIRED), monitoring state changes, and storing idle workflows. This bloats databases and complicates logic, whereas termination (DELETED) is a single, clean action.

Two-Step Lifecycle: Shifting from ACTIVE → INACTIVE → EXPIRED/DELETED doubles the transitions. Consent revocation is a definitive stop—why pause first when we can end it outright?

3. Additional Considerations

Client Clarity: For clients like a bank tracking Device status, INACTIVE is confusing—should they wait or resubscribe? Ending it with a subscription-ends event is clear: 'It’s over; restart if consent comes back.'

No Reactivation Mechanism: Camara guideline doesn’t support reactivating INACTIVE subscriptions. Without this, it’s a dead-end state—termination makes more sense.

Privacy Alignment: Holding a subscription after consent is withdrawn assumes future consent, which isn’t guaranteed. A fresh subscription on re-consent respects the user’s current choice.

Looking for your valuable insight on this.

Regards
Sachin

[eric-murray]

I think there will be subscription APIs where it is more reasonable to put the subscription into an INACTIVE state (or TEMPORARILY UNAVAILABLE or SUSPENDED or whatever) rather than deleting it, or leaving it ACTIVE without telling the API consumer that they will not be receiving notifications for the time being.

However, transitions between ACTIVE and INACTIVE should themselves be signalled by a notification (in the same way as the subscription deletion is signalled). And the documentation should be updated so that the API consumer knows they just need to wait until it transitions back to ACTIVE (unless they explicitly delete the subscription themselves).

No subscription API implementation is forced to use the INACTIVE state, though possibly some specific subscription API definitions could remove it if the sub-project felt it should never be used.

[rartych]

However, transitions between ACTIVE and INACTIVE should themselves be signalled by a notification (in the same way as the subscription deletion is signalled). And the documentation should be updated so that the API consumer knows they just need to wait until it transitions back to ACTIVE (unless they explicitly delete the subscription themselves).

The notification of these transitions is proposed by @PedroDiez in #437

No subscription API implementation is forced to use the INACTIVE state, though possibly some specific subscription API definitions could remove it if the sub-project felt it should never be used.

Indeed current guidelines say: "Management of the Subscription State engine is not mandatory for now"

Should it be further clarified?

[eric-murray]

I think any subscription API using (or allowing) the INACTIVE state should clarify why it might be used and what it means for the API consumer. But I don't think the template code in Commonalities needs to be updated.

[PedroDiez]

I agree that we can keep INACTIVE status in the template. In that way I think the same

[PedroDiez]

Regarding the first point commented by @sachinvodafone, have managed to be addressed internally.
It is also related to "law" concepts and we need to address it carefully. Once have internal feedback we resume it.

[PedroDiez]

Hi,

After internal checking with our Privacy and Legal Team we have feedback regarding the first bullet point (GDPR Compliance Risks).

---

From the Privacy point of view, we have checked with our privacy and legal team that the solution for managing subscriptions with INACTIVE/ACTIVE status is GDPR compliant.

When the subject exercises their rights to opt out (or opt-in back) on a lawful basis, we keep auditing the lifecycle status of the subscriptions (including the inactive status), otherwise, we cannot demonstrate that the subject exercised their opposition (or their acceptance back).
The lawful basis that supports all the auditory is legal obligation to have this auditory tracked to demonstrate in case the authority requires.

---

Therefore that is the point to differentiate from removing the subscription, because the API subject has not indicated that action, but just exercising their rights