InCommon metadata support

[Tom Scavo <>]

On Wed, Mar 2, 2016 at 2:00 PM, Wessel, Keith 
<>
 wrote:
> But you understood my point, it looks like. I simply meant that, if the 
> beta MDQ server failed to respond, my IDP would consult the current 
> production aggregate.

Yes, I did understand your point, but the main reason I pushed back is
that the above strategy may not be the best strategy---heck, it may
not even be a good strategy---so I think we need to step back and take
stock. (Btw, you're not the first one to contemplate such a
configuration, so you're in good company :)

> So, I think I'm back to my original question: what can I, as an IDP 
> operator, do to help with this pilot's success? Do you have any specific 
> guidance there?

When in doubt, do what Scott does :-) That is, identify one or more
SPs under your control (as SP owner, not Site Administrator) that will
tolerate a switch to mdq-beta. I'll let Scott describe what he does on
shibboleth.net (although I think he may have already let the cat out
of the bag).

Sorry, that probably isn't what you wanted to hear. At this point,
it's the best suggestion I have. As I mentioned yesterday, as our path
forward becomes more concrete, we'll let you know. We're just as
anxious to get this ball rolling as you are!

Tom

> -----Original Message-----
> From: 
> 
>  
> [mailto:]
>  On Behalf Of Tom Scavo
> Sent: Wednesday, March 02, 2016 12:23 PM
> To: 
> 
> Subject: Re: [Metadata-Support] How to test the per-entity metadata server 
> from an IDP
>
> On Wed, Mar 2, 2016 at 1:11 PM, Wessel, Keith 
> <>
>  wrote:
>>
>> And Tom, given it's a beta, would you call this a good or bad idea
>
> Well, all else equal, I wouldn't do anything until my IdP were
> completely migrated to Shib3. At that point, I would reconsider my
> options.
>
>> assuming I'm using the production aggregate as a fallback?
>
> I hope you'll let me correct your terminology so there's no confusion.
> The fallback aggregate on md.incommon.org is one thing (you can read
> about it here: https://spaces.internet2.edu/x/-oGeBQ) but using a
> chaining MetadataProvider that falls back on an aggregate if query
> fails is another thing altogether. Moreover, the latter is
> experimental in the sense we don't anticipate that will be the
> ultimate method of per-entity metadata refresh. In fact, this is one
> of the things we hope to learn by the end of this pilot.
>
> FYI, here's our working document on MDQ server configuration:
> https://spaces.internet2.edu/x/VQApBQ
>
> Tom
>
>> -----Original Message-----
>> From: 
>> 
>>  
>> [mailto:]
>>  On Behalf Of Cantor, Scott
>> Sent: Wednesday, March 02, 2016 12:08 PM
>> To: 
>> 
>> Subject: RE: [Metadata-Support] How to test the per-entity metadata server 
>> from an IDP
>>
>>> What I didn't realize was that folks were using this beta MDQ server in 
>>> their
>>> production IDPs with the InCommon production aggregate as a fallback
>>> aggregate. I'll need to float that past a few folks around here, but that
>>> certainly seems like a good way to participate in the pilot. So, I think 
>>> that's
>>> the answer I was looking for.
>>
>> I wasn't saying anybody was, I'm saying that's about the only practical 
>> real world test of it that's not all-in.
>>
>> That is what the shibboleth.net SPs are doing, though, and those are 
>> production (but not production in the "I'll get fired if it's down 
>> occasionally" sense, so I wasn't counting them).
>>
>> -- Scott
>>