Re: [sasl] Kitten Recharter

[Alexey Melnikov <[e-mail]>]

Shawn Emery wrote:

> Per the recent thead on "MOGGIES Proposed Charter"; I have taken 
> suggestions by kitten/SASL WG members and created recharter text for 
> Kitten (whilst closing SASL).  Please let me know if I missed anything.
>
> Shawn.
> Kitten co-chair.

Hi Sean,
Thanks for the updated version. This looks much better.
Some additional comments inline.

>Kitten (Common Authentication Technology Next Generation)
>
>
>Description of Working Group:
>
>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 following:
>	initializing credentials
>	iterating credentials
>	exporting/importing credentials
>
>* Specify interface for asynchronous calls.
>
>* Define interfaces for better error message reporting.
>
>* Provide a more programmer friendly interface for application developers.
>  
>
This point is a bit vague. Do we actually need this as an explicit goal?

>This WG is also chartered to transition proposed SASL mechanisms as
>GSS-API mechanisms:
>
>* A SASL Mechanism for OpenID
>	draft-lear-ietf-sasl-openid-00
>* A SASL Mechanism for SAML
>	draft-wierenga-ietf-sasl-saml-00
>
>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 (draft-ietf-sasl-gs2).
>
>* Shepard draft-melnikov-digest-to-historic through standards track.
>
typo: shephard

>This WG should review proposals for new SASL and GSS-API mechanisms.  The WG
>should also review non-mechanism proposals related to SASL and the GSS-API.
>
I think this is a bit too open-ended for IESG. I would have asked about 
that if I were asked to review such charter ;-).

To be frank, I would delete these 2 sentences, or say the exactly 
opposite: other proposals would require rechartering. However chairs 
always have some flexibility in allowing conversations on related 
topics, as long as this doesn't compromise progress on major deliverables.

>Deliverables:
>
>* GSS-API: initializing credentials
>[editor: TBD]
>
>* GSS-API: iterating credentials
>[editor: TBD]
>
>* GSS-API: exporting/importing credentials
>[editor: TBD]
>
>* GSS-API: specification for asynchronous calls
>[editor: TBD]
>
>* GSS-API: interfaces/improvements for better error message reporting
>[editor: TBD]
>
>* GSS-API: programmer friendly interfaces
>[editor: TBD]
>
>* GSS-API: transition SASL mechanism for OpenID
>[editor: TBD]
>
>* GSS-API: transition SASL mechanism for SAML
>[editor: TBD]
>
>* GSS-API: publish draft-ietf-kitten-gssapi-extensions-iana
>[editor: Nicolas Williams]
>
>* GSS-API: publish draft-ietf-kitten-gssapi-naming-exts
>[editor: Leif Johansson]
>
>* SASL: publish draft-melnikov-digest-to-historic
>[editor: Alexey Melnikov]
>
>Goals and Milestones:
>
>June 2010	Submit publish draft-ietf-kitten-gssapi-naming-exts to the IESG as Proposed Standard
>June 2010	WGLC, again, on draft-ietf-kitten-gssapi-extensions-iana
>July 2010	Submit draft-ietf-kitten-gssapi-extensions-iana to the IESG as Proposed Standard
>July 2010	First Meeting
>TBD		Other Listed Work Items
>  
>