This page was for GN5-1 and is now outdated. Please go to the GN5-2 page! TII call for Ideas
This page collects proposals for future Incubator activities. Anyone Anyone may add a new idea by adding a new row to the table below.
...
| Table of Contents | ||
|---|---|---|
|
Proposal details:
| Info | ||
|---|---|---|
| ||
The Call for Ideas for the next cycle starting in May is still open. The submission deadline for the next cycle is 08 April 2024. |
| Title | Proposer | Description | Supporter (+1 |
|---|
Scalable testing for insecure SAML signature validation
The SAML 2.0 protocol relies on XML signatures as the foundation of its security. A SAML assertion is signed with XMLDsig and the SP must properly validate this signature. If it does not, basically anyone in the world can trivially provide it with assertions thereby logging in as anyone, which also cannot be easily detected or even seen by the IdP. XMLDsig (and SAML) is notoriously complex and allows for many ways to create one or more signatures for any document. This makes that an implementation can easily fall victim to accepting not properly signed data - and even common implementations in our world like Shibboleth and SimpleSAMLphp have had issues here in the past. Besides these common products, which at least are periodically audited for such problems, a much larger risk is custom implementations that use different or even home grown libraries. Most of the times, the happy path is tested (does login work), but the unhappy path (do invalid assertions fail), not so much.
Some ideas of specific scenarios to test, all of which we've seen in real life to fail:
- Signature not checked at all, modified message accepted
- Modified message with signature rejected, but message without any signature accepted
- Multiple signatures on the same message/signature wrapping attacks
- Correctly signing a part of the message but unsigned part with attributes accepted.
Peter Brand (ACOnet)
Anass Chabli (RENATER)
Automation of
deployment and
configuration
of initial set of SPs
for new federations
Reale
(GÉANT)
While supporting new federations in setting up their infrastructures, IdPs and SPs, generally speaking, we still do not have much automation in place. All is done, still very manually, and takes much time. Talking specifically of the SPs, both for the installation and configuration of the services themselves, and the required operations to federate them (i.e. make them fully functional SAML2 Service Providers), in order to be able to provide them in a federated (e.g.eduAGAIN) fashion, pretty much all is still left to manual set up.
It would be useful to enhance the level of support we provide to them with the aim of quickly being able to deploy an initial set of services, the ones which could de-facto start to attract users towards the newly deployed federation infrastructure and the federated IdPs.
The idea here is to propose a new cycle of T&I incubator task activities aimed at the following tasks:
| ) | |||
|---|---|---|---|
Investigate Google WEI & Apple Private Access Tokens | Mihály Héder (KIFÜ/SZTAKI) | Google Web Environment Integrity is a method for websites to verify that the client platform (User Agent a.k.a. browser + operating system) is indeed genuine and has not been "tampered with". https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md The proposal has received strong criticism, the interlocutors mostly claim that it is just a harmful way of achieving DRM. For a summary, see the Wikipedia entry: https://en.wikipedia.org/wiki/Web_Environment_Integrity The insight of the CEO of Vivaldi browser is especially interesting: they apparently already need to spoof the user agent string in order to be able to use Google Docs, despite the fact that Vivaldi is based on chromium. https://www.theregister.com/2023/07/27/google_web_environment_integrity/ By the proposers it is purported to be a replacement of browser fingerprint-based anti abuse methods. They also claim that it is a better alternative than Apple's Similar Private Access tokens, another attestation scheme that works between Apple devices and Cloudflare. They also claim in defense of WEI that they may help sunsetting the increasingly useless CAPTCHAs. WEI is already supported by Chrome on Android. The proposal is to explore, try out WEI and write a report for the community. Perhaps the timing of this proposed activity is also a strategic concern - if the WEI proposal will have no good reception then there is no point in wasting resources on it, but if it there is uptake then we should reac. | Janos Mohacsi (KIFÜ) |
Scalable, interoperable revocation | Stefan Liström (SUNET) | Revocation is not only a mandatory privacy enhancing feature for endusers, it is also a core security feature. Both use cases for revocation need to be implemented in a future EUDI wallet ecosystem. There is currently however no clear solution for interoperable, scalable revocation in the EUDI. This activity investigates and describes the possible approaches for scalable, interoperable ways to handle revocation. The activity should try to test at least two of the approaches with respect to requirements on scalability and interoperability as may needed for the EUDI | Marina Adomeit (SUNET) |
Passkey registration to User Profile Page (Shibboleth) | Janne Lauros (CSC) | This proposal is continuation to earlier incubator work where User Profile Page for Shibboleth was implemented as means for the user to view the available user data and the tokens issued on behalf of user (https://github.com/GEANT/shib-idp-profile). Shibboleth project is working on WebAuthn authentication flow and has define the scope for the Passkey management as "The inbuilt flow represents the minimum viable product for implementing such a feature. In the future other plugins may provide this functionality". We propose following task for the next Incubator Cycle to provide additional features for Passkey maangement
| Timo Tunturi (Aalto Uni) Mihály Héder (SZTAKI) |
eduGAIN PoC | Davide Vaghetti (GARR/IDEM & eduGAIN), Niels van Dijk (SURF) | The eduGAIN service activity will set up a POC in order to evaluate the new OpenID Federation (OIDfed) standard and wants to eventually create an official eduGAIN Technology Profile to extend the current service. The Trust and Identity Incubator has over the years build considerable experience with developing tooling, and implementing OpenID Fed in various products and languages, as well as evaluating e.g. REFEDs specifications in the context of OIDfed. This activity seeks to contribute to the eduGAIN PoC by:
The incubator will work on these in close collaboration with the eduGAIN PoC team. | |
Implement OpenID Federation into SimpleSAMLphp and Shibboleth IdP | SCRE, CSC, Niels van Dijk, SURF | Related to the above eduGAIN OpenID Federation Pilot, we would like to add OpenID Federation capabiliteis to Commonly used software in our ecosystem. This activity will complete the work on implementing OpenID Federation into SimpleSAMLphp, as well as start with an implementation for Shibboleth IdP. | |
Automatic collection of Verifiable Academic Efforts | Mihály Héder (HUN-REN) | Academic Track Record is the primary source for establishing trust between collaborators that don't know each other. In such events, the researchers are left to check to past affiliations of each other, look for collaborators they shared, see what impactful conference or journal paper the other appeared in, see if the other supervised or reviewed PhDs, postgrads in relevant topics. Hence, a semi-formalized trust chain in established. In order to establish more trust in a researcher account in an academic collaborations, there are several automated actions an AAI platform can take. Commercial (Academia.edu, researchergate, google scholar) and community-owned (ORCID) initiatives already perform very basic collection of information (scraping crossref metadata (DOI)-s and the web). These methods could be much enhanced with more assured information that we have in the Research and Education space and could enrich an institutional or a MyAccessID account, for example. Several parts of this concept has been proven and demonstrated by the various science social networks, like Academia.edu and ResearchGate, who, as soon as a publication appears with a DOI. This is done by regularly scraping the related database, and the same happens for citations. This very often happens with matching of name strings, in lack of better curated attributes in the crossref metadata and results in mis-attributed data. However, other, equally important elements of the record - peer reviews in and efforts service of science, like PhD defense committee membership, and altmetrics (contribution to research software, instruments; confirmed reader counts) are overlooked and the technology for that is only an idea at this moment. A) arXiv API+ORCID: in possession of a verified ORCID, the arXiv API can be queried for articles written by an author: Trust: high arXiv was originally created for physics and is still dominant on that field. Output DOI+publishing place B) Crossref API+ORCID In the crossref JSON metadata, ORCID is present, if it was known
C) DBLP+ORCID on DBLP is possible to search by ORCID D) email based matching E) name based matching trust: low F) Consuming Verifiable Credentials | |
SeamlessAccess with OIDFed Support | Zacharias Törnblom | Primary goal: show OIDC OPs the same way as SAML IdPs - in synergy with the eduGAIN OIDFed PoC project. Secondary goal: use credentials to persist the choice of home organization. |
This proposal is about using a full Incubator cycle to develop an initial solution, work on it, and add some work to design in a clear way how things can be made sustainable after the T&I cycle would be over. More information on the proposal on https://docs.google.com/document/d/1pYN73FEbFApkPNAVgdbNIA1_87ekIEAt8HvzhhXkxrk/edit?usp=sharing
Davide Vaghetti (GARR)
Simple IdM software tailored for R&E institutions
Deploying IdM software from scratch in R&E context is not easy. There are many moving parts, like LDAP, RADIUS, OIDC, SAML that all require their own installation, setup, configuration and maintenance.
Existing solutions are usually a combination of expensive, outdated, complicated, offer limited functionality, not well-matched for R&E requirements, difficult to install, operate, update or deploy securely.
Most solutions are focused on big enterprise deployments with thousands of users, but small(er) organizations are left without an and easy to deploy IdM.
What is needed is software that makes it very easy for small to medium organizations to host and deploy their own IdM which requires minimal babysitting and is easy to configure through the web by designated administrators.
What if you could simply install the software in ~5 minutes and configure it through the web interface in 5 more minutes and updating wouldn't be more complicated than running "apt upgrade" without having to worry about breaking your setup?
More details on the proposal can be found here: https://cryptpad.fr/pad/#/2/pad/view/H9LhKlsbHVmYYptrQnTzOwRmlfRrVGeV5PnBowJZpvg/
Anass Chabli (RENATER)