1 of 58

Trust & Identity Incubator

Public Sprint Demo #3.2

Public (PU)

Public Sprint Demo

17 December 2024

GN5-1

2 of 58

Agenda

14:00 → 14:30

TI Wizard – A GUI-driven component to help configure endpoints and metadata for tools like SSP and SaToSa��Mihály Héder, Peter Bolha, Alexandr Petrunin

14:30 → 15:00

Verifiable Credentials Schema for eduPerson, SCHAC and voPerson

Niels van Dijk

15:00 → 15:30

OpenID Federation Implementation in Shibboleth IdP and SimpleSAMLphp

Henri Mikkonen, Marko Ivančić, Niels van Dijk

15:30 → 16:00

eduGAIN OpenID Federation Pilot��Davide Vaghetti, Diana Gudu, Gabriel Zachmann, Giuseppe De Marco, Niels van Dijk�

2 |

GN5-1

3 of 58

TI Wizard

3 |

GN5-1

4 of 58

Activity: TI Wizard – A GUI-driven component to help configure endpoints and metadata for tools like SSP and SaToSa

  • Create a GUI-driven component to help configure endpoints and metadata for tools like SSP and SaToSa. Focus on daily management of the relations between the identity product and external resources.
    • Helps set up the deployments’ role(s), like IdP, SP, OP, RP
    • Helps manage entity categories
    • Helps with generating key material
    • Manages remote entities
      • MDQ
      • File-based

4 |

GN5-1

5 of 58

Activity: TI Wizard - A GUI-driven component to help configure endpoints and metadata for tools like SSP and SaToSa

✅ A very nice GUI library

✅ Design is starting to converge

😀 Reframing from GUI proxy to a general endpoint and metadata management utility

😀 From UI mockup to GUI code skeleton

😀 Considering sensible defaults in the GUI and specific connectors for specific identity products

5

5 |

GN5-1

6 of 58

Architecture

6 |

GN5-1

7 of 58

Demo Screencasts - �GUI

7 |

GN5-1

8 of 58

Config Processors

8 |

GN5-1

9 of 58

Demo Screencasts - �Config Processors

9 |

GN5-1

10 of 58

Links

10 |

GN5-1

11 of 58

Verifiable Credentials Schema for

eduPerson, SCHAC and voPerson

Esther Ruiz Ben (DFN), Niels van Dijk (SURF)

11 |

GN5-1

12 of 58

12

Verifiable Credentials �Subcommittee Meeting @TechEx

  • Charter and activities�
  • A bit about VCs�
  • VC approaches�
  • VC presentation�
  • VC schema�
  • Next Steps

13 of 58

13

Verifiable Credentials Subcommittee Charter

W3C Verifiable Credentials (VC) are increasingly important to our community with the rise of Decentralized Identity and Wallet ecosystems. Several VC based credential definitions already exist for expressing skills and micro-credentials, like e.g. the Open Badges 3.0 specification. However, there is no consistent and community driven definition for expressing the 'identity related' credentials of the commonly used schema managed by REFEDs like e.g. eduPerson, SCHAC and voPerson.�

The REFEDS schema board is setting up a subcommittee to define the VC representations of these well known credentials so they may be used in an standardized and interoperable way.

14 of 58

14

Charter

Verifiable Credentials Subcommittee

  • Multi stakeholder, global community group (Federation, Institution, Library, Research) of about 20 participants
  • Meetup bi-weekly on Friday 08:00 CET�Next one is Dec 20, 2024

https://wiki.refeds.org/display/STAN/VC+Subcommittee

15 of 58

15

Simple VC

{

"@context": [

"https://www.w3.org/ns/credentials/v2",

"https://www.w3.org/ns/credentials/examples/v2"

],

"id": "https://university.example/Credential123",

"type": ["VerifiableCredential", "ExampleAlumniCredential"],

"issuer": "did:example:2g55q912ec3476eba2l9812ecbfe",

"validFrom": "2010-01-01T00:00:00Z",

"credentialSubject": {

"id": "https://www.example.org/persons/pat",

"name": "Pat",

"alumniOf": {

"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",

"name": "Example University"

}

}

}

https://www.w3.org/TR/vc-data-model-2.0/

16 of 58

16

eduPerson Object Class Specification (202208) v4.4.0

https://wiki.refeds.org/display/STAN/eduPerson+%28202208%29+v4.4.0

VC != attributes

17 of 58

17

Approach #1: All of eduPerson + Selective Disclosure

18 of 58

18

Approach #1: All of eduPerson + Selective Disclosure

