[java-identity-provider COMMIT] in /trunk/idp-saml-impl/src: main/java/net/shibboleth/idp/saml/impl/profile/saml1/Sig...

[Brent Putman]

On 2/6/14 7:25 PM, Cantor, Scott wrote:
> I see for signing that indeed we'd have to have separate copies of the
> context to represent response from assertion signing, as you say.

That is of course assuming the method of presence/absence signals to do
it, and assuming the use of a single context that holds all of these. 
In the profile actions there are also the profile config flags for
signing and encryption, which could be used more directly I guess.  For
MessageHandler protocol message signing though, those don't exist (in
OpenSAML), so the presence/absence thing seemed like the simplest.

And/or we could have different contexts to hold the data for the
specific operations, e.g. protocol message signing vs assertion
signing.  When I did this originally I just did the one
SecurityParametersContext because I needed something against which to
code some of the MessageHandlers, but we can certainly revist.

Same thing with the placement of all 4 -Parameters in a single context -
that was just the simplest thing to do, but we could in theory have a
distinct context for each one. 

Also, to be clear, regarding the current single 4 -Parameters context,
there was never an assumption on my part all 4 of those slots would
always be populated, or that they would be populated at the same time. 
Meaning, if a slot isn't applicable to that particular flow/usage, it
can be left null, and also the slots can be populated by different
stages/actions, as needed.