Per-Entity Metadata Working Group

[Chris Phillips <>]

It would be an interesting datapoint to capture latency but I suspect it
may not be material.

The whole principle of trust is that the item fetched is signed regardless
of transport -- right?

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

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?

In the case of SWITCH, it would still 'work' with their PKI only if the
MDQ elements are served with the same TLS chain of trust as they advise
their community..
For them, a CDN approach will not since TLS termination will be in the
CDN, not the origin of the MDQ content.

C

[1] https://www.switch.ch/aai/guides/idp/installation/
[2] https://www.switch.ch/pki/aai/

On 2016-09-06, 7:20 AM, 
"
 on behalf of
Scott Koranda" 
<
 on behalf of
>
 wrote:

>> On Fri, Aug 26, 2016 at 1:56 PM, David Walker 
>> <>
>>wrote:
>> > Getting back to Nick's original question, I guess I am concerned
>>about the
>> > latency times for 12KB objects (~0.4 secs in the US), unless we think
>> > InCommon sites have much better connectivity than Frost and Sullivan's
>> > average (and that the predominant latency factor is the last-mile
>>network).
>> >
>> > This, of course, brings us back to Chris's admonition that we focus on
>> > business needs.  What delay is acceptable when an IdP or SP needs to
>> > retrieve the metadata for some other SP or IdP?  0.4 seconds sounds
>>pretty
>> > long to me, but it is a rare event, we think.
>> 
>> I setup Cloudfront (US, Canada and Europe locations) to be a caching
>> proxy for the beta MDQ server.
>> A cache miss in the edge location closest to you will result in a
>> query going to the MDQ server. Cloud front will cache the result for
>> an hour.
>> You can test it by using http://drhqoesel6yr5.cloudfront.net/ in place
>> of http://mdq-beta.incommon.org/
>> 
>> Using curl to do the timing
>> 
>> curl -o /dev/null -s -w \
>> %{time_connect}:%{time_starttransfer}:%{time_total} \
>> 
>>http://drhqoesel6yr5.cloudfront.net/global/entities/https%3A%2F%2Ffm.inco
>>mmon.org%2Fsp
>> 
>
>Hi Patrick,
>
>How difficult would it be for you to add "HTTPS" as a
>transport?
>
>I am curious to see the difference in performance.
>
>For simple tests I think any X.509 cert you have (or the CDN
>is willing to provide) would be just fine.
>
>Thanks,
>
>Scott K