(Laura Paglione)
Session takes incentive from the October 2018 Tech Ex Conference Link to the Google Doc with notes from the last meeting:
The session is focused on placing a few things related to SPs on the roadmap, a process already started from the conference of last tech ex conference last fall. What are the parameters needed to establish and what could be done in a year to include SPs in this community and give them a stronger voice? What it means in general to have UNITED SPs?
Thom: are there specific kinds of SPs you are focused on? Laura: there are so many kinds of SPs – R&E SPs for example. It would be useful I think to start instead with a completely inclusive community. At this point it might be difficult to make a proper classification of the SPs. Representing orchid, we say “IdPs should never break SPs”
Part of the challenge is that there has been tension in the relationship between SPs and IdPs in the context of FIM. When I came in as a new SP, it felt like IdPs were trying to tell me how to behave. The balance felt not right, and the SPs should have a voice, a united one.
What are the challenges of the moment that would be solved from United SPs?
Main issue: who does the user belong to? Who has the right to tell the other side how to behave towards the user?
Problems raised:
It is hard to talk to the services themselves – would be good to have a united body of SPs to talk to. Need a gateway for SPs that makes the needs and requests more coherent.
SPs sharing their own proprietary metadata feed. Process owners have control over their own processes.
As an IdP operator - the FIM office is pushed by the forces around it- a solution would be the research community to come together and give them clear limitations.
We see regularly emails from IdP operators calling out SPs by name regarding their documentation. As a SP I have tried not to do that consciously – not going to the participant list and calling IdPs out. Should we start doing that as well?
What are some of the mechanisms that can be helpful to assist this communication in the future?
**Services: **
SP as a service should be easier to implement InCommon - type- person/service that is broader than only inCommon More research needed – GOVERNANCE to effect structural changes and help everyone have a common understanding on the split of roles and what do federation operators etc. do! Commons – how to include new communities? Marketing – Not a service catalog: sharing info on available SPs, better naming, what they do
Resources:
SP forum – where they get together and discuss their challenges, get advices from an SP perspective while not being outnumbered by federated operators SP-specific baseline Location that has a standard to point vendors to – specification/standard for interoperability and conformance The equivalent of Federation Operators Group for SPs (SPOG?)
Tools:
A tool that allows a SP to test their service against some IdP in eduGain that they can get credentials on. Something like a test IdP. Example: Access Check – has a set of test attributes for this purpose A tool that tests metadata, brings out problems and advices how to fix them IdP care-attribute testing tool Registry to tag entities for IdP-rep and forward that information to services (also for entity compromises)
Is it useful to clarify for the federations the bundle of information tailored for the SPs? Assumption is that the number of attributes is complete but there is a point to be made for the chance of having an extendable model – bringing the SPs in the conversation in the first place. Several fields are creating their own attributes and cannot use them in the current FIM structure. When new communities want to come on, they come with their own attributes and it has been impossible for them so far to express their point of view in the matter.
It is a big ecosystem and to increase value and efficiency, every community should feel included and the process should be clearly defined on how to assure that. This includes attributes, rules of engagement and delegation as well.
