v3 consent to attribute release : half-thoughts on UIs

[Cantor, Scott]

On 9/17/14, 2:35 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>
>I believe the latest GakuNin fork of uApprove, and maybe PrivacyLens,
>include a UI for managing a user's consent. The management page, at a
>minimum, would display one or more relying parties and the attributes
>(and values) that have either been approved or declined by the user
>for release.

Another way to think about it is that each record is just a "record of
post-authn decision", the specific meaning of which varies by flow and
that flow would provide plugins to handle things like displaying the
record on this page.

Alternatively, the management page could just lead to specific subflows
that are the "management" flow for a given record, and then the UI and
such for managing/altering the data becomes pluggable by each flow.

>Regardless of the UI however, I'm wondering how to parse the request
>parameters which represent the user's input. My half-thought is that
>the request parameter values would be the JSON serialization of a Java
>consent object, same as we would store as the value of a storage
>record in the StorageService. Does that make sense ?

Possibly, though the second alternative above makes it moot because you
don't need to actually code any logic that's altering results, you leave
it to each subflow.

>I've done a little sketching of what the Java consent object would
>look like, here is what I've got so far, obviously the fields should
>not be public :

What does the object here model? A decision? Or something to do with the
logic of the subflow?

>and the fields of a default impl would look like the current uApprove
>AttributeReleaseConsent object or PrivacyLens' AttributeReleaseChoice:

So this is really the object that's modeling a decision outcome?

My feeling is that we want to avoid making that public at all, provide an
example in what we're implementing, and then we can copy or evolve that
later, including making it public.

I think we'll waste too much time trying to get it "right" now, and we
won't get it right.

>In the Consent object I sketched out, I included several activation
>condition Predicates : ProfileRequestContext, RelyingPartyContext,
>IdPAttribute, and IdPAttributeValue. The are somewhat redundant, since
>the profile context contains the other contexts, but I thought it
>would be easier for deployers to customize by avoiding the need to
>navigate the context tree, not a big deal.

It mattters though, because if you have to build predicates with different
inputs, you end up needing a lot more code, and potentially more code
provided by deployers.

>Just some thoughts, feedback on the Consent class sketched above is
>appreciated.

I need some help understanding its role, and whether it's meant to be
public or not.

-- Scott