IETF Logo Mail Archive

Re: [abfab] Direction Forward for aaa-saml

Sam Hartman <hartmans@painless-security.com> Wed, 22 July 2015 16:28 UTC

Return-Path: <hartmans@painless-security.com>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378311A8AC7 for <abfab@ietfa.amsl.com>; Wed, 22 Jul 2015 09:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cf3rnD28MCA for <abfab@ietfa.amsl.com>; Wed, 22 Jul 2015 09:28:18 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D90F1B2A32 for <abfab@ietf.org>; Wed, 22 Jul 2015 09:26:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 47C5D2075D; Wed, 22 Jul 2015 12:26:29 -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 QtoETmxthi3T; Wed, 22 Jul 2015 12:26:28 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (dhcp-89db.meeting.ietf.org [31.133.137.219]) (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; Wed, 22 Jul 2015 12:26:28 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 030B98867F; Wed, 22 Jul 2015 12:26:51 -0400 (EDT)
From: Sam Hartman <hartmans@painless-security.com>
To: Leif Johansson <leifj@mnt.se>
References: <tslwpxsy0ql.fsf@mit.edu> <8E4E5965-0E43-4ABD-8853-8A6C7C6926C5@mnt.se> <tsloaj4xzvr.fsf@mit.edu> <0B96365A-4F6B-427A-9A87-70F069473F84@mnt.se> <tsl7fpsxrve.fsf@mit.edu> <0A08B89E-5533-4E34-9014-97C0D7877B6E@osu.edu> <tslio9cw8yd.fsf@mit.edu> <D143C9FB-F878-49C1-89C4-6A494714A3EC@mnt.se> <tslegk0w7iw.fsf@mit.edu> <1FA8CCED-221E-4A88-B525-BF46FAA53A3F@mnt.se> <55AFC0E3.8030500@um.es> <tslpp3kuq2f.fsf@mit.edu> <55AFC24C.3070205@sunet.se> <tslh9owuptm.fsf@mit.edu> <55AFC37D.1040607@mnt.se>
Date: Wed, 22 Jul 2015 12:26:51 -0400
In-Reply-To: <55AFC37D.1040607@mnt.se> (Leif Johansson's message of "Wed, 22 Jul 2015 18:23:25 +0200")
Message-ID: <tsl4mkwupis.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/abfab/weINOZbiOgeewYymMfdN6BK0eeE>
Cc: abfab@ietf.org
Subject: Re: [abfab] Direction Forward for aaa-saml
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 16:28:20 -0000

>>>>> "Leif" == Leif Johansson <leifj@mnt.se> writes:

    Leif> On 2015-07-22 18:20, Sam Hartman wrote:
    >>>>>>> "Leif" == Leif Johansson <leifj@sunet.se> writes:

    Leif> (I am and was speaking entirely wo any chair hats on btw)

    >> 
    >> 
    Leif> Right but we _could_ add Endpoint and leave the work of
    Leif> specifying the URL format of radius radsec servers to whomever
    Leif> wanted to deploy it
    >> 
    >> I'm very against that.  It's not guaranteed to be interoperable
    >> without the URI and I don't think we'd have confidence in the
    >> semantics without going through the URI spec.

    Leif> Thats why we have the Binding parameter! If you don't
    Leif> understand the Binding then you can't use the Endpoint.

No, my point is that until the URI is specified, it seems unlikely that
two implementations would both work with this endpoint.
I absolutely agree that it wouldn't break other bindings.
But for example if one implementation wanted radsec://... and one wanted
radius+tls://... then they wouldn't both be able to consume the same
metadata.

v2.23.0 | Report a Bug | By Email