Self service - Signing in activity

Service which could allow an user to check signing in activity on IdP service. That would allow an user to check the recent activity on his account in regards of authentication. Users could see the list if authentications containing datetime, ip and relying party etc. That would help them to spot suspicious activity.

After discussion in the Incubator board, the proposal for the Incubator is inspired by the above proposal, but with a slight difference:

Setting up a service as proposed originally is rather challenging as that service would have to learn about a lot of personal data. However, 'account activity', deployed as part of an IdP extension would actually improve privacy and GDPR compliance of e.g. SimpleSamlPHP and Shibboleth.
Proposal is to create such extensions for SSP and Shibboleth in close collaboration with the relevant community

Both SimpleSamlPHP and Shibboleth as well as also support the OIDC protocol. A 'profile page' should also allow an end user to manage and revoke OIDC access.

it would be advantageous to have a standardised log format  to all popular IdPs. Then these logs should be dumped to ELK or similar server. The log collection server should  provide a restricted access to the logs of a particular users (comment from Janos Mohacsi).

+1 Mihály Héder: I think an Audit Log self-service is an interesting functionality. Account activity is available in many commercial accounts, certainly the googles and the microsofts of the world. We should keep up - also not only the IdP Audit Log but the SP is relevant.

SSH certificates for a federated world

Mads Freek

Mikkel Hald

Doesn't this already exist? (See also: CILogon, SCITokens)

Mads: AFAIK they do not issue SSH certs. There are commercial offerings: smallstep, Teleport.

SSI and the AARC BPA

The AARC Blueprint Architecture (BPA) describes a ‘Community AAI’ solution, a set of software building blocks that can be used to implement federated access management solutions for (inter)national research collaborations. 

The benefit of the BPA is that its proxy-based architecture provides both a technical integration point for authentication and authorisation, as well as a centralised point for implementing the research communities' policies. The BPA also identifies a ‘membership management service’ which implements community-specific onboarding to help establish the researcher's status and may be used to issue community-specific attributes to establish roles and rights. Implementations of the BPA, like eduTEAMS and SRAM, have greatly improved the capability to use FIM for research communities.

Unfortunately, the BPA model also introduces a few challenges:

• The BPA proxy acts as an authentication gateway, which impacts the user flow. Depending on the authentication path taken by a user, the user may end up with a different identity and hence different permissions. This is confusing for end-users and leads to challenges for services.
• A centrally operated infrastructure is required, which is acting as a ’man-in-the-middle’ for all authentication transactions. This impacts data protection and user privacy and hence needs to be considered carefully. 
• Institutions need to release attributes to all such BPA infrastructures their users want to make use of. Even though this already scales much better as compared to releasing attributes to individual services, this may still impede the ability of users to gain access to relevant services.
• A centrally operated infrastructure may not be feasible for all communities as it introduces operational costs and a certain level of organisation of the collaboration.

At first glance, a SSI based model may offer similar benefits as the AARC BPA model, while reducing the number of impediments as a wallet model may take away the need to have a proxy as the central authentication gateway.

This activity will further explored the potential use of SSI technology in the context of the AARC BPA. It will describing where SSI technology may be leveraged, explore benefits and challenges and describe how that may be implement. A number of technical pilots will test the assumptions.

EU AI Act Trust & Identity implications

The idea is to investigate whether there are any preparations to be made by GÉANT project in the context of the "EU AI Act",  currently scheduled for EU Parliament vote on 26/27 October 2022 (deadline for amendments 18 May).  https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52021PC0206&from=EN
Reasons

1) some AI systems in education will be categorized as high-risk AI applications.

2) All other AI systems will be strongly suggested to comply with high-risk requirements voluntarily. 
See Preamble (35) "AI systems used in education or vocational training, notably for determining access or assigning persons to educational and vocational training institutions or to evaluate persons on tests as part of or as a precondition for their education should be considered high-risk, since they may determine the educational and professional course of a person’s life and therefore affect their ability to secure their livelihood. When improperly designed and used, such systems may violate the right to education and training as well as the right not to be discriminated against and perpetuate historical patterns of discrimination."

3) all high-risk AI applications (they will need to earn the "CE" mark) have some identity & trust requirements. These have to do with the strong requirement of human oversight combined with the requirements of accountability. 

In particular Chapter II/Article 12 /par. 4/d requires that the audit logs contain "the identification of the natural persons involved in the verification of the results, as referred to in Article 14 (5)"

The aforementioned Article 14 (5) prescribes that "For high-risk AI systems referred to in point 1(a) of Annex III, the measures referred to in paragraph 3 shall be such as to ensure that, in addition, no action or decision is taken by the user on the basis of the identification resulting from the system unless this has been verified and confirmed by at least two natural persons."

In my opinion the points above together may mean that on-campus AI (i.e. applicant sorting, plagiarism detection, etc.) should be connected with the local AAI infra, so that human oversight is properly validated, plus those logs can be maintained properly with eduPerson data.

This may mean that the operators of such AI systems will look for strong & trustworthy authentication methods to integrate. We may cater for that with our existing infra and our assurance profiles, but as usual, unless we make our case loudly, some of these operators just re-invent the wheel.

Education is only the most straightforward example, there may be other AI systems (ie. in research, government) within vicinity to GÉANT-style AAI.

