Finalizing TrustEngine config

[Brent Putman]

On 6/19/14 10:45 AM, Cantor, Scott wrote:
> On 6/19/14, 10:41 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>> The constructor for the trust engine (in this case
>> org.opensaml.xmlsec.signature.support.impl.ExplicitKeySignatureTrustEngine
>> )
>> needs a KeyInfoCredentialResolver which is instantiated as "new
>> org.opensaml.xmlsec.keyinfo.impl.BasicProviderKeyInfoCredentialResolver
>> (that list)" 
>>
>> In V2 (and currently in V3) that is created on the fly *in the parser*
>> which
>> is completely against our desire to leave defaulting in the objects or the
>> XML.  It might well be that a centrally defined list is not what we need.
>


I was thinking about this a little more after the call today.  On the
issue that Scott raised specifically with the KeyInfoProvider list
created for the LocalKeyInfoCredentialResolver for decryption:  I think
that in fact that one probably does need to be defined separately.  The
reason is that once we have support for ECDH (and possibly even just
straight DH), the way that will probably work is via a new
KeyInfoProvider that understands xenc:AgreementMethod and produces a
symmetric key credential from that by performing the key agreement
operation.  And for that it will need access to local creds with the
private key, etc.  That's at least how I currently envision it working.

So for that one specifically, it would probably continue to be a
separate provider list - it's not really the traditional "inline" case
that we have for metadata and signature KeyInfos, etc. 

If there are other places where we're duplicating the provider list, the
pulling that from a central bean or factory method etc would make sense.