unencrypted assertions not working

[Tom Scavo]

[replies to participants at incommon.org please]

On Wed, Apr 3, 2013 at 10:21 AM, Mark K. Miller <max at psu.edu> wrote:
>
> On Wed, 3 Apr 2013, lalithj wrote:
>
> I have no clue what federation/trust model the OP participates in, but, if
> I may jump on my 'InCommon soapbox' for a moment.  It's my opinion that
> its always best to guide new services in a direction that will require the
> least effort for them and their future business partners.  In this case,
> specifically, I think most of the IdPs in InCommon send encrypted
> assertions by default.  So, in the initial engagement, if we can get a new
> SP accepting encrypted assertions it's far less total effort for everyone
> in the long run.

That's true, InCommon does require *every* SP to submit an encryption
certificate. However, there's a big difference between exposing an
encryption certificate and fully supporting encryption. For the latter
to occur, your SAML implementation must be able to support multiple
configured decryption keys, and yet we know from experience that not
all SAML implementations support this. Forcing an SP to expose an
encryption certificate in this case actually does more harm than good.

Moreover, there are deployment scenarios where message-level
encryption is not needed at all. Two examples are: 1) a SAML1-only SP,
and 2) an SP that supports HTTP-Artifact only (i.e., not HTTP-POST).
Clearly an encryption certificate is not needed in these
circumstances.

Finally, there are IdPs that have chosen to release directory
information to *all* SPs precisely because that directory information
is considered to be public information. Since we'd like to see more
IdPs make such a policy decision, it seems counterproductive to
mandate message-level encryption when clearly it's not needed or
desired in all cases.

So, all that to say, we do require an encryption certificate at the SP
in the InCommon Federation but we are considering whether to relax
that requirement for all of the reasons mentioned above.

Tom