Parsing the trust engines

[Rod Widdowson]

Without double guessing the talk this afternoon it seems to me that the best
solution is that nearly all trust engines will be configured elsewhere (in a
combination of user visible and system reserved spring beans files).  

This would render them non-reloadable but I am comfortable with a change of
that magnitude requiring that the IdP be restarted ("I want to completely
rototill the security of my production system and I want to do it on the
fly").

Indeed the *only* trust engine that I can see us having any need to
configure via relying-parety.xml is the one which is to be injected into the
metadata certificate filter.

As such I am assuming that I can stub out those trust engines which were
there really for supporting the old <SecurityPolicy/> parts of the config
(which I believe we all agree will be represented differently and
elsewhere):

•	MetadataExplicitKey
•	MetadataPKIXX509Credential
•	MetadataExplicitKeySignature
•	MetadataPKIXSignature

This "just" leaves the ones which might be useful in filtering metadata:

•	Chaining
•	SignatureChaining
•	StaticExplicitKey
•	StaticPKIXX509Credential
•	StaticExplicitKeySignature
•	StaticPKIXSignature

(of course some of these come with the considerable you would expect from
PKIX config, but that’s the cost of doing this).

For the record, the parsing of relying-party.xml currently exports two
different services (with entirely different configuration).  These services
export the two interfaces:

MetadataResolver 
RelyingPartyConfigurationResolver

I am entirely happy with the setup of the first.  To my mind the teleconf
this afternoon is about the missing plumbing which is currently blocking the
second from being useable.