You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 72 Next »


To propose a new idea, copy and paste the table below.  Ideas don't need to be fully formed but the more scope we can get the easier it will be to assess whether idea should be taken forward.  

Anything in the Trust and Identity space is of interest, from improvements to current services to brand new ideas and technologies.

If your idea already exists in the suggestions, you can just add a +1 for endorsement.

Template

Title

<title of your proposal here>

Description<description text here>
Proposer<your name here>
Resource requirements<money? effort? coordination? infrastructure?>
+1's<for others to voice their support - add your name here>


Proposals

Title

Statistics for federation

DescriptionDevelopment 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.
ProposerJean Carlo Faustino
Resource requirementsStandardisation and collaboration
+1's
Title

Global Push-MDQ Infrastructure

DescriptionBuild a global, shared infrastructure for federations to submit/publish per-entity metadata to eduGAIN, and have those updates be pushed via messaging infrastructure to subscribers. This will enable more rapid metadata updates and a global per-entity metadata distribution infrastructure. It should be possible to accommodate multiple federations submitting/publishing metadata for the same entityIDs, and consumers can subscribe to whichever version they choose. NOTE: This may also facilitate a solution to IdP discovery in a per-entity metadata world.
ProposerNick Roy
Resource requirementsMoney, effort, standardisation, coordination, infrastructure, operations
+1's Chris Phillips - CANARIE – see related collab area: https://wiki.refeds.org/display/GROUPS/Incubator
Title

Response Testing for Security Contacts

DescriptionSimple response testing process for security contacts in federation metadata.  Could replicate the process currently used by Trusted Introducer.
ProposerNicole Harris
Resource requirementsmoney, 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


Title

Query service for Sirtfi

DescriptionAPI to query whether an entity supports Sirtfi. In addition, a mechanism for asserting Sirtfi compliance outside federation metadata.
ProposerHannah Short (with Nicole Harris and Ann Harding)
Resource requirementsmoney, infrastructure
+1's

