Per-Entity Metadata Working Group

[Paul Caskey <>]

Minor point, but ADFS won't care about latency.  It only queries the metadata 
URLs periodically to refresh its cache.  However, it can't do signature 
verification, so the https thing seems important.



> -----Original Message-----
> From: 
> 
>  [
> ]
>  On Behalf Of Scott Koranda
> Sent: Tuesday, September 06, 2016 8:05 AM
> To: Chris Phillips 
> <>
> Cc: Per-Entity Metadata Working Group 
> <>
> Subject: Re: [Per-Entity] Latency figures for CDNs
> 
> Hi,
> 
> > It would be an interesting datapoint to capture latency but I suspect
> > it may not be material.
> 
> I supsect it will be to our working group's discussion.
> 
> It is an open question on whether or not InCommon should operate a (not
> necessarily "the") MDQ service using HTTPS as a transport in order to allow
> some clients, most notably ADFS, to consume metadata for InCommon
> federated entities.
> 
> > The whole principle of trust is that the item fetched is signed
> > regardless of transport -- right?
> 
> See above.
> 
> Some InCommon Participant ADFS operators want to be able to consume
> metadata for a particular entity by pointing at a MDQ service that uses 
> HTTPS
> as the transport and the trust mechanism rather than XML digital signature 
> of
> the metadata.
> 
> > I think the only federation that leverages verification of connection
> > is SWITCH. See section 6.3 of this[1] and the PKI info here[2]
> >
> > While I'm very much in favour encrypted transit, is there a
> > requirement that MDQ content MUST be served over TLS?(as a way to
> > increase the
> > trustworthiness?)
> 
> There is no requirement in the sense to which, I believe, you are referring.
> 
> The question primarily is whether InCommon will operate "a"
> MDQ service available via HTTPS so that only that trust model is leveraged
> rather than the XML digital signature from the InCommon metadata signing
> certificate(s).
> 
> > I'm not seeing any compelling differences between what federations do
> > today and what MDQ Requires.  Content can be served both HTTP and
> > HTTPS but does not require HTTPS... Or does it?
> 
> There is no technical requirement in the sense to which you are referring.
> 
> I would like to start a seperate thread about this question of HTTPS 
> transport
> and the TLS trust model for InCommon MDQ service.
> 
> Thanks,
> 
> Scott K