Scalable testing for insecure SAML signature validation

Peter Brand (ACOnet)

Anass Chabli (RENATER)

Automation of
deployment and
configuration
of initial set of SPs
for new federations

Davide Vaghetti (GARR)

Anass Chabli (RENATER)

Arnout Terpstra (SURF)

Refeds Assurance Profile -like information for verifiable claims

Here is an example of a verifiable credential from the W3C VC v2.0 draft. The bold parts are relevant for us.

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/3732",
  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
  "issuer": "https://university.example/issuers/565049",
  "validFrom": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}

People who consume such an academic degree / earned credits / passed exams, etc. credentials are naturally curious about the circumstances of the activity achieved. Was it an in-person course or mixed or fully online? Was the identity of the exam participant verified and how? Was it a supervised event? Unless there is an assurance vocabulary to express these facts, the types themselves will proliferate, eg. there will be an OnlineBachelorDegree, OnlineBachelorDegreeWithInPersonMajorExams, etc. The problem is very simiar to what RAF solves for the context of an authentication. For instance, RAF Identity Assurance Profile introduces the concept of identity evidence and discusses in-person and supervised remote proofing. This is exactly what is needed for a claim about an exam taken. As an example, the default kind of badge (claim) earned on Coursera will be IAP/low, as ultimately a Coursera account is self-asserted. However, everybody who does not cheat and pays for a course would benefit from a badge/claim in which their idenity is more rigorously assured.

The proposal is to identify how elements of RAF could be re-used in the VC context as well as extended with other elements, to express the supervised closed-room exams, etc.

Investigate Google WEI & Apple Private Access Tokens

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 protocol relies on integrity attestations.

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.
https://github.com/RupertBenWiser/Web-Environment-Integrity/issues/28#issuecomment-1651129388

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.

It could turn out to be crucial that our community understands these protocols and develop its own relationship to them. Also, while the attestation about personal devices seems indeed quite privacy-endangering as well as the prospect of enhanced DRM, there may be legit use cases for classroom devices or around the integrity of wallets.

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

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)

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).

Timo Tunturi (Aalto Uni)

Mihály Héder (SZTAKI)

eduGAIN PoC

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:

• Sharing existing experience and providing a sparring partner to the eduGAIN PoC team
• Contribute to standards and policy development for eduGAIN and national federations (upon request by the eduGAIn PoC team)
• Developing or further enhancing software tools, including, but not limited to:
  • Contribute to existing software development for the eduGAIN PoC
  • Build/Productise a (scalable) resolver which can be deployed by fedops and eduGAIN
  • Further improve visualisation and reporting tooling
  • Further improve Go based OP/RP

The incubator will work on these in close collaboration with the eduGAIN PoC team.

Implement OpenID Federation into SimpleSAMLphp and Shibboleth IdP

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.