Per-Entity Metadata Working Group

[Paul Caskey <>]

IIRC, ADFS pre-caches all metadata (all metadata is retrieved at service 
startup, not on demand, so, if true, latency with ADFS is totally a 
non-issue).

That may have changed with this latest iteration of ADFS, which supposedly 
can consume an aggregate.  I have not had a chance to play with that yet.



> -----Original Message-----
> From: 
> 
>  [
> ]
>  On Behalf Of Scott Koranda
> Sent: Tuesday, September 06, 2016 6:11 PM
> To: David Walker 
> <>
> Cc: 
> 
> Subject: Re: [Per-Entity] HTTPS transport and TLS trust
> 
> > I don't see why we need to provide multiple ways for clients to verify
> > the metadata, particularly since we consider one to be reasonably
> > strong, and the other not so much.
> 
> To accomodate InCommon Participants that use ADFS as either their IdP or
> SP and who want to obtain metadata for specific entities in what is
> considered by them as the "natural way".
> 
> > We have no guarantee that a metadata client (per-entity or
> > aggregate) is checking signatures, anyway.  Since there's a cost to
> > https (in terms of latency), I would say don't support it.
> 
> There is a cost in latency only to those who decide to use HTTPS as the
> transport.
> 
> It is unlikely those same consumers will be at all concerned about the extra
> latency using HTTPS transport since, as was pointed out, they will not 
> really
> be doing "per entity"
> metadata (at least not initally).
> 
> > However, it's my understanding that ADFS requires https, independent
> > of security or trust.  If that's the case, I'd be tempted to tell
> > people they can use either http or https, but that they'll get lower
> > latency with http, and the authenticity of the metadata they get
> > should be verified from the signatures it contains, not from the 
> > transport.
> 
> That was my thinking.
> 
> The InCommon MDQ service would operate both HTTP and HTTPS, and serve
> XML signed per-entity from both, but only recommend the HTTPS transport
> for ADFS clients.
> 
> I brought up the issue to try and understand if the benefits of
> *additionally* offering HTTPS as a transport (primarily making it easier for
> ADFS to consume some InCommon metadata) was worth the costs.
> 
> It is probably not within scope for this working group to make that
> recommendation, but it would be nice if we could offer in the report enough
> information and frame the issue clearly enough so that another group (TAC?)
> could make the decision on whether the costs are worth the benefits.
> 
> Thanks,
> 
> Scott K
> 
> >
> > David
> >
> >
> > On 09/06/2016 01:52 PM, Cantor, Scott wrote:
> >
> >         Just for the background information, another concern was the 
> > server
> >         security which is assumed in TLS.  I'm not suggesting 
> > md.incommon.org
> is
> >         not secure but it was difficult to quantify and it was certainly 
> > less
> >         secure than the signing operation.  Ops also wanted to reserve the
> >         flexibility of hosting its stand-by servers in co-locations 
> > without
> >         special requirements on its physical security.
> >
> >     Right, that's the fundamental difference.
> >
> >     Signing Pro:
> >     - self-contained / portable security model
> >     Con:
> >     - subject to MITM threats
> >
> >     Transport Pro:
> >     - end to end security
> >     Con:
> >     - highly dependent on physical deployment characteristics that are
> > difficult to replicate widely
> >
> >     I wouldn't necessarily argue that both don't have their place, but we
> implement both and long experience has led us to believe that it's better to
> attack the MITM problem with signing somehow than give up the flexibility.
> >
> >     I think probably the best option is to sign, use TLS, but not go 
> > overboard
> trying to lock down the TLS part. That provides reasonable protection 
> against
> low-cost active attacks without relying on it exclusively.
> >
> >     -- Scott
> >
> >
> >
>