puzzled about the activationCondition of the AttributeReleaseFlow

[Cantor, Scott]

On 1/27/17, 9:53 AM, "users on behalf of Dominique Petitpierre" <users-bounces at shibboleth.net on behalf of Dominique.Petitpierre at unige.ch> wrote:

>Essentially it is
    
>     (NOT(idp.consent.allowPerAttribute) OR getProfileConfig().includeAttributeStatement())

Then you've figured it out. ;-)

If attributes aren't being pushed to the SP, then any per-attribute choices the user makes can't be enforced with the current code, so given that, the system doesn't give the user the UI to make decisions that it will not actually apply.

With the normal all or nothing consent UI, if the user says no, the whole flow just stops, so no attributes will be pushed or pulled. But with per-attribute, making selections doesn't block the flow, and if the attributes are queried and not pulled, the decision isn't available so it isn't enforced.

>- What happens if activationCondition evaluates to false and the attribute release consent flow is not applicable: should the
> filtered attributes be released or not?

If there's no consent involved, it released anything that was left after filter policy.

The problem of consent for back channel exchanges of data, be it SAML, OAuth, or anything else, is a different sort of problem that needs different solutions than anything we have built to date.
 
-- Scott