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

Sam Hartman <hartmans@painless-security.com> Wed, 06 March 2013 17:39 UTC

Return-Path: <hartmans@painless-security.com>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A163921F8A56; Wed, 6 Mar 2013 09:39:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCqCV6BtmQAv; Wed, 6 Mar 2013 09:39:35 -0800 (PST)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 927A821F89B3; Wed, 6 Mar 2013 09:39:26 -0800 (PST)
Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 1E01C2014B; Wed, 6 Mar 2013 12:39:17 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 83BE141CE; Wed, 6 Mar 2013 12:39:25 -0500 (EST)
From: Sam Hartman <hartmans@painless-security.com>
To: abfab@ietf.org, radext@ietf.org, saag@ietf.org
Date: Wed, 06 Mar 2013 12:39:25 -0500
Message-ID: <tsllia0zauq.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [abfab] Trust Router BAR BOF at IETF 86: Thursday at 1130
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/abfab>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Mar 2013 17:39:39 -0000

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