storing "data transparency" in consent records

[Peter Schober]

* Rod Widdowson <rdw at steadingsoftware.com> [2018-05-25 11:21]:
> > 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?
> 
> I'm taking this as read that this cannot be pushed back to the IDM?
> It seems to fit the "admin-writes, user-reads" paradigm...

Not sure I understand: How am I going to push the "this" you're
suggestiong to push back to the IDM if it's data the IDP's storage
service has put into the subject's HTML5 localStorage?
Please see my other mail "manage (view, revoke) consent in IDP" about
that, unless I'm mistaken.

The above was about either using only the "attribute-release"
intercept and adapting it dynamically to the "inform" vs. "consent"
use-cases (i.e., only one intercept at play, hence one storage
option), or cloning the attribute-release intercept into an "inform"
intercept (which is what I have done for now).  Either way, both mode
would use the same idp.consent.StorageService and so records would be
lumped together.
In that context I was wondering about consequences and alternatives.

I guess I could create a copy of the
shibboleth.consent.AttributeReleaseFlow bean I see in
system/conf/profile-intercept-system.xml and adapt that to an "inform"
flow, with a separate storage service configuration.

Now whether that effort is justified is an open question and relates
to the other question I've asked about potential (later) managing of
those consent records in a web UI -- if such a web UI was on the table
maybe I should make the effort to avoid lumping "inform" and "consent"
records in to the same storage.

-peter