Protocol Action: 'A SASL and GSS-API Mechanism for SAML' to Proposed Standard (draft-ietf-kitten-sasl-saml-09.txt)

The IESG <iesg-secretary@ietf.org> Wed, 22 February 2012 15:21 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A66821F87C0; Wed, 22 Feb 2012 07:21:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.507
X-Spam-Level:
X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrKl79WCM5Ma; Wed, 22 Feb 2012 07:21:28 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDFD21F87AD; Wed, 22 Feb 2012 07:21:23 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'A SASL and GSS-API Mechanism for SAML' to Proposed Standard (draft-ietf-kitten-sasl-saml-09.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64p2
Message-ID: <20120222152123.3069.72978.idtracker@ietfa.amsl.com>
Date: Wed, 22 Feb 2012 07:21:23 -0800
Cc: kitten mailing list <kitten@ietf.org>, kitten chair <kitten-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Feb 2012 15:21:35 -0000

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/




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