...
| Title | Scope verification based on DNS |
|---|---|
| Description | 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. |
| Proposer | Kristof Bajnok (eduID.hu) |
| Resource requirements | standardization - REFEDs? implementation for Shibboleth and SimpleSAMLphp |
| +1's | 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. |
| Comments | 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. Wolfgang Pempe, DFN: "can be easily implemented" sounds harmless, but carrying this out on federation level implies contacting several hundreds of IdP operators and providing support to them... |
| Title | Statistics for federation |
|---|---|
| Description | Development of statistical solutions for federation that show the number of federated accesses from the member institutions of a federation, besides the indication of the most accessed Service Providers. |
| Proposer | Jean Carlo Faustino |
| Resource requirements | Standardisation and collaboration |
| Comments | Wolfgang Pempe, DFN: How is this supposed to work for a full mesh federation? |
| +1's |
| Title | SOC tools |
|---|---|
| Description | GEANT should develop and maintain a toolchain for security operations (SOC) teams. This includes work on stuff like grr, plaso, timesketch, information sharing platforms, threat intelligence platforms etc |
| Proposer | Leif |
| Resource requirements | To be better scoped, but certainly resources. |
| +1's | This is similar to a proposal submitted under the security white paper planning. Talk to Sigita Jurkynaite about this. |
| Comment | SURFnet: We support the notion of having good security operations in trust and identity but in the geant project this should probably be developed in the security activity. Rhys Smith, UKf: Agree with SURF, sounds interesting, but isn't this a security area topic? |
...
| Title | Identity Discovery |
|---|---|
| Description | GEANT should operate a discovery service for the global identity ecosystem based on the outcomes of the RA21 process and dialogues with the research infrastructure community. If possible the service should be useful for the eIDAS community aswell. |
| Proposer | Leif |
| Resource requirements | To be better scoped, but certainly resources and budget |
| +1's | 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. Wolfgang Pempe, DFN: agree with Rhys. An embedded DS should always be the first choice, anyway. |
| Title | Enhance eduGAIN ops instrumentation with general metadata dashboard and augment existing eduGAIN API to query said stats |
|---|---|
| Description | 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:
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'. |
| Proposer | Chris Phillips, CANARIE |
| Resource requirements | This is an effort item, likely on eduGAIN OT with some API work too. I estimate it to be small (few days/1 week?), but highly useful and potentially a marketing tool as well. |
| +1's | 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. Wolfgang Pempe, DFN |
| Title | A Global Trust & Identity Management Lab Platform |
|---|---|
| Description | 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 |
| Proposer | Brook (stolen from Andre Marins idea @ TechEx ACAMP 2017https://docs.google.com/document/d/1mvD27mGJQIkvaqXESijDKWrYKvF_ZlC-Ucb-gWRCJjo/edit ) |
| Resource requirements | |
| +1's | |
| +/-1's | Potentially a nice idea, but would need to consider the use cases more to decide whether i'm +/- 1 on this - if there would be enough users, and it'd be useful enough to them, then +1. Otherwise, it's a distraction. |
...
| Title | Schema Standardisation |
|---|---|
| Description | 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. |
| Proposer | from data gathering exercise |
| Resource requirements | <money? effort? coordination? infrastructure?> |
| Comments | Wolfgang Pempe, DFN: not really a GÉANT topic |
| +1's | probably for REFEDS? |
| Title | eduTEAMS and guest IdPs |
|---|---|
| Description | eduTEAMS and guest IdPs - use-cases: need to support social IDs and guest IdP, but it need additional LoA. Step up authN as a service is in the plan |
| Proposer | from data gathering exercise |
| Resource requirements | <money? effort? coordination? infrastructure?> |
| +1's | isn't this the work being done in IoLR +REFEDS? |
...
| Title | Central/federated ticketing system for eduGAIN Operators |
|---|---|
| Description | I know the eduGAIN support team already uses a TTS, but I think we could go a step further and have a central TTS with federated access support, to track issues with the appropiate persons from any of the involved parts. The service should be able to gather information from metadata, including federation operators, and all entities participating in eduGAIN contacts. Of course, these tools would also use e-mail as a communication channel. |
| Proposer | José Manuel, SIR/RedIRIS |
| Resource requirements | Not quite sure if this could mean upgrading the eduGAIN support TTS, or create a new one from the start. |
| +1's | José-Manuel, SIR/RedIRIS Jose Manuel Macias Luna: What is a TTS? → a.k.a. Trouble Ticketing System... I don't like the first T though... |
| -1's | Wolfgang Pempe, DFN: I see no need for this. Most federations operate their own TTS. I would leave the eduGAIN-related issues to the eduGAIN support team and everything else to the federations' support desks. |
eduGAIN Maturity
| Title | Response Testing for Security Contacts |
|---|---|
| Description | Simple response testing process for security contacts in federation metadata. Could replicate the process currently used by Trusted Introducer. |
| Proposer | Nicole Harris |
| Resource requirements | money, infrastructure |
| +1's | 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. |
...