Metadata requireSignedMetadata=false Behavior

Cantor, Scott cantor.2 at osu.edu
Mon Jun 8 09:44:27 EDT 2015


On 6/8/15, 7:24 AM, "users on behalf of Nate Klingenstein" <users-bounces at shibboleth.net on behalf of ndk at internet2.edu> wrote:

>> 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.

An ID is a syntactic comment for logging. That's not a change.

>
>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.

That may be true, but it's simply a total non-starter to break upgrades in ways that don't have to be broken. That feedback has been universal, loud, and unambiguous.

>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.

Edugain is something federations consume, not IdPs. At least not in general.

-- Scott



More information about the users mailing list