I’m working on a OAuth2 (3LO) app for jira. We don’t save any user data except ther accountId of the user along with refresh token & access token.
In my console the below is said under “Distribution => Personal data declaration”
Select “Yes” if you copy and store personal data associated with user references (e.g. AccountID) in your own systems or if you cache data for longer than 24 hours.
Since I store AccountID does it mean that I have to choose “Yes” even though I don’t store anything else?
Following answer is incorrect and has been superceded by: Do I have to implement Personal Data Reporting in my OAuth2 app? - #9 by ibuchanan
Yes. I confirm your interpretation of the privacy policy. You should choose “yes” because Atlassian considers the Account ID to be personal data. When I last consulted our privacy team, refresh and access tokens alone are not considered personal data.
This seems to be a change in policy? Has that been communicated?
@remie, which part is the change? Account IDs? Is there a doc where they were communicated as something other than personal data?
If you look back at all the GDPR threads, the gist is: remove personal data and replace it with account ID and you’re good.
It’s PII for Atlassian because you store it alongside other information. If I’m only storing the account ID, then there has to be a breach in both systems to identify the user. And if Atlassian deletes the account, then my copy of the account ID is meaningless.
Thanks for clarifying and I see your point clearly now. I will discuss with our privacy team to see if I’m missing some important context, or if we have changed policy and should make a policy notification.
What I don’t understand is how AccountID is considered personal data and the access token that contains AccountID in sub claim is not considered as personal data…?
I reverse my previous answer. After reconsulting with our privacy team, you should choose “no”. Consistent with prior posts from Atlassians during GDPR roll-out, Atlassian does not consider the Account ID alone to be personal data.
For your benefit and that of concern parties like @remie and @james.dellow, my prior answer was the result of a procedural problem that we have resolved internally. Thanks to your engagement here, we are keeping established policy.
“If I’m only storing the account ID, then there has to be a breach in both systems to identify the user” → Is this true? I believe there is no need to be a breach in both systems…
If your connect app has the READ scope, anyone with access to the sharedSecret key could generate a token to get the name or email of a user associated with a user account id: “/rest/api/3/user?accountId=”
If the account id isn’t personal data, then I think most of the identifiers shouldn’t be considered personal data when stored alone…
This is indeed true. So the combination of accountId, sharedSecret and instance base URL in which the app is installed together create PII, to the extend that anyone that has access to all three data points and the app is installed and has access can use this information to retrieve account information (and other sensitive data).
As such, it is imperative that you make sure that these three options are not stored together and require additional effort to retrieve them.
It would be even better if Atlassian would allow us to rotate sharedSecret, but I think they will be moving to OAuth with rotated refresh tokens instead.
Please note that due to Atlassian action, it is highly recommended to consider the Atlassian accountId to be PII within the context of GDPR.
Any attacker that has retrieved access to an Atlassian account ID can publicly access that user PII if the user has ever interacted with MPAC. For instance, you can find my name here: Remie Bolte - Profile | Atlassian Marketplace
You can use https://marketplace.atlassian.com/users/<accountId> to retrieve the PII of other users if you wish.
In addition, the Atlassian account ID is a global identifier: you can track users through instances. If a user is added to multiple instances their identifier will remain the same. This might mean that the ePrivacy Directive (EU cookie law) is also applicable.
You might not need to use the Atlassian reporting API, but it is very very very much recommended to consult with a lawyer and get yourself a proper EULA, privacy policy & DPA if you are planning to store the Atlassian Account ID.
Hello,
are resourceId and resourceName also personal data? Should I implement Personal Data Reporting if I store those two information in a database?
Thank you.