Last updated: 
2 months 2 weeks ago
Group Manager
Project Moonshot is a Janet-led initiative, in partnership with the GÉANT project and others, to develop a single unifying technology for extending the benefits of federated identity to a broad range of non-Web services, including Cloud infrastructures, High Performance Computing & Grid infrastructures and other commonly deployed services including mail, file store, remote access and instant messaging. The goal of the technology is to enable the management of access to a broad range of services and applications, using a single technology and infrastructure. This is expected to significantly improve the delivery of these services by providing users with a common single sign-on, for both internal and external services. Service providers will be able to more easily offer their services to users from other organisations using a single common authentication mechanism. This will enhance the user’s experience, and reduce costs for those organisations supporting users, and delivering services to them. This group is for community of Moonshot users, whether you're new to the technology, you're currently evaluating and getting to grips with it, or you've deployed it. For the list of guidance available about Moonshot within this group, see the Start Here wiki page. Jisc Assent, the production service underpinned by the Moonshot technology, went live on 25th March 2015. For information on, or to join the Jisc Assent service, please visit

Trust Router IETF 86 Bar BOF

6 September 2013 at 5:06pm

On 14th March 2013 Sam and Margaret from Painless Security hosted a Bar BOF meeting at IETF 86 to begin the process that will hopefully lead to the standardisation of Trust Router.

Within the IETF, the ABFAB working group has been busy at work describing a federated identity and access management model that enables federated identity for a wide variety of use cases and applications; this work is currently drawing to a close. However, one of the typical problems in the federated world - and a problem that any ABFAB implementations needs to address - is managing the scaling of number of partners involved in the federation (this is because configuration changes need to be made at all interested partners when new entities join). Existing federation technologies attempt to solve this problem in a variety of ways (e.g. SAML metadata, hierarchical RADIUS federations) but each has their own unique disadvantages. A much more elegant, flexible, and extensible way to achieve the same goals would be beneficial - especially for when scaling up to the potential number of entities in a community of ABFAB-enabled partners.

Alongside this, operationally, there is also a need to separate the authentication process from the creation of a new partnership across a set of federated entities - so as to allow existing credentials to be used for new communities of users with minimal operation and infrastructure costs. This is crucial in driving adoption of federated technologies on a wide scale, and in reducing the cost of operating and being a part of federation on such a wide scale.

Trust Router is an attempt to build an infrastructure that solves these - and other - problems (see the full problem statement for more details). Essentially, Trust Router works by distributing information about new and existing trust relationships across a network of entities. It achieves this distribution using protocols with many similarities to existing routing protocols, and avoids any requirement for technologies such as PKI. The broad applicability of a general infrastructure for routing trust information between arbitrary entities and allowing them to communicate securely means that this is potentially quite an exciting topic, and one ripe for standardisation.

* Trust Router problem statement -

* ABFAB Architecture document -

Bar BOF Presentations: