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

[Tom Zeller]

On Mon, Sep 8, 2014 at 10:53 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 9/8/14, 11:27 AM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>
>>I was thinking I should create idp-attribute-consent-api|impl modules.
>>Is that the right name ?
>
> Depends if you're talking about the specific instance of a flow to do
> that. Could probably go either in its own module or just in
> idp-profile-impl. Don't know if there will actually be any APIs or not.

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.

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

> The general machinery for these flows, no, they're not specific anymore to
> attribute consent, they're just "flows that can be run at some point to do
> stuff". I would stick any such APIs in idp-profile-api.
>
>>It seems 'consent' would be the third step in attribute processing,
>>after 'resolver' and 'filter'.
>
> In that specific flow example, but again the machinery here is not about
> attributes, it's about running at a certain point and doing whatever it
> wants to do.

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

We'll need a flow descriptor that looks pretty much the same as the
SubjectCanonicalizationFlowDescriptor, maybe "ChainingFlowDescriptor"
? There will need to be an action just like
PopulateSubjectCanonicalizationContext, maybe
"PopulateChainingFlowContext", to populate the available flows of a
... "ChainingFlowContext" ?

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.

This "chaining" stuff will call the attribute-release and terms-of-use
flows, which don't need to know anything about it.

In summary, I guess I'm looking for a naming prefix for the consent
stuff, I'm suggesting "attribute consent", and a prefix for the
chaining flow stuff, I'm suggesting "ChainingFlow". I don't feel
strongly about these names, just trying to do the right thing.