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

[Cantor, Scott]

On 9/8/14, 1:31 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>
>I was thinking of idp-attribute-consent-* for classes/beans of the
>terms-of-use and attribute-release flows, for example, a BaseContext
>which holds pre-consented attributes and then the attributes resulting
>from user consent. Also not sure about APIs. I'm fine with
>idp-profile-impl until it seems clear that another module is
>appropriate.

That would be my suggestion. 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.

>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.

>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?

>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".

-- Scott