SAML Enhanced Client SASL and GSS-API Mechanisms
draft-ietf-kitten-sasl-saml-ec-20

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.

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 is the
    responsible area director.

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.

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 is the
    responsible area director.

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.