Metadata requireSignedMetadata=false Behavior

[Nate Klingenstein]

> It's not though. It's the same file as before, just without the RelyingParty parts. On an upgrade it copies relying-party.xml to that filename. If we changed options, that breaks upgrades.

I think there are more differences.  For example, the distribution in v2 had the ID "URLMD", whereas in v3 it's "HTTPMetadata".  That, along with the file path change, are enough to mean I need to totally rewrite things.

I also think it's generally more important to make v3 as good as possible rather than ensuring that every manner of upgrade is seamless.  We faced this question in the Installfest planning and I think that focusing on v3 as its own entity was a good idea for attendees.

> So the utility of the requireSignedMetadata/requireSignature attribs is the use case where the root is *not* expected to be signed, but 1 or more child elements *are* expected to be signed, and you still obviously need to validate signatures on those (otherwise you wouldn't bother configuring in the signature validation filter on that metadata in the first place).  As one example, think of a use case where the root is an EntitiesDescriptor which is merely a simple (non-signed) aggregation of signed EntityDescriptors obtained from elsewhere.

That all makes sense, but it strikes me as something of an edge case.  Is there a way to specify that you want a particular entity to be signed, for example, or could you only do this on the root?

> The signing key is for the whole metadata document.  The root may or may not be signed, but doesn't have anything to do with whether any other validation is going to happen.


This is the most interesting thing that you wrote, to me.  I wonder whether this is going to create questions for future use cases where we're trying to support multiple signatures.  I don't know how eduGAIN works, for example, but I could imagine deployments taking this path.

Thanks for taking so much time to clarify all this,
Nate.