Per-Entity Metadata Working Group

[Tom Scavo <>]

On Tue, Sep 6, 2016 at 9:40 AM, Scott Koranda 
<>
 wrote:
>
> My understanding is that the InCommon TAC in particular has
> had objections in the past to serving any InCommon metadata
> that *relies* on the TLS trust model.

That statement has some truth in it but that is not the whole story.
All you have to do is raise this topic on the REFEDS list to start a
religious war :-)

> Can someone familiar with that objection (Scott C or Tom S or
> Nick R or ?) provide more details, or correct my understanding
> if I am wrong?

I can give a historical perspective. AFAIK, InCommon has always
published a metadata location that begins with "http://";. Originally,
that location was:

http://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml

Now it is:

http://md.incommon.org/InCommon/InCommon-metadata.xml

Server md.incommon.org does not support TLS, which is intentional. A
surprising fact is that TAC recommended that md.incommon.org should
support TLS. Ops disagreed with TAC (which is rare, and perhaps
unprecedented) so md.incommon.org does not support TLS.

> What other objections are there to serving InCommon metadata
> using the TLS trust model?

I'll sidestep that question (ScottC gave an answer) and suggest a
thought experiment. Suppose md.incommon.org supported TLS. What
metadata location would we publish and document? The only answer that
makes sense (to me) is that we would publish a metadata location that
begins with "https://";. But what about the documentation? Honestly, I
wouldn't be able to write documentation that makes sense (to the
average deployer). That little "s" in the URL really complicates the
message, so in the end we decided not to support TLS on
md.incommon.org.

An MDQ server gives us an opportunity to revisit this issue. I'll stop there 
:-)

Tom