DEMO

19 of 58

19

Approach #2a: Specific Set of Claims

20 of 58

20

Approach #2: Specific Set of Claims

DEMO

21 of 58

21

Approach #3: eduPerson and voPerson in One VC

22 of 58

22

VC Presentation

DEMO

23 of 58

23

Approach #4: VC with Common Claims + Selective Disclosure

24 of 58

24

JSON Schema for Simple VC

{

"@context": [

"https://www.w3.org/ns/credentials/v2",

"https://www.w3.org/ns/credentials/examples/v2"

],

"id": "https://university.example/Credential123",

"type": ["VerifiableCredential", "ExampleAlumniCredential"],

"issuer": "did:example:2g55q912ec3476eba2l9812ecbfe",

"validFrom": "2010-01-01T00:00:00Z",

"credentialSubject": {

"id": "https://www.example.org/persons/pat",

"name": "Pat",

"alumniOf": {

"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",

"name": "Example University"

}

},

"credentialSchema": {

"id": "https://university.example/Credential-schema.json",

"type": "JsonSchema"

}

}

25 of 58

25

JSON Schema for Simple VC

{

"$id": "https://university.example/schemas/credential.json",

"$schema": "https://json-schema.org/draft/2020-12/schema",

"title": "ExampleAlumniCredential",

"description": "Alumni Credential using JsonSchema",

"type": "object",

"properties": {

"credentialSubject": {

"type": "object",

"properties": {

"alumniOf": {

"type": "string",

"format": "url"

}

},

"required": [

"alumniOf"

]

}

}

}

26 of 58

26

Issuer Specific Presentation

27 of 58

27

Presenting VCs

28 of 58

28

Proposed Approach

  1. Standardize the claimsWhite Paper for implementation of mappings between SAML 2.0 and OpenID Connect in Research and Education (2018)�https://docs.google.com/document/d/1b-Mlet3Lq7qKLEf1BnHJ4nL1fq-vMe7fzpXyrq2wp08
  2. Standardized specific VCs based on common use cases�Register JSON schema for these VCs�
  3. Describe best practices for presenting the VCs in the wallet

29 of 58

OID Federation implementation in

Shibboleth and SimpleSAMLphp

Public (PU)

Henri Mikkonen (CSC & Shibboleth Consortium), �Marko Ivančić (SRCE), �Niels van Dijk (SURF)�T&I Incubator Sprint Demo - December 17, 2024

GN5-1

30 of 58

Shibboleth IdP OIDC OP plugin - OIDfed support (1/5)

  • Short history of OIDC/OAuth2 support in Shibboleth Identity Provider
    • 2017-2019: Initial development of the OP-plugin in GEANT 4-2 and 4-3 projects
    • 2019: GEANT-branded OIDC OP plugin v1.0, OpenID Foundation certification
    • 2019: GEANT handed the OP-plugin to Shibboleth Consortium
    • 2020: Shibboleth-branded OIDC OP plugin v2.0
    • 2021-: Division into separate OIDC-common module and OP-plugin, OAuth2 AS features to the OP-plugin
    • 2023: OIDC RP-plugin v1.0 (exploits the OIDC-common module)

  • Current state of the OIDC OP plugin
    • OIDC: Core, Dynamic Client Registration, Logout
    • OAuth2: Revocation, Introspection, PKCE, JWT Access Tokens, PAR, DPoP Access Tokens, …

  • The goal is to extend the OIDC OP plugin to support OpenID federation
    • Initial main focus on GEANT community's use cases
    • Exploit Nimbus OAuth2/OIDC Java SDK in the same way as before in the plugin

30 |

GN5-1

31 of 58

Shibboleth IdP OIDC OP plugin - OIDfed support (2/5)

  • New features (Note: Proof-of-concept implementation / WIP):
    • Entity Configuration
    • Construction of Trust Chains
    • Automatic Registration of an OIDC RP in the authorization endpoint

  • Entity Configuration
    • The .well-known/openid-federation endpoint
    • Exploits the dynamic configuration endpoint contents (.well-known/openid-configuration)
    • Configurable lifetime for entity statement and its caching
    • relying-party.xml snippet:

<bean id="shibboleth.UnverifiedRelyingParty" parent="RelyingParty">

<property name="profileConfigurations">

<list>� <bean parent="OIDFED.Configuration"

p:cachedEntityStatementLifetime="PT2H" p:cachedEntityStatementLifetime=”PT1H”� p:authorityHints=”https://trust-anchor.testbed.oidcfed.incubator.geant.org/” />

</list>

