A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML)
draft-ietf-kitten-sasl-saml-09

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    kitten mailing list <kitten@ietf.org>,
    kitten chair <kitten-chairs@tools.ietf.org>
Subject: Protocol Action: 'A SASL and GSS-API Mechanism for SAML' to Proposed Standard (draft-ietf-kitten-sasl-saml-09.txt)

The IESG has approved the following document:
- 'A SASL and GSS-API Mechanism for SAML'
  (draft-ietf-kitten-sasl-saml-09.txt) as a Proposed Standard

This document is the product of the Common Authentication Technology Next
Generation Working Group.

The IESG contact persons are Stephen Farrell and Sean Turner.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml/

Ballot Text

Technical Summary

   This document describes a Simple Authentication and Security 
   Layer (SASL) mechanism for the SAML 2.0 specification.

Working Group Summary

   One controversial issue that may come up is in regards to another draft that
   the kitten WG has adopted; draft-ietf-sasl-saml-ec.  The saml and saml-ec drafts 
   both use SAML as an authentication function, but have different use cases.  The
   SAML solution requires less changes to the various entities than does
   SAML-EC.  SAML-EC requires that the SASL client change.  For cases such as
   browsers, this may not be an option in some environments.  SAML-EC also
   requires that the Identity Provider support its ECP profile.  However, SAML-EC
   provides a more integrated user solution and will provide additional support
   for GSS-API per-message tokens. 

Document Quality

   This protocol has been implemented in GNU SASL 1.7.0 and a number of
   applications have utilized this version including SimpleSAMLPHP 1.6.2
   with Jabberd server 2.2.11 and XMPPHP 0.1rc2-r77. 

Personnel

   The document shepherd is Shawn Emery
   The responsible AD is Stephen Farrell

RFC Editor Note

#1 In section 3.1 please delete a sentence as shown below:

OLD

  Domain name is specified in [RFC1035].  A domain name is either a
   "traditional domain name" as described in [RFC1035] or an
   "internationalized domain name" as described in [RFC5890].

NEW

    A domain name is either a
   "traditional domain name" as described in [RFC1035] or an
   "internationalized domain name" as described in [RFC5890].

#2 In section 3.2 please make the following replacement:

OLD
   Should the client
   support Internationalized Resource Identifiers (IRIs) [RFC3987] it
   MUST first convert the IRI to a URI before transmitting it to the
   server [RFC5890].

NEW
   Should the client
   support Internationalized Resource Identifiers (IRIs) [RFC3987] it
   MUST first map the IRI to a URI before transmitting it to the
   server, as defined in Section 3.1 of [RFC3987].

RFC Editor Note