InCommon metadata support

[Mike Flynn <>]

Thanks, Tom.  After we were acquired my email changed.  I'll unsub the old one.  I will wait until all the SAML 1 folks are in the mix to drop the UK MD.  Thanks everyone!

On Thu, Feb 25, 2016 at 1:40 PM, Nick Roy <> wrote:

The other approach would be to analyze the list of IdPs published in the UKf aggregate and the InCommon aggregate for any missing entity descriptors of Lynda customers.  If there are none, you can choose which ever you'd like to use, but as Tom and Ian have said, that choice should probably align with your home federation- that actually simplifies things.  You'd just need to check the InCommon aggregate for missing IdP partners from the UKf.  If any are found, I'm guessing they will either be in the rapidly shrinking subset of  Eduserv SAML1-only IdPs, or they could probably be cajoled into choosing to export.



Nick

On 2/25/16, 2:29 PM, " on behalf of Tom Scavo" < on behalf of > wrote:

>On Thu, Feb 25, 2016 at 1:46 PM, Mike Flynn <> wrote:
>> I thought I was subscribed.  I was still getting the emails.  Anyway,
>> resubscribed now.
>
>I think you're using two different email addresses. If that's true,
>then you need to subscribe twice.
>
>> I guess my home would be InCommon.  So are you saying I
>> can drop the UK fed metadata loading on my SP as I will pick up all the UK
>> Fed's IDPs via the new InCommon metadata that has eduGAIN in it?
>
>Yes, that's what I'm saying but read Ian's reply closely. It's not
>"all the UK IdPs" but "most of the UK IdPs." That may or may not be an
>interoperability issue for you. I guess you could try it and see what
>happens.
>
>Tom
>
>> On Thu, Feb 25, 2016 at 9:53 AM, Tom Scavo <> wrote:
>>>
>>> [Mike, can you please subscribe to this mailing list?]
>>>
>>> On Thu, Feb 25, 2016 at 12:26 PM, Mike Flynn <> wrote:
>>> > Well... as an SP, I load UK Federation and incommon which include
>>> > edugain.
>>> > InCommon is my home since I am US based.  It's just taking a really long
>>> > time to load this stuff now. if there is redundancy I want to eliminate
>>> > it
>>> > if possible.
>>>
>>> We're talking about two different things here. Ian and I were
>>> discussing the metadata you publish to the world. Currently you have
>>> at least two metadata sources to maintain. Ideally you should have ONE
>>> global metadata source.
>>>
>>> OTOH, you're asking how to configure your SP for metadata refresh (I
>>> think). If you are currently loading both the UKf metadata file and
>>> the InCommon metadata file, yes, your system is doing a bunch of
>>> unnecessary work. You should load just one of those files. Which one
>>> depends on your "home" federation.
>>>
>>> Hope this helps,
>>>
>>> Tom
>>>
>>> > On Thu, Feb 25, 2016 at 9:18 AM, Ian Young <> wrote:
>>> >>
>>> >>
>>> >> On 25 Feb 2016, at 16:48, Mike Flynn <> wrote:
>>> >>
>>> >> Since the UK federation now includes InCommon, can I drop the separate
>>> >> loading of InCommon?
>>> >>
>>> >>
>>> >> You almost certainly don't need to load both, but you can probably pick
>>> >> either to load as both federations have an opt-out policy for IdPs.
>>> >>
>>> >> There will be some IdPs that appear in one federation aggregate but not
>>> >> the other, and you should check those against your customer list before
>>> >> deciding. For example, there are still a number of SAML 1 only IdPs in
>>> >> the
>>> >> UKf which don't appear in InCommon at this point, but the great
>>> >> majority of
>>> >> those are part of a service run by Eduserv which are being converting
>>> >> to
>>> >> SAML 2 at a pretty rapid rate. So within the next couple of months, the
>>> >> UKf
>>> >> and InCommon aggregates will have very similar IdP collections.
>>> >>
>>> >> In the long run, obviously what we all want is that you'd pick the
>>> >> federation which is most obviously your "home" federation, register
>>> >> with
>>> >> that and get global reach by just consuming metadata from that single
>>> >> source. We're probably closer to that point than you might think.
>>> >>
>>> >>     -- Ian
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Mike Flynn
>>> >
>>> > linkedIn / lynda.com
>>> >
>>> > Internal Extension: 359
>>> > O. 805-755-1515
>>> > C. 805-990-4566
>>
>>
>>
>>
>> --
>> Mike Flynn
>>
>> linkedIn / lynda.com
>>
>> Internal Extension: 359
>> O. 805-755-1515
>> C. 805-990-4566

--

Mike Flynn

linkedIn / lynda.com

Internal Extension: 359

O. 805-755-1515
C. 805-990-4566