Here’s an attempt at a quick (?) rundown.
An identity federation trust framework is a set of federated identity “rules and tools” identified by a set of policymakers representing a community of interest, which may be vertical/sectoral or horizontal in nature. Here’s a
white paper from 2010 that presents what is intended to be a model for open identity trust frameworks. The community could run/use cloud identity services, or just be a bunch of companies or organizations that want to be able to single sign-in to each other’s stuff, or whatever.
As noted below, Kantara does the care and feeding of a specific identity federation trust framework, including “assessing the assessors” for it. That trust framework has a FICAM heritage; FICAM is a US gov-specific trust framework. OIX is becoming capable of hosting listings of the members of multiple trust frameworks, and doesn’t itself offer one and is agnostic as to the types.
What OTA published is very cool; I don’t know if I’d call it a trust framework; more a set of best practices (ymmv).
The Federal Bridge is a PKI-based trust framework. PKI predates the cross-domain federated identity protocols such as SAML and OpenID connect, and the Federal Bridge has been around a long time.
Connect.gov is a service that offers brokered federated identity services; parties involved in it have to be FICAM-accredited.
IDESG is the private-sector-led steering committee overseeing the US public-sector NSTIC initiative. I don’t think it has a specific focus on trust frameworks vs. other various elements that are thought to be valuable for making privacy-sensitive federated identity successful.
(This isn’t a complete list of federations, identity trust frameworks, or initiatives!)
My take on why this is all relevant to UMA is that, where identity federations deal with “rules and tools” for IdPs and relying parties and users, UMA is a different beast and needs “rules and tools” for its own involved parties: resource owners, requesting parties, resource servers, and the like. The name we’ve given to UMA deployment ecosystems with a formal organizational principle is “access federations”, and we believe they would benefit from trust frameworks too.
The main reason why we have the legal subgroup is to develop some starter (and/or meta?) “rules and tools” to encourage UMA deployment ecosystems to flourish, while staying true to UMA’s design principles.
(I welcome corrections…)
Eve
Thanks Adrian
Appreciate the list. The discussion was as a result of a newby question asked by myself, whilst there were only a few people to annoy. :-)
Still on a learning curve ...
Regards
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com