Deauthorization compliance in a shared-data scenario

[kibo]

Hi, we have questions related to deauthorization compliance.

Our app provides enhanced management tools and analytics for organizations that host events on Zoom. We hope that our app will help event organizers continue to host their events on Zoom, rather than migrating to a competing, all-in-one events platform.

The app is designed to be used by multiple people within an organization, using that organization’s Zoom account. As individuals within an org host events (consisting of Zoom meetings and/or webinars), we collect and analyze data from the associated Zoom meetings, making the data and insights available to other app users within the organization.

We’re wondering how to handle situations where an individual user within an org deauthorizes our app, while other users in the org continue to use the app.

To illustrate our question, imagine a scenario where there are three users of our application within the same organization. All have authorized and installed the app. The first user, Alice, is the organization’s Director of Events. The other two users, Bob and Charlie, work for Alice.

Alice, Bob and Charlie all host events for the organization, and they want to share analytics on their events with each other. Our app enables this. Alice, for example, can see detailed analytics for Bob and Charlie’s events. Our app provides the analytics using data stored in our database, obtained during the hosted events via the Zoom webhook and REST apis.

Now suppose that Bob leaves his role and decides to deauthorize our app, but the organization continues to use our app. If we are meant to subsequently delete all Bob’s data associated with his usage of our app, that would mean that Alice could no longer see analytics for the events that Bob hosted.

If the organization at large decides to deauthorize our app, it is clear to us that we should then delete all data associated with the organization’s usage of our app. Our questions lie one level deeper - when individuals within an org deauth our app, but the org wishes to continue using our app to analyze past events hosted by the individual who has deauthorized.

Perhaps an approach like this could be sensible:

If there’s only one user of our app within an organization, and that user deauths our app, we delete all associated data.
If there are multiple users of our app within an organization, and one of the users deauths our app, we confirm with our point of contact within the organization whether we should delete that user’s data.

We’re really excited about launching in the marketplace, and we hope to find a sensible approach together.

Thank you!

[will.zoom (Will)]

Hi @kibo,

Thanks for reaching out about this and for laying out your use case. Happy to help!

One basic question before I provide further guidance—can you confirm that you’re using an OAuth App to authorize your integration? And if so, can you confirm whether this is a user-level or account-level OAuth App that’s being authorized in the scenario you’ve outlined here?

Thanks!
Will

[kibo]

Hi Will, thanks for taking this up. Our app is indeed an OAuth app.

We’re currently developing it as a user-level app, primarily so that our expected customers can install the app and start seeing value quickly, without the need to coordinate with their Zoom admin. We’re open to input on this point, and we’d be pleased to hear your analysis of the options with respect to our goals.

Thank you!

[will.zoom (Will)]

Hi @kibo,

Thanks for confirming!

Given your use case:

We’re wondering how to handle situations where an individual user within an org deauthorizes our app, while other users in the org continue to use the app.

A user level app would likely be the best option here. A user level app will allow any member, individually, to authorize your integration. One member under an account could authorize your integration, while another member under the account may not.

If an individual user deauthorizes your app, it is expected that any Zoom data associated with that user would be removed as well (meeting IDs, meeting history, etc.).

Alternatively, if you use an account-level app, this would be authorized by an administrator on the account, on behalf of all users on the account. While you’d have access to account-wide data within the app’s scopes, if the admin deauthorizes the integration, you’d be expected to remove all data associated with the account’s users in whole. This is why I might recommend the user-level app.

Let me know if these details help!
Will

[kibo]

Hi Will thanks for the clear info. Alas, this leaves us in a bit of a bind.

A user-level app’s deauthorization requirements lead to scenarios that cut against the goals of the application.

Imagine the scenario outlined in my example - Alice is Bob’s boss and wants to see analytics for Bob’s events, even after Bob changes roles or leaves the company. With a user-level app, if Bob leaves and deauthorizes, we then have to delete data about Bob’s events, and Alice then loses visibility into Bob’s past events.

It’s perhaps worse if Alice and Bob co-host an event, with Alice hosting some meetings and Bob hosting others. After Bob deauthorizes, Alice would only see the meetings that she hosted. Bob’s meetings will have disappeared from Alice’s view of the event.

It seems as though (and perhaps you can confirm) that an account-level app would solve this problem. Since the app is installed once for all users on an account, there’s no user-level deauthorization to consider, therefore there’s no user-level data deletion requirements. Correct?

But if we indeed went with account-level, it would introduce friction in our onboarding process. Rather than an interested user quickly firing up our app, they would have to go through their Zoom admin, possibly to through procurement, IT review, etc. and explain the need and our app to everyone, and so on.

A couple questions:

1. Do you see any path to publishing a user-level app that permits us to conditionally delete the data of a user who has deauthorized - for example based on coordinating with the account regarding whether they’d like the data deleted?

2. Another possible solution is to start customers on a user-level version of our app for quick, easy onboarding, then later migrate them to account-level, preserving the data they own in their user-level apps. If we build a migration utility to do this, and if we obtain customer permission to do this in a way that Zoom finds acceptable, is this a viable option?

Thank you very much!

[will.zoom (Will)]

Hi @kibo,

Thanks for the reply, and you do have a good understanding. Regarding:

It seems as though (and perhaps you can confirm) that an account-level app would solve this problem. Since the app is installed once for all users on an account, there’s no user-level deauthorization to consider, therefore there’s no user-level data deletion requirements. Correct?

That’s right.

As for:

1. Do you see any path to publishing a user-level app that permits us to conditionally delete the data of a user who has deauthorized - for example based on coordinating with the account regarding whether they’d like the data deleted?

Unfortunately not, I would recommend an account level app.

1. Another possible solution is to start customers on a user-level version of our app for quick, easy onboarding, then later migrate them to account-level, preserving the data they own in their user-level apps. If we build a migration utility to do this, and if we obtain customer permission to do this in a way that Zoom finds acceptable, is this a viable option?

While I can appreciate the use case, it’s not possible to migrate users. They would need to separately authorize an account level app (or have an admin/owner authorize if they don’t have the necessary permissions).

Thanks,
Will

[kibo]

Thanks very much for clarifying, Will.

I’ve been looking at the uninstallation process for other apps. I noticed that after navigating to my installed apps within Zoom, and clicking the “Uninstall” button for a user-level app, Zoom then presents this dialog:

This strongly suggests that deauthorization need not automatically trigger deletion of a user’s data, and that data deletion can instead be a separate step, prompted by an explicit user request to delete their data.

Is that indeed the case, or is there something else going on here?

Thank you!

[will.zoom (Will)]

Hi @kibo,

That’s correct—it will be up to the app developer to handle this. In the past we required the app developer to receive our deauthorization webhook and then send a request to our [now deprecated] compliance API to confirm they’d handled it.

Now however, it’s up to you to honor users’ requests. As a best practice, we generally recommend removing any user data associated with the app regardless, upon deauth.

Let me know if it helps,
Will

[kibo]

Great, thanks. That is clarifying. Think this covers all our questions - thank you!

[will.zoom (Will)]

Glad I could help