v3.3.1 MetadataProvider, metadataURL formatting question

[Peter Schober]

Just to emphasize some of the things Scott said:

* Cantor, Scott <cantor.2 at osu.edu> [2017-06-01 22:20]:
> Well, you really should not be using met.refeds.org as a source of
> metadata for a deployment

Definitively not.

(That's why I always recommend for such tools to not expose the
underlying XML itself, at least not in an easily
referencable/addressable way that may lead someone to think they can
use this for trust establishment. The eduGAIN entities database makes
the same mistake, IMO, cf. https://technical.edugain.org/entities )

> unless you're operating some kind of aggregation exercise on behalf
> of something else (and even then, I don't think that's what the mets
> tool is meant for)

It is most certainly not. REFEDS MET is purely a tool for exploration
of federations and their entities for human agents using a web
browser. Anything and everything could be wrong in subtle (or not so
subtle) ways in MET or anywhere else you might find SAML 2.0 metadata
on the Internet (unless there's additional assurance that it's legit
and current.)

> You're also not verifying a signature here, so you can't be doing
> this safely.

To get metadata for an entity registered with InCommon the OP is free
to decide to trust InCommon (and their signing keys), even if they're
not InCommon members themselfs. (Otherwise they'd be loading InCommon
metadata already and all of this would be pointless.)

But in MET any and all signatures have been stripped, so it's
impossible to verify whether any of that XML is authentic.
Relying on /that/ to establish trust into cryptographic keys is not
advisable, to put it mildly.

-peter