Skip to main content

Common Authentication Technology Next Generation

The information below is for an older approved charter
Document Charter Common Authentication Technology Next Generation WG (kitten) Snapshot
Title Common Authentication Technology Next Generation
Last updated 2004-10-28
State Approved
WG State Active
IESG Responsible AD Paul Wouters
Charter edit AD (None)
Send notices to (None)

The Generic Security Services (GSS) API and Simple Authentication and
  Security Layer (SASL) provide various applications with a security
  framework for secure network communication. The purpose of the Common
  Authentication Technology Next Generation (Kitten) working group (WG) is
  to develop extensions/improvements to the GSS-API, shepherd specific
  GSS-API security mechanisms, and provide guidance for any new SASL-
  related submissions.
  This working is chartered to specify the following extensions and
  improvements (draft-yu-kitten-api-wishlist-00) to the GSS-API:
  * Provide new interfaces for credential management, which include the
     initializing credentials
     iterating credentials
     exporting/importing credentials
  * Specify interface for asynchronous calls.
  * Negotiable replay cache avoidance
  * Define interfaces for better error message reporting.
  * Provide a more programmer friendly GSS-API for application developers.
  This could include reducing the number of interface parameters, for
  example, by eliminating parameters which are commonly used with the
  default values.
  * Specify an option for exporting partially-established security
    contexts and possibly a utility function for exporting security
    contexts in an encrypted form, as well as a corresponding utility
    function to decrypt and import such security context tokens.
  This WG is also chartered to finalize proposed SASL mechanisms as
  GSS-API mechanisms (based on RFC 5801):
  * A SASL Mechanism for OpenID
  * SASL Mechanisms for SAML:
  The SAML mechanism drafts will include applicability
  statement text to highlight when each is appropriate
  for use.
  * A SASL Mechanism for OAuth
  The transition from SASL to GSS-API mechanisms will allow a greater set
  of applications to utilize said mechanisms with SASL implementations
  that support the use of GSS-API mechanisms in SASL (RFC 5801).
  This WG should review proposals for new SASL and GSS-API mechanisms, but
  may take on work on such mechanisms only through a revision of this
  charter. The WG should also review non-mechanism proposals related to
  SASL and the GSS-API. However, work that adds SASL or GSS-API support in
  application protocols is out of scope and should be handled by the
  corresponding application's WG.
  * GSS-API: initializing credentials
  * GSS-API: iterating credentials
  * GSS-API: exporting/importing credentials
  * GSS-API: specification for asynchronous calls
  * GSS-API: interfaces/improvements for better error message reporting
  * GSS-API: programmer friendly interfaces
  * SASL: SASL mechanism for OpenID
  * SASL: SASL mechanisms for SAML
  * SASL: SASL mechanism for OAuth
  * GSS-API: publish draft-ietf-kitten-gssapi-extensions-iana