v3 consent to attribute release : idp-attribute-consent-* modules ?

[Tom Zeller]

> As far as the context, you may be able to
> just use the AttributeContext directly. Seems like any use of consent for
> attributes ought to have an AttributeContext involved to start with, and
> you would have to edit that context afterward anyway.

Sure. The newer GakuNin flow has an "are you sure" page which made me
think we'd need to store the attributes-consented-to in addition to
the eventually-released attributes, but not a big deal.

>>I guess my question boils down to ... is "attribute consent" the right
>>term to be using as a prefix for classes or package names or modules
>>(if we need them) for stuff common to attribute-release and
>>terms-of-use ? Or just "consent" ?
>
> I think I'd favor consent.

That's fine. It's easy enough to change if we need to, if there are
other suggestions.

>>So ... what should I name the classes that implement what I have in my
>>local workspace as the "post-authn" hook ? Should the prefix be
>>"Chaining" ?
>
> I think the Chaining aspect is more manifested by an action that does the
> looping/dispatching instead of just picking one, not the flows themselves.
> For want of a better name for the concept, does "ProfileInterception" or
> "ProfileIntercepting" work?

Sure.

>>The post-authn-flow will have three actions : (1) populate a context,
>>(2) select a flow, and (3) call the flow, but none of that is specific
>>to post-authn, that's just where it is wired into the calling flows.
>
> Right, I'd favor something more general as a name. Can't think of anything
> but "intercepting".

All I've got is "ProfileHook", which makes me think of Captain Hook.
After reading your comments, maybe "ProfileIntercepter" for the
action.