v3 consent to attribute release : half-thoughts on UIs

[Cantor, Scott]

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.

-- Scott