ConsentFlowDescriptor extends ProfileInterceptorFlowDescriptor ?

[Tom Zeller]

On Wed, Sep 24, 2014 at 8:37 PM, Tom Zeller <tzeller at dragonacea.biz> wrote:
> On Wed, Sep 24, 2014 at 3:45 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>> On 9/24/14, 4:40 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>>>
>>>Were you thinking that the ConsentFlowDescriptor, which holds the
>>>configuration toggles for consent, would be a subclass of
>>>ProfileInterceptorFlowDescriptor ?
>>
>> Makes sense that it would. Same thing happened with c14n, I started with a
>> basic class and added NameIDCanonicalizationFlowDescriptor for the SAML
>> case afterward.
>
> Okay, hadn't see that one.
>
> I'm assuming that consent actions will be operating on a
> ConsentContext, so there will be an AbstractConsentAction. Should it
> extend AbstractProfileAction or AbstractProfileInterceptorAction ? My
> first thought was AbstractProfileInterceptorAction, but that seems too
> deep. And, the ConsentContext should hang off the PRC, not the
> ProfileInterceptorContext, right ? Or is that weird.
>
> We talked about a ProfileInterceptorResult, which I assume would be a
> field of the ProfileInterceptorContext, which a, say,
> WriteProfileInterceptorResultToStorage action would write to a storage
> service at the end of an interceptor flow. I guess a consent action
> could locate the ProfileInterceptorContext via a lookup strategy
> function and then get access to the interceptor result.

Oh, and I'm assuming that the ConsentFlowDescriptor would be a field
of the ConsentContext. So, if the flow descriptors have a parent-child
relationship, it seems the context and abstract action would as well,
I guess for symmetry. But, it seems we generally hang contexts off the
top level PRC unless some need arises.