Subject: New Work Items - Kitten Recharter

From: Shawn Emery <[email-masked]>
Date: Fri, 06 Aug 2010 23:51:59 -0600

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.

If we do decide to shepherd these drafts then we will recharter again to 
include the following patch:

@@ -50,10 +50,14 @@

  * A SASL Mechanism for OpenID
      draft-lear-ietf-sasl-openid-00
  * A SASL Mechanism for SAML
      draft-wierenga-ietf-sasl-saml-00
+* A SASL Mechanism for SAML Enhanced Client
+    draft-cantor-ietf-sasl-saml-ec
+* A SASL Mechanism for OAuth
+    draft-mills-kitten-sasl-oauth

  The transition from SASL to GSS-API mechanisms will allow a greater set of
  applications to utilize said mechanisms with SASL implementations that 
support
  the use of GSS-API mechanisms in SASL (draft-ietf-sasl-gs2).

Shawn.
--

---

From: Klaas Wierenga <[email-masked]>
Date: Sat, 7 Aug 2010 09:23:08 +0200

I support adopting both drafts.

Klaas

Sent from my iPad

On Aug 7, 2010, at 7:57 AM, "Shawn Emery" <[email-masked]> wrote:

> 
> We are looking for consensus on whether the Kitten WG should adopt the following drafts as work items:
> 
> You can respond to lists (kitten or SASL), but please indicate your decision regardless if you are for or against the proposal.
> 
> If we do decide to shepherd these drafts then we will recharter again to include the following patch:
> 
> @@ -50,10 +50,14 @@
>  
>  applications to utilize said mechanisms with SASL implementations that support
> _______________________________________________
> sasl mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sasl

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Aug 2010 09:36:00 +0100

> to include the following patch:

<hat type="AreaDirector">
I think IESG might want to know why there are 2 separate SAML 
mechanisms. While I can be convinced that both of them might be needed, 
the WG should have some good arguments to defend this.
</hat>

<hat type="IndividualContributor">
I think both of the documents should be discussed in the WG.
</hat>

> +    draft-mills-kitten-sasl-oauth

<hat type="IndividualContributor">
I am also happy to take this one as a WG item.
</hat>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Aug 2010 11:12:57 +0200

> 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.  

Discovery is also handled in Scott's draft.  That is something that we
should consider incorporating into the other.

Eliot

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Aug 2010 14:58:55 +0200

Hi Eliot,

Eliot Lear wrote:

> 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 
>  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.

> should consider incorporating into the other.

Right.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 09 Aug 2010 16:37:48 +0300

Hey Shawn,

this makes sense to me (as discussed during the WG session at the recent 
IETF meeting).

Ciao
Hannes

On 8/7/2010 8:51 AM, Shawn Emery wrote:
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: "Scott Cantor" <[email-masked]>
Date: Mon, 9 Aug 2010 09:55:58 -0400

> 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.

My proposal uses ECP, which means the exchange with the IdP is generally (and can be required to be) SOAP over HTTP. There is generally no need for a web browser in the client, or anything like that. That's the IPC you're referring to.
 
> should consider incorporating into the other.

I believe the latest draft of Klaas' proposal does this, though in a different way from ECP of course.

-- Scott

---

From: "Scott Cantor" <[email-masked]>
Date: Mon, 9 Aug 2010 10:06:40 -0400

> My proposal uses ECP, which means the exchange with the IdP is generally
> (and can be required to be) SOAP over HTTP. There is generally no need for
a
> web browser in the client, or anything like that. That's the IPC you're
> referring to.

Actually rereading you meant IPC between the client and some local agent.
What I'm trying to say is that the client/IdP exchange is structured (SOAP),
not unstructured (HTML). The client requirements of my mechanism proposal
are trivial (until/unless we add holder of key or other kinds of security
options).
 
-- Scott

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 09 Aug 2010 14:40:35 -0400

> convinced that the assumption is something important enough to warrant

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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Aug 2010 20:41:51 +0200

Jeffrey Hutzelman wrote:

> 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.