SAML @ IETF

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

As I mentioned on the TC call on Nov 22, there has occasionally been 
interest in SAML in activities in and around the IETF.  There seemed to be 
more interest at the recent IETF meeting (in Vancouver Nov 7-11) based on 
conversations I had with a number of people.  Here's some info on this 
offered as a public service to the SAML community (ie, I'm not proposing 
any TC work related to any of this).

One venue is SIP (not SXIP as reported in the conf call minutes), ie the 
Session Initiation Protocol used for Internet telephony etc.  There is a 
document:

   draft-tschofenig-sip-saml-04.txt

that has been kicking around for a while, describing how SAML might be 
used in SIP.  The primary motivation is getting user (caller) attributes 
to a relying party.  This item is now in the SIP WG charter, which means a 
certain level of commitment to finishing it.  Concern was expressed at the 
WG session that it seems to be taking a long time to be moving from good 
idea to spec.  I think this could be helped by participation from 
SAML-knowledgable persons, so I've started a list for discussion of the 
topic.  SIP is a more complex application space than you might think, so 
it's something of a design challenge.  If you'd like to join the list let 
me know (I'm keeping it design-teamy at the moment rather than a big 
public thing).

Another venue is SASL/GSS.  There is interest in both specifying SAML as a 
native SASL and/or GSS security mechanism, and in specifying how SAML 
attribute statements could be used in the context of existing mechanisms 
such as Kerberos.  In the "kitten" WG there's work on extending GSSAPI 
"naming" to include general attributes as well as the GSS traditional 
userid type identifiers, see draft-ietf-kitten-gss-naming-03.txt , partly 
motivated by the possible use of SAML attribute statements in GSS 
mechanisms.  I've started a list for this topic too, let me know if you're 
interested.

Not really SAML but close enough to mention is the interest in improving 
actual HTTP authentication.  One motivation for this is the Caldav 
protocol for calendar access that is nearing completion, and is based on 
Webdav, which of course is based on HTTP.  Since Caldav/webdav clients 
aren't web browsers the methods we use to make the SAML web browser 
profile won't work for them, which leaves Basic and Digest as the only 
authentication choices.  There has been a doc floating around for a while 
proposing SASL for HTTP, but it has many problems; so people are taking a 
fresh look at this.  There's a list for this:

   http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

that has been fairly active in the last month or so.

Lastly, the fine folks from SXIP initiated a discussion of "identity 
exchange" in the IETF context, see

   https://www1.ietf.org/mailman/listinfo/dix

with the intent to start a WG on the topic, and to standardize a protocol 
(not necessarily SXIP).  Considerations of whether such a thing is useful 
given SAML, WS-*, etc are certainly in scope for the discussion.

  - RL "Bob"