Handling failures and auth in Personal Data Reporting API implementation

Jira Development Jira Cloud
,
1

Hello!

I’m a bit confused on authorization and error handling for implementations of the Personal Data Reporting API. If a system failure on my end occurs in an implementation and the system fails to send Atlassian an updated list of users within the cycle period, what happens?

In addition, the OAuth2 (3LO) spec for this API doesn’t mention authorization outside of OAuth2 (and a Connect App which I’m not using), but suggests that 90 users can be sent in a single request. Surely a request in the context of one Atlassian user authorized via OAuth2 should not be sending data on behalf of other users. Is there a way to use this API for users that auth via OAuth2 but from a global context?

In other words, If I develop an app that allows users to authorize themselves via OAuth2 and need to implement the Personal Data Reporting API, can I use a process outside of any Atlassian user context to collect all of the Atlassian users that are using my product and send the list in bulk to the API? And if so, how do I authorize the request and what happens if the system fails to report data within the cycle period?

Thanks!

2

Hi @AndrewViteri ,

Welcome to the Atlassian developer community.

If a system failure on my end occurs in an implementation and the system fails to send Atlassian an updated list of users within the cycle period, what happens?

The Atlassian side will treat the app as having not complied with the personal data reporting requirements if app errors prevent it from being able to send requests at the required rate. If the Atlassian side detects that apps are not complying then it may record an issue and Atlassian may reach out to request the issue is rectified, but partners are primarily responsible for ensuring their apps comply with the personal data reporting requirements.

Surely a request in the context of one Atlassian user authorized via OAuth2 should not be sending data on behalf of other users.

The Atlassian OAuth2 (3LO) solution does not support sending 2LO requests which is why OAuth2 apps need to make the call to the user reporting API by picking any user that has gone through the grant flow. The reporting API implementation doesn’t do anything that acts as the user that the request was made on behalf of and the request can include accounts for other users that the app needs to report for.

Regards,
Dugald

3

Hi @dmorrow thanks for your reply! That clears up everything on the failure side of things. I have a follow up question regarding auth:

and the request can include accounts for other users that the app needs to report for.

Is the above a requirement? In other words, does the implementation have to use the same user to report accounts every time? Does it need to always use a single user and report in bulk? Or can an individual request be made on behalf of each user? For example: 10 users grant authorization, for each user, a request is made on behalf of said user only reporting the account ID of said user. Is that an acceptable use case of the API?

4

Hi @AndrewViteri ,

Thanks for the additional questions.

Here are some responses based on my understanding of how the API works and the obligations of apps, but note that I have raised an internal issue, ONECLOUD-2335: As an app developer, I need a detailed understanding of business rules relevant to the personal data reporting API in order to ensure my app is compliant, to update the User privacy guide for app developers updated with more formal guidance.

Is the above a requirement? In other words, does the implementation have to use the same user to report accounts every time?

No, it’s not a requirement that a single account is chosen for reporting on all other accounts.

Does it need to always use a single user and report in bulk? For example: 10 users grant authorization, for each user, a request is made on behalf of said user only reporting the account ID of said user. Is that an acceptable use case of the API?

No, an app can choose any pattern for reporting PD usage. For instance, an app can cycle through all it’s account storage records and report separately. The app can choose to make the call as the user being reported or it can choose to make the call on behalf of another user such as one that the app knows has a valid OAuth grant/consent in place.

And here’s another couple of questions that stem from the previous question:

How do I handle a 401 Unauthorized response from the user privacy API?

If a 401 Unauthorized response occurred after making an OAuth 2.0 based API call, then it could be because the user being impersonated has revoked their grant. If this occurs, the app has two choices;- (a) delete the personal data it is recording for the account that the OAuth call was made on behalf of, or (B) try to make the call on behalf of a different account ID and ensure you include the account ID that the first call was made on behalf of, but note that this request could also fail so the app would most likely need to limit the amount of retries.

How do I handle repeated error responses from the user privacy API?

Your app should track when accounts were last successfully reported. If it receives errors that are believed to be Atlassian’s fault, report the issue ASAP. If the app has been unable to successfully report account usage for more than the required reporting period, the app should take remedial action which would probably involve deleting the relevant personal data.

Hopefully this provides clarification and as mentioned above, the User privacy guide for app developers will updated with more formal answers when ONECLOUD-2335 is addressed.

Regards,
Dugald

5

Fantastic. Really appreciate your help @dmorrow!

1 Like