v3 consent to attribute release : half-thoughts on UIs

[Tom Zeller]

On Thu, Sep 18, 2014 at 10:36 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 9/18/14, 11:32 AM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>>
>>If the storage record context is the flow ID, that seems enough to
>>make a decision regarding how to dispatch, correct ?
>
> I think so, yes. Or maybe the class type of the object to deserialize the
> reslt into, but it just depends on the code. But the flow ID is paramount.
>
>>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.
>
> I see what you mean, but I wonder if those are special cases that could be
> handled within the flow itself. Like maybe they know to look for special
> keys that have flow-specific meaning.
>
>> 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.
>
> Maybe, but I would tend to think that bloats the individual records such
> that in the case of a regular database design, you'd be pulling back and
> parsing a lot of extra data. That doesn't matter as much in the client
> case since it's all being loaded anyway.

Oh right, a fat/concatentated value record does not make sense server-side.