v3 consent to attribute release : half-thoughts on UIs

[Tom Zeller]

On Wed, Sep 17, 2014 at 4:50 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 9/17/14, 3:09 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>>
>>Probably the UI, but I'd like the flow to be able to support it, so
>>that the UI can be figured out later, and be customizable by
>>deployers.
>
> I think we should not spend the time to get that right, because the chance
> of it working will be low, and there's no need if people can just copy/add
> to a new flow from the old one. The flows are just implementation, so they
> don't need to be frameworks themselves.
>
>>Mostly I'm hoping to get the serialization of consent "right", so that
>>it can be stored client-side, maybe passed as request parameters, and
>>extensible.
>
> I think the key to that is making it opaque to all surrounding code.
> That's why I don't think the management page should actually manipulate
> the data, only get enough from the storage format to be able to list the
> results and link to the flows that know how to actually process it.
>
> So maybe each flow's result should be a JSON object with some common base
> structure/fields and the rest will be flow-specific.

So that basically answers my question, which I didn't really ask,
which was : should we abstract the consent storage record ? And the
answer is, no, that is specific to the flow.

The prompt for this thread was wondering how to provide
per-attribute-value consent, ignoring the UI for now. The fields of
the current merged uApprove/PrivacyLens/GakuNin objects representing a
users's consent are :

 String attributeId (which might be a wildcard "*")
 String valuesHash (hash over all attribute values)
 DateTime expiration
 boolean isApproved

and for per-attribute-value consent, we probably just need

 String[] valueHashes (hashes of each attribute value)

But maybe per-attribute-consent is a separate flow, rather than a
configuration toggle.