[abfab] Comments on draft-ietf-abfab-usability-ui-considerations-04.txt

Alejandro Pérez Méndez <alex@um.es> Thu, 28 July 2016 12:06 UTC

Return-Path: <alex@um.es>
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 168BD12DF7E for <abfab@ietfa.amsl.com>; Thu, 28 Jul 2016 05:06:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.488
X-Spam-Level:
X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 3erFI3gBTLs1 for <abfab@ietfa.amsl.com>; Thu, 28 Jul 2016 05:06:29 -0700 (PDT)
Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEA512DF7D for <abfab@ietf.org>; Thu, 28 Jul 2016 05:06:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 4F3CE3FAE9 for <abfab@ietf.org>; Thu, 28 Jul 2016 14:06:27 +0200 (CEST)
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 TRB3UaglutnK for <abfab@ietf.org>; Thu, 28 Jul 2016 14:06:27 +0200 (CEST)
Received: from [192.168.100.8] (unknown [185.154.58.221]) (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 29E683FAE6 for <abfab@ietf.org>; Thu, 28 Jul 2016 14:06:25 +0200 (CEST)
To: abfab@ietf.org
From: Alejandro Pérez Méndez <alex@um.es>
Message-ID: <77c876d5-2816-38d0-beb6-9067eb93104a@um.es>
Date: Thu, 28 Jul 2016 14:06:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/abfab/KrLG-vOWjFjVAuqzCGRYj8L9Y1w>
Subject: [abfab] Comments on draft-ietf-abfab-usability-ui-considerations-04.txt
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 28 Jul 2016 12:06:31 -0000

Hi all,

I've reviewed draft-ietf-abfab-usability-ui-considerations-04. Following you can find my comments. I hope they can help moving this document forward.

Overall I find that the new sections provide better readability and completeness to the document. Good job! The document is even easier to follow, and provides a good guidance for future (and present) developers of ABFAB Identity Selectors. Hence, I consider the document ready for a WGLC, granted some minor comments and doubts I have are addressed or clarified either on the text or on the ML.

#1 On page 9, the text says "If the identity contains no password change URL or helpdesk URL, the identity selector MAY present any corresponding URL from the identity selector instead.". Should this be "...from the identity provider..." instead?

#2 On page 16, section 6.8 deals with storing identities with and without credentials. However, this is also dealt in section 6.1, when talking about the optional information an identity may have associated. Should both texts be merged?

#3 On page 19, section 7.3 is titled "Listing Services and Identities", but it only talks about listing services.

#4 On page 19, section 7.5 says "the identity selector will certainly know when successful (or failed) authentications to a particular service have happened." How does this happen? Is the Identity Selector somehowconnected to the GSS-EAP mechanism in order to obtain such feedback (e.g. D-BUS)? In that case, wouldn't it be worth mentioning that the Identity Selector must be listening for events from the mechanism? Should this communication interface be standardized, or does it depend on the GSS-EAP implementation?
  
#5 On page 20, section 8.1 mentions two new GSS-API extensions. I'm not sure I'm getting their purpose. Are they intended to inform the IdP or other entity? How does they improve error handling? I would appreciate a little more elaboration. Has this suggestion been made to the kitten WG? A reference to the discussion would be appreciated.

In any case, does it make sense to have them listed on an RFC-to-be without providing all their technical information (parameters, expected return values, etc.).

Best regards,
Alejandro