Re: [sasl] New Work Items - Kitten Recharter

[Jeffrey Hutzelman <[e-mail]>]

--On Monday, August 09, 2010 02:58:55 PM +0200 Alexey Melnikov 
<[e-mail]> 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.

-- Jeff