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. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
