The scope part of attributes means critical security context for many applications. Currently the only way for an SP to check whether an IdP is allowed to use a scope is based on verification of shibmd:Scope metadata extension. As metadata might  originate from a massive number of sources, an organization and/or an SP might want to provide additional means to verify scope usage. If the scope equals to a real domain name, it can be easily implemented by adding TXT records to the domain record that describe the allowed entityIDs which can assert the scope. (Similar to SPF - Sender Policy Framework.) This should be an optional measure in addition to existing metadata-based scope verification technique.

standardization - REFEDs?

implementation for Shibboleth and SimpleSAMLphp

Nick Roy, InCommon

Constantin Sclifos, RENAM

Rhys Smith, UKf: Sounds like an interesting idea. Would require changes to SP software though, of course, which means it'd be a very long term rollout. Worth exploring the idea in principle though.

SURFnet: Can this be solved by making this the responibility of the registar. Speaking for a hub-and-spoke registrar that already does it this way, forcing IdPs to administer TXT records for this is quite a burden for them.

Kristof: the concept is to provide an end-to-end solution to protect the scopes that works even with broken metadata sources/registrars.

Nick Roy, InCommon

SURFnet

Rhys Smith, UKf: +1 in principal, but reserving judgement until we see the output of RA21 to be able to understand the scope of this.

The eduGAIN technical website would benefit it's members by having a central overall status dashboard that renders a single page with eduGAIN stats with initial focus on latency estimates for metadata circulation. This page should auto-refresh every X seconds/minutes as a configuration. It would be a 'nice to have' if this were operationally friendly such that someone could have it presented in their NOC control center on a screen and also have the data published at an API endpoint such that someone can publicly poll the information in JSON and then in turn render it on their own.

The problem this addresses is the knowledge gap about the state of the system without requiring operational questions or gueses. Many federations exhibit latency on republishing stemming from operational practices and offline signing techniques. It would be helpful to know in a dashboard fashion the following:

• Last update of mds.edugain.org
• And per federation last known update of eduGAIN data and time difference since MDS publishing (inferred by eduGAIN ops tools based on publishing practices in a best effort style calculation)

This will go a long way in managing expectations of when to expect data to circulate beyond '24-48hrs'. I suggest a simple table view of flag and age difference from MDS so we may know how far we all drift from each other republishing data from the eduGAIN MDS 'creation date'.

CAF, obviously

SURFnet

Rhys Smith, UKf: We've actually just been talking about how something like this would be good. I'm sure Sirtfi folks would be interested in this as well as it directly impacts on the time to full resolution for security incidents mitigated by MD changes.

The most interesting session that I had at TechEx 2017 ACAMP was

The most interesting session that I had at TechEx 2017 ACAMP was asking "How do students federate an application?" with Fed-Lab.org and TestShib.org existing - but not solving all of the edge cases for new applications and especially new developers.

A student can pick a framework off the self - run through tutorials and then connect their application to a host of services (Github, Twitter, Facebook) but SAML often isn't an option - and even if it is - there is a lack of enviornments that a student/new developer can jump into to make their tool work. This needs to be solved to support new developers, create a sandbox for development and expose SAML integration for various frameworks.

Include OIDC

Schema standardisation - MACEDir is being rechartered, there is eduPerson,

Schema standardisation - MACEDir is being rechartered, there is eduPerson, SCHAC, where is the global conversation taking place in the eduPerson?

Ability to leverage the relationships with Microsoft and ADFS - Attempted for many years to influence microsoft to improve ADFS not very successful. We need as a global edu community to have some more leverage.

Thomas Lenggenhager (SWITCH) provided you are careful not to annoy the security contacts

Wolfgang Pempe (DFN): our plan is to perform some test alarm at least once a year

Tom Barton: +1, and let's try to ensure that each contact is tested by only one testing activity, ie, perhaps the Geant activity should be formulated as a complement to other activities that are/will test contacts in their federations/areas.

Scott Koranda for LIGO +1

Rhys Smith, UKf: Exactly the same comment as Thomas. Good idea in principal, but have to be VERY careful not to annoy security contacts, as they'll stop responding in a timely manner if all they generally get is test messages. Would suggest consultation with CSIRT folks about how they do this today, and follow that model.

(Wolfgang Pempe, DFN: outside federation metadata? IMHO not a good idea. This would lead to inconsistencies.)

Tom Barton: Once Wolfgang hears the details, he'll say it's a good idea!

Lukas Hämmerle, SWITCHaai: I don't exactly see the need for a query service if this information can be relatively easy retrieved from metadata. Then again I suspect this would be relatively easy to implement and given that there is already an API (https://technical.edugain.org/api.php) to query all sorts of eduGAIN-related things, this would probably be only  a small addition. (Comment from Scott Korand to Lukas–it cannot be easily retrieved from metadata because not enough federations are mature enough to support entitites registering Sirtfi. The descrition includes "outside federation metadata" as it should.)

SURFnet:

• Niels van Dijk: An independent registry outside of eduGAIN may carry a different trust level, and hence could be a resolution to challenges around mixing data with different trust levels. I therefor do not think this is the same thing as "Allow eduGAIN OT to enrich MDS metadata" below.
• -1: Many doubts. Sounds like an shadow metadata registration and/or confusion of the aggragator / registration roles (Pieter van der Meulen)

Scott Koranda for LIGO +1

With eduroam Managed IdP, there is a service which takes all RADIUS hassle off of Identity Providers. There is no equivalent for eduroam SPs. I.e. a future eduroam SP either needs to set up a local RADIUS server and connect it to the NRO, or (if the NRO supports it) connect the Wireless Controller directly to an NRO server - losing all advanced features such as VLAN assignment. For small hotspots, there is a possible additional complication if the hotspot has a dynamic IP address, which makes the interconnection via RADIUS' shared secrets infeasible. Right now, such potential hotspots are not serviceable by eduroam infrastructure.

The goal of this activity is to create a self-service web portal where any prospect SP can register his hotspot (requiring sign-off by the NRO; comparable to eduroam Managed IdP) - regardless whether he has a static IP address, a dynamic one, or doesn't even know what an IP address is in the first place. The new hotspot's RADIUS connectivity is tested in real-time (e.g. using a credential from eduroam Managed IdP, a good complement to this service) and the new SP is instantly connected to the eduroam infrastructure. Where the NRO admin confirms that a particular hotspot maps to a specific realm or Managed IdP instance, the SP can even get VLAN ID assignments for his own users (that part of the use case is possibly a bit weak as an SP who does not know about setting up a RADIUS server likely also doesn't know about VLANs to begin with).

For the technicalities of the uplink itself, there should be support for multiple attachment anchors (=RADIUS servers behind the web interface) because geographical proximity to the hotspot is important for performance reasons.

The remaining complexity for the SP which this service will not take away is: phyiscal installation of APs, controllers, and the configuration of those so that they are providing proper local eduroam.

To ensure service quality on such "no clue" SPs, it could be made mandatory to install a probe at the site so eduroam Operations can monitor the hotspot quality.

VM for web interface, VMs for RADIUS attachment anchors, a clever idea how to handle registering hotspots with dynamic or unknown IPshotspots with dynamic or unknown IPs