Straw-man for security parameter placement

[Cantor, Scott]

Mainly to Brent...

I'm wondering if we need to split up the EncryptionParameters into Data
and Key types to represent the difference between whether and how to
encrypt the data and who to encrypt it for?

I can't pull a single parameter set from a RelyingPartyContext as a signal
whether to encrypt because that doesn't tell me which objects need to be
encrypted. But if we split these, I could create separate subcontexts for
the different types of objects that might need encryption and hang those
off the profile context, but put the KeyEncryptionParameters below the
RelyingPartyContext.

Otherwise we'd have to combine the idea of presence/absence as a signal
with something more fine grained to tell what to do.

I don't know what you have in mind yet as Criteria for the resolvers, but
I'm assuming that we'd need a way to signal the "type of encryption"
(Assertion, NameID, Attribute) for it to resolve the parameters if the
intention is to bury whether to encrypt it all into that resolution
process.

Alternatively, we can split "whether to sign/encrypt" from "how to
sign/encrypt" and just add predicates to the signing/encryption actions
that determine that and fail in those actions if they have to do them but
can't find parameters.

-- Scott