Page History

Satellite eduroam (satroam..?) development

David Patterson

Authenticating to eduroam over Low Earth Orbit (LEO) satellite connectivity has the potential to extend connectivity to areas with no infrastructure, or where 4/5G mobile coverage is poor.  Satellite eduroam (satroam) could enable NRENs to provide secure connectivity for emergency medicine, disaster relief, environmental research, and addressing the digital divide in marginalised regions. 

The proposal is for Jisc to coordinate the following activity:

• Coalition. Establish a small-scale collaboration with up to 3 additional NRENs to share expertise and insights, and help shape the future development of satroam 
• Testing. Support proof-of-concept testing of satroam, to include: authentication processes; alternative LEO providers; diverse geographical regions; end user groups.
• Use cases. Produce examples of satroam, and identify future areas of investigation.

This follows proof-of-concept testing, conducted in partnership with KENET (Kenya), as part of the GÉANT Twinning Programme: How Jisc and KENET extended eduroam to rural Kenya using satellite internet - Jisc. The work in Kenya is based on Jisc's Extending eduroam service, which allows users to authenticate to eduroam over 4/5G. 

DIIP profile Implementation

ready for consideration

Mihály Héder

In the credential/wallet ecosystem there are an abundance of options between protocols and parameters, almost creating a combinatorical explosion of options implementers should support. Therefore the DIIP profile was developed: https://fidescommunity.github.io/DIIP/ 
Deep provides defaults as it "chooses standards for credential format, signature algorithm, identifying actors, and issuance and presentation protocols" so that an implementation can state that they are using DIIP. The task is to have our VC issueing IdPs (Ship, ssp) to support DIIP.

Public VC credentials

under development

Branko MarovicMarović (UoB/AMRES), Mihály Héder

