Privacy API for auth plugins

Privacy API for auth plugins

by Mike Churchward -
Number of replies: 6
Picture of Core developers Picture of Plugin developers Picture of Testers

I'm adding the privacy API to an auth plugin. The plugin stores some information per user about their login, so it needs to report, export and delete this data. I used the Oauth2 core plugin as an example.

I'm a bit confused as to what contexts I need to report and care about. The Oauth2 code seems to only care about the user context. It makes sense to care about this, since any request for a user that has a record in the auth table would be if concern. But shouldn't the system context also be dealt with? Wouldn't the auth plugin be associated with the system context as well?

Thanks.

Average of ratings: -
In reply to Mike Churchward

Re: Privacy API for auth plugins

by sam marshall -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

Hi Mike,

My understanding is that you should list all the contexts where you store data about the user (which might then need to be exported or deleted). If you are not storing any data about the user in a particular type of context then you don't need to list it.

For example, a module plugin probably stores data in the module context, but it might also store course-wide data of some kind, in which case it should really return both the module and the course context. It doesn't need to return the system context unless it also stores system-wide data somehow. (Other than user preferences or another API which is handled elsewhere, I mean.)

In the case where your auth plugin stores data globally about a user, I guess you can choose between whether you consider that to be in the user context or in the system context, not certain which is correct, but probably not both... You should probably only return two contexts if you are going to supply (export/delete) different data associated with each context.

Just my opinion, could be wrong smile

--sam

In reply to sam marshall

Re: Privacy API for auth plugins

by Mike Churchward -
Picture of Core developers Picture of Plugin developers Picture of Testers

Thanks Sam.

I think my question is the same as your answer. I don't know whether an auth plugin should consider the data part of the system context or not. I think it depends on what the requests are that come from Moodle?

API functions:

  • get_contexts_for_userid - This has the description in the docs as "to explain where data is held within Moodle for your plugin". So, a userid is provided to the function, and the plugin should return the list of contexts the plugin has data stored within. Wouldn't this be the system context for an auth plugin?
  • get_users_in_context - This has the description, "get the list of users who have data within a context". I'm guessing that I should care about the user context, but if the system context is requested as part of the userlist, shouldn't I also care about that?
  • ...
This is where I am confused.
In reply to Mike Churchward

Re: Privacy API for auth plugins

by sam marshall -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

User contexts are a bit weird. I've thought about this a bit more...

Often, a user context is used when you store data about another [different] user. (For example, a parent has a role within their kid's user context. Or if a teacher/administrator leaves notes about a student.)

If the data is about yourself, and really applies to the whole system, I would say it is normally in system context. In this case, if the data is about how you log in, I think that is more related to the whole system than it is about you. In other words, the data is about how You log into System. It's not about how You log into You. (Subject vs object.)

To put it another way, I think as a guideline it is usually appropriate to use user context only if you could potentially have data in multiple user contexts. This is true of the two examples I gave above (a parent with two kids could have roles within Kid A's context and Kid B's context; a member of staff could leave notes on Kid A and Kid B, and maybe also on their own user context too) but it's not true if you are just storing data for one user about their system access. That data would never go in a different user context so I think it's really system data.

So I'd be tempted to use system context here (and not user context), consistently for both functions.

It would be good to get an answer from a privacy API expert though because it's definitely possible that the privacy API implementations made a different distinction than mine...

--sam
In reply to sam marshall

Re: Privacy API for auth plugins

by Mike Churchward -
Picture of Core developers Picture of Plugin developers Picture of Testers

Your thinking matches mine. That's why I felt that an auth plugin should (only) care about the system context.

I used the two core auth plugins that provided privacy data, "oauth2" and "mnet", as my examples though. Both of them are only looking at the user context, which I think is wrong. But I also may be misinterpreting how this works.

In reply to Mike Churchward

Re: Privacy API for auth plugins

by Mike Churchward -
Picture of Core developers Picture of Plugin developers Picture of Testers

In a related problem, I have tried using the privacy API test scripts (https://docs.moodle.org/dev/Privacy_API/Utilities) on both the plugin I'm working on and the Oauth2 plugin, but I can't seem to cause the auth data to be exported. What am I missing?

In reply to Mike Churchward

Re: Privacy API for auth plugins

by Mike Churchward -
Picture of Core developers Picture of Plugin developers Picture of Testers

This one can ignored. I figured out how to get the data exported correctly.