Loading...

sasl@ietf.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [sasl] New Work Items - Kitten Recharter Alexey Melnikov Mon Aug 09 12:00:47 2010 

Jeffrey Hutzelman wrote:
--On Monday, August 09, 2010 02:58:55 PM +0200 Alexey Melnikov <[EMAIL PROTECTED]> 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 mailing list
[EMAIL PROTECTED]
https://www.ietf.org/mailman/listinfo/sasl