ConsentFlowDescriptor extends ProfileInterceptorFlowDescriptor ?

[Tom Zeller]

On Wed, Sep 24, 2014 at 8:43 PM, Tom Zeller <tzeller at dragonacea.biz> wrote:
> 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.

Then, the profile interceptor flow descriptor and context would need
to move to profile-api to avoid dependencies on profile-impl, is that
what we want to do ? The interceptor result would need to be in -api
too it seems.