<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 5/13/14 9:18 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CF983A85.CCAF%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<pre wrap="">
Yeah, I thought maybe if the SAML encryption resolver subclass could
create a subtype of EncryptionParams that might work, but it's not
structured to do that now.</pre>
</blockquote>
<br>
It's not right now. But maybe, possibly it could work. I'll think
on it some. It doesn't really scale though. Say we needed in the
future some SOAP-specific options. So we make a SOAP-specific
config, but then madness ensues with what kind(s) of resolvers can
deal with that, and what to do about the params, etc.<br>
<br>
I guess the other easier option would be to just expose either a
Map<String,Object> or a ClassIndexedSet or something on the
configs, and just have the resolvers mirror them straight over to
the params - logically merging the values from all the passed
configs. Or something like that. Then the thing using the params
would have to know what to look for. Don't know what the Spring
wiring for the config instances would look like, though, esp for a
ClassIndexedSet. That doesn't sit 100% well with me though at the
moment, although it feels more like the loosely coupled direction
we've been going in v3.<br>
<br>
<br>
<blockquote cite="mid:CF983A85.CCAF%25cantor.2@osu.edu" type="cite">
<pre wrap="">
I was hoping not, but I suspect if it's ever needed, it would be for an
interop purpose, so that's where it would have to be.
</pre>
</blockquote>
<br>
<br>
Yes, agree, it would be nice to have it be relying-party-specific.<br>
<br>
<br>
</body>
</html>