An open discussion list for topics related to the eduGAIN interfederation service.

["Nicholas Roy" <nroy AT internet2.edu>]

On 11 Mar 2020, at 2:49, Alan Buxey wrote:

> hi,
>
>> We are shutting down our old metadata service on March 1, 2021. We’ll
>> still offer aggregates (regular and IdP-only) in the new service as
>> required by the MDQ protocol, but we should probably start thinking of
>> how to sunset that requirement at some point, or transition it to simply
>> a list of entityIDs.
>
> as noted in another discussion, there is a need for a minimal feed of
> information
> to provide discovery services with key information on which IdP or SPs to 
> offer.
> (eg not just the entityID but also entity categories, name , HfD etc)
> .  otherwise
> to build a DISCO service you would need to hit the MDQ for each entityID or
> for the 'all' parameter - which would cause load/bandwidth use and
> just be another
> version of large aggregate xfer

Yes. This is why I said we need to figure out a way to move off of the "full 
aggregate" version of /entities in MDQ. Since I’m using a CDN, I don’t care a 
whole lot about download sizes or bandwidth, until it starts costing a lot of 
money (a point which we are very far away from).

I think pointers to metadata in the form of lists of entityIDs produced in 
response to actual query parameters (search predicates) are probably 
sufficient.

"Give me all REFEDS R&S IdPs" ---> OK here’s a list of those entityIDs ---> 
SP then does what it needs to do to construct a local cache of discovery 
information.

Push MDQ, which Niels’ incubator team is working on, is another possible 
solution. SPs and other deployments subscribe to feeds of metadata that they 
care about and get those changes pushed to them.

Nick

>
> alan

Attachment: signature.asc
Description: OpenPGP digital signature