Re: [sasl] New Work Items - Kitten Recharter

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 09 August 2010 18:42 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: sasl@core3.amsl.com
Delivered-To: sasl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D671D3A6940; Mon, 9 Aug 2010 11:42:13 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rs5vjN1uV6en; Mon, 9 Aug 2010 11:42:12 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 922D83A683C; Mon, 9 Aug 2010 11:42:12 -0700 (PDT)
Received: from [172.16.2.104] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <TGBMGwBIEDN-@rufus.isode.com>; Mon, 9 Aug 2010 19:42:44 +0100
Message-ID: <4C604BEF.8050503@isode.com>
Date: Mon, 09 Aug 2010 20:41:51 +0200
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Jeffrey Hutzelman <jhutz@cmu.edu>
References: <4C5CF47F.5040102@oracle.com> <4C5FC699.8060902@cisco.com> <17613_1281358755_o79CxEZL028303_4C5FFB8F.6030406@isode.com> <4C6210AE12B6E901D2025331@atlantis.pc.cs.cmu.edu>
In-Reply-To: <4C6210AE12B6E901D2025331@atlantis.pc.cs.cmu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org, sasl@ietf.org
Subject: Re: [sasl] New Work Items - Kitten Recharter
X-BeenThere: sasl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SASL Working Group <sasl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sasl>, <mailto:sasl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sasl>
List-Post: <mailto:sasl@ietf.org>
List-Help: <mailto:sasl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sasl>, <mailto:sasl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Aug 2010 18:42:13 -0000

Jeffrey Hutzelman wrote:

> --On Monday, August 09, 2010 02:58:55 PM +0200 Alexey Melnikov 
> <alexey.melnikov@isode.com> wrote:
>
>> Hi Eliot,
>>
>> Eliot Lear wrote:
>>
>>>> We are looking for consensus on whether the Kitten WG should adopt
>>>> the following drafts as work items:
>>>>
>>>>     draft-cantor-ietf-sasl-saml-ec
>>>>     draft-mills-kitten-sasl-oauth
>>>>
>>>> You can respond to lists (kitten or SASL), but please indicate your
>>>> decision regardless if you are for or against the proposal.
>>>
>>>
>>> I support the inclusion of both drafts in our milestones.  To answer
>>> Alexey's reaonable question, draft-wierenga-ietf-sasl-saml attempts to
>>> rely on existing infrastructure as much as possible, both on the
>>> client and on the IdP, while requiring some substantial changes to the
>>> RP.   draft-cantor-ietf-sasl-saml-ec requires more substantial changes
>>> to the client, but keeps SAML within the application protocol.  The
>>> implication of the design choices relate more to how actual
>>> authentication gets performed between the SASL client and the IdP.
>>>  Existing IdPs make use of HTTP/HTML and unstructured exchanges for
>>> that authentication.
>>>
>>> In Scott's draft, that occurs in step (4).  This requires the client
>>> to have substantially more capabilities than it might have today with
>>> either a fully functional web browser either built into the
>>> application or tied to the application via some form of IPC with
>>> sufficient semantic abilities to discern when to move through step 4
>>> to step 5, but at the same time, provides for an overall simpler
>>> protocol flow than the document that Klaas and I have put forth.
>>
>> Yes, I've seen this argument on the mailing list. Two documents suggest
>> reasonable solutions for the assumption made. However I am not yet fully
>> convinced that the assumption is something important enough to warrant
>> having 2 documents.
>
> The failure here is not in having two documents to discuss, but in 
> insisting on having specific documents listed by name in the charter.  
> A charter work item should be something like "produce a SAML-based 
> GSS-API mechanism", which could be satisfied by either of these 
> documents by the time we're done with them.  Perhaps in the end we'll 
> choose one or the other, or perhaps we'll decide that two mechanisms 
> really are necessary, in which case we'll make the case to the IESG as 
> to why both should by published.

Yes, I was about to suggest the same. Not naming specific documents 
would be better in this case.