Subject: [radext] Trust Router BAR BOF at IETF 86: Thursday at 1130

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Mar 2013 12:39:25 -0500

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.

Come join us to talk all about trust and trust routing at our Bar BOF - to be
held on Thursday March 14th @ 11:30AM, located in Caribbean 7.

Documents to read:
* Trust Router problem statement - http://tools.ietf.org/html/
draft-howlett-abfab-trust-router-ps-02
* ABFAB Architecture document - http://tools.ietf.org/html/
draft-ietf-abfab-arch-05
* Trust router protocol overview -
http://tools.ietf.org/html/draft-mrw-abfab-trust-router-02.txt

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Mar 2013 12:45:55 -0500

>>>>> "Klaas" == Klaas Wierenga (kwiereng) <[email-masked]> writes:

    Klaas> Sam, How does this relate to the trust router slot in Routing
    Klaas> Area Open Meeting?

we're going to introduce the topic and try and get routing folks to go
to the bar bof.
We think having routing clue review the trust router would be valuable.

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 6 Mar 2013 20:54:41 +0100

> We think having routing clue review the trust router would be valuable.

Agreed, makes a lot of sense.

Klaas

> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Wed, 6 Mar 2013 17:43:10 +0000

Sam,

How does this relate to the trust router slot in Routing Area Open Meeting?

Klaas

Sent from my iPad

On 6 mrt. 2013, at 18:39, "Sam Hartman" <[email-masked]> wrote:

> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab