Subject: Protocol Action: 'A SASL & GSS-API Mechanism for OpenID' to Proposed Standard (draft-ietf-kitten-sasl-openid-08.txt)

From: The IESG <[email-masked]>
Date: Mon, 05 Mar 2012 13:53:58 -0800

The IESG has approved the following document:
- 'A SASL & GSS-API Mechanism for OpenID'
  (draft-ietf-kitten-sasl-openid-08.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-openid/

Technical Summary

   OpenID has found its usage on the Internet for Web Single Sign-On.
   Simple Authentication and Security Layer (SASL, RFC 4422) and the 
   Generic Security Service Application Program Interface (GSS-API, 
   RFC 2743) are application frameworks to generalize authentication for 
   connection based protocols.  This memo specifies a SASL and 
   GSS-API mechanism for OpenID that allows the integration of existing 
   OpenID Identity Providers with applications using SASL and GSS-API.

   The OpenID foundation have assured the RFC editor that the 
   [OpenID] and [SREG] references are stable.

Working Group Summary

   Nothing worth noting, this document was relatively non controversial
   once the rough consensus was reached in the WG that using a browser
   for some part of SASL authentication is acceptable for some deployments.

Document Quality

   At least one implementation is in progress and one is planned.

Personnel
   
    Alexey Melnikov is the document shepherd.
    Stephen Farrell is the responsible AD.

RFC Editor Note

There are a bunch (7) of little changes.

First, in the References section:

1. Please add the following URL to the [OpenID] reference:
    http://specs.openid.net/auth/2.0

OLD

   [OpenID]   OpenID Foundation, "OpenID Authentication 2.0 - Final",
              December 2007.

NEW

   [OpenID]   OpenID Foundation, "OpenID Authentication 2.0 - Final",
              December 2007.     http://specs.openid.net/auth/2.0

2. Please add the following URL to the [SREG1.0] reference:
    http://openid.net/sreg/1.0

OLD

   [SREG1.0]  OpenID Foundation, "OpenID Simple Registration Extension
              version 1.0", June 2006.

NEW

   [SREG1.0]  OpenID Foundation, "OpenID Simple Registration Extension
              version 1.0", June 2006. http://openid.net/sreg/1.0

3. Please move the [XRI2.0] reference from the normative (9.1) to
    informative (9.2) references subsection.

4. In the security considerations text, section 6, please replace "[1]" 
   with "[OpenID]", apparently that's a bug in xml2rfc somehow

OLD

   specification and to other literature [1].  Similarly, for general

NEW

   specification and to other literature [OpenID].  Similarly, for general 

5. In section 2.2:

OLD

   defined in the crudest sense.  That is, when one is prompted to
   approve or disapprove an authentication, anything that one might find
   on a browser is allowed, including JavaScript, fancy style-sheets,
   etc.  Because of this lack of structure, implementations will need to
   invoke a fairly rich browser in order to ensure that the
   authentication can be completed.

NEW

  defined in the crudest sense.  That is, when one is prompted to
  approve or disapprove an authentication, anything that one might find
  on a browser is allowed, including JavaScript, complex style-sheets,
  etc.  Because of this lack of structure, implementations will need to
  invoke a rich browser in order to ensure that the
  authentication can be completed.

6.  On page 5, section 2, item 6:

OLD

     6.  The SASL client now sends an response consisting of "=", to
          indicate that authentication continues via the normal OpenID
          flow.

NEW

   6.  The SASL client now sends an response consisting of "=" to the
       server, to indicate that authentication continues via the normal
       OpenID flow.

7. On page 6, section 2, item 8:

OLD

       Next the client optionally authenticates to the OP and then
       approves or disapproves authentication to the Relying Party.

NEW

       Next the end user optionally authenticates to the OP and then,
       depending on the OP, may approve or disapprove authentication
       to the Relying Party.