...
...
Minutes
...
Albert gave us an update from the SeamlessAccess comms Working Group (Monday 2024-10-28). It appears that the Advanced mode of integration is becoming less attractive to SPs, and there is a lot of interest in moving to the Standard or Limited integration. And with this move, SPs will also have to move from the SP-managed button. Therefore there is more urgency in getting the metadata mechanism correct.
InCommon's current plan is to provide a checkbox whether to include the InCommon profile data. However, publishers will want to have detailed control over the filtering rules (adding IdPs, primarily) so the "federation profile" will not be a full solution.
LibLynx appears to be one of the SPs (publisher platform) which is keen to explore the move. They have registrations in multiple federations including InCommon and UK federation so any federation-mediated solution will need to be widely usable.
Some unresolved questions:
- Assuming a federation-mediated solution, how would fedops communicate the requirements to the SPs?
- How would SPs build the blob? Will there be an online tool for generating the BASE64-encoded blob or do we expect the SP operators to create it themselves?
- Where would the encoded blob get validated? Ultimately that's at the metadata consumer (SeamlessAccess), and the metadata intermediaries can just pass the blob straight through.
- All the issues about logical combination rules would need to be addressed
- how SPs will update their filtering rules (either at fedop or in SeamlessAccess directly)
The Working Group's interim report needs this content:
- define REFEDS remit and what's on SeamlessAccess
- just the metadata solution not the button.
- EA definition and encoding
- Profile only for one instance of EA. Says nothing on multiple instances.
- write considerations for fedops on use of metadata
- SeamlessAccess need to define feature, WG on Monday, looks like publishers starting to get interest
- Publishers (liblynx) rules will likely get complex & need them into metadata because Advanced mode isn't going to work long term
- With this WG & interim report: EA definition and let the
- InCommon UI: checkbox to add a InCommon-specified blob. Won't allow the additional specification.
- Any fed that LibLynx is registered in will need to do this
- How do we generate the base64 blob? Is there a "blob builder"
- There's also a communication burden: how to configure this. And once InCommon turned on, it's on for all SPs
- 2. blob needs to be validated somewhere. Fedop or SeamlessAccess
- 3. trustinfo spec is missing things (which we've noted already)
- fleshed out spec
- support function to help deployers
- So what does SeamlessAccess need to do? Are they only use cases?
- CoreAAI! They use SeamlessAccess too (or maybe thiss.io)
- They need to define all the features, and how to parse it, how to support it
- This WG needs to answer some questions in the interim report
- EA w/ JSON that follows SeamlessAccess specification
- Considerations for fedops and metadata
- Can SeamlessAccess implement?
- metadata transmission mechanism isn't enough, that's for fedop
- inconvenient for SPs to keep updating (either at fedop or login at SeamlessAccess)
- SeamlessAccess owns the ongoing development
- REFEDS What is limit of REFEDS remit
- not for 1 implementation, but for many
- metadata solution can do consultation and do quality control (both trustinfo spec and transport) but would not want to do lots of consultation
- As we've seen previously, REFEDS can't enforce adoption , can't ensure or ensiure policy is followed
- If SeamlessAccess is as successful as InCommon discovery, then we'll get new feature requests ... SeamlessAccess could submit spec to REFEDS for ratification / QA flow. Needs to own the ongoing development.
- 5 meetings before TechEx!
- Our interim report is to create mechanism (metadata not button), that's for organisations with operational responsibilities