Does Personal Data Reporting API need to be implemented for Auth provider supporting Atlassian oauth sign-in?

Hello,

Our product is an auth provider which supports multiple oauth vendors.

We would like to add sign-in / connect with Atlassian oauth 2 to our solution.

We will be storing the information returned from the https://api.atlassian.com/me endpoint in order to populate a user profile when they first sign up.

This includes accountId, name, email, nickname and their avatar.

The customers will be providing their own Atlassian keys to connect their app to our platform, but we also offer a shared account with our own credentials for testing (i.e. this is a shared Atlassian app owned by us as a platform).

Do we need to implement Personal Data Reporting API as a platform, or is this responsibility transferred to the Atlassian app owners who will be entering their oauth credentials on our platform?

Also what is the usage of the PDR API?

By posting accountIds there should the responsible party proceed with data deletion if the account has since been deactivated?

How is the response from the PDR API supposed to be utilized?

Thank you in advance,

Mark

Hey @MarkPitsilos,

I can offer my 2c here, but please note that I am not a lawyer and my interpretation does not represent legal advice or an official policy stance from Atlassian.

The personal data reporting API was built to support compliance with GDPR legislation (and emerging data privacy legislation in other jurisdictions) for apps that run on top of Atlassian’s products. The personal data reporting API allows Atlassian to offer our customers a streamlined process for actioning “right to be forgotten” requests for Atlassian accounts that may also have data stored by third parties through the usage of these apps. Without this, an Atlassian customer would need to issue a separate “right to be forgotten” request to Atlassian and every single provider of every single app they may have used across every single Atlassian site they ever logged in to. We did not view this as an acceptable user experience.

The idea that sits underneath this is that for a typical Atlassian app, if the user chooses to exercise their right to erasure for Atlassian products, they would no longer use Atlassian products and therefore also no longer use the apps, so the data can be safely erased.

The situation sounds a bit more complex for you since it seems like even if a user stops using Atlassian products, they may still want to retain usage of the product you are building the integration for?

Do we need to implement Personal Data Reporting API as a platform, or is this responsibility transferred to the Atlassian app owners who will be entering their OAuth credentials on our platform?

I believe the onus is still on you to handle the user’s personal data appropriately, regardless of who is configuring the connection.

Also what is the usage of the PDR API?

Atlassian will funnel accurate data into the API for you to action based on your requests. We also use information from the API to periodically identify apps which may not be in compliance with their obligations.

By posting accountIds there should the responsible party proceed with data deletion if the account has since been deactivated?

Yes, even if the account has been de-activated, you are still responsible for ensuring that you are no longer storing any of the user’s personal information.

How is the response from the PDR API supposed to be utilized?

The response should include information about which user accounts require action on your part to delete or update. Does that answer your question?

You should be confident that whatever course of action you take complies with your privacy policy/data policy. Presumably there would be a privacy policy or specific terms that explain to the user what will happen if they use the ‘sign-in with Atlassian OAuth 2’ option? Within Atlassian, we typically would involve a legal counsel or privacy expert in helping us understand the requirements for a feature like this and ensuring the legal terms are updated.

Depending on the stance you take with regards to your privacy policy, you might:

  1. Go ahead with deleting your paired account if the Atlassian account has been deleted… or;
  2. Scrub personal data synced from Atlassian from the paired account, but keep it active and accessible to the user… or;
  3. Disassociate the paired account from the deleted account, but retain the personal information in your systems so that the user’s experience in your product is unchanged.

Either way, I think that you will need to integrate with the Atlassian personal data reporting APIs unless you have specific legal guidance that says its un-necessary.

Hope this helps! Cloud data privacy is a complex and tricky topic, and I certainly don’t consider myself an expert.

Joe

1 Like