ConsentFlowDescriptor extends ProfileInterceptorFlowDescriptor ?

[Tom Zeller]

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.