Shibboleth Developers

[Chad La Joie <>]

Yes, everything you said here is true.

Also, it would be possible to bring up the consent page even if the IdP 
wasn't pushing attributes.  So you could ask the user's consent for the 
attributes that would be pulled by the SP.  Not sure if this is 
desirable.  It is still obviously mutually exclusive with the "always 
ask" option and in theory IdP deployers can create filter policies that 
would return different results for push vs pull, but I doubt anyone has 
ever done that.

On 6/10/10 5:26 AM, Rod Widdowson wrote:
> > - Ability to inject the consent engine in the back-channel and
> > non-browser flows. If a user has not given prior consent the SP will
> > not
> > receive any attributes.  Obviously, from an operational standpoint,
> > this
> > option is mutually exclusive with the "always ask" option mentioned
> > above.
>
> Just so I understand this:  The user can only be queried about attribute
> release in the attribute-push flows.  The IdP deployer then has three
> options for attribute pull (but not artefact resolution)
>
>    - Let everything past (which may not be sensible)
>    - Check what has been previously OK'd for this principal at this relying
> party (possibly further filtered by the login method?)
>    - Drop everything on the floor (presumably with a success status).
>
> Obviously many SAML1 deployments fall into this case but of course it need
> not be just them.  It seems sensible to expect that these SAML1 profiles
> will be less popular by then, so I'm just teasing out the deployment issues.
>
> Am I correct to say that attribute push is entirely configured by the IdP?
> Hence the IdP is the sensible place to make a call about back channel
> consent - if attributes are never pushed to a specific relying party then it
> seems dumb to put in any attribute consent enforcement?  Hence, at least in
> theory, the IdP deployers have all the tools needed to avoid shooting
> themselves in the foot.
>
> I realize that it's too early to have these discussions, but when we get
> there can we have a conversation about what the sensible defaults will be
> (having SAML1 off for relying parties which need consent seems reasonable to
> me)
>
> Note that I am *not* proposing a speculative consent form and I don't hear
> you doing so.  This doesn't really seem to fit in with the use cases I've
> heard.
>
> /Rod

--
Chad La Joie
http://itumi.biz
trusted identities, delivered