A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML)
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, kitten mailing list <firstname.lastname@example.org>, kitten chair <email@example.com> 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/
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].