Shibboleth Developers

["Scott Cantor" <>]

> Seriously, I can imagine some filtering rule that could check the uApprove
> database and throw an exception if user consent is needed. The uApprove
> could then process this, display the consent screen (or fail on back-
> channel) and redo the whole attribute resolution and filtering on success.

I'd think the best option is to ensure there are some hooks in the consent
layer or some kind of documented mechanism involving the database or
whatever, and then just let people build in rules that create filter
policies based on whatever information they want.

But my impression is that people won't rely on back channel approaches that
can't guarantee (at least approximately) that the data can be gotten, or
that consent can be asked in real-time. If it's 50/50 based on whether
consent was given at some other time, I think it's not going to fly.

I think it also depends on the architecture and how far removed you are from
the user. If it's a 3-tier scenario, it's pretty reasonable to look at
something like OAuth as a mechanism for a user consent pattern.

But past 3 tiers or offline, real-time consent is pretty tough, and if it's
not real-time it's going to be fatal to a lot of use cases.

-- Scott