Page Comparison

...

SignatureValidation (filter)

certificateFile=”String”

consumed in a builder as a (Spring) Resource where it is then converted and passed on as a X509Certificate

(Q: So this is also Converted by spring (via FilesystemGenericApplicationContext), or is this distinct as a behavior?)This is a two part conversion.  The parser passes a string to a  FactoryBean which consumes it as a Resource (and hence the conversion is using Spring via FilesystemGenericApplicationContext).  The FacotryBean then does the explicit conversion to a X509Certificate in its doCreateInstance() code.

ResourceBackedMetadataProvider <HttpResource>

...

We are going to jettison this.

Security Schema

Can we jettison this? At the very least we can get rid of all the unused types.  Note that jettisoning this means doing as good a job with its replacement as we currently do for relying party. Note this gets used in the attribute resolver to define LDAP security behaviorIt would be nice to jettison this, but apart its major use in the V2 relying party syntax, it is also used in several other schema

• LDAP Data connector (StartTLSTrustCredential, StartTLSAuthenticationCredential )
• HTTP Client behavior:
  • HTTPMetadata resolvers (TLSTrustEngine), 
  • Potentially the REST Data connector
• Metadata SignatureValidation Filte (TrustEngine)

If possible, it would be nice jettison this? However doing so would require easier to use mechanisms for the common case (certificates in files) and full documentation on how to configure native spring homologs..

Resource Schema

With the security schema gone this is only ever used in the ReourceBackedMetadataProvider.  I suggest that we only support (the existing) resource-ref="beanId", although we could add

...