Using a go Go implementation for public verifiable credentials (credentials that you don't [primarily] issue are not primarily issued to a wallet , but put published on a website or other public surface) that was done , developed by WP9 using with OpenBadges 3.0 to certify software quality or related software team practices, other use cases could be implemented. . This implementation is accompanied with a suitable certificate framework and dataset, which would probably need to be adapted for other user cases.

The task is to investigate what would be a good use-case and how we would achieve it. One such use case is suitable use cases and how they could be achieved. One example is a reviewer appreciation certificate (see in the topic list), another is all kinds . Others include a range of educational use cases where OpenBadges 3.0 is applicable. Another An additional interesting concept here is that the subject of the credential is does not necessarily have to be a person necessarily but a repo - it could be a repository, a company, a group, etcor similar.

Note (Mihály): We need to define a bit more, investigate moodle/canvas/etc integration modes, or integration with IdP dashboards.

Convergence of Password/passkey Managers and Wallets

under development

Mihály Héder

From the point of view of user experience of an ordinary web user, the landscape is getting quite confusing. Thanks to user education and frightening stories about stolen password and breaches, an increasing number of users rely on complicated password variations or generated passwords and because of this, to saving passwords. This can be done in browsers, which depending on browser accounts (like google accounts signed in to chrome) get stored centrally. Others learn about end-to-end encrypted, hosted dedicated password managers, such as Bitwarden, ProtonPass, etc. Yet another route is to rely on OS-level, such as some Android and Windows solutions. With the rollout of Passkeys by big providers such as google users have to use some sort of manager software to store those.  In this diverse set of identity tools most users will have to use, the wallet ecosystem provides new ways of getting confused. Strictly based on theoretical models of user acceptance (an not other considerations such as security, sovereignty, etc) we can hypothesize that users will prefer those solutions that integrate everything, such as a potential google wallet version in the future and won't prefer a dedicated wallet app such as paradym, wwwallet, lissi, sphereon, etc. Then the follow-up question is how to provide an open source alternative (such as keepass{xc}) or at least European alternative (proton) integrated with wallet functionality for those users who are interested in this.

Scalable, interoperable revocation (in EUDI  wallets)

ready for consideration

Stefan Liström (SUNET)

Marina Adomeit (SUNET)

Revocation is not only a mandatory privacy enhancing feature for end-users, 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.

Possible outcomes: report, training materials, proof-of-concept solutions, proposal for the relevant decision makers in EUDI.

Note (Mihály): revocation is so basic that it is suspicious if no one else works on this right now

Passkey registration to User Profile Page (Shibboleth)

ready for consideration

Timo Tunturi (Aalto Uni)

Mihály Héder (SZTAKI)

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

• Add Passkey registration to UserProfile. Work should be done in cooperation with Shibboleth team to guarantee best integration to interfaces provided by Shibboleth project. 
• The user must be able to register and manage multiple Passkey credentials. 
• An optional API providing organization tools to list and remove Passkeys of users. 
• An optional administrative function to allow an administrator to define requirements for authenticators (via Attestation).

Possible outcomes: prototypes, documentation, open source code for the relevant FOSS projects.

ReviewerAppreciation Certificates

under development

Mihály Héder (HUN-REN)

 Branko Marović (UoB/AMRES)

There is a widely acknowledged crisis in science assessment. By now, this research assessment, which by now prevents the realization realisation of its most important norms that ensured its progress in the past. CoARA, a consortium of 700 research institutions , and the most recent effort countering the problem offers this descriptionaddressing this problem, describes the issue as follows:

"Assessment processes relying predominantly on journal- and publication based metrics can be a hurdle to the recognition of diverse contributions and may negatively affect the quality and impact of research. They also contribute to an unhealthy research culture and an unaffordable publication system." (CoARA mission statement, March 2024, https://coara.eu/app/uploads/2024/03/CoARA_Presentation_-5min_.pdf)

One part Part of the problem is lies in the managerial approachapproaches, hence best addressed by CoARA's through CoARA’s advocacy.

An However, an overlooked element however is the tooling - and (or rather the lack thereof of it) that streamlines the creation and propagation of publication records (through via the now near-universal DOI system), while the rest of the other contribution types are overlooked. This way the accounts of researchers remain neglected. As a result, researchers’ records are automatically enhanced for publications but not for other achievementsforms of achievement.

Alarmingly from From a T&I point of view, usually even perspective this is troubling. Even the few appreciation existing forms that exists of recognition (usually reviewer certificate pdf filestypically reviewer certificates in PDF format) are tied to an email address addresses as a primary identifier, a surname and the initials of the given namesidentifiers, combined with surnames and initials, with all the associated problems. For the rest of the other contribution types: reviews, reproduction of experiments, such as peer review, experiment reproduction, software - as -a research - outcome, or PhD committee work - there is , no such universal mechanism , but it is recognized that some sort of exists, despite the general recognition that certificates or credentials should be issued at the point where such of activity happens. ORCID ORCID’s academic activity record type and Clarivate corp.'s Publons partially address this problem, but in a way that is tied to one given platform. records and Clarivate’s Publons address this only partially, and in ways tied to specific platforms.

With the emergence of Verifiable Credentials and the GÉANT community's community’s experience in creating truly building global collaborations we might be able to help the , there may be scope to contribute to reform efforts. In Specifically, this topic we should investigate explore how the eduPerson, SHAC SCHAC, and other schemas familiar to the TI T&I community could be integrated to into a reviewer appreciation data model at Crossref, and the different possible forms this in which such data could be expressed in. One such form of expression would be is Verifiable Credentials, building on top of the recent work in the area, but in this area. In this case, the certificate would have a public mode (i.e. not only issued to a wallet (only) but presented also published on a website for everyone to see) based on the work done ), following the approach developed in WP9 for certifying software security, projects - a technologically similar project.

Possible outcomes:

Proof-of-Concept, reports, educational materials, research assessment community engagement

Note: this could be a use case for WP9's public certificate issuance platform.

OIDFed of groups and people

under development

Mihály Héder (HUN-REN)

Academics are expected to have a public persona, complete with a public, unique identifier tied to their real name (ORCID), public affiliations, etc. This is necessary to fulfill one of the most important ethos of science, sharing knowledge, which in practice also creates a need to promote publications, collaborations, research agendas, etc. This sets academics apart from citizens in general, who are interested in maximal achievable online privacy. 

This special feature of academic life means that academics could be interested in not only a public profile page such as ORCID, Academia.edu, ResearchGate, etc. but even in public endpoints representing them. With and OIDFed leaf endpoint, together with a trust mark ecosystem acedemics could build trust chains to each other. This is crucial as often they have to collaborate with peers the don't know beforehand and they are resorted to the public academic track record (see the other topic "Automatic collection of Verifiable Academic Efforts") and guesswork. A main use case would be partner finding, verifying new hires and publising. In the latter domain editors should establish that the person submitting is real in the first place (email, ORCID can be self-generated) and that the affiliation is real. Memberships, such as IEEE or other could also be interesting.
The idea can be extended to research groups, projects and companies that all have an interest of a public profile in good standing. 

Possible outcomes

report or publication

PoC solutions

Accessibility and UX in wallets

Ready for consideration

Esther Ruiz Ben (DFN)

Francisca Martin-Vergara (UMA) y José Manuel Macías (RedIRIS)

Description: This activity focuses on users’ perspectives with wallets in research and education paying special attention to the needs of underrepresented groups, i. e. persons with disabilities. We aim to develop wallets prototypes prioritizing accessibility in both design and implementation, ensuring that the final product (prototypes for wallets, including verifiable credentials that are manageable by users) is usable and beneficial to all users, regardless of their backgrounds or abilities.
The main objective of this task is to contribute to enhancing user experiences with wallets in educational and research contexts by:

1. Focusing on real-life experiences of diverse users groups with digital identities in educational and research contexts.
2. Creating interface prototypes of usable and accessible wallets for education and research together with those users groups.
3. Testing the interface prototypes including under-represented groups (i. e. persons with disabilities).
4. Distributing the interface prototypes and recommendations to the education and research communities including developers of digital identities.

Possible outcomes: Prototypes and recommendations.

Note: the methodology can and should be extended beyond wallets, as UX of TI interfaces need attention elsewhere, too.

SAML Legacy

Under development

Mihály Héder

While much of the current focus of our T&I community is aimed at OpenID Federation, which could be the future of Research and Education Federations, it is inevitable that several NRENs will stick with the old SAML technology for a long period of time. This raises the question: what novelties could the TI Incubator work on to ease the life of these federations? With the OASIS working group behind SAML discontinued, the update of cryptographic primitives might be a challenge to be tacked. Another issue could ensuring the expression of new kind of data in SAML, as well as ensuring that there are well working and well-documented SAML-OIDFED proxy solutions.

Proxy token introspection

Under development

Mihály Héder

Proof-of-Concept for the AARC G052 implementation OAuth 2.0 Proxied Token Introspection, required by CoreAAI. In this protocol, an OAuth 2.0 Authorization Server (AS) receives an introspection request for a token it did not issue, to query a different, trusted AS. This enables the AS to determine the active state of the token and to retrieve associated metadata.

Metadata Event Streams

Under development

Pete Birkinshaw (Mimoto)

Mimoto has a simple proof-of-concept for notifying services of changes to remote data status, immediately, using persistent streams of JSON over web sockets. This activity would be to implement other clients and servers, decide on a data format for messages, and to test viability. 

Data types include federation information, metadata aggregates, MDQ entity records, and so on. It's not specific to SAML but may help to make older SAML services more responsive.

Clients open web sockets to an event server and receive lightweight notifications of changes in realtime. The simplest response to such messages is to reset a cached copy of the specified record and reload the record when requested. This technique appears to be faster and simpler than using existing approaches - a client to redownload an aggregate on remote changes should be possible with only a small shell script. The disadvantage is the need for an event service capable of supporting many concurrent connections - it may not be feasible in some languages and application frameworks. 

Fticks-like functionality for OIDFED

Under development

Mihály Héder, 

Niels van Dijk, Davide Vaghetti, Andrijana Todosijevic

As the case of EDUROAM eduroam shows, good, comprehensive usage statistics can help management, decision-making and popularization of a service. For this, the funtionality should be part of the default configuration, anonymous and batch-like to ensure complete anonymity and peace-of-mind of the operators in that they sufficiently protect their users. We propose that provided a sufficient level of k-anonymity (it is guaranteed that each individual cannot be distinguished from another k (say, 100, 1000) individuals in a dataset) and no significant performance sacrifice, such usage statistics would be acceptable and favorable at OP-side to reported to the NREN and to eduGAIN. 

OIDFED tools development 

Under development 

Janos Mohacsi (Pro-M)

Develop SAML metadata tools to be able to handle OIDFED

•  Metadata registry nadling and signing tools to handle OIDFED trust-anchor  (https://jagger.heanet.ie ?)
•  Metadata validator → ?? Validator?

 Proof-of-Concept, reports,