</property>

</bean>

31 |

GN5-1

32 of 58

Shibboleth IdP OIDC OP plugin - OIDfed support (3/5)

  • Dynamic construction of Trust Chains
    • Fetching and validation of entity configurations and subordinate statements via authority hints
    • Three metadata caches:
      • Entity Configuration cache (key: subject entity ID)
        • Fetches the entity statements from the subject’s entity configuration endpoint
      • Subordinate Statement cache (key: issuer and subject entity ID)
        • Fetches the entity statements from the issuer’s fetch endpoint
      • Trust Chain cache (key: subject entity ID)
        • Exploits the other two metadata caches for resolving all possible trust chains for the subject entity
        • Trust Anchor validation against locally stored public keys

32 |

GN5-1

33 of 58

Shibboleth IdP OIDC OP plugin - OIDfed support (4/5)

  • Automatic registration of an OIDC RP in the authorization endpoint
    • If a requesting RP is not already registered, its client_id is a valid URL and automatic registration is enabled, then
      • All valid Trust Chains are resolved via Trust Chain metadata cache
      • One Trust Chain is selected via customizable function
        • Initially only one option: always take the shortest chain
      • The combined metadata policy from the Trust Chain is constructed
      • A configurable local metadata policy is applied to the federation policy
      • Resolve and validate Trust Marks via Trust Chain metadata cache
      • Verify the Trust Marks meets the configuration
        • The mandatory trust marks may be configured on per trust anchor basis
    • If the previous sequence completes without any issues, then the RP may be automatically registered to the storage of registered clients
      • WIP: the storage may be avoided and instead base on metadata caches on all endpoints

33 |

GN5-1

34 of 58

Shibboleth IdP OIDC OP plugin - OIDfed support (5/5)

  • Automatic registration of an OIDC RP in the authorization endpoint - configuration (WIP)
    • Example relying-party.xml snippet configuring a specific trust mark when a specific trust anchor is involved and overriding profile configuration for any RPs registered via specific trust anchor

...

<util:list id="shibboleth.RelyingPartyOverrides">

<bean parent="RelyingPartyByName" c:relyingPartyIds="https://trust-anchor.testbed.oidcfed.incubator.geant.org/">

<property name="profileConfigurations">

<list>

<bean parent="OIDFED.AutomaticRegistration" p:mandatoryTrustMarks="https://mandatory.example.org/trustmark"/>

</list>

</property>

</bean>

<bean parent="RelyingPartyByTrustAnchor" c:trustAnchorIds="https://trust-anchor.testbed.oidcfed.incubator.geant.org/">

<property name="profileConfigurations">

<list>

<bean parent="OIDC.SSO" p:forcePKCE=”true” p:allowPKCEPlain=”false” />

<bean parent="OIDC.UserInfo" />

</list>

</property>

</bean>

...

34 |

GN5-1

35 of 58

Shibboleth IdP OIDC OP plugin - OIDfed support - Demo

35 |

GN5-1

36 of 58

SimpleSAMLphp Module OIDC

https://github.com/simplesamlphp/simplesamlphp-module-oidc

  • OpenID Federation capabilities are being introduced for v6 of the module which is WIP: https://github.com/simplesamlphp/simplesamlphp-module-oidc/tree/wip-version-6
  • Automatic client registration is implemented
    • new federation endpoints for issuing configuration entity statement and subordinate statements
    • new properties for clients
    • new capabilities like support for request objects on authorization endpoint, support for `private_key_jwt` client authentication method at token endpoint...
  • WIP federation participation (limiting) based on Trust Marks
  • Underlying library https://github.com/simplesamlphp/openid introduced, with capabilities like:
    • trust chain resolving
    • metadata (policy) resolving
    • abstractions and factories for entity statements, trust chains, trust marks …
    • http fetchers for entity statements, jwks …
    • optional built-in caching
  • Authentication can be tested on https://gorp.testbed.oidcfed.incubator.geant.org/ RP, by selecting "https://maiv1.incubator.geant.org" OP (u: testuser, p: testpass).

36 |

GN5-1

37 of 58

SimpleSAMLphp Module OIDC - Demo

37 |

GN5-1

38 of 58

Interop and Integration testing

Shib and SSP OP added to, and tested against implementations of Roland Hedberg, SPID/CIE and Incubator GO based implementation of TA, Intermediate and RPs

Shibboleth

OP

SimpleSAMLphp

OP

38 |

GN5-1

39 of 58

Thank You

www.geant.org

40 of 58

eduGAIN OpenID Federation Pilot

