I would prefer to have the consent stuff go directly into the database, so skip the self._consentdata dict.
This would allow you to do more direct queries against the backend that include the provider-key, so that we don't need to cache everything.

Also, you can just store json.dumps()'d data, and then you don't have to do manual splitting.

Note that for OIDC, we need both the claims, and the requested scopes, to be part of the consent framework.
This because the scopes are just as important (if not more so given that claims are based on requested scopes most of the time) than claims.

Is there any reason you're not using save_options?

The old semantics of save_options were that we passed it a bundle of options. Any options that weren't in the DB were added to the DB, any options that were in a DB with a different value were changed in the DB, and any options that were in the DB but not in the bundle were left alone.

The previous version of this PR maintained a copy of the consent data in a dict, which was synchronised with the DB using save_options. The first patch in this PR (which is the same as the original version of the PR) changes the save_options semantics to remove options in the DB that aren't in the options passed to it. Without that, we could never delete any consent from the DB.

I'll drop the save_options semantics patch, switch this to using save_options, and delete_consent to using delete_options.

I think it would be useful to run this through the respective provider modules, so that they can make the consent information user readable.
I think it's depending on the module how best to summarize the contents of the consent. (for example, see the display_name for custom scopes in OpenIDC, and the default OIDC scopes should probably not be shown due to the fact that they're just the internal way to ask for claims).

Yep, I had a similar thought.

Still needs tests adding, and we need to decide what to do about the save_options stuff.

Left over debugging? :)

Remaining debugging output? :)

This comment is not exactly what the function does.

One last remark about a comment, and then it looks good to me.
Thanks!

Commit 05a6a4e3 fixes this pull-request

Thank you very much!