<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 2/6/14 5:28 PM, Tom Zeller wrote:<br>
</div>
<blockquote
cite="mid:CAMNmQDROEfBYwOQGHambfg6aEfdhOa5qzQojy2oM_CmoANTvQw@mail.gmail.com"
type="cite"><br>
<pre wrap="">
If SecurityParametersContext is present but
getSignatureSigningParameters() returns null, that is an error,
correct ?</pre>
</blockquote>
<br>
No, it just means don't sign.<br>
<br>
In the IdP, given that we wouldn't be doing validation, encryption
or decryption on an outbound message flow (those being the other 3
property slots on that context), it would be "odd" to have added a
SecurityParametersContext without a SignatureSigningParameters any
data (the other 3 would presumably be empty also), but not really an
error.<br>
<br>
But this could certainly be the case in other contexts, e.g. the
outbound request flow of an SP that isn't signing this particular
message but is encrypting the message Subject NameID (if it were
done at the message handling level).<br>
<br>
To anticipate your next question, I'd think that the IdP actions
that for example sign and/or encrypt the Assertion would be coded
similarly. Presence of the data signals sign and/or encrypt,
otherwise don't. The stuff earlier in the flow that handles
deciding whether to even do (i.e. the profile config flags) and
resolving the params is the place where errors in resolution should
be handled, IMHO. It keeps the encrypting and signing code simpler
by only looking at the config flags once (that is, earlier in the
flow).<br>
<br>
</body>
</html>