Versions Compared

Old Version 1

changes.mady.by.user Alex Stuart

Saved on

compared with

New Version 2

changes.mady.by.user Alex Stuart

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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

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 needs lots of metadata rules. 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.

**the following are rought notes from the remainder of the meeting**

Information in trustworthyness is useful in many cases ... think about it seperate from current SAML protocol, SP wants to find IdP ... good place for adding other protocols ... use similar toolchains ... metadata enables mutlilateralism

Albert asks: is this the reason? This is quite detailed, so even though InC will ingest on behalf of SP ... so SP could do this itself (i.e. directly with S/A) but how to balance fed versus SP.

Pål: yes, this very SAML based. Nothing in OIDC for this. I want to write something more general, and then make SAML vehicle, OID Federation later perhaps. Most filtering on what we already have.

Albert: I've heard there may be other use cases, we need to hear those. Will it remain just S/A, then we can make certain short-cut decisions, otherwise

Shibboleth EDS / switchWayf / ...

But S/A is a shared i/s so need to have flexible (and compex) filtering.

Sunet adding contract link into metadata in an entity category. If an SP ... Albert: like a NSF, only want show IdPs they have a contrct with.

Who else cares? Sevice owners ... only looking for certain IdPs.

IdP side ... is it useful? When they consume it? Or if they assert it in metadata. If there was a small project?

SP says I have acontract with IdP

SP wanting to filter to vetted IdPs; or vendors wanting to include only customers.

General acceptance that it's no authz decision,

  • discvery
  • metaeata filter

memory resources for verifying cf. splitting and storing

In IDEM used JWT signed with JWK entire JSON discovery feed ... more ightweight ... then distribute to IDEM community. Is this useful?

pyFF can generate JSON but perhaps not sign it; Shibboleth MDA similarly.

Want to have a decision how S/A sooner than later; then general

2 stages: SAML for S/A, then general spec

differences of opinion ow difficult getting ... if just another EA in first bit ...



Meeting schedule: starting on 11 April, weekly at 1600 CEST / 0700 PDT.