v3 consent to attribute release : model terms-of-use as attribute ?

[Tom Zeller]

On Tue, Sep 30, 2014 at 12:50 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 9/30/14, 1:42 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
>
>>
>>I don't think I necessarily suggested that, although it's not impossible
>>to do that. I was assuming we'd use a configured token of some sort that
>>would be mapped into the text through the MessageSource interface, much
>>like the error events. My thinking was that the token itself would be
>>thing we'd record rather than hashing the message, since that way the
>>token itself is your versioning tool and you can adjust wording and such
>>without worrying about invalidating decisions.
>
> So, roughly, say you have a webflow configured at e.g.,
> /profile/interceptor/tou. It requires that the InterceptorFlowDescriptor
> type be a subclass, TermsInterceptorFlowDescriptor, and the token I speak
> of above is a field you populate in the config into that descriptor object.
>
> Then the flow itself looks at the InterceptorContext to get the
> descriptor, tests and casts down to get the token, and maps that to the
> text with the MessageSource interface.
>
> That was my general idea. One flow, easy to configure as many times as
> desired using interceptors.xml or whatever we call it, just a couple of
> things to populate to get it working.
>
> Way back when, when I talked about TOU and consent being the same, I was
> really just saying I wanted to generalize the whole concept for config and
> storage, and the interceptor idea is the full generalization that goes
> beyond those two cases to anything that happens to fit. I wasn't thinking
> about attributes, really.

Okay, I guess it was me that thought about modeling TOU as an
attribute because then I thought I could basically re-use the entirety
of the consent flow I've got so far. But it seemed weird to define the
TOU text in attribute-resolver.xml.

Thanks for the token to MessageSource resolution idea.

Just typing out-loud here ... I've got an AttributeConsent class which
is the thing that is serialized for storage and for passing as a
request parameter, which I like because attribute-release and
per-attribute-release seem to only differ in whether there is a
checkbox-per-attribute or only one, so the infrastructure for
per-attribute-release feels like it will be in place. The only
difference there is a line or two in the view template.

I think I'd like to try to reuse the AttributeConsent class for TOU.
The fields are currently attributeId, valuesHash, expiration, and
isApproved, I guess if I generalize attributeId to id and valuesHash
to value, then that should fit TOU. The (attribute) consent flow has
an action that creates the AttributeConsent objects to be displayed to
the user, perhaps the TOU flow just needs a different action to create
the AttributeConsent object from the TOU MessageSource. If so,
AttributeConsent might be renamed Consent.

So I guess it's not modeling TOU as an IdPAttribute, but generalizing
the AttributeConsent naming a bit, that will enable a single abstract
flow for consent.