The suggested project would be 1) study the draft legislation & background documents to understand the extent of the relevance of it all to the GEANT project. 2) survey organizations under our umbrella, with the help of the NRENS, to see what AI solutions they are using at all, etc.  3) analyze if there is any commonly used AI software with which it is worth integrating as a pilot. 4) if we found that it is indeed the case that our T&I ecosystem is a good fit, we should disseminate on many channels.

geteduroam Linux client

The geteduroam service provides a novel way for end users to configure eduroam on their devices. It helps them to get the configuration correct and secure, by combinding federated web login with the provision of an x.509 client certificate to use for authentication, it makes deploying eduroam more secure and minimizes the risk of sensitive credentials leaking due to a mistaken, insecure configuration. The apps provided for Windows, Android and iOS make configuring and keeping this certificate up to date very user friendly. This solves several of the challenges users and institutions had with this process.

What is currently missing is the same convenience for the users of Linux based operating systems, of which there are many in the higher education and research communities. It was hoped that some volunteer from the community would create this but this has not yet materialized.

The incubator can make a Linux client that interfaces with geteduroam and configures and refreshes the credential. This can be a commandline tool, but other types of interfaces can also be considered. If a basic client is available for Linux users, this provides instant value and makes it also easier for the community at large to make more incremental improvement after it.

A Linux client is now a major missing feature of the geteduroam ecosystem so this can be an enabler for further adoption for the service. Providing explicit support -next to the proprietary OS'es- to the open source Linux based systems also aligns with the public values that we as a community stand for.

OIDCfed support on SimpleSAMLphp

Investigate the Fediverse

Martin van Es

SURF

Passkey

Passkey promises a new way for passwordless login. The login however does not contain an attestation. How does this new protocol work, how does it integrate into our current ecosystem and how would this work in combination with new paradigms like wallets?

More background

• https://www.corbado.com/blog/passkeys-single-sign-on-sso
• https://www.helpnetsecurity.com/2013/09/12/saml-20-two-factor-sso-without-usernames-or-passwords/
• http://blog.xot.nl/2022/09/12/passkeys-and-eidas-the-future-of-authentication/index.html
• https://blog.chromium.org/2022/12/introducing-passkeys-in-chrome.html

Explore opporunities for aggregated IdP performance reporting effort

At present, services are collecting information about how IdPs perform in order to support the needs of individual services, and this results in various silos of information being created but not made available for re-use. This silo'd approach is not due to a lack of willingness on the part of the services! As such, multiple sources of behaviour of entityids are available but not currently aggregated at a higher level.

It is suggested that the Incubator performs an activity to:

• Investigate what sources of data are available and what type of information is stored,
• What stakeholders think should be done to use this information and whether aggregated data would add value,
• Suggest a design for an aggregated reporting service and how this could be used in the wider strategy of improving IdP adoption of the correct policies and configuration standards

Examples are:

• eduGAIN Reporting
• InAcademia
• eduTEAMS

To exacerbate this problem,there is limited/no qualitative context relating to known IdPs performance or policy, for example:

• where an IdP selectively release attributes subject to conscious policy decisions and for corner cases (e.g., IdP X is announced to eduGAIN only for the purposes of SP Y, or IdP purposefully chooses not to release attributes to a specified SP).
• where an IdP is known not to release attributes to CoCo policies (despite asserting CoCo)

This means that it is not possible for services to distinguish between faulty and 'strict-policy-driven' IdPs. This might require some additional information or flags to be provided by Federation Operators.

For services that are left to navigate this, it's necessary to engage directly with the Federation Operator which results in wasted/duplicated effort (i.e. the Fed Operator has to answer the same questions relating to the same IdPs to many/multiple SPs, and multiple SPs creating their own records and manual monitoring systems).

Therefore, ideally services would benefit from the ability to identify:

• IdPs that are known to fail to release according to CoCo based on policy (i.e. that assert CoCo but do not release attributes to SPs asserting CoCo).
• IdPs that are known to fail to release according to CoCo based on malformed configuration.
• IdPs with persisting certificate errors.
• IdPs that release misconfigured attribute values.
• IdPs currently in testing phase.

The unintended effects of making this information publicly and freely available should be considered; benefits and draw-backs of restricting the resulting reporting service to GEANT- and Federation-sponsored services should be considered.

Further improve the personal profile page

The #6 cycle in the GN4.3 incubator created a first version of a personal profile page for both Shibbileth idP as well as SimpleSAMLphp. Sprint demo result may be found here: https://docs.google.com/presentation/d/1GCJ5H50S0Zrm4xzLR-Hd5Vtaj-YpTqAfZHhtn-e6iHU/edit?usp=sharing
The sprint demo and also a similar demo at Internet2 TechEx yielded much positive response and a number of intresting suggestions for further improvements.
This activity proposes to continue the work on the profile page software:

• Create a version 2 of the MVP with additional features
• Further improve support for OIDC OP
• Further improve support for SAML IdP
• Investigate improving support for proxied entities
• Investigate a solution to allow consent (SAML) and/or access tokens (OIDC) to be revoked (in combination with existign consent and OIDC modules in Shibboleth IdP and SSP
• Other feature enhansments as suggested (e.g. custom templating of group information, displaying source of origin, etc)