(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! (smile)

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



Title

Reputation Portal

DescriptionA way to flag bad (or good!) behaviour of entities, e.g. Sirtfi compliance, LoA misuse, CoCo violation
ProposerHannah Short (with Nicole Harris and Ann Harding)
Resource requirementsmoney, infrastructure
+1's

Scott Koranda for LIGO + 1

-1'sSURFnet: Sounds like trying to solve a non technical problem (trust) using technology
Title

Last_seen()

DescriptionFederated AAI is poorly equipped to support SPs in dealing with the depreciation of users by the IdP. Outside of at login time, the SP basically has no way of finding out the user is no longer a user at an institution, save perhaps sending out emails. A mechanism to allow SPs to learn about a user status would help SPs immensely to keep data accurate and at the same time improve privacy and data protection. This activity should investigate push and pull scenarios and propose and implement example solution(s), in collaboration with entities that produce commonly used software products in our space. Retaining the privacy of the enduser in the process is paramount!
ProposerNiels (SURFnet)
Resource requirementsmoney, software dev, standarization
+1's

Wolfgang Pempe (DFN): the current approach (at least in our federation) is to perform periodical attribute queries with SAML2 Persistent NameID, which leads to quite some problems.

SURFnet: +1



Title

eduGAIN Federated Service Catalog

DescriptionAt the moment, the only way you get an overview of services in eduGAIN is via metadata. While this is how the system is designed to work (machine to machine), service info is also interesting to humans e.g. to browse, to know if an SP already exists etc. A preliminary WG is starting in REFEDs to look at how service catalogs could be built. An eduGAIN level catalog should build on that work and also integrate with other relevant catalogs e.g open science cloud, NREN's own catalogs etc.
ProposerAnn Harding
Resource requirements

Standardisation/spec via refeds

Prototype implemention for aggregation.

Protoype implementation for federation level infra.

Pilot.

+1's

Wolfgang Pempe (DFN): encourage cross-federation support for mdui:Keywords.

SURFnet: no catalog will survive if the (meta)data is not/cannot be maintained or is not of sufficient quality. I think therefore we need to address the root cause (as well). How prevent keeping a shadow "metadata" registry for this?

José Manuel, SIR/RedIRIS: We are developing such a service catalog for our federation now, and am interested in this. Also, agree with Wolfgang, and SURFnet... regarding the SURFnet question, the catalog could have both "static" (collaborative information, with the possibility of letting the providers administrate its own information) and "dynamically gathered" information (from metadata) for a certain entity in the catalog.

Title

Storing History and Evolution of Metadata in a Distributed Ledger

Description

The aggregated metadata of eduGAIN is under constant change as entities get added, removed, or changed. While daily backups are made, there is no event-based changelog and no trace of which change was made when. When an entry of interest is examined, the search for the exact event timestamps of changes pertaining to that entry are tedious by searching old copies of the entity database manually.

The proposed system stores any change to the metadata aggregate one-by-one in a ledger as soon as it happens. That way, even intra-day changes (between daily database backups) can be observed and a "rewind" of the entity list to specific point in time becomes simple.

For improved traceability of any changes, the ledger can be made distributed and authenticated in the way that both the publishing eduGAIN participant (sending side) and the eduGAIN OT (receiving side) both sign the change in a distributed ledger.

The ledger would be distributed so that each eduGAIN federation maintains a copy. With that, changes made automatically synchronise between federations and a manual polling of per-participant feeds (by eduGAIN OT) as well as a periodic download of the aggregate (by eduGAIN participants) becomes superfluous.

eduGAIN OT still maintains its role as metadata policy verifier by signing only such changes in metadata which result in eduGAIN policy conformant metadata. As a positive side-effect, this changes the granularity of metadata rejection from a per-participant (country-wide) effect to a per-entity effect, reducing outages due to metadata of entire participant federations vanishing.

The solution developed here is not limited to eduGAIN exclusively; it can also be used inside a federation to collect and sign individual pieces of metadata, thereby assembling its own metadata set in the same way.

Where IdPs or SP choose to maintain a copy of the ledger, they can immediately and in real-time see any changes and implement them in their entity; resulting in an experience similar to the MDX proposal above. They can choose to incorporate only entries signed by their own federation, or a superset to their liking.

ProposerStefan Winter (RESTENA)
Resource RequirementsVMs, storage for the ledger, a blockchain implementation, someone to work on that so it fits our needs
+1's
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.

ProposerKristof Bajnok (eduID.hu)
Resource requirements

standardization - REFEDs?

implementation for Shibboleth and SimpleSAMLphp

+1's

Nick Roy, InCommon

Constantin Sclifos, RENAM

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.

Title

Adoption & Outreach Support for eduGAIN BCP

DescriptionBCP for eduGAIN will be launched in 2018. Federations should be supported to gain adoption by campuses
ProposerAnn H on behalf of several
Resource requirementsFunding for outreach and adoption efforts at each GEANT partner, strategic/materials support for all.
+1's

Nick Roy, InCommon, SURFnet


Title

Reference implementation of an IdP and OP in Python

DescriptionThe current GN4-2 projet has invested heavly into the Python stack for OpenID Connect (federation) and it should be good to put together a full blown home organisation IdP/OP based on this work and earlier work with the SAML stack. This imlementation should support all current best practices in eduGAIN and retrie attributes from different sources.
ProposerPål Axelsson on behalf of Sunet
Resource requirementsmoney, software dev
+1's

Stefan Winter

Nick Roy, InCommon

Niels van Dijk, GEANT 4-2 Project; This should be carried out in close collaboration with the pyid.org community


Title

Allow eduGAIN OT to enrich MDS metadata

Description

Currently, metadata is controlled exclusively by federation operators, which is generally good. However, there will pop up use-cases where it is more efficient, a lot faster and definitely more agile to allow eduGAIN OT to enrich eduGAIN metadata centrally with some entity categories because if all 50+ federations have to do something, it will take years and effort to set some entity category is duplicated for each federation.

ProposerLukas Hämmerle, SWITCH
Resource requirementsPolicy might need to be changed, it would have to be defined what/what not eduGAIN OT reasonably could and should do. Some (limited) implementation effort on MDS might be needed.
+1's

Nick Roy, InCommon

Tom Barton: Although "Query service for Sirtfi" above is formulated as a query service, it might best be implemented as an enrichment by eduGain OT to metadata. Should these two proposals become one?

Niels van Dijk, SURFnet: I would be really interested in how distributing the trust between decentralized federations and central OT would work.

Hannah Short, CERN

Constantin Sclifos, RENAM

Scott Koranda, LIGO

-1'sSURFnet: Many worries: role of aduGAIN of aggregator that is now going to modify metadata (SURFnet)


Title

Discovery for Attribute Authorities (AAs)

Description

Users can select their IdP via discovery, therefore the SP can potentially receive users from thousands of IdPs.

There is no such facility for AA-s however, meaning that SP-s need to hard-configure which AAs they query. Also, query all the configured AAs for all users all the time.

In GN4-1-JRA3-T1 it has been established that this is a serious bottleneck, as maximum 2-3 AAs can be queried without breaking the entire login session.

A better approach is needed. The SPs need to query AAs selectively, based on either user input or some alternative means, like some VO lookup service. Otherwise all SPs will just stick with the biggest AAs like eduTEAMS basic membership service or hexaa.eduid.hu and not query alternative entities, making single-tenant AAs very unattractive.

ProposerMihály Héder
Resource requirements

This is a hard one. Currently there is no support for any elements of this whatsoever

  • Standardization
  • SAML Stack development
  • blood and sweat
+1'sConstantin Sclifos, RENAM
Title

Attribute Authority scoping information in Metadata

DescriptionIt seems that AARC-JRA1.4A will propose "scoping of group membership information". However, there is no element in the SAML metadata that contains the scope of an AA, therefore, there is nothing to verify the scoped membership information against. The only way today is to learn about the scopes used by an AA entity via word-of-mouth and then apply those scopes in attribute value level filtering and access control rules, maintained manually in the SP config. Obviously this does not scale.
ProposerMihály Héder
Resource requirements
  • Standardization
  • SAML stack development
+1's
Title

eduroam SP-as-a-service

Description

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.

ProposerStefan Winter
Resource requirements

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

+1's<for others to voice their support - add your name here>
Title

Attribute Authority Metadata policy development for eduGAIN

Description

While for IdPs and SPs eduGAIN metadata requirements are well described, no such requirements exist for AAs. We have however already 5 of these entities in eduGAIN.

It would also be a good idea to consider/define what it would mean for an AA to claim CoCo, R&S and Sirtifi support

ProposerNiels van Dijk
Resource requirements
  • Standardization
  • Probably a no-brainer as much can likely be derived from IdP requirements (?)
+1's

Constantin Sclifos, RENAM

Nick Roy, InCommon

SURFnet


Title

update SAML tracer

Description

The SAML Tracer (https://addons.mozilla.org/nl/firefox/addon/saml-tracer/) is a highly rated firefox plugin which was developed in our community (UNINETT, with contributions from others). As the browser is the central entity in any SAML transaction, it is extremely convenient tool for testing en debugging SAML transactions. There are not many alternatives to this tool

Unfortunately, Firefox has changed its plugin framework, rendering the existig plugin useless and a major rework is needed.

ProposerNiels van Dijk, SURFnet
Resource requirements

Money, a (junior) developer

+1's

Stefan Winter

Scott Koranda, LIGO

Nick Roy, InCommon

Thomas Lenggenhager, SWITCH:Feasibility to provide also a Chrome and/or Safari compatible version?

Pieter van der Meulen (SURFnet)

Michael Domingues (University of Iowa)

José Manuel, RedIRIS/SIR. Regarding Thomas question, there's a SAML Chome Panel extension for Chrome

Title

Investigate and test privacy enhancing technologies

Description

During REFEDs at TechEx2017,and later-on during TechEx2017 itself, a interesting discussions developed over the future of federation, the role of users and the use/rise of proxy technology.

This activity investigates and showcases privacy enhancing technologies including, but not limited to, PEP (Polymorphic Encryption Pseudonyms) (1) and IRMA (I reveal my attributes) (2) and tests and validates applicability and usecases of these in the context of R&E federations and eduGAIN.


SURFnet has build some experience with these technologies on a national level, and has for example implemented PEP into commonly used software products like ADFS, Shibboleth and SimpleSAMLphp. In regard to IRMA, it has now been enable in pilot for both SURFconext federation as well as the IDIN Bank ID federation. We feel these technologies have significant promise, but would like to validate this in international context. We would also like to learn about other alternative strategies and solutions that may help us to shape the future of our identity federations.

ProposerNiels van Dijk, SURFnet
Resource requirements
  • Other technologies to showcase other then PEP and IRMA
  • Participants for pilots
  • People with good ideas
+1's(SURFnet)
References

(1) https://blog.surf.nl/en/privacy-surfconext-using-polymorphic-pseudonyms/

(2) https://privacybydesign.foundation/irma-en/

Title

Identity Discovery

DescriptionGEANT 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.
ProposerLeif
Resource requirementsTo be better scoped, but certainly resources and budget
+1's

Nick Roy, InCommon

SURFnet


Title

eduroam DEEP Learning

DescriptionBased on Brooks idea, we train a DEEP network to detect eduroam 
breakage based on log-data. Possible joint work with Juniper Research. 
Leif will provide more information
ProposerLeif
Resource requirementsTo be better scoped, but certainly resources.
+1's

I'll give this one a "sounds cool, need more info" Nick Roy, InCommon

Can be integrated via existing diagnostics context: Existing work evaluation#eduroamdiagnostics so gets a +1 from prior endorsements too. (note from AH)

Should x-ref with the network perf folk. Talk to Kurt Baumann(Note from AH).

Georgi Tsochev, BREN 



Title

SOC tools

DescriptionGEANT 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
ProposerLeif
Resource requirementsTo 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.

CommentSURFnet: 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.


Title

IdP Maturity

Description

In the current eduGAIN SAML Profile work there is an effort to develop BCP to position a lot of the current "step-up" processes we have as a set of best current practice for eduGAIN.  Within eduGAIN, these will be positioned as what we consider mature entities  / federations to look like...and this could even possibly be flagged somehow.  The current requirements of eduGAIN will be promoted purely as a baseline and a "first step" to interoperability (acknowledging use cases that don't need any more than that).  The next logical step from that is to review whether there is any need to offer a central service to manage that maturity level for federations / entities as a bolt on to existing federation operations. This could take on a variety of forms and draw in a lot of the areas that have been proposed here. Options and areas could be:

- More work on the eduGAIN technical database to flag maturity for federation / entities.
- Establishing a REEP instance to allow entities to flag maturity when a federation is less developed.
- Allowing eduGAIN OT to decorate entities with additional information.
- Developing processes to allow MDS to select the most mature entity formulation within federations rather than simply the first submitted.
 -More advanced eduGAIN (including IdP certification, IdP categorisation, ...)
 -Standardise MRPS use
 -Standardise metadata publication practice

ProposerNicole Harris
Resource requirementsIt depends on the direction taken. Man hours in eduGAIN-OT for developing services, work for a policy lead, work to enhance eduGAIN support service. Possible infrastructure development
+1'sNick Roy, InCommon
CommentsSURFnet: It is unclear to us what is the purpose for this work and who will be the users.



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:

  • 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'.

ProposerChris Phillips, CANARIE
Resource requirementsThis 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 (smile)

SURFnet

Title

Scale eduroam infrastructure to the size of WIFI4EU

Description

There were a multitude of reasons why the GÉANT community couldn't run the infrastructure for WIFI4EU.

Sufficient issues were exposed by managing this as a single centrailsed infrastructure (partially addressed by "get eduroam", "eduroam DEEP Learning", "eduroam SP-as-a-Service"). By identifying all the scaling blocks to existing eduroam services we'd be able to offer advice, guidance and technology push into govroam, WIFI4EU and eduroam services to support the existing infrastructure and development in new territories.

ProposerBrook
Resource requirementsPeople
+1'sGeorgi Tsochev, BREN
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

ProposerBrook (stolen from Andre Marins idea @ TechEx ACAMP 2017https://docs.google.com/document/d/1mvD27mGJQIkvaqXESijDKWrYKvF_ZlC-Ucb-gWRCJjo/edit )
Resource requirements
+1's
Title

Jupyter Notebook for Metadata Management + Decoration

DescriptionThe predominate metadata aggregator used by federations joining eduGAIN is pyFF.io and having a Jupyter Notebook to allow these people to work through the metadata aggregation, selection or exclusion and decoration would be useful in training people to use this tool.
ProposerBrook
Resource requirementsPeople smarter than Brook, time, money
+1's
Title

Two Factor (something)

Description
  • Drive two factor towards ubiquity with low cost - create an eduToken (for the users that do not have a phone; critical mass can bring down the price even more. It can be implemented as a kickstarter campaign).

    • Challenges in deploying multi-factor in EU, partially due to the costs and partially due to the cost involved. A cost-effective approach would help.

    • An edu-token  as  a separate ‘token’ may reintroduce token management aspects (losing the token etc)

    • management is (will be even more) a non issue as the majority of people will use phones. We should strike for that.

    • Technically this problem can be solved, taking the above considerations into account.
      The real problem is how to scale the token vetting over EU. This is especially challenging for research collaborations.
ProposerFrom data gathering exercise
Resource requirements<money? effort? coordination? infrastructure?>
+1's<for others to voice their support - add your name here>


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.

Proposerfrom data gathering exercise
Resource requirements<money? effort? coordination? infrastructure?>
+1'sprobably for REFEDS?


Title

eduTEAMS and guest IdPs

DescriptioneduTEAMS 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
Proposerfrom data gathering exercise
Resource requirements<money? effort? coordination? infrastructure?>
+1'sisn't this the work being done in IoLR +REFEDS?
Title

certbot for all certificate management

Description

Let's Encrypt and the certbot have made certificate management for 1 particular CA very easy and effective. With the addition of ACME v2 this will allow additional CAs to participate and allow the dev/test/production environments to automatically deal with certificates.

Work should also investigate eduPKI and Let'sRADSEC use of this mechanism for certificate maintenance.

TechEx 2016 ACAMP notes: https://docs.google.com/document/d/1o20NmuLjmNySp10QqfueO3of6jmoeTRfmgG4e_olZ_s/edit

ProposerBrook (and a cast of thousands)
Resource requirementsPeople, Money, work to get standardisation of "realm validated certificates via RADIUS infrastructure" and maybe other paths.
+1'sGeorgi Tsochev, BREN
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.

ProposerJosé Manuel, SIR/RedIRIS
Resource requirementsNot 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...

You do not have to fill in every field, just give as much detail as you have right now if you know them.

  • No labels