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

Sam Hartman <hartmans-ietf@mit.edu> Tue, 12 March 2013 12:01 UTC

Return-Path: <hartmans@painless-security.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330BD21F8606 for <ietf@ietfa.amsl.com>; Tue, 12 Mar 2013 05:01:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 d+ncObA6nN9Q for <ietf@ietfa.amsl.com>; Tue, 12 Mar 2013 05:01:25 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5162521F86C0 for <ietf@ietf.org>; Tue, 12 Mar 2013 05:01:25 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (unknown [130.129.129.28]) (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 F3CAC20167 for <ietf@ietf.org>; Tue, 12 Mar 2013 08:01:02 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 069B441CF; Tue, 12 Mar 2013 08:01:23 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: ietf@ietf.org
Subject: [ Trust Router BAR BOF at IETF 86: Thursday at 1130
Date: Tue, 12 Mar 2013 08:01:22 -0400
Message-ID: <tsl4nggltd9.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Mailman-Approved-At: Tue, 12 Mar 2013 09:23:14 -0700
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2013 12:01:26 -0000

Hi.
We've also created the trust-router@ietf.org mailing list to discuss the
effort.


--- Begin Message ---
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
_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab

--- End Message ---