40 |

GN5-1

41 of 58

eduGAIN OpenID Federation Pilot

The eduGAIN service activity will set up a PoC in to evaluate the new OpenID Federation (OID Fed) 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 Fedederation in various products and languages, as well as evaluating e.g. REFEDs specifications in the context of OID Fed.

This activity seeks to contribute to the eduGAIN PoC by:

  • Sharing existing experience and providing a sparring partner to the eduGAIN PoC team
  • Contributing to standards and policy development for eduGAIN and national federations (upon request by the eduGAIn PoC team)
  • Developing or 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.

41 |

GN5-1

42 of 58

“eduGAIN interfederation service connects identity federations around the world, simplifying access to content, services and resources for the global research and education community”

42 |

GN5-1

43 of 58

Inter-federated Access

Federation Blue

Federation Green

43 |

GN5-1

44 of 58

eduGAIN Global Coverage

78 Federations

9552 Entities

5775 Identity Providers

3795 Service Providers

Last update November 26th 2024

44 |

GN5-1

45 of 58

What do we use it for?

45 |

GN5-1

46 of 58

eduGAIN provides

  • A governance model and body for global collaboration between the national federations
  • A policy for participating federations and entities
  • A technical infrastructure which publishes metadata
  • Tools to view, test and validate participants
  • Specifications for global interoperability,
    • specifically a SAML profile

46 |

GN5-1

47 of 58

eduGAIN provides

  • A governance model and body for global collaboration between the national federations
  • A policy for participating federations and entities
  • A technical infrastructure which publishes metadata
  • Tools to view, test and validate participants
  • Specifications for global interoperability,
    • specifically a SAML profile

A trust layer for cross border access to R&E resources

47 |

GN5-1

48 of 58

eduGAIN OpenID Federation Pilot Overview

WHEN

  • As soon as the dev work is done (end 2024)
  • 12 Months

HOW

  • OpenID Fed set up kit based on T&I Incubator tools
  • DRAFT eduGAIN OpenID Federation Technological Profile

WHO

  • eduGAIN service and T&I Incubator
  • Federation Operators
  • Research Community AAIs
  • Any other interested stakeholder

WHY

  • SAML is a legacy protocol
  • Mobile clients
  • Post-quantum cryptography
  • Verifiable credentials and DID
  • etc, etc

48 |

GN5-1

49 of 58

OpenID Federation

Trust Mark Owner

Trust Mark Issuer

49 |

GN5-1

50 of 58

Pilot assumptions

  • Entities (LEAF, Intermediate) register only once with one of the national federations
  • This provides the basic core trust infrastructure and would benefit from a significant consistency between National Federations�
  • All other trust relations are based on Trust Marks, including but not limited to:
    • eduGAIN
    • REFEDs profiles
    • Research Communities
    • University Alliances
  • Trust Mark Issuers and Ownership may be decentralized
  • International Trust Mark Issuers are registered at the eduGAIN level

50 |

GN5-1

51 of 58

eduGAIN OpenID Federation Trust model

51

51 |

GN5-1

52 of 58

The eduGAIN OpenID Connect Profile - work in progress

TRUST is based on trust chains with eduGAIN as Trust Anchor, Federations as Intermediates and Entities as Leaves

ENTITY RESOLUTION is provided by a resolver endpoint at federation and inter-federation level that provides metadata about entities

ENTITY VALIDATION is based the eduGAIN Trust Mark. Only validated entities can be part of trust chains with eduGAIN as Trust Anchor

52 |

GN5-1

53 of 58

Trust hierarchy ‘remix’ using Trustmarks

53

53 |

GN5-1

54 of 58

Trust hierarchy ‘remix’ using Trustmarks

54

54 |

GN5-1

55 of 58

Edugain Testbed

  • Edugain Trust Anchor: https://edugain.edugain-poc.incubator.geant.org/
  • Go-based Trust Anchor / Intermediates
  • Go-based RPs
  • Roland’s OP
  • SSP and shib OPs in the next days
  • Different Trust Marks and Trust Mark Issuers
  • Dynamic Trust Mark refreshing

55 |

GN5-1

56 of 58

Benefits for using OID Fed in eduGAIN

  • A route to start moving away from SAML, while retaining multilateral federation
  • Simplify federation management due to increased automation
  • End to end trust
  • More transparent trust, specifically wrt proxies
  • One unique trust infrastructure that may support SAML, OIDC and Wallets

56 |

GN5-1

57 of 58

Some of our software projects

57 |

GN5-1

58 of 58

Thank You

www.geant.org