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 Marović (UoB/AMRES), Mihály Héder

Using a Go implementation for public verifiable credentials (credentials that are not primarily issued to a wallet but published on a website or other public surface), developed by WP9 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 suitable use cases and how they could be achieved. One example is a reviewer appreciation certificate (see the topic list). Others include a range of educational use cases where OpenBadges 3.0 is applicable. An additional interesting concept is that the subject of the credential does not necessarily have to be a person - it could be a repository, a company, a group, or 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 research assessment, which by now prevents the realisation of its most important norms that ensured progress in the past. CoARA, a consortium of 700 research institutions and the most recent effort addressing 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)

Part of the problem lies in managerial approaches, best addressed through CoARA’s advocacy.

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

From a T&I perspective this is troubling. Even the few existing forms of recognition (typically reviewer certificates in PDF format) are tied to email addresses as primary identifiers, combined with surnames and initials, with all the associated problems. For other contribution types, such as peer review, experiment reproduction, software as a research outcome, or PhD committee work, no universal mechanism exists, despite the general recognition that certificates or credentials should be issued at the point of activity. ORCID’s academic activity 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 experience in building global collaborations, there may be scope to contribute to reform efforts. Specifically, this topic should explore how eduPerson, SHAC, and other schemas familiar to the T&I community could be integrated into a reviewer appreciation data model at Crossref, and the possible forms in which such data could be expressed. One such form is Verifiable Credentials, building on recent work in this area. In this case, the certificate would have a public mode (i.e. not only issued to a wallet but also published on a website), following the approach developed in WP9 for certifying software 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 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,