Per-Entity Metadata Working Group

[Nicholas Roy <>]

On 9/6/16 12:31 PM, Tom Scavo wrote:
> 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.
Just getting to this thread after coming back from vacation a couple 
weeks ago.

FYI, last year TAC recommended that Ops deploy an EV cert on the 
ops.incommon.org site where we distribute the information to allow 
bootstrapping trust in the signing key (details at: 
https://spaces.internet2.edu/display/InCFederation/Metadata+Signing+Certificate)

We deployed an EV cert on that site, and obtaining that cert was an 
arduous, multi-month process.  I have to renew it after TechEx, not 
looking forward to that...

Nick

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