1. Summary
This document defines a mechanism for use of Security Assertion Markup
Language (SAML) 2.0 in both the Security Authentication and Security Layer
(SASL) and the Generic Security Services Application Programming Interface
(GSS-API). This mechanism eases the use of SAML outside the browser, and
thereby improves federated authentication capabilities as well.
This is a Proposed Standard document since it defines this new mechanism
and its behavior.
Robbie Harwood is the document shepherd. Benjamin Kaduk was the
responsible area director, but this has now changed to Paul Wouters.
2. Review and Consensus
There is good consensus around this document, which integrates federation
with existing authentication technologies. The integration of SAML with
SASL is explicitly mentioned in our charter, and there was no opposition
to adopting a document to integrate the two.
This document has strong working group interest due to it being a focus of
the historical sasl working group (which moved into kitten in our
recharter). The first version was created in 2010, and at the time there
was another proposal which was more strongly tied to the web browser.
Early discussion was focused around merging the two proposals, and
consensus on this document's approach (with some changes) was achieved
prior to adopting this document in kitten. At that point, there was
additional detailed review and refinement from several members, but no
very little contention about changes.
There is a mature implementation which works with Shibboleth at
https://github.com/fedushare/mech_saml_ec to which several kitten members
have contributed; there are no outstanding specification issues reported
by this implementation.
3. Intellectual property
There are no intellectual property disclosures against this document, and
the I-D was submitted in full conformance with BCP 78 and BCP 79.
4. Other information
The IANA considerations are twofold. First, this document request a new
entry in an existing registry for GSS-API and SASL mechanisms,
corresponding to the mechanism this document defines. Second, it requests
a sub-namespace for XML constructs that the mechaism uses, and includes a
schema for it.
idnits warns about non-rfc2606-complaint FQDNs; this is a false positive.
Likewise, the normative use of the OASIS standard "SAML V2.0 Enhanced
Client or Proxy Profile Version 2.0" is intentional.