Skip to Content.
Sympa Menu

per-entity - Re: [Per-Entity] implementing a cache on the client

Subject: Per-Entity Metadata Working Group

List archive

Re: [Per-Entity] implementing a cache on the client


Chronological Thread 
  • From: "Cantor, Scott" <>
  • To: Tom Mitchell <>, Nick Roy <>
  • Cc: Thomas Scavo <>, "" <>
  • Subject: Re: [Per-Entity] implementing a cache on the client
  • Date: Wed, 27 Jul 2016 21:00:01 +0000
  • Accept-language: en-US
  • Authentication-results: spf=pass (sender IP is 164.107.81.216) smtp.mailfrom=osu.edu; bbn.com; dkim=none (message not signed) header.d=none;bbn.com; dmarc=bestguesspass action=none header.from=osu.edu;
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

On 7/27/16, 4:53 PM, "Tom Mitchell"
<>
wrote:

> If the MDQ protocol really is straight up HTTP documents, which it appears
> to be by
> design, there should be ample opportunity to make those documents highly
> available via
> CDNs or similar.

I'm not familiar enough with how they work, and I'm getting maybe this is one
reason Leif's been pushing the SAMLBits idea.

There's still the complexity of getting a web server to map an entityID to
the right document, and even if that was just a 302 to a more static
location, you've just put a redirector into the middle as the service that
has to be up.

But if we're blue-skying, when I think about hosting metadata at the
endpoints, I don't believe in, nor do I think we can use (because of all the
URNs and so forth), a well-known location. I think InCommon would have to
distribute a mapping file of the indirection from entityID to "something",
and that something could conceivably be hosted anywhere.

That's not what's implemented now, but it's been in my mind as what may have
to get done.

-- Scott





Archive powered by MHonArc 2.6.19.

Top of Page