v3 consent to attribute release : half-thoughts on UIs

[Tom Zeller]

On Thu, Sep 18, 2014 at 10:26 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 9/18/14, 11:22 AM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>>
>>The class yes, public, the fields, of course, no, private. While
>>sketching, I skipped accessor methods.
>
> Yes, I just meant the class. Like I said, I would suggest we avoid making
> anything public when it comes to the implementation of the flows, but we
> might want to (now or later) have a base class or interface that has
> sufficient common fields across all "decision" objects so that there's
> commonality and fields in the serialized JSON that can be read and
> understood by a management page, but only enough to dispatch the result to
> another subflow to actually parse/report/manipulate.

If the storage record context is the flow ID, that seems enough to
make a decision regarding how to dispatch, correct ?

I know we said that the flow descriptor would have a function to
determine the storage key, but I'm wondering if that makes sense for
the case of a key like "<user_id>:*" where the "*" means all relying
parties. My thinking is, that if we support per-attribute-value
consent, then a user might want to allow an attribute+value for all
relying parties, like a public email address, and not be annoyed by
being prompted for every SP, if there were lots of them. So, should
the storage record key be just the user identifier ? If consent
decisions for all relying parties are stored in one value, that might
make limiting storage size easier, not sure.