by David Walker
Heather Flanagan’s recent blog post, The Changing Face of Federation, is an excellent look forward to the future of identity federations and what federations must do to remain relevant. In this post, I suggest the unique role of federation operators within this evolution and what they can do to move things forward.
Federations do many things. They support software, provide training, perform community building by various means, and they distribute information about IdPs and SPs available to their federation members (i.e., federation metadata). As described in Trusted Relationships for Access Management: The InCommon Model, this metadata provides the following for each entity (IdP or SP) in the federation:
- Technical information to enable (SAML) interoperation among federation entities
- Miscellaneous useful information, such as links to contact individuals, documentation, etc.
- Elements that enhance trust among federation members
- The member that is responsible for the entity
- The Federation Operator that registered that member
- Certifications (e.g., R&S, assurance attributes, federation membership, etc.) that have been achieved for the entity
Of all these things, it is the distribution of metadata that is the federation operator’s unique and most important role. Software support, training, and even community building can be (and often are) accomplished by others.
Federations in Flux
Federations’ history is deeply rooted in the Security Assertion Markup Language (SAML), but that is changing. There has been significant work over the past several years to develop an analogous metadata framework for OpenID Connect (OIDC) with deployment in some federations, and there is currently considerable interest in wallet-based federation platforms. It will not end there. We are entering a multi-platform future.
[I am using the word “platform” here to indicate the deployment of a protocol. A key aspect of platforms is that they may not interoperate without federation, even if they are based on the same protocol. For example, Google and Facebook both offer identity platforms that utilize the OIDC protocol, but due to their respective business strategies, the two platforms do not choose to interoperate.]What We Need
Some observations:
- Because of the high degree (and often ad hoc nature) of collaboration in research and education, trust-enhancing metadata elements are essential to enable automated trust-related decisions.
- Trust-enhancing metadata elements are platform-independent. While the achievement of certifications may not be the same for all platforms supported by an entity, certifications carry the same meaning across all platforms.
- The trend for post-SAML federation platforms does not generally include trust-enhancing metadata (or any formal metadata) as part of their ecosystem. This is largely due to the dominance of B2B and B2C use cases, which establish trust external to the platform through inter-organizational and end-user agreements.
- It is a lot of work, or even impossible, to incorporate trust-enhancing metadata into an existing platform, and federations have limited resources.
- Organizations that are not federations are not able to define certifications that are useful within their organization. This is valuable, particularly for multi-institution organizations, such as state university systems or multi-institution research collaborations.
We need an infrastructure for trust-enhancing metadata that is independent of any one platform. Without modifying off-the-shelf platform-specific software, such an infrastructure would allow entities to select or authorize trustworthy partner entities and platforms (e.g., SAML IdPs and SPs) before invoking the selected platform, as well as decide whether to trust the information they receive after invoking the platform.
What This Means for Federation Operators
In order to remain relevant, federation operators should focus on enhancing trust among their members and the members of interfederated federations. More specifically:
- Engage the community in a discussion of trust enhancing metadata to raise awareness, and to create a common vision of how it should evolve.
- In partnership with eduGAIN, deploy a platform-independent, trust-enhancing metadata framework, as described in the previous section. Encourage appropriate use of this infrastructure in the implementation of services and identity providers in a way that does not modify “off the shelf” software for existing platforms.
- In creating this infrastructure, consider a distributed management structure for the infrastructure that not only operates the infrastructure but also enables sharing of effort among multiple federations to administer their entities’ trust-enhancing metadata. (E.g., Could federation A administer federation B’s trust-enhancing metadata?) For bonus points, consider the possibility of organizations other than federations, such as international research organizations, having the capability to manage their own segment of the trust infrastructure.