Agenda

  • Welcome & introductions
  • Scope of the WG
    • standardise the spec that's in the google doc
    • has the spec been implemented yet?
  • Decide on a method of working
    • collaboration through mailing list / slack / online meeting
    • notes from meetings in google doc or REFEDS wiki
  • Timeline
    • Will need to report some progress at REFEDS meeting at TNC (10 June)
    • Any other important dates?
  • Walk through the current specification google doc


Participants

  • Alex Stuart 
  • Pål Axelsson
  • Björn Mattson
  • Zacharias Törnblom
  • Albert Wu
  • David Walker
  • Mario di Lorenzo
  • Marco Malavolti

Minutes

Welcome and why are we here:

  • Alex: wants to standardise new metadata
  • Pål: We must be better at giving users good options for discovery
  • Zacharias: product manager with SeamlessAccess which needs the filtering capabilities, SPs include and exclude based on specifc needs. Feels too close to the fire so is in this working group to hear from others who'll use the filtering.
  • Bjorn: works with Sunet toolchain & has thought about implementing the trustinfo metadata. Doesn't want it to get blocked by any other federation, so define it in a usable way. Would like to make a metadata tag and also develop common sense on making interoperable filter between different federations. At present it's sunet → eduGAIN → SeamlessAccess.
  • David: before retirement was mover for UC trust federation. Author for many documents for Internet2. Engagement with InCommon winding down. Interested in trust in multi-protocol environment, especially with Verifiable Credentials use.
  • Albert: InCommon federation manager ... was part of group that formed UC trust. Is here because of Seamless Access. InCommon in the process of adopting SeamlessAccess & this piece is critical in roll-out. Wants something that will scale and doesn't break folks
  • Mario: IDEM GARR as federation operator, here to observe. We have some interest in SeamlessAccess
  • Marco: IDEM GARR federation operator too. Here to observe evolution of new specification. Interested in filtering of IdPs from SP perspective because have done this using a Shibboleth SP / EDS and it works well because it acts on the JSON output that feeds the Discovery Service. Not sure if there is a simpler solution. SeamlessAccess is very different to EDS.


SWAMID recommending SeamlessAccess for all SPs; InCommon looking to implement SeamlessAccess as the federation discovery service; UK federation continues to recommend local discovery because SPs know their customers best, but also point to SeamlessAccess and OpenAthens Wayfinder if SP wants to offload discovery.

Some history: SeamlessAcess originally favoured a filtering mechanism in JavaScript.

If adopting SeamlessAccess as a federation, federation needs to indicate which is a trusted metadata, because SeamlessAccess ingests much wider metadata than just eduGAIN. If people are presented with IdPs they'll choose them -  within a week of InCommon using SeamlessAccess as an alternative discovery service they found logins from IdPs not in eduGAIN metadata. This is probably fine if SP expects from multi-federation, but often it's not and one can't expect SPs to manage this. Have it at the federation space.

SeamlessAccess first to build something like that? Maybe the discontinued DSX discovery pilot had something similar. REFEDS discovery best practice guide - that's long gone.

Sunet happy with Seamless, apart from the IdP choices.

Albert opens another line of discussion: at Community Exchange 2 weeks ago were talking a very simple mechanism of just saying "show IdPs with a specific profile" rather than listing all IdPs that the SP is willing to interoperate with.

  • we don't know where new metadata would be ingested & would it get filtered by metadata processors (fedops and eduGAIN)
  • only consumed by S/A so it's a legitimate question to ask a major extension to SAML metadata when only 1 party will consume.

There was some discussion about whether trustinfo metadata would be useful for IdPs to signal to SPs. General mood was that an SP would usually know which IdPs had a specific contract. And that if SPs wanted to only show IdPs with a specific profile, they're filter on that profile. Potential use case if a few IdPs were working in a small project (although defining how to signal & have the IdP operators assert that is likely to be prohibitive).

General acceptance that trustinfo isn't about authorization decisions, it's about discovery and metadata filtering. Bjorn noted that memory resources for verifying are generally less than splitting large aggregates and storing the metadata in the application.

We had an interesting (but short) dIscussion on JSON discovery feeds. IDEM distributes a JWT signed with JWK over the entire JSON discovery feed. pyFF can generate JSON but perhaps not sign it; Shibboleth MDA similarly.

General agreement on the way forward

  1. Develop something that works for SeamlessAccess consuming SAML metadata asap
  2. Broaden the use cases out in both directions (other discovery services / metadata consumers / other protocols) because information about trustworthiness is useful in many cases.

Meeting schedule

Starting on 11 April, weekly on Thursday at 1600 CEST / 0700 PDT.







  • No labels