Subject: SASL mech for SAML "Enhanced Clients" submitted

From: "Scott Cantor" <[email-masked]>
Date: Thu, 27 May 2010 13:16:27 -0400

Klaas, WGs,

My proposed SASL mechanism for SAML is here:
http://www.ietf.org/id/draft-cantor-ietf-sasl-saml-ec-00.txt

I used "EC" to differentiate it from Klaas' browser proposal.

I believe some obvious steps would be:

- address any questions about the differences between this and the browser
proposal
- consider whether to try to merge with Klaas' mechanism, proceed with both,
etc.
- obtain assistance from experts that have volunteered to incorporate
GSS-related changes or improvements
- consider how/whether to strengthen the security characteristics of the
mechanism(s)

-- Scott

---

From: "Josh Howlett" <[email-masked]>
Date: Thu, 27 May 2010 20:37:24 +0100

Scott,

> - address any questions about the differences between this 
> and the browser proposal

There seem to be two principal differences between your proposal and
Klaas':

1. The use of the POAS binding within the SASL mechanism between the RP
and the client.

2. The use of SOAP binding between the client and the IdP.

Is that a reasonable summary?

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

---

From: "Scott Cantor" <[email-masked]>
Date: Thu, 27 May 2010 15:58:10 -0400

(Aside, I'm cc'ing both kitten and sasl, but if this is getting annoying,
feel free to let me know which to drop. Cost of transition I guess.)

> 1. The use of the POAS binding within the SASL mechanism between the RP

I wouldn't exactly call it PAOS (and I avoided referencing that binding),
since that's specifically bound to HTTP. I'm reusing some PAOS headers in
this draft to avoid making some changes to the original profile, but they
don't add much and I'm not sure they're needed. As long as the IdP can
operate in ignorance of the fact that it's not PAOS it shouldn't matter
whether it is or isn't.

What I wanted to do is make this a distinct profile that reused by inclusion
specific sections of the original one so that the actual normative message
definitions would come from the original one. For now at least (see below).

> Is that a reasonable summary?

Pretty much, but the use of the SOAP binding is also an arbitrary choice
designed for the purpose of reusing the ECP profile, and because it's the
only client/IdP SAML binding in existence today that isn't browser-centric.

The way to think about the difference from my point of view is like this:

Klaas' Mechanism:
- produce a URL equivalent to a Web SSO request from an SP
- send back empty response
- launch browser (explicitly or implicitly) and do Web SSO
- route result of Web SSO behind the scenes at server to trigger SASL result

Mine:
- challenge client with SAML AuthnRequest for delivery to IdP
- deliver AuthnRequest to IdP along with credentials to get Response for SP
- respond to SP with Response to complete SASL exchange

The messaging around those steps is essentially arbitrary to the conceptual
model and the ECP conventions were chosen as a starting point for reuse and
to save drafting time.
 
-- Scott