Metadata requireSignedMetadata=false Behavior

[Rod Widdowson]

The first thing to say is that this is exactly the same as the V2 setup, just exbedded from the RelyingParty.xml file.  There is just a bunch of semantic sugar to make things easier by bringing the key information closer to the filter (whereas in V2 you put it into a TrustEngine which was remote in the file)

> A) What happens if there's a public key but signed metadata is not required

Then it will do the signature test and fail if it's wrong.  This is a chocolate teapot configuration option, but it was here in V2 so it's there in V3.

> B) What the value is in specifying a signing key that is optional, since accepting
> unsigned metadata despite having a validation key seems to defeat the purpose
> of signing

Yup.  Chocolate teapot.  I think that that was even the default for one V2 release.

> C) Why you wouldn't make requireSignedMetadata=true implicit behavior if
> there's a key, and requireSignedMetadata=false implicit behavior if there is no
> key, which would seem to obviate the need for requireSignedMetadata as a
> flag.

My view is that the option should *never* be used.  However I also took the view that in V3 we would document *ALL* configuration options rather than saying that the wiki was just outline docs and the definitive statement was to be found in the schema which were hidden in a jar file (in the basement behind a sign saying beware of the leopard).

The counter to this is that the documentation is now a statement of fact with some words to help deployers.  The aim is (and always has been) to find someone to turn this into useful documentation but despite a large number of attempts over the last 3 years it has come to naught (so far)

> I also wonder why the note implies that secure interoperation 
> is impossible without metadata signature.  I would think that TLS 
> has been used in some environments, for instance.  Is that 
> intended as a warning to people who are new to the technology?

Yes.  If you know enough to see through the statement then you stand a reasonably good chance of deploying TLS in a secure manner - the configuration for which is far more complex involved separate Spring Bean files and custom HTTP Clients.   I know that one federation has documentation to allow this to be done and I'm sure that they target their documentation as superseding ours.

I think that it's fair to say that there is significant concern amongst the developers at the "TLS is magic-secure-pixie-dust" mindset which is inferred by trusting the CA bundle distributed in the JVM.  

HTH - and please keep up the feedback, it is our best chance to improve things. 

/R