[ 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 ---