Re: [abfab] Barry Leiba's No Objection on draft-ietf-abfab-aaa-saml-13: (with COMMENT)

Alejandro Pérez Méndez <alex@um.es> Mon, 11 January 2016 08:45 UTC

Return-Path: <alex@um.es>
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 E85281A8823; Mon, 11 Jan 2016 00:45:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.902
X-Spam-Level:
X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 b78__d_1nXAz; Mon, 11 Jan 2016 00:45:10 -0800 (PST)
Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id A81FC1A87F1; Mon, 11 Jan 2016 00:45:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id F0F433F8C1; Mon, 11 Jan 2016 09:45:08 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon21.um.es
Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id v7v0na5Vl0f8; Mon, 11 Jan 2016 09:45:08 +0100 (CET)
Received: from [192.168.1.5] (79.109.150.87.dyn.user.ono.com [79.109.150.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon21.um.es (Postfix) with ESMTPSA id DD7A43F8C0; Mon, 11 Jan 2016 09:45:06 +0100 (CET)
To: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>
References: <20160107014638.22674.62959.idtracker@ietfa.amsl.com>
From: =?UTF-8?Q?Alejandro_P=c3=a9rez_M=c3=a9ndez?= <alex@um.es>
Message-ID: <56936B91.4040508@um.es>
Date: Mon, 11 Jan 2016 09:45:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <20160107014638.22674.62959.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/abfab/uQ-739fcruPVnk7zOgoXuTwVWgk>
Cc: abfab@ietf.org, abfab-chairs@ietf.org, draft-ietf-abfab-aaa-saml@ietf.org
Subject: Re: [abfab] Barry Leiba's No Objection on draft-ietf-abfab-aaa-saml-13: (with COMMENT)
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: Mon, 11 Jan 2016 08:45:12 -0000

Hi Barry,

thanks for your comments. See my responses inline, please.

El 07/01/16 a las 02:46, Barry Leiba escribió:
> Barry Leiba has entered the following ballot position for
> draft-ietf-abfab-aaa-saml-13: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-abfab-aaa-saml/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Because abfab-arch defines the terms "Client", "Relying Party", and
> "Identity Provider", I think abfab-arch should be a normative reference.

As per the discussion you had with Sam, I see your point and I'm not 
against it.
On the other hand, I think that the terms "Client", "Relaying Party", 
and "Identity Provider" are common enough to don't require readers to go 
to the reference to understand them, specially when the document already 
contains a terminlogy table that matches these terms with their SAML and 
RADIUS correspondences.

>
> -- Section 3 --
>
>     The RADIUS SAML binding defined in Section 4 of this document uses
>     two attributes to convey SAML assertions and protocol messages
>     respectively [OASIS.saml-core-2.0-os]
>
> Nit: "respectively" is out of place here, and should be removed.  You
> would only use "respectively" if you named the two attributes ("...uses
> two attributes, SAML-Assertion and SAML-Protocol, to convey SAML
> assertions and protocol messages, respectively.").

Right, thanks. Probably the result of an edit to remove the attribute 
names from that paragraph.

>
> -- Section 7.3.5 --
>
>     If issued by the Identity Provider, the Relying Party MUST process
>     the <samlp:Response> message and any enclosed assertion elements as
>     described in [OASIS.saml-core-2.0-os]
>
> "If issued" is dangling, and  makes it look like the Relying Party is
> issued by the Identity Provider.
>
> NEW
>     If a <samlp:Response> message is issued by the Identity Provider,
>     the Relying Party MUST process that message and any enclosed
>     assertion elements as described in [OASIS.saml-core-2.0-os]
> END

Thanks, the text you've provided sounds much more clear. I will include it.

Best regards,
Alejandro

>
> -- Section 11.2 --
> Thank you; this section is well done.
>
>