storing "data transparency" in consent records

[Peter Schober]

More text with little dev content, sorry. Maybe user would have been a
better choice for this:

* Peter Schober <peter.schober at univie.ac.at> [2018-05-25 07:18]:
> Are there any plans to provide a UI within the IDP to manage (i.e.,
> display and optionally revoke) previously created and still active
> consent records in whatever storage service is active? E.g.:

Why is that important to me now: I'm currently working on a clone of
the attribute-release intercept, for "informational / transparency"
purposes (i.e., it looks like consent but isn't, as the legal basis is
not the individual's consent. The subject is merely informed about
what's going on. Plus the fact that you could chose not to click "ok"
to continue provides an added failsafe the EU data protection
authorities call "unconditional opt-out" which may be part of what
makes global use of R&S legal, at least for EU/EEA-based institutions.)
The reason for that clone is to:
* use separate velocity templates for "inform" vs. attribute-release*;
* easily trigger "attribute-release" vs. "inform"
  postAuthenticationFlows in the relying party configuration.
  E.g. R&S and CoCo SPs get "inform" (RelyingPartyByTag), locally
  managed SPs may not get any intercept (RelyingPartyByGroup), and
  everything else gets the "attribute-release" intercept via the
  (unmodified) DefaultRelyingParty.

Now, using the attribute-release intercept (or a clone thereof) for
informational purposes is simple and adds the desired "memory" so that
people don't get "informed" on every single access to the same SP.

But if the IDP introduced a management UI for consent storage records
(think oauth grant revocation UIs) it would be undesirable to also
show those "consent records" that were the result of clicking "ok" on
my "inform" intercept flow -- it makes no sense to "revoke" the fact
that you have been informed and said "Thanks, I don't need to be
informed about this SP again in the future".

So it's with these thoughts that I'm pondering how best to treat these
two intercepts *right* *now* (with GDPR coming into effect today):
* Use RDBMS storage for consent and localStorage for inform?
  (But then if you have RDBMS storage to make consent Just Work across
  devices why bother with device-specific localStorage for the
  "inform" nag screens?)
* Use separate RDBMS tables for consent vs. inform (somehow)?
* Don't bother about this and let people "revoke" "consent", explaining
  in The Fine Local Documentation that this also covers "re-activating
  those friendly information screens" for R&S and CoCo services?

Any comments?
-peter