Shibboleth Developers

["Rod Widdowson" <>]

> - 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