puzzled about the activationCondition of the AttributeReleaseFlow

Cantor, Scott cantor.2 at osu.edu
Fri Jan 27 16:37:55 EST 2017


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

> the AttributeQuery code would not take into account the attributes release decisions saved in the intercept/attribute->release context entries of the StorageRecords?

No. Nor did uApprove, from which the design was derived, as far as I'm aware.

> If that is the case one should prevent out of session attribute queries by filtering out the necessary persitentId/targetedId
> attribute for all service providers where the user is asked for attribute release consent!

You don't control NameIDs by filtering attributes, and they are not attributes, but in terms of controls over data, yes.

Most IdPs don't need to support queries at all and a good percentage don't anymore. Most IdPs do not support reversible persistent IDs either. Transients would be a risk. But the IdP can also impose additional constraints by limiting which SPs can actually request the reverse-mapping too, or simply limit which relying parties the query profile is even enabled for. There are all sorts of controls and limitations.

-- Scott




More information about the users mailing list