Okay to tag alpha3 ?

[Tom Zeller]

> On Oct 28, 2014, at 10:51 AM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
> 
> On 10/28/14, 11:34 AM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
> 
>>> I had to "fix" (in an interim form) the error handling in the intercept
>>> flow when I ported the attribute checker in, so you may have to look at
>>> whether I broke something until we get the consent flows cleaned up.
>> 
>> Thanks. I had been confused about the error handling. The integration
>> tests are testing the consent flows minus revocation and they are
>> still passing.
> 
> I had to fix them, but I did that by tweaking the error event they were
> using to match one that's already in the abstract flow.
> 
> The problem here that isn't as true with authn or c14n is that the set of
> event IDs is more open because of user extension, in order to use the
> message.properties trick and error.vm to do the view for you (or route to
> a different view).
> 
> Like with mine, I generalized the attribute-check flow I did as a
> "context-check" intercept flow, meaning it "examines the
> ProfileRequestContext and either signals proceed or ContextCheckFailed".
> 
> So, I have to make ContextCheckFailed a valid end state for both my flow,
> but also your intercept master flow. There's no way to wildcard that,
> unless we put the "real event" into a property of some other common event
> or create our own layer underneath flow events, etc. I would rather not do
> that.
> 
> But right now, the abstract flow is in system/. I tried to do a two level
> inherit with a parent flow in user, but that doesn't work, turns out SWF
> only allows one level of flow inheritance. So I'm still thinking.

Were you trying to merge end-states ?