By Alex Stuart (JISC)
How did we get here
Federation operators have rules for entity registration to ensure a good user experience within that federation. These rules are typically published in a Metadata Registration Practice Statement. When we look at a wider ecosystem where multiple federation operators register SPs and IdPs, we need prioritization and selection rules. The rule that many people know about is the metadata combination rule in eduGAIN metadata aggregation, which enforces unique entityIDs.
However, unique entityIDs are not sufficient to provide a good user experience in an ecosystem. Accurate and complete metadata (such as DisplayName and logos) will help people select the appropriate IdP when logging in, although this still requires an individual to make the correct choice at login time. What if there was also a mechanism in metadata for an SP to describe which IdPs it would prefer to interoperate with? That’s what the REFEDS trustinfo metadata Working Group is exploring.
We’re building on earlier work from SeamlessAccess to develop a specification that can allow SPs to identify a set of IdPs, either by entityID or generically by registrationAuthority or entity attribute. They coined the term “trustinfo” although we’re realising it’s actually an entity selection protocol.
Where are we now?
The Working Group is exploring two ways to signal entity selection. In both cases, we must ensure that metadata registrars can express the information, and that metadata intermediaries can pass the information unchanged, and that metadata consumers are able to process the information and act on it. We also need to ensure the scalability and fault tolerance of the proposed mechanism.
The first proposal is to define an entity attribute whose value is the URI of a profile. The profile is defined by the metadata consumer, and SPs that want to use it add that value to the entity attribute. This mechanism uses existing SAML metadata elements, and the profile can be defined flexibly (in text, in a piece of code, or expressed in a new metadata schema). It could be a quick route to standardisation. The disadvantage is that the metadata consumer is unlikely to want to define many profiles.
The other proposal is to directly specify the IdPs in existing metadata. This approach is also flexible because it allows each SP to specify their selections individually. However, it needs significant up-front development to define the syntax, semantics and encoding of the data.
More use cases required
The working group has discussed many possibilities. However, we currently have only one use case of a metadata consumer—SeamlessAccess using the thiss.io identity selector engine. To pursue a more general solution, we need more use cases for an entity selection protocol. Our current discussions have focussed on IdP discovery, so our hope is that another discovery service might be interested in using this protocol.
We would also be interested to hear other use cases where an entity wishes to publicly signal to a third party through metadata. Bear in mind that metadata updates can take days, and the process to authorize and update metadata can be lengthy, so we need to find use cases where the information doesn’t change quickly.
Join us
Information on the Working Group is on the REFEDS wiki. We meet most Thursdays at 4pm – 5pm CEST / 7am – 8am PDT and we’d welcome you to our meetings. You can also get in touch through Slack or mailing list. Details in the wiki. Many of the Working Group will also be at TNC in June so please come and talk to us.
Most importantly, bring your use cases!