Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch

Sam Hartman <hartmans@painless-security.com> Mon, 30 September 2013 11:11 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 3183021F9C36 for <abfab@ietfa.amsl.com>; Mon, 30 Sep 2013 04:11:40 -0700 (PDT)
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 zPddE9-jyafB for <abfab@ietfa.amsl.com>; Mon, 30 Sep 2013 04:11:24 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC7221F893E for <abfab@ietf.org>; Mon, 30 Sep 2013 04:11:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 842612037F; Mon, 30 Sep 2013 07:10:17 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o71nIQZzKwWf; Mon, 30 Sep 2013 07:10:17 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (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; Mon, 30 Sep 2013 07:10:16 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E598C82A83; Mon, 30 Sep 2013 07:11:18 -0400 (EDT)
From: Sam Hartman <hartmans@painless-security.com>
To: David Chadwick <d.w.chadwick@kent.ac.uk>
References: <tsl61ug7n72.fsf@mit.edu> <052301ceb814$54e4caa0$feae5fe0$@augustcellars.com> <523FE430.4040106@kent.ac.uk> <01ee01cebba0$2dc575c0$89506140$@augustcellars.com> <5246C6B1.9030500@kent.ac.uk> <00d701cebca3$37ead0f0$a7c072d0$@augutscellars.com> <524882A8.9050003@kent.ac.uk>
Date: Mon, 30 Sep 2013 07:11:18 -0400
In-Reply-To: <524882A8.9050003@kent.ac.uk> (David Chadwick's message of "Sun, 29 Sep 2013 20:42:32 +0100")
Message-ID: <tslpprqk1ih.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: Trevor Freeman <trevorf@exchange.microsoft.com>, abfab@ietf.org, Jim Schaad <ietf@augutscellars.com>
Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch
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: Mon, 30 Sep 2013 11:11:40 -0000

>>>>> "David" == David Chadwick <d.w.chadwick@kent.ac.uk> writes:

    David> I would be interested in giving a presentation about this,
    David> but unfortunately I cannot attend the next IETF meeting as it
    David> clashes with Openstack in Honk Kong (where I am also giving a
    David> presentation on Federation). But the first meeting next year
    David> could be suitable
In preparing a presentation, I'd ask that you focus a lot of effort on
    David> describing your assumptions.  We found when discussing trust
    David> router that you had a different set of assumptions than the
    David> rest of the room and until those assumptions were described I
    David> found myself rather frustrated.

I can already tell we're going to have similar issues with this
discussion.
As an example, in an earlier message, you stated that the SP is the only
party that  knows what attributes the SP needs.

There are cases where that's true, but one of the major motivations
behind the COI concept in Moonshot is to move knowledge about what
attributes are required around so that the IDP has more information
about this.

Similarly you propose that authentication happen prior to deciding what
service of a multi-service SP is used.  That's one approach, but it has
a lot of problems.  One is that you may want a different federation
fabric to use for different services.

I believe you're stating things as facts that are simply one
decomposition of the problem space.
I don't mind examining that decomposition of the problem space.  If
there are enough folks interested in writing code and specs and
reviewing them, I think doing work there could be very interesting.
However, I think it's also important to understand that decomposition
involves a lot of complexity.  There are alternate organizations of the
relationship between SP and IDP that may work better in different
environments.
I think understanding when complexity is necessary is quite desirable.

--Sam