Per-Entity Metadata Working Group

[Scott Koranda <>]

Hi,

> Minor point, but ADFS won't care about latency.  

Today, yes.

Nick Roy and I will soon have a call with Microsoft
engineering to talk about the future for ADFS and per-entity
metadata.

If it is not difficult for Patrick I would still like to have
the HTTPS latency numbers as a reference.

Cheers,

Scott K

> 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