Per-Entity Metadata Working Group

[Scott Koranda <>]

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