storing "data transparency" in consent records

[Cantor, Scott]

> 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".

I'm not sure I would say that's an obvious answer. I think it makes a lot of sense to treat them both as consent.

I'm not actually sure I get the difference. How are "inform" and "consent" different? By default, consent is not per-attribute, and you don't get control. You're just informed. You either approve or not. I don't yet follow how that's different than what you're suggesting you want to do.

> * 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?)

For sure.

> * 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 just not getting the distinction. As long as you can tailor the text to suit your needs, which you can certainly do brute force and we could obviously make more clean if need be, how are these actually different models? If you're displaying the attribute data at all, that's just consent as the IdP thinks of it.

-- Scott