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.
- [sasl] New Work Items - Kitten Recharter Shawn Emery
- Re: [sasl] New Work Items - Kitten Recharter Klaas Wierenga
- Re: [sasl] New Work Items - Kitten Recharter Alexey Melnikov
- Re: [sasl] New Work Items - Kitten Recharter Eliot Lear
- Re: [sasl] New Work Items - Kitten Recharter Alexey Melnikov
- Re: [sasl] New Work Items - Kitten Recharter Scott Cantor
- Re: [sasl] New Work Items - Kitten Recharter Scott Cantor
- Re: [sasl] New Work Items - Kitten Recharter Hannes Tschofenig
- Re: [sasl] New Work Items - Kitten Recharter Jeffrey Hutzelman
- Re: [sasl] New Work Items - Kitten Recharter Alexey Melnikov