Shibboleth Developers

[Brent Putman <>]

Scott Cantor wrote:

This is technically still true, but it does catch the exception that
gets thrown due to a null KEK credential parameter.  Question is:  what
should we do if the IdP config indicates to do encryption, but the
recipient doesn't have an encryption key published?    Should that be a
fatal error, or should the IdP just log it and proceed without doing the
encryption? The latter seems more correct to me, especially since we
typically will just have a single default security policy for all
relying parties.  I seem to remember us discussing that at some point.
    

It was concluded in San Diego that we should not send it in cleartext if
we're told to encrypt it.
  

Ah, it's all coming back to me now....   I suppose that's the right thing to do from a "be safe" standpoint.    FYI, so looks like we currently default (based on the config file schema) to attribute push with no encryption.  So if people turn on encryption of assertions or name ID's for the default relying party, then they'll need to know to override and turn it off for specific relying parties that don't publish keys, or it will result in a fatal error for the latter.

Alternatively, we'll need to have a multi-setting that can cover "off", "if
possible", and "required".
  

Sounds reasonable.  Don't know what Chad thinks.

I also think both front and back channel should be controllable
independently. I have that ability, but not the former right now.
  

Also sounds reasonable.  Were you going to add the former?  Or not for 2.0?